On 2013-05-08 07:51, Paweł Kierski wrote:
> Gdyby nie oberwał i była bezpieczna, to aplikacje androidowe byłyby
> w byte-code Javy

Dalvik jest zupełnie inna implementacją. I nie tylko z powodu licencji.
Google wielokrotnie zeznawał że jest "lepsza" cokolwiek by to miało
znaczyć i to raczej w sensie technicznym niż prawniczym.

do góry

On 08/05/2013 06:51, Paweł Kierski wrote:
> W dniu 2013-05-07 15:11, Michal Kleczek pisze:
>>
>> No wlasnie chyba Google nic od Oracla w koncu nie oberwal... I od tej
>> pory chyba Java juz jest bezpieczna...
>
> Gdyby nie oberwał i była bezpieczna, to aplikacje androidowe byłyby
> w byte-code Javy, a nie lewą ręką do prawego ucha w imię zgodności
> z licencją.

A zanim oberwał to były?

Sprawdź może fakty. Google nie oberwał. Dalvik to nie JVM. Pozew Oracle
był o trzy rzeczy:

1. Naruszenie patentów Javy w Dalviku,
2. Skopiowanie interfejsu biblioteki runtime,
3. Skopiowanie kodu biblioteki runtime.

W kwestii 1 sąd uznał, że naruszenie praw nie miało miejsca.
W kwestii 2, uznał że projekt API nie podlega ochronie praw autorskich,
W kwestii 3 zostały znalezione niewielkie naruszenia i Google został
obciążony symboliczną karą.

Jeśli w kontekście tego procesu rozważamy na ile Java jest bezpieczna,
to przede wszystkim Java jako taka jest produktem udostępnianym na
licencji, i dopóki trzymasz się warunków licencji jezteś "bezpieczny"
(modulo rozbieżności w interpretacji tej licencji). To właśnie
korzystanie z Javy jest bardziej bezpieczne niż nie korzystanie, bo
jeśli zamiast korzystać na warunkach licencji próbujesz to samo uzyskać
"po swojemu", jak Google, to nawet jeśli nie korzystasz z kodu, to
ryzykujesz proces o naruszenie patentów lub o naruszenie praw autorskich
do elementów projektu ("non-literal infringement").

do góry

Dnia Wed, 08 May 2013 20:24:19 +0100, Andrzej Jarzabek napisał(a):

>> Gdyby nie oberwał i była bezpieczna, to aplikacje androidowe byłyby
>> w byte-code Javy, a nie lewą ręką do prawego ucha w imię zgodności
>> z licencją.
>
> A zanim oberwał to były?
>
> Sprawdź może fakty. Google nie oberwał. Dalvik to nie JVM. Pozew Oracle
> był o trzy rzeczy:
>
> 1. Naruszenie patentów Javy w Dalviku,
> 2. Skopiowanie interfejsu biblioteki runtime,
> 3. Skopiowanie kodu biblioteki runtime.

Sorry, ze pod Twoim postem, ale...

no Panowie, ja bardzo Was prosze... moze nie o prawie, patentach i
licencjach a o tym LLVM popiszta nieco? To naprawde interesujacy projekt :-)
Dziekuje za uwage.

--
pozdro
R.e.m.e.K

do góry

Dnia Wed, 08 May 2013 21:32:24 +0200 po głębokim namyśle R.e.m.e.K rzekł:

> Sorry, ze pod Twoim postem, ale...
>
> no Panowie, ja bardzo Was prosze... moze nie o prawie, patentach i
> licencjach a o tym LLVM popiszta nieco? To naprawde interesujacy projekt
> :-)
> Dziekuje za uwage.

To jakiś sport jest czy co? Ja obok o Julii, a temat zszedł na jakieś
klamerki i spieranie się o to, czy to Java ma klamerki bardziej niż
C, o Rysiu to już nie chcę wspominać :-/

Żeby nie było na mnie, Julia jest na LLVM i nawet jeżeli da się
skompilować do biblioteki jak C++, to również może generować
własny kod w runtime (jak z interpretera) - co właśnie umożliwia
LLVM. To znaczy homoikoniczność umożliwia generowanie kodu
programu przez program, ale LLVM pozwala go faktycznie wykonać.

--
Edek

do góry

On 08/05/2013 20:32, R.e.m.e.K wrote:
[...]
> no Panowie, ja bardzo Was prosze... moze nie o prawie, patentach i
> licencjach a o tym LLVM popiszta nieco? To naprawde interesujacy projekt :-)
> Dziekuje za uwage.

Osobiście doświadczeń nie mam, ale:
1. Na stronie piszą, że " Despite its name, LLVM has little to do with
traditional virtual machines" i że nie jest skrótem od niczego, myślę,
że można sobie podarować wszelkie dalsze rozważania na temat tego w jaki
sposób LLVM jest VM.
2. Byłemkiedyś na ciekawej pogadance o tym, jak w pewnej firmie
wykorzystują clanga do budowania analizatorów sprawdzających kod w C++
pod względem zgodności z coding standards tej organizacji. Myślę, że to
ciekawy pomysł warty rozważania przynajmniej w większych organizacjach
poważnie traktujących temat jakości i niezawodności programów pisanych w
C++.

Z innych rzeczy - na pewno jest to interesująca propozycja dla kogoś,
kto chce tworzyć DSL-e wykonujące się z dobrą wydajnością (czyli
kompilowane). Jakiś czas temu w takim zastosowaniu Roman W pisał o
projekcie gdzie taki język był osadzony w Haskellu, co na pewno ma swoje
zalety, ale też i wady. LLVM daje (czy zdaje się dawać) rozsądną
alternatywę implementowania samodzielnego DSL-a zamiast osadzania.

do góry

Dnia Wed, 08 May 2013 21:18:15 +0100 po głębokim namyśle Andrzej Jarzabek
rzekł:

> On 08/05/2013 20:32, R.e.m.e.K wrote:
> [...]
>> no Panowie, ja bardzo Was prosze... moze nie o prawie, patentach i
>> licencjach a o tym LLVM popiszta nieco? To naprawde interesujacy
>> projekt :-)
>> Dziekuje za uwage.
>
> Osobiście doświadczeń nie mam, ale:
> 1. Na stronie piszą, że " Despite its name, LLVM has little to do with
> traditional virtual machines" i że nie jest skrótem od niczego, myślę,
> że można sobie podarować wszelkie dalsze rozważania na temat tego w jaki
> sposób LLVM jest VM.

No ale jest VM. W tym sensie, że zapewnia istnienie LLVM IR, czyli
odpowiednika assemblera. Skoro LLVM IR nie chodzi na żadnym prawdziwym
procesorze tylko jest "assemblerem VM", mamy VM. A że to nie ma nic
wspólnego z JVM czy .Net to oczywiste, przy czym to zupełnie osobne
sprawy.

> 2. Byłemkiedyś na ciekawej pogadance o tym, jak w pewnej firmie
> wykorzystują clanga do budowania analizatorów sprawdzających kod w C++
> pod względem zgodności z coding standards tej organizacji. Myślę, że to
> ciekawy pomysł warty rozważania przynajmniej w większych organizacjach
> poważnie traktujących temat jakości i niezawodności programów pisanych w
> C++.

To użycie clanga jest użyciem clanga, jego struktury, z samym llvm
nie ma zbyt wiele wspólnego. Clang i llvm to oddzielne technologie, tylko
rozwijane razem.

> Z innych rzeczy - na pewno jest to interesująca propozycja dla kogoś,
> kto chce tworzyć DSL-e wykonujące się z dobrą wydajnością (czyli
> kompilowane). Jakiś czas temu w takim zastosowaniu Roman W pisał o
> projekcie gdzie taki język był osadzony w Haskellu, co na pewno ma swoje
> zalety, ale też i wady. LLVM daje (czy zdaje się dawać) rozsądną
> alternatywę implementowania samodzielnego DSL-a zamiast osadzania.

Czyli jak konkretnie?

--
Edek

do góry

Dnia Wed, 8 May 2013 21:15:09 +0000 (UTC), Edek napisał(a):

>> Osobiście doświadczeń nie mam, ale:
>> 1. Na stronie piszą, że " Despite its name, LLVM has little to do with
>> traditional virtual machines" i że nie jest skrótem od niczego, myślę,
>> że można sobie podarować wszelkie dalsze rozważania na temat tego w jaki
>> sposób LLVM jest VM.
>
> No ale jest VM. W tym sensie, że zapewnia istnienie LLVM IR, czyli
> odpowiednika assemblera. Skoro LLVM IR nie chodzi na żadnym prawdziwym
> procesorze tylko jest "assemblerem VM", mamy VM. A że to nie ma nic
> wspólnego z JVM czy .Net to oczywiste, przy czym to zupełnie osobne
> sprawy.

No ale czy wlasnie "chodzi" czy tylko jest przy pierwszym uruchomieniu
przekompilowywane do kodu natywnego platformy (na tejze juz platformie
sprzetowej bedac) i juz chodzi jak "zwykly" program?


--
pozdro
R.e.m.e.K

do góry

Dnia Wed, 08 May 2013 23:31:59 +0200 po głębokim namyśle R.e.m.e.K rzekł:

> Dnia Wed, 8 May 2013 21:15:09 +0000 (UTC), Edek napisał(a):
>
>>> Osobiście doświadczeń nie mam, ale:
>>> 1. Na stronie piszą, że " Despite its name, LLVM has little to do with
>>> traditional virtual machines" i że nie jest skrótem od niczego, myślę,
>>> że można sobie podarować wszelkie dalsze rozważania na temat tego w
>>> jaki sposób LLVM jest VM.
>>
>> No ale jest VM. W tym sensie, że zapewnia istnienie LLVM IR, czyli
>> odpowiednika assemblera. Skoro LLVM IR nie chodzi na żadnym prawdziwym
>> procesorze tylko jest "assemblerem VM", mamy VM. A że to nie ma nic
>> wspólnego z JVM czy .Net to oczywiste, przy czym to zupełnie osobne
>> sprawy.
>
> No ale czy wlasnie "chodzi" czy tylko jest przy pierwszym uruchomieniu
> przekompilowywane do kodu natywnego platformy (na tejze juz platformie
> sprzetowej bedac) i juz chodzi jak "zwykly" program?

Nigdy nie jest interpretowany, jeżeli o to pytasz. Opcje są takie,
że albo zwykła kompilacja do bilbioteki albo JIT w dowolnym momencie.
To ostatnie pozwala na dynamiczność podobną do Javy. Ten JIT jest
wołany ręcznie, czyli musi być jakiś program-gospodarz (tak się
tłumaczy "host"?). Ale interpretowany tak jak bytecode Javy nie
jest.

Fajne jest też to, że może wołać C. Znając nazwę funkcji i typy
parametrów można "dokompilować" wywołanie, nawet C kompilowanego
inaczej niż poprzez LLVM.

--
Edek

do góry

On 08/05/2013 22:15, Edek wrote:
> Dnia Wed, 08 May 2013 21:18:15 +0100 po głębokim namyśle Andrzej Jarzabek
> rzekł:
>
> No ale jest VM. W tym sensie, że zapewnia istnienie LLVM IR, czyli
> odpowiednika assemblera. Skoro LLVM IR nie chodzi na żadnym prawdziwym
> procesorze tylko jest "assemblerem VM", mamy VM. A że to nie ma nic
> wspólnego z JVM czy .Net to oczywiste, przy czym to zupełnie osobne
> sprawy.

No właśnie VM często się rozumie tak, że to jest środowisko, w którym
"chodzi" ten "assembler". LLVM IR w ogóle na niczym nie "chodzi", tylko
jest normalnie tłumaczone na kod maszynowy.

>> Z innych rzeczy - na pewno jest to interesująca propozycja dla kogoś,
>> kto chce tworzyć DSL-e wykonujące się z dobrą wydajnością (czyli
>> kompilowane). Jakiś czas temu w takim zastosowaniu Roman W pisał o
>> projekcie gdzie taki język był osadzony w Haskellu, co na pewno ma swoje
>> zalety, ale też i wady. LLVM daje (czy zdaje się dawać) rozsądną
>> alternatywę implementowania samodzielnego DSL-a zamiast osadzania.
>
> Czyli jak konkretnie?

Konkretnie na przykład biorąc jakiegoś Antlr-a czy coś podobnego i
generując IR na regulach produkcyjnych.

do góry

Dnia Thu, 09 May 2013 12:59:20 +0100 po głębokim namyśle Andrzej Jarzabek
rzekł:

> On 08/05/2013 22:15, Edek wrote:
>> Dnia Wed, 08 May 2013 21:18:15 +0100 po głębokim namyśle Andrzej
>> Jarzabek rzekł:
>>
>> No ale jest VM. W tym sensie, że zapewnia istnienie LLVM IR, czyli
>> odpowiednika assemblera. Skoro LLVM IR nie chodzi na żadnym prawdziwym
>> procesorze tylko jest "assemblerem VM", mamy VM. A że to nie ma nic
>> wspólnego z JVM czy .Net to oczywiste, przy czym to zupełnie osobne
>> sprawy.
>
> No właśnie VM często się rozumie tak, że to jest środowisko, w którym
> "chodzi" ten "assembler". LLVM IR w ogóle na niczym nie "chodzi", tylko
> jest normalnie tłumaczone na kod maszynowy.

No właśnie dlatego mówią, że nie VM w tradycyjnym znaczeniu. Niemniej
sama zazwa wskazuje na to, czym llvm jest. Ja od zawsze, tak mnie
nauczono, myślę w wartwach abstrakcji tam gdzie je się stosuje,
i dla mnie LLVM zapewnia abstrakcyjną VM, niezależnie od implementacji,
która tradycyjną VM nie jest.

>>> Z innych rzeczy - na pewno jest to interesująca propozycja dla kogoś,
>>> kto chce tworzyć DSL-e wykonujące się z dobrą wydajnością (czyli
>>> kompilowane). Jakiś czas temu w takim zastosowaniu Roman W pisał o
>>> projekcie gdzie taki język był osadzony w Haskellu, co na pewno ma
>>> swoje zalety, ale też i wady. LLVM daje (czy zdaje się dawać) rozsądną
>>> alternatywę implementowania samodzielnego DSL-a zamiast osadzania.
>>
>> Czyli jak konkretnie?
>
> Konkretnie na przykład biorąc jakiegoś Antlr-a czy coś podobnego i
> generując IR na regulach produkcyjnych.

W sumie. Od pisania na JVM różni się tym, że to nie jest Java tylko
raczej C ze wszystkimi bindingami; od generowania assemblera
prostsze i ma się za darmo optymalizacje. Tak czy inaczej pisze
się kompilator odpowiednio skomplikowany do języka i haczyki runtime.

Jeżeli to jest opinioa na podstawie przykładów, gdyby się znalazł
jakiś fajny link chętnie bym obejrzał.

--
Edek

do góry