MasterDuke turns out i *nearly* have a fix for the JVM. it compiles fine, but './perl6-j tools/build/install-core-dist.pl /home/dan/Source/perl6/install/share/perl6' dies with 'Flattening named argument must have VMHash REPR' 01:00
--ll-exception output here: gist.github.com/MasterDuke17/0e3fb...7b600706de 01:02
that error is in ./src/vm/jvm/runtime/org/perl6/nqp/sixmodel/SixModelObject.java 01:04
[Tux] This is Rakudo version 2016.09-169-ge2cd7a3 built on MoarVM version 2016.09-39-g688796b 06:37
csv-ip5xs 3.118
test 15.785
test-t 6.863
csv-parser 20.721
jnthn morning, #perl6-dev 08:42
Hmm, just built latest Moar/NQP/Rakudo and get gist.github.com/jnthn/92afc7ae19f9...0c92532e1e 09:06
In spectest
Is it "just me"?
timotimo i'll have a go 09:07
need to turn off asan frist 09:10
first*
S06, and counting 09:13
jnthn is fixing Proc::Async to not be vulnerable to the same uncatchable decoding exception bug that IO::Socket::Async had
timotimo all tests successful on my machine 09:16
timotimo makes extra sure the nqp is up to date 09:17
i think there's only been commits to other backends since last time i make-installed
100% success 09:23
jnthn Oddness 09:24
Wonder what I'm missing
lizmat Files=1147, Tests=53301, 214 wallclock secs (12.82 usr 3.99 sys + 1303.13 cusr 121.19 csys = 1441.13 CPU) 10:07
jnthn: also 100% here 10:08
jnthn Oddness
Well, doing another run now with my latest patches
jnthn seems to have started on a bunch of stuff and finished little of late :/ 10:09
So, today going to at least try and finish some stuff up :P
lizmat jnthn++ :-)
jnthn oh dear, the water's turned a funny color 10:15
.oO( That makes beer the healthy option :P )
grmbl, now I get a totally different spectest fail 10:16
t/spec/S02-literals/allomorphic.t
And it runs fine on its own
lizmat does it also fail with "use lib "." or so? 10:18
and if so, how ? 10:19
jnthn I ran it with -Ilib 10:21
Fine with -I. too 10:22
dalek kudo/nom: 969701c | jnthn++ | / (4 files):
Move VMBackedDecoder into Rakudo::Internals.

So that we can re-use it in fixing up other I/O.		 10:24
kudo/nom: a745486 | jnthn++ | src/core/Proc/Async.pm:
Switch Proc::Async to manage decoding from Perl 6.

This solves the same problem IO::Socket::Async had with uncatchable exceptions on decoding errors.
Zoffix jnthn, I do get stresstest floppers... I think the other day I mentioned that in 5 runs only the first one passed, and it was a different file failing each time. 10:25
jnthn Argh 10:26
After all the time I spent hunting down flappers before... :/
Well, not going to get distracted with them.
cygx o/ 10:27
Zoffix \o
jnthn o/
cygx found a serialization bug: BEGIN my @foo[42];
put that in a module, and see it explode when useing it... 10:28
jnthn How does it explode? 10:29
timotimo we'll get the answer once cygx comes back from the hospital ... 10:30
Zoffix :D
timotimo i won't look at this issue. cool guys don't look at explosions! 10:32
cygx had to check on his cooking 10:33
Zoffix tips the waiters
cygx "Missing serialize REPR function for REPR MVMContext"
jnthn Odd 10:35
timotimo i pushed a little commit to moarvm that gives a tiny bit of extra info on this 10:36
jnthn RT it, anyways
cygx no change in output with the latest moarvm... 10:38
Zoffix ZOFVM: Files=1195, Tests=129697, 135 wallclock secs (21.36 usr 3.34 sys + 2444.11 cusr 201.22 csys = 2670.03 CPU) 10:39
timotimo no change at all?
Zoffix No fails in two runs
timotimo at least the "missing serialize repr function" message should have () at the end
if nothing else
Zoffix I think there's a better way to sort t/spectest.data (maybe even automagically, before each run): by time the test files take to run, longest first. Maybe even a bit smarter algorithm based on number of cores on the box. I'm seeing most of them fly through the screen, but at the end, there are about 5 that take ages to complete, and my other 19 cores are just sitting there. If those were first to run, the load would be distributed much more evenly. 10:40
Sounds like a fun project for the weekend \o/
jnthn Alternatively, rewrite the tests to not be so slow :) 10:41
Many tests use sleep and so on
When really we should make a test scheduler
With virtualized time
That we stick in $*SCHEDULER
Zoffix sounds fancy :D
jnthn And then tests for stuff like Promise.in and Supply.interval would run in a tiny amount of time
cygx is trying to figure out why his rakudo still uses an out-of-date moarvm 10:43
Zoffix cygx, forgot prefix? 10:44
cygx, if you don't build it yourself, it'll use the "good enough" version, not the latest.
You need to: cd nqp/MoarVM; git pull; perl Configure.pl --prefix=../../install; make; make install; cd ../../ 10:45
timotimo make -j is worth a lot in moarvm 10:46
dalek ast: 4fcb0be | jnthn++ | S17-procasync/encoding.t:
Test Proc::Async encoding errors are catchable.

Previously, they could bring down the process. Also two tests that tickle a separate supply/whenever/LAST bug that boil down to the long-unresolved phaser cloning issues.		 10:47
p: f8dfb0f | (Pawel Murias)++ | src/vm/js/Compiler.nqp:
[js] Remove expensive logging of stuff.
 10:57
p: cf14d7a | (Pawel Murias)++ | src/vm/js/nqp-runtime/reprs.js:
[js] Stub AsyncTask repr.
p: 558f4df | (Pawel Murias)++ | src/vm/js/RegexCompiler.nqp:
[js] Stop from generating unneeded boolifications (caused a bug when rakudo.js was compiling the setting).
kudo/js: 5c1b5e6 | (Pawel Murias)++ | src/vm/js/perl6-runtime/runtime.js:
[js] Fix bug in nqp::p6box_i.
travis-ci Rakudo build failed. Jonathan Worthington 'Switch Proc::Async to manage decoding from Perl 6. 10:58
travis-ci.org/rakudo/rakudo/builds/167007533 github.com/rakudo/rakudo/compare/e...454865eaf7
buggable [travis build above] ā˜  Did not recognize some failures. Check results manually
Zoffix all JVM. 10:59
dalek kudo/nom: 6037673 | jnthn++ | t/spectest.data:
Run S17-procasync/encoding.t.
 11:02
kudo/nom: e08da94 | jnthn++ | src/core/ (4 files):
Factor out byte supply -> chars supply decoding.

Also allow the encoding to be specified, in preparation for giving Proc::Async and IO::Socket::Async encoding support.
ast: 0705a6e | LLFourn++ | S17-promise/start.t:
Tests for RT #127033

dynamic variables used to disappear inside start blocks sometimes		 11:05
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=127033
cygx I've been unable to figure out the weirdness with my system 11:29
anyway, here's the ticket: rt.perl.org/Public/Bug/Display.html?id=129855 11:30
jnthn lunch & 11:34
travis-ci Rakudo build failed. Jonathan Worthington 'Factor out byte supply -> chars supply decoding. 11:36
travis-ci.org/rakudo/rakudo/builds/167015196 github.com/rakudo/rakudo/compare/a...8da94d635a
buggable [travis build above] ā˜  Did not recognize some failures. Check results manually
lizmat m: sub a(str @b) { dd @b }; a <a b c d> # this should work, no ?
camelia rakudo-moar e08da9: OUTPUTĀ«Type check failed in binding to @b; expected Positional[str] but got List ($("a", "b", "c", "d"))ā¤ in sub a at <tmp> line 1ā¤ in block <unit> at <tmp> line 1ā¤ā¤Ā»
jnthn No 11:40
Types are nominal, not structural
ah, right, I was going for lunch... :) & 11:41
lizmat m: say "1234567890".match(/./,:nth(2,4...*)) # expected to see 2 4 6 8 0 12:19
camelia rakudo-moar e08da9: OUTPUTĀ«ļ½¢2ļ½£ā¤Ā»
lizmat is that a bug? ^^^
jnthn m: sub foo(:@nth) { dd @nth }; foo :nth(2,4...*) 12:34
camelia rakudo-moar e08da9: OUTPUTĀ«(2, 4, 6, 8, 10, 12, 14, 16, 18, 20... (lazy list)ā¤Ā»
jnthn m: sub foo(:$nth) { dd @nth }; foo :nth(2,4...*)
camelia rakudo-moar e08da9: OUTPUTĀ«===SORRY!=== Error while compiling <tmp>ā¤Variable '@nth' is not declared. Did you mean '$nth'?ā¤at <tmp>:1ā¤------> sub foo(:$nth) { dd ā@nth }; foo :nth(2,4...*)ā¤Ā»
jnthn m: sub foo(:$nth) { dd $nth }; foo :nth(2,4...*)
camelia rakudo-moar e08da9: OUTPUTĀ«Seq $nth = (2, 4, 6, 8, 10, 12, 14, 16, 18, 20... (lazy list)ā¤Ā»
jnthn Looks like, yes
Givne than
m: say "1234567890".match(/./,:nth(2,4, 6))
camelia rakudo-moar e08da9: OUTPUTĀ«(ļ½¢2ļ½£ ļ½¢4ļ½£ ļ½¢6ļ½£)ā¤Ā»
jnthn Does work
No reason the Seq case should not 12:35
May need some extra care around laziness
lizmat indeed... will look at that...
jnthn But I think we established before that idt doesnt' work on any Seq
Wow, so typing
lizmat well, laziness is already taken care of, I think
and if not, I will now :-)
jnthn m: say uniname "Ɩl".encode('latin-1').decode('utf-8') 12:36
camelia rakudo-moar e08da9: OUTPUTĀ«Malformed UTF-8 at line 1 col 1ā¤ in block <unit> at <tmp> line 1ā¤ā¤Ā»
dalek kudo/nom: e8880d5 | jnthn++ | src/core/Proc/Async.pm:
Allow the encoding to be chosen in Proc::Async.
 12:41
ast: 82eb5c0 | jnthn++ | S17-procasync/encoding.t:
Tests for Proc::Async encoding flag.
kudo/nom: 49c0d63 | lizmat++ | src/core/ (2 files):
Give :ov its own iterator

One less check to make in a hot loop.		 12:50
lizmat m: say "1234567890".match(/../,:ov,:ex) # I would argue this is also a bug 12:53
camelia rakudo-moar e8880d: OUTPUTĀ«(ļ½¢12ļ½£ ļ½¢23ļ½£ ļ½¢34ļ½£ ļ½¢45ļ½£ ļ½¢56ļ½£ ļ½¢67ļ½£ ļ½¢78ļ½£ ļ½¢89ļ½£ ļ½¢90ļ½£)ā¤Ā»
lizmat oops, no
travis-ci Rakudo build failed. Jonathan Worthington 'Allow the encoding to be chosen in Proc::Async.' 13:14
travis-ci.org/rakudo/rakudo/builds/167039888 github.com/rakudo/rakudo/compare/e...880d55ce77
buggable [travis build above] ā˜  Did not recognize some failures. Check results manually
dalek kudo/nom: fcb0973 | jnthn++ | src/core/Proc/Async.pm:
Allow choice of encoding by handle in Proc::Async.
 13:23
ast: 5f60afa | jnthn++ | S17-procasync/encoding.t:
Also test setting Proc::Async encoding by handle.

So you can pick a different encoding to read for stdout/stderr vs. the one you pick for stdin. If not specified, the default is the encoding set in the Proc::Async constructor.
travis-ci Rakudo build failed. Elizabeth Mattijsen 'Give :ov its own iterator 13:36
travis-ci.org/rakudo/rakudo/builds/167042840 github.com/rakudo/rakudo/compare/e...c0d63a522d
buggable [travis build above] ā˜  Did not recognize some failures. Check results manually
dalek kudo/nom: 2f841db | lizmat++ | src/core/Rakudo/Internals.pm:
Add role Rakudo::Internals::MatchIterator

Part of the Str.match overhaul		 13:49
travis-ci Rakudo build failed. Jonathan Worthington 'Allow choice of encoding by handle in Proc::Async.' 14:01
travis-ci.org/rakudo/rakudo/builds/167052223 github.com/rakudo/rakudo/compare/4...b09733bf66
buggable [travis build above] ā˜  Did not recognize some failures. Check results manually 14:02
dalek kudo/nom: 23f2e2e | jnthn++ | src/core/IO/Socket/Async.pm:
Allow choosing encoding in IO::Socket::Async.
 14:12
p3rln00b .tell cygx if you'd like to show up under something other than `cygx` in credits in release announcement, please enter yourself into github.com/rakudo/rakudo/blob/nom/CREDITS
yoleaux2 p3rln00b: I'll pass your message to cygx.
dalek ast: c46f137 | jnthn++ | S32-io/IO-Socket-Async.t:
Test :enc argument in IO::Socket::Async.
jnthn And that rounds off the IO::Socket::Async/Proc::Async encoding fixes. Phew. :) 14:16
p3rln00b \o/
p3rln00b mods the contributor script to print number of commits along the names... 14:18
Jesus... I need to get a hobby :|
dogbert17 on no, it's p3rln00b :) 14:21
mst p3rln00b: I think this particular hobby already got you.
p3rln00b m: say "{209 / (Date.today.daycount - Date.new("2016-09-17").daycount)} commits/day average" 14:22
camelia rakudo-moar 2f841d: OUTPUTĀ«8.36 commits/day averageā¤Ā»
p3rln00b m: say Date.today - Date.new("2016-09-17") 14:24
camelia rakudo-moar 2f841d: OUTPUTĀ«25ā¤Ā»
p3rln00b This is nice.
NeuralAnomaly: status 14:25
NeuralAnomaly p3rln00b, [āœ˜] Next release will be in 2 days and 14 hours. Since last release, there are 43 new still-open tickets (3 unreviewed and 0 blockers) and 21 unreviewed commits. See perl6.fail/release/stats for details
[Coke] is so glad p3rln00b volunteered to take a few releases back in the day! 14:28
you've definitely improved it since I've touched it. 14:29
... I mean, that sounds like some kind of back-handed compliment, but I'm genuinely happy with the work you're doing. 14:46
travis-ci Rakudo build failed. Elizabeth Mattijsen 'Add role Rakudo::Internals::MatchIterator 14:54
travis-ci.org/rakudo/rakudo/builds/167059661 github.com/rakudo/rakudo/compare/f...841db95406
buggable [travis build above] ā˜  Did not recognize some failures. Check results manually
dalek p: 5224878 | jnthn++ | src/vm/moar/QAST/QASTRegexCompilerMAST.nqp:
Stop using flattenropes op.

Will be replaced with something non-inplace, and that will be done in
  !cursor_init.		 15:02
travis-ci Rakudo build failed. Jonathan Worthington 'Allow choosing encoding in IO::Socket::Async.' 15:05
travis-ci.org/rakudo/rakudo/builds/167066382 github.com/rakudo/rakudo/compare/2...f2e2ee9911
buggable [travis build above] ā˜  Did not recognize some failures. Check results manually 15:06
lizmat m: say "1234567890".match(/./,:nth(4,3)) # sorta expected 4 3 here 15:15
camelia rakudo-moar 23f2e2: OUTPUTĀ«(ļ½¢4ļ½£)ā¤Ā»
lizmat ^^^ should we consider this a bug?
p3rln00b m: say "1234567890".match(/./,:nth(4,3,5))
camelia rakudo-moar 23f2e2: OUTPUTĀ«(ļ½¢4ļ½£ ļ½¢5ļ½£)ā¤Ā»
p3rln00b I wouldo.
lizmat m: say "1234567890".match(/./,:g)[4,3] # or do we expect them to do this
camelia rakudo-moar 23f2e2: OUTPUTĀ«(ļ½¢5ļ½£ ļ½¢4ļ½£)ā¤Ā»
lizmat m: say "1234567890".match(/./,:g)[3,2] # eh this 15:16
camelia rakudo-moar 23f2e2: OUTPUTĀ«(ļ½¢4ļ½£ ļ½¢3ļ½£)ā¤Ā»
lizmat ok, will take that along then as well
p3rln00b m: say "1234567890".match(/./,:nth(1,0,3,2,5,4))
camelia rakudo-moar 23f2e2: OUTPUTĀ«(ļ½¢1ļ½£ ļ½¢3ļ½£ ļ½¢5ļ½£)ā¤Ā»
lizmat yeah, it's pretty convoluted and sick at the moment :-)
p3rln00b :) 15:17
TimToady according to S05:541, the list provided to nth must be monotonically increasing 15:22
synopsebot6 Link: design.perl6.org/S05.html#line_541
TimToady in other words, it's only intended for a non-caching, potentially lazy situation 15:23
p3rln00b hmm
TimToady .[] is there if you need caching, as shown above 15:24
jnthn Makes sense, given .match produces matches lazily anyway so you'd have to cache (which ruins memory savings of producing matches lazily) 15:26
And the other way would be to sort the :nth list, which you can't if it's infinite
TimToady simply ignoring the non-monotonic values is LTA though 15:28
jnthn True
It'd be a bit odd to use that as a feature :)
lizmat but now that we have better iterators since the GLR, why wouldn't we lazily support this anyway ? 15:29
dalek p: 13c0c48 | jnthn++ | tools/build/MOAR_REVISION:
Bump MOAR_REVISION for indexingoptimized op.
p: 6555575 | jnthn++ | src/vm/moar/QAST/QASTOperationsMAST.nqp:
Map nqp::indexingoptimized op.
p: 2fbb31b | jnthn++ | src/vm/moar/stage0/ (11 files):
Update bootstrap.

To provide access to the new indexingoptimized op.
lizmat aka, use caching only when needed ?
nqp: c0e80f8 | jnthn++ | src/QRegex/Cursor.nqp:
nqp: On Moar, use indexingoptimized op.
nqp:
TimToady you can't predict the need for caching without time travel 15:30
mst I've written caches that figured if it got called maybe 3 times then it was time to cache
probably not applicable here, but "can't" isn't quite true? 15:31
TimToady :nth(|(1..10000000),3)
lizmat well, if that were applied to a .match with 5 matches, it would show 1..5 15:32
because the :nth list is just a lazy provider of indexes in my book (off by one)
TimToady :nth(|(1..10),3)
suppose there are 15 matches
jnthn lizmat: The point is that you can't be lazy in both places we wish to be and have :nth not be monotonic
TimToady you gonna cache 'em all just on the theory there might be a 3 there? 15:33
lizmat no
jnthn Unless, as TimToady said, you have .match keep all the things around in memory so it can refer back to them, which is not really desirable either
TimToady so they can use .[] to force caching when they need it
p3rln00b
.oO( Lazy Pokemon: gotta cache 'em all )
lizmat jnthn: this is only appicable when :nth is specified with something other than an Int 15:34
TimToady :nth(@stuff)
simpler to just disallow decreasing and point them at .[] than to try to guess how much of a list is available at compile time 15:36
jnthn lizmat: Yes, I'm aware
TimToady it's only applicable when there's more than one value, yes 15:37
it's difficult for a single integer not to be monotonically increasing :)
lizmat that would make it complex :-) 15:38
TimToady wonders how the term "monotonic" is related to tonic 15:39
jnthn bbi15
TimToady I guess via "monotonous" :)
cygx also likes to point out that complex numbers are indeed unordered 15:40
yoleaux2 14:12Z <p3rln00b> cygx: if you'd like to show up under something other than `cygx` in credits in release announcement, please enter yourself into github.com/rakudo/rakudo/blob/nom/CREDITS
lizmat
.oO( nobody asks for them :-)
TimToady at least, not till we get 2D regex running on 2D strings... 15:41
p3rln00b :o 15:43
All of the text I read is in 2D shape.
p3rln00b steals the idea and gets rich
cygx I wonder, is there a good reason why the signature :($ where A|B) cannot be shortened to :(A|B) 15:44
that wuold improve the readability of some code I wrote quite a bit 15:45
geekosaur isn't A|B syntax reserved? 15:46
lizmat m: sub a(Int|Str $) { } # interesting error 15:49
camelia rakudo-moar 23f2e2: OUTPUTĀ«===SORRY!===ā¤No compile-time value for Strā¤Ā»
TimToady it's formally ambiguous with |c 15:51
because we don't have delimiters between each assertion of a paramter
s/delimiters/separators/ 15:52
likewise Int&Str is ambiguous with &block 15:53
m: sub a(Int|Str $) { } 15:56
camelia rakudo-moar 23f2e2: OUTPUTĀ«===SORRY!===ā¤No compile-time value for Strā¤Ā»
TimToady m: sub a(Str|Int $) { }
camelia rakudo-moar 23f2e2: OUTPUTĀ«===SORRY!=== Error while compiling <tmp>ā¤Malformed parameterā¤at <tmp>:1ā¤------> sub a(Str|Intā $) { }ā¤ expecting any of:ā¤ constraintā¤Ā»
TimToady m: sub a(Str&Int $) { } 15:57
camelia rakudo-moar 23f2e2: OUTPUTĀ«===SORRY!=== Error while compiling <tmp>ā¤Malformed parameterā¤at <tmp>:1ā¤------> sub a(Str&Intā $) { }ā¤ expecting any of:ā¤ constraintā¤Ā»
TimToady m: sub a(Int&Str $) { } 15:58
camelia rakudo-moar 23f2e2: OUTPUTĀ«===SORRY!=== Error while compiling <tmp>ā¤Malformed parameterā¤at <tmp>:1ā¤------> sub a(Int&Strā $) { }ā¤ expecting any of:ā¤ constraintā¤Ā»
TimToady odd
m: sub a(Int&Str) { }
camelia ( no output )
TimToady m: sub a(Int|Str) { }
camelia rakudo-moar 23f2e2: OUTPUTĀ«===SORRY!=== Error while compiling <tmp>ā¤Capture parameter must have a type accepting a Captureā¤at <tmp>:1ā¤------> sub a(Int|Str) { }ā<EOL>ā¤Ā»
lizmat TimToady: is it ok for me to remove Str.simplematch ? 16:04
you seem to have added about a year ago, but there is no spec, doc or tests for it 16:05
jnthn back 16:11
TimToady lizmat: well, I left it in in case we wanted to use it as an optimization target, but never did the optimization 16:13
lizmat ok, well, then I'll remove it after I have done said optimization :)
jnthn m: use Test; is sub { 42.return }(), 42, "Sub doing 42.return works" 16:22
camelia rakudo-moar 23f2e2: OUTPUTĀ«Attempt to return outside of any Routineā¤ in sub at <tmp> line 1ā¤ in block <unit> at <tmp> line 1ā¤ā¤Ā»
dalek kudo/nom: cff3437 | jnthn++ | src/Perl6/Actions.nqp:
Be less eager to not emit return handlers.

They're essentially free nowadays, except from prevening static inlining, which we only really care about for native ops, which don't do method calls.		 16:31
ast: 64fef88 | jnthn++ | S06-advanced/return.t:
Test for RT #129827.
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=129827
jnthn Anyone else able to reproduce rt.perl.org/Ticket/Display.html?id=128694 ? 16:39
jnthn has been running it for a while and a number of times 16:40
I suspect one of the earlier supplies fixes dealt with it
lizmat hopes so :-) 16:42
jnthn hm, in theory I can try the test out using commitable 16:44
perlpilot jnthn: I can't reproduce it, but the resident memory slowly creeps every upward it seems
s/every/ever/
jnthn commitable: help 16:45
committable6 jnthn, Like this: committable6: f583f22,HEAD say ā€˜helloā€™; say ā€˜worldā€™
timotimo watches the RSS of that program
jnthn commitable6: 2016.05,HEAD gist.github.com/jnthn/81d8ea0aa73c...43db029d75
committable6 jnthn, It looks like a URL, but mime type is ā€˜text/html; charset=utf-8ā€™ while I was expecting something with ā€˜text/plainā€™ or ā€˜perlā€™ in it. I can only understand raw links, sorry.
timotimo is it supposed to be growing without bound?
jnthn I'm not concenred about memory
The bug is about it locking up 16:46
timotimo i know :)
it's not locking up for me
jnthn As with all these things, it may grow to a fixed point
timotimo right
95 megs at the moment
p3rln00b committable6: 2016.05,HEAD gist.githubusercontent.com/jnthn/8...tfile1.txt
committable6 p3rln00b, Successfully fetched the code from the provided URL.
jnthn But yes, if it grows forever there's a problem
perlpilot mine made it to 100M before I killed it
jnthn p3rln00b: ah, I was about to try something like that :)
committable6 p3rln00b, Ā¦Ā«2016.05Ā»: Ā«timed out after 10 seconds, outputĀ»: Ā«exit signal = SIGHUP (1)Ā»ā¤Ā¦Ā«HEADĀ»: ok 1 -
jnthn ooh, nice 16:47
That means the test will cover the bug
(the folks who made commitable6)++ :)
committable6: 2016.05,HEAD gist.githubusercontent.com/jnthn/8...tfile1.txt
committable6 jnthn, Successfully fetched the code from the provided URL.
jnthn (Another try just to see if it was repeatable)
committable6 jnthn, Ā¦Ā«2016.05Ā»: Ā«timed out after 10 seconds, outputĀ»: Ā«exit signal = SIGHUP (1)Ā»ā¤Ā¦Ā«HEADĀ»: ok 1 -
jnthn Seems so 16:48
OK, in goes the test, and another RT down :)
p3rln00b \o/ jnthn++ 16:49
jnthn Vim n00b question: I'm really tired of having to :set paste before I Ctrl+Shift+V. What is a better alternative? :) 16:50
tadzik put it in your .vimrc :)
jnthn Yes, but then it'll not indent stuff? :P
Like, the other times when I want it to... :) 16:51
tadzik Āælol que?
oh, I see
jnthn: i0.kym-cdn.com/photos/images/newsfe...1244616130
jnthn Well, the gif was funny enough to make me put up with this for a few more weeks before worrying about it again, so... :P 16:52
timotimo jnthn: depending on your platform, you can just paste from the + or * buffer
so "*p or "+p will paste stuff into your buffer without it doing its own indentation and such
dalek ast: 8470d41 | jnthn++ | S17-supply/zip-latest.t:
Test to cover RT #128694.
 16:53
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128694
timotimo and ]p or [p will "paste at current indentation level", i'm not sure which
jnthn Hm, *p complains "No string under cursor" when I type the *, and +p just inserts an empty line 16:59
geekosaur the " was part of the command 17:00
jnthn oh wow
I totally didn't see there were them until you mentioned it o.O 17:01
tadzik btw, what got into you to make you use vim jnthn? :)
jnthn They both seem to just insert an empty line though 17:02
geekosaur what platform? there's some horkery you need to use to get things to work on OS X iirc (unless for some reason you're using an X11 build) 17:03
jnthn geekosaur: Just boring old Ubuntu 16.04 or so
Well, not so old, but still, non-exotic :)
geekosaur also there's the usual X11 thing with PRIMARY v CLIPBOARD 17:04
although I thought that was the difference between the * and + registers 17:05
jnthn tadzik: Found myself doing most of my dev work on Linux, and then some mix of being tired of using Atom (probably not Atom's fault but I get weird rendering artefacts going on when running it inside of my VM) and being curious why so many people seem to like Vim :P
My $dayjob stuff of late has involved a bunch of Docker/Kubernetes things, and when I'm doing Perl 6 stuff I want my valgrind/callgrind/massif/perf :) 17:07
tadzik noice :) 17:08
timotimo jnthn: clipboard handling can be weird. there's a vim plugin called "fakeclip" that's meant to make that stuff a bit less annoying, but i haven't looked at it closely enough to actually recommend it 17:15
geekosaur clipboards are weird. and it seems like very few programmers understand how X selections work, leading to lots of bizarre behavior 17:17
and sometimes to hangs
timotimo hangs? how is that?
geekosaur well, it wont happen if you're using a decent toolkit library, it;s only when using the raw X11 stuff that you are likely to get hangs if you don't understand what yu are doing 17:18
(so this happens pretty much any time someone tries to do something clipboard related in xmonad because it operates at the raw X11 layer and nobody understands selections)
if you use gtk/qt/fltk/whatever then they handle the low level stuff and the hang bugs have mostly been caught and fixed 17:19
but you still sometimes get odd behavior
anyway, the problem is everyone thinks "the clipboard" is a box you stick data in and something else pulls data out of. 17:20
in fact, it's a corkboard the program which holds the data hangs a tag on. to get the data you must negotiate with the program holding the data to agree on a common format
timotimo right, i thought it worked like that
based on how clipboard contents disappear when the owning window disappears
geekosaur (and this is where the hang happens because you need to be running the X event loop here or you won't be able to respond to the negotiation. this is actually an Xlib issue and one reason xcb is preferred these days...) 17:21
jnthn m: use Test; throws-like Q/sub (int $i) { $i() }(42)/, X::Method::NotFound
camelia rakudo-moar cff343: OUTPUTĀ« 1..2ā¤ ok 1 - 'sub (int $i) { $i() }(42)' diedā¤ not ok 2 - right exception type (X::Method::NotFound)ā¤ ā¤# Failed test 'right exception type (X::Method::NotFound)'ā¤# at /home/camelia/rakudo-m-inst-1/share/perl6/precomp/74305AA5C7FBE80Eā€¦Ā»
geekosaur (but even with xcb if you just block on certain calls, you will never wake up because you aren't processing the negotiation events) 17:22
anyway, even without the hang lots of folks do not understand the negotiate-common-format thing. including the toolkit devs, so sometimes you try to pull data from the clipboard and can't get it in the format you want 17:23
dalek p: 0592091 | jnthn++ | src/vm/moar/QAST/QASTOperationsMAST.nqp:
Just want an object when compiling a callee.

Any natives will thus be boxed, and invoked, which will also produce an error - but a more useful (HLL-specific) one with a location.
geekosaur so in e.g. vim you'd get a blank line because the other side doesn't handle "no, I need this as a UTF8_STRING" and aborts the negotiation
(or for that matter vim itself could have that bug, but I would hope at this point they have the string negotiation stuff working properly...) 17:24
jnthn The thing I copied from was the Terminal window, fwiw... 17:26
geekosaur also it's amazing how many people do not understand that if you clip an image, it might only be available as the pixels not as a URL or filename or whatever, and/or they actually need to negotiate to get the right thing. everyone believes strings are the only data type in existence
timotimo i've been having super annoying trouble with pasting out of terminal windows recently; whenever the selection ended existing i couldn't paste any more. up until like a month ago i didn't have to ensure the selection sticks around 17:27
so i had the habit of selecting and clearing the selection, then going over to paste
geekosaur it switched from CLIPBOARD to PRIMARY?
that's the main behavioral difference, PRIMARY only exists while something is actively selected
timotimo could be 17:28
it f'd me up for a solid two weeks, because i had that so strongly ingrained in my muscle memory
geekosaur still makes sure things stay actively selected, because PRIMARY was the only selection back when he got started... 17:29
also the CLIPBOARD behavior encourages people to think of the selection as a box you dump strings into, leading to more bugs :/ 17:30
jnthn *sigh* What a mess 17:31
geekosaur yep 17:32
timotimo there's clipboard managers that suck up your contents and serve it for other programs for as long as you want
geekosaur there's a jwz rant about the X selection mess, naturally. and nobody has learned anything from it and we have the same problems over adecade later :/ 17:33
timotimo like klipper
geekosaur yes. although in fact they have the same problem in different guise: they generally suck up *one* format because the protocol is designed for "converge on one format" not "iterate all formats"
timotimo mhm
geekosaur so if you have a program that can send you either a URL or a temp file or a block of pixels, you only get the first of those that the clipboard manager tries 17:34
so pasting can behave differently depending on whether a clipboard manager is running or n ot
dalek kudo/nom: 0d09178 | jnthn++ | tools/build/NQP_REVISION:
Get latest NQP.

Which, of note, has a fix to give better errors when trying to invoke a native parameter.		 17:35
timotimo right. ouch.
dalek ast: 3b11442 | jnthn++ | S32-exceptions/misc.t:
Test for RT #129772.
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=129772
jnthn Alrighty, enough fixing for today, I think :) 17:39
p3rln00b jnthn++ :)
TimToady just uses a couple of keyboard commands to turn autoindent off and on 17:45
timotimo has leader set to , and is very happy with that 17:46
TimToady
.oO(Take me to your leader!)
timotimo ,
dalek kudo/nom: faba645 | jnthn++ | docs/ChangeLog:
Update ChangeLog.
 17:50
travis-ci Rakudo build failed. Jonathan Worthington 'Be less eager to not emit return handlers. 18:11
travis-ci.org/rakudo/rakudo/builds/167106514 github.com/rakudo/rakudo/compare/2...f3437de58e
buggable [travis build above] ā˜  Did not recognize some failures. Check results manually
timotimo jvm only 18:12
p3rln00b "Memory allocation failed; could not allocate 462780 bytes" 19:06
heh.. something's wrong with buggable :}
dogbert17 perhaps buggable is bugged :) 19:07
travis-ci Rakudo build errored. Jonathan Worthington 'Get latest NQP.
travis-ci.org/rakudo/rakudo/builds/167122533 github.com/rakudo/rakudo/compare/c...0917806a08
buggable [travis build above] ā˜  Did not recognize some failures. Check results manually 19:08
dogbert17 p3rln00b: some spectests leaks memory like sieves, do you think I should RT stuff like that? 19:09
p3rln00b Yeah 19:10
dogbert17 ok, e.g. t/spec/S17-procasync/stress.t: definitely lost: 91,838 bytes in 1,022 blocks, indirectly lost: 64,240 bytes in 1,350 blocks, possibly lost: 254,216 bytes in 7,249 blocks 19:11
there are also two tests which gives 'invalid reads': t/04-nativecall/08-callbacks.t and t/spec/S17-supply/start.t. That's a bit scary. Could possibly be due to me being on 32 bit 19:15
I have RT'd one of them, i.e. RT #129832, but I guess I should RT the other one as well 19:17
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=129832
dogbert17 is jnthn still around? 20:30
mst "imagine a perfectly spherical jnthn" 20:31
dogbert17 I believe I might have found a memory leak in github.com/MoarVM/MoarVM/blob/mast...ops.c#L572
just wanted an expert opinion 20:32
it seems to me there's a call to MVM_unicode_normalizer_cleanup missing 20:33
perlpilot dogbert17: based on the other uses of MVM_unicode_normalizer_* in that code, I would agree with you. 20:40
dogbert17 perlpilot: thx 20:41
timotimo dogbert17: i was able to confirm the leak with valgrind 20:45
do you want to submit a pull request, or shall i just put in the code?
dogbert17 timotimo: plz fix 20:46
jnthn Yes, seems like a reasonable diagnosis/fix 20:47
perlpilot was half hoping that dogbert17 would make a PR :)
jnthn is still a decent bit of beer drinking off becoming spherical, and even them I think I'll still be pretty imperfect :P
dogbert17 perlpilot: I will if I find another leak :-) 20:48
perlpilot dogbert17: then you'll be just a hop, skip and a jump away from being a regular contributer to MoarVM ;) 20:49
s/buter/butor/
arnsholt In cases like this, I try to be sneaky and don't offer to put in the fix for people =) 20:50
dogbert17 perlpilot: perhaps there is something similar here? github.com/MoarVM/MoarVM/blob/mast...NFA.c#L655 20:51
perlpilot argh ... I've been switching back and forth between using sublime and vim at work. Sublime uses ^S to save your file ... vim, not so much :)
dogbert17: Maybe. Looks like a couple of places could use the MVM_unicode_normalizer_cleanup there. 20:53
dalek kudo/nom: 5a79e22 | (David Warring)++ | lib/Pod/To/Text.pm6:
handle uneven rows lengths in Pod::To::Text::table2text()
kudo/nom: 7af9ec9 | lizmat++ | lib/Pod/To/Text.pm6:
Merge pull request #903 from dwarring/pod-table-fix

handle uneven rows lengths in Pod::To::Text::table2text()
dogbert17 perlpilot: it does look a tiny bit suspicious to my untrained 'c' eye 20:55
MasterDukeMobile I'm still trying to figure out a JVM fix, but in the meantime anybody have any thoughts on my latest PR comments? 20:57
lizmat m: say 42.match(/42/); say $/ # /me haz found another .match bug 20:58
camelia rakudo-moar faba64: OUTPUTĀ«ļ½¢42ļ½£ā¤Nilā¤Ā»
lizmat as opposed to: 20:59
Zoffix m: say "42".match(/42/); say $/
camelia rakudo-moar faba64: OUTPUTĀ«ļ½¢42ļ½£ā¤ļ½¢42ļ½£ā¤Ā»
lizmat m: say "42".match(/42/); say $/ # /me haz found another .match bug
camelia rakudo-moar faba64: OUTPUTĀ«ļ½¢42ļ½£ā¤ļ½¢42ļ½£ā¤Ā»
Zoffix s: 42, 'match' 21:00
SourceBaby Zoffix, Sauce is at github.com/rakudo/rakudo/blob/faba...ol.pm#L178
Zoffix s: '42', 'match'
SourceBaby Zoffix, Sauce is at github.com/rakudo/rakudo/blob/faba...tr.pm#L417
lizmat Zoffix: it's nqp::getlexcaller('$/'); business :-) 21:01
Zoffix Ah
lizmat hmmm... wondering what's the difference between $/ := nqp::getlexdyn('$/') and $/ := nqp::getlexcaller('$/') 21:04
jnthn timotimo ^^^ ?? 21:08
timotimo you can use getlexcaller to assign to your local $/ 21:09
i think getlexdyn might give you the same? i'm not actually sure
lizmat well, in Cool.subst, getlexdyn is used, but in Str.matcj getlexcaller 21:10
*match
dalek? 21:12
github.com/rakudo/rakudo/commit/8d...c2d39c4c7a # fix for 42.match(/42/) not setting $/ 21:13
dalek kudo/nom: bed1428 | lizmat++ | src/core/Rakudo/Internals.pm:
Add generic R::I.SeqNextNFromIterator

Create a Seq from a given iterator, given the next N elements of the iterator (if available of course).		 21:44
kudo/nom: 6996512 | lizmat++ | src/core/Any-iterable-methods.pm:
.head now uses generic R::I.SeqNextNFromIterator
jnthn lizmat: iirc, dyn only walks the dynamic chain, and lexcaller looks in the lexical scopes of each step along the dynamic chain 21:48
lizmat any reason why one is used on .match and the other in .subst ?
ok, must be late, but what is the difference ? 21:50
jnthn I guess the difference would show up if you had a sub that returns a closure that does a match 21:52
subst may well have been thought out a bit better in this regard because the visibility of $/ is more important
lizmat jnthn: so getexdyn would be better in all cases? 21:56
jnthn Maybe. I guess "try it (not the day before a release) and see if there's fallout" 21:58
It seems odd they differ
lizmat yeah, all of my Str.match work is going to be pushed post release
except maybe some support stuff :-)
jnthn :)
Wise move :) 21:59
timotimo the wise moo 22:05
jnthn Enough bull from me today. :) 'night 22:18
dalek kudo/nom: a8221ee | lizmat++ | src/core/Iterator.pm:
Add Iterator.skip-at-least-pull-one

Skip at least N values of the iterator, and return the result of the next pull-one.
Initially I thought about adding this as a method to Rakudo::Internals, but it seemed more logical to add it here. Although this may have adverse effects, as now every class that does Iterator will have a copy of this method?		 22:34
lizmat good night, #perl6-dev! 22:47

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!