Perl 6 - the future is here, just unevenly distributed

IRC log for #divine, 2016-11-20

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

All times shown according to UTC.

Time Nick Message
00:26 divine-buildbot joined #divine
00:51 divine-buildbot joined #divine
01:26 divine-buildbot joined #divine
02:02 divine-buildbot joined #divine
02:39 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:01 divine-buildbot joined #divine
03:13 divine-buildbot joined #divine
08:46 xstill hm, divine se zacyhlil při generování trace zdá se
08:47 xstill ale pochybuju, že to souvisí s tím, co řešíš ty, protože je to call na nedefinovanou hodnotu
08:48 mornfall co trace, já zjistil že verify --threads 2 na float-arithmetic.2.c se zasekne
08:50 xstill a pak jsem ti opravil print na invoke a na call pointru
08:50 xstill + přidal nějaké testy na sim
08:51 mornfall ... mně?
08:52 mornfall kde to najdu?
08:52 xstill no tak VM je víceméně tvoje oblast
08:52 xstill normálně v ~xstill/DIVINE/divine4 myslím
08:52 xstill a taky jsem si úspěšně zabil stroj zdá se
08:53 xstill hm, koukám, že ten  VM: Work around limitations in 80-bit FP support in valgrind. bych měl asi unpullnout, že?
08:54 mornfall no, já chvíli myslel že jsem tím rozbil floaty, ale zdá se že ne
08:54 mornfall (proto jsem ho radši vykopnul z updatu nightly)
08:55 xstill zdá se, že při tom cyklení na trace divine sežere všechnu paměť :-/
08:56 xstill asi bych těm strojům měl nastavit nějaký cgrupy, jak to nemá SSD tak tomu sežraná paměť dělá fakt zle
09:01 mornfall aha já se divim že ty patche nemůžu najít a nějak jsem z historie vyvolal DiVinE místo DIVINE a tam nic nebylo (ale repo jo)
09:01 xstill aha :-D jo no, mohl bych si tam udělat pořádek
09:06 xstill wtf. to se stane jak, že ssh pošle do háje i roota?
09:07 mornfall logind blázní?
09:09 xstill to mám teda radost
09:11 xstill_ joined #divine
09:16 xstill ha, probralo se to dost na to abych zabil divine
09:22 xstill co by se mělo stát pokud zavolám funkci s míň parametrama než má?
09:23 mornfall fault
09:23 mornfall spito se s tím srazil, protože ty pts testy mají threadovej main bez argumentů
09:24 xstill ne, opačnej problém, mám foo( x ) a zavolám ho jako foo(). to teď nefaultuje totiž
09:26 mornfall no to vlastně nevim... tradičně to v C nevadilo (protože cdecl konvence)
09:26 mornfall ale asi bych to nechal vyfaultovat
09:26 xstill no C nevadí ani jedno, ne?
09:26 xstill taky bych to spíš nechal faultovat
09:26 xstill dodělám to
09:27 mornfall no když tam dáš míň tak si ta funkce přečte ze zásobníku něco jinýho, případně to přepíše
09:28 xstill ajo vlasntě, tak tím spíš by to měl být fault
09:28 mornfall no to je ten případ kdy to fault už je
09:30 xstill právě že ne, fault je pokud předám víc, než ta funkce čeká, což je to co se děje v těch testech, že tam thread nebere ten void *
09:30 mornfall nojo... asi potřebuju víc kafe
09:30 mornfall jakto že to není fault?
09:31 xstill nevím, dodělám
09:32 xstill tam je trochu problém, že v DIVINE je tohle OK (až na to, že ty argumenty jsou nedefinovaný)
09:32 xstill OK ve smyslu, že to s naší volací konvencí funguje
09:36 mornfall jasně, ale on je to asi stejně bug kterej chceš chytnout
09:36 xstill jo, to chci
09:39 xstill wtf. mám dva testy, jeden volá null, druhej nedefinovanej null, v releasu ten první normálně zahlásí chybu a ten druhej cyklí při výpisu trace. V debug ten první nenajde chybu, ale ten druhej ji normálně najde.
09:47 xstill aha, já už to začínám chápat, on totiž NULL není code pointer
09:56 mornfall no, blbý je že protipříklady sice fungujou, ale ze zatím těžko pochopitelných důvodů je to něco jako 3x pomalejší
09:57 mornfall i přesto, že by se to teoreticky mělo chovat spíš líp
10:03 xstill celej DIVINE, nebo jen generování protipříkladů?
10:09 mornfall no divine, ten problém nebyl v protipříkladech per se
10:18 xstill aha, to je blbý, co jsi s tím nakonec udělal?
10:29 mornfall počítám objid při alokaci jako hash pár hodnot (thread id, program counter, vzdálenost od iniciálního stavu, počet skoků od začátku hrany)
10:29 mornfall jinak se to chová dobře, ty objid jsou běžně unikátní, přesto se někde něco zasekalo
10:30 mornfall čekám na profil
10:35 xstill není problém s tou vzdáleností od iniciálního stavu? to by mohlo způsobovat, že se to na diamondu rozjede, ne?
10:36 mornfall nemohlo (počítá se to tak aby se to nedělo)
10:37 mornfall hm, no, vlastně mohlo, ale to stejně není ten problém
10:37 mornfall (pokud by ten diamond byl asymetrickej, nevim jestli se to moc děje)
10:45 mornfall jo, jenže já nevidim jak moc to rozbilo content hashe
11:02 xstill hm, on ten undefined pointer v callu dělá double fault
11:02 xstill a ten zdá se moc nefunguje
11:03 xstill ad content hashe, nejde přidat nějakou statistiku kolik je v té tabulce objektů? Protože pokud se rozbijou content hashe tak jich bude víc
11:06 xstill k čemu je ten rollback v doubleFaultu?
11:07 mornfall jinak by ten stav v momentě doublefaultu zase dostal scheduler, což by asi moc nezafungovalo
11:11 mornfall takhle by to aspoň teoreticky mělo vyrobit error selfloop, ale počítám že to nikdo nikdy nezkusil
11:13 divine-buildbot Hey! build divine-next-debug #144 is complete: Failure [finished]
11:13 xstill no vypadá to, že se na tom CE rozseká
11:14 xstill druhej problém teda je, že tady není důvod k double faultu
11:23 yaqwsx joined #divine
11:25 xstill v simu tam je selfloop
11:25 mornfall to asi štimuje
11:25 mornfall takže z toho nemůže jen trace ve verify?
11:26 xstill asi
11:30 mornfall a kterej kus toho nevíš? protože ten ss::search se nemá moc jak zacyklit, snad
11:31 xstill no found an error se vypíše, pak to cyklí
11:31 mornfall pokud by se tomu povedlo zkorumpovat si parent graf, tak se to zacyklí a bude to žrát pamět
11:31 yaqwsx joined #divine
11:35 mornfall a ten problém s rychlostí není jen s rychlostí, ono to navíc vygeneruje 4x tolik stavů (a je to tou vzdáleností, bez ní to funguje zhruba stejně jako předtím, ale je to trochu křehký, takže musim vymyslet ještě nějakou permutaci aby to bylo robustnější)
11:36 xstill křehký protože je velká šance, že to trefí stejná ID?
11:36 mornfall jo, a pokud se to začne dít tak to je fakt hodně drahý
11:37 mornfall když jako hash použiju const 1, tak to v release buildu generuje tak 15 stavů/s
11:38 mornfall chvíli jsem si myslel, že hash from je dobrý zdroj mixování, ale to funguje stejně blbě nebo hůř než počítadlo
11:39 mornfall (z podobného důvodu)
11:40 mornfall chce to nějaký číslo co nezáleží na proložení, ale mění se jak se tím grafem prochází (a to je asi trochu protimluv)
11:42 mornfall (stavy se množí když čísla závislá na objid přestanou být ukazatele a ty objid divergujou)
11:43 mornfall pak je taky potřeba check v memcpy implementovat nějak jinak asi, ale to až bude tohleto dořešený
11:45 mornfall jedna věc která by asi fungovala je počítat kroky (hrany) per vlákno za weak ukazatelem (to by musel udržovat dios), ale chtěl bych radši něco jednoduššího
11:46 xstill zkusím se zamyslet až zjistím proč cyklí ten trace; ten check v memcpy už jsem tuším jednou opravoval u sebe, protože se někdy i blbě optimalizoval
11:47 xstill každopádně trace z parentů se ještě napočítá
11:47 divine-buildbot Hey! build divine-next-debug #142 is complete: Failure [finished]
12:09 xstill hm, to je docela těžký, protože je potřeba aby to při alokaci na cyklu vracelo pořád nová IDčka (tomu vláknu v cyklu), i v případě, že se se mezitím udělal interrupt (což se skoro vždycky udělá)
12:10 xstill ad ten double fault, ta smyčka není úplně dobrá už proto, že tím pádem to nevypíše ten error trace (protože ten stav se zadá jako koncovej už když se najde poprvé)
12:10 xstill no a pak teda zdá se, že stepper nezastaví
12:11 mornfall error smyčku musíme umět řešit ať doublefault nebo ne
12:11 mornfall může vzniknout aj jinak
12:36 yaqwsx joined #divine
12:48 divine-buildbot Hey! build divine-next-debug #149 is complete: Failure [finished]
13:00 mornfall no, přimíchal jsem do toho jak objid tak (objid-independent) content hash aktuálního rámce, to by mělo pokrýt většinu případů
13:01 mornfall vyskakuje mi tam konflikt délky jedna na InterruptMask::Without::Without(...), ale jinak jsem žádný neviděl, za asi 4M stavů
13:03 wmbot joined #divine
13:04 mornfall navíc jsem zjistil, že to jestli je něco pointer se vůbec při dereferencování nekontroluje :) tak jsem to opravil a rovnou zrušil značkování ne-heap pointrů v shadow, což přidalo něco jako 30 % na rychlosti (testováno na masivním vzorku jednoho modelu)
13:05 xstill ne heap pointry nemusí být označné?
13:05 mornfall (ten konflikt je na rámci toho konstruktoru, jestli dobře vidim... nezdá se že by měl jakékoliv tendence prodlužovat se, takže je to jedno)
13:05 xstill co znamená konflikt délky jedna
13:05 xstill ?
13:06 mornfall no že se nahashujou na stejný objid dva objekty (a ne víc)
13:07 mornfall ono to teď funguje jako normální hashtabulka
13:12 xstill aha
13:19 mornfall pokud jde o značení, jediný co se tím rozbije jsou anonymní related pointry v sim-u, resp. v draw
13:20 mornfall hm, no dobře, ještě teda kontrola na protočení dokola
13:20 mornfall (u těch co nejsou heap)
13:21 mornfall což ale jde řešit i tím že se oddefinují když se to stane
13:22 mornfall jen to vlastně není moc hezký z pohledu aritmetiky která netušila že to je pointr... možná to tam vrátim
13:23 mornfall (on to je ale asi UB, ne?)
13:24 mornfall (nebo to se vztahuje jen když tu věc pak dereferencuješ? jakej byl problém s tím memcpy?)
13:25 xstill co jestli je UB?
13:25 mornfall rozdíl ukazatelů co neukazujou do stejnýho objektu třeba
13:25 xstill to myslím, že je podle standardu
13:26 xstill i když z hlediska LLVM asi ne
13:29 mornfall vyrobit ukazatel za konec objektu a pak ho 'vrátit' je, zdá se, taky UB... ale nevim jestli to platí i když se to castne na int a nechá se to být intem
13:29 mornfall teda intptr_t
13:33 mornfall ono totiž srovnání ukazatelů je unspecified, ne undefined
13:33 mornfall jen rozdíl je zakázanej
13:33 mornfall takže naimplementovat conforming memcpy by mělo být nakonec jednoduchý
13:34 mornfall ale teda kazí to myšlenku oddefinovat const/... ukazatele když se rozbijou
13:35 mornfall takže to asi vrátim, přijdeme o 30 %, a přidám tam na to kontrolu tak aspoň výměnou můžem chytat víc chyb
13:36 mornfall nicméně to ukazuje na bídu testů, protože doteď se to nekontrolovalo vůbec, ani u heap ukazatelů :-)
13:38 divine-buildbot Hey! build divine-next-debug #150 is complete: Failure [finished]
13:49 xstill hm, tak jsem se dopracoval až k assertícímu poolu
14:07 divine-buildbot Hey! build divine-next-debug #145 is complete: Failure [finished]
14:20 mornfall xstill: určitě chceme mít pid v corepattern? to se pak hrozně rychle množí
14:20 mornfall přijde mi lepší si zálohovat ty který chci
14:20 mornfall navíc to rozbilo backtrace v testech (který můžu spravit, ale tak...)
14:21 xstill mornfall: nejsem si vědomý, že bych to tak nastavoval
14:21 xstill a nechceme
14:22 mornfall tomu nerozumím, teď je tam zase core... tys to změnil?
14:22 xstill jo
14:22 mornfall já tam dával %e.core což by mělo vyrábět divine.core
14:22 xstill aha, tak sorry
14:22 xstill vrátil jsem to zpět
14:23 mornfall nicméně ještě před pár hodinama tam bylo %e.core.%p nebo něco takovýho... je možný že to nějakej démon změnil?
14:23 xstill to mi příjde dost divný, počítám, že kdyby do toho hrábnul systemd tak si tam vrátí ten journalovací bazmek
14:25 xstill nenastavil jsi to ty někdy? jak jsme se bavili o tom, že jsou vypnutý
14:25 mornfall kdoví... jedinou zmínku o core_pattern v /etc vidím na =core v sysctl.d
14:25 mornfall no já tam právě nastavoval to %e.core pár dnů dozadu
14:26 mornfall chvíli to omylem bylo core.%e ale podle historie jsem tam žádný %p nikdy nedával
14:27 xstill divný, pak na to asi fakt musel hrábnout nějakej daemon
14:28 mornfall to je nějaký trhlý
14:28 mornfall to %e.core asi prostě jen nefunguje
14:30 mornfall if
14:30 mornfall /proc/sys/kernel/core_pattern does not include %p and
14:30 mornfall /proc/sys/kernel/core_uses_pid (see below) is nonzero, then .PID will
14:30 mornfall be appended to the core filename.
14:30 mornfall nojo
14:31 mornfall takže houby démon, ale kernel si to tam lepí sám, proč ne
14:31 mornfall vypnul jsem to
14:33 mornfall sláva, mám backtrace
14:48 xstill mornfall: máš představu, proč by mohl selhat assert na brick-mem:230?
14:48 xstill volaný z allocate
14:53 mornfall valgrind nic neřekne?
14:57 xstill myslím, že nic neříkal, ještě to zkontroluju
15:05 xstill hm, před tím assertem ne, ale tady to za ním je dost podezřelý: Block 0x27d9d2f0..0x27d9d2f1 overlaps with block 0x27d9d2f0..0x27d9d2f1
15:06 mornfall no to odpovídá tomu assertu
15:06 mornfall pokouší se to alokovat už alokovanej chunk
15:07 mornfall xstill: hm, máš db00dedf41be06d78d519afef3bb5467d8e0df8b?
15:08 mornfall (jestli jo, tak by to mohlo být tím, ještě jsem se nedostal k tomu abych spravil sim, resp. teď tam opravuju ještě jinej fallout)
15:08 xstill vypadá to, že nemám, co to je?
15:09 mornfall VM: Fix a memory leak in Explore::start( Context ... ).
15:10 xstill hm, vypadá to, že se pokouším 2x materializovat něco ve shadow
15:10 xstill shadow.hpp:236
15:13 xstill ale nevím jestli to má být samo o sobě problém
15:14 mornfall asi spíš ne, protože jinak by to nefungovalo vůbec
15:14 mornfall (proto taky materialize maže paměť)
15:14 mornfall *-ise
15:16 xstill aha, tak to potom asi nesouvisí
15:17 xstill mě zmátlo, že je to ta stejná funkce, co trigla ten assert, ale je to jiné volání (jiné parametry)
15:17 mornfall to se stane tak, že v tom referenčním poolu se něco dealokovalo, ale ten přidruženej o tom nemá jak vědět
15:23 xstill aha
15:23 xstill ale nějak se asi podařilo haldě dvojitě alokovat objekt v object poolu, což je dost divný
15:24 mornfall koukám že resize asi leakuje paměť
15:29 mornfall (pokud ta věc byla writeable tak by ji měl zahodit)
16:21 yaqwsx joined #divine
16:31 divine-buildbot Hey! build divine-next-debug #143 is complete: Failure [finished]
17:44 mornfall yaqwsx: jak to dopadlo s testama na dios?
17:57 yaqwsx Stihl jsem zatím napsat 2.
19:13 yaqwsx joined #divine
19:17 xstill nějak záhadně se stane, že se v jednom poolu (teda z jednoho Shared) naalokuje 2x stejnej blok
19:18 xstill mám podezření, že za to může ten boot dbg kontextu ve verify ve spojení s tím loadem potom před spuštěním stepperu, přičemž každej z nich má jinej pool a z toho boot pool-u tam asi někde zůstane
19:19 xstill i když to teda moc nechápu
19:19 xstill každopádně když ten boot hodím do toho !statecount ifu, tak to zdá se funguje
19:20 xstill ale moc to nedává smysl
19:21 xstill stejným blokem myslím stejné číslo slabu
19:22 xstill a pak to bouchne protože to už má alokované vghandly
19:22 mornfall jo jenže pak to nebude fungovat (bez toho bootu)
19:23 mornfall budou chybět typeinfa pro výrobu backtrace
19:24 mornfall jakto že má každej jinej pool?
19:24 mornfall to je možná celej problém
19:24 xstill no, mě by spíš zajímalo jak je možný, že se to tak rozbije, tohle můžeš brát jako dodatečnou informaci o tom bugu
19:24 xstill to nevím
19:27 mornfall pokud jsou tam dva pooly tak se to stane asi lehce, počítám že stačí zavolat free na pointer z jinýho poolu
19:28 mornfall pokud to je ještě nealokovanej kus, tak se pak alokuje jak z freelistu tak jako kus poloprázdnýho bloku
19:28 mornfall bum
19:29 mornfall až teda na to, že pokud se děje tohle tak by asi měl assertovat valgrindDeallocate
19:29 mornfall +d
19:31 mornfall co se stane když před ten dbg_boot ještě hodíš dbg.load( ctx )?
19:31 mornfall (novej, ten co tam už je nemaž)
19:32 divine-buildbot Hey! build divine-next-debug #147 is complete: Failure [finished]
19:35 mornfall navíc ten content hash aktivního rámce není dobře a když to opravím tak je to horší...
19:35 mornfall teda ono to je v principu dobře, ale mně se nechce ho počítat pokaždý
19:41 xstill no jasně, protože konstruktor DebugContextu vůbec nebere haldu toho programu, to je počítám ten problém
19:42 mornfall jen pokud ten trik s loadem zabere... (pak je asi smysluplný přidat druhej konstrktor DebugContextu)
19:44 xstill no takhle je ta halda v tom dbg default konstruovaná, takže má svůj pool. Nevysvětluje to teda pořád proč se to rozsype takhle, ale mohlo by to tím být.
19:45 mornfall ten load tam tu haldu dodá
19:45 xstill to jo, ale není možný, že někde (v něčem co vytvořil boot) přežije něco z té staré?
19:46 xstill když loadnu kontext před tím bootem tak to funguje
19:46 mornfall jo to jsem se ptal
19:46 xstill však proto to dělám, jen jsem předtím chtěl vědět, proč tam ta halda není rovnou správná
19:47 xstill proč se vlastně debug context nevytváří z kontextu toho Explore?
19:50 mornfall haldu to mělo sdílet, ale beztak mi není zrovna jasný kde zůstane jaká reference na ten druhej pool
19:54 xstill on totiž Program nemá haldu jestli se dobře koukám
19:55 xstill mornfall: mám dbg přepsat tak aby se konstruovalo z kontexu, nebo z programu a haldy?
19:57 mornfall mně by docela zajímalo jestli to je skutečně ten bug nebo se to tím jen maskuje
19:59 mornfall v registrech to zůstat nemůže, ty se všechny přepíšou při loadu a nic jinýho v tom kontextu do haldy ukazovat snad ani nemůže
20:02 mornfall stejně tak ve verify se nezdá že by cokoliv leakovalo... ha, už vím
20:02 mornfall xstill: zkus tam hned za ten load co tam už byl přidat dbg.flush_ptr2i()
20:03 mornfall resp. ono to patří pak do Context::load( Context )
20:04 xstill co to je?
20:04 mornfall to je to jediný kde se mohla udržet nějaká reference na něco před load()-em
20:05 mornfall i v ptr2i je internal, tzn. pool pointer do haldy
20:06 mornfall pár hodin dozadu jsem je přidal na spoustu míst, ale do verify jsem se nedíval
20:07 xstill nepomohlo
20:08 mornfall jasně no, protože to se tam už volá (v setup::scheduler)
20:09 mornfall takže zase nevim kde může vyleakovat chybná reference
20:22 xstill protože to vůbec není bug v kontexu ale v poolu, v initL chybí _l.emptyblocks.clear()
20:23 xstill trochu blbý, že na tu funkci jsem už dneska několikát koukal
20:23 xstill a nenapadlo mě zkontrolovat, že inicializuje všechno
20:24 xstill jo, no, tím se to opraví, bez nějakých dalších loadů nebo něčeho takovýho
20:24 xstill takže jo, ten load jen maskoval bug
20:25 xstill problém je, že se to projeví jen pokud se do toho poolu přiřadí
20:26 mornfall vida
20:40 xstill škoda, že to není jediný co nefunguje, zatím jsem ti dal do repa patche na ten pool + reportování počtu argumentů, testy k tomu mám ale zatím neprochází všechny (protože ten selfloop), takže ty dodám později (testy na to co je v repu zdá se procházejí)
20:53 yaqwsx joined #divine
21:15 xstill bingo, druhej bug nalezen
21:23 mornfall omg callgrind a vlákna fakt nejdou dohromady
21:23 mornfall 3 hodiny na 4 vláknech, 3 minuty na jednom
21:24 mornfall profil k ničemu protože všechen čas to strávilo v deque
21:26 xstill mornfall: mám problém, stepper když zjistí, že má null frame tak pustí znovu scheduler, a já moc nemám jak poznat, že je to kvůli doble faultu, jedině snad podle toho, že platí zároveň, že je rámec 0 a _VM_CR_Error, což si ale nejsem jistej, jestli se od stepperu očekává
21:27 mornfall xstill: to by mohlo být jedno ne? když má nastavený _stop_on_error a _VM_CF_Error je nastavený tak se stopne? (pokud ne tak to je asi bug)
21:28 mornfall nebo mu ten error flag smaže to schedule?
21:29 xstill jo, smaže
21:29 xstill vm::setup::schedule
21:30 mornfall +r... jo, to asi stačí opravit schedule() ve stepperu aby to nevolal pokud _stop_on_error a _VM_CF_Error
21:30 xstill OK
21:31 divine-buildbot Hey! build divine-next-debug #151 is complete: Failure [finished]
21:40 mornfall xstill: chápu správně že ten patch na DebugContext s _disallowNowChoices je víceméně assert?
21:41 mornfall asi bych to vyřešil radši tím že bych tam na konec vrazil -1
21:42 xstill takovej podmíněnej assert
21:42 xstill to by teoreticky šlo, jen to nebude padat v release
21:42 mornfall to ani ostatní kontroly podobnýho ražení
21:43 mornfall pokud se tohle stane je to jednoznačně chyba jinde (třeba že se odignoruje _stop_on_error)
21:43 xstill tohle může způsobit zacyklení protipříkladu
21:43 xstill původně to tam je kvůli tomu selfloopu
21:44 mornfall kdyby každej assert kterýho fail může něco rozbít měl fungovat aj v release, tak je tam můžem dát rovnou všechny
21:45 xstill nojo, tak já si to smažu
21:53 mornfall nicméně to vidim tak, že uděláme betaverzi... sice jsme teď zničili spoustu bugů, ale kdoví kolik jich tam ještě je
21:55 xstill u mě jsou další patche (testy ještě běží)
21:55 xstill jen ten test s tím double faultem je pořád todo, protože tam nemá docházet k doulefaultu (call-undef)
21:55 xstill navíc při double faultu jsou špatně locations
22:10 xstill + jeden bonusový z 23. 1. :-D
22:12 mornfall jen bys mu mohl doamendovat nadpis :) (klidně s --keep-date)
22:13 xstill hm, akorát to buď nefunguje, nebo nefungovalo to předtím, protože failnul test
22:16 xstill amendnuto, ale zatím si ho nepulluj, musím zjisti proč padá ten test
22:18 mornfall nemá tam být <=? (s1 + n už je za koncem s1)
22:18 xstill
22:24 xstill jo no, pomohlo to
22:24 xstill amendnuto
22:26 divine-buildbot Hey! build divine-next-debug #152 is complete: Failure [finished]
22:31 divine-buildbot Hey! build divine-next-debug #153 is complete: Failure [finished]
22:34 yaqwsx joined #divine
22:36 divine-buildbot Hey! build divine-next-debug #154 is complete: Failure [finished]
22:42 divine-buildbot Hey! build divine-next-debug #155 is complete: Failure [finished]
22:46 divine-buildbot Hey! build divine-next-debug #156 is complete: Failure [finished]
22:52 divine-buildbot Hey! build divine-next-debug #157 is complete: Failure [finished]
23:15 divine-buildbot Hey! build divine-next-debug #158 is complete: Failure [finished]
23:41 yaqwsx mornfall: patch s API testy + bugfix na chybu, kterou odhalily, u mě v homu
23:45 mornfall kk

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