Здравствуйте, Didro, Вы писали:
D>Здравствуйте, Gaperton, Вы писали:
G>>Например, у нас, пользуясь С-шным интеропом (c-node), парни сделали интерфейсы к интерпретаторам языков Verilog и VHDL.
D>Ух.(в смысле "ВАУ" ) А если не секрет, у нас это где?
ИТМиВТ. Сделано в рамках работ по разработке фрейворка поддержки быстрого архитектурного прототипирования аппаратуры (блоков микросхем). Будем применять у себя внутри — сокращаем цикл прототипирования микропроцессоров и всяких навороченых интеллектуальных устройств типа контроллеров памяти, также рассчитываем использовать для моделирования систем на кристалле. Ацкая штука получилась. На ней так все воздушно описывается, по сравнению с С, и аппаратчики код понимают .
Здравствуйте, Курилка, Вы писали:
К>А можно будет потом что-нибудь хотябы обзорное почитать о вашем решении? Какие плюсы, с какими проблемами столкнулись и т.п.?
Я писал об том в постах по немногу. Мы долго-долго собираемся статью на эту тему запузырить — типа, надо бы кандидатские защищать. Но ужасно лень. Просто кошмар какой-то. Надо будет поручить кому-нибудь, штоли .
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, Didro, Вы писали:
D>>Здравствуйте, Gaperton, Вы писали:
G>>>Например, у нас, пользуясь С-шным интеропом (c-node), парни сделали интерфейсы к интерпретаторам языков Verilog и VHDL.
D>>Ух.(в смысле "ВАУ" ) А если не секрет, у нас это где?
G>ИТМиВТ. Сделано в рамках работ по разработке фрейворка поддержки быстрого архитектурного прототипирования аппаратуры (блоков микросхем). Будем применять у себя внутри — сокращаем цикл прототипирования микропроцессоров и всяких навороченых интеллектуальных устройств типа контроллеров памяти, также рассчитываем использовать для моделирования систем на кристалле. Ацкая штука получилась. На ней так все воздушно описывается, по сравнению с С, и аппаратчики код понимают .
А можно будет потом что-нибудь хотябы обзорное почитать о вашем решении? Какие плюсы, с какими проблемами столкнулись и т.п.?
Все тот же хороший человек Перевел еще один man. Но вот какие у енго возникли вопросы
Да, кстати, есть идея написать статью "А как оно ваще работает", где на каком-нить простеньком примере показано совместное использование всех стандартных поведений, их взаимосвязь и основные функции оных поведений (т.е. не я =). Ибо я это буду читать =)). Вот тока писать это должен человек, который имел дело со всеме модулями и разбирается в конечных автоматах. А также необходимо придумать такую идиотскую задачу, в которой понадобятся все эти модули.
Еще интересен вопрос, не ничего имеющий общего с OTP, ака "Подключение Сишных библиотек внутрь Эрланга". Т.е. задача такова — есть некий источник данных, подключить который можно только на Си. Источнику в инициализации задается callback-функция, которую он дергает каждый раз по приходу данных. А эта функция должна каким-то образом послать данные в эрланговый процесс, который уже и будет заниматся форматированием, сортировкой и раздачей данных. Однако, просмотрев вскользь способ работы с openssl в ejabberd, мне показалось (мож я че недоглядел), что там ситуация несколько другая — эрланговый процесс дергает сишную функцию, которая тупо ждет на порту данных (как gen_tcp:recv) и возвращает их по мере прибытия. Если же послать сообщение в эрланг из си невозможно, то можно ли подключить сишный процесс как эрланговый и общатся с ним хоть как-нибудь (хотя пайпы оч нежелательны — больно нестабильно)?
Здравствуйте, Mamut, Вы писали:
M>Все тот же хороший человек Перевел еще один man. Но вот какие у енго возникли вопросы M>
M>Еще интересен вопрос, не ничего имеющий общего с OTP, ака "Подключение Сишных библиотек внутрь Эрланга". Т.е. задача такова — есть некий источник данных, подключить который можно только на Си. Источнику в инициализации задается callback-функция, которую он дергает каждый раз по приходу данных. А эта функция должна каким-то образом послать данные в эрланговый процесс, который уже и будет заниматся форматированием, сортировкой и раздачей данных. Однако, просмотрев вскользь способ работы с openssl в ejabberd, мне показалось (мож я че недоглядел), что там ситуация несколько другая — эрланговый процесс дергает сишную функцию, которая тупо ждет на порту данных (как gen_tcp:recv) и возвращает их по мере прибытия. Если же послать сообщение в эрланг из си невозможно, то можно ли подключить сишный процесс как эрланговый и общатся с ним хоть как-нибудь (хотя пайпы оч нежелательны — больно нестабильно)?
Есть несколько способов подключить сишный код.
1) Linked-in driver — код влинковывается в рантайм и ведет себя почти как эрланговский процесс.
2) C-node — сишный процесс виден как эрланговский узел.
По-моему, был еще промежуточный вариант, а может и нет, я не помню точно. Во всех случаях интерфейс делается через посылку сообщений "из С в Эрланг". Все это подробнейшим образом описано в документации. Например, у нас, пользуясь С-шным интеропом (c-node), парни сделали интерфейсы к интерпретаторам языков Verilog и VHDL.
Здравствуйте, Gaperton, Вы писали:
G>Например, у нас, пользуясь С-шным интеропом (c-node), парни сделали интерфейсы к интерпретаторам языков Verilog и VHDL.
Ух.(в смысле "ВАУ" ) А если не секрет, у нас это где?
Здравствуйте, Gaperton, Вы писали:
G>Есть несколько способов подключить сишный код. G>1) Linked-in driver — код влинковывается в рантайм и ведет себя почти как эрланговский процесс. G>2) C-node — сишный процесс виден как эрланговский узел. G>По-моему, был еще промежуточный вариант, а может и нет, я не помню точно.
Есть еще порты : я могу запустить, к примеру, ping — и получать от него сообщения. Это стандартный юниксвей и работа через пайпы
Есть SNMP, которые достаточно шустро бегают при малых размерах пакетов
Во всех случаях интерфейс делается через посылку сообщений "из С в Эрланг". Все это подробнейшим образом описано в документации. Например, у нас, пользуясь С-шным интеропом (c-node), парни сделали интерфейсы к интерпретаторам языков Verilog и
Все не совсем так ! Драйвер МОЖЕТ посылать сообщения в ерланг, ежели он работает в нити, но в большинстве случаев взаимодействие происходит через прямые вызова функций control в driver_entry — это намного быстрее. Такой прямой вызов может обеспечить миллионы обращений в секунду
G>Все не совсем так ! Драйвер МОЖЕТ посылать сообщения в ерланг, ежели он работает в нити, но в большинстве случаев взаимодействие происходит через прямые вызова функций control в driver_entry — это намного быстрее. Такой прямой вызов может обеспечить миллионы обращений в секунду
Но при этом драйверы рекомендуют не писать, потому что их сложно спроектировать и сделать грамотно.
Здравствуйте, Mamut, Вы писали:
M>Но при этом драйверы рекомендуют не писать, потому что их сложно спроектировать и сделать грамотно.
Что поделать ! Иногда приходится. Мне хочется интерфейс к Berkeley DB — и без драйвера тут никак. Люди хотят Тикль изнутри Ерланга — и не через пайпы или TCP/IP, а прямыми вызовами, ибо быстрее — и опять-таки придется вываивать драйвер. Такова се ля ва, как говорят просветленные 8))
M>Форум интегрирован с вики, но необходимо зарегистрироваться еще раз.
М.б. лучше было-бы поставить какой-нибудь wiki-blog ? типа npj.ru ?
Тогда community — и будут разделами форума, со всеми wiki-фичами типа ссылок, редактирования...