OnlyOffice довольно неплохо принимается сообществом, совместимость с MS одна из лучших. Сам использую его уже давно, даже когда у меня ещё были ПК с Windows.
Специальной она является на уровне ОС и возможно MMU (Memory Management Unit). В обычных архитектурах есть регистр через который традиционно передается указатель на стек, и инструкции (push , pop) которые взаимодействуют с этим регистром. Но сам стек может распологаться в произвольном месте, определяемом ОС. С точки зрения машинного кода программы обращение к стеку зачастую эквивалентно обращению к какому-то адресу (за исключением спец инстркуций). C и С++ как языки не знают о стеке и куче, это детали реализации. В C++ есть storage duration, и переменные с automatic storage duration обычно хранятся на стеке, но они могут храниться напрямую в регистрах или вообще не быть материализованы. К куче доступ так или иначе производится через вызов системной функции, (обычно malloc) который может быть внутри operator new, std::allocator и т.п. Не уверен что имел ввиду автор под "автоматически управляется процессором", но за исключением нескольких инструкций для процессора стек - обычная область памяти, состоянием стека управляет программа, а выделением и контролем - ОС.
Инструменты делают ровно то, что в них заложил ремесленник ими управляющий. Результат работы инструментов предсказуем и повторяем. Задача "как сделать" всегда решалась человеком.
Модальность - ключевая особенность [нео]вима, которая позволяет эргономично работать без мышки, без извращений с Ctrl+Shift. Есть новое поколение модальных редакторов которые ещё не обзавелись плагинами, но уже имеют аудиторию показывает что эргономичность важна, а расширяемость ценой возможностей по умолчанию подходит не всем.
Большинство эффективных многопоточных структур сложны для понимания без участия ИИ. Для обеспечения производительности и корректности нужно довольно строго и точно понимать все переходы между состояниями, а со строгостью у LLM как раз проблемы насколько я вижу из отзывов. Довольно необычно если Ваш опыт говорит о полезности ИИ в данной задаче.
Интринсиксы намного удобнее в использовании чем ассемблер. И компилятор генерирует очень хороший код. std::experimental::simd просто пушка, очень жду C++26.
Короткий ответ: может. Клавиши обычно кофигурируются в виде матрицы, каждая строка и столбец матрицы требуют одного контакта микроконтроллера. В вашем случае микроконтроллере нужно минимум 8+5 цифровых пинов если делать обычную матрицу. Если не ошибаюсь, ZMK поддерживает виртуальные матрицы. Делается реальная матрциа близкая к квадратной, чтобы максимально эффективно использовать контакты, и она преобразуется в более удобную. Детали я не знаю, так как не занимался этим, но для 13 пинов 6x7 матрица даст 42 кнопок, а 5x8 даст 40. Каждая плата (которых может быть больше 2) конфигурируется отдельно, и теоретически может вообще содеражать независимые матрицы свитчей с независимыми слоями.
Насколько я понимаю Вы пробуете сделать нечто близкое к предлагаемому профилю memory safety?
Одна из основных критик данного профиля в невозможности реализации без аннотаций, хоть авторы и утверждают что аннотаций будет минимум. Я скорее разделяю мнение что без аннотаций это невозможно, но мне кажется что большинство из них должно быть в описании структур данных, то есть в библиотечном коде, что вполне допустимо. Поэтому в Вашем первом опросе я голосовал что безопасность только с плагином невозможна, так как потребует поддержки всей стандартной библиотеки.
Третий подход рассмотренный в статье мне кажется не очень правильным. Всё-таки получение итератора до функции меняющей состояние вектора - это ошибка программиста, и желательно ее детектировать и исправить. На мой взгляд второй подход может быть терпимым в отношении ложных срабатываний, если добавить список разрешенных методов для разных концептов контейнеров. Например, у contiguous контейнера операции доступа к элементам не должны инвалидировать память, а resize и reserve точно инвалидируют.
Ещё интересно, есть ли у вас привязка времени жизни слабой ссылки (например, внутри итератора) к времени жизни сильной ссылки?(Надеюсь я правильно применил термины которые вы используете для плагина) В memory safety профиле если не ошибаюсь благодаря такому слежению помимо предотвращения доступа после освобождения памяти этот механизм используется для контроля алиасинга. Это конечно снова требует аннотаций, но от этого не сбежать.
Других сплит клавиаутур у меня и знакомых не было, поэтому не могу сравнить. Я последние годы почти не играю, но недавно пробовал Deadlock, движение на WASD с цифрами совмещать без отдельного циферного ряда не самое удобное). Также мой друг отметил что в некотором ПО, в частнсти blender шорткаты неудобно нажимать одной рукой, а вторая занята мышкой. В остальном я очень кайфую от слоев, все символы доступны с минимальными движениями, поэтому лично для себя не вижу смысла в дополнительных клавишах.
1) Клон nice!nano с алиэкспресс, так проще всего найти 2) Половинки между собой только по беспроводу, с компьютером по bluetooth или по usb 3) Только один контроллер определятся как калвиатура, остальные не обмениваются данными по usb. 4) Прошивка zmk, у нее софт для конфигурации клавиш еще на очень раннем этапе. Y меня клавиши сконфигурированы старым способом и являются частью прошивки. Детальнее можно узнать из документации zmk 5) По ощущениям 2-3 недели, но я ни разу не делал хорошего измерения
Не видел, но могу посоветовать посмотреть каталог Alpine, они - очень крупный производитель кнопок, переключателей и энкодеров. Некоторые их устройства можно найти на Али. Кнопка ресета и переключатель в клавиатуре как раз от них.
Единственное применение энкодеров которое я нашел для себя - громкость и отключение звука по нажатию. Сейчас у меня для этого клавиши на отдельном слое. Возможно совсем немного менее удобно, но дискомфорта не испытываю. На алиэкспресс есть готовые corne (вроде V4) с дополнительными клавишами и\или энкодерами. На реддите видел хорошие отзывы про них.
Основная причина старой версии lua - это использование LuaJIT. Что также делает lua прекрасным выбором для плагинов.
OnlyOffice довольно неплохо принимается сообществом, совместимость с MS одна из лучших. Сам использую его уже давно, даже когда у меня ещё были ПК с Windows.
Специальной она является на уровне ОС и возможно MMU (Memory Management Unit).
В обычных архитектурах есть регистр через который традиционно передается указатель на стек, и инструкции (
push,pop) которые взаимодействуют с этим регистром. Но сам стек может распологаться в произвольном месте, определяемом ОС.С точки зрения машинного кода программы обращение к стеку зачастую эквивалентно обращению к какому-то адресу (за исключением спец инстркуций).
C и С++ как языки не знают о стеке и куче, это детали реализации. В C++ есть storage duration, и переменные с automatic storage duration обычно хранятся на стеке, но они могут храниться напрямую в регистрах или вообще не быть материализованы. К куче доступ так или иначе производится через вызов системной функции, (обычно malloc) который может быть внутри
operator new,std::allocatorи т.п.Не уверен что имел ввиду автор под "автоматически управляется процессором", но за исключением нескольких инструкций для процессора стек - обычная область памяти, состоянием стека управляет программа, а выделением и контролем - ОС.
Уже давно есть DAP ( debug adapter protocol) через который можно сделать удобный интерфейс для gdb и lldb. Используется в VSCode и прочих редакторах.
Успешно использую данный функционал для ежедневной отладки.
Инструменты делают ровно то, что в них заложил ремесленник ими управляющий. Результат работы инструментов предсказуем и повторяем. Задача "как сделать" всегда решалась человеком.
Довольно сильная разница если сравнивать с LLM.
Из поста на реддите - Kailh PG1316
Очень интересно было бы послушать про placement new, launder и лайфтаймы с точки зрения стандарта.
Казалось бы простая вещь: вызвать конструктор по адресу, но повсюду ждёт UB.
БПФ же как раз определен через рекурсию, реализовать его рекурсивно вовсе не сложно.
Я бы даже сказал что через рекурсию он понятнее, но это обсуждаемо.
Модальность - ключевая особенность [нео]вима, которая позволяет эргономично работать без мышки, без извращений с Ctrl+Shift. Есть новое поколение модальных редакторов которые ещё не обзавелись плагинами, но уже имеют аудиторию показывает что эргономичность важна, а расширяемость ценой возможностей по умолчанию подходит не всем.
LLM помог Вам в написании такой структуры?
Большинство эффективных многопоточных структур сложны для понимания без участия ИИ. Для обеспечения производительности и корректности нужно довольно строго и точно понимать все переходы между состояниями, а со строгостью у LLM как раз проблемы насколько я вижу из отзывов. Довольно необычно если Ваш опыт говорит о полезности ИИ в данной задаче.
Интринсиксы намного удобнее в использовании чем ассемблер. И компилятор генерирует очень хороший код. std::experimental::simd просто пушка, очень жду C++26.
Стоицизм
Короткий ответ: может.
Клавиши обычно кофигурируются в виде матрицы, каждая строка и столбец матрицы требуют одного контакта микроконтроллера. В вашем случае микроконтроллере нужно минимум 8+5 цифровых пинов если делать обычную матрицу.
Если не ошибаюсь, ZMK поддерживает виртуальные матрицы. Делается реальная матрциа близкая к квадратной, чтобы максимально эффективно использовать контакты, и она преобразуется в более удобную. Детали я не знаю, так как не занимался этим, но для 13 пинов 6x7 матрица даст 42 кнопок, а 5x8 даст 40.
Каждая плата (которых может быть больше 2) конфигурируется отдельно, и теоретически может вообще содеражать независимые матрицы свитчей с независимыми слоями.
Я думаю имеется ввиду новый api который позволяет реже использовать итераторы.
Насколько я понимаю Вы пробуете сделать нечто близкое к предлагаемому профилю memory safety?
Одна из основных критик данного профиля в невозможности реализации без аннотаций, хоть авторы и утверждают что аннотаций будет минимум. Я скорее разделяю мнение что без аннотаций это невозможно, но мне кажется что большинство из них должно быть в описании структур данных, то есть в библиотечном коде, что вполне допустимо. Поэтому в Вашем первом опросе я голосовал что безопасность только с плагином невозможна, так как потребует поддержки всей стандартной библиотеки.
Третий подход рассмотренный в статье мне кажется не очень правильным. Всё-таки получение итератора до функции меняющей состояние вектора - это ошибка программиста, и желательно ее детектировать и исправить. На мой взгляд второй подход может быть терпимым в отношении ложных срабатываний, если добавить список разрешенных методов для разных концептов контейнеров. Например, у contiguous контейнера операции доступа к элементам не должны инвалидировать память, а resize и reserve точно инвалидируют.
Ещё интересно, есть ли у вас привязка времени жизни слабой ссылки (например, внутри итератора) к времени жизни сильной ссылки?(Надеюсь я правильно применил термины которые вы используете для плагина) В memory safety профиле если не ошибаюсь благодаря такому слежению помимо предотвращения доступа после освобождения памяти этот механизм используется для контроля алиасинга. Это конечно снова требует аннотаций, но от этого не сбежать.
Других сплит клавиаутур у меня и знакомых не было, поэтому не могу сравнить. Я последние годы почти не играю, но недавно пробовал Deadlock, движение на WASD с цифрами совмещать без отдельного циферного ряда не самое удобное). Также мой друг отметил что в некотором ПО, в частнсти blender шорткаты неудобно нажимать одной рукой, а вторая занята мышкой. В остальном я очень кайфую от слоев, все символы доступны с минимальными движениями, поэтому лично для себя не вижу смысла в дополнительных клавишах.
Пробовал, но в итоге вручную в файлике делал, понятнее что-ли
1) Клон nice!nano с алиэкспресс, так проще всего найти
2) Половинки между собой только по беспроводу, с компьютером по bluetooth или по usb
3) Только один контроллер определятся как калвиатура, остальные не обмениваются данными по usb.
4) Прошивка zmk, у нее софт для конфигурации клавиш еще на очень раннем этапе. Y меня клавиши сконфигурированы старым способом и являются частью прошивки. Детальнее можно узнать из документации zmk
5) По ощущениям 2-3 недели, но я ни разу не делал хорошего измерения
Не видел, но могу посоветовать посмотреть каталог Alpine, они - очень крупный производитель кнопок, переключателей и энкодеров. Некоторые их устройства можно найти на Али. Кнопка ресета и переключатель в клавиатуре как раз от них.
Единственное применение энкодеров которое я нашел для себя - громкость и отключение звука по нажатию. Сейчас у меня для этого клавиши на отдельном слое. Возможно совсем немного менее удобно, но дискомфорта не испытываю.
На алиэкспресс есть готовые corne (вроде V4) с дополнительными клавишами и\или энкодерами. На реддите видел хорошие отзывы про них.