/snake/fido

Hello Nil! 21 Jan 23 01:41, you wrote to me: VA>> Ты перепутал с rvalues. lvalues были с самого рождения. NA> Оговорился. Я так и подумал. Просто поправил. ;) VA>> Или указатели. Да и сейчас много где используется, особенно, если VA>> объект надо отдать в несколько потоков и кто его удалит - заранее VA>> неизвестно. NA> Звучит как std::shared_ptr, если не известно кто и в каком потоке NA> прибьёт. Или как в qt, есть некий parent, который держит всё NA> остальное. Он самый. Хоть это и не очень хороший дизайн, но иногда приходится. VA>> Пожалуй не найдется ни одного человека в мире, включая авторов VA>> стандарта, который может сказать, что знает плюсы на 100%. NA> Там каждый автор в своей узкой нише хочет что-то продвинуть, и как раз NA> нужен такой кворум, чтобы сказать, что остальные части ломаются при NA> этом. Но чаще, они они просто говят, потому что нельзя. Согласен на все 100%. Тут главное, чтобы команда была нужного размера. Если слишком маленькая - легко пропустить какую-то мелочь. Если слишком большая - никогда не договоришься. NA> Кстати, FTSC ещё хуже, они говорят, низя и всё. Почему? Потому что NA> дядя Randy Bush копирайт держит на центральный FTS-0001. А нахуй вы NA> тогда нужны? А мы чтобы обновлять FTA-1003 регулярно. Концепт копирайта давно устарел. Только капиталисты его так просто не отдадут. VA>> Можно неплохо разбираться в какой-то одной-двух областях, но VA>> полностью не знать. Он тупо оргомный. NA> Там вопрос даже в другом, там нельзя вот так вот взять и "переписать с NA> нуля", должно быть легаси-совместимо. Поэтому там полно костылей. NA> Поэтому появляются всякие D языки ;-) убийцы C++. Иногда надо выбросить легаси. Да. Это больно. Примеры есть. Тот же python 3. Никто не умер. Обратные примеры тоже есть. Netscape - отличный браузер был. Похоронили... NA> Про всё предусмотреть, ну вот std::string, например, в c++23 добавили NA> contains() наконец таки, в c++20 добавили starts_with()/ends_with(). В NA> питонах это с версии2 ещё, с той не юникодной. Прикол в том, что они иногда умудряются сделать это сохраняя бинарную совместимость. Вот где высший пилотаж. NA> Кстати, вот из-коробки я хочу на C++ почитать файлы, и их полочить NA> надо, либо замапить в память, но такова нету. И даже нельзя достать NA> int fd. Из fopen() я могу достать fileno(), а из C++ fstream никак без NA> хака. А если я захочу почитать как корутина, например, уже в лиункс NA> фейсбуки отдали io_uring, и даже твой любимый boost:asio так умеет. Ну NA> окей, давайте сделаем IO thread pool (как какой-нибудь Libuv), и будет NA> все файловые операции туда кидать, но ведь thread pool так и не NA> завезли, только сраный std:async, который не оправдывает своего NA> названия. Кстати, в федо, которое умерло, сегодня самый гуру линуксов NA> - это Гремлин. Он в рулинуксе в прошлом году даже стал спорить со NA> мной, что на epoll якобы можно повесить файловые операции асинхронно, NA> так же как и сокеты. Опять согласен. Плюсы сосут именно из-за отсутствия элементарных кирпичиков, которые есть в стандартной либе любого уважающего себя языка. Файлы, сеть. Ну хоть потоки в стандарт добавили. И то хлеб. NA> Про юникод, я хочу открыть файл, и указать кодировку, и хочу получать NA> std::string каких-нибудь кодепоинтов, или рунов, или чего-то такова, NA> что я обычно в python, golang,.. получаю. QString так умеет, внутри NA> utf16, но мне пофиг на реализацию. В этом плане qt именно core, без NA> GUI части, он мог бы закрыть многие потребности обычного с++ NA> пейсателя, то, что в libc++ сделали неудобно, или не сделали совсем. Qt проприетарный... UTF либ и других хватает. Опять же. Кто что выбрал. В Java - UTF16 внутри использует. Плюсы же - просто байты. Ему, по большому счету по барабану, что там внутри. VA>> memset/memcpy в плюсах вообще быть не должно. Как и new/delete. NA> Ну я на кодревью new/delete не пропущу, но сам я пишу вон placement NA> new в готовом буфере, некая оптимизация при принятии сетевых пакетов, NA> например. А вот memcpy() тоже пришлось применить, ибо std::equal NA> оказался не готов хавать std::bytes также как и unsigned char, я даже NA> на стековерфлоу тут возмутился NA> https://stackoverflow.com/questions/75121121 В голову приходит одно место, где без new не обойтись. Но оно наружу не торчит. Иногда надо сделать объект, который можно использовать только через std::shared_ptr. Потому что он использует shared_from_this. Тогда я использую фабричный статический метод std::shared_ptr Create(). При этом конструктор делается приватным. И тут либо объявлять fiend, либо делать return std::shared_ptr (new A). Вот в этом месте норм. Так как этот new наружу не торчит. NA> memcpy() будет на buildin заменён компилятный, а он сука знает про ему NA> суют, выравненно оно или нет (а то бы я сам просто NA> reinterpret_cast(адрес) делал бы), и он разные 256битные NA> регистры можно использовать при копировании, если march задан не NA> низкий. reinterpret_cast может быть очень опасен. Кто его знает, как оно внутри объект сделает. Это из разряда - в 99.9% случаев работает, а иногда взрывается. :) Например, на какой-то хитрой архитектуре. VA>> Когда пейсался голдед - плюсы были "C с классами". И большинство VA>> пейсателей писали так, как привыкли на голых сях. А там особо не VA>> развернешься. NA> Труъ. NA> Кстати, про стандарто-пейсателей. Я щитаю, самый большой их косяк был NA> - это std::auto_ptr ;-) понятно что сегодня его уже депрекейтнули, но NA> осадочек остался. auto_ptr удивил не одного плюсовика. И принес массу "приятных" моментов. Похлеще, чем #define TRUE random(0.5) // Удачной отладки, суки. VA>> SFINAE - тоже прикольный пример. Например в boost::bind был VA>> реализован просто через набор шаблонов до 20 параметров. VA>> Еслибольше - хрен. Но это приводило к тому, что когда возникает VA>> ошибка компиляции - вываливает тонны нечитаемого текста. Я когда VA>> только начинал boost использовать - очень страдал от этого. VA>> Каждая такая ошибка приводила к мучительному поиску ошибки, VA>> которая в большинстве случаев была вообще в другом файле. VA>> Например, попытка скопировать некопируемый класс. NA> К сожалению, сегодняшнюю libc++ не переписали на c++20 concepts, и NA> если там напортачить с std::optional, в котором возвращается NA> std::unique_ptr, да ещё как-нибудь через .and_then(), то там 10 NA> экранов шаблонной магии вылезает, а могло быть всего одна строчка, что NA> вот требование такое то не совпало. Хотя, они уже там потрудились NA> static_assert() по максимуму понапихать, чтобы в таком виде свалилось, NA> а не в SFINAE. Поэтому я жду, когда мы таки доберемся до C++20 и концепты заюзаем. Хотя бы наш код будет выдавать вменяемые ошибки при компиляции. VA>> Именно так это работает. Как книжки от "трейдеров" как VA>> зарабатывать деньги на бирже. Если бы это реально работало, то VA>> книги такие никто бы не печатал, тупо рубили бы бабло. NA> Если бы экстрасенсы могли узнавать что-то через специфичный API, NA> который они так декларируют, то они бы просто все были бы миллионерами NA> от выигрыша в лотерею, или на фондовом рынке. :-) Но чудес не бывает. Умные люди стригут лохов. А, как известно, лох - не мамонт, никогда не вымрет. :D VA>> Корутины имеет смысл использовать там, где много IO. Так же, как VA>> и асинхронное программирование. Иначе особого прироста они не VA>> дают. NA> Ну сокеты все. И это всё реализовано. Но часто надо ещё и фалы NA> почитать, а вот это почитать асинхронно уже сложнее. boost::asio отлично с этим справляется. libuv, libevent - море их. Опять же, под задачу. Когда и многопоточная программа получше будет. А когда и однопоточная сгодится. Надо смотреть на требования. NA> Ещё коруинами обзывают то, что называется генераторами на самом деле. NA> Хотя вроде современный std::ranges::views::iota как-то без co_yield NA> внутри вроде. Именно. В том же питончике это просто синтаксический сахар над генераторами. Vitaliy ... 10.0 times 0.10 is hardly ever 1.00.

Hello, Vitaliy! Friday January 20 2023 14:40, from Vitaliy Aksyonov -> Nil A: VA> Ты перепутал с rvalues. lvalues были с самого рождения. Оговорился. VA> Или указатели. Да и сейчас много где используется, особенно, если VA> объект надо отдать в несколько потоков и кто его удалит - заранее VA> неизвестно. Звучит как std::shared_ptr, если не известно кто и в каком потоке прибьёт. Или как в qt, есть некий parent, который держит всё остальное. VA> Пожалуй не найдется ни одного человека в мире, включая авторов VA> стандарта, который может сказать, что знает плюсы на 100%. Там каждый автор в своей узкой нише хочет что-то продвинуть, и как раз нужен такой кворум, чтобы сказать, что остальные части ломаются при этом. Но чаще, они они просто говят, потому что нельзя. Кстати, FTSC ещё хуже, они говорят, низя и всё. Почему? Потому что дядя Randy Bush копирайт держит на центральный FTS-0001. А нахуй вы тогда нужны? А мы чтобы обновлять FTA-1003 регулярно. VA> Можно неплохо разбираться в какой-то одной-двух областях, но VA> полностью не знать. Он тупо оргомный. Там вопрос даже в другом, там нельзя вот так вот взять и "переписать с нуля", должно быть легаси-совместимо. Поэтому там полно костылей. Поэтому появляются всякие D языки ;-) убийцы C++. Про всё предусмотреть, ну вот std::string, например, в c++23 добавили contains() наконец таки, в c++20 добавили starts_with()/ends_with(). В питонах это с версии2 ещё, с той не юникодной. Кстати, вот из-коробки я хочу на C++ почитать файлы, и их полочить надо, либо замапить в память, но такова нету. И даже нельзя достать int fd. Из fopen() я могу достать fileno(), а из C++ fstream никак без хака. А если я захочу почитать как корутина, например, уже в лиункс фейсбуки отдали io_uring, и даже твой любимый boost:asio так умеет. Ну окей, давайте сделаем IO thread pool (как какой-нибудь Libuv), и будет все файловые операции туда кидать, но ведь thread pool так и не завезли, только сраный std:async, который не оправдывает своего названия. Кстати, в федо, которое умерло, сегодня самый гуру линуксов - это Гремлин. Он в рулинуксе в прошлом году даже стал спорить со мной, что на epoll якобы можно повесить файловые операции асинхронно, так же как и сокеты. Про юникод, я хочу открыть файл, и указать кодировку, и хочу получать std::string каких-нибудь кодепоинтов, или рунов, или чего-то такова, что я обычно в python, golang,.. получаю. QString так умеет, внутри utf16, но мне пофиг на реализацию. В этом плане qt именно core, без GUI части, он мог бы закрыть многие потребности обычного с++ пейсателя, то, что в libc++ сделали неудобно, или не сделали совсем. VA> memset/memcpy в плюсах вообще быть не должно. Как и new/delete. Ну я на кодревью new/delete не пропущу, но сам я пишу вон placement new в готовом буфере, некая оптимизация при принятии сетевых пакетов, например. А вот memcpy() тоже пришлось применить, ибо std::equal оказался не готов хавать std::bytes также как и unsigned char, я даже на стековерфлоу тут возмутился https://stackoverflow.com/questions/75121121 memcpy() будет на buildin заменён компилятный, а он сука знает про ему суют, выравненно оно или нет (а то бы я сам просто reinterpret_cast(адрес) делал бы), и он разные 256битные регистры можно использовать при копировании, если march задан не низкий. VA> Когда пейсался голдед - плюсы были "C с классами". И большинство VA> пейсателей писали так, как привыкли на голых сях. А там особо не VA> развернешься. Труъ. Кстати, про стандарто-пейсателей. Я щитаю, самый большой их косяк был - это std::auto_ptr ;-) понятно что сегодня его уже депрекейтнули, но осадочек остался. VA> SFINAE - тоже прикольный пример. Например в boost::bind был реализован VA> просто через набор шаблонов до 20 параметров. Еслибольше - хрен. Но VA> это приводило к тому, что когда возникает ошибка компиляции - VA> вываливает тонны нечитаемого текста. Я когда только начинал boost VA> использовать - очень страдал от этого. Каждая такая ошибка приводила к VA> мучительному поиску ошибки, которая в большинстве случаев была вообще VA> в другом файле. Например, попытка скопировать некопируемый класс. К сожалению, сегодняшнюю libc++ не переписали на c++20 concepts, и если там напортачить с std::optional, в котором возвращается std::unique_ptr, да ещё как-нибудь через .and_then(), то там 10 экранов шаблонной магии вылезает, а могло быть всего одна строчка, что вот требование такое то не совпало. Хотя, они уже там потрудились static_assert() по максимуму понапихать, чтобы в таком виде свалилось, а не в SFINAE. VA> Именно так это работает. Как книжки от "трейдеров" как зарабатывать VA> деньги на бирже. Если бы это реально работало, то книги такие никто бы VA> не печатал, тупо рубили бы бабло. Если бы экстрасенсы могли узнавать что-то через специфичный API, который они так декларируют, то они бы просто все были бы миллионерами от выигрыша в лотерею, или на фондовом рынке. :-) VA> Корутины имеет смысл использовать там, где много IO. Так же, как и VA> асинхронное программирование. Иначе особого прироста они не дают. Ну сокеты все. И это всё реализовано. Но часто надо ещё и фалы почитать, а вот это почитать асинхронно уже сложнее. Ещё коруинами обзывают то, что называется генераторами на самом деле. Хотя вроде современный std::ranges::views::iota как-то без co_yield внутри вроде. Best Regards, Nil

Hello Nil! 20 Jan 23 22:36, you wrote to me: NA> Префаза. в локальной тестовой эхе hobbit.test последние несколько NA> дней, довольно в активном ритме, случается много интересных CPP NA> обсуждений, поэтому кросс-пострю в профильную эху su.c_cpp. Конечно. Не вопрос. NA>>> Звучит как реклама C++. VA>> Но это ведь правда. Плюсы довольно низкоуровневы, чтобы писать VA>> эффективный код, но при этом не насолько, как голый си, чтобы VA>> писать удобно, безопасно и понятно человеку. NA> До появления в C++11 lvalues, там были сплошные копирования тяжёлых NA> структур данных. Были даже отдельные реализации, похожие на STL, где NA> есть move всего содержимого контейнера. Ты перепутал с rvalues. lvalues были с самого рождения. NA> И до появления явного правила RVO в C++11 (aka copy elision), был NA> вообще караул с возвратом значений, приходилось через параметры гонять NA> указатель или ссылку. Или указатели. Да и сейчас много где используется, особенно, если объект надо отдать в несколько потоков и кто его удалит - заранее неизвестно. NA> Кстати, на этом примере, покажу как стандарты C++ сосут. RVO правило NA> сразу не заработало, надо было ещё потом NRVO прописать, и потом в NA> C++17 ещё пришлось "guaranteed copy elision through simplified value NA> categories" прописывать. Всего сразу предусмотреть невозможно. Особенно в таком монстре, как плюсы. Пожалуй не найдется ни одного человека в мире, включая авторов стандарта, который может сказать, что знает плюсы на 100%. Можно неплохо разбираться в какой-то одной-двух областях, но полностью не знать. Он тупо оргомный. NA> А если у тебя там какой-то side-effects из-за вызовов copy/move NA> конструктотров? Ну так-то, чтобы не было side-effect, надо сразу на NA> Haskell писать, пока тебе не потребовалось из файла почитать, где NA> сайд-эффекты прут как из рога изобилия, и тут на сцену выходят монады. NA> Кстати, в жопу хаскель, монадный синтаксис уже плотно перекачевал в NA> C++. И, вот ещё пример, как C++ стандарт сосёт. В C++17 добавили NA> std::optional, который устанешь каждый раз проверять, и в других NA> языках ты пишешь .and_then, или .or_else, или transform. Они добавили NA> в C++23 монадный синтаксис, вместе с std::expected наконец (но мы то NA> все уже давно сидим на https://github.com/TartanLlama/expected). С std::optional связана другая история. Мы сейчас на gcc7.3. И в нем есть косяк в инициализации std::optional. Приходится вставлять костыли, чтобы warning не выкидывало. NA> Кстати, вот пример, как в 90х писали на C++, в до C++11, на примере NA> голдеда. Так то голдед, можно сказать, что ООП, по настоящему, где NA> есть интерфейсный класс, с виртуальными функциями почитать разные NA> форматы баз сообщений. Например, в Husky это сделано на голом Си, NA> через макрос, который через указатель попадает на структуру с адресами NA> функций, такой ручной переход по v-table. Так вот, в голдеде везде NA> оптимизации в виде memset()/memcpy() на sizeof класса, как будто он NA> весь такой POD, хоть там и виртуальные функции есть. Кстати, там в NA> голдеде новодел есть, в лице std::string и std::vector, ну честно же, NA> так удонее, чем руками тут же писать разные linked list. Но вот классы NA> с std::string и std::vector прям удалять и копировать через NA> memset()/memcpy() как-то совсем плохо, однажды запустив под valgrind NA> увидишь там потерянные std::vector. memset/memcpy в плюсах вообще быть не должно. Как и new/delete. Я посмотрел немного код деда - это жесткое легаси. Там работать и работать. Даже компиляция с -Wall выдает прилично предупреждений. NA> Я пример с голдедом привёл зачем. Чтобы показать, что на C++ нельзя NA> было пейсать эффективный код. И только сейчас, с помощью всех этих NA> шаблонов, constexpr выражений, можно получить эффективный бинарный код NA> на выходе, опять же, при условии, что программист знает что получится, NA> когда он именно вот так вот напишет, проверив на каком-нибудь NA> https://godbolt.org . Кстати, SFINAE должно умереть, и всё это должно NA> быть уже if constexpr с разными concepts требованиями к типам. Когда пейсался голдед - плюсы были "C с классами". И большинство пейсателей писали так, как привыкли на голых сях. А там особо не развернешься. SFINAE - тоже прикольный пример. Например в boost::bind был реализован просто через набор шаблонов до 20 параметров. Еслибольше - хрен. Но это приводило к тому, что когда возникает ошибка компиляции - вываливает тонны нечитаемого текста. Я когда только начинал boost использовать - очень страдал от этого. Каждая такая ошибка приводила к мучительному поиску ошибки, которая в большинстве случаев была вообще в другом файле. Например, попытка скопировать некопируемый класс. VA>> Смотрел видосик на ютубчике, как один товарищ про const VA>> рассказывал. Так там как раз был пример, когда он то ли VA>> добавлял, то ли наоборот убирал const и несколько ассемблерных VA>> инструкций превращалось в тонны кода. NA> "Один-товарищ", его зовут Jason Turner, его канал NA> https://www.youtube.com/@cppweekly Он самый. NA> Проблема с ним лично в том, что он далёк от продакшен кода. Он NA> раскрутился на консалтинге, кодревь, и прочих разводках, что щас NA> кого-то наймём и он "фсё починит". Гы. Ну это ж классика. Но при этом подобные эксерсизы посмотреть бывает полезно для реальных применений. Ну или как не стоит делать. NA> Вообще, с ними со всеми проблема общая в том, что если ты не умеешь NA> программировать, то ты идёшь в менеджеры. Если не умеешь руководить, NA> то ты идёшь учить других как программировать. Если не умеешь учить, то NA> ты пишешь книжки. Именно так это работает. Как книжки от "трейдеров" как зарабатывать деньги на бирже. Если бы это реально работало, то книги такие никто бы не печатал, тупо рубили бы бабло. VA>> У нас еще веселее. Мы в своем компоненте совмещаем асинхронный VA>> подход (самописные очереди на boost asio) и многопоточность. А в VA>> другом компоненте к этим двум еще добавили stackful корутины из VA>> буста. Иногда бывают очень занятные баги. NA> С++20 корутины должны сильно помочь, но проблема, что так и не дали NA> библиотеку в std:: неймспейсе, чтобы корутины использовать NA> "из-коробки", приходится cppcoro, им подобными, или самописными NA> пользоваться. Корутины имеет смысл использовать там, где много IO. Так же, как и асинхронное программирование. Иначе особого прироста они не дают. VA>> С корутинами был интересный прикол. Мы портировали этот код с VA>> винды на линукс и он начал странно крешиться иногда. Выяснилось, VA>> что при выделении памяти для стека она выделялась без VA>> выравнивания и вместо stack overflow код вылазил в чужую память и VA>> крешился. Было непросто найти причину. NA> Не надо stackful и stackless корутины в одном коде миксить. Конечно. Иначе начинается каша, которую хрен разберешь. Мы не мешали одно с другим. Асинхронный код у нас не на корутинах. NA> Кстати, придёт к тебе на работу джун, которых в школе учили NA> критические секции мьютексами защищать, а тут у тебя корутины, и как NA> ты его код отревьювишь? Очень просто. Он будет читать книжки, прежде чем писать код. :) NA>>> Кстати, в C++ комитете полно русский людей, что радует. VA>> Наслышан. Вроде STL наши написали первоначально. NA> Ты не знаешь кто такой Степанов Сан Саныч? Вики тебе в помощь. Точно. Вылетело имя из головы. Он самый. VA>> Большой плюс котлина, что он использует ту же JRE. А она почти VA>> везде есть или может работать. NA> На таком же принципе появляются новые языки программирования, как NA> грибы, и все такие C++ убицы. Вот тебе тройка из 2022 года. * Val NA> https://www.val-lang.dev * Carbon NA> https://github.com/carbon-language/carbon-lang сам Гугл учавствует, NA> считай уже 3ий язык после Go и Dart. * cppfront NA> https://github.com/hsutter/cppfront Все они поразитируют на том, что NA> совместимы с C++, только более модно/молодёжные. Это разумный подход. Ведь написать нормальный компилятор, который еще и оптимизирует толково - это работа на десяток лет или даже больше. А эти все "языги" - просто препроцессоры в плюсовый код или максимум AST. Потом какой-то LLVM в работу. VA>> Таймзоны - это боль. У нас 4 раза в год вылазят баги с ними. :) VA>> Спросишь, почему 4? Потому что перевод часов на зимнее и летнее VA>> время в США и в других странах происходит в разные дни. NA> Ты мне рассказываешь, как два раза в год у нас есть неделя, когда NA> митинги с США и Европейцами расходятся на час? У меня та же картина. У нас есть офисы в Европе. Так что мы друг друга понимаем. NA>>> Буст - это тестовая площадка для будущего C++ стандарта. VA>> Именно. Из него очень многое перехало почти без изменений. Те же VA>> умные указатели или ranges. NA> std::filesystem::path тоже из Буста. Но, забавно, Google C++ Style NA> Guide явно запрещает его использовать из-за "security vulnerability". NA> Чувак как-то умудрились Time-of-check to time-of-use проблему NA> притащить в самом спеке, как тот самый mktemp() страдает. Из буста очень много чего перетащили в стандарт. Такая себе песочница. А почему бы и нет. Работает. Vitaliy ... 10.0 times 0.10 is hardly ever 1.00.

From:	Vitaliy Aksyonov 2:5023/24.4107	21 Jan 2023 04:46 +0200
To:	Nil A 2:5015/46
Subject:	Получаем ноду в зиване - квест

From:	Vitaliy Aksyonov 2:5023/24.4107	21 Jan 2023 04:28 +0200
To:	Nil A 2:5015/46
Subject:	Test

From:	Nil A 2:5015/46	21 Jan 2023 01:41 +0200
To:	Vitaliy Aksyonov 2:5023/24.4107
Subject:	Test

From:	Nil A 2:5015/46	21 Jan 2023 02:52 +0200
To:	Vitaliy Aksyonov 2:5023/24.4107
Subject:	Получаем ноду в зиване - квест

From:	Vitaliy Aksyonov 2:5023/24.4107	21 Jan 2023 00:00 +0200
To:	Nil A 2:5015/46
Subject:	pvt.luna.local

From:	Vitaliy Aksyonov 2:5023/24.4107	20 Jan 2023 23:40 +0200
To:	Nil A 2:5015/46
Subject:	Test

From:	Vitaliy Aksyonov 2:5023/24.4107	20 Jan 2023 23:56 +0200
To:	Nil A 2:5015/46
Subject:	Получаем ноду в зиване - квест

From:	Vladimir Fyodorov 2:6035/3.2	21 Jan 2023 00:03 +0200
To:	Cheslav Osanadze 2:6078/80
Subject:	Test

From:	Vladimir Fyodorov 2:6035/3.2	20 Jan 2023 23:13 +0200
To:	Nil A 2:5015/46
Subject:	pvt.luna.local

From:	Nil A 2:5015/46	20 Jan 2023 22:56 +0200
To:	Vitaliy Aksyonov 2:5023/24.4107
Subject:	pvt.luna.local