Официальная конференция Direct Connect клиента EisKaltDC

eiskaltdc@conference.gentoo.ru

Суббота, 4 сентября 2010< ^ >

NegatiV установил(а) тему: Last stable release: 2.0.3 || Конференция разработчиков EiskaltDC++ || логи: http://gentoo.ru/jabber/logs/eiskaltdc@conference.gentoo.ru/2010/ || Лог изменений в последней ревизии на свн: http://code.google.com/p/eiskaltdc/source/list || Общая активность в проекте: http://code.google.com/p/eiskaltdc/updates/list
Release schedule:
2010-09-18 Feature freeze
2010-09-20 Strings freeze
2010-10-15 Release EiskaltDC++ 2.1.0
https://adc.svn.sourceforge.net/svnroot/adc/trunk/ADC-EXT.txt
ADC-Extensions July 2010
=== Version 1.0.4 UNRELEASED
* Added magnet link extension to 'UCMD'
* Added NAT traversal extension 'NATT'
* Added referral field to STA
* Added upload queue field to STA
* Added partial file sharing extension 'PFSR'

Конфигурация комнаты

Участники комнаты

GMT+4
[00:07:06] slepnoga вошёл(а) в комнату
[01:11:07] 0xd34df00d вышел(а) из комнаты
[01:13:50] 0xd34df00d вошёл(а) в комнату
[01:25:28] pavelvat вышел(а) из комнаты
[01:44:02] Spy вышел(а) из комнаты
[02:12:33] slepnoga вышел(а) из комнаты
[02:14:10] amfetamin вышел(а) из комнаты
[02:25:33] Spy вошёл(а) в комнату
[02:34:15] slepnoga вошёл(а) в комнату
[02:37:58] slepnoga вышел(а) из комнаты
[02:41:02] slepnoga вошёл(а) в комнату
[03:17:43] slepnoga вышел(а) из комнаты
[03:40:28] slepnoga вошёл(а) в комнату
[05:58:19] slepnoga вышел(а) из комнаты
[05:59:05] slepnoga вошёл(а) в комнату
[06:19:06] A-lexey вышел(а) из комнаты: Я счастливый пользователь Miranda IM. Возьми её тут http://miranda-im.org/.
[06:19:53] slepnoga вышел(а) из комнаты
[06:59:35] slepnoga вошёл(а) в комнату
[07:12:04] slepnoga вышел(а) из комнаты
[08:40:53] slepnoga вошёл(а) в комнату
[08:59:08] l0wk3y вошёл(а) в комнату
[08:59:18] l0wk3y вышел(а) из комнаты
[09:31:06] amfetamin вошёл(а) в комнату
[09:47:22] burzumko вошёл(а) в комнату
[09:50:01] <burzumko> утро. 9999 не компилится http://paste.pocoo.org/show/258328/
[09:51:34] amfetamin вышел(а) из комнаты
[09:59:24] nE0sIghT вошёл(а) в комнату
[10:10:45] Клёк вошёл(а) в комнату
[10:50:44] FiliN вошёл(а) в комнату
[11:00:24] slepnoga вышел(а) из комнаты
[11:04:02] <Nikoli> burzumko: http://pub.nikoli.msk.ru/portage-overlay/net-p2p/eiskaltdcpp/eiskaltdcpp-9999.ebuild
[11:04:32] <Nikoli> в портежи внесли мои правки не полностью
[11:11:50] man_hattan вошёл(а) в комнату
[11:13:35] FiliN вышел(а) из комнаты
[11:13:45] FiliN вошёл(а) в комнату
[11:13:54] <burzumko> ok
[11:15:26] FiliN_ вошёл(а) в комнату
[11:15:27] FiliN_ вышел(а) из комнаты
[11:19:10] <burzumko> как я понимаю miniupnp заменяет libupnp?
[11:24:11] <Nikoli> burzumko: да, библиотеку upnp сменили
[11:24:24] <Nikoli> к релизу добавим в портежи, надеюсь
[11:32:50] <man_hattan> еще бы звук сделали рабочим на приход друга. В настройках есть, а на деле ничего не работает
[11:32:51] <man_hattan> :(
[11:47:32] FiliN вышел(а) из комнаты
[11:47:46] FiliN вошёл(а) в комнату
[12:10:26] man_hattan вышел(а) из комнаты
[12:26:24] gelraen вышел(а) из комнаты
[12:27:10] gelraen вошёл(а) в комнату
[12:39:44] burzumko вышел(а) из комнаты
[12:45:13] slepnoga вошёл(а) в комнату
[12:51:57] slepnoga вышел(а) из комнаты
[12:52:36] slepnoga вошёл(а) в комнату
[12:58:49] NegatiV вошёл(а) в комнату
[13:12:04] NegatiV вышел(а) из комнаты
[13:13:03] NegatiV вошёл(а) в комнату
[13:25:33] slepnoga вышел(а) из комнаты
[13:27:49] FiliN вышел(а) из комнаты
[13:28:04] FiliN вошёл(а) в комнату
[13:49:33] FiliN вышел(а) из комнаты
[13:49:47] FiliN вошёл(а) в комнату
[14:28:20] vasily.n@k.. вошёл(а) в комнату
[14:54:24] FiliN вышел(а) из комнаты
[14:54:36] FiliN вошёл(а) в комнату
[15:19:10] FiliN вышел(а) из комнаты
[16:37:57] pavelvat вошёл(а) в комнату
[16:38:53] <pavelvat> NegatiV: как там дела с квадратиками вместо сообщений ядра под Windows?
[16:39:38] <NegatiV> pavelvat: я пока винду не ставил, хорошо что ты напомнил - сейчас в виртуалку поставлю)
[16:41:52] <pavelvat> NegatiV:
2010-09-20 Strings freeze
2010-10-15 Release EiskaltDC++ 2.1.0
почти целый месяц на поиск багов, да там багов столько нет чтобы целый месяц искать.
[16:42:28] <NegatiV> pavelvat: а ты взгляни на трекер)
[16:42:46] <0xd34df00d> NegatiV: ооо.
[16:42:50] <0xd34df00d> Хай :3
[16:42:54] <NegatiV> pavelvat: плюс мне еще надо пилить Wt
[16:42:59] <NegatiV> 0xd34df00d: хай
[16:43:33] <pavelvat> NegatiV: т.е. Strings freeze на Wt не распространяется?
[16:43:36] <0xd34df00d> NegatiV: чочо как оно там со впиливанием в личкрафты? )
[16:44:10] <NegatiV> pavelvat: я не успею сделать нармального демона к октябрю - работы и без него сейчас валом
[16:44:22] <NegatiV> *нормального
[16:45:08] <pavelvat> NegatiV: так Wt вообще будет в релизе 2.1.0 ?
[16:45:30] <NegatiV> 0xd34df00d: 2.0.3 впилю, все последующие версии уже нет - очень много изменений там
[16:45:54] <NegatiV> 0xd34df00d: в плане структуры проекта
[16:46:07] <NegatiV> pavelvat: в состоянии alpha или beta
[16:47:07] <0xd34df00d> Ох пичаль.
[16:47:11] <NegatiV> pavelvat: я бы вообще релиз на ноябрь перенес
[16:47:43] <pavelvat> NegatiV: так кто тебе мешает это сделать?
[16:48:12] <NegatiV> pavelvat: ну посоветоватся надо с другими еще)
[16:48:58] <NegatiV> плюс перенос релиза позволит сделать выпуск пары beta-версий
[16:50:39] <pavelvat> NegatiV: эти beta версии кому-то нужны?
[16:51:17] <NegatiV> pavelvat: ну как правило их тестируют продвинутые пользователи, которым страшновато юзать транк
[16:51:33] <NegatiV> а статус beta уже намекает на некоторую стабильность)
[16:51:51] <pavelvat> NegatiV: Issue 594 вроде как это уже давным давно исправили, но почему-то не закрыли issue.
[16:53:45] <pavelvat> NegatiV: кстати, а зачем на вкладке Downloads оставлены устаревшие релизы и даже alpha и beta версии?
[16:54:58] <NegatiV> pavelvat: а зачем их удалять?
[16:57:42] <pavelvat> NegatiV: ну если их не удалять то через несколько лет там будет свалка из всех выпущенных релизов и alpha и beta версий, просто в некоторых проектах принято чтобы в разделе Downloads были только текущий релиз и разрабатываемая версия.
[16:58:25] <NegatiV> pavelvat: свежие версии в Downloads находятся выше всех остальных, чем старее версия, тем она ниже в списке
[16:58:37] <NegatiV> так что свалки там не будет
[17:00:50] tehnick вошёл(а) в комнату
[17:07:02] <tehnick> [16:47:11] <NegatiV> pavelvat: я бы вообще релиз на ноябрь перенес
[16:47:43] <pavelvat> NegatiV: так кто тебе мешает это сделать?
[16:48:12] <NegatiV> pavelvat: ну посоветоватся надо с другими еще)
Я за. Wt морду надо допилить к релизу.
[17:07:31] <NegatiV> tehnick: хорошо
[17:07:32] <tehnick> И стринг-фриз надо отложить.
[17:07:50] <pavelvat> NegatiV: в папке sounds некоторые файлы дублируются: ConnectHUB.wav и HubConnected.wav
DisconnectHUB.wav и HubDisconnected.wav
и есть файл UploadFinished.wav но при этом нет файла UploadBegin.wav
а также ошибка с использованием множественного числа "Begins" в имени файла DownloadBegins.wav
[17:08:48] NegatiV установил(а) тему: Last stable release: 2.0.3 || Конференция разработчиков EiskaltDC++ || логи: http://gentoo.ru/jabber/logs/eiskaltdc@conference.gentoo.ru/2010/ || Лог изменений в последней ревизии на свн: http://code.google.com/p/eiskaltdc/source/list || Общая активность в проекте: http://code.google.com/p/eiskaltdc/updates/list
Release schedule:
2010-10-20 Feature freeze
2010-10-30 Strings freeze
2010-11-15 Release EiskaltDC++ 2.1.0
https://adc.svn.sourceforge.net/svnroot/adc/trunk/ADC-EXT.txt
ADC-Extensions July 2010
=== Version 1.0.4 UNRELEASED
* Added magnet link extension to 'UCMD'
* Added NAT traversal extension 'NATT'
* Added referral field to STA
* Added upload queue field to STA
* Added partial file sharing extension 'PFSR'
[17:09:12] <NegatiV> pavelvat: я это не добавлял, так что даже не понимаю о чем ты
[17:09:13] <NegatiV> =)
[17:09:34] <pavelvat> tehnick: кажется звуки ты добавлял
[17:10:00] <pavelvat> NegatiV: а в чём смысл такого раннего Strings freeze ?
[17:11:16] <tehnick> pavelvat: да я. Копипаста + рид_ми
[17:11:32] <tehnick> pavelvat: сейчас гляну, что там.
[17:11:42] <pavelvat> две недели только исправлять баги - столько времени может потребоваться только если до Strings freeze не исправлять ни одного бага из тех что есть сейчас.
[17:12:29] <NegatiV> pavelvat: не думаю что торопить переводчиков хорошая идея, поэтому им 2 недели на все про все
[17:12:50] <NegatiV> на исправление багов три недели
[17:13:13] <NegatiV> и то я уже против добавления нового функционала в Qt версию
[17:22:36] <pavelvat> NegatiV: а чисто гипотетически возможен в отдалённом будущем выход EiskaltDC++ 3.0 в котором dc++ будет только демоном? Соответственно все интерфейсы: CLI(консольный, нужен если не установлены X-ы, или если есть доступ к машине только по SSH), GUI(Qt, GTK) и WebUI(доступ через браузер) будут коннектится к этому демону.
[17:23:03] <tehnick> pavelvat: нет
[17:23:13] <NegatiV> нет
[17:23:19] <pavelvat> tehnick: почему?
[17:23:20] <NegatiV> ибо более чем бессмысленно
[17:23:37] <pavelvat> в чём бессмысленность то?
[17:23:40] <tehnick> pavelvat: уже обсуждали давно. И было разжевано почему...
[17:24:25] <NegatiV> pavelvat: если в 2-х словах: большой оверхед
[17:24:41] <NegatiV> особенно для GUI приложений
[17:25:47] <0xd34df00d> NegatiV: это.
[17:26:07] <0xd34df00d> NegatiV: а я могу как-то помочь с деланием LC-порта для EDC++ ≥2.1?
[17:26:09] <pavelvat> tehnick: то что там говорилось было не ясно - утверждалось что по каким-то причинам производительность ухудшится, в тоже время сейчас пилится Wt в котором ядро отдельно от интерфейса.
[17:26:51] <NegatiV> pavelvat: разницу между линковкой с библиотекой и CLI понимаешь?)
[17:27:20] <pavelvat> что ты имешь ввиду под CLI ?
[17:27:47] <NegatiV> 0xd34df00d: а оно надо тебе?) там работы будет выше крыши, придется выкидывать кучу наших велосипедов и переписывать все то их использовало
[17:27:57] <0xd34df00d> NegatiV: ну, DC какбе нужен 0
[17:27:58] <0xd34df00d> )
[17:28:21] <0xd34df00d> Можете вкратце рассказать, как сейчас все у вас устроено? В плане разных морд, велосипедов etc.
[17:28:30] <NegatiV> pavelvat: верней не CLI, а чтением и парсингом строк от демона
[17:28:54] <NegatiV> 0xd34df00d: 3 морды (Qt, GTK, Wt), lua и qt скриптинг
[17:29:01] <NegatiV> самые главные велосипеды)
[17:29:04] <pavelvat> NegatiV: не понимаю, объясни.
[17:29:28] <0xd34df00d> Ооокей.
[17:29:36] <0xd34df00d> А с точки зрения построения проекта и архитектуры этого дела?
[17:29:58] <NegatiV> pavelvat: как ты представляешь взаимодействие с демоном?
[17:30:37] <NegatiV> 0xd34df00d: ядро + upnp + фронтенд на выбор
[17:30:46] <0xd34df00d> Оокей.
[17:30:51] <NegatiV> + пара вспомогательных либ
[17:30:52] <pavelvat> так же как сделано сейчас когда он не отдельно, я не понимаю в чём будет отличие от того что сейчас.
[17:31:00] tehnick вышел(а) из комнаты
[17:31:03] <0xd34df00d> Ну так личкрафтовый фронтенд, использующий личкрафтовые костыли вместо самописных )
[17:31:42] <NegatiV> pavelvat: сейчас линкуется с либой, у нас нет посредника (в виде демона) который бы обрабатывал сообщения от ядра и передавал их остальным
[17:32:01] <NegatiV> pavelvat: каждый фронтэнд сам принимает и обрабатывает сообщения ядра
[17:32:45] <NegatiV> 0xd34df00d: с этим думаю и будет больше всего проблем - все написано под наши велосипеды)
[17:33:11] <0xd34df00d> В смысле )
[17:33:16] <0xd34df00d> Велосипед же в рамках фронтенда, верно?
[17:33:26] <0xd34df00d> Он же не в ядре? )
[17:33:55] <NegatiV> 0xd34df00d: велосипедов больше всего в Qt фронтэнде по историческим причинам
[17:34:01] <0xd34df00d> Ну вот и отлично.
[17:34:06] <NegatiV> в ядре вроде нет их (кроме LUA)
[17:34:21] <NegatiV> не считая то ядро у нас 0.75 + 0.77 =)
[17:34:21] <0xd34df00d> Будет личкрафтовый фронтенд — sort of порт/рерайт кутешного фронтенда, использующий где можно личкрафтовые велосипеды )
[17:34:28] <0xd34df00d> Постепенно будем их выпиливать, чо )
[17:34:42] <0xd34df00d> Скорее даже порт, чо. Там все же не так много переделывать )
[17:35:12] <NegatiV> 0xd34df00d: я вообще последнее время склоняюсь к написанию своего менеджера памяти
[17:35:28] <NegatiV> ибо производительности системного malloc нам не хватает)
[17:35:40] <0xd34df00d> Эээ, в чем именно?
[17:35:51] <0xd34df00d> Если в ядре — так фронтенду-то какая разница? )
[17:35:55] <NegatiV> нужно очень часто и много выделять мелкие классы
[17:36:06] <0xd34df00d> Ну да, нужен свой аллокатор тогда.
[17:36:08] <NegatiV> я не о порте
[17:36:26] <NegatiV> вот думаю его и сваять)
[17:36:45] <0xd34df00d> Ну и отлично же )
[17:36:59] <vasily.n@k..> Почему нельзя сделать обертку вокруг dcpp-ядра, которая бы взаимодействовала с работающим ядром-демоном через разделяемую память?
Тогда оверхид был бы сведен к минимому
[17:38:04] <pavelvat> NegatiV: вот если линковка dc++ идёт с либой Wt то значит нет оверхеда и когда мы подключаемся к программе через Firefox ведь всё нормально работает, почему нельзя собрать также и Qt и GTK ?
[17:38:11] <0xd34df00d> Разделяемая память не разносится по разным машинам — зачем?
[17:38:36] <NegatiV> pavelvat: они собираются точно так же)
[17:39:20] <NegatiV> pavelvat: просто Gtk/Qt морды не используют демон, а демон работает только на обслуживание Wt-морды
[17:39:33] <vasily.n@k..> 0xd34df00d: а по разным машинам разносить вообще как-то бессмыслено, x11-ssh forwarding хватит
[17:39:46] <0xd34df00d> vasily.n@k..: тогда зачем демон? )
[17:40:29] <vasily.n@k..> 0xd34df00d: а ты ssh закрыл и приехали, все отключилось...
[17:40:40] <0xd34df00d> Что?
[17:40:41] <vasily.n@k..> я за демона, но в пределах одной машины
[17:40:48] <0xd34df00d> Но зачем демон в пределах одной машины?
[17:41:09] <pavelvat> NegatiV: я уже ничего не понимаю, ты говорил что демон приведёт к оверхеду, но при этом в Wt есть демон и нет оверхеда.
[17:41:39] <vasily.n@k..> pavelvat: в Wt демоном работает сам веб-сервер
[17:41:41] <NegatiV> pavelvat: Wt это и есть демон
[17:42:51] <0xd34df00d> Ладно, господа.
[17:42:55] <0xd34df00d> Мне на электричку пора.
[17:43:01] <vasily.n@k..> другое дело, что если параллельно с Wt запустить другую морду, это не будет одно ядро + 2 морды
[17:43:34] <pavelvat> NegatiV: так если сделать устройство Qt версии клиента таким же как Wt, это возможно?
[17:43:52] <0xd34df00d> NegatiV: подумай все же о еще одном фронтенде :3
[17:45:32] <NegatiV> 0xd34df00d: ты не поверишь, но Wt и Qt морды работают аналогично - линкуются с ядром)
[17:45:59] 0xd34df00d вышел(а) из комнаты
[17:49:48] <pavelvat> NegatiV: а так ли прямо неизбежен оверхед для конструкции "один демон и много фронтэндов к нему на выбор с возможностью сначала подключится одним поуправлять демоном, затем отключится и подключится другим фронтендом" ? Из чего следует что избежать оверхеда принципиально нельзя?
[17:52:35] <NegatiV> pavelvat: как все работает сейчас: сообщение от ядра -> обработка фронтэндом, ты предлагаешь: сообщение от ядра -> обработка демоном (кодирование сообщения) -> декодирование сообщения фронтэндом -> обработка фронтэндом
[17:52:57] <NegatiV> 2 лишних шага: кодирование/декодирование сообщения
[17:54:53] <pavelvat> NegatiV: т.е. те программы которые так реализованы, например Transmission, работают неэффективно в сравнении с аналогами не демонами?
[17:55:43] <NegatiV> pavelvat: они эффективны в пределах своей архитектуры, для меня такой подход неприемлем (я говорю о Qt-морде)
[17:56:26] <pavelvat> NegatiV:
сообщение от ядра -> обработка демоном (кодирование сообщения) -> декодирование сообщения фронтэндом -> обработка фронтэндом
а почему бы не посылать от демона сообщения в точности также как их посылает ядро dc++ ?
[17:56:54] <NegatiV> pavelvat: в бинарном виде чтоли?
[17:57:04] <pavelvat> да
[17:57:47] <NegatiV> ну тогда ты не сможешь установить демон на 64-хразрядный сервак и подключатся к нему с 32-хразрядной машины
[17:58:26] <NegatiV> и наоборот соответсвенно
[17:59:11] <vasily.n@k..> Я подозреваю, что разработка демона в любой форме добавит головной мэйнтейнерам
[17:59:20] <vasily.n@k..> боли
[18:01:09] <NegatiV> vasily.n@k..: и это тоже, но основная причина для меня - неудовлетворительная производительность
[18:01:26] <NegatiV> поэтому каждая морда работает с ядром напрямую
[18:02:00] <vasily.n@k..> что касается накладных расходов, по кодированию-декодировнию сообщений, то я подозреваю, они не сильно превысят того, что сейчас дает гуи
[18:02:26] <vasily.n@k..> в основном цп тратится на работу с сокетами и гуи
[18:04:23] <NegatiV> vasily.n@k..: сейчас большую часть нагрузки дает диспатчинг сообщений от ядра в главный поток
[18:04:28] Abram вошёл(а) в комнату
[18:04:54] Abram вышел(а) из комнаты
[18:06:27] <pavelvat> NegatiV: сейчас обработка сообщений ядра идёт в коде написанном на C++ и Qt(некоторые строки в исходном коде) - после того как они обработаны - управление передаётся следующим строкам в исходном коде - т.е. в этих строках идут операции с полученными до этого сообщениями ядра. Так разве ядро dc++ само по себе не является демоном?
[18:06:35] <NegatiV> pavelvat: у тебя при сборке под win программа не ругалась на отсутсвие bzip2.dll?
[18:07:18] <pavelvat> NegatiV: так у меня этот файл присутствовал.
[18:07:41] <NegatiV> pavelvat: если бы ядро само по себе хотябы подключалось к хабам и экспортировало некоторые функции во вне то да, оно было бы ядром
[18:08:24] <NegatiV> *бы демоном
[18:09:22] <pavelvat> NegatiV: поменять чуть-чуть архитектуру ядра чтобы оно стало демоном?
[18:09:42] Abram вошёл(а) в комнату
[18:09:58] Клёк вышел(а) из комнаты
[18:10:00] <NegatiV> pavelvat: по сути придется написать демон отдельно)
[18:10:19] <NegatiV> в ядро такие вещи не нужно добавлять, на то оно и ядро
[18:11:30] <pavelvat> зачем нафиг нужно такое ядро если оно не может работать как демон
[18:13:31] <pavelvat> NegatiV: а ты что сейчас сам пытаешся собрать клиент под Windows?
[18:14:46] <NegatiV> pavelvat: собрал даже, но тут проблемы с динамическими либами)
[18:15:39] <pavelvat> в тех сборках под Windows что выложены на googlecode квадратиков нет потому что я не включил в сборку каталог locales
[18:17:19] <NegatiV> pavelvat: я гляну сегодня чего там не так
[18:17:37] <pavelvat> NegatiV: так ведь в файле readme описано откуда что надо скачать - там указаны прямые ссылки в том числе и на bzip
[18:18:09] <NegatiV> pavelvat: тут не только с bzip2 проблемы)
[18:18:14] <NegatiV> еще с либами Qt
[18:18:17] <pavelvat> а что ещё?
[18:18:38] <NegatiV> не может некоторые символы найти в динамических либах
[18:18:56] <NegatiV> сейчас все почистил и собираю по новой
[18:19:29] <pavelvat> NegatiV: так скопируй либы отсюда http://eiskaltdc.googlecode.com/files/EiskaltDC%2B%2B-r1656_x86.zip
[18:20:00] <NegatiV> pavelvat: я так и сделаю если что)
[18:21:01] <pavelvat> NegatiV: там просто два варианта либ qt одни собраны в MSVC другие в mingw надо брать те что в подкаталоге qt/bin
[18:22:03] amatus вошёл(а) в комнату
[18:24:28] <pavelvat> vasily.n@k..: почему интересно если собирается с либами имеющими суффикс ".a"(т.е. статическими) при запуске бинарник требует динамические либы dll ?
[18:28:12] <vasily.n@k..> pavelvat: это особенность сборки под винду. у мс компилятора тоже для .dll есть всегда соответствующий .lib
[18:30:22] <vasily.n@k..> так же есть особенности платформы, например, под линаксом можно передать параметр -rdynamic и исполняемый модуль будет экспортировать свои символы ка и .so-файл
[18:30:56] <vasily.n@k..> под winnt такой штуки для .exe нету
[18:31:30] <pavelvat> vasily.n@k..: как так сделать чтобы либы Qt слинковались с бинарником? когда я прямо указал статические либы Qt с суффиксом ".a" и в соответствующем файле link.txt генерируемом cmake стояли именно либы с суффиксом ".a" результирующий бинарник получился зависимым от dll либ Qt.
[18:31:31] <vasily.n@k..> из-за чего приходится ядро линковать статически
[18:32:38] <vasily.n@k..> ну, а вопрос такой: у тебя именно статические либы, или это для .dll соответсвующие .a файлы?
[18:33:41] <vasily.n@k..> я вот не уверен, что они статические, размер не показатель. точно быть уверенным сможеш только если сам собереш статическую версию qt4
[18:34:06] <pavelvat> vasily.n@k..: это либы отсюда /home/pavel/.wine/drive_c/Qt/2010.04/qt/lib/, другие либы в каталоге bin - это dll
больше в поставке Qt никаких либ нет.
[18:36:03] <pavelvat> vasily.n@k..: т.е. авторы Qt не соблюдают правила суффиксов: статические это ".a", динамические это ".so" или не винде ".dll" ?
[18:36:20] <pavelvat> *на винде
[18:38:52] <pavelvat> vasily.n@k..: тогда какой смысл поставлять два варианта динамических либ Qt: те что в каталоге qt/bin имеют расширение "dll" те что в каталоге qt/lib имеют расширение "a"
[18:40:36] <vasily.n@k..> pavelvat: помоему это просто так принято, что dll в bin, .a, .lib в lib
[18:41:02] <vasily.n@k..> попробуй http://www.formortals.com/build-qt-static-small-microsoft-intel-gcc-compiler/
[18:41:23] <vasily.n@k..> тебе нужна именно mingw сборка
[18:41:36] <pavelvat> vasily.n@k..: зачем тогда два набора динамических либ?
[18:42:16] <vasily.n@k..> pavelvat: да там 2 набора .dll, одни собраны mingw, другие msvc ( для creator )
[18:45:13] <vasily.n@k..> pavelvat: http://www.prog.org.ru/topic_10517_0.html , надо обязательно собирать самому из исходников
[18:45:57] <pavelvat> vasily.n@k..: нет, я не про это. я говорю что и в qt/bin лежат готовые dll - для mingw, и в каталоге qt/lib тоже динамические либы хотя у них суффикс "a", потому что для сборки используются именно они и при этом они не линкуются внутрь бинарника, после сборки с либами из каталога qt/lib бинарник требует либы из каталога qt/bin
[18:47:42] <vasily.n@k..> повторяю, на winnt .dll идет в паре с .a/.lib, статических версий с qt-sdk не идет
[18:53:26] tehnick вошёл(а) в комнату
[18:53:49] tehnick вышел(а) из комнаты
[18:53:59] tehnick вошёл(а) в комнату
[18:54:13] <tehnick> Да что за хрень с доступом к конференции?..
[18:54:23] <pavelvat> vasily.n@k..: в винде принято обозначать статические либы как ".lib" ?
идёт в паре ".dll" и ".a" других расширений там нет. В то же время ".a" - означает статическая либа, т.е. те кто поставляют архив с Qt нарушают правила именования библиотек.
[18:55:45] <tehnick> NegatiV: поддерживаю идею 0xd34df00d поместить еще одну морду (плагин для личкрафтов) в дерево проекта. И пилить ее отдельно, лишь местами заимствуя код из Qt морды.
[18:56:25] <vasily.n@k..> .lib это для ms и др. компиляторов. может и нарушают
[18:56:54] <tehnick> [17:54:53] <pavelvat>  NegatiV: т.е. те программы которые так реализованы, например Transmission, работают неэффективно в сравнении с аналогами не демонами?
100500 раз уже объясняли... Это другой протокол! В дц _гораздо_ больше информации передается ядром в единицу времени.
[18:57:02] <NegatiV> tehnick: у меня пока нет времени для того чтобы 2.1.х пилить туда
[18:57:17] <pavelvat> vasily.n@k..: зачем вообще нужно два вида динамических либ - "dll" и "a" соответственно из каталогов qt/bin и qt/lib, почему нельзя линковать программу сразу с либами dll из каталога qt/bin, а нужны ещё какие-то переходные либы c суффиксом "a" ?
[18:59:29] <tehnick> [18:01:09] <NegatiV> vasily.n@k..: и это тоже, но основная причина для меня - неудовлетворительная производительность
Это еще мягко сказано. На слабых машинах гуй будет на 100% проц грузить все время... Да и на слабом роутере такой демон не запустишь...
[19:03:30] <NegatiV> pavelvat: кажись нашел причину "квадратиков"
[19:03:38] <NegatiV> сейчас соберу клиент и проверю
[19:04:25] <pavelvat> vasily.n@k..: кстати насчёт твоего совета что маленькие либы слинкованные статически улучшат производительность - тут остальные выразили сомнение по этому поводу. Может они правы?
[19:05:31] <pavelvat> NegatiV: и в чём же причина?
[19:06:08] <vasily.n@k..> pavelvat: вообщем .lib можно сгенерировать из .dll c помощью специальной утилиты "implib", да и без .lib/.a можно исопльзовать --enable-auto-import
единственное логичное объяснение генерации .a/.lib файлов -- только, чтобы избежать возможных конфликтов
[19:06:29] <NegatiV> pavelvat: кодек неверный используется скорее всего
[19:06:53] <pavelvat> NegatiV: а почему только на windows
[19:07:30] <NegatiV> pavelvat: кодек использовался для UTF-8 =)
[19:07:56] <NegatiV> сейчас поправил чтобы юзался мой макрос _q()
[19:08:04] <NegatiV> с ним вроде как проблем нет
[19:09:41] <pavelvat> vasily.n@k..: кстати удалось найти причину не чистой линковки при кросскомпиляции - надо было передать линковщику опцию --auto-import - те сборки что сейчас выложены на googlecode я собирал в Linux.
[19:10:32] <tehnick> [19:04:25] <pavelvat>  vasily.n@k..: кстати насчёт твоего совета что маленькие либы слинкованные статически улучшат производительность - тут остальные выразили сомнение по этому поводу. Может они правы?
Производительность программ, слинкованых статически и динамически практически не отличается. Слегка отличается лишь время запуска. И заметно отличается занимаемое место в оперативе.
[19:10:35] <vasily.n@k..> pavelvat: насчет линковки static vs. dinamic
прирост производительности при статической линковке однозначно есть, однако он сильно зависит от самой программы
я в инете находил информацию, как чел питон компилировал статически и получал выйгрыш до 25%, но там это зависело от
особенностей самого питона и компиляцией PIC-библиотеки
[19:11:06] <tehnick> Хы.
[19:11:17] <tehnick> Это плохой пример.
[19:11:56] <tehnick> Еще неизвестно кстати с какими флагами оно собиралось...
[19:12:13] <pavelvat> vasily.n@k..: то что сейчас на googlecode почти полностью слинковано статически кроме библиотек mingw, lua и Qt
[19:13:06] <pavelvat> никакой разницы с предыдущей сборкой где все либы были динамическими я не заметил
[19:13:26] <tehnick> pavelvat: а размер бинарника?
[19:14:02] <pavelvat> tehnick: был 5.5 MB сейчас около 8 MB кажется.
[19:14:13] <NegatiV> pavelvat: в моей сборке 16 dll-ок
[19:14:13] <vasily.n@k..> tehnick: размер бинарника при статической линковке обычно меньше, чем сумма при динамической
[19:14:43] <tehnick> vasily.n@k..: спасибо, капитан =)
[19:15:09] <vasily.n@k..> do itashimashte
[19:15:39] <pavelvat> NegatiV: у тебя 16 наверно потому что все линкуется динамически
[19:15:49] <NegatiV> pavelvat: да
[19:16:01] <tehnick> vasily.n@k..: не распарсил
[19:16:49] <tehnick> pavelvat: ты кстати коммит с изменениями так и не сделал...
[19:17:05] <pavelvat> никто не против если я переименую каталог win32 в windows ?
[19:17:37] <tehnick> pavelvat: я против. Зачем?
[19:18:02] <pavelvat> tehnick: в будущем может быть будет win64
[19:18:04] <tehnick> Для x86_64 ты все равно не соберешь...
[19:18:34] man_hattan вошёл(а) в комнату
[19:18:41] <tehnick> pavelvat: ну вот когда будет...
[19:21:03] <NegatiV> man_hattan: починил звуки
[19:21:17] <NegatiV> man_hattan: в настройках только опять их включи)
[19:21:23] <man_hattan> NegatiV: пасиба :)
[19:21:50] <man_hattan> сначала надо разобраться с udev, потом откомпилю.
[19:22:23] slepnoga вошёл(а) в комнату
[19:22:44] <pavelvat> vasily.n@k..: а ты в курсе что в списке поддерживаемых платформ Qt есть только MinGW 32-bit http://doc.qt.nokia.com/4.6/supported-platforms.html
[19:24:12] <vasily.n@k..> pavelvat: вообще выйгрыш производительности статической линковки заметен на коротких функциях, поэтому я рекомендовал линковать статически мелкие либы. также дллки могут быть расположены далеко на диске и поэтому замедлять загрузку исполняемого модуля
[19:24:55] <vasily.n@k..> >[22:22:39] <pavelvat> vasily.n@k..: а ты в курсе что в списке поддерживаемых платформ Qt есть только MinGW 32-bit
да я в курсе, можно и на msvc собрать
[19:25:03] <pavelvat> tehnick: "Для x86_64 ты все равно не соберешь..." - ну вообще-то в MSVC можно собрать для x86_64, может и x64-mingw тоже можно хоть официально и не поддерживается Qt 64-bit.
[19:26:20] <NegatiV> по-моему найти ось которая поддерживает x86_64 кривее чем windows очень тяжело =)
[19:27:58] 0xd34df00d вошёл(а) в комнату
[19:28:36] <pavelvat> NegatiV: вот поэтому и будут сборки только для 32-bit до тех пор пока Nokia не добавит официальную поддержку Qt для 64-bit.
[19:29:06] <NegatiV> pavelvat: я не против)
[19:29:21] <pavelvat> NegatiV: так удалось решить проблему с квадратиками?
[19:30:44] <NegatiV> pavelvat: r1676
[19:30:56] <NegatiV> pavelvat: у меня все починилось
[19:31:30] <pavelvat> vasily.n@k..: кстати в поставке Qt в нет спека для 64-bit ни под один компилятор для Windows, так что даже для MSVC поддержка 64-bit какая-то полуофициальная.
[19:33:02] <NegatiV> pavelvat: потестишь и отпишись
[19:33:11] NegatiV афк
[19:33:59] <pavelvat> NegatiV: так а что тестить-то если у тебя заработало?
[19:35:00] <NegatiV> pavelvat: подтверждение нужно) если я буду на каждый баг говорить УМВР, то так дело не пойдет)
[19:35:45] <man_hattan> CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
MINIUPNP_INCLUDE_DIR (ADVANCED)
   used as include directory in directory /var/tmp/portage/net-p2p/eiskaltdcpp-9999/work/eiskaltdcpp-9999/miniupnp
MINIUPNP_LIBRARY (ADVANCED)
    linked by target "miniupnp" in directory /var/tmp/portage/net-p2p/eiskaltdcpp-9999/work/eiskaltdcpp-9999/miniupnp
[19:36:04] <NegatiV> Nikoli: ^^
[19:36:18] <Nikoli> ?
[19:36:31] <Nikoli> что требуется проверить?
[19:36:37] <NegatiV> Nikoli: тут сборка под гентой не пашет
[19:36:44] <man_hattan> ды
[19:37:18] <NegatiV> man_hattan: в крайнем случае можешь собрать без upnp
[19:37:22] <Nikoli> мои патчи закомитили не полностью, рабочий ебилд выше давал: http://pub.nikoli.msk.ru/portage-overlay/net-p2p/eiskaltdcpp/eiskaltdcpp-9999.ebuild
[19:37:59] <man_hattan> так, я вас скачиваю с оверлея rion
[19:38:57] <Nikoli> man_hattan: из риона удалили лёд
[19:39:34] <man_hattan> Nikoli: и где вас искать теперь? только ебилды скачивать? Оо
[19:39:34] <tehnick> [18:37:18] <NegatiV> man_hattan: в крайнем случае можешь собрать без upnp
Неправильный совет. Надо заставлять читать файл INSTALL. Там же все написано. Например, про опцию -DLOCAL_MINIUPNP
[19:40:12] <Nikoli> man_hattan: могу дать доступ через rsync
[19:40:20] <man_hattan> господа...я emergem устанавливаю...
[19:40:56] <NegatiV> tehnick: я не знаю как там в генте все собирается
[19:40:59] <Nikoli> но в портежах обычно ебилд рабочий, сейчас скорее исключение из правила)
[19:41:01] <tehnick> [18:37:22] <Nikoli> мои патчи закомитили не полностью
Ты там по настойчивей... =)
[19:41:17] <man_hattan> Nikoli: да лан, так справлюсь :)
[19:42:15] <tehnick> Nikoli: для wt и miniupnp прогресс есть?
[19:42:58] <Nikoli> ещё не добавили в портежи
[19:47:07] tehnick вышел(а) из комнаты
[19:49:00] <pavelvat> Nikoli: зачем надо обязательно отдельный пакет для miniupnp в портежах когда есть опция  -DLOCAL_MINIUPNP ?
[19:49:20] <Nikoli> unix way
[19:49:51] <Nikoli> пихать все либы в пакет каждой проги - это винда будет
[19:50:23] <pavelvat> Nikoli: а как же тогда собираются остальные программы зависящие от miniupnp?
[19:50:36] <Nikoli> какие именно?
[19:51:04] <Nikoli> только transmission её использует, там _пока_ статически
[19:52:31] <pavelvat> Nikoli: ну вот и в EiskaltDC++ тоже будет пока статически.
[19:53:28] <Nikoli> pavelvat: так в моём ебилде так сейчас и сделано
[19:53:39] <Nikoli> но к релизу надо поправить
[19:55:21] <pavelvat> Nikoli: что значит надо, без этого что неразрешат добавить ebuild в portage?
[19:55:56] <Nikoli> надо = незачем делать низкокачественный ебилд
[19:56:08] <Nikoli> разрешить могут, но зачем это?
[19:59:12] <man_hattan> Nikoli: да, наверно исключение
[19:59:34] slepnoga вышел(а) из комнаты
[20:17:06] slepnoga вошёл(а) в комнату
[20:20:46] amfetamin вошёл(а) в комнату
[20:37:48] WiseLord вышел(а) из комнаты
[20:55:21] gray_graff вышел(а) из комнаты
[20:55:31] Клёк вошёл(а) в комнату
[21:16:59] pavelvat вышел(а) из комнаты
[21:25:32] nE0sIghT вышел(а) из комнаты
[21:26:01] slepnoga вышел(а) из комнаты
[21:34:48] gray_graff вошёл(а) в комнату
[21:34:59] pavelvat вошёл(а) в комнату
[21:36:27] <pavelvat> NegatiV: настройки -> шара -> основные -> просмотр шары в простом виде, в поле размер вместо единиц измерения квадратики.
[22:12:09] <pavelvat> NegatiV: и если закачку развернуть, а она ещё не началась то внутри прогресс бара квадратики.
исправились только сообщения от ядра в статусной строке.
[22:39:46] Клёк вышел(а) из комнаты
[22:58:43] WiseLord вошёл(а) в комнату
[23:13:24] man_hattan вышел(а) из комнаты
[23:21:18] SolarRay вошёл(а) в комнату
[23:49:00] Spy вышел(а) из комнаты
[23:55:55] <pavelvat> NegatiV: планируется включить DHT в релиз 2.1.0 ?