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

VD>А он есть — это компилятор то? У нас пока что будет только набор классов которые будут читать метаданные. Вот их умения и надо будет тестировать.
Их гораздо проще тупро распечатать.
Портянка получится большая ну и хрен бы с ней. А руками ее ты озвереешь набивать.
У нас за ней роботы смотреть будут.
А если в портянке появится разница ее можно посмотреть через любой diff tool.

VD>Короче, NUnit всегда полезен. Положим так же в зависимости. Карман тянуть не будет.
Мне честно говоря подход NUnit к тестированию не нравится.
Мне всегда было в лом писать кучу проверок руками.
ИМХО куда проще просто сделать печать и сохранить первый выхлоп как эталон.

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

P>Хорошо бы всегда иметь перед глазами конечное состояние проекта т.е. список фундаментальных и не очень фич.
P>которые, кстати наверное надо обсудить и отразить хотя бы в issues(, а может ещё как-то получше?)

Цель — создать неограниченное управление синтаксисом и поддержать все рантаймы. Средство — компонентный компилятор: расширяемый и заменяемый парсер, заменяемые компонент(ы) по работе с IL (в далеких, но обозримых планах LLVM) и компактное ядро компилятора.

Вобщем получится конструктор компиляторов на котором будет написан nemerle 2. AFAIK, особых отличий синтаксиса не планируется, кроме новых синтаксических макр встраиваемых в парсер, а вот на них уже можно будет писать все что угодно.

Еще планируется полная поддержка всех фич немерла в C# (сейчас только вывод типов и атрибутные макры, причем сами макры пишутся на nemerle).

Это все мое имхо, компиляция обсуждений на форуме. Пусть Влад поправит, если что не так.

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

WH>Их гораздо проще тупро распечатать.
WH>Портянка получится большая ну и хрен бы с ней. А руками ее ты озвереешь набивать.

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

Потом лично мне по фигу как все будет тестироваться. Мне важно:
А. Чтобы оно тестировалось. Юнит-есты на начальном этапе — это лучший выбор.
Б. Чтобы оно тестировалось одними и теми же средствами. А то у каждого заведется по своей утилите тестирования и мы потонем в деталях.

WH>У нас за ней роботы смотреть будут.
WH>А если в портянке появится разница ее можно посмотреть через любой diff tool.

Ну, и с юнит-тестами та же фигня.

VD>>Короче, NUnit всегда полезен. Положим так же в зависимости. Карман тянуть не будет.
WH>Мне честно говоря подход NUnit к тестированию не нравится.
WH>Мне всегда было в лом писать кучу проверок руками.

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

WH>ИМХО куда проще просто сделать печать и сохранить первый выхлоп как эталон.

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

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

Я вот смотрю на твои тесты к ComputationExpressions и тихо охрениваю. И это при том, что в старом компиляторе как раз таки была отличная утилита по тестированию кода.

Зачем нам такой зоопарк? Пусть уж они пока на NUnit-е тесты делают. Тем более что если нужна будет проверка текстового вывода, то ее элементарно автоматизировать можно.

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

VD>Эту портянку еще руками набивать придется. Юнит-тесты же пишутся перед или непосредственно при реализции методов/свойств, так что не озвереют.
Я никогда не понимал зачем этот геморой.
Ибо эту работу может сделать машина.

VD>А. Чтобы оно тестировалось. Юнит-есты на начальном этапе — это лучший выбор.
Меня напрягают не юнит тесты, а то как они сделаны в NUnit.

VD>Б. Чтобы оно тестировалось одними и теми же средствами. А то у каждого заведется по своей утилите тестирования и мы потонем в деталях.
Вот я сейчас такое средство и сделаю.
Я под это уже клон завел.

WH>>У нас за ней роботы смотреть будут.
WH>>А если в портянке появится разница ее можно посмотреть через любой diff tool.
VD>Ну, и с юнит-тестами та же фигня.
И на что же ты будешь смотреть то если у тебя ничего не распечатывается?

VD>Они позволяют делать проверки интерактивно и более тонко.
По сравнению с чем?

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

VD>Я вот смотрю на твои тесты к ComputationExpressions и тихо охрениваю. И это при том, что в старом компиляторе как раз таки была отличная утилита по тестированию кода.
А я охреневаю от того во что это превратится при использовании NUnit.

VD>Зачем нам такой зоопарк? Пусть уж они пока на NUnit-е тесты делают. Тем более что если нужна будет проверка текстового вывода, то ее элементарно автоматизировать можно.
Зоопарк не нужен.
NUnit тоже.

Короче я сейчас сделаю и покажу что имею в виду.
А ты потом покажешь как тоже на NUnit выглядеть будет
Я буду жесток.

Раз начинаем заново, было бы интересно(если возможно конечно) оторвать Nemerle от .Net, и заложить на будущее возможность компиляции под разные платформы. Например LLVM.

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

KK>Раз начинаем заново, было бы интересно(если возможно конечно) оторвать Nemerle от .Net, и заложить на будущее возможность компиляции под разные платформы. Например LLVM.

Оторвать — не проблема, только без библиотек это получится "кусок суперязыка с компиляцией в x86".

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

C>Так почему не Indent ? Если в соглашении о кодировании уже включён индент, то
C>{ // Ну нафига я это пишу
C>} // Почему не индент ?

C>после def скобку открывать очень сложно, питон мне запретил так извращаться
C>для интерпрератора немерле индент очень подойдёт.

Хм, да нет, одно дело индент в соглашении о кодировании, а другое — в используемом режиме компиляции.

Сейчас индент на 100% не работает (лямбды и квазицитирование, как я понимаю, не пашут), поэтому стройного кода лишь на индентах не выйдет.

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

KK>Раз начинаем заново, было бы интересно(если возможно конечно) оторвать Nemerle от .Net, и заложить на будущее возможность компиляции под разные платформы. Например LLVM.

Это огромный объем работ. Лично я этим заниматься пока что не намерен. Можешь присоединиться и вести работу в этом направлении.

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

Z>Цель — создать неограниченное управление синтаксисом и поддержать все рантаймы. Средство — компонентный компилятор: расширяемый и заменяемый парсер, заменяемые компонент(ы) по работе с IL (в далеких, но обозримых планах LLVM) и компактное ядро компилятора.

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

Если уж поддерживать LLVM, то на другие рантаймы по идее надо забивать, так как тогда бы у нас были уже развязаны руки и мы могли бы реализовать очень смелые планы. Другие рантаймы при этом будут палками в колесах. К тому же сегодня поддерживать дотнет весьма нужно, так как это WP7, CF (а значит XBox), Сервилат, WPW и другие W.

Z>Вобщем получится конструктор компиляторов на котором будет написан nemerle 2. AFAIK, особых отличий синтаксиса не планируется, кроме новых синтаксических макр встраиваемых в парсер, а вот на них уже можно будет писать все что угодно.

+1

Z>Еще планируется полная поддержка всех фич немерла в C# (сейчас только вывод типов и атрибутные макры, причем сами макры пишутся на nemerle).

Ну, все фичи конечно не реализуешь. Синтаксис шарпа на это не рассчитан. Но что получится сделаем.

ЗЫ

Я бы охарактеризовал бы новую версию немерла как шаг к упрощению DSL-естроения и повышению качества.
Надеюсь, что когда мы зарелизим Nemerle 2, то создать на нем Немерле на Рельсах можно будет за недельку. А разные Разоры (внешние ДСЛи рендеренга ХТМЛ-я) будут клепаться за пару дней.

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

M>Оторвать — не проблема, только без библиотек это получится "кусок суперязыка с компиляцией в x86".

Ага. Но и оторвать — это проблема. Бэкэнд — это отдельная и очень объемная работа. Даже API типа обсуждаемых CCI/AbsIL — это мегабайты кода. AbsIL — это где-то 1.5 метра F#-пного кода! Это сопоставимо со всем объемом компилятора немерла. Короче — много букв (с).

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

WH>>Отступы чем отбиваем? Таб или 2 пробела?

M>Я использую 4 пробела.

Значит придется привыкнуть к двум. Для фунционального кода 4 — это оверкил.

M>Два пробела не дают хорошего визуального отделения блоков, тем более в таком хитросинтаксном языке.

Более чем достаточно. А вот разнобой недопустим.

Раз народ за пробелы, то будет точно 2 и никак иначе.

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

DR>Я пользуюсь табами длиной в 8 пробелов.

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

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

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

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

WH>TortoiseHG каждый раз при пуше спрашивает логин и пароль.
WH>Как ему объяснить чтобы он их запомнил раз и насегда?

hgtk log -> tools -> settings -> synchronize -> редактируем default репозитарий, там можно задать логин и пароль

Заодно там же добавляем свой клон (или главный репозитарий, если default на клон показывает).

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

Z>hgtk log -> tools -> settings -> synchronize -> редактируем default репозитарий, там можно задать логин и пароль

Z>Заодно там же добавляем свой клон (или главный репозитарий, если default на клон показывает).

А у меня еще такая ситуация... Я выполнил команду Pull, но текущей ревизией у меня является не последняя, а та что "Fix DirHierarchy.txt" (кстати, как их идентифицировать?). Она подсвечена жирным и кружочки за ней мельче чем до нее. Исходников, естественно, новых тоже нет.

Что сделать чтобы перейти на последнюю ревизию?

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

KK>Раз начинаем заново, было бы интересно(если возможно конечно) оторвать Nemerle от .Net, и заложить на будущее возможность компиляции под разные платформы. Например LLVM.
Моно же вроде умеет? Имхо, гораздо полезнее была бы java, там не вендорные языки пользуются хоть какой то популярностью.

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

VD>А у меня еще такая ситуация... Я выполнил команду Pull, но текущей ревизией у меня является не последняя, а та что "Fix DirHierarchy.txt" (кстати, как их идентифицировать?). Она подсвечена жирным и кружочки за ней мельче чем до нее. Исходников, естественно, новых тоже нет.

VD>Что сделать чтобы перейти на последнюю ревизию?

Pull-ом ты скачал коммиты в свой локальный репозиторий, а содержимое рабочей папки осталось прежним. Для того, чтобы обновить рабочую папку нужно выполнить сделай hg update. Команда, запущенная без параметров, выполнит обновление до самой последней версии текущей ветки.

p.s. Состояние репозитория и локальной папки лучше всего отображает следующая (еще не зарелизенная) версия tortoisehg, разработка которой ведется в репозитории https://bitbucket.org/tortoisehg/thg/wiki/Home . Там же можно скачать бету версию. Этот клиент показывает на общем графе также и рабочую папку, позволяя быстро просмотреть diff незакоммиченных изменеий или апдейтнуться на выбранную ревизию. Мне этот клиент очень понравился, но к сожалению он пока сильно притормаживает на репозиториях, имеющих много именованых бранчей (на репозитории nemerle еще не тестировал).

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

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

C>>Так почему не Indent ? Если в соглашении о кодировании уже включён индент, то
C>>{ // Ну нафига я это пишу
C>>} // Почему не индент ?

C>>после def скобку открывать очень сложно, питон мне запретил так извращаться
C>>для интерпрератора немерле индент очень подойдёт.

C>Хм, да нет, одно дело индент в соглашении о кодировании, а другое — в используемом режиме компиляции.

C>Сейчас индент на 100% не работает (лямбды и квазицитирование, как я понимаю, не пашут), поэтому стройного кода лишь на индентах не выйдет.

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

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

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

Пример:

using System
using Nemerle.Utility

[Record] // Новый индент не потребует \ как требуется сейчас
class A
  public F() : int
    1

  public G() : int { 1 } // можно в одну строку со скобками
 
class B {} // Пустой класс требует скобок, иначе невозможно описать его.

module Program
  Main() : void
    def x =
      match (A().F()) // Тут скобки не нужны
        | 1 => "a"
        | _ => def p = "b"; p // На одной строке в выражении можно использовать ; как обычно.
    
    def f(q) { q + "c" } // Однострочная функция требует скобки
    def g(q) // Многострочная не требует
      q + "d"

    Console.WriteLine(f(g(x)))

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

VD>А у меня еще такая ситуация... Я выполнил команду Pull, но текущей ревизией у меня является не последняя, а та что "Fix DirHierarchy.txt" (кстати, как их идентифицировать?). Она подсвечена жирным и кружочки за ней мельче чем до нее. Исходников, естественно, новых тоже нет.

VD>Что сделать чтобы перейти на последнюю ревизию?

конт. меню на нужной ревизии, update

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

M>Оторвать — не проблема, только без библиотек это получится "кусок суперязыка с компиляцией в x86".

Теоретически можно скомпилировать моно Компилировать C# мы умеем.