Jakub Zawadzki napisał(a):
Mh, swoja droga czemu commit diffy nie sa wysylane na libgadu-commit?
Bo wcześniej nie wiedziałem (zapomniałem?) o istnieniu tej listy. Będę
musiał pogadać z adminem.
A ja w sumie nadal jakos nie jestem przekonany co do uzywania tego
gg_login70 przy starej wersji
Marcin Slusarz napisał(a):
zapomniałeś wrzucić libgadu.h.in :)
Racja, ciągle jeszcze zapominam, że po przejściu na autotools, kod nie
leży tylko w jednym katalogu. Poprawione.
w.
___
libgadu-devel mailing list
libgadu-devel@lists.ziew.org
Jakub 'darkjames' Zawadzki napisał(a):
Gdy uzywamy pthreada przy kazdym resolvowaniu otwieramy fd ktorego
pozniej nie zamykamy... (a przy ostatnich padach serwera gg bardzo
nieprzyjemne jak po /_fds ma sie 40-50 kolejek fifo otwartych.
To by wyjaśniało tajemnicze pady zgłaszane na ekg-users.
Adam Wysocki napisał(a):
W sumie, tak będzie lepiej :) Chociaż to raczej spór o styl kodowania,
bo efekt będzie identyczny.
Przespałem się z tym i jednak SIG_DFL nie zadziała tak samo, bo będziemy
mieli wyścigi. Jeśli gg_logoff() zostanie wywołane między fork(), a
signal(), zachowanie będzie
Jakub Zawadzki napisał(a):
A ja w sumie nadal jakos nie jestem przekonany co do uzywania tego
gg_login70 przy starej wersji protokolu jaka deklarujemy domyslnie
przy logowaniu.. Bo teraz latwo gadu-gadu moze wyciac klienty uzywajace
libgadu... My deklarujemy sie jako 6.0, 6.0 umialo tylko
:10.360305259 +0200
+++ src/dcc7.c 2007-06-03 11:16:06.0 +0200
@@ -0,0 +1,824 @@
+/* $Id$ */
+
+/*
+ * (C) Copyright 2001-2007 Wojtek Kaniewski [EMAIL PROTECTED]
+ * Tomasz Chiliñski [EMAIL PROTECTED]
+ * Adam Wysocki [EMAIL PROTECTED
) Copyright 2001-2002 Wojtek Kaniewski [EMAIL PROTECTED]
@@ -31,6 +31,7 @@
void handle_event(struct gg_session *s);
void handle_dcc(struct gg_dcc *s);
+void handle_dcc7(struct gg_dcc7 *s);
void handle_msg(struct gg_event *e);
void handle_voice(struct gg_common *c);
@@ -41,7 +42,7 @@
void
Jakub Zawadzki pisze:
Ogolnie ja cos kojarze ze byly inne zmiany w libgadu, ale ja bym jednak
poczekal az ktos znajdzie czas i dokonczy obsluge polaczen bezposrednich
dla gg 7.x, i dopiero wtedy wydawac od razu 1.8
Z tego co pamiętam, to podstawowa funkcjonalność połączeń 7.x jest i
działa,
Jakub Zawadzki pisze:
(...)
Dodałem w test/dcc7 prosty program do wysyłania i odbierania plików.
Zrobiłem parę testów i we wszystkie strony działa poprawnie. NAT
symuluję przez zwrócenie błędu w connect() i wysyłanie nieprawidłowego
adresu IP -- również działa bez problemu. Po drugiej stronie
Rafał pisze:
Hejka. Sytuacja skrajna:
Wysyłam plik, odbiorca akceptuje go i ustawia offset == size.
libgadu zwraca mi wtedy DCC_ERROR
(...)
Poprawiłem w gałęzi głównej. Mógłbyś sprawdzić, czy teraz jest w
porządku? Jeśli tak, to wrzucę to samo do gałęzi 1.7.
w.
On Mon, Feb 25, 2008 at 10:11:28AM +, Marcin Owsiany wrote:
$ svn log https://toxygen.net/svn/libgadu/trunk /dev/null
[...]
svn: żądanie REPORT nie powiodło się dla '/svn/libgadu/!svn/bc/540/trunk'
svn: REPORT z '/svn/libgadu/!svn/bc/540/trunk': 200 OK (https://toxygen.net)
$
W
Piotr Latosiński pisze:
Chodzi mi o wersję 0x2a - najnowszą.
Tak, pomyliłem się. Oczywiście, że chodzi mi o 0x000d.
Ale skoro piszesz, że do tej pory ten pakiet przychodził, to czemu nie
jest opisany w protokole choćby jako unknow?
Też się pomyliłem i cały czas myślałem o 0x000b, który
Szymon Zygmunt pisze:
Może nie wypada ale przypominam się raz jeszcze. Porady z ostatnich postów
nie pomagaja i nie mogę sobie skompilować libgadu nowszego niż z ~20.
maja. Na domowej (linux) maszynie kompilacja bez najmniejszych problemów.
Spróbuj teraz.
w.
Piotr Pełzowski pisze:
Na forum Kadu w pewnym wątku[1] zaproponowano dodanie w Kadu jakiegoś
rodzaju potwierdzenia skutecznego wysłania obrazka. O ile mi wiadomo
libgadu nie dostarcza takiej funkcjonalności. Protokół GG chyba ma takie
coś w swoich specach ponieważ dokładnie taka sama
Piotr Domagalski pisze:
Nope -- w Pythonie wykorzystywane są wątki systemowe. (...)
Mea culpa, za dużo się o Stackless Pythonie naczytałem ostatnio :)
w.
___
libgadu-devel mailing list
libgadu-devel@lists.ziew.org
Michal Antonczak pisze:
Funkcje debugujace libgadu produkuja taki log:
(...)
Nie widzę wysyłania pustej listy kontaktów. Na pewno kod wchodzi do
obsługi GG_EVENT_CONN_SUCCESS?
w.
___
libgadu-devel mailing list
libgadu-devel@lists.ziew.org
Hej,
Korzystając z wolnej chwili chcę naprawić mało sensowny sposób
wybierania resolvera na etapie kompilacji. Nic nie stoi na przeszkodzie,
żeby móc wybierać między fork() a pthread w czasie pracy. O ile przy
połączeniu z serwerem nie ma problemu, bo wystarczy dodać kolejne pole
do
[EMAIL PROTECTED] pisze:
int (*resolver_start)(int *fd, void **priv_data, const char *hostname);
void (*resolver_cleanup)(void **priv_data, int force);
W kwestii estetyki - jak start to bardziej pasuje end, a jak cleanup to
init :)
start startuje, ale resolvowanie kończy się samo. cleanup
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
Jakub Zawadzki pisze:
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
On Sun, Dec 07, 2008 at 07:22:32PM +0100, [EMAIL PROTECTED] wrote:
Nie jest i nie będzie -- zapomniałem wywalić. I nie rozumiem za bardzo
po co w ekg inny resolver niż fork(). Czyżby były używane wątki? :)
Jeżeli libgadu jest skompilowane z wątkami to czemu nie? :) Zostawiłbyś
w ekg
Tomek pisze:
Mam problem z resolverem pod Mac OS X. W przypadku biblioteki
skompilowanej z obsluga pthreads nastepuje zawias w funkcji gg_watch_fd
na wykonaniu close(sess-fd); (events.c:1084).
Natomiast w przypadku kompilacji bez pthreads zawias nie nastepuje,
natomiast konsola jest
Tomek pisze:
Jeden z uzytkownikow Kadu zglosil nam nastepujacy problem:
Jeśli ustawie żeby kadu się na starcie nie łączyło z gg to wtedy się
poprawnie zamyka, a jeśli połączę się z gg to wtedy nie chce się
zamknąć. Może to ma związek z libgadu?
PS. Raz się poprawnie zamyka po połączeniu z
Tomek pisze:
Przyszedl mi do glowy pomysl zeby napisac resolvera na qt i ustawic przy
pomocy gg_session_set_custom_resolver() tylko jest jedno ale - w kadu
wywolujemy gg_login() ktora przyjmuje tylko GG_RESOLVER_FORK,
GG_RESOLVER_PTHREAD lub GG_RESOLVER_DEFAULT i dla kazdego innego zwroci
-1.
Dnia 2008-12-28, nie o godzinie 17:37 +0100, Adam Wysocki pisze:
Na FreeBSD kompilacja wykłada się z braku inkludów, patch
(eliminuje także warninga w connect() i warningi implicit
declaration funkcji ze string.h):
Dzięki, commitnięte.
w.
___
Rafal Malinowski pisze:
Dla wersji 0.6.6 Kadu postanowiłem poczynić pewne poprawki z naszym prawie-
nigdy-nie-działającym kodem obsługi Dcc.
I natrafiłem na drobny problem - nie mogę odebrać (ani wysłać) pliku od osoby
która jest za NAT (ja mam publiczne IP).
Prawdopodobnie coś robię
wit...@ravir.pl pisze:
Postanowilem skodzic obsługe GG8 w Delphi. Od kilku juz dni meczee sie z
logowaniem. Nie wiem dokladnie w czym jest problem - tylko przypuszczam.
Gadu po wyslaniu pakietu logowania (0x0031) zawsze zwraca mi 9 - login
failed. Wysnifowalem oryginalny klient i porownalem
Adam Osuchowski pisze:
Piszę o tym tutaj, bo nie wiem czy to jest kwestia samej biblioteki czy
klienta. Z jednej strony, pętla obsługi zdarzeń jest kodowana w kliencie,
więc to on powinien czekać na ew. pakiety od serwera, ale z drugiej
strony, to zachowanie jest związane ze specyfiką
wit...@ravir.pl pisze:
Witam. Dzięki za poprawienie tego opisu. Jak już mówiłem tłumaczę sobie
wszystko na Delphi. Do szyfrowania używam biblioteki DCPCrypt. Mój kod
wygląda tak (właściwie to cała procedura szyfrująca testowa)
(...)
Nie pisałem już w Pascalopodobnych od ładnych paru lat,
On Tue, Jun 16, 2009 at 01:42:48PM +0200, Szymon Zygmunt wrote:
resolver.c: In function `gg_gethostbyname':
resolver.c:107: warning: passing arg 5 of `gethostbyname_r' from incompatible
pointer type
resolver.c:107: error: too many arguments to function `gethostbyname_r'
resolver.c:107:
On Tue, Jun 16, 2009 at 02:04:50PM +0200, Wojtek Kaniewski wrote:
Mógłbyś podesłać stronę manuala dla gethostbyname_r, jeśli takowa jest
zainstalowana w tym systemie? Najwyraźniej implementacje z glibc i
sunowych bibliotek się róźnią.
...a póki co, poszła tymczasowa poprawka, która powinna
Szymon Zygmunt pisze:
Libgadu się skompilowało, ale musiałem zrobić to:
http://lists.ziew.org/pipermail/libgadu-devel/2008-August/000309.html
Czy da się to jakoś poprawić na stałe, żeby nie trzeba było ręcznie za
każdą kompilacją?
Spróbuj teraz. Poprawiłem to wcześniej, ale umknął mi
Adam Wysocki pisze:
Jeżeli chcesz dobrze to możnaby się dowiedzieć czemu wersja nie jest
ustawiana - to problem z libgadu, dlatego wysyłam też na libgadu-devel.
Nie zmieniałeś nic w pliku configure.ac (w libgadu)? (...)
Fakt, że to trochę niestandardowe użycie autoconfa, ale prawie wszędzie
Szymon Zygmunt pisze:
Pociągniemy ten temat dalej? Chętnie pomogę znaleźć przyczynę tego
błędu. Dodatkowo od pewnego czasu na tym Solarisie mam problem z
automatycznym połączeniem się z serwerem - muszę ustawiać zmienną
protocol
Adam Wysocki pisze:
[go...@sloneczko ~]$ uname -a
SunOS sloneczko 5.10 Generic_118822-25 sun4u sparc SUNW,Ultra-5_10
Taka może być?
Nie pogardzę ;)
Pozdr,
Wojtek
___
libgadu-devel mailing list
libgadu-devel@lists.ziew.org
Sporo czasu minęło, sporo zmian w świecie Gadu-Gadu zaszło, więc wypada
w końcu coś z tym zrobić. Lista zmian:
* Podstawowa obsługa protokołu Nowego Gadu-Gadu, a co za tym idzie,
wiadomości i opisy kodowane w UTF-8. Domyślnie biblioteka nadal
przekazuje do aplikacji i spodziewa
Szymon Zygmunt pisze:
Pociągniemy ten temat dalej? Chętnie pomogę znaleźć przyczynę tego
błędu. Dodatkowo od pewnego czasu na tym Solarisie mam problem z
automatycznym połączeniem się z serwerem - muszę ustawiać zmienną
protocol
Mietek Bąk pisze:
Od pewnego czasu mój program (bramka GG/XMPP) przestał się łączyć z
serwerami GG. Kod błędu to GG_FAILURE_CONNECTING, ale zupełnie nie
rozumiem przyczyny. Czy mógłbym prosić o pomoc?
Załączam wyciąg z informacji odpluskwiania:
// gg_read_line() error on read (errno=11,
Marcin Owsiany pisze:
Czy powyższe nie powinno spowodować podbicia numeru API?
Możliwe, że nadal nie rozumiem numeracji bibliotek dzielonych a'la
libtool, ale czy zmiana z 3.9.0 do 3.10.0 to za mało?
w.
___
libgadu-devel mailing list
Marcin Owsiany pisze:
Zakładając, że funkcje
T gg_resolve
T gg_resolve_pthread
T gg_resolve_pthread_cleanup
nie były w publicznym API, to nie.
O, usunięcia tych funkcji nawet nie zauważyłem. Jeśli zostały by
usunięte z API, to powinno to pociągnąć za sobą podbicie numeru _ABI_.
Dnia 2009-10-01, czw o godzinie 09:05 +0100, Marcin Owsiany pisze:
gg_gethostbyname() zostało przeniesione do resolver.h, więc zniknęło z
API. Niby symbol został, ale ABI się zmieniło, bo zmieniła się sygnatura
funkcji. (zwracany typ danych pointer-int, dodane parametry)
Patch Jakuba trafił do
Dnia 2009-10-01, czw o godzinie 12:33 +0100, Marcin Owsiany pisze:
Przy okazji dodałem GG_OBSOLETE (w gcc __attribute__ ((deprecated)) )
O, to jest dobre choćby dzięki temu że wiadomo będzie co wyleci w
przyszłości. A jaki to ma wpływ na binarkę?
Żaden. ZTCW to daje tylko ostrzeżenie
Dnia 2009-10-03, sob o godzinie 15:42 +0100, Marcin Owsiany pisze:
Przesyłam kilka łatek jak w temacie. Jeśli nie będzie sprzeciwu to commitnę
dziś wieczorem lub jutro.
Nie krępuj się :)
Pozdr,
Wojtek
___
libgadu-devel mailing list
Dnia 2009-10-03, sob o godzinie 14:37 +0200, Jakub Zawadzki pisze:
O, dobrze wiedzieć bo na moim laptopie (gdzie mam stripnięte symbole):
nm: /bin/cat: no symbols
nm -D
Swoją drogą po coś takiego chyba wymyślono wersjonowanie symboli? (nie
wiem jak to się fachowo nazywa, chodzi mi o np.
Krzysztof Klinikowski pisze:
Okej. Wydaje mi się, że to działa ale problem powstaje teraz inny. Mam
coś takiego do przy odbieraniu statusów innych użytkowników:
(...)
Kiedyś używając tego kodu dostawałem jako statusy liczby rzędu 0 - 5 z
tego co pamiętam lecz teraz są one bardzo duże:
Marcin Owsiany pisze:
Czy mógłbyś napisać parę słów na temat tego jak odpalać te testy?
Jeśli są jakieś które mogą działać automatycznie bez dostępu do sieci,
to chętnie włączyłbym wykonywanie ich przy kompilacji pakietu (w
Debianie jest 16 architektur, więc byłyby odpalane na każdej z nich).
Krzysztof Klinikowski pisze:
Okej. Zaraz sprawdzę czy wszystko działa i w razie błędów napisze tutaj.
Mam jeszcze pytanie dotyczące tego UTF8. Czy UTF jest tylko dla
wiadomości i statusów czy wyszukiwanie użytkowników i rejestracja konta
też już używa UTF8?
Poprawiłem obsługę katalogu
Marcin Owsiany pisze:
-# Only try to generate documentation if it is not already there.
# Do not fail if doxygen is not available.
-html: ../include/libgadu.h
-test -d html || if doxygen --version /dev/null; then doxygen; fi
+html-stamp: ../include/libgadu.h $(wildcard ../src/*.c)
Marcin Owsiany pisze:
Elegancko, ale bije po oczach ta kombinacja no-op + touch html-stamp
:)
Poprawiłem @DOXYGEN@ na $(DOXYGEN). Nawet jeśli go nie ma, będzie
wiadomo o co chodzi.
Może zamiast ustawiać DOXYGEN na : zrobić żeby make nie wchodził w
ogóle do podkatalogu docs?
Mówisz, masz.
Lista zmian względem 1.9.0-rc1:
* Poprawiona obsługa UTF-8: wysyłanie i odbieranie wiadomości
powinno już zawierać coś więcej niż CP1250.
* Operacje na katalogu publicznym działają poprawnie w UTF-8.
* Uaktualnione skrypty testowe.
* Uaktualnione przykładowe aplikacje.
Dominik 'Rathann' Mierzejewski pisze:
Fakt, że libgadu linkuje openssl sprawia kłopoty licencyjne aplikacjom,
które używają libgadu i są na licencji GPL (pidgin, ekg2, gg2). Czy dałoby
się dodać obsługę np. gnutls?
Mam to ma mojej liście TODO, ale póki co, to nie ma sensu. O ile mi
wiadomo, w
Marcin Owsiany pisze:
+sess-status_flags = 0x0081;
Może by to wyrazić jako sumę symbolicznych flag?
Jasne, tak powinno być od początku :)
w.
___
libgadu-devel mailing list
libgadu-devel@lists.ziew.org
W dniu 10.05.2010 16:12, Marcin Owsiany pisze:
Ponad pół roku powinno wystarczyć na ustabilizowanie nowego wydania,
więc najwyższy czas na oficjalną wersję 1.9.0. Zmiany względem gałęzi
1.8 już dawno przestały być nowościami, ale i tak wypada podać:
Hm, czy nie powinna być podbita wersja
W dniu 30.11.2010 21:56, Piotr Galiszewski pisze:
Dzisiaj w Kadu otrzymaliśmy pierwsze zgłoszenie [1], o dziwnym wysypie
programu po aktualizacji libgadu to wersji 1.9.1. Problem ten dotyczy
zarówno najnowszych wersji testowych kadu, jak i starszych wersji
stabilnych. Otrzymaliśmy również
W dniu 28.12.2010 19:11, Michał Nykiel pisze:
Ile tych struktur bym nie wysłał, w odpowiedzi tylko dwie.
Natomiast dostaję powiadomienia o zmianach statusu każdego z numerów
jakie wysłałem. Dlaczego tak się dzieje?
Sprawdź, czy Twój kompilator nie wyrównuje rozmiaru struktury gg_notify
do
W dniu 01.03.2011 00:28, Rafał Malinowski pisze:
Załączam patch, który działa, ale pewnie łamie jakieś zasady wstecznej
kompatybilności ;)
Proszę o wskazówki, jak ich nie łamać.
Myślałem o tym wcześniej i mam mieszane uczucia. Z jednej strony
moglibyśmy sprawdzać, czy client_version zaczyna
Dnia 2011-04-15, pią o godzinie 13:55 +0200, Rafał Malinowski pisze:
Mam pewien problem z opisem protokołu :) Konkretnie z tym działem:
http://toxygen.net/libgadu/protocol/#ch3.4 i z opisem przeplatanki
GG_DCC7_INFO z pobieraniem adresu serwera pośredniczącego.
Jeżeli dobrze rozumiem, to w tym
Dnia 2011-04-16, sob o godzinie 13:24 +0200, Rafał Malinowski pisze:
Nowa wersją łatki w załączniku.
Już w repo, dzięki.
Pozdr,
Wojtek
___
libgadu-devel mailing list
libgadu-devel@lists.ziew.org
http://lists.ziew.org/mailman/listinfo/libgadu-devel
Dnia 2011-04-23, sob o godzinie 01:16 +0200, Bartosz Brachaczek pisze:
Przeglądając kod libgadu, natrafiłem na niezgodny z faktycznym
działaniem opis funkcji gg_read_line(). Dokumentacja mówi, że w
przypadku powodzenia zwraca ona buf, podczas gdy w rzeczywistości
zwraca ona miejsce w buf
Dnia 2011-04-30, sob o godzinie 16:24 +0200, Tomasz Wasilczyk pisze:
Może być tak, że ustawienie gg_login_params.tls na 1 (GG_SSL_ENABLED)
będzie się zachowywać jak do tej pory, a ustawienie na 2
(GG_SSL_REQUIRED) będzie zwracało błąd, jeśli nie ma wkompilowanej
obsługi SSL?
Brzmi nawet
Dnia 2011-05-05, czw o godzinie 23:08 +0200, Bartosz Brachaczek pisze:
Mały update dokumentacji protokołu był od początku częścią tej serii
łatek i, jak widzę, również został dzisiaj wrzucony. :)
Wrzuciłem Twoje poprawki do repo. Pozwoliłem sobie przenieść funkcje
kompresji do osobnego pliku,
Dnia 2011-05-11, śro o godzinie 14:57 +0200, Bartosz Brachaczek pisze:
(...) Trudno mi sobie wyobrazić, jak w
rozsądny sposób można by dostosować do takiego przypadku funkcję
gg_message_html_to_text(), więc moje pytanie brzmi, dlaczego właściwie
libgadu dokonuje konwersji HTML-a do czystego
Dnia 2011-05-11, śro o godzinie 16:05 +0200, Bartosz Brachaczek pisze:
1. Stripować nieprzewidzanie przez protokół znaczniki HTML w
odebranych wiadomościach (np. script zamieniać na lt;scriptgt;).
Nie rozumiem dlaczego w ogóle mielibyśmy w cokolwiek ingerować. Jeśli
ktoś będzie chciał napisać
Dnia 2011-05-12, czw o godzinie 15:29 +0200, Tomasz Wasilczyk pisze:
znalazłem małego buga w kodzie odpowiadającym za pobranie adresu
serwera z huba. Mianowicie, jeżeli wystąpi błąd w połączeniu, libgadu
zinterpretuje to, co dostanie jako adres serwera. Jeżeli więc nic nie
dostanie, będzie
Dużo zmian API się nazbierało w repozytorium, więc tym razem podbijamy
środkową liczbę i dedykujemy wydanie ekipie Kadu.
* Import i eksport listy kontaktów zgodnej z Gadu-Gadu 10
(dodaje zależność od zlib)
* Poprawione zarządzanie adresami i portami przy połączeniach
bezpośrednich.
Dnia 2011-06-05, nie o godzinie 12:44 +0200, Tomasz Wasilczyk pisze:
Plik dcc.c:421 - zmienna uint16_t port jest przyrównywana do -1 (sypie
warningiem w libpurple). Można by chociaż rzutować tą -1 na uint16_t.
Ten kod i tak nie jest już pewnie przez nikogo używany do niczego
sensownego, więc
Dnia 2011-06-15, śro o godzinie 09:14 +0200, Marcin Owsiany pisze:
Są więc następujące pytania:
0) jak to cudo właściwie działa? :)
Forkuje się i w tle działa proces udający oryginalny serwer, a na
pierwszym planie działa proces testujący ponad sto scenariuszy łączenia
się z serwerem.
1) co
Dnia 2011-06-19, nie o godzinie 17:19 +0200, Jakub Zawadzki pisze:
Valgrind pokazuje jedynie parę ostrzeżeń - patrz załącznik.
Poprawiłem, swoją drogą nieinicjowanie addr_count mogło
prowadzić do SIGSEGVów?
Raczej tak. Zaraz potem jest czytanie addr_count * sizeof() bajtów, więc
może być
Dnia 2011-07-04, pon o godzinie 01:46 +0200, Tomasz Wasilczyk pisze:
Czy to zamierzone, że libgadu nie wspiera starszych wersji GnuTLS (tzn
nie posiadających funkcji gnutls_priority_set_direct)? W powyższym
tickecie pojawił się prosty patch, który rozwiązuje problem, ale
wymaga dodania do
Dnia 2011-07-10, nie o godzinie 20:06 +0200, Dagobert Michelsen pisze:
I am trying to compile libgadu 1.11.0 on Solaris 9 Sparc with Sun Studio 12
and
there are some issues:
- Binding 10 127.0.67.67 does not work on Solaris as the IP adress is usually
no
bound on the local machine.
Dnia 2011-09-01, czw o godzinie 02:58 +0200, Bartosz Brachaczek pisze:
e-type = GG_EVENT_MSG;
+ memset(e-event, 0, sizeof(e-event));
e-type = (type != GG_RECV_OWN_MSG) ? GG_EVENT_MSG :
GG_EVENT_MULTILOGON_MSG;
+ memset(e-event, 0, sizeof(e-event));
Pozwoliłem sobie te
Dnia 2011-09-04, nie o godzinie 17:52 +0200, Bartosz Brachaczek pisze:
Hm, dziwne. Specjalnie wysyłałem serię za pomocą git send-email, żeby
nie zepsuć formatowania. Zresztą wydaje mi się, że mailman pokazuje,
że w łatkach są tabulacje[1]. Gdyby w przyszłości były jeszcze jakieś
problemy z
Dnia 2011-10-12, śro o godzinie 01:41 +0200, Tomasz Wasilczyk pisze:
Jeśli dobrze pamiętam, to na jakimś PowerPC można było użyć typu va_list
tylko raz, dlatego jedna kopia była używana do określenia rozmiaru
bufora, druga do właściwego vsnprintf(). Nie wiem, czy jest sens nadal
utrzymywać
Dnia 2011-10-20, czw o godzinie 22:10 +0200, Tomasz Wasilczyk pisze:
(ciach)
Odpowiem hurtowo. Bardzo dobrze, że usunąłeś ioctl(), bo ta funkcja
zawierała kod zupełnie niezwiązany z libgadu. GG_CONFIG_HAVE_FORK jest
wykrywane przez configure.ac. Zamieniłem compat.h na network.h, bo mimo
ogólnej
Dnia 2011-10-21, pią o godzinie 01:31 +0200, Tomasz Wasilczyk pisze:
W dniu 20 października 2011 23:16 użytkownik Wojtek Kaniewski
wojte...@toxygen.net napisał:
Bardzo dobrze, że usunąłeś ioctl(), bo ta funkcja
zawierała kod zupełnie niezwiązany z libgadu.
Nie wiem, do czego ona służy
Dnia 2011-10-23, nie o godzinie 03:11 +0200, Bartosz Brachaczek pisze:
Właściwie żeby móc polegać na errno, to trzeba by coś takiego zrobić
dla wszystkich funkcji socketowych, tj. także socket(), bind(),
accept() itd. Tak czy inaczej jest to mniej inwazyjna metoda niż
gg_socket_errno() +
Dnia 2011-10-24, pon o godzinie 13:49 +0200, Bartosz Brachaczek pisze:
W dniu 24 października 2011 07:28 użytkownik Wojtek Kaniewski
wojte...@toxygen.net napisał:
No tak, API. To trzeba będzie zrobić warunek, że ustawienie
GG_RESOLVER_CUSTOM powoduje użycie read(), a wbudowane recv(), mimo
Dnia 2011-10-25, wto o godzinie 01:03 +0200, Bartosz Brachaczek pisze:
Mam nadzieję, że w środę napiszę te wszystkie errno-wrappery i
przetestuję całość pod MSVC (paru dodatkowych łatek jeszcze będę
musiał pewnie użyć). Przetestuję również w szczególności tego
resolvera Win32. Ale powinien
Dnia 2011-10-28, pią o godzinie 00:59 +0200, Bartosz Brachaczek pisze:
W ramach prac nad portem Win32 przeglądałem użycia funkcji close() w
libgadu i stwierdziłem, że wszystkie jej wywołania w pliku dcc.c
dotyczą gniazd. W związku z czym wydaje mi się, że brakuje
close(d-file_fd) w
Dnia 2011-10-29, sob o godzinie 03:11 +0200, Bartosz Brachaczek pisze:
To ja może podsumuję tutaj znane mi problemy pod MSVC i Win32 ogólnie:
To ja się ustosunkuję do paru, bo okazało się, że jednak mam już
zainstalowane Visual Studio Express i udało mi się pogrzebać tak w
kodzie, żeby się
Dnia 2011-11-02, śro o godzinie 19:04 +0100, Bartosz Brachaczek pisze:
Cześć,
Kawałek kodu w src/dcc7.c (a także kod na usługach dcc7 w
include/internal.h i src/endian.c) zależy od zdefiniowanych makr
HAVE_STRTOULL i HAVE_UINT64_T.. Tak się jednak składa, że te makra są
jedynie definiowane
Dnia 2011-12-19, pon o godzinie 16:18 +0100, Marcin Owsiany pisze:
On Fri, Dec 16, 2011 at 11:21:26PM +0100, Rafał Malinowski wrote:
Dostaję: -lgnutls
Wersja to 3.0.3-8.1
Podeślesz swój plik /usr/lib/pkgconfig/gnutls.pc ?
Przydałby się też wycinek komunikatów z kompilacji która zawodzi
Dnia 2011-12-28, śro o godzinie 00:50 +0100, Bartosz Brachaczek pisze:
W obecnym trunku obsługa OpenSSL jest zepsuta. Mianowicie w
gg_session_init_ssl() wywoływane jest SSL_CTX_new() pod warunkiem, że
gs-ssl_ctx != NULL, podczas gdy powinno być wywoływane pod przeciwnym
warunkiem. Sam nie
Dnia 2011-12-28, śro o godzinie 13:30 +0100, Jakub Zawadzki pisze:
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ń ;|
Gdyby chodziło Ci o r1243, to bym powiedział, że świetna robota ;)
Pozdr,
Wojtek
Dobry wieczór,
Parę ważnych zmian się uzbierało na gałęzi 1.11, więc najwyższy czas
wydać wersję z poprawkami. Tym razem będą to:
* Poprawiona obsługa SSL za pomocą biblioteki GnuTLS
* Poprawione określanie bibliotek dla pkg-config
* Poprawione rozwiązywanie nazw dla systemów bez funkcji
Dnia 2012-06-13, śro o godzinie 01:31 +0200, Libgadu commit list pisze:
Author: beevvy
Date: 2012-06-13 01:31:45 +0200 (Wed, 13 Jun 2012)
New Revision: 1262
Modified:
trunk/configure.ac
trunk/pkgconfig/libgadu.pc.in
Log:
Umieszczaj zależność od openssl tam gdzie należy, czyli w
Dnia 2012-06-13, śro o godzinie 01:33 +0200, Libgadu commit list pisze:
Zatem musimy koniecznie użyć pthread_join(), aby być pewnym, że wątek
nie spróbuje użyć zwolnionych już danych. Niesie to też ze sobą
konieczność zrezygowania z pthread_detach().
Plus dla Ciebie. Ten kod tam siedział od
Dnia 2012-06-13, śro o godzinie 14:40 +0200, Libgadu commit list pisze:
for (i = 0; i 9; i++) {
unsigned int left = 1048576;
+ off_t current_pos = (len - 1048576) / 9 * i;
- if (lseek(fd, (len - 1048576) / 9 * i,
Dnia 2012-06-13, śro o godzinie 01:34 +0200, Libgadu commit list pisze:
Author: beevvy
Date: 2012-06-13 01:34:58 +0200 (Wed, 13 Jun 2012)
New Revision: 1269
Modified:
trunk/src/dcc7.c
trunk/src/http.c
Log:
Obsługuj EAGAIN i EINTR również przy gg_resolver_recv()
Tak się
Dnia 2012-06-13, śro o godzinie 20:13 +0200, Bartosz Brachaczek pisze:
W dniu 13 czerwca 2012 19:55 użytkownik Wojtek Kaniewski
wojte...@toxygen.net napisał:
libgadu.h zawiera #include openssl/ssl.h. Jesteś pewny, że powinno iść
do .private?
Tak, pkgconfig doda ścieżki do inkludów tak czy
Dnia 2012-06-13, śro o godzinie 23:05 +0200, Bartosz Brachaczek pisze:
Niezbyt rozumiem, jak do..while mogłoby znieść konieczność użycia
czegoś w stylu MIN. No ale faktycznie do..while trochę skróciłoby kod.
I powinienem był to makro nazwać jakoś mniej ogólnie, np. GG_MIN. W
każdym razie chyba
Dnia 2012-06-16, sob o godzinie 22:47 +0200, Wojtek Kaniewski pisze:
Jesteś w stanie zgarnąć plik tests/automatic/report.html z maszyny
budującej?
Eee, to nie ten test wyleciał. Niestety `protocol` średnio się nadaje do
testowania na nielinuksowej maszynie z wieloma użytkownikami, bo adres i
Dnia 2012-06-17, nie o godzinie 17:57 +0100, Marcin Owsiany pisze:
W czasie kompilacji r1289 na Debianie sid amd64 dostaję następujące
ostrzeżenia. Gdyby tak poprawić przynajmniej wszystkie od GCC to mógłbym się
pokusić o użycie -Werror, co dałoby wgląd w stan kodu na wszystkich
Dnia 2012-06-17, nie o godzinie 13:15 +0100, Marcin Owsiany pisze:
Dzięki, sprawdzę (nawiasem ten log to był trunk). Spróbuję też zobaczyć
czy da się jakoś usdostępniać report.html na przyszłość.
Od dawna nosiłem się z tym, żeby pozbyć się generowania HTML-a przez
testy, bo wartość dodana jest
Dnia 2012-06-18, pon o godzinie 21:00 +0100, Marcin Owsiany pisze:
Timeouty w tym teście
są zmniejszone do minimum, żeby nie osiwieć czekając na wyniki, co przy
słabym sprzęcie i/lub dużym loadzie może niestety mieć negatywny wpływ.
Plus to, że wywalił się test 433, a te od 324 w górę lecą
Dnia 2012-06-23, sob o godzinie 10:40 +0100, Marcin Owsiany pisze:
Niestetyż wygląda na to że na hurdzie nadal się zacina:
https://buildd.debian.org/status/fetch.php?pkg=libgaduarch=hurd-i386ver=1%3A1.12.0~pre%2Br1298-1stamp=1340426273
Spróbuję wyczaić czy inactivity faktycznie znaczy to co
Dnia 2012-06-25, pon o godzinie 17:31 +0200, Tomasz Wasilczyk pisze:
Mozna tez przekazac tam nowa strukture, zawierajaca konfiguracje proxy (lub
NULL, aby uzyc globalnej konfiguracji). Sesja by tez mogla ja przechowywac.
To chyba najlepsze rozwiazanie?
Zrobiłem szkic prototypów nowej
Dnia 2012-06-25, pon o godzinie 09:10 +0100, Marcin Owsiany pisze:
r1301 się zbudowało na autobuilderze hurd-i386, ale dla odmiany pojawił
się błąd na kfreebsd-amd64, które było OK. Chyba jest jeszcze jakiś
wyścig:
Dnia 2012-07-02, pon o godzinie 23:31 +0200, Tomasz Wasilczyk pisze:
Zrobiłem bardzo wstępną implementację [1], którą podpiąłem na sztywno
do połączeń http - na razie bez żadnej konfiguracji, taki
proof-of-concept.
Działa ona w ten sposób, że najpierw zlecamy nawiązanie połączenia za
pomocą
Dnia 2012-11-14, śro o godzinie 19:32 +0100, Tomasz Wasilczyk pisze:
tak sobie walczę z tym GG11 i stwierdzam, że strasznie ciężko zauważyć
w debug logu błędy wypluwane przez libgadu - są one oznaczane tak
samo, jak komunikaty o powodzeniu operacji.
Dało by się wprowadzić nowe flagi,
1 - 100 of 123 matches
Mail list logo
