abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
dnes 01:00 | Komunita

Luboš Kocman, Release Manager openSUSE Leap, oznámil, že verze 15.2 linuxové distribuce openSUSE Leap vstoupila do beta fáze. Připojit se lze k testování a hlásit chyby. Aktivní testeři mohou získat tričko. Finální vydání openSUSE Leap 15.2 je plánováno na 7. května 2020.

Ladislav Hagara | Komentářů: 4
včera 23:11 | Nová verze

Oficiálně byla vydána nová stabilní verze 2.10.18 svobodné aplikace pro úpravu a vytváření rastrové grafiky GIMP. Přehled novinek i s náhledy a videi v oznámení o vydání a v souboru NEWS na GitLabu. Verze 2.10.16 nebyla kvůli vážné chybě oficiálně vydána.

Ladislav Hagara | Komentářů: 0
včera 22:55 | Nová verze

Balík Rakudo Star, tj. Rakudo včetně modulů a dokumentace, byl vydán ve verzi 2020.01. Rakudo je implementace programovacího jazyka Raku. Ten byl ještě nedávno znám pod názvem Perl 6.

Ladislav Hagara | Komentářů: 0
včera 20:00 | Komunita

Aaron Griffin, dosavadní vedoucí projektu Arch Linux, oficiálně oznámil výsledek volby nového vedoucího projektu Arch Linux. Novým vedoucím se stal Levente Polyak (anthraxx).

Ladislav Hagara | Komentářů: 0
včera 07:00 | Zajímavý článek

Nová čísla časopisů od nakladatelství Raspberry Pi: MagPi 90 (pdf), HackSpace 28 (pdf) a Wireframe 31 (pdf) a 32 (pdf).

Ladislav Hagara | Komentářů: 0
23.2. 15:22 | Nová verze

Byla vydána nová verze 0.3.0 multimediálního serveru zprostředkujícího aplikacím na Linuxu jednotný přístup k audiu a videu PipeWire (Wikipedie). Přehled novinek v souboru NEWS na GitHubu. Zdůraznit lze například vylepšenou kompatibilitu s JACK.

Ladislav Hagara | Komentářů: 0
23.2. 13:22 | Zajímavý článek

Michal Špaček informuje v článku Maximální délka platnosti HTTPS certifikátů bude zkrácena na 1 rok na svých stránkách: "Apple tento týden na setkání certifikačních autorit a prohlížečů oznámil, že od 1. září tohoto roku bude maximální platnost TLS certifikátů v Safari (a možná i v celém macOS a iOS) zkrácena na 1 rok, čímž v podstatě zabil certifikáty s delší platností".

Ladislav Hagara | Komentářů: 15
23.2. 13:00 | Nová verze

Byla vydána nová verze 12.8 softwarového nástroje s webovým rozhraním umožňujícího spolupráci na zdrojových kódech GitLab (Wikipedie). Představení nových vlastností s náhledy a animovanými gify v příspěvku na blogu.

Ladislav Hagara | Komentářů: 8
22.2. 21:11 | Nová verze

Vyšla nová verze 1.4.0 nástroje pro připojení ke vzdálené ploše Remmina. Mezi změnami figurují např. opravy autentizace přes SSH nebo nakládání se schránkou při připojení přes RDP. Sestavení dostupná z PPA pro Ubuntu skončí ve prospěch Flatpaku a Snapu.

Fluttershy, yay! | Komentářů: 6
21.2. 16:33 | Komunita

Google zveřejnil seznam 200 organizací přijatých do letošního Google Summer of Code (GSoC). Dle plánu se studenti přihlašují od 16. do 31. března. Vydělat si mohou od 3 000 do 6 600 dolarů. V Česku a na Slovensku 3 600 dolarů. Další informace v často kladených otázkách (FAQ). K dispozici jsou také statistiky z minulých let.

Ladislav Hagara | Komentářů: 2
Vydržela vám novoroční předsevzetí?
 (9%)
 (5%)
 (3%)
 (83%)
Celkem 195 hlasů
 Komentářů: 0
Rozcestník

www.AutoDoc.Cz

Pharo 8.0

Vyšlo Pharo 8.0. Přináší lepší nástroje pro refactoring či spoluráci s Gitem. Pharo je programovací jazyk a vývojové prostředí s řadou pokročilých vlastností.

20.1. 17:11 | Pavel Křivánek | Nová verze


Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

Komentáře

Vložit další komentář

21.1. 21:52 Viktor Čistič
Rozbalit Rozbalit vše Re: Pharo 8.0
Na jednu stranu to vypadá jako úžasné sci-fi (myšleno v dobré), ale na druhou stranu mne to nutí přemýšlet: v čem je sakra háček? Proč se to víc nepoužívá?

Nechcete o tom napsat někdo článek (nebo spíš seriál)? Rád bych to viděl na příkladech z praxe.
21.1. 22:57 pkm
Rozbalit Rozbalit vše Re: Pharo 8.0
Podle mě je problém, že to "nestackuje" tím jak je to všechno integrované dohromady: IDE, GUI, něco jako operační systém. Programovací jazyky, které si z toho jen vyzobaly myšlenky (ObjectiveC, Python, Java, ...) se ukázaly praktičtější. Idea "obrazu" není příliš kompatibilní třeba s gitem, takže integrace s ním je jedna z novinek.

Komerční implementaci Smalltalku VisualWorks používá prý JP Morgan Chase. Skoro bych se tam nechal zaměstnat, jen abych to viděl.
Bystroushaak avatar 22.1. 12:46 Bystroushaak | skóre: 36 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Pharo 8.0
Nechcete o tom napsat někdo článek (nebo spíš seriál)? Rád bych to viděl na příkladech z praxe.
Viz ten štítek smalltalk, tam nějaké ty články najdeš.
Na jednu stranu to vypadá jako úžasné sci-fi (myšleno v dobré), ale na druhou stranu mne to nutí přemýšlet: v čem je sakra háček? Proč se to víc nepoužívá?
Ze své zkušenosti musím říct, že to minimálně v minulosti vyžadovalo docela netriviální časovou investici a dokumentace nebyla moc dobrá. Taky máš super prostředí, kde ovšem musíš používat všechno úplně neznámé, od způsobu verzování po grafickou knihovnu. A spousta z těch věcí měla bugy a spousta dalších věcí byla v oficiální image v několika historických verzích a pro začátečníka bez učitele byl docela bordel se v tom vyznat. Ve stylu "a mám používat metacello, nebo monticello, nebo nějaký další projekt X", protože vesměs to vypadá, že fungují všechny všechny přístupy. A pak dáš commit a ono ti to sigsegvne na libgit2 a tak.

Jinak to co popisuji byla verze 4, teď se to hodně zlepšilo a mám v plánu tomu dát někdy další šanci na nějaký projekt, až si uvolním ruce od těch současných.
Jak psal Bystroushaak. Je to kombinací řady faktorů. Vyžaduje to na začátku překročit dost velkou vstupní bariéru, má to otravné technických nedostatky a nestačil se u toho (zatím) vytvořit dostatečný síťový efekt. Ale lepší se to a zkusit Pharu obětovat trochu času na jeho osvojení není dle mého naprosto neobjektivního názoru špatná investice :-)
I'm sure it crashed in the most type-safe way possible.
22.1. 17:21 OldFrog {Ondra Nemecek} | skóre: 32 | blog: Žabákův notes | Praha
Rozbalit Rozbalit vše Re: Pharo 8.0
Příklady z praxe tam mají https://pharo.org/success

Jinak souhlas, lidi by to raději zkusili, pokud by to mohli používat ve svém oblíbeném IDE a s nějakým rozumným GUI toolkitem. Je to hezký výzkumný projekt, ale dělat v tom praktickou aplikaci bych asi zatím nechtěl.
-- OldFrog
23.1. 10:55 tukan
Rozbalit Rozbalit vše Re: Pharo 8.0
Na jednu stranu to vypadá jako úžasné sci-fi (myšleno v dobré), ale na druhou stranu mne to nutí přemýšlet: v čem je sakra háček? Proč se to víc nepoužívá?

 

Nechcete o tom napsat někdo článek (nebo spíš seriál)? Rád bych to viděl na příkladech z praxe.

Seriál o smalltalku by určitě nebyl problém (lidi co to umí by se našli třeba Pavel Křivánek .), i jiní zde vypadají, že už do toho nějaký čas investovali, něco umím i já). Jinak je možné najít články na root(u) - např. squeak případně na zdrojáku a našli by se určitě další další. Stačí více pohledat a těch článků je poměrně dost.

V čem je háček?

Tady je nutné se podívat do historie.

Kupodivnu hlavním problémem Smalltalku v počátcích nebyl vůbec technický, ale lidský.  Byla to obyčejná lidská hamižnost.  Na začátku této cesty stála A. Goldberg, která účtovala nehorázné poplatky za licence, pak chtěla podíl na zisku z firem, které používaly smalltalk (opravdu!) a zastavení vývoje společností, které měli sublicencovaný smalltalk - více doporučuji čtení na první wiki c2.com.  Absurně vysoké poplatky byl podle mého hlavní důvod proč se Smalltalk od počátku lavinovitě neprosadil.

Druhá háček byl vstup modré smrti alias IBM.  IBM je obrovský mamut a chtěl se prostadit v oblasti Smalltalk s produktem VisualAge for Smalltalk.  Čehož se zalekly firmy Digitalk a ParcPlace.  Ty se rozhodly provést sloučení, které dopadlo spíše jako boj na život a na smrt.   Pěkný člának o tom jeTale of Terror

.

A pak přišlel Sun se svojí Javou zdarma a IBM se rozhodlo, že nebude soutěžit s Javou (kam přešla většina vývojářů VM z IBM). Díky IBM se Smalltalk dostal třeba do bank jako je J.P.Morgan nebo na Wallstreet a jinde, ale najednou nebyla žádná firma schopná to podporovat. Následně vznikl pohrobek Cincom (výsledek spojenom Digitalk a ParcPlace), kterému teď zvoní umíráček.

Po IBM jeho smalltalk převzala firma Instantiations a ta se o něj stará a stále vybírá absurdně velké poplatky za licence. Ale je skutečně komečně nasazen a používá se.

Nejschopnější smalltalk je v součastnosti asi GemStone/S, který chvíli vlastnil i VmWare, což byl docela úlet. Nicméně se po této epizodě opět osamostatnil a stále existuje a vyvíjí se dál. Tady je také poměrně široké nasazení

Další reálně nasazený smalltalk je Smalltalk/X od firmy eXcept. Existuje dokonce i odnož, kde lze najít českou stopu Honzy Vraného a jeho Smalltalk/X-jv.

V problémech jsou Pharo a Cincom VisualWorks. Odešli od nich vývojáři VM a tudíž se VM nevyvíjí. Pharo uvádí nové blištivé fičury jako git integraci (Iceberg), ale není tam chuť ani vůle se zastavit a opravovat chyby, které se nakupili. A Cincom také upadá, i když dovnitř nevidím asi tam nebude nic moc atmosféra, když lidé co tam pracovali roky firmu najednou opouští.

Pak jsou zde další jako Dolphin, Squeak, GNU Smalltalk a Amber. Tyhle jsou spíše okrajové důležitosti a spíše na naučení jak to funguje a nevím jestli jsou někde více nasazeny.

Co Smalltalku chybí?

Nyní asi nějaká větší firma či komunita co by se do toho obula. Microsoft má svůj .NET, Google Go a spoustu dalších, SUN (Oracle) má Javu, Facebook má PHP. Pak jsou zde víceméně komunitní věcí jako Python, Ruby či Rust, kolem kterých se utvořila životaschopná komunita a začalo to fungovatl. Smalltalk nic takového bohužel neměl a zatím podle mého nemá (šanci mělo Pharo, ale zde to dle mého názoru nevypadá úplně slibně).

Další důležitým aspektem jsou pracovní příležitosti. Nějaké jsou, ale moc jich není a pokud chce nováček vstoupit do světa Smalltalku není to tak jednoduché, protože většinu pozic mají zkušení matadoři.

Osobně si myslím, že je spíše zázrak, že Smalltalk přežil své několikateré klinické smrti a stále se v něm programuje. Spíše to vypovídá o tom, jak se ve smalltalku dobře programuje a celý ten koncept je výborně vymyšlen.

Co se týká Smalltalk image. Ta je, v současné podobě, dle mého názoru již překonaná myšlenka (vznikla v době, kdy sdílení kódu ve formě VCS vůbec neexistovalo, internet byl v plenkách) - tato myšlenka by potřebovala zásadní inovaci a spojit CVS s image by bylo úžasné.

Diky za shrnutí

Cincom je společnost, co skupuje staré technologie s "vendor lock-in" a ždímá zákazníky, dokud to jde. Bez toho, aby svoje produkty nějak zásadně rozvíjela. Bohužel se do jejích spárů dostala i největší komerční implementace Smalltalku. To, že chtějí podíl na zisku svých zákazníků, platí do dneška. Těm se to samozřejmě moc nelíbí a aktivně pokukují po alternativách, Především po Pharu.

Takže tyto firmy buď aktivně pracují na přechodu nebo se alespoň spolupodílejí na financování vývoje Phara jako své budoucí potenciální platformy. I díky tomu Pharo docílilo stavu, kdy je schopné ufinancovat několik full-time vývojářů.

Co se virtuálních strojů týká, od Cincomu vývojáři neodešli, byli odejiti. Situace ohledně virtuálního stroje Phara se točí hlavně kolem osoby Eliota Mirandy, což je hlavní vývojář OpenSmalltalk VM, kterou Pharo používá, ale on sám Pharo otevřeně nesnáší. V důsledku toho nakonec letos Pharo de-facto vytvořilo fork této VM, na což Eliot zareagoval vyloženě nepřátelsky, viz licence k tomuto balíčku: http://www.squeaksource.com/ClosedVMMaker/

Díky tomu ale vývoj virtuálního stroje Phara pokročil za pár měsíců víc než za několik let. Eliot blokoval tak základní infrastrukturní kroky jako sjednocení všech zrojových kódů v jednom Git repozitáři, použití cmake atd.. Pharo VM má nyní konečně fungující headless VM, threaded FFI, virtuální stroj je použitelný jako dynamická knihovna, má skutečně fungující CI, pročištěné závislostmi balíčků, řadou nových testů atd. Takže bych to tak černě neviděl.

Nemyslím si, že by VCS a koncept image byl v nějakém rozporu, ale chvíli trvalo najít způsob, jak je sloučit do funkčního celku. Čímž netvrdím, že by koncept image nezasloužil inovovat, ale kvůli VCS to nutné není.

I'm sure it crashed in the most type-safe way possible.
24.1. 11:57 tukan
Rozbalit Rozbalit vše Re: Pharo 8.0
Není vůbec zač, myslím si, že je dobré, aby lidé co chtějí se Smalltalkem koketovat, věděli jak se věci mají.

Cincom je společnost, co skupuje staré technologie s "vendor lock-in" a ždímá zákazníky, dokud to jde. Bez toho, aby svoje produkty nějak zásadně rozvíjela. Bohužel se do jejích spárů dostala i největší komerční implementace Smalltalku. To, že chtějí podíl na zisku svých zákazníků, platí do dneška. Těm se to samozřejmě moc nelíbí a aktivně pokukují po alternativách, Především po Pharu.

Takže tyto firmy buď aktivně pracují na přechodu nebo se alespoň spolupodílejí na financování vývoje Phara jako své budoucí potenciální platformy. I díky tomu Pharo docílilo stavu, kdy je schopné ufinancovat několik full-time vývojářů.

Ano, společnost Cincom je nyní takový parazit, který se snaží ze svých zákazníků vysát co nejvíce za co nejméně úsilí. To, že se do spárů dostala v roce 1999 může právě spackané spojení ParcPlace and Digitalk, vznik javy a IBM. Cincom to stálo prý kolem $3m což byla směšná částka. Více na VisualWorks selling to Cincom. Když tam byl zesnulý James Robertson, tak se vývoj konal a vypadalo to na světlé zítřky - takže parazitem nebyly vždy a nějaký vývoj se skutečně konal. V současnosti pouze paběrkují a nejspíše je očekává se hořký konec, ostatně všechny firmy co rezignují na inovace a vlastní vývoj.

Co vím, tak se aktnivně koukají po alternativách, ale Pharo často mezi nimi chybí. Důvody jsou různé, ale s těma firmami co jsem mluvil vadí následující:

1] problém se stabilitou prostředí, což jsem si ověřil sám na vlastní kůži. Není vůbec žádný problém shodit prostředí. Stabilita je nutnost pokud to člověk na tom má běžet produkční prostředí. Tým kolem Pharo by měl věnovat hodně soustředěného úsilí na stabilizaci prostředí. Nic takové ale nevidím, což se možná špatně dívám, rád se nechám poučit.

2] chybí dlouhodobé plánování (roadmap) a z toho těžko předvídatelný vývoj.

3] Díky bodu 2] Tudíž tendence na produkcích zůstat u původního Pharo a nezkoušet nové věci, protože se bojí, a asi oprávněně, budou trávit hodně časo migrací a objevovat chyby nové a žít s těmi starými. Na staré chyby už mají způsoby jak se jim vyhnout.

4] problém překompilovaní nové verze knihoven oproti staršímu Pharu. Například libgit2 na RedHat(u).

5] na spoustě funkcionalit dělá pouze jeden člověk, který když odejde tak není kdo by ho udržoval a tudíž chyby se kupí a celé to chřadne.

6] rekompilace celého Pharo ze zdrojáků je práce spíše pro šamany než inženýry. Je to opravdu oříšek to zkompilovat.

7] neexistence migrační schématu v případě migrace ze starší verze (co přesně má člověk očekávat, jaké problémy mohou nastat, atd.).

8] závislost na historických verzích gcc - chybí podpora pro novější. Teď je stable gcc 9.x, lze zkompilovat Pharo s gcc 8, 7 atd. co jsem koukal tak to nejde. Možná mě opravíte?

Co se virtuálních strojů týká, od Cincomu vývojáři neodešli,
Děkuji za upřesnění. V konečném důsledku je to to samé, žádný vývoj neprobíhá, případně možná opravy. Cincom je loď co jde ke dnu.

Situace ohledně virtuálního stroje Phara se točí hlavně kolem osoby Eliota Mirandy, což je hlavní vývojář OpenSmalltalk VM, kterou Pharo používá, ale on sám Pharo otevřeně nesnáší. V důsledku toho nakonec letos Pharo de-facto vytvořilo fork této VM, na což Eliot zareagoval vyloženě nepřátelsky, viz licence k tomuto balíčku: http://www.squeaksource.com/ClosedVMMaker/

Díky tomu ale vývoj virtuálního stroje Phara pokročil za pár měsíců víc než za několik let. Eliot blokoval tak základní infrastrukturní kroky jako sjednocení všech zrojových kódů v jednom Git repozitáři, použití cmake atd..

Tady pravděpodobně budeme zpět u lidských vztahů a ne technických, což se u Smalltalku obecně dost často vyskytuje, protože lidí co se profesně věnují Smalltalku moc není. Domnívám se, nebyl jsem u toho, že je to spíše osobní nevraživost mezi šéfem projektu Stephanem Ducasse a Eliotem Mirandy. Ostatně u Phara předtím skončil další VM vývojář Clément Béra, ten nyní pracuje u Googlu, předpokládám, že se opět nějakým způsobem neshodli na osobní rovnině. Docela by mě zajímalo, kdo nyní pracuje na u Pharo na jeho VM? Pokud bránil rozvoji a vývoji VM, tak je asi jenom dobře, že nechce sdílet svojí práci s Pharo, ne? To co popisujete jako jsou (jeden git repository, cmake, atd.) to jsou spíše údržbové záležiosti, kterou jsou důležité, ale nejde o vývoj VM jako JIT, multi-threaded VM, atd. Jak mě říkal jeden kamarád, dnešní Javascript VMky jsou prakticky všechny lepší než-li nejlep39 Smalltakové. Je to svým způsobem daň za úspěch Smalltalku, ale také to vypovídá něco o komunitě. Místo soustředění se na nedůležité detaily jako implementace #become: se soustředit na to v čem byl opravdový pokroj a kde ujel vlak.

Pharo VM má nyní konečně fungující headless VM, threaded FFI, virtuální stroj je použitelný jako dynamická knihovna, má skutečně fungující CI, pročištěné závislostmi balíčků, řadou nových testů atd. Takže bych to tak černě neviděl.

To rád slyším, tohle pročisťování je klíčem ke stabilitě, po které všichni volají. Kde je nyní místo, kde se sbírají případné chyby? Držím palce, ať se to podaří.

Nemyslím si, že by VCS a koncept image byl v nějakém rozporu, ale chvíli trvalo najít způsob, jak je sloučit do funkčního celku. Čímž netvrdím, že by koncept image nezasloužil inovovat, ale kvůli VCS to nutné není.

Tady jsme si nerozumněli. Netvrdím, že image je v rozporu s VCS. Psal jsem jenom o tom, že Smalltalkový image je v původní verzi v současnosti těžko použitelný pokud, by někdo chtěl sdílet právě ten image mezi více uživateli a pak ten kód nějakým způsobem v té image udržovat. t.j. aby každý vývojář si mohl stáhnout současnou image a přidat k ní své rozdíly, s tím pak pracovat a následně uložit změny a aktualizovat image, aby z ní mohli ostatní vycházet.

Pokusů o verzovacích systémů má Smalltalk za sebou několik, ale moderní verzovací systémy jako git či mercurial všechny daleko přesahují, proto Pharo pochopitelně pracovalo na itegraci s git, což je jen dobře. (Pro ostatní původní verzovací systémy u Smalltalku: Monticello (Pharo), ENVY (VA Smalltalk) a Store (VisualWorks))

V současnosti pouze paběrkují a nejspíše je očekává se hořký konec, ostatně všechny firmy co rezignují na inovace a vlastní vývoj.

Naposledy, když jsem slyšel o situaci v Cincomu, tak se tvrdilo, že majitel umírá a zbylý management se snaží urvat, co se dá. Což pro jejich budoucnost nevěští nic dobrého a světu Smalltalku to také nepřidá.

1] problém se stabilitou prostředí, což jsem si ověřil sám na vlastní kůži. Není vůbec žádný problém shodit prostředí. Stabilita je nutnost pokud to člověk na tom má běžet produkční prostředí. Tým kolem Pharo by měl věnovat hodně soustředěného úsilí na stabilizaci prostředí. Nic takové ale nevidím, což se možná špatně dívám, rád se nechám poučit.

V posledních verzích se to zlepšilo, ale, abych byl upřímný, s příchodem headless VM v Pharo 9.0 se to pravděpodobně zase zhorší, alespoň tedy u image s IDE.

2] chybí dlouhodobé plánování (roadmap) a z toho těžko předvídatelný vývoj.

Osobně jsem neviděl roadmap na víc než jedno vydání dopředu ani u komerčních impmlementací, ale u Phara byly původní cíle definovány v dokumentu "Pharo’s Vision", který je ovšem už překonaný, protože se tam nastíněné vize dočkaly realizace. Devátá verze přinese Threaded FFI, headless image, Spec 2 (s podporou Gtk), nový skriptovatelný object-centric debugger, všechny nástroje se upraví (pravděpodobně ne hned ve verzi 9) tak, aby nový Spec používaly, takže se vývojové nástroje stanou nezávislými na Morphicu.

3] Díky bodu 2] Tudíž tendence na produkcích zůstat u původního Pharo a nezkoušet nové věci, protože se bojí, a asi oprávněně, budou trávit hodně časo migrací a objevovat chyby nové a žít s těmi starými. Na staré chyby už mají způsoby jak se jim vyhnout.

Pharo používá mechanismy, které umožňují automaticky opravovat konstrukce a volání označené jako "deprecated" i nástroje na migraci, které se zkoušely na reálných projektech a dařilo se jim migrovat kód někdy od verze 1.2. Navíc je kód základního systému v posledních verzích bez větších změn. Mimochodem, JP Morgan migruje z verze VisualWorks 7 na verzi 8 už dva roky, co jsem se doslechl. Jeden z cílů, které Pharo Consortium má, je přímo zajišťovat migraci aplikací pro zákazníky.

4] problém překompilovaní nové verze knihoven oproti staršímu Pharu. Například libgit2 na RedHat(u).

Pharo zatím nemá žádnou LTS. O problémech s VM jsme již mluvili a tohle s nimi přímo souvisí.

5] na spoustě funkcionalit dělá pouze jeden člověk, který když odejde tak není kdo by ho udržoval a tudíž chyby se kupí a celé to chřadne

To není problém jen Phara. Ale Pharo samotné spíš trpí tím, že se deklaruje náhrada nějakého subsystému (např. Morphic), což spolehlivě zabije nějakou motivaci ten subsystém udržovat, aníž ta náhrada skutečně v rozumné době příjde.

6] rekompilace celého Pharo ze zdrojáků je práce spíše pro šamany než inženýry. Je to opravdu oříšek to zkompilovat.

Bootstrapping se dělá při každém pull requestu a je tedy přímo automatizovaný a reprodukovatlený. Na druhou stranu uznávám, že by si zasloužil mnohem lépe zdokumentovat, aby bylo jednodušší jej upravovat pro vývojáře bez šamanských zkoušek.

7] neexistence migrační schématu v případě migrace ze starší verze (co přesně má člověk očekávat, jaké problémy mohou nastat, atd.)

Viz předchozí body, Pharo se snaží označovat věci jako deprecated a likvudují se až ve verzi následující.

8] závislost na historických verzích gcc - chybí podpora pro novější. Teď je stable gcc 9.x, lze zkompilovat Pharo s gcc 8, 7 atd. co jsem koukal tak to nejde. Možná mě opravíte?

Minimálně s verzí 7 to určitě jde. Na CI servery, které Pharo VM kompilují, se historické verze GCC rozhodně cíleně nedávají. Případné problémy, prosím, reportujte na https://github.com/pharo-project/opensmalltalk-vm

Domnívám se, nebyl jsem u toho, že je to spíše osobní nevraživost mezi šéfem projektu Stephanem Ducasse a Eliotem Mirandy.

To značné míry. Ducasse se občas nechová mic diplomaticky a někdy reaguje přehnaně, takže když se střetne s osobností, která je na tom podobně, je oheň na střeše. Clémentovi se asi vidina toho, že by pod ním měl dlouhodobě pracovat, příliš nezamlouvala, ale nezažil jiné šéfy, tak doufám, že neskočil z bláta do louže. Musím říct, že Stéphane toho pro něj udělal skutečně hodně.

Na VM pracuje především Pablo Tesone. Dále Esteban Lorenzano a Guillermo Polito. Nejsou to takové superstar jako Eliot, ale jsou hodně dobří a dát do pořádku infrastrukturu kolem VM je teď nejdůležitější pro další rozvoj. JavaScriptové VMky jsou samozřejmě mnohem výkonější než Smalltalkové, vzhledem k investicím a některým nižším nárokům JavaScriptu. Osobně si nemyslím, že je reálné, aby Pharo mělo v brzké budoucnosti klasickou vícevláknovou VM. Musí jít cestou víceméně samostatných komunikujících image.

Psal jsem jenom o tom, že Smalltalkový image je v původní verzi v současnosti těžko použitelný pokud, by někdo chtěl sdílet právě ten image mezi více uživateli a pak ten kód nějakým způsobem v té image udržovat. t.j. aby každý vývojář si mohl stáhnout současnou image a přidat k ní své rozdíly, s tím pak pracovat a následně uložit změny a aktualizovat image, aby z ní mohli ostatní vycházet.

Pracují v malém týmu, kde v přesně tohle děláme (jen s tím rozdílem, že vývojáři nikdy nesdílí své image, protože je sestavuje CI)

I'm sure it crashed in the most type-safe way possible.
27.1. 11:18 tukan
Rozbalit Rozbalit vše Re: Pharo 8.0
Předně děkuji za podnětnou diskuzi.
Naposledy, když jsem slyšel o situaci v Cincomu, tak se tvrdilo, že majitel umírá a zbylý management se snaží urvat, co se dá. Což pro jejich budoucnost nevěští nic dobrého a světu Smalltalku to také nepřidá.
To Smalltalku rozhodně nepřidá, zase na druhou stranu mohlo by to narušit status quo a mohli by se ledy pohnout a konečně se uvolnit některé věci které byly zatuhlé mnoho let. Cincom k jedné takové zatuhlé věci patřilo, od doby co James Robertson odešel.
1] problém se stabilitou prostředí, což jsem si ověřil sám na vlastní kůži. Není vůbec žádný problém shodit prostředí. Stabilita je nutnost pokud to člověk na tom má běžet produkční prostředí. Tým kolem Pharo by měl věnovat hodně soustředěného úsilí na stabilizaci prostředí. Nic takové ale nevidím, což se možná špatně dívám, rád se nechám poučit.
V posledních verzích se to zlepšilo, ale, abych byl upřímný, s příchodem headless VM v Pharo 9.0 se to pravděpodobně zase zhorší, alespoň tedy u image s IDE.

To rád slyším, naposledy jsem to testoval ve verzy 6/7 a spadlo mě to tak do minuty. Samozřejmě když člověk ví co "nemá" dělat, když už to používá dlouho, tak se tomu dokáže vyhnout, ale to by nemělo být účelem.

Docela by mě zajímalo, proč headless VM zhorší stabilitu prostředí? Přidání nové funkcionality, pokud se ví, že způsobuje zhoršení stability, by se mělo odložit dokud se neopraví bolestivá místa a vydat to v okamžiku, kdy nejsou známy žádné takovéto vedlejší účinky (to samozřejmně neznamená, že tam chyby nebudou, některé jako "race conditions" se nedají jednoduše odhalit). Stabilita prostředí je klíčem k úspěchu v podnikové oblasti, bez stability nemůže být o větším nasazovaní moc řeč.

2] chybí dlouhodobé plánování (roadmap) a z toho těžko předvídatelný vývoj.
Osobně jsem neviděl roadmap na víc než jedno vydání dopředu ani u komerčních impmlementací, ale u Phara byly původní cíle definovány v dokumentu "Pharo’s Vision", který je ovšem už překonaný, protože se tam nastíněné vize dočkaly realizace. Devátá verze přinese Threaded FFI, headless image, Spec 2 (s podporou Gtk), nový skriptovatelný object-centric debugger, všechny nástroje se upraví (pravděpodobně ne hned ve verzi 9) tak, aby nový Spec používaly, takže se vývojové nástroje stanou nezávislými na Morphicu.

U těch komerčních Smalltaků, co jsem stačil zaznamenat tak je to spíše na nějaký časový úsek a následně nějaké zhodnocení či prezentace jak se co povedlo. Komerční Smalltalk implementace Například: VAST má roadmap na každý rok na VAST roadmap. U GemStone/S jsem to viděl spíše ve formě prezentací (pro rok 2015, 2017). Ono by přesně stačilo udělat jednoduchý seznam co se dá očekávat u 9ky:

  • threaded FFI
  • headless image
  • spec 2 (s podporou Gtk)
  • nový skriptovatelný object-centric debugger
  • úprava instrumentária, aby byla nezávislá na Morphic
.

To zní jako HODNĚ...HODNĚ moc práce. U toho threaded FFI se trochu bojím, jak to bude s těma threadama a stabilitou. Nebudou tam vznikat zámky (deadlocks) nebo problémy se souběhem (race condition)? Headless image je super (divím se, že to přichází tak pozdě), ale zase ne za cenu snížení stability prostředí. Nový debugger, to je skvělé, ale pořádný debugger je na roky práce ne? spec2 s gtk (doufám, že gtk3) tak pokud se to udělá pořádně, tak to bude v oblasti GUI krok správným směrem! To přepsání všeho do spec2 to zní jako hodně moc práce. Trochu mě napadá jestli to není moc změn na jednu verzi? Jenom ten debugger by stačil na verzi 9.

3] Díky bodu 2] Tudíž tendence na produkcích zůstat u původního Pharo a nezkoušet nové věci, protože se bojí, a asi oprávněně, budou trávit hodně časo migrací a objevovat chyby nové a žít s těmi starými. Na staré chyby už mají způsoby jak se jim vyhnout.
Pharo používá mechanismy, které umožňují automaticky opravovat konstrukce a volání označené jako "deprecated" i nástroje na migraci, které se zkoušely na reálných projektech a dařilo se jim migrovat kód někdy od verze 1.2. Navíc je kód základního systému v posledních verzích bez větších změn. Mimochodem, JP Morgan migruje z verze VisualWorks 7 na verzi 8 už dva roky, co jsem se doslechl. Jeden z cílů, které Pharo Consortium má, je přímo zajišťovat migraci aplikací pro zákazníky.

To rád slyším, i když o nich čtu poprvé. Možná by stálo za úvahu mít nějaký ukázkový projet a ukázat jak se to dělá. Nevím jestli zákazníci budou chtít, aby pro ně Pharo Concortium dělalo migraci, někteří si z povahy dat, se kterými zacházejí budou muset udělat migraci sami. U JP Morgan nemají kam odmigorvat, když Cincom přestal s vývojem. Takže odmigrovat sice můžou zkusit, ale když nebude nikdo kdo je bude podporovat, tak mají asi smůlu.

4] problém překompilovaní nové verze knihoven oproti staršímu Pharu. Například libgit2 na RedHat(u).
Pharo zatím nemá žádnou LTS. O problémech s VM jsme již mluvili a tohle s nimi přímo souvisí.

LTS verze by vyřešila řadu problémů, proč vlastně není žádná LTS verze?

5] na spoustě funkcionalit dělá pouze jeden člověk, který když odejde tak není kdo by ho udržoval a tudíž chyby se kupí a celé to chřadne
To není problém jen Phara.

To asi není, ale když o tom tak přemýšlím (marně přemýšlím, který další projekt je Ph.D. projekt driven, kde se něco vyvine v rámci Ph.D. a pak ten člověk odejde), tak každý projekt ala Linux Kernel (o dost větší projekt), Git, OpenBSD(tam má nejvyšší autoritu Theo, mají pravidelné hackatlony, chyba v dokumentaci či chybějící dokumentace je rovna chybě v kódu), Wireshark atd. mají fáze vývojové a fáze udržovací. Každý může poslat návrh na změnu (patch), ale záleží na správci daného substému, případně celého projektu jestli danou změnu přijme nebo ji nechá k přepracovaní nebo ji zamítne zcela s nějakým rozumným odůvodněním. Takovýto systém by asi slušil i Pharu. Jde o to, že když se něco vyvine, tak by to automaticky mělo mít správce, který je s funkcionalitou dostatečně obeznámen a dokáže kód udržovat, zkontrolovat, až pak se přidá do hlavní větve. Správce(i) pak udržují danou funkcionalitu a jsou za ní zodpovědní.

Ale Pharo samotné spíš trpí tím, že se deklaruje náhrada nějakého subsystému (např. Morphic), což spolehlivě zabije nějakou motivaci ten subsystém udržovat, aníž ta náhrada skutečně v rozumné době příjde.

To je právě ten problém s plánováním a je to přirozená skutečnost. Pokud se uvede, že bude přechod ala gtk2 na gtk3, tak je jasné, že aktivita u gtk2 bude upadat a věnujese většina energie na gtk3. Pokud se odhadne, že gtk3 tu bude za zhruba 5 let, tak je jasné, že je potřeba udržovat gtk2 ještě 5 let, ale je jasné, že nový vývoj u něho moc nebude, bude se pouze udržovat. Proto je potřeba takovéto zásadní změny opravdu dobře naplánovat.

6] rekompilace celého Pharo ze zdrojáků je práce spíše pro šamany než inženýry. Je to opravdu oříšek to zkompilovat.
Bootstrapping se dělá při každém pull requestu a je tedy přímo automatizovaný a reprodukovatlený. Na druhou stranu uznávám, že by si zasloužil mnohem lépe zdokumentovat, aby bylo jednodušší jej upravovat pro vývojáře bez šamanských zkoušek

To rád slyším, že je to automatizované a reprodukovatelné. Když jsem to před nějakým časem zkoušel tak to opravdu nešlo a nechtěl jsem tomu věnovat čas, protože jsem si říkal, že se to postupně stejně musí nějakým způsobem automatizovat, jinak ten vývoj jde dělat opravdu těžko. Teď ještě nějakou dokumentaci, pro ty z nás co nejsou v srdci projektu.

8] závislost na historických verzích gcc - chybí podpora pro novější. Teď je stable gcc 9.x, lze zkompilovat Pharo s gcc 8, 7 atd. co jsem koukal tak to nejde. Možná mě opravíte?
Minimálně s verzí 7 to určitě jde. Na CI servery, které Pharo VM kompilují, se historické verze GCC rozhodně cíleně nedávají. Případné problémy, prosím, reportujte na https://github.com/pharo-project/opensmalltalk-vm

Co mě chybí je seznam jaké přesně gcc verze jsou podporávny a co není. U toho gcc 7 je podporáno vše, tedy 7.x? Nebo je to jenom 7.0 nebo pouze nejnovější 7.3.x? Když si vezmu dokument HowToBuild opensmalltalk-vm tak je tam zmínka o problémech s gcc version > 4.2.1.

Pamatuji si dokonce, tak 2-3 roky zpět kdy se na mailing listu psalo něco takovéhoto:

My understanding is that gcc 4.8(.4) is the default version in trusty, so if anyone else wants to build the VM with the same compiler, they'll need gcc 4.8. At the moment it is needed because a few people have found that the VM doesn't work properly if compiled with gcc 5.4

Děkuji a za link, až to bude opět zkoušet určitě to tam nahlásím.

Domnívám se, nebyl jsem u toho, že je to spíše osobní nevraživost mezi šéfem projektu Stephanem Ducasse a Eliotem Mirandy.
To značné míry. Ducasse se občas nechová mic diplomaticky a někdy reaguje přehnaně, takže když se střetne s osobností, která je na tom podobně, je oheň na střeše. Clémentovi se asi vidina toho, že by pod ním měl dlouhodobě pracovat, příliš nezamlouvala, ale nezažil jiné šéfy, tak doufám, že neskočil z bláta do louže. Musím říct, že Stéphane toho pro něj udělal skutečně hodně.

Také mám takový pocit, že reaguje přehnaně. Šéf projektu by měl bý i diplomat a umět se domluvit, což přiznávám může být občas složité. Trochu mě to připomíná situaci s Lennart(em) Poettering(em) a jeho systemd, kde problém není technický ale osobnostní. Nevím jak se daří Clémentovi, ale protože vypadá, že tam stále pracuje snad je i spokojen. Do zákulisí skutečně nevidím a nedokážu ocenit kolik pro něj S. Ducasse udělal či neudělal.

Na VM pracuje především Pablo Tesone. Dále Esteban Lorenzano a Guillermo Polito. Nejsou to takové superstar jako Eliot, ale jsou hodně dobří a dát do pořádku infrastrukturu kolem VM je teď nejdůležitější pro další rozvoj.

Děkuji za jména, nějak jsem ztratil pojem kdo tam teď zbyl. Měl jsem pocit, že Esteban pracuje na celém projektu a nejen na VM. On se teď věnuje hlavně VM? G. Polita jsem ještě někde zahlédl. P. Tesone neznám, ale našel jsem si práci GildaVM: a Non-Blocking I/O Architecture for the Cog VM, kterou si musím pročíst, která je k tématu. Trochu se obávám toho, že vývoj VM zpomalí, protože odchod 2 schopných VM vývojářů je těžko nahradit a další nerostou na stromech. Rád se budu mýlit.

JavaScriptové VMky jsou samozřejmě mnohem výkonější než Smalltalkové, vzhledem k investicím a některým nižším nárokům JavaScriptu. Osobně si nemyslím, že je reálné, aby Pharo mělo v brzké budoucnosti klasickou vícevláknovou VM. Musí jít cestou víceméně samostatných komunikujících image.

JavaScript je samozřejmně díky prohlížečům teď na výslunní a nelze porovnávat množství prostředků vložených do jeho VM vs. Smalltalkových. Jelikož je u Smalltalku mnohem méně prostřeků je daleko důležitější je investovat správným směrem Jde mě o to, že je možné se inspirovat u těchto "našlápnutých" VM a přestat lpět na některých detailech, které v konečném důsledku nejsou vůbec důležité.

Co se týká vícevláknové VM, tak její vytvoření představuje hodně práce nejen na VM, ale i na základních knihovnách, které musí být bezpečné pro vícevláknové použití. Nejsem si jist jestli je cesta samostatně komunikujících image jediná možné, určitě je nejjenodušší. Vím, že Matz (tvůrce ruby), s podobným principem již delší dobu koketuje, ale není s výsledky spokojen - je tam přiliž velká penalizace mezi komunikujícími procesy.

Možná, že zajímavější a prespektivnější cestou by byla implementace IBM OMR (zdrojové kódy: omr github), kde je možnost využít obrovské práce IBM, které zobecnila svojí JVM pro využití v ostatních jazycích. Už mimochodem implemntovali ukázkovou Smalltakovou VM SOM smalltalk.

Pracují v malém týmu, kde v přesně tohle děláme (jen s tím rozdílem, že vývojáři nikdy nesdílí své image, protože je sestavuje CI)
Ano, to už se blíží tomu co jsem myslel! To je významný pokrok. Já jsem přemýšlel to dotáhnout ještě o krok dále, kde by se takováto vygenerovaná image spojená s vývojářovím diffem (kde by byly zaznamenámy pohy oken, stav debuggeru atd.) otevřela podobně jak se otevírá uložená image na jednotlivých počítačích.
Předně děkuji za podnětnou diskuzi.

Nápodobně :-)

To Smalltalku rozhodně nepřidá, zase na druhou stranu mohlo by to narušit status quo a mohli by se ledy pohnout a konečně se uvolnit některé věci které byly zatuhlé mnoho let. Cincom k jedné takové zatuhlé věci patřilo, od doby co James Robertson odešel.

VA Smalltalk se v poslední době začal hýbat správným směrem. Třeba nakonec VisualWorks od Cincomu koupí nějaký stávající zákazník jako Lam Research a oživí to.

Docela by mě zajímalo, proč headless VM zhorší stabilitu prostředí?

Protože více práce přejde na image, třeba zpracování událostí okenního manažeru. Nedělám si iluze, že to bude mít jen pozitivní dopady. Osobně headless VM používám téměř výhradně už asi půl roku a žádné větší problémy jsem s ní nezaznamenal, ale na některé krizové situace je prostě z principu citlivější. Přínosy by to ale měly vyvážit.

To zní jako HODNĚ...HODNĚ moc práce

Prezentace roadmap pro Pharo je napříkad zde: https://www.youtube.com/watch?v=6vax47zC47Y. Je to hodně práce a vše z toho je již v pokročilé fázi vývoje. Pharo 8 mělo alespoň část z toho obsahovat, ale raději jsme přistoupili k vydání víceméně opravné verze a získali více času na dokončení těch věcí, než se to vše snažit urychleně dokončit a neustále vydání odkládat. ThreadedFFI je na tom se stabilitou velmi dobře a teď potřebuje spíš už jen výkonnostní optimalizace. Pozdě přichází proto, protože Eliot. Ano, jedná se o Gtk3. Přepis všech nástrojů do Spec2 se určitě ve verzi 9 ještě nestihne, pokud se nestane nějaký zázrak.

JP Morgan na migraci na Pharo aktivně pracuje, víceméně se snaží ho ohnout tak, aby co nejvíc odpovídalo VisualWorks, takže např. implementovali jmenné prostory a podobné VW specifické konstrukce. Má to ale několik ale. Je to velký byrokratický moloch, který neumí spolupracovat s open-source světem. Také největší ořišek je migrace UI a vhledem k tomu, jak rychle postupují při migraci v rámci verzí VisualWorks, je to ještě na dlouho. Na migraci na Pharo pracuje aktivně třeba ještě Lifeware (cca 8000 tříd jen datového modelu) a Schmidt.

Takovýto systém by asi slušil i Pharu

Ano, ale to samozřejmě naráží na lidské zdroje. Pharo pořádá každý měsíc setkání, kde se opravují chyby a s přechotem na GitHub je i podstatně jednodušší dělat posouzení pull-requestů, takže to dělá více lidí. Ale jednoznačně přiřaditelné správce má jen několik podsystémů.

je tam zmínka o problémech s gcc version > 4.2.1.

pharo-project/pharo-vm není aktuální repozitář. Podle Pabla funguje překlad na GCC 9.3.

Do zákulisí skutečně nevidím a nedokážu ocenit kolik pro něj S. Ducasse udělal či neudělal.

Stéphane dělal vše možné, aby mu zajistil stabilní místo kde by si do důchodu mohl dělat téměř cokoliv, co by chtěl, které ale nakonec Clément (z výše uvedených důvodů) odmítnul, což Stéphane vzal jako kudlu do zad. Chápu oba.

Měl jsem pocit, že Esteban pracuje na celém projektu a nejen na VM. On se teď věnuje hlavně VM? G. Polita jsem ještě někde zahlédl. P. Tesone neznám, ale našel jsem si práci GildaVM: a Non-Blocking I/O Architecture for the Cog VM, kterou si musím pročíst, která je k tématu. Trochu se obávám toho, že vývoj VM zpomalí, protože odchod 2 schopných VM vývojářů je těžko nahradit a další nerostou na stromech. Rád se budu mýlit.

Na VM pracuje především Pablo, což je opravdu prvotříní všestranný programátor. ThreadedFFI a dokončení headless VM je jeho zásluha. Esteban se na VM podílí především v oblastech, které se dotýkají spolupráce s Gtk (např. aby VM běžela ve vedlejším vlákně a ne hlavním). Guillermo je tak od všeho něco, pracuje, mimo jiné, na vylepšení způsobu překladu Slangu.

Co se týká vícevláknové VM, tak její vytvoření představuje hodně práce nejen na VM, ale i na základních knihovnách, které musí být bezpečné pro vícevláknové použití. Nejsem si jist jestli je cesta samostatně komunikujících image jediná možné, určitě je nejjenodušší.

Ano, GC a základní knihovna představují asi největší problém. Na druhou stranu, Pharo ma velmi slušný jednovláknový GC i celkový výkon, takže by byla toho nevyužít a spíše se snažit image rozdělit na řadu menších. Hnát se ale za co nejvyšším výkonem není ta nejlepší cesta, protože žene vývoj do lokálního maxima, ze které je nemožné přeskočit skutečně dále.

¨
Já jsem přemýšlel to dotáhnout ještě o krok dále, kde by se takováto vygenerovaná image spojená s vývojářovím diffem (kde by byly zaznamenámy pohy oken, stav debuggeru atd.) otevřela podobně jak se otevírá uložená image na jednotlivých počítačích.

Zatím jen přizpůsobujeme image konkrétním lidem (změní se nastavení, otevřou se požadovaná okna...), ale něco takového je samozřejmě možné.

I'm sure it crashed in the most type-safe way possible.
28.1. 13:58 tukanos
Rozbalit Rozbalit vše Re: Pharo 8.0
Děkuji za odpovědi a za zeptání se na to gcc. To určitě vyzkouším.

Jenom toto Vaše vyjádření nechápu:
Hnát se ale za co nejvyšším výkonem není ta nejlepší cesta, protože žene vývoj do lokálního maxima, ze které je nemožné přeskočit skutečně dále.
V čem spočívá to lokální minimum ze kterého je možná přeskočit (ochladit, žíhat) dále? Pokud mám framework jako OMR, který už ma zasebou jistě mnoho tisíců hodin běhu, tak je nějakým způsobem odzkoušen, tak by to mohlo podstatně ušetřit práci na dosáhnutí vícevláknového prostředí.

Myslím to tak, že "hackovatelnost" virtuálního stroje to značně omezuje. Podobné snahy sice mohou vést k vysokému výkonu na jednotkách jader, ale pro stovky až tisíce částečně nelokálních jader je potřeba použít diametrálně jiné přístupy, které jsou sice v souladu se základními myšlenkami Smalltalku, ale experimentovat s nimi na základu aktuálních vypiplaných, rychlých a komplikovaných virtuálních strojů je téměř nemožné. To je ale možná až moc akademický pohled.
I'm sure it crashed in the most type-safe way possible.
29.1. 12:50 tukanos
Rozbalit Rozbalit vše Re: Pharo 8.0
Aha, tak tak to už chápu, pokud by se jednalo o nelokální jádra.

Pokud, v hypotetickém příkladu budu mít lokálně 128 jáder k dispozici (dnešní 2x AMD) CPU, a budu mít takovýchto 10 vrcholů (nodů) zapojených v nějakou hyperkostku, budu dohoromady chtít obsloužit 1280 jader, tak stejně bude záležet lokálním výkonu jednotlivých vrcholů (nodů) v dané kostce.

Mohu pak mít třeba nějaké neblokující směrovaní třeba ecube směrovaní. Když budu mít lokální nody rychlé, pak jim mohu rychleji rozdávat jednotlivé porce úloh.

Otázkou zůstává jestli tohle by měla řešit přímo VM nebo raději knihovna ala OpenMP. Osobně bych to, zatím, viděl raději jako knihovna nad VM, kde VM se snažila využit maximum jednolivých nodů.

Já zkoušel třeba vytvářet sítě 128 takových uzlů, kde každý je obousměrně propojen s každým a má na ostatní uzly proxy objekty, takže jim může přirozeně zasílat zprávy. Dokonce i s vypracovanou distribucí kódu mezi takové uzly. Ale to není jediná možná cesta.

S Marcusem Denkerem se teď nezávazně snažíme načrtnout architekturu, která by Pharo mohla posunout někam dál. Jde o to alespoň mít nějaou konrétnější představu, jakým směrem se ubírat. Momentální představy jsou asi takové:

  • redefinovat relaci vlastnění objektu jiným objektem. Jde v podstatě o to zmenšit rozídl mezi jedním objekty a image. Mít větší kontrolu nad komunikací skupiny objektů s jinými skupinami a umožnit tak např. distribuované systémy s distribuovaným GC.
  • zvětšit objektovost systému (což u Phara muže už samo o sobě znít dost zvláštně, ale prostor je tu obrovský). Například zavedení first-class referencí atd.
  • co nejvíce potřít oddělení VM od zbytku systému
  • rozšířit možnosti zasílání zpráv a odpovědí na ně. Asynchronní zpracování jako výchozí
  • v smalltalkovském objektovém systému je vlastně skutečně živý jen jeden druh objektů - aktivační objekty metod. Využít toho, mít nad image libovolné množství "workerů", které je budou zpracovávat.
  • Mít na image "přilepeno" několik dalších typů workerů, například pro směrování zpráv a přípravu aktivačních objektů, JIT či pro GC. Mít GC jako službu objektového systému, která je pokud možno jeho součástí
  • atd. atd.
I'm sure it crashed in the most type-safe way possible.
30.1. 16:04 tukanos
Rozbalit Rozbalit vše Re: Pharo 8.0
Tak teď už mám konkrétnější představu.

Vše vypadá moc pěkně otázkou je jak to bude při určité zasycenosti kanálu, případně chybovostí?

Image by tedy byl rozprostřen mezi všechny nody a obsluha by byla pomocí pracantů (worker(ů))- image by v konečném důsledku mohl být objektem sám a pak by se to setřelo úplně. No s tím JIT a distributed GC to bude složité, ale zajímavé.

Opravdu děkuji za podnětnou diskuzi! Moc pěkné!

Založit nové vláknoNahoru


ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.