LINUX.ORG.RU

Обдумываю концепцию новой кодировки

 , ,


0

4

Проектирую тут ЯП и дошло дело до UTF-8 и вот он мне, ну, совсем не нравится. В части графем и в части двубайтовой кодировки символов, которые вполне раньше были однобайтовыми в легаси системах. Наполовину не нравится отсутствие перехода за O(1) по произвольному индексу.

Поэтому идея сделать кодировку, где первый байт (в самой строке) определяет тип кодирования. Если это языки, которые в легаси кодировках могли в 1 байт, то в первом байте будет об этом указано. А если это винегрет из символов, то в первом байте будет указано перейти на проверку первых битов, чтобы определиться какой у нас символ однобайтовый или двубайтовы.

Но тут как в UTF-8, тогда не получится перемещаться по произвольному индексу за O(1). Можно винегрет кодировать весь двумя байтами (или даже 4-мя), указав это опять же в первом байте. И тогда проблема исчезает. И этот тип кодирования может задать принимающая символьные байты сторона - хочет так, а хочет вот так. В зависимости от дальнейшей задачи работы с этой строкой.

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

UPD 1 Добавил конкретики https://chatgpt.com/share/6a97d97d-3fac-83ed-af50-6022e8f635e2 Для Ъ Обдумываю концепцию новой кодировки (комментарий)

★★★★★

Последнее исправление: foror (всего исправлений: 4)
Ответ на: комментарий от ckotctvo

это ж блин редактор кода. на нем надо программы писать а не иероглифы корябать

А это еще одна отдельная проблема. Если допустить в этом редакторе использование юникода где-то кроме строковых констант то обязательно найдется кто-нибудь, кому захочется запихнуть юникодные символы например в имя переменной(программисты 1С как пример). И возникает вопрос - а какие символы в имени переменной допустимы и какие нет? Разные IDE имеют на эту тему разные мнения.

watchcat382 ★★
()
Ответ на: комментарий от qulinxao3

операционой оболочкой

Вот именно что не так уж и очевидно где проходит граница между «операционной системой», «оболочкой», «монитором», «библиотекой». Вон в микроконтроллерах вполне есть именно что библиотеки функций, реализующие многозадачность, и библиотеки, реализующие драйвер файловой системы (для флешек например). Если я подключу к своей программе такие библиотеки(и еще библиотеку вывода на экран) - получается что ее уже можно «операционной системой» называть? IBM же свой DOS так называет :)

watchcat382 ★★
()
Ответ на: комментарий от qulinxao3

Я уже определился. На текущий момент это просто соединение готовых кодировок под одним форматом, включая utf8. Но с возможностью в смешанном режиме кодировать одним байтом не только ascii. А создавать кодировку с нуля пока нет времени и не особо нужно сейчас.

foror ★★★★★
() автор топика
Ответ на: комментарий от watchcat382

прелесть естественного языка в туманности областей узусов

вон достопочтеный minix-родитель Таненбаум ваще считатл что ос это химера а всё есть слои всё более и более уточнённой/расширенной машины (это особенно в эпоху доступного любому прогеру микрокода и процессоров со шкафоф несколькоих)

поэтому так позновательно видеть контеризацию как решения бардака(бедлама)

qulinxao3 ★☆
()
Ответ на: комментарий от watchcat382

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

А тут еще вы с еще одной несуществующей проблемой. Есть редакторы кода где используются шрифты с фиксированной длиной и код написанный на человеческих языках. Есть юникод, где для кодирования вообще всех ероглифов и прочих буков надо порядка миллиона значений. Т.е. 20 бит из 32. 2бита на подчеркивание, четыре бита на тип символа, чтоб не дрыгать проверку каждый раз. 6 бит на тип окрашивания вполне хватает.

Не надо выдумывать изумительных проблем там где их нет.

ckotctvo
()
Ответ на: комментарий от watchcat382

Или придется английское,немецкое,французское и прочие варианты бувы «A» делать символами с разными кодами.

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

Кстати, «болгарское А» и «русское А» - это один и тот же код символа или нет?

тоже не знаток, но там выше приносили ссылку на статью, там как раз про болгарский есть пример и вот как минимум часть кодов совпадает, что и приносит неразбериху. Локаль никак не связана с текстом и приходится «угадывать» либо надеятся на какие-то метаданные. Если я правильно понимаю, это делает практически невозможными написать в одном сообщении и на русском и на болгарском так, то бы в конечном результате начертания символов были разные

user_undefined ★★
()

Короче прекрати херней страдать. Я тут уже написал что 20 бит хватит для всех хероглифов и прочей лабуды.

Плюс 12 бит на прочее что надо кэшировать.

Большинство файлов исходников меньше 1000 строк, и 99% меньше 10к строк. Каждая строка в среднем не более 50 символов. То есть в подавляющем большинстве случаев тебе хватит тупо буфера в одну строку и вектора с индексами строк для быстрого поиска. И самого тупого и неоптимального алгоритма! Если нужно лучше, можно simd с movnta приделать для перебора строки.

Но думать надо дальше. Ты много видел функций или методов длиннее 100 строк? Может начать в проектировании с того что проект это не набор файлов а база данных и в ней есть поля-функции-методы-классы и что там еще.

ckotctvo
()
Ответ на: комментарий от user_undefined

Для отображения символа нужен индекс глифа. Он однозначно берется из шрифта по юникодному номеру. Максимум там надо несколько глифов совместить но с учетом

А)подсветки кода

Б)невозможности побуквенной подсветки буков в Qt и GTK

рисовать придется побуквенно в любом случае

ckotctvo
()
Ответ на: комментарий от ckotctvo

выдумал несуществующую проблему.

Насущная проблема кодировать кирилицу одним байтом, а не двумя. Перевод кирилицы обратно в один байт для БД это огромная экономия. Для кеширующего сервера это огромная экономия по памяти. Для поиска и сортировки будет выигрыш.

foror ★★★★★
() автор топика
Ответ на: комментарий от ckotctvo

Это вообще не для редактора. Мой редактор будет работать не с текстом, а со снипетами. Каждая строка это очень короткий список снипетов. В ЯП на выходе нет текста, только бинарное AST дерево в качестве исходного кода.

foror ★★★★★
() автор топика
Ответ на: комментарий от foror

Херово тебе наверно с жестким диском на 2 гигабайта. Я ж тебя помню. Ты уже кажется второй раз за месяц меня какой-то бараньей упоротостью поражаешь. Зачем ты так делаешь?

Подумай какую задачу ты хочешь решить. Сколько усилий ты потратишь. На несовместимое ни с чем поделие. Ради чего. Тебе не заплатят за русские символы в 1 байт. Зачем ты тратишь свое время?

ckotctvo
()
Ответ на: комментарий от foror

А вводить текст ты будешь через libastral. Не забудь обновиться, в новой версии как раз завезли сниппеты

ckotctvo
()
Ответ на: комментарий от ckotctvo

Подумай какую задачу ты хочешь решить

Создаю фундамент под будущие задачи из огромного списка моих идей. Текущие инструменты не вытягивают.

foror ★★★★★
() автор топика
Ответ на: комментарий от qulinxao3

PEG

А зачем PEG? Оно же для парсинга, а не формат хранения кода в виде дерева. А парсинг кода кастомный без всяких регулярок и прочих заготовленных шаблонов.

foror ★★★★★
() автор топика
Последнее исправление: foror (всего исправлений: 1)
Ответ на: комментарий от foror

Чел я еще раз говорю твою ты энергию да в мирное русло. Подумаю ТУ ЛИ ЗАДАЧУ ты решаешь. Может быть надо сесть обдумать. Как мы можем переосмыслить кодинг в принципе. Мне с телефона писать длинные телеги в лом но подумай в сторону базы данных

ckotctvo
()
Ответ на: комментарий от ckotctvo

подумай в сторону базы данных

Я пилю на базе своего опыта. Сейчас потихоньку сбрасываю на гитхаб из своих черновиков. Как всё досбрасываю выложу ссылку для стороннего свежего взгляда. А так я не понимаю зачем исходному коду нужна СУБД. Не, понятно, что классы со всеми потрохами я не тупо в файлах буду хранить. Всё будет проиндексировано и разложено в виде БД, которую редактор будет подтягивать и преобразовывать БД в текст конкретных классов.

foror ★★★★★
() автор топика
Ответ на: комментарий от foror

Подумай вот над чем. Благо ты меня сподвиг подумать тоже. Не нужны файлы. Что если например класс это таблица в БД. В нем есть метод и его декларация это строка плюс опционально разобранные данные для ускорения поиска плюс ссылка на таблицу с кодом.

Я лишь предлагаю

Если ты решил идти по пути файлов то привет тебе на дороге боли. Где парсер который должен успевать парсить должен реально успевать

ckotctvo
()
Ответ на: комментарий от watchcat382

По мне так юникод должен просто содержать все символы по одному разу, т.е. у всех языков будет «а» с одним кодом, у всех на основе латиницы «z» тоже единый код. А локали должны указывать что вот в этом языке такое подмножество символов и сортируются они вот так.

ptah_alexs ★★★★★
()
Ответ на: комментарий от ptah_alexs

юникод гадость. там есть нормализованные и денормализованные представления. но для работы с кодом достаточно нормализованного представления и насрать на голову тем кто пользуется всякими волшебными наборами символов.

ckotctvo
()
Ответ на: комментарий от ckotctvo

Ну, если БД, тут можно и блокировки в реальном времени на методы и классы делать, чтобы избегать конфликтов при совместной разработке.

foror ★★★★★
() автор топика
Ответ на: комментарий от ckotctvo

так не берется же однозначно, не? русская и болгарская «к» имеет одинаковый код и и единственный способ понять как именно ее отрисовать - из локали, о которой приложение должно как-то догадаться

user_undefined ★★
()
Ответ на: комментарий от user_undefined

Приложение может системную локаль посмотреть. Вот только нафига это всё? У меня только английская локаль стоит. Каждый алфавит должен быть разделён на группы, даже если символы пересекаются, всё равно ему отдельный код и в отдельную группу. И каждой группе назначить нужную локаль. Допустим зашитая в систему таблица с диапозонами кодов.

foror ★★★★★
() автор топика

UTF-8 гениален. Ничего лучше придумать просто невозможно. Нужно брать и использовать его как есть.

vbr ★★★★★
()
Последнее исправление: vbr (всего исправлений: 1)
Ответ на: комментарий от watchcat382

Чем человек, учивший программирование четверть века назад в вузе в качестве непрофильного предмета и изрядно забывший даже то что учил - да, может быть.

питонячие и баш скрипты - ИИ очень хорошо пишет ну а если пару раз его пнуть то и вообще хорошо )

x905 ★★★★★
()
Ответ на: комментарий от ckotctvo

с еще одной несуществующей проблемой

Тем не менее проблемы у юникода есть и это признается даже официально. Но никто пока что не знает как их решить так чтобы не сделать хуже.

6 бит на тип окрашивания вполне хватает.

А с чего вдруг цвет букв должен быть засунут в код символов? В одном тексте могут использоваться буквы разного цвета и даже с какой-нибудь градиентной заливкой - это же получатся тысячи вариантов для каждой буквы.

watchcat382 ★★
()
Ответ на: комментарий от user_undefined

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

Мне вот тоже кажется такой подход более правильным.Если уж авторы-идеологи юникода провозгласили идею запихать в него все символы всех существующих языков то надо четко придерживаться заданного курса. Тем более что визуально похожих символов там и так уже огромное количество. Есть языки, у них есть утвержденные алфавиты, вот их все и закодировать - вполне логично как мне кажется. Уверен что 32 бита на все хватит, особенно если не пихать туда всякие картинки, не имеющие отношения к буквам. Это действительно упростит отображение символов.

отдельно локаль не нужна будет, и так каждый символ будет относиться к какой-то локали

Локаль всё равно нужна - для направления письма, сортировки по алфавиту, преобразования верхний/нижний регистр например. Другое дело что ее будет существенно проще угадывать - прямо по кодам символов.

watchcat382 ★★
()
Ответ на: комментарий от user_undefined

Зачем тебе их различать если они одинаковые? Код на английском пишут. Или мы тут обсуждаем редактор православного языка программирования?

ckotctvo
()
Ответ на: комментарий от ptah_alexs

у всех языков будет «а» с одним кодом

Беда в том, что в разных языках начертание букв может несколько отличаться. Выше уже приводили в пример «м» и «m». И даже упоминали русский и болгарский, которые хотя и оба используют кириллические буквы но тоже есть отличия. Говорят, с начертанием иероглифов всё еще хуже в этом смысле в разных странах из тех что их используют.

А локали должны указывать что вот в этом языке такое подмножество символов и сортируются они вот так.

В том-то и дело что совмещение похожих букв разных языков под одним кодом всё равно от необходимости локали не избавляет, а только добавляет проблем и не дает никаких плюсов кроме «экономии байтов», актуальность которой давно уже весьма сомнительна.

Впрочем - есть куда более сложная проблема: считать ли «букву» и «букву с крышкой» разными символами или кодировать букву и крышку отдельными кодами и потом склеивать при отображении, что порождает кучу сложностей. Причем если самих букв с диакритическими знаками не так уж много, то например символ ударения может быть поставлен над любой гласной.

Увы - хорошего ответа на этот и ряд других вопросов я не знаю. Зато я уверен что компьютеризация повлияет на естественные языки ничуть не меньше чем внедрение типографских станков когда-то.

watchcat382 ★★
()
Ответ на: комментарий от x905

На питоне не пробовал(надобности не было), а для написания баш скриптов сам ИИ использую. Да, пишет хорошо, но что-то небольшое. С трудом представляю сколько его пришлось бы пинать чтобы он родил что-то размером с configure от крупного пакета.

Основная проблема в том, что для правильного написания программы нужно полное и точное техзадание. Которые по объему окажется таким что не влезет на вход ИИ. Во всяком случае ограничения на размер запроса у известных мне чат-ботов весьма не велики. А в отсутствии точных указаний ИИ начинает импровизировать и делает это «не по-человечески». Потому что при недостатке четких указаний человек способен руководствоваться «здравым смыслом»(жизненным опытом, общим уровнем образования,контекстом задачи), а у ИИ с этими вещами плохо. Да, ИИ знает много, но он без явного указания не сообразит где и какие из этих знаний надо применить.

watchcat382 ★★
()
Ответ на: комментарий от watchcat382

для написания баш скриптов сам ИИ использую. Да, пишет хорошо, но что-то небольшое

ну да, как скрипт баша становится большим, перехожу на питон ) питона на 50кб кода он вполне норм пишет, както работает

x905 ★★★★★
()
Ответ на: комментарий от thunar

Я за бан.

А я вас всех в свою тетрадку записал, в лицензии поименно составлю чёрный список с запрещением на пользование.

foror ★★★★★
() автор топика
Ответ на: комментарий от pasquale

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

Только так и работают некоторые языки, за всех не говорю. В винде UTF-16 и его двухбайтная кодировка охватывает весь диапазон, с определением позиции ни векторами, ни глафами, ни поинтами, а на чистой математике, надо на 15 символов сместится, умножай на 2 и получишь позицию в байтах. А если вы там сломались на редакторе, берите Scintilla, кроссплатформенный движок с доступом к символам по позициям (собственными функциями), с хранением текста в UTF-8. Вот сейчас специально гуглил где располагаются китайские иероглифы и каким то способом они располагаются внутри двух-байтной кодировки. Там ещё есть какой-то диапазон суррогатных символов между D800 и DFFF, а так на этой кодировке работают во всех странах и ни у кого ничего не ломается.

AZJIO
()
Ответ на: комментарий от watchcat382

Только вот путать О латинское и О русское это не мешает.

Я даже «с» не путаю, во первых слежу за раскладкой, во вторых прога переворачивает в правильную, в том числе и «с», в третьих в редакторе есть подсветка, если чей-то мусорный текст попался мне в редактор после какого нибудь файнридера или ещё чего, то подсветка сразу покажет.

AZJIO
()
Последнее исправление: AZJIO (всего исправлений: 1)
Ответ на: комментарий от watchcat382

Букв b или z в русском нет, а вот почему русское «а» имеет не такой код как английское «a» ? Почему английское «a» и немецкое «a» могут иметь одинаковый код, а русское должно иметь другой? Какая логика в этом?

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

AZJIO
()
Ответ на: комментарий от watchcat382

в «компьютерных» шрифтах по сей день часто встречается перечеркнутый ноль чтобы с буквой О не путали.

Только в языках предназначенных для программирования, чтобы явно показать отличие. Кстати, англосаксы не могут ввести русское «О» на клавиатуре методом опечатки или неверной раскладки, поэтому им как-то ровно, что для вас это проблема.

AZJIO
()
Последнее исправление: AZJIO (всего исправлений: 1)
Ответ на: комментарий от watchcat382

Нахера ему локаль?

Потому что как выше заметили начертание одинаковых букв

Да просто изначально не надо кривую кодировку делать с экономией двух байт.

AZJIO
()
Ответ на: комментарий от user_undefined

Хотя в том же utf-8 дохренище свободных кодов

Что-то мне кажется, что сам формат подразумевает бесконечность. Гугл говорит, что ввели ограничение UTF-8 ради полной совместимости с UTF-16. А по факту если символ декодируется методом нуль-терминированного символа, то запихать туда можно сколько угодно, главное в конце нолик добавить, что символ завершился.

AZJIO
()
Ответ на: комментарий от watchcat382

Так в том-то и дело что видя юникодный символ «A» но не имея информации о локали - мы не может сказать к какому языку он относится.

То есть вы хотите, чтобы «Арбуз» было написано в виде «А(русское)р(русское)б(русское)у(русское)з(русское)»?

AZJIO
()
Ответ на: комментарий от foror

Не совсем понимаю, экономия на байтах что-ли? Хранить в cp12xx и потом получить проблему несовместимости, откроет англосакс ваш сниппет и получит ?????. Тогда нужен преобразователь ANSI->UTF-16 с распознаванием кодовой страницы. Тогда кодовую страницу надо указывать и модуль иметь, который умеет из неё преобразовать символы в UTF-16, то есть все таблицы преобразования иметь в комплекте для каждой кодовой страницы.

AZJIO
()
Ответ на: комментарий от foror

Для поиска и сортировки будет выигрыш.

Для сниппетов нужна ли сортировка? Гораздо удобнее фильтр/поиск с разными условиями поиска. Ввёл имя, получил список подходящих под описание. Какой чел в здравом уме будет разглядывать несколько тысяч сниппетов просто ради посмотреть? И почему они при этом должны сортироваться?

Для кеширующего сервера это огромная экономия по памяти

А почему это должен быть сервер? На сервере можно просто синхронизировать базу сниппетов с локальной, если даты обновлений отличаются. Если база на сервере в течении 5 лет не обновлялась, то и от участников к серверу не будет ни единого обращения. Ну это в рамках экономии сервера.

AZJIO
()
Ответ на: комментарий от AZJIO

откроет англосакс ваш сниппет и получит ?????

Он его сможет открыть только в специализированном редакторе. А если захочет скопировать, то можно без проблем конвертнуть в utf8 на лету. Но это вообще не для редактора. Это больше для баз данных, где кирилицу хранишь двумя байтами, а можно хранить одним. Экономия на лицо. Но если в cp1251 ты этим одним байтом и ограничен, здесь же можно хранить и прочие символы хоть два, хоть четыре байта рядом.

foror ★★★★★
() автор топика
Ответ на: комментарий от watchcat382

Насколько большого размера требуется техзадание для написания такого объема кода?

И каким ИИ пользуетесь?

задание я формировал в процессе, скрипт проходит по исходникам и по одному отправляет их на анализ на api типа /chat/completions

сначала был дипсик копипастой в браузере, потом чуть изучил aider

чтото болшее чем такие скрипты я еще не осилил, изучаю ….

x905 ★★★★★
()

Посмотри научные статьи по этому вопросу в гугл сколар или на киберленинке. Как мне кажется, что это какая-то стандартная задача типа как уложить эффективно вещи в рюкзак. И скорее всего кодировки уже есть на любой случай жизни. Плюс строка - это все же не массив чтобы по индексам прыгать.

AntonyRF ★★★★
()
Ответ на: комментарий от AZJIO

англосаксы не могут ввести русское «О» на клавиатуре методом опечатки или неверной раскладки, поэтому им как-то ровно, что для вас это проблема.

Вот именно это и есть проблема - что для американцев нет никаких других языков кроме американского и поэтому их поддержка делается «на отвяжись» посредством костылестроения.

watchcat382 ★★
()
Ответ на: комментарий от AZJIO

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

Тем не менее, как выше уже было сказано, различия именно между языками - существуют. Даже между теми которые казалось бы используют один алфавит. Вот пример русского и болгарского: https://www.reddit.com/r/typography/comments/1ee2o69/a_handy_chart_showing_the_difference_between/ Вопрос лишь в том - можно ли их игнорировать? Русский текст, набранный болгарским шрифтом, остается понятным, как и наоборот. Поэтому вопрос о том коды каких букв каких языков можно совмещать, а какие нет - не так уж и прост. Это даже не считая политических причин когда кто-нибудь не захочет писать буквами соседней страны с которой у них там «вековая вражда». А таких в мире хватает.

watchcat382 ★★
()
  • Markdown
Пустая строка (два раза Enter) начинает новый абзац. Знак '>' в начале абзаца выделяет абзац курсивом цитирования.
Внимание: прочитайте описание разметки Markdown.
Используйте Ctrl-Enter для размещения комментария