Здравствуйте, V.Petrovski, Вы писали:
VP>CVS/SVN, Форум
SVN и форум, предоставляется RSDN для проектов.
VP>Solution
В смысле?
VP>Лицензия
Хороший, даже очень хороший вопрос. Надо подумать.
Итак, я думаю никто не возражает против open-source'сности проекта Так же я думаю никто не будет возражать против того чтобы выбрать из существующих лицензий, а не придумывать новую. Выбор в таком случае велик http://www.opensource.org/licenses/
Здравствуйте, adontz, Вы писали:
VP>>CVS/SVN, Форум A>SVN и форум, предоставляется RSDN для проектов.
ОК, если это так.
VP>>Solution A>В смысле?
Под этим словом я подрозумевал:
1. Задачи который будет решать этот проект.
2. Что должно получиться в итоге.
3. Из каких частей, проектов будет состоять решение.
4. Распеделить задачи между участниками.
A>Хороший, даже очень хороший вопрос. Надо подумать. A>Итак, я думаю никто не возражает против open-source'сности проекта
Я не против.
A> Так же я думаю никто не будет возражать против того чтобы выбрать из существующих лицензий, а не придумывать новую. Выбор в таком случае велик A>http://www.opensource.org/licenses/
Надо читать.
Здравствуйте, V.Petrovski, Вы писали:
VP>1. Задачи который будет решать этот проект. VP>2. Что должно получиться в итоге. VP>3. Из каких частей, проектов будет состоять решение. VP>4. Распеделить задачи между участниками.
Здравствуйте, V.Petrovski, Вы писали:
VP>Здравствуйте, AndrewVK, Вы писали:
AVK>>А ты готов писать этот проект на Nemerle? VP>Я не ткаой фанат как Влад, писать R# на R#
Я вообще не фанат. Но только так можно увидить слабые и сильные стороны того что делашь. Немерле, кстати, тоже сам на себе делается.
VP>И моё мнение, что лучше писать на C# 2.0 под VS2005.
Как язык C# рядом с Немерлом и рядом не волялся. Но в интеграции со студией язык думаю будет не главным. К тому же было бы хоть что-то. А там переписать на более мощьном языке будет не сложно. Так что если начать можно и на C#. А там видно будет.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Транслирую свой ответ по почте, чтобы все были вкурсе:
> У меня появилась несколько идей касательно VSIP. > 1. Давайте сперва напишем некоторую базу. проект который содержит > файлы, позволяет их добавлять переименовывать, удалять, редактировать, > показывать контекстное меню и проч.
Начинать с чего-то надо, так что перечисленное конечно нужно делать.
> Никакой компиляции и отладки.
Немного не ясно почему? Тем более, что это уже сделано у Nemerle-овцев. Да и компиляция точно идет через msbuild, и реализовать файл проекта в этом формате не сложно (в общем-то он уже есть).
> Собственно это у > меня уже почти есть
Так закладывай в SVN.
> 2. Добавим к этому контроль версий... > 3. Язык. Я думал над возможностью проекта для языка Nemerle... и > вспомнил, что уже давно люди хотели многоязыковые проекты... > 4. Front End'ы... > ...А тут мы можем предоставить генератору не просто этот XML, но и все > настройки проекта и данные об уже скомпилированном коде. Для тех же > DSL-писателей какое-то подспорье наверное.
Я боюсь... нет я уверен, что если попытаться объять необъятное, то ничего не выйдет. Думаю, тебе самому не приятно будет делать проект вероятность доведения которого до завершения ничтожно мала. Хватит нам уже бэнчей.
Надо быть реалистом. Я сам романтик и с удовольствием мечтаю о крутых свершениях, но больше всего в жизни я не люблю проигрывать. Так что участвовать в заведомо нереальном проекте я не хочу.
Так что, если делать, то нужно выставить приоритеты так, чтобы польза от проекта была как можно раньше.
Итак, начнем по пунктам.
П.2 — контроль версий. Реально в нем нет никакой необходимости. Просто никакой. SVN прекрасно используется с любым проектом и без какой бы то нибыло интеграции. Так что ставим этому пункту наинизший приоритет.
П.3 — многоязыковые проекты. Для начала нужно сделать хотя бы поддержку одного языка. Замахиваясь на большее мы рискуем профукать все. К тому же особых проблем создать многоязыковый проект нет. Проблема в том, чтобы собрать конечный модуль из исподников на разных языках. А это уже скорее к компилятору. Единственное, что приходит в голову — это воспользоваться разными утилитами для сливания исходников, но это можно делать и сейчас. В общем опять таки этот пункт нужно отложить до лучших времен.
П.4 — фронтэнды и генераторы. Не сделав ни одной интеграции в студию делать супер обобщенные решения крайне неразумно. Так что предлагаю сначала сосредоточиться на интеграции одного Nemerle, а уже потом обобщить опыт и сделать реализацию более универсальной.
В общем, предлагаю отбросить супер-планы и настроиться на интеграцию со студией одного языка. Если мы сделаем это качественно, то потом можно будет улучшить то что получилось. Но главное... главное, то что мы и так сдеаем очень важное дело за которое нам будут благодарны очень и очень многие.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Немного не ясно почему? Тем более, что это уже сделано у Nemerle-овцев. Да и компиляция точно идет через msbuild, и реализовать файл проекта в этом формате не сложно (в общем-то он уже есть).
В смысле мы пока сделаем не проект для Nemerle, а просто проект состоящий из файлов. Нужно будет писать другие проекты — возьмёшь этот код за основу. Не то чтобы никакой компиляцуии и отладки, скорее ничего специфичного для конкретного языка.
Что касается MSBuild. Я думал об этом, но... насколько это нас устраивает проект в формате MSBuild? Можно туда запихать элементы (файлы, например) зависимости между элементами и что дальше? Насколько этот формат расширяемый? Пример из SDK использует именно этот формат, но проекты из самой VS использут свои форматы. Причём по сравнению со студией 7.1 они поменялись без обратной совместимости, так что кажется MSBuild не очень удобен для серьёзных вещей. И вообще зачем нам компилировать через MSBuild? Импорт/экспорт в этот формат ещё ясно, а зачем нам внутри через него работать? И собственно не понятно почему импорт/экспорт сделать для MSBuild и не сделать для того же NAnt? Вобщем проблемы работать напрямую (вызывать EXE файл компилятора) я не вижу никакой, а вот какие преимущества мы получим работая через MSBuild?
VD>П.2 — контроль версий. Реально в нем нет никакой необходимости. Просто никакой. SVN прекрасно используется с любым проектом и без какой бы то нибыло интеграции. Так что ставим этому пункту наинизший приоритет.
Согласен. Я так и написал "Это не объязательно делать срочно, достаточно просто оставить лазейки."
VD>П.3 — многоязыковые проекты. Для начала нужно сделать хотя бы поддержку одного языка. Замахиваясь на большее мы рискуем профукать все. К тому же особых проблем создать многоязыковый проект нет. Проблема в том, чтобы собрать конечный модуль из исподников на разных языках. А это уже скорее к компилятору. Единственное, что приходит в голову — это воспользоваться разными утилитами для сливания исходников, но это можно делать и сейчас. В общем опять таки этот пункт нужно отложить до лучших времен.
Хм... то есть например собрать CS и VB файл в один DLL файл проблематично? Если да (нет обобщённых средств), то многоязычные проекты идут лесом.
VD>П.4 — фронтэнды и генераторы. Не сделав ни одной интеграции в студию делать супер обобщенные решения крайне неразумно. Так что предлагаю сначала сосредоточиться на интеграции одного Nemerle, а уже потом обобщить опыт и сделать реализацию более универсальной.
Тут очень простая схема. Есть файл с исходником и компилятор. Мы вызываем его как
compiler.exe source.lang
Я предлагаю добавить возможность передавать содержимое source.lang некоторому внешнему модулю, а то что он вернёт и отдавать компилятору.
compiler.exe source.lang.processed
Очень обобщённая схема. Совершенно не срочная, как и контроль версий, главное оставить лазейку.
A>В смысле мы пока сделаем не проект для Nemerle, а просто проект состоящий из файлов. Нужно будет писать другие проекты — возьмёшь этот код за основу. Не то чтобы никакой компиляцуии и отладки, скорее ничего специфичного для конкретного языка.
Зачем нам "просто проект"? Сферокони нас не интересуют. В проекте должны быть именно немерел. Его файл по умолчанию. Его визарды...
A>Что касается MSBuild. Я думал об этом, но... насколько это нас устраивает проект в формате MSBuild?
На 100%.
A> Можно туда запихать элементы (файлы, например) зависимости между элементами и что дальше?
Естественно.
A>Насколько этот формат расширяемый?
На 100%.
A> Пример из SDK использует именно этот формат, но проекты из самой VS использут свои форматы.
Не правда. Все проекты кроме С++ — это МСБилд-файлы.
A> Причём по сравнению со студией 7.1 они поменялись без обратной совместимости, так что кажется MSBuild не очень удобен для серьёзных вещей.
A> И вообще зачем нам компилировать через MSBuild?
Чтобы не изобретать велосипеды.
A> Импорт/экспорт в этот формат ещё ясно, а зачем нам внутри через него работать?
См. выше. И вообще это не обсуждается. Это стндарт Студии.
A> И собственно не понятно почему импорт/экспорт сделать для MSBuild и не сделать для того же NAnt?
Думаю прокатят импорты для Шарпового проекта (которые уже есть).
A> Вобщем проблемы работать напрямую (вызывать EXE файл компилятора) я не вижу никакой, а вот какие преимущества мы получим работая через MSBuild?
Компиляция из командной строки и при отсуствии студии.
A>Согласен. Я так и написал "Это не объязательно делать срочно, достаточно просто оставить лазейки."
ОК
VD>>П.3 — многоязыковые проекты. Для начала нужно сделать хотя бы поддержку одного языка. Замахиваясь на большее мы рискуем профукать все. К тому же особых проблем создать многоязыковый проект нет. Проблема в том, чтобы собрать конечный модуль из исподников на разных языках. А это уже скорее к компилятору. Единственное, что приходит в голову — это воспользоваться разными утилитами для сливания исходников, но это можно делать и сейчас. В общем опять таки этот пункт нужно отложить до лучших времен.
A>Хм... то есть например собрать CS и VB файл в один DLL файл проблематично?
Ага.
A> Если да (нет обобщённых средств), то многоязычные проекты идут лесом.\
Вот и я о том. Самый разумный вариант который я вижу — это конвертация. Из C# в немерле конвертировать можно. А вот из ВБ...
A>Тут очень простая схема. Есть файл с исходником и компилятор. Мы вызываем его как A>compiler.exe source.lang
И что толку?
A>Я предлагаю добавить возможность передавать содержимое source.lang некоторому внешнему модулю, а то что он вернёт и отдавать компилятору.
Здравствуйте, adontz, Вы писали:
A>Повторное использование кода. Сегодня Nemerle, завтра ещё что-то...
Такое ощущение, что языки как грибы рождаются. Зная как интегрировать один язык втрой пойдет уже как по маслу. Тогда можно будет сделать и обобщенное решение. А до первого языка делать обобщенное решение неразумно. Ведь не ясно что обобщать.
Так что надо сделать Немерле. А там уже думатьэ.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>>Для хитрой компиляции ничего придумывать не надо. Все украдено до нас.
A>Это через файлы, что не может не сказаться на производительности. К тому же нет доступа до многих данных, которых просто не существует в файлах.
Ты статью прочти, а там поговорим.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
A>>Это через файлы, что не может не сказаться на производительности. К тому же нет доступа до многих данных, которых просто не существует в файлах. VD>Ты статью прочти, а там поговорим.
Так, вот тебе реальный пример.
Есть исходник вида
#beginregion Symbol List Generation
char[] symbolList = {
<%
for (int index = 0; index < 255; ++index)
{
Response.Write("{0}, ", index);
}
%>
};
#endregion
Отдаётся это Си++ компилятору Регионы чисто для красоты, поэтому для начала выкинем их (первый FrontEnd). В целях оптимизации регионы не вырезаются, а заменяются на комметарии. Тогда не надо сдвигать то что за ними.
/*--------------------------*/
char[] symbolList = {
<%
for (int index = 0; index < 255; ++index)
{
Response.Write("{0}, ", index);
}
%>
};
/*------*/
кроме того, у нас ещё есть код для шаблона на основе ASP.Net. Обработаем и его (второй FrontEnd)
/*--------------------------*/
char[] symbolList = {
0, 1, 2, /* немного сократил, а то 255 большое число */ 253, 254, 255,
};
/*------*/
Здравствуйте, VladD2, Вы писали:
VD>Такое ощущение, что языки как грибы рождаются.
А зачем им рождаться? Они и так есть, просто не интегрированы. Может я хочу PHP тот же или Ruby Языков как раз пруд пруди, а диалектов ещё больше. Почему бы не добавить GNU C++ Compiler к студии? Тут как раз за базовый шаблон скажут в конечном итоге гораздо большее спасибо, чем за проект но для какого-то одного языка.
VD>Зная как интегрировать один язык втрой пойдет уже как по маслу. Тогда можно будет сделать и обобщенное решение. А до первого языка делать обобщенное решение неразумно. Ведь не ясно что обобщать.
Почему не ясно? Просто для некоторых вещей функциональность будет разделена на базовый класс и наследник от него. Добавляя новую функциональност ты задумаешься специфична ли эта функциональность для Nemerle? Если да, то добавляй её в наследника, если нет, то в базовый класс. Например показывать контекстное меню ты будешь в базовом классе, но выбирать какие именно пункты показать в наследнике. Очень просто, не вижу проблем.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, V.Petrovski, Вы писали:
VP>>Здравствуйте, AndrewVK, Вы писали:
VD>Я вообще не фанат. Но только так можно увидить слабые и сильные стороны того что делашь. Немерле, кстати, тоже сам на себе делается.
Вот именно, мы ведь не Nemerle разрабатяваем.
VD>Как язык C# рядом с Немерлом и рядом не волялся. Но в интеграции со студией язык думаю будет не главным. К тому же было бы хоть что-то. А там переписать на более мощьном языке будет не сложно. Так что если начать можно и на C#. А там видно будет.
ОН конечно мощнее C#, но я так понимаю что релиза еще нет?
И для разработки одного языка мало, надо еще среда. Если бы это было не так, этот бы проект не начался.
А я уже привык к ReSharper
Здравствуйте, V.Petrovski, Вы писали:
VP>ОН конечно мощнее C#, но я так понимаю что релиза еще нет? VP>И для разработки одного языка мало, надо еще среда. Если бы это было не так, этот бы проект не начался. VP>А я уже привык к ReSharper
Решарпер макросов и паттерн-матчинга не заменит.
Среда это конечно аргумент. Но он вот как раз и должен кончиться как только заработает этот проект. После этого смысла писать на C# не останетсчя вовсе.
Боюсь вообще с C# бдут проблемы и на 100% без Немрла вообще не обойтись. Дело в том, что компилятор Немерла во всю испоьзует варианты и списки. В C# они выглядят ужасно громоздко, а использовать их из C# будет крайне затруднительно (хотя и можно).
Как минимум прийдется создать еще один проект (переходник).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, adontz, Вы писали:
A>А зачем им рождаться? Они и так есть, просто не интегрированы. Может я хочу PHP тот же или Ruby
Хватит IronPyton-а и Boo. Для них и так пришлось вывод типов делать. До немерли они конечно не дотягивают, но Руби с ПХП отдыхают по полной программе. Ведь для комплита нужно знать типы. В скриптовых языках их можно только попробовать вычислить, как в Немереле. Вот только Немерле проектировался в рассчете на вывод типов, а Руби и ПХП напичканы фичами усложняющими процесс. Ну, а без этого полноценный коплит невозможен. А что толку просто с подсветки синтаксиса?
A> Языков как раз пруд пруди, а диалектов ещё больше.
Для большинсва интеграция уже есть.
A> Почему бы не добавить GNU C++ Compiler к студии?
Потому что он и так без проблем может использоваться. Там толко компилятор заменить и все. А это работа на 3 дня. Создавать интеграцию чере ВСИП для этого точно не нужно. Да и смысл нулевой. VC ничем не хуже.
A> Тут как раз за базовый шаблон скажут в конечном итоге гораздо большее спасибо, чем за проект но для какого-то одного языка.
Никто тебе зе абстрактные недоделки ничего хорошего не скажет.
И вообще, делать бобщенную и универсальную реализацию не сделав ни одной конкретной просто смешно. Это 100%-ый способ завалить проект.
VD>>Зная как интегрировать один язык втрой пойдет уже как по маслу. Тогда можно будет сделать и обобщенное решение. А до первого языка делать обобщенное решение неразумно. Ведь не ясно что обобщать.
A>Почему не ясно?
Ну, вот ты, например, не знашь даже что такое МСБилд и с чем его едять. Уже навострил лыжи отказаться от него. Меж тем на лицо банальное незнание и как следствие велосипидизм.
A> Просто для некоторых вещей функциональность будет разделена на базовый класс и наследник от него.
А где ее делить то? Ты ведь ни разу задачу не решал. И в целом ее не представляешь как решать. Ты сейчас исследователь. Твоя задача познать как работает Студия. При таком расскладе ты максимум сделашь специализированное решение. А вот когда оно будет готово, то можно покумекать как его обобщить.
A> Добавляя новую функциональност ты задумаешься специфична ли эта функциональность для Nemerle? Если да, то добавляй её в наследника, если нет, то в базовый класс. Например показывать контекстное меню ты будешь в базовом классе, но выбирать какие именно пункты показать в наследнике. Очень просто, не вижу проблем.
Nemerle хотя бы на C# похож. И у него есть готовые КодДом-провайдеры, парсеры, лексеры... А для какого нить Руби этого всего не будет. И вообще там особенностей хватает. Максимум что можно придумать, то некий шаблон с универсальным реплэйсом. Но для этого нужно сначала получить хотя бы одну работающую реализацию в которой ты будешь понимать что твориться.
В общем, делать первую версию универсальной считаю неразумным. Надо получить хотя бы какой-то прототип, а уже там думать можно ли его обобщить. Иначе все затянется и так и кончитсвя ни чем.
Более того я поглядел IronPyton и прихожу к выводу, что видимо проще сделать проект для Немерла на его базе. Убрать все лишнее... Заменить по контексту... И потихоничку набить фукнционалом. Это мозволит получить рабочую версию в ближайшее время (недели две). Ну, а там видно будет.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Так же я думаю никто не будет возражать против того чтобы выбрать из существующих лицензий, а не придумывать новую. Выбор в таком случае велик
Регионы чисто для красоты, поэтому для начала выкинем их (первый FrontEnd). В целях оптимизации регионы не вырезаются, а заменяются на комметарии. Тогда не надо сдвигать то что за ними.
