Вопрос по компиляторам/трансляторам

на юниксе кодировка utf-8

Юникс - это ОС 70-х годов, в ней не было utf-8.

И за мат сейчас минусанут хорошо. Лучше убрать пока никто не видит.

По сабжу - в коде на этом языке что, не-латинские буквы используются? У него операторы на русском? В чем проблема с utf-8.

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

да, есть операторы на русском языке

Это 1С?

мне кажется, что месяц-полтора ты будешь только в код въезжать.. не знаю, может это только я такой тормоз, конечно...

нет, это язык для асутп, для контролеров, можешь погуглить круг2000

так я уже там полгода работаю и уже въехал, как все работает, плюс есть бекграунд в виде книжки про компиляторы, так что с пониманием происходящего все ок))

можешь погуглить круг2000

без поллитры квадратола не обойтись )

А что мешает перекодировать файл в ср1251?

согласен)) но желательно по сабжу узнать мысли

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

а он есть в каком виде? исходники? описание?

PS тексты программ с оффтопика перекодировать ВСЕ РАВНО придется, так или иначе

там есть еще библиотека функций, типо как в с++ stl, и там есть типо файлы, которые описывают функции, и они не просто файлы, а бинарные, в них структуры записаны, и текст в струтктурах тоже в CP1251. Там просто как снежный ком катитться на меня, и я незнаю че с этим делать)))

Ой, чего там въезжать с современными ИИ. Проблема решается просто перекодированием файла в ср1251. Если очень хочется заморочиться, gsub("[\128-\255][\128-\255]) (луа, но суть думаю понятна). Не думаю что у него есть еще и на каком нибудь китайском операторы, а отловить кириллицу и латиницу и распознат это дело одной функции-однострочника.

исходники есть

исходники есть

так в чем проблема? вылаживай

По моему личному опыту (в свое время сделал интерпретатор простенького языка в академических целях) лексер и парсер языка с контекстно-независимой грамматикой довольно просто реализуются вручную, при этом такое решение даже будет гибче. Если хочется мнения, повесомее, чем от анонимуса с LOR, то Walter Bright (создатель первого компилятора C++ и языка D) высказывался в аналогичном ключе (см. раздел Implementation).

Вроде бы для парсинга Паскалеподобного языка не нужен большой lookahead (как для C), так что с дивана кажется, что рекурсивного нисходящего парсера в твоем случае может быть достаточно (а он довольно прост в реализации вручную).

Если бы это был хобби-проект, я бы однозначно посоветовал попробовать написать свой парсер. Но при наличии жестких сроков и отсутствии опыта, лучше основательно взвесить все риски. Хотя костыль у тебя уже есть и, я так понял, работает. Т.е. ты особо ничем не рискуешь.

на чём исходники-то?

форкни и портируй, чо там

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

эту работу (на перекат на новый анализатор) мне выделят месяц, максимум, полтора

Какой там объем кода? Ты начни делать, и через несколько дней поймёшь, хватит тебе месяца или нет.

мне выделят месяц, максимум, полтора

кароч e-bash под wine-ом и не парься )

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

В данный момент я костылю перекодированием с помощью iconv, но чую что это дичь))

Почему? У тебя основная проблема в том что нужно просто кушать исходники в кодировке отличной от utf-8, и вся задача сводится к просто к условию, если на входе CP1251 сконвертировать в utf-8 и передать дальше. Всё =)

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

или дальше костылить с перекодировкой строк.

Это не костыль, ОС много разных если несколько ОС являются целевыми, то ты не костылишь, а учитываешь платформенные особенности источников исходного кода, даже более того, у тебя заявлена явная обратная совместимость, так что это даже не учёт.

Внутри твоей реализации будет одна единственная кодировка с которой всё работает, внешнее к ней приводится если то требуется.

Я не спец, просто мимокрокодил

в данный момент так есть. но время работы тоже важно, плюс еще есть ФБД схемы, там просто пиздец…

Автор и написал, что подобный костыль он уже реализовал. Просто у него парсер работает в CP-1251, а в UTF-8 ему на вход могут в теории подать например emoji или вообще китайский - конвертер это не прожует.

а бинарные, в них структуры записаны, и текст в струтктурах тоже в CP1251.

Ааааа…

Причем свой маленький преобразователь делается в рамках самой софтины без сторонних зависимостей. Я ж в луа 3 года так работаю - давно себе всю работу с ютф переписал. Оказалось - вообще не сложно. Простейшая структура же.

цель сделать нативный проект, без вайна

Так не используй сторонние утилиты. Минималистичная низкоуровневая функция парсер. Работает мгновенно. Просто допиши в рамках утилиты.

верно!

Ааа.. Ну если работат надо не просто с операторами, а вообще с текстом, тогда хз хз.

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

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

цель сделать нативный проект, без вайна

быстро, дёшево, качественно

выбирай любые 2

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

Подожди. У него ср1251, в рамках которой эмодзи и всякие китайские не существуют. Тогда в чем проблема? Делаем простейший конвертор подходящих нам символов. Используем их. Остальное не в нашей компетенции в принципе и тут уже можно думать что с ними делать. Или отсеивать или заменять.

спасибо, вы пока самый адекватный из ответчиков))

Опиши что произойдет, если тебе подсунут текст на китайском, например? В рамках ср1251 такого быть не может чисто физически, например. Как ты его должен обработать? Мне уже интересно просто стало.

это замедляет работу транслятора просто в разы…

Все, вопросы отпали. Попробовал реализацию на раст - разница в 260 раз.

переписать этот транслятор на юникс, с сохранением поддержки старых проектов с винды.

Какую задачу пытаетесь решить? Почему не использовать то что есть?

сурьезные дядьки пишут свой лексер, и занимает он строк несколько сот. ну в районе 500-600 и меньше.

предлагаю не курочить какой-то там флекс, а просто написать свой лексер.

если знать как писать, ну это дня три на расслабоне.

найди в инете как пишутся лексеры, их в гитхабе наверняка немеряно.

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

поскольку будет уникод, то нужно брать wide_char.

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

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

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

и не ругайся матом.

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

вроде описалв саюже, если что то не понятно, спросите конкретно…

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

там, помнится, один прикрутил freeradius )

матом больше не буду, простите

А если, допустим, все это просто в wine заставить работать как есть?

Я тут поэкспериментировал на раст. Если вручную обрабатывать, то там разница практически незаметна:

--- Test: ASCII ---
Read UTF-8 directly: 2.136ms
Convert with encoding_rs: 2.622ms
Fast byte-level conversion: 6.482ms
Convert with iconv: 9.450ms

--- Test: Cyrillic ---
Read UTF-8 directly: 2.906ms
Convert with encoding_rs: 35.093ms
Fast byte-level conversion: 2.892ms
Convert with iconv: 7.831ms

--- Test: Mixed ---
Read UTF-8 directly: 1.368ms
Convert with encoding_rs: 17.427ms
Fast byte-level conversion: 2.782ms
iconv warning: "iconv: недопустимая входная последовательность в позиции 12240\n"
Convert with iconv: 819.765µs

--- Test: Emoji ---
Read UTF-8 directly: 2.512ms
Convert with encoding_rs: 71.829ms
Fast byte-level conversion: 7.765ms
iconv warning: "iconv: недопустимая входная последовательность в позиции 30192\n"
Convert with iconv: 976.654µs

--- Test: Digits ---
Read UTF-8 directly: 146.420µs
Convert with encoding_rs: 232.213µs
Fast byte-level conversion: 1.578ms
Convert with iconv: 4.277ms

--- Test: Punctuation ---
Read UTF-8 directly: 126.472µs
Convert with encoding_rs: 218.345µs
Fast byte-level conversion: 1.495ms
Convert with iconv: 4.230ms

--- Test: Long words ---
Read UTF-8 directly: 301.526µs
Convert with encoding_rs: 469.201µs
Fast byte-level conversion: 2.761ms
Convert with iconv: 7.348ms

--- Test: All together ---
Read UTF-8 directly: 2.972ms
Convert with encoding_rs: 43.406ms
Fast byte-level conversion: 6.322ms
iconv warning: "iconv: недопустимая входная последовательность в позиции 12528\n"
Convert with iconv: 891.437µs

--- Test: Empty ---
Read UTF-8 directly: 5.047µs
Convert with encoding_rs: 3.565µs
Fast byte-level conversion: 2.996µs
Convert with iconv: 566.670µs

--- Test: Very long line ---
Read UTF-8 directly: 99.324µs
Convert with encoding_rs: 210.339µs
Fast byte-level conversion: 1.384ms
Convert with iconv: 3.956ms

«В разы», да - но не в 260 раз уже.

в данный момент это и работает на вайне, и у всех производителей скад это только в вайне, мыже хотим типо первую нативнуйю реализацию, без вайна. И щас все активно юзают библиотеку open62541, они наверное в шоке, сколько у них форков)) И с вайном так же, наши ребята уже 5 багов в вайне пофиксили, связаные с gdi

не нашел, как просто написать сообщение, так что так… Все таки надеюсь нати человека, кто работал в flex и re-flex и расскажет в чем у них разница… Спасибо!