| lizmat | . | 00:06 | |
| yoleaux2 | 22 Jun 2016 21:52Z <timotimo> lizmat: you think you can figure out how to make comb's pull-one not allocate Int? i tried replacing < with islt_i, but that's not it, so maybe it's $!pos++? | ||
| lizmat | timotimo: not sure what you benchmark is and which candidate you're talking about | 00:52 | |
| timotimo | oh | 00:53 | |
| my benchmark is 'my @res; for line() { @res.append: .comb }' over my linux' word list | |||
| lizmat | timotimo: ok, will check | 01:17 | |
| dalek | kudo/nom: 78d2ce6 | hoelzro++ | t/harness6: Chomp fudged filename output Otherwise, TAP::Harness ends up with filenames that have a trailing \n, and run(..., :!err) will silently fail with no TAP plan |
04:14 | |
| [Tux] | This is Rakudo version 2016.06-23-g78d2ce6 built on MoarVM version 2016.06 | 07:59 | |
| test 16.725 | |||
| test-t 9.934 | |||
| csv-parser 22.277 | |||
| psch | well, i'm not really getting anywhere with trying to figure out what's wrong from scratch, so i thought "just do the thing with the patch-method for the nested cu already" | 10:06 | |
| but then i realized that i need to have the knowledge of the nested cu in the containing cu | |||
| and i'm not sure i do | |||
| nine | But the containing CU is the one running the EVAL, so it should by definition know about the nested CU? | 10:25 | |
| yoleaux2 | 22 Jun 2016 23:14Z <Zoffix> nine: the bug I found last night where a P5 module loaded together with a P6 module had errors was introduced by this commit: github.com/rakudo/rakudo/commit/bf59085 | ||
| psch | nine: i'm not sure. i only reliably know the classname of the EVAL after it ran | ||
| nine: and i cannot say if the outer cu is finished then or not | |||
| nine | For a BEGIN time EVAL (which the bug is about) the outer CU cannot be finished before the EVAL ran | 10:26 | |
| psch | okay, yeah, i can see that | 10:29 | |
| ...also i think hack is dying | 10:30 | ||
| $ uptime 10:30:48 up 31 days, 11:15, 30 users, load average: 61.24, 28.46, 13.51 | |||
| it's 1min, 5min, 10min? | 10:31 | ||
| ah, 1 5 15 | 10:32 | ||
| anyway, yeah, that puts a stop on my hacking for now vOv | |||
| moritz: can you poke hack? with something that reboots it, preferably? | 10:37 | ||
| Woodi | I wonder about GC... we have generational one so "promoting" to 2nd generation is coping object memory or moving info about promoted object ? | 10:38 | |
| psch | Woodi: i think it's just putting the pointer in a different array | ||
| Woodi: but that's probably more a #moarvm question | 10:39 | ||
| Woodi | psch: I hope and right :) | ||
| jnthn | We actually move the object | ||
| Same during the semispace collection | |||
| Once an object reached gen2 it (at present) never moves any more. | 10:40 | ||
| uh, "any further" is perhaps clearer | |||
| So generally an object that makes it to the old generation will have been copied twice | |||
| Note though that this is about the direct object body | |||
| Arrays and strings in turn point to buffers, which are not moved. | 10:41 | ||
| Woodi | jnthn: why not just reference (and eg. not worry about memory fragmentation, etc) | ||
| jnthn | The point of copying is to avoid memory fragmentation, in fact. :) | ||
| Well, a point of is probably more correct, but still.... :) | 10:42 | ||
| Woodi have counter-example but forget what it was... | |||
| jnthn | A semi-space copying GC lets you just bump-the-pointer allocate your way through a nursery space, and when it's full you evacuate the living objects to the other semi-space, and they all land up packed together at the start of it. | ||
| Then the old generation in Moar is implemented as - up to a size limit anyway - a set of regions that all contain objects of the same size. | 10:43 | ||
| Also note that in most programs the majority of objects die young, and so never have to be copied at all. | 10:45 | ||
| timotimo | psch: i can also poke hack with something that reboots it | ||
| psch | timotimo: ah, i wasn't aware and didn't think to check | ||
| timotimo: fwiw, i think your fuzzer ran shortly before this started | |||
| timotimo | it's been running for like 3 or 4 days | ||
| psch | although i doubt that's what drove hack to (now) 200 load | ||
| timotimo | yeah, it shows "task blah blocked for more than 120 seconds" on its screen | 10:46 | |
| i bet it's the virtual disks again | 10:47 | ||
| timotimo forces a reset | |||
| Woodi | probably I was imagining outsorcing defragmentation to system malloc, which it don't offer... on the other hand freeing VM from that would be nice :) | ||
| timotimo | "force reset" didn't seem to do anything, but "force off" and "power on" did the trick | 10:49 | |
| did a bit of fsck, and is now booting | |||
| yup, there it is | |||
| psch | what a wonderful opportunity to reorganize my screen sessions \o/ | 10:51 | |
| timotimo | yeah, i guess | ||
| tmux would have let you do that on-the-fly, i bet :P | |||
| psch | well, think positive | ||
| idk if tmux does that automatically | |||
| but getting screen titles to always include CWD or "vim $openfile" was so annoying | 10:52 | ||
| Woodi | jnthn: if moust of object have something in common then Flyweight pattern applies (if they group into classes with common, immutable set of attrs)... so it allows to acquire simpler/smaller objects | ||
| psch | otoh, with tmux i'd have to conf it for screen binds, so that's annoying too :P | ||
| Woodi | psch: I lastly learned tmux with ^Z bindings :) | 10:57 | |
| timotimo | all in all, the response time to the crash was about 30 minutes. that's better than the last time. | 10:59 | |
| blurgh. the afl commandlines didn't end up in my bash history | 11:01 | ||
| timotimo is resuming afl, which seems to take a while | 11:13 | ||
| timotimo knows what most of the cached portions of hack's RAM will contain for the forseeable future | |||
| moritz | there seem to be a few (sd-pam) processes on hack | 11:18 | |
| does anybody what they do, and if I should care? | 11:19 | ||
| timotimo | "I think it's intended to guarantee that pam_close_session() is closed | 11:20 | |
| when its parent "systemd --user" exits. | |||
| " | |||
| wow, each of the three fuzzers has a sync_dir that's 4 gigs in size | 11:23 | ||
| hmm. the memory used on the root partition was also going up over the last days. not sure why that would be; all my fuzzing happens in my home directory | 11:24 | ||
| maybe it's collecting core dumps or something? but afl should prevent that, i'd think | |||
| going through / with ncdu -x doesn't highlight anything critical | 11:28 | ||
| oooh, q&a with larry wall, that's gotta be interesting | 11:35 | ||
| nine | timotimo++ # teaching me about ncdu | ||
| timotimo | ncdu is especially fantastic as it has a "delete this" button | 11:36 | |
| and the popup lets you tell it to "never ask me again (in this session)" | |||
| tadzik | oh yes :) | ||
| ncdu is great | |||
| dalek | kudo/nom: efbfdaa | lizmat++ | src/core/Str.pm: Make Str.comb 30% faster, timotimo++ Please note that I got rid of the ProcessStr role, because we cannot yet work with native int attributes from a role :-( |
13:35 | |
| kudo/nom: 9b579d0 | lizmat++ | src/core/Seq.pm: Squeeze a few percent out of Seq.iterator|is-lazy |
14:36 | ||
| psch | i am so confused right now | 14:41 | |
| so i'm declaring an array in nqp | |||
| then i iterate over another array and potentially push things into the declared array | 14:42 | ||
| then i have some debug output that gives me the size of the array | |||
| then i pass the array into a different sub in the same nqp file, and it gets copied into a different array | |||
| and after that copy process, numification of the array doesn't work anymore | 14:43 | ||
| on the target, though | 14:44 | ||
| which maybe means the copying is a silly idea..? | |||
| i really have no clue | |||
| lizmat | gist? | 14:45 | |
| psch | gist.github.com/peschwa/785b29f2eb...0267808653 | 14:46 | |
| the p6sort is copied from src/vm/moar/Perl6/Ops.nqp | |||
| well, plus a default for the &comparator parameter | 14:47 | ||
| and the bindpos_i was nqp::push before, didn't work the same way | |||
| lizmat | too much code to parse for me during Damian's functional programming tutorial :-( | 14:49 | |
| hope someone else can have the necessary cycles | |||
| psch | eh, i got it to work once before, i just lost the stash | ||
| i am confident i'll figure it out again somewhen, i'm mostly just venting i guess :/ | 14:50 | ||
| nine | psch: you lost the stash? Not even recoverable through the ref-log? | 14:51 | |
| psch | nine: well, "lost" in "dropped it"... i'm sometimes a bit stupid, ok? ;) | ||
| nine: i have no idea if that means it could still be in the reflog though | |||
| s/ in / as in / # vOv | 14:55 | ||
| nine | As long as the garbage collection has not run yet, it should be recoverable | 14:58 | |
| psch | well, i also didn't name it :| | ||
| ilmari | if you committed it it'll be in the reflog | 14:59 | |
| so you can cherry-pick it by id | |||
| psch | nope, didn't, i only stashed it | ||
| ilmari | the stash is commits too | ||
| psch | okay. can i look at diffs of that somehow? | 15:01 | |
| i mean, the reflog | |||
| ilmari | psch: hm, a dropped stash doesn't show up with reflog --all | ||
| |Tux| | lizmat, I got an eol failure. re-running now | ||
| psch | lizmat: ah, thanks for checking. i'll just try to recreate whatever i must have done... :) | 15:02 | |
| ilmari | psch: try asking on #git | ||
| nine | psch: git reflog -p | ||
| I guess git reflog -p | grep p6sort would give a quick answer | |||
| psch | nine: ah, yeah, that does indeed find it | 15:04 | |
| nine | Yeah :) | 15:07 | |
| Otherwise you could have tried the really hardcore desparate search: | |||
| find .git/objects/ -type f | cut -d/ -f 3- | sed 's/\///' | xargs -n 1 git cat-file -p | grep p6sort | |||
| psch | i don't see the crucial difference between the two patches, but well vOv | ||
| |Tux| | lizmat: p6 t/46_eol_si.t | 15:08 | |
| psch | like, the only thing i did different was iterating with for over the methods instead of with a while and incrementing a counter... o.o | ||
| nine | If it were an obvious thing, you'd have found it already ;) | ||
| psch | probably yeah :) | ||
| |Tux| | that does NOT run all tests. every run has a different number of tests | ||
| must be efbfdaa or 9b579d0 | 15:09 | ||
| lizmat | [Tux] : will check it out | 15:20 | |
| psch | compiling something that kinda maybe could potentially almost work \o/ | 16:04 | |
| the big doubt remaining is "can i actually just call the nested CU main method and don't i have to like pass some program state around..?" | |||
| which would be terrible if i had to, but i can easily imagine i'll have to, so there | 16:05 | ||
| timotimo | lizmat: wow, 30%, i did not expect this much. nice! | 16:19 | |
| psch | grr | 16:32 | |
| perl6 habits even propagate into indirect jvm bytecode generation | 16:33 | ||
| 'cause i compiled three times, trying to fix the same problem in a few ways | |||
| but in the end it clearly was just the omitted return | |||
| ...or not /o\ | 16:52 | ||
| well, the return *was* missing, but i still get the same error | |||
| codegen over too many abstractions is hard /o\ | |||
| lizmat | timotimo: well, it broke Text::CSV | 17:10 | |
| now looking at that | |||
| timotimo | oh crap :( | ||
| anyway, that'll give us a shiny new spec test ): | 17:11 | ||
| :) | |||
| lizmat | [Tux]: how many test *should* it run? | 17:12 | |
| timotimo | 50000 or something? | 17:15 | |
| lizmat | timotimo: this is not test-t | ||
| it's t/46_eol_si.t of the Text::CSV test-suite | 17:16 | ||
| .tell [Tux] looks like the problem existed *before* my patches: first run after re-compile: 693 tests, any other run has 673 tests | 17:23 | ||
| yoleaux2 | lizmat: I'll pass your message to [Tux]. | ||
| [Tux] | one run had over 750 | 17:33 | |
| yoleaux2 | 17:23Z <lizmat> [Tux]: looks like the problem existed *before* my patches: first run after re-compile: 693 tests, any other run has 673 tests | ||
| [Tux] | Now I get 703 every run | 17:34 | |
| timotimo | oh, oof | ||
| [Tux] | 703 looks ok, so I must have misremembered the 750+ | 17:38 | |
| rm -rf .precomp; make test | 17:39 | ||
| This is Rakudo version 2016.06-25-g9b579d0 built on MoarVM version 2016.06 | 17:43 | ||
| test 16.412 | |||
| test-t 9.756 | |||
| csv-parser 21.924 | |||
| 703 it is | 17:45 | ||
| sortiz | lizmat, a quick question: After fd98fc342 should we assume that Iterator.count-only, still documented, is not more in 6.c? Should its documentation be removed? | 19:39 | |
| Asking 'cus, I understand that many of the removed _implementation_ where, in fact, a premature optimization, but at the interface level, still make much sense, IMO. | 19:46 | ||
| lizmat | sortiz: the problem is that .elems did not cache, and this confused people | 19:58 | |
| and it potentially give a different result from prefix + | |||
| (because that *did* cache) | 19:59 | ||
| so, until we can figure that one out, having count-only is a premature optimization | |||
| so, what I did was basically 2 things: | |||
| - remove all internally defined count-only methods | |||
| - don't let Seq.elems call count-only on the iterator | 20:00 | ||
| sortiz | Yep, that clear, but honestly I wold have preferred resolve the confusion the other way, ie. made numification attempt to count-only fist. | 20:01 | |
| lizmat | sortiz: tried that :-( | 20:02 | |
| sortiz: which does not mean you shouldn't try :-) | |||
| it's just that *I* gave up, and *I* was the only one between pmichaud / jnthn / TimToady to who it made sense | 20:03 | ||
| sortiz | The problem I see is that now, a BIG Iterabkeerator | 20:04 | |
| lizmat | which is what .cache does | 20:05 | |
| sortiz | oops A big iterable, when cached, isn't yet reified but when elems called, that colapse! | ||
| unless marked lazy, so now there isn't any more for ask the size without loading, in memory, all the elements. And happens that I has an on-disk Hashish (LMDB) potentially really big. | 20:11 | ||
| *a way for ask | |||
| lizmat | sortiz: ok, so you're saying you can know the number of elements of an iterator without generating the values? | 20:15 | |
| that's not generally true | |||
| hmmm... perhaps the default count-only should cache... | 20:16 | ||
| sortiz | In all the *DBM files that the case, and all support an Iterable interface. | ||
| lizmat | hmmm... lemme think about that | ||
| sortiz | *that is | 20:17 | |
| lizmat starts paying more attention to Damian's tutorial again :-) | |||
| sortiz | Oops, sorry.. CYL& | 20:18 | |
| nine | lizmat: so you're finally learning Perl 6? ;) Wish I could join you | 20:24 | |
| lizmat | yeah.... finally! :-) | ||
| m: multi a() {}; multi a() {}; a # not taking the foirst | 20:46 | ||
| camelia | rakudo-moar 9b579d: OUTPUT«Ambiguous call to 'a'; these signatures all match::():() in block <unit> at <tmp> line 1» | ||
| lizmat | TimToady: was that what you meant ? | ||
| TimToady | only if there are constraints | ||
| lizmat | ah, ok | ||
| m: multi a("") { say "first" }; multi a("") { say "second" }; a("") # first matching constraint | 20:48 | ||
| camelia | rakudo-moar 9b579d: OUTPUT«first» | ||
| sortiz | My point of is that, at the interface level, the Iterator role needs a well defined method to ask for its size, even if the default result is Inf or some kind of 'dunno'. | 21:21 | |
| Zoffix | 2016.04: Stage parse: 81.936 / Bleed: Stage parse : 56.483 | 21:47 | |
| m: say "{(81.936 - 56.438) / 81.936 * 100}% fastar" | |||
| camelia | rakudo-moar 9b579d: OUTPUT«31.119410% fastar» | ||
| Zoffix | (for rakudo build) | 21:48 | |
| timotimo | nice | 21:51 | |
| jdv79 | Zoffix: what causes that speedup? | 23:19 | |
| Zoffix | ¯\_(ツ)_/¯ general progress? | 23:24 | |
| timotimo | someone else got a bronze sponsorship for the butterfly | 23:40 | |
| Zoffix | Yeah, saw it :) | 23:51 | |
| They fixed my name! |