# Re: Разбор idec
revoltech (spnet, 4) → shaos – 05:42:33 2024-10-31
shaos> чем плохо то? ;)
Это не ко мне вопрос.
revoltech (spnet, 4) → shaos – 05:42:33 2024-10-31
shaos> чем плохо то? ;)
Это не ко мне вопрос.
# Re: Разбор idec
shaos (spnet, 2) → revoltech – 05:40:50 2024-10-31
ну IDEC клиентов и серверов наклепали за 10 лет некоторое количество, поэтому и /u/e/echo.1/echo.2/echo.3 и /u/e/echo.1/echo.2/echo.3/-10:10 должны продолжать работать, а я предлагаю раширение, которое исправит последнюю претензию, что слайс распространяется на каждую эху из списка - будет возможность задавать разные слайсы на разные наборы эх в пределах одного запроса - чем плохо то? ;)
shaos (spnet, 2) → revoltech – 05:40:50 2024-10-31
ну IDEC клиентов и серверов наклепали за 10 лет некоторое количество, поэтому и /u/e/echo.1/echo.2/echo.3 и /u/e/echo.1/echo.2/echo.3/-10:10 должны продолжать работать, а я предлагаю раширение, которое исправит последнюю претензию, что слайс распространяется на каждую эху из списка - будет возможность задавать разные слайсы на разные наборы эх в пределах одного запроса - чем плохо то? ;)
# Re: Разбор idec
Andrew Lobanov (tavern,1) → shaos – 05:21:40 2024-10-31
shaos> Блин как эти ==== в этом ii-php работают?
Это знает только автор. И то вряд ли вспомнит.
shaos> Ненавижу регулярные выражения...
Что может быть проще? Грамматики? Конечные автоматы?
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
Andrew Lobanov (tavern,1) → shaos – 05:21:40 2024-10-31
shaos> Блин как эти ==== в этом ii-php работают?
Это знает только автор. И то вряд ли вспомнит.
shaos> Ненавижу регулярные выражения...
Что может быть проще? Грамматики? Конечные автоматы?
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
# Re: Разбор idec
Andrew Lobanov (tavern,1) → shaos – 05:21:40 2024-10-31
>> кто будет переписывать цезий или фетчеры под замену стандартов?
shaos> никто - сервер может поддерживать и ванильный ii без индексов, и старый IDEC где индексы в конце, и новый многоиндексный вариант - ничто ничему не противоречит!
Ну просто всё несовместимое снимается с фетча. Зачем нам поломанные узлы?
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
Andrew Lobanov (tavern,1) → shaos – 05:21:40 2024-10-31
>> кто будет переписывать цезий или фетчеры под замену стандартов?
shaos> никто - сервер может поддерживать и ванильный ii без индексов, и старый IDEC где индексы в конце, и новый многоиндексный вариант - ничто ничему не противоречит!
Ну просто всё несовместимое снимается с фетча. Зачем нам поломанные узлы?
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
# Re: Разбор idec
Andrew Lobanov (tavern,1) → ahamai – 05:21:40 2024-10-31
ahamai> кто будет переписывать цезий или фетчеры под замену стандартов? стандарты уже такие, какие получились. у меня вопрос - чому так?
Из стандарта выкидывается то, что по факту никому не нужно. Стандарты полностью совместимы с ii. Так что не понимаю твоего бухчения. Ты можешь взять хоть свой горячо любимый ii-0.3 и работать в сети полноценно.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
Andrew Lobanov (tavern,1) → ahamai – 05:21:40 2024-10-31
ahamai> кто будет переписывать цезий или фетчеры под замену стандартов? стандарты уже такие, какие получились. у меня вопрос - чому так?
Из стандарта выкидывается то, что по факту никому не нужно. Стандарты полностью совместимы с ii. Так что не понимаю твоего бухчения. Ты можешь взять хоть свой горячо любимый ii-0.3 и работать в сети полноценно.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
# Re: Разбор idec
Andrew Lobanov (tavern,1) → shaos – 05:21:40 2024-10-31
shaos> Не надо драматизировать :)
shaos> Индексы тоже пару строк кода добавляют (ну может чуть больше)
shaos> Для разнообразия можно множественные "слайсы" тоже сделать, типа
shaos> /u/e/echo.1/echo.2/-1:1/echo.3/-100:100/echo.4
shaos> будет означать, что echo.1 и echo.2 должны вернуть одно последнее сообщение, echo.3 должно вернуть 100 последних, а echo.4 должно вернуть всё - в этом случае всё будет логично и гибко ;)
И это ломает поддержку стандарта.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
Andrew Lobanov (tavern,1) → shaos – 05:21:40 2024-10-31
shaos> Не надо драматизировать :)
shaos> Индексы тоже пару строк кода добавляют (ну может чуть больше)
shaos> Для разнообразия можно множественные "слайсы" тоже сделать, типа
shaos> /u/e/echo.1/echo.2/-1:1/echo.3/-100:100/echo.4
shaos> будет означать, что echo.1 и echo.2 должны вернуть одно последнее сообщение, echo.3 должно вернуть 100 последних, а echo.4 должно вернуть всё - в этом случае всё будет логично и гибко ;)
И это ломает поддержку стандарта.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
# Re: тестовый архив
Andrew Lobanov (tavern,1) → ahamai – 05:21:40 2024-10-31
ahamai> смотрю я на это и думаю, а давайте ru.humor.14 на бон вернём?
У нас нет бона.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
Andrew Lobanov (tavern,1) → ahamai – 05:21:40 2024-10-31
ahamai> смотрю я на это и думаю, а давайте ru.humor.14 на бон вернём?
У нас нет бона.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
# Re: Разбор idec
Andrew Lobanov (tavern,1) → ahamai – 05:21:39 2024-10-31
Я честно пытался с тобой обсуждать, но ты, похоже, наркоман. Ты видишь то, чего нет.
За сим считаю, что обсуждение стандарта с тобой можно завершать. Какие счётчики? Какое скачивание лишних сообщений? Если ты не читал то, что я сюда приносил как черновик, то открой хотя бы исходники своего ii-0.3. Почитай на досуге. Сразу увидишь где ты неправ в своих претензиях. Ну а если не увидишь, то обсуждать с тобой дизайн, стандарт и реализацию тем более нет смысла.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
Andrew Lobanov (tavern,1) → ahamai – 05:21:39 2024-10-31
Я честно пытался с тобой обсуждать, но ты, похоже, наркоман. Ты видишь то, чего нет.
За сим считаю, что обсуждение стандарта с тобой можно завершать. Какие счётчики? Какое скачивание лишних сообщений? Если ты не читал то, что я сюда приносил как черновик, то открой хотя бы исходники своего ii-0.3. Почитай на досуге. Сразу увидишь где ты неправ в своих претензиях. Ну а если не увидишь, то обсуждать с тобой дизайн, стандарт и реализацию тем более нет смысла.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
# Re: игры в эхах
Andrew Lobanov (tavern,1) → tuple – 05:21:39 2024-10-31
tuple> Ещё есть вариант найти мастера, сыграть в D&D.
В общем случае неудобно. Карту надо и токены.
tuple> P.S. Чур я бард-человек.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
Andrew Lobanov (tavern,1) → tuple – 05:21:39 2024-10-31
tuple> Ещё есть вариант найти мастера, сыграть в D&D.
В общем случае неудобно. Карту надо и токены.
tuple> P.S. Чур я бард-человек.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
# Re: Срез
Andrew Lobanov (tavern,1) → ahamai – 05:21:39 2024-10-31
ahamai> - если сообщений в базе мало
ahamai> + если новых сообщений в эхах разное количество, непонятно почему просто не запрашивать с каждой нужное (ну, или, с гарантией +1, +5 сообщений, это небольшой оверхед, по сравнению со случаем когда опращиваются одним запросом эхи с 1 и 110 сообщениями)
ahamai> 111
ahamai> Вообще, связка h и sf реально сокращает количество запросов и реально экономит трафик. Если это кому-то важно.
Оверхед меньше килобайта в подавляющем большинстве случаев. Это даже на 9600 бод можно не считать оверхедом. При этом ты предлагаешь более сложный и неработающий в части случаев вариант.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
Andrew Lobanov (tavern,1) → ahamai – 05:21:39 2024-10-31
ahamai> - если сообщений в базе мало
ahamai> + если новых сообщений в эхах разное количество, непонятно почему просто не запрашивать с каждой нужное (ну, или, с гарантией +1, +5 сообщений, это небольшой оверхед, по сравнению со случаем когда опращиваются одним запросом эхи с 1 и 110 сообщениями)
ahamai> 111
ahamai> Вообще, связка h и sf реально сокращает количество запросов и реально экономит трафик. Если это кому-то важно.
Оверхед меньше килобайта в подавляющем большинстве случаев. Это даже на 9600 бод можно не считать оверхедом. При этом ты предлагаешь более сложный и неработающий в части случаев вариант.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
# Re: игры в эхах
Andrew Lobanov (tavern,1) → ahamai – 05:21:39 2024-10-31
>> Можно передавать уровни сокобана в plaintext-формате (.sok).
ahamai> это всё не так весело, тут играешь в одиночку. а я именно про игры всей компанией и совместную вовлечённость
Многие НРИ годятся для такого занятия. Всей гурьбой, увлекательно, разнообразно.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
Andrew Lobanov (tavern,1) → ahamai – 05:21:39 2024-10-31
>> Можно передавать уровни сокобана в plaintext-формате (.sok).
ahamai> это всё не так весело, тут играешь в одиночку. а я именно про игры всей компанией и совместную вовлечённость
Многие НРИ годятся для такого занятия. Всей гурьбой, увлекательно, разнообразно.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
# Re: Срез
Andrew Lobanov (tavern,1) → ahamai – 05:21:39 2024-10-31
ahamai> Понятия не имею, что это слово означает, но вопросы имеются - раньше я вообще никогда не задумывался, как работают слайсы.
ahamai> Во-первых, формат. /u/e/ чётко определён, там перечисляются эхи.
Читай документацию внимательнее. Там не только эхи перечисляются.
ahamai> Почему не использовать что-то типа ?s=-100:100 или любой другой способ?
Мы и используем один из любых других способов.
ahamai> Если в фетчер ii 0.3 просунуть такой формат url и запросить что-то с ii 0.3, фетчер упадёт, не растоссив пакет, потому что будет считать -100:100 хэшем сообщения.
Почему у тебя фетчер считает имя эхи хэшем сообщения? Это явно что-то не так в ii 0.3. Зачем с аплинком на ii использовать то, что ii не умеет?
ahamai> Зачем плодить неоднозначность просто на ровном месте, там, где есть куча способов её избежать?
>> Читать далее
Andrew Lobanov (tavern,1) → ahamai – 05:21:39 2024-10-31
ahamai> Понятия не имею, что это слово означает, но вопросы имеются - раньше я вообще никогда не задумывался, как работают слайсы.
ahamai> Во-первых, формат. /u/e/ чётко определён, там перечисляются эхи.
Читай документацию внимательнее. Там не только эхи перечисляются.
ahamai> Почему не использовать что-то типа ?s=-100:100 или любой другой способ?
Мы и используем один из любых других способов.
ahamai> Если в фетчер ii 0.3 просунуть такой формат url и запросить что-то с ii 0.3, фетчер упадёт, не растоссив пакет, потому что будет считать -100:100 хэшем сообщения.
Почему у тебя фетчер считает имя эхи хэшем сообщения? Это явно что-то не так в ii 0.3. Зачем с аплинком на ii использовать то, что ii не умеет?
ahamai> Зачем плодить неоднозначность просто на ровном месте, там, где есть куча способов её избежать?
>> Читать далее
# Re: Срез
Andrew Lobanov (tavern,1) → ahamai – 05:21:38 2024-10-31
ahamai> Хэш в блеклисте это вообще ничего не меняет, нужны же "сообщения от", если в файле эхи сообщение есть, то от него и пойдёт. Если хэша нет, то отдастся вся эха. По сравнению с текущим случаем, преимуществ два - хэш гораздо более надёжный источник, чем количество сообщений, и не сработает только в одном случае: если конкретная нода инъектировала в эху сообщения сверху - но на это нужно иметь настолько серьёзные основания, что это повод говорить об этом в сисопской эхе.
Какие-то количества сообщений придумал. Нет их уже, считай. Легаси, который в скором времени выставим на мороз.
> Ну и второе - точно отдадутся только самые новые сообщения, одним запросом (я думал, реализация срезов вообще не так работает, в текущем виде она вообще какая-то непонятная, почему на все эхи один лимит, если сообщений в базе мало)
Как количество сообщений влияет на работу срезов? Out of range невозможен.
ahamai> не использовалось это никогда потому что я не вижу смысла экономить и так копеечный трафик. но на такой случай реализация в моей станции была
Если не видишь смысла экономить трафик, то тогда непонятно что тебе не нравится в том, что срез один на запрос, а не для каждой эхи отдельно. Я думал, ты байтики экономишь и не хочешь получать в индексе сообщения, которые у тебя уже есть в базе.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
Andrew Lobanov (tavern,1) → ahamai – 05:21:38 2024-10-31
ahamai> Хэш в блеклисте это вообще ничего не меняет, нужны же "сообщения от", если в файле эхи сообщение есть, то от него и пойдёт. Если хэша нет, то отдастся вся эха. По сравнению с текущим случаем, преимуществ два - хэш гораздо более надёжный источник, чем количество сообщений, и не сработает только в одном случае: если конкретная нода инъектировала в эху сообщения сверху - но на это нужно иметь настолько серьёзные основания, что это повод говорить об этом в сисопской эхе.
Какие-то количества сообщений придумал. Нет их уже, считай. Легаси, который в скором времени выставим на мороз.
> Ну и второе - точно отдадутся только самые новые сообщения, одним запросом (я думал, реализация срезов вообще не так работает, в текущем виде она вообще какая-то непонятная, почему на все эхи один лимит, если сообщений в базе мало)
Как количество сообщений влияет на работу срезов? Out of range невозможен.
ahamai> не использовалось это никогда потому что я не вижу смысла экономить и так копеечный трафик. но на такой случай реализация в моей станции была
Если не видишь смысла экономить трафик, то тогда непонятно что тебе не нравится в том, что срез один на запрос, а не для каждой эхи отдельно. Я думал, ты байтики экономишь и не хочешь получать в индексе сообщения, которые у тебя уже есть в базе.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
# Re: Разбор idec
ahamai (blackcat, 2) → revoltech – 05:03:00 2024-10-31
Я про это тоже собирался вечером написать. Это было в bosfor
ahamai (blackcat, 2) → revoltech – 05:03:00 2024-10-31
Я про это тоже собирался вечером написать. Это было в bosfor
# Re: Разбор idec
revoltech (spnet, 4) → Andrew Lobanov – 05:31:53 2024-10-31
AL> И это ломает поддержку стандарта.
Ладно. Ломает, так ломает, будем контекстозависимые парсеры городить. А что насчёт /u/mc?
revoltech> А ещё предлагаю ввести /u/mc, возвращающий число, чтобы клиент знал максимум сообщений, который нода может ему отдать за один GET-запрос /u/m.
Сейчас у меня в фетчере это значение по умолчанию равно 12, пока явно не указано обратное. Было бы неплохо, если бы станция сообщала эту информацию клиенту для оптимального выкачивания мессаг.
revoltech (spnet, 4) → Andrew Lobanov – 05:31:53 2024-10-31
AL> И это ломает поддержку стандарта.
Ладно. Ломает, так ломает, будем контекстозависимые парсеры городить. А что насчёт /u/mc?
revoltech> А ещё предлагаю ввести /u/mc, возвращающий число, чтобы клиент знал максимум сообщений, который нода может ему отдать за один GET-запрос /u/m.
Сейчас у меня в фетчере это значение по умолчанию равно 12, пока явно не указано обратное. Было бы неплохо, если бы станция сообщала эту информацию клиенту для оптимального выкачивания мессаг.
# Дополнения к стандарту
revoltech (spnet, 4) → revoltech – 05:14:34 2024-10-31
Предлагаю ввести общий слайсинг вида «ключ-значение», в котором вместо диапазона можно писать all или же msgid (в таком случае берётся содержимое эхо от него):
/u/e/echo.1/all/echo.2/some_msgid_blablabla/echo.3/-10:10
А ещё предлагаю ввести /u/mc, возвращающий число, чтобы клиент знал максимум сообщений, который нода может ему отдать за один GET-запрос /u/m.
revoltech (spnet, 4) → revoltech – 05:14:34 2024-10-31
Предлагаю ввести общий слайсинг вида «ключ-значение», в котором вместо диапазона можно писать all или же msgid (в таком случае берётся содержимое эхо от него):
/u/e/echo.1/all/echo.2/some_msgid_blablabla/echo.3/-10:10
А ещё предлагаю ввести /u/mc, возвращающий число, чтобы клиент знал максимум сообщений, который нода может ему отдать за один GET-запрос /u/m.
# Re: Разбор idec
revoltech (spnet, 4) → revoltech – 05:03:54 2024-10-31
revoltech> /u/e/echo.1/all/echo.2/-3:3/echo.3/-10:10
И да, в моём варианте вместо диапазона легко подставить msgid, и так же легко на стороне сервера проверить, что именно там стоит. Если диапазон, берём диапазон, если msgid, берём от этого msgid.
revoltech (spnet, 4) → revoltech – 05:03:54 2024-10-31
revoltech> /u/e/echo.1/all/echo.2/-3:3/echo.3/-10:10
И да, в моём варианте вместо диапазона легко подставить msgid, и так же легко на стороне сервера проверить, что именно там стоит. Если диапазон, берём диапазон, если msgid, берём от этого msgid.
# Re: Разбор idec
ahamai (blackcat, 2) → shaos – 04:52:41 2024-10-31
Кстати я ошибся мой код ломает
Вечером напишу
ahamai (blackcat, 2) → shaos – 04:52:41 2024-10-31
Кстати я ошибся мой код ломает
Вечером напишу
# Re: Разбор idec
ahamai (blackcat, 2) → shaos – 04:52:03 2024-10-31
У меня вообще в ноде на парсере нет регулярных выражений :)
ahamai (blackcat, 2) → shaos – 04:52:03 2024-10-31
У меня вообще в ноде на парсере нет регулярных выражений :)
# Re: Разбор idec
revoltech (spnet, 4) → ahamai – 05:00:09 2024-10-31
ahamai> Складывается впечатление, что idec это пример плохого проектирования.
На это я пытался намекнуть чуть ли не с первого дня появления здесь.
ahamai> MSGID? по логике вроде бы да.
Нет, в msgid тоже двоеточий быть не может. И длина должна быть 20 символов.
Но в целом согласен, текущий формат слайсов какой-то недоработанный. Не то чтобы его сложно реализовать, но задачи экономить трафик при запросе большого количества эх он действительно не решает.
Я ещё могу понять, почему всё через / — это проще парсить, чем отдельно компоненты пути и компоненты HTTP query, особенно учитывая, что от HTTP в общем случае можно (и нужно) отходить. Но я не могу понять, почему бы не сделать в запросе такую же железобетонную структуру ключ-значение, как и в тегах бандла ii/ok/repto/blabla:
/u/e/echo.1/all/echo.2/-3:3/echo.3/-10:10
Этот формат (после удаления первого слэша) однозначно парсится в ключ-значение, на тикле он вообще одним сплитом преобразуется в список, читающийся через dict. И тогда и дополнительных проверок на то, где название эхи, а где диапазон, делать не нужно. Первый ключ — u со значением e, второй ключ — echo.1 со значением all и так далее. А сейчас всё как-то дико контекстозависимо получается, потенциал допустить ошибку куда выше.
revoltech (spnet, 4) → ahamai – 05:00:09 2024-10-31
ahamai> Складывается впечатление, что idec это пример плохого проектирования.
На это я пытался намекнуть чуть ли не с первого дня появления здесь.
ahamai> MSGID? по логике вроде бы да.
Нет, в msgid тоже двоеточий быть не может. И длина должна быть 20 символов.
Но в целом согласен, текущий формат слайсов какой-то недоработанный. Не то чтобы его сложно реализовать, но задачи экономить трафик при запросе большого количества эх он действительно не решает.
Я ещё могу понять, почему всё через / — это проще парсить, чем отдельно компоненты пути и компоненты HTTP query, особенно учитывая, что от HTTP в общем случае можно (и нужно) отходить. Но я не могу понять, почему бы не сделать в запросе такую же железобетонную структуру ключ-значение, как и в тегах бандла ii/ok/repto/blabla:
/u/e/echo.1/all/echo.2/-3:3/echo.3/-10:10
Этот формат (после удаления первого слэша) однозначно парсится в ключ-значение, на тикле он вообще одним сплитом преобразуется в список, читающийся через dict. И тогда и дополнительных проверок на то, где название эхи, а где диапазон, делать не нужно. Первый ключ — u со значением e, второй ключ — echo.1 со значением all и так далее. А сейчас всё как-то дико контекстозависимо получается, потенциал допустить ошибку куда выше.
# Re: Разбор idec
ahamai (blackcat, 2) → shaos – 04:28:59 2024-10-31
Можно хоть xml регекспами парсить. Я спрашиваю зачем добавлять в список эх что то ещё, делать проверки которые можно было не делать, терять в прозрачности, если всё это можно было сделать кучей способов, каждый из которых лучше. Какую проблему решили добавив неэховую инфу в /u/e?
ahamai (blackcat, 2) → shaos – 04:28:59 2024-10-31
Можно хоть xml регекспами парсить. Я спрашиваю зачем добавлять в список эх что то ещё, делать проверки которые можно было не делать, терять в прозрачности, если всё это можно было сделать кучей способов, каждый из которых лучше. Какую проблему решили добавив неэховую инфу в /u/e?
# Re: Разбор idec
ahamai (blackcat, 2) → shaos – 04:10:09 2024-10-31
Это надо дополнительно разбирать. Когда иожно было бы этого не делать. Это неочевидно, теряется простота. И это порождает артефакты там, где это не поддерживается. Я всё написал выше, это ненужная работа вследствие плохого дизайна. Не надо пихать что то в список эх, это кривит архитектуру.
ahamai (blackcat, 2) → shaos – 04:10:09 2024-10-31
Это надо дополнительно разбирать. Когда иожно было бы этого не делать. Это неочевидно, теряется простота. И это порождает артефакты там, где это не поддерживается. Я всё написал выше, это ненужная работа вследствие плохого дизайна. Не надо пихать что то в список эх, это кривит архитектуру.
# Re: Разбор idec
shaos (spnet, 2) → shaos – 04:21:32 2024-10-31
Блин как эти ==== в этом ii-php работают? Ненавижу регулярные выражения...
shaos (spnet, 2) → shaos – 04:21:32 2024-10-31
Блин как эти ==== в этом ii-php работают? Ненавижу регулярные выражения...
# Re: Разбор idec
shaos (spnet, 2) → shaos – 04:20:41 2024-10-31
> Индексы тоже пару строк кода добавляют (ну может чуть больше)
Ну ок не 2 строки, а 20, но тем не менее :)
>> Читать далее
shaos (spnet, 2) → shaos – 04:20:41 2024-10-31
> Индексы тоже пару строк кода добавляют (ну может чуть больше)
Ну ок не 2 строки, а 20, но тем не менее :)
elseif ($opts[0] == 'u' and $opts[1] == 'e') {
$work_options=array_slice($opts, 2);
$w_opts_count=count($work_options);
if (
$w_opts_count > 1 and
strstr($work_options[$w_opts_count-1], ":")!==false
) {
$buffer="";
$numbers=explode(":", $work_options[$w_opts_count-1]);
>> Читать далее
# Re: Разбор idec
shaos (spnet, 2) → ahamai – 03:46:24 2024-10-31
> если менять это, то надо убирать неэхи из стрки для эх
очевидно, что запись [-]N:M не является эхой т.к. там не точка, а двоеточие (и может быть минус вначале)
shaos (spnet, 2) → ahamai – 03:46:24 2024-10-31
> если менять это, то надо убирать неэхи из стрки для эх
очевидно, что запись [-]N:M не является эхой т.к. там не точка, а двоеточие (и может быть минус вначале)