Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-07-28

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:47 ilbot3 joined #moarvm
01:47 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
02:23 vendethiel joined #moarvm
04:54 pyrimidine joined #moarvm
06:36 FROGGS joined #moarvm
06:41 zakharyas joined #moarvm
07:04 Ven joined #moarvm
07:18 brrt joined #moarvm
07:54 rurban_ joined #moarvm
08:26 Ven joined #moarvm
08:40 vendethiel joined #moarvm
09:09 brrt joined #moarvm
09:10 donaldh joined #moarvm
09:10 brrt many algorithms, such complexity
09:11 FROGGS :o)
09:18 vendethiel joined #moarvm
09:25 jnthn So long as the complexity is polynomial...
09:28 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
09:29 jnthn o/ FROGGS
09:29 jnthn How's things?
09:30 FROGGS jnthn: good... I even plan do be active again here :o)
09:31 FROGGS 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:32 jnthn Well, a break now and then can be good :)
09:32 jnthn Will be glad to see commits from you again :)
09:32 FROGGS :o)
09:33 FROGGS will bug you about frame handlers anytime soon
09:34 jnthn :)
09:35 jnthn teaching today/tomorrow, then will be doing lots and lots of Perl 6 from Thu :)
09:37 brrt jnthn: some polynomial is just a bit much, though
09:38 jnthn .oO( Did Parrot's optimizer run in pollynomial time? )
09:39 nwc10 I think that it was O(0) at runtime, which is hard to beat.
09:39 nwc10 (assuming you had compiled PIR or PASM to PBC, ahead of time)
09:41 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
09:49 brrt hmmm
09:49 brrt i'm doing it wrong
09:50 Ven joined #moarvm
09:51 timotimo polly no meal
10:20 zakharyas1 joined #moarvm
10:47 brrt hah!
10:47 brrt topological sort, again, saves the day
11:03 brrt dalek dead?
11:04 nwc10 10:39 -!- dalek [~dalekbot@2001:780:101:ff00::2:9] has quit [Ping timeout: 244 seconds]
11:04 nwc10 not flooding, either
11:04 brrt i think moritz++ said something about infrastructure changes on #perl6
11:05 brrt so, maybe just that
11:05 brrt anyway, topological sort saveth the day, as i said
11:06 brrt 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 brrt most combinations of rules are *never generated*
11:07 brrt hence, if one writes an O(n^3) algorithm, one is keenly interested in keeping n pretty small
11:07 brrt n can be kept small by figuring out which combinations the grammar *can* generate
11:07 brrt how did i solve this? by letting the grammar... generate them
11:08 brrt how to solve the chicken-and-egg problem that obviously arises from this? topological sort
11:16 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
11:16 brrt on holiday?
11:17 * brrt doesn't use infrastructure
11:17 moritz brrt: yes, Norway
11:17 brrt ah, very nice i imagine
11:17 brrt i... should probably go on holiday, too, some day
11:18 Ven joined #moarvm
11:39 Ven joined #moarvm
11:45 zakharyas joined #moarvm
11:50 colomon joined #moarvm
12:05 colomon_ joined #moarvm
13:22 dalek joined #moarvm
13:26 Util joined #moarvm
13:33 Ven joined #moarvm
13:33 ggoebel joined #moarvm
13:42 [Coke] joined #moarvm
13:50 dalek MoarVM/even-moar-jit: 4c14a58 | brrt++ | tools/tiler-table-generator.pl:
13:50 dalek MoarVM/even-moar-jit: Read expr tree IR ops order
13:50 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/4c14a58b6d
13:50 dalek MoarVM/even-moar-jit: 9519dfe | brrt++ | / (6 files):
13:50 dalek MoarVM/even-moar-jit: Generate a tiler table
13:50 dalek MoarVM/even-moar-jit:
13:50 dalek MoarVM/even-moar-jit: Next up: rule table; then; search algorithm.
13:50 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/9519dfecf7
13:50 brrt hey, dalek lives again
14:14 Ven joined #moarvm
14:23 brrt joined #moarvm
14:45 brrt and, it's dead
14:48 dalek MoarVM/even-moar-jit: f2b49e1 | brrt++ | / (2 files):
14:48 dalek MoarVM/even-moar-jit: Add tiler rule output table
14:48 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/f2b49e12f8
14:49 brrt not sure if i've just solved one of the harder, or one of the easier problems
15:10 dalek MoarVM/even-moar-jit: 5f6c196 | brrt++ | / (2 files):
15:10 dalek MoarVM/even-moar-jit: Add binary search function to find tile table items
15:10 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/5f6c19653d
16:09 TEttinger joined #moarvm
16:32 timotimo oooh
16:32 timotimo things are moving forward
16:46 hoelzro_ii joined #moarvm
16:47 Ven_ joined #moarvm
16:55 dalek joined #moarvm
17:38 Ven_ joined #moarvm
18:05 brrt joined #moarvm
18:09 brrt \o
18:10 nwc10 o/
18:12 brrt i'm currently writing a blog post
18:23 hoelzro_ii joined #moarvm
19:04 brrt joined #moarvm
19:04 colomon joined #moarvm
19:10 zakharyas joined #moarvm
19:14 colomon_ joined #moarvm
19:17 colomon joined #moarvm
19:23 rurban_ joined #moarvm
19:26 timotimo cool
19:30 colomon_ joined #moarvm
19:35 colomon_ joined #moarvm
19:57 FROGGS joined #moarvm
20:01 [Coke] "GOOD THINGS ARE HAPPENING"
20:15 jnthn omg GOOD THINGS?!?!
20:17 [Coke] oh, not to me, I was referring to timotimo's send earlier. :)
20:19 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:20 FROGGS 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
20:20 FROGGS how are we going to handle leave control exceptions for frames, which don't have frame handlers?
20:21 FROGGS I guess I could special case that exception type...
20:21 FROGGS and then, can I do what return_* does still?
20:22 jnthn I don't get the "which don't have frame handlers" bit
20:22 jnthn I mean, that's not a MoarVM level thing, that's just that the QAST node has no nqp::handle anywhere in it
20:22 FROGGS aye
20:22 FROGGS and these frame get skipped in exception.c
20:23 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
20:23 FROGGS ahh
20:23 jnthn Well, if it's got no handlers it can't possibly be a target for an exception?
20:23 FROGGS well... :o)
20:24 FROGGS I though about adding LEAVE handlers, but isnt that overkill?
20:24 FROGGS but anyway, I think I can try things now again
20:29 jnthn Handlers don't cost anything much (other than a little memory to store them)
20:30 jnthn Well, that's a lie. :)
20:30 jnthn They have some JIT costs I guess
21:07 jnthn In today's "JIT and optimization is really hard": http://nickcraver.com/blog/2015/07/27/why-you-should-wait-on-dotnet-46/
21:12 brrt joined #moarvm
21:35 lizmat jnthn: S17:940 states "C<Lock> is reentrant."
21:35 lizmat maybe we should elaborate on the reentrancy semantics ?
21:38 brrt what... could we elaborate on
21:39 * 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:40 lizmat well. more specifically on the semantics of $lock.protect({  $lock.protect({ ... }); ... });
21:41 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({ ... }) }; ... });
21:41 brrt ah, that one probably should deadlock
21:41 lizmat should it?
21:41 brrt yes, start starts work on another thread, doesn't it?
21:42 * brrt checks out the concurrency docs
21:42 lizmat perhaps, having it in a protected piece of code maybe shouldn't ?
21:42 lizmat I mean, there are plenty of ways this could / should work  :-)
21:44 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
21:45 brrt it... is, in some sense
21:45 brrt well
21:45 brrt wait
21:45 brrt hmm
21:45 brrt ok, let me correct that
21:45 lizmat .oO( an idiot can ask more questions than all the wise people can answer :-)
21:46 brrt that piece of code would deadlock if the start is awaited within the lock protect block, not otherwise
21:46 brrt and i refuse to see it otherwise :-)
21:46 brrt but i'm going to sleep :-)
21:46 brrt see you!
21:47 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 timotimo 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
21:47 timotimo in which case - by sheer luck! - the lock would be re-entered rather than deadlocked with
21:49 lizmat we possibly could easily make this work by changing $*SCHEDULER to CurrentThreadScheduler for the $lock.protect scope
21:50 lizmat 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 #moarvm
21:51 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
21:51 lizmat it's just that maybe in the future, .cueing code would be as simple as doing >>.foo
21:51 timotimo i don't think we can decide that for the user, but i don't really know about all use cases :)

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary