Re: [libgadu-devel] Segmentation fault w teście resolvera (było: Re: libgadu 1.12.0-rc1)
Cześć, On Sun, Jun 01, 2014 at 03:06:13PM +0200, Wojtek Kaniewski wrote: Co do samego błędu, na który trafił Dominik, to zmieniłem test resolvera tak, żeby w kółko tworzył wątek i po losowym czasie (rzędu milisekund) go ubijał. (...) Niestety po przekompilowaniu libgadu nową wersję gcc przestało się reprodukować :( Próbowałeś może uruchomić swój test pod valgrindem? Wygląda że moje gcc-4.6 optymalizuję wywołanie gg_resolver_cleaner(), (skoro buf == NULL, to *(buf) też będzie NULL), co generuje memleaka: ==4697== 2,234,368 bytes in 2,182 blocks are definitely lost in loss record 10 of 10 ==4697==at 0x4C2C730: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==4697==by 0x4E4BF08: gg_gethostbyname_real (resolver.c:119) ## buf = malloc(buf_len) ==4697==by 0x4E4C2E0: gg_resolver_run.constprop.0 (resolver.c:294) ==4697==by 0x4E4C38F: gg_resolver_pthread_thread (resolver.c:537) ==4697==by 0x58E4EB6: start_thread (in /lib64/libpthread-2.17.so) Kompilowanie libgadu z -fno-inline albo dodanie volatile do buf łata tego memleaka. Mógłby ktoś potwierdzić? Pozdr, Kuba. ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] libgadu 1.12.0-rc2
On Thu, Feb 06, 2014 at 07:59:39PM +0100, Marcin Owsiany wrote: W dniu 4 lutego 2014 21:36 użytkownik Jakub Zawadzki darkjames...@darkjames.pl napisał: On Tue, Feb 04, 2014 at 08:54:10PM +0100, Tomasz Wasilczyk wrote: Od siebie dodam jeszcze, że wersja rc2 ma przydatną zmianę w API: dodany symbol gg_is_gpl_compliant, który jest obecny wtedy i tylko wtedy, gdy biblioteka jest zgodna z GPL (tzn. nie jest skompilowana z openssl). Pidgin się tym przejmował już wcześniej - teraz i inne projekty GPL (Kadu?) mogą zapewnić GPL-spójność jednolinijkowym checkiem w configure. Przyznam się, że ja nigdy tego nie rozumiałem, ale czy samo sprawdzenie w configure jest wystarczające? W sensie, czy ktoś jak skompiluje program z GPLowym libgadu, potem zrekompiluje libgadu z openssl, to myślę, że taki komplet nie jest zgodny z GPL? Wydaje mi się że linker dynamiczny nie pozwoli uruchomić tego drugiego libgadu z programem, bo będzie brakowało wspomnianego symbolu. Mówisz o przypadku gdy w swoim programie masz: #ifdef HAVE_LIBGADU_GPL const int _libgadu_gpl_compilant = gg_is_gpl_compliant; #endif Gdzie HAVE_LIBGADU_GPL jest ustawione gdy w libgadu znajduje się symbol gg_is_gpl_compliant. Tomek, pisał tylko o sprawdzaniu w configure stąd moje pytanie. Kuba. ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Implementacja protokołu GG11 w libgadu
Cześć, On Thu, Sep 20, 2012 at 09:01:28PM +0200, Tomasz Wasilczyk wrote: (tzn. nie wiem, czy się da w libgadu wywołać jakiejś funkcji za jedną sekundę, żeby wyczyściła bufor). Zrobiłem to czyszczenie bufora w funkcji ping, ale klient może ją wywoływać nawet co 3.5 - 4 minuty (tak robi oryginalny klient), a my mamy na potwierdzenie 40 sekund. Z kolei jeżeli potwierdzimy za szybko (a jest taka możliwość, że ping wywoła się zaraz po odebraniu jakiegoś pakietu), to zostaniemy rozłączeni. Mam nadzieję, że opisałem to w miarę zrozumiale. Jakieś pomysły? Może dodatkowa funkcja podobna do ping, wywoływana przez klienta co 1s? Ale to chyba złamie API? Może da się to zaimplementować wykorzystując -timeout oraz -soft_timeout? (zgaduję, nie oglądałem kodu) Pozdr, Kuba. ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Implementacja protokołu GG11 w libgadu
On Sun, Sep 02, 2012 at 04:28:04PM +0200, Tomasz Wasilczyk wrote:
Napisałem prototyp wspomnianego bufora, do odczytywania pakietów
GG11 - nazwa robocza safe const buffer. Działa to w ten sposób, że
sobie odczytujemy z takiego bufora po kolei co chcemy, a on sam
pamięta w którym miejscu jest oraz czy nie wychodzimy poza bufor.
Poprawność odczytu można sprawdzić jednorazowo, na samym końcu. W
rezultacie, zamiast kodu, możemy uzyskać kod.
Co o tym myślicie? Mogę to spokojnie implementować i opierać obsługę
gg11 o to narzędzie? To mi bardzo ułatwi pracę i poprawi jakość kodu.
Ja raczej byłbym za stworzeniem funkcji podobnych do pack/unpack[1][2].
Przykładzik:
#v+
struct {
uint8_t magic1; /* 0x08 */
uint8_t magic2; /* 0x00 */
uint8_t magic3; /* 0x10 */
uint16_t seq;
uint8_t magic4; /* 0x1a */
char *data;
} pkt = { };
ptr = gg_unpack(ptr, len, CCCvCZ, pkt.magic1, pkt.magic2, pkt.magic3,
pkt.seq, pkt.magic4, pkt.data);
if (ptr == NULL || pkt.magic1 != 0x08 || pkt.magic2 != 0x0 || pkt.magic != 0x10
|| pkt.magic3 != 0x1a) {
free(pkt.data);
return -1;
}
ge-event.xml_event.data = pkt.data;
return gg_ack_gg11(gs, GG_ACK110_MPA, pkt.seq, ge);
#v-
(gg_unpack() zwraca wskaźnik na koniec przetworzonego bufora, aktualizując
*len,
lub zwraca NULL w przypadku błędu [np. wyjście za bufor]).
Nie upieram się zarówno przy zwracanej wartości (endptr może być parametrem, a
f. może zwracać 0/-1) ani
przy formacie CCCvCZ.
Możemy stosować dowolnie inne literki, lub nawet cyferki ('1' [uint8], '2'
[uint16], '4' [uint32]).
Dla zainteresowanych formaty w d-bus[3] i pythonie[4], modułu icq w ekg2[5]
Pozdr,
Kuba.
[1] http://perldoc.perl.org/functions/pack.html
[2] http://www.perlmonks.org/?node_id=224666
[3] http://dbus.freedesktop.org/doc/dbus-specification.html#type-system
[4] http://docs.python.org/library/struct.html#format-characters
[5] https://github.com/leafnode/ekg2/blob/master/plugins/icq/misc.c
(/icq_unpack_common)
___
libgadu-devel mailing list
libgadu-devel@lists.ziew.org
http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Implementacja protokołu GG11 w libgadu
On Mon, Sep 03, 2012 at 01:17:51AM +0200, Tomasz Wasilczyk wrote:
W dniu 2 września 2012 21:24 użytkownik Jakub Zawadzki
darkjames...@darkjames.pl napisał:
Ja raczej byłbym za stworzeniem funkcji podobnych do pack/unpack.
Przykładzik:
(...)
(gg_unpack() zwraca wskaźnik na koniec przetworzonego bufora, aktualizując
*len,
lub zwraca NULL w przypadku błędu [np. wyjście za bufor]).
Nie upieram się zarówno przy zwracanej wartości (endptr może być
parametrem, a f. może zwracać 0/-1) ani
przy formacie CCCvCZ.
Możemy stosować dowolnie inne literki, lub nawet cyferki ('1' [uint8], '2'
[uint16], '4' [uint32]).
Można to zrobić i tak, ale wtedy będzie ciężej obsługiwać pakiety, w
których nie ma z góry ustalonej struktury. Na przykład w pakietach
informacyjnych o konferencji, czasem pojawia się blok z jego nazwą, a
czasem nie - jest to zależne od wartości bajtu tuż przed nim.
W takim przypadku trzeba by było parsować osobno część pakietu przed
opcjonalnym blokiem, blok i część po.
Tak, nie widzę z tym problemu, dlatego unpack() zwraca wskaźnik na
koniec przetworzonego bufora.
A w ogóle, to mam wrażenie, że
wszystkie te pakiety składają się z takich bloków, które to być może
mogą być w dowolnej kolejności.
Łatwo ustalić czy jest to TLV, spróbuj wysłać klientowi bloki w innej
kolejności i sprawdź jak się zachowa ;-)
Przy takich bardziej skomplikowanych pakietach ich struktura nie
będzie wyraźnie widoczna w kodzie źródłowym. No i przy wielu
wywołaniach gg_unpack nie unikniemy używania goto.
Dlaczego? Jak dla mnie z obu rozwiązan można korzystać identycznie.
[gg_unpack() nic nie robi gdy buf == NULL]
Ty wywołujesz gg_scb_is_valid(), u mnie zamiast tego
trzeba sprawdzić czy buf != NULL + dodatkowe magiczne wartości (lub
jedna flage is_invalid).
is_invalid |= (magic != 0xdead);
is_invalid |= (magic |= 0xbeaf);
...
Moim zdaniem pierwsze rozwiązanie [...]
Twoje rozwiązanie ma też lepszą kontrolę typów, w moim pomylisz się w
literce i pozamiatane.
Pozdr,
Kuba.
___
libgadu-devel mailing list
libgadu-devel@lists.ziew.org
http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] [OT] gg_send_packet() a EAGAIN
On Thu, Dec 29, 2011 at 12:32:04PM +0100, Marcin Mirosław wrote: Przeglądając archiwum listy przez www, również nie widzę żadnych wiadomości nowszych niż z 16 grudnia. Czy z tą listą nie jest coś nie tak? Nie mogę wypowiadać się o liście, aczkolwiek wydaje się, że działa. Zgadzam się, lista działa, gorzej że archiwum nie. Pozdr, Kuba. ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] gg_send_packet() a EAGAIN
On Wed, Dec 28, 2011 at 01:28:12PM +0100, Jakub Zawadzki wrote: Spróbuj z r1240 (...) Oczywiście chodziło mi o r1242, zły dzień ;| ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Przeterminowane funkcje protokołu
Cześć, On Mon, Nov 07, 2011 at 01:13:22PM +0100, Jakub Zawadzki wrote: Jak dla mnie jedymi powodami do zmiany byłoby: - Podobnie jak GG Network S.A. rezygnujemy z obsługi starszych protokołów i zostawiamy tylko 0x2e (GG 8.0, 8.5?). Jak ktoś bardzo potrzebuję obsługę starszego protokołu to musi ściągnąć starszą wersje libgadu FYI, libgadu po r1236 nie obsługuje gg 7.x Została jeszcze kwestia gg_userlist_request() :) Pozdr. ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Nie działająca klawiatura w ekg(trunk), od libgadu rev. 1199
Witaj, On Sun, Oct 30, 2011 at 06:54:00PM +0100, Marcin Mirosław wrote: od rewizji 1199 włącznie, nie mogę używać klawiatury w ekg, objaw: całkowity brak reakcji. Mógłbyś przetestować r1203? Pozdr. ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Dokumentacja protokołu / Multilogowanie
On Fri, Aug 05, 2011 at 03:03:14PM +0200, Kaworu wrote: Nie dostajemy. Ale jakbyś dopadł jakoś ID własnej sesji to pewnie byś mógł ją zamknąć tym sposobem. ;P Czyli aby poprawnie zamknąć połączenie z serwerem gg: 1/ Otwieramy kolejną sesję. 2/ W drugiej sesji otrzymujemy idka pierwszej sesji, w pierwszej otrzymujemy idka drugiej. 3/ Wymieniamy idki /najlepiej przez GG_SEND_MSG, oczywiście szyfrowane!/ 4/ Losowo wybieramy sesje i najpierw zamykamy inną sesje, a potem swoją. /me idzie pisać łatkę do libgadu! *g* Pozdr, Jakub ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Neverending test...
On Wed, Jun 15, 2011 at 11:28:45PM +0200, Wojtek Kaniewski wrote: 2) jak zrobić żeby zrzut stosu dostawał się do logu? Przekierować stderr do loga :) 3) jak zrobić żeby przy podobnych błędach build nie zwisał w nieskończoność? Zobacz, czy łata w załączniku pomoże. signal(SIGQUIT, cleanup); + signal(SIGSEGV, cleanup); signal(SIGALRM, sigalrm); #v+ Test 14 of 162...*** glibc detected *** /home/mowsiany/Desktop/debian/devel/libgadu/libgadu/test/automatic/.libs/lt-connect: double free or corruption (fasttop): 0x01f9f3b0 *** #v- Jak dla mnie to jest SIGABORT wywołany przez MALLOC_CHECK_=3 (domyślne w nowszych glibach) czyli bardziej: + signal(SIGABORT, cleanup); Pozdr. ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Propozycja zmian w obsłudze przesyłania formatowanych wiadomości HTML
On Wed, May 11, 2011 at 04:05:02PM +0200, Bartosz Brachaczek wrote: Czy w ogóle wszystkim to pasuje. Mnie pasuje jeśli klient nieznające htmla (ekg, ekg2) będą dalej działac. 1. Stripować nieprzewidzanie przez protokół znaczniki HTML w odebranych wiadomościach (np. script zamieniać na lt;scriptgt;). script jest prawidłowym znacznikiem HTML, opisanym między innymi w [1]. [1] http://www.w3.org/TR/html4/interact/scripts.html#h-18.2.1 Pozdr. ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Wiadomości przychodzące i zamiana HTML-a na czysty tekst
On Wed, May 11, 2011 at 02:57:52PM +0200, Bartosz Brachaczek wrote: Łata, którą załączam, zdaje się rozwiązywać problem i moje testowanie jej w rozmowie z klientem libgadu (Kadu), oryginalnym klientem GG 10.5, botem Infobot oraz botem Allegro nie wykazało żadnych problemów. Racja, skoro korzystamy z odebranych formatek (a nie przerabiamy ich z htmla), to powinniśmy też korzystać z orygianlnej wiadomości. Chyba, że lepszym rozwiązaniem byłoby właśnie konwertowanie, Wojtek? Pozdr. ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Wiadomości w czystym tekście i adresy URL
Cześć, On Wed, Apr 20, 2011 at 08:33:19PM +0200, Tomasz Wasilczyk wrote: Mogę podesłać wersję patcha bez funkcji pomocniczej, ale to jest moim zdaniem za dużo copy-paste. Istniejąca funkcja gg_append() jest bardzo podobna do Twojej funkcji pomocniczej, tylko nie kończy ciągu \0 (zamiast strncpy() jest memcpy()). Jakbyś mógł przerobić na łatkę aby z niej korzystała to by było super. Pozdr. ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] libgadu 1.10 i problemy z wysyłaniem obrazków
On Sun, Mar 06, 2011 at 10:57:50PM +0100, Bartosz Brachaczek wrote: Problemy objawiają się tym, że zazwyczaj przy próbie wysłania obrazka Kadu się rozłącza, a rozmówca dostaje informację o przychodzącym obrazku, lecz ten nigdy do niego faktycznie nie dochodzi. Załączam archiwum z kilkoma logami. Nazwy plików, mam nadzieję, same się wyjaśniają. W logach nie bardzo wiadomo czemu rozłącza, jest tylko: // gg_watch_fd_connected() received a message ack ** gg_login(0x90a97ac: [uin=11910939, async=1, ...]); ** gg_connect(91.214.237.2, 8074, 1); // gg_connect() connect() in progress timeout? Możecie dorobić logowanie czasów w logach? (przynajmniej do dziesiątych sekundy :) Pozdr. ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] RFC: Usunięcie kodu DCC6
On Tue, Feb 15, 2011 at 12:10:03AM +0100, Rafał Malinowski wrote: Z okazji dzisiejszego odkrycie, że wspieranie DCC6 jest niemożliwe (nie otrzymujemy już informacji o wersji protokołu wspieranego przez nasze kontakty), Jak ustawisz protokół na starszy (np. 0x2a) to dostajesz te informacje. Pozdr. ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Wyciek informacji przez dziury w strukturach?
On Wed, Dec 01, 2010 at 06:55:06PM -0800, Marcin Owsiany wrote:
http://thread.gmane.org/gmane.linux.kernel/1066711
Gdy to czytałem, przyszło mi na myśl libgadu, które co prawda nie
kopiuje niczego z pamięci jądra do użytkownika, ale wysyła dane przez
sieć.
Jesli dobrze rozumiem to jest problem w ktorym przy inicjalizacji
struktury gcc niezeruje danych ktore zostaly uzyte do jej wyrownania?
Jesli tak, to u nas problem nie wystepuje, bo
a/ Nie robimy struct foo f = { .bar = 1, .foobar = 2 };
tylko:
struct foo f;
memset(f, 0, sizeof(f)); /* prawie zawsze */
f.bar = 1;
f.foobar = 2;
b/ wszystkie (chociaz glowy sobie nie dam uciac) struktury
ktore wysylamy maja atrybut 'packed' czyli sa wyrownywane do 1 bajta.
(a pol bitowych nie mamy).
Gdybym chciał sam sprawdzić w kodzie czy coś takiego (albo podobnego) ma
miejsce to pewnie bym się zgubił, ale może ktoś po prostu wie? :-)
___
libgadu-devel mailing list
libgadu-devel@lists.ziew.org
http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Invitation to connect on LinkedIn
On Sat, Aug 14, 2010 at 12:40:46PM -0700, Krzysztof Klinikowski wrote: LinkedIn libgadu, I'd like to add you to my professional network on LinkedIn. Teraz /me tylko czeka na zaproszenie libgadu do facebooka. Ciekawe jakie inne osoby libgadu może znać... ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] libgadu 1.9.0
On Mon, May 10, 2010 at 03:12:04PM +0100, Marcin Owsiany wrote: Hm, czy nie powinna być podbita wersja API? Np. ze względu na dodanie gg_typing_notification(). gg_typing_notification() jest trunku a nie w 1.9. Pozdrawiam. ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Patch: Fixed uninitialized variable in notify60
Hi, On Tue, Apr 27, 2010 at 11:50:42PM +0200, Jan Kaluza wrote: I'm sending simple patch which fixes uninitialized variables in three places in event.c. I've just checked current stable version and it seems the bug is still there. The whole memory of structure event_t is initialized to 0 in calloc. Can you show content of ev at frame #7? I mean this one: #7 0x7fc9939be8c4 in ggp_callback_recv (_gc=value optimized out, fd=value optimized out, cond=value optimized out) at /home/mati/repositories/jaunty/pidgin-2.6.6/./libpurple/protocols/gg/gg.c:1584 gc = (PurpleConnection *) 0x1009fe0 ev = (struct gg_event *) 0x1009f10 Cheers. ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Patch: Fixed uninitialized variable in notify60
On Wed, Apr 28, 2010 at 07:44:26AM +0200, Jakub Zawadzki wrote:
On Tue, Apr 27, 2010 at 11:50:42PM +0200, Jan Kaluza wrote:
I'm sending simple patch which fixes uninitialized variables in three
places in event.c. I've just checked current stable version and it
seems the bug is still there.
The whole memory of structure event_t is initialized to 0 in calloc.
Sorry, this memory is allocated by malloc ;/
#7 0x7fc9939be8c4 in ggp_callback_recv (_gc=value optimized out,
fd=value optimized out, cond=value optimized out) at
/home/mati/repositories/jaunty/pidgin-2.6.6/./libpurple/protocols/gg/gg.c:1584
gc = (PurpleConnection *) 0x1009fe0
ev = (struct gg_event *) 0x1009f10
Pidgin code:
#v+
case GG_EVENT_NOTIFY60:
purple_debug_info(gg,
notify60_pre: (%d) status=%d; version=%d; descr=%s\n,
ev-event.notify60-uin, ev-event.notify60-status,
ev-event.notify60-version,
ev-event.notify60-descr ? ev-event.notify60-descr :
(null));
for (i = 0; ev-event.notify60[i].uin; i++) {
purple_debug_info(gg,
notify60: (%d) status=%d; version=%d; descr=%s\n,
ev-event.notify60[i].uin,
ev-event.notify60[i].status,
ev-event.notify60[i].version,
ev-event.notify60[i].descr ?
ev-event.notify60[i].descr : (null));
/* ... */
}
#v-
I don't see a reason for debug code outside loop.
End of e-event.notify60 array is terminated by item with uin 0,
I can't find information if other fields of gg_notify_reply60 should be
initialized or no.
IMHO If we want to proper fix case like this, we need to initialize all fields
to \0
(and not only cases where there is only one item, but also if there're more
items)
(In pidgin code at least: ev-event.notify60-status
ev-event.notify60-version is affected)
Anyway, GG_NOTIFY_REPLY60 with 0 items? HUH!?
___
libgadu-devel mailing list
libgadu-devel@lists.ziew.org
http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] GG10 i flamaster
On Mon, Apr 26, 2010 at 11:05:38AM +0200, Tomek Nagisa wrote: W sumie to już od czasów GG8 lista kontaktów nie jest dzielona przy eksporcie/imporcie, tylko wysyłana as is. Nie ma już limitów na ilość bajtów w jednym pakiecie? libgadu ZTCW ma limit 65k na pojedynczy pakiet. 65k znaków na userlistę to IMHO nie jest tak dużo. Dzięki kompresji ten limit jest pewnie kilka razy większy, ale libgadu nie obsługuje -lz :) ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] GG10 i flamaster i inne
On Mon, Apr 26, 2010 at 02:31:28PM +0200, Tomek Nagisa wrote: A to da się wysłać listę XML'em bez kompresji? Nie sprawdzałem, przyznaję się. Ale mam dziwne wrażenie, że może się nie dać. Hint: Libgadu nie obsługuję list XML-owych. Tj. - taka lista nie będzie czytelna dla innych klientów. To może warto sprawdzać czy ciąg jest XML-owy, i jeśli tak to nie dekompresować go? ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Pakiety 0x44 i 0x46
On Wed, Feb 17, 2010 at 11:50:15AM +0100, Piotr Latosiński wrote: Zatem to są moje obserwacje. Dodałem Ciebie do autorów i commitnąłem w r902 :) Jeszcze raz dzięki. Pozdrawiam. ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] [patch] dcc7 - use external ip and port
On Tue, Dec 22, 2009 at 01:10:04AM +0100, Bart. wrote:
Nastepna latka z opisem pakietow:
http://starowa.one.pl/~uzi/kadu/libgadu-dcc7-relay-packets.patch
Dobrą praktyką jest zalączać patcha w liście - wtedy łatwiej go obejrzeć oraz
skomentować :)
Index: include/libgadu.h.in
Wojtek chciał, żeby rzeczy protokołowe, które nie są potrzebne aplikacji
były w pliku protocol.h - Mógłbyś je przenieść?
+struct gg_dcc7_relay_reply {
+ uint32_t magic; /** 0x0b **/
+ uint32_t len; /** d#ugo## ca#ego pakietu **/
+ uint32_t rcount;/** ilo## serwerów **/
+ struct {
+ uint32_t ip;/** adres ip serwera **/
+ uint16_t port; /** port serwera **/
+ uint8_t family; /** rodzina adresów (na ko#cu?!) AF_INET=2 */
+ } proxies[rcount];
+} GG_PACKED;
Erm, kompiluję Ci się deklaracja tej strukturki?
I wydaję mi się, że proxies też powinny być GG_PACKED.
___
libgadu-devel mailing list
libgadu-devel@lists.ziew.org
http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] [kzu...@netglob.com.pl: [OT] GG.]
System została zastąpiona przez Linuksa. Scentralizowana i przestarzała architektura została wyparta przez rozproszone systemy kontrolowane przez Linuksa. Nowy serwer ruszył w dniu 26 września i zastąpił działający stary serwer, który pracował od samego początku istnienia Gadu-Gadu, czyli od 2000 roku. Pewnie korzystają z USG (http://toxygen.net/usg/) :) ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Rozmowa poprzez WidgetGG
On Sun, Sep 20, 2009 at 02:05:08PM +0200, Piotr Latosiński wrote: Zdaje się że oba pakiety się ścigają, więc nie zawsze jako pierwszy dojdzie STATUS80. Ale jeśli tak się stanie, NoweGG w oknie rozmowy wyświetla 'Widget' zamiast numerka. Innych zmian nie zauważyłem. Zgłosiłeś buga t...@gadu-gadu.pl? :) Pozdrawiam. ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Numery sekwencyjne zapytań do ka talogu publicznego
On Thu, Sep 17, 2009 at 04:10:00PM +0200, Mietek Bąk wrote: Mam problem z obsługą katalogu publicznego. Numery sekwencyjne zapytań wysyłanych w tej samej sekundzie są identyczne. Tak chyba nie powinno być? Tak chyba było w oryginalnym kliencie. Zawsze możesz użyć gg_pubdir50_seq_set() do zmiany numeru sekwencyjnego. ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Problem z połączeniem (libga du 1.8.2)
Witam, On Sat, Sep 05, 2009 at 12:59:03AM +0200, Mietek Bąk wrote: // gg_watch_fd() GG_STATE_CONNECTING_HUB // gg_watch_fd() connected to hub, sending query = -BEGIN-HTTP-QUERY- GET /appsvc/appmsg4.asp?fmnumber=XXXversion=7%2c+7%2c+0%2c+3351fmt=2lastmsg=0 HTTP/1.0 Host: appmsg.gadu-gadu.pl User-Agent: Mozilla/4.7 [en] (Win98; I) Pragma: no-cache = -END-HTTP-QUERY- ** gg_event_free(0x6c5950); ** gg_watch_fd(0x6c50f0); // gg_watch_fd() GG_STATE_READING_DATA // gg_read_line() error on read (errno=11, Resource temporarily unavailable) To znaczy, że libgadu chciało przeczytać coś z socketa, na którym jeszcze nic nie ma, i należy spróbować później. Nie znam Twojego kodu, ale ogólnie jak korzystasz z jakiegoś monitorowania zdarzeń na socketach (epoll(), poll(), select()) I wywołujesz gg_watch_fd() dopiero gdy zdarzenie odczytu nastąpiło, to nie powinno być problemu. Jeśli tak robisz, i po prostu w pewnym momencie przestało działać, mógłbyś uruchomić test connect i przesłać report.html? (Chyba nie mamy lepszego testa?) // gg_watch_fd() received http header () // gg_watch_fd() invalid http reply, connection failed Btw. wczoraj Wojtek pisał: quote Boże, jak beznadziejnie głupia jest obsługa odpowiedzi huba w libgadu. normalnie cały ten kod jest do wywalenia :( /quote (-; Pozdrawiam. ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
[libgadu-devel] FWD: Nowości w protokole GG8
Cześć,
forwarduje e-maila z opisem nowości w GG_XML_ACTION oraz jak działają opisy
graficzne.
Autorowi (Cc) wielkie dzięki :)
// Maska 0x4000 jest ustawiona prawdopodobnie wtedy gdy jest ustawiony opis:
http://lists.ziew.org/pipermail/libgadu-devel/2009-May/000440.html
// No i dobrze jest się zapisać na libgadu-devel
(http://lists.ziew.org/mailman/listinfo/libgadu-devel)
- Forwarded message from Biuro Obsługi Klienta Koko Software bok (at)
kokosoftware.pl -
From: Biuro Obsługi Klienta Koko Software bok (at) kokosoftware.pl
Date: Wed, 1 Jul 2009 19:57:33 +0200
Message-ID: 001a01c9fa75$6981c640$01000...@laptop
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
Subject: Nowości w protokole GG8
Witam serdecznie!
Jako, że na stonie toxygen.net nie ma podanego adresu, na jaki można zgłaszać
nowości w porotokole GG, postanowiłem przekazac je Tobie.
Dodatkowe 2 przykładowe wiadomości otrzymywane w pakiecie GG_XML_ACTION.
//Zmiana avatara przez znajomego
events
event id=13095886332244853765
type28/type
sender3732/sender
time1245843651/time
body/body
bodyXML
smallAvatarhttp://media6.mojageneracja.pl/oiytwyurtp/avatar/ueuivsp.jpg/smallAvatar
/bodyXML
/event
/events
//Nowy wpis na blogu znajomego
events
event id=13095868082578904423
type7/type
sender3732/sender
time1245847900/time
bodyXML
serviceIDMG/serviceID
msg![CDATA[DodaĹ, wpis do bloga]]/msg
link
isLogin=1http://www.mojageneracja.pl/7233258/blog/485414a42215b91fd7/0/link
creationTime1245847900/creationTime
/bodyXML
/event
/events
type - rodzaj zdarzenia:
28 - zmiana avatara
7 - nowy wpis na blogu
sender - nr użytkownika którego dotyczy zdarzenie
time - timestamp
Nowe flagi w polu features w strukturze gg_login80 .
0x0010 - Obsługa nowych stanów DND i FFC
0x0020 - Obsługa opisów graficznych (http://www.gadudodatki.pl/opisygraficzne)
Nowy stan
0x4104 - Osoboa ma ustawiony opis graficzny (mozliwe ze z jakimis flagami)
Pakiet w HEX powiadamiajacy o zmianie opisu, na opis Graficzny
3700 2500 2704 0441 3700 FF 64 01001000
0900 4B 72 6F 6C 20 50 6F 70 75
typ len uin stat flagiIP port img u2 unkown3
length K r o l P o p u
struct gg_notify_reply80 {
int uin; /* numer Gadu-Gadu kontaktu */
int status; /* status */
int flags; /* flagi (nieznane przeznaczenie) */
int remote_ip; /* adres IP bezpośrednich połączeń (nieużywane) */
short remote_port; /* port bezpośrednich połączeń (nieużywane) */
char image_size; /* maksymalny rozmiar obrazków w KB */
char unknown2; /* 0x00 */
int unknown3; /* 0x */
int description_size; /* rozmiar opisu */
char description[]; /* opis (nie musi wystąpić, bez \0) */
};
Pozdrawiam
Adrian Warecki
www.kokosoftware.pl
GG: 3732
Tlen: kokosoft
- End forwarded message -
___
libgadu-devel mailing list
libgadu-devel@lists.ziew.org
http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Transfery plików a opis protoko łu
Cześć, On Mon, Jun 01, 2009 at 05:08:50PM +0200, piknew wrote: Cześć, mam pytanie - jaii pakiet otrzyma strona wywoływana po nadaniu przez stronę wysyłają pakietu GG_DCC7_NEW? Inaczej: na jakie zdarzenie (pakiet) strona wywoływana ma zareagować, by odpowiedzieć pakietem GG_DCC7_ACCEPT lub GG_DCC7_REJECT? Strona wywoływana dostaje GG_DCC7_NEW taki sam jaki wysłała strona wywołująca. ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Transfery plików a opis protoko łu
On Sun, May 31, 2009 at 10:01:02AM +0200, Daniel Zaborowski wrote: Dzięki za uaktualnienie protokołu przesyłania plików! Mam dodatkowe pytania. 1. Czy przy połączeniach typu P2P, i po udanym połączeniu na adres podany w DCCInfo, należy wysłać jedynie ID połączenia? Pytam, bo w momencie gdy je wysyłam do GG8, połączenie zostaje zerwane. Z tego co wysniffowalem i o ile dobrze pamietam kod w libgadu to tak. 2. Skąd klient GG wie, czy zaoferować połączenie typu P2P czy połączenie przez serwer? W którym momencie i jak to jest ustalane? W starym protokole można było coś wywnioskować po adresach IP otrzymywanych od serwera w pakietach statusu, ale teraz ich już nie ma. Oryginalny klient zawsze probuje sie laczyc z adresem ktory dostaje w GG_DCC_INFO (nie wiem co z fake adresami, albo adresami ktore sa nierutowalne) Zabilem ruting po lo: (route add mojip mask 255.255.255.255 jakis_blackhole) I po 7s zadna ze stron sie nie polaczyla (bo nie mogla :)) zaczela nawiazywac polaczenie przez serwer. ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Transfery plików a opis protoko łu
On Sun, May 31, 2009 at 12:06:51PM +0200, Daniel Zaborowski wrote: Generalnie mam tylko jedno pytanie jeszcze odnośnie transferów (przynajmniej póki co). W opisie transferów przez serwer jest coś takiego jak numerek TBD. Jak rozumiem TBD oznacza tutaj - To Be Determined? Czy chodzi o coś innego? To Be Done :) U mnie ciągle powtarzały się numerki: 9358 (wysyłający) i 6962 (odbierający) ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Transfery plik?w a opis protoko?u
On Sun, May 31, 2009 at 04:43:20PM +0200, Daniel Zaborowski wrote: Eh jednak jeszcze stan??em na jednej rzeczy. Po??czenia P2P dzia?aj? bez zarzutu. Gorzej jest z tymi transferami kt?re lec? przez serwer. Powiedzmy ?e nie uda?o si? po??czy? stron? po przez P2P. Strona wysy?aj?ca plik po 7s przysy?a nowy pakiet DCCInfo m?wi?cy o konieczno?ci po??czenia z serwerem. Pobra?em odpowiednie serwery proxy (??cz?c si? z relay.gadu-gadu.pl) Lepiej lacz sie z 91.197.13.102 Mam te? dodatkowe pytanie. Czy w momencie otrzymania nowego pakietu DCCInfo, powinienem odsy?a? r?wnie? nowy pakiet DCCInfo z flag? GG_DCC7_TYPE_SERVER? Czy ju? nie trzeba tego robi?? (pr?bowa?em te? tego, ale nie pomog?o). I jeszcze kolejna kwestia, strona wysy?aj?ca plik, i wysy?aj?ca drugi raz pakiet DCCInfo powinna po??czy? si? z serwerem Proxy... no w?a?nie. Kiedy? w/g mnie wysylasz nowe GG_DCC7_INFO wtedy kiedy sie nie polaczysz przez p2p. Z powodu tego ze timeout po obu stronach jest taki sam (7s) - te pakiety powinny przyjsc mniej wiecej w tym samym momencie. Moje srodowisko testowe jest ubogie wiec nie wiem jak to dokladnie dziala :) IMHO dostajesz GG_DCC7_INFO, laczysz sie. Aby byc pewnym jest potrzebny resercz ze snifferem/ nauka obslugi Gorta [1] [1] http://lists.ziew.org/pipermail/libgadu-devel/2008-July/000306.html ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Transfery plik?w a opis protoko?u
On Sun, May 31, 2009 at 08:53:47PM +0200, Daniel Zaborowski wrote:
Juz sie z tym uporalem (z pomoca znajomego). Mylnie jest zadeklarowana
struktura:
struct gg_dcc7_welcome_server {
long long id; /* identyfikator polaczenia */
short dunno1; /* 06 0a */
short dunno2; /* 00 00 */
};
Powinno byc:
struct gg_dcc7_welcome_server {
short dunno1;/* BE BA */
short dunno2;/* DE C0 */
long long id; /* identyfikator polaczenia */
};
...i wszystko dziala bez zarzutu :)
Racja, /me pac dj. Dzięki :)
___
libgadu-devel mailing list
libgadu-devel@lists.ziew.org
http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Transfery plików a opis protoko łu
On Wed, May 27, 2009 at 10:59:36PM +0200, Daniel Zaborowski wrote: Chciałbym zwrócić uwagę, że opis protokołu transferu plików opisany na http://toxygen.net/libgadu/protocol/ jest nieprawidłowy. Po pierwsze, dotyczy on w sumie (w dużej części) protokołu 6.0. Ponad to, są opisane połączenia bezpośrednie - lecz ich opis nie jest już do końca aktualny, o ile wiem, zmienił się handshake przy połączeniach P2P. Nowe GG 8.0 oferuję też transfer plików bez połączeń bezpośrednich (przez serwer). Protokół nawet nie dotyka tego zagadnienia. Czy jest możliwe, aby ktoś zaktualizował protokół. Uaktualniłem opis protokołu, jak coś jest niejasne to pisz. PS: Testowałem jak działa transfer Nowe Gadu-Gadu == Nowe Gadu-Gadu na tej samej maszynie - w innych warunkach może działać inaczej (ja nie mam możliwości innych testów) Sniffuj, jak coś się nie będzie zgadzać z opisem/przykładami daj znać. ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] GG8 - Logowanie
On Thu, May 28, 2009 at 05:47:35PM +0200, wit...@ravir.pl wrote:
Witam ponownie.
Korzystając z funkcji, które znalazłem w LibGadu napisałem funkcję do
tworzenia SHA i nadal mam problem.
Wciąż nie zwraca mi się taki hash, jaki wysłało NoweGG, przez co mnie
nie loguje.
int main(void){
SHA_CTX ctx;
char password[] = dupawolowa1;
unsigned int seed = 1622137249;
unsigned char result[20];
char wynik[40];
Tutaj lepiej: char wynik[41]
SHA1_Init(ctx);
SHA1_Update(ctx, (const unsigned char*) password, strlen(password));
SHA1_Update(ctx, (uint8_t*) seed, sizeof(seed));
SHA1_Final(result, ctx);
std::cout result \n;
for (int i = 0; i 20; i++)
sprintf(wynik[i*2], %02x, result[i]);
std::cout wynik \n;
system(pause);
return 0;
}
Hash jaki ono wysłało był taki:
3B 09 96 E4 C8 4D 51 CB 37 4F 85 B5 A9 3C 1E 56 B1 3F D4 55
a ja otrzymuje jakiś od D6 1A ... Co źle robie?
Ja dla dupawolowa1 oraz seeda 1622137249 otrzymuja
a33c7534778a23b52fc8df329b9c84165f1b1df7 (AMD64/Linux)
Kod wygląda ok.
___
libgadu-devel mailing list
libgadu-devel@lists.ziew.org
http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] nowe statusy w gg80
On Wed, May 27, 2009 at 11:11:54PM +0200, Bartłomiej Zimoń wrote: OK ale jakies wnioski? Zmienily sie wartosci wszystkich typow stanow z opisem. Do wszystkich stanow starych trzeba dodac 0x4002 zeby byly z opisem Nowe stany maja wartosci: - FFC pogadaj ze mna 0x0017 - DND nie przeszkadzac 0x0021 zeby te stany byly opisowe nalezy dodac wartosc 0x4001 #define GG_STATUS_DESCR_MASK 0x4000 ? Btw. dzięki za wiadomość że znowu ulepszyli protokół :) ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] GG_ACK_MBOXFULL
On Fri, Apr 24, 2009 at 03:29:01PM +0200, Mietek Bąk wrote: Mam wrażenie, że flaga GG_ACK_MBOXFULL nie jest ustawiana wtedy, kiedy powinna. Według moich obserwacji pojemność skrzynki GG wynosi 21 wiadomości; kolejne wiadomości giną w eterze, Wysłałem do mojego testowego konta 40 wiadomości, połączyłem się i wszystkie doszły. jednakże libgadu ciągle informuje, że GG_ACK_DELIVERED. Czy wynika to z ograniczeń protokołu, czy też jest to błąd w libgadu? Raczej błąd serwerów (lub specjalnie ukrywają informację o przepełnieniu skrzynki) libgadu nic nie zmienia w pakietach wysyłanych przez serwer; Kiedyś działało :) ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Niekonczacy sie watek w libgadu?
Hej, On Sat, Mar 21, 2009 at 02:45:25PM +0100, rozt...@interia.pl wrote: A dalo by sie przemycic cos w stylu zalaczonej laty do trunka? Psujesz ABI, aplikację robią memset(l, 0, sizeof(struct gg_login_params)), na maszynach 64bitowych, gdy updejtniesz libgadu, a aplikacji nie zrekompilujesz, to wtedy memset nie wyzeruje twojego wskaźnika. Naszczęście nic strasznego się nie stanie. (bo pewnie nikt nie ustala p-resolver na GG_RESOLVER_CUSTOM). Można zaaplikować twoją łatkę i zwiększyć wersję API bibloteki. Innym rozwiązaniem jest poświęcenie jednego int dummy na int login_version, (albo login_size). Dzięki temu mielibyśmy kontrolę która część struktury jest zainicjowana na pewno (a nie śmieciami ze stosu), a która nie i nie należy jej używać. Btw. Wojtek (bardzo) nie lubi tej strukturki, i ZTCP nie chciał jej rozbudowywać. ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Protokół GG 7.7 i wysyłani e obrazków do GG 8.0
On Thu, Feb 12, 2009 at 01:59:10PM +0100, Daniel Zaborowski wrote: AQQ/Tlen (działa na libgadu) ---wysyłanie obrazka --- GG 7.7 -- działa AQQ/Tlen (działa na libgadu) ---wysyłanie obrazka --- GG 8.0 -- nie działa GG7.7 ---wysyłanie obrazka --- GG 8.0 -- działa Co ciekawe, odbieranie obrazków z GG 8.0 jest bezproblemowe. Po analizie przysyłanych pakietów obrazka z GG8 nie zauważyłem żadnych widocznych zmian... Moglbys przeslac dumpy wysylania obrazka: libgadu - GG 8.0, oraz GG 7.7 - GG 8.0? Najlepiej tego samego obrazka :) Pozdrawiam. ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Protokół GG 7.7 i wysyłani e obrazków do GG 8.0
On Thu, Feb 12, 2009 at 05:47:48PM +0100, Daniel Zaborowski wrote: No więc właśnie. Chodzi mi o to, aby dało się to wysłać i do gg 7 i do gg 8. Sęk w tym, że oryginalne gg 7.7 sobie z tym radzi. Zatem opis protokołu ma jakieś błędy. I chciałem się dowiedzieć jakie :) stąd temat :) GG 7.7 IMHO tez nie rozumie Nowego Gadu-Gadu, chyba ze wysylasz jakis obrazek, ktory wyslales juz kiedys (i trzyma go w keszu, to wtedy go wyswietli); Jak cos to mam shoty na dowod! (czyt. IMHO Nowe Gadu-Gadu/ ekg2 nie umie wysylac do GG 7.7), Jak zobaczylem ze GG 7.7 wysyla 0x28 w polu rodzaj wiadomosci, to sie poddalem :) ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Niekonczacy sie watek w libgadu?
On Tue, Dec 16, 2008 at 06:32:08PM +0100, Tomek wrote: W momencie zakonczenia aplikacji glowny watek kadu sie konczy, wypisuje pozegnanie ale aplikacja sie nie konczy tylko zawisa. Pomaga kill -9. No to niech uzytkownik Kadu podczepi sie gdb pod kadu, i backtrace, najlepiej backtrace full. ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] RFC: Zmiany w API (było RFC : Wybór resolvera)
On Thu, Dec 04, 2008 at 12:14:29AM +0100, Wojtek Kaniewski wrote: Jakub Zawadzki pisze: Kiedys mi juz pokazywales, ja wolalbym przepisac libgadu na gliba i wydac 2.0, z zupelnie nowym API (powtarzam sie? :)) Problem w tym, że pewnie jest parę projektów, które korzystają z libgadu, ale zależność od glib byłaby zbyt ciężka. Mimo wszystko chciałbym, żeby integracja z glib i Qt była banalna dzięki zmianom gg_watch_fd() i ekipy. Wlasnie dlatego mowie o wydaniu 2.0, projekty ktore nie sa zainteresowane glibem, moglyby dalej korzystac z 1.x Zresztą całe to gg_session_new() i gg_session_set_cośtam() jest inspirowane glib, więc nikt nawet nie zauważy różnicy, jeśli będzie używał glib i libgadu w jednej aplikacji ;) Glib to nie tylko nazewnictwo funkcji :) To mialoby byc ulatwienie dla nas tez (przenosnosc, dostep do wiekszego API ktorego nie trzeba samemu pisac \o/) Anyway, mozna zrobic osobnego brancha dla gliba (nawet jesli nie zostanie wydane jako 2.0), postaram sie zobaczyc w weekend :) Howgh. ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] RFC: Wybór resolvera
On Mon, Dec 01, 2008 at 11:32:24PM +0100, [EMAIL PROTECTED] wrote: 01.12.08 [EMAIL PROTECTED] napisał: Można albo dodać zmienną globalną, która określi rodzaj resolvera (zwykle ustala się to raz na początku), albo dodać parametr do każdej funkcji, która rozpoczyna połączenie. Ani to, ani to nie jest idealnym rozwiązaniem, ale skłaniałbym się ku zmiennej globalnej. A co Wy sądzicie? Najbardziej liczę na odpowiedź developerów Kadu, bo pewnie macie z tym najwięcej problemów. Myślę że zmienna globalna i funkcja typu gg_set_resolver(), przyjmująca enumem trzy wartości - default, fork, pthread. A mozna poprosic aby mozna bylo ustawic wlasna funkcje? W sumie nie wiem po co - ale moze komus sie przyda :) ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Odp: libgadu 1.7.2
On Sat, Feb 16, 2008 at 04:51:36PM +0100, Wojtek Kaniewski wrote: Rafał pisze: Czyli 1.7.2 nie ma jeszcze dcc7? Jeżeli tak to jest szansa na 1.8.0 przed kadu 0.6.0? (następna niedziela)? Dzisiaj, jutro, na pewno przed przyszłą niedzielą. 1.7.2 wypuściłem własnie po to, żeby zamknąć gałąź 1.7 i móc wydać 1.8.0 za chwilę. Posprawdzam dokumentację, sprawdzę zgodność ABI i wyjdzie. Swoją drogą, nie bójcie się pisać wydajemy Kadu 0.6.0 za chwilę, a gdzie [EMAIL PROTECTED] jest libgadu? ;) A w ekg2 sprawdzamy symbole ktore sie pojawi w libgadu dawno temu. AC_CHECK_LIB([gadu], [gg_remind_passwd3], [AC_DEFINE(HAVE_GG_REMIND_PASSWD3, 1, [define if libgadu has gg_remind_passwd3 since LIBGADU ~20050217 ])]) AC_CHECK_LIB([gadu], [gg_change_passwd4], [AC_DEFINE(HAVE_GG_CHANGE_PASSWD4, 1, [define if libgadu has gg_change_passwd4 since LIBGADU ~20030930 ])]) AC_CHECK_LIB([gadu], [gg_dcc7_send_file], [AC_DEFINE(HAVE_GG_DCC7_SEND_FILE, 1, [define if libgadu has gg_dcc7_send_file since LIBGADU ~20070603 ])]) Wiem, ze to nie jest rozwiazanie na wszystko, ale imho lepsza metoda niz sprawdzanie wersji / lub ciche zalozenie ze uzytkownik ma najnowsza wersje a jak nie to bledy czasie kompilacji/ runtime podczas ladowania bibloteki. Ale to chyba wszystko zalezy od POV (czy robimy ifdef'y i informujemy runtime uzytkownika ze ma stara bibloteke, i cos mu moze nie dzialac, czy nie robimy ifdef'ow) Pozdrawiam. ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Nowa wersja protokolu 0x2a
On Thu, Apr 26, 2007 at 12:34:35AM +0200, Jakub Zawadzki wrote: Ok, to proba druga ,,przepchniecia'' obslugi dcc7 do libgadu ;-) W zalacznikach patch + nowy plik (w/g sugestii Wojtka zeby to robic w nowym pliku) Pytanie do Wojtka: commitujemy/ nie commitujemy? (Tak wiem, niby mam dostep do CVS, i dostalem zgode, ALE) A ogolnie to dostalem przed chwila maila z pytaniem: - Forwarded message from blizni [EMAIL PROTECTED] - Witam, widze ze jesteś autorem patcha do libgadu dodającego obsługę transferu plików z nowymi klientami gg (dcc7) W związku z tym mam pytanie: czy jest sposób, żeby wykorzystać to w ekg ? A jeśli tak, czy mógłbyś mi w tym pomoc? Bardzo chętnie bym wyprobował takie rozwiązanie, tylko cos nie bardzo idzie mi pożenienie tego wszystkiego ze sobą:/ Jesli to api przejdzie postaram sie dopracowac patcha do ekg1 ;) A tutaj prosba do deweloperow ekg1, aktualnie niestety nie dysponuje czasem zeby to zrobic, wiec jesli ktos by mogl to zrobic to byloby super. ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
