01:08
FROGGS_ joined
01:47
ilbot3 joined
02:46
sortiz joined
|
|||
lizmat | commute& | 06:32 | |
09:03
RabidGravy joined
09:08
vendethiel- joined
10:47
teatime joined
|
|||
dalek | p: 5b38e6c | (Pawel Murias)++ | src/vm/js/Chunk.nqp: [js] Emitting source-mapped code for an ChunkEscaped. |
10:56 | |
p: 70e4020 | (Pawel Murias)++ | src/vm/js/ (2 files): [js] Implement nqp::multicachefind and nqp::multicacheadd. |
|||
p: 637ff94 | (Pawel Murias)++ | src/vm/js/nqp-runtime/core.js: [js] Fix multi caching. |
|||
[Tux] | test 21.957 | 11:53 | |
test-t 13.383 | |||
csv-parser 26.385 | |||
And I will start playing with UTF8-C8 | 11:54 | ||
Will RT#127358 get some thoughts? | 11:55 | ||
synopsebot6 | Link: rt.perl.org/rt3//Public/Bug/Displa...?id=127358 | ||
nine | Working through this EVAL issue feels like doing one of those 5000 piece puzzles. Some days you sit there for an hour matching up a single piece and other days you make real progress. Only that this is a puzzle that I have to build in my head while having an almost perfect template. | 11:56 | |
masak | nine: is that because of essential complexity that's hard to do anything about, or because some inspection tool is currently missing? | 12:36 | |
nine | It's probably just the essential complexity of compiling and running code at the compile time of other code. And me having to figure out all the intricacies of this process just by reading rakudo's, nqp's and MoarVM's code and littering the code with nqp::sayfh. | 12:41 | |
jnthn: I finally made some progress again! Turns out, I had a little thinko: binding $!num_code_refs to the outer world's $!num_code_refs won't bind a container as in Perl 6, so they won't stay shared. Results in $!code_ref_blocks[1] being overwritten and thus one code ref not appearing in the SC. | 13:00 | ||
jnthn: with that fixed, I'm now at "Expected MAST::Frame, but didn't get one". I guess this will be just as challanging... | 13:01 | ||
14:08
vendethiel joined
18:40
hankache joined
18:48
Skarsnik joined
21:12
AlexDaniel joined
|
|||
ugexe | Text::Levenshtein::Damerau is failing its tests with a "Memory allocation failed; could not allocate 1823145984 bytes". Started sometime after 2016.02-63-g9dc21a0 | 22:58 | |
timotimo | that sounds like an endless recursion | 22:59 | |
ugexe | ah strange. when i run the tests directly it tells me more precisely trying to modifying an immutable Str | 23:05 | |
but fixing that it still hits the memory error after | |||
timotimo | you can gdb it and break on MVM_panic or something | 23:06 | |
ugexe | s/int/Int/ and s/str/Str/ gets past the error as well | 23:07 |