Perl 6 - the future is here, just unevenly distributed

IRC log for #divine, 2017-05-12

| 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/
18:22 yaqwsx Vím, že už se to někdy řešilo, ale nemůžu si teď vzpomenout na řešení - divine cc mi nechce najít standardní C++ hlavičky pro cpp soubor v functions/sys/start.cpp: https://pastebin.com/f5BPGVEY
18:22 yaqwsx Nevzpomínáte si, čím to bylo?
18:23 xstill yaqwsx: runtime-cc musí explicitně dostat include cesty na C++ ty při kompilaci libc nejsou nastavené
18:24 xstill yaqwsx: dal bych tam <stdint.h> pokud nepotřebuješ nic dalšího (a neměl bys potřebovat nic z c++ co není v halivčkách, jinak vytvoříš cyklus mezi libc a libc++ (doufám, že tam ještě není))
18:26 xstill (teda runtime-cc musí explicitně dostat všechny include cesty, ne jen na C++)
18:31 yaqwsx Ok, ale potom nedává smysl přesunutí _start do libc, jelikož využívá funkce z STL...
18:33 yaqwsx mornfall: Nebo jak jsi to myslel s přestěhováním _start?
18:36 xstill yaqwsx: jak se na to dívám, tak jediná věc co v dios/core/main.cpp vidím z STL je sort
18:37 xstill to bych si tipnul, že bude header only
18:38 xstill a tím pádem by mělo stačit přidat cestu k libc++ do cmake, není to sice bůh ví jak čistý, ale alespoň to nevytvoří linkovací cyklickou závislost, která by byla skutečně problém
18:40 xstill nebo bys mohl použít qsort, ono to nebude nějak hrozně pomalý (nebo zjistit, jestli to pole náhodou není setřízený tak jak ho kompilátor vygeneruje, nejsem si jistý, že jsem to zkoumal když jsem to tam dával)
18:41 xstill hm, ještě je tam find a nějaký pairy, ale to všechno bude taky v hlavičce, hlavně jsou to všechno šablony, tak tomu vlastně ani nic dalšího nezbývá asi
18:41 xstill otázka je nakolik nám vadí c++ include v libc
18:41 xstill mornfall: ^^
18:41 xstill (ale zas už máme pthready v c++, tak by to nemuselo moc vadit)
18:42 yaqwsx Popravdě, moc se mi to stěhování _start do libc z tohoto důvodu nelíbí
18:43 xstill ještě z toho můžeš udělat samostatnou jednotku tak jak je crt0.o/crt1.o na linuxu
18:43 xstill (a linkovat ji před libc)
18:44 xstill to by možná dávalo větší smysl
18:46 yaqwsx xstill: Tj, ale není to zbytečná komplikace života?
18:47 xstill no pokud budeme chtít oddělit někdy dios od programu tak to bude potřeba někam přesunout
18:49 xstill a v podstatě je to otázka toho napsat pravidlo do CMake a nějaký řádek kódu do linkEssentials v cc (a možná upravit mapování aby se .o mapovalo tamtéž co .a pokud se to ještě neděje)
18:49 xstill (mapování do VFS v CC)
18:49 yaqwsx xstill: Ok, to dává smysl.
19:03 xstill btw. monitory teď běží v kernel módu, že?
19:04 yaqwsx xstill: Jj
19:08 xstill jo, tak to bude taky potřeba rozmyslet co s tím až se budou řešit globální proměnný v kernelu
20:27 mornfall yaqwsx: _start určitě nemůže být v dios-u, ten se časem nebude s programem vůbec linkovat (aspoň ne povinně)
20:31 mornfall globální proměnný v kernelu se budou muset řešit docela hned, protože blurry už má polofunkční fork
20:33 mornfall (a 'normální' monitory asi budou per process, to jak řešit monitorování víceprocesových věcí nějak globálně se vyřeší třeba časem)
20:34 yaqwsx mornfall: Ok, tak ze _startu udělám crt
20:34 yaqwsx mornfall: To se týká v podstatě jenom simfailu, ne?
20:34 mornfall nevim, je tam teď docela bordel
20:35 mornfall určitě jsou tam nějaký __cxa_globals věci a něco tam ještě bylo statickýho tuším
20:35 mornfall jak moc je smysluplný mít crt nevim, zatím je to spíš práce navíc?
20:36 mornfall navíc crt nesmí linkovat ani libc, ne to ještě libc++
20:36 mornfall (takže tím že se to vytáhne do crt se problém závislostí zas tak moc nevyřeší)
20:39 yaqwsx mornfall: Ale zároveň mi připadá hloupost do toho tahat C++
20:40 mornfall hlavně crt1 není analogie toho co je naše _start
20:40 yaqwsx mornfall: Tak nemůžeme mít vlastní "start"?
20:40 mornfall no v crt1 je _start kterej má něco jako 20 instrukcí a v podstatě jen zavolá __libc_start_main kterej už je v libc
20:42 mornfall yaqwsx: nicméně v libc už nějaký C++ věci jsou, takže nevim jak moc velkej rozdíl tady ten _start dělá
20:43 mornfall je to teda C++ bez knihoven
20:44 yaqwsx _start právě používá funkce, které využívají C++ knihovnu (sorty, pair, apod)
20:45 mornfall je ke zvážení jestli to prostě nenaprogramovat bez té knihovny
20:45 yaqwsx Neříkám, že je problém se toho zbavit
20:45 mornfall protože to je věc která by nás stejně mohla pokousat
20:45 yaqwsx Otázka byla, jestli se o to pokoušet nebo to řešit jinak.
20:45 mornfall někde v libc++ bude nějakej mutex kterýmu se ještě nezavolal konstruktor a celý se to sesype jak domeček z karet
20:46 yaqwsx Ok, takže to za to stojí. Udělám to.
20:47 mornfall (to getSysOpt k tomu zbytku nepatří, ne?)
20:47 yaqwsx mornfall: Doplnil jsem u mě na Arke 2-3 patche.
20:51 mornfall fajn, na patche už teď asi nemám schopnost se soustředit, ale podívám se co nejdřív (to stejný xheno a xstill)
20:52 yaqwsx mornfall: Ok, já se pokusím ten _start podívat o víkendu a pak se vrhnu na globální věci v kernelu
20:58 yaqwsx _start by tedy neměl ani záviset na __dios_fault, co?
21:01 mornfall yaqwsx: jinak se mi zdá že dios už je v docela dobrým stavu, tak je možná pomalu čas rozhlížet se co dál ... jedna věc která by stála za zvážení je integrace sim-u s abstrakcema/symbolizací (a možná přechodný projekt zlepšit integraci dios/sim)
21:03 mornfall yaqwsx: __dios_fault je v libc ne?
21:03 mornfall runtime/libc/functions/sys/fault.c?
21:04 yaqwsx mornfall: Pravda. Na to jsem zapomněl.
21:04 yaqwsx mornfall: Jj, souhlasím. Za mě chybí ještě udělat pořádek v includech (mám rozpracováno) a synchronní scheduler.
21:06 yaqwsx mornfall: Ok, jedna věc ohledně závislostí mi není jasná (možná je to jen tím, že je večer). DiOS se nemusí linkovat k programu, proto _start nemůže být součástí DiOSu. Ale _start může záviset na libc s příchutí DiOSu?
21:07 mornfall yaqwsx: tady jde čistě o to, že teď se spoléhá na to, že dios je knihovna a funkce v dios-u a funkce v libc se můžou vzájemně nahodile volat
21:07 mornfall yaqwsx: tzn. _start z dios-u může zavolat main z programu, třeba
21:07 mornfall yaqwsx: ale pokud to bude žít v různých binárkách tak tohle fungovat nebude
21:08 mornfall co zůstane je že dios může vysyntetizovat rámec v programu (ale musí to být na fci která je v programu, nikoliv v dios-u) a syscally
21:11 mornfall (možná je teď matoucí že když říkám dios tak myslím jádro)
21:13 yaqwsx mornfall: Ok, to už začíná dávat trochu smysl.
21:13 yaqwsx mornfall: S tím simem souhlasím + si myslím, že Jiřík by rád viděl nějaký postup na Simulinku.
21:14 mornfall nojo simulink
21:14 yaqwsx + ještě jsem si vymyslel jednu věc, kterou bych chtěl alespoň lehce prozkoumat - build závislosti runtimu a ideálně nebuildit celý runtime při změně jedné hlavičky (ale jen, to co je třeba)
21:15 mornfall jo to bude bolet asi hodně (protože cmake a spol jsou tomhle trochu retardovaný)
21:15 mornfall ale je pravda že by to všemu dost pomohlo
21:15 yaqwsx Proto říkám "alespoň lehce prozkoumat" ;)
21:16 yaqwsx Momentálně mě, který pořád překládá runtime, točí libm :D
21:17 mornfall (pokud jde o integraci dios/sim, ještě bych asi ocenil nějakej trik jak se zbavit těch hrozných typů co nám vyrobila komponentizace... sim by se asi mohl naučit nějaký překladový pravidla na typy a případně by pak dios mohl nějak naznačit co se má zjednodušit)
21:18 mornfall (to je asi taky spíš k zamyšlení, ale tohle nás teď občas bolí všechny)
21:18 yaqwsx Přemýšlel jsem, jestli by DiOS v sobě nemohl mít nějakou překladovou tabulku, kterou by sim četl.
21:19 yaqwsx Ale ještě jsem to nedomyslel.
22:00 yaqwsx ...škoda: "Note that the IMPLICIT_DEPENDS option is currently supported only for Makefile generators and will be ignored by other generators."

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