Изучил вопрос, увы слишком сложный путь. Надо перехватывать ввод всего в системе (сейчас всё сделано без перехвата фокуса активного приложения специально), включая пароли, токены и всё-всё-всё. А это верный путь в бан у всех антивирусов.
Какие-то ещё оптимизации по ходу разработки помогли сократить размер. У NET11 как раз оптимизации на nativeAOT направлены, плюсы предполагаются, а риск небольшой. Сжимать не стал из-за антивирусов, чтобы они лишний раз сдуру не орали на приложение.
Я готовился к тяжёлой фазе с потоками захвата экрана и оркестрацией всего этого. Написать-то агентом всё это можно попробовать, но многочасовые сессии отладки этого зоопарка утомили бы мой энтузиазм очень быстро. Поэтому было ожидание от NET, что там всё более стабильно реализовано.
Не ожидал, что найдётся такое одно “волшебное API”. Теперь-то да, можно этот код попробовать портировать с целью уменьшения кода. Но в моём случае это скорее всего может быть Zig, который достаточно эффективен как C/C++, но не содержит боли и страданий.
И первые проблемы - если сборка падает, то мусор накапливается внутри storage.vhdx и не очищается через wslc image prune --all (там кеш только корректных образов). Нужно останавливать wslcsession + vmmemwslc* и удалять файл storage.vhdx вручную.
Такие случаи в CodeGraph/Socrati нормально не обрабатываются. Для корректной работы таких запросов нужен и связанный многогранный граф и семантическое соответствие и дополнительные алгоритмы поиска “часто используется рядом с…” с предразбивкой всего составного в коде на токены и потом прогон по новым найденным дополнительным графам в связке с семантикой и второй круг - совмещение всех графов в один с реранкингом. Если делать это “прямолинейно” на 200к строк, то потребует 30Гб RAM и один запрос будет 10 мин колбасить (слишком много прогонов по всему дереву с перебором). Конкретно когда я решал проблему, то было много “шаманства” на каждом этапе (их примерно десяток в этом запросе), но получилось до 50-100мс сократить.
Я делаю похожее приложение, но с нормальной семантикой, полным графом и стат анализом. А так же бесконечное undo любых изменений, линтинг, анализ разного рода, граф по документации в связке с кодом, автодокументирование кода. Первые версии на пользователях протестил, понял что нужна максимальная автоматизация установки и использования (установка докера, запуск конфигуратора - оказывается неподёмная задача для обычного пользователя). Через пару недель доведу до нормального вида и поделюсь.
Так вот, у меня на предварительной версии сейчас такие цифры по swift-репо (на ноутбучной RTX5060):
Парсинг 4 393 файла с кодом в 143 101 сущности с 458 201 связями (в 5 раз больше структурных данных чем в CodeGraph/Socrati) – 2,2 сек
Индексация с предобучением и записью в БД – 2.8 сек
Генерация 170 332 вектора ембеддингов – 38 сек. (4 376 emb/s) С учётом всех доп-процессов (prolly, trigram, etc) на все процессы от старта до завершения = 60 сек (инкрементные изменения 50-100мс).
4 минуты на базовые связи - это очень долго. Если запустить CodeGraph/Socrati на проекты типа postgesql, chromium, dawn, aspnet (3M LOC), то оно мне кажется помрёт в конвульсиях…
Всё гораздо сложнее в разработке таких приложений, чем просто взять доступный парсер и векторную бд.
А я наоборот, переношу на Zig проекты. Этакий “C++ для блондинок” и без привычного насилия.
Но регулярные сильно breaking changes мажорных релизов - это конечно больно. Вышел 0.16 - и переделывай все I/O-операции включая архитектуру (тысячи мест кода со сложной отладкой). Без ИИ тут не вытянуть.
Сделал новую версию montab 1.1.0:
Добавил работу с мульти-мониторами.
Добавил управление через трей.
Повторный левый клик на активный таб - перемещает его окно под остальные окна.
Правый клик на таб - сворачивает приложение.
Нотификации и другие микро-окна игнорируются.
Вернусь из отпуска к мультимониторам, разберусь. Пока нет возможности проверить.
Вероятно надо делать переключение только внутри данного монитора. И возможность панель иметь на нескольких мониторах сразу.
Изучил вопрос, увы слишком сложный путь. Надо перехватывать ввод всего в системе (сейчас всё сделано без перехвата фокуса активного приложения специально), включая пароли, токены и всё-всё-всё. А это верный путь в бан у всех антивирусов.
Какие-то ещё оптимизации по ходу разработки помогли сократить размер. У NET11 как раз оптимизации на nativeAOT направлены, плюсы предполагаются, а риск небольшой. Сжимать не стал из-за антивирусов, чтобы они лишний раз сдуру не орали на приложение.
Добавил скроллбар постоянный при наведении на панель, думаю что он хорошо помогает соориентироваться когда много чего открыто. montab v1.0.1
Я сделал вначале на NET10, но потом решил попробовать NET11 раз нет сервер-критикал работы. И это уменьшило размер бинарника на 500К.
Попробую сделать постоянный полупрозрачный с постоянной зоной активации, чтобы она не конфликтовала с крестиками закрытия.
Я готовился к тяжёлой фазе с потоками захвата экрана и оркестрацией всего этого. Написать-то агентом всё это можно попробовать, но многочасовые сессии отладки этого зоопарка утомили бы мой энтузиазм очень быстро. Поэтому было ожидание от NET, что там всё более стабильно реализовано.
Не ожидал, что найдётся такое одно “волшебное API”. Теперь-то да, можно этот код попробовать портировать с целью уменьшения кода. Но в моём случае это скорее всего может быть Zig, который достаточно эффективен как C/C++, но не содержит боли и страданий.
И первые проблемы - если сборка падает, то мусор накапливается внутри storage.vhdx и не очищается через wslc image prune --all (там кеш только корректных образов). Нужно останавливать wslcsession + vmmemwslc* и удалять файл storage.vhdx вручную.
Перешёл с docker buildx на wslc - работает быстрее и меньше потребляет. Где там создаётся кеш и как его чистить если что, пока не разобрался.
Что за фантастическая выдумка про XML vs JSON?
Такие случаи в CodeGraph/Socrati нормально не обрабатываются. Для корректной работы таких запросов нужен и связанный многогранный граф и семантическое соответствие и дополнительные алгоритмы поиска “часто используется рядом с…” с предразбивкой всего составного в коде на токены и потом прогон по новым найденным дополнительным графам в связке с семантикой и второй круг - совмещение всех графов в один с реранкингом. Если делать это “прямолинейно” на 200к строк, то потребует 30Гб RAM и один запрос будет 10 мин колбасить (слишком много прогонов по всему дереву с перебором). Конкретно когда я решал проблему, то было много “шаманства” на каждом этапе (их примерно десяток в этом запросе), но получилось до 50-100мс сократить.
TS-версия открытая. Zig-версия закрытая, рассматриваю её для корп рынка где репо 50M+ LOC
Я делаю похожее приложение, но с нормальной семантикой, полным графом и стат анализом. А так же бесконечное undo любых изменений, линтинг, анализ разного рода, граф по документации в связке с кодом, автодокументирование кода. Первые версии на пользователях протестил, понял что нужна максимальная автоматизация установки и использования (установка докера, запуск конфигуратора - оказывается неподёмная задача для обычного пользователя). Через пару недель доведу до нормального вида и поделюсь.
Так вот, у меня на предварительной версии сейчас такие цифры по swift-репо (на ноутбучной RTX5060):
Парсинг 4 393 файла с кодом в 143 101 сущности с 458 201 связями (в 5 раз больше структурных данных чем в CodeGraph/Socrati) – 2,2 сек
Индексация с предобучением и записью в БД – 2.8 сек
Генерация 170 332 вектора ембеддингов – 38 сек. (4 376 emb/s) С учётом всех доп-процессов (prolly, trigram, etc) на все процессы от старта до завершения = 60 сек (инкрементные изменения 50-100мс).
4 минуты на базовые связи - это очень долго. Если запустить CodeGraph/Socrati на проекты типа postgesql, chromium, dawn, aspnet (3M LOC), то оно мне кажется помрёт в конвульсиях…
Всё гораздо сложнее в разработке таких приложений, чем просто взять доступный парсер и векторную бд.
А я наоборот, переношу на Zig проекты. Этакий “C++ для блондинок” и без привычного насилия.
Но регулярные сильно breaking changes мажорных релизов - это конечно больно. Вышел 0.16 - и переделывай все I/O-операции включая архитектуру (тысячи мест кода со сложной отладкой). Без ИИ тут не вытянуть.
Да, только чем на них работать-то? OVMS несоизмеримо медленней любого CUDA-runtime.
"Мы сделали кроссплатформеное решение, которое надо компилировать под каждую платформу отдельно"
Привет, а почему не взяли что-то быстрое и готовое типа Janus?
У меня другая последовательность:
Создатель
Тренер
Стратег
После выхода из состояния "стартап" и перехода к сложным бизнес-процессам - никакого здоровья на менеджмент и "прямую курацию" не хватит.
Привет! Интересный прокет.
Вопросы:
TTL для записей есть? как реализован, если есть? Мне надо избавляться от старых записей без лишних телодвижений.
Как настраивается соотношение "в памяти" к "на диске"? Если в кубере запускать, то не надо заходить за лимиты.