Python - Historie editací

Jst: /* Co jsi zkoumal nejdříve? Proč to nefunguje správně? */

Jst — Tue, 02 Oct 2018 06:10:49 GMT

Co jsi zkoumal nejdříve? Proč to nefunguje správně?

← Starší verze		Verze z 2. 10. 2018, 06:10
Řádka 12:		Řádka 12:

	Občas zkouším rozjet náhodné scripty, abychom viděli, jak je na tom naše implementace. Jednak tím testujeme možné chyby a jednak také sleduji performance. Když jsem narazil na článek na Root.cz, kde byla porovnávána rychlost výpočtu obrázku různého rozlišení na základě Mandelbrotovy množiny, zkusil jsem autorův Python skript pustit také na naší implementaci. Nejdříve jsem musel doimplementovat asi dvě specializace v naší implementaci, abychom byli schopni skript spustit. To bylo jednoduché a otázka několik minut.		Občas zkouším rozjet náhodné scripty, abychom viděli, jak je na tom naše implementace. Jednak tím testujeme možné chyby a jednak také sleduji performance. Když jsem narazil na článek na Root.cz, kde byla porovnávána rychlost výpočtu obrázku různého rozlišení na základě Mandelbrotovy množiny, zkusil jsem autorův Python skript pustit také na naší implementaci. Nejdříve jsem musel doimplementovat asi dvě specializace v naší implementaci, abychom byli schopni skript spustit. To bylo jednoduché a otázka několik minut.
		+
		+	===== Co to je ta specializace? =====
		+
		+	[[TBD]]

	Jenže po spuštění jsem zjistil, že čas který je potřeba pro výpočet obrázku je několikanásobně větší než je potřeba pro výpočet toho samého obrázku v CPython. Problém byl v tom, že algoritmus vypočítané barvy jednotlivých bodů ukládá do stringu a nakonec celý string je vypsán na standartní výstup, který je přesměrován do souboru. Asi si řeknete, že to není ideální řešení, nicméně je to zdrojový kód z praxe.		Jenže po spuštění jsem zjistil, že čas který je potřeba pro výpočet obrázku je několikanásobně větší než je potřeba pro výpočet toho samého obrázku v CPython. Problém byl v tom, že algoritmus vypočítané barvy jednotlivých bodů ukládá do stringu a nakonec celý string je vypsán na standartní výstup, který je přesměrován do souboru. Asi si řeknete, že to není ideální řešení, nicméně je to zdrojový kód z praxe.

Jst: /* Pracuješ v pražské pobočce OracleLabs. Co tu vlastně děláš? */

Jst — Tue, 02 Oct 2018 06:09:04 GMT

Pracuješ v pražské pobočce OracleLabs. Co tu vlastně děláš?

← Starší verze		Verze z 2. 10. 2018, 06:09
Řádka 5:		Řádka 5:
	==== Pracuješ v pražské pobočce OracleLabs. Co tu vlastně děláš? ====		==== Pracuješ v pražské pobočce OracleLabs. Co tu vlastně děláš? ====

-	Posledních pár měsíců pracuji na implementaci jazyka Python v Graal VM. Před tím, než jsem začal pracovat v Oracle Labs, tak jsem dělal pár editorů do NetBeans IDE. V NetBeans jsem se naučil hodně o lexování, ~~pársovaní~~, AST a mnoho dalších věcí, které se týkají analýzy zdrojového kódu. Tohle mi určitě pomohlo v Oracle Labs, ale i tak je to jen malá část toho, co potřebují vědět nyní.	+	Posledních pár měsíců pracuji na implementaci jazyka Python v Graal VM. Před tím, než jsem začal pracovat v Oracle Labs, tak jsem dělal pár editorů do NetBeans IDE. V NetBeans jsem se naučil hodně o lexování, parsovaní, AST a mnoho dalších věcí, které se týkají analýzy zdrojového kódu. Tohle mi určitě pomohlo v Oracle Labs, ale i tak je to jen malá část toho, co potřebují vědět nyní.

	==== Co jsi zkoumal nejdříve? Proč to nefunguje správně? ====		==== Co jsi zkoumal nejdříve? Proč to nefunguje správně? ====

Jst v 2. 10. 2018, 06:08

Jst — Tue, 02 Oct 2018 06:08:48 GMT

← Starší verze		Verze z 2. 10. 2018, 06:08
Řádka 1:		Řádka 1:
-	[[GraalVM]] umí spouštět různé jazyky, mimo jinými i [[wikipedia:Python\|Python]]. Proto jsem byl překvapený, že Pavel Tišňovský ve svých předchozích porovnáních různých implementací jazyka [[Python]] neuvedl i [[GraalVM\|GraalPython]] (například při popisu [https://www.root.cz/clanky/rpython-prekvapive-vykonny-dialekt-pythonu-na-nemz-je-zalozen-pypy/ RPythonu] či [https://www.root.cz/clanky/prakticke-pouziti-nastroje-cython-pri-prekladu-pythonu-do-nativniho-kodu-1/ Cythonu]). Trochu uraženě jsem si tedy vyzkoušel, jak si s uvedeným [[wikipedia:Mandelbrot\|Mandelbrot]] příkladem poradí náš [[Python]]. No a nakonec jsem byl vlastně rád, že to Pavel nevyzkoušel. Nejen, že to počítalo dlouho, ale hlavně počítalo úplně špatně. Výsledný obrázek nevypadal ~~tak~~ jako ostatní.	+	[[GraalVM]] umí spouštět různé jazyky, mimo jinými i [[wikipedia:Python\|Python]]. Proto jsem byl překvapený, že Pavel Tišňovský ve svých předchozích porovnáních různých implementací jazyka [[Python]] neuvedl i [[GraalVM\|GraalPython]] (například při popisu [https://www.root.cz/clanky/rpython-prekvapive-vykonny-dialekt-pythonu-na-nemz-je-zalozen-pypy/ RPythonu] či [https://www.root.cz/clanky/prakticke-pouziti-nastroje-cython-pri-prekladu-pythonu-do-nativniho-kodu-1/ Cythonu]). Trochu uraženě jsem si tedy vyzkoušel, jak si s uvedeným [[wikipedia:Mandelbrot\|Mandelbrot]] příkladem poradí náš [[Python]]. No a nakonec jsem byl vlastně rád, že to Pavel nevyzkoušel. Nejen, že to počítalo dlouho, ale hlavně počítalo úplně špatně. Výsledný obrázek vůbec nevypadal jako ty ostatní.

	To však bylo na začátku srpna. Od té doby si s tím Petr Pišl hraje, udělal pár vylepšení a [[GraalVM]] 1.0.0 RC6 již nejen počítá správně, ale je také výrazně rychlejší než standardní [[Python]]3 a přitom nevyžaduje žádné změny kódu. Dovolil jsem si tedy Petra vyzpovídat a zeptat se jej, jak to dokázal.		To však bylo na začátku srpna. Od té doby si s tím Petr Pišl hraje, udělal pár vylepšení a [[GraalVM]] 1.0.0 RC6 již nejen počítá správně, ale je také výrazně rychlejší než standardní [[Python]]3 a přitom nevyžaduje žádné změny kódu. Dovolil jsem si tedy Petra vyzpovídat a zeptat se jej, jak to dokázal.

Jst: /* Proč to vlastně bylo tak pomalé? A jak jsi na to přišel? */

Jst — Tue, 02 Oct 2018 06:07:09 GMT

Proč to vlastně bylo tak pomalé? A jak jsi na to přišel?

← Starší verze		Verze z 2. 10. 2018, 06:07
Řádka 19:		Řádka 19:
	Tady narážíme na problém zpracování stringu v jazyku Java, což je jazyk ve kterém je naše implementace napsaná. Sčítání stringů v Javě je poměrně rychlá, ale ovšem jen do té doby, než začne docházet paměť. Dříve nebo později se zavolá Arrays.copyof a tento příkaz vyžaduje souvislou volnou paměť pro vytvoření nového pole. Pokud velikost volné paměti je menší, než požadovaná velikost nového pole, dostanete OutOfMemoryException a končíte. To je ta lepší varianta z hlediska performance. Horší situace je, když volná paměť je, ale vytvářené pole se nevejde do žádného souvislého místa v paměti. V tu chvíli se zapíná GC a snaží se paměť uvolnit, tak aby se nové pole vešlo na jedno místo. Za špatných podmínek toto může trvat i několik desítek sekund. Nechci úplně zabíhat do podrobností, to by bylo na samostatný článek.		Tady narážíme na problém zpracování stringu v jazyku Java, což je jazyk ve kterém je naše implementace napsaná. Sčítání stringů v Javě je poměrně rychlá, ale ovšem jen do té doby, než začne docházet paměť. Dříve nebo později se zavolá Arrays.copyof a tento příkaz vyžaduje souvislou volnou paměť pro vytvoření nového pole. Pokud velikost volné paměti je menší, než požadovaná velikost nového pole, dostanete OutOfMemoryException a končíte. To je ta lepší varianta z hlediska performance. Horší situace je, když volná paměť je, ale vytvářené pole se nevejde do žádného souvislého místa v paměti. V tu chvíli se zapíná GC a snaží se paměť uvolnit, tak aby se nové pole vešlo na jedno místo. Za špatných podmínek toto může trvat i několik desítek sekund. Nechci úplně zabíhat do podrobností, to by bylo na samostatný článek.

-	Pokud někdo zná Graal a Truffle, tak ví, že jednotlivé jazyky lze běhat buď v JVM nebo SVM módu. Kód předkompilovaný pomocí SVM ~~módu~~ startuje mnohonásobně rychleji než v JVM. Jenže tady jsem narazil na chybu v SVM, která právě zahrnuje chování Arrays.copyof a čas, který byl potřeba pro běžení skriptu na generování obrázku o velikosti 1024x1024 bodů, byl 15 minut.	+	Pokud někdo zná Graal a Truffle, tak ví, že jednotlivé jazyky lze běhat buď v JVM nebo SVM módu. Kód předkompilovaný pomocí SVM startuje mnohonásobně rychleji než v JVM. Jenže tady jsem narazil na chybu v SVM, která právě zahrnuje chování Arrays.copyof a čas, který byl potřeba pro běžení skriptu na generování obrázku o velikosti 1024x1024 bodů, byl 15 minut.

	==== Jak jsi to zrychloval? ====		==== Jak jsi to zrychloval? ====

Jst: /* Proč to vlastně bylo tak pomalé? A jak jsi na to přišel? */

Jst — Tue, 02 Oct 2018 06:06:51 GMT

Proč to vlastně bylo tak pomalé? A jak jsi na to přišel?

← Starší verze		Verze z 2. 10. 2018, 06:06
Řádka 19:		Řádka 19:
	Tady narážíme na problém zpracování stringu v jazyku Java, což je jazyk ve kterém je naše implementace napsaná. Sčítání stringů v Javě je poměrně rychlá, ale ovšem jen do té doby, než začne docházet paměť. Dříve nebo později se zavolá Arrays.copyof a tento příkaz vyžaduje souvislou volnou paměť pro vytvoření nového pole. Pokud velikost volné paměti je menší, než požadovaná velikost nového pole, dostanete OutOfMemoryException a končíte. To je ta lepší varianta z hlediska performance. Horší situace je, když volná paměť je, ale vytvářené pole se nevejde do žádného souvislého místa v paměti. V tu chvíli se zapíná GC a snaží se paměť uvolnit, tak aby se nové pole vešlo na jedno místo. Za špatných podmínek toto může trvat i několik desítek sekund. Nechci úplně zabíhat do podrobností, to by bylo na samostatný článek.		Tady narážíme na problém zpracování stringu v jazyku Java, což je jazyk ve kterém je naše implementace napsaná. Sčítání stringů v Javě je poměrně rychlá, ale ovšem jen do té doby, než začne docházet paměť. Dříve nebo později se zavolá Arrays.copyof a tento příkaz vyžaduje souvislou volnou paměť pro vytvoření nového pole. Pokud velikost volné paměti je menší, než požadovaná velikost nového pole, dostanete OutOfMemoryException a končíte. To je ta lepší varianta z hlediska performance. Horší situace je, když volná paměť je, ale vytvářené pole se nevejde do žádného souvislého místa v paměti. V tu chvíli se zapíná GC a snaží se paměť uvolnit, tak aby se nové pole vešlo na jedno místo. Za špatných podmínek toto může trvat i několik desítek sekund. Nechci úplně zabíhat do podrobností, to by bylo na samostatný článek.

-	Pokud někdo zná Graal a Truffle, tak ví, že jednotlivé jazyky lze běhat buď v JVM nebo SVM ~~modu~~. ~~Překompilovaný kód v~~ SVM módu ~~je několikánásobně rychlejší~~ než ~~spouštění~~ v JVM. Jenže tady jsem narazil na chybu v SVM, která právě zahrnuje chování Arrays.copyof a čas, který byl potřeba pro běžení skriptu na generování obrázku o velikosti 1024x1024 bodů, byl 15 minut.	+	Pokud někdo zná Graal a Truffle, tak ví, že jednotlivé jazyky lze běhat buď v JVM nebo SVM módu. Kód předkompilovaný pomocí SVM módu startuje mnohonásobně rychleji než v JVM. Jenže tady jsem narazil na chybu v SVM, která právě zahrnuje chování Arrays.copyof a čas, který byl potřeba pro běžení skriptu na generování obrázku o velikosti 1024x1024 bodů, byl 15 minut.

	==== Jak jsi to zrychloval? ====		==== Jak jsi to zrychloval? ====

Jst: /* Proč to vlastně bylo tak pomalé? A jak jsi na to přišel? */

Jst — Mon, 01 Oct 2018 16:14:47 GMT

Proč to vlastně bylo tak pomalé? A jak jsi na to přišel?

← Starší verze		Verze z 1. 10. 2018, 16:14
Řádka 17:		Řádka 17:
	==== Proč to vlastně bylo tak pomalé? A jak jsi na to přišel? ====		==== Proč to vlastně bylo tak pomalé? A jak jsi na to přišel? ====

-	Tady narážíme ne problém zpracování stringu v jazyku Java, což je jazyk ve kterém je naše implementace napsaná. Sčítání stringů v Javě je poměrně rychlá, ale ovšem jen do té doby, než začne docházet paměť. Dříve nebo později se zavolá Arrays.copyof a tento příkaz vyžaduje souvislou volnou paměť pro vytvoření nového pole. Pokud velikost volné paměti je menší, než požadovaná velikost nového pole, dostanete OutOfMemoryException a končíte. To je ta lepší varianta z hlediska performance. Horší situace je, když volná paměť je, ale vytvářené pole se nevejde do žádného souvislého místa v paměti. V tu chvíli se zapíná GC a snaží se paměť uvolnit, tak aby se nové pole vešlo na jedno místo. Za špatných podmínek toto může trvat i několik desítek sekund. Nechci úplně zabíhat do podrobností, to by bylo na samostatný článek.	+	Tady narážíme na problém zpracování stringu v jazyku Java, což je jazyk ve kterém je naše implementace napsaná. Sčítání stringů v Javě je poměrně rychlá, ale ovšem jen do té doby, než začne docházet paměť. Dříve nebo později se zavolá Arrays.copyof a tento příkaz vyžaduje souvislou volnou paměť pro vytvoření nového pole. Pokud velikost volné paměti je menší, než požadovaná velikost nového pole, dostanete OutOfMemoryException a končíte. To je ta lepší varianta z hlediska performance. Horší situace je, když volná paměť je, ale vytvářené pole se nevejde do žádného souvislého místa v paměti. V tu chvíli se zapíná GC a snaží se paměť uvolnit, tak aby se nové pole vešlo na jedno místo. Za špatných podmínek toto může trvat i několik desítek sekund. Nechci úplně zabíhat do podrobností, to by bylo na samostatný článek.

	Pokud někdo zná Graal a Truffle, tak ví, že jednotlivé jazyky lze běhat buď v JVM nebo SVM modu. Překompilovaný kód v SVM módu je několikánásobně rychlejší než spouštění v JVM. Jenže tady jsem narazil na chybu v SVM, která právě zahrnuje chování Arrays.copyof a čas, který byl potřeba pro běžení skriptu na generování obrázku o velikosti 1024x1024 bodů, byl 15 minut.		Pokud někdo zná Graal a Truffle, tak ví, že jednotlivé jazyky lze běhat buď v JVM nebo SVM modu. Překompilovaný kód v SVM módu je několikánásobně rychlejší než spouštění v JVM. Jenže tady jsem narazil na chybu v SVM, která právě zahrnuje chování Arrays.copyof a čas, který byl potřeba pro běžení skriptu na generování obrázku o velikosti 1024x1024 bodů, byl 15 minut.

109.81.214.101: /* Proč to vlastně bylo tak pomalé? A jak jsi na to přišel? */

109.81.214.101 — Fri, 31 Aug 2018 09:15:31 GMT

Proč to vlastně bylo tak pomalé? A jak jsi na to přišel?

← Starší verze		Verze z 31. 8. 2018, 09:15
Řádka 16:		Řádka 16:

	==== Proč to vlastně bylo tak pomalé? A jak jsi na to přišel? ====		==== Proč to vlastně bylo tak pomalé? A jak jsi na to přišel? ====
		+
		+	Tady narážíme ne problém zpracování stringu v jazyku Java, což je jazyk ve kterém je naše implementace napsaná. Sčítání stringů v Javě je poměrně rychlá, ale ovšem jen do té doby, než začne docházet paměť. Dříve nebo později se zavolá Arrays.copyof a tento příkaz vyžaduje souvislou volnou paměť pro vytvoření nového pole. Pokud velikost volné paměti je menší, než požadovaná velikost nového pole, dostanete OutOfMemoryException a končíte. To je ta lepší varianta z hlediska performance. Horší situace je, když volná paměť je, ale vytvářené pole se nevejde do žádného souvislého místa v paměti. V tu chvíli se zapíná GC a snaží se paměť uvolnit, tak aby se nové pole vešlo na jedno místo. Za špatných podmínek toto může trvat i několik desítek sekund. Nechci úplně zabíhat do podrobností, to by bylo na samostatný článek.
		+
		+	Pokud někdo zná Graal a Truffle, tak ví, že jednotlivé jazyky lze běhat buď v JVM nebo SVM modu. Překompilovaný kód v SVM módu je několikánásobně rychlejší než spouštění v JVM. Jenže tady jsem narazil na chybu v SVM, která právě zahrnuje chování Arrays.copyof a čas, který byl potřeba pro běžení skriptu na generování obrázku o velikosti 1024x1024 bodů, byl 15 minut.

	==== Jak jsi to zrychloval? ====		==== Jak jsi to zrychloval? ====

109.81.214.101: /* Co jsi zkoumal nejdříve? Proč to nefunguje správně? */

109.81.214.101 — Fri, 31 Aug 2018 09:13:55 GMT

Co jsi zkoumal nejdříve? Proč to nefunguje správně?

← Starší verze		Verze z 31. 8. 2018, 09:13
Řádka 14:		Řádka 14:

	Jenže po spuštění jsem zjistil, že čas který je potřeba pro výpočet obrázku je několikanásobně větší než je potřeba pro výpočet toho samého obrázku v CPython. Problém byl v tom, že algoritmus vypočítané barvy jednotlivých bodů ukládá do stringu a nakonec celý string je vypsán na standartní výstup, který je přesměrován do souboru. Asi si řeknete, že to není ideální řešení, nicméně je to zdrojový kód z praxe.		Jenže po spuštění jsem zjistil, že čas který je potřeba pro výpočet obrázku je několikanásobně větší než je potřeba pro výpočet toho samého obrázku v CPython. Problém byl v tom, že algoritmus vypočítané barvy jednotlivých bodů ukládá do stringu a nakonec celý string je vypsán na standartní výstup, který je přesměrován do souboru. Asi si řeknete, že to není ideální řešení, nicméně je to zdrojový kód z praxe.
-
-	Tady narážíme ne problém zpracování stringu v jazyku Java, což je jazyk ve kterém je naše implementace napsaná. Sčítání stringů v Javě je poměrně rychlá, ale ovšem jen do té doby, než začne docházet paměť. Dříve nebo později se zavolá Arrays.copyof a tento příkaz vyžaduje souvislou volnou paměť pro vytvoření nového pole. Pokud velikost volné paměti je menší, než požadovaná velikost nového pole, dostanete OutOfMemoryException a končíte. To je ta lepší varianta z hlediska performance. Horší situace je, když volná paměť je, ale vytvářené pole se nevejde do žádného souvislého místa v paměti. V tu chvíli se zapíná GC a snaží se paměť uvolnit, tak aby se nové pole vešlo na jedno místo. Za špatných podmínek toto může trvat i několik desítek sekund. Nechci úplně zabíhat do podrobností, to by bylo na samostatný článek.
-
-	Pokud někdo zná Graal a Truffle, tak ví, že jednotlivé jazyky lze běhat buď v JVM nebo SVM modu. Překompilovaný kód v SVM módu je několikánásobně rychlejší než spouštění v JVM. Jenže tady jsem narazil na chybu v SVM, která právě zahrnuje chování Arrays.copyof a čas, který byl potřeba pro běžení skriptu na generování obrázku o velikosti 1024x1024 bodů, byl 15 minut.

	==== Proč to vlastně bylo tak pomalé? A jak jsi na to přišel? ====		==== Proč to vlastně bylo tak pomalé? A jak jsi na to přišel? ====

109.81.214.101: /* Co jsi zkoumal nejdříve? Proč to nefunguje správně? */

109.81.214.101 — Fri, 31 Aug 2018 09:13:02 GMT

Co jsi zkoumal nejdříve? Proč to nefunguje správně?

← Starší verze		Verze z 31. 8. 2018, 09:13
Řádka 8:		Řádka 8:

	==== Co jsi zkoumal nejdříve? Proč to nefunguje správně? ====		==== Co jsi zkoumal nejdříve? Proč to nefunguje správně? ====
		+
		+	U implementace jazyka Pythonu do Graal VM nejsem od začátku. Nastoupil jsem již do rozjetého projektu, což není většinou jednoduché u projektů jako je tento. Prvních pár týdnů jsem implementoval Math modul, na kterém jsem se učil základní věci. Vlastně se pořád učím.
		+
		+	Občas zkouším rozjet náhodné scripty, abychom viděli, jak je na tom naše implementace. Jednak tím testujeme možné chyby a jednak také sleduji performance. Když jsem narazil na článek na Root.cz, kde byla porovnávána rychlost výpočtu obrázku různého rozlišení na základě Mandelbrotovy množiny, zkusil jsem autorův Python skript pustit také na naší implementaci. Nejdříve jsem musel doimplementovat asi dvě specializace v naší implementaci, abychom byli schopni skript spustit. To bylo jednoduché a otázka několik minut.
		+
		+	Jenže po spuštění jsem zjistil, že čas který je potřeba pro výpočet obrázku je několikanásobně větší než je potřeba pro výpočet toho samého obrázku v CPython. Problém byl v tom, že algoritmus vypočítané barvy jednotlivých bodů ukládá do stringu a nakonec celý string je vypsán na standartní výstup, který je přesměrován do souboru. Asi si řeknete, že to není ideální řešení, nicméně je to zdrojový kód z praxe.
		+
		+	Tady narážíme ne problém zpracování stringu v jazyku Java, což je jazyk ve kterém je naše implementace napsaná. Sčítání stringů v Javě je poměrně rychlá, ale ovšem jen do té doby, než začne docházet paměť. Dříve nebo později se zavolá Arrays.copyof a tento příkaz vyžaduje souvislou volnou paměť pro vytvoření nového pole. Pokud velikost volné paměti je menší, než požadovaná velikost nového pole, dostanete OutOfMemoryException a končíte. To je ta lepší varianta z hlediska performance. Horší situace je, když volná paměť je, ale vytvářené pole se nevejde do žádného souvislého místa v paměti. V tu chvíli se zapíná GC a snaží se paměť uvolnit, tak aby se nové pole vešlo na jedno místo. Za špatných podmínek toto může trvat i několik desítek sekund. Nechci úplně zabíhat do podrobností, to by bylo na samostatný článek.
		+
		+	Pokud někdo zná Graal a Truffle, tak ví, že jednotlivé jazyky lze běhat buď v JVM nebo SVM modu. Překompilovaný kód v SVM módu je několikánásobně rychlejší než spouštění v JVM. Jenže tady jsem narazil na chybu v SVM, která právě zahrnuje chování Arrays.copyof a čas, který byl potřeba pro běžení skriptu na generování obrázku o velikosti 1024x1024 bodů, byl 15 minut.

	==== Proč to vlastně bylo tak pomalé? A jak jsi na to přišel? ====		==== Proč to vlastně bylo tak pomalé? A jak jsi na to přišel? ====

109.81.214.101: /* Pracuješ v pražské pobočce OracleLabs. Co tu vlastně děláš? */

109.81.214.101 — Fri, 31 Aug 2018 08:24:34 GMT

Pracuješ v pražské pobočce OracleLabs. Co tu vlastně děláš?

← Starší verze		Verze z 31. 8. 2018, 08:24
Řádka 5:		Řádka 5:
	==== Pracuješ v pražské pobočce OracleLabs. Co tu vlastně děláš? ====		==== Pracuješ v pražské pobočce OracleLabs. Co tu vlastně děláš? ====

-	Posledních pár měsíců pracuji na implementaci jazyka Python v Graal VM.	+	Posledních pár měsíců pracuji na implementaci jazyka Python v Graal VM. Před tím, než jsem začal pracovat v Oracle Labs, tak jsem dělal pár editorů do NetBeans IDE. V NetBeans jsem se naučil hodně o lexování, pársovaní, AST a mnoho dalších věcí, které se týkají analýzy zdrojového kódu. Tohle mi určitě pomohlo v Oracle Labs, ale i tak je to jen malá část toho, co potřebují vědět nyní.

	==== Co jsi zkoumal nejdříve? Proč to nefunguje správně? ====		==== Co jsi zkoumal nejdříve? Proč to nefunguje správně? ====