Ничто не припятствует использовать gogrep/phpgrep внутри emacs/vim/чём-либо другом. Причём плюс перечисленных инструментов в том, что они могут быть использованы в терминале напрямую.
В интерфейсе всё ещё доступна кнопка на переход в старый редактор. Уже довольно давно обещают его поддержку отключить, но пока ещё можно в markdown писать.
Я даже не знаю, что буду делать, когда это всё будет невозможно. :(
Видимо, это будет мотивация писать статьи на английском и выкладывать их где-то в другом месте. В WYSIWYG я набирать не буду не потому что на хабре он недостаточно хорош, а потому что мне тот же VS Code (а ранее Emacs) для этого кажется более подходящим. А markdown приятен тем, что можно исходники статьи сохранить и не потерять форматирование.
Если вставка markdown в WYSIWYG начнёт работать лучше, то может реально будет какие-то статьи с простым форматированием публиковать без редактирования на самом хабре. Но из того, что я пробовал, пока что криво вставляется (например, блоки кода выходят за свои границы и включают лишнее).
Я сначала даже удивился, что на корпусе было 0 срабатываний, но тесты в gogrep показывают, что матчить такие паттерны он может. Так что делаем выводы, что быстрый insert в слайс если и добавлять, то через внешний generic пакет, а не через распознавание паттерна компилятором.
Хотя это так же может означать, что корпус недостаточно разнородный. Если есть предложения, что ещё добавить - открывайте issue, будем расширять. :)
Кроме "разработчиков компилятора", это так же полезно в следующих случаях:
Разработка инструментов разработчика (IDE и плагины для редакторов, тулы для рефакторинга).
Разработка статических анализаторов.
Попытка выбора между вариантами X и Y, когда вы составляете гайдлайны стиля для своей команды (выбираете более идиоматичное).
Банальное удовлетворение любопытства.
Как вы и сказали, при работе над самим Go это тоже полезно. И именно для этого я это и делал в первую очередь, чтобы можно было как-то аргументировать свои доводы при обсуждении той или иной идее или планов по добавлению оптимизаций в компилятор.
А что именно "зачем"? Чтобы лучше понимать, что отвечать, хоть я и не "автор языка". И речь про KPHP или PHP? Может быть, кто-то из команды PHP что-то относительно FFI высказывал и вы на это ссылаетесь? Если так, то поделитесь ссылочкой, интересно ознакомиться.
Далее буду считать, что вы уточнили, "зачем это всё в KPHP?"
Я в статье постарался это затронуть, но если кратко: FFI не ограничивается геймдевом и/или графическими приложениями. Через него, гипотетически, можно использовать некоторые C-библиотеки. Зачем нам "какие-то" C-библиотеки? Чтобы была возможность через них реализовать недостающий функционал KPHP (libgd, например).
Одно из преимуществ FFI: модуль для работы с libgd будет работать и на KPHP, и на PHP. Распространять его можно как composer пакет. А ещё этот модуль не нужно будет вливать в основной репозиторий KPHP (в "ядро" языка).
Я в репозитории с кодом указал, что ассеты не принадлежат авторам проекта, а лицензия самого кода (MIT) не распространяется на ассеты.
Думаю, стоит добавить конкретики и указать, что ассеты именно из Warcraft II.
В сам текст статьи не уверен, что есть смысл добавлять об этом. Статья не владеет кодом, как и игрой. А лицензия у игры и ассетов прописаны отдельно.
Но, конечно же, вы правы. Это довольно рискованно было выкладывать такое с юридической точки зрения.
Вместо удаления игры или скрытия её, возможно, я постараюсь заменить спрайты на полностью открытые или сам перерисую. А до тех пор, ассеты будут удалены. Игру собрать, соответственно, не получится.
Не очень понятно, как это возможно, потому что фичу для KPHP делал лично я, статью писал - тоже я, игру для демонстрации, опять же, вместе со мной делали.
У FFI в KPHP есть свои особенности. Например, есть типы ffi_cdata и ffi_scope, без которых код работать не будет. По ходу повествования я раскидал ещё парочку трюков, которые были необходимы, чтобы игра запускалась и на PHP, и на KPHP.
Там есть как разработчики самого KPHP, так и пользователи. Присоединяйтесь. :)
А ещё есть https://github.com/quasilyte/awesome-kphp, который может стать более полным с вашей помощью. Через FFI можно реализовать недостающий функционал, а чтобы о ваших библиотеках было проще узнать остальным пользователям - давайте добавлять все полезняшки в этот индекс.
Я на eg обращал ранее внимание, но к нему маловато документации и примеров. Выглядит как более простая утилита, чем gogrep, я так понимаю, там нет фильтров по атрибутам и не построить конвейеры. Использовать отдельный файл с before/after выглядит не так удобно для интерактивной команды (хотя расширение могло бы создавать такой файл самостоятельно).
Есть ещё малоизвестный (?) gofmt -r, сравнение с которым было в докладе автора gogrep.
Я не знаю, сделано для Go или нет, но в IDE известной компании есть SSR, который работает для нескольких ЯП.
В ruleguard есть возможность описывать quickfix на основе тех же gogrep шаблонов. Разница в том, что можно хранить правила в отдельном файле, что позволит на сохранении заменять всё, что хочется упрощать автоматически. Вот простой пример:
Надо обладать определенной смелостью, чтобы от лица компании публично критиковать слова другого человека.
Мне кажется, не обязательно приписывать любое высказывание сотрудника высказыванию от лица компании. Как минимум, этот пост не в блоге Яндекса.
Я не знаю, когда это было добавлено в статью, но сейчас там есть это:
Дисклаймер: написанное ниже является моим личным мнением, официальное мнение компании по данному вопросу мне неизвестно.
Ради мыслительного эксперимента, мы можем поставить себя на место другого. Если некто работает в компании X, ему или ей может быть не очень приятно, если любое высказывание (даже с дисклеймером) могут назвать высказыванием от лица X.
Меня только беспокоит, что с какого-то момента переходишь тот порог, когда организация становится более серьёзной и напоминает работу.
Первые встречи сообщества, помню, можно было делать гораздо проще, всё ощущалось непринуждённо. Я бы и дальше делал бы такие встречи с минимальными усилиями, но некоторые не согласны с такой позицией.
Если бы в статье не было практически прямых оскорблений и принижения чужой позиции, она была бы менее популярной на хабре?
Я могу согласиться с посылом статьи, так как я тоже за статическую типизацию, но нападения на других людей отталкивает от текста, отвлекает от мысли. Мне не нравится читать о "динамической типизации", но отвлекаться на описание чьей-то "башки" и приравнивание её к тупой.
В списке причин минуса к статье нет такого, который описывал бы агрессивность изложения, а ставить за "другое" не хочется. Есть "личная неприязнь к автору", но я же автора как человека не знаю, мне конкретно текст не нравится. :)
Если что, структурный поиск и замена так же доступны в том же VS Code (и можно в другие редакторы добавить).
Для Go это делается через gogrep.
Для PHP это делается через phpgrep.
Ничто не припятствует использовать gogrep/phpgrep внутри emacs/vim/чём-либо другом. Причём плюс перечисленных инструментов в том, что они могут быть использованы в терминале напрямую.
В интерфейсе всё ещё доступна кнопка на переход в старый редактор. Уже довольно давно обещают его поддержку отключить, но пока ещё можно в markdown писать.
Я даже не знаю, что буду делать, когда это всё будет невозможно. :(
Видимо, это будет мотивация писать статьи на английском и выкладывать их где-то в другом месте. В WYSIWYG я набирать не буду не потому что на хабре он недостаточно хорош, а потому что мне тот же VS Code (а ранее Emacs) для этого кажется более подходящим. А markdown приятен тем, что можно исходники статьи сохранить и не потерять форматирование.
Если вставка markdown в WYSIWYG начнёт работать лучше, то может реально будет какие-то статьи с простым форматированием публиковать без редактирования на самом хабре. Но из того, что я пробовал, пока что криво вставляется (например, блоки кода выходят за свои границы и включают лишнее).
Вот реальный пример где это было полезно:
cmd/compile: detect and optimize slice insertion idiom append(sa, append(sb, sc...)...) · Issue #31592 · golang/go (github.com)
Я сначала даже удивился, что на корпусе было 0 срабатываний, но тесты в gogrep показывают, что матчить такие паттерны он может. Так что делаем выводы, что быстрый insert в слайс если и добавлять, то через внешний generic пакет, а не через распознавание паттерна компилятором.
Хотя это так же может означать, что корпус недостаточно разнородный. Если есть предложения, что ещё добавить - открывайте issue, будем расширять. :)
Кроме "разработчиков компилятора", это так же полезно в следующих случаях:
Разработка инструментов разработчика (IDE и плагины для редакторов, тулы для рефакторинга).
Разработка статических анализаторов.
Попытка выбора между вариантами X и Y, когда вы составляете гайдлайны стиля для своей команды (выбираете более идиоматичное).
Банальное удовлетворение любопытства.
Как вы и сказали, при работе над самим Go это тоже полезно. И именно для этого я это и делал в первую очередь, чтобы можно было как-то аргументировать свои доводы при обсуждении той или иной идее или планов по добавлению оптимизаций в компилятор.
А что именно "зачем"? Чтобы лучше понимать, что отвечать, хоть я и не "автор языка". И речь про KPHP или PHP? Может быть, кто-то из команды PHP что-то относительно FFI высказывал и вы на это ссылаетесь? Если так, то поделитесь ссылочкой, интересно ознакомиться.
Далее буду считать, что вы уточнили, "зачем это всё в KPHP?"
Я в статье постарался это затронуть, но если кратко: FFI не ограничивается геймдевом и/или графическими приложениями. Через него, гипотетически, можно использовать некоторые C-библиотеки. Зачем нам "какие-то" C-библиотеки? Чтобы была возможность через них реализовать недостающий функционал KPHP (libgd, например).
Одно из преимуществ FFI: модуль для работы с libgd будет работать и на KPHP, и на PHP. Распространять его можно как composer пакет. А ещё этот модуль не нужно будет вливать в основной репозиторий KPHP (в "ядро" языка).
Кажется, удалось сохранить примерно такой же внешний вид, заменив при этом все ассеты на свободные.
Отдохнуть правда этим вечером не получилось. :)
Я в репозитории с кодом указал, что ассеты не принадлежат авторам проекта, а лицензия самого кода (MIT) не распространяется на ассеты.
Думаю, стоит добавить конкретики и указать, что ассеты именно из Warcraft II.
В сам текст статьи не уверен, что есть смысл добавлять об этом. Статья не владеет кодом, как и игрой. А лицензия у игры и ассетов прописаны отдельно.
Но, конечно же, вы правы. Это довольно рискованно было выкладывать такое с юридической точки зрения.
Не очень понятно, как это возможно, потому что фичу для KPHP делал лично я, статью писал - тоже я, игру для демонстрации, опять же, вместе со мной делали.
У FFI в KPHP есть свои особенности. Например, есть типы ffi_cdata и ffi_scope, без которых код работать не будет. По ходу повествования я раскидал ещё парочку трюков, которые были необходимы, чтобы игра запускалась и на PHP, и на KPHP.
Напоминаю, что у KPHP есть чатик сообщества в телеграме: https://t.me/kphp_chat
Там есть как разработчики самого KPHP, так и пользователи.
Присоединяйтесь. :)
А ещё есть https://github.com/quasilyte/awesome-kphp, который может стать более полным с вашей помощью. Через FFI можно реализовать недостающий функционал, а чтобы о ваших библиотеках было проще узнать остальным пользователям - давайте добавлять все полезняшки в этот индекс.
Мы там даже обсуждаем всякие внутренности KPHP и помогаем тем, у кого возникают проблемы с использованием.
Так что welcome. :)
Я думаю, вы про https://plugins.jetbrains.com/plugin/9927-deep-assoc-completion ?
Из коробки PhpStorm, кажется, такое не поддерживает.
А кроме автодоплений для tuple и shape типов плагин умеет ещё и другие вещи.
FAQ.
Q: Что такое "движки"?
A:
s/движки/сервисы/
(или "демоны") — сервис сообщений, сервис лайков, etc.Из статьи:
Q: А как происходит обращение к полям из KPHP?
A: По именам, но без динамических выражений.
Не особо.
Но если поискать в интернете, автоматическую векторизацию вроде как не хотят добавлять из-за потенциального замедления компиляции.
Новый calling convention уже давно обсуждается и там есть некоторые успехи в этом направлении. Тоже по Go трекеру можно найти.
mid-stack инлайнинг уже работает из коробки. Эвристики инлайнинга вроде тоже несколько раз подкручивали.
Сворачивание константных выражений тоже, скорее всего, улучшилось. Хотя чудес типа символического исполнения я бы не ждал.
Добавлю в статью и унесу под спойлер. :)
Я на
eg
обращал ранее внимание, но к нему маловато документации и примеров. Выглядит как более простая утилита, чемgogrep
, я так понимаю, там нет фильтров по атрибутам и не построить конвейеры. Использовать отдельный файл с before/after выглядит не так удобно для интерактивной команды (хотя расширение могло бы создавать такой файл самостоятельно).Есть ещё малоизвестный (?)
gofmt -r
, сравнение с которым было в докладе автора gogrep.Я не знаю, сделано для Go или нет, но в IDE известной компании есть SSR, который работает для нескольких ЯП.
В ruleguard есть возможность описывать quickfix на основе тех же
gogrep
шаблонов. Разница в том, что можно хранить правила в отдельном файле, что позволит на сохранении заменять всё, что хочется упрощать автоматически. Вот простой пример:Находим вызовы
Fprintf
с аргументовStdout
и заменяем наPrint*
функции.Мне кажется, не обязательно приписывать любое высказывание сотрудника высказыванию от лица компании. Как минимум, этот пост не в блоге Яндекса.
Я не знаю, когда это было добавлено в статью, но сейчас там есть это:
Ради мыслительного эксперимента, мы можем поставить себя на место другого. Если некто работает в компании X, ему или ей может быть не очень приятно, если любое высказывание (даже с дисклеймером) могут назвать высказыванием от лица X.
Если кто-то использует VS Code для PHP, то теперь под него есть расширение для удобного использования phpgrep.
Меня только беспокоит, что с какого-то момента переходишь тот порог, когда организация становится более серьёзной и напоминает работу.
Первые встречи сообщества, помню, можно было делать гораздо проще, всё ощущалось непринуждённо. Я бы и дальше делал бы такие встречи с минимальными усилиями, но некоторые не согласны с такой позицией.
Если бы в статье не было практически прямых оскорблений и принижения чужой позиции, она была бы менее популярной на хабре?
Я могу согласиться с посылом статьи, так как я тоже за статическую типизацию, но нападения на других людей отталкивает от текста, отвлекает от мысли. Мне не нравится читать о "динамической типизации", но отвлекаться на описание чьей-то "башки" и приравнивание её к тупой.
В списке причин минуса к статье нет такого, который описывал бы агрессивность изложения, а ставить за "другое" не хочется. Есть "личная неприязнь к автору", но я же автора как человека не знаю, мне конкретно текст не нравится. :)
На afterparty планируем делать live выпуск GenericTalks.
Это если кому-то захочется переключиться с основной комнаты для обсуждений.