Comments 30
Photoshop под неё есть?
Разрыв мозга при первом прочтении… оставлю на осмысливание, через пару часов попробую еще раз понять…
В инферно любая программа либо просто завершается (если всё в порядке), либо генерирует исключение, значение которого это строка с текстом ошибки. Принято соглашение, по которому эта строка должна начинаться на «fail:» если это ошибка штатная — т.е. приложение не «упало», а просто хочет выйти вернув эту ошибку тому, кто это приложение запустил (обычно это шелл). [...] после завершения запущенной команды [...] текст ошибки-исключения будет находится в переменной окружения $status (префикс «fail:» из него будет автоматически удалён, если текст исключения кроме «fail:» больше ничего не содержал, то в $status будет строка «failed»).
Вот за такое того, кто это проектировал, хочется убить.
Да, меня тоже всегда удивляло, нафига было вводить неоднозначность на пустом месте. Я даже больше скажу, дополнение насчёт «failed» появилось 4 года назад, после того, как я отрапортовал баг, что приложение упавшее с ошибкой «fail:» считается успешно завершившимся. Ну, значит и на старуху бывает проруха. Архитектура инферно содержит очень много практически гениальных решений, которые позволили невероятно упростить и саму ОС, и софт который под неё пишется (поэтому я и предпочитаю писать именно под инферно). Но с этим моментом они явно погорячились. К счастью, это всё-таки не критичная мелочь, и жить не мешает.
Вот Вы говорите что пишите под инферно — можете отписать какие именно приложения? Меня интересует именно сетевой код + работа в нативном режиме.
Если под нативным режимом имеется в виду запуск инферно на голом железе, то я этого не делал — я использую инферно под линухом просто как комфортный runtime для своего кода, виртуальную машину а-ля JVM, только намного проще и функциональнее (всё-таки это полноценная ОС, в неё можно удалённо зайти, позапускать/покилять процессы, подключиться удалённым отладчиком, etc.).
Пишу в основном сетевые сервисы — обычные TCP сервера/клиенты, работающие в кластере (находящие друг друга через инферновский штатный реестр сервисов), общающиеся между собой в JSON, etc. Но по большей части такой стиль вызван тем, что инферновские сервисы добавляются в существующую систему, где остальные сервисы написаны в основном на Perl — если бы инферно внедрялась с самого начала, то вместо TCP использовалили бы более естественный для инферно протокол 9P/Styx и сервисы бы реализовывались не как TCP-сервера, а как обычные инферновские файловые сервера.
Пишу в основном сетевые сервисы — обычные TCP сервера/клиенты, работающие в кластере (находящие друг друга через инферновский штатный реестр сервисов), общающиеся между собой в JSON, etc. Но по большей части такой стиль вызван тем, что инферновские сервисы добавляются в существующую систему, где остальные сервисы написаны в основном на Perl — если бы инферно внедрялась с самого начала, то вместо TCP использовалили бы более естественный для инферно протокол 9P/Styx и сервисы бы реализовывались не как TCP-сервера, а как обычные инферновские файловые сервера.
меня больше интересует возможность запуска Inferno как очень легкого гипервизора под другой Inferno. Поскольку сейчас в качестве хоста лучше всего использовать OpenBSD — и хоть она и хороша — но хочется native self-hosted.
По поводу чисто 9P/Styx тут думаю не все так просто — т.к. если приложение работает через WAN то есть вероятность того что трафик могут «завернуть», поэтому использование TCP считаю оправданным, а Styx хорош только для локальных задач.
P.S. в личку отписал пару вопросов про итоговый КПД.
По поводу чисто 9P/Styx тут думаю не все так просто — т.к. если приложение работает через WAN то есть вероятность того что трафик могут «завернуть», поэтому использование TCP считаю оправданным, а Styx хорош только для локальных задач.
P.S. в личку отписал пару вопросов про итоговый КПД.
Как это «завернуть»? Сам 9P работает обычно через TCP (порт 6666), с чего бы его кто-то стал блокировать? У 9P другая проблема — высокая latency, для задач вроде раздачи больших файлов не подойдёт. А вот как раз для виртуальных файловых серверов, которые на самом деле не файлы, а какие-то сервисы просто выглядящие как каталог с файлами — 9P идеален.
и очень плохо что 2 мои любимые ОС — QSS QNX и Vita Nuova Inferno — обе не поддерживают 64бита — а если учесть что в продакшене сейчас только x64 — то наводит на грусные мысли.
Это, конечно, пичалька… но в 32-битном режиме инферно отлично работает на 64-битных ОС. Самой инферно 64 бита внутри особо не нужны. Так что хочется, конечно, нативную 64-битную версию, но её отсутствие сильно жить не мешает. Вроде несколько лет назад в maillist-е пробегал патч добавляющий поддержку 64-бит, но он Форсайту не понравился чем-то — по крайней мере ходят такие слухи.
в режиме эмуляции (OS-hosted) проблем конечно нету, однако если делать Out-of-box решение — то нужен доступ к памяти более чем 4GB по сумме — к сожалению попытка написать приложения с возможностью аллоцирования такого региона не удалась — тестил на RHEL6 c 16GB RAM, но запустить 8 приложения по 1GB в каждом не удалось :(
UFO just landed and posted this here
Ну, на протёкшую абстракцию эта проблема не тянет. Это просто пара строк в коде sh, которые, по-моему, надо просто выкинуть. Я даже не уверен, что от этого что-то где-то сломается.
UFO just landed and posted this here
Почему? Что не так с исключениями? В инферно архитектура построена так, чтобы все задачи решать минимумом выделенных сущностей. Если в приложениях уже есть исключения (и в 99% это обычные строки, а не объекты), зачем вводить отдельную сущность «код возврата приложения» если можно использовать для этой цели те же исключения? Кроме того, в инферно нет разницы между приложениями и модулями/библиотеками, так что ваше приложение абсолютно не обязательно было вызвано именно как приложение, в отдельной нити и т.п. — его функцию init() могли запустить и как обычную функцию из другого приложения, так что завершение вашего приложения с ошибкой через генерирование исключения позволит штатно перехватить и обработать это исключение в программе, которая вызвала ваш init().
Что касается workaround-а, то это не workaround а соглашение. Не всегда нужно писать код реализующий некую функциональность, иногда достаточно задокументировать определённые соглашения, которые позволят получить эту же функциональность без лишних строчек кода. В инферно такие соглашения используются довольно активно, и это опять же позволило много упростить.
Что касается workaround-а, то это не workaround а соглашение. Не всегда нужно писать код реализующий некую функциональность, иногда достаточно задокументировать определённые соглашения, которые позволят получить эту же функциональность без лишних строчек кода. В инферно такие соглашения используются довольно активно, и это опять же позволило много упростить.
завершение вашего приложения с ошибкой через генерирование исключения позволит штатно перехватить и обработать это исключение в программе, которая вызвала ваш init().
Это как бы само по себе не означает, что среда выполнения должна обрабатывать исключения именно как строки, да еще и с соглашением. Как раз наоборот, в моем понимании это должно означать, что среда выполнения должна эти исключения перехватывать и отдавать наружу в виде того же исключения, чтобы по нему можно было понять, что и как дальше делать. А не парсить строку.
Не всегда нужно писать код реализующий некую функциональность, иногда достаточно задокументировать определённые соглашения, которые позволят получить эту же функциональность без лишних строчек кода. В инферно такие соглашения используются довольно активно, и это опять же позволило много упростить.
Я надеюсь, к этим соглашениям верификатор прилагается?
(ключевые слова: programming by contract, defensive programming)
Насколько я понимаю, исключения в инферно изначально были только строковые, возможность ограниченно использовать объекты была добавлена значительно позднее, и ей практически никто не пользуется (по-моему, её используют только в сложных парсерах). Строки-исключения при выборе обработчика обычно парсятся самим Limbo по шаблону «prefix*», что просто, наглядно, и никаких проблем не вызывает.
Верификатор не прилагается. Желающие выстрелить себе в ногу всегда найдут способ это сделать, сколько assert-ов в код не пихай.
Верификатор не прилагается. Желающие выстрелить себе в ногу всегда найдут способ это сделать, сколько assert-ов в код не пихай.
Насколько красив и строен Unix Shell, настолько странен и неуклюж Windows Shell, многие программы до сих пор не научились верно возвращать return code.
А вы про какой именно Windows Shell говорите?
Вроде как Windows Shell это explorer.exe (штатный shell по умолчанию — как оболочка), а вот командная строка с Windows Vista — это Windows PowerShell — и там возможности весьма и весьма широки (тесная связь с WMI уже хорошо)
Смайлики. Теперь и в топиках.
Кстати говоря,
alias emu-g='rlwrap -a -r emu-g' действительно делает работу с шеллом инферно намного удобнее! И подсветку синтаксиса для Vim я уже сделал. Так что из недостатков осталась только скорость работы. Впрочем, насчёт неё тоже есть идея что проверить, но быстро это сделать не получится.
Я когда-то пытался перейти с bash на ремейк rc из Plain9. Там была даже некоторая поддержка readline, но комплетишен был гараздо хуже.
Через rlwrap копмлетишен нормально не сделаешь. А жаль, shell был бы удобный.
Через rlwrap копмлетишен нормально не сделаешь. А жаль, shell был бы удобный.
Sign up to leave a comment.
Inferno Shell