🚀 go-pugleaf

Derek Kuliński / takeda wrote:
> Czy ktoś kiedyś spróbował napisać moduł który zaimplementował by obsługę GG
> w tcl'u?
> 
> Teoretycznie nie powinno być z tym problemów, libgg z ekg ma chyba całą
> potrzebną funkcjonalność więc wystarczy jakiś wrapper który dodałby
> odpowiednie polecenia do tcl.
> 
> Pytam się tutaj, bo jeżeli coś takiego już jest to szkoda to robić ponownie
> :)

Kiedyś myślałem czy czegoś takiego nie zrobić, ale ostatecznie się za to 
nie wziąłem. Myślę że bardzo łatwo i szybko zrobiło by się to za pomocą 
swig'a, ale niestety przeniósł by on po prostu funkcje z C to Tcl, a 
lepiej napisać rozszerzenie, które upraszcza obsługę protokołu - tak, 
żeby komendy z tego pakietu były analogiczne do pozostałych znanych z Tcl.

Jeśli chciałbyś się za to zabrać, to służę radą.

-- 
Pozdrawiam!
Googie

On Mon, 09 Jan 2006 23:42:09 +0100, Derek Kuliński / takeda  
<d.kulinski@gmail.com> wrote:

> Czy ktoś kiedyś spróbował napisać moduł który zaimplementował by obsługę  
> GG
> w tcl'u?

Ja. Nawet ładne API to ma. Chętnie bym to komuś oddał, bo już mnie nie  
interesuje aż tak ten projekt, a jest zrobiony jako TEA2 albo TEA3 (czyli  
configure + make + make install i stubs :).

> Teoretycznie nie powinno być z tym problemów, libgg z ekg ma chyba całą
> potrzebną funkcjonalność więc wystarczy jakiś wrapper który dodałby
> odpowiednie polecenia do tcl.

Lepiej byłoby zrobić porządne API.

> Pytam się tutaj, bo jeżeli coś takiego już jest to szkoda to robić  
> ponownie
> :)

Kiedyś zacząłem, jest to tutaj:

http://www.zoro2.org/tclgg.tar.gz

Na ile to jeszcze w ogóle działa to nie mam pojęcia.

Jedynym prostym sposobem na dzielenie tcl event loop i libgg jest dodanie  
FD, a to niestety nie działa pod Windows.

Pod Windows byćmoże prościej byłoby stworzyć wątek, ale nie wiem jak to  
zrobić, żeby z nonthreaded Tcl nie robiło problemów.

-- 
WK

On Tue, 10 Jan 2006 08:31:45 +0100, Wojciech Kocjan wrote:

>> Czy ktoś kiedyś spróbował napisać moduł który zaimplementował by obsługę  
>> GG
>> w tcl'u?
> Ja. Nawet ładne API to ma. Chętnie bym to komuś oddał, bo już mnie nie  
> interesuje aż tak ten projekt, a jest zrobiony jako TEA2 albo TEA3 (czyli  
> configure + make + make install i stubs :).

No to pięknie.
BTW: pierwszy raz spotykam się z pojęciem TEA2, TEA3, co to?

>> Teoretycznie nie powinno być z tym problemów, libgg z ekg ma chyba całą
>> potrzebną funkcjonalność więc wystarczy jakiś wrapper który dodałby
>> odpowiednie polecenia do tcl.
> Lepiej byłoby zrobić porządne API.

Aktualnie potrzebne jest tylko odbieranie informacji (ewentualnie.
wysyłanie)

>> Pytam się tutaj, bo jeżeli coś takiego już jest to szkoda to robić  
>> ponownie
>> :)
> Kiedyś zacząłem, jest to tutaj:
> 
> http://www.zoro2.org/tclgg.tar.gz
> 
> Na ile to jeszcze w ogóle działa to nie mam pojęcia.

Emm... Dosyć zawiłe... :)))
Jeszcze nie do końca rozumiem kod... ale nie da się tego zrobić bez
używania threadów?

> Jedynym prostym sposobem na dzielenie tcl event loop i libgg jest dodanie  
> FD, a to niestety nie działa pod Windows.

FD = File Descriptor? Nie rozumiem...
Jeżeli chodzi o bardziej zaawansowane rzeczy jak theady to na razie nie
miałem okazji tego poznać.

> Pod Windows byćmoże prościej byłoby stworzyć wątek, ale nie wiem jak to  
> zrobić, żeby z nonthreaded Tcl nie robiło problemów.

Nie pomogę, bo nawet problemu nie rozumiem =)

-- 
ダレック
takeda@IRCnet.EFnet, ICQ# 15827691, YahooIM: takeda64
http://ircwiki.takeda.tk - strona wiki poświęcona IRC

On Tue, 10 Jan 2006 08:24:08 +0100, Googie wrote:

> Kiedyś myślałem czy czegoś takiego nie zrobić, ale ostatecznie się za to 
> nie wziąłem. Myślę że bardzo łatwo i szybko zrobiło by się to za pomocą 
> swig'a, ale niestety przeniósł by on po prostu funkcje z C to Tcl, a 
> lepiej napisać rozszerzenie, które upraszcza obsługę protokołu - tak, 
> żeby komendy z tego pakietu były analogiczne do pozostałych znanych z Tcl.

Właśnie, mógłbyś napisać coś więcej o tym Swig'u? Ja spotkałem się z tym
przy subversion, i zastanawiało mnie co to.
Ten post trochę rozjaśnił mi sytuację, ale nei do końca. To znaczy to jest
coś jak np. yacc czyli po prostu analizuje coś i na tej podstawie genruje
kod w C?

Czy po wygenerowaniu jest nadal potrzebny do używania czy ów kod już jest
samowystarczalny?

Może nie byłoby głupim pomysłem wygenerować ów kod, a później go podrasować
aby był wygodny w użyciu z poziomu Tcl'a...

> Jeśli chciałbyś się za to zabrać, to służę radą.

Dzięki zobaczę jeszcze jak kod Wojtka działa, zawsze prościej wprowadzić
zmiany do czyjegoś kodu niż robić wszystko od podstaw =)
Tak właściwie, to nie ja dokładnie tego potrzebuję tylko znajomy, który
czyta tą grupę ale wstydzi się zadać pytanie :>>

-- 
ダレック
takeda@IRCnet.EFnet, ICQ# 15827691, YahooIM: takeda64
http://ircwiki.takeda.tk - strona wiki poświęcona IRC

On Tue, 10 Jan 2006 22:12:13 +0100, Derek Kuliński / takeda  
<d.kulinski@gmail.com> wrote:
>> Ja. Nawet ładne API to ma. Chętnie bym to komuś oddał, bo już mnie nie
>> interesuje aż tak ten projekt, a jest zrobiony jako TEA2 albo TEA3  
>> (czyli
>> configure + make + make install i stubs :).
> No to pięknie.
> BTW: pierwszy raz spotykam się z pojęciem TEA2, TEA3, co to?

Tcl Extension Architecture. TEA2 to druga wersja, TEA3 to trzecia.

>>> Teoretycznie nie powinno być z tym problemów, libgg z ekg ma chyba całą
>>> potrzebną funkcjonalność więc wystarczy jakiś wrapper który dodałby
>>> odpowiednie polecenia do tcl.
>> Lepiej byłoby zrobić porządne API.
> Aktualnie potrzebne jest tylko odbieranie informacji (ewentualnie.
> wysyłanie)

No to to jest. Poczatować mi się udało. Ale to było daawno.

> Emm... Dosyć zawiłe... :)))
> Jeszcze nie do końca rozumiem kod... ale nie da się tego zrobić bez
> używania threadów?

To jest bez używania threadów, ale z kolei unix only.

-- 
WK

On Tue, 10 Jan 2006 22:12:14 +0100, Derek Kuliński / takeda  
<d.kulinski@gmail.com> wrote:

> On Tue, 10 Jan 2006 08:24:08 +0100, Googie wrote:
>
>> Kiedyś myślałem czy czegoś takiego nie zrobić, ale ostatecznie się za to
>> nie wziąłem. Myślę że bardzo łatwo i szybko zrobiło by się to za pomocą
>> swig'a, ale niestety przeniósł by on po prostu funkcje z C to Tcl, a
>> lepiej napisać rozszerzenie, które upraszcza obsługę protokołu - tak,
>> żeby komendy z tego pakietu były analogiczne do pozostałych znanych z  
>> Tcl.
>
> Właśnie, mógłbyś napisać coś więcej o tym Swig'u? Ja spotkałem się z tym
> przy subversion, i zastanawiało mnie co to.

Simplified Wrapper and Interface Generator :-)

> Ten post trochę rozjaśnił mi sytuację, ale nei do końca. To znaczy to  
> jest
> coś jak np. yacc czyli po prostu analizuje coś i na tej podstawie genruje
> kod w C?

Chyba możesz albo stworzyć plik .i z interfejsem albo on sam zanalizuje  
.c/.h.

> Czy po wygenerowaniu jest nadal potrzebny do używania czy ów kod już jest
> samowystarczalny?

On AFAIR generuje kod w C i nie jest potem potrzebny.

> Może nie byłoby głupim pomysłem wygenerować ów kod, a później go  
> podrasować
> aby był wygodny w użyciu z poziomu Tcl'a...

On nawet jest gotowy do użycia, ale zazwyczaj interfejsy pisane ręcznie są  
czytelniejsze w użyciu z poziomu Tcl... Tutaj dochodzi jeszcze integracja  
event loop Tcl z oczekiwaniem na zdarzenia gg.

>> Jeśli chciałbyś się za to zabrać, to służę radą.
> Dzięki zobaczę jeszcze jak kod Wojtka działa, zawsze prościej wprowadzić
> zmiany do czyjegoś kodu niż robić wszystko od podstaw =)
> Tak właściwie, to nie ja dokładnie tego potrzebuję tylko znajomy, który
> czyta tą grupę ale wstydzi się zadać pytanie :>>

Pozdrawiamy kolegę zza drzewa :-)

-- 
WK

On Tue, 10 Jan 2006 22:33:10 +0100, Wojciech Kocjan wrote:

>> Właśnie, mógłbyś napisać coś więcej o tym Swig'u? Ja spotkałem się z tym
>> przy subversion, i zastanawiało mnie co to.
> 
> Simplified Wrapper and Interface Generator :-)

LOL, jak bym znał pełną nazwę to bym tego pytania nie zadał =)))

> Chyba możesz albo stworzyć plik .i z interfejsem albo on sam zanalizuje  
> .c/.h.

Spróbuję się tym pobawić...

>> Może nie byłoby głupim pomysłem wygenerować ów kod, a później go  
>> podrasować
>> aby był wygodny w użyciu z poziomu Tcl'a...
> On nawet jest gotowy do użycia, ale zazwyczaj interfejsy pisane ręcznie są  
> czytelniejsze w użyciu z poziomu Tcl...

Ale później chyba otrzymany kod można jakoś dostosować?

> Tutaj dochodzi jeszcze integracja  
> event loop Tcl z oczekiwaniem na zdarzenia gg.

Nie prościej napisać polecenie, które sprawdza czy jest coś nowego i dać
aby skrypt się o to martwił?

-- 
ダレック
takeda@IRCnet.EFnet, ICQ# 15827691, YahooIM: takeda64
http://ircwiki.takeda.tk - strona wiki poświęcona IRC

On Tue, 10 Jan 2006 22:29:41 +0100, Wojciech Kocjan wrote:

>> No to pięknie.
>> BTW: pierwszy raz spotykam się z pojęciem TEA2, TEA3, co to?
> Tcl Extension Architecture. TEA2 to druga wersja, TEA3 to trzecia.

To jest coś związanego ze stubsami?

>>> Lepiej byłoby zrobić porządne API.
>> Aktualnie potrzebne jest tylko odbieranie informacji (ewentualnie.
>> wysyłanie)
> No to to jest. Poczatować mi się udało. Ale to było daawno.

No to być może wystarczy =)

>> Emm... Dosyć zawiłe... :)))
>> Jeszcze nie do końca rozumiem kod... ale nie da się tego zrobić bez
>> używania threadów?
> To jest bez używania threadów, ale z kolei unix only.

To nie ma znaczenia, bo w sumie chodzi o użycie tego w skrypcie Tcl na
eggdropie (który raczej nie będzie na windowsie). Przypuszczam, że albo
chodzi o wydawanie poleceń botu, albo jako kolejny interfejs (poza IRC) do
gry którą znajomy mówił, że pisze.

-- 
ダレック
takeda@IRCnet.EFnet, ICQ# 15827691, YahooIM: takeda64
http://ircwiki.takeda.tk - strona wiki poświęcona IRC

Derek Kuliński / takeda wrote:
> Właśnie, mógłbyś napisać coś więcej o tym Swig'u?

Tworzy gotowy kod C do skompilowania i zlinkowania z "wrappowaną" 
biblioteką. Potem można to załadować w Tcl i używać funkcji 
zwrappowanych. Jest to proste, ale niestety nieefektywne, bo np:

struct jakas_struktura
{
     int a;
     char* b;
     double c;
}

Stworzy w interpreterze Tcl komendę 'jakas_struktura' i metody dla tej 
struktury: get_a, set_a, get_b, set_b, get_c, set_c (nie pamietam 
dokladnie nazw getterow i setterow, ale z grubsza o to chodzi) i jeśli 
jakaś metoda korzysta z tej struktury, powiedzmy:

komenda <argument tej struktury>

to trzeba w Tclu pisać:

jakas_struktura s
s set_a 325
s set_b "hsfh"
s set_c 345.4567
komenda s

Wiec nie jest to zbyt wygodne. Zaletą jest fakt, że swig generuje od 
razu sprawdzanie typów (czyli jeśli komenda otrzyma coś innego niż 
jakas_struktura, to wyrzuci błąd).

Inną zaletą swig'a jest to, że obsługuje też IncrTcl - generuje od razu 
klasy Itcl dla klas C++.

Kiedyś chciałem zrobić bindy Qt dla Tcl'a przy pomocy swiga, ale 
niestety Qt jest zbyt zaawansowaną biblioteką, trzeba by skrupulatnie 
pisać interfejsy (próbowałem po prostu przelecieć wszystkie nagłówki 
swig'iem, jak leci - były błędy :) ). Natomiast udało mi się bez 
problemów zrobić bindy do libaa, libcaca, oraz libSDL (w tym SDL_mixer, 
SDL_ttf i jakieś tam inne jeszcze), tyle że uznałem że takie interfejsy 
są bez sensu - wytłumaczyłem to powyżej - za dużo kodu Tcl trzeba pisać. 
Tcl to nie C/C++, Tcl ma być szybki i wygodny :)

-- 
Pozdrawiam!
Googie

On Wed, 11 Jan 2006 00:45:51 +0100, Derek Kuliński / takeda  
<d.kulinski@gmail.com> wrote:

> On Tue, 10 Jan 2006 22:29:41 +0100, Wojciech Kocjan wrote:
>
>>> No to pięknie.
>>> BTW: pierwszy raz spotykam się z pojęciem TEA2, TEA3, co to?
>> Tcl Extension Architecture. TEA2 to druga wersja, TEA3 to trzecia.
> To jest coś związanego ze stubsami?

Też. To są szkielety (configure.in, Makefile.in i struktury katalogów) do  
budowania rozszerzeń (.dll/.so). Założenie jest takie, że takie coś działa  
z unixami/windows+msvc/windows+mingw/windows+cygwin/macos/macosx bez  
problemów i autor skupia się na kodzie, a nie na budowaniu. No i łatwiej  
wtedy dostosować się do podejścia Tcl - katalogi generic, unix, windows,  
mac.

>>>> Lepiej byłoby zrobić porządne API.
>>> Aktualnie potrzebne jest tylko odbieranie informacji (ewentualnie.
>>> wysyłanie)
>> No to to jest. Poczatować mi się udało. Ale to było daawno.
> No to być może wystarczy =)

To daj znać czy działa.

>>> Emm... Dosyć zawiłe... :)))
>>> Jeszcze nie do końca rozumiem kod... ale nie da się tego zrobić bez
>>> używania threadów?
>> To jest bez używania threadów, ale z kolei unix only.
>
> To nie ma znaczenia, bo w sumie chodzi o użycie tego w skrypcie Tcl na
> eggdropie (który raczej nie będzie na windowsie). Przypuszczam, że albo
> chodzi o wydawanie poleceń botu, albo jako kolejny interfejs (poza IRC)  
> do gry którą znajomy mówił, że pisze.

To może Jabber?

http://tkabber.jabber.ru/ - tam chyba jest m.in. biblioteka do obsługi  
Jabbera. Powinna działać z eggdropem, jeśli eggdrop będzie chciał :-)

ps. Nie żebym się czepiał, ale nie lepiej zrobić np daemon gry i frontend  
do gg/irc/jabber/www/whatever? :-)

-- 
WK

On Wed, 11 Jan 2006 00:45:50 +0100, Derek Kuliński / takeda  
<d.kulinski@gmail.com> wrote:
>>> Może nie byłoby głupim pomysłem wygenerować ów kod, a później go
>>> podrasować
>>> aby był wygodny w użyciu z poziomu Tcl'a...
>> On nawet jest gotowy do użycia, ale zazwyczaj interfejsy pisane ręcznie  
>> są
>> czytelniejsze w użyciu z poziomu Tcl...
> Ale później chyba otrzymany kod można jakoś dostosować?

Można, ale chyba swig preferuje podejście "my zrobimy wszystko i jak coś  
to już nie tykaj". Poza tym wtedy prościej zmieniać interfejs w  
C/C++ jeśli automat nadal wygeneruje całość :-)

>> Tutaj dochodzi jeszcze integracja
>> event loop Tcl z oczekiwaniem na zdarzenia gg.
> Nie prościej napisać polecenie, które sprawdza czy jest coś nowego i dać
> aby skrypt się o to martwił?

Nie. Porządne rozszerzenia albo integrują się z eventloopem (nawet eggdrop  
to zrobił :-). Albo z timerem albo w tym przypadku z obsługą socketów.

-- 
WK

Derek Kuliński / takeda wrote:

> Może nie byłoby głupim pomysłem wygenerować ów kod, a później go podrasować
> aby był wygodny w użyciu z poziomu Tcl'a...

To nie jest zalecane z dwóch powodów:

1. SWIG wcale nie stara się generować czytelnego kodu, więc 
podrasowywanie go nie jest wcale przyjemne.

2. Kodu generowanego w ogóle nie powinno się dotykać - jakakolwiek 
zmiana w źródle (czyli w tym przypadku w bibliotece C/C++) i SWIG 
generuje wszystko od nowa. Wtedy czas spędzony na podrasowywaniu jego 
poprzedniego wyniku jest stracony.


Do integrowania kodu C/C++ z Tcl polecam:

http://cpptcl.sourceforge.net/

Nie jest to automat i trzeba trochę napisać. Ale po pierwsze niedużo, po 
drugie właśnie wtedy jest okazja, żeby coś zmienić albo nagiąć pod kątem 
Tcla.


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Maciej Sobczak wrote:
> Do integrowania kodu C/C++ z Tcl polecam:
> 
> http://cpptcl.sourceforge.net/
> 
> Nie jest to automat i trzeba trochę napisać. Ale po pierwsze niedużo, po 
> drugie właśnie wtedy jest okazja, żeby coś zmienić albo nagiąć pod kątem 
> Tcla.

Ale czy cpptcl nie służy do używania bibliotek na poziomie Tcl? Bo - tak 
tylko dla pewności mówię - my tu dywagujemy o użyciu C/C++ w Tcl.


-- 
Pozdrawiam!
Googie

On Wed, 11 Jan 2006 17:49:25 +0100, Googie <no@spam.org> wrote:
> Maciej Sobczak wrote:
>> Do integrowania kodu C/C++ z Tcl polecam:
>>  http://cpptcl.sourceforge.net/
>>  Nie jest to automat i trzeba trochę napisać. Ale po pierwsze niedużo,  
>> po drugie właśnie wtedy jest okazja, żeby coś zmienić albo nagiąć pod  
>> kątem Tcla.
>
> Ale czy cpptcl nie służy do używania bibliotek na poziomie Tcl? Bo - tak  
> tylko dla pewności mówię - my tu dywagujemy o użyciu C/C++ w Tcl.

Possibility to define classes and class member functions, visible in Tcl  
in the style similar to SWIG wrappers.

Nie mam pytań :-)

-- 
WK

Googie wrote:

>> Do integrowania kodu C/C++ z Tcl polecam:
>>
>> http://cpptcl.sourceforge.net/
>>
>> Nie jest to automat i trzeba trochę napisać. Ale po pierwsze niedużo, 
>> po drugie właśnie wtedy jest okazja, żeby coś zmienić albo nagiąć pod 
>> kątem Tcla.
> 
> Ale czy cpptcl nie służy do używania bibliotek na poziomie Tcl? Bo - tak 
> tylko dla pewności mówię - my tu dywagujemy o użyciu C/C++ w Tcl.

Co to znaczy "użyciu C/C++ w Tcl"? Chyba nie chodzi o mieszanie składni 
dwóch języków w jednym pliku (chociaż da się użyć Tcl w C++, patrz niżej)?

C++/Tcl umożliwia przede wszystkim to, co SWIG - czyli zrobienie z 
istniejącego kodu C++ (np. z jakiejś gotowej biblioteki) modułu 
ładowalnego (albo nawet pakietu), który będzie używalny w Tcl w tym 
sensie, że w Tcl będą dostępne nowe komendy, automatycznie związane z 
kodem w C++.

Tutaj:

http://cpptcl.sourceforge.net/doc/quickstart.html

w pierwszym przykładzie jest pokazane, jak w Tcl zrobić polecenie hello, 
któro wywołuje istniejącą funkcję C++.

Można też zrobić coś, co zdaje się w SWIGu nie jest możliwe (ale nie 
sprawdzałem) - zagnieździć interpreter Tcl w programie C++ tak, że jedno 
i drugie będzie miało nawzajem dostęp do swoich struktur. Pokazuje to 
drugi przykład na tej samej stronie.

A konkretnie (w praktyce): kolega z pracy ma jakieś cyfrowe oscyloskopy, 
obsługiwane przez sieć przy użyciu biblioteki w C/C++ dostarczonej przez 
producenta tych oscyloskopów. Krótki dodatkowy plik z kilkoma wrapperami 
i jednym blokiem CPPTCL_MODULE pozwolił na stworzenie modułu ładowalnego 
do Tcl, dzięki czemu kolega może sobie teraz pisać skrypty diagnostyczne 
w Tcl (albo nawet pisać je na bieżąco w konsoli z tclsh), co jest dużo 
prostsze, niż pełny cykl tworzenia nawet krótkiego programu w C++.

Nie wiem co to ten libgg, ale też się da. :)

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

On Wed, 11 Jan 2006 14:49:24 +0100, Maciej Sobczak wrote:

> Do integrowania kodu C/C++ z Tcl polecam:
> 
> http://cpptcl.sourceforge.net/
> 
> Nie jest to automat i trzeba trochę napisać. Ale po pierwsze niedużo, po 
> drugie właśnie wtedy jest okazja, żeby coś zmienić albo nagiąć pod kątem 
> Tcla.

http://cpptcl.sourceforge.net/doc/quickstart.html
Niezłe - ląduje do moich bookmarków :)

Chociaż nie pokazali jak w tym przekazuje się informacje (argumenty do
funkcji, zwraca wynik itp), bo w sumie samo podpięcie poleceń też nie jest
takie skomplikowane w zwykłym C.

-- 
ダレック
takeda@IRCnet.EFnet, ICQ# 15827691, YahooIM: takeda64
http://ircwiki.takeda.tk - strona wiki poświęcona IRC

On Wed, 11 Jan 2006 08:47:18 +0100, Googie wrote:

> struct jakas_struktura
> {
>      int a;
>      char* b;
>      double c;
> }
> 
> Stworzy w interpreterze Tcl komendę 'jakas_struktura' i metody dla tej 
> struktury: get_a, set_a, get_b, set_b, get_c, set_c (nie pamietam 
> dokladnie nazw getterow i setterow, ale z grubsza o to chodzi) i jeśli 
> jakaś metoda korzysta z tej struktury, powiedzmy:
> 
> komenda <argument tej struktury>
> 
> to trzeba w Tclu pisać:
> 
> jakas_struktura s
> s set_a 325
> s set_b "hsfh"
> s set_c 345.4567
> komenda s
> 
> Wiec nie jest to zbyt wygodne.

Można w sumie napisać funkcję, która będzie te czynności wykonywała... Ale
może faktycznie lepiej zrobić to ręcznie...

> Zaletą jest fakt, że swig generuje od 
> razu sprawdzanie typów (czyli jeśli komenda otrzyma coś innego niż 
> jakas_struktura, to wyrzuci błąd).
> 
> Inną zaletą swig'a jest to, że obsługuje też IncrTcl - generuje od razu 
> klasy Itcl dla klas C++.
> 
> Kiedyś chciałem zrobić bindy Qt dla Tcl'a przy pomocy swiga, ale 
> niestety Qt jest zbyt zaawansowaną biblioteką, trzeba by skrupulatnie 
> pisać interfejsy (próbowałem po prostu przelecieć wszystkie nagłówki 
> swig'iem, jak leci - były błędy :) ). Natomiast udało mi się bez 
> problemów zrobić bindy do libaa, libcaca, oraz libSDL (w tym SDL_mixer, 
> SDL_ttf i jakieś tam inne jeszcze), tyle że uznałem że takie interfejsy 
> są bez sensu - wytłumaczyłem to powyżej - za dużo kodu Tcl trzeba pisać. 
> Tcl to nie C/C++, Tcl ma być szybki i wygodny :)

Eee szybki to ma być C, Tcl najwyżej wygodny :))

-- 
ダレック
takeda@IRCnet.EFnet, ICQ# 15827691, YahooIM: takeda64
http://ircwiki.takeda.tk - strona wiki poświęcona IRC

On Wed, 11 Jan 2006 09:39:16 +0100, Wojciech Kocjan wrote:

> Też. To są szkielety (configure.in, Makefile.in i struktury katalogów) do  
> budowania rozszerzeń (.dll/.so). Założenie jest takie, że takie coś działa  
> z unixami/windows+msvc/windows+mingw/windows+cygwin/macos/macosx bez  
> problemów i autor skupia się na kodzie, a nie na budowaniu. No i łatwiej  
> wtedy dostosować się do podejścia Tcl - katalogi generic, unix, windows,  
> mac.

Ok... czyli ten kod to nie jest całość...
Bo właśnie te pliki makefile makra itp strasznie zniechęciły do dalszego
analizowania =)

>>> No to to jest. Poczatować mi się udało. Ale to było daawno.
>> No to być może wystarczy =)
> To daj znać czy działa.

Działa fajnie, ale hmm dlatego, że użyłeś TEA sprawia wrażenie
nieczytelnego (dla mnie).
Nie wiem czy jestem w stanie opanować ten kod aby móc wprowadzić jakieś
zmiany...

>> To nie ma znaczenia, bo w sumie chodzi o użycie tego w skrypcie Tcl na
>> eggdropie (który raczej nie będzie na windowsie). Przypuszczam, że albo
>> chodzi o wydawanie poleceń botu, albo jako kolejny interfejs (poza IRC)  
>> do gry którą znajomy mówił, że pisze.
> To może Jabber?
> 
> http://tkabber.jabber.ru/ - tam chyba jest m.in. biblioteka do obsługi  
> Jabbera. Powinna działać z eggdropem, jeśli eggdrop będzie chciał :-)
> 
> ps. Nie żebym się czepiał, ale nie lepiej zrobić np daemon gry i frontend  
> do gg/irc/jabber/www/whatever? :-)

Aaaa... to już nie do mnie to pytanie. :)

-- 
ダレック
takeda@IRCnet.EFnet, ICQ# 15827691, YahooIM: takeda64
http://ircwiki.takeda.tk - strona wiki poświęcona IRC

On Wed, 11 Jan 2006 09:41:27 +0100, Wojciech Kocjan wrote:

> Można, ale chyba swig preferuje podejście "my zrobimy wszystko i jak coś  
> to już nie tykaj". Poza tym wtedy prościej zmieniać interfejs w  
> C/C++ jeśli automat nadal wygeneruje całość :-)

:)

> Nie. Porządne rozszerzenia albo integrują się z eventloopem (nawet eggdrop  
> to zrobił :-). Albo z timerem albo w tym przypadku z obsługą socketów.

Ale eggdrop jest ciut inaczej. Tcl jest dołączony do eggdropa a nie eggdrop
do tcl'a. Eggdrop ma swoją pętlę i jedną z czynności w tej pętlijest
wywołanie tcl'owej :)

A moduł to nie wiem... no chyba że można jakoś podłączyć kod do tcl'owej
pętli?

-- 
ダレック
takeda@IRCnet.EFnet, ICQ# 15827691, YahooIM: takeda64
http://ircwiki.takeda.tk - strona wiki poświęcona IRC

On Thu, 12 Jan 2006 10:25:53 +0100, Maciej Sobczak wrote:

> Nie wiem co to ten libgg, ale też się da. :)

Tutaj jest trochę:
http://dev.null.pl/ekg/docs/api.txt

-- 
ダレック
takeda@IRCnet.EFnet, ICQ# 15827691, YahooIM: takeda64
http://ircwiki.takeda.tk - strona wiki poświęcona IRC

On Fri, 13 Jan 2006 00:16:02 +0100, Derek Kuliński / takeda  
<d.kulinski@gmail.com> wrote:
>> Też. To są szkielety (configure.in, Makefile.in i struktury katalogów)  
>> do
>> budowania rozszerzeń (.dll/.so). Założenie jest takie, że takie coś  
>> działa
>> z unixami/windows+msvc/windows+mingw/windows+cygwin/macos/macosx bez
>> problemów i autor skupia się na kodzie, a nie na budowaniu. No i łatwiej
>> wtedy dostosować się do podejścia Tcl - katalogi generic, unix, windows,
>> mac.
> Ok... czyli ten kod to nie jest całość...
> Bo właśnie te pliki makefile makra itp strasznie zniechęciły do dalszego
> analizowania =)

Wystarczy autoconf.in zmienić i Makefile można w mniejszym stopniu znać.  
To też plus.

A struktura jaką "promuje" Tcl jest taka:

generic/ - kod niezależny od platformy (u mnie wszystko prawie :-)
unix/ - kod typowy dla Unixów (u mnie obsługa zdarzeń)
win/ - kod typowy dla Windows (u mnie pustka :-)

Spójrz do tls, tktable czy wielu innych rozszerzeń. To jest 'trendy', a i  
oszczędza czas przy późniejszym portowaniu np do Windows (nie trzeba  
owarunkowywać Makefile'i).

>>>> No to to jest. Poczatować mi się udało. Ale to było daawno.
>>> No to być może wystarczy =)
>> To daj znać czy działa.
> Działa fajnie, ale hmm dlatego, że użyłeś TEA sprawia wrażenie
> nieczytelnego (dla mnie).
> Nie wiem czy jestem w stanie opanować ten kod aby móc wprowadzić jakieś
> zmiany...

Dlaczego. Cały kod, który Cię interesuje to generic/tclgg*.[ch]. Reszta to  
libgadu i TEA.

Większość rozszerzeń Tcl jest w ten sposób tworzona.

-- 
WK

On Fri, 13 Jan 2006 00:16:03 +0100, Derek Kuliński / takeda  
<d.kulinski@gmail.com> wrote:
>> Nie. Porządne rozszerzenia albo integrują się z eventloopem (nawet  
>> eggdrop
>> to zrobił :-). Albo z timerem albo w tym przypadku z obsługą socketów.
>
> Ale eggdrop jest ciut inaczej. Tcl jest dołączony do eggdropa a nie  
> eggdrop
> do tcl'a. Eggdrop ma swoją pętlę i jedną z czynności w tej pętlijest
> wywołanie tcl'owej :)

Zgadza się. Ale jeśli on się z nią integruje to lepiej zrobić kod, który  
integruje się z tą pętlą niż z eggdropem. Wtedy można go poza eggdropem  
też wykorzystać...

> A moduł to nie wiem... no chyba że można jakoś podłączyć kod do tcl'owej
> pętli?

Jest cały duży dokument (na SF chyba) o tym jak działa pętla Tcl i na ile  
sposobów można coś do niej dodać. Ale to chyba nie to co chcesz osiągnąć  
tak na prawdę. To już tylko dyskusja akademicka :-)

-- 
WK

Derek Kuliński / takeda napisał(a):
> Eee szybki to ma być C, Tcl najwyżej wygodny :))
> 

Miałem na myśli szybkość pisania kodu :)

-- 
Pozdrawiam!
Googie

Derek Kuliński / takeda napisał(a):
> Chociaż nie pokazali

cpptcl jest autorstwa jednej osoby. Macieja Sobczaka :)

-- 
Pozdrawiam!
Googie

On Fri, 13 Jan 2006 08:22:53 +0100, Wojciech Kocjan wrote:

>>> Nie. Porządne rozszerzenia albo integrują się z eventloopem (nawet  
>>> eggdrop
>>> to zrobił :-). Albo z timerem albo w tym przypadku z obsługą socketów.
>> Ale eggdrop jest ciut inaczej. Tcl jest dołączony do eggdropa a nie  
>> eggdrop
>> do tcl'a. Eggdrop ma swoją pętlę i jedną z czynności w tej pętlijest
>> wywołanie tcl'owej :)
> Zgadza się. Ale jeśli on się z nią integruje to lepiej zrobić kod, który  
> integruje się z tą pętlą niż z eggdropem. Wtedy można go poza eggdropem  
> też wykorzystać...

No tak ale mi chodziło że umieszczenie tcla w programie to coś nnego niż
umieszczenie programu (modułu) w tclu.

Tzn. nadal nie wiem jak podpiąć coś pod tcl'ową pętlę z poziomu modułu, ale
czuję że odpowiedź jest w Twoim tclgg muszę go dokładniej przejrzeć.

Zgaduję, że to jest tutaj:
void tclggpWatchSession(Tcl_Interp *interp, struct tclgg_session *session)
{
    Tcl_CreateFileHandler(session->session->fd, TCL_READABLE,
handlereadable, (ClientData) session);
}

PS co oznaczją /* {{{ */  i  /* }}} */ w Twoim kodzie?



>> A moduł to nie wiem... no chyba że można jakoś podłączyć kod do tcl'owej
>> pętli?
> Jest cały duży dokument (na SF chyba) o tym jak działa pętla Tcl i na ile  
> sposobów można coś do niej dodać. Ale to chyba nie to co chcesz osiągnąć  
> tak na prawdę. To już tylko dyskusja akademicka :-)

:))
-- 
ダレック
takeda@IRCnet.EFnet, ICQ# 15827691, YahooIM: takeda64
http://ircwiki.takeda.tk - strona wiki poświęcona IRC

On Fri, 13 Jan 2006 08:42:34 +0100, Googie wrote:

>> Chociaż nie pokazali
> cpptcl jest autorstwa jednej osoby. Macieja Sobczaka :)

... chociaż nie pokazał ...
pasuje? ;)

-- 
ダレック
takeda@IRCnet.EFnet, ICQ# 15827691, YahooIM: takeda64
http://ircwiki.takeda.tk - strona wiki poświęcona IRC

On Fri, 13 Jan 2006 08:19:26 +0100, Wojciech Kocjan wrote:

> Wystarczy autoconf.in zmienić i Makefile można w mniejszym stopniu znać.  
> To też plus.

Miałeś na myśli configure.in i Makefile.in ?

> A struktura jaką "promuje" Tcl jest taka:
> 
> generic/ - kod niezależny od platformy (u mnie wszystko prawie :-)
> unix/ - kod typowy dla Unixów (u mnie obsługa zdarzeń)
> win/ - kod typowy dla Windows (u mnie pustka :-)
> 
> Spójrz do tls, tktable czy wielu innych rozszerzeń. To jest 'trendy', a i  
> oszczędza czas przy późniejszym portowaniu np do Windows (nie trzeba  
> owarunkowywać Makefile'i).

Ja rozumiem to, tylko ten sposób sprawił że mały kod wygląda jak jakiś
kolos przez co stał się odstraszający.

> Dlaczego. Cały kod, który Cię interesuje to generic/tclgg*.[ch]. Reszta to  
> libgadu i TEA.
> Większość rozszerzeń Tcl jest w ten sposób tworzona.

Aaaa no teraz to już jest przejrzyste... Hehe ... tylko 3 pliki =)
Teraz faktycznie jaśniej jest =)

Aha, przy kompilacji pod FBSD makefile jakoś dziwnie zastopował. Tzn
stworzył już działający plik .so następnie chyba próbował stworzyć
pakiet... Jak długo trwa ta czynność? Ja czekałem 1-2 minut i później
przerwałem, skrypt testowy działał (oczywiście po zmianie uin'a, bo gg
chyba zdążyło usunąć stary, albo ktoś go przejął =)

-- 
ダレック
takeda@IRCnet.EFnet, ICQ# 15827691, YahooIM: takeda64
http://ircwiki.takeda.tk - strona wiki poświęcona IRC

On Fri, 13 Jan 2006 08:41:21 +0100, Googie wrote:

>> Eee szybki to ma być C, Tcl najwyżej wygodny :))
> Miałem na myśli szybkość pisania kodu :)

No ok, ok :>
I tak perl jest lepszy... ;))))

-- 
ダレック
takeda@IRCnet.EFnet, ICQ# 15827691, YahooIM: takeda64
http://ircwiki.takeda.tk - strona wiki poświęcona IRC

On Fri, 13 Jan 2006 08:42:34 +0100, Googie wrote:

>> Chociaż nie pokazali
> cpptcl jest autorstwa jednej osoby. Macieja Sobczaka :)

... chociaż nie pokazał ...
pasuje? ;)

BTW, udałem się z powrotem na stronę, poklikałem trochę, znalazłem stronę
domową.

I muszę powiedzieć --- wow :) Zazdroszczę...

Nie dość, że wysokie osiągnięcia w dziedzinie komputerów to jeszcze ciekawe
zainteresowania. Zdjęcia są rewelacyjne.

-- 
ダレック
takeda@IRCnet.EFnet, ICQ# 15827691, YahooIM: takeda64
http://ircwiki.takeda.tk - strona wiki poświęcona IRC

On Fri, 13 Jan 2006 09:34:11 +0100, Derek Kuliński / takeda  
<d.kulinski@gmail.com> wrote:
>> Wystarczy autoconf.in zmienić i Makefile można w mniejszym stopniu znać.
>> To też plus.
> Miałeś na myśli configure.in i Makefile.in ?

Tak. Albo raczej samo configure.in, chyba tylko tam się dopisuje jakieś  
makra o plikach *.c i *.h.

>> A struktura jaką "promuje" Tcl jest taka:
>>
>> generic/ - kod niezależny od platformy (u mnie wszystko prawie :-)
>> unix/ - kod typowy dla Unixów (u mnie obsługa zdarzeń)
>> win/ - kod typowy dla Windows (u mnie pustka :-)
>>
>> Spójrz do tls, tktable czy wielu innych rozszerzeń. To jest 'trendy', a  
>> i
>> oszczędza czas przy późniejszym portowaniu np do Windows (nie trzeba
>> owarunkowywać Makefile'i).
> Ja rozumiem to, tylko ten sposób sprawił że mały kod wygląda jak jakiś
> kolos przez co stał się odstraszający.

Wystarczy wiedzieć, że (unix|generic|win)/*.[ch] :-)

>> Dlaczego. Cały kod, który Cię interesuje to generic/tclgg*.[ch]. Reszta  
>> to
>> libgadu i TEA.
>> Większość rozszerzeń Tcl jest w ten sposób tworzona.
>
> Aaaa no teraz to już jest przejrzyste... Hehe ... tylko 3 pliki =)
> Teraz faktycznie jaśniej jest =)

:-)

> Aha, przy kompilacji pod FBSD makefile jakoś dziwnie zastopował.

Hmmm. Nie mam pojęcia dlaczego. Ale to już nie mój problem, to nie mój  
Makefile ;-)

> Tzn
> stworzył już działający plik .so następnie chyba próbował stworzyć
> pakiet... Jak długo trwa ta czynność? Ja czekałem 1-2 minut i później
> przerwałem, skrypt testowy działał (oczywiście po zmianie uin'a, bo gg
> chyba zdążyło usunąć stary, albo ktoś go przejął =)

Nie dołączyłem po prostu prawidłowego hasła ;-)

-- 
WK

Derek Kuliński / takeda wrote:

> http://cpptcl.sourceforge.net/doc/quickstart.html
> Niezłe - ląduje do moich bookmarków :)
> 
> Chociaż nie pokazali jak w tym przekazuje się informacje (argumenty do
> funkcji, zwraca wynik itp)


http://cpptcl.sourceforge.net/doc/freefun.html

Wystarczy podać *nazwę* funkcji, którą chcemy wyeksportować. C++/Tcl 
samo rozpozna, ile jest parametrów i jakie są ich typy i zajmie się 
"brudną robotą".

Czyli mając funkcję w C (lub C++):

int abs(int i) { return i >= 0 ? i : -1 * i; }

robimy tak:

i.def("abs", abs);

i już - to wystarczy, żeby w Tclu pojawiła się komenda "abs", która ma 
jeden parametr i zwraca to, co abs().

% abs 7
7
% abs -7
7
%

> bo w sumie samo podpięcie poleceń też nie jest
> takie skomplikowane w zwykłym C.

Pewnie, że nie jest. Ale przekazywanie parametrów, wartości zwracanych, 
automatyczna transformacja wyjątków z C++ na Tcl, koncepcja klasy, 
funkcje o zmiennej liczbie parametrów, kwestie życia obiektów, operacje 
na listach - to są rzeczy, przy których C staje się uciążliwe.


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Derek Kuliński / takeda wrote:

> http://cpptcl.sourceforge.net/doc/quickstart.html
> Niezłe - ląduje do moich bookmarków :)

Przy okazji - częste pytanie od użytkowników to zależność od biblioteki 
Boost. Niektórzy mają problem z jej zainstalowaniem. Otóż nie trzeba jej 
instalować (ani nawet kompilować), wystarczy tylko *rozpakować*.


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Maciej Sobczak napisał(a):
> Przy okazji - częste pytanie od użytkowników to zależność od biblioteki 
> Boost. Niektórzy mają problem z jej zainstalowaniem. Otóż nie trzeba jej 
> instalować (ani nawet kompilować), wystarczy tylko *rozpakować*.

Hehe... właśnie miałem o to pytać :) (może jakieś faq w menu na 
stronie?), tylko w nieco innym kontekście: jak wygląda sprawa zależności 
u użytkowników końcowych naszego rozszerzenia, jeśli mowa o dystrybucji 
binarnej wersji tego rozszerzenia - czy end-user musi mieć boost?

-- 
Pozdrawiam!
Googie

Maciej Sobczak napisał(a):
> http://cpptcl.sourceforge.net/

Jeszcze jedno pytanie: jak wygląda sprawa obiektów danych klas w 
argumentach? Tzn. załóżmy że mamy 2 klasy C++:

class A
{
     /// jakieś ciało
};

class B
{
     public:
         void metoda(A argument);

     /// jakieś ciało
};

?
Czy w Tcl będzie można zapisać:

set a [A]
set b [B]
b metoda $a

?
To samo pytanie odnośnie wartości zwracanych.

-- 
Pozdrawiam!
Googie

Googie wrote:

>> Przy okazji - częste pytanie od użytkowników to zależność od 
>> biblioteki Boost. Niektórzy mają problem z jej zainstalowaniem. Otóż 
>> nie trzeba jej instalować (ani nawet kompilować), wystarczy tylko 
>> *rozpakować*.
> 
> Hehe... właśnie miałem o to pytać :) (może jakieś faq w menu na 
> stronie?)

FAQtycznie, przydałby sie.

> tylko w nieco innym kontekście: jak wygląda sprawa zależności 
> u użytkowników końcowych naszego rozszerzenia, jeśli mowa o dystrybucji 
> binarnej wersji tego rozszerzenia - czy end-user musi mieć boost?

Nie, nic nie musi mieć poza run-timem Tcl.
Z Boosta wykorzystane są tylko niektóre pliki nagłówkowe. One nie 
wymagają ani instalacji, ani osobnej kompilacji, ani tym bardziej 
obecności u end-usera. Boost (tzn. jego obecność gdzieś na ścieżce) jest 
potrzebny tylko i wyłącznie do skompilowania kodu, który korzysta z C++/Tcl.


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Googie wrote:

>> http://cpptcl.sourceforge.net/
> 
> Jeszcze jedno pytanie: jak wygląda sprawa obiektów danych klas w 
> argumentach? Tzn. załóżmy że mamy 2 klasy C++:
> 
> class A
> {
>     /// jakieś ciało
> };
> 
> class B
> {
>     public:
>         void metoda(A argument);

           void metoda(A *argument);

>     /// jakieś ciało
> };
> 
> ?
> Czy w Tcl będzie można zapisać:
> 
> set a [A]
> set b [B]
> b metoda $a

Tak - ale wtedy, gdy parametr jest przez wskaźnik. I, niestety, w tej 
chwili bez rozpoznania, czy typ jest poprawny.

> To samo pytanie odnośnie wartości zwracanych.

Też przez wskaźnik.

Tutaj:

http://cpptcl.sourceforge.net/doc/callpolicies.html

są pokazane dodatkowe szczegóły, które mogą być w takich sytuacjach 
potrzebne.


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

On Fri, 13 Jan 2006 14:07:10 +0100, Maciej Sobczak wrote:

> Nie, nic nie musi mieć poza run-timem Tcl.
> Z Boosta wykorzystane są tylko niektóre pliki nagłówkowe. One nie 
> wymagają ani instalacji, ani osobnej kompilacji, ani tym bardziej 
> obecności u end-usera. Boost (tzn. jego obecność gdzieś na ścieżce) jest 
> potrzebny tylko i wyłącznie do skompilowania kodu, który korzysta z C++/Tcl.

Nie prościej dołączyć te potrzebne nagłówki z boost'a do kodu? Ich licencja
chyba na to pozwala, bo ponoć chcą być czymś w rodzaju STL.

-- 
ダレック
takeda@IRCnet.EFnet, ICQ# 15827691, YahooIM: takeda64
http://ircwiki.takeda.tk - strona wiki poświęcona IRC

On Fri, 13 Jan 2006 10:26:25 +0100, Maciej Sobczak wrote:

> http://cpptcl.sourceforge.net/doc/freefun.html
> 
> Wystarczy podać *nazwę* funkcji, którą chcemy wyeksportować. C++/Tcl 
> samo rozpozna, ile jest parametrów i jakie są ich typy i zajmie się 
> "brudną robotą".
> 
> Czyli mając funkcję w C (lub C++):
> 
> int abs(int i) { return i >= 0 ? i : -1 * i; }
> 
> robimy tak:
> 
> i.def("abs", abs);
> 
> i już - to wystarczy, żeby w Tclu pojawiła się komenda "abs", która ma 
> jeden parametr i zwraca to, co abs().
> 
> % abs 7
> 7
> % abs -7
> 7
> %

Ok, teraz widzę prawdziwą siłę owego rozwiązania. Świetne, dzięki.

-- 
ダレック
takeda@IRCnet.EFnet, ICQ# 15827691, YahooIM: takeda64
http://ircwiki.takeda.tk - strona wiki poświęcona IRC

Derek Kuliński / takeda wrote:

> Nie prościej dołączyć te potrzebne nagłówki z boost'a do kodu?

Prościej? Jeżeli już ktoś ściągnął C++/Tcl z SourceForge'a i rozpakował 
na dysku, to powinien poradzić sobie też ze ściągnięciem Boost i 
rozpakowaniem tegoż - robi się to dokładnie tak samo. :)

Natomiast ze strony C++/Tcl problemy są dwa:

1. Te potrzebne nagłówki są tak dokładnie powiązane z innymi, które są 
powiązane z..., że wszystkich potrzebnych jest pewnie kilkadziesiąt - 
czyli duuużo więcej, niż samego C++/Tcl.

2. Jeżeli ktoś użyje C++/Tcl z kodem C++, który i tak już korzysta z 
Boost, to najgorszą rzeczą jest doprowadzenie do sytuacji, w której w 
jednym pliku wynikowym znajdzie się kod z nagłówków różnych wersji Boost 
(jedna wersja przywieziona przez C++/Tcl a druga już używana w danym 
projekcie). Lepiej niech użytkownik sam decyduje, którą wersję użyć - 
jeśli już Boosta używa, to niech po prostu poda ścieżkę do *tej wersji*, 
którą używa - a jeśli nie używa, to niech ściągnie i rozpakuje [*].

Dlatego C++/Tcl nie wozi ze sobą cudzych plików.

> Ich licencja
> chyba na to pozwala, bo ponoć chcą być czymś w rodzaju STL.

Pozwala, ale to nie ma związku z STL - STL to część biblioteki 
standardowej i istnieją jej różne implementacje; również takie, które 
mają "komercyjne" licencje.


[*] Na większości linuksów boost jest rozprowadzany również jako pakiet 
(.rpm, .deb, itp.) i jest dostępny z płytek instalacyjnych. Niektórzy 
mogą to już mieć na dysku i nawet o tym nie wiedzieć. ;)


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

On Sun, 15 Jan 2006 15:48:57 +0100, Maciej Sobczak wrote:

[...]

> Dlatego C++/Tcl nie wozi ze sobą cudzych plików.

Ok w sumie racja, zresztą biblioteka jest dla programistów a Ci powinni
wiedzieć co robią... :)

>> Ich licencja
>> chyba na to pozwala, bo ponoć chcą być czymś w rodzaju STL.
> Pozwala, ale to nie ma związku z STL - STL to część biblioteki 
> standardowej i istnieją jej różne implementacje; również takie, które 
> mają "komercyjne" licencje.

Tzn. są stl'e które są osobne, czy po prostu ta licencja jest od
kompilatora, w którego skład wchodzą owe biblioteki?

-- 
ダレック
takeda@IRCnet.EFnet, ICQ# 15827691, YahooIM: takeda64
http://ircwiki.takeda.tk - strona wiki poświęcona IRC

Derek Kuliński / takeda wrote:

>>>Ich licencja
>>>chyba na to pozwala, bo ponoć chcą być czymś w rodzaju STL.
>>
>>Pozwala, ale to nie ma związku z STL - STL to część biblioteki 
>>standardowej i istnieją jej różne implementacje; również takie, które 
>>mają "komercyjne" licencje.
> 
> Tzn. są stl'e które są osobne, czy po prostu ta licencja jest od
> kompilatora, w którego skład wchodzą owe biblioteki?

Są takie i takie. STL to nie jest jedna biblioteka od jednego producenta 
- to jest po prostu zbiór klas i funkcji i jest gdzieś czarno na białym 
(w standardzie) zapisane, co to za klasy i co to za funkcje. 
Implementacje są różne, i konkurują ze sobą w różny sposób: szybkością, 
możliwościami diagnostycznymi, przenośnością, itd.

No, ale to NTG.

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/