dalek arVM: 45863d1 | jnthn++ | src/core/exceptions.h:
Register some further control exceptions.

Related to upcoming async features in Perl 6.		 02:30
arVM: ec051f5 | jnthn++ | lib/MAST/Nodes.nqp:
Add new control exceptions to MAST::Nodes.
brrt i just had the luminous (i think, and hope) idea of having a 'conditional block' flag 13:41
into the register allocator
that signifies that the values and blocks allocated then are used conditionally, and hence should be cleared together 13:42
you know what i mean?
timotimo i think i understand 13:43
clearing doesn't mean actively nulling, right? just marking as re-usable?
brrt for conditional blocks, its complicated 13:51
do you want the long version?
timotimo only if it helps you advance 13:52
brrt (but yes, invalidation doesn't mean you erase their contents, just mark them as safe to use)
timotimo otherwise i'll likely understand once i get into the finished implementation
brrt basically, registers can be in one of three states
free, allocated, and used
free means there is no node that refers to them 13:53
timotimo mhm
brrt allocated means that they are currently inhabitated (as it were) by the value of a node
i.e. the node is held there
actually, hmmm
no, allocated means that it's safe for the allocator to use it 13:54
hmm
no, my first instinct was correct, but it means i'll need to make adjustments
anyway, used means the register is currently in use by an operation, and cannot be spilled 13:56
timotimo mhm 13:57
brrt an allocated register can be spilled and made free, a used register cannot
must be explicitly released for that to happen
timotimo right 13:58
brrt now i was thinking, what if upon entering a conditional block, i marked it so, so that registers allocated and values calculated within that block can be made 'invisible' upon leaving the block
i.e. have a new 'conditional block' stack, or something like that 13:59
hmm
this thing is becoming mighty complicated already...
timotimo right; i don't think it can be helped very much
brrt anyway, and i probably need to up-propagate register usage counts for that to work out 14:00
possibly during the value selection step (the last tiling step)
brrt so that i can also mark a block as possibly invalidating the whole register set (e.g. during calls) 14:01
timotimo right
brrt which sucks, by the way 14:05
join me in the campaign against function calls
timotimo heh 14:06
let's build an x86 meta-interpretor that figures out what registers are used and what registers aren't
and ... other things 14:07
brrt lol 14:15
no, that's fortunately not necessary :-) 14:16
you know, i had a thought yesterday evening 14:17
in some 10 years or so, installing an AI discriminator / neural network is going to be as easy as installing MySQL is now
isn't that weird? 14:18
timotimo a bit, yeah 14:19
but training would still be a bit of an effort, no?
brrt hmm, probably, but there'll be easy-to-use training wizards, or pre-trained sets 14:21
training, designing and querying a neural network is likely to be a skill as common as relational or object-oriented modelling is today
although, that may take a few more years
people still suck at SQL. but they'll suck at neural nets in mostly the same way, i think 14:22
timotimo possibly 14:23
brrt you know what won't change? the front-end hell :-)
timotimo %)
brrt oh, programmers will talk, and whine, and fight little wars over frameworks and standards and build tools... 14:24
but really? it's still about making things visually appear in a way suitable to our own neural network, trained on fruit picking and predator detection 14:25
timotimo oh yes 14:42
brrt hmmm.... 15:23
can't do nested ALL or ANY i think
that works out really ugly 15:24
dalek arVM/even-moar-jit: b870a79 | brrt++ | src/jit/compile.c:
Mostly implement branching

Except for register/value invalidation, this mostly implements branching, including short-circuiting for ANY/ALL and nested ANY/ALL.		 16:51
brrt nested ANY/ALL should work now
Ven brrt++ !! 16:57
brrt Ven :-) 16:58
Ven++, even
Ven brrt: I'm pretty clueless about the JIT, but I'd love to understand what this means: github.com/MoarVM/MoarVM/commit/b8...f47d18R297 17:00
brrt alright, i can explain that, should be fun 17:01
you know short-circuit evaluation, right?
if (foo() || bar()) only evaluates bar() if foo() was false
basically, WHEN is a unary conditional block node 17:02
i.e. it's equivalent to if (condition) { block; }
(unlike IF and EITHER which are binary, whereby IF yields a value and EITHER does not) 17:03
anyway, to implement short-circuit evaluation for the OR case (called ANY here because it is variadic, e.g. takes multiple arguments)
what you need to do is jump into the block after foo() is true
so far so clear? 17:04
(and you need to jump beyond the block if you reach the end with bar() being false) 17:06
well, that's kind of the logic that determines these things 17:10
Ven re-reads another time 17:13
brrt :-)
Ven yes, that's clear 17:14
the only part i don't seem to get is the "if/either" being binary
brrt oh, that's just an IR tree design decision
Ven and what does it entails? 17:15
brrt basically, nodes should best have a fixed number of children, to deal with more easily
Ven oh, you mean if has some kind of "tails" node
that's there for the "else" part?
brrt yes, the IF node has two alternatives (the 'true' and 'false' blocks), and WHEN only has a 'true' block 17:16
obviously WHEN cannot yield a value 17:17
Ven alright, I think I got it :)
thanks. brrt++ # jitting my brain
brrt ok great :-)
if you have any more questions, be sure to ask

Powered by Cro and the Raku® Programming Language.

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

Thank you!