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.
>> Próbowałem uż
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.
> Próbowałem używać libgadu skompilowanego z MSVC z własnym systemem
> budowania (nawet
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ż działa).
>> Ja mam
On Sat, Oct 29, 2011 at 07:26:59PM +0200, Wojtek Kaniewski wrote:
> Dnia 2011-10-29, sob o godzinie 03:11 +0200, Bartosz Brachaczek pisze:
> > - MSVC odmawia kompilacji pustej struktury gg_dcc7_dunno1. Jak dla
> > mnie można by ją spokojnie usunąć lub zakomentować.
>
> Chętnie bym to usunął, ale 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ę skomp
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
> nic nie stoi
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
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
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(), bo ta fu
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ć warunek, że ustawienie
>> > GG_RES
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ć warunek, że ustawienie
> > GG_RESOLVER_CUSTOM powoduje użycie read(), a wbudowane recv(), mimo że w
> > praktyc
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_
Dnia 2011-10-24, pon o godzinie 00:04 +0200, Bartosz Brachaczek pisze:
> W r1192 chyba zapomniałeś wkomitować network.c ;).
Ups.
> Poza tym w tych
> miejscach z read()/write(), które dotykała łatka z mojej poprzedniej
> wiadomości, nadal jest potrzebne recv()/send(), aby to działało na
> Win32 (
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(), bind(),
>> accept() itd
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() + gg
Hej,
Ponadto z read()/write() vs recv()/send() jest jeszcze jeden problem.
Mianowicie pipe'y w resolverze w forkach libpurple oraz Kadu są
zrealizowane za pomocą socketów, a nie windowsowych pipe'ów. Nie
sprawdzałem, czy to faktycznie konieczne, ale zgodnie z komentarzem do
funkcji socket_pipe()
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 forkiem są dość spore i w
>
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ł:
> Jeśli jest FIONBIO, a nie ma ioctl() to prawdopodobnie powinniśmy użyć
> ioctlsocket(). Mógłbyś sprawdzić, czy dodanie
>
> #define ioctl ioctlsocket
>
> do network.h pomoże?
Pomogło, tzn. kod się kompiluje. Ale znowu rzuca w
On Thursday, 20 October 2011 at 23:16, Wojtek Kaniewski wrote:
> Dnia 2011-10-20, czw o godzinie 22:10 +0200, Tomasz Wasilczyk pisze:
> > (ciach)
[...]
> że nie ma żadnego standardowego pliku nagłówkowego z intX_t. Ale skoro
> nie używamy intX_t, to można wyrzucić, bo to pochodziło z jakiegoś
> aut
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
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
> 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, ale libgadu ją
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ął).
>
> To jest ten sam
Z tego co pamiętam to ten resolver został napisany przez pierwszego
dewelopera obsługi GG w Pidginie na potrzeby kompilacji komunikatora pod
cygwinem dawno temu i od tego czasu raczej nie był ruszany. Później ja
go przepisałem w trakcie update'u wewnętrznej wersji libgadu kiedy
wprowadzałem pie
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ął).
To jest ten sam co w libpurple (nawet w komentarzu jest to
wspomniane), ale już na pierwszy rzut
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 01:31 użytkownik Tomasz Wasilczyk
napisał:
> Po zaaplikowaniu załączonego patcha wszystko w folderze src kompiluje
> się bez żadnych warningów
Już zasypiałem, jak mi się przypomniało, że przeoczyłem jeszcze jedną
konieczną dla Win32 zmianę (svn diff mi jej nie złapał,
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 nawet pod
>> MSVC.
>
W dniu 20 października 2011 23:16 użytkownik Wojtek Kaniewski
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, ale libgadu ją wykorzystuje
(src/common.c:267), a cygwin nie dostarcza.
> Trochę poprawiłem Two
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 nawet pod
> MSVC.
Bardzo spore. Na początek pozamieniałem socketowe write() i read() na
send()
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
W dniu 18 października 2011 16:41 użytkownik Tomasz Wasilczyk
napisał:
> Zmiana, do której nie jestem całkowicie przekonany: implementacja
> getsockopt i ioctl wyciągnięta z libpurple. To chyba wymaga
> dopracowania.
Po przemyśleniu, jednak wywaliłem to całkiem z patcha, jako że nie mam
tego nawe
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
Cześć,
właśnie pracuję nad zmniejszeniem liczby różnic libpurplowego forka z
oryginalnym libgadu, dzięki czemu może docelowo uda się z niego
całkiem zrezygnować. Sporo już tych różnic powycinałem, ale - tak jak
poprzednio - niektóre chyba powinny być pchnięte z powrotem do
upstream-libgadu. Sporo
34 matches
Mail list logo
