ну так то согласен… только с кем заниматься анализом? с теми кто устриц не ел...?
это не про вас… вообще про ситуацию…
то что вы описываете делают единицы, подсказать имеют возможность еще меньшее число (да их надо найти, им надо услышать, найти время на ответ, и чтобы вопрос им совсем ламерским не показался и наконец у них было время на ответ)
так что я может быть был бы и рад, но не люблю искать ответы в абстрактном гугле (очень и очень много времени уходит, и не всегда с результатом)
да и задачу надо было как то опробовать что ли алгоритмически, посмотрите исходный код — там много всяких заготовок, пробовал десятки вариантов пока нашел то что устраивает… и для этого хорошо это все пробовать на чем то простом, что знаешь и за примитивами к которому не нужно напрягать гугл, так как итак хватает алгоритмических и оптимизационных задач, чтобы еще терять время на задачи по осваивания не совсем понятного по возможностям нового языка в рамках работы плагином к какому то редактору… :-(
просто я реалист, начинать надо с чего то простого…
ну у меня подсветка реализована за счет выбора одного из внешних файлов правил… программа содержит в себе некий компилятор правил (как бы в байт код перевожу правила) и потом уже этот байт код делает парсинг текста
по подсветке — у меня происходит полный разбор синтаксиса команды, посмотрите на варианты LDR… это далеко не фильтр по регулярным выражениям с ключевыми словами для подсветки…
про возможности VSCode + TypeScript:
у меня каждый файл проекта имеет свои символы, инклудные символы, глобальные символы (передаются в проект), спсисок инклудных файлов
соответственно, когда нужно получить список символов доступных в текущем файле идет просто запрос по инклудным файлам (соответственно запрос может быть перенаправлен глубже по инклудам) + добавляются символы текущего положения + добавляются глобальные символы с проекта
на TypeScript вы видите как это реализовать? подсказка — парсить внешний файлы с нуля при запросе списка символов — капец какая плохая идея (быстродействию капут) — я загружаю и обрабатываю все файлы проекта, и потом просто файлы обращаются друг к другу для получения имен символов, адресов, и так далее… то есть если файл отредактировали и потом перешли к другому файлу — то при обращении к нему — он никаких действий по поиску списка символов (просмотру и парсингу себя), просмотру файлов инклудов — не делает, они у него уже готовые в списках лежат…
вот в таком режиме работы — работа с символами более менее прозрачная и обеспечивает нужное быстродействие…
если вы можете написать такое на type script — то можно подумать над дальнейшим и объединять усилия… а я не хочу начать изучать новое, и потом узнать что в обработке файлов каждый файл изолирован, и нужно чесать левое уже пять раз для каждого желания правого… программируя редактор с нуля я вообще не думаю о каких то ограничениях свыше…
ну и все эти хипстерские установки и допиливания редакторов меня вечно веселят… наверное это круто… поставить редактор и потом еще допиливать и допиливать тот или иной дополнительный функциональный блок…
тут все в одном, работает из коробки, ничего ставить (кроме дров для ст-линк) не надо… но оказывается мы вдруг стали все блондинками, и нам при разработке стразы нужны обязательно, хипстерский дизайн редактора всем нужен…
нужна функциональность, и еще удобство — это то что можно и нужно обсуждать… а использование модного редактора, и крутых свистоперделок, скинов, шрифтов и прочего — это не со мной… это к блондинкам, они оценят
не знаю, мне нравиться, хотя конечно по началу очень не привычно…
в принципе задумка первоначальная была вообще сделать конструктор инструкций, но потом сколько всего навалилось что ее реализовывать уже не стал :-(
ну могу открыть секрет полишинеля, сейчас многое скорее всего будет переписано на дотнеткор так что потом если будет действительно интерес можно будет морды рисовать хоть на плюсах хоть на минусах
только Win, причем сама среда позволяет компилировать под линукс, но в коде много Win зависимого кода…
да и нет у меня линукса, так что проверять не на чем и коль нет человека который бы решал те или трудности — то и заморачиваться я не буду (нет времени на это)
ну тут еще прямо скажем пробный камень… многие вещи что здесь реализованы я писал впервые, а по поводу дизайна — никто не задумывался что не все умеют делать красивые интерфейсы?.. у меня вот нет этого чувства гармонии и стиля… готов принять помощь…
но вообще конечно все буду переписывать наверное под WPF, сейчас интерфейс мне не нравиться, и многие задумки не знаю как реализовать на паскале
ну это же не за навальным бегать, за это на погоны звезды не упадут
вообще единственная правильная модель поведение это просто вешать трубку после такого звонка (не говоря ничего о себе) и потом перезвонить в банк… номер по которому звонить указан на оборотной стороне карты, обычно над магнитной полосой…
и желательно научить этому родителей
гм… а зачем 4-5 броузеров запускать одновременно?
да плюс фотошоп ?!!! и офисные программы ?!!! — одновременно ?!!! гм… это что обработка кучи фоток скачиваемых при помощи разных броузеров и с ведением реестра картинок с изменениями внесенными в них с включением одновременно информации в таблицу ?!!!
ну жесть, что я могу сказать :-)) особенно учитывая что невозможно использовать все эти программы одновремеено, у вас все равно 2 руки и 2 глаза :-), но понт наверное крутой :-))
p.s. это компьютер демонстратор что ли? я не могу себе представить профиль использования с таким набором программ…
у меня ноут с 16 гб, я не видел загрузки памяти более 10 гб… и это был капец какой-то по запущенным программам, как минимум половина из которых точно была не нужна для задач которые на компе в текущий момент исполнялись…
потому у себя и не стал дальше расширять память — просто нет смысла…
но у вас наверное какой то свой профиль использования, понятный вам и не понятным мне… :-)
это что же за броузер ?!
или у вас правило открытых 100 вкладок?
нет такого расхода в браузере… если использовать его нормально,
хром, 6 не самых легких сайтов со скриптами — 1 гб занятого озу, 12 вкладок — 1,273 гм… и так далее…
не вижу смысла в таком объеме памяти для браузера…
такая память нужна только для программ которые умеют ее использовать…
это любимая сказка всяких фсб-шников :-)) они вечно пугают что сигнал дескать с монитора может быть просканирован :-)))
при этом забывают сказать что если мониторов будет 2 то уже ничего просканировать не получиться, а если еще и расстояние будет более чем метр — так и вовсе это из разряда фантастики :-)))
нет, уравнивающие нужны только если вы генерите кадр на 625 строк
посмотрите по ссылке выше
жк телевизоры нормально обрабатывают и 625 строк и 312.
проверяйте длительность строчного гасящего, время до выдачи изображения, паузу после — вот это для жк действительно критично, у меня например один жк нормально переваривает длину сги до 8 мкс, а другой при 6 мкс уже не видит или изображение теряет стабильность
без комментариев
гм… прикольная идея…
это не про вас… вообще про ситуацию…
то что вы описываете делают единицы, подсказать имеют возможность еще меньшее число (да их надо найти, им надо услышать, найти время на ответ, и чтобы вопрос им совсем ламерским не показался и наконец у них было время на ответ)
так что я может быть был бы и рад, но не люблю искать ответы в абстрактном гугле (очень и очень много времени уходит, и не всегда с результатом)
да и задачу надо было как то опробовать что ли алгоритмически, посмотрите исходный код — там много всяких заготовок, пробовал десятки вариантов пока нашел то что устраивает… и для этого хорошо это все пробовать на чем то простом, что знаешь и за примитивами к которому не нужно напрягать гугл, так как итак хватает алгоритмических и оптимизационных задач, чтобы еще терять время на задачи по осваивания не совсем понятного по возможностям нового языка в рамках работы плагином к какому то редактору… :-(
просто я реалист, начинать надо с чего то простого…
для си — да, необходимо…
по подсветке — у меня происходит полный разбор синтаксиса команды, посмотрите на варианты LDR… это далеко не фильтр по регулярным выражениям с ключевыми словами для подсветки…
про возможности VSCode + TypeScript:
у меня каждый файл проекта имеет свои символы, инклудные символы, глобальные символы (передаются в проект), спсисок инклудных файлов
соответственно, когда нужно получить список символов доступных в текущем файле идет просто запрос по инклудным файлам (соответственно запрос может быть перенаправлен глубже по инклудам) + добавляются символы текущего положения + добавляются глобальные символы с проекта
на TypeScript вы видите как это реализовать? подсказка — парсить внешний файлы с нуля при запросе списка символов — капец какая плохая идея (быстродействию капут) — я загружаю и обрабатываю все файлы проекта, и потом просто файлы обращаются друг к другу для получения имен символов, адресов, и так далее… то есть если файл отредактировали и потом перешли к другому файлу — то при обращении к нему — он никаких действий по поиску списка символов (просмотру и парсингу себя), просмотру файлов инклудов — не делает, они у него уже готовые в списках лежат…
вот в таком режиме работы — работа с символами более менее прозрачная и обеспечивает нужное быстродействие…
если вы можете написать такое на type script — то можно подумать над дальнейшим и объединять усилия… а я не хочу начать изучать новое, и потом узнать что в обработке файлов каждый файл изолирован, и нужно чесать левое уже пять раз для каждого желания правого… программируя редактор с нуля я вообще не думаю о каких то ограничениях свыше…
ну и все эти хипстерские установки и допиливания редакторов меня вечно веселят… наверное это круто… поставить редактор и потом еще допиливать и допиливать тот или иной дополнительный функциональный блок…
тут все в одном, работает из коробки, ничего ставить (кроме дров для ст-линк) не надо… но оказывается мы вдруг стали все блондинками, и нам при разработке стразы нужны обязательно, хипстерский дизайн редактора всем нужен…
нужна функциональность, и еще удобство — это то что можно и нужно обсуждать… а использование модного редактора, и крутых свистоперделок, скинов, шрифтов и прочего — это не со мной… это к блондинкам, они оценят
в принципе задумка первоначальная была вообще сделать конструктор инструкций, но потом сколько всего навалилось что ее реализовывать уже не стал :-(
да и нет у меня линукса, так что проверять не на чем и коль нет человека который бы решал те или трудности — то и заморачиваться я не буду (нет времени на это)
но вообще конечно все буду переписывать наверное под WPF, сейчас интерфейс мне не нравиться, и многие задумки не знаю как реализовать на паскале
вообще единственная правильная модель поведение это просто вешать трубку после такого звонка (не говоря ничего о себе) и потом перезвонить в банк… номер по которому звонить указан на оборотной стороне карты, обычно над магнитной полосой…
и желательно научить этому родителей
да плюс фотошоп ?!!! и офисные программы ?!!! — одновременно ?!!! гм… это что обработка кучи фоток скачиваемых при помощи разных броузеров и с ведением реестра картинок с изменениями внесенными в них с включением одновременно информации в таблицу ?!!!
ну жесть, что я могу сказать :-)) особенно учитывая что невозможно использовать все эти программы одновремеено, у вас все равно 2 руки и 2 глаза :-), но понт наверное крутой :-))
p.s. это компьютер демонстратор что ли? я не могу себе представить профиль использования с таким набором программ…
у меня ноут с 16 гб, я не видел загрузки памяти более 10 гб… и это был капец какой-то по запущенным программам, как минимум половина из которых точно была не нужна для задач которые на компе в текущий момент исполнялись…
потому у себя и не стал дальше расширять память — просто нет смысла…
но у вас наверное какой то свой профиль использования, понятный вам и не понятным мне… :-)
или у вас правило открытых 100 вкладок?
нет такого расхода в браузере… если использовать его нормально,
хром, 6 не самых легких сайтов со скриптами — 1 гб занятого озу, 12 вкладок — 1,273 гм… и так далее…
не вижу смысла в таком объеме памяти для браузера…
такая память нужна только для программ которые умеют ее использовать…
спасибо за карму… я уже привык что мне ее минусуют :-))
он еще пишется, но уже может многое
при этом забывают сказать что если мониторов будет 2 то уже ничего просканировать не получиться, а если еще и расстояние будет более чем метр — так и вовсе это из разряда фантастики :-)))
посмотрите по ссылке выше
жк телевизоры нормально обрабатывают и 625 строк и 312.
проверяйте длительность строчного гасящего, время до выдачи изображения, паузу после — вот это для жк действительно критично, у меня например один жк нормально переваривает длину сги до 8 мкс, а другой при 6 мкс уже не видит или изображение теряет стабильность