Здравствуйте, _Claus_, Вы писали:
_C_>чего не будет? если удаленный интерфейс будет 1 в 1 или близко повторять локальный..
Это само по себе не слабая работа. А на еще нужно и основную сделать.
Пока что нет ни одного примера абраузерной IDE которая была бы сравнима по функциональности с полноценной, десктопной.
VD>>То что сделано в котлине сделано за счет Явы. Чисто вебный интерфейс там совсем убогий (нет интелисенса).
_C_>пока дойдет до добавления интеллисенса что-то наверняка придумается. это по любому не космическая сложность.
Это большой объем работы. У колинце наверняка тот же редактор был уже в виде явского компонента. А где взять такой же для ХТМЛ?
VD>>Как не парадоксально, но дотнет встраивается в браузеры с большим скрипом нежели Ява. Так что нам будет сложнее.
_C_>а зачем его встраивать? фреймворк должен транслировать вызовы и принимать прозрачно для .Net кода (см ссылку)
Если таскать всю обрабтку на сервер, то будет сильная латентность. А чтобы реализовать парсинг на клиенте, на нем придется запускать дотнет.
Яваскрипт точно не потянет парсинг. Это будут вселенские тормоза. Да и для этого сначала нужно сделать полную трансляцию немерла в жабаскрипт. Что уже само по себе нехилый объем работ.
_C_>вопрос в том, подходит что готовое для этого, или все таки надо делать.
Сначала подумай — как ты вообще себе это видишь? Где должен делаться парсинг и типизация? Если на сервере, то как обеспечить приемлемый отлик? Ведь весь код придется таскать на сервер, там обрабатывать и тащить на клиента результат.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Яваскрипт точно не потянет парсинг. Это будут вселенские тормоза. Да и для этого сначала нужно сделать полную трансляцию немерла в жабаскрипт. Что уже само по себе нехилый объем работ.
Здравствуйте, VladD2, Вы писали:
VD>Это само по себе не слабая работа. А на еще нужно и основную сделать.
я ж и предлагаю делать одну работу, а хитрым Гуем обеспечить удаленную работу. без доп. затрат.
VD>Пока что нет ни одного примера абраузерной IDE которая была бы сравнима по функциональности с полноценной, десктопной.
даже урезанная функциональность будет впечатлять. в конце концов — удаленная работа — это знакомство и всякий экстрим.
для обычного программирования десктоп остается ессно главным.
VD>>>То что сделано в котлине сделано за счет Явы. Чисто вебный интерфейс там совсем убогий (нет интелисенса).
_C_>>пока дойдет до добавления интеллисенса что-то наверняка придумается. это по любому не космическая сложность. VD>Это большой объем работы. У колинце наверняка тот же редактор был уже в виде явского компонента. А где взять такой же для ХТМЛ?
тут веберы должны сказать. Google Docs потрошить можно можно прозрачно затащить бинарный компонент — см. ниже.
VD>Яваскрипт точно не потянет парсинг. Это будут вселенские тормоза. Да и для этого сначала нужно сделать полную трансляцию немерла в жабаскрипт. Что уже само по себе нехилый объем работ.
можно ограничиться Google Chome, у них есть технология прозрачно грузить бинарики, в том числе и .Net, и крутить хоть парсинг, хоть что без шума и пыли. мозилла тоже подтянется по-любому, если уже не сделала. этот варинт также делает возможным запаковать всю небольшую студию, но удаленная отладка и доступ должны быть как-то покрыты.
Здравствуйте, para, Вы писали:
VD>>Яваскрипт точно не потянет парсинг. Это будут вселенские тормоза. Да и для этого сначала нужно сделать полную трансляцию немерла в жабаскрипт. Что уже само по себе нехилый объем работ.
P>транслировать во флеш?
Ага. Шиза полная.
Так что реалистичных варианта два:
1. Таскать на каждый чих все на сервер.
2. Поднимать на клиенте полноценный дотнет. Причем, из-за завязки на SRE мы даже Сервилат не можем пока использовать. Вроде как WPF-приложения можно в браузерный вид превратить довольно легко.
В общем, вопросов больше чем ответов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Аноним, Вы писали:
А>Есть. У меня работал и довольно шустро.
На каком объеме и с какой латентностью сети?
Потом у них там пока что зачатки интелисенса. Даже комплит работает через пень колоду. Если там навернуть все фичи IDE, то все это будет не подтормаживать на мало мальски серьезных файлах.
VD>>Как не парадоксально, но дотнет встраивается в браузеры с большим скрипом нежели Ява. Так что нам будет сложнее. А>У меня нет выпилен из браузеров. Ие не пользуюсь и на работе удалил со всех компов ибо достали порнобанеры у пользователей. С хромом и лисицей проблем нет. Ие 9 это кошмар админа.
Какая связь между дотнетом и порнобанерами?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Аноним, Вы писали:
А>Через нет создает окошко подменяющее сообщение установить. Убиваешь нет ассистанс и порнобанер не ставиться. Было такое года 3 назад. Больше не хочу.
Во как?!... Никогда о таком не слышал.
А>Кстати с чего вывод что джабаскрипт настолько медленный. Он все таки компилируется. Не думаю что он проиграет нет в 2 раза. Нужен тест.
Не смешите мои тапочки. Язык без статической типизации может хвастаться производительность только на детских тестах. Когда речь пойдет о парсинге, то это будет полный кабздец. Тут даже дотнетные проверки выхода за границы массивов и то сильно просаживают производительность. А уж массивы объектов — это будет полный мрак.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>То что сделано в котлине сделано за счет Явы. Чисто вебный интерфейс там совсем убогий (нет интелисенса).
Там несколько способов компиляции.
VD>Как не парадоксально, но дотнет встраивается в браузеры с большим скрипом нежели Ява. Так что нам будет сложнее.
Странно, что никто здесь не обратил внимание на то, что котлин компилируется в js и имеет компилятор на js. Они этот вопрос проработали очень неплохо. Со встраиванием в браузер там все очень красиво.
Тут еще нужно учесть:
1. Что это сравнение с тормозным Моно.
2. В их тестах учитывается время затрачиваемое на загрузку и джит-компиляцию приложения.
3. Что это все синтетика на которой оптимизации обычно работают хорошо.
В реальной жизни разница будет куда существеннее. Думаю что не меньше 8 раз.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Поискал у них задачку отдаленно напоминающую парсинг. Нашел reverse-complement: C# Mono — 2.93 сек. JavaScript V8 — 15.15 сек. GNU С++ и ATS — 0.88 сек.
Думаю, что при честных измерения (с прогревом) Nemerle на дотнете показал бы где-то 1-1.5 сек. Что составляет 10 и более раз. Что и следовало бы ожидать при сравнении динамики и статики.
И это на синтетике. А реальный парсер куда сложнее оптимизировать будет. Плюс еще будет неизбежный оверхэд от тупости преобразователя (вручную ведь можно больше из языка выжать).
Короче, все печально в этом плане.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ziaw, Вы писали:
Z>Там несколько способов компиляции.
Да компиляция — это фигня, в общем-то. Ее на сервер можно без проблем отправлять.
VD>>Как не парадоксально, но дотнет встраивается в браузеры с большим скрипом нежели Ява. Так что нам будет сложнее.
Z>Странно, что никто здесь не обратил внимание на то, что котлин компилируется в js и имеет компилятор на js. Они этот вопрос проработали очень неплохо.
Да ладно. Там примеры сложнее хловорда как один на этом жс падают все время.
Z>Со встраиванием в браузер там все очень красиво.
Согласен. Но на IDE это все равно не тянет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
N>>Если бы вы сделали подобный инструмент для N2, да ещё в вебе (наподобие Kotlin Web Demo)
VD>Я вот у них попытался получить комплешон и все зависло. Думаю, сделать качественный интерфейс в броузере будет не очень просто.
Я предложил веб исключительно с целью снизить порог вхождения. Тому, кто хочет поиграться с инструментом 5-10 минут, чтобы понять, интересно ли это вообще ему или нет, гораздо проще сделать это на веб-страничке, чем что-то скачивать/устанавливать/запускать.
Здравствуйте, VladD2, Вы писали:
VD>В ANTLRWorks там все шибко визуальное. Это не просто. У нас будет обычная отладка в отладчике. Собственно она и сейчас есть. Только много лишнего показывает. Надо будет подумать как упростить отладку, чтобы она прямо по правилам бежала.
Надо, чтобы была видна текущая позиция в исходнике и стек правил, которые в данный момент разбираются.
Здравствуйте, nikov, Вы писали:
N>Надо, чтобы была видна текущая позиция в исходнике и стек правил, которые в данный момент разбираются.
В итоге генерируется парсер рекусивного спуска (правда, с откатами). Так что кол-стек и есть стек правил. Он конечно несколько замусоренный, но все же суть проходящего понять можно.
Можно просто получить сгенерированный исходник парсера, ставить в нем точки останова и бродить по коду.
ЗЫ
В общем, если поможете разобраться с тем как подкрутить отладочную информацию — сделаем как надо.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, nikov, Вы писали:
N>Я предложил веб исключительно с целью снизить порог вхождения. Тому, кто хочет поиграться с инструментом 5-10 минут, чтобы понять, интересно ли это вообще ему или нет, гораздо проще сделать это на веб-страничке, чем что-то скачивать/устанавливать/запускать.
Можно сделать страничку без лишних наворотов (без интелисенса, или с минимальным его вариантом).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, nikov, Вы писали:
N>В Roslyn инкрементальный парсинг уже есть. Хотя скорость парсера и так очень высокая — он оптимзирован вручную по самое немогу.
Так а какой смысл в инкременталном варианте? Чтобы было что отлаживать?
И как вы поступаете в случае когда где-то всередике кода встречаются инструкции препроцессора?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали: VD>Можно сделать страничку без лишних наворотов (без интелисенса, или с минимальным его вариантом).
А в чём проблема сделать интеллисенс на странице? Если список дополнений можно получить на десктопе, то его так же можно получить в браузере. Задержка для запроса будет не такая уж и большая.
Здравствуйте, ionoy, Вы писали:
I>А в чём проблема сделать интеллисенс на странице? Если список дополнений можно получить на десктопе, то его так же можно получить в браузере. Задержка для запроса будет не такая уж и большая.
Проблема в стейтлесс природе веба. На десктопе мы можем держать дерево, занимаясь перепарсиванием мелких кусков. В вебе придется либо делать огромную сессию и поднимать ее по запросу. Либо отправлять на сервер весь код и парсить тоже все. Первый вариант накроется на сотне пользователей, второй подходит только для туториалов.
можно прозрачно затащить бинарный компонент — см. ниже.
