Kedd 4?

[Daniel Berenyi]

Sziasztok!

Boldog Újévet mindenkinek!

Akarunk holnap, kedden meetinget tartani a szokásos 4-órai időpontban?

Ha igen, akkor várom a visszajelzéseket.

üdv,

D.

[Csaba Hruska]

Sziasztok,

Nekem nem jo a mostani kedd, mert eloadasom lesz este a berlini FP meetupon es arra keszulok. De kov hettol mar jo lesz keddenkent negytol, de mas idopont is :D

Udv,

Csaba

--
Azért kapta ezt az üzenetet, mert feliratkozott a Google Csoportok „compiler-seminar-budapest” csoportjára.
Az erről a csoportról és az ahhoz kapcsolódó e-mailekről való leiratkozáshoz küldjön egy e-amailt a(z) compiler-seminar-b...@googlegroups.com címre.
Ha szeretné megtekinteni ezt a beszélgetést az interneten, látogasson el ide: https://groups.google.com/d/msgid/compiler-seminar-budapest/CABmfui0Zif1X8bjFhVs9OFhv2QRZtKhUYq6_JKOpCM0Y_x8oaA%40mail.gmail.com.

[Gábor Horváth]

Sziasztok!

Nekem is jobb lenne jövő héttől.

Üdv,

Gábor

Ha szeretné megtekinteni ezt a beszélgetést az interneten, látogasson el ide: https://groups.google.com/d/msgid/compiler-seminar-budapest/CANjChEpFoPyBpa%3DEQTbQQ9X29CXj5OvtS5-SQ6JmqeVApK9u_w%40mail.gmail.com.

[Daniel Berenyi]

Sziasztok!

Akkor elhalasztjuk a kezdést jövő hétre.

D.

[Whisperity]

Sziasztok!

Én tegnap meg ma mindenféle félévzárási dolgokat meg doktori
beszámolókat meg egyebeket csináltam, teljesen kiment a fejemből ez az
egész. :(

On Tue, Jan 5, 2021 at 2:43 PM Gábor Horváth <xaza...@gmail.com> wrote:
>

> Ha szeretné megtekinteni ezt a beszélgetést az interneten, látogasson el ide: https://groups.google.com/d/msgid/compiler-seminar-budapest/CAPRL4a0BnWkTtuw%3D87tVQ0eLjEkRVCsCS4Erpqn9CDhHzsFFZw%40mail.gmail.com.

[Daniel Berenyi]

Sziasztok!

Ma 4-től meeting?

https://meet.google.com/bvq-koox-fpp

D.

Azért kapta ezt az üzenetet, mert feliratkozott a Google Csoportok szolgáltatásbeli compiler-seminar-budapest csoportra.

Az erről a csoportról és az ahhoz kapcsolódó e-mailekről való leiratkozáshoz küldjön egy e-amailt a(z) compiler-seminar-b...@googlegroups.com címre.

Ha szeretné megtekinteni ezt a beszélgetést az interneten, látogasson el ide: https://groups.google.com/d/msgid/compiler-seminar-budapest/CAL3FZmVRT7_dJS5O29-xTUuF5oOWSum39DjnndGvx6ZDcvYj-w%40mail.gmail.com.

[Csaba Hruska]

igen, nekem jo!

Ha szeretné megtekinteni ezt a beszélgetést az interneten, látogasson el ide: https://groups.google.com/d/msgid/compiler-seminar-budapest/CABmfui2foBC%3D%3Du_XBOQHOVF2yfYCoWFs%3DPXrF-5sXmH-i-fHOg%40mail.gmail.com.

[Csaba Hruska]

the link expired, a new one is needed!

[Daniel Berenyi]

Új meeting kód van, mert a régi lejárt:

https://meet.google.com/nox-sqmf-auz

D.

On Tue, Jan 12, 2021 at 3:03 PM Csaba Hruska <csaba....@gmail.com> wrote:

[Daniel Berenyi]

Sziasztok!

Ma ezek a linkek kerültek be a chat-be.

D.

---------------

Csaba Hruska
Előadás:
video: https://www.youtube.com/watch?v=jyaR8E325ok
slides: https://docs.google.com/presentation/d/1g_-bHgeD7lV4AYybnvjgkWa9GKuP6QFUyd26zpqXssQ/edit?usp=sharing

Gábor Lehel
Pratt parser rustban:
https://gist.github.com/glaebhoerl/ae1534ee1cca7cad965dd0086ab093fd

Gábor Horváth
Könyvajánló:
https://en.wikipedia.org/wiki/To_Mock_a_Mockingbird

C++ IR:
https://github.com/GabrielDosReis/ipr

https://en.cppreference.com/w/cpp/types/nullptr_t

Csaba Hruska
The story of ispc: all the links
https://pharr.org/matt/blog/2018/04/30/ispc-all.html

Balazs Komuves
https://github.com/vmware/differential-datalog
https://github.com/vmware/differential-datalog/blob/master/doc/tutorial/tutorial.md

Csaba Hruska
Data-flow analyses as effects and graded monads
https://youtu.be/7r4H1vWIOVk?t=1228
https://www.repository.cam.ac.uk/handle/1810/305096

Gábor Lehel
https://www.microsoft.com/en-us/research/uploads/prod/2020/11/perceus-tr-v1.pdf

Csaba Hruska
Perceus implementacio:
http://koka-lang.org/
https://github.com/koka-lang/koka


Csaba Hruska
Type theory elaboration implementation
https://www.youtube.com/playlist?list=PL2ZpyLROj5FOt99f_KCxARvd1hDqKns5b

D. B.
https://github.com/AndrasKovacs/elaboration-zoo

Balazs Komuves
https://copilot-language.github.io/

[Daniel Berenyi]

Sziasztok!

 

Ma 4-től meeting:

https://meet.google.com/nox-sqmf-auz

D.

[Daniel Berenyi]

Sziasztok!

Ma az alábbi linkek kerültek be a chat-be.

D.

--------------------------

Whisperity Dypertkova
https://www.lewuathe.com/hello,world-with-mlir.html
Itt van hozzá src: https://github.com/Lewuathe/mlir-hello
https://github.com/Lewuathe/mlir-hello/blob/main/include/Hello/HelloDialect.td
https://github.com/Lewuathe/mlir-hello/blob/main/include/Hello/HelloOps.td
Itt az OPS az érdekes

Csaba Hruska
http://takenobu-hs.github.io/downloads/haskell_ghc_illustrated.pdf
26. oldal
28. oldal is

https://llvm.org/docs/StackMaps.html#llvm-experimental-patchpoint-intrinsic

http://takenobu-hs.github.io/downloads/haskell_ghc_illustrated.pdf
22. oldl

Gábor Lehel
két érdekes link a stack kezeléssel meg az LLVMmel kapcsolatban:

https://kavon.farvard.in/publication/stacks-pldi20

https://kavon.farvard.in/publication/cwc-eptcs/

Csaba Hruska
https://twitter.com/nomeata/status/1351189041845309441
https://luajit.org/performance_x86.html
https://luajit.org/dynasm.html

[Gábor Lehel]

Naszóval, nekem két témám van amiről szívesen beszélnék, meg egy harmadik amiről szívesen hallanék:

1. Korábban is szóba került már a CBPV (Chronic Bee Paralysis Virus Call By Push Value), aminek kicsit nondeszkript neve van és az elérhető anyagok túlnyomó része is elég formális és nehezen felfogható (számomra legalábbis!), úgyhogy sokáig nem nagyon vágtam hogy mi ez, de amióta összeállt bennem egy kép [kb. 50%ban azáltal hogy függetlenül feltaláltam egy-két hasonló feature-t, amiután előbb-utóbb végre beütött a hasonlóság], szerintem érdekes és hasznos dolgok vannak benne, és szívesen megpróbálhatnám felvezetni úgy hogy remélhetőleg a C++osoknak meg Haskelleseknak is hasznos legyen valamennyire. (Inkább csak intuitív szinten, hogy mi ez és mire lehet jó, semmi formális levezetési szabályok vagy ilyesmi.) Hivatalosan ehhez a rendszerhez az volt a motiváció, hogy a call-by-name meg call-by-value szemantikát is ki lehet vele fejezni, de a jelenlegi felfogásom szintjén inkább úgy tekintek rá, mint a call-by-value (strict) alapok kiegészítése érdekes új képességekkel a computation/codata típusok oldalán. (Ill. állítólag compiler IRhoz is jó alapul tud szolgálni, úgyhogy ebből a szempontból is érdekes lehet talán, de ezen még kevésbé gondolkodtam.)
   
2. Nemrég találtam egy módját a subtyping meg a unificationös type inference összeegyeztetésének ami kevesebbet tud, mint az algebraic subtyping / mlsub, cserébe egyszerűbb; vagy másik oldalról valamivel többet tud / jobban működik mint a 'naiv' unification és nem sokkal bonyolultabb. (Még nem teljesen 100%, hogy ez valóban működik, de néhány kör oda-vissza után már ott tartok, hogy úgy mondjuk 90%; ha befejezem a kis prototípust amit elkezdtem akkor remélhetőleg pozitív irányba változik majd ez a szám.)  És szívesen mésélnék arról hogy egyrészt ezek a szavak mit jelentenek :), egyáltalán mi volt az eredeti probléma amire ez született megoldásként, meg esetleg az 'algebraic subtyping'ot is felvázolni és ahhoz viszonyítani, ill. András említette múlt héten, hogy ő is implementált egy coercive subtyping-ot, aminél a metaváltozók kezelésénél vannak a komplikációk, és szívesen összevetném azzal is, ha neki is vannak erre jó ötletei (mint általában szoktak lenni).
3. Szintén András említette múlt héten, hogy a fordítók optimalizációs pipelineját (vagy azoknak egy jelentős részét) szerinte NbE-s alapon (normalization-by-evaluation) lenne jobb ötlet megvalósítani, és erről is nagyon szívesen hallanék többet: hogy milyen optimalizációk férnek ebbe bele, mik nem, meg úgy általában hogy hogyan működne és mik a tradeoffok. Ill. tágabban a "hogyan lehet minél kevesebb effortból/kódból/komplexitásból minél több optimalizációt megvalósítani, amik minél gyorsabban is működnek" téma engem is sokat foglalkoztat.

(ha az a közös akarat, hogy egyik vagy másikról beszéljek majd, akkor azt jó lenne még előtte megtudni, hogy tudjak valamennyit készülni meg esetleg vmi linkeket vadászni)

--

Azért kapta ezt az üzenetet, mert feliratkozott a Google Csoportok „compiler-seminar-budapest” csoportjára.
Az erről a csoportról és az ahhoz kapcsolódó e-mailekről való leiratkozáshoz küldjön egy e-amailt a(z) compiler-seminar-b...@googlegroups.com címre.

Ha szeretné megtekinteni ezt a beszélgetést az interneten, látogasson el ide: https://groups.google.com/d/msgid/compiler-seminar-budapest/CABmfui1N9Dh0RdipJ_AG_15YY1kxdh_d9FjVFt%3DXyM4GfQ1g3Q%40mail.gmail.com.

[Whisperity]

A 2)-es lehet engem is érint, mert lehet hasonlón (igaz, potenciálisan
kevesebb típuselmélettel és több gyakorlati C++-szal) dolgokkal
foglalkozok. Vagy kéne foglalkoznom, ha végre ki lenne takarítva a
problémát megalapozó checker, és fel lenne küldve reviewra...

> Ha szeretné megtekinteni ezt a beszélgetést az interneten, látogasson el ide: https://groups.google.com/d/msgid/compiler-seminar-budapest/CAFCmug-n7DY_p-WoqT2KaSC2LGwS1NnY2Wz%3D23sNt5%2Bk7rFhVw%40mail.gmail.com.

[András Kovács]

Lehel Gábor: 1) 2) érdekelne. Az én subtyping megvalósításaim nagyon egyszerűek, mert nem használok semmi bound constraint-et vagy "valódi" subtype inference-t, csak közvetlen bidirectional subtype eldöntést. Ha a subtyping-ot metaváltozók elakasztják, akkor postpone-olni lehet. Tapasztalatom szerint ez teljesen jól használható gyakorlatban. A 3)-ról az elképzeléseim elég homályosak, ez egyelőre csak kutatás felvetés szintjén van.

Azért kapta ezt az üzenetet, mert feliratkozott a Google Csoportok szolgáltatásbeli compiler-seminar-budapest csoportra.

Az erről a csoportról és az ahhoz kapcsolódó e-mailekről való leiratkozáshoz küldjön egy e-amailt a(z) compiler-seminar-b...@googlegroups.com címre.

Ha szeretné megtekinteni ezt a beszélgetést az interneten, látogasson el ide: https://groups.google.com/d/msgid/compiler-seminar-budapest/CAL3FZmXy1nTxma2a%3DvVUqXScajAPUnGJHhuPdPFw-d8bNO%3DheQ%40mail.gmail.com.

[Gábor Lehel]

Ja, hogy postponing a trükk, érdekes... és hogyhogy ez nem "sül el visszafelé" mint a polimorfikus instantiációnál (ha jól emlékszem arra), hogy a posztponált meták következtében még több posztponált meta keletkezik, és nem jut előre a dolog?

[András Kovács]

Kicsit jobban belegondolva, szerintem a konkrét subtyping relációtól erősen függ, hogy mennyire erős az egyszerű bound-mentes megoldás. A 2LTT esetén a reláció elég egyszerűen generálódik (U i < U (i + 1)) és (A ~ ^A) által. A sum/product altípusozásban minden bizonnyal több a szabadságfok ehhez képest.

[Daniel Berenyi]

Sziasztok!

Ezek mind nagyon jól hangzanak, és szívesen meghallgatom őket.

Egyetlen dolgot szeretnék kérni, ami szerintem hosszú távon hasznos lenne: mivel az ember agyában egyszerre véges mennyiségű puzzle darab fér el, és hiába értünk meg valamit, pár hónap után simán teljesen el tudjuk felejteni, még akár azt is, hogy egyáltalán létezik, ezért találjunk már ki valami rendszert, amiben össze lehet ezeket legalább nagyjából írogatni és számontartani, pl.:

- mik a kérdések, problémák, amik felmerülnek a compiler/nyelv fejlesztés során, pláne mik a *jó* kérdések, amikre fontos ismerni v keresni a válaszokat

- mi az, amire jól bejáratott, kitalált meglevő módszerek vannak, mi azoknak az alkalmazási köre, mit oldanak meg, mint nem

- mi az, ami teljesen nyitott kérdés, ebből mi az, ahol van tippünk h mit érdemes csinálni, és mi az ahol absz semmit nem tudunk, mi az ahol csak menni kell fát vágni, és halad az ember.

- hol vannak fontos trade-offok különböző szempontok mentén, amiket célszerű ismerni

Bocs, hogy ilyen absztrakt, de szerintem értitek... Pár ilyen dolgot elkezdtünk feldobálni a FeoFu repoba, de folytatni kéne, és rendszerezni. Én szívesen csinálom a mechanikus részét, de találjunk már ki egy rendszert.

Azon parázok, hogy mire oda jutok h ezeket használjam, és implementáljam, addigra 0-ról kell kezdenem minden információ morzsa megkeresgélését:)

köszi,

D.

[Kéri Kálmán]

Sziasztok!

A CBPV meg a type inference engem is érdekel. Szervezett oktatásban nem tanultam ezekről, így sokat segítene, ha az elején kontextusba helyeznénk a szóban forgó elméletet/módszert. Egyszer a Redditen valaki közzétett egy pure type system implementációt, én pedig megkérdeztem, hogy lesz a következtetési szabályokból algoritmus. Megtudtam, hogy a legegyszerűbb esetben minden termre pontosan egy szabály illik (syntax directed), máskor pedig szükség van kreativitásra, amit pl. a Hindley-Milner esetén unifiction-nek hívnak. Az ilyen információk nagyon hasznosak számomra.

Sajnos januártól az irodai munkám rendszeresen ütközik a kedd délutánokkal. Kérlek, ha lehet szóljatok előre, amikor az említett témákról szó lesz, hogy szabaddá tudjam tenni magam.

Üdv:

K.

[Gábor Lehel]

András: Hm, az előbbi ezek közül belefér az ún. structural subtypingba (amikor a típusok csak a paramétereiken keresztül tudnak subtype relációban lenni; ez elvileg egy ismert egyszerűsítés, amit könnyebb kezelni), a második az szigorúan véve nem, de lehet hogy "elég közel van hozzá" vmilyen értelemben... nem tudom van-e vajon köze a dologhoz.

Dani: Hmm, hát nem tudom... lehet hogy nekem mégis túl absztrakt, és ezért nem értem eléggé. :) Ha az ember az adott témában ezeket rendszerezni akarná olyan módon hogy értelme és haszna is legyen, az szerintem egy elég nagy meló (és valszeg ahány ember, annyiféleképpen csinálná). De gondolom te csak valami olyasmit képzelsz most el, hogy inkrementálisan a heti meetingek témáiból építenénk fel ezeket valahogyan. Erről viszont nem nagyon van előttem kép, hogy mégis mit és hogyan működne. Neked van? Mert akkor azt tudnám javasolni, hogy esetleg vázold azt fel (a gyakorlati konkrétumokhoz közelebbi szinten:), és akkor abból talán el lehet majd valamerre indulni, ha egy kicsit már kézzelfoghatóbb a dolog... ez a sok ember találjon ki 'közösen' majd egy általánosan megfogalmazott valamit megközelítés a tapasztalat alapján nem biztos h eredményrevezető :)

Kálmán: Ezesetben megnyugodhatsz, mert én is hasonlóképpen vagyok ezekkel :)

Mind: Ha nincs valakinek erős ellenpreferenciája, akkor szerintem megpróbálom elmondani majd a subtypingosat, ha a prototípusozás jól megy addig, mert akkor kíváncsi lennék majd arra is, hogy másvalaki lát-e esetleg az elképzelésben valami bibit vagy bökkenőt...

[Daniel Berenyi]

Még a témákhoz:

Én akartam mesélni a rekurziós sémákról és arról, hogy hogyan használjuk őket C++-ban, mert anno még az elején ígértem h mutatok konkrét kódokat is. Ha van erre érdeklődés, ez főleg a C++-os embereknek lehet érdekes.

Ismeretek szervezése:

Elsőnek az is jó, ha minden témakörhöz, algoritmushoz, v talk-hoz tudunk valami labeleket rendelni, h az épp mikhez kapcsolódik, milyen problémára ad választ. Az a baj, hogy nem látom át, hogy milyen tengelyek vannak egyáltalán, ezért vagy segítetek, vagy elsőre csak építek vmi gráfot belőlük:) Aztán ha már elég sok node van benne, akkor talán látszik vmi szisztéma.

Pl.: pár dolgo el lehet helyezni: type ckecker / inference algoritmusok, IR reprezentációk, analízis módszerek, optimalizációs passok, nyelv design kérdések, compiler belső reprezentáció (AST) kérdések. De ez első kissé ad-hocnak tűnik, és nem tudom mi mennyire fér bele..

Javaslatokat várok:)

D.

[Gábor Horváth]

Rek.  sémák érdekelnek, de a jövő héten nem leszek, szóval későbbre tartogassuk :D

--
Azért kapta ezt az üzenetet, mert feliratkozott a Google Csoportok „compiler-seminar-budapest” csoportjára.
Az erről a csoportról és az ahhoz kapcsolódó e-mailekről való leiratkozáshoz küldjön egy e-amailt a(z) compiler-seminar-b...@googlegroups.com címre.

Ha szeretné megtekinteni ezt a beszélgetést az interneten, látogasson el ide: https://groups.google.com/d/msgid/compiler-seminar-budapest/CABmfui3m9ZA0LOhi2HqpRoOKC0PT6SM-8Z%2BFSyQ_p3fC56np1w%40mail.gmail.com.