Perl 6 - the future is here, just unevenly distributed

IRC log for #divine, 2017-05-05

| Channels | #divine index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:49 ilbot3 joined #divine
01:49 Topic for #divine is now DIVINE | http://divine.fi.muni.cz | http://irclog.perlgeek.de/divine/
07:41 xstill_ hm, disk quota zase
11:31 xstill_ mornfall: mám novou verzi těch libc++abi patchů, ale ty with fallback věci jsem udělal znova stejně, protože všude kde se teď používají tak to bylo přepsané pod DIVINE na __vm_obj_make
12:37 blurry mornfall: manual patchie
13:01 divine-next 3 new patches validated [blurry xstill]
13:03 xstill_ mornfall: ten lart na konci zatím netahej, ještě není dobře
13:29 mornfall xstill_: není mi to moc jasný
13:30 xstill_ co?
13:30 mornfall xstill_: když vezmu libc++, libc++abi (zdá se že jsou cyklicky závislý) ale bez těch změn ve fallback tak to normálně prochází testy
13:31 xstill_ prochází, akorát to vždycky zkusí alokovat jak z mallocu tak z té fallback haldy
13:31 xstill_ (a ta může dojít, teoreticky)
13:31 mornfall no to byl smysl toho jak to bylo
13:31 xstill_ (to je jedna věc která se tím schová)
13:31 mornfall (je pravda že to asi bylo vyřazený tím že tam byl #ifdef, ale v podstatě by neměl být)
13:31 xstill_ ne, tak jak to tam bylo tak to volalo obj make
13:33 xstill_ a to rozvětvení není vůbec zadarmo, protože ty dvě větve ne neseběhnou dokud ten pointer existuje
13:33 mornfall a __cxa_allocate_exception ten fallback malloc nevolalo?
13:34 mornfall to že v __cxa_get_globals byl std::calloc by se dalo považovat za bug v té předchozí libc++
13:34 mornfall kterej někdo opravil tím že vyrobil ty _with_fallback verze a použil to tam
13:34 xstill_ ano, cxa_get_globals opravili
13:35 xstill_ ten hunk v resolve patchi je trochu zavádějící, to je ale tím jak to darcs vyresolvoval
13:35 xstill_ cxa_allocate_exception volalo fallback malloc
13:36 xstill_ nikde jidne než na těhlech dvou místech se to snad nevolá
13:36 mornfall takžé v podstatě říkáš, že tím že se ten fallback malloc teď použije i když nevyletí výjimka je drahý a proto bychom ho měli zrušit?
13:37 mornfall takže*
13:39 xstill_ no říkám spíš to, že ve staré libc++ to bylo na obou místech kde je teď fallback malloc vyifdefované tak, že se používal obj make. a ano, pokud by se v __cxa_get_globals nechal fallback malloc s haldou tak to bude drahý asi, můžu ti to klidně změřit
13:40 mornfall takže tomu furt nerozumím... před chvílí jsi řekl že v cxa_allocate_exception se používal fallback malloc a teď říkáš že nepoužíval
13:42 xstill_ ok, v upstreamu se v cxa_allocate_exception používal fallback malloc, v DIVINE to jeden z nás přepsal na obj make myslím, v get_globals byl v upsteamu calloc, v divine obj make (protože to jinak dost nefungovalo) a v libc++4 to opravili na fallback malloc
13:43 mornfall no já ten přepis v cxa_allocate_exception nemůžu najít
13:44 mornfall (jakože kdysi -- v době kdy existovalo __divine_malloc -- to tak bylo)
13:47 xstill_ aha tak ne, jsem si to spletl s libcxxabi: Get the fallback heap from __vm_obj_make in __divine__.
13:47 xstill_ otázka je jestli teda chceme tu fallback haldu zachovat, protože to řešení s tím, že se zachová ale přehodí se na haldu se mi taky moc nelíbí
13:48 xstill_ jediný co to teda má za výhodu je, že se testuje, že se to tam vleze
13:48 mornfall no ta změna je dost ekvivalentní
13:48 mornfall ne, testuje se navíc že ten fallback malloc funguje jak má
13:48 mornfall přesunul bych tu alokaci do konstruktoru teda
13:48 xstill_ ekvivalentní čemu?
13:48 mornfall aby to nevětvilo
13:49 xstill_ do jakého konstruktoru?
13:49 mornfall globální pole vs __vm_obj_make jsou si ekvivalentní
13:49 mornfall globálního konstruktoru
13:49 xstill_ no to je trochu ošemetné, protože potřebuješ aby běžel před všemi C++ konstruktory
13:50 xstill_ což prakticky vzato jde, protože clang jim zdá se dává konstantní vysokoy prioritu, ale je to docela hack teda
13:50 mornfall může si to klidně zařídit _start (kterej by teda yaqwsx mohl příležitostně přesunout do libc, nebo do nějakýho crt0)
13:51 mornfall yaqwsx: (až budeš mít čas, samozřej
13:51 mornfall yaqwsx: mě... no hurry)
13:52 xstill_ to mi příjde horší zásah než nekontrolovat fallback malloc
13:52 mornfall zásah do čeho?
13:53 xstill_ do libc++abi, protože hackuješ nějaké specilní konstruktory které musí DiOS vědět, že má volat
13:54 xstill_ jako v pthread to děláme proto, že už C konstruktory můžou potřebovat použít pthread, tady by to bylo jen proto, že nemáme dostatečně efektivní reprezentaci globálních proměnných
13:55 xstill_ příjde ti tak hrozné nekontrolovat fallback haldu?
13:57 xstill_ druhá věc teda je, že to buď pak musíme v cxa_get_globals ohackovat stejně na na obj_make, nebo si nejspíš zdvojnásobíme stavový prostor všech C++ programů co bez nofail:malloc
13:58 mornfall jo, vyrábět to v konstruktoru nemá smysl, vyjde to nastejno jak to je teď jen je to složitější
14:03 xstill_ yaqwsx, mornfall: add _start, pokud bys ho vyhazoval z dios (do něčeho jako crt0) tak bude potřeba zajistit aby to cc přilinkovalo by default, teď se linkuje všechno z diosu, ale to půjde celkem snadno; může to vlastně i být v libc a přitáhne se to stejně jako malloc deklarací linkEssentials nebo co to je
14:06 blurry_ joined #divine
14:06 blurry_ mornfall: dakujem!
14:18 yaqwsx mornfall: Ok, píšu na ToDo list. Jen toho teď moc přes víkend nestihnu.
14:19 xstill_ yaqwsx: jak ti dopadla Norština? (jestli už jsi ji psal)
14:19 yaqwsx xstill_: To uvidím. Nejbombastičtější na tom bylo to, že jsem ji psal sám - kvůli ETAPSu mi ařídili speciální termín jen pro mě.
14:21 xstill_ :-)
14:21 yaqwsx Takže jsem seděl ve velké místnosti a naproti mě postarší dáma, která pletla a četla si módní časopis. Situace k pokukání :D
14:22 xstill_ aha až tak jo? to je dobrý teda
14:51 xstill_ jinak ty dva patche na konci by už taky měly fungovat
15:21 divine-next 12 new patches validated [xstill]
18:13 xstill dík, a ten lart patch je pořád blbě, achjo
18:33 xstill hm to, že se lart nepočítá do version hashe nepotěší, opravím (a rovnou přidám i tools, bricks a external ať je tam všechno když už podle toho děláme benchamarky)
18:53 mornfall jo až na to že nic z toho tam (přímo) nepatří
18:54 xstill no, minimálně lart tam podle mě patří, nechceme přece změnit preprocesing aniž by se to projevilo na instanci
18:55 xstill a změna v bricks taky může změnit chování celého DIVINE, byť tam může být spousta věcí který ho nezmění
18:56 mornfall a taky v glibc
18:56 mornfall nebo v kernelu
18:56 xstill ano, nicméně platforma je jedna věc a náš kód je druhá
18:56 mornfall tak llvm
18:57 mornfall prostě není zvykem uvádět ve verzi něčeho taky verze všech závislostí
18:57 mornfall klidně ať je to umí vypsat a spočítat nějakej všeobjímající hash
18:57 mornfall ale určitě to není verze libdivine
18:58 xstill LLVM se téměř nemění, ale chápu, nicméně lart je dost specielní v tomhle ohledu
18:58 xstill přeci jen preprocesing v lartu přímo ovlivňuje výsledky
18:59 xstill (a zároveň se může lehce změnit bez změny v divine, což u LLVM půjde dost těžko)
19:01 mornfall taky by měl nejspíš liblart obsahovat vlastní hash
19:02 xstill to by mohl, ale pokud to chceme udělat tak budeme muset překopat databázi (je otázka jestli pak instanci neurčovat spíš podle kombinovaného hashe)
19:03 mornfall nebo se může lart zrušit a přesunout ten kód do libdivine (ale to není úplně optimální řešení)
19:05 xstill to je otázka nakolik se lart chce tvářit, že dokáže být užitečný i mimo divine, zatím mi příjde, že dává smysl ho mít i samostatně (byď teda na zdrojácích už nějakou závislost má, minimálně na divm.h)
19:06 mornfall no, lart/divine je dost hroznej hack
19:07 mornfall (a vytváří cyklickou závislost, to snad není ani mezi komponentami libdivine)
19:08 mornfall (něco z toho co tam je asi ve skutečnosti nepatří pod divine/ a ten zbytek by se časem měl buď někam uklidit nebo zničit)
19:09 xstill je no, ale většina těch věcí je DIVINE specific jen ve smyslu, že instrumentují do kódu DiVM hypercally, nebo případně DiOS věci
19:09 xstill jo je v tom poněkdu nepořádek
19:09 mornfall eventually...
19:11 xstill jo no, to bude na větší zamyšlení jak to uklidit
19:11 mornfall (btw. přidat sloupec do db by taky neměl být žádnej problém)
19:12 xstill taky pravda
23:07 divine-buildbot_ Hey! build divine-nightly-release #109 is complete: Success [finished]

| Channels | #divine index | Today | | Search | Google Search | Plain-Text | summary