- 1
- 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));
Dummy00001 21.03.2016 18:54 # 0
1024-- 21.03.2016 20:15 # +1
Dummy00001 22.03.2016 00:14 # 0
bot 22.03.2016 00:56 # 0
makc3d 22.03.2016 00:58 # +2
Dummy00001 22.03.2016 01:11 # 0
wvxvw 22.03.2016 15:45 # 0
Я когда-то ради практики писал: можно сгенерировать несколько NFA, потом их объединить, потом оптимизировать, потом обратно сгенерировать регулярку (последнее, к сожалению не оптимизируется / не решенная проблема в теории автоматов).
Dummy00001 22.03.2016 15:53 # 0
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
Dummy00001 22.03.2016 15:58 # +1
я сам тоже писал нечто подобное `Regexp::Trie` только тупо в лоб. я только еще в добавок делал оптимизицию/группирование не только по префиксам, но еще и по суффиксам. (я делал регулярки для более или менее нормального набора слов английского языка, потому там суффиксы часто повторялись. я генерил Н регулярок как переменные которые потом в перле все в одну регулярку сливались.)
roman-kashitsyn 22.03.2016 15:51 # +3
Dummy00001 22.03.2016 16:00 # 0
roman-kashitsyn 23.03.2016 09:27 # 0
evil-mode же и прочие spacemacs
CHayT 23.03.2016 09:45 # 0
3_14dar 22.03.2016 16:40 # 0
guest 22.03.2016 18:14 # +1
вы ищите генератор, который сгенерирует регулярное выражение, по которому сгенерируется не детерминированный конечный автомат
Vasiliy 22.03.2016 18:19 # +2
Dummy00001 22.03.2016 18:28 # +1
мы пишем (на пример на С) который прогоняется через перепроцессор, который конвертится в AST, который конвертится в промежуточный код, который конвертится в объектный код, и только вот этот код и выполняются различными блоками CPU.
зачем все это надо? почему бы не сразу в микро-инструкциях код писать?? зачем трахатся 2 минуты писать десяток строчек - вместо того что бы по быструхе за пару месяцев не своять то же самое на ассемблере?
guest 22.03.2016 18:35 # 0
я думал это только в случае llvm, а другие компиляторы хуячат код прямо из AST
>> который конвертится в объектный код, и только вот этот код
нет
объектный код патчится линкером, затем патчится (иногда) лоадером, затем его декодер комманд CPU переводит во внутренние инструкции, и вот только они выполняются микрокодом
Dummy00001 22.03.2016 18:40 # 0
> я думал это только в случае llvm, а другие компиляторы хуячат код прямо из AST
в случае LTO - все компилеры (которые я знаю). у GCC тоже есть свой промежуточный (нестандартизированый) код, потому что в случае LTO линкер делает всю работу.
guest 22.03.2016 18:44 # +1
вообще надо драгон бук почитать, я в компиляторах не копенгаген
даже совестно как-то
Dummy00001 22.03.2016 18:55 # 0
я все еще (наивно) планирую вирта читать. потому что у него там компилер на p-code'ы есть.
ЗЫ промежуточный код дело относительно новое. сомневаюсь что в классике будет упоминаться.
guest 22.03.2016 19:03 # 0
а это было черти когда
Dummy00001 22.03.2016 19:10 # 0
в какой-то книге (виртовских бук в сети лежит три штуки) у него есть простенький компилер в пи коды в две страницы. и интерпретер в полторы страницы. что меня и привлекает. но вот на ту сотню страниц теории которая этому предшевствует времени ни как не нахожу.
Dummy00001 22.03.2016 19:18 # 0
пи коды в оригинале использовались только для интерпретации. например авторы жабы открыто говорили что жаба байт-код был вдохновлен пи кодами.
промежуточный код это в простейшем случае это просто дамп AST. потому что из него надо не только инструкции генерировать, но например еще и дебуг инфо.
guest 22.03.2016 19:20 # 0
байт-код джавы тоже превращается в x86 ISA в момент JIT:)
по дампу AST еще удобно испекции гонять и делать всякие патчи
наверняка ARC в clang именно там и работает
ECEHuHCKuu_nemyx 18.10.2020 23:58 # 0
_PHP_ 19.10.2020 00:00 # 0
ECEHuHCKuu_nemyx 19.10.2020 00:58 # 0
bootcamp_dropout 19.10.2020 01:02 # +1
Ну как, нашел?
ECEHuHCKuu_nemyx 19.10.2020 01:29 # 0
guest8 19.10.2020 01:34 # −999
KAXETuHCKuu_nemyx 19.10.2020 01:51 # 0
bormand 22.03.2016 18:42 # 0
И даже этот код конвертится в микрооперации...
guest 22.03.2016 18:45 # 0
x86 внутри давно уже совсем другой проц, а его ISA это просто такой высокоуровневный стандартный API к процу
Dummy00001 22.03.2016 18:52 # 0
с пентиум про по какой-то там - ядро был почти риск. но новые актуальные поколения процов опять в живую интерпретируют нативный код.
интеловец в одном интервью на анандтич/или подобное упоминал. говорил что ограничения на количество транзисторов теперь не сильно актуально, извраты больше не нужны, и по этому можно конечный автомат по полной программе делать что бы нативно все инструкции исполнять.
bormand 22.03.2016 19:11 # 0
З.Ы. Ну я последний раз видел эту ситуацию лет 6 назад. Может сейчас и правда нету микрокода.
Dummy00001 22.03.2016 19:23 # 0
guest 22.03.2016 19:14 # 0
bormand 22.03.2016 19:16 # +1
guest 22.03.2016 19:16 # +2
wvxvw 22.03.2016 22:25 # 0
Вообще у регулярных выражений есть много других полезных свойств / операций, которые почему-то не реализованы в популярных языках. Например, произведение, или отрицание. Но без доступа к реализации / без существующих АПИ прийдется самому генерировать НКА и с ним работать. Хз почему так, но так практически везде.
guest 22.03.2016 22:57 # +1
в итоге регулярками вроде a+a?b лучше и не пользоваться если заранее не ограничил длину входа
3_14dar 23.03.2016 03:16 # 0
"a+a?" - это что такое?
wvxvw 23.03.2016 09:53 # +1
3_14dar 23.03.2016 16:30 # +1
bormand 23.03.2016 19:06 # +2
3_14dar 23.03.2016 19:40 # 0
naxoM 23.03.2016 22:00 # +1
kegdan 23.03.2016 21:08 # 0