[>]
Re: Дополнения к стандарту
idec.talks
revoltech(spnet, 4) — shaos
2024-10-31 05:48:09
shaos> ну разве что если /x/e/...
Да пофигу, раз упростить алгоритмически всё равно ничего не получится, пусть будет так, как есть. Меня больше про /u/mc вопрос интересует.
[>]
Re: Разбор idec
idec.talks
shaos(spnet, 2) — Andrew Lobanov
2024-10-31 05:53:59
> Что может быть проще? Грамматики? Конечные автоматы?
Мне проще на сях - перебираем строку посимвольно и делаём чо хотим...
[>]
Re: Разбор idec
idec.talks
ahamai(blackcat, 2) — shaos
2024-10-31 05:43:47
Кстати, если в срезе будет точка, то старый софт будет считать это не как неккорректный msgid, а как пустую эху и и игнорировать её
[>]
Re: Дополнения к стандарту
idec.talks
revoltech(spnet, 4) — shaos
2024-10-31 06:05:06
shaos> насколько длинный урл можно скормить вебсерверу это настройка вебсервера - сама нода может про это и не знать
Но её админ должен об этом знать. И выставить в урлу /u/mc. Иначе при перефетче придётся брутфорсить на стороне клиента: ага, 10000 айдишников — отлуп, 1000 айдишников — отлуп, 500 — отлуп, 389 — норм... Запишем, что в этой станции 389.
[>]
Re: Дополнения к стандарту
idec.talks
shaos(spnet, 2) — revoltech
2024-10-31 06:12:07
> Но её админ должен об этом знать.
Ну я например не знал пока не загуглил :)
Потом пришлось свой анализатор логов переписывать, чтобы строки длинне 8К принимал ;)
[>]
Re: Разбор idec
idec.talks
ahamai(blackcat, 2) — Andrew Lobanov
2024-10-31 07:03:49
> ahamai просто не помнит свой же стандарт. Надеюсь, у него всё хорошо.
В бандле только эхи и msgid. Эхи с точками, всё осталное msgid. Если там что то ещё, падай а не игнорируй
[>]
Re: Дополнения к стандарту
idec.talks
hugeping(ping,1) — revoltech
2024-10-31 07:40:58
Я тут несколько дней сдерживаюсь. К тому же, довольно сильно приболел.
Но сдерживаться мне всё тяжелее конечно...
Понимаю, что меня не воспримут, всё-таки напишу.
Подумайте, что за задачи вы решаете?
Например, в данном случае, в один запрос запиханы разные лимиты слайсов для разных эх. Зачем?
Видимо, предполагается что "умный" админ будет настраивать фетч таким образом под станцию, что задаст разные лимиты для эх разной наполненности? Зачем этот ужас? Придумайте, как в реальности вы будете это использовать?
Потом, Рома трясёт своим ?sf=hash - как замену слайсов. На самом деле этот sf=hash при своей красоте, всё-таки, хуже слайсов. Во первых, даже с хешем надо делать запрос внахлёст с запасом (не забываем про то, что порядок сообщений на ноде может не совпадать с нашим) и нам все равно придётся самим на своей станции находить n сообщение от конца в эхе и брать затем его хеш чтобы сформировать запрос. Те же слайсы, вид сбоку. Ну и во-вторых, sf решает одну конкретную задачу, а слайсы - универсальны. Слайсы делают возможным адаптивный фетч и онлайн просмотр.
Потом постоянные намёки на то, что нам нужно обязательно забрать всё одним запросом. Причём, неявно подразумевается что это благая цель которую все разделяют... ЗАЧЕМ?? У меня фетчер вообще забирает по 12 кажется msgid за раз, но он, наверное, самый быстрый из всех реализаций что я видел. Можете скачать ii-go и сделать полное клонирование моей станции и написать, сколько это заняло времени.
Про ограничение на запрос. В лучшем случае в стандарт можно добавить рекомендацию про 8кб "стандарт" запроса, который в большинстве случаев совпадает с фактическим положением дел. Но расширение, которое будет показывать этот параметр, который вообще говоря доступен только веб серверу? Сами же простоту и элегантность хотите, нет? По 16 msgid забирать чистоплюство не позволяет? Значит, страдайте! :)
В общем, попытки решить какие-то несуществующие проблемы и навязать какие-то свои оценки. Чего я боялся, то и происходит. Лебедь рак и щука.
Моё мнение -- надо замораживать вариант драфта Андрея. А дальше, пилить альтернативный стандарт - если он будет хорош - ну значит его поддержит. Кто-то. Но в таком хаосе и горячке я точно не участник. Мне не нравится русло в которое все свернуло. Но это - неизбежно. Поэтому коммьюнити не будет. Никогда.
[>]
Re: Разбор idec
idec.talks
Andrew Lobanov(tavern,1) — revoltech
2024-10-31 07:52:20
AL>> И это ломает поддержку стандарта.
revoltech> Ладно. Ломает, так ломает, будем контекстозависимые парсеры городить. А что насчёт /u/mc?
Ненужная вещь.
[>]
Re: Разбор idec
idec.talks
Andrew Lobanov(tavern,1) — shaos
2024-10-31 07:52:20
>> Это знает только автор. И то вряд ли вспомнит.
Да там всё в коде - читай нехочу, но только без поллитры в этих регекспах не разрбраться (мне):
if (preg_match("/^====$/", $string[$i])) {
if (!$pre_flag) {
$pre_flag = true;
$string[$i] = preg_replace("/====/", "<pre>====", $string[$i]);
} else {
$pre_flag = false;
$string[$i] = preg_replace("/====/", "====</pre>", $string[$i]);
}
}
А что тут разбираться? Может, кто-то пихает пробелы после ====? Ну так надо просто им напихать в панамку за это.
[>]
Re: Разбор idec
idec.talks
Andrew Lobanov(tavern,1) — shaos
2024-10-31 07:52:20
>> Что может быть проще? Грамматики? Конечные автоматы?
shaos> Мне проще на сях - перебираем строку посимвольно и делаём чо хотим...
Как только начинаем писать что-то сложнее поиска подстроки, код на Си превращается в чан доширака. Регулярки надо осилить один раз и потом кратко и лаконично описывать желаемое.
[>]
Re: Дополнения к стандарту
idec.talks
Andrew Lobanov(tavern,1) — revoltech
2024-10-31 07:52:21
revoltech> Предлагаю ввести общий слайсинг вида «ключ-значение», в котором вместо диапазона можно писать all или же msgid (в таком случае берётся содержимое эхо от него):
revoltech> /u/e/echo.1/all/echo.2/some_msgid_blablabla/echo.3/-10:10
Зачем? Усложнение ради усложнения? Так IDEC не про это, а про дубовую простоту.
[>]
Re: Разбор idec
idec.talks
Andrew Lobanov(tavern,1) — shaos
2024-10-31 07:52:21
shaos> ну IDEC клиентов и серверов наклепали за 10 лет некоторое количество, поэтому и /u/e/echo.1/echo.2/echo.3 и /u/e/echo.1/echo.2/echo.3/-10:10 должны продолжать работать, а я предлагаю раширение, которое исправит последнюю претензию, что слайс распространяется на каждую эху из списка - будет возможность задавать разные слайсы на разные наборы эх в пределах одного запроса - чем плохо то? ;)
Тем, что не решает никаких проблем :)
[>]
Re: Дополнения к стандарту
idec.talks
Andrew Lobanov(tavern,1) — revoltech
2024-10-31 07:52:21
shaos>> ну разве что если /x/e/...
revoltech> Да пофигу, раз упростить алгоритмически всё равно ничего не получится, пусть будет так, как есть. Меня больше про /u/mc вопрос интересует.
Не вижу в нём смысла.
[>]
Re: Разбор idec
idec.talks
Andrew Lobanov(tavern,1) — ahamai
2024-10-31 07:52:21
ahamai> Кстати, если в срезе будет точка, то старый софт будет считать это не как неккорректный msgid, а как пустую эху и и игнорировать её
Ты хочешь в срезе получить нецелое количество сообщений? Зачем тебе точка в срезе? Типа, -12.5:12.5?
[>]
Re: Дополнения к стандарту
idec.talks
Andrew Lobanov(tavern,1) — revoltech
2024-10-31 07:52:21
shaos>> насколько длинный урл можно скормить вебсерверу это настройка вебсервера - сама нода может про это и не знать
revoltech> Но её админ должен об этом знать. И выставить в урлу /u/mc. Иначе при перефетче придётся брутфорсить на стороне клиента: ага, 10000 айдишников — отлуп, 1000 айдишников — отлуп, 500 — отлуп, 389 — норм... Запишем, что в этой станции 389.
А зачем?
[>]
Re: Разбор idec
idec.talks
shaos(spnet, 2) — shaos
2024-10-31 08:36:19
Вот почему в предыдущем сообщении оно только на последний ==== среагировало? Пустую строку надо до?
again?
[>]
Re: Дополнения к стандарту
idec.talks
revoltech(spnet, 4) — Andrew Lobanov
2024-10-31 09:02:02
AL> Зачем? Усложнение ради усложнения? Так IDEC не про это, а про дубовую простоту.
Это как раз и было бы про дубовую простоту парсинга. Ключ-значение. Всё однозначно.
[>]
Re: Дополнения к стандарту
idec.talks
revoltech(spnet, 4) — hugeping
2024-10-31 09:09:58
hugeping> Например, в данном случае, в один запрос запиханы разные лимиты слайсов для разных эх. Зачем?
Чтобы не качать лишнее.
hugeping> Видимо, предполагается что "умный" админ будет настраивать фетч таким образом под станцию, что задаст разные лимиты для эх разной наполненности? Зачем этот ужас? Придумайте, как в реальности вы будете это использовать?
В реальности — точно так же, как и твой адаптивный фетч сейчас это делает, только без необходимости предварительно мурыжить каждую эху отдельно.
hugeping> По 16 msgid забирать чистоплюство не позволяет?
Накладные расходы не позволяют. Когда станция тормозит, это особо заметно.
Сейчас у меня в stations.txt напротив каждой ноды стоит число. Если непонятно, сколько сообщений нода позволяет забрать за раз, ставлю 12, ибо это случай с tgi и его ограничением 256 символов на гет. Андрей не озвучивал ограничение spline-online, поэтому там тоже стоит 12, и делать полный перефетч — это боль с такой-то скоростью отдачи. А бывает, что надо. Например, когда я внутренний формат базы поменял, добавив поле.
hugeping> Моё мнение -- надо замораживать вариант драфта Андрея.
Я-то не против, просто предлагаю вещи, которые облегчат жизнь, пока не поздно.
[>]
Тест скорости фетча (+потеряшки)
idec.talks
tuple(ping,54) — hugeping
2024-10-31 09:37:10
hugeping> Можете скачать ii-go и сделать полное клонирование моей станции и написать, сколько это заняло времени.
Активного участия в дискуссиях не принимал, но решил попробовать:
$ time ./ii-tool fetch https://club.hugeping.ru
INFO: 2024/10/31 12:20:50 Start fetcher(s) for https://club.hugeping.ru
INFO: 2024/10/31 12:20:50 Get https://club.hugeping.ru/u/e/pipe.2032
INFO: 2024/10/31 12:20:50 Get https://club.hugeping.ru/u/e/std.rein
...
real 0m30,322s
user 0m9,286s
sys 0m4,117s
При фетче были ошибки на некоторые сообщения, у которых обнаружили "wrong repto format":
-
ii://z8W283Fkra8J96OrKQCC
-
ii://TKcKYfkzLXg3YU3iMQrS
-
ii://nXdcHnk0Y4UunGNNUIwi
-
ii://VJPNtsUz2RhjJUXPAqZs
-
ii://GInGJYvgNySpTJGHmk8U
-
ii://8vRmig2SXkHzCmgqFHOI
-
ii://XLMzTeZG3uvc9kJIjUpU
-
ii://2xsAUpSzT1kmFLiAP7TN
-
ii://OANneaKiLh1Ft7Gx0NEP
Как я понял: эти сообщения существуют, но сообщения, которые записаны в их repto, не существуют. Поэтому их веб-морда показать не может, а они есть. Потеряшки?
[>]
Re: Тест скорости фетча (+потеряшки)
idec.talks
hugeping(ping,1) — tuple
2024-10-31 09:50:52
tuple> Как я понял: эти сообщения существуют, но сообщения, которые записаны в их repto, не существуют. Поэтому их веб-морда показать не может, а они есть. Потеряшки?
Возможно, это не очень хорошо. Судя по коду, DecodBundle отбрасывает сообщение если в нём неверный repto. То-есть дело не в веб морде даже. Потом подумаю, что лучше с этим сделать. Пока так.
[>]
Re: Тест скорости фетча (+потеряшки)
idec.talks
hugeping(ping,1) — hugeping
2024-10-31 09:54:59
hugeping> Возможно, это не очень хорошо. Судя по коду, DecodBundle отбрасывает сообщение если в нём неверный repto. То-есть дело не в веб морде даже. Потом подумаю, что лучше с этим сделать. Пока так.
Да нет, вру. Там проверяется на корректность ID всего лишь. Странно. Проверю.
[>]
Re: Тест скорости фетча (+потеряшки)
idec.talks
hugeping(ping,1) — hugeping
2024-10-31 09:58:29
hugeping> Да нет, вру. Там проверяется на корректность ID всего лишь. Странно. Проверю.
У этих сообщений repto не соответствует формату. Не 20 символов. Таки сообщения я стал дропать на приёме, после того случая недавнего. Но старые сообщения остались, видимо, битые.
[>]
Re: Разбор idec
idec.talks
Andrew Lobanov(tavern,1) — ahamai
2024-10-31 10:43:05
>> ahamai просто не помнит свой же стандарт. Надеюсь, у него всё хорошо.
ahamai> В бандле только эхи и msgid.
Ещё пустая строка.
ahamai> Эхи с точками, всё осталное msgid. Если там что то ещё, падай а не игнорируй
Откуда оно там возьмётся?
[>]
Re: Дополнения к стандарту
idec.talks
Andrew Lobanov(tavern,1) — revoltech
2024-10-31 10:43:17
AL>> Зачем? Усложнение ради усложнения? Так IDEC не про это, а про дубовую простоту.
revoltech> Это как раз и было бы про дубовую простоту парсинга. Ключ-значение. Всё однозначно.
Тут слайс, тут волшебное слово, тут хэш. Сиди, разбирай.
[>]
Re: Дополнения к стандарту
idec.talks
Andrew Lobanov(tavern,1) — hugeping
2024-10-31 10:43:24
hugeping> Я тут несколько дней сдерживаюсь. К тому же, довольно сильно приболел.
hugeping> Но сдерживаться мне всё тяжелее конечно...
hugeping> Понимаю, что меня не воспримут, всё-таки напишу.
hugeping> Подумайте, что за задачи вы решаете?
[skipped]
Подписываюсь под каждым словом.
[>]
Re: Разбор idec
idec.talks
Andrew Lobanov(tavern,1) — shaos
2024-10-31 10:43:24
shaos> Нету пробелов после ====
shaos> Он просто иногда работает, но чаще не работает
shaos> ====
shaos> here?
shaos> ====
А может, это от тех деятелей, которые \n\r шлют вместо \n? Попробуй поэкспериментировать с этим.
[>]
Re: Разбор idec
idec.talks
Andrew Lobanov(tavern,1) — shaos
2024-10-31 10:43:24
shaos> Вот почему в предыдущем сообщении оно только на последний ==== среагировало? Пустую строку надо до?
Вангую, что это потому, что не было пустой строки в конце сообщения. Попробуй добавить и оно сломается совсем :)
shaos> ====
shaos> again?
shaos> ====
[>]
Re: Разбор idec
idec.talks
Andrew Lobanov(tavern,1) — hugeping
2024-10-31 10:43:25
shaos>> Неа - опять не сработало…
hugeping> Возможно, потому что в сообщении нет последнего перевода строки ( см: http://shaos.net:8085/ii-point.php?q=/m/DpizUAp7CfgxVznSUul4 )
По идее, это без разницы. $ -- это в любом случае конец строки.
[>]
Re: Дополнения к стандарту
idec.talks
Andrew Lobanov(tavern,1) — revoltech
2024-10-31 10:43:25
hugeping>> Например, в данном случае, в один запрос запиханы разные лимиты слайсов для разных эх. Зачем?
revoltech> Чтобы не качать лишнее.
Чтобы что?
hugeping>> Видимо, предполагается что "умный" админ будет настраивать фетч таким образом под станцию, что задаст разные лимиты для эх разной наполненности? Зачем этот ужас? Придумайте, как в реальности вы будете это использовать?
revoltech> В реальности — точно так же, как и твой адаптивный фетч сейчас это делает, только без необходимости предварительно мурыжить каждую эху отдельно.
Лучше мурыжить все эхи пока все слайсы не уляжутся. И этот человек говорит мне о том, чтобы не качать лишнего. Будь последователен.
hugeping>> По 16 msgid забирать чистоплюство не позволяет?
revoltech> Накладные расходы не позволяют. Когда станция тормозит, это особо заметно.
revoltech> Сейчас у меня в stations.txt напротив каждой ноды стоит число. Если непонятно, сколько сообщений нода позволяет забрать за раз, ставлю 12, ибо это случай с tgi и его ограничением 256 символов на гет. Андрей не озвучивал ограничение spline-online, поэтому там тоже стоит 12, и делать полный перефетч — это боль с такой-то скоростью отдачи. А бывает, что надо. Например, когда я внутренний формат базы поменял, добавив поле.
hugeping>> Моё мнение -- надо замораживать вариант драфта Андрея.
revoltech> Я-то не против, просто предлагаю вещи, которые облегчат жизнь, пока не поздно.
Они ни облегчат, ни усложнят жизнь. Просто придётся делать бесполезную работу.
[>]
Re: Дополнения к стандарту
idec.talks
revoltech(spnet, 4) — Andrew Lobanov
2024-10-31 10:53:10
AL> Зачем ему это понимать?
Да блин. Моделируем ситуацию. Клиент пришёл в сеть. Без готовой базы сообщений, без ничего. Выкачивает список эх по /list.txt. Выкачивает по /u/e/[список_эх] айдишники сообщений. Их овердофига. Дальше как ему знать, по сколько айдишников группировать для посыла одного GET /u/m, если ни станция, ни стандарт об этом ничего не говорят? Он может сгруппировать по 16 и получить ошибку на tgi, каковы дальнейшие действия?