Возникли вопросы после прочтения вброса Алана Кокса в статье:

Компьютер — это конечный автомат. Потоковое программирование нужно тем, кто не умеет программировать конечные автоматы.

Не особо вдаваясь в теорию, сразу пошёл контраргумент о многоядерных машинах. Но потом, подумал, ведь и здесь их в принципе могут заменить n тасков распределённого приложения на n ядер, всем остальным пусть занимается Linux. А то и вообще многоядерные машины не нужны, ведь https://www.linux.org.ru/forum/talks/9156237...

Есть вопросы по теории конечных автоматов. Прочитав статью на википедии суть особо не чувствую, но возникла аналогия, что многопоточное приложение это несколько групп сборщиков - каждая собирает по вертолёту, а КА - конвейер производящий автомобили.

25 лет назад, 18 декабря 1987г., программист и лингвист Ларри Уолл выпустил первую версию языка программирования Perl.

>>> Подробности

Инновационный интерфейс, новая корневая идея, всплывающие окна, тонущие двери, убегающие стенки, конкурирующие звёзды, толкающие шары

Приглашаю в творческю мастерскую идей интерфейса

Есть обширное рабочее пространство. Одни окна лежат поверх других. Есть обычные координаты xгоризонталь и yвертикаль. Также есть zглубина. Слишком глубокие окна тонут и сворачиваются в иконку нижнего моря панели. Слишком близкие окна конкурируют с другими близкими окнами, конкуренты представляются как звёзды в верхней панели небе.

Например я пишу в чате, рисую картину, и играю в сапёра. Все эти окна топовые, они в самом вершу, поэтому это звёзды, звёзды конкурируют, это разные задачи как разные рабочие столы.

Передо мной круглая дверь около изображения, на ней надпись размытие. Я постучал в дверь. Из неё вышли две двери, размыть гаусово, размыть пиксельно, дверь из которой они вышли вывернулась на изнанку и утонула.

Я стучу в дверь размыть гаусово и за ней начинает размываться картинка. Я достаю картинку из за двери, но не даю утонуть этой двери, поэтому изменения оригинальной картинки влияет на размытую версию.

Я листаю каталоги информация загружается и стенки убегают. Ограниченность оперативки не позволяет мне разогнать все стенки, я какбы в пузыре стенок.

Я захожу в виртуальную машину через дверь и закрываю эту дверь изнутри, мне не мещают другие элементы я полностью в контексте.

Я трогаю шар под определённым вектором и вызываю причину его качения, ура я сделал необративное действие, это шаротрон.

Но я до этого ясно видел последствия трогания шара в этом векторе, потому что я представлял дальнейшие касания. Это как всё равно как нажать на кнопку.

Прошу не придираться к фантастичности и другому. А приглашаю в мастерскую перлов во имя новых идей !!

Перемещено tazhate из development

Ну во-первых, такая вот интересная ссылка:
http://cm.bell-labs.com/cm/cs/who/dmr/1stEdman.html

Маны к одной из первых версий юникс, датированные 1971 годом, то есть, около 40 лет назад.

Интересно, что тогда восьмеричные права доступа уже были, но было всего две цифры: rw владельца, rw не-владельца, исполнимость, suid. Вместо /etc/passwd и /etc/shadow были файлы /etc/uids который содержал только имя и uid, и собственно /etc/passwd который содержал пароли в открытом виде.

Перезагрузка машины осуществлялась командой /etc/boot и спрятана она в /etc она была что бы её случайно не запустили.

Команда cmp действовала практически так же, как в современных GNU/Linux. df и du имели даже такие же ключи, хоть и в меньшем количестве

Уже тогда был dc, правда не поддерживавший циклов, так что его нельзя назвать тьюринг-полным.

Вместо rm -i была специальная команда dsw которая показывала имена файлов и можно было выбрать, удалить их или оставить

Уже тогда была команда mount которая монтировала директорию и umount, которая, как можно догадаться, размонтировала. Правда umount понимал только формат umount /dev/... и у этих команд вообще не было опций

ln уже тогда была и позволяла делать только жесткие ссылки. И уже тогда был запрет на жесткие ссылки на директорию.

Кстати, не могу не дать ссылку вот на это: http://www.nordier.com/v7x86/download.html Хоть это и UNIX v7, но всё-таки там много общего с более старыми юниксами

О пользе отсроченной обработки функций. Ленивое программирование -- обобщенное понятие для отсрочки обработки функции или запроса до тех пор, пока не понадобятся результаты. Это понятие имеет многочисленные применения, от очевидных до скрытых. Понимание термина "ленивое программирование" может помочь избавить ваш код от ненужных вычислений и реструктурировать программы так, чтобы они были более проблемно-ориентированы.

>>> Подробности

Подскажите, пожалуйста, можно ли в лиспе работать с собственными структурами как в с++? Например вручную указать сколько памяти выделить для хранения и т.п. Гуглил, что можно делать как то через FFI, но ни одного примера не нашел, поэтому спрашиваю на данном форуме - можно ли управлять памятью программы и работать с указателями вручную?

Я знаю как минимум 4 слабо совместимых друг с другом понятия ООП:

• С++: класс = неймспейc, вызов метода через точку,
• CLOS: класс = идентификатор + наследование, тело метода определяется по классу всех параметров (а не только первого), методы доопределяются модификаторами :after :before :around.
• Racket: класс = first-class object, как и функция, соответственно, может доопределяться по месту и не иметь имени.
• Haskell: классы типов как наборы операций над типам (которые можно считать эквивалентными классам других языков)

Хотелось бы узнать, какой подход вам ближе и почему. А также, можно ли из упомянутых видов получить некую «идеальную реализацию» и какой синтаксис мог бы быть у такой реализации.

Подскажите какую книгу лучше прочитать дабы лучше понять язык C и устройство ЭВМ. Как работает компилятор, что делает препроцессор, что такое связывание, раннее, позднее, динамическое, символы. Как в ЭВМ происходит выделение памяти, что происходит при вызове функции.

С кратким комментарием — что именно произвело впечатление. Вот меня, например, в следующем порядке поразили:

1) Haskell в институте — системой типов, по сравнению с другими языками казалось неземной красотой, что можно написать всякие Show a, Num a.

2) Prolog тоже в институте — первый опыт настоящей декларативности — пишешь не то, что нужно делать, а что нужно получить и доступные для этого действия. Описал задачу, а система сама все решила.

3) Forth — тем, что самый мощный язык может быть написан в несколько сотен строк.

4) Io и Lua — Io чистотой и элегантностью концепции, а Lua тем, что интерпретатор мощного (на уровне JS) и простого языка может ещё и быстро работать.

5) Lisp — дата-код-дата, полноценная среда для вычислений в компайл-тайме и рантайме.

Ну и по-мелочи:

1) Python — 2D-синтаксисом.

2) colorForth — цветной синтаксис.

3) Katahdin — тем, что можно не очень сложно объединить кучу языков под крышей одного рантайма в пределах одного файла или строки.

4) D — тем, что из C++, в принципе, мог получиться нормальный язык.

5) Pascal ещё в школе, тем что можно было работать с динамической памятью, использовать арифметику указателей и вообще все эти двусвязные списки и т.п.

Может потом ещё что вспомню...

Уже некоторое время я использую язык OCaml в качестве альтернативы Си++ для написания разного рода полезных и не очень программ. Библиотек не очень много, но этот недостаток компенсируется простым как бревно интерфейсом к сишным либам, которых, как известно, чуть более чем дофига.

В качестве среды разработки я использую emacs. Существуют плагины для IDEA, eclipse и vim, но первый у меня не завелся, второй слишком тормозной, а последний умеет только бибикать и все портить.

Для emacs есть несколько пакетов, обеспечивающих базовые инструменты для работы с OCaml. В интернете широко распространен tuareg-mode, но я использую TypeRex.

TypeRex работает на линуксе и макоси, с окамлом старше 3.11.2 и емаксом с версии 23.2.1.

Искаропки умеет:

• навигация по коду (go to definition и т.п.);
• автокомплит;
• базовые возможности рефакторинга кода.

Говорят, его можно собрать и под OCaml 4.0, но я не пробовал.

Итак, на скриншоте можно увидеть:

• emacs (меню и туллбар, ага) с typerex, пресловутой темой solarized и шрифтами terminus
• эмулятор терминала через eshell
• скриншот с v4l2 устройства, полученный в процессе чтения Unix system programming in OCaml и ковыряния библиотеки ocaml-extunix
• в остальном — дефолтная убунта

например:

(defun f (&obj)
 (with-slots a b c) obj
  (setf a b)
  (setf b c)))

Пора уже опубликовать результаты сравнения и сделать официальные выводы.

Таки мне удалось формализовать описание расширения системы команд микропроцессора для реализации микроядра L4 на кристалле. Бонусом идёт аппаратный планировщик. Пока речь не идёт об адресных пространствах и об MMU сказано лишь несколько строк. Хотелось бы задать несколько вопросов специалистам по VHDL/Verilog и юристам по патентному праву. Я в правильное место попал?

Добрый день дорогие аналитики L0R'a. Ковыряю ракет, пишу на нем клиентскую программу - а пока хочется вот что спросить. Все же что лучше - Racket или Common Lisp? Что более перспективно? Ну и естественно, какие у одного недостатки/преимущества по сравнению с другим?

Уже много дней пишу на C++, но так сложилось, что в проектах, в которых я участвую, исключения не используются.

На днях задумался о том, чтобы протестировать их в одном из своих собственных проектов. Перед этим хотелось бы почитать какие-нибудь умные буквы о том, почему исключения - это хорошо.

Приветствуются ссылки на статьи на русском и английском языках.

Так же можете оставлять свое собственное мнение о практике и философии использования исключений в с++ коде.

Я тут упоролся и подумал, а что если бы у нас был ЯП уровня Си с гомоиконным синтаксисом в стиле Io или Julia. То есть — у нас есть интерпретатор гомоиконного языка, который работает как макропроцессор, и результат трансформаций исходного кода скармливается затем компилятору языка с Си-подобной семантикой. И у нас будет нормальный тьюринг-полный макроязык, который позволит бескостыльно расширять возможности ЯП неограниченно. Компилирующаяя же часть будет по сути обычным компилятором Си (просто читающим входные данные в неСишном синтаксисе).

Это ж кайф. Выражения типа regexp(«^[a-z][a-z0-9]») или format(«%s - %s (%d)», bla1, bla2, i) можно будет автоматически обрабатывать макропроцессором и отправлять компилятору оптимизированный вариант. Это значит, регулярка, например, будет скопилирована в конечный автомат при компиляции программы, а не при выполнении.

Вот эта вот странная задачка, на которой dr_jumba проверял лаконичность языков, записывалась бы как-то вот так:

sample_function := fn(a(iterable(T))) to(T) {
    a select(match(regexp(/^J[a-z]+/))) each_chunk(3) map(format_with("~1 and ~2 follow ~3")) join("\n")
}

Дискас.

Хочу найти экстремально простую и понятную реализацию (и желательно небольшую по объёму кода), пускай и тормозную для какого-нибудь простого динамического языка программирования.

Под такими языками я имею ввиду: Scheme, Tcl, Lua, может быть JavaScript (хотя не хотелось бы).

В первую очередь нужна простота и понятность.

ЛОР, подскажешь?

Сабж. Есть идеи, хочу их попробовать. Если ли, скажем, какие-то тулкиты для эээ автоматизации этого? Ну, например, набор примитивов (структуры, списки, массивы ...), плюс какие-нить парсеры итд итп. Я не про yacc/bison+llvm, а про что-нить более высокоуровневое и лузер-френдли.

Добрый день.

Читаю про адресацию в Линуксе, но никак не могу понять почему логический (линейный) адрес в ядре _всегда_ соответствует физическому, только смещен на константу. Читал, что это должно как-то увеличивать скорость, но ведь все равно адрес преобразовывается или через таблицу страниц или через tlb и, как мне кажется, ему должно быть тогда все равно. Смысл вижу только, если память будет использоваться при вводе/выводе (DMA, например).

И почему ядро старается разместиться в ZONE_NORMAL, а не в ZONE_HIGH, например? Ведь адреса-то виртуальные.

Небольшой вопрос по циклам в Forth.

При выполнении цикла, команды внутри него вообще не взаимодействуют со стеком параметров? Т.е. внутри цикла создается новый стек и единственная связь между внешним стеком и внутренним происходит с помощью операторов типа I?

Ну и наверное cast KRoN73