Сообщение [Nitra] Отчет на 30.03.2016 от 29.03.2016 22:00
Изменено 29.03.2016 22:12 VladD2
Работаем над клиент-серверной версией движка IDE.
Все поддерживаемые IDE и Nitra.Visualizer будут работать с ним.
Введены четыре новые сборки:
Nitra.ClientServer.Server.exe — Nitra-сервер. Сама Nitra и языковые сборки грузятся в него.
Nitra.ClientServer.Client.dll — клиентская сборка инкапсулирующая взаимодействие с сервером.
Nitra.ClientServer.Messages.dll — интерфейсная сборка содержащая сериализуемые типы используемые для передачи данных между клиентом и сервером.
Nitra.ClientServer.Macros.dll — вспомогательная сборка макросы (сериализации и прочие). Конечным пользователям ненужна.
Клиентские процессы (IDE, Nitra.Visualizer.exe и Nitra.TestsLauncher.exe) загружают только сборку Nitra.ClientServer.Client.dll и Nitra.ClientServer.Messages.dll. Их интерфейс очень простой, но исчерпывающий. С их помощью клиент делает запросы к серверу (передавая ему информацию о солюшене) и получает обратно ответы с данными (подсветка, фолдинг, список ошибок, информация об индетификаторах и т.п.).
Взаимодействие между клиентом и сервером ведется через именованные каналы по средствам сообщений (из сборки Nitra.ClientServer.Messages.dll). Есть основной канал работающий в основном на прием, по позволяющий, если надо, отдавать данные в синхронном режиме (это надо для фич вроде получения для подсказок и т.п.). Так же есть канал предназначенный для асинхронной передачи клиенту вычисляемых сервером данных (подсветка, фолдинг, ошибки, ...) об активных файлах.
Активный файл — это файл открытый в редакторе кода и отображаемый на экране. Их может быть более одного.
Преимущества такого подхода:
1. Меньше проблем с клинчем сборок (разными версиями т.п.).
2. Проблема блокировки сборки при перекомпиляции решается простым срубанием процесса.
3. Не будем толкаться в студии с Roslin и ReSharper. Студия по прежнему 32-битная и когда выйдет 64 битная не ясно.
4. Проще отладка, так как в процессе сервера нет лишнего кода (студии, решарпера и прочих плагинов).
5. Есть четкое разделение на презентационную логику и контроллер, роль которого выполняет сервер.
6. Работа клиента теперь полностью асинхронна. Пока сервер "шуршит" пользователь может менять код или переключать файлы.
7. Это позволит нам в будущем сделать Веб-IDE и Веб-песочницу для популяризации Нитры и языков поднятых на ней.
Минусы:
1. Для отладки приходится цепляться к другому процессу, даже если отладка идет в Визуалайзере.
2. Коммуникация между сервером и клиентом существенно дороже нежели прямой вызов. Надо контролировать размер передаваемых данных. По сему передаваемые типы фактически сводятся к примитивным и используется реляционная модель (как при работе с БД). Например, вместо срок файлы (и прочие строки) идентифицируются числами.
На сервере массово используются рабочие потоки (по одному на физическое ядро), так что фалы обрабатываются параллельно. Так что чем больше у вас в системе процессоров, тем потенциально быстрее будут у вас работать нитровские языки.
Hardcase занимается переводом самой Nitra на новый движок типизации. Так что как только он закончит и доведем новый движок до ума у нас будет и интеграция для самой Нитры.
На сегодня сервер уже:
1) загружает проекты;
2) парсит файлы;
3) производит семантический анализ (типизацию) проектов;
4) выдает информацию для фолдинга и подсветки (ключевых слов и символов).
На очереди:
1) информация об ошибках.
2) Поиск вхождений символа.
3) Переход к определению символа.
4) Автодополение идентификаторов.
5) Правка генератор интеграций так чтобы сгенерированный код использовал новый клиент-серверный движок.
Хинты (для символов), рефакторинги и т.п. требуют больше работы, так как не были реализованы ранее.
Все поддерживаемые IDE и Nitra.Visualizer будут работать с ним.
Введены четыре новые сборки:
Nitra.ClientServer.Server.exe — Nitra-сервер. Сама Nitra и языковые сборки грузятся в него.
Nitra.ClientServer.Client.dll — клиентская сборка инкапсулирующая взаимодействие с сервером.
Nitra.ClientServer.Messages.dll — интерфейсная сборка содержащая сериализуемые типы используемые для передачи данных между клиентом и сервером.
Nitra.ClientServer.Macros.dll — вспомогательная сборка макросы (сериализации и прочие). Конечным пользователям ненужна.
Клиентские процессы (IDE, Nitra.Visualizer.exe и Nitra.TestsLauncher.exe) загружают только сборку Nitra.ClientServer.Client.dll и Nitra.ClientServer.Messages.dll. Их интерфейс очень простой, но исчерпывающий. С их помощью клиент делает запросы к серверу (передавая ему информацию о солюшене) и получает обратно ответы с данными (подсветка, фолдинг, список ошибок, информация об индетификаторах и т.п.).
Взаимодействие между клиентом и сервером ведется через именованные каналы по средствам сообщений (из сборки Nitra.ClientServer.Messages.dll). Есть основной канал работающий в основном на прием, по позволяющий, если надо, отдавать данные в синхронном режиме (это надо для фич вроде получения для подсказок и т.п.). Так же есть канал предназначенный для асинхронной передачи клиенту вычисляемых сервером данных (подсветка, фолдинг, ошибки, ...) об активных файлах.
Активный файл — это файл открытый в редакторе кода и отображаемый на экране. Их может быть более одного.
Преимущества такого подхода:
1. Меньше проблем с клинчем сборок (разными версиями т.п.).
2. Проблема блокировки сборки при перекомпиляции решается простым срубанием процесса.
3. Не будем толкаться в студии с Roslin и ReSharper. Студия по прежнему 32-битная и когда выйдет 64 битная не ясно.
4. Проще отладка, так как в процессе сервера нет лишнего кода (студии, решарпера и прочих плагинов).
5. Есть четкое разделение на презентационную логику и контроллер, роль которого выполняет сервер.
6. Работа клиента теперь полностью асинхронна. Пока сервер "шуршит" пользователь может менять код или переключать файлы.
7. Это позволит нам в будущем сделать Веб-IDE и Веб-песочницу для популяризации Нитры и языков поднятых на ней.
Минусы:
1. Для отладки приходится цепляться к другому процессу, даже если отладка идет в Визуалайзере.
2. Коммуникация между сервером и клиентом существенно дороже нежели прямой вызов. Надо контролировать размер передаваемых данных. По сему передаваемые типы фактически сводятся к примитивным и используется реляционная модель (как при работе с БД). Например, вместо срок файлы (и прочие строки) идентифицируются числами.
На сервере массово используются рабочие потоки (по одному на физическое ядро), так что фалы обрабатываются параллельно. Так что чем больше у вас в системе процессоров, тем потенциально быстрее будут у вас работать нитровские языки.
Hardcase занимается переводом самой Nitra на новый движок типизации. Так что как только он закончит и доведем новый движок до ума у нас будет и интеграция для самой Нитры.
На сегодня сервер уже:
1) загружает проекты;
2) парсит файлы;
3) производит семантический анализ (типизацию) проектов;
4) выдает информацию для фолдинга и подсветки (ключевых слов и символов).
На очереди:
1) информация об ошибках.
2) Поиск вхождений символа.
3) Переход к определению символа.
4) Автодополение идентификаторов.
5) Правка генератор интеграций так чтобы сгенерированный код использовал новый клиент-серверный движок.
Хинты (для символов), рефакторинги и т.п. требуют больше работы, так как не были реализованы ранее.
Работаем над клиент-серверной версией движка IDE.
Все поддерживаемые IDE и Nitra.Visualizer будут работать с ним.
Введены четыре новые сборки:
Nitra.ClientServer.Server.exe — Nitra-сервер. Сама Nitra и языковые сборки грузятся в него.
Nitra.ClientServer.Client.dll — клиентская сборка инкапсулирующая взаимодействие с сервером.
Nitra.ClientServer.Messages.dll — интерфейсная сборка содержащая сериализуемые типы используемые для передачи данных между клиентом и сервером.
Nitra.ClientServer.Macros.dll — вспомогательная сборка макросы (сериализации и прочие). Конечным пользователям ненужна.
Клиентские процессы (IDE, Nitra.Visualizer.exe и Nitra.TestsLauncher.exe) загружают только сборки Nitra.ClientServer.Client.dll и Nitra.ClientServer.Messages.dll. Их интерфейс очень простой, но исчерпывающий. С их помощью клиент делает запросы к серверу (передавая ему информацию о солюшене) и получает обратно ответы с данными (подсветка, фолдинг, список ошибок, информация об индетификаторах и т.п.).
Взаимодействие между клиентом и сервером ведется через именованные каналы по средствам сообщений (из сборки Nitra.ClientServer.Messages.dll). Есть основной канал работающий в основном на прием, но по позволяющий, если надо, отдавать данные в синхронном режиме (это надо для фич вроде получения данных для подсказок и т.п.). Так же есть канал предназначенный для асинхронной передачи клиенту вычисляемых сервером данных (подсветка, фолдинг, ошибки, ...) об активных файлах.
Активный файл — это файл открытый в редакторе кода и отображаемый на экране. Их может быть более одного.
Преимущества такого подхода:
1. Меньше проблем с клинчем сборок (разными версиями т.п.).
2. Проблема блокировки сборки при перекомпиляции решается простым срубанием процесса.
3. Не будем толкаться в студии с Roslin и ReSharper. Студия по прежнему 32-битная и когда выйдет 64 битная не ясно.
4. Проще отладка, так как в процессе сервера нет лишнего кода (студии, решарпера и прочих плагинов).
5. Есть четкое разделение на презентационную логику и контроллер, роль которого выполняет сервер.
6. Работа клиента теперь полностью асинхронна. Пока сервер "шуршит" пользователь может менять код или переключать файлы.
7. Это позволит нам в будущем сделать Веб-IDE и Веб-песочницу для популяризации Нитры и языков поднятых на ней.
Минусы:
1. Для отладки приходится цепляться к другому процессу, даже если отладка идет в Визуалайзере.
2. Коммуникация между сервером и клиентом существенно дороже нежели прямой вызов. Надо контролировать размер передаваемых данных. По сему передаваемые типы фактически сводятся к примитивным и используется реляционная модель (как при работе с БД). Например, вместо использования строковых путей к файлам для их идентификации используются числа. Тоже самое происходит с рядом других строк и типов. Например, с типами описывающими SpanClass-ы.
На сервере массово используются рабочие потоки (по одному на физическое ядро), так что фалы обрабатываются параллельно. Чем больше у вас в системе процессоров, тем потенциально быстрее будут у вас работать нитровские языки.
Hardcase занимается переводом самой Nitra на новый движок типизации. Так что как только он закончит и доведем новый движок до ума у нас будет и интеграция для самой Нитры.
На сегодня сервер уже:
1) загружает проекты;
2) парсит файлы;
3) производит семантический анализ (типизацию) проектов;
4) выдает информацию для фолдинга и подсветки (ключевых слов и символов).
На очереди:
1) информация об ошибках.
2) Поиск вхождений символа.
3) Переход к определению символа.
4) Автодополение идентификаторов.
5) Правка генератора интеграций так чтобы сгенерированный код использовал новый клиент-серверный движок, т.е. перевод на новый движок плагинов к VS.
Хинты (для символов), рефакторинги и т.п. требуют больше работы, так как не были реализованы ранее.
Все поддерживаемые IDE и Nitra.Visualizer будут работать с ним.
Введены четыре новые сборки:
Nitra.ClientServer.Server.exe — Nitra-сервер. Сама Nitra и языковые сборки грузятся в него.
Nitra.ClientServer.Client.dll — клиентская сборка инкапсулирующая взаимодействие с сервером.
Nitra.ClientServer.Messages.dll — интерфейсная сборка содержащая сериализуемые типы используемые для передачи данных между клиентом и сервером.
Nitra.ClientServer.Macros.dll — вспомогательная сборка макросы (сериализации и прочие). Конечным пользователям ненужна.
Клиентские процессы (IDE, Nitra.Visualizer.exe и Nitra.TestsLauncher.exe) загружают только сборки Nitra.ClientServer.Client.dll и Nitra.ClientServer.Messages.dll. Их интерфейс очень простой, но исчерпывающий. С их помощью клиент делает запросы к серверу (передавая ему информацию о солюшене) и получает обратно ответы с данными (подсветка, фолдинг, список ошибок, информация об индетификаторах и т.п.).
Взаимодействие между клиентом и сервером ведется через именованные каналы по средствам сообщений (из сборки Nitra.ClientServer.Messages.dll). Есть основной канал работающий в основном на прием, но по позволяющий, если надо, отдавать данные в синхронном режиме (это надо для фич вроде получения данных для подсказок и т.п.). Так же есть канал предназначенный для асинхронной передачи клиенту вычисляемых сервером данных (подсветка, фолдинг, ошибки, ...) об активных файлах.
Активный файл — это файл открытый в редакторе кода и отображаемый на экране. Их может быть более одного.
Преимущества такого подхода:
1. Меньше проблем с клинчем сборок (разными версиями т.п.).
2. Проблема блокировки сборки при перекомпиляции решается простым срубанием процесса.
3. Не будем толкаться в студии с Roslin и ReSharper. Студия по прежнему 32-битная и когда выйдет 64 битная не ясно.
4. Проще отладка, так как в процессе сервера нет лишнего кода (студии, решарпера и прочих плагинов).
5. Есть четкое разделение на презентационную логику и контроллер, роль которого выполняет сервер.
6. Работа клиента теперь полностью асинхронна. Пока сервер "шуршит" пользователь может менять код или переключать файлы.
7. Это позволит нам в будущем сделать Веб-IDE и Веб-песочницу для популяризации Нитры и языков поднятых на ней.
Минусы:
1. Для отладки приходится цепляться к другому процессу, даже если отладка идет в Визуалайзере.
2. Коммуникация между сервером и клиентом существенно дороже нежели прямой вызов. Надо контролировать размер передаваемых данных. По сему передаваемые типы фактически сводятся к примитивным и используется реляционная модель (как при работе с БД). Например, вместо использования строковых путей к файлам для их идентификации используются числа. Тоже самое происходит с рядом других строк и типов. Например, с типами описывающими SpanClass-ы.
На сервере массово используются рабочие потоки (по одному на физическое ядро), так что фалы обрабатываются параллельно. Чем больше у вас в системе процессоров, тем потенциально быстрее будут у вас работать нитровские языки.
Hardcase занимается переводом самой Nitra на новый движок типизации. Так что как только он закончит и доведем новый движок до ума у нас будет и интеграция для самой Нитры.
На сегодня сервер уже:
1) загружает проекты;
2) парсит файлы;
3) производит семантический анализ (типизацию) проектов;
4) выдает информацию для фолдинга и подсветки (ключевых слов и символов).
На очереди:
1) информация об ошибках.
2) Поиск вхождений символа.
3) Переход к определению символа.
4) Автодополение идентификаторов.
5) Правка генератора интеграций так чтобы сгенерированный код использовал новый клиент-серверный движок, т.е. перевод на новый движок плагинов к VS.
Хинты (для символов), рефакторинги и т.п. требуют больше работы, так как не были реализованы ранее.