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

VD>Вот хрен его знает. Раньше я бы категорически за табы, но как-то привык к двум проблемам. Так что теперь мне в общем-то все равно. Даже проблемы удобнее, так как таб можно использовать для отбивки в стиле табличного форматирования.
+1
Но нужно сделать выбор.
Предлагаю два пробела.

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

• перед началом работы, впишите в настройки репозитария или глобальные себя как автора в виде Alex Zimin <ziminav@gmail.com> иначе ваши комиты пойдут под именем пользователя в OS.
  
• если у вас стоит tortoisesvn — используйте его tortoisemerge и tortoisediff,
  
• чтобы не делать лишних мерджей, включите расширение mq. Теперь можно указывать в комбобоксах After pull значение Rebase, тогда ваши правки автоматом разместятся поверх вытянутых чужих. Merge не понадобится если не были задеты одни и те же строки.
  Эти три пункта делаются проще всего правкой конфига tortoisehg -> Global Settings -> Edit file
  

  [ui]
  username = Alex Zimin <ziminav@gmail.com>
  merge = tortoisemerge
  
  [extensions]
  mq=
  rebase=
  
  [tortoisehg]
  vdiff = tortoisemerge

  
  
  
• перед пулом, убедитесь, что все ваши правки закомичены, тогда они точно никуда не пропадут при неожиданном merge, вообще merge лучше делать тогда когда вы хотите, а не когда идет pull.
  
• вообще комиттесь чаще, это очень быстро, гарантирует безопасность правок и облегчает последующий merge конфликтов если они случились. Интересный факт, в rubymine, лучшем IDE для ruby отсутствует save, все правки сразу пишутся на диск. Никаких проблем это не вызывает, ибо большинство рубистов сидит на git, и функцию сохранить заменили себе комитом. Как только все работает, сделайте комит, потом будет легче понять, что же все таки сломалось.
  
• для быстрого комита сделайте кнопки на тулбаре студии, для этого добавьте в external tools две команды:
  
  

  Title: Show repository
  Command: %PROGRAMFILES%\TortoiseHg\hgtk.exe 
  Arguments: log
  Initial directory: $(SolutionDir) 
  
  Title: Commit
  Command: %PROGRAMFILES%\TortoiseHg\hgtk.exe 
  Arguments: commit
  Initial directory: $(SolutionDir)

  
  
  У студии есть один неприятный момент, изменения в csproj она хранит в памяти до одного ей известного момента, поэтому желательно проверять, ушел ли этот csproj в комит. Не знаю как с этим дела у немерловой интеграции. В принципе дома я использую VisualHg, работает стабильно, но кнопки на тулбаре все равно остались, к ним привык.
  
  
• Окно repository explorer (hgtk log) универсальное, все нужные операции делаются в нем, надобность в отдельных окнах incoming, outgoing, synchronize, changelog отсутствует начисто. Изучите его и диалог комита, больше для работы ничего не понадобится.
  
• Для экспериметального бранча проще всего сделать еще один клон репозитария. Склонировать локально репозитарий можно очень быстро.

Здравствуйте, 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>6.2. Если вы инициализируете mutable начальное значение которой совпадает со значением для ее типа принятым по умолчанию, не указывайте начальное значение.
VD>

VD>// Используйте:
VD>mutable isOpen;
VD>// вместо:
VD>mutable isOpen = false;
VD>

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

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

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

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

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

Я тоже использовал когда-то 4 пробела. 2 удобнее — немерловый код имеет свойство быстро "уезжать" вправо.

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

IT>>Не передумали ещё на табы перейти?
C>+1 , Я за табы. 2 пробела мне совсем не нравятся, мне привычнее 4, а табуляцию может каждый настроить по настроению.

К сожалению, разработчики Немерле любят пробелы больше, чем людей.

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

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

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

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

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

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

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

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

VD>А из Тортилы это как сделать?

Щелкнуть правой кнопкой на самой последней ревизии и выбрать Update... В появившемся диалоге уже будет выбран номер ревизии, по которой ты щелкнул. Вместо номера ревизии можно вбить имя бренча, тогда будет произведен апдейт на последнюю ревизию указанной ветки. При установленном VisualHG диалог можно вызвать непосредственно из студии — кнопкой на тулбаре. При сброшенной галочке "Discard local changes" апдейт не затронет неверсионированные файлы рабочего каталога — они так и останутся лежать на своих местах. При взведенной галочке рабочий каталог после апдейта будет в точности соответствовать состоянию ревизии в репозитории — все неверсионировнные файлы будут удалены. Галочку можно использовать для отмены еще незакоммиченных изменений, например для ликвидации последствий неудачного merge.

Если изменения были закомиченны, но еще не заPUSHены в удаленый (гугловый) репозиторий, то такой коммит можно отменить коандой rollback, доступной из меню тортилы Tools->Recovery

VD>Можно конкретную ссылку на место где бэту брать?

https://bitbucket.org/tortoisehg/thg/downloads/tortoisehg-unstable-1.9.655.2596-x86-9e60adaf-6749-4d95-ae4a-468f55864223.msi
Честно говоря боюсь рекоменловать эту бету, тем более VisualHG с ней не работает. Обещают, что проект зарелизится в марте и заменит собой текущую тортилу. Правда месяц назад датой релиза разработчики называли декабрь этого года )))

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

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

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

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

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

Z>>Впрочем глобальный рефакторинг тоже хороший выход. Надо вычитать и вычистить хотя бы те статьи, на которые есть ссылки с главной. Там столько старых и абсолютно неактуальных текстов, что врядли кому-то понравится поиск нужной информации. Я бы мог этим позаниматься, только не могу даже восстановить пароль.

VD>Обратись к Кочеткову. Он поможет с паролем.

VD>Только учти. На статьи есть ссылки из других мест (не только из вики). Так что удалять их не стоит. Лучше просто создавать новые.

Создать шаблон {{deprecated|new_url=}} и вставить в старые статьи

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

Так же заранее прошу прощения за узурпацию права по выработке стиля.

Стиль кодирования проекта Nemerle 2

1. Базовым документом по оформлению кода является Соглашения по оформлению кода команды RSDN.

2. Правила описанные ниже переопределяют правила описанные в приведенном в пункте 1.

3. Длинна строк должна быть <= (меньшей или равной) 120 символам. Допускаются строки длинyее 120 символов если они не несут смысловой нагрузки. Например, если имеется длинная строк с текстовым сообщением, то ее нет смысла переносить на новую строку, так как для понимания кода она не особо нужна, а увеличение количества строк ухудшает понимание остального кода.
Если выражение получается слишком длинным и требует переноса, то стоит подумать над тем, чтобы разбить его на ряд промежуточных выражений путем введения дополнительных локальных переменных или локальных функций. Имена локальных переменных и локальных функций являются дополнительной документацией к коду, так что не пренебрегайте ими на том основании, что можно обойтись без них или что код станет чуточку длиннее. Помните, что важна не длинна кода, а его понятность окружающим.

4. Старайтесь оставлять строковые литералы целыми. Разбивайте их только если они превышают в длинну более 150 символов.

5. Если литералы содержат несколько строк, предпочитайте DSL-строки (<#...#>) или манки-строки (@"..."). Тоже самое касается строк содержащих символы '\\' и '"'. Старайтесь по возможности избегать эскеп-последовательностей. Например, для путей к файлам лучше использовать манки-строки, а для текста содержащего кавычки и концы строк — DSL-строки.

6. Оформление локальных переменных.
6.1. Если локальная переменная может быть не изменяемой, то ее нужно стараться сделать таковой (т.е. определять с помощью ключевого слова def, а не mutable).
6.2. Если вы инициализируете mutable начальное значение которой совпадает со значением для ее типа принятым по умолчанию, не указывайте начальное значение.

// Используйте:
mutable isOpen;
// вместо:
mutable isOpen = false;

6.3. Инициализацию переменной размещайте или на той же строке что ее объявление
def obj = if (meth.IsAbstract) <[ null : this ]> else <[ base ]>;
или оформляйте ее следующим образом:

def opcodes =
  match (opcode)
  {
    | "==.ref" | "=="   => (OpCodes.Bne_Un, OpCodes.Beq)
    | "!=.ref" | "!="   => (OpCodes.Beq,    OpCodes.Bne_Un)
    | "<.s"    | "<.f"  => (OpCodes.Bge,    OpCodes.Blt)
    | "<.u"             => (OpCodes.Bge_Un, OpCodes.Blt_Un)
    | ">.s"    | ">.f"  => (OpCodes.Ble,    OpCodes.Bgt)
    | ">.u"             => (OpCodes.Ble_Un, OpCodes.Bgt_Un)
    | "<=.s"   | "<=.f" => (OpCodes.Bgt,    OpCodes.Ble)
    | "<=.u"            => (OpCodes.Bgt_Un, OpCodes.Ble_Un)
    | ">=.s"   | ">=.f" => (OpCodes.Blt,    OpCodes.Bge)
    | ">=.u"            => (OpCodes.Blt_Un, OpCodes.Bge_Un)
    | "bool.!"          => (OpCodes.Brtrue, OpCodes.Brfalse)
    | _ => Util.ice($"invalid opcode '$opcode' in optimized TExpr.If pattern")
  };

Обратите внимание на то, что инициализирующее выражение ОТБИТО на один отступ внутрь, и на то, что оно ОБЯЗАТЕЛЬНО заканчивается точкой а запятой (хотя Nemerle позволяет этого не делать).
6.4. По возможности используйте табличное форматирование при объявлении группы переменных (как локальных, так и полей). Например:

    private         _methodName        : string;
    private mutable _debugSymbolWriter : ISymbolDocumentWriter;
    private mutable _isCtor            : bool;
    private mutable _isLambda          : bool;

7. Формление оператора match.
7.1. Скобки тела оператора match всегда ставятся с новой строки.
7.2. Содержимое тела оператора match отбивается на один отступ внутрь.
7.3. Если содержимое обработчика "=> ..." умещается на одной строке, то оно должно находиться на той же стоке где и оператор "=>", а содержимым не должно идти пустых строк.

  // Верно:
  match (opcode)
  {
    | "==.ref" | "=="   => (OpCodes.Bne_Un, OpCodes.Beq)
    | "!=.ref" | "!="   => (OpCodes.Beq,    OpCodes.Bne_Un)
    | "<.s"    | "<.f"  => (OpCodes.Bge,    OpCodes.Blt)
    | _ => Util.ice($"invalid opcode '$opcode' in optimized TExpr.If pattern")
  }

  // Не верно!:
  match (opcode)
  {
    | "==.ref" | "=="   => 
      (OpCodes.Bne_Un, OpCodes.Beq)
    | "!=.ref" | "!="   =>
    (OpCodes.Beq,    OpCodes.Bne_Un)
    | "<.s"    | "<.f"  => (OpCodes.Bge,    OpCodes.Blt)

    | _ => Util.ice ("invalid opcode '" + opcode +
                     "' in optimized TExpr.If pattern")
  }

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

    // Правильно:
    match (_ast)
    {
      | PT.TopDeclaration.VariantOption(members) =>
        unless (Util.is_capitalized(name))
          Message.Error(NameLocation, "variant options' names must start with capital letter");
      
        foreach (mem in members)
          unless (mem.Attributes %&& NemerleAttributes.AccessModifiers)
            mem.Attributes |= NemerleAttributes.Public; // пустая строка нужна!
        
      | PT.TopDeclaration.Variant =>  attributes |= NemerleAttributes.Abstract // пустая строка не нужна
      | PT.TopDeclaration.Enum when !this.typarms.IsEmpty =>
        Message.Error("enums cannot have generic type parameters"); // пустая строка не нужна!
    }

    // Не правильно!
    match (_ast)
    {
      | PT.TopDeclaration.VariantOption (members) =>
        unless (Util.is_capitalized (name))
          Message.Error(NameLocation, "variant options' names must start with capital letter");
      
        foreach (mem in members)
          unless (mem.Attributes %&& NemerleAttributes.AccessModifiers)
            mem.Attributes |= NemerleAttributes.Public; // нет пустой строки!
      | PT.TopDeclaration.Variant =>  attributes |= NemerleAttributes.Abstract // лишняя пустая строка!

      | PT.TopDeclaration.Enum when !this.typarms.IsEmpty =>
        Message.Error ("enums cannot have generic type parameters"); // нет пустой строки!
      | _ => () // лишняя пустая строка!

    }

7.5. В случае если это возможно применяйте табличное форматирование в операторе match:

            match (part)
            {
              | PT.TopDeclaration.Class    (typarms = t) => t
              | PT.TopDeclaration.Variant  (typarms = t) => t
              | PT.TopDeclaration.Interface(typarms = t) => t                
              | _                                        => Util.ice("non class / variant")
            }
...
match (topDecl)
{
  | PT.TopDeclaration.Class         => TypeDeclaration.Class()
  | PT.TopDeclaration.Alias(t)      =>
    match (this.tydecl)
    {
      | TypeDeclaration.Alias(null) =>
        def ttype = this.tenv.BindFixedType(this.GlobalEnv, this, t, check_parms = false);
        TypeDeclaration.Alias(ttype)

      | _ => Util.ice("The 'tydecl' field of alias must have TypeDeclaration.Alias(null) type.")
    }

  | PT.TopDeclaration.Interface     => TypeDeclaration.Interface()
  | PT.TopDeclaration.Enum          => TypeDeclaration.Enum()
  | PT.TopDeclaration.Variant       =>
    TypeDeclaration.Variant(variant_options.Map(fun (x : TypeBuilder) : TypeInfo { x }))

  | PT.TopDeclaration.VariantOption => TypeDeclaration.VariantOption()
  | PT.TopDeclaration.Delegate 
  | PT.TopDeclaration.Macro         => Util.ice("this top declaration shouldn't survive to typing")        
}

7.6. Если match применяется к значению вариантного типа или к перечислению, старайтесь не использовать символ заместитель "_" для обработки неиспользуемых значений. Лучше перечислить эти значения явно. Это заставит компилятор отслеживать недостающие значения и сообщать вам об этом.

// Правильно:
match (topDecl)
{
  | PT.TopDeclaration.Class         => TypeDeclaration.Class()
  | PT.TopDeclaration.Alias(t)      => convert(t)
  | PT.TopDeclaration.Interface     => TypeDeclaration.Interface()
  | PT.TopDeclaration.Enum          => TypeDeclaration.Enum()
  | PT.TopDeclaration.Variant       =>
    TypeDeclaration.Variant(variant_options.Map(fun (x : TypeBuilder) : TypeInfo { x }))

  | PT.TopDeclaration.VariantOption => TypeDeclaration.VariantOption()
  | PT.TopDeclaration.Delegate 
  | PT.TopDeclaration.Macro         => Util.ice("this top declaration shouldn't survive to typing")        
}

// Неправильно:
match (topDecl)
{
  | PT.TopDeclaration.Class         => TypeDeclaration.Class()
  | PT.TopDeclaration.Alias(t)      => convert(t)
  | PT.TopDeclaration.Interface     => TypeDeclaration.Interface()
  | PT.TopDeclaration.Enum          => TypeDeclaration.Enum()
  | PT.TopDeclaration.Variant       =>
    TypeDeclaration.Variant(variant_options.Map(fun (x : TypeBuilder) : TypeInfo { x }))

  | PT.TopDeclaration.VariantOption => TypeDeclaration.VariantOption()
  | _                               => Util.ice("this top declaration shouldn't survive to typing")        
}

7.7. Если оператор match имеет большие размеры в следствии того, что большие размеры у некоторых обработчиков, следует вынести обработчики в локальные функции или методы. Помните, что работать с большими операторами match крайне неудобно!

8. Локальные функции.
8.1. Старайтесь указывать типы параметров и возвращаемых значений у локальных функций. Это полезно сразу по двум причинам. Во-первых, тем самым вы упрощаете чтение кода (код не всегда читается в IDE), так как типы — это дополнительная документация. Во-вторых, тем самым вы облегчаете жизнь IDE и компилятору. При этом они будут работать быстрее и выдавать более точные сообщения об ошибках.
Не следует доводить выполнение этого пункта до маразма. Так что в каждом случае стоит подумать нужно ли указывать типы параметров и возвращаемого значения. Бывают простые случаи когда в этом нет смысла. Так же бывают случае кода информация о типах ухудшает читаемость кода, например, когда размеры типов очень большие. В таком случае возможно не задавать типы, задавать их частично, или объявить псевдонимы (алиасы) типов с помощью конструкции type или usung.
Так же можно задавать только часть структуры типов указывая вместо некоторых параметров типов постановочный символ "_". Например, вместо Hastable(SomeLongTypeName[OtherLongTypeName], string) указать Hastable(_, string). Помните, что даже частично заданные типы могут сделать код понятнее.
В общем, если вы видите, что тип может улучшить понятность кода, то не поленитесь и добавьте аннотацию типов.
Помните так же, что аннотации типов можно задавать и вне параметров (прямо в выражениях).

9. Точка с запятой.
Точку с запятой следует ставить там где требует компилятор, в конце инициализации переменных или за выражениями тип которых void.
Причем при инициализации переменных точка с запятой должна ставиться даже если компилятор этого не требует (когда выражение кончается на фигурную скобку), а в остальных случаях только если выражения не оканчиваются на закрывающую фигурную скобку.
Не ставьте точку с запятой в конце выражений которые являются листовыми (содержат возвращаемые из функции значения), если его тип не void.
Обратите внимание на то, что объявление локальных функций так же имеет тип мoid, так что не ставьте точку с запятой за ними.

// Правильно:
def sigMatches =
  (if (meth.Attributes %&& NemerleAttributes.Override)
    sub_current.Equals(meth.GetMemType())
  else
    (sub_current :> FixedType.Fun).from.Equals(meth.GetMemType().from))
  && m.GetParameters().Length == par_amount;

// Неправильно:
def sigMatches =
  (if (meth.Attributes %&& NemerleAttributes.Override)
    sub_current.Equals(meth.GetMemType());
  else
    (sub_current :> FixedType.Fun).from.Equals(meth.GetMemType().from))
  && m.GetParameters().Length == par_amount;

// Правильно:
def currentValue =
  match (value)
  {
    | Some(expr) => calculateEnumValue(expr, prevValue, resolvedValues)
    | None =>
      def lit = ConstantFolder.FoldLiterals(true, "+", prevValue, Literal.Integer(1, false, underlyingEnumType));
      Literal.Integer(lit.val, lit.isNegative, underlyingEnumType)
  };

// Неправильно:
def currentValue =
  match (value)
  {
    | Some(expr) => calculateEnumValue(expr, prevValue, resolvedValues)
    | None =>
      def lit = ConstantFolder.FoldLiterals(true, "+", prevValue, Literal.Integer(1, false, underlyingEnumType));
      Literal.Integer(lit.val, lit.isNegative, underlyingEnumType)
  }

// Правильно:
match (value)
{
  | 1 => "a"
  | _ => "b"
}

// Неправильно:
match (value)
{
  | 1 => "a"
  | _ => "b"
};

10. Пробелы. Для отбивки кода используется 2 пробела. Табуляции или отличное от двух пробелов недопустимо.

11. Указание типов. Ставьте по одному пробелу до и после двоеточия (если не применяется табличное форматирование). Если это возможно применяйте табличное форматирование.

// Неправильно:
def loop(i:int, k: int, z  :string)
{
  def a:int=i;
  def bbbb:int = i;
  ...
}

// Правильно:
def loop(i : int, k : int, z : string)
{
  def a    : int = i;
  def bbbb : int = i;
  ...
}

12. Оформление функций и свойств в одну строку.
Если тело функции или свойства (или его эксосора) настолько маленькое, что легко влезает в одну строку, то можно оставить выражение и все фигурные скобки на одной строке с определением функции/свойства/событий.
При этом обязательно от отбивайте тело функции/свойства/событий одним пробелом от фигурных скобок. Так же по одному проблему должно быть перед и после ключевых слов get/set/add/remove.

// Неправильно:
public SomeProperty : int { get{_someField+1}}
public SomeProperty : int { get{ _someField + 1 } }
public SomeProperty : int { get { _someField + 1 }}
public SomeProperty : int {get{ _someField + 1 } }
public SomeProperty : int {get{_someField + 1}}
// Правильно:
public SomeProperty : int { get { _someField + 1 } }

PS

Если в этом списке и в Соглашениях по оформлению кода команды RSDN отсутствуют правила для того или иного фрагмента кода, спрашивайте о том как его форматировать здесь (в ответ на это сообщение).

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

IT>К сожалению, разработчики Немерле любят пробелы больше, чем людей.

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

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

_>По поводу репозитария, может имеет смысл использовать codeplex.com (извините если это уже где то обсуждалось)?

Опять переезжать? Ну нафиг.

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

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

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

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

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

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

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

VD>И так, раз пошла такая пьянка сразу введем некоторые правила и ограничения. Данная тема посвящена им. Просьба не засирать ее не относящимся к делу. Один вопрос — одно подсообщение.

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

1. http://www.rsdn.ru/article/nemerle/Nemerle.VsIntegration-en.xml

Автор(ы): VladD2
Дата: 13.09.2003

Ссылка на svn ведет сюда: http://nemerle.org/svn/nemerle/trunk Попытайтесь ее открыть

2. Ладно, откроем главную страницу сайта, может там есть ссылки на svn?

Да, есть. Но она ведет не на svn, а http://groups.google.com/group/nemerle-svn
Да, где-то на странице есть ссылка на Downloads, которая ведет на однострочную страницу, на которой есть ссылка на code.google.com

3. Ладно, не хочу засорять этот топик, и хочу написать это в багтрекер. Так, у нас есть ссылка на багтрекер?

Да есть. Но она ведет не на багтрекер, а на http://groups.google.com/group/nemerle-bugs


Пока прыгал туда-сюда, наконец-то заметил маленькую фразу get the fresh source code directly from the repository со ссылкой на описание про репозиторий.



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ага, потом ктото подгонить для красоты выравнивание двоеточий табличное пробелами, а в тех у кого табы все поедет!

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

VD>И так, раз пошла такая пьянка сразу введем некоторые правила и ограничения. Данная тема посвящена им. Просьба не засирать ее не относящимся к делу. Один вопрос — одно подсообщение.

Работа с VCS. Предлагаю сделать так:
Любая фича делается в клоне или в локальном репо и пушится в центральный только на стадии какой-то готовности. Если разработчик не уверен в готовности фичи, он пушит ее в клон и задает вопрос на форуме. После одобрения пушит в центральный. Та же начальная структура папок вполне могла бы быть уже в клоне.

Совет начинающим по использованию tortoisehg — лучше сразу заменить в настройках его стандартный diff/merge tool на tortoisesvn.

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

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

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

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

А как же Золотая Середина Синклера, что табы набиваем в соответствии с логическими отступами, а пробелы — чтобы красиво было?

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

P>запускать всю студию под отладкой как-то не айс, а просмотр значений переменных с помощью Message.Hint напоминает эру динозавров, когда писал распределённые вычисления на С .

assert2(false) и ходи по макрам на здоровье. Я как правило в этом случае запускаю не студию, а CLR Debugger.

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

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

Я тоже предпочитаю явно задавать мутабельной переменной значение.

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

H>Я тоже предпочитаю явно задавать мутабельной переменной значение.
+1
Более того ИМХО со временем нужно будет прикрутить что-то типа type state для отслеживания "инициализированности" переменных.
Ибо Имею Мнение Хрен Оспоришь что значения по умолчанию зло.

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

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

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

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

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

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

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

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

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

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

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

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

BM>Ага, потом ктото подгонить для красоты выравнивание двоеточий табличное пробелами, а в тех у кого табы все поедет!

Табличное выравнивание только пробелами и делается. Табы сугубо для отступов. Если кто-то сделает иначе, всегда можно исправить и попросить больше так не делать. Сложно что ли?

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

IT>>Разработчика нет, а пробелы есть. Парадокс!
C>Почему же парадокс? Так сложилось исторически

В данном случае "сложилось исторически" звучит как "а нам пофиг, мы любим пробелы больше, чем людей".

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

IT>В данном случае "сложилось исторически" звучит как "а нам пофиг, мы любим пробелы больше, чем людей".

Совсем нет. Оно звучит как "мы любим хоть какие-то стандарты больше, чем никаких".

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

VD>И так, раз пошла такая пьянка сразу введем некоторые правила и ограничения. Данная тема посвящена им. Просьба не засирать ее не относящимся к делу. Один вопрос — одно подсообщение.

По поводу репозитария, может имеет смысл использовать codeplex.com (извините если это уже где то обсуждалось)?

Достоинства:

• Много .NET разроботчиков пасутся именно там, включая Microsoft.
  
• Возможность крутить рекламу в пользу проекта. Мелочь конечно, но приятно.

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

_>Достоинства:
_>

_>
• Много .NET разроботчиков пасутся именно там, включая Microsoft.
  _>
• Возможность крутить рекламу в пользу проекта. Мелочь конечно, но приятно.
  _>

Ну достоинства сомнительные... майкрософт как наложит лапу. А гугл хорошо функционирует.. и веб морда удобная.

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

_>>По поводу репозитария, может имеет смысл использовать codeplex.com (извините если это уже где то обсуждалось)?

Поддерживаю. Думаю добавится популярность. Хотя лично мне google code и subversion Очень удобны )

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

M>То есть общая идея такая: помимо того, что работа над N2 должна вестись в рамках ограничений и правил, описанных в этом топике. Но и сайт проекта — его документация, и все, что с ним связаны, должны не только постоянно соответствовать тому, что происходит в проекте и давать прямой доступ ко всей информации, а не через какие-то непонятные пути и тропки.

Полностью согласен. Прежде чем писать и переводить статьи, надо привести в порядок сайт. Лично я бы вообще сделал новый, простенький сайт и перенес туда самое важное. То, что команда в состоянии поддержать. Пора уже признать, что поддерживать то, что сейчас на nemerle.org мы не в состоянии, нужен либо глобальный "рефакторинг", либо переписывание с нуля.

M>>1. http://www.rsdn.ru/article/nemerle/Nemerle.VsIntegration-en.xml

Автор(ы): VladD2
Дата: 13.09.2003

M>>Ссылка на svn ведет сюда: http://nemerle.org/svn/nemerle/trunk Попытайтесь ее открыть

VD>Да, файл отстал от жизни. Я уже попросил его обновить.

Это решается rewrite'ом на сервере

M>>2. Ладно, откроем главную страницу сайта, может там есть ссылки на svn?

M>>Да, есть. Но она ведет не на svn, а http://groups.google.com/group/nemerle-svn

VD>Спасибо за замечание. Поправил.

M>>Да, где-то на странице есть ссылка на Downloads, которая ведет на однострочную страницу, на которой есть ссылка на code.google.com
VD>И что в этом плохого? На страницу Downloads есть много ссылок извне. Так что удалять ее нельзя. Но все загрузки теперь находятся на гуглакоде.

Опять же rewrite'ом можно сделать 301-й редирект на собственно страницу загрузок. Хотя, на самом деле ее надо объединить с Fetching Nemerle


M>>То есть общая идея такая: помимо того, что работа над N2 должна вестись в рамках ограничений и правил, описанных в этом топике. Но и сайт проекта — его документация, и все, что с ним связаны, должны не только постоянно соответствовать тому, что происходит в проекте и давать прямой доступ ко всей информации, а не через какие-то непонятные пути и тропки.

VD>Вообще-то проекты Nemerle и Nemerle 2 — это разные проекты. Замечания которые ты высказал верны и ценны, но все же они относятся к сайту посвященному Nemerle.

VD>В общем, выявленные проблемы постараемся в ближайшее время устранить.

Скажем так, так как N2 все равно появится, рано или поздно, то лучше учесть ошибки прошлого и не дать им повториться в будущем

И так, раз пошла такая пьянка сразу введем некоторые правила и ограничения. Данная тема посвящена им. Просьба не засирать ее не относящимся к делу. Один вопрос — одно подсообщение.

Ниже приведен список правил относящийся к структуре каталогов.

1. Каталоги создаются только в момент их непосредственного заполнения файлами. На всякий случай ничего не создаем.

2. Общая структура каталогов репозитория будет такова:

Boot
ExternalDependences 
Libraries
  Nemerle - стандартная библиотека
  PEG
  Linq
  другие библиотеки
Compiller
IDEs
  VS2010
  ShrapDevelop

3. Каждый солюшен входящий в репозиторий должен иметь следующую структуру:

ИмяПроека - Корневая папка
  Lib     - Каталог для библиотек (если нужно). Учтите, что это не внешние библиотеки!
  Macro   - Каталог макросов
  Gui     - Каталог для гуи-утилит
  Test    - Тесты решения (обязательно!)
  Друкие каталоги (если нужно)
  ИмяПроека.sln

4. Каждый класс, структуру или вариантный тип нужно в обязательном порядке помещать в отдельный файл. Связанные группы типов помещаются в подкаталоги.

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

Boot — это каталог содержащий набор файлов необходимый для начальной сборки проекта.

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

Так как какое-то (и довольно долгое) время компилятор не сможет собирать себя (да и вообще что-то) проект будет собираться наиболее свежей, доступной на сайте в виде инсталлятора версией Nemerle 1.0. Посему каталог Boot должен содержать файл Readme.txt в котором должен быть указан путь к инсталлятору и краткая инструкция по сборке проекта (если надо).

По поводу Boot-2.0, Boot-4.0 и т.п. Новый компилятор будет способен собирать сборки для любой версии дотнета (что будет определяться опциями компиляции). Посему нам не нужны Boot-ы подо всем поддерживаемые платформы.

Платформой на которой будет работать компилятор будет являться Microsoft Framework 4.0 и последняя версия Momo. При появлении более свежих рантаймов будем думать о миграции под них.

Пока что, в следствии того, что Nemerle 1.0 порождает сборки для Microsoft Framework 2+ платформой будет Microsoft Framework 3.5.

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

Z>Любая фича делается в клоне или в локальном репо и пушится в центральный только на стадии какой-то готовности. Если разработчик не уверен в готовности фичи, он пушит ее в клон и задает вопрос на форуме. После одобрения пушит в центральный. Та же начальная структура папок вполне могла бы быть уже в клоне.

Лично я никогда не работал с подобными системами, так если можно опиши процесс по подробнее.

Z>Совет начинающим по использованию tortoisehg — лучше сразу заменить в настройках его стандартный diff/merge tool на tortoisesvn.

Опять же по шагам, что как и зачем делать?

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

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

Z>>Любая фича делается в клоне или в локальном репо и пушится в центральный только на стадии какой-то готовности. Если разработчик не уверен в готовности фичи, он пушит ее в клон и задает вопрос на форуме. После одобрения пушит в центральный. Та же начальная структура папок вполне могла бы быть уже в клоне.

VD>Лично я никогда не работал с подобными системами, так если можно опиши процесс по подробнее.

Попробую.

У нас есть центральный репозитарий, назовем его M.
Для разработки необходимо сделать его локальный клон — L. В этом клоне мы можем делать сколько угодно комитов не трогая M. В это время кто-то делает изменения в M. По достижении готовности фичи, мы вытягиваем (pull) все изменения из M к себе и склеиваем две ветки разработки, свою и чужую локально (merge). После этого мы можем отправить все изменения (push) в M. Теперь M и L снова идентичны.

Еще есть возможность создать удаленный клон репозитария прямо на гуглкоде, назовем его C. Все то же самое, только его никто не трогает и мы можем пушить туда свои изменения хоть после каждого комита. По завершении фичи делаются все те же действия, только пуш делатся как в C так и в M. После такого пуша L, C, M — снова идентичны.

Вместо merge можно делать rebase, т.е. встроить свои изменения так, как будто все делалось в одной ветке, тогда не будет лишнего комита и граф ревизий будет выглядеть прямо. Но это опционально.

Z>>Совет начинающим по использованию tortoisehg — лучше сразу заменить в настройках его стандартный diff/merge tool на tortoisesvn.

VD>Опять же по шагам, что как и зачем делать?

Это просто задается в настройках tortoisehg, там комбобокс даст выбрать tortoisemerge если она установлена.

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

Самый удобный способ работы с tortoisehg — запустить hgtk log внутри репозитария. Оттуда можно сделать посмотреть историю, сделать комит, пуш, пул, мердж. Я просто в студии вывел на тулбар запуск hgtk log и hgtk commit в папке солюшена как внешние инструменты (external tools). Если интересно — опишу подробнее, когда буду под виндой. Теперь комичусь перед каждым рефакторингом в 5 сек, потом удобно посмотреть все что он затронул.

Еще одна типичная ошибка переходящих из свн. Не делайте hg pull (svn up) не закомитив локально свои правки. В принципе они смерджатся, но при кривом мердже вы можете что-то потерять. Смерджить эти изменения лучше имея две закомиченые ветки.

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

Z>У нас есть центральный репозитарий, назовем его M.
Z>Для разработки необходимо сделать его локальный клон — L. В этом клоне мы можем делать сколько угодно комитов не трогая M. В это время кто-то делает изменения в M. По достижении готовности фичи, мы вытягиваем (pull) все изменения из M к себе и склеиваем две ветки разработки, свою и чужую локально (merge). После этого мы можем отправить все изменения (push) в M. Теперь M и L снова идентичны.

Возможно все станет более понятно глядя на репо nrails

Я и Валера начали добавлять фичи основываясь на ревизии da7. Поскольку мои изменения были сделаны раньше и не перескались с чужими в M — я просто выложил их в M, hg push (svn commit). Валера уже не смог бы сделать push, т.к. в репозитарии появились бы две ветки растущие из da7 (это тоже реализуемо, но сейчас не об этом). Поэтому он сделал pull моей ветки и свел их, получив ревизию 2bb. Теперь у него в репозитарии осталась одна ветка и он смог сделать push всех своих изменений в M.

Сделал клон в котором закомитил свой обычный .hgignore (исключает из комита ненужные в репозитарии файлы) и файл со структурой каталогов.
Посмотри, если все нормально — залью в центральный.

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

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

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

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

    match (_ast)
    {
      | PT.TopDeclaration.VariantOption(members) =>
        {
          unless (Util.is_capitalized(name))
            Message.Error(NameLocation, "variant options' names must start with capital letter");
      
          foreach (mem in members)
            unless (mem.Attributes %&& NemerleAttributes.AccessModifiers)
              mem.Attributes |= NemerleAttributes.Public; // пустая строка нужна!
        }
      | PT.TopDeclaration.Variant =>  attributes |= NemerleAttributes.Abstract // пустая строка не нужна
      | PT.TopDeclaration.Enum when !this.typarms.IsEmpty =>
        Message.Error("enums cannot have generic type parameters"); // пустая строка не нужна!
   }

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

Z>Сделал клон в котором закомитил свой обычный .hgignore (исключает из комита ненужные в репозитарии файлы) и файл со структурой каталогов.
Z>Посмотри, если все нормально — залью в центральный.

Вроде все ОК. А что нужно сделать мне, чтобы слить эту версию с основной?

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

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

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

Репозиторий находится по адресу: http://code.google.com/p/nemerle-2/
В качестве клиента рекумендуется использовать TortoiseHg

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

P>использовать фигурные скобки для выделения операторов матча не разрешено?

Нет. Это только создает несколько лишних строк.

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

Z>>Сделал клон в котором закомитил свой обычный .hgignore (исключает из комита ненужные в репозитарии файлы) и файл со структурой каталогов.
Z>>Посмотри, если все нормально — залью в центральный.

VD>Вроде все ОК. А что нужно сделать мне, чтобы слить эту версию с основной?

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

ziaw@ziaw-desktop:~/dev$ hg clone https://ziminav-main.googlecode.com/hg/ ziminav  // берешь себе мой клон
requesting all changes                                                                                                                                                                                     
adding changesets                                                                                                                                                                                          
adding manifests                                                                                                                                                                                           
adding file changes                                                                                                                                                                                        
added 1 changesets with 2 changes to 2 files                                                                                                                                                               
updating to branch default                                                                                                                                                                                 
2 files updated, 0 files merged, 0 files removed, 0 files unresolved                                                                                                                                       
ziaw@ziaw-desktop:~/dev$ cd ziminav                                                                      // заходишь в папку
ziaw@ziaw-desktop:~/dev/ziminav$ hg push https://nemerle-2.googlecode.com/hg/        // делаешь пуш в центральный 
pushing to https://nemerle-2.googlecode.com/hg/                                                                                                                                                            
searching for changes                                                                                                                                                                                      
http authorization required                                                                                                                                                                                
realm: Google Code Mercurial Repository
user: ziminav@gmail.com                                                                                        // тут нужен пользователь с правом комита в nemerle-2
password: 
remote: Success.

Второй вариант, у тебя есть локальный репозитарий nemerle-2, в нем делаешь:

hg pull https://ziminav-main.googlecode.com/hg/
hg push

Тут предполагается, что в моем клоне уже все сведено к последней версии в репозитарии, иначе надо перед пушем сделать merge (hgtk log, выделить топ одной ветки потом в контекстном меню топа другой нажать merge).

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

VD>Предисловие. Стиль кодирования является весьма флэймовой темой. Прошу всех кто не согласен с изложенным ниже стилем быть конструктивными и понимать, что в этом вопросе не возможно достичь полного согласия и каждый должен пожертвовать своими привычками. Мы конечно будем рассматривать вопросы изменения стиля кодирования, если на то будут ощутимые (большинством) причины. Но до принятия общего решения по изменению стиля нужно строго придерживаться описанного ниже стиля.

VD>Так же заранее прошу прощения за узурпацию права по выработке стиля.

VD>Стиль кодирования проекта Nemerle 2

Вообще в опенсорс проектах обычно выделяются несколько самых простых правил для стиля и описываются в небольшом документе для всех (это выравнивание, именование, основные правила обрамляющих {}), это можно положить в Docs. Этого обычно достаточно, чтобы пофиксить баг и не превратить код в кашу.

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

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

C>А как же Золотая Середина Синклера, что табы набиваем в соответствии с логическими отступами, а пробелы — чтобы красиво было?

У всех золотых середин есть одна проблема. Их тяжело определять на практике.

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

WH>+1
WH>Но нужно сделать выбор.
WH>Предлагаю два пробела.

Как я уже сказал — мне по фигу. Если большинство за пробелы, то я к нему присоединюсь.

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

Z>Вообще в опенсорс проектах обычно выделяются несколько самых простых правил для стиля и описываются в небольшом документе для всех (это выравнивание, именование, основные правила обрамляющих {}), это можно положить в Docs. Этого обычно достаточно, чтобы пофиксить баг и не превратить код в кашу.

Z>Все остальное для внутреннего пользования командой разработки и достаточно ветки на этом форуме.

Я не очень понял смысл этого замечания. Зачем нам делать что-то тяп-ляп когда у нас есть полноценное описание?

Надо просто перевести указанный документ, внести в него описанные мной отклонения и выложить в вики проекта.

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

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

C>>А как же Золотая Середина Синклера, что табы набиваем в соответствии с логическими отступами, а пробелы — чтобы красиво было?

VD>У всех золотых середин есть одна проблема. Их тяжело определять на практике.

Да ладно, что там тяжелого, внутри каждого многострочного {} таб, а все остальное пробелами забивается...

Но мне как-то тоже все равно, так что куда большинство туда и я

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

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

Z>>>Сделал клон в котором закомитил свой обычный .hgignore (исключает из комита ненужные в репозитарии файлы) и файл со структурой каталогов.
Z>>>Посмотри, если все нормально — залью в центральный.

VD>>Вроде все ОК. А что нужно сделать мне, чтобы слить эту версию с основной?

Z>Да ничего, я сам залью. Но в принципе можешь и ты, требуются примерно такие действия:
...

Что-то многовато. А с помощью TortoiseHg это нельзя как-то упростить? Ведь это всего лишь слитие двух версий. В SVN как-то все было куда проще.

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


Z>Сделал клон в котором закомитил свой обычный .hgignore (исключает из комита ненужные в репозитарии файлы) и файл со структурой каталогов.
Z>Посмотри, если все нормально — залью в центральный.

Файл dirhier.txt переименуй в dir-structure.txt или dir-hierarchy.txt, а то две минуты втыкаешь что это за базворд.

И наверно Libraries нужно сократить до Libs. Сокращение вполне стандартное. А смотреть на трехкилометровые пути в логах компиляции лично мне не очень хочется.

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

C>Да ладно, что там тяжелого, внутри каждого многострочного {} таб, а все остальное пробелами забивается...

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

C>Но мне как-то тоже все равно, так что куда большинство туда и я

Ну, и мне тоже.

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

Z>>>>Сделал клон в котором закомитил свой обычный .hgignore (исключает из комита ненужные в репозитарии файлы) и файл со структурой каталогов.
Z>>>>Посмотри, если все нормально — залью в центральный.

VD>>>Вроде все ОК. А что нужно сделать мне, чтобы слить эту версию с основной?

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

VD>Что-то многовато. А с помощью TortoiseHg это нельзя как-то упростить? Ведь это всего лишь слитие двух версий. В SVN как-то все было куда проще.

Многовато три команды? Ты вывод со вводом не перепутал? Первый сценарий вообще для того, у кого локального репозитария нет.

Обычно это две три команды Залить к себе правки, сделать мердж и отправить в центральный сервер.

С помощью TortoiseHg — hgtk log, вставляем урл клона в строку адреса вверху, жмем pull, смотрим что залилось, нужен ли мердж, меняем в адресе репо на default, жмем пуш. Кликов 10 без конфликтов наверное, это много?
SVN такая легкость не снилась даже.

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

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

VD>Файл dirhier.txt переименуй в dir-structure.txt или dir-hierarchy.txt, а то две минуты втыкаешь что это за базворд.

Переименовал в DirHierarchy.txt, по аналогии с ExternalDependencies

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

Z>>Вообще в опенсорс проектах обычно выделяются несколько самых простых правил для стиля и описываются в небольшом документе для всех (это выравнивание, именование, основные правила обрамляющих {}), это можно положить в Docs. Этого обычно достаточно, чтобы пофиксить баг и не превратить код в кашу.

Z>>Все остальное для внутреннего пользования командой разработки и достаточно ветки на этом форуме.

VD>Я не очень понял смысл этого замечания. Зачем нам делать что-то тяп-ляп когда у нас есть полноценное описание?

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

VD>Надо просто перевести указанный документ, внести в него описанные мной отклонения и выложить в вики проекта.

Да я не против. Просто должен быть и краткий вариант в HowToContribute.txt, в котором можно сделать ссылку на полный. Когда таковая появится.

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

Z>Многовато три команды? Ты вывод со вводом не перепутал? Первый сценарий вообще для того, у кого локального репозитария нет.

Ага, многовато. Пол экрана кода. В СВН чтобы мэнджуть брэнч нужно всего одну команду выполнить в тортиле.

Z>Обычно это две три команды Залить к себе правки, сделать мердж и отправить в центральный сервер.

Странно, что они не сделали отдельную команду прямо на гуглькоде.

Z>Клоны с которыми ты работаешь запоминаются в настройках репозитария и обмен с ними происходит так же легко как и с центральным репо.

Попробовал... вроде даже получилось что-то. Но как-то СВН сильно привычнее (от чего сильно проще).

Что ты имешь в виду под окном "log"? я такого не нашел.

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

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

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

Z>>Многовато три команды? Ты вывод со вводом не перепутал? Первый сценарий вообще для того, у кого локального репозитария нет.

VD>Ага, многовато. Пол экрана кода. В СВН чтобы мэнджуть брэнч нужно всего одну команду выполнить в тортиле.

Ну, это ж консольный вариант... в TortoiseHG тоже просто.

VD>Попробовал... вроде даже получилось что-то. Но как-то СВН сильно привычнее (от чего сильно проще).

Это да...

VD>Что ты имешь в виду под окном "log"? я такого не нашел.

Repository Explorer в контекстном меню.. вызывается консольной командой hgtk log (кому как удобней).

VD>В ТорлилаСВН есть очень удобное окно комита. В нем выводится список изменных и новых файлов и предоставляется возможность посмотреть див в человеческом виде. Как это же сделать в ТорлилаХг?

Да так же, при комите. Только в Hg комиты локальные, поэтому для публикации изменений нужен еще один шаг — пуш на гугловый репозиторий.

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

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

Стандарты нужны чтобы в них тыкать носом. А так конечно обычно люди просто смотрят на то, как пишут другие и делают так же. Но вот когда возникает необходимость попрвить человека, то проще сказать — смотри пункт x.y.

VD>>Надо просто перевести указанный документ, внести в него описанные мной отклонения и выложить в вики проекта.

Z>Да я не против. Просто должен быть и краткий вариант в HowToContribute.txt, в котором можно сделать ссылку на полный. Когда таковая появится.

Краткий — это бесполезно. По нему все будут лепить что хотят. Нюансов очень много.

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

Z>Переименовал в DirHierarchy.txt, по аналогии с ExternalDependencies

Вижу. А вот в проекты ты зря ExternalDependencies вставил. Все зависимости должны лежать в одном месте. Иначе потом задница будет. Потому в корне каталог и сделан. Я убрал это дело и сделал комит в основную копию.

ЗЫ

Пока-что есть ощущения неудобства. Будем надеяться, что это пройдет по мере привыкания и изучения Меркурия.

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

Z>>Многовато три команды? Ты вывод со вводом не перепутал? Первый сценарий вообще для того, у кого локального репозитария нет.

VD>Ага, многовато. Пол экрана кода.

Код это вывод hg, сами команды там предельно простые, это то, что находится между $ и //. Я просто все сделал у себя так, как будто у меня нет никакого репо и скопировал содержимое консоли.

VD>В СВН чтобы мэнджуть брэнч нужно всего одну команду выполнить в тортиле.

В hgtk тоже одна визуальная команда, удобнее svn тем, что в ней ты визуально видишь ветки которые конкретно мерджишь.
Еще две команды нужны чтобы взять бранч из клона и отправить полученные изменения в центр.

VD>Странно, что они не сделали отдельную команду прямо на гуглькоде.

Не стали заморачиваться, в общем случае там вероятен merge да еще и с конфликтами, веб интрефейс для всего этого дело муторное.

VD>Попробовал... вроде даже получилось что-то. Но как-то СВН сильно привычнее (от чего сильно проще).

Обычное дело для большинства переходящих, привыкнешь. Есть конечно на первый взгляд лишние движения (push & pull) но потом понимаешь, что без них еще хуже.

VD>Что ты имешь в виду под окном "log"? я такого не нашел.

hgtk log или Repositary explorer, я обычно даже в комит через него хожу, ибо иногда комичу несколько изменений несколькими комитами.

VD>В ТорлилаСВН есть очень удобное окно комита. В нем выводится список изменных и новых файлов и предоставляется возможность посмотреть див в человеческом виде. Как это же сделать в ТорлилаХг?

hgtk commit или комит в контекстном меню.

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

из мелочей: иметь возможность проходить отладчиком по коду макросов.

запускать всю студию под отладкой как-то не айс, а просмотр значений переменных с помощью Message.Hint напоминает эру динозавров, когда писал распределённые вычисления на С .

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

P>из мелочей: иметь возможность проходить отладчиком по коду макросов.

P>запускать всю студию под отладкой как-то не айс, а просмотр значений переменных с помощью Message.Hint напоминает эру динозавров, когда писал распределённые вычисления на С .

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

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

Z>>Переименовал в DirHierarchy.txt, по аналогии с ExternalDependencies

VD>Вижу. А вот в проекты ты зря ExternalDependencies вставил. Все зависимости должны лежать в одном месте. Иначе потом задница будет. Потому в корне каталог и сделан. Я убрал это дело и сделал комит в основную копию.

Ты прав, я переборщил, этож не снипеты. Там опечатка, i пропущена, ExternalDependencies.

VD>Пока-что есть ощущения неудобства. Будем надеяться, что это пройдет по мере привыкания и изучения Меркурия.

Все еще хуже, не только пройдет, а еще и от svn станет ломать. Я сейчас ощущаю дискомофорт, деля один репозитарий с другими людьми.

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

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

P>>использовать фигурные скобки для выделения операторов матча не разрешено?

VD>Нет. Это только создает несколько лишних строк.

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

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

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

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

да, да, без этого педалить даже начинать не надо особо...

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

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

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

В прочем, в данном случае ты наверно в чем-то прав. Есть как минимум один случай когда начальное значение указывается всегда — это цикл for. Там это часть паттерна.

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

H>>Я тоже предпочитаю явно задавать мутабельной переменной значение.
WH>+1
WH>Более того ИМХО со временем нужно будет прикрутить что-то типа type state для отслеживания "инициализированности" переменных.
WH>Ибо Имею Мнение Хрен Оспоришь что значения по умолчанию зло.

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

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

VD>Это не только не нужно, но и невозможно в ряде случаев.
На счет невозможности я бы поспорил но мне лень.

VD>Например, при автоматической инициализации структуры.
А это очередная глупость мелкомягких.

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

VD>>Это не только не нужно, но и невозможно в ряде случаев.
WH>На счет невозможности я бы поспорил но мне лень.

А я бы не стал.

VD>>Например, при автоматической инициализации структуры.
WH>А это очередная глупость мелкомягких.

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

У меня следующие вопросы:

1. Версия компилятора — откуда и какую версию брать
   
2. Среда разработки — можно ли использовать Nemerle Studio ( не хотелось бы устанавливать VS2008)
   
3. Дополнительные инструменты — какие дополнительные инструменты нужны? Например, нужен ли, Visual Studio SDK?

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

_E_>

Версия компилятора — откуда и какую версию брать

Польемся последним (самым свежим) инсталлятором. Брать здесь:
http://code.google.com/p/nemerle/downloads/list

Так же можно пользоваться собранным из исходников (trunk).

_E_>

Среда разработки — можно ли использовать Nemerle Studio ( не хотелось бы устанавливать VS2008)

Можно.

_E_>

Дополнительные инструменты — какие дополнительные инструменты нужны? Например, нужен ли, Visual Studio SDK?

Нет. По крайней мере пока нет интеграции.

Из дополнительных инструментов может потребоваться NUnit и клиент к Меркури.

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

_E_>

Дополнительные инструменты — какие дополнительные инструменты нужны? Например, нужен ли, Visual Studio SDK?

Конечно же еще нужно скачать установить и скомпилировать ту нижележащую библиотеку работы с метаданными на основе которой будет создаваться реализация (т.е. CCI Metadata, AbsIL из F# или Mono Cecil). Предпочтительнее использовать первые две. Для сборки AbsIL потребуется F# причем, так как пока что разработка будет идти под дотнет 3.5, то и компилятор шарпа нужен будет соответствующий.

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

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

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

VD>Конечно же еще нужно скачать установить и скомпилировать ту нижележащую библиотеку работы с метаданными на основе которой будет создаваться реализация (т.е. CCI Metadata, AbsIL из F# или Mono Cecil). Предпочтительнее использовать первые две. Для сборки AbsIL потребуется F# причем, так как пока что разработка будет идти под дотнет 3.5, то и компилятор шарпа нужен будет соответствующий.

Ок, понятно.

Я буду разбираться с CCI.

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

H>Я тоже использовал когда-то 4 пробела. 2 удобнее — немерловый код имеет свойство быстро "уезжать" вправо.

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

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

VD>>Из дополнительных инструментов может потребоваться NUnit и клиент к Меркури.
WH>А NUnit точно нужен?

Пока компилятор нельзя будет тестировать как старый (спец.утилитой) его отдельные блоки надо чем-то тестировать. NUnit — это то что нужно. Старый компилятор его содержал в ExternalDependences.

WH>Ибо тестировать компилятор гораздо проще печатью результатов на консоль.

А он есть — это компилятор то? У нас пока что будет только набор классов которые будут читать метаданные. Вот их умения и надо будет тестировать.

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

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

_E_>Я буду разбираться с CCI.

Давай. Сразу провентилируй возмоности работы с разными рантаймами (компиляции под разные рантаймы). Нас интересуют 2.0, 4.0, CF, Сервилат, WP7.

По мере возможностей я буду описывать требуемые интерфейсы в подветках этой ветки

Автор: VladD2
Дата: 27.12.10

.

Вопросы и предложения можно задавать или сюда, или по Скайпу. Мой логин там VladD2.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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, Вы писали:

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

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

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

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

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

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

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

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

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

А из Тортилы это как сделать?

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

Ну, он пустой пока. Так что тормозить не должно.

Можно конкретную ссылку на место где бэту брать?

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

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

Действительно, удобно сделали.

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

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

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

Во, я тут тему создавал, но никто не понял что я спрашивал. На что конкретно синтаксис шарпа не расчитан?

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

S>Честно говоря боюсь рекоменловать эту бету, тем более VisualHG с ней не работает. Обещают, что проект зарелизится в марте и заменит собой текущую тортилу. Правда месяц назад датой релиза разработчики называли декабрь этого года )))

Вероятно дело в том, что там hgtk.exe заменили на thg.exe, я просто скопировал thg.exe в hgtk.exe, заработало.

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

Z>Во, я тут тему создавал, но никто не понял что я спрашивал. На что конкретно синтаксис шарпа не расчитан?

На расширяемость. Есть деление на выражения и стэйтменты. Грамматика не однозначна и для разрешения неоднозначностей используются не очевидные эвристики. Погляди на предикаты в грамматике шарпа. Большая их част — это обход неоднозначностей.

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

VD>На расширяемость. Есть деление на выражения и стэйтменты. Грамматика не однозначна и для разрешения неоднозначностей используются не очевидные эвристики. Погляди на предикаты в грамматике шарпа. Большая их част — это обход неоднозначностей.

А можно подробнее? Не вижу кардинальных отличий между "выражением" foreach в nemerle и стейтментом foreach в C#.

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

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

Z>Действительно, удобно сделали.

Можно ставить? Или лучше подождать релиза?

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

Z>А можно подробнее? Не вижу кардинальных отличий между "выражением" foreach в nemerle и стейтментом foreach в C#.

Это долгая история. Но если тебе хочется немного порвать мозг, то вот забавный пример:

  Main() : void
  {
    def x = foreach (y in [1]) WriteLine(y);
    x
  }

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

Z>А можно подробнее?

Стейтмент — это частный случай выражения, это выражение, которое вычисляет void, полезное лишь за счет своих "побочных эффектов". А раз так, то нам в языке стейтменты не нужны — мы выразим их через выражения.

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

VD>Но если тебе хочется немного порвать мозг, то вот забавный пример:
VD>

VD>  Main() : void
VD>  {
VD>    def x = foreach (y in [1]) WriteLine(y);
VD>    x
VD>  }
VD>

А что тут забавного? foreach сразу выводит "1" и следующее выражение ничего не делает.

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

DR>А что тут забавного? foreach сразу выводит "1" и следующее выражение ничего не делает.

Возможность создать переменную типа void и присвоить ей значение выражения "цикл".

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

Z>>А можно подробнее?

H>Стейтмент — это частный случай выражения, это выражение, которое вычисляет void, полезное лишь за счет своих "побочных эффектов". А раз так, то нам в языке стейтменты не нужны — мы выразим их через выражения.

Ну так в нашем надмножестве C# стейтменты будут выражениями В том то и фича, что нужен C# со всеми возможностями nemerle, в том числе и "все есть выражение". Мне кажется могут быть проблемы с синтаксисом указания типов, но не могу сообразить в чем конкретно.

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

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

Z>>Действительно, удобно сделали.

VD>Можно ставить? Или лучше подождать релиза?

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

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

VD>Из дополнительных инструментов может потребоваться NUnit и клиент к Меркури.

Как лучше организовать работу с NUnit:

1. Где нужно размещать тесты в самом проекте или отдельный проект для тестов?
   
2. Если отдельный проект, то как его называть: "ИмяПроекта_Test" подойдет ?
   
3. Если отдельный проект, то где его располагать? рядом с основным проектом?
   
4. Какую версию NUnit использовать? Последнюю?
   
5. Все проекты должны использовать одну и ту же библиотеку NUnit?

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

_E_>Как лучше организовать работу с NUnit:

_E_>* Где нужно размещать тесты в самом проекте или отдельный проект для тестов?

В отдельном проекте.

_E_>* Если отдельный проект, то как его называть: "ИмяПроекта_Test" подойдет ?

Test и разместить в поддиректории основного проекта.

_E_>* Какую версию NUnit использовать? Последнюю?

Последнею, что есть у них на сейте. Положи нужные сборки (nunit.core.dll, nunit.core.interfaces.dll, nunit.framework.dll, nunit.util.dll, nunit-console-runner.dll, nunit-console.exe) в ExternalDependencies (как в прошлом проекте).

_E_>* Все проекты должны использовать одну и ту же библиотеку NUnit?

См. выше.

ЗЫ

Главное был бы код, а уж все остальное переименуем и передвинем, если что.

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

Z>Самый удобный способ работы с tortoisehg — запустить hgtk log внутри репозитария. Оттуда можно сделать посмотреть историю, сделать комит, пуш, пул, мердж. Я просто в студии вывел на тулбар запуск hgtk log и hgtk commit в папке солюшена как внешние инструменты (external tools). Если интересно — опишу подробнее, когда буду под виндой. Теперь комичусь перед каждым рефакторингом в 5 сек, потом удобно посмотреть все что он затронул.

Помоему самый удобный способ работать из студии с tortoisehg: VisualHG

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

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

Z>У студии есть один неприятный момент, изменения в csproj она хранит в памяти до одного ей известного момента, поэтому желательно проверять, ушел ли этот csproj в комит.

Ctrl+Shift+S aka. Save All

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

вот создал я свой клон основного репозитория, а как теперь в него залить изменения из основного репо ? Что то я не вижу соответствующей кнопки в админке

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

J>вот создал я свой клон основного репозитория, а как теперь в него залить изменения из основного репо ? Что то я не вижу соответствующей кнопки в админке
Вытягиваешь изменения из основного или любого другого репозитория себе локально после чего заливаешь в свой клон.
Так сделано по тому что в общем случае придется мержить.

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

VD>Что-то многовато. А с помощью TortoiseHg это нельзя как-то упростить? Ведь это всего лишь слитие двух версий. В SVN как-то все было куда проще.

На репозитории Syncronize (ну как обычно) там вместо адреса основного репозитория вводиться адрес клона и делаеться Pull потом адресменяеться на обычный. А дальше смерджыть и сделать Push

Собственно тоже ~3 действия, но не с консоли.

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

VD>Польемся последним (самым свежим) инсталлятором. Брать здесь:
VD>http://code.google.com/p/nemerle/downloads/list

VD>Так же можно пользоваться собранным из исходников (trunk).

Боюсь, что не все что будет собираться самым свежим компилятором собереться той версией, что на странице скачивания бинарников.

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

BM>Боюсь, что не все что будет собираться самым свежим компилятором собереться той версией, что на странице скачивания бинарников.

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

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

WH>Предлагаю два пробела.

Худший из возможных вариантов.

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

WH>>Предлагаю два пробела.

IT>Худший из возможных вариантов.

Я так не считаю.

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

И еще одно. Если выбирать табуляции, то на них нужно переводить и Nemerle 1.х, так как студия не поддерживает разные настройки для разных проектов на одном языке.

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

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

BM>Ага, потом ктото подгонить для красоты выравнивание двоеточий табличное пробелами, а в тех у кого табы все поедет!

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

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

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

Создал и потихонечку стал наполнять вики:
http://code.google.com/p/nemerle-2/wiki/TableOfContents

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

VD>10. Пробелы. Для отбивки кода используется 2 пробела. Табуляции или отличное от двух пробелов недопустимо.

Не передумали ещё на табы перейти?

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

VD>>10. Пробелы. Для отбивки кода используется 2 пробела. Табуляции или отличное от двух пробелов недопустимо.

IT>Не передумали ещё на табы перейти?

Что ты мне отвечаешь? Я же тебе сказал, что мне по фигу.

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

Создай новую тему. Уговаривай людей.

Я буду на твой стороне. Единственное мое требование — это перевод на табы как 2.0, так и всех проектов 1.0.

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

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

VD>>10. Пробелы. Для отбивки кода используется 2 пробела. Табуляции или отличное от двух пробелов недопустимо.

IT>Не передумали ещё на табы перейти?

Я в таком случае за индент

А можно ли сделать изменение отображение в зависимости от настроек в студио... например при одном варианте 2 пробела, а при другом скобки...

отображение одного и того же исходника.

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

IT>Не передумали ещё на табы перейти?

+1 , Я за табы. 2 пробела мне совсем не нравятся, мне привычнее 4, а табуляцию может каждый настроить по настроению.

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

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

IT>>>Не передумали ещё на табы перейти?
C>>+1 , Я за табы. 2 пробела мне совсем не нравятся, мне привычнее 4, а табуляцию может каждый настроить по настроению.

IT>К сожалению, разработчики Немерле любят пробелы больше, чем людей.

Для начала как-то бы сделать, чтобы в интеграцию и Nemerle Studio отбивались табы, а не 4 пробела.
Ну и настройку таба под 2 пробела.

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

IT>К сожалению, разработчики Немерле любят пробелы больше, чем людей.

Готов встать на твою сторону, если ты примкнешь к команде Н2.

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

__>Для начала как-то бы сделать, чтобы в интеграцию и Nemerle Studio отбивались табы, а не 4 пробела.
__>Ну и настройку таба под 2 пробела.

А что переключение в настройках сломалось?