Да, серьёзно. Я согласился после того, как Макс мне доложил, что ты разбираешься в ассемблере + присутствует ещё достаточно программистов. Зашёл где-то часов в 18 (по пути было). Вас было только трое.

Ромхакинг для меня будет трудоёмким, так как нечего хакать =)
Но вот тот же GNU Asm хотелось бы изучить.

> В принципе, достаточно просто и вполне увлекательно.
Ключевое слово - увлекательно.

Попробую всё-таки начать сам. Если что-то получится, то подумаю насчёт следующего клиента =)

vit01>> Актуальный Cutiefeed всегда лежит на Гитхабе, однако пашет нормально только на линуксах. Он, конечно, ужасен, но уже получше :)
vit01>> Давно хочу переписать всё это дело на другом тулките и сделать дизайн как в IDEC Mobile, но постоянно сталкиваюсь с трудностями и так и не могу сделать какой-то рабочий прототип.

libra> А в чём стреляют сложности?! Наличие машины на винде?! Среды для компилинга?! Времени?! Желания?! Силы?!

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

Насчёт тулкитов есть вполне определённые причины. Я пробовал много всяких штукенций, но требованиям к поддержке разных систем и по дизайну удовлетворяет только Qt + QML

Однако, в QML есть немало трудностей

1. Нет концепции "фрагментов" для избежания дублирования кода и адаптивного дизайна. Есть некоторые базовые штуки в плане дизайна, но там многое надо реализовывать с нуля

2. В IDEC Mobile список эх и список сообщений полностью полагаются на компонент RecyclerView https://developer.android.com/guide/topics/ui/layout/recyclerview , который позволяет не жрать память на больших объёмах информации и запрашивать данные из БД только по мере необходимости. Для эх с >100 сообщениями такая штука просто необходима. Иначе придётся либо уменьшать количество фич, либо делать не слишком отзывчивый в плане производительности клиент.

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

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

Зашёл на главную http://spline.rooker.ru
Удивился немного =)

>Это тизер моей новой игрушки
Где скачать можно?

Кто здесь ещё сидит? Как у вас дела?

> Отпуск через месяц =)
Хорошо вам, а мне через месяц опять трудиться :)

Мне тоже понравилось, спасибо. Хоть формально сходка была про MLP, но обсуждали мы в основном ассемблер и программирование.

Не часто выхожу из дома, тем более на _такие_ мероприятия.

Кстати, ты говорил, что хотел бы посмотреть наше API, так что вот:

http://ii-net.tk/ii-doc - документация, API и много дополнительного текста по теме
http://ii-net.tk/iidownload - ссылки на скачивание различных клиентов + исходники
http://ii-net.tk/station.html - список станций нашей сети

// Да, Максу теперь несладко без интернета придётся, будет повод испытать в действии ii флешка-edition :D

Решил написать на асме прогу, выводящую содержимое ii-шной эхоконференции, передаваемой ей в аргументах командной строки.

В принципе тут всё просто, но я изрядно намучался с этим =)
http://ii-net.tk/view.s

В процессе написания новых утилит.

Для аналога write.c осталось доделать парсинг сообщения и ещё несколько вещей.

Писать абсолютно без использования внешних библиотек очень весело :D

Написал аналог write.c из iitxt-c
Правда, в отличие от сишного аналога, он ещё не умеет ставить Re: в сабж, но скоро научится.

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

Кому интересно почитать/попробовать, выложил на гитхаб
https://github.com/vit1-irk/iitxt-asm

Компилить через $ gcc файл.s -o файл # как обычно, т.е. не через as и ld

Осталось написать фетчер и мейлер :D

> Видел железки на Debian. Даже на Slackware 9 есть до сих пор две железки. Но на Gentoo вижу что-либо впервые.

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

ii://Q2W8hMM6eJeCJS4Z5I4o

Тогда загейтую так, как есть.

// уже подумал, что ты обиделся на меня из-за mlp.15 и решил не отвечать :С (вот что дебаггер делает с человеком)

> Это в какой эхе сообщение? А то у меня там пустота.
ii://mlp.15

Насколько помню, http://ii.difrex.ru ту эху не гейтует

> он ещё не умеет ставить Re: в сабж, но скоро научится.
Научился.

Ещё добавил мейкфайл, сделал libcurl-мейлер, который содержит в себе кучу кода, но пока не работает (сегфолты и мусор в запросе). Реализация base64 пока взята из сишного клиента.

> Прикольный у тебя Just For Fun :)
Устал уже от него, целыми днями код пишу =)

libcurl при вызове curl_easy_perform портит кучу памяти, а если реализовывать через голые сокеты, то ругается "Cannot resolve hostname", так как пока не получилось дословно продублировать структуру socketaddr_in из сишного аналога.

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

> Я себя в C, а тем более ASM не смогу заставить
Си на самом деле довольно удобен для программиста, в самом языке и в стандартных библиотеках много хороших штук. Просто попробуй. К асму, в принципе, тоже приноровиться можно, но тут дебаггер обязательно нужен и внимательный взгляд =)

> Меня обидишь. Это постараться надо сильно.
Вот надеюсь, что я не старался.

// всем добра в этой эхе! http://ii-net.tk/fs2.gif (warning: mlp)

> Извините за этот поток сознания и негодования, но накипело. Как у вас обстоят дела со столь тяжелодобываемым ресурсом, как чистая вода?
У нас плановые отключения тоже проводят раз в пару месяцев. Около недели держат, потом включают, и не по всему городу, а по отдельным домам. Насчёт чистоты претензий никогда не было. В Иркутске вообще вода из-под крана чистая, её даже пить можно. Говорят, что это вообще редкость в России.

> В связи с концом лета, желаю всем бесконечного августа. Пусть за окном будет дождь и метели, ... ... , но внутри у каждого будет лето.
Дождь и метели круче, чем жара, так что всё отлично :)

> P.S.: Всем внезапного добра и радостных моментов.
Спасибо, тебе тоже. =)

> Откопал в своих залежах раритетного и не очень железа сабж Compaq Evo n600c.
Помню, ты уже писал про него в ii://linux.14 или ещё где. И собирался на него OpenBSD вкатить =)

У моего варианта модели HDD 20гб, но зато живой привод и трекпоинт.
Цезий и сишный клиент отлично там работают, уже пробовал.

P.S. Ты нашёл где-нибудь драйвера на Mobility Radeon M5/6? Слышал, что их давно убрали из xf86-video-ati, при том, что во времена Kubuntu 9.04 там даже компиз работал отлично.

> Трудно стало найти дома оптические диски =)
Можно же с флешки дистрибутив поставить =)

> Буду надеяться, что оно заведётся хотя бы без ускорения, так как оно (ускорение то бишь) мне без надобности, а вот иксы нужны.
Без ускорения оно вполне себе нормально работает. Даже xfce использовать можно. Только советую композитинг не включать, иначе тормоза пойдут.

> У моего бука такой опции нет. Не умеет он грузиться с USB-устройств. Хоть тресни.

Умеет. В биосе в меню Device options поставь USB legacy support: enable; (эта опция по-умолчанию отключена), потом в меню Boot Options сделай Express Boot Popup Delay > 0, затем перезагружаешься, и он выдаст в менюшке USB Hard Disk.
Правда, после этих шагов он cможет увидеть флешку не сразу, так что придётся перезагрузиться несколько раз, если не поможет.

Сабж.

Помню, что Денис эти 2 недели отсутствует, но всё-таки надо бы узнать, есть здесь кто или нет.

> я живой.
Ура, есть люди! Привет :)

> раз 20 пытался сюда написать - да и сейчас еле залогинился. писал на @ii-net.tk, дали отлуп.
Разберусь с этим, спасибо за ответ.

> писал на spline@ - нет ответа.
Насколько помню, Андрей по выходным отдыхает.

Что у тебя хоть нового? Давно не заходил сюда.

> кстати, а где ссылка со всеми актуальными клиентами

http://ii-net.tk/iidownload/
Всегда здесь было.

А насчёт остального утром отвечу, так как спать организму надо :)

> Qt-клиент - это вот это?
Именно. Сам им пользуюсь.

> основное, что мне хочется от своего нового протокола - это короткие msgid (12 символов, а то и 8)
У нас куча клиентов, в них стоят проверки (хотя в сишном и qt они точно отсутствуют). Да и не особо это важно: было всегда 20 и не мешало.

> избавление от цифровых приставок и возможность запрашивать произвольное количество сообщений (чтобы в одной эхе можно было хранить хоть миллион сообщений, но юзерам это не мешало жить).
Теперь подробнее рассказывай, как ты будешь обеспечивать безболезненную жизнь с миллионом сообщений в эхе :)
Это же главная архитектурная проблема ii, если мы помним.

> в общем, если есть интерес - давайте организуем конгресс по выработке стандартов взаимодействия сетей ii и gk11
Написать гейт-скрипт, как было в прошлый раз с uliss - без проблем. Но менять стандарты у себя пока смысла не имеет.

> 2. научить клиенты использовать оба стандарта
В моих клиентах проверок на длину msgid (и не только длину) нет. Есть только проверки на эху (если в строке есть точка, то это эха), но могу добавить двойной фильтр, если что.

> забираем только последние n сообщений. либо количественно,
Если на сервере за время до фетча появились сообщения в количестве больше n, то клиент не сможет их зафетчить.

> либо отслеживаем новое поле таймштампа "прибыло на станцию" и отслеживаем по нему.
Таймштамп ненадёжен тем, что как у клиента, так и у сервера системное время может быть неверным. Допустим, что оно верное, остаётся другая проблема: проблематичность отслеживания таймстампов для каждого сообщения, т.е. придётся либо строить кэш, либо завязываться полностью на базах данных, что убирает принцип простоты.

> нужно выработать общие стандарты. тот же uliss не мог гейтовать любую эху. есть ещё нюансик с протоколами ии:// в ii и аналогичными для эх и сообщений... в общем, стандарты должны учитывать друг друга, чтобы легко меняться.
> поэтому нужен симпозиум - чтобы не дублировать постоянно одно и то же, клонируя серверы и клиенты, а добиться совместимости

Давайте вырабатывать. Только в пределах разумного, конечно =)

> покажите хоть одну ноду с регистрацией, на случай потери ключа
Таких пока нет. Надо будет что-нибудь придумать.

> Андрей, а у тебя через веб-интерфейс писать можно?
Веб-интерфейс есть у всех нас, т.е. можно.
http://spline.rooker.ru/ii

> дело не в длине, а в том, чтобы софт понимал, что это такое
Видимо, мы про одно и то же говорим =)

> кроме того, если в n сообщений нет ни одного знакомого, можно запросить ещё n, а потом ещё.
А вот это мне уже нравится. Только вот надо придумать, как реализовать подобные смещения.

> например, зачем мне сейчас весь архив pipe.2032? мне нужны только последних 100 сообщений, где я в дискуссии.
Но нодам при синхронизации и парсинге нужно работать с полным списком сообщений, поэтому нужно проработать и переполнение файла эхи.

> принцип старый - сначала списки с msgid, потом сами сообщения. и не нужно хранить acceptts для каждого сообщения, нужно хранить для каждой эхи.
Кажется, начинаю понимать. Можно делать таймстамп последнего обновления эхи и/или преобразовать файл echo/<название> на ноде в формат msgid:ts\nmsgid:ts.
Это куда более реально.

> я вот смотрю на станцию ii-net и spline, и вижу, что там разное количество сообщений в pipe.2032 :)
Это же из-за blacklist.txt =)

> не обязательно.
Но сообщения в эхе могут находиться в разном порядке, поэтому так или иначе проводить полную синхронизацию придётся иногда.

Но я имел в виду другую вещь. Предположим, элементов в эхе 100 000. Когда серверное ПО пытается распарсить список из 100 000 msgid, оформить это в виде массива, выделить для всех элементов память, а потом ещё и манипуляции с такими вещами проводить, то это превращается в очень медленное и трудоёмкое дело.

> у bosfor был ключ appendts, который вместе с запросом выдаёт и ts синхронизации сервера
> ты его сохраняешь, а при следующем синке делаешь запрос /acceptfrom/СОХРАНЁННЫЙTS
В общем, гибрид /x/t/ и /u/e. Вполне неплохо.

> самый простой способ - запрашивать список с n последних
Попробовать, конечно, можно.

> до 2 млн волноваться не стоит.
Я уже на 10 тыс. волнуюсь =) Python и PHP хорошо умеют кушать память и имеют не очень впечатляющую производительность.

> есть ещё нюансик с протоколами ии:// в ii и аналогичными для эх и сообщений...
Упоминание этого дела навело на одну мысль.

Всегда считал использование одной разметки для эх и сообщений немного неудобным для парсинга. Проще было бы чисто с программной точки зрения сделать msg:// для сообщений и echo:// для эх. Ещё достаточно костыльно парсить ====, более удобной альтернативой этой схеме были бы комментарии в стиле Си /* вот так вот */ или Lua --[[ как здесь ]], чтобы просто их заменять на <pre> или </pre>.

// Это просто мысли вслух

> Я думал сделать режим такой: первый забор эхи или рескан n сообщений или полный, поуказанию пользователя. А потом диффы от первого известного клиенту сообщения до последнего в эхе на ноде.

Неплохо выглядит идея забирать сначала n последних (параметр -n), затем если среди них все новые, то запрашивать -2n:n, потом -3n:n и так далее. Причём хранить на клиенте упоминание о полной синхронизации (если её вообще не было, то сначала фетчим по полной, затем просто ставим метку, чтобы дальше в экономном режиме).

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

> 200000 - это смешной размер
> [код]

Выполнение этого скрипта заняло у меня 15 секунд. Плюс заметим, что ПО ii для своих нужд требуется и распарсить файлы, и проводить поиск. Нельзя забывать, что на сервер могут приходить (в перспективе) сотни запросов ежесекундно, так что беспокоиться есть за что.

> замена не подойдёт. во-первых, заменяемый код может уже быть в коде, а во-вторых, внутри кода не должны работать никакие другие парсеры, типа "url в ссылку" и тому подобное.
Хорошо, согласен.

> а так у меня используются msg:// и echo://
Вот хотелось бы так же сделать, но для принятия чего-либо нужно всем голосовать (Андрей и Денис в особенности).

> Некорректно выразился. Не диффы в прямом смысле, а примерно то, что получаем с ноды сейчас. То есть простое построение разностного списка сообщений, но только с учётом того, что было полученно изначально.
Теперь я запутался =) Объясни поточнее, пожалуйста, если не затруднит.

> ps. что-то та станция постоянно отваливается - сейчас написал ответ, а отправить не смог, "сервер не отвечает"
Можешь сидеть на резерве http://alicorn.tk/ii , либо у Андрея. Сам замечаю за своей станцией даунтайм.

> в ii есть запрос /u/e/, который получает список из эх и выдаёт их. в текущем же bosfor, насколько я помню, это не реализовано, и выдаётся просто список сообщений. связано это с тем, что в ii был "список эхи", и "указание на эху в сообщении", в текущей же реализации никакого "списка эхи нет", есть только список сообщений, у которых есть параметр "эха", и по ней всё определяется

Поскольку ii исходит из принципа быстродействия и суперпростоты, делать у нас что-то подобное смысла не вижу. Оно будет сильно загружать процессор и ЖД. Даже если это будет не так, то придётся завязываться строго на базе данных (да пусть если sqlite), то это противоречит идее простоты и универсальности.
ii должен ориентироваться на возможность построения по текстовой БД с малыми потерями в производительности.

> поэтому я и думаю, как можно ваши клиенты приспособить, чтобы не форкать - но я же не знаю, как они устроены.
Требуется сделать возможность наличия двоеточия в имени эхи (и идентификацию эхи по нему) и совместимые msgid? В своих клиентах я это обеспечить могу, мне не принципиально.

> 14.5 секунд - это генерация :) это время уйдёт на загрузку списка :)
Но это же ооочень долго =) и просто недопустимо. 2-3 секунды - максимум для комфортной работы.

> ii пусть остаётся. но лучше и её перевести на формат ii12, чтобы оно было совместимо полностью
Собираюсь определить особенности каждого формата и хорошие мысли, высказанные в этой дискуссии, и наконец-то устроить голосование по стандартам. Но только не сегодня, а то дел, увы, полно =)
Тут же ещё с особенностями софта рассчитать надо, а это помню только я и Андрей.

> есть ли хде самый полный список эх? а то в веб-интерфейсе - не все ;(
Только у сисопов. Я вон себе давно уже BSOD поставил на http://ii-net.tk/ii/echo/ =)

Могу припомнить из своих более-менее новых только архивную ii://hc.51, lenta.rss.15.* до 6 и ii://clop_r.34 (только не читай её, там куча бреда).

> какие есть ещё живые эхи (но не rss), которые есть на всех станциях?
У Андрея есть spline. [creepy, local] .14 и ещё что-то. У меня только архивные.
Ах да, у него ещё есть ii://lor.news.15 : это новостная, но он туда вручную постит.

> ii - 20значная... начать сейчас что-то гейтовать - потом опять всё переделывать...
Мы просто уберём проверки на длину, и всё будет работать.

Только вот интересно, что именно гейтовать? А то, смотрю, у тебя на том сайте домен истёк.

> в гейте?
Не только в гейте, а вообще на ноде. На длину msgid.
Либо можно сделать их нестрогими (от 8 до 20, к примеру)

> куда истёк? http://bb.51t.ru
Был же более короткий hc25.ru, он и истёк.

> эхи :besedka, :obsd, :humor - все вроде живые
Попробую тогда загейтовать потом. Правда, беседку гейтовать не хочется, а openbsd вполне можно.

> первый недостаток, который я вижу - bosfor не умеет ничего, кроме 8 символов, и если скормить ему 20 - подавится :)
А вот это уже реальная проблема. Тогда предлагаю всем нам убрать фильтры, чтобы по-честному, а длину msgid оставить на собственное усмотрение.

> в passthru заведи, мож кому из даунлинков понадобится :)
У меня из даунлинков только Rush_Pon, а ему эта эха уж точно не нужна =) Difrex же сейчас в отпуске, без сети отдыхает.

> три новых песни - на http://osole.51t.ru
Хорошо песни делают =) Аж 3 сразу

> 58b из новых просто супер

> Сабж
С возвращением.
А у нас тут много нового. Теперь читай тут всё ;)

> Вот вам енотик
Милашка :3

Ничего страшного, за такое не надо извиняться. Выздоравливай и удачи с сессией.

> Сегодня мне снился код.
Везёт же некоторым людям =)

// А кому-то всякая гадость снится...

> Пилим мы сейчас некую API для админов. Ну, то есть мы админы и пилим систему для админов. :)
> Подробности будут позже. Детали о том, что же это такое тоже попозже. Следите за событиями, лол :)

Интересно, что же это может быть. Слежу.