metaclass | (no subject)

Сейчас кортексы например стоят дешевле 32-й меги. А для хаскеля на контроллере придется брать еще нечто пожирнее, потому что память ест непредсказуемо.

>Сейчас кортексы например стоят дешевле 32-й меги.

в 8..20 ногом корпусе бывают? Не везде нужно да и не везде лезет какой-нибудь plcc-48.

>А для хаскеля на контроллере придется брать еще нечто пожирнее, потому что память ест непредсказуемо.

Вот-вот. :) вместо простого быстрого решения, влезающего в 8ножку, мне предлагают нечто еще более эпическое чем 'propeller'(tm) :)

Самый хилый из кортексов в 20ногом корпусе. STM вроде планировали что-то малоногое.
Хаскель в контроллерах и правда не очень круто. А вот эрланг - интересненько. Можно было бы сети делать из контроллеров с удаленным обновлением кода.

>Можно было бы сети делать из контроллеров с удаленным обновлением кода.

это и на сях делается.
В случае всякой мелочи - бутлоадер или обмена скрипта для интерпретатора внутри контроллера.
в случае крупного - обычный линух с обычными ссш/дпкг/крон/итд.

20 ног иногда таки много. Чисто по размерам корпуса.

На сях сеть контроллеров делается крайне нетривиально, а на эрланге прозрачно из коробки. Обновление кода делается с горячей заменой кода - ни один интерпретатор для контроллеров этого не умеет. Кроме того, нехилые возможности по удаленному администрированию, которым ссш сливает по полной. Кроме того продвинутый фейловер, что немаловажно для железа в поле. Кроме того ин-мемори хранилище данных, альтернатива которым для железа сейчас только Sqlite, что явный перебор.

20 ног многовато, да. Ну может сделают 8ногую версию когда-нибудь. Чтобы например I2C/UART/ADC мультиплексированные, а остальное питание, земля, сброс и кварц.

>На сях сеть контроллеров делается крайне нетривиально

на сях уже всё сделано. Ставим линух и имеем готовую отлаженую инфраструктуру. (если контроллер достаточно жирный для линухов)

> нехилые возможности по удаленному администрированию

А можно весь список? ссш, естественно, не под виндой, а на нормальных ос.

> Кроме того ин-мемори хранилище данных, альтернатива которым для железа сейчас только Sqlite, что явный перебор.

у питона тоже есть что-то аналогичное, но я оба языка с их средами тщательно не щупал.
кстати, а как у эрланга с гарантиями-реалтаймами? В сях я могу гарантировать, что вот этот код заведомо выполнится менее чем за Х тактов, а в любых средах с автосборкой мусора эта гарантия почти гарантированно пропадает или требует серьезных костылей.

>20 ног многовато, да. Ну может сделают 8ногую версию когда-нибудь. Чтобы например I2C/UART/ADC мультиплексированные, а остальное питание, земля, сброс и кварц.

Кварц зачастую не нужен. 2 питания, 1 ресет, остальные 5 ног мультиплексированные. Ну или ресет тоже мультиплексированная, но тогда программирование будет чуть затейливее чем у авр через spi.

"Ставим линух и имеем готовую отлаженую инфраструктуру."
Почитай про распределенные приложения в Эрланге. Будешь удивлен. :)

"А можно весь список? ссш, естественно, не под виндой, а на нормальных ос."
Например, возможность поставить трейс на любой вызов не меняя кода. Сделать вызов процедуры прямо из шелла. Скомпилировать изменения в модуле также прямо из шелла и сделать горячую замену.

"кстати, а как у эрланга с гарантиями-реалтаймами?"
У Эрланга софт-риалтайм. Честно говоря, не совсем понимаю что это такое, но звучит круто. :)

У эрланга GC раздельный для каждого треда. Т.к. у идиоматических эрланг-тредов хип очень маленький обычно (зато тредов много), сборка мусора очень быстро отрабатывает (единицы микросекунд), причём виснет на это время только собираемый тред. Весь сетевой стек при этом продолжает работать (процесс может получать сообщения от сетевого стека, но не начинает их обрабатывать), поэтому в целом система никогда не делает пауз на GC.
В целом же Эрланг делался Эриксоном как раз для АТС, набранных из нескольких вычислительных нод и находящихся где-нибудь у чёрта на рогах. Отсюда удалённая консоль из коробки, отсюда возможность трейса всего и вся наживую, отсюда возможность замены любого кода прямо на лету, причём, возможно, с вызовом кода для смены состояния системы в новый формат. Отсюда куча разнообразных средств для обработки и изоляции ошибок, в т.ч. программиста.

А минимальные требования к системе какие?

А почему эрланг так малопопулярен, если он так крут?

>А минимальные требования к системе какие?
Зависит от того, что нужно. Есть готовые сборки под Gumstix/Beagle вот тут http://www.erlang-embedded.com/ , под ARM компилируется без проблем вроде. По производительности можно брать «чуть быстрее cpython», если не брать в расчёт JIT (я не знаю, работает ли он на ARM). Слышал из первых уст, что кто-то пилит бортовые компьютеры для авто на Erlang'е, ну и Erlang Solutions много рассказывали о том, как они двигают Erlang в embedded — сборки, поддержка от вендоров железа, тестирование на разном железе. Думаю, если заинтересуют, можно с ними связаться.
>А почему эрланг так малопопулярен, если он так крут?
Потому что основная часть софта в количественном плане — сайты по продаже виагры на пхп, там эрланг не нужен.

О, в официальном faq'е:
Rule of thumb: if the embedded system can run an operating system like linux, then it is probably possible to get current implementations of Erlang running on it with a reasonable amount of effort. Getting Erlang to run on, say, an 8 bit CPU with 32kByte of RAM is not feasible. People successfully run the Ericsson implementation of Erlang on systems with as little as 16MByte of RAM. It is reasonably straightforward to fit Erlang itself into 2MByte of persistant storage (e.g. a flash disk).

А. Ну это малоинтересно.
Вот что-то подобное для 8-биток было бы реально интересно.

Но зачем?

Зачем нужны восьмибитки?
Ну, малоногое маложручее иногда таки нужно.

Плюс, зачвстую, чисто топологически удобнее поставить стадо мелких 8-биток и не тянуть например тучу силовых проводов по всей конструкции.