Спасибо за развернутый ответ. Не скажу, что сразу все стало понятно, поскольку теорией никогда не занимался, все больше практикой. Но для общего развития полезно будет разобраться.
E>>На том же курсе нам прочитали такую штуку, как "Правила подстановки Флойда" (это как раз для разбора LR(1) грамматик). Но затем я пробовал сам в интернете найти описание этого метода, но ничего не получилось. Хоть я свой аналог yacc-а на основе этих правил когда-то сделал. Вот меня любопытство мучает, где про "Правила подстановки Флойда" почитать можно. Не подскажешь?
M>Не знаю, даже не слышал об этом методе. В известной литературе не встречается. Скорее всего, твой препод что-то писал по этому методу, поэтому включил в лекции.
Видимо так и было.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[2]: Theory and Techniques of Compiler Construction
Здравствуйте, fplab, Вы писали:
F>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>Книга Н. Вирта
СГ>>Theory and Techniques of Compiler Construction. Addison-Wesley, Reading, April 1996.
СГ>>http://www.cs.ucr.edu/~phf/mir/wirth-compiler-1996.pdf F>Знаем такую, достойная вещь. Только не хватает страниц 58, 59, 74 и 75. А они довольно важны Вот их бы почитать.
Кстати, интересущимся практической стороной разработки компиляторов, очень рекомендую посмотреть книгу "Implementation of the icon programming languag" на сайте http://www.cs.arizona.edu/icon/ibsale.htm. Тут расписано все так подробно, что, кажется, уж дальше и некуда
Приходиться заниматься гадостью — зарабатывать на жизнь честным трудом (Б.Шоу)
Re[10]: Theory and Techniques of Compiler Construction
Здравствуйте, Алексей., Вы писали:
А>За примерчик спасибо. Как раз забыл добавить обработку вложенных partial-типов. Пришлось добавить 15 строчек кода.
А ты чем занимашся то? Зачем тебе граматика Шарпа?
А>В целом, разбор "partial" довольно прост — нужно просто проверить следующий за ним токен. Если он class, struct или interface — переходишь к разбору вложенного типа, если левая скобка и класс называется partial — к разбору конструктора. Если нет, то partial является частью типа.
В LL(1)-граматике такое не описать. А так ка я использую коку, то при разрешении LL(1)-конфликтов начинается серьезный геморрой. Дело в том, что в CocoR встроен механизм разруливания конфликтов. Но к сожалению при добавлении оного начинает не верно строиться конечный автомат разбора и геморрой начинает появляться на ровном месте.
На самом деле конфликт с "partial" похоже проще разрешить в лексере. Нужно просто считать это слово ключевым, но при его выдаче проверять какой токен следующий. Если это не class, struct или interface, то менять тип лексемы на identifier. Тогда в граматике можно будет просто использовать "partial" как ключевое слово.
К сожалению до этого я додумался только когда писал предыдущее сообщени, так что я убил день или даже два на борбу с конфликтами вызванными этим гребанным "partial". Надо признать, что ни с чем я так не трахался.
А>У меня гораздо больше возникло проблем 9.2.3 и с разбором member-name + type-parameter-list. Для разрешения 9.2.3 без заглядывания вперед ну никак не обойтись, тем более что на это косвенно намекает стандарт.
В C# 2.0 таких мест не одной. Я уже пожалел, что выбрал в качестве парсера CocoR, а не ANTLR. В нем эти заглядывания хотя бы можно декларативно делать. Да и оптимизация там делается в автомате.
Собственно по этому и говорю о GLL/LL(*)-парсерах. Они по идее должны были бы решать такие задачки легко и не принужденно. Страшно подумать... чистая граматика без костылей и никакого траха.
... << RSDN@Home 1.2.0 alpha rev. 578>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Theory and Techniques of Compiler Construction
Здравствуйте, mefrill, Вы писали:
M>Да я ничего не имею против АНТЛРовского алгоритма. Но он имеет свои ограничения и не подходит для задач, не входящих во вполне определенный набор. Конечно, система спроектирована толково, т.е. программисткая задача выполнена очень хорошо. Но вот сам выбор алгоритма для реализации выглядит для меня уступкой общественному вкусу.
ОК, фиг с ними с учеными и т.п. Давай лучше обсудим этот алгоритм. Я еще раз поглядел презентаху и не понял, что тебе в нем не нарвится. Может пояснишь? Только плиз не нужно всех этих рассуждений про "уступки общественному вкусу". Меня это дико раздражает.
Объясни, конструктивно, что тебе не нравится в алгоритме. По мне так идея очень неплоха. Для совпадающих частей строится ДКА, а верный путь определяется по лексемам идущим за этим ДКА. Таким образом граматика выглядит как набор ДКА и проверок между ними. Ну, а далее идет банальный рекусивный спуск управляемый логикой ДКА + доп. проверками. При этом можно так же
M>Да зачем? Понимаешь, он же член научного сообщества, ну зачем ему рекламировать свои работы в других сообществах?
Я смотрю на это с другой стороны. Не рекламировать, а делать доступными для народа и открытыми. Если это прикладная наука, то она должна находить отражение на практике. Вот опубликуй какой-нить ученый статью в Интернете, и глядишь в следующий раз какой нибудь АНТЛР будет еще лучше, ну, или раньше лет на 10-20.
Ведь смешно же, но в 2005 году нет ни одного доступного парсера позволяющего не трахаться, а просто описывать граматику.
M>...У меня все-же другая точка зрения. Я уверен, что при разработке программного продукта должен быть специалист, эксперт, как сейчас модно говорить, который хорошо понимает область, в которой оперирует программная система. Вот этот человек должен читать журналы и быть в курсе разработок за последние 100-50 лет.
Зашибись. Ну, вот предположим я хочу стать таким специалистом. И что мне делать? Идти в Ленинку и перерывать все подшивки за последние 50 лет? Угробить лет десять только на это?
А в Интернет я могу за пять минут найти гуглем то что меня интересут. Главное, чтобы оно тут было.
M> Ведь реферативные журналы специально для этого созданы, это коллективная память человечества.
На сегодня это плохой путь. Вернее недостаточный. Правильным решением является создание своего сайта, ну, или проекта на некотором сайте.
В общем, все течет, все именяется. Должны изменяться и подходы ученых в области популяризации своих идей.
Особенно это верно для области компьютерных наук. В этой области есть огромные сообщества занимающиеся исследованиями и разработками "фор-фан". Опен-сорс уже давно конкурирует с коммерческим софтом (и питает его идеями). Так почему не пользоваться таким подспорьем? Сам ученый не сделает много. Так пусть позволит сделать большее другим.
M>И самое важное, что я могу этой иныормации доверять, мне не нужно будет проверять и доказывать что-то снова, потому что все это уже доказано и проверено компетентными людьми. В этом главное отличие: меня сначала проверят несколько экспертов и только потом опубликуют, а в интернете можно выкладывать что хочешь. Существующая модель мне кажется разумной.
Знашь, я много раз видел "проверенную экспертами информацию" которая на поверку аказывалась полнейшим булшитом. Большинство дисертаций ни стоят и выеденного яйца. Они делаются ради степени. А проверенность... это конечно хоршо. Но меня удовлетворит и банальная проверенность на практике. Когда я читаю про те же построители лексеров и натыкаюсь на слова что мол "ДКА в некоторых случаях может быть неприемлемо большим, но на практике обычно все ОК" меня это более чем удовлетворяет. И мне не нужно 10 страниц формальных доказательств.
M>В общем, оставим Борщева, а насчет билагейтса я уже написал выше. Ничего плохого не имел ввиду, только специфическое отношение к области, которая всегда числилась как вотчина научного и инженерного сообщества.
Оставим. Оставим и билгейтсов. Пойми, то такое пренебрижительное отношение к тем, кто что-то делат на практие сильно раздражает. Надо все же понимать, что тот же билигейст сейчас нехило двигат ту же науку вперед давая миллионы баксов на исследования иститутам.
Про то что все украдено, тфу-ты, придумано до нас я слышал много раз. Появляется Ява/дотнет и мы тут же слышим, о том, что все эти идеи давно известны. Появляется парсер которым можно ползоваться не матерясь по каждому поводу и мы поять слышим "а что тут тагого?". Да ничего. Просто ребята не треплются, аделают. А то что у них нехватает иформации... в этом конечно есть и их вина, но думаю как раз основная вина здесь лежит на тех самых ученых/исследователях которые не думают о разумной популяризации своих идей.
... << RSDN@Home 1.2.0 alpha rev. 578>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Theory and Techniques of Compiler Construction
Здравствуйте, VladD2, Вы писали:
VD>А ты чем занимашся то? Зачем тебе граматика Шарпа?
На досуге пишу на C++ парсер для C#2.0. Парсер для C#1.x уже написан.
VD>В LL(1)-граматике такое не описать. А так ка я использую коку, то при разрешении LL(1)-конфликтов начинается серьезный геморрой. Дело в том, что в CocoR встроен механизм разруливания конфликтов. Но к сожалению при добавлении оного начинает не верно строиться конечный автомат разбора и геморрой начинает появляться на ровном месте.
По-поводу CocoR. Вроде как в инете на ихнем сайте лежит граммaтика C#2.0. Почему бы не использовать ее. Или она некорректная?
VD>На самом деле конфликт с "partial" похоже проще разрешить в лексере. Нужно просто считать это слово ключевым, но при его выдаче проверять какой токен следующий. Если это не class, struct или interface, то менять тип лексемы на identifier. Тогда в граматике можно будет просто использовать "partial" как ключевое слово.
VD>К сожалению до этого я додумался только когда писал предыдущее сообщени, так что я убил день или даже два на борбу с конфликтами вызванными этим гребанным "partial". Надо признать, что ни с чем я так не трахался.
Разные инструменты порождают разные проблемы и способы их решения. В парсере написаном вручную таких проблем не возникает. Странно, а как же 9.2.3?
VD>В C# 2.0 таких мест не одной. Я уже пожалел, что выбрал в качестве парсера CocoR, а не ANTLR. В нем эти заглядывания хотя бы можно декларативно делать. Да и оптимизация там делается в автомате.
Угу. Правда стоит отметить что на сайте ANTLR до сих пор нет полной C#1.x-грамматики (не говоря уже о C#2.0). Они недоделаны и неоптимизированы. Так что с ANTLR тоже не все так просто. Может с выходом ANTLR3 ситуация изменится.
VD>Собственно по этому и говорю о GLL/LL(*)-парсерах. Они по идее должны были бы решать такие задачки легко и не принужденно. Страшно подумать... чистая граматика без костылей и никакого траха.
Будем надеяться.
Re[12]: Theory and Techniques of Compiler Construction
Здравствуйте, Алексей., Вы писали:
А>На досуге пишу на C++ парсер для C#2.0. Парсер для C#1.x уже написан.
Маньяк, однако. А зачем?
А>По-поводу CocoR. Вроде как в инете на ихнем сайте лежит граммaтика C#2.0. Почему бы не использовать ее. Или она некорректная?
Она не просто не корректна. Она ужасна. Хотя может что-то изменилось за последнее время. Но гда я ее смотрел, то плевался по страшному. Я тоже думал... вот она халява. А оказался обман.
А>Разные инструменты порождают разные проблемы и способы их решения. В парсере написаном вручную таких проблем не возникает.
В рукопашном парсере ровно одна проблема — невозможность увидеть чистую граматику и как следствие гарантировать ее корректность.
А>Странно, а как же 9.2.3?
Это тот что "Grammar ambiguities"? И что с него? Про тот же partial там не слова. А как средство разрешения конфликтов с тем что там описано я его использовал по полной. Вот только это тоже рукопашный код.
А>Угу. Правда стоит отметить что на сайте ANTLR до сих пор нет полной C#1.x-грамматики (не говоря уже о C#2.0).
Да, практически полная 2.0-грамматика у меня и у самого есть. Нехватает только работы с nulable-типами и префиксами простарнств имен. Но вот сколько ошибок в парсере в следствии обхода LL(1) конфликтов?
А> Они недоделаны и неоптимизированы. Так что с ANTLR тоже не все так просто. Может с выходом ANTLR3 ситуация изменится.
Вот я и смотрю на него. Судя по тому что я увидел C# на нем должен парситься просто и красиво. Да и С++ скорее всего без особых костылей должен проскачить (хотя, фиг бы с ним).
Вот только жаль, что он явский. Хорошо бы его хотя бы на J# перетащить.
... << RSDN@Home 1.2.0 alpha rev. 578>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Theory and Techniques of Compiler Construction
1. Доступны ли где-нибудь публично GLR-построители парсеров?
2. Хотелоь бы услышать мнение по поводу LL(*) или другими словами GLL-парсеров: General LL
Здравствуйте, Алексей., Вы писали:
А>Из-за этой эвристики ANTLR2.x не является полноценным LL(k)-анализатором. В корректных LL(k)-грамматиках возникают неоднозначности. С введением в ANTLR3 поддержки LL(*)-грамматик проблема отпала.
Я бы сказал видимо отпадет. Кстати, когда они оафициальные бэты хотят выпустить?
... << RSDN@Home 1.2.0 alpha rev. 578>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Theory and Techniques of Compiler Construction
Здравствуйте, VladD2, Вы писали:
VD>Кстати, когда они официальные бэты хотят выпустить?
В начале года говорилось о том что ANTLR3 выйдет осенью.
В последнее время о сроках выпуска ничего не говорилось. Все увлечены тестированием eap'ов и портированием ANTLR3 на другие языки (ANTLR/C#, ANTLR/C++ и т.д.).
Re[11]: Theory and Techniques of Compiler Construction
Здравствуйте, Алексей., Вы писали:
А>В начале года говорилось о том что ANTLR3 выйдет осенью. А>В последнее время о сроках выпуска ничего не говорилось.
Ясно.
А> Все увлечены тестированием eap'ов и портированием ANTLR3 на другие языки (ANTLR/C#, ANTLR/C++ и т.д.).
А исходники доступны? И какой смысл портировать до выхода окончательной версии?
... << RSDN@Home 1.2.0 alpha rev. 587>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Theory and Techniques of Compiler Construction
Здравствуйте, VladD2, Вы писали:
VD>А исходники доступны? И какой смысл портировать до выхода окончательной версии?
Если честно, то не в курсе. Исходников пока никто не выкладывал. Для ANTLR/C++ существует экспериментальная ветка (под условным названием ANTLR2.8) на которой отрабатываются внутренности вроде сборщика мусора для AST-узлов и прочие оптимизации.
Re[13]: Theory and Techniques of Compiler Construction
Прошу прощения, что ответил не сразу, был в отпуске, подставляя свою бледную кожу жарким лучам южного солнца в районе озера Иссык-Куль . Дисскутировать дальше не имею никакого желания, я и не хотел этого делать изначально, просто высказывал свою позицию. Отвечу только на вопрос, чем мне не нравится алгоритм, примененный в АНТЛР3. Только одним — узостью класса грамматик, для которых он может работать. Конечно, можно сказать, что для большинства языков программирования легко придумать подходящую дя АНТЛР грамматику, но вот как раз это мне и не нравится. Я хочу использовать ту грамматику, которая нравится мне, а не данному генратору разборщиков. Можно было бы смериться с ситуацией, если бы не было других алгоритмов синтаксического анализа, позволяющих производить разбор языка на основе любой грамматики, но ведь они есть. Зачем ездить на самокате, если есть вездеход?
ных/исследователях которые не думают о разумной популяризации своих идей.
Re[14]: Theory and Techniques of Compiler Construction
Здравствуйте, mefrill, Вы писали:
M>Отвечу только на вопрос, чем мне не нравится алгоритм, примененный в АНТЛР3. Только одним — узостью класса грамматик, для которых он может работать. Конечно, можно сказать, что для большинства языков программирования легко придумать подходящую дя АНТЛР грамматику, но вот как раз это мне и не нравится. Я хочу использовать ту грамматику, которая нравится мне, а не данному генратору разборщиков. Можно было бы смериться с ситуацией, если бы не было других алгоритмов синтаксического анализа, позволяющих производить разбор языка на основе любой грамматики, но ведь они есть. Зачем ездить на самокате, если есть вездеход?
А какие, по-твоему, алгоритмы обеспечивают более широкую полосу анализа?
И почему ты думашь, что LL(*) охватывает узкий класс граматик.
Мне почему-то кажется, что LL(*) ни чем не хуже GLL.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Theory and Techniques of Compiler Construction
Здравствуйте, VladD2, Вы писали:
VD>А какие, по-твоему, алгоритмы обеспечивают более широкую полосу анализа?
Ну, есть несколько таких алгоитмов. Это классические алгоритмы разбора сверху вниз и снизу вверх с поиском в глубину. Существуют способы избежать зацикливания в этих алгоритмах, но способы не очень хорошие. Алгоритм Кока-Янгера-Касами позволяет производить разбор любой грамматики, но требует перевода ее в нормальную форму Хомского. Алгоритм Эрли позволяет производить разбор языка, заданного любой КС-граммаикой. До недавнего времени не было корректного алгоритма построения деревьев вывода для метода Эрли, но моими усилиями этот алгоритм был создан. Алгоритм Томиты, известный еще как GLR, также позволяет разбирать языки, заданные любой КС-грамматикой. В общем, есть два хороших алгоритма: алгоритм Эрли и алгоритм Томиты.
VD>И почему ты думашь, что LL(*) охватывает узкий класс граматик.
Блин, ну ты читаешь мои ответы??? Я же там распинался, на конкретных примерах тебе показывал, что алгортим зацикливается для грамматик, содержащих леворекурсивные правила и правила с пустой правой частью. Как будут обрабатываться неоднозначности? Моя модификация алгоритма Эрли, например, строит всевозможные деревья вывода для входной строки, если есть неоднозначности. LL(*) не строит, а выбирает только одно дерево по ходу пъесы, руководствуясь либо семантическими ограничениями, либо случайно выбирая конкретную альтернативу. Далее, все ограничения, связанные с LL(k) алгоритмом никто не отменял и в LL(*).
VD>Мне почему-то кажется, что LL(*) ни чем не хуже GLL.
Что за GLL такой??? Не слышал о таком методе. Вообще, Влад, ну ты хоть немного прислушивайся к мнению других людей. Я этой темой занимаюсь уже несколько лет, написал диссертацию. Зачем спорить об очевидных вещах? И мне совершенно непонятна твоя любовь к АНТЛР. Чем она вызвана? И о чем мы вообще спорим?
Re[16]: Theory and Techniques of Compiler Construction
Здравствуйте, mefrill, Вы писали:
VD>>А какие, по-твоему, алгоритмы обеспечивают более широкую полосу анализа?
<...skipped...> M>В общем, есть два хороших алгоритма: алгоритм Эрли и алгоритм Томиты.
В каких нибудь antlr/yacc/cocor — подобных инструменах они доступны?
M>Что за GLL такой??? Не слышал о таком методе. Вообще, Влад, ну ты хоть немного прислушивайся к мнению других людей. Я этой темой занимаюсь уже несколько лет, написал диссертацию. Зачем спорить об очевидных вещах? И мне совершенно непонятна твоя любовь к АНТЛР. Чем она вызвана? И о чем мы вообще спорим?
Очень похоже на спор программиста-практика и математика-теоретика. Одному нужен работающий инструмент здесь и сейчас. Другому нужен метод, к которому, может быть, инструмент со временем приложится. Вот только эта дельта t проблемой и является.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[17]: Theory and Techniques of Compiler Construction
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, mefrill, Вы писали:
VD>>>А какие, по-твоему, алгоритмы обеспечивают более широкую полосу анализа?
E><...skipped...> M>>В общем, есть два хороших алгоритма: алгоритм Эрли и алгоритм Томиты.
E>В каких нибудь antlr/yacc/cocor — подобных инструменах они доступны?
К сожалению, нет. Все известные мне реализации платные. Компания делает инструмент для себя, это требует ресурсов и, поэтому, никому не хочется делать такой инструмент бесплатным. У меня есть реализация алгоритма Эрли и некоторой системы динамической компиляции на его основе. Парсер регулярных выражений, лексический анализатор и синтаксический анализатор. Вот, если кому интересно, можно довести это до ума, написать еще один бесплатный открытый генератор парсеров.
Здравствуйте, mefrill, Вы писали:
VD>>И почему ты думашь, что LL(*) охватывает узкий класс граматик.
M>Я же там распинался, на конкретных примерах тебе показывал, что алгортим зацикливается для грамматик, содержащих леворекурсивные правила и правила с пустой правой частью. Как будут обрабатываться неоднозначности?
При постпроении ДКА можно попытаться выявлять такие места и переписывать их.
M> Моя модификация алгоритма Эрли, например, строит всевозможные деревья вывода для входной строки, если есть неоднозначности. LL(*) не строит, а выбирает только одно дерево по ходу пъесы, руководствуясь либо семантическими ограничениями, либо случайно выбирая конкретную альтернативу. Далее, все ограничения, связанные с LL(k) алгоритмом никто не отменял и в LL(*).
Насколько я понимаю основная идея этого LL(*) — это построение единого ДКА. Если состояния автомата совпадают с несколькими правилами, то входной поток сканируется до тех пор пока не будет найден токен который будет удовлетворять только одному правилу. Мне кажется, это решает большинство проблем LL(k)-анализаторов. Ну, да конечно в данной области мои познания не столь велеки.
VD>>Мне почему-то кажется, что LL(*) ни чем не хуже GLL.
M>Что за GLL такой??? Не слышал о таком методе.
Это не метод. Это только так "мысли в слух".
Это я про идею описанную здесь: General LL
.
M> Вообще, Влад, ну ты хоть немного прислушивайся к мнению других людей. Я этой темой занимаюсь уже несколько лет, написал диссертацию.
Я и прислушиваюсь. Только хочу не просто поверить слову, а хоть немного разобраться в проблеме. Мне эта информация нужно в сугубо практическом плане.
M> Зачем спорить об очевидных вещах?
Это они тебе очевидны. Даже если отбросить мысль о том, что ты можешь банльно не правильно понять суть этго LL(*), то нужно понимать, что это ты на этом собаку съел. А я так только понадкусывал. По этому то что тебе кажется очевидным для меня может таковым не являться (не хватает предпосылок).
M> И мне совершенно непонятна твоя любовь к АНТЛР. Чем она вызвана?
Да нет никакой любви к АНТЛР. Просто это даже на сегодны один из самых мощьных построителей парсеров из доступных свободно. А эта 3-шка вроде как обещает стать еще лучше. Вот мне и интересно мнение о ней и вообще о том как можно заполучить построитель парсеров удовлетворительного качетсва.
M> И о чем мы вообще спорим?
Разве это спор? Так... выуживаем из тебя доступную информацию.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: Theory and Techniques of Compiler Construction
Здравствуйте, mefrill, Вы писали:
M>К сожалению, нет. Все известные мне реализации платные. Компания делает инструмент для себя, это требует ресурсов и, поэтому, никому не хочется делать такой инструмент бесплатным. У меня есть реализация...
В каком виде?
M> алгоритма Эрли и некоторой системы динамической компиляции на его основе. Парсер регулярных выражений, лексический анализатор и синтаксический анализатор. Вот, если кому интересно, можно довести это до ума, написать еще один бесплатный открытый генератор парсеров.
Несколько вопросов:
1. Какова оценочная эффективность этого алгоритма. Ведь для рельной жизни важно не только качество разбора, но и скорость парсинга.
2. Где можно почитать о твоем методе. (по возможности популярно).
3. Насколко ты готов разобраться в этом вопросе тем кто займется этоим доведением до ума?
В принципе задача интересная. Ею можно было бы заняться.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, fplab, Вы писали:
F>> Знаем такую, достойная вещь. Только не хватает страниц 58, 59, 74 и 75. А они довольно важны Вот их бы почитать.
СГ>Можете сказать спасибо Владимиру Лосю...
СГ>http://blackbox.thundersign.su/docs.html
Спасибо ! То, что надо
Приходиться заниматься гадостью — зарабатывать на жизнь честным трудом (Б.Шоу)
Вот их бы почитать.
