ЙажаСценарий / Говнокод #16573 Ссылка на оригинал

0

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
function parse(input) {
        var options = arguments.length > 1 ? arguments[1] : {},
    
            peg$FAILED = {},
    
            peg$startRuleFunctions = { grammar: peg$parsegrammar },
            peg$startRuleFunction  = peg$parsegrammar,
    
            peg$c0 = peg$FAILED,
            peg$c1 = null,
            peg$c2 = [],
            peg$c3 = function(initializer, rules) {
. . .
            peg$c142 = { type: "other", description: "whitespace" },
            peg$c143 = /^[ \t\x0B\f\xA0\uFEFF\u1680\u180E\u2000-\u200A\u202F\u205F\u3000]/,
            peg$c144 = { type: "class", value: "[ \\t\\x0B\\f\\xA0\\uFEFF\\u1680\\u180E\\u2000-\\u200A\\u202F\\u205F\\u3000]", description: "[ \\t\\x0B\\f\\xA0\\uFEFF\\u1680\\u180E\\u2000-\\u200A\\u202F\\u205F\\u3000]" },
    
            peg$currPos          = 0,
            peg$reportedPos      = 0,
            peg$cachedPos        = 0,
            peg$cachedPosDetails = { line: 1, column: 1, seenCR: false },
            peg$maxFailPos       = 0,
            peg$maxFailExpected  = [],
            peg$silentFails      = 0,
    
            peg$result;
. . . // + 3К строк бреда до конца функции

История моих мытарств и жалких метаний:
Меня попросило начальство радикально улучшить формат в котором приложение хранит данные. Думал я, думал, и решил, что YAML ка нельзя лучше подходит для задачи (нужно хранить описание слайдов презентации, т.е. много текста и довольно схематичная графика, все это желательно бы иметь возможность комфортно редактировать в текстовом виде, создавать заготовки и т.д.).

Шаг первый: поиск готового YAML парсера, врезультате обнаружились две штуки для АС3. Один - клон Ява парсера, в котором по класу на токен. Я не шучу. Проект заброшен 5 лет назад. Второй: заброшен 4 года назад, все в одном файле, парсится регулярками и магией, какие-то комментарии имеются, но они только свидетельствуют о несостоятельности писавшего коментарии.

Подумал: если нет нормального парсера, может есть генератор парсеров?

Шаг второй: поиск обнаружил одну попытку написать клон ANTLR, но очень ограниченную, и не работающую.

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

И тут я нашел это.

Запостил: wvxvw wvxvw, (Updated )

Комментарии (11) RSS

  • ava roman-kashitsyn # Ссылка на оригинал 0

    Десеализатор ямла в llvm ещё недавно ронялся в сегфолт тривиальной опечаткой, лол.
    Ответить

    • ava wvxvw # Ссылка на оригинал 0 ⇈

      Меня, кстати сказать, удивляет такая плохая распространненость формата. Т.е. с одной стороны, любому, кто сталкивался с JSON / XML очень быстро становится понятно, что есть много вещей, которые хотелось бы, но нет возможности выразить в этих форматах, с другой стороны - будут строить велик из JSON / XML, но не будут пользоваться YAMLом.

      Я не знаю, почему в llvm было так плохо. Формат, конечно, немного сложнее XML, но не на столько, чтобы прямо невыполнимо. В Руби, пусть меня поправят, кто знает, это формат для встроенного механизма рефлексии / ОРМ, и т.п.
      Ответить

        • ava wvxvw # Ссылка на оригинал 0 ⇈

          Ну, с практической точки зрения, YAML позволяет:
          - повторное использование уже определенного элемента. например:
          element: &foo { x: 42 }
same element: *foo

          - определяемые парсером типы данных (в отличие от головной боли с XSL). Документ может сразу же содержать и определение и использование тэгов (XML тоже может одновременно в одном документе использовать DTD и содержание, но в DTD новых типов данных не объявить).
          - явно указывает нужно ли читать дочерние объекты по порядку, или можно порядок игнорировать.
          YAML принципиально отличаеся тем, что типы привязаны к аннотациям типов, а не к структуре документа. Т.е. в XSL нет возможности объявить универсальный тип, который будет инрерпретирован в любом месте документа, где бы он ни встретился, а в YAML так оно работает само по себе. Это помогает избегать очень сложных описаний документов, и делает их более модульными.

          С более теоретической точки зрения: YAML позволяет хорошее разделение данных и метаданных (в XML положение метаданных определяется данными, и его никак не поменять). Т.е. <p>параграф</p>: параграф - содержание, <p></p> - метаданные. Их никак не переместить в другоем место (если в каждом <p> нужно описать свойства параграфа, то их прийдется повторять, либо писать специальные языки расширения, типа CSS). Не предписывает однозначную интерпретацию, а только делает ее возможной. Т.е. в XML внешний вид целиком определяет интерпретацию, а в YAML это можно оставить на совести парсера.
          Ответить

      • ava bormand # Ссылка на оригинал 0 ⇈

        > немного сложнее XML
        Ну-ну. Что-то сложнее XML, походу, хрен придумаешь.
        Ответить

      • ava roman-kashitsyn # Ссылка на оригинал 0 ⇈

        > Я не знаю, почему в llvm было так плохо.
        Потому что формат в основном читался той же либой, которой генерился, потому всё работало.
        Когда в дело вступают люди, всё гораздо интереснее.

        Ну и плюс отказ от исключений, как и любой фанатизм, до добра редко доводит.

        > удивляет такая плохая распространненость формата
        Js всё ещё один из самых популярных языков на планете, а тащить парсер YAML на фронтенд ради эфемерных удобств врядли можно назвать превосходной идеей.
        Ответить

  • ava guest # Ссылка на оригинал 0

    Никто не хочет делать либы под анально огороженный AS?
    АДОБОПРОБЛЕМЫ
    Ответить

    • ava wvxvw # Ссылка на оригинал 0 ⇈

      Ну так а тут очень печальная история. Это как в институте работаешь на зачетку, а потом зачетка работает на тебя: проработав лет десять в одной области, при всем желании очень тяжело найти работу где-то в другом месте. Я бы, например, с радостью переквалифицировался в питониста, даже Яву можно было бы вытерпеть. Я даже как-то пытался в девоп. Но люди не верят. И их сложно в этом винить. Я, может, за всю жизнь встретил 1-2 флешеров, которые знали бы какой-нибудь другой язык в достаточном объеме, чтобы на этом зарабатывать. Как правило, это люди с очень примитивным и ограниченым представлением о программировании, о том, как устроены компьютер, периферия, сетевые технологии и... вобщем все, что обычно ассоциируется с ИТ или программированием.
      Так что приходится решать адобопроблемы.
      Ответить

      • ava guest # Ссылка на оригинал 0 ⇈

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

        >Но люди не верят. И их сложно в этом винить
        Да судя по здешним тредам Вы можете запросто переубедить и переговорить многих.
        Даже тех кто твёрдо стоял на своём.
        Ответить

        • ava wvxvw # Ссылка на оригинал 0 ⇈

          А кто эти познания проверять будет? Агент HR? Год назад, когда я рассылал резюме, мне один раз позвонили из агенства и приятная девушка наивно так спросила: "А вот у вас тут сказано опыт программирования на Элайэспи - вы не могли бы рассказать поподробниее?"
          Ответить

Добавить комментарий

Я, guest, находясь в здравом уме и твердой памяти, торжественно заявляю:

    А не использовать ли нам bbcode?

    ↑
    8
    ↓