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

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

VD>>Я тебе уже говорил, что IParser и вся их идеология гнилая. Она только на языки типа шарпа подходит. Как я понял, hardcase разными изворотами прикрутил туда полноценную интеграцию. Так что IParser он попросту обходит (использует не совсем по назначению).

ВВ>Насколько я помню, там IParser использовался для фолдинга и Класс-вью. Собственно, и все. А для Класс-Вью зачем типизация?

Да, именно для этого, а типизация потребуется для установления связей в шарпдевелоповском AST.

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

VD>>>Я тебе уже говорил, что IParser и вся их идеология гнилая. Она только на языки типа шарпа подходит. Как я понял, hardcase разными изворотами прикрутил туда полноценную интеграцию. Так что IParser он попросту обходит (использует не совсем по назначению).
ВВ>>Насколько я помню, там IParser использовался для фолдинга и Класс-вью. Собственно, и все. А для Класс-Вью зачем типизация?
H>Да, именно для этого, а типизация потребуется для установления связей в шарпдевелоповском AST.

А в каком это виде сейчас? Где-нибудь выложено?

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

ВВ>А в каком это виде сейчас? Где-нибудь выложено?

Интеграция в SharpDevelop лежит с снипетах. Периодически ковыряется мною в самом SharpDevelop.

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

C>Демонстрация по ссылке (хостится прямо на моем компьютере, потому время от времени может быть офлайн):

C>www.catbert.co.cc/code

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

C>В следующих сериях : навигация, перекрестные ссылки, ссылки на данные из System.Reflection — то есть фичи, для которых код нужно не только парсить, но и типизировать.

Нашелся баг.
Берем файл http://code.google.com/p/nemerle/source/browse/nemerle/trunk/macros/core.n вставляем.

Вначале текст выглядит четко, а к концу очень бледно.


Вот код воспроизводящий проблему.

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

C>Приблизительно в этом направлении я работаю. Но мне кажется, можно сделать универсальную "карту" символов для любого языка, чтобы браузер кода работал не только в Nemerle (ну, в стиле PDB).

Универсально можно сделать все. Только есть две проблемы:
1. Чем универсальнее делаешь, тем больше работы.
2. Чем универсальнее, тем менее функционально.

В АСТ немерла есть вся нужная информация. А вот как ты сделаешь тоже самое универсально, я представить себе не могу.

C>Ну, учитывая то, что:

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

C>не знаю, будет ли мое «спокойное» решение полезно для «быстрой» интеграции.

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

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

Минус — скорость получения результата. Но для многих применений — это не такой уж и минус.

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

VD>>Вот этот файл приводит к некислым тормозам.

C>Да не должен бы в теории... там же только Lexer+PreParser.

Lexer+PreParser конечно к таким тормозам привести не могут (в той же интеграции они работают молниеносно).
А вот то как формируется текст или даже то какой канал у твоего сервера — может.

Вот ты строки чем формирвешь? StringBuilder-ом?

C>Да и на практике не могу заметить тормозов. Возможно, в этот же момент мой комп занимался чем-то процессоро-интенсивным.

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

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

VD>Вот ты строки чем формирвешь? StringBuilder-ом?

Даже если складывать строки "+", то объем здесь не настолько велик, чтобы приводить к таким задержкам. Подумаешь, несколько десятков миллионов мелких объектов в куче.

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

Кстати, размер HTML можно вполне ужать. К примеру, там нефиговый вью-стейт — причем непонятно, откуда он взялся и на фига он там нужен.

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

ВВ>Даже если складывать строки "+", то объем здесь не настолько велик, чтобы приводить к таким задержкам. Подумаешь, несколько десятков миллионов мелких объектов в куче.

Тут ты не прав. При определенных (легко достигаемых) условиях сложение строк может привести к экспоненциальному алгоритму. А это кирдык уже на тысячах объектов.

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

Возможно, но не уверен. Лучше бы автору самому проверить все.

ВВ>Кстати, размер HTML можно вполне ужать. К примеру, там нефиговый вью-стейт — причем непонятно, откуда он взялся и на фига он там нужен.

Ну, у меня канал широкий...

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

ВВ>С самим проектом компилятора нельзя работать из студии?

К сожалению, нет. С Интеграцией, можно, а с компилятором нет.

Раньше у меня мозгов не хватало, чтобы решить там все проблемы. Сейчас вроде я до этого дорос, но туго со временем.

Возможно в ближайшее время попробую разобраться.

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

VD>Тут ты не прав. При определенных (легко достигаемых) условиях сложение строк может привести к экспоненциальному алгоритму. А это кирдык уже на тысячах объектов.

А что в данном случае можно такое сотворить со строками, чтобы получить такие тормоза? Считай, минимум 5 секунд лишнего времени. Если сконкатенировать результирующий ХТМЛ через плюсик, то разница по сравнению со стринг-билдером и на глаз заметна не будет.

ВВ>>Кстати, размер HTML можно вполне ужать. К примеру, там нефиговый вью-стейт — причем непонятно, откуда он взялся и на фига он там нужен.
VD>Ну, у меня канал широкий...

Однако это не поможет, если у него — узкий.

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

VD>К сожалению, нет. С Интеграцией, можно, а с компилятором нет.
VD>Раньше у меня мозгов не хватало, чтобы решить там все проблемы. Сейчас вроде я до этого дорос, но туго со временем.
VD>Возможно в ближайшее время попробую разобраться.

А как вы сами-то компилятор правите? Без студии? Честно, даже как-то сложно представить — Влад и без студии

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

ВВ>А что в данном случае можно такое сотворить со строками, чтобы получить такие тормоза? Считай, минимум 5 секунд лишнего времени. Если сконкатенировать результирующий ХТМЛ через плюсик, то разница по сравнению со стринг-билдером и на глаз заметна не будет.

Попробуй, вот такой вот безобидный с виду примерчик:

using System.Console;
using Nemerle.Diagnostics;

module Program
{
  Main() : void
  {
    def source = "test ";
    mutable str = "";

    time 
      repeat(40_000)
        str += source;

    WriteLine($"Size: $(str.Length)");
  }
}

ВВ>Однако это не поможет, если у него — узкий.

+1

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

ВВ>А как вы сами-то компилятор правите? Без студии? Честно, даже как-то сложно представить — Влад и без студии

Без интеграции. В студии, но проект студия понимает как шарповский. При этом подсветка делается путем ассоциации .n-файлов с С++ и добавлением файла с ключевыми словами для С++.

При этом работает только дерево проектов, редактор кода и отладка. Хреновенько конечно, но лучше чем ничего.

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

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

ВВ>А как вы сами-то компилятор правите? Без студии? Честно, даже как-то сложно представить — Влад и без студии


Я в SharpDevelop-е. Отлаживаю как получится, но как правило методом пристального взгляда.

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

Такое можно только специально написать На строку в 200 килобайт (хотя там генерится максимум 100) 40 тыс. перевыделений — это несколько крутовато.

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

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

H>Я в SharpDevelop-е. Отлаживаю как получится, но как правило методом пристального взгляда.

А там дебагер-то штатный должен был завестись. Или он глючит?

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

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

H>>Я в SharpDevelop-е. Отлаживаю как получится, но как правило методом пристального взгляда.

ВВ>А там дебагер-то штатный должен был завестись. Или он глючит?

Он работает, но SD себя в системе не прописывает, и потому аттачусь к процессу (компилятор предлагает запустить отладку при флаге -debugger) студией. Но это случается если я совсем не понимаю что происходит.

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

__>Все три строки подсвечиваются одинаково.
__>Мне кажется просто строковой литерал должен подсвечиваться как здесь на rsdn.

Как именно?

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

__>Вначале текст выглядит четко, а к концу очень бледно.

Бледно выглядит код, помещенный в квазицитату. В вашем примере несбалансированная скобка помещает в квазицитату весь код дальше её самой.

Собственно, "бледность" — один из вариантов Внешний вид кода задается CSS.

У меня все генерируется мгновенно, так что проблема в канале.

Да, гигантский ненужный viewstate есть, он отвечает за текст в текстбоксе, куда код писать.

Web-приложение неоптимизированное, написанное под чистые Web Forms, откуда и часть проблем. Если выход сжимать gzip-ом, ответ сервера будет соовсем маленьким.