LINUX.ORG.RU

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

 ,


0

2

Вопрос по транслятору, не знаю в какую ветку задать вопрос, если что, простите…

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

Столкнулся с проблемой кодировок, на юниксе кодировка utf-8, на винде кодировка CP1251, транслятор написан на основе лексического анализатора flex, он не понимает unicode, для него должно быть один символ - один байт, соответственно если текст в кодировке utf-8, он не понимает ничего. В данный момент я костылю перекодированием с помощью iconv, но чую что это дичь))

Прошу совета, стоит ли переписывать транслятор на новый анализатор, погуглил, есть re-flex и типо он подерживает все старые команды из flex, то есть по сути ничего особо переписывать и не нужно будет, но чет я не уверен))

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

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

Спасибо!



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

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

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

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

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

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

anonymous
()
Ответ на: комментарий от LINUX-ORG-RU

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

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

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

LightDiver ★★★★★
()

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

mittorn ★★★★★
()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ST что-ли ? :-)

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

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

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

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

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

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

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

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

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

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

MKuznetsov ★★★★★
()

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

soomrack ★★★★★
()

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

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

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

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

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

hobbit ★★★★★
()
Последнее исправление: hobbit (всего исправлений: 1)

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

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

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

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

no-such-file ★★★★★
()

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

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

peregrine ★★★★★
()

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

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

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

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

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

lazgo
() автор топика