Здравствуйте, Ziaw, Вы писали:
C>>Раньше я юзал Scite (где-то в svn есть раскраска кода немерле под скайт) и самодельную билд-программу, которая просто принимала аргументы от скайта, и передавала их немерлу. Но она канула в лету Z>Лучше всего было бы портировать интеграцию шарпдевелопа на монодевелоп. Они вроде из одного корня растут, но модель уже поменялась неслабо. Но если нет желания использовать IDE, этот рецепт не подойдет.
Когда МоноДевелоп отпочковался от #D, модель расширения у #D была сильно другой. А сейчас так вообще МоноДевелоп производит впечатление чего-то совсем более другого, чем #D.
Здравствуйте, catbert, Вы писали:
C>Что посоветуете использовать, если нет возможности (и желания) использовать IDE для разработки на Немерле? Под Виндоус или под Линуксом.
В Виме просто набираю программу, говорю :make, нажимаю F5 — и она запускается. Для более сложных проектов использую MSBuild.
C>Удобно ли работать вручную с MsBuild и немерле?
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Да, и получилось бы кривое и страшное приложение. ВВ>А сейчас по крайней мере есть вполне приличный МоноДевелоп.
Да он и есть кривой и страшный.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Что посоветуете использовать, если нет возможности (и желания) использовать IDE для разработки на Немерле? Под Виндоус или под Линуксом.
Раньше я юзал Scite (где-то в svn есть раскраска кода немерле под скайт) и самодельную билд-программу, которая просто принимала аргументы от скайта, и передавала их немерлу. Но она канула в лету
Удобно ли работать вручную с MsBuild и немерле? Стоит ли использовать make под линуксом?
Здравствуйте, catbert, Вы писали:
C>Что посоветуете использовать, если нет возможности (и желания) использовать IDE для разработки на Немерле? Под Виндоус или под Линуксом.
C>Раньше я юзал Scite (где-то в svn есть раскраска кода немерле под скайт) и самодельную билд-программу, которая просто принимала аргументы от скайта, и передавала их немерлу. Но она канула в лету
Лучше всего было бы портировать интеграцию шарпдевелопа на монодевелоп. Они вроде из одного корня растут, но модель уже поменялась неслабо. Но если нет желания использовать IDE, этот рецепт не подойдет.
C>Удобно ли работать вручную с MsBuild и немерле? Стоит ли использовать make под линуксом?
make точно не стоит. Под моно есть XBuild который справляется с большинством проектов для msbuild. А так, не вижу проблемы в использовании вручную, по идее для большинства проектов можно использовать один и тот же nproj, указав файлы по маске <Compile Include="*.n" />.
Здравствуйте, catbert, Вы писали:
C>Раньше я юзал Scite (где-то в svn есть раскраска кода немерле под скайт) и самодельную билд-программу, которая просто принимала аргументы от скайта, и передавала их немерлу. Но она канула в лету C>Удобно ли работать вручную с MsBuild и немерле? Стоит ли использовать make под линуксом?
А какие вообще требования к такому редактору? Если просто синтаксис раскрашивать и билд-пакет запускать, то, наверное, большинство даже не самых хитрых блокнотиков подойдет. Под виндой это м.б. Programmers Notepad или Notepad++.
В любом случае, скажем так, без интеграции "проекта" с т.з. редактора и билд-пакета, получится, наверное, не очень удобно. Но это все-таки смотря что за проекты, что должно происходить при билде и пр. Если просто собрать файлики из одной папки, то тут и MSBuild-то особо не нужен.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Когда МоноДевелоп отпочковался от #D, модель расширения у #D была сильно другой. А сейчас так вообще МоноДевелоп производит впечатление чего-то совсем более другого, чем #D.
Меня другое удивляет. А почему нельзя собрать SharpDevelop под Mono/(Linux/MacOS)? Он же вроде весь из себя на шарпе написан.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, catbert, Вы писали:
C>Что посоветуете использовать, если нет возможности (и желания) использовать IDE для разработки на Немерле? Под Виндоус или под Линуксом.
MsBuild — можно....
MsBuild имеет клон XBuild (что ли?) под Линкусом. Только вот, как многое другое, XBuild сильно убог и не все из MsBuild поддерживает. Так что имеет смысл сразу создавать тестировать проекты в обоих окружениях.
C>Удобно ли работать вручную с MsBuild и немерле? Стоит ли использовать make под линуксом?
Компилятор и интеграция им и собираются. Только вот MsBuild-проект — это и есть проект VS. Так что не ясно зачем при этом от студии отказываться то?
Ты в курсе, что есть излоэйтед-шел. Совершенно бесплатная вещь. Качаешь... ставишь... ставиль немерл поверх и получаешь практически полноценную VS без малейших угрызений совести по поводу использования не лицензионного софта.
А работать без IDE — это не очень разумно. Трата времени в пустую.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>Когда МоноДевелоп отпочковался от #D, модель расширения у #D была сильно другой. А сейчас так вообще МоноДевелоп производит впечатление чего-то совсем более другого, чем #D.
VD>Меня другое удивляет. А почему нельзя собрать SharpDevelop под Mono/(Linux/MacOS)? Он же вроде весь из себя на шарпе написан.
Он под WinForms. А WinForms на линуксе страшноват и глючит.
Поэтому, собственно, и решили написать MonoDevelop. Но автор MonoDevelop хотел сделать все получше, и в результате MonoDevelop довольно сильно отличается от #Develop.
Что в MonoDevelop лучше, чем в #D — более гибкая система подсветки синтаксиса, которая (теоретически) позволяет подключать чужие парсеры, в том числе Nemerle.
Здравствуйте, catbert, Вы писали:
C>Он под WinForms. А WinForms на линуксе страшноват и глючит.
Насколько я знаю они воспроизведены и не плохо работают. Для IDE много не надо. Могли бы уж потрудиться.
C>Поэтому, собственно, и решили написать MonoDevelop. Но автор MonoDevelop хотел сделать все получше, и в результате MonoDevelop довольно сильно отличается от #Develop.
Это был не верный шаг. Или уж если писать "лучше", то опять же делать версию которая будет одновременно собираться и на Моно и на дотнете.
C>Что в MonoDevelop лучше, чем в #D — более гибкая система подсветки синтаксиса, которая (теоретически) позволяет подключать чужие парсеры, в том числе Nemerle.
Вообще, когда я пытался в нем разораться он был копией #Develop и оба они были кривы до нельзя. Правад Хардкейс что-то там изобразил на #Develop, так что может они допили что или я плохо разобрался.
Мои ощущения, что время затрачиваемое на трах с их убогими API лучше потратить на создание своей IDE. Если взять за основу имеющийся редактор кода (хотя бы от того же #Develop-а), то это окажется куда быстрее.
Немерлу не подходят "стандартные" подходы которые навязывают #Develop и MonoDevelop. В студии все проще. "Стандартный подход" реализован в библиотеке которую можно послать далеко и на долго. А сама студия имеет серьезную компонентную архитектуру. 2010-я так вообще очень грамотно сделана. Особенно в области работы с редактором. В области редактор задел сделан на много лет вперед. Современные интеграции и 20% фишек не используют.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, catbert, Вы писали:
VD>>А работать без IDE — это не очень разумно. Трата времени в пустую.
C>Памяти не хватает на IDE
Серьезно? В наше время трудно купить плитку памяти?
C>Ну и я заметил, что работать без IDE привыкаешь. И заодно лучше усваиваются API. Нельзя прямо сказать, что это трата времени.
Это чушь. Сам не мало работаю без IDE, но только сильнее понимаю, что трачу море времени впустую. Чем дольше компилируется проект, тем больше нужна IDE.
Если бы в ней еще были рефакторинги как в Решарпере...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Насколько я знаю они воспроизведены и не плохо работают. Для IDE много не надо. Могли бы уж потрудиться.
Надо-надо. И редактор, и панельки чтоб работали и не глючили... Короче, мои впечатления таковы что WinForms не готов для мало-мальски серьезного использования.
VD>Это был не верный шаг. Или уж если писать "лучше", то опять же делать версию которая будет одновременно собираться и на Моно и на дотнете.
+1. хотя монодевелоп на дотнете/виндах работает.
VD>Вообще, когда я пытался в нем разораться он был копией #Develop и оба они были кривы до нельзя. Правад Хардкейс что-то там изобразил на #Develop, так что может они допили что или я плохо разобрался.
ну, они кривые, но монодевелоп лучше
VD>Мои ощущения, что время затрачиваемое на трах с их убогими API лучше потратить на создание своей IDE. Если взять за основу имеющийся редактор кода (хотя бы от того же #Develop-а), то это окажется куда быстрее.
мне тоже так кажется. хотя объем работы немаленький.
Здравствуйте, VladD2, Вы писали:
VD>Это чушь. Сам не мало работаю без IDE, но только сильнее понимаю, что трачу море времени впустую. Чем дольше компилируется проект, тем больше нужна IDE.
Здравствуйте, catbert, Вы писали:
VD>>Насколько я знаю они воспроизведены и не плохо работают. Для IDE много не надо. Могли бы уж потрудиться.
C>Надо-надо. И редактор, и панельки чтоб работали и не глючили...
Редактору по фигу что у него там под за либа в основе. Ему кроме скролбаров и отлова ввода пользователия ничего не надо. Ну, разве что отрисовка на экране. Редактор как раз и есть контрол.
С тулбарами тоже самое. Можно было бы их на коленке за неделю написать. Лично я бы обошелся даже без визультного расширения. Только бы IDE пахало на разных платформах.
Вот Эклпис же пашет.
C>Короче, мои впечатления таковы что WinForms не готов для мало-мальски серьезного использования.
Я видел рабочие примеры. Еще раз повторюсь, что для IDE особых наворотов не нужно.
C>+1. хотя монодевелоп на дотнете/виндах работает.
Значит надо было под него интеграцию Хардкейсу и делать.
C>мне тоже так кажется. хотя объем работы немаленький.
Не больше чем трах с невразумительным АПИ при полном отсутствии документации.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Немерлу не подходят "стандартные" подходы которые навязывают #Develop и MonoDevelop. В студии все проще. "Стандартный подход" реализован в библиотеке которую можно послать далеко и на долго. А сама студия имеет серьезную компонентную архитектуру. 2010-я так вообще очень грамотно сделана. Особенно в области работы с редактором. В области редактор задел сделан на много лет вперед. Современные интеграции и 20% фишек не используют.
Своя IDE это конечно круто, но что делать с солюшенами в которых используется не только nemerle?
Здравствуйте, Ziaw, Вы писали:
Z>Своя IDE это конечно круто, но что делать с солюшенами в которых используется не только nemerle?
Лучше что-то. Чем ничего. Сейчас под Линуксом и МакОСью нет ничего, если не считать текстовых редакторов.
Z>MD&SD тоже имеют компонентную архитектуру. При этом MD прекрасно работает в винде и линкусе, так что интеграция для него покроет кучу потребностей. Для него кто-то даже когда-то писал расширение: https://github.com/mono/monodevelop/tree/master/extras/NemerleBinding
Ну, займись.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
ВВ>>Когда МоноДевелоп отпочковался от #D, модель расширения у #D была сильно другой. А сейчас так вообще МоноДевелоп производит впечатление чего-то совсем более другого, чем #D.
VD>Меня другое удивляет. А почему нельзя собрать SharpDevelop под Mono/(Linux/MacOS)? Он же вроде весь из себя на шарпе написан.
Не знаю как сейчас, но раньше там использовалась библиотечка для докинга окон http://sourceforge.net/projects/dockpanelsuite/ Она сильно завязана на winapi. А редактор у них вполне себе кроссплатформенный.
Здравствуйте, VladD2, Вы писали:
ВВ>>Когда МоноДевелоп отпочковался от #D, модель расширения у #D была сильно другой. А сейчас так вообще МоноДевелоп производит впечатление чего-то совсем более другого, чем #D. VD>Меня другое удивляет. А почему нельзя собрать SharpDevelop под Mono/(Linux/MacOS)? Он же вроде весь из себя на шарпе написан.
Собрать может и можно, но толку? Он на вин-формс. Более того, часть его ГУЯ вроде доканутых окошек, весьма активно налегает на вин-апи.
Здравствуйте, Ziaw, Вы писали:
Z>MD&SD тоже имеют компонентную архитектуру. При этом MD прекрасно работает в винде и линкусе, так что интеграция для него покроет кучу потребностей. Для него кто-то даже когда-то писал расширение: https://github.com/mono/monodevelop/tree/master/extras/NemerleBinding
[Ide] Improve dialog for adding external files to a folder
slluis (author)
about 7 hours ago
Здравствуйте, nCdy, Вы писали:
Z>>Для него кто-то даже когда-то писал расширение: https://github.com/mono/monodevelop/tree/master/extras/NemerleBinding
C>[Ide] Improve dialog for adding external files to a folder C>slluis (author) C>about 7 hours ago
C>И кстати пишет C>Это очень здорово !
Здравствуйте, catbert, Вы писали:
C>Что посоветуете использовать, если нет возможности (и желания) использовать IDE для разработки на Немерле? Под Виндоус или под Линуксом.
Здравствуйте, VladD2, Вы писали:
VD>Значит надо было под него интеграцию Хардкейсу и делать.
Надобыло, но тогда (год назад) MD был ещё сильно унылым, и к тому же я только разбирался с API компилятора. Опять же SD я делал фактически "под себя" — сейчас в ней занимаюсь разработкой компилятора.
В принципе сделать с нуля аддин вполне реально занедолго. MD как и SD тесно умеют работать с msbuild/xbuild и имеют вменяемый API проектов (не то что VS с её COM-ами), основной проблемой SD является совершенно синхронный текстовый редактор и механизмов автокомплита, как в MD — не знаю, возможно такая же ерунда, раз автор тот же.
Здравствуйте, VladD2, Вы писали:
C>>Он под WinForms. А WinForms на линуксе страшноват и глючит. VD>Насколько я знаю они воспроизведены и не плохо работают. Для IDE много не надо. Могли бы уж потрудиться.
Они плохо работают.
C>>Поэтому, собственно, и решили написать MonoDevelop. Но автор MonoDevelop хотел сделать все получше, и в результате MonoDevelop довольно сильно отличается от #Develop. VD>Это был не верный шаг. Или уж если писать "лучше", то опять же делать версию которая будет одновременно собираться и на Моно и на дотнете.
Да, и получилось бы кривое и страшное приложение.
А сейчас по крайней мере есть вполне приличный МоноДевелоп.
Здравствуйте, hardcase, Вы писали: H>Здравствуйте, VladD2, Вы писали:
VD>>Значит надо было под него интеграцию Хардкейсу и делать. H>Надобыло, но тогда (год назад) MD был ещё сильно унылым, и к тому же я только разбирался с API компилятора.
Здравствуйте, catbert, Вы писали: C>Здравствуйте, VladD2, Вы писали:
C>Он под WinForms. А WinForms на линуксе страшноват и глючит.
SD4 использует AvalonEdit — WPF'ный компонент (и эта одна из главных причин, по которой отвалилась интеграция с SD3, AFAIK). А на моно с впф все очень и очень плохо.
Здравствуйте, hardcase, Вы писали:
H>основной проблемой SD является совершенно синхронный текстовый редактор и механизмов автокомплита, как в MD — не знаю, возможно такая же ерунда, раз автор тот же.
Ага. АПИ редактора там совсем убогий. И что самое противное что до него еще добраться надо. Они по умолчанию предлагают "почти готовое решение для языков типа C#". А это решение с Nemerle никак не сочетается. Я даже не нашел способа обойти его.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ziaw, Вы писали:
Z>Не знаю как сейчас, но раньше там использовалась библиотечка для докинга окон http://sourceforge.net/projects/dockpanelsuite/ Она сильно завязана на winapi. А редактор у них вполне себе кроссплатформенный.
Я уже тут рядом отвечал, что такие вещи нормальные люди убирают в базовые библиотеки. Докинг — это на 99% расчеты. Весь доступ к АПИ можно вынести и реализовать для каждой ОС отдельно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
H>>основной проблемой SD является совершенно синхронный текстовый редактор и механизмов автокомплита, как в MD — не знаю, возможно такая же ерунда, раз автор тот же.
VD>Ага. АПИ редактора там совсем убогий. И что самое противное что до него еще добраться надо. Они по умолчанию предлагают "почти готовое решение для языков типа C#". А это решение с Nemerle никак не сочетается. Я даже не нашел способа обойти его.
Это ты сейчас по SD или MD? Это реально уже очень разные продукты с разными моделями расширения.
