s22>В качестве здравой идеи.... Сделайте на Нитре Котлин. Это не юмор, это путь к ресурсам.
Котлин это pet project как минимум одного из основателей JB. Для того чтобы нитру второй раз взяли под крыло — у отцов основателей должно произойти осознание косяка уровня того который ощутили в яндексе с кинопоиском, а скорее и побольше — всё-таки кинопоиском основатели яндекса не занимались и было кого объявить крайним.
Здравствуйте, hi_octane, Вы писали:
s22>>В качестве здравой идеи.... Сделайте на Нитре Котлин. Это не юмор, это путь к ресурсам. _>Котлин это pet project как минимум одного из основателей JB. Для того чтобы нитру второй раз взяли под крыло — у отцов основателей должно произойти осознание косяка уровня того который ощутили в яндексе с кинопоиском, а скорее и побольше — всё-таки кинопоиском основатели яндекса не занимались и было кого объявить крайним.
Так у меня и в мыслях не было предложить конкурировать с Котлин, я предложил создавать на Нитре Котлин!
Соответственно будет проще отлаживать и тестировать фишки и т д.
А удобство может перерасти в выделения на соответствующие доработки человеко часов в рабочее или не рабочее время.
s22>Так у меня и в мыслях не было предложить конкурировать с Котлин, я предложил создавать на Нитре Котлин!
Это и есть конкуренция. В компании уже вложены десятки тысяч человеко-часов в компилятор котлина. Признать целесообразность существования ещё одного компилятора на базе нитре, да ещё на таком уровне чтобы выделять на это дополнительные деньги — это признать что отказ от развития нитры был ошибкой, и одновременно что компилятор котлина имеет какие-то недостатки по сравнению с нитрой. Кинопоиск в чистом виде, только для яндекса кинопоиск был не таким уж важным проектом как котлин для JB, и принять решение всё откатить а менеджмент кинопоиска уволить было несравненно легче.
Здравствуйте, hi_octane, Вы писали:
s22>>Так у меня и в мыслях не было предложить конкурировать с Котлин, я предложил создавать на Нитре Котлин! _>Это и есть конкуренция. В компании уже вложены десятки тысяч человеко-часов в компилятор котлина. Признать целесообразность существования ещё одного компилятора на базе нитре, да ещё на таком уровне чтобы выделять на это дополнительные деньги — это признать что отказ от развития нитры был ошибкой, и одновременно что компилятор котлина имеет какие-то недостатки по сравнению с нитрой. Кинопоиск в чистом виде, только для яндекса кинопоиск был не таким уж важным проектом как котлин для JB, и принять решение всё откатить а менеджмент кинопоиска уволить было несравненно легче.
Опять ты немного не понял, я не особо верю, что котлин на нитре можно сделать быстрее(с точки зрения времени компиляции) чем то что сделано.
Я говорю, о тестировании фич. Кстати, кто то на форуме из разработки Котлина, когда еще Нитра была проектом Джейбрейна обращался с таким вопросом и ответ Влада был, если нужно пили сам, я постараюсь помочь.
Удачная среда дала бы шанс стать нитре как минимум внутренним проектом для Котлина.
Здравствуйте, VladD2, Вы писали:
VD>1. Межпроцесное взаимодействие не такая уж медленная вещь. Мы выбрали именованные каналы (Named pipes), которые в Windows являются самым быстрым интерфейсом.
Самый быстрый — shared mem. Пайпы, если локально, тоже поверх shared mem реализованы, но оверхед там довольно заметный.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, WolfHound, Вы писали:
VD>>А есть такое АПИ для коммуникации? Это просто общее название для работы с памятью в ОС. WH>https://msdn.microsoft.com/en-us/library/windows/desktop/aa366551(v=vs.85).aspx WH>Нужно только помнить, что MapViewOfFile в разных процессах может отобразить память на разные виртуальные адреса.
А на фиг мне нужны MMF? Ты читал бы вопрос внимательнее прежде чем отвечать. Мне нужно АПИ для коммуникации. Это АПИ должно не только данные шарить, но и передавать сообщения в том или ином виде. На эти сообщения должны запускаться некоторые действия в другом процессе. Вот сокеты или именованные каналы — это то что нужно. MMF может разве что сгодиться как база для велосипеда.
VD>>В микроскоп не увидишь. Вот здесь демонстрация скорости дебажной версии: VD>>https://twitter.com/VladDQ/status/804293400417726464 WH>Я думаю в данном случае ты даже TCP/IP через хороший интернет не заметишь.
На то и расчет был. Хотя, конечно чем быстрее работает связь, тем меньше лаги отрисовки. У меня там все асинхронное. Так что пока не приедет та же подсветка, измененный кусок текста будет "черным".
И зависит это не только от связи. Но и от оптимизаций. Именно по этому я тебя просил сделать инкрементальное редактирование.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, VladD2, Вы писали:
VD>>В микроскоп не увидишь. Вот здесь демонстрация скорости дебажной версии: VD>>https://twitter.com/VladDQ/status/804293400417726464 WH>Я думаю в данном случае ты даже TCP/IP через хороший интернет не заметишь.
Сейчас, конечно, уже поздно говорить, но имхо TCP/IP был бы более подходящим вариантом. Он более распространённый, а значит было бы легче портировать на другие IDE/платформы.
Здравствуйте, s22, Вы писали:
s22>Здравствуйте, hi_octane, Вы писали:
s22>Опять ты немного не понял, я не особо верю, что котлин на нитре можно сделать быстрее(с точки зрения времени компиляции) чем то что сделано. s22>Я говорю, о тестировании фич. Кстати, кто то на форуме из разработки Котлина, когда еще Нитра была проектом Джейбрейна обращался с таким вопросом и ответ Влада был, если нужно пили сам, я постараюсь помочь. s22>Удачная среда дала бы шанс стать нитре как минимум внутренним проектом для Котлина.
Нитра, кстати, очень быстро парсит/типизирует. Не знаю, насколько быстр самописный код Котлина, но вполне допускаю, что Нитра могла бы оказаться быстрее.
Здравствуйте, VladD2, Вы писали:
VD>А на фиг мне нужны MMF? Ты читал бы вопрос внимательнее прежде чем отвечать. Мне нужно АПИ для коммуникации.
Это и есть АПИ для коммуникации.
VD>Это АПИ должно не только данные шарить, но и передавать сообщения в том или ином виде. На эти сообщения должны запускаться некоторые действия в другом процессе. Вот сокеты или именованные каналы — это то что нужно. MMF может разве что сгодиться как база для велосипеда.
А никто не говорил, что это будет простым АПИ. Было сказано, что это самый быстрый АПИ.
Через каналы тебе придётся минимум два раза скопировать память и несколько раз потрогать ядро ОС.
Через MMF будет ноль копирований памяти и ноль обращений к ядру если сделать синхронизацию на интерлокедах. И только если данных долго нет можно уснуть на примитивах ОС.
В случае с нитрой это всё не нужно. Скорости каналов хватит за глаза. Но есть приложения, которым оно надо.
VD>На то и расчет был. Хотя, конечно чем быстрее работает связь, тем меньше лаги отрисовки. У меня там все асинхронное. Так что пока не приедет та же подсветка, измененный кусок текста будет "черным".
Локально разницы между ТСР и пайпами нет вообще.
VD>И зависит это не только от связи. Но и от оптимизаций. Именно по этому я тебя просил сделать инкрементальное редактирование.
Это разные задачи.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, ionoy, Вы писали:
I>Сейчас, конечно, уже поздно говорить, но имхо TCP/IP был бы более подходящим вариантом. Он более распространённый, а значит было бы легче портировать на другие IDE/платформы.
Там АПИ почти одинаковое.
Так что заменить одно на другое не проблема. Или даже абстрагировать и иметь оба варианта.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
VD>>А на фиг мне нужны MMF? Ты читал бы вопрос внимательнее прежде чем отвечать. Мне нужно АПИ для коммуникации. WH>Это и есть АПИ для коммуникации.
Ну, и как с его помощью предать управление в другой процесс?
WH>А никто не говорил, что это будет простым АПИ. Было сказано, что это самый быстрый АПИ.
Это вообще нее АПИ коммуникации.
WH>Через каналы тебе придётся минимум два раза скопировать память и несколько раз потрогать ядро ОС.
Мне ничего делать не придется. Все сделали программисты писавшие реализацию. Онаписали они ее очень качественно. Скорость очень высокая. Явно MMF и использовали для передачи данных, а сами уведомления реализовали через эффективные механизмы ОС.
И это стандартный АПИ присутствующий и в Моно, и в Кор, т.е. работать будет везде.
WH>Через MMF будет ноль копирований памяти и ноль обращений к ядру если сделать синхронизацию на интерлокедах. И только если данных долго нет можно уснуть на примитивах ОС.
Через MMF ничего не будет. Там просто нет механизма передачи управления.
Короче, не трать мое время по посту.
VD>>И зависит это не только от связи. Но и от оптимизаций. Именно по этому я тебя просил сделать инкрементальное редактирование. WH>Это разные задачи.
Это нужная, но не сделанная задача. Не сделанная тобой. Как и еще несколько. Чем развлекаться на форумах, помог бы довести продукт до ума. Ты уже два года ни одной строчки кода не написал, за-то лезешь советы давать.
Я выбираю те АПИ, которые считаю нужными. Обсуждать это я буду только с теми, кто вместе со мной хочет работать над проектом. Если ты следил за проектом, то должен был заметить, что этот АПИ я выбрал пол года назад. И выбрал именно по результатам испытаний.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Всё это весьма мозголомно но можно сделать так что работать будет так же быстро как в одном процессе.
VD>Это вообще нее АПИ коммуникации.
Оно самое. Просто очень низкого уровня.
VD>Это нужная, но не сделанная задача. Не сделанная тобой. Как и еще несколько. Чем развлекаться на форумах, помог бы довести продукт до ума.
Если ты думаешь, что накричать на меня что-то решит ты заблуждаешься.
VD>Ты уже два года ни одной строчки кода не написал, за-то лезешь советы давать.
Если бы это было так, то нитра вообще бы не работала от слова совсем.
VD>Я выбираю те АПИ, которые считаю нужными. Обсуждать это я буду только с теми, кто вместе со мной хочет работать над проектом. Если ты следил за проектом, то должен был заметить, что этот АПИ я выбрал пол года назад. И выбрал именно по результатам испытаний.
Я ни разу не сказал, что нужно перевести нитру на MMF.
Более того я явно сказал, что не нужно это делать.
Но ты же опять включил режим берсеркера и не читаешь что тебе пишут.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Ну, на хрена мне эту логику выписывать, если есть готовые пайтпы? Почему ты считаешь, что ты напишешь ее эффективнее орлов из МС? И зачем ее вообще повторять?
WH>Всё это весьма мозголомно но можно сделать так что работать будет так же быстро как в одном процессе.
Это идиотизм. Особо быстрее пайпов не получится. Если даже и выиграешь копейки, то не ясно зачем это надо.
WH>Если ты думаешь, что накричать на меня что-то решит ты заблуждаешься.
Я думаю, что ты убиваешь время. Убивай его в одиночестве.
Мне на фиг не нужны подобные советы. Если тебе не чем убить время напиши свой велосипед поверх MMF. Но меня этим не донимай.
VD>>Ты уже два года ни одной строчки кода не написал, за-то лезешь советы давать. WH>Если бы это было так, то нитра вообще бы не работала от слова совсем.
Это так. Посмотри на свои комиты. Ты ни хрена полезного за два года не сделал. Взялся за инкрементальный парсинг, но и его не доделал. Зато выносишь мне мозг на хрен не сдавшимися велосипедами.
WH>Я ни разу не сказал, что нужно перевести нитру на MMF.
А на фига тогда вообще было что-то говорить? Что такое MMF я не хуже тебя знаю. Это не комуникационный АПИ, а всего лишь средство разделения странци памяти между процессами. Чтобы сделать поверх него протокол, нужно залудить не хилы велосипед. И быстрее пайпов вряд ли выйдет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, ionoy, Вы писали:
I>Сейчас, конечно, уже поздно говорить, но имхо TCP/IP был бы более подходящим вариантом. Он более распространённый, а значит было бы легче портировать на другие IDE/платформы.
Пайпы были в юниксах когда TCP/IP еще в проекте не было. Они есть везде. По верх сокетов они работают. Ну, и перевести на сокеты не долго.
Короче, обсуждать нечего.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, hi_octane, Вы писали:
s22>>Так у меня и в мыслях не было предложить конкурировать с Котлин, я предложил создавать на Нитре Котлин! _>Это и есть конкуренция. В компании уже вложены десятки тысяч человеко-часов в компилятор котлина. Признать целесообразность существования ещё одного компилятора на базе нитре, да ещё на таком уровне чтобы выделять на это дополнительные деньги — это признать что отказ от развития нитры был ошибкой, и одновременно что компилятор котлина имеет какие-то недостатки по сравнению с нитрой. Кинопоиск в чистом виде, только для яндекса кинопоиск был не таким уж важным проектом как котлин для JB, и принять решение всё откатить а менеджмент кинопоиска уволить было несравненно легче.
Да ладно. Ты почитай этот тред, особенно мессаги Влада. Тут сразу все объяснения, и про 'маркетинг', и про 'команду', и про 'менеджмент'. 'Мы работали' плавно превратилось в обвинения 'ты нихрена не делал' с подсчетом заслуг в строчках кода. Это было заметно и в прошлый раз, теперь только более в явной форме. Это очень токсичный стиль руководства. Собственно этот стиль Влад демонстрирует во всех его проектах.
Что касается самой нитры, то Влад повторяет ровно тот же подход, который и приводит к смерти большинство стартапов — вместо продвижения пилит фичи. Инвесторы имеют обыкновение избавляться от таких вот стартапов.
Собтсвенно, нечего удивляться, что JB поступило вот так.
Здравствуйте, ionoy, Вы писали:
WH>>Я думаю в данном случае ты даже TCP/IP через хороший интернет не заметишь.
I>Сейчас, конечно, уже поздно говорить, но имхо TCP/IP был бы более подходящим вариантом.
Пока нет внятной монетизации, нужно заниматься продвижением, а не оптимизациями и всякими баззвордами.
Продукты дохнут в основном из за маркетинга. 'Не те баззворды' почти никогда не являются причиной смерти ни продуктов ни, тем более, стартапов.
Здравствуйте, VladD2, Вы писали:
VD>Я выбрал не TCP, а именованные каналы из-за того, что они по шустрее при межпроцессном взаимодействии. Но думаю, что все будет приемлемо пахать и по TCP и даже по сетке. При тормозах сети будут некоторые задержки отрисовки, но не более того. Задержки до секунды будут вполне себе приемлемы. А найти латентность больше секунды сегодня не так то просто.
Для десктопного UI критичны задержки даже в пол-секунды. Для мышиных операций, всяких вещей связаных с прокруткой, выборкой из списка, и тд, фактически интеллисенс — даже четверть секунды будет много. Смотреть 8 часов кряду как запаздывает курсор или менюшки/списки удовольствие сильно ниже среднего.
VD>Потом одна из самых больших проблем Nemerle была в том, что мало кто мог написать сложный макрос.
