Perl 6 - the future is here, just unevenly distributed

IRC log for #divine, 2015-05-04

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

All times shown according to UTC.

Time Nick Message
07:18 xstill mornfall: nevíš takhle z hlavy jak zprovoznit klíče pro nix-copy-closure?
10:42 xstill (už jsem to vyřešil)
13:34 CcxCZ joined #divine
14:00 [exa]_ joined #divine
14:10 xstill hm, on ten assert stejně asi nastává jen při splitterech, ale problém je, že se to bude dost špatně řešit jinak,než že se ten slack nechá v rootu
14:10 xstill jako příjde mi dost špatné, aby splitter musel pamatovat na slack (a která část je která)
15:53 mornfall no, je sice hezká ambice aby to tak nebylo, ale aby to mělo smyslu muselo by se kompletně překopat generátory
15:54 mornfall (totiž, stejně tak nemá smysl aby splitter začínal tam kde končí slack ale všechno ostatní v generátoru začínalo na začátku blobu)
16:23 xstill mornfall: no, ne, všechno v generátoru si pamatuje slack, a začíná od toho slacku (celkový slack), problém je, že po splitteru se najednou chce aby začínal o něco dřív ve fairness
16:24 xstill jinak řečno, navrhuju neměnit generátor, ale zajistit, že to co si on myslí, že je slack bude to samé s čím ntree počítá a ntree se nějak pořeší hashovatelnou část slacku
16:24 xstill tj. generátor nebude muset vědět, že slack má 2 části
16:25 xstill (teď je situace, že graph.slack != ntree.slack a to je ten problém)
16:26 mornfall ale graph.slack > ntree.slack snad ne?
16:26 mornfall to znamená že splitter generuje offsety správně, ale ntree je nesprávně interpretuje
16:26 mornfall myslim
16:29 xstill jo graph.slack > ntree.slack, ale otázka je, jak by je měl ntree správně interpretovat (a mimi jiné k tomu stejně pořebuje vědět celkový slack)
16:29 xstill *mimo
16:29 xstill on totiž nemá tušení, že je to posunutý teď
16:32 mornfall no, ideální by bylo kdyby to neinterpretoval nijak
16:32 xstill v podstatě vidím 2 možnosti: a) generátor řekne ntree slack *v okamžiku volání splitteru* a ntree přilepí hashovatelnou část (tj. rozdíl) k 1. bloku; b) ntree bude vědět celkový slack od začátku a nechá ho celý mimo strom (a pořeší zlášť hashování)
16:32 xstill jak neinterpretoval nijak?
16:33 xstill někdo musí tušit, že ty dva slacky se liší
16:34 mornfall ntree by neměl o existenci graph.slack vůbec vědět, asi
16:35 mornfall a FairGraph by měl obsahovat splitHint který to posune
16:35 mornfall z pohledu ntree je FairGraph< Něco > prostě generátor a co si cpe do stavu by neměl řešit
16:36 mornfall taky bychom to mohli všechno nějak přejmenovat, ale nevím jak
16:37 xstill co přejmenovat?
16:37 mornfall graph.slack je 'kde má tahleta úroveň graph-u začátek svých dat uvnitř stavu' a ntree.slack je 'která část stavu se nemá hashovat a může se měnit'
16:38 mornfall když se to vezme kolem a kolem tak to spolu vůbec nesouvisí, ale historicky to většinou bylo to stejný číslo
16:38 xstill hm, jako řešit splitHint v Fair by asi je dobrý nápad, jen se musím podívat nakolik to půjde
16:39 mornfall stačí změnit store.h:649
16:39 mornfall na splitter = &g místo &g.base()
16:40 mornfall (nevím jak moc to robzije typy teda)
16:40 mornfall (a samozřejmě opravit graph::Transform aby to provolal)
16:40 xstill no spíš mi šlo o tu část jak posunout to co llvm vrací…
16:40 xstill ale podívám se na to
16:40 mornfall to by mělo být jednoduchý, když budeš vědět kam to chceš splitnout
16:42 mornfall (pravda, může být nutný zabalit ten Coroutine co přijde a poslat dál novej)
16:45 xstill hm, no problém to bude poměrně velkej, protože teď zrovna store neví co je tam za transformace zdá se (což je divný…)
16:47 xstill musím zkusit zjistit proč to tak je
16:47 mornfall to by doufám mohlo být jedno
16:48 xstill no není, pak nejde říct ntree jak mají vypadat ThreadData
16:51 mornfall zajímavé
16:51 mornfall nevím proč to tak je a jestli na to je důvod
16:51 mornfall asi jen jeden způsob jak to zjistit
16:52 xstill jako já mám patnou představu, že pro to důvod možná byl, zjistím
16:52 xstill jo no on totiž PORGraph má jako parametr store
16:53 xstill takže je tak takový malý cyklus :-/
16:54 xstill ale možná by to šlo nějak obejít
18:23 xstill hm, já myslím, že ten POR nemusí být typem závislý na store
18:31 xstill ale teda za cenu toho, že ty funkce budou šablonovaný, což trochu naruší typovou kontrolu :-/
18:31 mornfall hm, je to marný
18:34 mornfall hloupý je že por taky potřebuje paměť ve stavu
18:34 xstill proč je to hloupý?
18:34 mornfall (jinak bych řekl že se může rozdělit který transformace půjdou pod a který nad to co se cpe do store jako typovej parametr)
18:35 mornfall ale muselo by platit že buď používaj store xor maj paměť, ale por je obojí
18:36 xstill tak ono tohle fungovat bude myslím, jen to není úplně typově hezký
18:36 mornfall jo to jo (trochu se bojim kolik se toho bude muset ozdobit šablonou na store teda)
18:37 xstill hm?
18:38 xstill v NonPorGrafu už jsou všechny věci šablonovaný
18:39 xstill popravdě ta struktura by ani neměla mít tu šablonu na Graf, vůbec ji nepoužívá :-D
18:39 xstill teda použvá, protože to posílá do Transform
18:40 mornfall it's complicated
18:44 xstill doprdele
18:44 xstill on je tam v POR ještě ten to_expand
18:45 xstill vector< Handle >, to jsem přehlídl
18:46 xstill teoreticky se to dá zachánit tak, že zafixujeme Handle vždy na TrivialHandle (což teď stejně je)
18:46 xstill otázka je jeslti to může někdy vadit
18:47 mornfall možná bych to prozatím radši řešil tím že se zakáže fairness (a por) + komprese
18:47 mornfall a zkusil vymyslet něco lepšího
18:48 mornfall je to trochu k zlosti ovšem
18:49 mornfall člověk si říká že ten model checker vlastně nic nedělá a mělo by to jít popsat na pár set řádek
18:49 xstill to se mi dost nechce (s ohledem na to, že ono to vlastně asi i funguje s normálním generic splitterem (já tu měl ještě per-object)
18:49 xstill no jo, taky mě to někdy štve kolik času trávíme těmahle blbostma
18:49 mornfall tak, blbostma
18:50 mornfall on to je ve skutečnosti asi nejfundamentálnější problém v CS jakej v životě potkáš
18:50 xstill no,  v ideálním světě bysme nemuseli řešit jak naskládat šablony, nebo dokonce proč se nám linker nevejde do paměti
18:50 xstill co je nejfundamentálnější problém CS?
18:51 mornfall no, jak něco popsat tak aby to šlo přečíst a zároveň fungovalo
18:51 xstill ah
18:52 mornfall (problém který se teda neomezuje na CS... kam se podíváš tam se s tím bojuje)
18:53 mornfall nejvíc mě na tom asi fascinuje, že „inženýři“ z praxe se návrhem jazyků zabývají mnohem víc než „akademici“
18:54 mornfall možná maj vědci špatnou chuť v ústech od dob Russela a Whiteheada
18:55 mornfall „From this proposition it will follow, when arithmetical addition has been defined, that 1+1=2.“ Volume I, 1st edition, page 379
19:03 xstill nojo, navrhni si vlastní a lepší
19:04 mornfall tak, všichni víme že C++ je v podstatě mizernej jazyk, stejně jako všechny ostatní... jen nikdo neví jak to spravit
19:06 mornfall (a taky není jasný že ony vyjádřovací problémy na které narážíme vůbec lze lepším jazykem řešit)
19:08 xstill tak, já třeba ani nevím jak ten problém pojmenovat jinak než "nefunguje to, nebo to není pěkné" :-/
19:09 mornfall :-)

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