🚀 go-pugleaf

On Thu, 10 May 2007 21:23:28 +0000 (UTC), " pawel"
<pawellt.SKASUJ@gazeta.pl> wrote:

>Witam,
>
>Pewnie Ci ktorzy sie tym interesuja juz wiedza.. ECLiPSe (odmiana Prologa
>z CLP, COIN-OR, spora iloscia dodatków, funkcjonalnym IDE i dobra dokumentacja)
>jest juz na licencji open source (najnowsza wersja 5.10_70 wypuszczona zostala
>wczoraj): http://eclipse-clp.org/
>
>No i wlasnie. Jesli brac pod uwage CLP, ale i pozostale kwestie (szybkosc,
>jakosc implementacji, mozliwosci), to jak oceniacie ECLiPSe w porownaniu do 
>takiego Ciao Prologa, SWI, czy nawet komercyjnego SICStus'a? 

ECLIPSe to wsrod "free" Prologow neiwatpliwie Numer Jeden. Jezeli
kogos interesuej constraint programming, to praktycznie wsrod "free"
sa tylko dwa: wkasnie owe ECLIPSe oraz B-Prolog, przy czym B-Prolog
pryz ECLIPSE jest bardzo amatorski,

SWI i Ciao maja "sladowe" implementacje constraint programming,
aczkolwiek jezeli komus CP nie ejst potzrebne, to SWI ma zdecydowanei
najlepsza reputacje, i wtedy wlasnei bym raczej polecal SWI zamiast
ECLIPSe. Co nie znaczy ze Ciao jest zly.

SICStus jeszt zdecydowanei lepszy od ECLIPSe pod wzgledem dostepnych
"global constraints" oraz latwosci i elegancji generowania wlasnych,
ale glebokich roznic na korzysc jednego lub drugiego nie widze. Zaleta
SICStusa jes tdoskonaly support (za ktory oczywiscie tzreba placic,
ale podobnego nie widze w przypadku Eclipse).

>Poki co jest wersja pod Linuksa (x86 i ia64), Solarisa, Windowsa..

Jest tez pod MacOS czy jak to sie tam nazywa...

>Jest tez ciekawie prezentujaca sie ksiazka wydana w Cambridge 
>"Constraint Logic Programming using Eclipse":
>http://www.cambridge.org/catalogue/catalogue.asp?isbn=0521866286
>Szkoda tylko ze zadnych fragmentow nie udostepniaja w sieci, bo tak
>w ciemno kupowac troche nie bardzo :(

Ksiezke wypada polecic z nastepujacymi zatzrezeniami: a) Jet to
podrecznik akademicki, wiec o zastosowaniach "prawdziwych" sie nei
dowiesz, b) Prawie 100% koncentruje sie na constraint programming, c)
Jest to NIECO rozszerzona wersja tutoriala ktory idzie razem z
ECLIPSe, ale znowu nie tak bardzo rozszerzona. Jezeli masz na zbyciu
kilkadziesiat dolcow, to polecam, ale moze zamiast kupowac "w ciemno"
przestudiuj najpier tutorial. Jezeli bedzieszc chaial miec troche
wiecej i twarde okladki to polecam ksiazke.

Acha, no i ksiazka nie zastapi podrecznika Prologu, chociaz podsatwy
Prologu sa w niej poruszane.

Na dodatek wypada dodac ze jest lista e-majlowa na temat ECLIPse i
ruch na niej panuje dosc duzy, wiec jezeli kogos ECLIPSe na serio
interesuje, to proponuej sie zapisac.

A.L.

> Na dodatek wypada dodac ze jest lista e-majlowa na temat ECLIPse i
> ruch na niej panuje dosc duzy, wiec jezeli kogos ECLIPSe na serio
> interesuje, to proponuej sie zapisac.

Wielkie dzieki za opinie i info. Faktycznie z ksiazka jeszcze sie
wstrzymam - a na razie postudiuje dokumentacje dostarczana razem
z Eclipse. Zauwazylem tez, ze Eclipse (testy na zwyklych listach,
tyle ze mocno rozbudowanych,bez uzycia CLP) jest szybszy od Ciao.

pozdrawiam

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

On Fri, 11 May 2007 22:59:40 +0000 (UTC), " pawel"
<pawellt.WYTNIJ@gazeta.pl> wrote:
 
>z Eclipse. Zauwazylem tez, ze Eclipse (testy na zwyklych listach,
>tyle ze mocno rozbudowanych,bez uzycia CLP) jest szybszy od Ciao.

Who cares?...

A.L.

> >z Eclipse. Zauwazylem tez, ze Eclipse (testy na zwyklych listach,
> >tyle ze mocno rozbudowanych,bez uzycia CLP) jest szybszy od Ciao.
> 
> Who cares?...

No zapewne tych, którzy uzywaja w Prologu duzej ilosci mocno rozbudowanych
list - a zalezy im na szybkosci dzialania .. i darmowym narzedziu do realizacji
powyzszego ;-)

pozdrawiam

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

On Sat, 12 May 2007 14:22:18 +0000 (UTC), " pawel"
<pawellt.WYTNIJ@gazeta.pl> wrote:

>
>> >z Eclipse. Zauwazylem tez, ze Eclipse (testy na zwyklych listach,
>> >tyle ze mocno rozbudowanych,bez uzycia CLP) jest szybszy od Ciao.
>> 
>> Who cares?...
>
>No zapewne tych, którzy uzywaja w Prologu duzej ilosci mocno rozbudowanych
>list - a zalezy im na szybkosci dzialania .. i darmowym narzedziu do realizacji
>powyzszego ;-)
>

Ja uzywam Prologu do zastowowan komercyjnych, i ostatnia rzecza jaka
by mnie interesowala to ktora implementacja jest szybsza od ktorej. 

Poza tym, gdybym potrzebowal Prologu bez CLP to na pewno wybralbym SWI
a nie Ciao. Bez wzgledu na szybkosc.

A.L.

On Sat, 12 May 2007 09:34:59 -0500, A.L. <fela@2005.com> wrote:

>On Sat, 12 May 2007 14:22:18 +0000 (UTC), " pawel"
><pawellt.WYTNIJ@gazeta.pl> wrote:
>
>>
>>> >z Eclipse. Zauwazylem tez, ze Eclipse (testy na zwyklych listach,
>>> >tyle ze mocno rozbudowanych,bez uzycia CLP) jest szybszy od Ciao.
>>> 
>>> Who cares?...
>>
>>No zapewne tych, którzy uzywaja w Prologu duzej ilosci mocno rozbudowanych
>>list - a zalezy im na szybkosci dzialania .. i darmowym narzedziu do realizacji
>>powyzszego ;-)
>>
>
>Ja uzywam Prologu do zastowowan komercyjnych, i ostatnia rzecza jaka
>by mnie interesowala to ktora implementacja jest szybsza od ktorej. 
>
>Poza tym, gdybym potrzebowal Prologu bez CLP 

I DARMOWEGO...

>to na pewno wybralbym SWI
>a nie Ciao. Bez wzgledu na szybkosc.
>
>A.L.

A.L. <fela@2005.com> writes:

[...]

> SWI i Ciao maja "sladowe" implementacje constraint programming,
> aczkolwiek jezeli komus CP nie ejst potzrebne, to SWI ma
> zdecydowanei najlepsza reputacje, i wtedy wlasnei bym raczej 
> polecal SWI zamiast ECLIPSe. Co nie znaczy ze Ciao jest zly.

SWI Prolog ma zaimplementowaną funkcję 'do what I mean', czyli potrafi
sam sobie poprawić błędnie wpisany identyfikator predykatu.

A.L. <fela@2005.com> writes:

> On Fri, 11 May 2007 22:59:40 +0000 (UTC), " pawel"
> <pawellt.WYTNIJ@gazeta.pl> wrote:
>  
>>z Eclipse. Zauwazylem tez, ze Eclipse (testy na zwyklych listach,
>>tyle ze mocno rozbudowanych,bez uzycia CLP) jest szybszy od Ciao.
>
> Who cares?...

Jeśli chodzi o szybkość, to zawsze można napisać kluczowe dla
wydajności programu moduły w języku maszynowym i dołączyć je 
do interpretera.  Tak się często robi w przypadku Pythona.

-- 
http://www.piotr.dembiński.prv.pl

On Sat, 12 May 2007 22:43:04 +0200, pdemb@gazeta.pl (Piotr Dembiński)
wrote:

>A.L. <fela@2005.com> writes:
>
>> On Fri, 11 May 2007 22:59:40 +0000 (UTC), " pawel"
>> <pawellt.WYTNIJ@gazeta.pl> wrote:
>>  
>>>z Eclipse. Zauwazylem tez, ze Eclipse (testy na zwyklych listach,
>>>tyle ze mocno rozbudowanych,bez uzycia CLP) jest szybszy od Ciao.
>>
>> Who cares?...
>
>Jeśli chodzi o szybkość, to zawsze można napisać kluczowe dla
>wydajności programu moduły w języku maszynowym i dołączyć je 
>do interpretera.  Tak się często robi w przypadku Pythona.

Ale tak sie nie robi w przypadku Prologu.

A.L.

On Sat, 12 May 2007 22:41:15 +0200, pdemb@gazeta.pl (Piotr Dembiński)
wrote:

>A.L. <fela@2005.com> writes:
>
>[...]
>
>> SWI i Ciao maja "sladowe" implementacje constraint programming,
>> aczkolwiek jezeli komus CP nie ejst potzrebne, to SWI ma
>> zdecydowanei najlepsza reputacje, i wtedy wlasnei bym raczej 
>> polecal SWI zamiast ECLIPSe. Co nie znaczy ze Ciao jest zly.
>
>SWI Prolog ma zaimplementowaną funkcję 'do what I mean', czyli potrafi
>sam sobie poprawić błędnie wpisany identyfikator predykatu.

SWI Prolog tego nie ma.

A.L.

Użytkownik ""Piotr Dembiński"" <pdemb@gazeta.pl> napisał:

> Jeśli chodzi o szybkość, to zawsze można napisać kluczowe dla
> wydajności programu moduły w języku maszynowym i dołączyć je
> do interpretera.  Tak się często robi w przypadku Pythona.

_Maszynowym_ ? Chyba przesadzasz.
A nawet zdrowo.
Chyba ze traktujesz C/C++ jako jezyk maszynowy
(ja tak traktuje:) to zgoda.

AK

Adam Karpierz wrote:
> _Maszynowym_ ? Chyba przesadzasz.
> A nawet zdrowo.

Asemblery maja swoja nisze w niszy. ;)

w.

A.L. <fela@2005.com> writes:

> On Sat, 12 May 2007 22:41:15 +0200, pdemb@gazeta.pl (Piotr Dembiński)
> wrote:
>
>>A.L. <fela@2005.com> writes:
>>
>>[...]
>>
>>> SWI i Ciao maja "sladowe" implementacje constraint programming,
>>> aczkolwiek jezeli komus CP nie ejst potzrebne, to SWI ma
>>> zdecydowanei najlepsza reputacje, i wtedy wlasnei bym raczej
>>> polecal SWI zamiast ECLIPSe. Co nie znaczy ze Ciao jest zly.
>>
>>SWI Prolog ma zaimplementowaną funkcję 'do what I mean', czyli
>>potrafi sam sobie poprawić błędnie wpisany identyfikator predykatu.
>
> SWI Prolog tego nie ma.

hm, dokładnie to: nie sam prolog, tylko interpreter pracujący w trybie
interaktywnym i nie poprawia, tylko sugeruje poprawkę

A.L. <fela@2005.com> writes:

> On Sat, 12 May 2007 22:43:04 +0200, pdemb@gazeta.pl (Piotr
> Dembiński) wrote:
>
>>A.L. <fela@2005.com> writes:
>>
>>> On Fri, 11 May 2007 22:59:40 +0000 (UTC), " pawel"
>>> <pawellt.WYTNIJ@gazeta.pl> wrote:
>>>  
>>>>z Eclipse. Zauwazylem tez, ze Eclipse (testy na zwyklych listach,
>>>>tyle ze mocno rozbudowanych,bez uzycia CLP) jest szybszy od Ciao.
>>>
>>> Who cares?...
>>
>>Jeśli chodzi o szybkość, to zawsze można napisać kluczowe dla
>>wydajności programu moduły w języku maszynowym i dołączyć je 
>>do interpretera.  Tak się często robi w przypadku Pythona.
>
> Ale tak sie nie robi w przypadku Prologu.

Taka konwencja?

A.L. <fela@2005.com> writes:

> On Sat, 12 May 2007 22:41:15 +0200, pdemb@gazeta.pl (Piotr Dembiński)
> wrote:
>
>>A.L. <fela@2005.com> writes:
>>
>>[...]
>>
>>> SWI i Ciao maja "sladowe" implementacje constraint programming,
>>> aczkolwiek jezeli komus CP nie ejst potzrebne, to SWI ma
>>> zdecydowanei najlepsza reputacje, i wtedy wlasnei bym raczej
>>> polecal SWI zamiast ECLIPSe. Co nie znaczy ze Ciao jest zly.
>>
>>SWI Prolog ma zaimplementowaną funkcję 'do what I mean', czyli
>>potrafi sam sobie poprawić błędnie wpisany identyfikator predykatu.
>
> SWI Prolog tego nie ma.

hm, dokładnie to: nie sam Prolog, tylko interpreter pracujący w trybie
interaktywnym i nie poprawia, tylko sugeruje poprawkę

On Sun, 13 May 2007 19:16:09 +0200, pdemb@gazeta.pl (Piotr Dembiński)
wrote:

>A.L. <fela@2005.com> writes:
>
>> On Sat, 12 May 2007 22:43:04 +0200, pdemb@gazeta.pl (Piotr
>> Dembiński) wrote:
>>
>>>A.L. <fela@2005.com> writes:
>>>
>>>> On Fri, 11 May 2007 22:59:40 +0000 (UTC), " pawel"
>>>> <pawellt.WYTNIJ@gazeta.pl> wrote:
>>>>  
>>>>>z Eclipse. Zauwazylem tez, ze Eclipse (testy na zwyklych listach,
>>>>>tyle ze mocno rozbudowanych,bez uzycia CLP) jest szybszy od Ciao.
>>>>
>>>> Who cares?...
>>>
>>>Jeśli chodzi o szybkość, to zawsze można napisać kluczowe dla
>>>wydajności programu moduły w języku maszynowym i dołączyć je 
>>>do interpretera.  Tak się często robi w przypadku Pythona.
>>
>> Ale tak sie nie robi w przypadku Prologu.
>
>Taka konwencja?

Idzie Pan do KF.

A.L.

Dnia Thu, 10 May 2007 21:23:28 +0000 (UTC)
" pawel" <pawellt.SKASUJ@gazeta.pl> napisał(a):

> Jest tez ciekawie prezentujaca sie ksiazka wydana w Cambridge 
> "Constraint Logic Programming using Eclipse":
> http://www.cambridge.org/catalogue/catalogue.asp?isbn=0521866286
> Szkoda tylko ze zadnych fragmentow nie udostepniaja w sieci, bo tak
> w ciemno kupowac troche nie bardzo :(
> 
NIe kupuj, tylko przejrzyj manual. Ksiazka oprocz tego, ze ma skapy
rozdzial na temat Prologa jest chamska kopia manuala. A najgorsze jest to,
ze to jest kolejna ksiazka z oklepanymi przykladami.

Zdrowia
-- 
[ Wit Jakuczun    <W.Jakuczun [at] wlogsolutions.com> ]
[ WLOG Solutions  http://www.wlogsolutions.com ]

A.L. <fela@2005.com> writes:

[...]

>>>>Jeśli chodzi o szybkość, to zawsze można napisać kluczowe dla
>>>>wydajności programu moduły w języku maszynowym i dołączyć je 
>>>>do interpretera.  Tak się często robi w przypadku Pythona.
>>>
>>> Ale tak sie nie robi w przypadku Prologu.
>>
>>Taka konwencja?
>
> Idzie Pan do KF.

Technicznie takie rozwiązanie jest możliwe.  Dlatego zapytałem
o dominującą wśród programistów konwencję w tym zakresie.

Co do języka maszynowego, to IMO assembler jest maszynowy.

-- 
http://www.piotr.dembiński.prv.pl

> Co do języka maszynowego, to IMO assembler jest maszynowy.

http://pl.wikipedia.org/wiki/J%C4%99zyk_maszynowy 

"radoslaw tereszczuk" <tereszczuk@it1.pl> writes:

>> Co do języka maszynowego, to IMO assembler jest maszynowy.
>
> http://pl.wikipedia.org/wiki/J%C4%99zyk_maszynowy

Tak, ale zauważ, że w przypadku kompilatorów i interpreterów języków
programowania, które nie są językami maszynowymi, zawsze istnieje
pewien poziom abstrakcji, który skutkuje w możliwości odmiennego
zinterpretowania lub przetłumaczenia napisanego programu przez różne
interpretery lub kompilatory.

W przypadku assemblera nie ma takiej możliwości -- dowolny assembler
przetłumaczy instrukcje zapisane w postaci mnemoników (plus ew. makr)
zawsze w ten sam sposób.  Dlatego właśnie moim zdaniem assembler jest
językiem maszynowym, nawet jeśli obsługuje makra.

-- 
http://www.piotr.dembiński.prv.pl

""Piotr Dembiński"" <pdemb@gazeta.pl> wrote:

> W przypadku assemblera nie ma takiej możliwości -- dowolny assembler
> przetłumaczy instrukcje zapisane w postaci mnemoników (plus ew. makr)
> zawsze w ten sam sposób.  Dlatego właśnie moim zdaniem assembler jest
> językiem maszynowym, nawet jeśli obsługuje makra.

To jednak zbyt abstrakcyjny jezyk.
To sie i tak przeklada na gonitwe elektronow obijajacych sie o
bariery potencjalu w tranzystorach.
Prawdziwy jezyk maszynowy to graf przeplywu elektronow.

AK

"Adam Karpierz" <karpierz@NOOOOSPAAAAMpython.pl> writes:

> ""Piotr Dembiński"" <pdemb@gazeta.pl> wrote:
>
>> W przypadku assemblera nie ma takiej możliwości -- dowolny
>> assembler przetłumaczy instrukcje zapisane w postaci mnemoników
>> (plus ew. makr) zawsze w ten sam sposób.  Dlatego właśnie moim
>> zdaniem assembler jest językiem maszynowym, nawet jeśli obsługuje
>> makra.
>
> To jednak zbyt abstrakcyjny jezyk.

Oprócz makr są jeszcze dyrektywy dla assemblera, i to by może tam 
coś zmieniało, ale moje kryterium rozgraniczające język maszynowy 
od języka wysokiego poziomu to możliwość różnorakiej interpretacji
konstrukcji programistycznych przez programy tłumaczące lub
interpretujące, dającej określone w specyfikacji języka efekty -- 
te same dla każdego z możliwych sposobów.

W każdym razie -- o ile każdy assembler przetłumaczy mnemonik
z określonymi argumentami zawsze na tę samą sekwencję bitów, 
to występująca w języku C instrukcja inkrementacji  może zostać
zaimplementowana przez program tłumaczący lub interpretujący 
na wiele różnych sposobów.

> To sie i tak przeklada na gonitwe elektronow obijajacych sie
> o bariery potencjalu w tranzystorach.

Niekoniecznie.  Można przecież uruchomić program w maszynie
wirtualnej, w której najniższy poziom abstrakcji jest określony 
przez kod napisany w języku wysokiego poziomu.

-- 
http://www.piotr.dembiński.prv.pl