TimToady but my timings are just all over the map right now, so I dunno what to think 00:18
with the "correct" fix I get the fastest times sometimes, and also the slowest :/ 00:19
I think there's just too much noise in my setup here to determine the hit
so ignore my earlier 7%, that was just noise 00:20
dalek p: e0e113d | TimToady++ | src/QRegex/Cursor.nqp:
add $*SUPPOSING dynvar to mark conjectural parsing

This dynvar is set inside <?before> and <?after> so that action methods can decide whether to do permanent side effects outside the AST.		 00:23
kudo/nom: 9c7b3c1 | TimToady++ | src/Perl6/Actions.nqp:
don't create thunk refs inside a <?before>
 00:39
kudo/nom: 6183a57 | TimToady++ | tools/build/NQP_REVISION:
bump NQP to get $*SUPPOSING set in <?before>
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:49
hopefully the map is not the territory... 00:50
mst Zoffix: \o/ 01:13
Zoffix :) 01:17
jdv79 what did zoffix do now? 01:31
Zoffix jdv79, I quit drinking! 01:38
Just now... like 3 seconds ago... I ran out of beer :P 01:39
jdv79 better head out fore the shops closr!
methinks you'll quit drinking bout when i do; when we expire. 01:41
Zoffix Nah, I'm quitting again :) 01:46
jdv79 :)
ok
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.
jdv79 3 months? wow. thats crazy.
moderation++
TimToady Zoffix++
nine TimToady: I run "cpupower frequency-set -g performance" before doing any kind of benchmark. Reduces the noise a lot. 08:56
psch j: A: for ^1 { for ^1 { last A } } # vOv 08:59
camelia ( no output )
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"
j: A: for ^1 { B: while True { last A } } 09:00
camelia ( no output )
psch which seems to mean "a given nqp::handle call always generates code exactly once"
or we have some kind of weird lexical shadowing with the Labels maybe..? 09:01
jnthn Morning, #perl6-dev 09:10
psch o/ jnthn 09:12
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
jnthn o.O 09:17
That would be odd
psch and, well, it happens when the same code path leading to the same nqp::handle invocation is executed
jnthn iirc there's some "compile code in the context of a handler" stuff
May be worth checking that is happening consistently
psch yeah, i saw that bit
well, skimmed over it :) 09:18
but that's the most sensible explanation i've found for what's happening 09:19
j: A: for ^1 { B: for ^2 -> $, $ { last A } } # different nqp::handle calls in Any-iterable-methods.pm, works
camelia ( no output )
psch 'cause 1ary and 2ary blocks in sequential map use different instantiations of SlippyIterator
labeled and not labeled also works 09:20
but any given identical two doesn't work
what i've seen from debug output is that two different ones generate more handlers
and the missing one in the case of identical ones is the one with the lower handler id
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:23
jnthn I'd think so 09:24
Tux__ This is Rakudo version 2016.07.1-110-g6183a57 built on MoarVM version 2016.07-13-gcba3ae3 09:46
test 15.271
test-t 8.207
csv-parser 16.983
jnthn lizmat: About? :) 10:06
dalek kudo/supply-circular-wait-fix: 5f1249e | jnthn++ | src/core/Supply.pm:
Eliminate locking in favor of a work queue.

The approach taken so far is vulnerable to deadlock, since there can be unfortunate timing interactions between the up-stream management of the subscription and downstream flow of values. This changes puts a work queue in place instead, which successfully avoids the deadlock and in theory should give lower overhead, less blocked threads, and hopefully better CPU cache behavior. Regresses a couple of tests, however.		 10:19
rakudo/supply-circular-wait-fix: 5e61516 | jnthn++ | src/Perl6/Actions.nqp:
rakudo/supply-circular-wait-fix: Fix a scoping bug with blockless phasers.
rakudo/supply-circular-wait-fix:
rakudo/nom: 5f1249e | jnthn++ | src/core/Supply.pm: 10:27
rakudo/nom: Eliminate locking in favor of a work queue.
rakudo/nom:
rakudo/nom: The approach taken so far is vulnerable to deadlock, since there can
rakudo/nom: be unfortunate timing interactions between the up-stream management
jnthn lizmat: Could you glance github.com/rakudo/rakudo/commit/88...354a269268 and github.com/rakudo/rakudo/commit/02...6818d3ea31 if you get chance, to see if they make sense to you? :)
lizmat looks 10:36
jnthn: looking back there at code I did ~ a year ago, pre last Supply refactor, it makes sense I think 10:39
although I must admit I'm not quite awake just yet 10:40
jnthn OK :)
It passes all the tests, anyways.
The branch I merged fixes a nasty circular wait that could occasionally cause deadlocks for programs using the supply/whenever syntax.
Which was to blame for some spectest hangs.
psch huh. we get a BOOTStr for :$label in sequential-map..? 10:43
that seems wrong
dalek ast: ea70ef3 | jnthn++ | S17-lowlevel/semaphore.t:
Add tests for Semaphore.

Which we seem to have missed entirely so far. These also cover the Semaphore hangs reported in RT #128628.		 10:44
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128628
dalek ast: 1c28d3a | lizmat++ | S04-phasers/in-loop.t:
Unfudge now passing test
 10:48
kudo/nom: 942a696 | jnthn++ | t/spectest.data:
Run new semaphore tests.
 10:54
ast: 9287f32 | lizmat++ | integration/advent2012-day15.t:
Unfudge another passing test
 10:58
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
I've sent mails 11:03
jnthn ah, OK...guess I can mark it resolved
lizmat I've sent mails to both RT's that they can be closed 11:04
jnthn++ # nudging me :-)
moritz ... ticket resolved 11:05
jnthn Ah, thanks :)
jnthn was just writing up a resolution of another one :)
Done. And lunch. :) bbiab 11:10
jnthn back 11:37
masak short lunch :) 11:51
jnthn aye 11:53
Clearly I'm racing to fix these bugs :P
masak far be it from me to discourage you from fixing bugs quickly :P 11:55
dalek ast: 4fdee95 | LLFourn++ | S32-exceptions/misc.t:
Tests for RT #128770 128766

checks two instances of useless "useless use of blash in sink context"		 12:13
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128770
unmatched} lizmat: what do you hate about RT's interface? 12:22
[Coke] lizmat, jnthn, I am happy to do RT cleanup for you folks. 12:23
[Coke] yawns. 12:29
lizmat unmatched}: its interface & the difficulty of logging in
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
so I use my mail program to respond to tickets, and that works for me 12:30
[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!
jnthn [Coke]: fwiw, I've no problems working with RT...only didn't get to it 'cus I was doing something else. :)
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
jnthn [Coke]++ # thanks, though! :)
masak [Coke]++ # also responsive 12:32
[Coke] ++zoffix for a newer search. 12:36
jnthn gist.github.com/jnthn/ec19c88a592c...41953ad25a 14:20
^^ is a write-up of a Supply race issue that I've written up.
Any input welcome. :)
lizmat has taken her own advice: act.yapc.eu/alpineperl2016/talk/6868 14:21
anybody else here wants to submit a Perl 6 presentation for the Alpine Perl Workshop ?
dalek p: 3d8fe9f | jnthn++ | tools/build/MOAR_REVISION:
Get a couple of MoarVM I/O fixes.
 14:30
kudo/nom: ed9cbb2 | jnthn++ | src/core/Supply.pm:
Correct comment on Supply grammar.

In the event of a supply being closed by the consumer, it may not produce a done or quit event.		 14:31
kudo/nom: 171307b | jnthn++ | tools/build/NQP_REVISION:
Bump for some MoarVM I/O fixes.
ast: c900158 | jnthn++ | S32-io/IO-Socket-Async.t:
Test to cover missing "address in use" error bug.
 14:32
ast: 2103b87 | (LE Manh Cuong)++ | S16-io/eof.t:
Reading /proc files line by line does not go into infinitive loop

RT #127370		 14:33
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=127370
dalek ast: 207e611 | jnthn++ | S16-io/eof.t:
Merge pull request #137 from Gnouc/master

Reading /proc files line by line does not go into infinitive loop
kudo/nom: d97e093 | jnthn++ | t/spectest.data:
Run S16-io/eof.t.
 14:43
jnthn Break; bbl 14:44
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:31
And ../MoarVM ../nqp ../roast, but I guess those are counted in nqp nqp/MoarVM t/spec 15:32
[Coke] unmatched}: I have never had doc checked out there, so it's not just you 15:40
unmatched} now I feel less bad, thanks :) 15:42
lizmat guess that was just me :-( 15:44
so where should it be checkout then ?
unmatched} I actually do have `doc` checked out there on one of my boxes, but I don't release there :D 15:45
dalek kudo/nom: 0513393 | (Zoffix Znet)++ | tools/contributors.pl6:
Improve tools/contributors.pl6

  - Abort if expected repository location is missing
   - Remove duplicate repository locations as those are present in
   the rakudo repo build.
  - note() a message alerting the user of expected repo locations and
remind them to ensure those repos have all the latest changes.
unmatched} I think ../doc is fine, as long as the person running it knows it needs to be there.
jnthn rt.perl.org/Ticket/Display.html?id=128809 is impressively explosive... 16:17
TimToady: Do you think a start block should declare its own $/ and $!, rather like a Routine does? 16:28
The issue in that RT is half because of over-sharing of those (and half because of a thunk/closure problem) 16:29
TimToady one could almost argue that nothing outside a start should be visible by default 16:36
so I'd be fine with that 16:37
jnthn OK :)
timotimo will we get a lambda syntax like c++ has?
jnthn The thunky one will be harder to fix...
TimToady timotimo: we don't generally turn to C++ for syntactic advice... 16:39
timotimo gee, i wonder why that is
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"
jnthn
.oO( Is that from C++ too? :P )
 16:43
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␤»
jnthn m: say await map { start { my $foo = "barbaz"; $foo ~~ s/(.).+/$0/; $foo } }, ^100;
camelia rakudo-moar 051339: OUTPUT«Memory allocation failed; could not allocate 4 bytes␤»
jnthn hmm
Oh, is that the camelia memory limit thing maybe... 16:45
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)␤»
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␤»
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;
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␤»
jnthn The patch fixes that case at least :)
And spectest passes :) 16:49
timotimo i've seen this error a looooooong time ago in productive code 16:50
dalek kudo/nom: f32173b | lizmat++ | src/core/Array.pm:
Make Array.splice($offset) about 40x faster

  - for a 10 element array and offset 5
  - rewritten using nqp ops
  - more candidates		 16:58
lizmat afk& 16:59
jnthn m: use Test; { my $/; isnt await(start { $/ }), 42, 'Get a fresh $/ inside of a start block'; }
camelia rakudo-moar 051339: OUTPUT«ok 1 - Get a fresh $/ inside of a start block␤»
jnthn m: use Test; { my $/ = 42; isnt await(start { $/ }), 42, 'Get a fresh $/ inside of a start block'; }
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'␤»
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)'␤»
dalek kudo/nom: 08e39ee | jnthn++ | src/Perl6/Actions.nqp:
start blocks get their own $! and $/.

This avoids over-sharing of them, which can cause all sorts of pain.		 17:03
ast: 8ee1f2d | jnthn++ | S17-promise/start.t:
Test start blocks get fresh $/ and $!.
ilmari 'blorst'? 17:05
jnthn block or statement
Sounds like a posh English guy saying "blast" :P 17:06
ilmari sounds like an eastern european dish
and what's kok? that's norwegian for boil (imperative verb) 17:07
kok blorst # get in the kitchen! 17:08
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...
ilmari there's also tribble and sibble 17:11
ilmari giggles
travis-ci Rakudo build errored. Zoffix Znet 'Improve tools/contributors.pl6
travis-ci.org/rakudo/rakudo/builds/149510116 github.com/rakudo/rakudo/compare/d...133931a9b6
buggable travis-ci, one build failed due to the timeout. No other failures.
unmatched} <3 buggable 17:12
jnthn Neat! :)
OK, dinner time, I think :)
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 17:58
timotimo oversharing of $!; one thread is changing $! while the other is reading it 18:25
gfldex we could do with input to resolve github.com/perl6/doc/issues/787 18:26
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:31
timotimo gfldex: i gavea input, but maybe a bit too much noise, not enough actaul help ... 18:36
unmatched} gfldex: xkcd.com/221/ 18:41
:}
m: say 1.rand 18:47
camelia rakudo-moar 08e39e: OUTPUT«0.458646765263575␤»
unmatched} m: say 1.rand*10 18:48
camelia rakudo-moar 08e39e: OUTPUT«5.18174009528097␤»
unmatched} m: say 10**(1.rand*10).chars
camelia rakudo-moar 08e39e: OUTPUT«1000000000000000␤»
dalek kudo/nom: 7ec824e | TimToady++ | src/Perl6/Grammar.nqp:
if missing block after }, guess bad hash subscript

Fixes RT #128830.		 18:50
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128830
unmatched} ""block (apparently claimed by " ~ ($*BORG<name>...." 18:53
heh, we got $*BORGs :D
TimToady we've even got the sink 19:03
mst unit module Kitchen; 19:05
TimToady not to be confused with a model kitchen unit... 19:07
jnthn Duh... I really need to write us a decent thread pool scheduler soon. 19:15
(That accounts for available hardware, throughput, queue length, etc.) 19:20
Just tracked a deadlock down to it not starting enough threads.
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:24
[Coke] m: say «123 asdf» 19:28
camelia rakudo-moar 7ec824: OUTPUT«(123 asdf)␤»
[Coke] m: say «123 asdf».perl;
camelia rakudo-moar 7ec824: OUTPUT«(IntStr.new(123, "123"), "asdf")␤»
lizmat jnthn: re writing a decent thread pool scheduler, isn't it more important that "await" no longer blocks a thread ? 19:43
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:09
lizmat why would that need to be 6.d ? syntax wise nothing changes? and it only fixes issues, no 20:10
?
jnthn It's a quite notable semantic change, though...:) 20:11
And we *will* perhaps break things
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
lizmat ah
hmmm....
jnthn Well, that your code ran be running on a different thread after an await unless you arrange otherwise.
Which is fine for most things, but could be a bit of a surprise if you ain't expecting it.
(And yes, we'll need to arrange ways for people to opt out of that) 20:13
Dealings with native code may also be affected, for example.
Most of the time you can write code without really caring what OS thread it might be running on.
But sometimes the escape hatch matters. 20:14
lizmat gotcha :-) 20:16
gfldex lizmat: on linux the effective UID/GID is per thread 20:19
lizmat hmmm.... doesn't that actually mean that we can *NEVER* switch threads after an await ? 20:20
security wise ?
gfldex i would think so 20:21
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
TimToady separate threadpool for each?
lizmat wonder how that works on Win 20:23
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:26
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
That is, there'll have to be something in your dynamic scope saying "I can handle awaits smarter"
And the ThreadPoolScheduler will put that in place for you 20:28
(The default one you get, that is.)
lizmat isn't this something that libuv should be doing ? 20:29
jnthn No.
libuv is far more low level than this
lizmat oki
masak libuv handles "thread pool" but not "thread pool scheduler"? 20:33
lizmat masak: indeed 20:35
that is currently handled in src/core/ThreadPoolScheduler 20:36
jnthn libuv does have a thread pool, but it's somewhat special-case
It's used by libuv itself in various cases 20:37
docs.libuv.org/en/v1.x/threadpool.html if you're curious 20:38
masak thank you 20:41
dalek kudo/nom: f13c40a | lizmat++ | src/core/Buf.pm:
Buf.push|append|unshift|prepend also allow Blob:D
 20:54
masak lizmat++ 20:57
lizmat jnthn: do you agree that: my Buf $a; $a.push(Buf.new(1,2,3)) should work ?
timotimo hmm. i'd say append yes, but push no 21:01
because push has the "push a single item" semantics everywhere else and you can't push a buf into a buf 21:02
masak but you can push a number into a buf 21:03
lizmat timotimo: pretty sure we currently have pushing a Buf onto a Buf in roast 21:05
timotimo oh 21:06
then maybe that wants to become append and push ought to warn of deprecation?
lizmat well, removing Buf.push(Buf) even breaks make install 21:10
timotimo ouch 21:11
jnthn lizmat: Hmmm... Seems inconsistent with Array 21:35
(Where push is always "this item") 21:36
lizmat yeah, I think we agree that Buf.push(Buf:D) working, is a mistake
I guess we missed that when append/prepend were introduced
dalek kudo/nom: 4693a52 | lizmat++ | src/core/IO/ (3 files):
Use Buf.append(Buf) instead of Buf.push(Buf)

The latter has questionable / confusing semantics wrt to Array		 21:38
lizmat this is spectest clean, so we can deprecate Buf.push|unshift(Blob) if we want
b2gills If Buf has a .push it should only accept a single value 21:39
single value according to the Buf that is
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)␤»
jnthn m: my @a; @a.push(1,2,3); dd @a 21:43
camelia rakudo-moar f13c40: OUTPUT«Array @a = [1, 2, 3]␤»
jnthn So yes :)
b2gills It would depend on :(*@) vs :(+@)
jnthn Yeah, push is *, append is + iirc 21:44
lizmat ok, I'm getting too tired to think about this in depth now 21:45
so I'm gonna sleep on it
good night, #perl6-dev! 21:46
jnthn Good plan. Think I'll do likewise :) 21:49
masak 'night, #perl6-dev 22:21
Zoffix m: Regex.^parents.say 23:15
camelia rakudo-moar 4693a5: OUTPUT«((Method) (Routine) (Block) (Code))␤»
Zoffix is pretty surprised to see Regex has such parentage.
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␤␤»
Zoffix m: say .file, .line for /'foo'/
camelia rakudo-moar 4693a5: OUTPUT«concatenate requires a concrete string, but got null␤ in block <unit> at <tmp> line 1␤␤»
Zoffix
.oO( concatenate?? )
timotimo while trying to gist the list eh 23:19
Zoffix I'm curious, what's the point of the entire commit hash if apparently just '4693a5' is enough to identify one? 23:28
m: say $*VM.version 23:30
camelia rakudo-moar 4693a5: OUTPUT«v2016.07.16.g.85.b.6537␤»
Zoffix There's no way to get the commit number from within Perl 6 is there?
geekosaur the prefix is *usually* enough. I've worked on projects where it 23:31
s not
Zoffix Ah
m: say $*PERL.compiler.version.parts[5..7].join 23:36
camelia rakudo-moar 4693a5: OUTPUT«4693a52␤»
geekosaur basically the fact that short prefixes are often good enough is the mark of a good hash digest function
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)
that is, for a hash ac35d92 you'd get v[date].gac.35.d.92 23:37
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:38
Zoffix Thanks. 23:48
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. 23:59

Powered by Cro and the Raku® Programming Language.

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

Thank you!