(До этого, думая что ты помнишь С++, пересказывал тебе похожий сценарий словами насчет гипотетического языка, который как С++, только без предварительного объевления.)
V>>Это медицинский факт для нисходящего разбора в случае некоторых неоднозначностей, приводящих к левой рекурсии. WH>Вот только мой парсер жрет левую рекурсию не напрягаясь.
Да ничего он не жрет, у него просто детерминированный алгоритм разбора, поэтому он не сможет разобрать аналогичную неоднозначную грамматику, о которой речь, принципиально.
V>>Именно исходная неоднозначность грамматики может не дать её полностью факторизовать. WH>Языки программирования неоднозначны.
Ты хотел сказать однозначны, надеюсь. Грамматика для КС-парсера всё-равно будет неоднозначной. Мы это раз в пол-года снова и снова будем обсуждать?
И да, я помню абсолютно все твои доводы (ты уже на 10й круг пошел минимум за последний год) и внимательно посмотрел на сам алгоритм работы TDOP. Он приципиально сможет разобрать только простые, однозначные на уровне синтаксиса конструкции.
V>>Поэтому-то я не люблю LL(k) для неоднозначных грамматик, что в таких случаях в LL(K) надо описывать не целевую грамматику, а некую промежуточную. А потом действительно, ручками и только ручками переводить промежуточную в целевую. WH>Те, по-твоему, нисходящие парсеры это только LL(K)?
LL(1) по эффективности не уступает LR(0) и даже просто лексеру на ДКА. Поэтому, ес-но, лично у меня он заслуживает внимания и всегда первый претендент, если грамматика позволяет.
WH>>>Языки программирования однозначны. V>>Но не в координатах КС-разбора. WH>Меня КС разбор не волнует.
Не говори гоп.
V>>Та блин, GLR — это просто самый общий вариант для восходящего разбора (и дословный перевод такой же), отец семейства, кароч. Есть же LALR, всевозможные модификации SLR и т.д. Ты только копни в эту область. Прямо сейчас эта область исследуется активнее всего, (случайно, что ле?). WH>Вся драконщина это одна большая случайность.
Какая прелесть. Ниасиливший тему студент пытается организовать движение против невыученных им уроков.
V>>И да, конкретно против TDOP я ничего не имею, WH>Только ты не понимаешь что это. И как он работает.
Если в том смысле, что "не проникся", ну т.е. как собутыльник "ты ведь меня понимаешь, да?"... то нет, ес-но, не проникся. Понимать-то там нечего, ограничения подхода TDOP видны невооруженным взглядом. Но вот ты этого в упор не видишь, бо тебе не с чем сравнить. Ну тогда поизобретай велисипеды. Ссылку уже дал, развлекайся.
WH>Иначе бы не вещал глупости на тему того что нужно его грамматику факторизовать.
Очередная твоя брехня.
1. Речь была о факторизации исходной неоднозначной грамматики;
2. Грамматика TDOP однозначна.
3. Грамматикой это назвать можно лишь с большой натяжкой — это алгоритм разбора, как и ПЕГ. По мне — никакой грамматикой там и не пахнет. То бишь описание правил для парсера не есть описание грамматики в терминах редукций, например, а есть описание работы некоего императивного алгоритма.
4. Любой императивный алгоритм по своей природе ограничивает исходный класс разбираемых грамматик только теми, св-ва которых ложатся на этот алгоритм. В этом плане TDOP недалеко ушел от других, вполне конкретных императивных алгоритмов разбора, которые ВСЕГДА определяют лишь некий подкласс разбираемых грамматик (LL(k), LALR, SRL и т.д.). Это всего-лишь алгоритмы, ограниченные неким подклассом грамматик, и для них тоже подается описание грамматики в некоем понятном им виде. (вовсе не в таком, как эта грамматика представлена в терминах редукций).
V>>Гы, если не понимаешь, то для тебя многие вещи пустой звук, ес-но... как для троешников на уроках в школе. Ну и плюс приходится тратить силы на борьбу с тобой, бо ведешь спор очень скользско (хотя бы насчет альфы пример). WH>И альфой я абсолютно буквален. И сразу сказал куда смотреть. WH>Но ты не можешь даже википедию открыть.
Да вменяем ли ты? Тебе было сказано, как работает альфа — понятно. Поделись, где ты увидел проблему.
WH>И посмотреть на размер формулы, которая смешивает два пикселя с альфой.
Так она тебя вгоняет в ступор или в чем у тебя дело-то? Или на полном серьезе считаешь, что у меня интернет не той системы? Или в моем справочнике по студийной видеотехнике думаешь другие формулы для т.н. "ключевого канала" (он же альфа-канал) приведены? То, что ты решил повалять дурака было понятно сразу, только валять дурака принято малость скромнее.
WH>И чем дальше, тем больше я убеждаюсь, что разговор с тобой не имеет смысла.
В такой манере — ес-но не имеет. Ты же за слова не отвечаешь, а я дотошный. Вот тебе и некомфотно. Тебе же нужна аудитория, в рот заглядывающая..
Здравствуйте, VladD2, Вы писали:
VD>Тут вряд ли найдутся знатоки формата. Ты привел бы, действительно, грамматику и пояснил в чем косяк.
Грамматику в удобном вам виде я не нашел, везде дается в том же виде как и уменя в PDF в доке одного из проектов. Т.е. вы сможете найти ее легко на первых страницах гугла в таком же как у меня виде.
Грамматика там несложная, а косяк в EDI торчит в самом сценарии электронного документооборота.
Немного терминологии. В EDI есть сегменты — это именованные записи. С т.ч. парсера документа — это терминалы, ему на вход идут коды сегментов. И есть циклы. Цикл — это повторение некоего шаблона из сегментов и циклов от 0 до нескольких раз. Сегменты тоже могут повторяться от 0 до нескольких раз, но специальный цикл-нетерминал под них не заводят, это просто отображение поля-массива в сообщении. Рекурсии в циклах нет. То бишь, проверить входящее сообщение на принадлежность грамматике можно даже с помощью регулярной грамматики, если имена циклов (нетерминалы) считать нецелевыми, т.е. отбросить их в процессе приведения НКА в ДКА. Но отбросить их нельзя требуется именно восстановить дерево разбора. (Перекликается с той вашей задачей в ПЕГ, если помнишь, когда терялись нетерминалы при минимизации ДКА).
Неоднозначность берется от опциональности циклов и сегментов. Даже один и тот же сегмент в одном цикле может быть массивом, в другом — единичным элементом. А по факту придет только один элемент, вот тебе и неоднозначность, это массив с кол-вом элементов 1, или другой цикл, где этот элемент не является массивом.
Но сами документы EDI всегда однозначны. Т.е. даже с учетом опциональных сегментов сам документ будет построен так, что рано или поздно в конце останется только один вариант разбора. Вот этот момент и есть мега-косяк, когда сервер зачитывает приличный трафик из этих документов и обрабатывает их по конвейерной схеме. В моих экспериментах с нисходящим парсингом я получал сотни откатов на средние по размерам документы. Это был приплызд. Имено в этом месте я попробовал Эрли (допиливал ваш вариант с сайта), изучал варианты с мемоизацией, но умножал это дело на предельные размеры документов (мегабайты, и это "одно выражение" если проводить аналогию с языками программирования), то у меня выходило, что не хватит всей памяти компьютера.
Потом попробовал обкатанный ранее GLR — и всё сразу стало на свои места. В среднем идут себе 2-4 ветки вдоль всего разбора. Какие-то появляются, какие-то исчезают... В максимальных точках доходило до 3-х десятков веток, но эти места редки и коротки, быстро проскакиваются и дальше опять идет малое число вариантов. Работа парсера: по сути есть одна таблица автомата разбора на каждую транзакцию (транзацкция = электронный документ), по ней (таблице) протягиваются те самые 2-4 курсора. Согласись, смешные затраты на обеспечение параллельности. Хранить исходную последовательность для целей отката не надо. В каких-то местах у нас все варианты "схлопываются" до 1-го, вот до этой точки уже можно отдавать высокоуровневые циклы (узлы дерева документа) на прикладную валидацию и расшифровку значений. Причем, сценариев "схлопывания" несколько: это когда вообще остается один вариант из всех, либо когда всё множество неоднозначных вариантов распознает данный цикл как один и тот же (бывает и такое). Т.е. выходит прикольно: документ еще не разобран целиком, а уже полным ходом идет его обработка. Такое возможно потому, что алгоримт указывает на "достоверно-разобранные" куски входного потока. Далее. Все неоднозначные варианты шарят м/у собой одинаковые части до момента возникновения неоднозначности в каждой ветке дерева. Момент работы с памятью тоже характерно приятен: "отваливающиеся" узлы погибших неверных веток разбора переиспользуются на каждом шаге для новых. Даже в дотнете это дало приличных буст для скорости разбора.
VD>Это называется спекулятивная типизация. Я что-то пока не слышал о парсерах предоставляющих услуги типизации да еще и в для произвольной системы типов. Если тебе такие известны, то дай ссылку, плиз.
Ес-но это этап после парсинга. Просто этому этапу согласно его природы абсоютно до фени — один там вариант, или несколько. Например, в процессе вывода типов всё-равно перебираются мн-во вариантов, но остаются только такие, где всё однозначно стыкуется. Я лишь заметил, что в таких условиях неоднозначный выхлоп GLR не должен привести с серьезным переделкам остального, даже если речь идет о выводе типов (то бишь "модных" языках).
V>>А ты начни. GLR может порекомендовать правильные конструкции в месте ошибки, в отличии от LL(k), который тоже может порекомендовать, ес-но, правда на порядок большее их мн-во. )) VD>Опять же. Не надо громких слов. Заявил, что GLR есть какие-то преимущества — обоснуй.
Под GLR сидит LR(0), а у него всегда в месте конфликта есть список "удачных" продолжений. Более-менее вменяемый аналогичный этот список только у LL(1), а там где k>1, там список может быть невменяемый по размеру.
VD>Потом порекомендовать — это детский сад. Правильный парсер должен в автомате выявить минимально-возможный ошибочный код, восстановить состояние парсера и продолжить разбор. При этом нужно еще дать качественную диагностику и постараться разобрать то правило на котором произошел облом, так чтобы потом в IDE можно было информацию по правильно разобранным частям получить.
1. Восходящие парсеры можно вернуть в произвольную точку разбора, но для ЯВУ вообще достаточноскипнуть текущее выражение и найти следующее.
2. Для ЯВУ вопрос отката вообще как бы несложен. Парсер ЯВУ можно условно составить из нескольких вложенных парсеров: парсеров общей структуры программы, парсеров выражений языка и т.д. Интересный момент в том, что на нисходящих парсерах (типа ПЕГ), такое описание структуры программы через вложенные парсеры происходит естественным образом. Но самый интересный момент в том, что на уровне выражений языка более удобные восходящие парсеры. Помню когда-то подобные рассуждения порвали тебе мозг и ты меня попытался высмеять... хотя техника ПЕГ — это разновидность комбинаторного парсинга, то бишь лично у меня бы не было никаких комплексов по поводу того, что на самом низком "тупиковом" уровне комбинации парсеров сидел бы восходящий разбор. ДКА-то лексера всё-равно по восходящему принципу работает и ничего.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, vdimas, Вы писали: V>>Блин, Мамут, давай лучше о политике, там хоть более предметно выходит. Подход настолько отличается, что натянуть одно на другое вообще никак. В нормальных защищенных соединениях у тебя будет просто поток байт по ровно одному TCP-соединению и по какому-то хрен его знает высокоуровнемому протоколу сверху TCP, о котором операционка ни слухом ни духом. Передать удаленно хендл открытого файла (как предложил Wolfhound) — вообще никак, чтобы контроллировать процесс передачи и последующее использование операционкой. S>Как всегда — много умных слов, ни тени понимания. S>Система работает примитивно просто (это изобрели ещё в доисторические времена): каждое приложение получает доступ только к тому, что ему дали. Обходных путей не существует.
Осталось определиться с понятием "приложение". Для того же MS SQL — это десятки запускаемых экзешников. Давай, покажи процесс раздачи прав каждому из них.
S>В десктопе упрощённая цепочка выглядит так: S>1. Есть приложение Explorer, которому мы сильно доверяем. Ему в начале времён дали доступ ко всем дискам, и к АПИ типа CreateFile(). S>2. Есть произвольное другое приложение, которое по умолчанию ничего не видит и не имеет. Вызвать CreateFile оно не может. Всё, что оно может сделать — вызвать OpenFileDialog(), который возвращает сразу хэндлы файлов, которые указал пользователь.
S>Ключевой момент: Explorer здесь не является частью модели безопасности. Это всего лишь одна из надстроек, построенных поверх низкоуровневых механизмов, которых в оберонах нету.
Упс... Ну и у кого тут не тени понимания?
1. Эксплорер — это обычное GUI приложение, а не надстройка.
2. Как и обычному GUI приложению, Эксплореру НЕ нужно АПИ CreateFile() для своей работы, бо OpenFileDialog можно вызывать с мильонами флагов, в т.ч. для создания файлов.
S>Если мне удобно, то я могу дать SQL Server всеобъемлющие права на все диски — и проблема будет решена: он будет открывать всё подряд.
Проблема будет создана, а не решена.
S>Если я не доверяю SQL Server (потому что он у меня исполняет скрипты, присланные непонятно кем), то я заставлю его работать с внешним приложением-конфигуратором, которое будет ему давать доступ к файлам, которые лично я ему подтвердил — хотя бы через конфиг-файл, права на доступ к которому я получаю тем же способом через OpenFileDialog на своём администраторском ноутбуке.
Сорри, неважнецки с воображением. Не взлетит такой подход.
1. Не заставишь ты работать MS SQL с "внешним приложением-конфигратором".
2. Не работает для бэкапа в сетку.
S>Поэтому все рассуждения про байты, TCP-соединения, передачи хендлов, тут совершенно не про то. Речь только про то, как исполняющая среда решает, какие методы каких объектов кому разрешено вызывать, и какие значения параметров позволены быть у этих методов.
Эта модель НЕ работает вообще нигде и не будет впредь. То, что ты недопонял мои аргументы — было видно с первой строчки твоего ответа, т.к. я исхожу из того, что в реальности работает суперпозиция прав приложения и пользвателя, а ты решил ограничиться только приложением. Но такой подход для реальной работы неудобен, т.к. по умолчанию всё будет запрещено, кроме локаьных хранилищ, а в случае попыток улучшить удобсво как ты описал (начать раздавать права только приложению), твой подход превращается в точно такую же дыру в безопасности.
S>Если такая система есть — значит, можно построить надёжную конструкцию взаимного доверия.
А смысл, если как раз из этой конструкции и можно украть данные? Ты же пользователя проигнорировал, вернее, переложил головную боль о пользователе на конкретное приложение.
S>Если такой системы нет — то рассуждения про безопасность можно смело сливать в канализационный прибор, так как всегда будет возможность под видом калькулятора подсунуть программу, которая делает что угодно с привилегиями текущего пользователя.
Не можно. Ты допускаешь невнимательность, пытаясь рассматривать две крайности: система прав от пользователя vs система прав от приложения. Это у тебя спор сам с собой получается, т.к. по мне единственный реально работающий вариант совместный и никак иначе. А юниксы я тут, похоже, сам для себя в пример приводил. Просто у юниксов сама шкала прав, скажем прямо, примитивная, но общий подход верен. У современных виндов наоборот, шкала прав всеобъемлющая, но общий подход заведомо ненадежный. Да, поэтому под видом калькулятора в виндах можно делать что угодно. Только это не аргумент ни разу в ЭТОМ споре.
S>Изоляция одного лишь модуля SYSTEM — детский сад. В нормальной среде все компоненты параноидальны по-максимуму друг к другу.
Ты не понял про SYSTEM. )))
Этот модуль для хаков, при том, что кольцо исполнения общее на всех. Все остальные модули не позволят перепрыгнуть встроенные механизмы защиты, какие бы они не были.
Да и вообще, опять же с воображением не ахти. Никакой взаимной параноидальности на уровне модулей в рантайм быть не может и не надо, если загрузчик уже пропустил/загрузил модуль — этот модуль должен адекватно и эффективно работать. Это же нейтивная истема. А любая безопасность с т.з. кода обеспечивается артефактами безопасности и никак иначе — некими описательными структурами. Например: некий модуль предоставляет функциональность художественного логгирования. Дык, этот модуль не должен корчить из себя операционную систему и считать, какому вызывающему модулю что можно, а что нет. Он вообще понятия не может иметь, кто именно его вызывает — нет такой возможности узнать. Зато он может получить артефакт безопасности в одном из аргументов и использовать его в операциях над файлами. И такой модуль понятия не должен иметь, локально его вызывают или удаленно — это должно быть в артефактах и прописано. А то смешно бы было, если бы при обращении к файловому АПИ такой модуль пытался показать диалог открытия файлов что для локального GUI-приложения, что для локального серверного для удаленного клиента.
Спасибо, поржал. Они собрались запустить мобильник в космос. И почему именно на Андроиде? "Каждая домохозяйка должна уметь писать программы"? (С)
А запустили уже или как? А рынок захватили?
V>>========= V>>Ну и дело не в кач-вах среды ни разу, ес-но. Там с одной стороны толкает MS, с другой Google. Всего-навсего две самые мощные IT-компании... Какие мелочи, право.
S>Тут есть нюанс. Дело в том, что кроме андройда и (условно) "дотнета" на рынке мобильных девайсов существует множество других осей. Но оберон-оси не предвидится, нет?
ХЗ, мобильникам ОС понадобилась буквально лет 5-6 лет назад, а до этого, всё, что называлось "mobile OC" на самом деле никакой ОС не являлось.
А поменять тему обсуждения тебе вряд ли удасться. Речь была о том, что было в Обероне, а не о том, что в нем будет. И да, оберон на мобильных ARM-платформах запускали многократно, в отличие от мифического незапущенного спутника под управлением мобильника.
Здравствуйте, VladD2, Вы писали:
V>>Да врде автодополнение есть, с переводом ключевых слов в ерхний регистр, но с какими-то ополнениями не из коробки. "Подсветка" там через синтаксис самого языка (ключевые слова большими буквами). VD>Ау! Ты часом не заблудился? Ты пришел на форум современных разработчиков, а не к срперам из дома престарелых программистов.
Покажи мне современных разработчиков. Кокретно на этом сайте по большей части разработчики под дотнет. Разработчики не самой этой среды, заметь, то бишь не производители технологий, а сугубо потребители современных технологий. Домохозяйки тоже с современными технологиями обращаются на ура на кухне...
Ты решил предложить мне сравнить домохозяку, орудующую самым современным кухонным комбайном, с разаработчиком кухонного комбайна? Пусть даже предыдущего поколения? А что ты сравнивать собрался?
VD>Тут "вроде как где-то" не катит. А подсветка "через синтаксис" вызовет только смех.
Ок, берешь код на Обероне, предлагаешь помимо ключевых слов выделить еще что-то, выражаешь свои намерения хотя бы в RTF или HTML. Смотрим, сравниваем. Своё ИМХО я уже сказал, для Паскалевкого синтаксиса подсветка помимо ключевых слов не принципиальна. Как и для похожего на него VB. Там же нечего подсвечивать.
VD>Давай называть вещи своими именами. Оберона на ПК практически нет. Есть ублюдочный БлэкБокс застрявший в совем развитии в 80-ых годах.
Оберона на ПК всяко больше Немерле, застрявшего в своем развитии в 2005-м.
VD>Есть ли он еще где-то тоже большой вопрос. Потому как почитав список успешных проектов, который ты давал, и не найдя ни одного тому подтверждения по указанным ссылкам, верить уже не хочется.
Т.е. ты всерьез собрался утверждать, что в той ссылке тебе наврали?
Ох и трололо...
V>>Ну и по собственным ощущениям, хоть и не слишком много пришлось на Паскале когда-то пошпилить, но этому языку, в отличие от, например, C/C# подсветка синтаксиса и даром не сдалась. VD>Конечно. Языку вообще ничего не нужно. Он же не живой. Нужно людям. Возможно ты не в их числе. Но я вот точно не буду использовать язык без нормальной поддержки IDE.
А как же ты до 2003-го года программировал, бедный?
Не забыл еще, что мы обсуждали систему, разработка которой остановилась еще до дотнета.
V>>Ну и еще, там же не текстовый документ, а гипертекстовый. VD>Это никого не трогает. Да и не нужно это никому за пределами универов.
Узнаю старого доброго Влада2. Если аргумент оппонента неудобен — тем хуже аргументу.
Ладно, в таком ключе смысла сорить в форуме нет. Сорри, дальше даже не читал.
ARK>>Минутку. Стало быть, в API будет такой сервис, который предоставляет возможность слать поток байт в сеть. ARK>>Наш вредоносный редактор документов открывает файл через OpenFileDialog (точнее пользователь открывает для работы) и шлет все его байты в сеть. Ну, дали мы редактору при установке такое право, он попросил. Такой сценарий возможен? S>1. Вы дали редактору право на взаимодействие с любыми целевыми адресами? А зачем?
Затем. Поставь изкаробки WinServer2008. Ничего сам не настраивай. Вроде бы обычная винда (так и есть, кстате). Посади на эту операцинку свою девушку или любого другого продвинутого пользователя, но не прожженого админа. Пользоваться этой виндой он/она не сможет. Даже приличная часть программистов не сразу сможет ей пользоваться как десктопом... хотя, нефик делать, если разобраться — это обычная винда... Просто изкаробки всё запрещено. Т.е. даже в условиях относительно примитивной модели безопасности Windows (сравнить с юниксовой), система абсолютна неюзабельна для пользователя.
Здравствуйте, Klapaucius, Вы писали:
V>>Гарантирует не хуже Хаскеля. Такой уровень гарантий тебя устроит? Или в природе существуют гарантии еще выше? K>Справедливости ради нужно отметить, что хуже. К примеру, аналоги обероновского SYSTEM в хаскеле все-таки отключаются.
Зависимости от SYSTEM тоже запрещаются.
(и вообще, не надоело вокруг SYSTEM спекулировать?)
Другие приводимые языки, типа Лиспа, SmallTalk, Симулы и т.д. настолько из другой оперы, что авторы указанных языков себе явно льстят, когда ссылаются на них. А реально в приведенной группе языков в точности одинаковый механизм рантайм-полиморфизма над императивным исполнением и отсюда одинаковый подод к решению задач. Взять те же паттерны из GOF — они ровно для этой группы языков. Ни Лиспу ни SmallTalk эти паттерны и даром не сдались, у тех свои паттерны.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, samius, Вы писали:
V>>>Не так. Ждем спутников на Андроиде. А вот как захватит рынок спутников, тогда поубавится смысл обсуждать тормозные среды исполнения.
S>>Спутинки на андройде в природе имеются (гугл в помощь) S>>http://techland.time.com/2011/01/26/android-powered-satellite-headed-to-space/
V>Спасибо, поржал. Они собрались запустить мобильник в космос. И почему именно на Андроиде? "Каждая домохозяйка должна уметь писать программы"? (С)
Я почитал прежде чем кинуть ссылку.
V>А запустили уже или как? А рынок захватили?
эк ты тему на изнанку вывернул
S>>Тут есть нюанс. Дело в том, что кроме андройда и (условно) "дотнета" на рынке мобильных девайсов существует множество других осей. Но оберон-оси не предвидится, нет?
V>ХЗ, мобильникам ОС понадобилась буквально лет 5-6 лет назад, а до этого, всё, что называлось "mobile OC" на самом деле никакой ОС не являлось. V>А поменять тему обсуждения тебе вряд ли удасться. Речь была о том, что было в Обероне, а не о том, что в нем будет. И да, оберон на мобильных ARM-платформах запускали многократно, в отличие от мифического незапущенного спутника под управлением мобильника.
Ждём мобилу с оберон-осью Как выйдет и захватит рынок, тогда поубавится смысл обсуждать тормозные среды исполнения.
Два сообщения спустя ты меня спрашиваешь от захвате андройдом рынка спутников. Если ты не понял мой тот ответ, то я его расшифрую. До тех пор, пока рынок мобильных приложений и разработок не захватит супершустрая оберон-ось, будет смысл обсуждать тормозные среды исполнения андройда и дотнета.
Здравствуйте, AndrewVK, Вы писали:
V>>А какой интерпретатор вышел сложнее какого компилятора? AVK>Некий внутренний DSL. Сперва был написан интрпретатор, потом переделан в компилятор под CLR с сильным сокращением объема исходников.
А техника интерпретации какая была: p-код или работающее AST?
Здравствуйте, samius, Вы писали:
S>>>Спутинки на андройде в природе имеются (гугл в помощь) S>>>http://techland.time.com/2011/01/26/android-powered-satellite-headed-to-space/
V>>Спасибо, поржал. Они собрались запустить мобильник в космос. И почему именно на Андроиде? "Каждая домохозяйка должна уметь писать программы"? (С) S>Я почитал прежде чем кинуть ссылку.
Ну дык другие не любят ходить на ссылки без аннотаций. А сходить стоит, там изысканный фан в каждой строчке.
V>>А запустили уже или как? А рынок захватили? S>эк ты тему на изнанку вывернул
Это тоже я писал?
Ждём мобилу с оберон-осью Как выйдет и захватит рынок,
S>>>Тут есть нюанс. Дело в том, что кроме андройда и (условно) "дотнета" на рынке мобильных девайсов существует множество других осей. Но оберон-оси не предвидится, нет?
S>Ждём мобилу с оберон-осью Как выйдет и захватит рынок, тогда поубавится смысл обсуждать тормозные среды исполнения.
А, т.е. ты типа задал тему. Ну дык я по ней полностью ответил. Твой аргумент всё-равно нерелевантен в ключе обзора технологий.
А вот то, что ты проигнорировал это:
Речь была о том, что было в Обероне, а не о том, что в нем будет. И да, оберон на мобильных ARM-платформах запускали многократно, в отличие от мифического незапущенного спутника под управлением мобильника.
Показательно. Ты сам старательно уходишь от исходной темы. И проявляешь недовольство что я неохотно ухожу вслед за тобой. Это забавно само по себе. ))
S>Два сообщения спустя ты меня спрашиваешь от захвате андройдом рынка спутников. Если ты не понял мой тот ответ, то я его расшифрую. До тех пор, пока рынок мобильных приложений и разработок не захватит супершустрая оберон-ось, будет смысл обсуждать тормозные среды исполнения андройда и дотнета.
1. Это ты не понял мой ответ тебе.
2. Ты хотел сказать Не будет смысл? Ошибаешься, ес-но. Чем популярнее некая среда, тем больше подробностей о ней надо обсуждать. И уж глюки, тормознутость и самую плохую на сегодня энергоэффективность — в первую очередь.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, samius, Вы писали:
S>>Я почитал прежде чем кинуть ссылку.
V>Ну дык другие не любят ходить на ссылки без аннотаций. А сходить стоит, там изысканный фан в каждой строчке.
Это ты для других написал?
V>>>А запустили уже или как? А рынок захватили? S>>эк ты тему на изнанку вывернул
V>Это тоже я писал? V>
V>Ждём мобилу с оберон-осью Как выйдет и захватит рынок,
S>>Дык, а некоторые еще на Дотнет и Андроид молятся и что? Смысл обсуждать все эти тормозные среды исполнения?
(*)
V>А, т.е. ты типа задал тему. Ну дык я по ней полностью ответил. Твой аргумент всё-равно нерелевантен в ключе обзора технологий.
(**)
V>А вот то, что ты проигнорировал это:
V>
V>Речь была о том, что было в Обероне, а не о том, что в нем будет. И да, оберон на мобильных ARM-платформах запускали многократно, в отличие от мифического незапущенного спутника под управлением мобильника.
V>Показательно. Ты сам старательно уходишь от исходной темы. И проявляешь недовольство что я неохотно ухожу вслед за тобой. Это забавно само по себе. ))
Я это проигнорировал лишь потому что запуск оберона на ARM-платформе не является значимым событием на рынке мобильных разработок. Как и не является причиной не обсуждать тормозные среды исполнения.
S>>Два сообщения спустя ты меня спрашиваешь от захвате андройдом рынка спутников. Если ты не понял мой тот ответ, то я его расшифрую. До тех пор, пока рынок мобильных приложений и разработок не захватит супершустрая оберон-ось, будет смысл обсуждать тормозные среды исполнения андройда и дотнета.
V>1. Это ты не понял мой ответ тебе. V>2. Ты хотел сказать Не будет смысл? Ошибаешься, ес-но. Чем популярнее некая среда, тем больше подробностей о ней надо обсуждать. И уж глюки, тормознутость и самую плохую на сегодня энергоэффективность — в первую очередь.
А теперь посмотри на (*) (**) и пойми что ты уже споришь сам с собой.
Здравствуйте, VladD2, Вы писали:
V>>Выделенное — оксюморон сам по себе, вообще-то. Ты обсуждение вообще читал? Т.е. оно такое даже есть, согласен, тот же BlackBox, но это уже частные поделки. VD>Ты уже договорился до полнешего бреда. Виндвос, видите ли, мешает вам. Яве и дотнету не мешает, а Оберону мешает.
Да мешает. Ты бы эта... Не погружался сразу в ветки... Переведи представление топика из дерева в хронологический порядок... Почитай, пройдись по ссылкам, а потом велкам... если желание останется.
В общем, точно так же, "Виндвос" (С) мешает небезызвестному Бартоку/Сингулярити, он мешает Оберону. Оберон был разработан не с целью yet another language, эта была взята Модула (развитие Паскаля) и доработана до нужд разработки безопасной операционки. Вот что такое Оберон. Это язык, ОС и среда исполнения на нем. Ну просто одно слово было взято для всего, в отличии от двух слов для аналогичного Bartok-Singularity.
VD>Слушай кончай троллить. VD>Я тебя кормить не намерен. VD>Намеренный бред с целью провокации флэйма.
Здравствуйте, vdimas, Вы писали:
V>Ты решил предложить мне сравнить домохозяку, орудующую самым современным кухонным комбайном, с разаработчиком кухонного комбайна? Пусть даже предыдущего поколения? А что ты сравнивать собрался?
Кабздец. Это уже все пределы перешло. Тема полшла во флэйм.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, novitk, Вы писали:
V>> о мне, не знающему толком ни Хаскеля ни тем более Конкурентного Хаскеля, понадобилось ~5 мин чтения документации, чтобы показать тебе полное невладение предметом относительно твоего же собственного примера.
N>Как показывает эта ветка, ты вообще мало что знаешь толком. Очень жалею, что потратил время и вежливость. Надо было отключаться сразу, как только ты понес в своей обычной хамской манере пургу про мутабельность, вместо того чтобы прислушаться и понять, что МVar == AWAIT, а forkIO == "активные обьекты Oberona".
Я не могу прислушиваться к нубству, сорри. Для танкистов повторяю, MVar — это простая мутабельная переменная, обложенная локом. А что такое await — курить Conditional variables. Затем, когда подкрепишься знаниями, обрати внимание, что никакие конкурентные банковские транзакции из примера не проверяют никаких условий, они тупо получают синхронизированный доступ к мутабельной переменной.
Но и это не принципиально. Прикол в том, что именно ты прокоментировал на какую именно мысль. Всю тяжесть выбитого лулза, боюсь, у тебя не получилось осознать до сих пор... Ты ведь прокоментировал мысль о том, что чистому функциональному языку нужен механизм продолжений для реализации агентской среды, так? Но ты предложил такой язык, который уже никак не является чистым функциональным... Так и не поняв, насколько глубоко уселся в лужу, затем спросил (и сейчас опять спрашиваешь) "и где разница?". Вопрос-то хороший. Особенно если помнить, что в хорошем вопросе содержится часть ответа. А нету никакой разницы. Где ты видел принципиальную раницу м/у императивными языками?
Здравствуйте, Klapaucius, Вы писали:
V>>А побочные эффекты надо заворачивать в монаду-последовательность и эта монада появилась не сразу, так? K>Да, это один из результатов экспериментов по изоляции и т.д.
Это промежуточный результат эксперимента. Автор Хаскеля разразился статьей о том, что коль нам приходится эмулировать императивность в функциональном языке и в этой императивности повторимы в точности все побочные эффекты, то никакого смысла делать так на самом деле нет, а к безопасности языка надо подходить с другой стороны.
Вот тебе результаты всех экспериментов — возвращение на круги своя. Потому что моделиировать модель над моделью оказалось излишним. Ссылочная прозрачность на основе типобезопасности дает точно такой же эффект контроллируемой мутабельности.
K>
V>>Функциональный подход хорош при вычислении данных и плох, когда эти вычисленные данные надо куда-то девать.
K>Ничего не понял. Это можно как-то раскрыть?
А что непонятного? Процесс математических вычислений легко ложится на функциональную чистоту, OK, но последующее полезное использование этих вычисленных данных должно сопровождаться побочными эффектами. Например, с целью сохранить результат вычислений. См. выделенное.
Здравствуйте, vdimas, Вы писали: V>Осталось определиться с понятием "приложение". Для того же MS SQL — это десятки запускаемых экзешников. Давай, покажи процесс раздачи прав каждому из них.
"Приложение" в такой системе — единица раздачи привилегий. Тот же MS SQL — это вовсе не "десятки запускаемых екзешников", но в обсуждаемой системе будет состоять из достаточно большого количества компонент. Большинству из них не нужны никакие особенные права. А вот тем, кто хочет работать с чем-то особенным (например, собственно backup engine, которому нужен tape access), будут получать доступ через подтверждение.
V>Упс... Ну и у кого тут не тени понимания?
Судя по ответам — у вас. V>1. Эксплорер — это обычное GUI приложение, а не надстройка. V>2. Как и обычному GUI приложению, Эксплореру НЕ нужно АПИ CreateFile() для своей работы, бо OpenFileDialog можно вызывать с мильонами флагов, в т.ч. для создания файлов.
Вы продолжаете не понимать. Кто, по-вашему, реализует OpenFileDialog?
Он не является частью ядра.
V>Сорри, неважнецки с воображением. Не взлетит такой подход.
Ничего, потренируете воображение — и всё получится. V>1. Не заставишь ты работать MS SQL с "внешним приложением-конфигратором". V>2. Не работает для бэкапа в сетку.
Всё прекрасно работает. Один процесс имеет доступ к кэшу DB Engine, другой — к сетке. Благодаря отсутствию аппаратной изоляции, передача данных между ними ничего не стоит.
V>Не можно. Ты допускаешь невнимательность, пытаясь рассматривать две крайности: система прав от пользователя vs система прав от приложения.
Нет. Само собой разумеется, что права пользователя тоже играют роль. Однако, без изоляции процессов это никак не спасает, т.к. у пользователя всегда слишком много прав.
V>Этот модуль для хаков, при том, что кольцо исполнения общее на всех. Все остальные модули не позволят перепрыгнуть встроенные механизмы защиты, какие бы они не были.
Откуда там возьмутся механизимы защиты, если их нет?
V>Да и вообще, опять же с воображением не ахти. Никакой взаимной параноидальности на уровне модулей в рантайм быть не может и не надо, если загрузчик уже пропустил/загрузил модуль — этот модуль должен адекватно и эффективно работать.
Вы тренируйте, тренируйте воображение. В вашей модели загрузчик пропускает запуск калькулятора, который хочет доступ к временным файлам, и калькулятор сразу получает доступ ко всему тому, на что имеет доступ пользователь.
Это же нейтивная истема. А любая безопасность с т.з. кода обеспечивается артефактами безопасности и никак иначе — некими описательными структурами. Например: некий модуль предоставляет функциональность художественного логгирования. Дык, этот модуль не должен корчить из себя операционную систему и считать, какому вызывающему модулю что можно, а что нет. Он вообще понятия не может иметь, кто именно его вызывает — нет такой возможности узнать. Зато он может получить артефакт безопасности в одном из аргументов и использовать его в операциях над файлами. И такой модуль понятия не должен иметь, локально его вызывают или удаленно — это должно быть в артефактах и прописано. А то смешно бы было, если бы при обращении к файловому АПИ такой модуль пытался показать диалог открытия файлов что для локального GUI-приложения, что для локального серверного для удаленного клиента.
Ваше воображение работает не в ту сторону. Модулю не нужно узнавать о том, как его вызывают. Почитайте что-нибудь про CAS.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vdimas, Вы писали: S>>1. Вы дали редактору право на взаимодействие с любыми целевыми адресами? А зачем?
V>Затем. Поставь изкаробки WinServer2008. Ничего сам не настраивай. Вроде бы обычная винда (так и есть, кстате). Посади на эту операцинку свою девушку или любого другого продвинутого пользователя, но не прожженого админа. Пользоваться этой виндой он/она не сможет. Даже приличная часть программистов не сразу сможет ей пользоваться как десктопом... хотя, нефик делать, если разобраться — это обычная винда... Просто изкаробки всё запрещено. Т.е. даже в условиях относительно примитивной модели безопасности Windows (сравнить с юниксовой), система абсолютна неюзабельна для пользователя.
Не понял смысл вашего мысленного эксперимента. Ешё раз спрошу: зачем вы дали редактору право ходить в любое место в интернете?
Если вы хотите поговорить о социальной инженерии — давайте поговорим. Но не стоит смешивать её с техническими вопросами.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
