ap
Ещё можно oh-my-zsh переводить в vi-mode и у командной строки появится обычный режим как в виме с теми же клавишами управления
покаж как
Size: a a a
2020 November 07
ap
пазязя
A
Ещё можно oh-my-zsh переводить в vi-mode и у командной строки появится обычный режим как в виме с теми же клавишами управления
Не нашел, как Вы это делаете?
NG
Было бы полезно в вим ввести все содержимое буфера терминала, но я не нашел, как это сделать
в баше такое буквой v делается
A
в баше такое буквой v делается
Возможно чего-то не хватает. Буква v букву v напечатает, думаю
ap
Ещё можно oh-my-zsh переводить в vi-mode и у командной строки появится обычный режим как в виме с теми же клавишами управления
а зочем
SS
Yaroslav Schekin
> RE2 — не вершина развития, он внутри довольно плох, кстати
Конечно, не вершина — это "возврат к основам", скорее (т.е. удивительно именно то, что он вообще настолько хорош на современном уровне). Что намекает на то, что последние [почти] 60 лет движки шли куда-то не совсем туда. ;)
Я имел в виду именно используемые алгоритмы.
> сравнение, как обычно, biased,
То-то и оно. ;(
> почти никто другой не удосужился побенчмаркать нормально свои либы
Потому что нафиг надо и так good enough (а если нет, то и ладно — есть задачи поважнее). ;)
Т.е. в тех местах, куда они встроены, они обычно не представляют и 0.001% функционала языка (или продукта).
> из него интересно на PCRE vs RE2 смотреть
Это я почитаю, спасибо!
>Бенчмарки с Tcl не видел, интересно поискать, это правда, но что-то я удивлюсь
А вот: https://github.com/rust-lang/regex/blob/master/bench/log/05/tcl-vs-rust — и (к вопросу biased) я уже удивился — по-моему, автор не смог нормально "завести" (адаптировать / скомпилировать) этот движок или взял его не оттуда (во-первых, фактический upstream сейчас в PostgreSQL; во-вторых, в Tcl он работает только с utf-16, поэтому использование его на файлах "как есть" — автоматический performance hit как минимум в 2-3 раза).
> выяснить более эффективный, что бы это не значило
Ну это как-то несерьёзно, правда. ;)
> классификатор — это отдельная и очень широкая тема
Казалось бы, почему не просто "если это не умеет первый, используй второй" (как Вы и написали)?
> С тех пор он крайне активно разрабатывается и даже замахнулся на значительно более сложную область
Да, я заметил... но что это даёт на практике — другой вопрос. А n-грамные индексы — старая тема, на самом деле, просто в grep-ах до неё пока не очень-то дошли.
> Из использующих подобный подход с выбором движка по самому запросу я помню только ripgrep и Intel Chimera
Вот то-то и оно (Tcl всегда внутри таким был, но это исключение)... да и в vim-е нынче тоже два движка. :)
Конечно, не вершина — это "возврат к основам", скорее (т.е. удивительно именно то, что он вообще настолько хорош на современном уровне). Что намекает на то, что последние [почти] 60 лет движки шли куда-то не совсем туда. ;)
Я имел в виду именно используемые алгоритмы.
> сравнение, как обычно, biased,
То-то и оно. ;(
> почти никто другой не удосужился побенчмаркать нормально свои либы
Потому что нафиг надо и так good enough (а если нет, то и ладно — есть задачи поважнее). ;)
Т.е. в тех местах, куда они встроены, они обычно не представляют и 0.001% функционала языка (или продукта).
> из него интересно на PCRE vs RE2 смотреть
Это я почитаю, спасибо!
>Бенчмарки с Tcl не видел, интересно поискать, это правда, но что-то я удивлюсь
А вот: https://github.com/rust-lang/regex/blob/master/bench/log/05/tcl-vs-rust — и (к вопросу biased) я уже удивился — по-моему, автор не смог нормально "завести" (адаптировать / скомпилировать) этот движок или взял его не оттуда (во-первых, фактический upstream сейчас в PostgreSQL; во-вторых, в Tcl он работает только с utf-16, поэтому использование его на файлах "как есть" — автоматический performance hit как минимум в 2-3 раза).
> выяснить более эффективный, что бы это не значило
Ну это как-то несерьёзно, правда. ;)
> классификатор — это отдельная и очень широкая тема
Казалось бы, почему не просто "если это не умеет первый, используй второй" (как Вы и написали)?
> С тех пор он крайне активно разрабатывается и даже замахнулся на значительно более сложную область
Да, я заметил... но что это даёт на практике — другой вопрос. А n-грамные индексы — старая тема, на самом деле, просто в grep-ах до неё пока не очень-то дошли.
> Из использующих подобный подход с выбором движка по самому запросу я помню только ripgrep и Intel Chimera
Вот то-то и оно (Tcl всегда внутри таким был, но это исключение)... да и в vim-е нынче тоже два движка. :)
Такой метод ведения треда разве что на форумах удобен, сообщения разрастаются экспоненциально:) На что-то отвечу, больше меня не хватит
> То-то и оно. ;(
Большая часть бенчмарков этих воспроизводима / данные можно менять. Пробовал пары штук, результаты были похожие. Ну и в целом за недостатком информации по теме приходится довольствоваться тем, что есть.
> Ну это как-то несерьёзно, правда. ;)
Формализовать эту область крайне тяжело, нормальных корпусов запросов нет (на самом деле есть, но не публичные), сравнивать не на чем.
> Казалось бы, почему не просто "если это не умеет первый, используй второй" (как Вы и написали)?
Ну почти не бывает же ситуаций "на всем множестве запросов, где работает движок A, он работает строго быстрее движка B". Я почти уверен, что для любой пары движков могу подобрать регулярку и корпус, матчинг которой выполнится на первом движке быстрее, чем на втором.
> Да, я заметил... но что это даёт на практике — другой вопрос
Довольно внимательно слежу за развитием проекта; насколько я вижу по настроению вокруг, большая часть пользователей крайне довольна, да и сам BurntSushi — очень эффективный и профессиональный разработчик. Пока проект выглядит крайне перспективно, все-таки рекомендую попробовать, если есть время и тема интересна.
> Просто в grep-ах до неё пока не очень-то дошли.
Да давно дошли, тот же https://github.com/google/codesearch (он сильно неэффективный, но в целом работает), из котрого RE2 вырос, да и до него были. Просто большая часть подобных грепов крайне плоха, потому что задача выглядит простой, но на деле эффективно решается относительно сложно.
> Вот то-то и оно
Ну мы же обсуждаем интересные реализации, что бы это не значило; про простые и обделенные функциональностью как-то скучно говорить.
На Tcl посмотрю, спасибо, как-то пропускал раньше; может быть, даже в своей поделке заиспользую
UPD: Интересный тред, общаются разработчики hyperscan и rust regex / ripgrep https://news.ycombinator.com/item?id=11616482
> То-то и оно. ;(
Большая часть бенчмарков этих воспроизводима / данные можно менять. Пробовал пары штук, результаты были похожие. Ну и в целом за недостатком информации по теме приходится довольствоваться тем, что есть.
> Ну это как-то несерьёзно, правда. ;)
Формализовать эту область крайне тяжело, нормальных корпусов запросов нет (на самом деле есть, но не публичные), сравнивать не на чем.
> Казалось бы, почему не просто "если это не умеет первый, используй второй" (как Вы и написали)?
Ну почти не бывает же ситуаций "на всем множестве запросов, где работает движок A, он работает строго быстрее движка B". Я почти уверен, что для любой пары движков могу подобрать регулярку и корпус, матчинг которой выполнится на первом движке быстрее, чем на втором.
> Да, я заметил... но что это даёт на практике — другой вопрос
Довольно внимательно слежу за развитием проекта; насколько я вижу по настроению вокруг, большая часть пользователей крайне довольна, да и сам BurntSushi — очень эффективный и профессиональный разработчик. Пока проект выглядит крайне перспективно, все-таки рекомендую попробовать, если есть время и тема интересна.
> Просто в grep-ах до неё пока не очень-то дошли.
Да давно дошли, тот же https://github.com/google/codesearch (он сильно неэффективный, но в целом работает), из котрого RE2 вырос, да и до него были. Просто большая часть подобных грепов крайне плоха, потому что задача выглядит простой, но на деле эффективно решается относительно сложно.
> Вот то-то и оно
Ну мы же обсуждаем интересные реализации, что бы это не значило; про простые и обделенные функциональностью как-то скучно говорить.
На Tcl посмотрю, спасибо, как-то пропускал раньше; может быть, даже в своей поделке заиспользую
UPD: Интересный тред, общаются разработчики hyperscan и rust regex / ripgrep https://news.ycombinator.com/item?id=11616482
YS
Такой метод ведения треда разве что на форумах удобен, сообщения разрастаются экспоненциально:) На что-то отвечу, больше меня не хватит
> То-то и оно. ;(
Большая часть бенчмарков этих воспроизводима / данные можно менять. Пробовал пары штук, результаты были похожие. Ну и в целом за недостатком информации по теме приходится довольствоваться тем, что есть.
> Ну это как-то несерьёзно, правда. ;)
Формализовать эту область крайне тяжело, нормальных корпусов запросов нет (на самом деле есть, но не публичные), сравнивать не на чем.
> Казалось бы, почему не просто "если это не умеет первый, используй второй" (как Вы и написали)?
Ну почти не бывает же ситуаций "на всем множестве запросов, где работает движок A, он работает строго быстрее движка B". Я почти уверен, что для любой пары движков могу подобрать регулярку и корпус, матчинг которой выполнится на первом движке быстрее, чем на втором.
> Да, я заметил... но что это даёт на практике — другой вопрос
Довольно внимательно слежу за развитием проекта; насколько я вижу по настроению вокруг, большая часть пользователей крайне довольна, да и сам BurntSushi — очень эффективный и профессиональный разработчик. Пока проект выглядит крайне перспективно, все-таки рекомендую попробовать, если есть время и тема интересна.
> Просто в grep-ах до неё пока не очень-то дошли.
Да давно дошли, тот же https://github.com/google/codesearch (он сильно неэффективный, но в целом работает), из котрого RE2 вырос, да и до него были. Просто большая часть подобных грепов крайне плоха, потому что задача выглядит простой, но на деле эффективно решается относительно сложно.
> Вот то-то и оно
Ну мы же обсуждаем интересные реализации, что бы это не значило; про простые и обделенные функциональностью как-то скучно говорить.
На Tcl посмотрю, спасибо, как-то пропускал раньше; может быть, даже в своей поделке заиспользую
UPD: Интересный тред, общаются разработчики hyperscan и rust regex / ripgrep https://news.ycombinator.com/item?id=11616482
> То-то и оно. ;(
Большая часть бенчмарков этих воспроизводима / данные можно менять. Пробовал пары штук, результаты были похожие. Ну и в целом за недостатком информации по теме приходится довольствоваться тем, что есть.
> Ну это как-то несерьёзно, правда. ;)
Формализовать эту область крайне тяжело, нормальных корпусов запросов нет (на самом деле есть, но не публичные), сравнивать не на чем.
> Казалось бы, почему не просто "если это не умеет первый, используй второй" (как Вы и написали)?
Ну почти не бывает же ситуаций "на всем множестве запросов, где работает движок A, он работает строго быстрее движка B". Я почти уверен, что для любой пары движков могу подобрать регулярку и корпус, матчинг которой выполнится на первом движке быстрее, чем на втором.
> Да, я заметил... но что это даёт на практике — другой вопрос
Довольно внимательно слежу за развитием проекта; насколько я вижу по настроению вокруг, большая часть пользователей крайне довольна, да и сам BurntSushi — очень эффективный и профессиональный разработчик. Пока проект выглядит крайне перспективно, все-таки рекомендую попробовать, если есть время и тема интересна.
> Просто в grep-ах до неё пока не очень-то дошли.
Да давно дошли, тот же https://github.com/google/codesearch (он сильно неэффективный, но в целом работает), из котрого RE2 вырос, да и до него были. Просто большая часть подобных грепов крайне плоха, потому что задача выглядит простой, но на деле эффективно решается относительно сложно.
> Вот то-то и оно
Ну мы же обсуждаем интересные реализации, что бы это не значило; про простые и обделенные функциональностью как-то скучно говорить.
На Tcl посмотрю, спасибо, как-то пропускал раньше; может быть, даже в своей поделке заиспользую
UPD: Интересный тред, общаются разработчики hyperscan и rust regex / ripgrep https://news.ycombinator.com/item?id=11616482
> Формализовать эту область крайне тяжело, нормальных корпусов запросов нет (на самом деле есть, но не публичные), сравнивать не на чем.
Это да, а что есть публичное — обычно выбрано более-менее случайно.
Но мне помнится, что где-то были ещё "заточенные" на типичные слабые места движков того или иного типа, кстати.
> Ну почти не бывает же ситуаций "на всем множестве запросов, где работает движок A, он работает строго быстрее движка B"
А обычно не нужно "строго лучше", достаточно "чаще всего". Тогда можно делать fallback на "медленный" только тогда, когда "быстрый" этого не умеет, да и сойдёт.
> Просто большая часть подобных грепов крайне плоха
Я это и имел в виду под "не очень-то дошли". А вообще, в плане "дошли", что касается Computer Science (исследований / статей), то можно убедиться, что почти любую идею уже придумали, реализовали, оценили и забыли лет 30-40 назад. ;)
> про простые и обделенные функциональностью как-то скучно говорить.
Не знаю, не знаю... у некоторых современных движков функционал уже несколько чересчур — т.е. подталкивает к тому, что, когда давно бы пора бы regex-ы бросить в качестве инструмента (и уже использовать полноценные parsers), можно упоротно продолжать за них цепляться. ;)
Это да, а что есть публичное — обычно выбрано более-менее случайно.
Но мне помнится, что где-то были ещё "заточенные" на типичные слабые места движков того или иного типа, кстати.
> Ну почти не бывает же ситуаций "на всем множестве запросов, где работает движок A, он работает строго быстрее движка B"
А обычно не нужно "строго лучше", достаточно "чаще всего". Тогда можно делать fallback на "медленный" только тогда, когда "быстрый" этого не умеет, да и сойдёт.
> Просто большая часть подобных грепов крайне плоха
Я это и имел в виду под "не очень-то дошли". А вообще, в плане "дошли", что касается Computer Science (исследований / статей), то можно убедиться, что почти любую идею уже придумали, реализовали, оценили и забыли лет 30-40 назад. ;)
> про простые и обделенные функциональностью как-то скучно говорить.
Не знаю, не знаю... у некоторых современных движков функционал уже несколько чересчур — т.е. подталкивает к тому, что, когда давно бы пора бы regex-ы бросить в качестве инструмента (и уже использовать полноценные parsers), можно упоротно продолжать за них цепляться. ;)
D
antony pywhy?
покаж как
Есть плагин для этого: https://github.com/Nyquase/vi-mode
ap
нафигааааа
ap
только хоткеи?
VG
Нет. Если я буду открывать vim для редактирования каждой команды в течение рабочего дня, то это будет неудобно.
Мне нужен именно интерактивный vi mode с отображением всех режимов в промпте.
Мне нужен именно интерактивный vi mode с отображением всех режимов в промпте.
а зачем вообще vi-мод в шелле, где строка всего одна?
S
а зачем вообще vi-мод в шелле, где строка всего одна?
Потому что строк может быть много.
SS
antony pywhy?
ты их все редачить можешь?
Да, почему нет