Здравствуйте, Ziaw, Вы писали: Z>Проблема в стейтлесс природе веба. На десктопе мы можем держать дерево, занимаясь перепарсиванием мелких кусков. В вебе придется либо делать огромную сессию и поднимать ее по запросу. Либо отправлять на сервер весь код и парсить тоже все. Первый вариант накроется на сотне пользователей, второй подходит только для туториалов.
Стейтлесс нас в этом случае не интересует. Никто не мешает тебе запустить некоторый компонент на ApplicationStart, а потом подкармливать его данными время от времени и получать результат. Так что если сервер позволяет запустить у себя 50 сессий парсинга, то нет разницы, работаешь ли ты с ним через десктоп клиент или веб морду.
Ну и как уже сказал Nikov, эта штука нужна только для того, чтобы пощупать возможности платформы. Так что большое количество одновременных пользователей на самом деле и не нужно.
Здравствуйте, ionoy, Вы писали:
I>Стейтлесс нас в этом случае не интересует. Никто не мешает тебе запустить некоторый компонент на ApplicationStart, а потом подкармливать его данными время от времени и получать результат. Так что если сервер позволяет запустить у себя 50 сессий парсинга, то нет разницы, работаешь ли ты с ним через десктоп клиент или веб морду. I>Ну и как уже сказал Nikov, эта штука нужна только для того, чтобы пощупать возможности платформы. Так что большое количество одновременных пользователей на самом деле и не нужно.
В теории можно, на практике придется бороться с ASP.NET который может выгрузить приложение на любой чих. Я бы не стал идти против веб идеологии. Можно спрятать эти сессии в отдельный сервис. Победить проблему можно, но конструкция будет не простая, по сути будет инстанс движка с загруженным туда проектом на каждого пользователя. Для тестов и туториалов сойдет.
Здравствуйте, Ziaw, Вы писали:
Z>В теории можно, на практике придется бороться с ASP.NET который может выгрузить приложение на любой чих.
Ну, не на любой чих. IIS не станет просто так перезаргужать appdomain, если правильно настроен recycling.
Иначе in-memory сессии вообще не имели бы никакой ценности.
Z>Для тестов и туториалов сойдет.
Именно для них и нужно. Чтобы каждый прохожий мог потыкаться пальцем, посмотреть примеры и увидеть результат вживую. Если при этом будет рабочий интеллисенс, то возрастёт вероятность того, что человек заинтересуется.
Немного про dsl
Людям понадобилось писать на шарпе для вычислений в кластере
Ладно, сделали фреймворк
А потом написали на яве транслятор из их расширенной версии языка в обычный C#
А потом вообще свою версию компилятора C# (с их расширениями movable/async) (parallelcsharp.com)
Это же убиться током — проделать всю работу по разработке компилятора с нуля
На немерле к фреймворку для вычислений в кластере пришлось бы написать всего несколько макросов
по типу тех что реализуют функционал и Cw (Comega)
Недавно познакомился с JetBrains MPS.
Поработав в нем, я понял насколько это круто — получить такую свободу языка, что можешь сам контролировать синтаксис вплоть до точек, запятых и отступов. При том, что твой только что описанный синтаксис тут же проявляет себя еще и в автокомплите. Это то, что называют Killer Feature.
Но ориентированность на Java и невозможность использовать визуальный редактор кода в своих приложениях огорчает.
Поэтому хотел сказать спасибо, что развиваете эту идею в .Net, заодно хотел предложить мысль о том, что хорошо бы, если бы редактор H2 кода не был бы завязан на Visual Studio и была бы возможность использовать редактор DSL в своих приложениях.
Здравствуйте, shakirov.ruslan, Вы писали:
SR>Но ориентированность на Java и невозможность использовать визуальный редактор кода в своих приложениях огорчает.
Меня там гораздо больше не это огорчает.
Ибо все, что они сделали это редактор.
А типизацию нужно писать руками.
SR>Поэтому хотел сказать спасибо, что развиваете эту идею в .Net, заодно хотел предложить мысль о том, что хорошо бы, если бы редактор H2 кода не был бы завязан на Visual Studio и
Никогда не будет. Я гарантирую это.
SR>была бы возможность использовать редактор DSL в своих приложениях.
Это будет обязательно.
2Влад можешь спорить сколько угодно, но это очень востребовано. Да ты и сам поймешь со временем.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, shakirov.ruslan, Вы писали:
SR>И забыл еще сказать, что хорошо бы, чтобы AST написанной программы где-то можно было перехватить в чистом виде. SR>В целом, хочется получить язык, на котором можно будет быстро написать компилятор или интерпретатор для DSL текущего проекта.
Так для этого все и делается.
Более того можно будет перехватить не просто дерево разбора, а типизированное дерево разбора. Это гораздо круче. Уж поверь тому, кто на этом собаку съел.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
SR>>была бы возможность использовать редактор DSL в своих приложениях. WH>Это будет обязательно.
WH>2Влад можешь спорить сколько угодно, но это очень востребовано. Да ты и сам поймешь со временем.
Я как бы не против полезных перспектив. Только нужно понимать, что это дополнительный объем работ. Редактор — это в общем-
то фигня. Но там ведь не только редактор, но и управление проектами.
АПИ 100 пудов будет независимым и его можно будет использовать откуда угодно. Сделать свою маленькую ИДЕ тоже можно, но на
это нужны ресурсы.
Если удастся перевести проект в коммерческое русло или найти спонсоров, то не вопрос. Иначе на эту задачу нужны внешние
разработчики. Ну, или пострадают другие части.
Меж тем возможность открыть проект во внешней бесплатной ИДЕ удовлетворит 99%.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Я как бы не против полезных перспектив. Только нужно понимать, что это дополнительный объем работ. Редактор — это в общем-
VD>то фигня. Но там ведь не только редактор, но и управление проектами.
Зачем проекты? Зачем иде? Достаточно редактора с примитивной отладкой, компилятора и возможно автокомплита. Если можно компилировать в память подгружая к работающему проекту то более чем достаточно. Тут область использования как раз не бесплатная ид а встраиваемая среда доработки. Если я правильно понял.
Здравствуйте, shakirov.ruslan, Вы писали:
SR>Поэтому хотел сказать спасибо, что развиваете эту идею в .Net, заодно хотел предложить мысль о том, что хорошо бы, если бы редактор H2 кода не был бы завязан на Visual Studio и была бы возможность использовать редактор DSL в своих приложениях.
Есть Visual Studio Isolated Shell, которую можно со своими приложениями таскать. Тяжеловата, правда, но все же.
Здравствуйте, Аноним, Вы писали:
А>Зачем проекты? Зачем иде?
Затем что в общем случае все это нужно.
А>Достаточно редактора с примитивной отладкой,
Примитивная отладка — это хорошая шутка. Отладка — это такая не хилая задача для компилируемого языка. Тут уж точно проще открыть полноценный отладчик и получить все преимущества отладки, а не пытаться соорудить свой самопал.
Сделать простенький редактор для частных случаев не проблема. Основной движок к ИДЕ привязан не будет. Так что можно используя его и готовые компоненты вроде редактора кода для создания своего интерфейса. Комплит и т.п. будет делаться в пару строк кода.
А>компилятора и возможно автокомплита. Если можно компилировать в память подгружая к работающему проекту то более чем достаточно.
В рамках дотнета или явы конечно можно. В прочем и с диска разница бдуте не большая.
А>Тут область использования как раз не бесплатная ид а встраиваемая среда доработки. Если я правильно понял.
Вообще не порнял сказанного.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
