Perl 6 - the future is here, just unevenly distributed

IRC log for #divine, 2016-11-03

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

All times shown according to UTC.

Time Nick Message
01:43 divine-buildbot joined #divine
01:57 divine-buildbot joined #divine
02:48 ilbot3 joined #divine
02:48 Topic for #divine is now DIVINE | http://divine.fi.muni.cz | http://irclog.perlgeek.de/divine/
03:12 divine-buildbot joined #divine
03:22 divine-buildbot joined #divine
05:01 divine-buildbot joined #divine
07:12 xstill mornfall: ty jsi říkal, že první ctrl+c má zabít jen ten jeden test ve functional?
07:53 xstill mornfall: to je hrozně veselý, __vm_obj_resize mi smazal obsah objektu
07:55 xstill zdá se, že to má co do činění s pointrem zarovnaným na 4, ale zatím se mi to nepodařilo zreprodukovat mimo pthready
07:55 xstill mornfall: http://pastebin.dqd.cz/Wca5/
07:56 xstill resize je na this
07:57 xstill jo __vm_obj_resize se rozseká pokud dostane pointr do objektu ale ne na offset 0
08:17 xstill (jakože rozbije ten objekt a nic neřekne)
09:11 mornfall nojo, asi mě nikdy nenapadlo resizovat objekt pointrem doprostřed (ale jo, mělo se to kontrolovat... stejně tak free, asi)
09:13 mornfall vida, free to dokonce kontroluje
09:33 xstill jinak jsem teda přidal __dios_get_errno funkci do dios.h která z TLS vytáhne to errno, akorát nevím jestli naše testy někde používají errno
09:34 xstill repsektive teda testy ho nepoužívají přímo, mohlo by ho používat jedině n2co co je v testech
11:07 xstill mornfall: v ~/DIVINE/divine4pthread jsou patche, ten poslední (test/vm) obsahuje test kterej momenátlně padá kvůli tomu __vm_obj_resize
11:32 mornfall xstill: errno se určitě nepoužívá jinde než v fs testech
11:32 mornfall xstill: Katka na to ale testy má
11:33 xstill tak možná dává smysl počkat až to Katka pošle
11:38 mornfall hm, Vilík a bugreporty
11:39 xstill jeho neschopnost dodávat relevantní informace mě dost překvapuje no…
11:42 mornfall Jiřík by měl do těch profilů absolventa dopsat „umí vyplnit bugreport“
11:43 xstill to by asi měl :-D, studenti to dost nedávaj, ale u Vilíka mě to teda překvapilo
11:43 mornfall na tohle jsem si stěžoval na CAVu v Peterburgu, a někteří nejmenovaní vůbec nechápali proč by člověk měl umět nahlásit chybu
11:44 mornfall prej jestli kdyby náhodou dostali práci v QA
11:49 xstill to je asi jako kdyby se někdo ptal proč by učitel měl být schopný říct studentovi co má blbě v písemce
12:44 spito :D
12:49 xstill a ještě k tomu neumí odpovídat na mailing list…
12:50 xstill a segví nám to zase někde v initu (dost podobně jako se to stávalo Heňovi, když měl rozdrbaný modul)
12:59 mornfall nám...
12:59 mornfall nejlepší by bylo vyrobit na to test :)
13:01 xstill jo, nejdrív musím zjisti proč to dělá a co to dělá
13:03 mornfall já asi ani nevim že Heňovi něco segvilo (mimo lart teda)
13:12 xstill nojo segvilo, jsem myslel, že ti o tom psal
13:15 xstill hm, LLVM se mi rozhodlo přebuildit… takže někdy později
13:22 xstill hm, pokud ve valgrindu vidím několikrát za sebou "by stejná adresa" tak to asi znamená, že se to všechno zainlinovalo, že?
13:23 mornfall v stacktrace?
13:23 mornfall to těžko
13:23 xstill tak proč by tam jinak byla stejná adresa?
13:23 xstill (jj stacktrace)
13:23 mornfall rekurze?
13:24 xstill různé funkce
13:24 xstill a zrovna takové, kde by dávalo smysl aby se inlinovali
13:24 mornfall když se něco inlinuje, tak tam není call
13:24 mornfall když tam není call, nemá to rámec
13:25 mornfall a stejná adresa nemůže patřit víc než jedné funkci
13:26 xstill on to může tahat z debug info možná nějak, ne? Zrovna dneska jsem uvažoval o tom, že jestli se to dá z LLVM metadat dostat tak bychom to mohli v divine dělat (to = rekonstruovat stacktrace zainlinovaných funkcí)
13:26 mornfall (za normálních okolností, aspoň)
13:26 xstill akorát v LLVM metadatech se dá vyznat, DWARF si fakt ručně číst nebudu abych zjistil jestli to tam je
13:26 mornfall no to právě moc nejde, nebo o tom aspoň nevim... víš, že nějaká instrukce přišla inlinováním, ale už nevíš jak hluboko
13:27 mornfall syntetickej řádek vyrobit asi můžeš, ale pochybuju že víc než jeden
13:28 xstill nevím jestli to půjde, ale každpodálně jsem to odložil na 3.9
13:28 xstill ale tady by ten asm tomu odpovídal, asi začínám tušit co se děje
13:33 xstill je možný, že destruktor modulu nějak likviduje něco co patří kontextu a říká mu o tom, ale když destruktor modulu neběží tak to zdestruuje destruktor kontextu? Počítám, že jo…
13:33 mornfall s tím debuginfo je to tak, že tam je informace o řádcích kudy se něco inlinovalo
13:34 xstill protože jestli jo, tak je to skoro určitě tím, že v BitCode je nejdřív modul a pak kontext, takže se destruuje nejdřív kontext a destruktur modulu to pak shodí, a děje se to pokud v initu vyletí výjimka
13:34 xstill mám ověřený, že v tom běhu vyletí výjimka a že se to destruuje v tomto pořadí
13:34 mornfall ale samozřejmě to má tu vlastnost, že z instrukce na instrukci se ti může celej ten syntetickej zásobník přeskládat
13:34 xstill ale buildí se mi LLVM
13:35 xstill jj. to je jasný s tím přeskládávání, navíc je jasný, že to nemusí vždycky dávat smysl (protože jde třeba optimalizovat přes hranice toho co byly funkce)
13:36 mornfall jediný co s tím můžem udělat je přidat jako atribut rámce ten syntetickej kus 'zásobníku'
13:39 mornfall no, možný to je (s tím kontextem), ale je to divný, protože ten kontext přijde jako sdílenej ukazatel zvenčí kde snad ještě existuje když se likviduje ten modul
13:40 mornfall no a hlavně ~BitCode ten modul zlikviduje ještě než se má šanci likvidovat kontext
13:40 xstill nepříjde, jde to tím ctorem kterej nebere kontext (když se načítá bc a ne cpp)
13:41 mornfall no je to jedno, protože ~BitCode se volat musí tak jako tak, a ten obsahuje explicitní _module.reset()
13:41 xstill když se vyhodí výjimka v konstruktoru tak se desttruktor nevolá
13:41 xstill asi
13:41 mornfall pokud se nevolá destruktor tak se ty ukazatele leakujou
13:42 xstill počkáme až se mi překompiluje llvm…
13:51 mornfall no, zjistil jsem, že a) destruktor se nevolá b) volají se destruktory členů c) nikde jsem nenašel v jakém pořadí
13:52 mornfall (tzn. nevolá se ani 'implicitní' destruktor, v konstruktoru se data member chová jako by to byla plusminus lokální proměnná)
13:53 mornfall ale asi je zaručený, že se to ničí v opačným pořadí než se to konstruuje
13:54 mornfall takže by to fakt mohlo být ono... ale je to solidní past (ono by to fungovalo, kdyby llvm používalo shared pointery na kontext)
13:55 xstill jj, taky to čtu, a pořadí destruování by mělo být vždy odzadu objektu (alepoň to tak učí Nikola a chová se to tak když to zkouším)
13:57 mornfall no standard nějak zaručuje tu reverznost proti konstrukci v rámci jedné storage class
14:01 xstill jj. 12.6.2.13 zaručuje pořadí konstrukce a říká, že destrukce je v opačném pořadí
19:38 xstill mornfall: jo pomohlo to, patch v /home/xstill/DIVINE/divine4
20:00 xstill hm, když už elsevier chce spamovat tak by si alespoň nemusel vymýšlet tituly
20:38 xstill mornfall: bylo by fajn kdybys to pullnul než se bude synchronizovat current

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