01:47 ilbot3 joined 02:23 vendethiel joined 04:54 pyrimidine joined 06:36 FROGGS joined 06:41 zakharyas joined 07:04 Ven joined 07:18 brrt joined 07:54 rurban_ joined 08:26 Ven joined 08:40 vendethiel joined 09:09 brrt joined 09:10 donaldh joined
brrt many algorithms, such complexity 09:10
FROGGS :o) 09:11
09:18 vendethiel joined
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
09:50 Ven joined
timotimo polly no meal 09:51
10:20 zakharyas1 joined
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
11:18 Ven joined 11:39 Ven joined 11:45 zakharyas joined 11:50 colomon joined 12:05 colomon_ joined 13:22 dalek joined 13:26 Util joined 13:33 Ven joined, ggoebel joined 13:42 [Coke] joined
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
14:14 Ven joined 14:23 brrt joined
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
16:09 TEttinger joined
timotimo oooh 16:32
things are moving forward
16:46 hoelzro_ii joined 16:47 Ven_ joined 16:55 dalek joined 17:38 Ven_ joined 18:05 brrt joined
brrt \o 18:09
nwc10 o/ 18:10
brrt i'm currently writing a blog post 18:12
18:23 hoelzro_ii joined 19:04 brrt joined, colomon joined 19:10 zakharyas joined 19:14 colomon_ joined 19:17 colomon joined 19:23 rurban_ joined
timotimo cool 19:26
19:30 colomon_ joined 19:35 colomon_ joined 19:57 FROGGS joined
[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
21:12 brrt joined
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
21:50 harrow joined
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!