[Nitra] Почему клинт-сервер?
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.12.17 09:51
Оценка:
Уже не один человек задает вопрос "Почему для реализации IDE-движка выбрана именно клент-серверная реализация? И не является ли это перебором?".

Вот здесь
Автор: VladD2
Дата: 29.12.17
описаны цели, которые пытались достичь подобным дизайном.

Публикую один из чатов в Скайпе. Думаю, что в такой форме (вопрос, ответ) будет проще объяснить все "за" и "против".

Dmitry Golovko: Вариант с сервером какой то тяжеловесный на мой взгляд (он оправдан для работы с 32 битной версией VS) но для отдельного проекта с редактором это по моему перебор.
По идее для интелисенса должна быть отдельная библиотека с публичным апи.

Vlad: Наоборот. Это чистое и незамутненное разделение представления и модели.

Dmitry Golovko: А чем отдельная библиотека этому разделению препятствует?

Vlad: Вот сообщения и есть публичный АПИ.

Dmitry Golovko: Зачем затевать межпроцессорное взаимодействие если есть возможность выполнения в рамках одного процесса?

Vlad: Переверни свой вопрос и попробуй на него ответить.
Vlad: Тут вопрос лучше ставить по другому. Не "зачем", а что дает один и другой подход.

Dmitry Golovko: Дают по идее то же самое

Vlad: Ну, вот не совсем.
Vlad: И потому сейчас почти все движки ИДЕ по этому пути пошли. Райден, Розлин по карайней мере.
Dmitry Golovko: Ну там скорее всего упирается в ограничения по памяти в VS

Vlad: Это только одно "за".
Vlad: Еще — возможность реализации движка IDE для не дотнетной платформы. Месаги то просто плоские данные сериализуемые в поток.
Vlad: Реализуй их передачу на яве или С++ и получишь общение с сервером на дотнете даже не зная про это.

Dmitry Golovko: Это да.
Но для дот нета можно совместить оба подхода и в серверной части добавить открытое апи.

Vlad: Ну, и сама чистота связей. Когда у тебя все в одном процессе невольно хочется использовать какие-то внутренние структуры. А так ты обязан все сериализовать. А значит и сам не захочешь тащить кишки компилятора.
Изменены 12:24:08] Vlad: В итоге АПИ остается простым и легким.
Vlad: На скорость же это никак не влияет, так как все делается довольно крупными транзакциями.

Dmitry Golovko: Для тонких клиентов написанных на дот нете наличие серверной части усложняет интеграцию на мой взгляд

Vlad: Ну, про устойичивость к сбоям и говорить не приходится. Процесс слетит, и отряд не заметит потери бойца...

Dmitry Golovko: АПИ можно оставить один к одному как есть и при работе с библиотекой
Dmitry Golovko: Те де сообщения

Vlad: Ну, где усложняет то? Тебе и так и эдак надо реализовать некий АПИ.

Dmitry Golovko: + добавить запускалку серверной части
Dmitry Golovko: И отслеживать ее работоспособность

Vlad: Если ты пишешь на дотнете, то клиент уже есть. Просто создаешь его экземпляр и пользуешся.
Vlad: Ничем от классического АПИ не отличается.
Vlad: Разве что вместо вызова методов — передаешь сообщения. Но это и в обычном коде бывает. Слышал про модель акторов?

Dmitry Golovko: Да

Vlad: Тут еще один нюанс. Месаги выбраны не просто так. Все АПИ асинхронное. Это нужно чтобы не было тормозов.
Vlad: А с асинхронным, многопоточным кодом крайне неприятно работать теми средствами, что предоставляет тот же Шарп.
Vlad: Вот и была выбрана модель актров, чтобы все взаимодействие был понятным человеку.
Vlad: Пока что эта модель не подводила. Проблем с многопоточностью (тьфу-тьфу) нет.

Dmitry Golovko: Это все понятно — как серверный процесс будет запускаться лучше расскажи?

Vlad: Да молча. Стартует как ехе-шник. Это проблемы клиента.
Vlad: Он создает дочерний процесс и передает ему имена именованных каналов через параметры.
Vlad: Тебе как пользователю АПИ эти детали не важны. Ты просто соззаешь клиент и вызваешь всегда один метод — Send()

Dmitry Golovko: Ну как же не важны
Если я поставляю утилиту редактора то мне важно чтобы как можно проще можно было его установить и запустить без лишних зависимостей
Vlad: Вот отсутствие зависимостей — это еще одно преимущество данного подхода. Твой процесс зависит только от двух длл-ей Nitra.ClientServer.Client.dll и Nitra.ClientServer.Messages.dll.
Dmitry Golovko: Т.е я их подключаю к проекту и дергаю у них метод Send?

Vlad: Все что может прийти с сервера и все что можно послать на сервер описано вообще в одном файле. https://github.com/rsdn/nitra/blob/master/Nitra/ClientServer/Nitra.ClientServer.Messages/Messages.n
Vlad: Т.е я их подключаю к проекту и дергаю у них метод Send?Да
Vlad: Так и работают плагин к Студии и Визуалайзер.

Dmitry Golovko: Ну супер.
Это то что я хотел
При это они создают отдельный процесс?

Vlad: Вот если захочешь на Яве ИДЕ замутить, то придется реализовать обе длл-ки. Но они не так уж сложны.
Vlad: При это они создают отдельный процесс?Да. Точнее создает Nitra.ClientServer.Client.dll

Dmitry Golovko: Ок
Главное что мне этим заниматься не надо

Vlad: Nitra.ClientServer.Messages.dll только содержит месаги и код их сериализации/десериализации (сгенерированный макросами).

Dmitry Golovko: Ок
Главное что мне этим заниматься не надо

Vlad: Ну, каждому главное свое. Кому-то может оказаться приятным, то что можно обращаться к серверу из Явы или С++.
Vlad: И он с радостью реализует эти две Длл-и. Благо они простенькие.

Dmitry Golovko: Это большой плюс

Vlad: Это куча огромных плюсов!

Dmitry Golovko: Согласен

Vlad: Потому и клиент-сервер. Жаль только каждому все это объяснять приходится.

Dmitry Golovko: Ну надо заметку создать



20.12.17 21:00: Перенесено из 'Nemerle'
20.12.17 21:00: Перенесено из 'Nemerle'
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Отредактировано 30.12.2017 8:43 VladD2 . Предыдущая версия . Еще …
Отредактировано 19.12.2017 9:54 VladD2 . Предыдущая версия .
Отредактировано 19.12.2017 9:54 VladD2 . Предыдущая версия .
Re: [Nitra] Почему клинт-сервер?
От: Pzz Россия http://pzz.livejournal.com/
Дата: 19.12.17 10:00
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Уже не один человек задает вопрос "Почему для реализации IDE-движка выбрана именно клент-серверная реализация? И не является ли это перебором?".


А что, нормальный такой UNIX way. Я тоже так люблю

А клиент умеет выживать, если сервер упал и перезапустился?
Re: [Nitra] Почему клинт-сервер?
От: Kolesiki  
Дата: 19.12.17 11:05
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Уже не один человек задает вопрос "Почему для реализации IDE-движка выбрана именно клент-серверная реализация? И не является ли это перебором?".


"Ичо?" Влад, ты всё равно ничего не объяснил, кроме как парируя гипотетическими преимуществами ( <- прочитать, вникнуть!) клиент-серверного подхода, оставляя за кадром саму нужность этого "многоплатформенного суперрешения". Ты идёшь от преимуществ к решению (а точнее, оправдываешь решение преимуществами), в то время как задача вообще нигде не формулирует нужность этой самой "всемногопуперности". Задача — предоставить клиенту удобный backend API, минимизируя любые затраты, ибо time critical.

Рассуди как маркетолог, после ЖетБрынзы ты теперь это можешь: кому нужна многоплатформенность? Ну да, есть пара гиков, которые пишут калькулятор для "Пингвохрень-Линукс 425.1.3". Ичо? Этот 0.000001% стóит тех затрат, что ты терпишь, учитывая все ньюансы решения "нечто независимое — связь — нечто независимое"? Очевидно, что нет. МакакОСь — та вообще удел конченых эпплерастов, не интересна ни разу.
Остаёмся мы и форточка. И космическая архитектура, позволяющая НЛО соединяться с Землёй и парсить там сорсы Немерли.

Учитывая, что .NET и так "простихоспади" по производительности, да ещё и компиляция — весьма ресурсоёмкая задача, нужно крайне аккуратно разбрасываться "абстракциями", заранее предусматривая тотальную оптимизацию, кэши, reusing и т.п.

Так что нет, аргументированного ответа мы не получили. "Все так делают" — тоже не аргумент.
Re[2]: [Nitra] Почему клинт-сервер?
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.12.17 11:05
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>А клиент умеет выживать, если сервер упал и перезапустился?


IDE остается жить. А вот сервер перезапускаться не умеет. Не научили пока. Оно и без того вроде пашет. Если что придется переоткрыть солюшен. Но, конечно, нужно сделать и это.

Как не странно самым противным багом оказалась передача неожидаемых клиентом данных (несоответствие протоколу). Вот тут ИДЕ не раз складывалась. Но это можно обложить трай-кэтчами.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: [Nitra] Почему клинт-сервер?
От: Pzz Россия http://pzz.livejournal.com/
Дата: 19.12.17 11:34
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>IDE остается жить. А вот сервер перезапускаться не умеет. Не научили пока. Оно и без того вроде пашет. Если что придется переоткрыть солюшен. Но, конечно, нужно сделать и это.


Ну если сервер руками перезапустить, клиент его подхватит?

VD>Как не странно самым противным багом оказалась передача неожидаемых клиентом данных (несоответствие протоколу). Вот тут ИДЕ не раз складывалась. Но это можно обложить трай-кэтчами.


А ты это сообщения не валидируешь, что ли, при приеме?
Re[4]: [Nitra] Почему клинт-сервер?
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.12.17 11:57
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>Ну если сервер руками перезапустить, клиент его подхватит?


Нет. Серверу передаются имена именованных каналов. Так что перезапускать его должен клиент. Это не сложно. Надо просто это сделать. Пока этого нет.

Pzz>А ты это сообщения не валидируешь, что ли, при приеме?


Да формат по определению не может быть не правильным. Он не сериализуется неверно. Но среди смесаг были такие, которые предполагают ответ, например. А в сервере может быть какой-то выход без ответа. И все идет наперекосяк.

Или другой пример. Сервер вырабатывает хинт. Но хинт частично формируется прикладным кодом. При этом в нем могут быть баги. В разультате может вернуться невалидный ХМЛ. Он тупо подсовывался парсеру от МС, которые ничего умнее не делал как кинуть исключение. Исключение не ловилось и все ИДЕ падала. Ну, понятно, что в итоге это дело отловилось и было перекрыто на разных уровных абстракции (вплоть до перехвата исключений парсера ХМЛ-я). Но какое-то время клиент наворачивался от некорректного выхлопа сервера. Теперь не только не падает, но еще и диагностику дает.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: [Nitra] Почему клинт-сервер?
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.12.17 12:22
Оценка:
Здравствуйте, Kolesiki, Вы писали:

K>"Ичо?" Влад, ты всё равно ничего не объяснил, кроме как парируя гипотетическими преимуществами


Просто тебе так хочется считать не смотря на аргументы. Если просто здраво сопоставить все требования, то становится понятным, что выбор был единственно возможным.

Просто аргументы я несколько раз приводил. Последний раз в видео. Могу еще раз перечислить:
1. Преодоление 32-битного адресного пространства Студии.
2. Надежность.
3. Переносимость между платформами и поддержка разных ИДЕ в будущем.
4. Гарантированная изоляция представления от модели и как следствие удержание АМИ минималистическим, не тянушим лишних деталей.
5. Упрощение асинхронной, многозадачной реализации за счет использования модели акторов.
6. Возможность реализации клиента на основе браузера.

Уже одного пункта 1 за глаза хватает для выбора именно клиент-серверного решения. Но все остальные возможности тоже крайне желательны. Их отсутствие уменьшает конкурентоспособность Нитры.

K>Рассуди как маркетолог, после ЖетБрынзы ты теперь это можешь: кому нужна многоплатформенность?


Вот как раз "после" могу четко ответить на этот вопрос. Когда я пришел туда, основным продуктом был Решарпер, а сейчас основным продуктом стала Идея. Причем решарпер запихнули в такой же сервер и прикрутили к Идеее. Получившийся продукт назвали Райдер. Уж кто-то, а Джет коммерческая контора и просто так они ничего не разрабатывают. Тем более, что на разработку они тратят сильно больше одного человека.

K>Ну да, есть пара гиков, которые пишут калькулятор для "Пингвохрень-Линукс 425.1.3". Ичо? Этот 0.000001% стóит тех затрат, что ты терпишь, учитывая все ньюансы решения "нечто независимое — связь — нечто независимое"?


Очевидно, что ты пропустил маленькое событие. За эти годы разработка для Веба стала доминирующей, а десктоп отошел на второй план. Ранее МС выезжал на том, что которы писали разные бухгалтерии и склады под Винду. Но теперь они все прочухали, что лучше писать для Веба. Это снимает проблемы развертывания и администрирования клиентов. Делает решение клиент-серверным (т.е. более устойчивым к сбоям и более производительным).

Ну, еще в тренде мобилы. Но это опять не про МС, так как МС этот рынок слил.

И вот даже МС схватилась за голову и в спешке лепит .Net Core! На первый взгляд можно подумать, что это какой-то отдел нашел фатальный недостаток в дотнете и решил его исправить путем написания такого же дотнета, но другого. Но на самом деле они спасают шкуру компании, так как если не делать этого, то МС может и разориться.

Новая стратегия — захват облачного рынка. Но люди не очень хотят платить за Винду на сервере, ведь пхп-шки не плохо работают и на бесплатном Линухе. Вот МС и клепает в строчном порядке переносимый сабсэт дотнета. Основная задача .Net Core — хостить Asp.Net MVC. Именно по этому Джет начал клепать Райдер.

Так что нужда в кроссплатформенности не мнимая, а самая что ни на есть реальная.

K>Учитывая, что .NET и так "простихоспади" по производительности, да ещё и компиляция — весьма ресурсоёмкая задача, нужно крайне аккуратно разбрасываться "абстракциями", заранее предусматривая тотальную оптимизацию, кэши, reusing и т.п.


Это никак не противоречит клиент-серверной архитектуре. Наоборот, серверу удобнее кэшировать все что надо. Обмен с сервером идет довольно редкими и крупными сообщениями. Так что на производительности это не сказывается. Думаю, сервер и через ХТТП по Вебу будет не плохо работать.

K>Так что нет, аргументированного ответа мы не получили. "Все так делают" — тоже не аргумент.


Это твои домыслы.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: [Nitra] Почему клинт-сервер?
От: Слава  
Дата: 19.12.17 12:38
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Уже не один человек задает вопрос "Почему для реализации IDE-движка выбрана именно клент-серверная реализация? И не является ли это перебором?".


Можно было ответить одной фразой "это Unix-way". Самое универсальное это именно взаимодействие процессов, поддерживаю такой выбор.
Re[5]: [Nitra] Почему клинт-сервер?
От: Pzz Россия http://pzz.livejournal.com/
Дата: 19.12.17 13:58
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Нет. Серверу передаются имена именованных каналов. Так что перезапускать его должен клиент. Это не сложно. Надо просто это сделать. Пока этого нет.


А почему не наоборот? Я бы сделал имя именованного канала фиксированным, и пусть сервер его "слушает", а клиенты к нему коннектятся по мере надобности.

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

Pzz>>А ты это сообщения не валидируешь, что ли, при приеме?


VD>Да формат по определению не может быть не правильным. Он не сериализуется неверно. Но среди смесаг были такие, которые предполагают ответ, например. А в сервере может быть какой-то выход без ответа. И все идет наперекосяк.


Я бы сделал ответ всегда, пусть пустой, чтобы клиент как минимум знал, что его письмо достигло адресата. И сделал бы с серверной стороны некоторый общий уровень, который распаковывает и проверяет запрос, вызывает соответствующую функцию, запаковывает ответ, if any, и отправляет взад.

VD>Или другой пример. Сервер вырабатывает хинт. Но хинт частично формируется прикладным кодом. При этом в нем могут быть баги. В разультате может вернуться невалидный ХМЛ. Он тупо подсовывался парсеру от МС, которые ничего умнее не делал как кинуть исключение. Исключение не ловилось и все ИДЕ падала. Ну, понятно, что в итоге это дело отловилось и было перекрыто на разных уровных абстракции (вплоть до перехвата исключений парсера ХМЛ-я). Но какое-то время клиент наворачивался от некорректного выхлопа сервера. Теперь не только не падает, но еще и диагностику дает.


А парсеру от МС вообще безопасно подсовывать неизвестно откуда взявшийся ХМЛ? Не получится так, что ты создаешь дыру в защите? Я б не очень доверял по умолчанию парсеру от МС, честно говоря.
Re: [Nitra] Почему клинт-сервер?
От: _Raz_  
Дата: 19.12.17 14:02
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>

VD>Dmitry Golovko: Зачем затевать межпроцессорное взаимодействие если есть возможность выполнения в рамках одного процесса?

VD>Vlad: Переверни свой вопрос и попробуй на него ответить.
VD>Vlad: Тут вопрос лучше ставить по другому. Не "зачем", а что дает один и другой подход.




VD>Уже не один человек задает вопрос "Почему для реализации IDE-движка выбрана именно клент-серверная реализация? И не является ли это перебором?".


Конечно задают — ты же уходишь от ответа. И будут задавать, пока ты игнорируешь часть "если есть возможность выполнения в рамках одного процесса".
... << RSDN@Home 1.3.108 alpha 5 rev. 56>>
Re[2]: [Nitra] Почему клинт-сервер?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.12.17 05:16
Оценка:
Здравствуйте, _Raz_, Вы писали:

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


Я ни от чего не ухожу. Просто у кого-то есть мнение, которое хрен оспоришь. С этим бороться невозможно.

Сама постановка вопроса "Зачем, если есть возможность выполнения в рамках одного процесса?" ущербная. Ее точно так же можно развернуть на 180 градусов: "Зачем, если есть возможность выполнения в рамках разных процессов?". Чем хуже?

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

Сервер изолированный в отдельном процессе дает кучу преимуществ и ни одного недостатка. Скорости передачи данных достаточно. Остальное мелочи. Пользователь может и не знать, что там что-то на процессы разнесено. В том же Розлине тоже отдельный процесс, но что-то никто не выступает против этого.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: [Nitra] Почему клинт-сервер?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.12.17 05:34
Оценка:
Здравствуйте, Слава, Вы писали:

С>Можно было ответить одной фразой "это Unix-way". Самое универсальное это именно взаимодействие процессов, поддерживаю такой выбор.


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

Да и не все понимают смысл этого UNIX-way.

Но, согласен — с UNIX-way много общего.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: [Nitra] Почему клинт-сервер?
От: ifle  
Дата: 20.12.17 06:13
Оценка:
А к чему эти споры? непонятно . Абсолютно правильное решение, позволяющее безопасно не нагружая IDE делать свою работу, легко переносимое на любую IDE.
Примеров достаточно, тот-же VS, Code, Idea, Rider с решарпером как клиент-сервер.
Re[3]: [Nitra] Почему клинт-сервер?
От: WolfHound  
Дата: 20.12.17 06:38
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Это не совсем UNIX-way. Все же наш сервер это многопоточное, асинхронное приложение. Каналы в нем используются для интерактивного общения через модель акторов.

На самом деле можно сделать совсем UNIX-way.
Пропустить всё общение через stdin и stdout процесса.
На производительности это не скажется.
За одно будет возможность работать с сервером по сети. Ибо API получится идентичным TCP/IP протоколу.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[4]: [Nitra] Почему клинт-сервер?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.12.17 07:00
Оценка:
Здравствуйте, ifle, Вы писали:

I>А к чему эти споры? непонятно . Абсолютно правильное решение, позволяющее безопасно не нагружая IDE делать свою работу, легко переносимое на любую IDE.

I>Примеров достаточно, тот-же VS, Code, Idea, Rider с решарпером как клиент-сервер.

Есть стойкое непонимание и неприятие у ряда людей. Месяц назад я IT тоже самое объяснял. Решил, чтобы не объяснять каждому в отдельности, выложить переписку с подобным объяснением.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: [Nitra] Почему клинт-сервер?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.12.17 07:05
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>На самом деле можно сделать совсем UNIX-way.

WH>Пропустить всё общение через stdin и stdout процесса.

Они текстовые. И не уверен, что не синхронные. У нас для возврата сообщений две очереди. Одна псевдо-синхронная (для операций, которые требуют продолжения) и одна асинхронная.

WH>На производительности это не скажется.


Возможно. Но это тоже надо проверять.

WH>За одно будет возможность работать с сервером по сети. Ибо API получится идентичным TCP/IP протоколу.


Именованные каналы и так по сети работают. Вопрос только в том зачем это сейчас нужно?

Вот что, возможно, и надо было бы сделать, так это перейти на HTTP и JSON вместо именованных каналов и бинарной сериализации. Та же VS Code именно этими форматами пользуется. Плюс, гоняя текст, упрощается отладка.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: [Nitra] Почему клинт-сервер?
От: WolfHound  
Дата: 20.12.17 08:03
Оценка:
Здравствуйте, VladD2, Вы писали:

WH>>На самом деле можно сделать совсем UNIX-way.

WH>>Пропустить всё общение через stdin и stdout процесса.
VD>Они текстовые.
Это не правда.
Их обычно используют для текста. Но там нет ничего что бы делало их текстовыми.

VD>И не уверен, что не синхронные.

using System;
using System.Console;

module Program
{
  Main() : void
  {
    using (cout = Console.OpenStandardOutput())
    {
      def arr = array(256);
      for (mutable i = 0; i < 256; ++i)
        arr[i] = i :> byte;
      def t1 = cout.WriteAsync(arr, 0, 128);
      def t2 = cout.WriteAsync(arr, 128, 128);
      t2.Wait();
      t1.Wait();
    }
  }
}

Запусти и направь вывод в файл.
Потом шестнадцатеричным редактором посмотри содержимое.
Там будут все байты в нужной последовательности.

VD>У нас для возврата сообщений две очереди. Одна псевдо-синхронная (для операций, которые требуют продолжения) и одна асинхронная.

Да хоть десять. Если в клиенте будет сидеть поток, который постоянно читает поток и распихивает сообщения по очередям всё будет прекрасно работать.

WH>>На производительности это не скажется.

VD>Возможно. Но это тоже надо проверять.
Нужно. Но там те же пайпы. Так что разницы быть не должно.

VD>Вот что, возможно, и надо было бы сделать, так это перейти на HTTP и JSON вместо именованных каналов и бинарной сериализации. Та же VS Code именно этими форматами пользуется. Плюс, гоняя текст, упрощается отладка.

На HTTP нельзя. Там на каждый запрос нужен ответ. Причем сторого в той последовательности в которой были отправлены запросы.
Что касается JSON то в VS Code не какой попало JSON, а вполне конкретный. И я не уверен, что наши сообщения могут быть 1 в 1 представлены в формате VS Code. Возможно там понадобятся некие пляски для того чтобы сгенерировать JSON в формате VS Code.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: [Nitra] Почему клинт-сервер?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.12.17 08:49
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>На HTTP нельзя. Там на каждый запрос нужен ответ. Причем сторого в той последовательности в которой были отправлены запросы.


Ну, вот в VS Code как-то сделано. Многие интеграции через него работают.

WH>Что касается JSON то в VS Code не какой попало JSON, а вполне конкретный. И я не уверен, что наши сообщения могут быть 1 в 1 представлены в формате VS Code. Возможно там понадобятся некие пляски для того чтобы сгенерировать JSON в формате VS Code.


Я так понимаю, что общение с сервером там точно такой же рукописный код написанный на Тайп Скрипте. Но вообще с этим надо разбираться, а времени нет.

Ты вот за генерацию кода парсера брался. Что-нибудь сделал?
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: [Nitra] Почему клинт-сервер?
От: Kolesiki  
Дата: 20.12.17 10:48
Оценка: +1 :)
Здравствуйте, VladD2, Вы писали:

VD>Просто тебе так хочется считать не смотря на аргументы.


Влад, мне не нужно "хотеть", мне достаточно увидеть хотя бы один весомый, технический аргумент (при отсутствии серьёзных недостатков), чтобы принять твою идею как здравую. Мы оба видим один и тот же предмет, но ты упорно считаешь слона удавом, держа его за хобот.

VD>1. Преодоление 32-битного адресного пространства Студии.


Мимо. Студия спокойно компилирует проекты любой мыслимой величины. То, что сама студия — отстоище на COM технологии — отдельная песня.

VD>2. Надежность.


Надёжность... эээ... по каким параметрам?? Вместо "программа-библиотека" ты ввёл "программа-RPC-библиотека", тем самым ухудшив надёжность лишним звеном.
А если ты про "упал парсер, но не упал редактор", то извини — это не метод разработки софта, ВСЁ должно быть подконтрольно и обёрнуто в try/catch. В любом случае, упавший парсер — это ПРОБЛЕМА, которую надо решать, а не дистанцироваться за клиент-сервером. От того, что редактор не упал, мне не легче — код всё равно нельзя редактировать!


VD>3. Переносимость между платформами и поддержка разных ИДЕ в будущем.


Уже обсуждали, не аргумент. Все эти "многоплатформенности" — миф, распыление сил на гетерогенные системы, где профита — ноль.


VD>4. Гарантированная изоляция представления от модели и как следствие удержание АМИ минималистическим, не тянушим лишних деталей.


Да мне пофиг эти изоляции — ты сейчас говоришь тупо про КАЧЕСТВО API, никакого отношения к "клиент-серверу" оно не имеет. Кроме того, RPC — лишь транспорт, любое API предоставляет только те методы, которые выставляет. К чему тут какие-то "изоляции"?


VD>5. Упрощение асинхронной, многозадачной реализации за счет использования модели акторов.


Асинхронность — вообще рядом стояла, причём тут опять "клиент-сервер"? Хочешь — можешь и с "программа-библиотека" написать такой же асинхронный код, кто мешает-то? Многонитевость — туда же. Да и "упрощения" я что-то не вижу — на обеих сторонах придётся аккуратно программировать потоки.


VD>6. Возможность реализации клиента на основе браузера.


О! Эт да... нам же тормозов мало — браузер закосячим! Потом портируем на Newton и МК-61. Браузер? Для разработки?? Знаешь, у меня хоть и мощный комп, но ни под каким видом я не хочу это убожество "отображатель гипертекста" превращать в элегантные шорты. Чистое баловство на фоне общего хайпа.


VD> Их отсутствие уменьшает конкурентоспособность Нитры.


Нитра — у неё, строго говоря, вообще нет конкурентов! Прикинь, сюрприз! Ты воюешь на танке против мельниц. Но надо понимать, что чем выше ты улетаешь в абстракции, тем дальше ты от задачи помола зерна. Нитра ценна сама по себе, своей сутью. А ты пытаешься сделать из неё попсовый гироскутер. Лучше сначала полностью реализовать самое ядро Нитры, а потом уже думать, принесут ли ей бенефиты остальные свистоперделки — браузеры, облака, линупсы и прочая местечковая буря в стакане.


K>>Рассуди как маркетолог, после ЖетБрынзы ты теперь это можешь: кому нужна многоплатформенность?


VD> Причем решарпер запихнули в такой же сервер и прикрутили к Идеее. ... Уж кто-то, а Джет коммерческая контора...


Влад, я уже это писал: "а вон те так делают" — не технический аргумент. Тем более, в таком болоте, как компания с многолетним легаси. То, что сначала изобрели телегу для лошади, а только потом — паровой двигатель, не делает "паровую телегу" королём дороги. Я не считаю их решение оптимальным, скорее — агония из-за неправильно выбранной стратегии.
(от себя лично: десяток раз ставил Решарпер и сносил к чертям — бессмысленная монстро-перделка с парой полезных фич, душащая мою IDE. Решарпер — это инструмент студоты, в проф. сегменте, да при всех возможностях VS, ему делать нечего.)


VD>Очевидно, что ты пропустил маленькое событие. За эти годы разработка для Веба стала доминирующей, а десктоп отошел на второй план.


Влад, ты штанины не подворачиваешь, случаем? Какой Веб, какие "доминанты"?? Виндуза как были, так и остались диктатором на десктопах. ВЕСЬ мой рабочий софт — чистые, незамутнённые Win API. Веб кажется "большим" в силу единственной причины — это параллельная вселенная, которой раньше не было, а теперь она разрослась. Её смысл — примитивные интерфейсы к большим системам, чтобы каждый задрот со смартом мог тыкнуть единственную кнопку на экране и возрадоваться курсу Биткойна. Веб никогда не был rich UI, это всегда позорные компромиссы и ограничения.
Но ладно, с чего-то вдруг ты сделаешь этот WebUI. Для кого? Что это за странный контингент одарённых шимпанзе, который не может поставить студию, но может писать макросы?? Да нас, "немерлистов", даже в ДотНЕТе — единицы, и те не все могут наладить безпроблемную среду (а я тебе говорил!). Веб никого не спасёт, всё равно полноценные проекты даже для библиотеки+GUI потребуют настоящей, нативной среды.


VD> Это снимает проблемы развертывания и администрирования клиентов.


А кого тебе понадобилось развёртывать?? Это компилятор, а не калькулятор! Специфическая вещь даже не для каждого программиста! Сделаешь качественный сетап — будут и пользователи. А прятать одни проблемы за другими — не поможет.


VD>Ну, еще в тренде мобилы. Но это опять не про МС, так как МС этот рынок слил.


Мобилы? Для компиляции Nitra?!


VD>И вот даже МС схватилась за голову и в спешке лепит .Net Core! На первый взгляд можно подумать, что это какой-то отдел нашел фатальный недостаток в дотнете и решил его исправить путем написания такого же дотнета, но другого. Но на самом деле они спасают шкуру компании, так как если не делать этого, то МС может и разориться.


Ты прав, Core — это агония. С одной поправкой — Core тоже не спасёт MS, новые вёсла не спасут тонущую лодку. Там проблема в людях, а не технологиях.


VD>Новая стратегия — захват облачного рынка.


С одним маленьким ньюансом: ни один чел на Земле не любит, когда его откровенно доят. Ни один сервер, даже за сущие копейки и при "неубиваемом, быстром Интернете" (несбыточная мечта), не сравнится с локальной копией, которая просто работает.


VD>Так что нужда в кроссплатформенности не мнимая, а самая что ни на есть реальная.


Только если ты нырнул в глубины этого глупого хайпа. Вернись на десяток лет назад — ВСЁ работало безо всяких облаков. Веб — чисто утилитарные клиенты для всё тех же серверов, к которым уже были нативные GUI-клиенты. Линукс — как был маргинальной дырой для траты времени — так и остался. Причём дыры, даже самые тупые, вылазят и по сей день. GUI и Линукс — вообще оксюморон. Apple — там делать нечего, анально огороженная секта. Ну и... какая кроссплатформенность, Влад? Винда даже в своих самых чистейших попытках быть "ещё и мобильной" провалила всё — "десятка" вошла в историю эпик фэйлом.


VD>Это никак не противоречит клиент-серверной архитектуре. Наоборот, серверу удобнее кэшировать все что надо. Обмен с сервером идет довольно редкими и крупными сообщениями. Так что на производительности это не сказывается.


Вот именно. Суть работы юзера — часто и малыми сообщениями. Ты это заворачиваешь в "редко и крупными". В этой связке явно кто-то пострадает — думаю, юзер. Собственно, ради которого ты и стараешься. Не видишь здесь противоречий?

Ещё раз: для каждого решения должно быть веское обоснование. "Нельзя просто так взять и вывернуть всё наизнанку!". Сначала — чёткое, доказанное обоснование потребности и только потом — её решение. А судя по аргументам, ты просто увидел где-то решение, словил пару "бенефитов" и на этом успокоился, даже не пытаясь скептически оценить, насколько это новое решение обоснованно в твоей задаче. Ну, тут я просто развожу руками! Ты — босс, тебе и отвечать за недальновидную растрату сил.
Кстати, ровно тем же занимается MS — вместо того, чтобы в поте лица развивать мобильную венду (на рынке которой уже МИЛЛИАРДЫ профита), они гоняют лысого и переписывают собственные ошибки. Только вот "работа над экзаменационными ошибками" уже не нужна, когда сам экзамен прошёл. хех....
Re[4]: [Nitra] Почему клинт-сервер?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.12.17 13:47
Оценка:
Здравствуйте, Kolesiki, Вы писали:

K>Влад, мне не нужно "хотеть", мне достаточно увидеть хотя бы один весомый, технический аргумент (при отсутствии серьёзных недостатков), чтобы принять твою идею как здравую. Мы оба видим один и тот же предмет, но ты упорно считаешь слона удавом, держа его за хобот.


Для того чтобы что-то понять, нужно иметь соответствующую компетенцию и опыт. У тебя их явно недостаточно. Но мнение ты имеешь (ц).

VD>>1. Преодоление 32-битного адресного пространства Студии.


K>Мимо. Студия спокойно компилирует проекты любой мыслимой величины. То, что сама студия — отстоище на COM технологии — отдельная песня.


Причем тут "компилирует"? Компилирует не студия, а компиляторы. Почти все компиляторы запускаются (сюрприз!) в отдельном процессе. По этому 32-битность Студии для них не проблема. А вот код обеспечивающий интеллисенс для языков работает внутри процесса. Причем так как Студия — это компонетный контейнер, кода такого загружается довольно много. Если одновременно встречается какой-нибудь РеШарпер и движок Розлина, а проекты имеют большой объем, то памяти начинает не хватать даже без сторонних компонентов. По сему движок Розлина и часть Решарпера реализованы как внешние процессы. Только ты об этом не знаешь.

K>Надёжность... эээ... по каким параметрам??


По сохранности кода. Вылет движка IDE, особенно, если память кончалась или стек переполнился, может спокойно привести к краху Студии с полной потерей не записанных изменений. Если же предполагается, что языки могут иметь пользовательские расширения, то данный вопрос становится еще более актуальным.

K>А если ты про "упал парсер, но не упал редактор", то извини — это не метод разработки софта, ВСЁ должно быть подконтрольно и обёрнуто в try/catch.


Попробуй на досуге в catch поймать переполнение стека.

K>Уже обсуждали, не аргумент.


Для тебя — возможно. Вот только проблема в тебе. Для тех кто думает на шаг вперед — это очень серьезный аргумент.

K>Все эти "многоплатформенности" — миф, распыление сил на гетерогенные системы, где профита — ноль.


Вот тебе простой пример — JetBrains Rider. Работает под Windows, macOS и Linux. Реализована в клиент-серверной технологии. Движок РеШарпера живет в серверном процессе, а "мордой" выступает IDEA.

Новый движок интеллисенса для C# от Майкрософт тоже реализован в отдельном процессе-сервере из тех же соображений.

Так что это не миф, а твое незнание.

K>Да мне пофиг эти изоляции


А мне не по фиг. И вообще, что либо объяснять тем, кому все по фиг нет даже желания. Кому надо поймет. А если тебе по фиг — проходи мимо.

K> — ты сейчас говоришь тупо про КАЧЕСТВО API, никакого отношения к "клиент-серверу" оно не имеет.


Имеет наимпрямейшее. АПИ предназначенный для клиент-сервера можно без проблем использовать локально. А вот наоборот — нет.

K>К чему тут какие-то "изоляции"?


К тому, что ошибиться не можешь. Нельзя случайно протащить лишнее. Даизайн получается сам собой. Границу разделения можно просто увидеть в одном файле. Уже никто не сможет "прикастить" какой-нибудь интерфейс к типу или вызвать что-то через рефлексию.

K>Асинхронность — вообще рядом стояла, причём тут опять "клиент-сервер"?


При том, что механизм используемый для межпроцессного взаимодействия — это и есть механизм обеспечения асинхронности. Ты выше RPC упоминал. Так вот никакого RPC мы не используем. Мы используем модель акторов. Почитай на досуге, что это. Вкратце — это механизм передачи сообщений и идеология асинхронного взаимодействия. С ее помощью по фигу в каком потоке работает агент обрабатывающий сообщения. Мы просто шлем сообщения в очередь и обрабатываем другую очередь содержащую ответы.

K>Хочешь — можешь и с "программа-библиотека" написать такой же асинхронный код, кто мешает-то? Многонитевость — туда же. Да и "упрощения" я что-то не вижу — на обеих сторонах придётся аккуратно программировать потоки.


Разберись с тем, что такое модель акторов. Тогда и упрощение увидишь. Она как раз и придумана, чтобы не надо было "аккуратно программировать потоки".

K>О! Эт да... нам же тормозов мало — браузер закосячим! Потом портируем на Newton и МК-61. Браузер? Для разработки?? Знаешь, у меня хоть и мощный комп, но ни под каким видом я не хочу это убожество "отображатель гипертекста" превращать в элегантные шорты. Чистое баловство на фоне общего хайпа.


Я понимаю, для тебя многое в новинку. Привыкай.

K>Нитра — у неё, строго говоря, вообще нет конкурентов! Прикинь, сюрприз!


Ты и тут блеснул компетенцией. Ну, знакомься c конкурентами. Там правда, всего два приведены. А их где-то с десяток.

K>Но надо понимать, что чем выше ты улетаешь в абстракции, тем дальше ты от задачи помола зерна. Нитра ценна сама по себе, своей сутью. А ты пытаешься сделать из неё попсовый гироскутер. Лучше сначала полностью реализовать самое ядро Нитры, а потом уже думать, принесут ли ей бенефиты остальные свистоперделки — браузеры, облака, линупсы и прочая местечковая буря в стакане.


Ядро давно работает. Вот только людям интересно интегрированное решение. Причем есть люди которым не нужен дотнет. А другие не хотят иметь дел с MS VS. Я делаю продукт, который если не сейчас, то по крайней мере в перспективе, можно будет перенацелить на другую IDE и перенести на другие платформы. Делать реализации для всех IDE я сейчас не собираюсь. Но возможность для этого я заложил. Каши она не просит. И кроме перенацеливания на другие платформы дает еще кучу возможностей. При этом недостатки у данного подхода несущественны.

K>Влад, я уже это писал: "а вон те так делают" — не технический аргумент.


Ты утверждал, что никому не надо. Я тебе привел примеры, что надо. Предлагаю больше не упомянуть ошибочные аргументы.

K>Тем более, в таком болоте, как компания с многолетним легаси. То, что сначала изобрели телегу для лошади, а только потом — паровой двигатель, не делает "паровую телегу" королём дороги.


Написал еще кучу текста в ответ, а потом поймал себя на слове, что трачу время впустую. Я привел достаточно аргументов, чтобы те хотел понять — поняли. У тебя явно недостаточно знаний, чтобы их понять, а часть ты просто забалтываешь неся не пойми что. Оставайся со своими заблуждениями дальше. Мне от этого ни горячо, ни холодно.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Отредактировано 20.12.2017 14:26 VladD2 . Предыдущая версия .
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.