Re[3]: Здравствуйте товарищи разработчики R#. - Открытые проекты

Здравствуйте товарищи разработчики R#.

Давно читаю ваш форум и изучаю ваши сорцы поскольку тема для меня интересная.
Меня интересует построение на базе R# генератора метрик для статического анализа кода
и редактора сорцов с интелектуальным рефакторингом.

Наконец собрал из них все бинарии и получил нечто работающее. В данном случае CodeAnalizer. Проблема сборки была банальна, TreeGrid reference в проекте CodeAnalizer тащится из фолдера внешнего по отношению к проекту RSharp хотя внутри лежит копия длл (до этого попадались снапшоты сорцов которые не собирались в некоторых местах).

Натравил CodeAnalizer на сорцы R# (RSParser) поскольку других под рукой не оказалось. Получил ошибку парсинга

E:\Projects\RSharp\RSParser\CodeDom\Collections\RAttributeCollection.cs(267,38): error: "(" expected
E:\Projects\RSharp\RSParser\CodeDom\Collections\RAttributeCollection.cs(267,38): error: ")" expected
E:\Projects\RSharp\RSParser\CodeDom\Collections\RAttributeCollection.cs(267,38): error: invalid ClassOrStructMemberDecl
E:\Projects\RSharp\RSParser\CodeDom\Collections\RAttributeCollection.cs(267,38): error: "}" expected
E:\Projects\RSharp\RSParser\CodeDom\Collections\RAttributeCollection.cs(267,38): error: "}" expected
E:\Projects\RSharp\RSParser\CodeDom\Collections\RAttributeCollection.cs(267,38): error: EOF expected

Пригляделся к сорцам и убидел что диагностика не соотвествует действительности.
Думаю бага, низкого приоритета.

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

А>Меня интересует построение на базе R# генератора метрик для статического анализа кода

ПЛ (он же Павел Леонов, Берета) даже в свое время сделал проект-плагин к VS 2003. Который даже отловил пару реальных ошибок в проекте. К сожалению он похоже его забросил. Ну, да было бы желание...

А>и редактора сорцов с интелектуальным рефакторингом.

А чем не устраивает ReSharperздесь? В смысле, делай если хочется. Но вот есть ли толк?

Для того, чтобы из R#-а сделать тул для рефакторинга сначала нужно обязательно написать полноценное разрешение имен. Пока что-оно сильно ограниченное.

А>Наконец собрал из них все бинарии и получил нечто работающее. В данном случае CodeAnalizer. Проблема сборки была банальна, TreeGrid reference в проекте CodeAnalizer тащится из фолдера внешнего по отношению к проекту RSharp хотя внутри лежит копия длл (до этого попадались снапшоты сорцов которые не собирались в некоторых местах).

Вот тут R# под SVN и в открытом доступе. есть описание по сборке R#-а.

А>Натравил CodeAnalizer на сорцы R# (RSParser) поскольку других под рукой не оказалось. Получил ошибку парсинга
...
А>Пригляделся к сорцам и убидел что диагностика не соотвествует действительности.
А>Думаю бага, низкого приоритета.

Это не приоритет. Это недоработка. Просто R# переведен на C# 2.0 и отехоничку использует его новые фичи. В том числе дженерик-интефейсы. Вот в этом файле как раз явная реализация этого дела:

IEnumerator<RAttributeDeclaration> IEnumerable<RAttributeDeclaration>.GetEnumerator()
{
    throw new NotImplementedException();
}

А сейчас это дело не обрабатывается. Я как раз сейчас над этим работаю. Там не все так просто. Это фишка не по зубам для LL(1)-парсера (коим является используемый нами CocoR).

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

IEnumerator<X>  IEnumerable<X>.GetEnumerator<Y>()

Каждый участок Xxx<...> является так называемым "простым именем". Но имя метода плюс параметры типа тоже прокатывает под определение простого имени. Так что нужен более делатьный контроль.

Ну, а так как времени нехватает, то торможу по тихончку. В обще, надеюсь в ближайшее время устранить эту недороботку.

Пока что можно тестироваться на других проектах. Например, есть проект RscTest. Это специально созданная копия RSParser, но замороженная на стадии когда проект еще не был переведен на C# 2.0. На нем все должно проходить верно.

... << RSDN@Home 1.1.4 beta 3 rev. 207>>

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

VD>А чем не устраивает ReSharperздесь? В смысле, делай если хочется. Но вот есть ли толк?

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

VD>Для того, чтобы из R#-а сделать тул для рефакторинга сначала нужно обязательно написать полноценное разрешение имен. Пока что-оно сильно ограниченное.

VD>Вот тут R# под SVN и в открытом доступе. есть описание по сборке R#-а.
Угу, но я вроде уже со сборкой разобрался, а поддержка SVN понадобится когда напишу и коммитить соберусь что-нибуть.

А>>Натравил CodeAnalizer на сорцы R# (RSParser) поскольку других под рукой не оказалось. Получил ошибку парсинга
VD>...
А>>Пригляделся к сорцам и убидел что диагностика не соотвествует действительности.
А>>Думаю бага, низкого приоритета.

VD>Это не приоритет. Это недоработка. Просто R# переведен на C# 2.0 и потехоничку использует его новые фичи. В том числе дженерик-интефейсы. Вот в этом файле как раз явная реализация этого дела:

VD>

VD>IEnumerator<RAttributeDeclaration> IEnumerable<RAttributeDeclaration>.GetEnumerator()
VD>{
VD>    throw new NotImplementedException();
VD>}
VD>

VD>А сейчас это дело не обрабатывается. Я как раз сейчас над этим работаю. Там не все так просто. Это фишка не по зубам для LL(1)-парсера (коим является используемый нами CocoR).

VD>Дело в том, что метод сам по себе может быть дженерик. Тогда запись будет примерно такой:
VD>

VD>IEnumerator<X>  IEnumerable<X>.GetEnumerator<Y>()
VD>

VD>Каждый участок Xxx<...> является так называемым "простым именем". Но имя метода плюс параметры типа тоже прокатывает под определение простого имени. Так что нужен более делатьный контроль.

VD>Ну, а так как времени нехватает, то торможу по тихончку. В обще, надеюсь в ближайшее время устранить эту недороботку.

VD>Пока что можно тестироваться на других проектах. Например, есть проект RscTest. Это специально созданная копия RSParser, но замороженная на стадии когда проект еще не был переведен на C# 2.0. На нем все должно проходить верно.

Ясно. Буду смотреть дальше.

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

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

VD>>А чем не устраивает ReSharperздесь? В смысле, делай если хочется. Но вот есть ли толк?

L>Про решарпер знаю. Хочется самому, ручками научится.

Тогда нет вопросов.

Только учти, для этого нужно въехать во многие тонкасти того что уже сделано. Я готов помочь чем могу.

L>Кстати поглядел на кодеаналайзер. на сколько я понимаю он рисует дерево

Что значит рисует? Он использует парсер R#-а. Сам он только пробегается по нему и провдит анализ.

L> согласно внутреннему представлению ничего при этом не меняя, отсюда вопрос, почему при разборе одного юнита получается два неймспейса на одном уровне,

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

L>глобальный и тот который программер навалял, хотя вроде как они должны быть вложеные (IMHO программерский должен быть ребенком глобального).

По идее, да.

L>Ясно. Буду смотреть дальше.

Если что... дергай. Будем помогать.

... << RSDN@Home 1.1.4 beta 3 rev. 207>>

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

L>>Про решарпер знаю. Хочется самому, ручками научится.

VD>Тогда нет вопросов.

VD>Только учти, для этого нужно въехать во многие тонкасти того что уже сделано. Я готов помочь чем могу.

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

VD>Что значит рисует? Он использует парсер R#-а. Сам он только пробегается по нему и провдит анализ.
Рисует в смысле, берет то что построено парсером и отображает его 1 в 1, т.е. это визуальное представление работы парсера в чистом виде.

VD>Это работа парсера и спецификация языка. То что они на одном уровне — это скорее огрехи производства. По уму все остальные пространства имен должны быть вложенными в глобальный. Просто никто до этого е обращал на это внимание. Не мешает и ладно.

L>>глобальный и тот который программер навалял, хотя вроде как они должны быть вложеные (IMHO программерский должен быть ребенком глобального).
VD>По идее, да.

ясно.

Надумалось вот еще что:

сейчас так

compile-unit {
  Imports{}
  namespaces {
    global-namespace {...}
    user-namespace1 {...}
    user-namespace2 {...}
  }
}

подумалось что global покрывает весь файл вместе с таблицей импорта
при этом import вроде вполне может быть внутри любого неймспейса (стандарт C# еще не читал, попробовал, компайлер не ругается),
тогда выглядеть это будет примерно так

compile-unit {
  global-namespace {
    Imports{}
    namespaces {
      user-namespace1 {...}
      user-namespace2 {...}
    }
  }
}

таким образом global-namespace фактически совпадает со всем compile-unit и
отличается от него только тем что у того есть имя файла.

Про разрешение имен.
Это всякий геморой связаный с разрешением ссылок на ф-ии, Argument Depended Lookup и т.д?

L>>Ясно. Буду смотреть дальше.
VD>Если что... дергай. Будем помогать.

Угу, сенькс.

ЗЫ: у global-namespace тоже имя есть так что не очень понятно чем оно от compile-unit отличается.

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

L>Рисует в смысле, берет то что построено парсером и отображает его 1 в 1, т.е. это визуальное представление работы парсера в чистом виде.

А разве этот адд-ын что-то отображает?

L>Надумалось вот еще что:

L>сейчас так
L>

L>compile-unit {
L>  Imports{}
L>  namespaces {
L>    global-namespace {...}
L>    user-namespace1 {...}
L>    user-namespace2 {...}
L>  }
L>}
L>

L>подумалось что global покрывает весь файл вместе с таблицей импорта
L>при этом import вроде вполне может быть внутри любого неймспейса (стандарт C# еще не читал, попробовал, компайлер не ругается),

На самом деле все не так просто (однозначно). Вот граматика из спецификации:

compilation-unit:
    extern-alias-directives-opt 
    using-directives-opt 
    global-attributes-opt
    namespace-member-declarations-opt

Как видишь, по сути глобального пространства имен даже не существует. using и глобальные атрибуты как бы находятся в compilation-unit-е. И это не с проста, ведь глобальные атрибуты могут быть только тут. Вот, для сравнения, описание тела пространства имен:

namespace-body:
{
    extern-alias-directives-opt 
    using-directives-opt 
    namespace-member-declarations-opt
}

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

L>тогда выглядеть это будет примерно так

L>

L>compile-unit {
L>  global-namespace {
L>    Imports{}
L>    namespaces {
L>      user-namespace1 {...}
L>      user-namespace2 {...}
L>    }
L>  }
L>}
L>

L>таким образом global-namespace фактически совпадает со всем compile-unit и
L>отличается от него только тем что у того есть имя файла.

Нет, главное отличие — это наличие глобальных атрибутов. В принципе можно было бы создать базовый класс (RNamespaceBase) от которого породить RNamespace и RCompileUnit. Тогда у RNamespace можно было бы добавить имя, а у RCompileUnit список глобальных атрибутов. Тогда можно было бы наиболее полно применять полиморфизм.

Видимо так и нужно будет сделать. Но насколько это актуально? По мне так приоритетность у данной задачи не велика.

L>Про разрешение имен.
L>Это всякий геморой связаный с разрешением ссылок на ф-ии, Argument Depended Lookup и т.д?

Что-то вроде. Одним словом — это разрешение всех ссылок. Например, в коде программы есть ссылки на переменные. Сейчас — это неразрешенные ссылки, а надо сделать так чтобы имея объявление переменной можно было бы быстро найти все ее вхождения. И наоборот, имея некоторое вхождение узнать ее объявление, типа и т.п. Тоже самое с методами, классами и т.п.

L>ЗЫ: у global-namespace тоже имя есть так что не очень понятно чем оно от compile-unit отличается.

Нет у него имени. Это побочные эффекты. В принципе я выше описал как будет правильнее. Можно в принципе поправить.

... << RSDN@Home 1.1.4 beta 3 rev. 207>>

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

VD>На самом деле все не так просто (однозначно). Вот граматика из спецификации:
VD>

VD>compilation-unit:
VD>    extern-alias-directives-opt 
VD>    using-directives-opt 
VD>    global-attributes-opt
VD>    namespace-member-declarations-opt
VD>

VD>Как видишь, по сути глобального пространства имен даже не существует. using и глобальные атрибуты как бы находятся в compilation-unit-е. И это не с проста, ведь глобальные атрибуты могут быть только тут. Вот, для сравнения, описание тела пространства имен:
VD>

VD>namespace-body:
VD>{
VD>    extern-alias-directives-opt 
VD>    using-directives-opt 
VD>    namespace-member-declarations-opt
VD>}
VD>

VD>Как видишь, структура похожа, но не идентична. В принципе было бы правильно вообще избавиться от глобального пространства имен, но уж больно удобно им пользоваться.

VD>Нет, главное отличие — это наличие глобальных атрибутов. В принципе можно было бы создать базовый класс (RNamespaceBase) от которого породить RNamespace и RCompileUnit. Тогда у RNamespace можно было бы добавить имя, а у RCompileUnit список глобальных атрибутов. Тогда можно было бы наиболее полно применять полиморфизм.

Попробовал для начала просто пронаследовать RCompileUnit от RNamespace, почикал дубликаты ф-ий. Попатчил еще cs.atg в районе CS() дабы другая структура получалась. В принципе заработало. Но во первых правильнее как ты написал через RNamespaceBase сделать, во вторых возможно где-то в другом месте что-то отвалилось, Юнит тестов нет, фиг узнаешь.

VD>Видимо так и нужно будет сделать. Но насколько это актуально? По мне так приоритетность у данной задачи не велика.

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

.

L>>Про разрешение имен.
L>>Это всякий геморой связаный с разрешением ссылок на ф-ии, Argument Depended Lookup и т.д?

VD>Что-то вроде. Одним словом — это разрешение всех ссылок. Например, в коде программы есть ссылки на переменные. Сейчас — это неразрешенные ссылки, а надо сделать так чтобы имея объявление переменной можно было бы быстро найти все ее вхождения. И наоборот, имея некоторое вхождение узнать ее объявление, типа и т.п. Тоже самое с методами, классами и т.п.

Правильно я понимаю что:

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

для первого видимо нужна какая то другая структура где каждая переменная будет содержать список ссылок на места где она используется либо каждый раз бегать по дереву и генерировать этот список. Т.е. бегать придется всегда а вот сохранять или не сохранять?

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

L>Попробовал для начала просто пронаследовать RCompileUnit от RNamespace, почикал дубликаты ф-ий. Попатчил еще cs.atg в районе CS() дабы другая структура получалась. В принципе заработало. Но во первых правильнее как ты написал через RNamespaceBase сделать, во вторых возможно где-то в другом месте что-то отвалилось, Юнит тестов нет, фиг узнаешь.

Загрузи тот же RSParser и процентов 70 тестов тебе гарантировано. Погляди на результат рендеренга кода по АСТ (менял ты ведь только RCompileUnit и RNamespace, вот ни них и смотри).

L>Мои ощущения были такие что, каждый элемент дерева построен парсером из куска кода и все непосредственные дети этого элемента покрывают собой этот кусок кода но не пересекаются между собой. это мое ощущение и было нарушено

.

AST не совсем отражение кода. Это отражение объектной модели кода. А она несколько более хитра нежели внешнее представление кода. К этому нужно привыкнуть.

L>Правильно я понимаю что:

L>для второго пункта надо иметь деревообразное пространство всего проекта

Правильно. Это уже делается в RSharp.Compiler/rsc и в CodeAnalyzer (если загружать проект, а не отдельный файл).

L>и импортированых в него сущностей

Правильно. Но это еще не делается. Хотя список внешних сборок получается.

L>(не знаю как это назвать)

Внешние сборки на которые ссылается проект.

L> и бегать по нему снизу вверх в поисках нужных ссылок.

Неправльно. Бегать нужно только от корня вниз. Если я не ошибаюсь, разрешение имен может быть сделано за 1 объход AST.

L> Алгоритм очевидно будет более сложный в силу множественности мест откуда могут приезжать типы и переменные и т.д.

Алгоритм осложняется только множественностью пространств имен.

L> Дерево проекта уже есть осталось только дерево импортированых сущностей и бегать.

Сложность в том чтобы написать правильный и в тоже время быстрый алгоритм объода.

L>для первого видимо нужна какая то другая структура где каждая переменная будет содержать список ссылок на места где она используется

Это называется областью видимости (scope). Где-то в форуме _Obelisk_ уже описывал примерный алогоритм.

L>либо каждый раз бегать по дереву и генерировать этот список.

Это медленно. Сейчас примерно так и делается. Причем разрешаются только типы описанные в проекте и только для заданного метса (где производится ссылка на тип).

L> Т.е. бегать придется всегда а вот сохранять или не сохранять?

Даже сейчас кое-что сохраняется. А надо сделать так чтобы после объхода вся информация была доступна с минимальными затратами.

... << RSDN@Home 1.1.4 beta 3 rev. 207>>

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

VD>Загрузи тот же RSParser и процентов 70 тестов тебе гарантировано. Погляди на результат рендеренга кода по АСТ (менял ты ведь только RCompileUnit и RNamespace, вот ни них и смотри).

Ну в общем это конечно вариант но к сожалению все случаи он не покрывает. С юниттестами было бы лучше.

Вчера попробовал сделать неймспейсы по честному через абстрактный RNamespaceBase. Наткнулся что в RCompileUnit и в RNamespace есть одинаково названные проперти Types которые при этом разные по сути. Переименовывать Types в RNamespace наверное неправильно. Насколько я понял эта проперть есть некое с-во встречающееся в наскольких R-сущностях. Кроме того еще наступают проблемы с генерацией визиторов с помощью CodeGen. Попробовал переименовать в RCompileUnit. Вроде прокатило но до конца еще не проверил, вот тут бы пригодились юниттесты.

Кстати о визиторах, планируется ли перевести их генерацию на механизм метаправил?
Может имеет смысл выделять автогенеренный код в отдельный файл и метить класс как partial?

Ну вроде пока все, приду домой допроверяю.

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

L>Вчера попробовал сделать неймспейсы по честному через абстрактный RNamespaceBase. Наткнулся что в RCompileUnit и в RNamespace есть одинаково названные проперти Types которые при этом разные по сути. Переименовывать Types в RNamespace наверное неправильно. Насколько я понял эта проперть есть некое с-во встречающееся в наскольких R-сущностях. Кроме того еще наступают проблемы с генерацией визиторов с помощью CodeGen. Попробовал переименовать в RCompileUnit. Вроде прокатило но до конца еще не проверил, вот тут бы пригодились юниттесты.

L>Ну вроде пока все, приду домой допроверяю.

вроде заработало.
Кстати CodeGen парсится с ошибкой.

//F:\Projects\RSharp\RSharp.Development.CodeGen\Query\ReachableMatrixGen.cs(194,44): error: invalid Expr
//F:\Projects\RSharp\RSharp.Development.CodeGen\Query\ReachableMatrixGen.cs(194,44): error: ";" expected

PS: Если выкладывать автогенеренные части в отдельный файл то тогда его под соурс контрол класть не надо, а то сейчас попробовал диф сделать, получилось ~400 кил. Хотя изменений с гулькин нос.

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

L>Ну в общем это конечно вариант но к сожалению все случаи он не покрывает. С юниттестами было бы лучше.

Если ты возьмешся написать юнит-тесы я против не буду.

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

L>Вчера попробовал сделать неймспейсы по честному через абстрактный RNamespaceBase. Наткнулся что в RCompileUnit и в RNamespace есть одинаково названные проперти Types которые при этом разные по сути.

Да. Есть такое дело. Вообще, наверно все эти Types, Udt, Classes, Interfaces, Structs, Enums и Delegates пока что нужно закоментировать и забыть про них до поры до времени. Они были сделаны для оптимизации запросов на собственно движке запросов. Но этот движок на сегодня малость заброшен, так как удалось прилично опримизировать XPath.

L> Переименовывать Types в RNamespace наверное неправильно. Насколько я понял эта проперть есть некое с-во встречающееся в наскольких R-сущностях. Кроме того еще наступают проблемы с генерацией визиторов с помощью CodeGen.

L> Попробовал переименовать в RCompileUnit. Вроде прокатило но до конца еще не проверил, вот тут бы пригодились юниттесты.

Types в RCompileUnit расширенное словйство (помечено атрибутом [ExtendedProperty]) и для визитеров оно не должно быть видно. Это, как я уже говорил, оптимизация фичи которая на сегодня заброшена. И как любая оптимизация она может создать проблемы. Так что пока что эти свойства нужно закоментировать (вместе с кодом их заполняющим).

L>Кстати о визиторах, планируется ли перевести их генерацию на механизм метаправил?

Да уже как бы. Просто все пока в тестовом режиме. Собственно вот эта тема: Мета-правило реализующиее паттерн Visitor как раз плот этой попытки.

L>Может имеет смысл выделять автогенеренный код в отдельный файл и метить класс как partial?

Зачем? Пока что rsc генерирует код для всего проекта в поддериктории .RSharp\Generated обрабатываемого проекта. Тутда же будут попадать и все визитеры.

L>Ну вроде пока все, приду домой допроверяю.

Давай. Только у тебя прав на комит, как я понимаю, нет. Так что пока шли мне на мыло. Я проверю и залью. А там и права дадим.

... << RSDN@Home 1.1.4 beta 3 rev. 207>>

L>вроде заработало.
L>Кстати CodeGen парсится с ошибкой.

L>

L>//F:\Projects\RSharp\RSharp.Development.CodeGen\Query\ReachableMatrixGen.cs(194,44): error: invalid Expr
L>//F:\Projects\RSharp\RSharp.Development.CodeGen\Query\ReachableMatrixGen.cs(194,44): error: ";" expected
L>

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

L>PS: Если выкладывать автогенеренные части в отдельный файл то тогда его под соурс контрол класть не надо, а то сейчас попробовал диф сделать, получилось ~400 кил. Хотя изменений с гулькин нос.

Как я уже говорил, я сейчас работаю над переводом генерации кода для R# на сам R#. Как только это будет сделано, и как только компиляция R# будет осуществляться с помощью него же, проблем с чекином автогенерируемого кода вообще не будет, так как чекиниться будет исходный кода, а втогенеренный будет лежать в другой папке (создаваться по требованию).

Надеюсь в ближайший месяц удастся перевести R# на R#.

... << RSDN@Home 1.1.4 beta 3 rev. 207>>

	От:	Аноним
	Дата:	19.11.04 11:57
	Оценка:

От:	VladD2	www.nemerle.org
Дата:	20.11.04 01:25
Оценка:

	От:	Loislo
	Дата:	22.11.04 09:29
	Оценка:

От:	VladD2	www.nemerle.org
Дата:	23.11.04 14:14
Оценка:

	От:	Loislo
	Дата:	23.11.04 15:03
	Оценка: