dokończyć wydanie dzisiaj.
>
> Tomek
>
> W dniu 31 stycznia 2017 08:11 użytkownik Bartosz Brachaczek <
> b.brachac...@gmail.com> napisał:
>
>> Widziałem, że Rafał w Kadu walczy z tym samym błędem:
>> http://www.kadu.im/redmine/issues/3117
>>
>> Wygl
Widziałem, że Rafał w Kadu walczy z tym samym błędem: http://www.kadu.im/red
mine/issues/3117
Wygląda na to, że jest częściowa poprawka w libgadu 1.12.2. Nie jestem
pewien, jaki jest status tego wydania: tag w Gicie jest, ale nie widziałem
żadnego ogłoszenia, a http://libgadu.net/ oraz htt
ps://gi
Po pobraniu dodatkowych siedmiu DLL-ek, od których ten build libgadu
zależał (a właściwie libgnutls i sześciu jego zależności) i zmianie
nazwy z libgadu-3.dll na gadu.dll działa z Kadu bez zarzutu.
Pozdrawiam!
___
libgadu-devel mailing list
libgadu-devel
2013/6/15 Wojtek Kaniewski :
> Dnia 2013-06-07, pią o godzinie 01:55 +0200, Bartosz Brachaczek pisze:
>> So the functions of interest are:
>> a) for OpenSSL:
>> -- SSL_CTX_set_default_verify_paths() to use CA cert store configured
>> during OpenSSL's build
&g
2013/6/13 Wojtek Kaniewski :
> I plan to copy and paste a part of GnuTLS' configure.ac. Take a look at
> https://gitorious.org/gnutls/gnutls/blobs/c59329a089a9ed108692066de95f533f482b5422/configure.ac
> line 377. And if we detect GnuTLS 3.x we'll use appropriate function. Are
> you okay with such s
2013/6/12 Wojtek Kaniewski :
> As Bartosz wrote
> the code for GnuTLS will be more complicated, so it may take some time.
Do you have any plan for it? I have performed some research and the
options seem to be to:
1) Have a build-time option to explicitly specify a CA trust store
file to use, and
(Reposting my conversation with Wojtek to the mailing list. I have
just noticed we switched away from it).
2013/6/7 Bartosz Brachaczek :
> 2013/6/6 Wojtek Kaniewski :
>> Dnia 2013-06-04, wto o godzinie 13:37 +0200, Bartosz Brachaczek pisze:
>>> But checking which certificates a
Hi,
Simply using SSL_get_verify_result() is not a solution here, as it
returns X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY when connecting
to the proprietary servers on my system (I assume I am not being
attacked, you might want to confirm it yourself).
But checking which certificates are accept
W dniu 21 września 2012 03:48 użytkownik Bartosz Brachaczek
napisał:
> Zasymulowałem takie zachowanie i Kadu działa tak, jak się spodziewałem
> (zżera 2/3 jednego wątku, ale jest responsywne) albo całkowicie się
> zamraża na gnutls_record_recv(), jeśli go używamy -- to jest chyba
>
W dniu 20 września 2012 22:01 użytkownik Jakub Zawadzki
napisał:
> Może da się to zaimplementować wykorzystując ->timeout oraz ->soft_timeout?
> (zgaduję, nie oglądałem kodu)
Oczywiście, głupek ze mnie. Kombinowałem jak koń pod górkę, a zupełnie
zapomniałem o soft_timeout. Duet timeout i soft_tim
W dniu 21 września 2012 00:38 użytkownik Tomasz Wasilczyk
napisał:
>> 3. Z kodu wnioskuję, że co trzeci pakiet potwierdzasz jednak od razu.
>> Więc widocznie potwierdzanie z opóźnieniem nie jest twardym wymogiem,
>> a przynajmniej nie zawsze. Brałeś pod uwagę taką możliwość, że
>> faktyczne znacze
W dniu 21 września 2012 03:21 użytkownik Bartosz Brachaczek
napisał:
> A jeśli faktycznie będzie trzeba rozwiązać jakoś kwestię opóźnionego
> potwierdzania końcówek tych niezamawianych fragmentów obrazków, to ja
> niestety nie mam żadnego mądrego pomysłu. Jedyny sposób bez zmiany
&g
W dniu 20 września 2012 21:01 użytkownik Tomasz Wasilczyk
napisał:
> Natrafiłem jednak na pewien problem: nie można potwierdzać odebrania
> pakietów z obrazkami od razu po ich otrzymaniu. Zrobiłem więc bufor, w
> którym potwierdzam po trzy pakiety (udaję tak oryginalnego klienta).
> Wszystko fajni
W dniu 2 września 2012 21:24 użytkownik Jakub Zawadzki
napisał:
> 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 tak
W dniu 2 września 2012 16:28 użytkownik Tomasz Wasilczyk
napisał:
> Napisałem prototyp wspomnianego bufora [1], 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 miejs
2012/8/30 Rafał Malinowski :
> Hohohoh!
>
> Trzymamy kciuki w Kadu za to!
Ja postaram się nie tylko trzymać kciuki, ale to jak znajdę znowu trochę czasu.
___
libgadu-devel mailing list
libgadu-devel@lists.ziew.org
http://lists.ziew.org/mailman/listinfo/l
Dobra. Chyba poprawiłem też ten test na kFreeBSD. Załączam łatki.
0008-Zawsze-zeruj-struktur-sockaddr_in-valgrind-FreeBSD.patch
Description: Binary data
0009-Popraw-implementacj-timeoutu-w-connect.patch
Description: Binary data
___
libgadu-devel maili
W dniu 27 sierpnia 2012 09:17 użytkownik Marcin Owsiany
napisał:
> Jeśli wyślesz mi łatkę wcześniej, to mogę potestować.
Racja. Łatka jest bardzo prosta. Załączyłem ją w pliku 0005-*.patch.
Łatka 0006-*.patch może przy odrobinie szczęścia nieco rozjaśnić powód
problemów na kFreeBSD.
Bartosz
00
2012/8/27 Daniel Macks :
> Now that configure.ac puts -Wall in CFLAGS for the whole build process
> conditional on GCC, that same flag should not also be hardcoded in any
> specific makefiles. There are several instances of it in
> test/automatic/Makefile.am and test/manual/Makefile.am
>
> While
2012/8/26 Daniel Macks :
> configure has an AC_CHECK_LIB(c, __connect, ...) and uses its result to
> control whether test/manual that use __connect are activated. However, it
> does not control test/automatic. OS X does not have this symbol, so
> test/manual/dcc7 fails to compile. The attached (
2012/8/18 Marcin Owsiany :
> .. w r1314, na kfreebsd-i386 i hurd-i386, ale w różny sposób:
>
> https://buildd.debian.org/status/fetch.php?pkg=libgadu&arch=kfreebsd-i386&ver=1%3A1.12.0%7Epre%2Br1314-1&stamp=1345247660
>
> https://buildd.debian.org/status/fetch.php?pkg=libgadu&arch=hurd-i386&ver=1%3A
W dniu 15 sierpnia 2012 16:05 użytkownik Wojtek Kaniewski
napisał:
> Dnia 2012-08-11, sob o godzinie 21:52 +0200, Libgadu commit list pisze:
>> Author: beevvy
>> Date: 2012-08-11 21:52:57 +0200 (Sat, 11 Aug 2012)
>> New Revision: 1307
>>
>> Modified:
>>trunk/configure.ac
>>trunk/src/sha1.c
W dniu 16 czerwca 2012 23:03 użytkownik Bartosz Brachaczek
napisał:
> I akurat tak się składa, że
> wczoraj napisałem poprawkę na test protocol, która powinna tutaj pomóc
> -- postaram się ją jeszcze dzisiaj wrzucić.
Poprawka polegała na tym, że używane były sockety AF_UNIX zamiast
AF_
W dniu 16 czerwca 2012 22:47 użytkownik Wojtek Kaniewski
napisał:
> Dnia 2012-06-16, sob o godzinie 19:22 +0100, Marcin Owsiany pisze:
>> Witam,
>>
>> log z autobuildera:
>> https://buildd.debian.org/status/fetch.php?pkg=libgadu&arch=kfreebsd-amd64&ver=1%3A1.12.0~pre%2Br1278-1&stamp=1339864900&fil
W dniu 13 czerwca 2012 19:55 użytkownik Wojtek Kaniewski
napisał:
> libgadu.h zawiera #include . Jesteś pewny, że powinno iść
> do .private?
Tak, pkgconfig doda ścieżki do inkludów tak czy inaczej. Polecam
przeczytać "Guide to pkg-config"[1], w szczególności dwa ostatnie
punkty FAQ. Kilka minut c
W dniu 13 czerwca 2012 22:38 użytkownik Wojtek Kaniewski
napisał:
> 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)
W dniu 13 czerwca 2012 23:20 użytkownik Wojtek Kaniewski
napisał:
> Tak się zastanawiam... Jest jakiś konkretny powód, dla którego
> mielibyśmy obsługiwać EAGAIN? Kręcenie się w kółko zżerając 100%
> procesora, gdy aplikacja zrobi coś głupiego, to na pewno najlepsze
> wyjście? :)
To bardzo kiepsk
W dniu 5 marca 2012 00:02 użytkownik Wojtek Kaniewski
napisał:
> Dnia 2012-03-03, sob o godzinie 18:46 +0100, Bartosz Brachaczek pisze:
>> Wiem, że powyższa sytuacja to głównie wina błędu w Kadu, ale _wydaje
>> mi się_, że w gg_handle_connecting() w libgadu powinno nastąpi
Cześć,
W events.c soft_timeout jest ustawiany w następujących funkcjach:
gg_handle_connect(): na 1
gg_handle_connect_gg(): na 1
gg_handle_connecting_gg(): na 0
Co przy połączeniu asynchronicznym bez proxy skutkuje na przykład
takim przepływem:
GG_STATE_RESOLVE_HUB_ASYNC
GG_STATE_RESOL
W dniu 29 grudnia 2011 12:32 użytkownik Marcin Mirosław
napisał:
> W dniu 28.12.2011 16:05, Bartosz Brachaczek pisze:
>> A wiadomość z "Spróbuj z r1240" w ogóle do mnie nie doszła.
>> Przeglądając archiwum listy przez www, również nie widzę żadnych
>> wiadomości n
2011/12/28 Jakub Zawadzki :
> 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ń ;|
Dzięki, pomogło.
A wiadomość z "Spróbuj z r1240" w ogóle do mnie nie doszła.
Przeglądając archiwum listy przez www, również nie w
Hej,
Czy byłoby możliwe wydanie libgadu 1.11.1? Powód mojego pytania jest
taki, że w libgadu 1.11.0 nie działają połączenia szyfrowane z użyciem
GnuTLS, a w obecnej gałęzi 1.11 jak najbardziej działają (działają
również połączenia z użyciem OpenSSL, tak samo jak w 1.11.0). Zbliża
się nowe wydanie
Cześć,
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 wrzucam poprawki, bo nie wiem, czy dla przypadku
gs->ssl_ctx != NULL ma
Cześć,
Próbowałem poprawić dzisiaj błąd w Kadu na Windows polegający na tym,
że próba wysłania dużej wiadomości (u mnie to było około 400 znaków) w
dużej konferencji (10 osób) kończyła się niepowodzeniem. Co ciekawe,
podczas używania wersji Kadu z oknem terminala, na którym wypisywane
było wyjście
W dniu 20 października 2011 22:10 użytkownik Tomasz Wasilczyk
napisał:
> W dniu 18 października 2011 16:41 użytkownik Tomasz Wasilczyk
> napisał:
>> - dlaczego #pragma pack jest używana tylko w C++? Jak przeniosłem w
>> libpurple ifdefy tak, żeby odpowiadały tym z upstream-libgadu, to
>> niektóre
W dniu 3 listopada 2011 22:28 użytkownik Wojtek Kaniewski
napisał:
> Dnia 2011-11-02, śro o godzinie 02:04 +0100, Bartosz Brachaczek pisze:
>> Testy automatyczne, a dokładniej test na obecność libxml2 w
>> configure.ac, zależą od pkg-config. Bez pkg-config użycie autocon
W dniu 3 listopada 2011 00:11 użytkownik Wojtek Kaniewski
napisał:
> Dnia 2011-11-02, śro o godzinie 23:45 +0100, Bartosz Brachaczek pisze:
>> No więc wrzuciłem praktycznie wszystko, co mam i teraz trunk powinien
>> się kompilować na Cygwinie, MinGW czy MSVC bez żadnych problemów
W dniu 29 października 2011 19:26 użytkownik Wojtek Kaniewski
napisał:
> Dnia 2011-10-29, sob o godzinie 03:11 +0200, Bartosz Brachaczek pisze:
>> - Na Win32 gniazda trzeba zamykać za pomocą closesocket(), ale pliki
>> nadal za pomocą close() (właściwie _close(), ale close() też
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 w config.h (include/libgadu.h.in nic o nich nie
wie), a żaden ze wspomnianych
W dniu 31 października 2011 01:26 użytkownik Bartosz Brachaczek
napisał:
> Spróbowałem skompilować pod MSVC libgadu z wersją mojej łaty wysłanej
> tutaj i okazało się, że z jakiegoś powodu MSVC zaczyna traktować
> va_copy jako nazwę funkcji (mimo że definicja preprocesora jest moim
Hej,
Testy automatyczne, a dokładniej test na obecność libxml2 w
configure.ac, zależą od pkg-config. Bez pkg-config użycie autoconf
kończy się niepowodzeniem z bardzo nieprzyjaznym komunikatem błędu[1].
Zastanawiam się, czy nie można by przerobić tego testu w taki sam
sposób, jak jest zrobiony tes
dochodzić powodu, więc załączam alternatywną
wersję łaty. I czekam na opinie, bo wypadałoby na jakieś rozwiązanie
wreszcie się zdecydować :).
Pozdrawiam,
Bartosz
From 66d9395294ac894512d77029087a2745e9c7de34 Mon Sep 17 00:00:00 2001
From: Bartosz Brachaczek
Date: Sat, 29 Oct 2011 01:40:33 +0200
W dniu 30 października 2011 01:54 użytkownik Bartosz Brachaczek
napisał:
> Jasne, ale my va_copy() potrzebujemy wszędzie, chyba że akurat na
> danej platformie z przyczyn wynikających ze szczegółów
> implementacyjnych nie jest to konieczne. Nic nie stoi na przeszkodzie,
> aby jakaś p
W dniu 29 października 2011 18:53 użytkownik Wojtek Kaniewski
napisał:
> Dnia 2011-10-29, sob o godzinie 02:35 +0200, Bartosz Brachaczek pisze:
>> W załączonych łatkach moim zdaniem są błędy off-by-one, podobnie
>> zresztą jak jest w aktualnym kodzie libgadu. Przypadek res == size
W dniu 29 października 2011 03:11 użytkownik Bartosz Brachaczek
napisał:
> - Na Win32 deskryptory gniazd to liczby bez znaku (w 32-bitowej
> bibliotece rozmiaru inta, w 64-bitowej niestety większe, czym zacznę
> się martwić po rozwiązaniu tutaj opisanych problemów) i zgodnie z MSDN
>
: Bartosz Brachaczek
Date: Sat, 29 Oct 2011 01:40:33 +0200
Subject: [PATCH] Popraw gg_vsaprintf() dla nie-C99
---
src/common.c | 58 --
1 files changed, 28 insertions(+), 30 deletions(-)
diff --git a/src/common.c b/src/common.c
index 14eb5f3
To ja może podsumuję tutaj znane mi problemy pod MSVC i Win32 ogólnie:
- Na Win32 obecnie nie można polegać na errno, bo funkcje Windows
Sockets go nie ustawiają. Mam na to prawie gotową łatę w duchu
sugestii Wojtka z tego wątku.
- Na Win32 gniazda trzeba zamykać za pomocą closesocket(), ale plik
W dniu 28 października 2011 06:59 użytkownik Wojtek Kaniewski
napisał:
> 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 d
Cześć,
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 gg_dcc_free().
Pozdrawiam,
Bartosz
__
W dniu 25 października 2011 01:03 użytkownik Bartosz Brachaczek
napisał:
> Natomiast jeszcze została podobna kwestia write() vs
> send() w gg_resolver_run(), którego słusznie użyłeś w
> gg_resolver_win32_thread().
Teraz mnie oświeciło, że akurat tutaj można teraz bezpiecznie użyć
send
W dniu 25 października 2011 00:08 użytkownik Wojtek Kaniewski
napisał:
> 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
>> napisał:
>> > No tak, API. To trzeba będzie zrobi
W dniu 24 października 2011 07:28 użytkownik Wojtek Kaniewski
napisał:
> No tak, API. To trzeba będzie zrobić warunek, że ustawienie
> GG_RESOLVER_CUSTOM powoduje użycie read(), a wbudowane recv(), mimo że w
> praktyce pewnie nikt nigdy nie korzystał z oryginalnego libgadu na
> Win32.
Wówczas GG_
W dniu 23 października 2011 23:25 użytkownik Wojtek Kaniewski
napisał:
> 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(), bi
W dniu 21 października 2011 02:05 użytkownik Bartosz Brachaczek
napisał:
> W dniu 21 października 2011 00:03 użytkownik Wojtek Kaniewski
> napisał:
>> Dnia 2011-10-18, wto o godzinie 21:02 +0200, Bartosz Brachaczek pisze:
>>> Różnice między oryginalnym libgadu a naszym fork
W dniu 22 października 2011 02:31 użytkownik Tomasz Wasilczyk
napisał:
> W dniu 21 października 2011 23:17 użytkownik Wojtek Kaniewski
> napisał:
>> Jeśli jest FIONBIO, a nie ma ioctl() to prawdopodobnie powinniśmy użyć
>> ioctlsocket(). Mógłbyś sprawdzić, czy dodanie
>>
>> #define ioctl ioctlsoc
W dniu 21 października 2011 23:17 użytkownik Wojtek Kaniewski
napisał:
>> Prawdopodobnie w libgadu mógł by się przydać resolver dla win32, który
>> udało mi się wyciągnąć poza źródła libgadu dzięki dodaniu
>> gg_global_set_custom_resolver. Bo w tej chwili windowsowe buildy będą
>> bez żadnego. Ale
W dniu 21 października 2011 12:33 użytkownik Tomasz Wasilczyk
napisał:
> W dniu 21 października 2011 02:36 użytkownik Bartosz Brachaczek
> napisał:
>> (niestety nie wiem, na ile działa lub nie działa ten, który
>> znajduje się w naszym forku, ani nawet skąd on tam się wziął).
&
W dniu 21 października 2011 01:31 użytkownik Tomasz Wasilczyk
napisał:
> Prawdopodobnie w libgadu mógł by się przydać resolver dla win32, który
> udało mi się wyciągnąć poza źródła libgadu dzięki dodaniu
> gg_global_set_custom_resolver. Bo w tej chwili windowsowe buildy będą
> bez żadnego. Ale to
W dniu 21 października 2011 00:03 użytkownik Wojtek Kaniewski
napisał:
> Dnia 2011-10-18, wto o godzinie 21:02 +0200, Bartosz Brachaczek pisze:
>> Różnice między oryginalnym libgadu a naszym forkiem są dość spore i w
>> wielu miejscach nadmiarowe, ale kompiluje się on i działa na
W dniu 15 września 2011 01:18 użytkownik Bartosz Brachaczek
napisał:
> W dniu 3 września 2010 22:54 użytkownik Jakub Zawadzki
> napisał:
>>
>> Witam,
>>
>> Nieoficjalnym standardem[1] szyfrowania wiadomości w gg jest wykorzystanie
>> kluczy RSA w kodo
W dniu 19 października 2011 00:53 użytkownik Tomasz Wasilczyk
napisał:
> W dniu 18 października 2011 23:37 użytkownik Wojtek Kaniewski
> napisał:
>> Dnia 2011-10-13, czw o godzinie 03:22 +0200, Tomasz Wasilczyk pisze:
>>> Pytanie pierwsze: czy libgadu nie powinno udostępniać możliwości
>>> ustawi
W dniu 18 października 2011 16:41 użytkownik Tomasz Wasilczyk
napisał:
> Nie rozumiem tylko, w jaki sposób bez niektórych z tych zmian wychodzą
> np. nowe wersje Kadu pod Windows.
Kadu pod Windows ma własnego forka libgadu[1]. Z tego co wiem, część
kodu dla Windows została napisana parę lat temu
W dniu 11 października 2011 20:46 użytkownik Wojtek Kaniewski
napisał:
>> - zastanawiam się, po co kopiować zmienną ap do aq (zresztą jak nie ma
>> dostępnych funkcji do kopiowania, nasza funkcja tego po prostu nie
>> robi); Poza tym wywołanie vsnprintf na końcu w wersji patcha C jest
>> prawdopod
Witam,
Ostatnio zauważyłem, że na moim systemie test connect w losowym
momencie dostaje SIGABRT z glibc. Problem udało mi się powtórzyć na
kilku systemach (nie na wszystkich). Co ciekawe, pod valgrindem nie
mogłem powtórzyć tego problemu. Za to na wszystkich systemach, jakie
sprawdzałem, uruchomie
W dniu 6 września 2011 03:15 użytkownik Bartosz Brachaczek
napisał:
> Cześć,
>
> Myślę, że przyszedł czas, aby libgadu mogło umożliwiać wysyłanie
> wiadomości poprzez podanie bezpośrednio treści. Dzięki temu klienty
> będą mogły całkiem zapomnieć o starych atrybutach formatow
Cześć,
Nie jestem pewien, czy dobrze myślę, dlatego tutaj piszę. Wydaje mi
się, że libgadu wspiera używanie wersji starszych wersji protokołu
(konkretnie chodzi mi o <0x2d) z kodowaniem sesji UTF-8. Jeśli tak
jest, to funkcje gg_login() i gg_change_status_common() powinny w
takim przypadku dokonyw
W dniu 3 września 2010 22:54 użytkownik Jakub Zawadzki
napisał:
Witam,
Nieoficjalnym standardem[1] szyfrowania wiadomości w gg jest wykorzystanie
kluczy RSA w kodowaniu WINDOWS-1250.
W ekg2 jak implementowaliśmy obsługę UTF-8 w gg, niechcący zmieniliśmy
również kodowanie szyfrowanej wiadomości
W dniu 4 września 2011 17:33 użytkownik Jakub Zawadzki
napisał:
> On Thu, Sep 01, 2011 at 02:59:06AM +0200, Bartosz Brachaczek wrote:na
>> + const size_t color_size = 3;
>> ...
>> + if (*old_attr_flag != attr_flag || (has_color && memcmp(old_color,
>>
Cześć,
Myślę, że przyszedł czas, aby libgadu mogło umożliwiać wysyłanie
wiadomości poprzez podanie bezpośrednio treści. Dzięki temu klienty
będą mogły całkiem zapomnieć o starych atrybutach formatowania, a
także obsługiwać bardziej szczegółowe formatowanie, jeśli taka będzie
wola ich developerów.
Co prawda nie mam żadnego doświadczenia z architekturami big endian
i nie testowałem na takiej maszynie, ale ta poprawka wydaje mi się
w porządku. W każdym razie wydaje się nie psuć niczego na little endian.
Nie użyłem funkcji gg_fix16(), aby plik message.c pozostał niezależny
od zewnętrznego kodu
W dniu 4 września 2011 17:37 użytkownik Wojtek Kaniewski
napisał:
> Tak czy inaczej wszystkie patche miały pozamieniane tabulacje na spacje,
> więc nie było łatwo, ale pewnie nie czułbyś się całkiem komfortowo
> wysyłając poprawione ;)
Hm, dziwne. Specjalnie wysyłałem serię za pomocą git send-ema
W dniu 4 września 2011 17:36 użytkownik Wojtek Kaniewski
napisał:
> 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 =
Cześć,
Zauważyłem, że jeden kawałek kodu nie był pokryty żadnym testem. No i
oczywiście skrywał się tam dość głupi błąd. A że jakoś tak nie czułbym
się całkiem komfortowo spamując tę listę po raz kolejny nową wersją
serii łatek (a może jednak powinienem tak zrobić?), załączam tylko
tutaj łatkę na
---
src/message.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/message.c b/src/message.c
index 125cc72..7fc2145 100644
--- a/src/message.c
+++ b/src/message.c
@@ -393,7 +393,7 @@ size_t gg_message_text_to_html(char *dst, const char *src,
gg_encoding_t encodi
---
test/automatic/message2.c | 129 ++--
1 files changed, 111 insertions(+), 18 deletions(-)
diff --git a/test/automatic/message2.c b/test/automatic/message2.c
index e01f5fd..8add069 100644
--- a/test/automatic/message2.c
+++ b/test/automatic/message2.c
@
---
include/message.h |2 +-
src/libgadu.c |4 ++--
src/message.c | 25 -
test/automatic/message2.c |4 ++--
4 files changed, 17 insertions(+), 18 deletions(-)
diff --git a/include/message.h b/include/message.h
index 9d02baf..c
Dzięki tej zmianie formatowanie w odebranych wiadomościach m.in. od
Infobota jest poprawne.
---
src/handlers.c| 15 ---
test/automatic/script/20-messages.scr | 30 --
2 files changed, 28 insertions(+), 17 deletions(-)
diff --git
---
include/message.h |2 +-
src/handlers.c|4 +-
src/message.c | 237 +
test/automatic/message2.c |4 +-
4 files changed, 222 insertions(+), 25 deletions(-)
diff --git a/include/message.h b/include/message.h
---
src/message.c | 14 ++
test/automatic/message2.c | 99 +
2 files changed, 78 insertions(+), 35 deletions(-)
diff --git a/src/message.c b/src/message.c
index 7fc2145..7c35cb1 100644
--- a/src/message.c
+++ b/src/message.c
@@ -410,
---
src/message.c | 27 ---
test/automatic/message2.c | 14 +++---
test/automatic/script/20-messages.scr |2 +-
3 files changed, 24 insertions(+), 19 deletions(-)
diff --git a/src/message.c b/src/message.c
index 7c35cb1..
Ostatni z dodanych testów pokazuje dlaczego ta zmiana była konieczna.
Krótko mówiąc, oryginalny klient wcale nie gwarantuje, że prześle
atrybuty formatowania posortowane niemalejąco według pozycji w tekście,
jak do tej pory zakładaliśmy.
---
src/message.c | 79 +++
---
src/encoding.c |5 +
src/message.c | 18 +-
2 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/src/encoding.c b/src/encoding.c
index ef2ff5c..41822df 100644
--- a/src/encoding.c
+++ b/src/encoding.c
@@ -136,11 +136,8 @@ static char *gg_encoding_convert_u
W razie potrzeby konwertujemy przychodzącą wiadomość w czystym tekście
do HTML-a.
---
src/handlers.c | 31 ---
1 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/src/handlers.c b/src/handlers.c
index 9100e1b..764c5a0 100644
--- a/src/handlers.c
+++ b/src/
---
include/message.h |2 +-
src/libgadu.c |4 ++--
src/message.c | 11 ++-
test/automatic/message2.c |4 ++--
4 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/include/message.h b/include/message.h
index 824f1a8..9d02baf 100644
---
src/handlers.c | 27 +++
1 files changed, 23 insertions(+), 4 deletions(-)
diff --git a/src/handlers.c b/src/handlers.c
index 0377937..9100e1b 100644
--- a/src/handlers.c
+++ b/src/handlers.c
@@ -834,8 +834,10 @@ static int gg_session_handle_recv_msg(struct gg_sessio
---
src/handlers.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/src/handlers.c b/src/handlers.c
index bc442e8..0377937 100644
--- a/src/handlers.c
+++ b/src/handlers.c
@@ -790,7 +790,6 @@ static int gg_session_handle_recv_msg(struct gg_session
*sess, uint32_t type
Przesyłam serię ponownie. Jedyna zmiana to wycofanie z serii poprzedniego
patcha 08, bo okazał się zupełnie niepotrzeby, oraz dostosowanie dalszych
łatek, aby się poprawnie nakładały.
Pozdrawiam
Bartosz Brachaczek (13):
Usunięcie niepotrzebnej zmiennej
Bardziej zwracamy uwagę na
W dniu 31 sierpnia 2011 21:22 użytkownik Wojtek Kaniewski
napisał:
> Dnia 2011-08-31, śro o godzinie 16:51 +0200, Bartosz Brachaczek pisze:
>> ---
>> src/message.c | 20 ++--
>> 1 files changed, 10 insertions(+), 10 deletions(-)
>
> Nieźleee. Na 15
---
test/automatic/message2.c | 129 ++--
1 files changed, 111 insertions(+), 18 deletions(-)
diff --git a/test/automatic/message2.c b/test/automatic/message2.c
index e01f5fd..8add069 100644
--- a/test/automatic/message2.c
+++ b/test/automatic/message2.c
@
Dzięki tej zmianie formatowanie w odebranych wiadomościach m.in. od
Infobota jest poprawne.
---
src/handlers.c| 15 ---
test/automatic/script/20-messages.scr | 30 --
2 files changed, 28 insertions(+), 17 deletions(-)
diff --git
---
include/message.h |2 +-
src/handlers.c|4 +-
src/message.c | 237 +
test/automatic/message2.c |4 +-
4 files changed, 222 insertions(+), 25 deletions(-)
diff --git a/include/message.h b/include/message.h
---
include/message.h |2 +-
src/libgadu.c |4 ++--
src/message.c | 25 -
test/automatic/message2.c |4 ++--
4 files changed, 17 insertions(+), 18 deletions(-)
diff --git a/include/message.h b/include/message.h
index 9d02baf..c
---
src/message.c | 27 ---
test/automatic/message2.c | 14 +++---
test/automatic/script/20-messages.scr |2 +-
3 files changed, 24 insertions(+), 19 deletions(-)
diff --git a/src/message.c b/src/message.c
index 2048934..
---
src/message.c | 14 ++
test/automatic/message2.c | 99 +
2 files changed, 78 insertions(+), 35 deletions(-)
diff --git a/src/message.c b/src/message.c
index 0cb8ef1..2048934 100644
--- a/src/message.c
+++ b/src/message.c
@@ -410,
---
src/message.c | 20 ++--
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/src/message.c b/src/message.c
index 7fc2145..0cb8ef1 100644
--- a/src/message.c
+++ b/src/message.c
@@ -467,7 +467,7 @@ size_t gg_message_text_to_html(char *dst, const char *src,
gg_enc
W razie potrzeby konwertujemy przychodzącą wiadomość w czystym tekście
do HTML-a.
---
src/handlers.c | 31 ---
1 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/src/handlers.c b/src/handlers.c
index 9100e1b..764c5a0 100644
--- a/src/handlers.c
+++ b/src/
---
src/message.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/message.c b/src/message.c
index 125cc72..7fc2145 100644
--- a/src/message.c
+++ b/src/message.c
@@ -393,7 +393,7 @@ size_t gg_message_text_to_html(char *dst, const char *src,
gg_encoding_t encodi
---
include/message.h |2 +-
src/libgadu.c |4 ++--
src/message.c | 11 ++-
test/automatic/message2.c |4 ++--
4 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/include/message.h b/include/message.h
index 824f1a8..9d02baf 100644
Ostatni z dodanych testów pokazuje dlaczego ta zmiana była konieczna.
Krótko mówiąc, oryginalny klient wcale nie gwarantuje, że prześle
atrybuty formatowania posortowane niemalejąco według pozycji w tekście,
jak do tej pory zakładaliśmy.
---
src/message.c | 79 +++
---
src/handlers.c | 27 +++
1 files changed, 23 insertions(+), 4 deletions(-)
diff --git a/src/handlers.c b/src/handlers.c
index 0377937..9100e1b 100644
--- a/src/handlers.c
+++ b/src/handlers.c
@@ -834,8 +834,10 @@ static int gg_session_handle_recv_msg(struct gg_sessio
1 - 100 of 127 matches
Mail list logo
