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

уже въехал, как все работает

там все просто

но есть вопросы:

1. Почему перед web-сервером firewall есть, а после - нет?
2. Зачем по обеим сторонам экрана коллективного пользования два принтера?

Во-первых, какое твоему транслятору вообще дело до кодировок? У тебя синтаксис языка на кириллице? Если так, говна тебе в тарелку. Но, даже если так, какая ему разница какая там кодировка? Работай просто с байтами, flex это умеет. Проблем не будет пока тебе не нужна какая-нибудь дичь типа регистронезависимости или матчить литералы длины ровно N кодпоинтов.

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

Во-первых, какое твоему транслятору вообще дело до кодировок?

там в блобах симболы от оффтопика )

это к отделу маркетинга, он делает сайты и картинки, могу номер дать

Так в любом случае вариантов всего два: или конвертировать, тогда будет не шибко большое замедление (чаще всего). Если даже небольшое замедление критично - переписывать. Какие еще варианты? Других нет.

Все таки надеюсь нати человека,

Сделаю за лям. Но распишешься сам )

я хотел спросить совета, кто работал с flex и re-flex, в чем разница, и так далее…

Рефлекс умеет юникод и стильный модный молодежный, если коротко. Гораздо круче, фичастее, быстрее.

а старый код от flex-а он скушает?

Чаще всего должен. Совместимость есть. Но это теория, я сам не пробовал.

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

вроде нет ничего такого, ну пока не видел…

Я бы потестировал сначала.

ну эт понятно, спасибо за ответ!

а тут развели хуйни на две страницы…

у тса есть исходники, flex, reflex а он нозги пудрит

Так я совета спросил, и мне уже его дали, ты то бы сразу сообразил бы, спору нет…

utf-8 совместима с ascii, так что если изначально всё с cp1251 работало и тебе не надо парсить непосредственно идентификаторы в не-ascii - на лексер это никак не повлияет. Да даже если надо - кто запрещает с utf-8 работать как и с обычной строкой, но чуть подлиннее? utf-8 даже парсить не надо, просто считать как последовательность байт

ну напиши код для flex, чтобы он понимал utf-8, че голословишь

У тебя синтаксис на кириллице там что ли? Если нет - то тебе должно быть пофиг какая там кодировка, просто байты 0x80-0xFF, какая разница скольким символам они соответствуют?

Опиши нормально в чём конкретно проблема. Вот запускаешь ты свой транслятор как есть, без правок, что происходит?

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

не нашел, как отредактировать сообщение, поэтому, отвечаю на добавленный вопрос так

не находит переменные и функции, потому что кодировка строк не совпадает

вы не читаете все сообщения в теме?

Только стартовое прочёл перед тем как отвечать. Теперь вижу, что тебе уже писали это несколько раз.

может нужно в топик добавить?

Конечно, это с самого начала надо было сделать, это же важный аспект задачи.

Проблема решается просто перекодированием файла в ср1251.

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

т.е вот мы берём наш линукс, компилируем под него этот транслятор и запускаем в линуксе. транслятор не будь дурак понимая что он в линуксе берёт файл и перекодирует в cp1251. и выдаёт нам бинарник программы. ну и в какой кодировке будет программа выдавать сообщения в консоль?

Ну я понял вобщем. У тебя есть какой-то старый код в cp1251 и есть новый в utf-8, в обоих имеется кириллица и надо чтобы компилятор понимал и слово «текст» в cp1251 и слово «текст» в utf8, и понимал что это одно и то же слово. Ну, тут нормальный вариант наверно только один. Лексер ни при чём.

Перед компиляцией старого кода конвертируй его из cp1251 в utf8 и дальше работай только в utf8. Тут могли бы быть проблемы, если бы идентификаторы были регистронезависимые (сравнивать букву А и а - это зависит от кодировки), но ты пишешь что у тебя регистрозависимость там, значит этот вопрос нас не волнует, идентификатор это просто последовательность байт, сравнивается побайтово. При этом надо как-то отличать cp1251 и utf8 исходники - это можно либо сделать автоопределением (оно не 100% надёжно, я бы не стал на него полагаться как на единственный источник инфы о кодировке), либо в новых проектах в начале файла писать какую-то условную строку-пометку о том что он utf8 (заодно поможет от случайного пихания его в старый компилятор).

язык для асутп на основе паскаля

ST что-ли ? :-)

в исходных текстах, которые на CP1251 поменять ключевые слова на стандартные (которые latin1) и будет двойное счастье - и переносимо и стандартам соответствует

PS/ проблему с flex так и не понял :-( скорее у вас просто синтаксис изначально неверно описан. Идентификатор это не [a-zA-Za-я]+ (как в школах учат) а любая хрень кроме пробелов,спец-символов и word-терминаторов или вообще любая фигня между ``.

да ST )) проблема еще есть (выше в сообщениях писал), что есть еще библиотека функций, там тоже все в кодировке CP1251, и если в ST пишешь функцию, то транслятор ее не находит, потому что он ищет по имени, и кодировки не совпадают и все беда, у меня лапки)

Ну в целом мне уже ответили, буду пробовать переезжать на re-flex

Всем спасибо! Лайков тут нет, или я не нашел…

Переменные и функции кириллицей?
bruh

Переменные и функции кириллицей?

Спасибо, что не забони тоҷикӣ )

Ну в целом мне уже ответили, буду пробовать переезжать на re-flex

re-flex нужен только если регистро-НЕзависимость, а у вас её нет.

Обычный flex с обычным utf-8 работает влёт. По большому счёту и работу-то делает не особо большую - токенизер pascal/st пишется и без него влёт. Другое дело что flex это типичный вид и его поддерживать проще чем ловить детские баги в самоделке.

Переменные и функции кириллицей?

настоящий тсырк начнется когда utf8 долетит в байткоде в мку в перемешку с 1251 )

С моей т.з., не ASCII символы в программе могут быть только комментарием. А ASCII в кодировках совпадает, поэтому я бы сделал препроцессор, который выдерет все не ASCII, а потом вставит как комментарий…

Во-первых, прекрати материться, тут это не принято.

Во-вторых, тот костыль, который ты сделал – не такой уж костыль, тут народ гораздо более дикие костыли лепит. iconv по моему опыту работает достаточно быстро. Я бы, пожалуй, только предусмотрел на будущее для транслятора ключик, какую именно кодировку задействовать. Единственный случай, когда это окажется неприемлемым — это если у тебя в токенах кириллица окажется перепутанной с греческими символами, например.

А ещё – читал ли ты вот это.

В качестве одного из путей – я бы пока оставил костыль. Судя по твоему упоминанию про то, что в оригинале было ещё и OLE, парсер для тебя сейчас – совсем не основная проблема. Если останется время, попробуешь переход на re-flex. Да, не очень красиво, но… Вон, разработчики одной очень известной отечественной САПР продают сборку под wine в качестве основного протестированного решения и обещают, что нативная будет чуть позже :) А у тебя всё-таки не wine, у тебя костыль не такой страшный. Как временное решение пойдёт.

С другой стороны, если на re-flex получится переехать за день-два, это, вероятно, более правильный путь.

соответственно если текст в кодировке utf-8, он не понимает ничего

Он и не должен ничего понимать, токены это просто набор байтов. Русские буквы будут 2 байта каждая и что? Это не проблема, токены будут распознаваться.

на винде кодировка CP1251

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

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

А внутри софта в плане в бинариках обычно utf-32 что в Linux что в современном Windows, т.к. фиксированный размер бит на символ пусть и не оптимален, но всякие штуки с ним делать проще и быстрее если прям в оперативку не надо ужиматься, вроде вычисления длины строки в кодепоинтах (с буквами utf-32 всё равно не поможет, т.к. это всё тот же юникод точно такой же как utf-8).

Реакции

Embarcadero покури.

...стоит ли перекатываться на новый анализатор...

Нет, не стоит.

на юниксе кодировка utf-8, на винде кодировка CP1251, транслятор написан на основе лексического анализатора flex, он не понимает unicode

В чем проблема с utf-8 во flex? flex работает с 7 или 8-ми битными символами.

unicode это utf-16/utf-32 с которым во flex есть проблема.

Ну в общем я последовал вашему совету, на re-flex переехать с полпинка не получилось, оставил костыль, оформил получше, что выглядит вроде и не костыль)), и работает по скорости приемлемо. С OLE файлами я разобрлся с помощью библиотеки libgsf, в данный момент транслятор передал тестировщикам, дальше видно будет)) Теперь на очереди ядро, это то что выполняет транслированный байт код, там тоже наверное будет веселуха)