vit01> Круто. Теперь будет ещё повод написать скрипт для уведомлений, чтобы сабж сам почту проверял. Всё на днях думаю сделать, да откладываю.

Пулл-реквест видел, но пока не пробовал. Как попробую, так смержу.

vit01> А по самому андроиду спрашивай совета, если что; способы выживания на этой необычной платформе весьма неочевидны.

По большей части он мои скромные потребности перекрывает. Осталось только SBCL под Termux собрать и будет полная сатисфакция. Но буду иметь в виду, так как после месяца пользования всё равно чувствую себя пришельцем из каменного века :)

btimofeev> Ты в пулл реквесте написал про cron и busybox. Ты настраивал в cron'e, который вместе с термуксом идет или в отдельном приложении busybox (которое требует root)? Можно поподробнее?

Который вместе с Термуксом.

apt install busybox
crontab -e

Однако тут есть проблема, потому что приложение crontab тут не работает, как подобает.
Поэтому делаем вот так:

cd ~/../usr/var/spool/cron/crontabs
ls
# здесь будет имя файла, совпадающее с именем пользователя
# его и используем
echo "*/15 * * * *	cd ~/caesium && termux_mailcheck.sh" > u0_a106

# где u0_a106 - имя пользователя (whoami)

# запускаем cron в режиме foreground с отображением логов
crond -f -d 0

После запуска cron спускаем "шторку" и в открывшемся висящем уведомлении Termux выбираем пункт Wake Lock, чтобы запретить уходить телефону в спящий режим.

И вот только после этого будет работать автопроверка в Цезии.

>Теперь https://ii-net.tk и https://alicorn.tk
Это очень хорошо!

AL> Приложи эту инструкцию к пулл-реквесту. Чтоб было в отдельном ридми.

Уже давно приложил. До сих пор не проверял реквест?

AL> Мне как-то совершенно нечего написать.

Но ведь написал же немного.

Весьма необычно, кстати, что роскомпозор заинтересовался настоящими сектантами. Это, наверное, лобби РПЦ травит конкурентов :)

AL> Не то чтобы тяжело, но ехать 5 часов и 3 часа работать не по мне. Тем более, что впятером в легковой машинке тесновато и ноги затекают сильно.

Знакомо. Самому вон приходится 4 дня из 7 в неделю проводить на даче. С одной стороны, вроде бы и ничего, но жара и зной выматывают.

AL> Пожалуй, это всё интересное, что со мной произошло в последний месяц. Но не за горами отпуск.

Держись там. А в отпуске не забывай заходить со смартфона и делиться впечатлениями.

Сам вот решил попутно подзаработать летом и как-то применить свои навыки в вёрстке и прочих околовебовых вещах. Пока что получается. Заиграли новыми красками шутки про заказчиков, которые постоянно меняют свои хотелки и ТЗ :) Но зато потом накуплю мелких комплектующих к своим девайсам и плюшевую поняху.

Досуг пока проходит спокойно, размеренно и незамысловато. Иногда скука пробирает. Такие дела.

Интересно, чем сейчас живут остальные.

В настройки сабжа добавил пункт "Разворачивать клиент на весь экран при запуске". По умолчанию отключен.

Он может пригодиться обладателям floating WM на небольших мониторах и/или виндоюзерам. А то не все же на тайловых сидят :)

AL> Есть желание на sqlite перевести базу сообщений а то.

Тогда надо бы это вместе обговорить, чтобы позднее было бы проще поддерживать совместимость баз друг с другом.

Хотя вот прямо сейчас нам не о клиентах и базах хлопотать надо на самом деле. А о том, что молчание.

Перенёс в Git страницы https://ii-net.tk/iidownload и https://ii-net.tk/station.html

Информация там не поменялась (кроме мелочей и добавления idec-utils), старые ссылки делают перенаправление.

Зачем?

1. Markdown править приятнее, чем html
2. Всё в одном месте - удобнее для поиска
3. Актуальность информации меньше зависит от ii-net.tk

vit01> Уже давно приложил. До сих пор не проверял реквест?

Извини, но да. Сейчас без задних ног валяюсь с ноутом на пузе и так лень думать и пробовать. На днях обязательно попробую и смержу.

Что-то на работе ныне жесть полнейшая. Прямо не продохнуть. А ещё инстедоз этот замыслил за каким-то лешим.

vit01> Перенёс в Git страницы https://ii-net.tk/iidownload и https://ii-net.tk/station.html

Хорошее дело. А я всё время выкроить на цезий не могу. Есть желание на sqlite перевести базу сообщений а то.

vit01> Хотя вот прямо сейчас нам не о клиентах и базах хлопотать надо на самом деле. А о том, что молчание.

Мне как-то совершенно нечего написать.

Так сложилось, что на меня в том числе свалилась работа по контролю блокировок ресурсов в интернете (а то роскомзапрет сам не справляется со своими же блокировками). Работа тупая и нудная. Страдают пока больше всех имейджборды, онлайн казино и всяческий досуг для взрослых. Хотя недавно целая плеяда сайтов иеговистов попала под раздачу, но неясно почему.

А ещё на этой неделе ездил по командировкам в составе комиссии. Проверяли состояние необслуживаемых РКП (радиоконтрольных пунктов). Не то чтобы тяжело, но ехать 5 часов и 3 часа работать не по мне. Тем более, что впятером в легковой машинке тесновато и ноги затекают сильно.

Пожалуй, это всё интересное, что со мной произошло в последний месяц. Но не за горами отпуск. Если всё сложится, как планировалось, то отпишусь про Миасс и Тургояк. И фоток положу.

Опять сабж. Никто ничего не пишет.

vit01> Ты имеешь в виду msg ok: <msgid> или error: blablabla?

Их самых.

vit01> У нас эти самые ответы вообще в стандарт не включены. Могу, конечно, взять те, которые сейчас в PHP-ноде, но для остальных нод они могут отличаться.

Ну по доброму бы их надо стандартизировать, так как клиенты должны парсить ответ ноды. Я за образец брал ii-0.3.

vit01> Я попробую, конечно, как-нибудь это оформить, но отсутствие несостыковок не обещаю.

Итак, можно смотреть в репозиторий new-docs в файл errors.md. На сайте пока не синхронизировал, потому что пока рано. Специально заглянул в сорцы ii-0.3 и своей ноды, чтобы всё это записать. Надо бы в скором времени стандартизировать записи об ошибках.

// А ещё у моего верного нетбука сдох разъём питания. Самому его не починить, так что придётся заказывать эту мелкую деталь отдельно и несколько дней подождать из-за отсутствия свободного времени.
// Но с этим ничего страшного, потому что я подключил по USB OTG хардварную клавиатуру к своему телефону и доступен как ни в чём не бывало. Сабжевый коммит сделал с помощью Termux (а для USB-HID у него даже специальные сочетания клавиш предусмотрены; очень удобно).

Хотя не факт, что это необходимо. Подумать надо.

AL> Ну по доброму бы их надо стандартизировать, так как клиенты должны парсить ответ ноды. Я за образец брал ii-0.3.

В 0.3 идёт проверка исключительно для "msg ok" (причём msgid не парсится), наши клиенты тоже работают именно так. Ещё там проверяется на "error:", но текст после error тоже никогда не парсится (а только выводится на экран).

Проблема есть ещё и в том, что у наших схем вроде /x/file свои сообщения об ошибках, и из 0.3 их не позаимствуешь.

Я попробую, конечно, как-нибудь это оформить, но отсутствие несостыковок не обещаю.

В документации не хватает информации о стандартных ответах ноды. Этот момент было бы неплохо уточнить, хотя и не критично.

AL> В документации не хватает информации о стандартных ответах ноды.

Ты имеешь в виду msg ok: <msgid> или error: blablabla?
У нас эти самые ответы вообще в стандарт не включены. Могу, конечно, взять те, которые сейчас в PHP-ноде, но для остальных нод они могут отличаться.

vit01> // почему у тебя в ii.stat включена music.14? Она же в архиве давно.

Этот момент как-то мимо меня прошёл просто =)

На самом деле жалко эху, но в текущих реалиях хватит и трубы. Сегодня сниму её отовсюду.

AL> // Антиэхотаг, я так и не решил как лучше организовать процесс фетчинга. Просто забирать последние N сообщений индекса мне не нравится.

Именно для этого существует схема /x/c, которая пока не поддерживается в таверне, но зато сильно ускоряет процесс фетча. Вперёд за нанотехнологиями =)

vit01>> Теперь можно с уверенностью сказать, что этот фетчер умеет всё подряд. Ну, по крайней мере, все фишки с фетчем, которые мы когда-либо придумывали.

AL> Умеет ли он клонировать эхи и есть ли возможность задавать все параметры (ноду, эхи, клонируемые эхи) через CLI? А то я подумываю не велосипедить, а прикрутить к цезию твой фетчер.

Через GUI клонирование только костылём. По факту фетчер - это всего лишь одна функция:

def fetch_messages(adress, firstEchoesToFetch, xcenable=False, one_request_limit=20, fetch_limit=False, from_msgid=False, proxy=None, pervasive_ue=False, callback=None, cut_remote_index=0):

Вызывая её только с первыми двумя параметрами, ты получаешь тот самый clone.
Думаю, CLI-морду для всех возможностей ты вполне можешь реализовать сам. Если что, спрашивай.

И тут я посмотрел на неё и понял, что, оказывается, немного ввожу народ в заблуждение.

Параметр from_msgid не работает, потому это всего лишь заглушка (а в стандарте подходящего расширения просто нет, несмотря на то что сервер ii-php его поддерживает).

Также эта штука не поддерживает /x/features, который в стандарте у нас как бы есть. На комфорт и скорость это не влияет, но на точность моего высказывания - да. Так что прошу прощения.

На http://ii-net.tk/ дублируется ii://Z1rb9LRFqSlIzt94tt5k Не критично, но всё же.

vit01> Добавил в фетчер (и в GUI-конфигуратор) сабжа возможность принудительной обрезки удалённого индекса. Такую же функцию реализует Цезий, работая со старыми станциями на 0.3, которые не поддерживают расширенный /u/e

vit01> Теперь можно с уверенностью сказать, что этот фетчер умеет всё подряд. Ну, по крайней мере, все фишки с фетчем, которые мы когда-либо придумывали.

Умеет ли он клонировать эхи и есть ли возможность задавать все параметры (ноду, эхи, клонируемые эхи) через CLI? А то я подумываю не велосипедить, а прикрутить к цезию твой фетчер.

Сабж задумался. Определение смещения для расширенной схемы u/e мы можем хранить как константу (или передавать как константу в качестве параметра), а можем вычислять из результата работы схемы x/c. И всё это просто замечательно пока мы работаем с одной единственной нодой. Но если ноды две и более, то порядок сообщений в индексе у них скорее всего разный и мы можем потерять сообщения при фетчинге одной и той же эхи с разных узлов.

На стороне клиента ещё возможны костыли вида каждому аплинку по базе (хотя мне эта затея и не нравится), но на ноде мы уже так делать не можем.

В процессе раздумий на эту тему меня посещали разные идеи, но все они отметались в силу своей несостоятельности или замороченности. Пока лучше достаточно большой минимальной длины запрашиваемого индекса я не придумал. Но это всё равно достаточно мороченный вариант. Может действительно имеет смысл просто забирать индекс фиксированной длины и не заморачиваться на лютую оптимизацию трафика (что такое +- несколько десятков килобайт в наши дни?).

Что думаете на этот счёт?

2vit01: Да я могу взять твой навороченный фетчер, но мне он показался достаточно сложным (не в духе нашей сетки, так сказать). Хочется максимальной простоты а-ля изначальный ii, но с шахматами и гимназистками.

Добавил в фетчер (и в GUI-конфигуратор) сабжа возможность принудительной обрезки удалённого индекса. Такую же функцию реализует Цезий, работая со старыми станциями на 0.3, которые не поддерживают расширенный /u/e

Теперь можно с уверенностью сказать, что этот фетчер умеет всё подряд. Ну, по крайней мере, все фишки с фетчем, которые мы когда-либо придумывали.

В сабже починил ответ на сообщения из окна "стены текста"

В настройках станций добавил пункт "Настроить всё автоматически". Когда пользователь нажмёт эту кнопку, клиент заботливо проверит поддержку всех схем через /x/features и сам расставит все галочки для расширений в зависимости от их поддержки.
А если /x/features сообщает о наличии list.txt, то ещё и загрузит список эх с ноды (аж минус один клик!).
Если нет поддержки расширенного /u/e, то поставит принудительную обрезку индекса на 50 сообщений (как в Цезии).
Также кнопка автонастройки проверяет одну типичную опечатку для новичков (забывают слэш в конце адреса ноды) и исправляет её.

Надо бы потом обновить сборки для винды и дебиана, но пока лень.

vit01> Через GUI клонирование только костылём.

Ну как костылём. Просто создать в настройках такую же станцию, но отключив при этом галочками новомодные расширения.

vit01>> 3. Расширенный /u/e используется и там, и там. Различие лишь в том, что оптимальное значение на клиенте - это 50-100, а на сервере - немного больше. Mira station фетчит каждого аплинка со смещением 200. Уже как очень долгое время.

AL> Эту практику я считаю приемлемой, если нас не интересует гарантированное получение всех новых сообщений.

Без обид, но у тебя плохая память :)
В моём фетчере эта проблема уже решена. Передаёшь параметр pervasive_ue=True, и ни одного сообщения потеряно не будет.

Алгоритм:
Запрашиваем последние -N. Если все из них новые, то запрашиваем -2N:N и так далее, подсовывая в начало.

А насчёт максимального приращения новых сообщений идея нравится. Но большой погоды она вряд ли сделает. В любом случае, рад буду посмотреть на рабочее решение.

AL> 2vit01: Да я могу взять твой навороченный фетчер, но мне он показался достаточно сложным (не в духе нашей сетки, так сказать). Хочется максимальной простоты а-ля изначальный ii, но с шахматами и гимназистками.

Тогда пиши сам, какой считаешь идеальным и юниксвейным :)
Главное, чтобы он свои задачи выполнял и не тормозил на большом количестве эх.

vit01>> Запрашиваем последние -N. Если все из них новые, то запрашиваем -2N:N и так далее, подсовывая в начало.

AL> У меня на данный момент так же точно происходит (по крайней мере при построении индекса). Фигня случается, когда одна и та же эха забирается с разных узлов. В таком случае этот подход приводит к потере сообщений из-за разного порядка сообщений на разных нодах.

Вижу только единственный вариант, при котором такое может произойти.

Есть нода1 и нода2. У клиента стоит /u/e, предположим, на 50 сообщений.
В течение 10 минут на ноде1 появляются сразу 50 сообщений. В то же самое время на ноде2 появляются 10 сообщений. После этого нода2 гейтует ноду1, забирая те 50 сообщений.

Итого на ноде1 - 50 новых, а на ноде2 - 60 новых.

В этот самый момент подключается клиент и начинает фетчить сначала первую, затем вторую.
Так как у него лимит стоит 50, то с первой ноды он забирает 100 записей индекса и успокаивается. На второй ноде он обнаруживает 50 сообщений, которые у него уже есть в базе, и не трогает её дальше.

Да, действительно, потери. Но тебе не кажется, что такой интенсивный трафик в одной единственной эхе за такое короткое время - это _слишком_ маловероятно?

Но это ещё не всё. Предположим, вышеописанная ситуация каким-то сказочным образом осуществилась.

Дальше нода1 гейтует ноду2, забирая у неё недостающие 10 сообщений (мы же не забыли, что сервера оптимизации не используют, да?). Клиент фетчит ноду1, и недостающие 10 сообщений также к нему приходят. Всё разрешилось само собой.

vit01> Для начала не надо мешать мух с котлетами, то есть сервера с клиентами.

Фетчинг есть фетчинг. Мечта идиота у меня - создать фетчер, который бы экономил трафик и гарантировал получение всех новых сообщений.

vit01> 1. Вычисление смещения из результата /x/c - это порочная практика. Её никто никогда не предлагал и не реализовывал.

Вот я и начинаю предлагать =)

vit01> 2. На сервере /x/c не нужен. Более того, ни один серверный фетчер его не поддерживает. Эта схема необходима только для того, чтобы клиенту не фетчить creepy.14, mlp.15 и прочие питоны, в которые пишут не больше раза в неделю. Самая частая работа /x/c - это выдать на экран надпись "новых сообщений нет".

Поверх этого вычисляем максимальное приращение в эхах у аплинка и принимаем этот результат за смещение. Теряем в трафике (например, если подписаны на ленту и забираем почту раз в день, то гарантированно получаем около 100 сообщений в индексах), но получаем всё новьё. Если запоминать количество сообщений для каждой ноды отдельно, то может получиться вполне сносно. Пока в эту сторону размшляю.

vit01> 3. Расширенный /u/e используется и там, и там. Различие лишь в том, что оптимальное значение на клиенте - это 50-100, а на сервере - немного больше. Mira station фетчит каждого аплинка со смещением 200. Уже как очень долгое время.

Эту практику я считаю приемлемой, если нас не интересует гарантированное получение всех новых сообщений.

vit01> Так и надо. Для гейтоскриптов вообще можно и не использовать кучу оптимизаций.

Гейты да. Можно хоть от 0.3 фетчер оторвать и оно будет оправдано =)

vit01> Чтобы все были счастливы, надо

vit01> 1. Делать ровно один запрос /u/e вместо того, чтобы опрашивать каждую эху

В процессе. Пока не пишу в апстрим свои эксперименты потому как лучше плохая работа, чем поломатый клиент.

vit01> 2. Добавить в Цезий поддержку /x/c, чтобы не фетчить все 40 эх из подписок, когда новые сообщения только в пайпе или в новостях (или когда их вообще нет).

Это будет, но хочу шире использовать.

vit01> Этих двух пунктов достаточно и для скорости, и для комфорта.

И для потенциальной потери сообщений. Вот именно это мне покоя не даёт.

vit01> Дальше нода1 гейтует ноду2, забирая у неё недостающие 10 сообщений (мы же не забыли, что сервера оптимизации не используют, да?). Клиент фетчит ноду1, и недостающие 10 сообщений также к нему приходят. Всё разрешилось само собой.

Я хочу оптимизацию на серверах применять %) Отсюда и наступление на грабли.

vit01> Без обид, но у тебя плохая память :)

Я знаю. Очень плохая =)

vit01> В моём фетчере эта проблема уже решена. Передаёшь параметр pervasive_ue=True, и ни одного сообщения потеряно не будет.

vit01> Алгоритм:
vit01> Запрашиваем последние -N. Если все из них новые, то запрашиваем -2N:N и так далее, подсовывая в начало.

У меня на данный момент так же точно происходит (по крайней мере при построении индекса). Фигня случается, когда одна и та же эха забирается с разных узлов. В таком случае этот подход приводит к потере сообщений из-за разного порядка сообщений на разных нодах.

vit01> А насчёт максимального приращения новых сообщений идея нравится. Но большой погоды она вряд ли сделает. В любом случае, рад буду посмотреть на рабочее решение.

Самое главное, что она решит вышеозвученную проблему. Но пока я её не реализовал.

vit01> Тогда пиши сам, какой считаешь идеальным и юниксвейным :)

Мой девиз "Велосипедостроительство и отвага" =)

AL> Определение смещения для расширенной схемы u/e мы можем хранить как константу (или передавать как константу в качестве параметра), а можем вычислять из результата работы схемы x/c.

AL> На стороне клиента ещё возможны костыли вида каждому аплинку по базе (хотя мне эта затея и не нравится), но на ноде мы уже так делать не можем.

Для начала не надо мешать мух с котлетами, то есть сервера с клиентами.

1. Вычисление смещения из результата /x/c - это порочная практика. Её никто никогда не предлагал и не реализовывал.

2. На сервере /x/c не нужен. Более того, ни один серверный фетчер его не поддерживает. Эта схема необходима только для того, чтобы клиенту не фетчить creepy.14, mlp.15 и прочие питоны, в которые пишут не больше раза в неделю. Самая частая работа /x/c - это выдать на экран надпись "новых сообщений нет".

3. Расширенный /u/e используется и там, и там. Различие лишь в том, что оптимальное значение на клиенте - это 50-100, а на сервере - немного больше. Mira station фетчит каждого аплинка со смещением 200. Уже как очень долгое время.

AL> Пока лучше достаточно большой минимальной длины запрашиваемого индекса я не придумал. Но это всё равно достаточно мороченный вариант. Может действительно имеет смысл просто забирать индекс фиксированной длины и не заморачиваться на лютую оптимизацию трафика (что такое +- несколько десятков килобайт в наши дни?).

Так и надо. Для гейтоскриптов вообще можно и не использовать кучу оптимизаций.

Чтобы все были счастливы, надо

1. Делать ровно один запрос /u/e вместо того, чтобы опрашивать каждую эху
2. Добавить в Цезий поддержку /x/c, чтобы не фетчить все 40 эх из подписок, когда новые сообщения только в пайпе или в новостях (или когда их вообще нет).

Этих двух пунктов достаточно и для скорости, и для комфорта.

vit01> И она работать пока отказывается.
vit01> https://ii-net.tk/ii/files/I7D9Pr9GzoFkojC1mSix.png

Что очень странно, так как я ей сейчас как раз и пользуюсь. Ошибка странная. С какой нодой возникает? Кинь caesium.cfg без auth.

vit01> Тогда ничего против не имею. Надо как-то лучше друг друга понимать учиться :)

Ну с формулировками у меня всю дорогу проблему. Именно поэтому по юности в фидо я молчал =)

vit01> Реализую-ка у себя тоже этот хак с /x/c, чтобы от прогресса не отставать.

Я уже написал. Осталось только запоминание x/c для разных нод реализовать, но уже сейчас фетчер просто молниеносный.

Сейчас допишу поддержку нескольких нод и подсуну этот фетчер в цезий дабы погоняю немного. Если всё нормально будет, то внедрю в апстрим.

Ещё хочу добавить возможность формировать строку вызова фетчера в конфиге. Тогда останется только чтобы фетчер умел принимать через аргументы адрес ноды, список эх для фетча и список эх для клонирования (последнее опционально).

AL> Сейчас допишу поддержку нескольких нод и подсуну этот фетчер в цезий дабы погоняю немного. Если всё нормально будет, то внедрю в апстрим.

Как и писал, получается весьма годно. Конечно, из-за того, что индекс получается одним запросом, мы получаем лишние записи в нём (в эхе 1 2 новых сообщения, а в эхе 2 - 1 и получаем индекс на обе эхи по 2 сообщения).

Ещё надо чтобы необновлённые эхи в запрос не попадали, но это вечером или завтра.

vit01> Реализую-ка у себя тоже этот хак с /x/c, чтобы от прогресса не отставать.

На пробу можно взять мою версию (непричёсана и как всегда с дублирующим кодом пока) тут http://spline-online.tk/stuff/fetcher.py можно просто подложить её цезию и она будет работать.

В первый коннект с нодой забирает индекс со смещением 200 (можно изменить значение в конфиге или через параметр). Если подписаться на новую эху, то тоже берёт смещение 200. В остальных случаях юзает этот финт с x/c.

Надо причёсывать скорее и внедрять. Можно даже 0.3 цезия под шумок выпустить. Хотя теперь я думаю на тему а действительно ли надо от цезия отделять фетчер, если остальное всё равно монолитно.

AL> На пробу можно взять мою версию (непричёсана и как всегда с дублирующим кодом пока) тут http://spline-online.tk/stuff/fetcher.py можно просто подложить её цезию и она будет работать.

И она работать пока отказывается.
https://ii-net.tk/ii/files/I7D9Pr9GzoFkojC1mSix.png

AL> Ошибка странная. С какой нодой возникает?

Видимо, с самой первой, mira station. От изменения подписок ошибка не уходит. Скинул конфиг на email

vit01> Реализую-ка у себя тоже этот хак с /x/c, чтобы от прогресса не отставать.

Это оказалось значительно проще, чем себе представлял. Коммитить пока не буду. Лучше недельку потестирую сначала.

vit01>> Дальше нода1 гейтует ноду2, забирая у неё недостающие 10 сообщений (мы же не забыли, что сервера оптимизации не используют, да?). Клиент фетчит ноду1, и недостающие 10 сообщений также к нему приходят. Всё разрешилось само собой.

AL> Я хочу оптимизацию на серверах применять %) Отсюда и наступление на грабли.

Тогда ничего против не имею. Надо как-то лучше друг друга понимать учиться :)

Реализую-ка у себя тоже этот хак с /x/c, чтобы от прогресса не отставать.

>> И не просто шевелится, а вполне себе ходит :)
gadfly> И много тут народу?

4 человека ровно. vit01 (т.е. я), spline (теперь он уже Andrew Lobanov), Difrex, иногда бывает поинт btimofeev.
По факту у нас сейчас серверов больше, чем людей.

Но зато мы достаточно развились технически и сдружились за это время, поэтому уходить отсюда и сворачивать проект никто не собирается. Слишком удачной на практике оказалась эта, казалось бы, мелочь, чтобы её бросить.

gadfly> Раз мой клиент завелся без изменений, значит протокол не сильно меняли. Но расширения протокола видел, да. Был-таки форк? Была драма?

Суть форка была только в смене названия и в добавлении расширений для экономии трафика. В остальном совместимость с ii гарантируется.

И да, мы полностью отказались от перекатывания эх. В некоторых уже по несколько тысяч сообщений, поэтому советую поставить современный клиент, а не сидеть на старом.

Драма была и не одна :) Читать эхи ii://pipe.2032 и ii://ii.14

ОНО ШЕВЕЛИТСЯ

vit01> И зря. Всегда включаю дебаг, это одна из самых нужных настроек.

Новый фетчер гораздо проще по своему устройству и его можно отлаживать и так. Могу вернуть, но сперва в цезии поправлю функцию вызова фетчера и впихну команды вызова в конфиг (две, так как для клонирования придётся отделять).

vit01> Ну а так новая версия работает, большое спасибо. Теперь ждать меньше буду с мобильным интернетом.

Меня тоже радует ага.

gadfly> ОНО ШЕВЕЛИТСЯ

И не просто шевелится, а вполне себе ходит :)

С возвращением, привет.

// Заглядывал на сайты с доками?

vit01> Видимо, с самой первой, mira station. От изменения подписок ошибка не уходит. Скинул конфиг на email

Ошибку исправил. Забыл проверку на пустые строки сделать. И ещё дебаг опцию надо отключить. Лежит так же. Коммитить не буду пока. потестирую немного сперва.

>И не просто шевелится, а вполне себе ходит :)

И много тут народу?

>// Заглядывал на сайты с доками?

Полистал. Раз мой клиент завелся без изменений, значит протокол не сильно меняли. Но расширения протокола видел, да. Был-таки форк? Была драма?