#game #gamedev
Factorio вышла из раннего доступа и наконец дошла до версии 1.0, спустя восемь с половиной лет от начала разработки.
factorio.com/blog/post/fff-360
Factorio вышла из раннего доступа и наконец дошла до версии 1.0, спустя восемь с половиной лет от начала разработки.
factorio.com/blog/post/fff-360
Factorio
Friday Facts #360 - 1.0 is here! | Factorio
Hello, the atmosphere in the last week was kind of special. We experienced the feeling of the final release being on the horizon many times. And we were shown that it isn't the case time and time again. So it feels very special when it is actually becoming…
#prog #parsing #regex #article (строго говоря, не про разбор, а про распознавание, но всё же)
Можно ли подсчитать производную от регулярного выражения? Можно и нужно!
Статья рассказывает о изученной и эффективной, но почему-то мало известной на практике технике построения распознающих конечных автоматов непосредственно из регулярных выражений. К сожалению, в статье рассматривается лишь задача о соответствии регулярного тексту, в ней ничего не говорится о, скажем, захвате соответствующих частей текста.
"In this paper, we have presented RE derivatives, which are an old, but largely forgotten, technique for constructing DFAs directly from REs. Our experience has been that RE derivatives are a superior technique for generating scanners from REs and they should be in the toolkit of any programmer. Specifically, RE derivatives have the following advantages:
• They provide a direct RE to DFA translation that is well suited to implementation in functional languages.
• They support extended REs almost for free.
• The generated scanners are often optimal in the number of states and are uniformly better than those produced by previous tools.
In addition to presenting the basic RE to DFA algorithm, we have also discussed a number of practical issues related to implementing a scanner generator that is based on RE derivatives, including supporting large character sets"
www.ccs.neu.edu/home/turon/re-deriv.pdf
Можно ли подсчитать производную от регулярного выражения? Можно и нужно!
Статья рассказывает о изученной и эффективной, но почему-то мало известной на практике технике построения распознающих конечных автоматов непосредственно из регулярных выражений. К сожалению, в статье рассматривается лишь задача о соответствии регулярного тексту, в ней ничего не говорится о, скажем, захвате соответствующих частей текста.
"In this paper, we have presented RE derivatives, which are an old, but largely forgotten, technique for constructing DFAs directly from REs. Our experience has been that RE derivatives are a superior technique for generating scanners from REs and they should be in the toolkit of any programmer. Specifically, RE derivatives have the following advantages:
• They provide a direct RE to DFA translation that is well suited to implementation in functional languages.
• They support extended REs almost for free.
• The generated scanners are often optimal in the number of states and are uniformly better than those produced by previous tools.
In addition to presenting the basic RE to DFA algorithm, we have also discussed a number of practical issues related to implementing a scanner generator that is based on RE derivatives, including supporting large character sets"
www.ccs.neu.edu/home/turon/re-deriv.pdf
Блог*
#prog #ml Machine learning, который мы заслужили. thisdickpicdoesnotexist.com (если вы ещё не поняли, это NSFW)
#prog #ml #article
А тут решали обратную задачу: детектирование NSFW.
habr.com/ru/company/ru_mts/blog/515000/
А тут решали обратную задачу: детектирование NSFW.
habr.com/ru/company/ru_mts/blog/515000/
Хабр
Не те игрушки: как мы научили нейросеть бороться с порно в стримах
Всем привет, меня зовут Олег, я занимаюсь компьютерным зрением в команде Видеоаналитики МТС и сегодня расскажу вам, как мы защищаем от небезопасного контента стриминговую платформу WASD.tv, в...
Блог*
#prog #parsing #regex #article (строго говоря, не про разбор, а про распознавание, но всё же) Можно ли подсчитать производную от регулярного выражения? Можно и нужно! Статья рассказывает о изученной и эффективной, но почему-то мало известной на практике технике…
#prog #rust #rustlib #amazingopensource
А вот где эта техника используется на практике: в новом генераторе лексеров Sana.
github.com/suhr/sana/
А вот где эта техника используется на практике: в новом генераторе лексеров Sana.
github.com/suhr/sana/
Это просто цирк какой-то. Яндекс.Такси переименовали в Яндекс Go и запихнули туда функционал Яндекс.{Еды, Лавки, Драйв}. Причём почему-то это преподносится как что-то хорошее.
Интересно, как быстро они распилят обратно, сопроводив это той же самой риторикой о том, как стало удобнее.
yandex.ru/company/press_releases/2020/2020-08-19
Интересно, как быстро они распилят обратно, сопроводив это той же самой риторикой о том, как стало удобнее.
yandex.ru/company/press_releases/2020/2020-08-19
Компания Яндекс
Яндекс Go — новое приложение для быстрого решения задач в городе
Яндекс запускает Go — единое приложение для решения повседневных задач в городе. С помощью Яндекс Go люди смогут быстро добраться куда нужно на общественном транспорте, такси, каршеринге и даже на машине с персональным водителем, заказать экспресс-доставку…
👍4
Forwarded from Generative Anton
Ого, оказывается даже Apple чёт там у себя хотят в нетворкинге писать на Rust'e как замене чистому C. Интересно конечно
Блог*
Это просто цирк какой-то. Яндекс.Такси переименовали в Яндекс Go и запихнули туда функционал Яндекс.{Еды, Лавки, Драйв}. Причём почему-то это преподносится как что-то хорошее. Интересно, как быстро они распилят обратно, сопроводив это той же самой риторикой…
Twitter
Niki Tonsky
У Яндекса вышло приложение Яндекс.Go Fuck Yourself https://t.co/HhahTn4VD4
The After Times
Photo
#prog #моё
Если вы используете регулярные выражения — вам должно быть за это стыдно
У регулярных выражений есть куча недостатков, и, на мой взгляд, их слишком часто используют там, где не надо. Сейчас я расскажу о том, что же с ними не так.
Проблемы
1. Регулярные выражения (за некоторыми исключениями - 1, 2) парсятся в рантайме.
В подавляющем большинстве случаев строка, используемая для построения регулярных выражений, является константной, поэтому принципиально ничего не мешает провести компиляцию регулярного выражения одновременно с компиляцией программы. Большая часть моих следующих претензий напрямую вытекает из этого свойства.
2. Регулярные выражения (далее RE) фактически динамически типизированы.
Разберу подробнее:
2.а. Если в описании RE есть ошибка (незакрытая скобка, обратная ссылка на несуществующий паттерн) — ты не узнаешь об этом до запуска программы. Если RE находится в функции, которая редко вызывается и которую не покрывают тесты, то баг может всплыть уже в, казалось бы, сто лет нормально работающей программе.
2.б. В качестве аргумента для RE используется строка — слабо структурированный тип данных. Какой бы сложной не была бы структура, заданная RE, в статически типизированном языке приходится возвращать значение одного и того же типа, поэтому вся информация о структуре теряется.
Хочешь достать текст из некой группы захвата? Вот тебе геттеры по индексам — разумеется, все возвращают Option, даже если данная группа заведомо присутствует. Ах да, не забудь на всякий случай их все проверить и поменять, где надо, когда поменяешь RE.
Что, вы говорите, именованные группы захвата? Ну, окей, именованные. Ну, геттеры по строкам, а не по индексам. Но геттеры всё равно отдают Option, а теперь у тебя появилась невероятная возможность опечататься в геттере. Конечно, можно использовать строковые константы, но, во-первых, Option никуда не денутся, а во-вторых, эти же константы по-хорошему надо использовать для строки, из которой создаётся RE, так что вместо просто литерала будет конкатенация нескольких строк. Ура, читаемость!
2.в. Хочешь, чтобы IDE ловила ошибки? А вот хрен тебе: если только у тебя RE не встроены в язык, тебе IDE ничего не подскажет, ибо для неё это всего лишь строка, не отличающаяся от всех прочих.
2.г. Хочешь быстрые RE? Надейся, что автор используемой тобой библиотеки смог написать хороший компилятор RE. Что, говоришь, у твоего ЯП есть оптимизирующий компилятор? Очень хорошо, да только он тут не поможет и не может помочь, потому что он ничего про конкретное RE не знает.
3. Такой вещи, как "просто регулярное выражение", не существует.
Есть Perl RE (и PCRE), POSIX RE (и не одна разновидность), и есть... Библиотеки, которые реализуют один из этих стандартов.
Или не реализуют.
Или реализуют не полностью.
Или реализуют с отличиями.
Или просто бажные.
А есть ещё жадное и нежадное сопоставление. Движок для RE, который ты используешь, точно умеет в оба варианта? А какой использует по умолчанию?
Короче, практически любое нетривиальное RE, вероятно, непереносимо между разными языками и разными библиотеками одного и того же языка.
4. У RE просто отвратительная композируемость. Не, ну серьёзно.
Тебе нужно сматчить подряд два RE или одно, но несколько раз? Делай сам. Руками. Ты ж программист, писать программы — это твоя обязанность.
Хочешь протестировать отдельно кусок сложного RE? Не вопрос, компилируй отдельно подстроку. Да, компилируй заново. Ну и что, что там структура одинаковая? А почему одинаковая, собственно? Ты разве синхронно меняешь строки при внесении изменений? Да, да, можно конкатенировать строки. Да, так структура у этих кусочков будет одинаковая. Нет, ты не можешь этим воспользоваться.
Что, говоришь, у тебя структура текста параметризована некоторым значением? Нет, ты не можешь сделать RE с аргументом. Ручками вклеивай значение и компилируй каждый раз отдельно. Да, и кеш у JIT-компилятора RE не забудь инвалидировать полностью.
Что ты там говоришь про декомпозицию? Да не ссы, пиши всё в одну большую строку. Деды, вон, в одном файле всё писали — и ничего, выжили. Они терпели — и ты потерпи.
Если вы используете регулярные выражения — вам должно быть за это стыдно
У регулярных выражений есть куча недостатков, и, на мой взгляд, их слишком часто используют там, где не надо. Сейчас я расскажу о том, что же с ними не так.
Проблемы
1. Регулярные выражения (за некоторыми исключениями - 1, 2) парсятся в рантайме.
В подавляющем большинстве случаев строка, используемая для построения регулярных выражений, является константной, поэтому принципиально ничего не мешает провести компиляцию регулярного выражения одновременно с компиляцией программы. Большая часть моих следующих претензий напрямую вытекает из этого свойства.
2. Регулярные выражения (далее RE) фактически динамически типизированы.
Разберу подробнее:
2.а. Если в описании RE есть ошибка (незакрытая скобка, обратная ссылка на несуществующий паттерн) — ты не узнаешь об этом до запуска программы. Если RE находится в функции, которая редко вызывается и которую не покрывают тесты, то баг может всплыть уже в, казалось бы, сто лет нормально работающей программе.
2.б. В качестве аргумента для RE используется строка — слабо структурированный тип данных. Какой бы сложной не была бы структура, заданная RE, в статически типизированном языке приходится возвращать значение одного и того же типа, поэтому вся информация о структуре теряется.
Хочешь достать текст из некой группы захвата? Вот тебе геттеры по индексам — разумеется, все возвращают Option, даже если данная группа заведомо присутствует. Ах да, не забудь на всякий случай их все проверить и поменять, где надо, когда поменяешь RE.
Что, вы говорите, именованные группы захвата? Ну, окей, именованные. Ну, геттеры по строкам, а не по индексам. Но геттеры всё равно отдают Option, а теперь у тебя появилась невероятная возможность опечататься в геттере. Конечно, можно использовать строковые константы, но, во-первых, Option никуда не денутся, а во-вторых, эти же константы по-хорошему надо использовать для строки, из которой создаётся RE, так что вместо просто литерала будет конкатенация нескольких строк. Ура, читаемость!
2.в. Хочешь, чтобы IDE ловила ошибки? А вот хрен тебе: если только у тебя RE не встроены в язык, тебе IDE ничего не подскажет, ибо для неё это всего лишь строка, не отличающаяся от всех прочих.
2.г. Хочешь быстрые RE? Надейся, что автор используемой тобой библиотеки смог написать хороший компилятор RE. Что, говоришь, у твоего ЯП есть оптимизирующий компилятор? Очень хорошо, да только он тут не поможет и не может помочь, потому что он ничего про конкретное RE не знает.
3. Такой вещи, как "просто регулярное выражение", не существует.
Есть Perl RE (и PCRE), POSIX RE (и не одна разновидность), и есть... Библиотеки, которые реализуют один из этих стандартов.
Или не реализуют.
Или реализуют не полностью.
Или реализуют с отличиями.
Или просто бажные.
А есть ещё жадное и нежадное сопоставление. Движок для RE, который ты используешь, точно умеет в оба варианта? А какой использует по умолчанию?
Короче, практически любое нетривиальное RE, вероятно, непереносимо между разными языками и разными библиотеками одного и того же языка.
4. У RE просто отвратительная композируемость. Не, ну серьёзно.
Тебе нужно сматчить подряд два RE или одно, но несколько раз? Делай сам. Руками. Ты ж программист, писать программы — это твоя обязанность.
Хочешь протестировать отдельно кусок сложного RE? Не вопрос, компилируй отдельно подстроку. Да, компилируй заново. Ну и что, что там структура одинаковая? А почему одинаковая, собственно? Ты разве синхронно меняешь строки при внесении изменений? Да, да, можно конкатенировать строки. Да, так структура у этих кусочков будет одинаковая. Нет, ты не можешь этим воспользоваться.
Что, говоришь, у тебя структура текста параметризована некоторым значением? Нет, ты не можешь сделать RE с аргументом. Ручками вклеивай значение и компилируй каждый раз отдельно. Да, и кеш у JIT-компилятора RE не забудь инвалидировать полностью.
Что ты там говоришь про декомпозицию? Да не ссы, пиши всё в одну большую строку. Деды, вон, в одном файле всё писали — и ничего, выжили. Они терпели — и ты потерпи.
The After Times
Photo
5. Синтаксис.
Да, я сказал это — у RE уродливый синтаксис.
Причём он не был бы настолько уродливым, если бы не необходимость в двойном экранировании. Сначала слеш, чтобы вставить в RE спецсимвол. Потом ещё один, чтобы этот слеш распознался в строке именно как слеш, а не спецсимвол. Да, с сырыми строковыми литералами проще. Если они, конечно, есть в ЯП.
Скобок много. Группировку за маму, группировку за папу. Хочешь скобку как символ? Ставь ещё один слеш. И ещё один, потому что экранирование в твоём ЯП. Ммммм, обожаю кашу из слешей и спецсимволов по утрам.
А ещё эта чувствительность к пробельным символам. Хочешь разнести на несколько строк, добавить комментариев? Ну, давай, только включи спецфлаг в начале. Если, конечно, используемая тобой либа это поддерживает.
Или вот ещё классы символов — с двойными квадратными скобками и двоеточиями на концах. Максимально вербозно, максимально уродливо, чтобы быть уверенным, что ты понятное имя вместо пачки диапазонов будешь использовать поменьше.
Но топ, конечно — это отрицание. Как нужно показать, что нужно, чтобы не матчился набор символов? Поставь
6. Тут должна была быть лекция на тему того, что регулярные выражения могут парсить только регулярные языки и потому не могут распарсить, скажем, HTML, но в силу того, что по факту то, что в программировании называют регулярными выражениями — это, как правило, различные расширения, делающие язык RE более выразительным, она была устранена ещё до написания
7. RE толком не отлаживаются.
Если что-то идёт не так — можно лишь тешить себя надеждами, что ты найдёшь ошибку при помощи тестов (которые почему-то не поймали эту ошибку ранее) и собственного пристального взгляда.
Говоришь, отладчик подцепишь? Да у тебя программа внутри скомпилированного RE. Естественно, отладчик по шагам этой программы ходить не будет, только по шагам ЯП, который его интерпретирует. Будешь отлаживать программу, пока отлаживаешь программу. we-need-to-go-deeper.jpg
Короче
Игрушка дьявола, дрянь, на которую подсаживаются, как на наркотик, несерьёзная вещь, которую вдруг начали широко использовать неиронично — это всё про Javascript. То есть, простите, регулярные выражения. Я надеюсь (это, если что, фигура речи такая — на самом деле я ничерта не надеюсь, что могу кого-то как-то изменить — я не евангелист, не спикер на конференциях, не Боб Мартин и не Бугаенко, не даже чей-нибудь завалящий тимлид — просто парень в интернете, который пишет о чём-то, в чём якобы разбирается — одним словом, диванный эксперт от мира айти), что вы все поняли, насколько эта плохая вещь и что вы никогда не будете её использовать и не будете давать её детям. Даже чужим.
P. S.: если вам показалось, что это #бомбёжкипост, то вам не показалось.
Да, я сказал это — у RE уродливый синтаксис.
Причём он не был бы настолько уродливым, если бы не необходимость в двойном экранировании. Сначала слеш, чтобы вставить в RE спецсимвол. Потом ещё один, чтобы этот слеш распознался в строке именно как слеш, а не спецсимвол. Да, с сырыми строковыми литералами проще. Если они, конечно, есть в ЯП.
Скобок много. Группировку за маму, группировку за папу. Хочешь скобку как символ? Ставь ещё один слеш. И ещё один, потому что экранирование в твоём ЯП. Ммммм, обожаю кашу из слешей и спецсимволов по утрам.
А ещё эта чувствительность к пробельным символам. Хочешь разнести на несколько строк, добавить комментариев? Ну, давай, только включи спецфлаг в начале. Если, конечно, используемая тобой либа это поддерживает.
Или вот ещё классы символов — с двойными квадратными скобками и двоеточиями на концах. Максимально вербозно, максимально уродливо, чтобы быть уверенным, что ты понятное имя вместо пачки диапазонов будешь использовать поменьше.
Но топ, конечно — это отрицание. Как нужно показать, что нужно, чтобы не матчился набор символов? Поставь
^
. Только не снаружи квадратных скобок, а внутри. Больше граничных случаев богу граничных случаев! Уверен, что потом сможешь прочитать то, что сам написал неделю назад?6. Тут должна была быть лекция на тему того, что регулярные выражения могут парсить только регулярные языки и потому не могут распарсить, скажем, HTML, но в силу того, что по факту то, что в программировании называют регулярными выражениями — это, как правило, различные расширения, делающие язык RE более выразительным, она была устранена ещё до написания
7. RE толком не отлаживаются.
Если что-то идёт не так — можно лишь тешить себя надеждами, что ты найдёшь ошибку при помощи тестов (которые почему-то не поймали эту ошибку ранее) и собственного пристального взгляда.
Говоришь, отладчик подцепишь? Да у тебя программа внутри скомпилированного RE. Естественно, отладчик по шагам этой программы ходить не будет, только по шагам ЯП, который его интерпретирует. Будешь отлаживать программу, пока отлаживаешь программу. we-need-to-go-deeper.jpg
Короче
Игрушка дьявола, дрянь, на которую подсаживаются, как на наркотик, несерьёзная вещь, которую вдруг начали широко использовать неиронично — это всё про Javascript. То есть, простите, регулярные выражения. Я надеюсь (это, если что, фигура речи такая — на самом деле я ничерта не надеюсь, что могу кого-то как-то изменить — я не евангелист, не спикер на конференциях, не Боб Мартин и не Бугаенко, не даже чей-нибудь завалящий тимлид — просто парень в интернете, который пишет о чём-то, в чём якобы разбирается — одним словом, диванный эксперт от мира айти), что вы все поняли, насколько эта плохая вещь и что вы никогда не будете её использовать и не будете давать её детям. Даже чужим.
P. S.: если вам показалось, что это #бомбёжкипост, то вам не показалось.
Stack Overflow
RegEx match open tags except XHTML self-contained tags
I need to match all of these opening tags:
<p>
<a href="foo">
But not self-closing tags:
<br />
<hr class="foo" />
I came up with this and wanted to make
<p>
<a href="foo">
But not self-closing tags:
<br />
<hr class="foo" />
I came up with this and wanted to make
Forwarded from Shady Bytes
99,9999% утра пытаюсь придумать шутку про SRE, но у меня не получается.