Нашли или выдавили из себя код, который нельзя назвать нормальным,
на который без улыбки не взглянешь?
Не торопитесь его удалять или рефакторить, — запостите его на
говнокод.ру, посмеёмся вместе!
А что там может проебаться? Тупо запускаешь цикл https://govnokod.ru/user/1 .. сколькотамвсегопользователей и вытаскиваешь цифру из <a href="https://govnokod.ru/user/1/codes">Его говнокоды (1419)</a>
Да там просто с длиной какая-то хуйня начинается. Поэтому, имхо, лучше считать что есть отдельные массивы и хешмапы. И никогда их не смешивать между собой.
да, именно с длиной у разрешенных таблоиц и есть проблема.
длина у них будет равна непрерывной их части. Таблица в луа это единственный нескалярный тип данных: он может быть массивом, словарем (хешем/мапой) или объектом, даже неймспейсом.
Лучше конечно все это не смешивать.
А угадай, в каком еще божественном язые можно смешать массив и ассоциативный массив?
local a = {'a', 'b', 'c'}
print(#a) --3
a['makaka'] = 'uroboros'
print(#a) --снова 3!!
--но при этом
for k,v in pairs(a) do
print(v) --a,b,c,urubotos, то-есть 4!!
end
И я помню что мне однажды нужно было постоянно считать подобные таблы. По этому я перегружал # __len
Помнитя в 5.1 нельзя перегрузить len по этому я там извращался - добавлял новый элемент n в каждую новую таблицу и при добавлении туда любой хуйни - вызывал я метода который n=n+1 просто.
Я читал мануал по Lua, какую-то тестовую питушню делал. Может, на ГК пару кусков кода оставил когда-то давно, когда Сёма ещё считал себя русским.
Потом я увидел Ваше "давненько я не брал в руки шашек" и код с sequence и какой-то монадической питушнёй, решил посмотреть в сторону хаскеля. После заражения функциональной питушанкой оказалось, что нормальную программу нельзя написать без map и forEach, а в Lua их вроде бы нет, и вообще какая-то процедурных сишных питухов с жсовскими слабодинамическими ворециями. Lua стал забываться. Теперь я помню только, что там есть таблицы {}, интересная находка в виде разницы между точкой и двоеточием, а также разделение данных и метаданных у таблиц, что позволяет без специальных знаний тонкостей языка создать хороший ассоциативный массив, которому, в отличие от жс, ничего не угрожает.
А есщо налаживал связку nginx + gunicorn + flask + python + mysql + phpmyadmin + ещё куча хуеты. Весь день потратил на прыщепердолинг с питонячими модулями.
Именно, блять, поэтому я за "PHP".
Да? А я видел использование uwsgi именно как в "PHP". На каждый запрос вызывается твой скрипт. То есть http://site.com/index.py вызовет скрипт index.py, и в переменных окружения у тебя будут данные о запросе.
Там хитрая хуйня. Она в любом режиме работы одинаково выглядит, как ты описал. Даже если мультитред, то эти глобальные переменные эмулируются через тредлокалы. Но скрипт при этом может невозбранно болтаться в памяти, в отличие от пхп.
Так я не понял, когда я работаю через flask, я могу сохранять глобальные пельменные, и на следующем запросе их использовать. Так? Смогу ли я так с uwsgi?
Ну можешь, только когерентность кеша между процессами uwsgi тебе никто не гарантирует. Так что скорее всего придётся тот же мемкешед юзать если таблички не совсем read-only...
нужно различать API и то, как физически обрабатывается запрос
В классическом CGI cервер на каждый запрос запускает скрипт (fork+exec или CreateProcess) передавая ему переменные окружения.
Скрипт читал переменные окурения, выдавал заголовки в stdout, затем \r\n\r\n и тело.
Это было API CGI.
В различных mod_[..] интерпретатор грузился в сервер, и новых процессов не создавалось (все работало в контексте сервера) и там были свои API, у каждого языка свои. Пых видел _REQUEST (но вероятно не видел переменных окружения), python имеел спец метод request(), mod_perl имел функцию handler, но мог эмулировать и CGI api.
В FastCGI сервер приложений работал в отдельном процессе, общаясь с сервером по протоколу FastCGI.
API опять таки у всех были разные.
Наконец, питонистов заебало, и они сделали спецификацию WSGI: это было API
Gunicorn запускает скрипт предоставляя ему wsgi api, а с другой стороны реализует HTTP.
uwsgi делает тоже самое, но вместо http может реализовывать FastCGI для связи с nginx или apache.
Пиздец, ты как-то сложно объясняешь. Я вижу 2 способа работы.
Начнём с того, что мне похуй по какому протоколу общается nginx с кем-либо. И мне похуй на каком языке писать.
1) Я могу написать программу, которая 1 раз запускается, слушает сокет (в нашем случае от nginx), и отвечает на запросы. Может делать это в несколько потоков, и сохранять данные в глобальные массивы (в случае C++, например). Если программа крешнется, то её кто-то должен перезапустить.
2) Я могу написать программу, которая запускается на каждый запрос, в которую по stdin или как-то ещё получает дынные, и высирает ответ в stdout. У неё нет шансов сохранить стейт в памяти (то самое, что каждый петух знает). Это классическая схема для PHP.
И вы мне, блять, не можете ответить к чему относится gunicorn, и к чему uwsgi.
Все (кроме классического CGI) работает по первой схеме, с той лишь разницей, что сохранить ты ничего не можешь, потому что таких процессов может быть несколько (и они будут мультиплексироваться через главный процесс)
ПХП тоже не работает по второй схеме, если только он не запущен через cgi (что почти никогда не бывает).
ДАнные ты в пхп тоже не сохранишь, но сам процесс интерпретатора никуда не денется из памяти
Не совсем так. Кто-то извне зовёт функцию в твоём index.py. При этом он может это сделать как на чистом инстансе твоего скрипта, так и на поюзанном. Или даже исполнить несколько запросов на одном инстансе скрипта параллельно, если включены треды.
Возможно, ты использовал PHP как CGI, и у тебя сложилось превратное представление: якобы PHP может работать только как CGI.
Но это не так.
Как CGI может работать любой язык, хоть шелл скрипт. Просто запускается внешний скрипт, выдает stdout, и умирает.
Это очень медленно, потому в какой-то момент стали интерпретатор загружать в аресное пространство веб-сервера (mod_php, mod_perl итд).
Для скриптов как-бы ничего не изменилось (кроме появления взможрости делать http auth), но физически они висели в памяти.
Можно было даже насрать в глобальный стейт случайно (скорее их сишного расширения, чем из скрипта), но официальных API не было.
Затем, скрипты стали запускать отельным процессом -- php-fpm, например. В нем по-прежнему нету API для сохранения состояния, но наверняка можно как-то изъебнуться, может быть специфичным для php-fpm способом.
Единственный способ изъебнуться именно в «PHP» — это использовать расширение. Например, «memcache».
Я тебя удивлю, но единственная функция «PHP» для «FastCGI» — это fastcgi_finish_request. Она отправляет страницу клиенту, рвёт с ним соединение, но продолжает выполнять скрипт. Дальше клиент может хоть закрыть вкладку, скрипт будет выполняться молча, не отправляя ничего клиенту.
Гипотетически эта функция предназначена для выполнения тяжёлой задачи типа работы с базой данных. О результатах клиент может узнать, только сделав следующий запрос.
А для HTTP Auth, если не путаю, состояние хранится не в памяти, а в файликах в /tmp (надо проверить).
Процессов может быть запущено несколько. Каким именно процессом будет обработан следующий запрос, зависит от фазы луны. Полагаться на то, что следующий запрос будет обработан тем же самым процессом, нельзя, поэтому память процесса для аутентификации мы использовать не можем. Для аутентификации нужно общее хранилище, которое шарится между всеми процессами.
#!/usr/bin/env php
<?php
// if you don't want to setup permissions the proper way, just uncomment the following PHP line
// read http://symfony.com/doc/current/book/installation.html#configuration-and-setup for more information
//umask(0000);
set_time_limit(0);
require_once __DIR__.'/bootstrap.php.cache';
require_once __DIR__.'/AppKernel.php';
use Symfony\Bundle\FrameworkBundle\Console\Application;
use Symfony\Component\Console\Input\ArgvInput;
$input = new ArgvInput();
$env = $input->getParameterOption(array('--env', '-e'), getenv('SYMFONY_ENV') ?: 'dev');
$debug = getenv('SYMFONY_DEBUG') !== '0' && !$input->hasParameterOption(array('--no-debug', '')) && $env !== 'prod';
$kernel = new AppKernel($env, $debug);
$application = new Application($kernel);
$application->run($input);
И как это всё работает? «Конардо» не поймёт такой код. В «AppKernel.php» тоже какая-то бесполезная херня вроде перечисления классов.
Нет, всё не ставится. Чем больше пакетов уже́ установлено, тем больше системные требования. Похоже на алгоритм маляра Шлемиля.
В распакованном виде все пакеты, включая «Symfony», не наберут и сотню мегабайт. Для чего компостеру несколько гигов оперативки? Чтобы майнить биткоины?
Причём все эти пакеты почему-то потребовались «Говнокоду» — по сути простенькому коллективному блогу с комментариями. Мне казалось, что это не rocket science.
Рискну предположить, что он пытается построить граф зависимостей, и тот банально не влезает в память:)
Предел памяти установлен у самого интерпретатора, чтобы не вызвать подкачку из вторичной памяти (это медленно) либо же чтобы не вызвать OOMKiller в случае отсутствия подкачки.
Граф можно было бы обрабатывать по частям, реализовав нечто типа оверлеев, но странно делать это вручную при наличии виртуальной памяти.
С другой стороны, сам граф можно было бы разбить на несколько и тем самым понизить потребление памяти.
А в самом переиспользовании сторонних пакетов я не вижу ничего дурного.
Я ещё могу понять, почему долго думают менеджеры пакетов, у которых репозиторий глобальный (cpan, pip, gem, pear, opam, cabal) — там нужно дважды подумать перед установкой нового пакета, чтобы не сломать установленный софт.
Но «Composer» ставит пакеты локально, в чистую директорию. Требуемые версии указаны в файле «composer.json». Тут даже нечего ломать несовместимой версией.
Это всё растёт, как снежный ком. Я это понимаю так: в ORM «Doctrine» обнаружился фатальный недостаток, поэтому необходимо подпереть его очередным костылём.
Емнип, они оба реализуют WSGI API. Которое уже используется фласком, джангой и прочей хуйнёй для обработки запросов. Можешь и сам функцию написать без фреймворков.
Т.е. питоньему скрипту вообще насрать что там в качестве транспорта - http, fastcgi или какой-нибудь mod_python. Ему просто зовут функцию с нужными параметрами и окружением. А свежее это состояние скрипта или нет - зависит от реализации, настроек и погоды на луне.
wsgi api НЕ дает гарантии, что ты запустишься на том же самом интерпретаторе
Можно использовать более низкоуровневые api, например самому реализовать FastCGI и тогда твой скрипт действительн будет жить вечно, но плодить потоки ты будешь см
Я не на столько туп, и не завязывался, а планировать использовать как кеш. Я прекрасно понимаю, что если запустится несколько инстансов, то у них не будет общей памяти.
Вы всегда пишите свои программы под какой-то API, верно?
API предоставляет вам функционал, и определяет для него семантику. Иными словами, вам могут даваться (или не даваться) определенные гарантии.
Если вы используете api wsgi (а так поступают обычно Flask и Django), то такое API не дает гарантий, что каждый запрос исполнится в том же самом процессе.
Если авторы сервера приложений (gunicorn, uwsgi) решат по какой-то причине очищать глобальный стейт после каждого запроса, то они будут полностью правы (они НЕ нарушат спецификации), а ваш кеш сломается
Хм, а мне казалось, что там какая-то нелогичная питушня и функциональщина уровня "автор читал учебник по хаскелю, но надышался краской и сделал как в сишке".
Какие-то оторванные блоки родом из структурного программирования, которые можно переиспользовать и передавать в недо-ФВП, обычные функции/методы, у которых другой тип, и хрен их куда передашь и хрен ссылку на них получишь и т.п. Зато map отзывается на 100500 алиасов.
Как будто функциональщину туда затащили решением суда, и был вариант либо выучить хаскель за 21 час и сделать так же, либо отправляться на виселицу.
То ли дело JS, где передача функции в ФВП выглядит естественно, и вообще не надо тужиться и думать, чтобы её передать.
он же хуй
он же растворение
Некоторые концепции (корутины там, генераторы) не такие уж и простые
Основное дерьмо учится за 15 минут. Главное осознать метатаблицы.
длина у них будет равна непрерывной их части. Таблица в луа это единственный нескалярный тип данных: он может быть массивом, словарем (хешем/мапой) или объектом, даже неймспейсом.
Лучше конечно все это не смешивать.
А угадай, в каком еще божественном язые можно смешать массив и ассоциативный массив?
А в жопоскрипте можно смешивать ассоциативный массив и поля объекта. Более того, obj.coq и obj['coq'] ссылаются на один и тот же элемент.
Главное не перепутать, где что с чем перемешано.
Помнитя в 5.1 нельзя перегрузить len по этому я там извращался - добавлял новый элемент n в каждую новую таблицу и при добавлении туда любой хуйни - вызывал я метода который n=n+1 просто.
https://www.lua.org/pil/10.2.html
Потом я увидел Ваше "давненько я не брал в руки шашек" и код с sequence и какой-то монадической питушнёй, решил посмотреть в сторону хаскеля. После заражения функциональной питушанкой оказалось, что нормальную программу нельзя написать без map и forEach, а в Lua их вроде бы нет, и вообще какая-то процедурных сишных питухов с жсовскими слабодинамическими ворециями. Lua стал забываться. Теперь я помню только, что там есть таблицы {}, интересная находка в виде разницы между точкой и двоеточием, а также разделение данных и метаданных у таблиц, что позволяет без специальных знаний тонкостей языка создать хороший ассоциативный массив, которому, в отличие от жс, ничего не угрожает.
Там просто феерия функциональщины, всю программу можно написать в одну строку.
Заебал майкрософт со своими обновлениями, мне на форуме посоветовали их отключить
Ветер северный
в 3.7 -- дата классы
в 3.9 наверное структуры завезут
а вы все про 36
Всё нормально работает под Windows, а прышепитон -- нет
Кстати, сайт «Леруа Мерлен» перестал работать в старых браузерах. А там всего лишь табличка картинок и наименований товаров.
Именно, блять, поэтому я за "PHP".
> phpmyadmin
Блядь, лол, есть.
а как еще на продакшен базе выполнить DELETE и ошибиться в условии WHERE?
https://memepedia.ru/wp-content/uploads/2017/05/KHhcEzQy3xA-600x338.jpg
А если нужна сама база, я предлагаю сливать ее копию в реальном времени и смотреть в нее командлайн тулой или DataGrip или чем ты там смотришь.
Запускать левые запросы на продакшен базе это очень плохо
Иметь туда райт доступ еще хуже
Поднимать ради этого доступа веб приложение на чужом языке -- вообще мне не поняно
но на самом деле даже и без наеба можно написать случайно такой запрос, что продакшен база станет раком на пару минут
Закроешь сессию да и всё. Вроде все СУБД такое прерывание умеют. Не?
https://bugs.mysql.com/bug.php?id=78809
https://dev.mysql.com/doc/refman/5.7/en/kill.html
uwsgi умнее, быстрее, и умеет в fastcgi
FastCGI это висящий демоном процесс, просто с твоим nginx он разговаривает по протоколу FastCGI, а не по HTTP.
Так что не надо два раза парсить заголовки, и не надо костылей, чтобы передать REMOTE_ADDR и пр
1. Поскольку сам процесс «PHP» висит в памяти, контекст расширений не очищается. Именно поэтому работает расширение «memcache».
2. Из-за архитектуры самого интерпретатора «PHP» его контекст всё равно очищается после каждого запроса (это каждый петух знает).
именно по этому я за джава сервелат или за приложения под дотнет
там можно запустить соседний поток и чото там делать, а тут на каждый запрос как сначала
https://www.php.net/manual/ru/function.socket-accept.php
Но так почему-то не делают.
Т.к. следующий запрос может уйти в соседний процесс uwsgi. Или текущий процесс uwsgi ребутнётся для профилактики.
В общем, это больше для разогрева кода чем для хранения данных.
А я ебу. Я его не юзал ни разу.
Просто нет такого api, и все.
Если у тебя что-то где-то случайно сохранилось, то тебе просто повезло.
В классическом CGI cервер на каждый запрос запускает скрипт (fork+exec или CreateProcess) передавая ему переменные окружения.
Скрипт читал переменные окурения, выдавал заголовки в stdout, затем \r\n\r\n и тело.
Это было API CGI.
В различных mod_[..] интерпретатор грузился в сервер, и новых процессов не создавалось (все работало в контексте сервера) и там были свои API, у каждого языка свои. Пых видел _REQUEST (но вероятно не видел переменных окружения), python имеел спец метод request(), mod_perl имел функцию handler, но мог эмулировать и CGI api.
В FastCGI сервер приложений работал в отдельном процессе, общаясь с сервером по протоколу FastCGI.
API опять таки у всех были разные.
Наконец, питонистов заебало, и они сделали спецификацию WSGI: это было API
Gunicorn запускает скрипт предоставляя ему wsgi api, а с другой стороны реализует HTTP.
uwsgi делает тоже самое, но вместо http может реализовывать FastCGI для связи с nginx или apache.
Начнём с того, что мне похуй по какому протоколу общается nginx с кем-либо. И мне похуй на каком языке писать.
1) Я могу написать программу, которая 1 раз запускается, слушает сокет (в нашем случае от nginx), и отвечает на запросы. Может делать это в несколько потоков, и сохранять данные в глобальные массивы (в случае C++, например). Если программа крешнется, то её кто-то должен перезапустить.
2) Я могу написать программу, которая запускается на каждый запрос, в которую по stdin или как-то ещё получает дынные, и высирает ответ в stdout. У неё нет шансов сохранить стейт в памяти (то самое, что каждый петух знает). Это классическая схема для PHP.
И вы мне, блять, не можете ответить к чему относится gunicorn, и к чему uwsgi.
Или где я не прав?
ПХП тоже не работает по второй схеме, если только он не запущен через cgi (что почти никогда не бывает).
ДАнные ты в пхп тоже не сохранишь, но сам процесс интерпретатора никуда не денется из памяти
Почему? Я могу запустить 1 поток, и он будет жить вечно, пока тачка не отключится.
Меня не должно это ебать. Это уже внутрення оптимизация. Для меня это выглядит так, что мой "index.php" или "index.py" кто-то запускает извне.
Это и есть API.
Так вот с питоном же тоже самое.
Он тоже как-бы запускается каждый раз извне. Никто тебе в wsgi не гарантирует, что процесс не пересоздли
Не совсем так. Кто-то извне зовёт функцию в твоём index.py. При этом он может это сделать как на чистом инстансе твоего скрипта, так и на поюзанном. Или даже исполнить несколько запросов на одном инстансе скрипта параллельно, если включены треды.
Вспомнил. Плагин "cgi" называется.
Но это не так.
Как CGI может работать любой язык, хоть шелл скрипт. Просто запускается внешний скрипт, выдает stdout, и умирает.
Это очень медленно, потому в какой-то момент стали интерпретатор загружать в аресное пространство веб-сервера (mod_php, mod_perl итд).
Для скриптов как-бы ничего не изменилось (кроме появления взможрости делать http auth), но физически они висели в памяти.
Можно было даже насрать в глобальный стейт случайно (скорее их сишного расширения, чем из скрипта), но официальных API не было.
Затем, скрипты стали запускать отельным процессом -- php-fpm, например. В нем по-прежнему нету API для сохранения состояния, но наверняка можно как-то изъебнуться, может быть специфичным для php-fpm способом.
Я тебя удивлю, но единственная функция «PHP» для «FastCGI» — это fastcgi_finish_request. Она отправляет страницу клиенту, рвёт с ним соединение, но продолжает выполнять скрипт. Дальше клиент может хоть закрыть вкладку, скрипт будет выполняться молча, не отправляя ничего клиенту.
Гипотетически эта функция предназначена для выполнения тяжёлой задачи типа работы с базой данных. О результатах клиент может узнать, только сделав следующий запрос.
А для HTTP Auth, если не путаю, состояние хранится не в памяти, а в файликах в /tmp (надо проверить).
Процессов может быть запущено несколько. Каким именно процессом будет обработан следующий запрос, зависит от фазы луны. Полагаться на то, что следующий запрос будет обработан тем же самым процессом, нельзя, поэтому память процесса для аутентификации мы использовать не можем. Для аутентификации нужно общее хранилище, которое шарится между всеми процессами.
Такой возможности нету в cgi, ведь там в стандарте нельзя выбирать код
а у mod_php есть, ибо он испольует api апача напряую
"Новый Говнокод" запускается не как CGI, а через свою еботню:
https://github.com/wiistriker/govnokod.ru/issues/52
И как это всё работает? «Конардо» не поймёт такой код. В «AppKernel.php» тоже какая-то бесполезная херня вроде перечисления классов.
Полутора гигов компостеру не хватило, чтобы установить зависимости. Какой багор )))
https://getcomposer.org/doc/articles/troubleshooting.md#memory-limit-errors
Если стереть файл «composer.json» и ставить пакеты по одному командой «composer require», то всё работает.
В распакованном виде все пакеты, включая «Symfony», не наберут и сотню мегабайт. Для чего компостеру несколько гигов оперативки? Чтобы майнить биткоины?
1. Скачать пакеты.
2. Распаковать пакеты.
То же самое можно сделать с гораздо меньшими системными требованиями, запуская «wget» и «unzip» из sh-файла.
операторы шаблонизатора не умеют в computer science
Предел памяти установлен у самого интерпретатора, чтобы не вызвать подкачку из вторичной памяти (это медленно) либо же чтобы не вызвать OOMKiller в случае отсутствия подкачки.
Граф можно было бы обрабатывать по частям, реализовав нечто типа оверлеев, но странно делать это вручную при наличии виртуальной памяти.
С другой стороны, сам граф можно было бы разбить на несколько и тем самым понизить потребление памяти.
А в самом переиспользовании сторонних пакетов я не вижу ничего дурного.
Но «Composer» ставит пакеты локально, в чистую директорию. Требуемые версии указаны в файле «composer.json». Тут даже нечего ломать несовместимой версией.
У других менеджеров пакетов на такую фигню не нарывался.
Это всё растёт, как снежный ком. Я это понимаю так: в ORM «Doctrine» обнаружился фатальный недостаток, поэтому необходимо подпереть его очередным костылём.
ПХП ГАРАНТИРУЕТ очистку стейта
А в wsgi таких гарантий нет
а работать два одновременно в одном процессе ен могут
Ну в вебе один хер всё в io до базы и других сервисов упирается... Так что и так сойдёт.
И поставил раком CPU у vps именно на питоне
Т.е. питоньему скрипту вообще насрать что там в качестве транспорта - http, fastcgi или какой-нибудь mod_python. Ему просто зовут функцию с нужными параметрами и окружением. А свежее это состояние скрипта или нет - зависит от реализации, настроек и погоды на луне.
guest, всё правильно?
wsgi api НЕ дает гарантии, что ты запустишься на том же самом интерпретаторе
Можно использовать более низкоуровневые api, например самому реализовать FastCGI и тогда твой скрипт действительн будет жить вечно, но плодить потоки ты будешь см
тогда я понимаю Питуха
Питух завязался на случайно сохраненную переменную в гуникорне, и решил, что это фича питона
Не надо так
Хочешь кеша -- юзай мемкешд
Использование глобальных переменных в питоне - сайдэффект?
Вы всегда пишите свои программы под какой-то API, верно?
API предоставляет вам функционал, и определяет для него семантику. Иными словами, вам могут даваться (или не даваться) определенные гарантии.
Если вы используете api wsgi (а так поступают обычно Flask и Django), то такое API не дает гарантий, что каждый запрос исполнится в том же самом процессе.
Если авторы сервера приложений (gunicorn, uwsgi) решат по какой-то причине очищать глобальный стейт после каждого запроса, то они будут полностью правы (они НЕ нарушат спецификации), а ваш кеш сломается
Мне и не нужны такие гарантии. Если я запущу 4 процесса, и в среднем каждый проживет хотябы 30 минут или 50 запросов - меня это устраивает.
Какие-то оторванные блоки родом из структурного программирования, которые можно переиспользовать и передавать в недо-ФВП, обычные функции/методы, у которых другой тип, и хрен их куда передашь и хрен ссылку на них получишь и т.п. Зато map отзывается на 100500 алиасов.
Как будто функциональщину туда затащили решением суда, и был вариант либо выучить хаскель за 21 час и сделать так же, либо отправляться на виселицу.
То ли дело JS, где передача функции в ФВП выглядит естественно, и вообще не надо тужиться и думать, чтобы её передать.
____________________
* Всё же это ГК
— 1023, ты из Минска?
— 1023, ты из Питера?
https://ideone.com/CBggWm