00:02 vendethiel joined 01:23 vendethiel joined 01:34 colomon joined 01:35 Peter_R joined 02:00 vendethiel joined 02:19 colomon joined 02:24 vendethiel joined 02:51 TEttinger joined 03:06 colomon joined 03:10 vendethiel joined 03:19 TimToady joined 03:42 vendethiel joined 04:37 vendethiel joined
dalek arVM/free-exception-strings: ac517ce | hoelzro++ | src/ (22 files):
Free strings used for exception formats
 05:07
05:27 vendethiel joined 05:51 vendethiel joined 06:00 brrt joined 06:26 FROGGS joined 06:33 vendethiel joined 06:38 btyler joined 06:43 brrt joined 07:22 vendethiel joined 08:36 vendethiel joined 08:49 sivoais joined 09:06 vendethiel joined 10:49 TimToady joined 11:19 rurban joined 12:25 brrt joined
brrt \o 12:26
JimmyZ o/
brrt i've learned another lessons today 12:29
the builder pattern is bogus
the builder pattern presumes (among other things) that you want a immutable 'value' thingy which you need some other mutating thingy to construct 12:30
i guess that makes sense for an URI, but it does not for a graph 12:31
why want a graph that you can't mutate? it's madness
jnthn I don't think the pattern mandates the resulting object has to be immutable...
It's a good fit when it is, but mostly I see it was providing a nice interface to complex construction
brrt good point 12:33
still
i want to mutate my graphs, it turns out
:-)
oh, and i'm rather controversially (i think) going to add a dynamic array implementation 12:36
based on macros
i have only one question
prefer foo_num or num_foo
jnthn concrete examples? 12:38
hoelzro moarning #moarvm 12:41
brrt ehm, in spesh/graph.h, i think we have... lemmesee
moarning hoelzro
spesh_slots, num_spesh_slots, alloc_spesh_slots
timotimo we have "num used" and "num allocd" struct members all over the place; maybe adapt the names from there? 12:42
yeah, sounds good
brrt i have no intention of changing those just now, just want to see how this works for new code :-)
timotimo did you know we have/had a pullrequest in the past that built a common struct and functions for auto-growing arrays?
at least i think i saw something like that
i forgot who sent it in, though, and why it wasn't taken in
brrt did you know it was one of the first things i've said when i started working on moarvm? :-) 12:43
timotimo hehe
OK :)
BBIAB
brrt but, macro's are preferable, actually
hmmm 12:45
in this case, foo_num is preferable
that works correctly with structs
because the macro makes foo->bar ## _num into foo->bar_num, and it'd otherwise be num_foo->bar 12:47
hoelzro so I found a lot of instances of MVM_exception_throw_adhoc that use strings from MVMStrings, and I fixed them to use MVM_exception_throw_adhoc_free 12:54
jnthn hoelzro++ 12:55
hoelzro would anyone mind looking over the changes to see if I missed anything? github.com/MoarVM/MoarVM/pull/231
brrt the first few files look quite reasonable to me :-) 13:02
oh, in 6model.c you have an // XXX , any particular reason?
timotimo i think // comments are discouraged in our codebase 13:05
hoelzro looks
timotimo and the travis ci error is about clang taking more than 10 minutes for interp.c
which ... yeah, clang is slow i guess? 13:06
brrt o.O
i thought they had that fixed, but it's probably just ELOCALMACHINEISFAST
timotimo hehe
what are those //~ things in nativecall_libffi.c, i wonder 13:08
hoelzro the // XXX is one of the spots I missed
dalek arVM/free-exception-strings: fb89cfe | hoelzro++ | src/ (22 files):
Free strings used for exception formats
 13:10
timotimo there seems to be at least two // XXX
hoelzro I just see one
well, saw
;)
timotimo only one left in loadbytecode.c
except, you probably fixed it now? :)
hoelzro oh, that one 13:12
well, that is something outside my knowledge level
because I don't know to catch a MVM exception and rethrow it after cleanup
timotimo i think if MVM_cu_map_from_file throws an exception, that longjmps out of the code 13:13
back into the interpreter
I personally would probably go with a flag for cu_map_from_file that says if the string should be freed or not
actually, looking at the MVM_exception_throw_adhoc_free implementation to see how it handles the dance around the exception throw may be enlightening 13:14
(enlightening for me, too)
ah, i se 13:16
see*
hoelzro "Clear any C stack temporaries that code may have pushed before throwing" 13:18
that sounds kind of like mortals in the perl 5 interpreter
timotimo well, when push comes to throw it's the only thing we can do 13:19
hoelzro is there no way for a C function to clean up if a MoarVM exception is being thrown? 13:20
jnthn C stack temporaries are about GC rooting fwiw
hoelzro ahhhh
jnthn It's that the MVMROOT thingy pushes too
13:29 vendethiel joined
brrt hmm 13:38
curious 13:41
13:58 vendethiel joined, zakharyas joined 14:03 FROGGS joined
brrt aaarggh 14:20
ok, interesting lesson
if you try and read an operand too many, you'll have an interesting experience 14:22
jnthn ;) 14:25
brrt hmm 14:33
ok, a bit of an issue here
inc_i says about itself that it has a write operand 14:34
for ... what i assumed to be reasonable reasons, i don't pre-load write operands
jnthn It's kinda a rw one
brrt this means that inc_i will try to link to something that isn't there
jnthn We special case this in a few places...
brrt yes, my question it
would it hurt dearly if i added a rw operand rw type 14:35
*is
btw, sorry to hear about your allergies and medicin problems
jnthn I don't think it'd hurt at all, just be careful with places doing existing checks 14:36
brrt aye
jnthn It's mostly that the pain threshold for the special casing wasn't reached.
brrt that will be another commit, though 14:37
hmm
14:37 colomon joined
brrt i can do special casing too, of course 14:37
i'll just disable inc_i and dec_i for now
dalek arVM/even-moar-jit: 664bb08 | brrt++ | / (7 files):
Use dynamic arrays for the expression tree

For creating an expression tree, I had used a builder. This left the expression tree itself pretty much immutable. That is unsuitable for e.g. constant folding and other optimizations.
Also disable inc_i and dec_i, because these were not handled correctly by the template preprocessor because their operands are rw rather than r.		 14:45
brrt actually rather dislikes refactoring
jnthn Some languages make it more pleasant than others, but code design plays a big part in how easy it is too. 14:46
brrt one refactors usually to make the code more $verb-able, right?
jnthn Sometimes :)
Sometimes it's just to enable another thing you want to do to be more easily possible
brrt hmm
i'd call that 'a refactor because i was wrong' 14:47
which is also ok :-)
anyway, the reason i'm doing all this is really not so much to deal with the expression tree but with the full jit graph
as in, i need the jit graph to be able to make labels, rather than the jit graph builder 14:48
because the jit graph builder is an internal structure which is nobody else's business, and the jit graph itself needs to be used in expression tree building to get labels 14:49
hence, my initial design of building the jit graph was wrong 14:50
15:33 vendethiel joined
hoelzro is that PR I made ok to go, sans the comment before MVM_cu_map_from_file? 15:33
15:49 zakharyas joined 15:55 FROGGS joined 15:59 vendethiel joined 16:08 brrt joined
brrt hoelzro: as far as i can tell, yes 16:09
16:16 synbot6 joined 16:34 vendethiel joined 16:55 brrt joined 17:18 vendethiel joined 17:45 vendethiel joined 17:52 rurban joined
dalek arVM/even-moar-jit: bf46581 | brrt++ | src/jit/ (3 files):
Make the Jit Graph use dynamic arrays

This is a large, but not very exciting change; it implies that the jit graph is now malleable for places that don't have (or are not interested in) the jit graph builder; specifically the jit graph can now add and find labels for itself, which I need for the expression compiler.
It also leaks tiny amounts of memory, which will be fixed in due course.		 18:03
brrt that change was longer overdue than it should've been
note to self 18:25
running spectests twice drains your battery rather fast 18:26
[Coke] r: :10(':16<bad.decaf>') 18:27
camelia rakudo-jvm 3bdd0a: OUTPUT«Unhandled exception: Cannot convert string to number: base-10 number must begin with valid digits or '.' in ':10<⏏:16<bad.decaf>>' (indicated by ⏏)␤ in throw (gen/jvm/CORE.setting:15084)␤ in throw (gen/jvm/CORE.setting:17083)␤ in sink (gen/jvm/…»
..rakudo-moar 3bdd0a: OUTPUT«Unhandled exception: Cannot convert string to number: base-10 number must begin with valid digits or '.' in ':10<⏏:16<bad.decaf>>' (indicated by ⏏)␤ at <unknown>:1 (/home/camelia/rakudo-inst-2/share/perl6/runtime/CORE.setting.moarvm:throw:42949672…»
[Coke] ww
18:34 Ven joined
hoelzro during my code dive last night, I noticed a lot of adhoc exceptions used for things like failure to open a file; is there any interest in having more granular exceptions that Rakudo can make sense of? 18:40
brrt jnthn; we consistently increase the usages for the rw ops based on reg.i - 1 ; whereas we use reg.i for the reading-operands
i think the solution to that would be to catch it in rakudo and rethrow a context-based exception? 18:41
ok, i see why the inc_i style ops have been special-cased 18:43
it's not worth it to generic-case them ^^ 18:48
dalek arVM/even-moar-jit: fc47c38 | brrt++ | src/jit/expr (2 files):
Special-case inc_i and friends

These instructions have read-write operands rather than read operands. Because adding a 'read-write' operand type is rather involved due to the changes in spesh required, and because there are only four such opcodes, I've decided to special-case them here rather than generic-case them throughout the codebase.		 18:51
brrt with that ends tonights entertainment, because i'm going to acquire tea 18:53
18:57 pyrimidine joined 20:30 zakharyas joined 21:27 TEttinger joined 21:36 pyrimidine joined
dalek arVM: eb0c964 | hoelzro++ | src/ (22 files):
Free strings used for exception formats
 22:28

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!