brrt many algorithms, such complexity 09:10
FROGGS :o) 09:11
jnthn So long as the complexity is polynomial... 09:25
FROGGS hi jnthn 09:28
timotimo we can still have a exponential algorithm that finds the absolutely perfect answer, but runs in a background thread once something is *really* hot
jnthn o/ FROGGS 09:29
How's things?
FROGGS jnthn: good... I even plan do be active again here :o) 09:30
dunno why I wasnt the last days/week(s)... I guess too much dayjob and a pet project is enough to fill my spare time 09:31
jnthn Well, a break now and then can be good :) 09:32
Will be glad to see commits from you again :)
FROGGS :o)
will bug you about frame handlers anytime soon 09:33
jnthn :) 09:34
teaching today/tomorrow, then will be doing lots and lots of Perl 6 from Thu :) 09:35
brrt jnthn: some polynomial is just a bit much, though 09:37
jnthn
.oO( Did Parrot's optimizer run in pollynomial time? )
 09:38
nwc10 I think that it was O(0) at runtime, which is hard to beat. 09:39
(assuming you had compiled PIR or PASM to PBC, ahead of time)
brrt o.O :-) 09:41
jnthn Sure, just like drinking water is hard to beat, 'cus you don't have to spend energy opening a beer bottle :P
brrt hmmm 09:49
i'm doing it wrong
timotimo polly no meal 09:51
brrt hah! 10:47
topological sort, again, saves the day
dalek dead? 11:03
nwc10 10:39 -!- dalek [~dalekbot@2001:780:101:ff00::2:9] has quit [Ping timeout: 244 seconds] 11:04
not flooding, either
brrt i think moritz++ said something about infrastructure changes on #perl6
so, maybe just that 11:05
anyway, topological sort saveth the day, as i said
what was the problem, you ask? well, naively generating all combinations-of-rules starting with a given head generated an explosively large table, which had to be pruned afterwards 11:06
most combinations of rules are *never generated*
hence, if one writes an O(n^3) algorithm, one is keenly interested in keeping n pretty small 11:07
n can be kept small by figuring out which combinations the grammar *can* generate
how did i solve this? by letting the grammar... generate them
how to solve the chicken-and-egg problem that obviously arises from this? topological sort 11:08
moritz brrt: no, I said something about being absent in August, and that infrastructure permissions should be settled before that 11:16
brrt ah, ok
on holiday?
brrt doesn't use infrastructure 11:17
moritz brrt: yes, Norway
brrt ah, very nice i imagine
i... should probably go on holiday, too, some day
dalek arVM/even-moar-jit: 4c14a58 | brrt++ | tools/tiler-table-generator.pl:
Read expr tree IR ops order
 13:50
arVM/even-moar-jit: 9519dfe | brrt++ | / (6 files):
Generate a tiler table

Next up: rule table; then; search algorithm.
brrt hey, dalek lives again
brrt and, it's dead 14:45
dalek arVM/even-moar-jit: f2b49e1 | brrt++ | / (2 files):
Add tiler rule output table
 14:48
brrt not sure if i've just solved one of the harder, or one of the easier problems 14:49
dalek arVM/even-moar-jit: 5f6c196 | brrt++ | / (2 files):
Add binary search function to find tile table items
 15:10
timotimo oooh 16:32
things are moving forward
brrt \o 18:09
nwc10 o/ 18:10
brrt i'm currently writing a blog post 18:12
timotimo cool 19:26
[Coke] "GOOD THINGS ARE HAPPENING" 20:01
jnthn omg GOOD THINGS?!?! 20:15
[Coke] oh, not to me, I was referring to timotimo's send earlier. :) 20:17
FROGGS jnthn: do you remember me working on leave()? the point I stopped working at it I figured out that common blocks don't have frame handlers associated... 20:19
jnthn: you said something along the lines of a possible solution, but I did not get it... 20:20
jnthn Well, I finished writing a course between then and now, so I've forgotten it now too :P
FROGGS how are we going to handle leave control exceptions for frames, which don't have frame handlers?
I guess I could special case that exception type... 20:21
and then, can I do what return_* does still?
jnthn I don't get the "which don't have frame handlers" bit 20:22
I mean, that's not a MoarVM level thing, that's just that the QAST node has no nqp::handle anywhere in it
FROGGS aye
and these frame get skipped in exception.c
jnthn But if we're using the exception system for leave, then we should probably just emit every Perl 6 frame with a LEAVE handler... 20:23
FROGGS so we do not even try to check if this frame might be a target for an exception
ahh
jnthn Well, if it's got no handlers it can't possibly be a target for an exception?
FROGGS well... :o)
I though about adding LEAVE handlers, but isnt that overkill? 20:24
but anyway, I think I can try things now again
jnthn Handlers don't cost anything much (other than a little memory to store them) 20:29
Well, that's a lie. :) 20:30
They have some JIT costs I guess
In today's "JIT and optimization is really hard": nickcraver.com/blog/2015/07/27/why-...dotnet-46/ 21:07
lizmat jnthn: S17:940 states "C<Lock> is reentrant." 21:35
maybe we should elaborate on the reentrancy semantics ?
brrt what... could we elaborate on 21:38
brrt is wondering whether it is worth it to add an 'addressification' optimization step, that allows the tiler to match (load mem) consistently, thereby reducing grammar size because (load reg) disappears 21:39
lizmat well. more specifically on the semantics of $lock.protect({ $lock.protect({ ... }); ... }); 21:40
brrt would seem that a reentrant lock allows the second lock to proceed as if nothing happens; a non-reentrant lock would deadlock 21:41
lizmat and perhaps $lock.protect({ start { $lock.protect({ ... }) }; ... });
brrt ah, that one probably should deadlock
lizmat should it?
brrt yes, start starts work on another thread, doesn't it?
brrt checks out the concurrency docs 21:42
lizmat perhaps, having it in a protected piece of code maybe shouldn't ?
I mean, there are plenty of ways this could / should work :-)
brrt the scheduler must then know about lock scope 21:44
timotimo hm, right, if you start { ... } inside a llock.protect, the inside of the start block isn't protected any more
brrt it... is, in some sense 21:45
well
wait
hmm
ok, let me correct that
lizmat
.oO( an idiot can ask more questions than all the wise people can answer :-)
brrt that piece of code would deadlock if the start is awaited within the lock protect block, not otherwise 21:46
and i refuse to see it otherwise :-)
but i'm going to sleep :-)
see you!
timotimo hm, right, if the "outer" piece of code awaits the start block and the inside of the start block hopes for the lock to free up, then we'll reach a deadlock situation 21:47
we're not at the point yet where the await would cause the work to be run on the same thread if it's awaited
in which case - by sheer luck! - the lock would be re-entered rather than deadlocked with
lizmat we possibly could easily make this work by changing $*SCHEDULER to CurrentThreadScheduler for the $lock.protect scope 21:49
and add a :scheduler param to Lock.protect to override if you really know what you're doing 21:50
timotimo well, the problem only occurs if you actually lock on that same lock inside the start'd block
lizmat anyways, this way surely lies madness 21:51
timotimo i'm not sure we really want to set CTS for every lock-protected piece of code
lizmat it's just that maybe in the future, .cueing code would be as simple as doing >>.foo
timotimo i don't think we can decide that for the user, but i don't really know about all use cases :)

Powered by Cro and the Raku® Programming Language.

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

Thank you!