1. JavaScript / Говнокод #19662

    +4

    1. 1
    2. 2
    this.navigator = navigator.userAgent || navigator.vendor || window.opera;
    this.mobile = /(android|bb\d+|meego).+mobile|avantgo|bada\/|blackberry|blazer|compal|elaine|fennec|hiptop|iemobile|ip(hone|od|ad)|iris|kindle|lge |maemo|midp|mmp|mobile.+firefox|netfront|opera m(ob|in)i|palm( os)?|phone|p(ixi|re)\/|plucker|pocket|psp|series(4|6)0|symbian|treo|up\.(browser|link)|vodafone|wap|windows ce|xda|xiino/i.test(this.navigator) || /1207|6310|6590|3gso|4thp|50[1-6]i|770s|802s|a wa|abac|ac(er|oo|s\-)|ai(ko|rn)|al(av|ca|co)|amoi|an(ex|ny|yw)|aptu|ar(ch|go)|as(te|us)|attw|au(di|\-m|r |s )|avan|be(ck|ll|nq)|bi(lb|rd)|bl(ac|az)|br(e|v)w|bumb|bw\-(n|u)|c55\/|capi|ccwa|cdm\-|cell|chtm|cldc|cmd\-|co(mp|nd)|craw|da(it|ll|ng)|dbte|dc\-s|devi|dica|dmob|do(c|p)o|ds(12|\-d)|el(49|ai)|em(l2|ul)|er(ic|k0)|esl8|ez([4-7]0|os|wa|ze)|fetc|fly(\-|_)|g1 u|g560|gene|gf\-5|g\-mo|go(\.w|od)|gr(ad|un)|haie|hcit|hd\-(m|p|t)|hei\-|hi(pt|ta)|hp( i|ip)|hs\-c|ht(c(\-| |_|a|g|p|s|t)|tp)|hu(aw|tc)|i\-(20|go|ma)|i230|iac( |\-|\/)|ibro|idea|ig01|ikom|im1k|inno|ipaq|iris|ja(t|v)a|jbro|jemu|jigs|kddi|keji|kgt( |\/)|klon|kpt |kwc\-|kyo(c|k)|le(no|xi)|lg( g|\/(k|l|u)|50|54|\-[a-w])|libw|lynx|m1\-w|m3ga|m50\/|ma(te|ui|xo)|mc(01|21|ca)|m\-cr|me(rc|ri)|mi(o8|oa|ts)|mmef|mo(01|02|bi|de|do|t(\-| |o|v)|zz)|mt(50|p1|v )|mwbp|mywa|n10[0-2]|n20[2-3]|n30(0|2)|n50(0|2|5)|n7(0(0|1)|10)|ne((c|m)\-|on|tf|wf|wg|wt)|nok(6|i)|nzph|o2im|op(ti|wv)|oran|owg1|p800|pan(a|d|t)|pdxg|pg(13|\-([1-8]|c))|phil|pire|pl(ay|uc)|pn\-2|po(ck|rt|se)|prox|psio|pt\-g|qa\-a|qc(07|12|21|32|60|\-[2-7]|i\-)|qtek|r380|r600|raks|rim9|ro(ve|zo)|s55\/|sa(ge|ma|mm|ms|ny|va)|sc(01|h\-|oo|p\-)|sdk\/|se(c(\-|0|1)|47|mc|nd|ri)|sgh\-|shar|sie(\-|m)|sk\-0|sl(45|id)|sm(al|ar|b3|it|t5)|so(ft|ny)|sp(01|h\-|v\-|v )|sy(01|mb)|t2(18|50)|t6(00|10|18)|ta(gt|lk)|tcl\-|tdg\-|tel(i|m)|tim\-|t\-mo|to(pl|sh)|ts(70|m\-|m3|m5)|tx\-9|up(\.b|g1|si)|utst|v400|v750|veri|vi(rg|te)|vk(40|5[0-3]|\-v)|vm40|voda|vulc|vx(52|53|60|61|70|80|81|83|85|98)|w3c(\-| )|webc|whit|wi(g |nc|nw)|wmlb|wonu|x700|yas\-|your|zeto|zte\-/i.test(this.navigator.substr(0,4));

    substr(0,4), Карл

    Запостил: makc3d, 20 Марта 2016

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

    • а может кто-то просто все юзер-агенты собрал и автоматом регулярку сгенерил? потому что я представить себе не могу что кто-то такую регулярку руками напишет.
      Ответить
      • Как мне кажется, правую часть сгенерировали в стародавние времена, а переднюю потомки дописывали вручную и жаловались на форумах, что не работает.
        Ответить
        • наврядли. там в регулярке все по алфавиту отсортировано. список UA через какой-то простой генератор прогоняли.
          Ответить
          • Генератор, блять... А я каждый раз руками это пишу.
            Ответить
            • у ботов нет рук
              Ответить
            • гугли "generate regex from list of strings". народ простые генераторы пишет пачками, и какого-то стандартного я не знаю. пару раз надо было - гуглил, пользовался, забывал.
              Ответить
              • В Руби есть, но херовый:
                http://ruby-doc.org/core-2.1.2/Regexp.html#method-c-union

                Я когда-то ради практики писал:
                https://github.com/wvxvw/intro-to-automata-theory/blob/master/automata/convert.pl#L148
                можно сгенерировать несколько NFA, потом их объединить, потом оптимизировать, потом обратно сгенерировать регулярку (последнее, к сожалению не оптимизируется / не решенная проблема в теории автоматов).
                Ответить
                • от перловых аксакалов:

                  http://search.cpan.org/~dankogai/Regexp-Trie-0.02/lib/Regexp/Trie.pm

                  http://search.cpan.org/~dankogai/Regexp-Optimizer-0.23/lib/Regexp/Optimizer.pm

                  http://search.cpan.org/dist/Regexp-Assemble/lib/Regexp/Assemble.pm
                  Ответить
                • > Я когда-то ради практики писал:

                  я сам тоже писал нечто подобное `Regexp::Trie` только тупо в лоб. я только еще в добавок делал оптимизицию/группирование не только по префиксам, но еще и по суффиксам. (я делал регулярки для более или менее нормального набора слов английского языка, потому там суффиксы часто повторялись. я генерил Н регулярок как переменные которые потом в перле все в одну регулярку сливались.)
                  Ответить
              • (regexp-opt '("meego" "mobile" "avanto" "blackberry" "blazer"))
                
                "\\(?:avanto\\|bla\\(?:ckberry\\|zer\\)\\|m\\(?:eego\\|obile\\)\\)"
                Ответить
                • ... только текстового редактора хорошего не хватает.
                  Ответить
              • "|".join(map(re.escape, list))?
                Ответить
              • люди, вы ебанулись

                вы ищите генератор, который сгенерирует регулярное выражение, по которому сгенерируется не детерминированный конечный автомат
                Ответить
                • Совершенно верно. Нам нужен генератор который с генерирует генератор ....
                  Ответить
                • и что в этом такого?

                  мы пишем (на пример на С) который прогоняется через перепроцессор, который конвертится в AST, который конвертится в промежуточный код, который конвертится в объектный код, и только вот этот код и выполняются различными блоками CPU.

                  зачем все это надо? почему бы не сразу в микро-инструкциях код писать?? зачем трахатся 2 минуты писать десяток строчек - вместо того что бы по быструхе за пару месяцев не своять то же самое на ассемблере?
                  Ответить
                  • >>который конвертится в промежуточный код
                    я думал это только в случае llvm, а другие компиляторы хуячат код прямо из AST

                    >> который конвертится в объектный код, и только вот этот код
                    нет
                    объектный код патчится линкером, затем патчится (иногда) лоадером, затем его декодер комманд CPU переводит во внутренние инструкции, и вот только они выполняются микрокодом
                    Ответить
                    • > > который конвертится в промежуточный код
                      > я думал это только в случае llvm, а другие компиляторы хуячат код прямо из AST

                      в случае LTO - все компилеры (которые я знаю). у GCC тоже есть свой промежуточный (нестандартизированый) код, потому что в случае LTO линкер делает всю работу.
                      Ответить
                      • Да, уже читаю про RTL passes

                        вообще надо драгон бук почитать, я в компиляторах не копенгаген
                        даже совестно как-то
                        Ответить
                        • драгон бук? не знал.

                          я все еще (наивно) планирую вирта читать. потому что у него там компилер на p-code'ы есть.

                          ЗЫ промежуточный код дело относительно новое. сомневаюсь что в классике будет упоминаться.
                          Ответить
                          • ну как новое если Вы сами говорите что пи коды были еще в паскале у Вирта
                            а это было черти когда
                            Ответить
                            • я не уверен что в паскале, но очень очень давно. вирт один из основоположников теории компиляции - новым это быть не может.

                              в какой-то книге (виртовских бук в сети лежит три штуки) у него есть простенький компилер в пи коды в две страницы. и интерпретер в полторы страницы. что меня и привлекает. но вот на ту сотню страниц теории которая этому предшевствует времени ни как не нахожу.
                              Ответить
                            • о блин я не понял о чем ты говоришь.

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

                              промежуточный код это в простейшем случае это просто дамп AST. потому что из него надо не только инструкции генерировать, но например еще и дебуг инфо.
                              Ответить
                              • в этом мире всё условно
                                байт-код джавы тоже превращается в x86 ISA в момент JIT:)

                                по дампу AST еще удобно испекции гонять и делать всякие патчи
                                наверняка ARC в clang именно там и работает
                                Ответить
                          • Ну как, прочитал?
                            Ответить
                  • > и только вот этот код
                    И даже этот код конвертится в микрооперации...
                    Ответить
                    • да, потому-то я и напейсал: "декодер комманд CPU переводит во внутренние инструкции"

                      x86 внутри давно уже совсем другой проц, а его ISA это просто такой высокоуровневный стандартный API к процу
                      Ответить
                      • интел этого больше не делает. (амд этого никогда не делала.)

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

                        интеловец в одном интервью на анандтич/или подобное упоминал. говорил что ограничения на количество транзисторов теперь не сильно актуально, извраты больше не нужны, и по этому можно конечный автомат по полной программе делать что бы нативно все инструкции исполнять.
                        Ответить
                        • А чо за апдейт микрокода тогда биос заливает в проц? И почему отказывается продолжать, если не найдёт кода под данный проц?

                          З.Ы. Ну я последний раз видел эту ситуацию лет 6 назад. Может сейчас и правда нету микрокода.
                          Ответить
                          • хез. microcode update интел делал еще и до p-pro. как именно оно там рабоает я не знаю. слышал только что вся архитектура проца сделана так что бы можно было почти все микрокодом патчить. скандал с fdiv'ом тогда интелу дорого стоил и они что-то очень навороченое сделали.
                            Ответить
                        • а что тогда делает декодер команд?
                          Ответить
                • А что делать, когда регулярные выражения практически во всех популярных языках не дают доступ к сгенерированому автомату.
                  Вообще у регулярных выражений есть много других полезных свойств / операций, которые почему-то не реализованы в популярных языках. Например, произведение, или отрицание. Но без доступа к реализации / без существующих АПИ прийдется самому генерировать НКА и с ним работать. Хз почему так, но так практически везде.
                  Ответить
                  • Самое отвратительное что большинство реализаций недетерминированного автомата регулярок выдают экспоненциальную сложность, а могли бы не выдавать если бы создавали множество автоматов

                    в итоге регулярками вроде a+a?b лучше и не пользоваться если заранее не ограничил длину входа
                    Ответить
                    • И как ты это множество для твоей регулярки представляешь?

                      "a+a?" - это что такое?
                      Ответить
                      • Я так понимаю, что имеется в виду lookahead. Т.е. чтобы найти лучшее совпадение, в худшем случае придется перебрать все подстроки префикса а+. Но я не думаю, что с регулярными выражениями тут может быть лучшая стратегия. Если это создает проблемы, то нужно использовать что-то типа PEG парсеров, и описывать критерии совпадения по-другому.
                        Ответить

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