🚀 go-pugleaf

Googie wrote:

> Czegoś tu nie rozumiem - dlaczego żadna firmanie dostrzegła jeszcze
> potencjału Tcl'a, oraz profitów jakie mogła by z tego wyciągać - tak jak
> to było z Javą i Sun'em (w końcu Sun nie wymyślił Javy, tylko ją przejął
> i rozwija).
> 

   Moim zdaniem firmy wyraźnie dostrzegają potencjał języków skryptowych,
ale ich logistycy potrafią robić bilanse zysków/strat i widzą, że program
napisany 'lepiej' przy sprzedaży przyniesie więcej strat niż program
napisany 'gorzej' :-) Obecnie klient w większości przypadków otrzymuje
binarkę i ma raczej ograniczone możliwości grzebania w kodzie - jest
zmuszany do zakupu następnej wersji softu, a to nakręca komputerowy
interes. Gdyby dostał program pod postacią czystego kodu (jako skrypt),
to kombinowanie w nim nawet za cenę łamania prawa byłoby dla niego często
bardzo opłacalne. Dodatkowo takie beztroskie puszczanie w świat przez
producentów softu różnych 'firmowych' patentów na rozwiązywanie problemów
z którymi programiści z konkurencji się wciąż borykają... 

   Ot, co ;-) Dlatego postuluję: objąć całe oprogramowanie klasy PC
licencją GNU. :-)))


P.S. No właśnie - tak sobie teraz pomyślałem, że nigdy nie słyszałem o
kompilatorze tcl-a. Spotkał się ktoś z was z takim ustrojstwem??? 

   pozdrawiam
-- 
Miroslaw Kosmala    mail-to:miroslaw.kosmala(|)trilowcy.org
Linux User:#197007  root:$1$ueQ1d75z$NlDhu6oQhfUpmBlnKTDpj0:
DNS-Private-Name:   akka.sytes.net -> Powered by SlackWare %-*

On Sat, 07 Jan 2006 02:36:39 +0100, Mirosław Kosmala  
<miroslaw.kosmala@trilowcy.org> wrote:
>    Moim zdaniem firmy wyraźnie dostrzegają potencjał języków skryptowych,
> ale ich logistycy potrafią robić bilanse zysków/strat i widzą, że program
> napisany 'lepiej' przy sprzedaży przyniesie więcej strat niż program
> napisany 'gorzej' :-) Obecnie klient w większości przypadków otrzymuje
> binarkę i ma raczej ograniczone możliwości grzebania w kodzie - jest
> zmuszany do zakupu następnej wersji softu, a to nakręca komputerowy
> interes. Gdyby dostał program pod postacią czystego kodu (jako skrypt),
> to kombinowanie w nim nawet za cenę łamania prawa byłoby dla niego często
> bardzo opłacalne. Dodatkowo takie beztroskie puszczanie w świat przez
> producentów softu różnych 'firmowych' patentów na rozwiązywanie problemów
> z którymi programiści z konkurencji się wciąż borykają...

Akurat ostatnio modne jest rzucanie słów technicznych typu Java... Wtedy  
manadżerom wydaje się, że to nowoczesna i trendy aplikacja... Chociaż na  
szczęście nie za często.

>    Ot, co ;-) Dlatego postuluję: objąć całe oprogramowanie klasy PC
> licencją GNU. :-)))

To już przesada, ale po prostu dołączanie kodu byłoby ok.

> P.S. No właśnie - tak sobie teraz pomyślałem, że nigdy nie słyszałem o
> kompilatorze tcl-a. Spotkał się ktoś z was z takim ustrojstwem???

Tak samo jak nie spotkałem się z kompilatorem perla do kodu assemblera :-)
Kiedyś był tclcompiler...

Natomiast np dqkit pozwala zwijać do binarki.

-- 
WK

On Sun, 08 Jan 2006 17:33:45 +0100, Mirosław Kosmala  
<miroslaw.kosmala@trilowcy.org> wrote:

> Wojciech Kocjan wrote:
>>>
>>>    Ot, co ;-) Dlatego postuluję: objąć całe oprogramowanie klasy PC
>>> licencją GNU. :-)))
>>
>> To już przesada, ale po prostu dołączanie kodu byłoby ok.
>>
>
>    Toć GNU polega właśnie na darmowym dołączaniu kodu, a za binarkę
> wytwórca może sobie zażyczyć ile tylko chce :-)

Ale nie może ograniczyć redystrybucji? O ile pamiętam to to jest założenie  
GPL.

Czy GPL tylko wymaga dawania źródła wraz z binarką? - chyba tak jest w  
momencie
łączenia kodu GPL z inną licencją.

>> Natomiast np dqkit pozwala zwijać do binarki.
>    Ale wszystkiego nie da się chyba zwinąć? Tzn. w tcl-owym programie  
> mogą
> być bardziej złożone fragmenty kodu, których stosowany w dqkit wrapper
> nie da rady upakować?

A dlaczego nie? Przecież to VFS, więc całą strukturę widzisz jako np:

binarka.exe/lib/tcllib1.7/base64/base64.tcl
binarka.exe/lib/tcllib1.7/base64/pkgIndex.tcl
binarka.exe/lib/oratcl4.3/oratcl43.dll
binarka.exe/lib/app-binarka/app.tcl

Dllka jest wymieniona, bo Tcl sobie z tym radzi, zapisując .dll w katalogu  
tymczasowym i stamtąd ją ładując. Jeśli chodzi o Dllki wymagające innych  
Dllek, to to się obchodzi albo wszystko wrzucając do katalogu binarki.

Wtedy lepiej już skorzystać z installjammera lub  jakiegoś .msi-kreatora,  
ale i tak nie jest wymagane nic poza kilkoma .dll i .exe w jednym miejscu.

Mi to działa bezproblemowo.

-- 
WK

Wojciech Kocjan wrote:
>> 
>>    Ot, co ;-) Dlatego postuluję: objąć całe oprogramowanie klasy PC
>> licencją GNU. :-)))
> 
> To już przesada, ale po prostu dołączanie kodu byłoby ok.
> 

   Toć GNU polega właśnie na darmowym dołączaniu kodu, a za binarkę
wytwórca może sobie zażyczyć ile tylko chce :-)


>
> Natomiast np dqkit pozwala zwijać do binarki.
> 

   Ale wszystkiego nie da się chyba zwinąć? Tzn. w tcl-owym programie mogą
być bardziej złożone fragmenty kodu, których stosowany w dqkit wrapper
nie da rady upakować?


   zdrawiam
-- 
Miroslaw Kosmala    mail-to:miroslaw.kosmala(|)trilowcy.org
Linux User:#197007  root:$1$ueQ1d75z$NlDhu6oQhfUpmBlnKTDpj0:

Wojciech Kocjan wrote:
>>
>>    Toć GNU polega właśnie na darmowym dołączaniu kodu, a za binarkę
>> wytwórca może sobie zażyczyć ile tylko chce :-)
> 
> Ale nie może ograniczyć redystrybucji? O ile pamiętam to to jest założenie
> GPL.
> 

   Dokładnie, prawo do przerabiania i redystrybucji jest podstawą. Dlatego
jest bezwarunkowy wymóg udostępniania kodu źródłowego - żeby można było
sobie w nim pogrzebać ;-)


> Czy GPL tylko wymaga dawania źródła wraz z binarką? - chyba tak jest w
> momencie
> łączenia kodu GPL z inną licencją.
> 

   Z tego co wiem licencji GNU GPL nie wolno łączyć z żadną inną. Tzn.
jeżeli jakiś program zawiera fragment kodu licencjonowanego na GPL, to cały
kod tego programu też musi być dystrybuowany na zasadach GPL. Jeżeli ktoś
robi jakiś większy projekt na innej licencji i chce w nim wykorzystać kod
GPL, to musi umieścić go w wyraźnie osobnym programie i ten osobny program
musi być objęty GPL, a jego źródła udostępnione. Resztę projektu twórca
może sobie puszczać na licencjach jakie mu się podobają.
   Inna sytuacja następuje gdy ktoś od początku do końca jest twórcą kodu,
który puszcza w świat na zasadach GPL. Ta licencja nie obowiązuje autora
kodu. Tzn. może on wziąść napisane przez siebie fragmenty programu, który
upublicznił na zasadach GPL i zastosować w innym swoim projekcie - na
dowolnej licencji.


> 
> A dlaczego nie? Przecież to VFS, więc całą strukturę widzisz jako np:
> 
> binarka.exe/lib/tcllib1.7/base64/base64.tcl
> binarka.exe/lib/tcllib1.7/base64/pkgIndex.tcl

   Rozumiem.


   pozdrawiam
-- 
Mirosław Kosmala
miroslaw.kosmala(Q)resko.pl

Mirosław Kosmala wrote:
> Gdyby dostał program pod postacią czystego kodu (jako skrypt),
> to kombinowanie w nim nawet za cenę łamania prawa byłoby dla niego często
> bardzo opłacalne.

Developer nie jest zmuszony rozdawać źródeł. O tym niżej.

> 
> P.S. No właśnie - tak sobie teraz pomyślałem, że nigdy nie słyszałem o
> kompilatorze tcl-a. Spotkał się ktoś z was z takim ustrojstwem??? 

Do assemblera - nie, ale do kodu maszynowego owszem, przy pomocy 
ActiveState ProCompiler, albo tego samego narzędzia z pakietu TclPro (to 
drugie jest trochę starsze - ale i darmowe - i nie obsługuje najnowszych 
wersji Tcl). ProCompiler tłumaczy Tcl na kod maszynowy, który jest 
teoretycznie nie dekodowalny (w praktyce się da, tak jak i reverse 
enginnering na assemblerze, ale nigdy nie otrzyma się kodu w takiej 
postaci jak na początku). Ten program powstał właśnie w celu ochrony 
praw autorskich kodu Tcl.

Tak skompilowany kod też uruchamia się w interpreterze Tcl, tyle że na 
początku skrypt ładuje specjalne rozszerzenie do wykonywania kodu 
maszynowego, a w dalszej części skryptu jest już tylko sam kod maszynowy  :)

-- 
Pozdrawiam!
Googie

Googie wrote:
> 
> Tak skompilowany kod też uruchamia się w interpreterze Tcl, tyle że na
> początku skrypt ładuje specjalne rozszerzenie do wykonywania kodu
> maszynowego, a w dalszej części skryptu jest już tylko sam kod maszynowy 
> :)
> 

   Hmm... ciekawe, ciekawe... coś czuję, że wieczorkiem puszczę google w
ruch ;-)


   zdrówka
-- 
Mirosław Kosmala

On Mon, 09 Jan 2006 10:23:59 +0100, Googie wrote:

> Do assemblera - nie, ale do kodu maszynowego owszem, przy pomocy 
> ActiveState ProCompiler, albo tego samego narzędzia z pakietu TclPro (to 
> drugie jest trochę starsze - ale i darmowe - i nie obsługuje najnowszych 
> wersji Tcl). ProCompiler tłumaczy Tcl na kod maszynowy, który jest 
> teoretycznie nie dekodowalny (w praktyce się da, tak jak i reverse 
> enginnering na assemblerze, ale nigdy nie otrzyma się kodu w takiej 
> postaci jak na początku).

Jesteś pewien? Mi wydawało się, że kompiluje do tzw. bytecode (coś jak
pliki .class z javy; tcl też sam kompiluje kod z procedur do takiej
postaci, przyspiesza to działanie). Jak by tcl kompilował do kodu
maszynowego, to wtedy wydaje mi się, że tcl interpreter niebyłby w ogóle
potrzebny, ale mogę się mylić =)

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

Derek Kuliński / takeda wrote:
> Jesteś pewien? Mi wydawało się, że kompiluje do tzw. bytecode (coś jak
> pliki .class z javy; tcl też sam kompiluje kod z procedur do takiej
> postaci, przyspiesza to działanie). Jak by tcl kompilował do kodu
> maszynowego, to wtedy wydaje mi się, że tcl interpreter niebyłby w ogóle
> potrzebny, ale mogę się mylić =)
> 

Tłumaczenie 'bytecode' na j. polski jest trochę upośledzone i z tego co 
mi wiadomo to brzmi ono "kod maszynowy", bo nie spotkałem się z "kodem 
bajtowym". Kod skompilowany przez ProCompilera niestety nie jest 
szybszy, ani nie jest to też ten sam kod, na który jest kompilowany Tcl 
przez interpreter - kiedyś wywiązała się na ten temat dyskusja na clt.

-- 
Pozdrawiam!
Googie

On Tue, 10 Jan 2006 08:18:59 +0100, Googie <no@spam.org> wrote:
> Tłumaczenie 'bytecode' na j. polski jest trochę upośledzone i z tego co  
> mi wiadomo to brzmi ono "kod maszynowy", bo nie spotkałem się z "kodem  
> bajtowym". Kod skompilowany przez ProCompilera niestety nie jest  
> szybszy, ani nie jest to też ten sam kod, na który jest kompilowany Tcl  
> przez interpreter - kiedyś wywiązała się na ten temat dyskusja na clt.

O ile pamiętam jest, ale z powodu zapisu jako ASCII85 ładowanie go nie  
jest szybsze. O ile pamiętam tak się kończy większość dyskusji na ten  
temat na CLT :-)

ps. Nie mam pojęcia dlaczego nikt nie zrobił tbcload::tbcsource i pliki  
binarne, pewnie byłoby szybciej...

-- 
WK