Здравствуйте, WolfHound, Вы писали:

V>>Давай в отдельной теме рассмотрим IOMMU. А то сдается мне, кто-то чего-то недопонимает насчет этой технологии. Там не отсутсвует DMA, там ровно наоборот, работа с любыми аппаратными ресурсами идет теперь примерно так же, как раньше только для DMA. В общем, в этой однородности суть (см. спецификации HyperTransport).
WH>Главное там то, что можно сказать какие страницы памяти может трогать данная железка.
WH>Все остальное к делу не относится.

Неверно. Страницы памяти можно назначить любые. Полная функциональность DMA сохраняется. Я же сказал — любое обращение к аппаратуре выполняется в стиле DMA — посылкой пачки байт. Только теперь эта пачка называется "сообщением" и идёт обмен сообщениями вместо записи в многие регистры ввода/вывода (о семантике которых операцинка ни слухом ни духом) и слушания многих прерываний (аналогично). Т.е. теперь идет унифицированный обмен как целевыми данными, так и настройками для этих данных. Речь относительно IOMMU о том, чтобы некий верификатор "понимал" семантику этих сообщений и енфорснул бы типобезопасность операций DMA.

Так вот, мой аргумент был в том, что за десяток лет разновидностей DMA накопилось столько, что разработчики Сингулярити жалуются, что покрыть этот зоопарк практически невозможно. Я предположил, что рано или поздно аналогичное случится для будущих спецификаций IOMMU. Сейчас этот подход еще не набрал популярность, а уже пяток несовместимых спецификаций налицо. Что будет, когда на IOMMU перейдут в полный рост?


WH>>>>>Кстати IOMMU на данную модель натягивается почти автоматически.
V>>>>Не натягивается на эти два дврайвера без введения дополнительных динамических артефактов в среду исполнения, эдаких известных операционке структурах, на которых достоверно переносятся адреса страниц из диапазонов, прописанных в манифесте.
WH>>>Что за бред?
WH>>>Какие еще адреса страниц в манифесте?
V>>ОМГ.
WH>Ты давай по существу.
WH>Или не в состоянии.
WH>Ибо для IOMMU не нужно ничего прописывать ни в каком манифесте.
WH>Ибо страницы выделяются динамически.
WH>И динамически прописываются в IOMMU для данной железки.

В манифесте указываются ресурсы, к которым обращается драйвер. Насколько я понял, еще до загрузки операционки известно, какой драйвер какие физические адреса памяти получит, если они ему нужны в кач-ве ресурсов (как пример — область адресов для "окон" памяти видеокарты). Если верификатор будет знать сообщения IOMMU "в лицо", он сможет проверить, что в этих сообщениях фигурирует только диапазоны памяти (для операций IOMMU->DMA), указанные в манифесте.

==========
на остальное потом

Здравствуйте, vdimas, Вы писали:

V>Потому что у нас плоская модель памяти, которая, как мне представлялось, возможна только при неких гарантиях. А тут требуется кусок предвыделенной т.н. "low memory" описать парой адресов в одном процессе-драйвере и передать в другой процесс пользовательского уровня для модификации.
И в чем проблема то?

WH>>Особенно если пользовательский код скажет: Дай мне кусок памяти подходящий для DMA.
WH>>После чего просто отправит его в драйвер.
V>Покажи плиз, как оформить этот небезопасный код, чтобы его пропустил верификатор?
Да запросто.
AllocateDmaMamory(size : int) : option[DmaBuffer]
DmaBuffer это уникальный указатель на память доступную для ДМА.
Если процесс его потеряет то система сразу об этом узнает.
И благодаря уникальности процесс может спокойно передать его в другой процесс.

V>Это не тот уровень опасности, это уровень устойчивости к стресс-сценариям, он не несет опасность в плане обсуждаемого несанкционированного доступа к произвольным данным.
Вот и я говорю, что ничего другого не придумать.
Это единственная проблема.

V>Мне пока хочется понять трюк с записью в ПРОИЗВОЛЬНУЮ память на уровне пользовательского кода. Я так-то со многими доводами относительно Сингулярити соглашался из-за того, что считал, что это невозможно. Если же это возможно, хотелось бы увидеть — как?
Откуда ты взял слово ПРОИЗВОЛЬНУЮ я так и не понял.

Но что самое интересное IOMMU полностью снимает эту проблему. А без IOMMU ОС с программной защитой не живут.
Бутылка тоже не жилец.
Так что тут даже отдельного API не понадобится.
Просто выделяем уникальный буфер и все.

V>Это я не тебе. А перевод не такой уж кривой. Автор перевода присылал мне его на коррекцию когда-то, но после нескольких первых откорректированных и возвращенных исправленых абзацев я увидел, что мои уточнения, скажем так, задевают автора перевода... Просто мои уточнения шли в плане тонкостей речевых оборотов (репорт написан довольно свободным языком), и эти исправления спровоцировали спор в стиле "а какая разница???". В общем, я самоустранился от сего неприятного времяпрепровождения, хотя успел сверить перевод с оригиналом. Если не обращать внимание на тонкости речевых оборотов, всё более-менее верно.
Да я бы не сказал. За давностью уже не помню, какие там косяки. Но их там хватает.

Здравствуйте, WolfHound, Вы писали:

V>>Я уже молчу о такой предложенной вещи как "личное" кликанье юзверя с нужными правами мышью по кнопке ОК этого диалога...
WH>Еще можно сделать так чтобы юзер один раз написал в консоли, что данное приложение имеет доступ к данной папке.

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

Здравствуйте, vdimas, Вы писали:

V>Неверно. Страницы памяти можно назначить любые. Полная функциональность DMA сохраняется. Я же сказал — любое обращение к аппаратуре выполняется в стиле DMA — посылкой пачки байт. Только теперь эта пачка называется "сообщением" и идёт обмен сообщениями вместо записи в многие регистры ввода/вывода (о семантике которых операцинка ни слухом ни духом) и слушания многих прерываний (аналогично). Т.е. теперь идет унифицированный обмен как целевыми данными, так и настройками для этих данных. Речь относительно IOMMU о том, чтобы некий верификатор "понимал" семантику этих сообщений и енфорснул бы типобезопасность операций DMA.
Так это будет обеспечивать драйвер IOMMU.
Ему мы верим.
Он сертифицированный.

V>Так вот, мой аргумент был в том, что за десяток лет разновидностей DMA накопилось столько, что разработчики Сингулярити жалуются, что покрыть этот зоопарк практически невозможно. Я предположил, что рано или поздно аналогичное случится для будущих спецификаций IOMMU. Сейчас этот подход еще не набрал популярность, а уже пяток несовместимых спецификаций налицо. Что будет, когда на IOMMU перейдут в полный рост?
Они жалуются на то, что железки имеют какой попало интерфейс для DMA.

При этом интерфейс IOMMU можно очень легко абстрагировать от всех подробностей.

V>В манифесте указываются ресурсы, к которым обращается драйвер. Насколько я понял, еще до загрузки операционки известно, какой драйвер какие физические адреса памяти получит, если они ему нужны в кач-ве ресурсов (как пример — область адресов для "окон" памяти видеокарты). Если верификатор будет знать сообщения IOMMU "в лицо", он сможет проверить, что в этих сообщениях фигурирует только диапазоны памяти (для операций IOMMU->DMA), указанные в манифесте.
Ох.
Одна функция.
BufferLock(buffer : Buffer) : LockedBuffer
Эта функция отмапит данный буфер в адресное пространство железки.
После чего железка сможет работать с ним и только с ним.
У LockedBuffer можно позвать метод Adress который вернет адрес буфера. Этот адрес можно скормить железке.
Ну и BufferUnlock для симметрии.
Либо просто теряем уникальный LockedBuffer и память освобождается. И IOMMU узнает, что нужно эту память забрать у железки.

Здравствуйте, VladD2, Вы писали:

VD>И что ты тут вычитал? Это неоднозначность для КС-парсеро. Добавление таблицы символов и проверки идентификаторов по ней делает грамматику однозначной КЗ грамматикой.

Таблица для описанного варианта помогает только для случая, когда типы объявляются перед использованием. А внутри классов некоторые компиляторы С++ это умеют уже ДО того, как встретили объявление типа:

//////////////////////////////////////////////////////////////////
struct S1 {
  void m() { 
    if(MyInt * tmp = getTmp()) {
      // тут компилятор считает MyInt * tmp объявлением переменной
    }
  }

  typedef int MyInt;

  MyInt * getTmp() { return NULL; }

  MyInt * tmp;
};

//////////////////////////////////////////////////////////////////
struct S2 {
  void m() { 
    if(MyInt * tmp = getTmp()) {
      // тут компилятор считает MyInt * tmp умножением 
    }
  }

  int getTmp() { return 42; }

  static struct S3 {
    int & operator*(int) { return tmp; }
  } MyInt;

  static int tmp;
};

В этом примере TDOP загнется. GLR проглотит, не заметив.


VD>Ты сейчас дискредитируешь себя в глазах окружающих.

Когда ты уже отучишься говорить собеседнику неприятные вещи вместо обсуждения по делу???
На тебя смотрят младшие твои товарищи и безнадежно портятся...

Здравствуйте, vdimas, Вы писали:

V>Дык, я-то понял, что ты от собственной затеи уже отказался. А Mamut еще продолжает по инерции катиться в ту же сторону. Не хочешь прокомментировать его пост, справедливости ради?
Ни от чего я не отказался.
Это тебе в очередной раз твои галлюцинации нашептали.

Здравствуйте, WolfHound, Вы писали:

V>>2. ЯВУ с высокой степенью неоднозначности, но "неглубокими" выражениями. Типичный представитель — С++. Парсеры с откатами тоже сосут не нагибаясь, поэтому LALR или GLR.
WH>БРЕД! Полнейший.
WH>С++ невозможно адекватно разобрать контекстно-свободным парсером.
WH>А GLR строго контекстно-свободный.

Вообще-то можно. Просто в случаях полной неоднозначности GLR выдаст столько деревьев сколько удалось разобрать.

Далее натравливается алгоритм разрешения неоднозначностей который уже использует информацию о символах.

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

Но, думаю, что мы это тоже сможем сделать.

Здравствуйте, VladD2, Вы писали:

VD>В плане истории важно не то что в нем нет, а то что в нем появилось. К сожалению, я не могу вспомнить ничего.

В нем появилась среда исполнения для нейтивного кода, такая, что эта среда демонстрировала характеристики в плане подгрузки модулей, ГЦ и т.д., ранее присущие лишь интерпретаторам байткода или динамическим языкам. Второй раз на более-менее нормальном уровне это было повторено только в дотнете с их JIT-компилятором.

C>>Чувак, я участвовал в эпичном треде о "синтаксическом оверхеде". Это ты ничерта не знаешь об Обероне.
VD>Давай по уважительнее. А синтаксический оверхэд — это было сильно, да.

Вот то-то и оно. Он участвовал в "синтаксическом оверхеде" и все знания, походу, подчерпнул оттуда. А здесь засыпал вопросами, ответы на которые содержатся на первых страницах Вики... Действительно, эпично вышло. "Не читал, но осуждаю".

Здравствуйте, WolfHound, Вы писали:

VD>>Давай по уважительнее. А синтаксический оверхэд — это было сильно, да.
WH>Этот топик тоже сильно. Только место Губанова vdimas занял.

Боюсь, его занял ты, со своим плаванием в обсуждаемом и постоянными загадочными недоговоренностями. Губанов №2 и есть. "Вы ничего не понимаете" (С).

Здравствуйте, FR, Вы писали:

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

FR>Я компиляторы писать не собирался и не собираюсь, но судя по размеру описания языка и рантайма, компилятор оберона
FR>гораздо проще чем интерпретатор питона, тем более сейчас когда есть такие штуки как llvm.

Написать компилятор строго типизированного языка при готовом бекенде проще, чем интерпретатор, если за скобками оставить типизацию и кое какие хитрозадые вещи в некоторых языках (в Обероне таких нет). Проверено лично мной на практике.

Здравствуйте, vdimas, Вы писали:

V>В нем появилась среда исполнения для нейтивного кода, такая, что эта среда демонстрировала характеристики в плане подгрузки модулей, ГЦ

Которые были в ML появившемся в 1973 (Оберон появился в 1986). Так что этот не более чем твоя выдумка.

V>и т.д.,

О "т.д." по подробнее, плиз. А то пока информация не подтверждается.

V>ранее присущие лишь интерпретаторам байткода или динамическим языкам.

Ага. Таким как ML. Пойду за попкорном, продолжай.

V>Второй раз на более-менее нормальном уровне это было повторено только в дотнете с их JIT-компилятором.

Яву мы опускаем за некошерностью? В прочем, нормального уровня в Обероне не было никогда. Можно посмотреть реализацию Оберона для Виндовс с приличным GC? А то все что пробовали в прошлом эпическом сраче про синтаксический оверхэд обделалалось на примитивных тестах замусоривших кучу.

V>Вот то-то и оно. Он участвовал в "синтаксическом оверхеде" и все знания, походу, подчерпнул оттуда. А здесь засыпал вопросами, ответы на которые содержатся на первых страницах Вики... Действительно, эпично вышло. "Не читал, но осуждаю".

Извини, но пока большая часть твоих слов не более чем домыслы. Так что разницы я не наблюдаю. Все те же попытки выдать желаемое за действительное.

Лично моего мнения об Обероне ты не изменил. Язык тупиковый. Единственная его идея — минимализм. Может оно не плохо для обучения, но не для практического использования.

Здравствуйте, vdimas, Вы писали:

V>Если еще все либы без этого модуля перепишешь. В общем, это ты на полвопроса ответил. Вопрос звучал так: Оберону надо садиться на аппаратаное прерывания и прочие DMA, потому что операционка, а вот зачем такой модуль в OCaml — непонятно.

А Обероны для Виндовс таких модулей не имеют? Если имеют, то хочу услышать ответ на данный вопрос для них.

V>Ну ок, вот интересная транзакция, X12 271.
V>Небольшая, но показывающая всю убогость парсеров с откатами для определенных сценариев.

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

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

Оберон ушел в историю. Почтим память старка и пойдем дальше.

V>Зачем руками. Программирование в ограничениях. Вывод типов как, по твоему работает? Это точно такая же задача — найти решение при наличии фактов и правил.

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

WH>>Это я еще про восстановление после ошибок говорить не начинал.

V>А ты начни. GLR может порекомендовать правильные конструкции в месте ошибки, в отличии от LL(k), который тоже может порекомендовать, ес-но, правда на порядок большее их мн-во. ))

Опять же. Не надо громких слов. Заявил, что GLR есть какие-то преимущества — обоснуй.

Потом порекомендовать — это детский сад. Правильный парсер должен в автомате выявить минимально-возможный ошибочный код, восстановить состояние парсера и продолжить разбор. При этом нужно еще дать качественную диагностику и постараться разобрать то правило на котором произошел облом, так чтобы потом в IDE можно было информацию по правильно разобранным частям получить.

Что тут может дать GLR и где можно посмотреть реализации (чтобы попробовать их)?

V>>>Отличие от нисходящих парсеров с откатами в том, что парсеры с откатами в случае неоднозначностей грамматики имеют склонность вечно зацикливаться.
WH>>Бред.

V>Это медицинский факт для нисходящего разбора в случае некоторых неоднозначностей, приводящих к левой рекурсии.

Подтверждаю — это реально бред (ака заблуждение). Зацикливание никак не связано с неоднозначостями в грамматиках.
Можешь попытаться создать такую грамматику. Уверен, что парсер N2 не зациклится. В худшем случае будет исключение говорящее о неоднозначности.

V> Именно исходная неоднозначность грамматики может не дать её полностью факторизовать.

Факторизация решает другую проблему парсеров с бэктрекингом — исключение экспоненциального случая. В парсере Н2 используется частичная мемоизация которая исключает экспоненту в большинстве случаев в автоматическом режиме. Так что ему факторизация не нужна.

Скажу больше Н2-шный парсер даже провоцирует на отказ от факторизации, так как это упрощает получаемое АСТ.

V>Поэтому-то я не люблю LL(k) для неоднозначных грамматик,

LL то тут причем? В нем нет бэктрекинга, а значит LL-грамматики не могут разбирать неоднозначные грамматики.

V>что в таких случаях в LL(K) надо описывать не целевую грамматику, а некую промежуточную. А потом действительно, ручками и только ручками переводить промежуточную в целевую.

Что-то ты совсем не в ту степь пошел. LL(k) обсуждать бессмысленно.

Что касается алгоритма N2, то вот фрагмент грамматики самого N2. Как не сложно убедиться никакой левой факторизации нет. И это не приводит к каким-то проблемам, так как парсинг подправил мемоизируется.

V>>>Вот почему определение "оперативный" — это ключевой момент и почему разборщики неоднозначных грамматик делают по восходящей технологии. Потому что мощность представления неодозначного результата для оперативного парсера не может быть больше длины разбираемой цепочки.

Можно расшифровать понятия "мощность представления неодозначного результата" и "оперативный парсер"?

Да и вообще хотелось бы объяснений. Голословные заявления как-то напрягают.

Лично я не вижу разницы между нисходящим и восходящим анализом в случае неоднозначностей. В любом случае их можно выявить и каким-то образом обработать.

WH>>Языки программирования однозначны.

V>Но не в координатах КС-разбора.

Вообще-то из современных ЯП только С++ и Немерл не может быть отпарсен КС-парсером. И их зависимость от контекста довольно простая.

V>Не начнут. Про С/С++ уже обсуждали. У него идет предварительное объявление типов именно чтобы "спокойно добавить таблицу имен". Блин, но это же 70-е года, мало памяти и однопроходность парсера... Сейчас-то всё тоже самое можно на GLR без предварительного объявления типов. Просто каждый встреченный символ будет отбрасывать ранее сохраненные неоднозначности. И что характерно — опять же оперативным образом, то бишь не накапливая ненужную информацию.

Я не знаком с реализациями GLR, но что-то не подсказывает, что за обобщение информации придется платить промежуточным копированием.

Где-нибудь есть информация о производительности GLR-парсеров?

V>Та блин, GLR — это просто самый общий вариант для восходящего разбора (и дословный перевод такой же), отец семейства, кароч. Есть же LALR, всевозможные модификации SLR и т.д. Ты только копни в эту область. Прямо сейчас эта область исследуется активнее всего, (случайно, что ле?). ИМХО, потому что оперативность — это отличное качество для современных скоростей обмена информацией, т.е. она хорошо смотрится при конвейерной организации обработки этой информации.

У любых LR-парсеров есть проблемы с динамической расширяемостью. Плюс восходящий анализ сильно отличается от того как код читается человеком. Отсюда проблемы с диагностикой ошибок. А описывать в грамматике все возможные случаи опечаток как-то очень не просто.

V>И да, конкретно против TDOP я ничего не имею,

Ты еще за одно осознай, что алгоритм используемый в N2 не эквивалентен TDOP. Это совмещение TDOP, PEG и пидуманных Вольфхаундом улучшений. По сему нельзя рассуждать о нем как о TDOP или как о LL(k).

V>а LL(1) вообще считаю НАИЛУЧШИМ вариантом для тех случаев, где исходная грамматика приводима к LL(1) без необходимости ее подмены на промежуточную (нецелевую) грамматику. Поэтому пользовал LL(1) неоднократно. Моя мысль банально в том, что не существует одного решения на все случаи жизни. А вы как-то умудрились целый пласт восходящего разбора проигнорировать.

Ну, почему же? По факту TDOP фактически восходящий алгоритм (хотя выглядит как нисходящий). Мы не разделяем твоих симпатий к LR. Причем даже не потому что он восходящий, а потому что он автоматный. Нам нужен динамически расширяемый парсер. Тут ни LL ни LR особо не годятся, так как подразумевают автоматную реализацию.

У TDOP и рекурсивного спуска с откатами есть одно неоспоримое преимущество — эти алгоритмы позволяют динамически комбинировать парсеры.

Можно в середине разбора взять и изменить GLR-парсер (грамматику)?

V>Это слишком дохрена игнорировать надо. Помнишь то обсуждение, чтобы при преобразовании частей правил в ДКА для вашего ПЕГ сохранялись исходные нетерминалы? Это же натуральная вотчина для восходящего разбора — генерить именно такие ДКА (для регулярной грамматики вроде бы достаточен LR(0) ).

Как я говорил, это был баг в реализации прошлой версии парсера. В новой подобных проблем нет. В ней токены выделены в отдельную сущность и для них всегда генерируются ДКА. LR тут на фиг не уперся, так как токены обладают регулярной грамматикой. Для них обычных ДКА (без магазинов) за глаза хватает. Это же очевидно.

V>Такая же скорость разбора, ровно один шаг алгоритма на каждый символ, и достоверно восстановленное синтаксическое дерево произвольной глубины. Я ХЗ почему ты не обратил внимание на этот момент еще тогда. LR(0) вообще можно юзать вместо ДКА для случаев, когда грамматика явно приводима к регулярной, но нужны не только сами разобранные строки (нетерминал верхнего уровня), но и обязательно ход разбора, то бишь дерево.

Для разбора дерева рекурсивный спуск подходит точно так же как

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>В этом обсуждении, в частности, упомянут и ДРАКОН:

С какого боку тут Дрокон? Нельзя же совать его во все дыры?

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Cyberax, Вы писали:

C>>Ты думаешь я зря спросил у vdimas'а какую версию Оберона взять?
C>>Я всё жду пока он попытется найти работающий компилятор на их сайте. Муахахахаха.

V>Тебя тоже в гугл больше не пускают как и Мамута? Вот уже точно муа... ))
V>http://www.ethoberon.ethz.ch/download.html

Читать их сайт очень забавно. Чего стоит только комментарий к (видимо) компилятору для Винды:

Integrates Oberon with Windows, Netscape and ActiveX

Бред выдающий тот факт, что со времен Вынь 95 никому не было дела до этой поделки.

V>http://bluebottle.ethz.ch/download.html

За фиг кому-то нужны какие-то левые ОС? Всем нужны компиляторы под виндовс или линукс. Причем желательно с поддержкой IDE.

Здравствуйте, vdimas, Вы писали:

V>Не знаю, не знаю... Тот же BlackBox в куда высокой степени готовности находится, чем один из самых сложных аналогичных опен-сорсовых проектов — MonoDevelop,

Ты шутишь? Как можно сравнивать вордпэд пристствующий в Блэкбоксе со средой разработки? Где (хотя бы) автодополение при вводе и подсветка синтаксиса?

Потом сам Блэкбокс не является Обероном по сути и использует крайне примтивный GC который не применим в более-менее нагруженных по памяти проектах.

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

Здравствуйте, VladD2, Вы писали:

VD>Бред выдающий тот факт, что со времен Вынь 95 никому не было дела до этой поделки.

Им и самим нет дела до компилятора под винду. Сам язык без своей среды исполнения полезен не более, чем комплятор C# без дотнета.


VD>За фиг кому-то нужны какие-то левые ОС? Всем нужны компиляторы под виндовс или линукс. Причем желательно с поддержкой IDE.

Дык, а некоторые еще на Дотнет и Андроид молятся и что? Смысл обсуждать все эти тормозные среды исполнения? По мне как раз ключевой любопытный в Оберон-ОСях момент — это его эффективные среды исполнения. А их никак не сделать с теми же характеристиками поверх Windows или Линукс, бо сами эти операционки сверх-тормознутые с т.з. Оберона, особенно в плане ввода-вывода (не смотря на свою нейтивность).

Здравствуйте, vdimas, Вы писали:

V>Боюсь, его занял ты, со своим плаванием в обсуждаемом и постоянными загадочными недоговоренностями. Губанов №2 и есть. "Вы ничего не понимаете" (С).
Хватит говорить о себе во множественном числе.

Здравствуйте, vdimas, Вы писали:

V>Дык, а некоторые еще на Дотнет и Андроид молятся и что? Смысл обсуждать все эти тормозные среды исполнения? По мне как раз ключевой любопытный в Оберон-ОСях момент — это его эффективные среды исполнения. А их никак не сделать с теми же характеристиками поверх Windows или Линукс, бо сами эти операционки сверх-тормознутые с т.з. Оберона, особенно в плане ввода-вывода (не смотря на свою нейтивность).

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

Здравствуйте, VladD2, Вы писали:

V>>Не знаю, не знаю... Тот же BlackBox в куда высокой степени готовности находится, чем один из самых сложных аналогичных опен-сорсовых проектов — MonoDevelop,
VD>Ты шутишь? Как можно сравнивать вордпэд пристствующий в Блэкбоксе со средой разработки? Где (хотя бы) автодополение при вводе и подсветка синтаксиса?

Да врде автодополнение есть, с переводом ключевых слов в ерхний регистр, но с какими-то ополнениями не из коробки. "Подсветка" там через синтаксис самого языка (ключевые слова большими буквами).
Ну и по собственным ощущениям, хоть и не слишком много пришлось на Паскале когда-то пошпилить, но этому языку, в отличие от, например, C/C# подсветка синтаксиса и даром не сдалась. Как раз выделения ключевых слов было достаточно, что под TP, что под Дельфи. Ну и еще, там же не текстовый документ, а гипертекстовый. Ты можешь раскрашивать исходник вообще как хочешь, превращая исходник в некий полноценный справочник-документ по коду.

VD>Потом сам Блэкбокс не является Обероном по сути и использует крайне примтивный GC который не применим в более-менее нагруженных по памяти проектах.

Дык, это же среда, работающая поверх обычной операционки. Ей в таком сценарии некомфортно. Я и не собрался обсуждать характеристики BackBox, просто разговор шел не только о характеристиках Оберона, но и доступности инструментария. В этой среде можно удобно поотлаживаться, без всяких виртуалок.

VD>Это игрушка для институтов. Может на ней и можно учить программировать, но программировать на ней в 21 веке нельзя.

Почему нет? Какие-нить расчетные утилиты, вспомогательные программы? Я гогда-то даже на VB for DOS писал много всякого такого, т.к. однажды прикинул статистику, и выходило, что в расчетных утилитках поверх TurboVision непростительно большую долю кода в исходниках отнимает обслуживание самого TurboVision, а он же не целевой ни разу...

Ну и в плане адекватности под учебный процесс... Во многих ВУЗах до сих пор лабораторки по программированию на TP пишут... Вот уж

Здравствуйте, VladD2, Вы писали:

ВП>>В этом обсуждении, в частности, упомянут и ДРАКОН:
VD>С какого боку тут Дрокон? Нельзя же совать его во все дыры?

А эта ветка иначально в обсуждении ДРАКОНА жила, пока ее не выделили.

А насчет Blocky полностью согласен. Они так умудрились сделать графический дизайн уонструкция языка, что многие правиа ДРАКОНА по формированию графического представления алгоритмов выполняются автоматически.