В моём случае переключение только линий данных приводило к тому, что хост, к которому был подключен новый slave (клавиатура, мышь), не замечал факта подключения - или, по крайней мере, замечал нестабильно/не сразу. С обрывом питания на пару секунд - замечал сразу. Не исследовал, что там происходит на физическом уровне, но предполагаю, что при получении питания подчинённое устройство по шине данных посылает какой-то специальный сигнал "я подключилось, инициализируй связь со мной". При переключении подчинённому, видимо, кажется, что ведущий просто перестал слать пакеты, и соответствующий сигнал "инициализируй меня" оно не посылает.
Вот здесь я описывал архитектуру разрабатываемой системы, в которой ядро взаимодействует с локальными модулями, а также другими ядрами по сети при помощи вот таких бинарных пакетов. Структуру самих пакетов как-нибудь опишу более подробно.
Если вкратце - на основе API метода (оторванного от языка) формируется соглашение о раскладке полей аргументов и возвращаемых значений. Затем ядро пакует данные с использованием описанного итератора и передаёт модулю, а тот распаковывает - либо с использованием тех же итераторов (если используется C++ SDK), либо самостоятельно (есть пример модуля на чистом C, который просто приводит полученный void* к указателю на соответствующую структуру). И наоборот: модули пакуют данные, ядро - распаковывает. Получилось лаконичнее, чем если бы на каждый метод была своя структура данных (как у GRPC, к примеру).
Добрый день! Да, если бы была рефлексия, можно было бы перевести код на неё. Не думаю, что он бы стал сильно проще в итоге: поскольку речь о передаче данных в т. ч. по сети и в модули на других языках, к собственно плюсовому представлению данных привязываться нельзя. Да, только примитивы - возможна передача по сети. Представление строк показано, представление массивов аналогично, вместо объектов передаются хэндлы, которые можно затем использовать для вызова.
Что-то я перестал понимать, какую задачу Вы решаете. Если Вы хотите на базе JSON или подобного формата построить среду, в которой возможность любых программ взаимодействовать гарантируется по построению (на уровне возможности подмены любого узла любым совместимым узлом без необходимости менять что-либо в других узлах), то Вам так или иначе придётся строго определить правила взаимодействия. Можно не в виде "монструозного фреймворка", а в виде спецификации протокола взаимодействия, который каждая программа поддерживает самостоятельно, - количество информации получится одним и тем же (а вот работы программисту в случае с готовым фреймворком заметно убавится). В принципе, к описанной в статье системе ничего не мешает прикрутить интерфейс доступа по JSON (или даже заменить им основной канал), было бы желание.
Если же Вы просто хотите обмениваться какими-то данными в JSON или 9P, то это придумали до нас с Вами, но задач, ради которых затеяна описанная в статье разработка, это не решает.
CLR вполне себе активно используется - на дотнет много разработки идёт. SOAPы-RESTы тоже, вроде, умирать не собираются. COM... Опять же, трансформировался в ActiveX, на котором пусть не так много чего-то пишется сейчас, но и от написанного вряд ли получится так сразу избавиться. Из более свежего можно вспомнить какой-нибудь GRPC. Но да, я и не утверждаю, что сам подход с ООП-RPC я лично придумал - было бы странно, если бы это не оказалось похоже на что-то из уже существующего.
Разумеется, вызовы могут быть и синхронными, и асинхронными. В спойлерах есть примеры кода и того, и другого.
Согласен, массовому пользователю это не надо - по крайней мере, не на системном уровне (хотя какие-то приложения на базе этой системы могут оказаться востребованы, но, опять же, всем будет пофиг на то, что у них под капотом). Точно так же какой-нибудь Linux долгое время был уделом гиков, но, тем не менее, сумел проложить путь подходу к разработке и распространению софта, отличным от принятых на тот момент в проприетарном мире. Если предложенная система сможет послужить чему-то подобному, пусть даже в качестве одного из камней пути, - будет здорово.
Транспортный уровень для передачи пачек байтов (в т. ч. при файловых операциях), разумеется, будет проще, чем для передачи сложно структурированных данных, однако кажущееся облегчение от отсутствия монструозных SDK обернётся необходимостью всю обработку этих сырых данных делать уровнем выше - со всеми вытекающими. Здесь изначально подход "скажи мне, что делать, а не как" - требует больше информации на уровне API, чем при банальном "всё есть файл".
Для управления питанием: отключения отдельных потребителей (камера, звуковуха), а также выбора источника питания схемы. Наверное, человек с бОльшим, чем у меня, опытом в электронике сделал бы это на транзисторах, но меня смутила перспектива падения напряжения на них.
Спасибо за подробный ответ. Я не понял только, каким образом состояния атома и фотона запутываются без взаимодействия - я как-то думал, что запутанное состояние всегда рождается в результате какого-то процесса, в котором участвуют обе запутанные частицы: например, два запутанных фотона излучаются одним и тем же фермионом, или какая-то иная причинно-следственная связь присутствует. Я не помню, чтобы фотон мог провзаимодействовать с фермионом как-либо, кроме как через поглощение. Или в данном случае запутанность возникает без взаимодействия или какой-либо другой причины?
Мне попадались вариации, где двигатель не упоминался, а самолёт был троссом привязан к неподвижному относительно земли объекту (бетонному блоку, флагштоку и т. п.). В обоих случаях установившийся режим один и тот же: самолёт неподвижен относительно земли, конвейер под ним движется с, как минимум, взлётной скоростью самолёта, трение в колёсах компенсируется (двигателем или натяжением тросса) - или наоборот, работа двигателя компенсируется трением в колёсах.
Спасибо, мысль понял. Сначала хотел привести пример с точками, лежащими по разные стороны горизонта событий, потом понял, что так мы докажем лишь, что евклидова геометрия не годится для описания данного конкретного пространства, но не её принципиальную неверность - для своего класса задач она останется применимой. Забавно, что так мы в конечном счёте вышли на подтверждение исходной мысли о неустранимости аксиом из теории.
Все вопросы к автору коммента. Я нигде не утверждал, что опровергнуто может быть лишь то, что относится к материальному миру, вся математика с её вечным "мы пришли к противоречию, теорема доказана" - яркий пример обратного. Энергия, число, психотип, скорость, Великобритания, электрон, гравитация - такие же абстракции, как прямая, введённые для удобства описания реально наблюдаемых явлений.
Не вижу проблем с тем, чтобы опровергнуть данную аксиому. Берём две точки А, Б, через которые нельзя провести прямую. Показываем, почему их координаты не могут одновременно удовлетворять уравнению одной и той же прямой с любыми параметрами. Либо, по желанию, показываем то же графически. Профит.
Лично наблюдал подобный, ммм, обмен мнениями на физматфоруме. Кто-то считал, что на взлёт самолёта влияет именно его скорость относительно поверхности, на которой он стоит. Кто-то говорил, что для того, чтобы компенсировать трение в колёсах, самолёту придётся включить двигатель, а тот приведёт к взлёту. Самые смелые приплетали увлечение поверхностного слоя воздуха лентой транспортёра, что должно было создать ту самую разницу давлений.
О как. Интересный вывод, спасибо. Т. е. получается, что я рассматриваю только часть системы, как в задачке про экономию бензина путём выбора системы отсчёта? Здорово. Спасибо за объяснение, надо с ним теперь свыкнуться.
В моём случае переключение только линий данных приводило к тому, что хост, к которому был подключен новый slave (клавиатура, мышь), не замечал факта подключения - или, по крайней мере, замечал нестабильно/не сразу. С обрывом питания на пару секунд - замечал сразу. Не исследовал, что там происходит на физическом уровне, но предполагаю, что при получении питания подчинённое устройство по шине данных посылает какой-то специальный сигнал "я подключилось, инициализируй связь со мной". При переключении подчинённому, видимо, кажется, что ведущий просто перестал слать пакеты, и соответствующий сигнал "инициализируй меня" оно не посылает.
Вот здесь я описывал архитектуру разрабатываемой системы, в которой ядро взаимодействует с локальными модулями, а также другими ядрами по сети при помощи вот таких бинарных пакетов. Структуру самих пакетов как-нибудь опишу более подробно.
Если вкратце - на основе API метода (оторванного от языка) формируется соглашение о раскладке полей аргументов и возвращаемых значений. Затем ядро пакует данные с использованием описанного итератора и передаёт модулю, а тот распаковывает - либо с использованием тех же итераторов (если используется C++ SDK), либо самостоятельно (есть пример модуля на чистом C, который просто приводит полученный void* к указателю на соответствующую структуру). И наоборот: модули пакуют данные, ядро - распаковывает. Получилось лаконичнее, чем если бы на каждый метод была своя структура данных (как у GRPC, к примеру).
Добрый день!
Да, если бы была рефлексия, можно было бы перевести код на неё. Не думаю, что он бы стал сильно проще в итоге: поскольку речь о передаче данных в т. ч. по сети и в модули на других языках, к собственно плюсовому представлению данных привязываться нельзя.
Да, только примитивы - возможна передача по сети. Представление строк показано, представление массивов аналогично, вместо объектов передаются хэндлы, которые можно затем использовать для вызова.
Что-то я перестал понимать, какую задачу Вы решаете. Если Вы хотите на базе JSON или подобного формата построить среду, в которой возможность любых программ взаимодействовать гарантируется по построению (на уровне возможности подмены любого узла любым совместимым узлом без необходимости менять что-либо в других узлах), то Вам так или иначе придётся строго определить правила взаимодействия. Можно не в виде "монструозного фреймворка", а в виде спецификации протокола взаимодействия, который каждая программа поддерживает самостоятельно, - количество информации получится одним и тем же (а вот работы программисту в случае с готовым фреймворком заметно убавится). В принципе, к описанной в статье системе ничего не мешает прикрутить интерфейс доступа по JSON (или даже заменить им основной канал), было бы желание.
Если же Вы просто хотите обмениваться какими-то данными в JSON или 9P, то это придумали до нас с Вами, но задач, ради которых затеяна описанная в статье разработка, это не решает.
CLR вполне себе активно используется - на дотнет много разработки идёт. SOAPы-RESTы тоже, вроде, умирать не собираются. COM... Опять же, трансформировался в ActiveX, на котором пусть не так много чего-то пишется сейчас, но и от написанного вряд ли получится так сразу избавиться. Из более свежего можно вспомнить какой-нибудь GRPC. Но да, я и не утверждаю, что сам подход с ООП-RPC я лично придумал - было бы странно, если бы это не оказалось похоже на что-то из уже существующего.
Разумеется, вызовы могут быть и синхронными, и асинхронными. В спойлерах есть примеры кода и того, и другого.
Согласен, массовому пользователю это не надо - по крайней мере, не на системном уровне (хотя какие-то приложения на базе этой системы могут оказаться востребованы, но, опять же, всем будет пофиг на то, что у них под капотом). Точно так же какой-нибудь Linux долгое время был уделом гиков, но, тем не менее, сумел проложить путь подходу к разработке и распространению софта, отличным от принятых на тот момент в проприетарном мире. Если предложенная система сможет послужить чему-то подобному, пусть даже в качестве одного из камней пути, - будет здорово.
Транспортный уровень для передачи пачек байтов (в т. ч. при файловых операциях), разумеется, будет проще, чем для передачи сложно структурированных данных, однако кажущееся облегчение от отсутствия монструозных SDK обернётся необходимостью всю обработку этих сырых данных делать уровнем выше - со всеми вытекающими. Здесь изначально подход "скажи мне, что делать, а не как" - требует больше информации на уровне API, чем при банальном "всё есть файл".
Для управления питанием: отключения отдельных потребителей (камера, звуковуха), а также выбора источника питания схемы. Наверное, человек с бОльшим, чем у меня, опытом в электронике сделал бы это на транзисторах, но меня смутила перспектива падения напряжения на них.
Ага. Ага. Спасибо, понял, что надо рассматривать полный спектр выходных состояний.
Большое спасибо! Хорошее объяснение, с которым нужно переспать. Возможно, позже появятся дополнительные вопросы.
Спасибо за подробный ответ. Я не понял только, каким образом состояния атома и фотона запутываются без взаимодействия - я как-то думал, что запутанное состояние всегда рождается в результате какого-то процесса, в котором участвуют обе запутанные частицы: например, два запутанных фотона излучаются одним и тем же фермионом, или какая-то иная причинно-следственная связь присутствует. Я не помню, чтобы фотон мог провзаимодействовать с фермионом как-либо, кроме как через поглощение. Или в данном случае запутанность возникает без взаимодействия или какой-либо другой причины?
Мне попадались вариации, где двигатель не упоминался, а самолёт был троссом привязан к неподвижному относительно земли объекту (бетонному блоку, флагштоку и т. п.). В обоих случаях установившийся режим один и тот же: самолёт неподвижен относительно земли, конвейер под ним движется с, как минимум, взлётной скоростью самолёта, трение в колёсах компенсируется (двигателем или натяжением тросса) - или наоборот, работа двигателя компенсируется трением в колёсах.
Спасибо, мысль понял. Сначала хотел привести пример с точками, лежащими по разные стороны горизонта событий, потом понял, что так мы докажем лишь, что евклидова геометрия не годится для описания данного конкретного пространства, но не её принципиальную неверность - для своего класса задач она останется применимой. Забавно, что так мы в конечном счёте вышли на подтверждение исходной мысли о неустранимости аксиом из теории.
Все вопросы к автору коммента. Я нигде не утверждал, что опровергнуто может быть лишь то, что относится к материальному миру, вся математика с её вечным "мы пришли к противоречию, теорема доказана" - яркий пример обратного. Энергия, число, психотип, скорость, Великобритания, электрон, гравитация - такие же абстракции, как прямая, введённые для удобства описания реально наблюдаемых явлений.
А где вообще речь шла про материальный мир?
Не вижу проблем с тем, чтобы опровергнуть данную аксиому. Берём две точки А, Б, через которые нельзя провести прямую. Показываем, почему их координаты не могут одновременно удовлетворять уравнению одной и той же прямой с любыми параметрами. Либо, по желанию, показываем то же графически. Профит.
Лично наблюдал подобный, ммм, обмен мнениями на физматфоруме. Кто-то считал, что на взлёт самолёта влияет именно его скорость относительно поверхности, на которой он стоит. Кто-то говорил, что для того, чтобы компенсировать трение в колёсах, самолёту придётся включить двигатель, а тот приведёт к взлёту. Самые смелые приплетали увлечение поверхностного слоя воздуха лентой транспортёра, что должно было создать ту самую разницу давлений.
О как. Интересный вывод, спасибо. Т. е. получается, что я рассматриваю только часть системы, как в задачке про экономию бензина путём выбора системы отсчёта? Здорово. Спасибо за объяснение, надо с ним теперь свыкнуться.
Спасибо, что пояснили. Да, с этим согласен.
Ну, так и точка не имеет размера и, стало быть, не является физической. На этом основании предлагаете демонтировать геометрию, начав с аксиом?