Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6-dev, 2016-08-03

| Channels | #perl6-dev index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:18 TimToady but my timings are just all over the map right now, so I dunno what to think
00:19 TimToady with the "correct" fix I get the fastest times sometimes, and also the slowest :/
00:19 TimToady I think there's just too much noise in my setup here to determine the hit
00:20 TimToady so ignore my earlier 7%, that was just noise
00:23 dalek nqp: e0e113d | TimToady++ | src/QRegex/Cursor.nqp:
00:23 dalek nqp: add $*SUPPOSING dynvar to mark conjectural parsing
00:23 dalek nqp:
00:23 dalek nqp: This dynvar is set inside <?before> and <?after> so that action methods can
00:23 dalek nqp: decide whether to do permanent side effects outside the AST.
00:23 dalek nqp: review: https://github.com/perl6/nqp/commit/e0e113dcbf
00:33 Zoffix joined #perl6-dev
00:39 dalek rakudo/nom: 9c7b3c1 | TimToady++ | src/Perl6/Actions.nqp:
00:39 dalek rakudo/nom: don't create thunk refs inside a <?before>
00:39 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/9c7b3c1f47
00:39 dalek rakudo/nom: 6183a57 | TimToady++ | tools/build/NQP_REVISION:
00:39 dalek rakudo/nom: bump NQP to get $*SUPPOSING set in <?before>
00:39 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/6183a57a0e
00:49 TimToady I think I proved to myself that it's not a major performance hit; at least, the best times didn't get worse when I measured repeatedly, though the average times were all over the map
00:50 TimToady hopefully the map is not the territory...
01:13 mst Zoffix: \o/
01:17 Zoffix :)
01:26 ShimmerFairy joined #perl6-dev
01:31 jdv79 what did zoffix do now?
01:38 Zoffix jdv79, I quit drinking!
01:39 Zoffix Just now... like 3 seconds ago... I ran out of beer :P
01:39 jdv79 better head out fore the shops closr!
01:41 jdv79 methinks you'll quit drinking bout when i do;  when we expire.
01:46 Zoffix Nah, I'm quitting again :)
01:46 jdv79 :)
01:46 jdv79 ok
01:46 Zoffix I didn't drink for 89 days and today I did and it sucked. I couldn't write code and couldn't practice my guitar. Waste of a day. Quitting is good.
01:46 jdv79 3 months?  wow.  thats crazy.
01:46 jdv79 moderation++
01:46 TimToady Zoffix++
01:48 ilbot3 joined #perl6-dev
01:48 Topic for #perl6-dev is now Perl 6 language and compiler development 2.0 | Logs at http://irclog.perlgeek.de/perl6-dev/today
08:13 RabidGravy joined #perl6-dev
08:56 nine TimToady: I run "cpupower frequency-set -g performance" before doing any kind of benchmark. Reduces the noise a lot.
08:59 [Sno] joined #perl6-dev
08:59 psch j: A: for ^1 { for ^1 { last A } } # vOv
08:59 sno joined #perl6-dev
08:59 camelia rakudo-jvm cd19db: ( no output )
08:59 psch i am by now sure that the problem is kind of "we don't generate different handlers for nested looping blocks of the same kind"
09:00 psch j: A: for ^1 { B: while True { last A } }
09:00 camelia rakudo-jvm cd19db: ( no output )
09:00 psch which seems to mean "a given nqp::handle call always generates code exactly once"
09:01 psch or we have some kind of weird lexical shadowing with the Labels maybe..?
09:10 jnthn Morning, #perl6-dev
09:12 psch o/ jnthn
09:16 jnthn All nqp:: ops generate code exactly once, no? :)
09:16 psch well, yes.  but the issue seems to be that handle doesn't seem to care if the arguments change
09:17 jnthn o.O
09:17 jnthn That would be odd
09:17 psch and, well, it happens when the same code path leading to the same nqp::handle invocation is executed
09:17 jnthn iirc there's some "compile code in the context of a handler" stuff
09:17 jnthn May be worth checking that is happening consistently
09:17 psch yeah, i saw that bit
09:18 psch well, skimmed over it :)
09:19 psch but that's the most sensible explanation i've found for what's happening
09:19 psch j: A: for ^1 { B: for ^2 -> $, $ { last A } } # different nqp::handle calls in Any-iterable-methods.pm, works
09:19 camelia rakudo-jvm cd19db: ( no output )
09:19 psch 'cause 1ary and 2ary blocks in sequential map use different instantiations of SlippyIterator
09:20 psch labeled and not labeled also works
09:20 psch but any given identical two doesn't work
09:20 psch what i've seen from debug output is that two different ones generate more handlers
09:20 psch and the missing one in the case of identical ones is the one with the lower handler id
09:23 psch the debug output is injected into the InstructionList which surrounds the handler block, so it should get called even if we don't enter the handler afaict..?
09:24 jnthn I'd think so
09:38 Woodi joined #perl6-dev
09:46 Tux__ This is Rakudo version 2016.07.1-110-g6183a57 built on MoarVM version 2016.07-13-gcba3ae3
09:46 Tux__ test            15.271
09:46 Tux__ test-t           8.207
09:46 Tux__ csv-parser      16.983
10:06 jnthn lizmat: About? :)
10:19 dalek rakudo/supply-circular-wait-fix: 5f1249e | jnthn++ | src/core/Supply.pm:
10:19 dalek rakudo/supply-circular-wait-fix: Eliminate locking in favor of a work queue.
10:19 dalek rakudo/supply-circular-wait-fix:
10:19 dalek rakudo/supply-circular-wait-fix: The approach taken so far is vulnerable to deadlock, since there can
10:19 dalek rakudo/supply-circular-wait-fix: be unfortunate timing interactions between the up-stream management
10:19 dalek rakudo/supply-circular-wait-fix: of the subscription and downstream flow of values. This changes puts
10:19 dalek rakudo/supply-circular-wait-fix: a work queue in place instead, which successfully avoids the deadlock
10:19 dalek rakudo/supply-circular-wait-fix: and in theory should give lower overhead, less blocked threads, and
10:19 dalek rakudo/supply-circular-wait-fix: hopefully better CPU cache behavior. Regresses a couple of tests,
10:19 dalek rakudo/supply-circular-wait-fix: however.
10:19 dalek rakudo/supply-circular-wait-fix: review: https://github.com/rakudo/rakudo/commit/5f1249e843
10:19 dalek rakudo/supply-circular-wait-fix: 5e61516 | jnthn++ | src/Perl6/Actions.nqp:
10:19 dalek rakudo/supply-circular-wait-fix: Fix a scoping bug with blockless phasers.
10:19 dalek rakudo/supply-circular-wait-fix:
10:27 dalek rakudo/nom: 5f1249e | jnthn++ | src/core/Supply.pm:
10:27 dalek rakudo/nom: Eliminate locking in favor of a work queue.
10:27 dalek rakudo/nom:
10:27 dalek rakudo/nom: The approach taken so far is vulnerable to deadlock, since there can
10:27 dalek rakudo/nom: be unfortunate timing interactions between the up-stream management
10:27 jnthn lizmat: Could you glance https://github.com/rakudo/rakudo/commit/88f6f8491027baf4fbab89686da0c5354a269268 and https://github.com/rakudo/rakudo/commit/02ee790d4243eb95b4aeb7ace57dde6818d3ea31 if you get chance, to see if they make sense to you? :)
10:28 dalek joined #perl6-dev
10:36 * lizmat looks
10:39 lizmat jnthn: looking back there at code I did ~ a year ago, pre last Supply refactor, it makes sense I think
10:40 lizmat although I must admit I'm not quite awake just yet
10:40 jnthn OK :)
10:40 jnthn It passes all the tests, anyways.
10:40 jnthn The branch I merged fixes a nasty circular wait that could occasionally cause deadlocks for programs using the supply/whenever syntax.
10:40 jnthn Which was to blame for some spectest hangs.
10:43 psch huh.  we get a BOOTStr for :$label in sequential-map..?
10:43 psch that seems wrong
10:44 dalek roast: ea70ef3 | jnthn++ | S17-lowlevel/semaphore.t:
10:44 dalek roast: Add tests for Semaphore.
10:44 dalek roast:
10:44 dalek roast: Which we seem to have missed entirely so far. These also cover the
10:44 dalek roast: Semaphore hangs reported in RT #128628.
10:44 dalek roast: review: https://github.com/perl6/roast/commit/ea70ef329c
10:44 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=128628
10:48 dalek roast: 1c28d3a | lizmat++ | S04-phasers/in-loop.t:
10:48 dalek roast: Unfudge now passing test
10:48 dalek roast: review: https://github.com/perl6/roast/commit/1c28d3ac41
10:54 dalek rakudo/nom: 942a696 | jnthn++ | t/spectest.data:
10:54 dalek rakudo/nom: Run new semaphore tests.
10:54 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/942a69686e
10:58 dalek roast: 9287f32 | lizmat++ | integration/advent2012-day15.t:
10:58 dalek roast: Unfudge another passing test
10:58 dalek roast: review: https://github.com/perl6/roast/commit/9287f3249f
11:01 jnthn lizmat: You taking care of the RT that goes with that test too? :)
11:01 lizmat jnthn: I don't do RT really, I've come to hate the interface intensely
11:03 lizmat I've sent mails
11:03 jnthn ah, OK...guess I can mark it resolved
11:04 lizmat I've sent mails to both RT's that they can be closed
11:04 lizmat jnthn++  # nudging me  :-)
11:05 moritz ... ticket resolved
11:05 jnthn Ah, thanks :)
11:05 * jnthn was just writing up a resolution of another one :)
11:10 jnthn Done. And lunch. :) bbiab
11:37 * jnthn back
11:51 masak short lunch :)
11:53 jnthn aye
11:53 jnthn Clearly I'm racing to fix these bugs :P
11:55 masak far be it from me to discourage you from fixing bugs quickly :P
12:13 dalek roast: 4fdee95 | LLFourn++ | S32-exceptions/misc.t:
12:13 dalek roast: Tests for RT #128770 128766
12:13 dalek roast:
12:13 dalek roast: checks two instances of useless "useless use of blash in sink context"
12:13 dalek roast: review: https://github.com/perl6/roast/commit/4fdee95e24
12:13 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=128770
12:22 unmatched} lizmat: what do you hate about RT's interface?
12:23 [Coke] lizmat, jnthn, I am happy to do RT cleanup for you folks.
12:29 * [Coke] yawns.
12:29 lizmat unmatched}: its interface & the difficulty of logging in
12:29 lizmat In the past I've been able to, but somehow I can't anymore, and I can't be bothered to spend more time on it
12:30 lizmat so I use my mail program to respond to tickets, and that works for me
12:31 [Coke] lizmat: the rt bug admins are responsive if you want to try opening a ticket with them; but like I said, happy to help you two out.
12:31 lizmat [Coke]++   # thank you!
12:31 jnthn [Coke]: fwiw, I've no problems working with RT...only didn't get to it 'cus I was doing something else. :)
12:31 unmatched} I see. Personally, I abhor the search interface. Currently working on an RT ticket viewing web app, but so far I plan to make it read-only
12:31 jnthn [Coke]++ # thanks, though! :)
12:32 masak [Coke]++ # also responsive
12:36 [Coke] ++zoffix for a newer search.
13:26 skids joined #perl6-dev
14:20 jnthn https://gist.github.com/jnthn/ec19c88a592c44684ffafb41953ad25a
14:20 jnthn ^^ is a write-up of a Supply race issue that I've written up.
14:20 jnthn Any input welcome. :)
14:21 * lizmat has taken her own advice: http://act.yapc.eu/alpineperl2016/talk/6868
14:21 lizmat anybody else here wants to submit a Perl 6 presentation for the Alpine Perl Workshop ?
14:30 dalek nqp: 3d8fe9f | jnthn++ | tools/build/MOAR_REVISION:
14:30 dalek nqp: Get a couple of MoarVM I/O fixes.
14:30 dalek nqp: review: https://github.com/perl6/nqp/commit/3d8fe9f4d5
14:31 dalek rakudo/nom: ed9cbb2 | jnthn++ | src/core/Supply.pm:
14:31 dalek rakudo/nom: Correct comment on Supply grammar.
14:31 dalek rakudo/nom:
14:31 dalek rakudo/nom: In the event of a supply being closed by the consumer, it may not
14:31 dalek rakudo/nom: produce a done or quit event.
14:31 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/ed9cbb28ef
14:31 dalek rakudo/nom: 171307b | jnthn++ | tools/build/NQP_REVISION:
14:31 dalek rakudo/nom: Bump for some MoarVM I/O fixes.
14:31 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/171307b469
14:32 dalek roast: c900158 | jnthn++ | S32-io/IO-Socket-Async.t:
14:32 dalek roast: Test to cover missing "address in use" error bug.
14:32 dalek roast: review: https://github.com/perl6/roast/commit/c900158107
14:33 dalek roast: 2103b87 | (LE Manh Cuong)++ | S16-io/eof.t:
14:33 dalek roast: Reading /proc files line by line does not go into infinitive loop
14:33 dalek roast:
14:33 dalek roast: RT #127370
14:33 dalek roast: review: https://github.com/perl6/roast/commit/2103b87cbb
14:33 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=127370
14:33 dalek roast: 207e611 | jnthn++ | S16-io/eof.t:
14:33 dalek roast: Merge pull request #137 from Gnouc/master
14:33 dalek roast:
14:33 dalek roast: Reading /proc files line by line does not go into infinitive loop
14:33 dalek roast: review: https://github.com/perl6/roast/commit/207e61126b
14:43 dalek rakudo/nom: d97e093 | jnthn++ | t/spectest.data:
14:43 dalek rakudo/nom: Run S16-io/eof.t.
14:43 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/d97e0938a8
14:44 jnthn Break; bbl
15:31 unmatched} aw crap. Looks like in my last three releases I left off some people from "These people contributed to this release" because the contributors script assumes the person running it has `doc` repo checked out in ../doc
15:32 unmatched} And ../MoarVM ../nqp ../roast, but I guess those are counted in nqp nqp/MoarVM t/spec
15:40 [Coke] unmatched}: I have never had doc checked out there, so it's not just you
15:42 unmatched} now I feel less bad, thanks :)
15:44 lizmat guess that was just me  :-(
15:44 lizmat so where should it be checkout then ?
15:45 unmatched} I actually do have `doc` checked out there on one of my boxes, but I don't release there :D
15:45 dalek rakudo/nom: 0513393 | (Zoffix Znet)++ | tools/contributors.pl6:
15:45 dalek rakudo/nom: Improve tools/contributors.pl6
15:45 dalek rakudo/nom:
15:45 dalek rakudo/nom: - Abort if expected repository location is missing
15:45 dalek rakudo/nom:     - Remove duplicate repository locations as those are present in
15:45 dalek rakudo/nom:       the rakudo repo build.
15:45 dalek rakudo/nom: - note() a message alerting the user of expected repo locations and
15:45 dalek rakudo/nom: remind them to ensure those repos have all the latest changes.
15:45 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/05133931a9
15:45 unmatched} I think ../doc is fine, as long as the person running it knows it needs to be there.
16:17 jnthn https://rt.perl.org/Ticket/Display.html?id=128809 is impressively explosive...
16:28 jnthn TimToady: Do you think a start block should declare its own $/ and $!, rather like a Routine does?
16:29 jnthn The issue in that RT is half because of over-sharing of those (and half because of a thunk/closure problem)
16:36 TimToady one could almost argue that nothing outside a start should be visible by default
16:37 TimToady so I'd be fine with that
16:37 jnthn OK :)
16:37 timotimo will we get a lambda syntax like c++ has?
16:37 jnthn The thunky one will be harder to fix...
16:39 TimToady timotimo: we don't generally turn to C++ for syntactic advice...
16:39 timotimo gee, i wonder why that is
16:42 jnthn Let's see what spectest makes of the $/ and $! per start thing
16:42 timotimo and if you want lexicals to be shared, you use "shart" instead of "start"
16:43 jnthn .oO( Is that from C++ too? :P )
16:44 jnthn m: say await map { start { my $foo = "barbaz"; $foo ~~ s/(.).+/$0/; $foo } }, ^100;
16:44 camelia rakudo-moar 051339: OUTPUT«Memory allocation failed; could not allocate 4 bytes␤»
16:44 jnthn m: say await map { start { my $foo = "barbaz"; $foo ~~ s/(.).+/$0/; $foo } }, ^100;
16:44 camelia rakudo-moar 051339: OUTPUT«Memory allocation failed; could not allocate 4 bytes␤»
16:44 jnthn hmm
16:45 jnthn Oh, is that the camelia memory limit thing maybe...
16:46 jnthn m: PROCESS::<$SCHEDULER> = ThreadPoolScheduler.new(initial_threads => 0, max_threads => 2); say await map { start { my $foo = "barbaz"; $foo ~~ s/(.).+/$0/; $foo } }, ^100;
16:46 camelia rakudo-moar 051339: OUTPUT«(b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b)␤»
16:48 jnthn m: PROCESS::<$SCHEDULER> = ThreadPoolScheduler.new(initial_threads => 0, max_threads => 2); say [+] await map -> $n { start { my $foo = "barbaz" x $n; $foo ~~ s/.+/$/.chars()/; $foo } }, ^100;
16:48 camelia rakudo-moar 051339: OUTPUT«Use of Nil in string context  in code  at <tmp> line 1␤Use of Nil in string context  in code  at <tmp> line 1␤29472␤»
16:48 jnthn m: PROCESS::<$SCHEDULER> = ThreadPoolScheduler.new(initial_threads => 0, max_threads => 2); say [+] await map -> $n { start { my $foo = "barbaz" x $n; $foo ~~ s/.+/$/.chars()/; $foo } }, ^100;
16:48 camelia rakudo-moar 051339: OUTPUT«Use of Nil in string context  in code  at <tmp> line 1␤Use of Nil in string context  in code  at <tmp> line 1␤28788␤»
16:48 jnthn The patch fixes that case at least :)
16:49 jnthn And spectest passes :)
16:50 timotimo i've seen this error a looooooong time ago in productive code
16:58 dalek rakudo/nom: f32173b | lizmat++ | src/core/Array.pm:
16:58 dalek rakudo/nom: Make Array.splice($offset) about 40x faster
16:58 dalek rakudo/nom:
16:58 dalek rakudo/nom: - for a 10 element array and offset 5
16:58 dalek rakudo/nom: - rewritten using nqp ops
16:58 dalek rakudo/nom: - more candidates
16:58 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/f32173b2ca
16:59 lizmat afk&
16:59 jnthn m: use Test; { my $/; isnt await(start { $/ }), 42, 'Get a fresh $/ inside of a start block'; }
16:59 camelia rakudo-moar 051339: OUTPUT«ok 1 - Get a fresh $/ inside of a start block␤»
16:59 jnthn m: use Test; { my $/ = 42; isnt await(start { $/ }), 42, 'Get a fresh $/ inside of a start block'; }
16:59 camelia rakudo-moar 051339: OUTPUT«not ok 1 - Get a fresh $/ inside of a start block␤␤# Failed test 'Get a fresh $/ inside of a start block'␤# at <tmp> line 1␤# twice: '42'␤»
17:01 jnthn m: use Test; { my $ex = Exception.new; my $! = $ex; isnt await(start { $! }), $ex }
17:01 camelia rakudo-moar 051339: OUTPUT«not ok 1 - ␤␤# Failed test at <tmp> line 1␤# twice: 'Something went wrong in (Exception)'␤»
17:03 dalek rakudo/nom: 08e39ee | jnthn++ | src/Perl6/Actions.nqp:
17:03 dalek rakudo/nom: start blocks get their own $! and $/.
17:03 dalek rakudo/nom:
17:03 dalek rakudo/nom: This avoids over-sharing of them, which can cause all sorts of pain.
17:03 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/08e39ee265
17:03 dalek roast: 8ee1f2d | jnthn++ | S17-promise/start.t:
17:03 dalek roast: Test start blocks get fresh $/ and $!.
17:03 dalek roast: review: https://github.com/perl6/roast/commit/8ee1f2d006
17:05 ilmari 'blorst'?
17:05 jnthn block or statement
17:06 jnthn Sounds like a posh English guy saying "blast" :P
17:06 ilmari sounds like an eastern european dish
17:07 ilmari and what's kok? that's norwegian for boil (imperative verb)
17:08 ilmari kok blorst # get in the kitchen!
17:09 jnthn I've read it as "keyword OK", but maybe only TimToady really knows... :)
17:09 * jnthn hopes he never has to read that part of the grammar out loud on stage...
17:11 ilmari there's also tribble and sibble
17:11 * ilmari giggles
17:11 travis-ci joined #perl6-dev
17:11 travis-ci Rakudo build errored. Zoffix Znet 'Improve tools/contributors.pl6
17:11 travis-ci https://travis-ci.org/rakudo/rakudo/builds/149510116 https://github.com/rakudo/rakudo/compare/d97e0938a89c...05133931a9b6
17:11 travis-ci left #perl6-dev
17:11 buggable travis-ci, one build failed due to the timeout. No other failures.
17:12 unmatched} <3 buggable
17:12 jnthn Neat! :)
17:12 jnthn OK, dinner time, I think :)
17:58 jdv79 jnthn: when you get a chance can you explain what the second half of that bug is?  would it be the cause of "Use of uninitialized value $!made of type Any in string context" which I think is coming out of XML::Grammar when async'ed
18:05 FROGGS joined #perl6-dev
18:25 timotimo oversharing of $!; one thread is changing $! while the other is reading it
18:26 gfldex we could do with input to resolve https://github.com/perl6/doc/issues/787
18:31 jnthn jdv79: It seems that the closure inside of the right hand side of the substitution ends up getting mis-handled when we turn the right hand side into a thunk. So, an AST mis-construction problem, essentially, that leads to it seeing state from other threads when that should never happen. It's probably possible to reproduce such a bug using recursion too.
18:36 timotimo gfldex: i gavea input, but maybe a bit too much noise, not enough actaul help ...
18:41 unmatched} gfldex: http://xkcd.com/221/
18:41 unmatched} :}
18:47 unmatched} m: say 1.rand
18:47 camelia rakudo-moar 08e39e: OUTPUT«0.458646765263575␤»
18:48 unmatched} m: say 1.rand*10
18:48 camelia rakudo-moar 08e39e: OUTPUT«5.18174009528097␤»
18:48 unmatched} m: say 10**(1.rand*10).chars
18:48 camelia rakudo-moar 08e39e: OUTPUT«1000000000000000␤»
18:50 dalek rakudo/nom: 7ec824e | TimToady++ | src/Perl6/Grammar.nqp:
18:50 dalek rakudo/nom: if missing block after }, guess bad hash subscript
18:50 dalek rakudo/nom:
18:50 dalek rakudo/nom: Fixes RT #128830.
18:50 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/7ec824e52a
18:50 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=128830
18:53 unmatched} ""block (apparently claimed by " ~ ($*BORG<name>...."
18:53 unmatched} heh, we got $*BORGs :D
19:03 TimToady we've even got the sink
19:05 mst unit module Kitchen;
19:07 TimToady not to be confused with a model kitchen unit...
19:15 jnthn Duh... I really need to write us a decent thread pool scheduler soon.
19:20 jnthn (That accounts for available hardware, throughput, queue length, etc.)
19:20 jnthn Just tracked a deadlock down to it not starting enough threads.
19:24 jnthn That's not really something to start on in the middle of the evening though. Heck, the current one was probably put together quickly in the space of an evening. :)
19:28 [Coke] m: say «123 asdf»
19:28 camelia rakudo-moar 7ec824: OUTPUT«(123 asdf)␤»
19:28 [Coke] m: say «123 asdf».perl;
19:28 camelia rakudo-moar 7ec824: OUTPUT«(IntStr.new(123, "123"), "asdf")␤»
19:43 lizmat jnthn: re writing a decent thread pool scheduler, isn't it more important that "await" no longer blocks a thread ?
20:09 jnthn lizmat: Well, that one comes with the "only in 6.d" yak shave, I think, and I'm pretty sure it's going to be rather more fraught. They both need doing.
20:10 lizmat why would that need to be 6.d ?  syntax wise nothing changes?  and it only fixes issues, no
20:10 lizmat ?
20:11 jnthn It's a quite notable semantic change, though...:)
20:11 jnthn And we *will* perhaps break things
20:12 lizmat I guess I'm being dense, but what is the semantic change ?
20:12 jnthn `await` whole holding a lock might have to become an error, for example
20:12 lizmat ah
20:12 lizmat hmmm....
20:12 jnthn Well, that your code ran be running on a different thread after an await unless you arrange otherwise.
20:12 jnthn Which is fine for most things, but could be a bit of a surprise if you ain't expecting it.
20:13 jnthn (And yes, we'll need to arrange ways for people to opt out of that)
20:13 jnthn Dealings with native code may also be affected, for example.
20:13 jnthn Most of the time you can write code without really caring what OS thread it might be running on.
20:14 jnthn But sometimes the escape hatch matters.
20:16 lizmat gotcha  :-)
20:19 gfldex lizmat: on linux the effective UID/GID is per thread
20:20 lizmat hmmm.... doesn't that actually mean that we can *NEVER* switch threads after an await ?
20:20 lizmat security wise ?
20:21 gfldex i would think so
20:22 lizmat or it would need to be running on a thread with the same UID/GID
20:22 gfldex or better before switching to a thread it has to check if UID matches
20:22 TimToady separate threadpool for each?
20:23 * lizmat wonder how that works on Win
20:26 jnthn Note that since a start block may run on any of the thread pool threads, and its continuation (.then(...)) on a different one, you'd already have to take care of this.
20:27 jnthn As far as I've got it worked out, though, if you Thread.start({ ...seteuid... ... await ... }) then your await will really be blocking that one thread.
20:27 jnthn That is, there'll have to be something in your dynamic scope saying "I can handle awaits smarter"
20:28 jnthn And the ThreadPoolScheduler will put that in place for you
20:28 jnthn (The default one you get, that is.)
20:29 lizmat isn't this something that libuv should be doing ?
20:29 jnthn No.
20:29 jnthn libuv is far more low level than this
20:29 lizmat oki
20:29 AlexDaniel joined #perl6-dev
20:31 sno joined #perl6-dev
20:33 masak libuv handles "thread pool" but not "thread pool scheduler"?
20:35 lizmat masak: indeed
20:36 lizmat that is currently handled in src/core/ThreadPoolScheduler
20:36 jnthn libuv does have a thread pool, but it's somewhat special-case
20:37 jnthn It's used by libuv itself in various cases
20:38 jnthn http://docs.libuv.org/en/v1.x/threadpool.html if you're curious
20:41 masak thank you
20:54 dalek rakudo/nom: f13c40a | lizmat++ | src/core/Buf.pm:
20:54 dalek rakudo/nom: Buf.push|append|unshift|prepend also allow Blob:D
20:54 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/f13c40ae84
20:57 masak lizmat++
20:57 lizmat jnthn: do you agree that: my Buf $a; $a.push(Buf.new(1,2,3)) should work ?
21:01 timotimo hmm. i'd say append yes, but push no
21:02 timotimo because push has the "push a single item" semantics everywhere else and you can't push a buf into a buf
21:03 masak but you can push a number into a buf
21:05 lizmat timotimo: pretty sure we currently have pushing a Buf onto a Buf in roast
21:06 timotimo oh
21:06 timotimo then maybe that wants to become append and push ought to warn of deprecation?
21:10 lizmat well, removing Buf.push(Buf) even breaks make install
21:11 timotimo ouch
21:35 jnthn lizmat: Hmmm... Seems inconsistent with Array
21:36 jnthn (Where push is always "this item")
21:36 lizmat yeah, I think we agree that Buf.push(Buf:D) working, is a mistake
21:36 lizmat I guess we missed that when append/prepend were introduced
21:38 dalek rakudo/nom: 4693a52 | lizmat++ | src/core/IO/ (3 files):
21:38 dalek rakudo/nom: Use Buf.append(Buf) instead of Buf.push(Buf)
21:38 dalek rakudo/nom:
21:38 dalek rakudo/nom: The latter has questionable / confusing semantics wrt to Array
21:38 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/4693a52b2d
21:38 lizmat this is spectest clean, so we can deprecate Buf.push|unshift(Blob) if we want
21:39 b2gills If Buf has a .push it should only accept a single value
21:39 b2gills single value according to the Buf that is
21:40 lizmat m: my $b = Buf.new; $b.push(1,2,3); dd $b   # should this work ?
21:40 camelia rakudo-moar f13c40: OUTPUT«Buf $b = Buf.new(1,2,3)␤»
21:43 jnthn m: my @a; @a.push(1,2,3); dd @a
21:43 camelia rakudo-moar f13c40: OUTPUT«Array @a = [1, 2, 3]␤»
21:43 jnthn So yes :)
21:43 b2gills It would depend on :(*@) vs :(+@)
21:44 jnthn Yeah, push is *, append is + iirc
21:45 lizmat ok, I'm getting too tired to think about this in depth now
21:45 lizmat so I'm gonna sleep on it
21:46 lizmat good night, #perl6-dev!
21:49 jnthn Good plan. Think I'll do likewise :)
22:21 masak 'night, #perl6-dev
22:26 skids joined #perl6-dev
23:15 Zoffix m: Regex.^parents.say
23:15 camelia rakudo-moar 4693a5: OUTPUT«((Method) (Routine) (Block) (Code))␤»
23:15 * Zoffix is pretty surprised to see Regex has such parentage.
23:16 Zoffix m: say .file,.line for /'foo'/
23:16 camelia rakudo-moar 4693a5: OUTPUT«concatenate requires a concrete string, but got null␤  in block <unit> at <tmp> line 1␤␤»
23:16 Zoffix m: say .file, .line for /'foo'/
23:16 camelia rakudo-moar 4693a5: OUTPUT«concatenate requires a concrete string, but got null␤  in block <unit> at <tmp> line 1␤␤»
23:16 Zoffix .oO( concatenate?? )
23:19 timotimo while trying to gist the list eh
23:28 Zoffix I'm curious, what's the point of the entire commit hash if apparently just '4693a5' is enough to identify one?
23:30 Zoffix m: say $*VM.version
23:30 camelia rakudo-moar 4693a5: OUTPUT«v2016.07.16.g.85.b.6537␤»
23:30 Zoffix There's no way to get the commit number from within Perl 6 is there?
23:31 geekosaur the prefix is *usually* enough. I've worked on projects where it
23:31 geekosaur s not
23:31 Zoffix Ah
23:36 Zoffix m: say $*PERL.compiler.version.parts[5..7].join
23:36 camelia rakudo-moar 4693a5: OUTPUT«4693a52␤»
23:36 geekosaur basically the fact that short prefixes are often good enough is the mark of a good hash digest function
23:36 geekosaur you cant get away with that by fixed position since it splits at digit-letter boundaries. look for the ".g" (which may have an alpha initial portion of the hash appended)
23:37 geekosaur that is, for a hash ac35d92 you'd get v[date].gac.35.d.92
23:38 geekosaur for a more robust pattern, you want the last segment that begins with "g" (since "g" is not a valid hex digit, and this frees you from depending on the prefix being date-based)
23:48 Zoffix Thanks.
23:59 jdv79 I think i found another async data issue but i can't golf it well.  i guess i'll just submit it as is.

| Channels | #perl6-dev index | Today | | Search | Google Search | Plain-Text | summary