Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6-dev, 2016-10-14

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

All times shown according to UTC.

Time Nick Message
00:05 dalek rakudo/nom: a09c8dc | (Zoffix Znet)++ | src/core/Mix (2 files):
00:05 dalek rakudo/nom: Make Mix/MixHash.Bag/BagHash .Int not .round
00:05 dalek rakudo/nom:
00:05 dalek rakudo/nom: Per discussion[^1] with lizmat++ and TimToady++, the .Int is more correct here.
00:05 dalek rakudo/nom: Also, it is 4.8 times faster... Yey performance gains \o/
00:05 dalek rakudo/nom:
00:05 dalek rakudo/nom: [1] https://irclog.perlgeek.de/perl6-dev/2016-10-13#i_13399264
00:05 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/a09c8dc99e
00:06 dalek roast: 887a35f | (Zoffix Znet)++ | S02-types/mix (2 files):
00:06 dalek roast: Correct Mix/MixHash.Bag/BagHash test
00:06 dalek roast:
00:06 dalek roast: The correct behaviour is for weights to be .Inted, not .rounded. The test was
00:06 dalek roast: added today, as part of coverage work and after a discussion[^1], the behaviour
00:06 dalek roast: has been amended[^2].
00:06 dalek roast:
00:06 dalek roast: [1] https://irclog.perlgeek.de/perl6-dev/2016-10-13#i_13399264
00:06 dalek roast: [2] https://github.com/rakudo/rakudo/commit/a09c8dc99e
00:06 dalek roast: review: https://github.com/perl6/roast/commit/887a35fdcd
00:23 Zoffix__ joined #perl6-dev
00:26 Zoffix___ joined #perl6-dev
00:31 Zoffix joined #perl6-dev
00:37 psch joined #perl6-dev
00:37 [Coke] joined #perl6-dev
00:37 moritz joined #perl6-dev
00:47 Zoffix What does this bit do? It seems to fetch an attribute and set it right back in: https://github.com/rakudo/rakudo/blob/nom/src/core/Baggy.pm#L72-L74
00:48 geekosaur decontainerizes all of them in one go
00:48 geekosaur after setting %!elems to the raw elems passed in, which might include containers
00:48 Zoffix OK. Thanks.
01:19 MasterDuke joined #perl6-dev
01:24 Zoffix Hm. Found a strange bug in core that I can't reproduce.
01:25 Zoffix m: Bag.new-from-pairs: 1 => -1;
01:25 camelia rakudo-moar a09c8d: OUTPUT«Use of Nil in string context␤  in block <unit> at <tmp> line 1␤Use of Nil in string context␤  in block <unit> at <tmp> line 1␤Found negative values for  in ␤  in block <unit> at <tmp> line 1␤␤Actually thrown at:␤  in block <unit> at <tmp> l…»
01:25 Zoffix Those Nils? It's the two interpolated blocks on this line: https://github.com/rakudo/rakudo/blob/nom/src/core/Baggy.pm#L48
01:25 Zoffix If I change it to this: my $wat = @toolow.join:  ' '; my $name = self.^name; fail "Found negative values for $wat in $name" if @toolow;      then the bug goes away.
01:25 Zoffix m: role Foo { method !meow { my @meows = <foo bar ber>; fail "some {@meows}" if @meows; }; method moo { self!meow; 42 } }; class :: does Foo {}.moo
01:25 camelia rakudo-moar a09c8d: OUTPUT«some foo bar ber␤  in method meow at <tmp> line 1␤  in method moo at <tmp> line 1␤  in block <unit> at <tmp> line 1␤␤Actually thrown at:␤  in method moo at <tmp> line 1␤  in block <unit> at <tmp> line 1␤␤»
01:26 Zoffix But can't reproduce it ^ :/
01:26 MasterDuke committable6: releases Bag.new-from-pairs: 1 => -1
01:27 Zoffix It'll be muddied up by Baggy reorganization
01:28 MasterDuke uh oh, it ran into a bad tar file anyway
01:32 Zoffix Rakudobugged: https://rt.perl.org/Ticket/Display.html?id=129874
01:35 Zoffix m: role Foo { method !meow (-->Nil) { my @meows = <foo bar ber>; fail "some {@meows}" if @meows; }; method moo { self!meow; 42 } }; class :: does Foo {}.moo
01:35 camelia rakudo-moar a09c8d: OUTPUT«Use of Nil in string context␤  in method meow at <tmp> line 1␤some ␤  in method meow at <tmp> line 1␤  in method moo at <tmp> line 1␤  in block <unit> at <tmp> line 1␤␤Actually thrown at:␤  in method moo at <tmp> line 1␤  in block <unit> …»
01:35 Zoffix haw
01:36 Zoffix m: sub (-->Nil) { fail "{42}"; }()
01:36 camelia rakudo-moar a09c8d: OUTPUT«Use of Nil in string context␤  in sub  at <tmp> line 1␤␤  in sub  at <tmp> line 1␤  in block <unit> at <tmp> line 1␤␤Actually thrown at:␤  in block <unit> at <tmp> line 1␤␤»
01:38 Zoffix m: sub (-->Nil) { say "wat {42} heh"; }()
01:38 camelia rakudo-moar a09c8d: OUTPUT«Use of Nil in string context␤  in sub  at <tmp> line 1␤wat  heh␤»
01:38 Zoffix m: sub () { say "wat {42} heh"; }()
01:38 camelia rakudo-moar a09c8d: OUTPUT«wat 42 heh␤»
01:38 Zoffix trippy
01:38 MasterDuke damn weird
01:41 geekosaur mm? should produce the last value, which will be 1
01:41 Zoffix Huh?
01:41 geekosaur m: dd (sub () { say "wat {42} heh"; })()
01:41 camelia rakudo-moar a09c8d: OUTPUT«wat 42 heh␤Bool::True␤»
01:41 geekosaur oh, True, sorry
01:41 geekosaur return value of say, which will be success/failure of the write on stdouyt
01:42 Zoffix Yeah, but I'm not outputting that value.
01:46 Zoffix I'm trying to `say` a string inside a sub that has an interpolated block and that block is affected.
01:46 geekosaur right, but without the --> Nil you are producing the result of that say, which is Bool
01:46 * Zoffix doesn't get the relevance
01:46 Zoffix It doesn't get returned from a sub with -->Nil in it
01:46 Zoffix m: dd sub (-->Nil) { 'whatever' }()
01:46 camelia rakudo-moar a09c8d: OUTPUT«WARNINGS for <tmp>:␤Useless use of constant string "whatever" in sink context (line 1)␤Nil␤»
01:46 Zoffix m: sub () { say "wat {42} heh"; 42 }()
01:46 camelia rakudo-moar a09c8d: OUTPUT«wat 42 heh␤»
01:46 geekosaur looks to me like you were trying to tell why it was behaving differently between the two
01:46 Zoffix m: sub (-->Nil) { say "wat {42} heh"; 42 }()
01:46 camelia rakudo-moar a09c8d: OUTPUT«WARNINGS for <tmp>:␤Useless use of constant integer 42 in sink context (line 1)␤Use of Nil in string context␤  in sub  at <tmp> line 1␤wat  heh␤»
01:46 Zoffix geekosaur, yes, I am.
01:46 Zoffix geekosaur, it's a bug.
01:46 Zoffix The string that should not be affected is affected by the sub's return constraint.
01:46 * geekosaur is not seeing that here
01:46 Zoffix The say should output "wat 42 heh", but it outputs "wat heh" (along with a Nil warning)
01:46 * geekosaur ... finally spots the {} vs. (). sorry
01:49 ilbot3 joined #perl6-dev
01:49 Topic for #perl6-dev is now Perl 6 language and compiler development 2.0 | Logs at http://irclog.perlgeek.de/perl6-dev/today
02:17 MasterDuke .tell psch you seem to know a bit about the JVM implementation, any suggestions for how to tackle the BOOTSTRAPATTR -> Attribute problem i've been working on?
02:17 yoleaux2 MasterDuke: I'll pass your message to psch.
02:17 MasterDuke .tell pmurias you seem to know a bit about the JVM implementation, any suggestions for how to tackle the BOOTSTRAPATTR -> Attribute problem i've been working on?
02:17 yoleaux2 MasterDuke: I'll pass your message to pmurias.
02:42 AlexDaniel committable6: releases Bag.new-from-pairs: 1 => -1
02:43 committable6 AlexDaniel, https://gist.github.com/1f32141e3ac0a2dbc4f775ad4a903990
02:44 AlexDaniel MasterDuke: “Found negative values for in” /o\
05:23 travis-ci joined #perl6-dev
05:23 travis-ci Rakudo build failed. Zoffix Znet 'Revert "Convert some BOOTSTRAPATTRs to Attributes"
05:23 travis-ci https://travis-ci.org/rakudo/rakudo/builds/167363851 https://github.com/rakudo/rakudo/compare/5b6f4b6fb522...2d5a2c9d167b
05:23 travis-ci left #perl6-dev
05:23 buggable [travis build above] ☠ Did not recognize some failures. Check results manually.
05:32 [Tux] joined #perl6-dev
06:12 [Tux] This is Rakudo version 2016.09-193-ga09c8dc built on MoarVM version 2016.09-47-g736364c
06:12 [Tux] csv-ip5xs        3.337
06:12 [Tux] test            16.060
06:12 [Tux] test-t           6.970
06:12 [Tux] csv-parser      17.544
06:53 [Tux] joined #perl6-dev
07:07 [Tux] joined #perl6-dev
07:39 travis-ci joined #perl6-dev
07:39 travis-ci Rakudo build failed. Zoffix Znet 'Fix Mixy.Bag/.BagHash coercers
07:39 travis-ci https://travis-ci.org/rakudo/rakudo/builds/167376704 https://github.com/rakudo/rakudo/compare/2d5a2c9d167b...bf7945eec5e4
07:39 travis-ci left #perl6-dev
07:39 buggable [travis build above] ☠ Did not recognize some failures. Check results manually. All failures are on JVM only.
08:01 AlexDaniel joined #perl6-dev
08:11 RabidGravy joined #perl6-dev
08:31 psch ~
08:31 yoleaux2 02:17Z <MasterDuke> psch: you seem to know a bit about the JVM implementation, any suggestions for how to tackle the BOOTSTRAPATTR -> Attribute problem i've been working on?
08:33 psch MasterDuke: well, assuming you did the same thing to HEAD as i did to get the "Flattening named mumble VMHash mumble" error -- which is adding istype Mu checks -- i don't think that's the right solution
08:55 AlexDaniel joined #perl6-dev
09:09 geekosaur joined #perl6-dev
09:19 psch s/to/past/
09:28 travis-ci joined #perl6-dev
09:28 travis-ci Rakudo build failed. Zoffix Znet 'Fix Cool.IO coercion
09:28 travis-ci https://travis-ci.org/rakudo/rakudo/builds/167455558 https://github.com/rakudo/rakudo/compare/bf7945eec5e4...7f16cbbc4556
09:28 travis-ci left #perl6-dev
09:28 buggable [travis build above] ☠ Did not recognize some failures. Check results manually. All failures are on JVM only.
09:29 dalek nqp: b392903 | MasterDuke17++ | src/vm/jvm/runtime/org/perl6/nqp/runtime/CallSiteDescriptor.java:
09:29 dalek nqp: Include the bad REPR type in error message
09:29 dalek nqp: review: https://github.com/perl6/nqp/commit/b3929037b3
09:29 dalek nqp: 670806b | jnthn++ | src/vm/jvm/runtime/org/perl6/nqp/runtime/CallSiteDescriptor.java:
09:29 dalek nqp: Merge pull request #312 from MasterDuke17/remove_BOOTSTRAPATTR_where_possible
09:29 dalek nqp:
09:29 dalek nqp: Include the bad REPR type in error message
09:29 dalek nqp: review: https://github.com/perl6/nqp/commit/670806b144
09:30 psch oh, there was a PR sitting there...
09:30 jnthn Figured I'd do something useful and merge a PR while waiting for a build :)
09:31 psch yeah, i straight up didn't check...
09:32 psch cool, so i'll build nqp HEAD and nom HEAD and see if that works, and if not why not
09:33 psch from the looks of it, if we do check for $!compstuff ~~ Mu it works when we don't have Capture with Attribute instead of BOOTSTRAPATTR
09:33 psch which seems to mean that bindcapsig or something is not deconting/dehllizing enough i guess
09:39 psch uhm, nqp HEAD doesn't build
09:39 psch the indexingoptimized impl seems to be incomplete
09:42 psch ah
09:43 psch no stage0 bump for jvm
09:43 psch so we try to compile stage1, which uses indexingoptimized, without a stage0 that knows indexingoptimized
09:44 jnthn o.O
09:45 jnthn Yeah, I had it #?if moar'd so I'd not have to do that dance with the JVM
09:45 jnthn I guess somebody decided to...
09:45 psch pmurias i think brought it to all backends
09:45 psch though as noop on jvm i think?
09:45 jnthn Though not sure how they'd have gotten it to build
09:45 jnthn Ah
09:45 psch well, i'd assume the jvm hasn't been build with the op implemented :)
09:45 jnthn It should just return identity on JVM, yeah
09:46 jnthn Yeah, ops that get used in the NQP source need a bootstrap update
09:46 jnthn So that you compile with a compiler that knows about them
09:46 jnthn Maybe the JavaScript backend late-binds things enough to get away with it
09:48 psch so i remove all the uses of indexingoptimized, rebuild with the op defined but unused, then run the make target that copies to stage0/ and then reintroduce the usage of the op and build again to see everything works..?
09:49 jnthn Yes
09:50 Zoffix left #perl6-dev
09:50 Zoffix joined #perl6-dev
10:09 psch well, it builds at least
10:09 psch got 5 failures in t/qast/01-qast.t though :l
10:11 psch three about state vars, two about boxing...
10:14 Zoffix :(
10:14 Zoffix .oO( at least it's not about wrestling... )
10:15 psch i think we have that ticketed on the rakudo level though
10:15 psch i mean, something being wonky with state var
10:15 psch maybe i can figure it out :S
10:16 psch r: sub f { loop { say $++; last } }; f;f;f;f; #128661
10:16 camelia rakudo-moar a09c8d: OUTPUT«0␤0␤0␤0␤»
10:16 camelia ..rakudo-jvm 2a1605: OUTPUT«0␤1␤2␤3␤»
10:16 psch RT #128661 # /o\
10:16 psch anyway, yeah
10:16 psch that's probably it
10:17 psch or rather, that'll fall out from passing the nqp test, i hope :)
10:20 Zoffix Is that JVM-only failure?
10:20 Zoffix All tests were passing on last release.
10:21 psch it's nqp
10:21 psch at least the failing test i'm talking about
10:21 psch and yes, it's jvm :)
10:21 psch i'm not really testing anything else tbh :P
10:22 Zoffix So are we going to release despite that regression or does it need to be fixed before the release?
10:23 psch well, the nqp test is from 2016-10-08
10:23 psch and the rakudo level bug is ticketed since 2016-07-18
10:24 Zoffix ok
10:24 psch so i don't think it's really a regression
10:24 psch we just didn't test for it in nqp before, and might still not test for it in roast
10:24 Zoffix We don't have any fudging mechanism in nqp, do we?
10:24 psch nope
10:25 Zoffix 'cause that failure will make the release robot abort :( I guess I'll need to teach it to ignore it when told to
10:25 psch are we releasing nqp-j and r-j?
10:25 psch i wasn't aware
10:26 psch maybe i'm thinking star
10:26 Zoffix I was running nqp-j tests in last releases... but mostly 'cause they were passing, I guess :)
10:26 Zoffix Last release, I was unable to build r-j, so I ran no tests.
10:27 Zoffix Or maybe it did build but R test suite was failing. it's the stuff you fixed for travis
10:27 psch that was mostly NativeCall iirc..?
10:27 Zoffix yeah
10:37 Zoffix I think we should comment out the failing test for the release and then uncomment it. To avoid confusion for whoever may be building/packaging this downstream and seeing test failures where none were in the past.
11:26 psch hmm, the state var setup code does look pretty much identical across the two backends i looked at :/
11:28 psch https://github.com/MoarVM/MoarVM/blob/master/src/core/frame.c#L598
11:28 psch https://github.com/perl6/nqp/blob/master/src/vm/jvm/runtime/org/perl6/nqp/runtime/CallFrame.java#L148
11:28 psch except, well, C is obviously a bit more verbose there
11:28 psch but maybe i'm also just missing something really obvious vOv
11:30 psch wait, there's one difference i think?
11:31 psch moar allocates a new MVMRegister, while JVM just assigns something from the staticCodeInfo
11:32 psch otoh, we clone on JVM..?
11:43 MasterDuke_ joined #perl6-dev
11:46 MasterDuke_ psch: i'm not sure what you mean by "adding istype Mu checks". i was getting the flattening error on the branch that had my second PR (with my first PR already merged)
11:46 psch MasterDuke_: which branch?
11:47 MasterDuke_ https://github.com/MasterDuke17/rakudo/tree/remove_BOOTSTRAPATTR_where_possible
11:48 MasterDuke_ my second PR was this commit: https://github.com/rakudo/rakudo/pull/902/commits/c4d6b12367e28a2af07030190d07cdf106d79c19
11:50 psch okay, so whatever i'm doing on nom/HEAD probably has nothing at all to do with what you're doing
11:50 MasterDuke_ at first i thought it was just the changes to the Code class, but if i put all its Attributes back to BOOTSTRAPATTR i was getting the same error
11:50 MasterDuke_ oh interesting, so you are getting the same error with your work?
11:50 psch anyway, what i *did* figure out is that adding a 'nqp::istype($cs, Mu)' check in all the spots that deal with $!compstuff and also reverting the Capture Attributes to BOOTSTRAPATTR makes it work
11:51 psch where $!compstuff is a Code Attribute
11:52 psch that was against todays HEAD, maybe like 3 hours ago or so i think
11:52 psch since then i've been poking at nqp-j instead because that's broken too
11:52 psch or rather, we have new tests :)
11:52 psch so, i'm thinking that p6bindcaptosig is what doesn't know how to deal with Attribute instead of BOOTSTRAPATTR
11:53 psch but yeah, i haven't looked closer at it
11:54 MasterDuke_ cool, that's more progress than i made
12:04 psch okay, that branch merged rebased onto nom builds fine here
12:04 psch ...i think
12:04 psch i might've mishandled git :)
12:07 p3rln00b https://xkcd.com/1597/
12:11 MasterDuke_ my branch? nice, what'd you do to fix it?
12:12 psch nothing?  i pulled it against nom
12:12 MasterDuke_ huh. did you do a make install?
12:13 psch i think so, yeah
12:13 psch but well, i'm not really sure git did what i thought it did so yeah
12:13 MasterDuke_ ha
12:16 psch i'm also somewhat confused with the commits in the branch, honestly
12:20 MasterDuke_ well, there may have been some git mishaps on my end also
12:21 MasterDuke_ on that branch i first made two commits, those were merged into nom with my first PR
12:22 p3rln00b m: class Foo { method dispatch:<!>(Mu \SELF: \name, Mu \type, |c) { say 'cannot call that, bruh' }; }!meow
12:22 camelia rakudo-moar a09c8d: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Private method call to meow must be fully qualified with the package containing the method␤at <tmp>:1␤------> { say 'cannot call that, bruh' }; }!meow⏏<EOL>␤    expecting any of:␤        met…»
12:22 MasterDuke_ then i made another commit, and created a PR for that
12:23 p3rln00b What's all of these dispatch:<> methods? Are they available to users to override? https://github.com/rakudo/rakudo/blob/nom/src/core/Mu.pm#L658
12:23 MasterDuke_ but somewhere along the way i merged nom into the branch and pushed the commits it brought along
12:24 MasterDuke_ or is it my commits you're confused about?
12:25 psch MasterDuke_: well, 26 behind and 18 ahead doesn't seem right is all
12:25 psch commits that is
12:25 p3rln00b m: class Foo { method dispatch:<.*>(Mu \SELF: \name, |c) { say 'cannot call that, bruh' }; }.*meow
12:25 camelia rakudo-moar a09c8d: OUTPUT«cannot call that, bruh␤»
12:25 p3rln00b w00t
12:25 psch p3rln00b: you can't use ! like that is the error
12:26 p3rln00b psch: to me it looks like a bug vis-a-vis overriding dispatch:<!> method
12:26 psch m: class Foo { method dispatch:<!>(Mu \m, |c) { say "nope" }; method bar { self!whatever } }; Foo.new.bar
12:26 camelia rakudo-moar a09c8d: OUTPUT«===SORRY!=== Error while compiling <tmp>␤No such private method 'whatever' for invocant of type 'Foo'␤at <tmp>:1␤------> , |c) { say "nope" }; method bar { self!⏏whatever } }; Foo.new.bar␤»
12:26 MasterDuke_ psch: yeah, i may have done the merge/push/whatever incorrectly
12:26 psch m: class Foo { method dispatch:<!>(Mu \m, |c) { say "nope" }; method bar { self!whatever }; method !whatever { }  }; Foo.new.bar
12:26 camelia rakudo-moar a09c8d: ( no output )
12:26 p3rln00b m: class Foo { method dispatch:<.+>(Mu \SELF: \name, |c) { say "cannot call {name} like that, bruh" }; }.+meow
12:26 camelia rakudo-moar a09c8d: OUTPUT«cannot call meow like that, bruh␤»
12:27 psch p3rln00b: there might be something wrong with overriding dispatch:<!>, but it's not that you cannot call a private method from outside the class
12:27 psch m: class Foo { method !bar { } }!bar
12:27 camelia rakudo-moar a09c8d: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Private method call to bar must be fully qualified with the package containing the method␤at <tmp>:1␤------> class Foo { method !bar { } }!bar⏏<EOL>␤    expecting any of:␤        method argu…»
12:27 psch ^^^ that error always happens like that
12:27 p3rln00b psch: ah, ok
12:27 p3rln00b I see what you mean
12:28 psch MasterDuke_: fwiw, after each PR i always ditch the branch completely, and branch again from the upstream HEAD, nom in our case
12:29 psch MasterDuke_: anyway, afaict the issue is with whatever we get in p6bindcaptosig, and how we don't handle that correctly
12:29 psch MasterDuke_: the interesting question is, why does what arrives there change on jvm and not on moar
12:30 MasterDuke_ psch: that's what i've done in the past (and probably exclusively will do from now on!), but in this case i was pretty sure i would do multiple PRs that were all very related
12:31 MasterDuke_ psch: yep, and unfortunately i know very little about the JVM implementation
12:33 tadzik joined #perl6-dev
12:34 MasterDuke_ but i am willing to try and learn more
12:34 psch cool :)
12:35 psch the place stuff goes wrong is in CallSiteDescriptor.explodeFlattening
12:36 moritz it has explode in the name, what do you expect? :-)
12:36 psch afair my debugging there we get a 2-elem array in oldArgs, where the first is a VMArray and the second is Mu
12:36 dalek roast: 001fb73 | (Zoffix Znet)++ | S02-types/mu.t:
12:36 dalek roast: [coverage] Cover all routine calls in Mu
12:36 dalek roast: review: https://github.com/perl6/roast/commit/001fb7352a
12:36 psch so i'd assume that somehow the %hash part of the Capture doesn't make it, for one reason or another
12:37 dalek rakudo/nom: e4fdc32 | (Zoffix Znet)++ | t/spectest.data:
12:37 dalek rakudo/nom: Add S02-types/mu.t test file to list of files to run
12:37 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/e4fdc32d6d
12:37 psch i could work around that by not converting Capture to Attribute and adding the istype Mu checks for $!compstuff, as mentioned  earlier
12:37 psch buut i didn't save any of that anywhere and messed around a lot with my repo so yeah :P
12:41 MasterDuke_ and after you did that the rest of the BOOTSTRAPATTR -> Attribute changes worked fine you say? make install worked, did you run a j-spectest?
12:42 psch i only ran 'make test' iirc
12:46 MasterDuke_ well, that's farther than i got
13:00 dalek nqp: a365b62 | peschwa++ | src/vm/jvm/stage0/ (10 files):
13:00 dalek nqp: Update JVM stage0
13:00 dalek nqp: review: https://github.com/perl6/nqp/commit/a365b624be
13:00 NeuralAnomaly joined #perl6-dev
13:00 buggable joined #perl6-dev
13:01 huggable joined #perl6-dev
13:01 p3rln00b .tell p3rln00b test
13:01 yoleaux2 p3rln00b: Talking to yourself is the first sign of madness.
13:08 p3rln00b m: { CONTROL { when CX::Warn { say "caught"; } }; warn 'foo'; say "hi"; }
13:08 camelia rakudo-moar e4fdc3: OUTPUT«caught␤»
13:08 p3rln00b TIL catching warnings aborts further code in that block
13:08 psch m: { CONTROL { when CX::Warn { say "caught"; .resume } }; warn 'foo'; say "hi"; }
13:08 camelia rakudo-moar e4fdc3: OUTPUT«caught␤hi␤»
13:09 p3rln00b m: { { warn 'foo'; say "hi"; }; CONTROL { when CX::Warn { say "caught"; } }; }
13:09 camelia rakudo-moar e4fdc3: OUTPUT«caught␤»
13:09 p3rln00b It's kinda like you're fatalizing them :/
13:09 jnthn No, it's just completley normal exception handling semantics
13:09 jnthn If you want to resume, you write that in the handler
13:09 p3rln00b m: { CONTROL { when CX::Warn { say "caught"; .resume } }; warn 'foo'; say "hi"; }
13:09 camelia rakudo-moar e4fdc3: OUTPUT«caught␤hi␤»
13:09 p3rln00b Neat.
13:10 jnthn warn is one of the few exception handlers where you do what to resume (even other control exceptions don't want that)
13:10 jnthn Well, except take I guess :)
13:11 jnthn But it's unusual to be writing a custom handler for take :)
13:17 p3rln00b ZOFVM: Files=1197, Tests=129741, 135 wallclock secs (21.25 usr  3.16 sys + 2396.22 cusr 204.47 csys = 2625.10 CPU)
13:18 dalek rakudo/nom: b08ef96 | (Zoffix Znet)++ | src/core/Nil.pm:
13:18 dalek rakudo/nom: Fix Nil.chrs
13:18 dalek rakudo/nom:
13:18 dalek rakudo/nom: .chrs wants to be called on an Int, not a Str. I suspect the .Str
13:18 dalek rakudo/nom: coersion was accidentally copy-pastaed from Nil.ords method.
13:18 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/b08ef9666e
13:18 dalek roast: ea0aeff | (Zoffix Znet)++ | S02-types/nil.t:
13:18 dalek roast: [coverage] Cover all naked methods in Nil.pm
13:18 dalek roast: review: https://github.com/perl6/roast/commit/ea0aeffe63
13:24 p3rln00b m: my $x = 42 but role meow {}; dd $x; $x++; dd $x
13:24 camelia rakudo-moar e4fdc3: OUTPUT«Int+{meow} $x = 42␤Int $x = 43␤»
13:25 p3rln00b Is this a bug? I very vaguelly recall this discussed before.
13:25 gfldex no
13:25 p3rln00b OK
13:25 gfldex the mixin happens on the object
13:29 p3rln00b Yeah. I pictured it more like a method call, rather than a sub that takes two things and makes a new thing out of them, for a second.
13:42 gfldex m: class A {}; role R { method m { say 'oi‽' } }; my $A = A but R; my $a1 = $A.new; $a1.m; my $a2 = $A.new; $a2.m;
13:42 camelia rakudo-moar b08ef9: OUTPUT«oi‽␤oi‽␤»
13:50 p3rln00b m: sub postfix:<++> (Any:D \x) {my \z = x; x.new: x+1; z }; my $x = 42 but role meow {}; dd $x; $x++; dd $x
13:50 camelia rakudo-moar b08ef9: OUTPUT«Int+{meow} $x = 42␤Int+{meow} $x = 42␤»
13:51 p3rln00b m: sub postfix:<++> (Any:D \x) {my \z = x; x = x.new: x+1; z }; my $x = 42 but role meow {}; dd $x; $x++; dd $x
13:51 camelia rakudo-moar b08ef9: OUTPUT«Int+{meow} $x = 42␤Int $x = 43␤»
13:51 p3rln00b Ah, right.
13:51 p3rln00b Int's .new is speshul
13:53 dalek rakudo/nom: 0337137 | lizmat++ | src/core/Str.pm:
13:53 dalek rakudo/nom: Guard .split when there is no .match
13:53 dalek rakudo/nom:
13:53 dalek rakudo/nom: Basically, guard it from handling a List without $!reified, which
13:53 dalek rakudo/nom: will be the case after the Str.match refactor.
13:53 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/0337137476
14:14 lizmat m: say "1234567890".match(/./,:x(3..4)) # is this correct behaviour ?
14:14 camelia rakudo-moar 033713: OUTPUT«(「1」 「2」 「3」 「4」)␤»
14:14 lizmat if so: yuck  :-)
14:16 lizmat also, why isn't there any documentation on Str.match (at least on https://docs.perl6.org/type/Str)
14:17 p3rln00b I recall opening an issue about that.
14:18 p3rln00b There some docs for the adverbs on https://docs.perl6.org/routine/subst (bottom page)
14:19 p3rln00b The types are wrong tho: https://github.com/perl6/doc/issues/919
14:20 p3rln00b s/wrong/don't match implementation/;
14:20 lizmat yeah... there's a lot of that  :-(
14:20 p3rln00b I'd expect :x(3..4) to give 3rd and 4th matches
14:20 lizmat am going to think about that
14:21 lizmat yes, me too, but if you don't do that, a lot of internals break
14:21 lizmat if you want 3rd and 4th match, you need to do :nth(3..4)
14:21 p3rln00b oh
14:21 lizmat anyways, going to think about this with some fresh air
14:21 lizmat Ah, and the good news is:
14:21 p3rln00b m: say "123".match(/./,:x(4))
14:21 camelia rakudo-moar 033713: OUTPUT«()␤»
14:22 p3rln00b m: say "123".match(/./,:x(3..4))
14:22 camelia rakudo-moar 033713: OUTPUT«(「1」 「2」 「3」)␤»
14:22 lizmat yeah, stuff like that, *sigh*
14:22 lizmat anyways, the good news is, is that Str.match will be at least 2x as fast
14:22 p3rln00b lizmat: then the current behaviour makes sense to me. :x(Range) gives at most Range matches
14:22 p3rln00b wooo \o/
14:22 lizmat but that will be for after the release  :-)
14:23 lizmat afk&
14:54 FROGGS joined #perl6-dev
15:12 dalek joined #perl6-dev
15:18 travis-ci joined #perl6-dev
15:19 travis-ci Rakudo build failed. Zoffix Znet 'Add S02-types/mu.t test file to list of files to run'
15:19 travis-ci https://travis-ci.org/rakudo/rakudo/builds/167632421 https://github.com/rakudo/rakudo/compare/a09c8dc99ef7...e4fdc32d6d90
15:19 travis-ci left #perl6-dev
15:19 buggable [travis build above] ☠ Did not recognize some failures. Check results manually. All failures are on JVM only.
15:20 FROGGS o/
15:23 p3rln00b \o\
15:25 p3rln00b m: rand()
15:25 camelia rakudo-moar 033713: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Unsupported use of rand(); in Perl 6 please use rand␤at <tmp>:1␤------> rand⏏()␤»
15:25 p3rln00b Inturresting...
15:26 p3rln00b m: say &rand
15:26 camelia rakudo-moar 033713: OUTPUT«sub rand ( --> Num:D) { #`(Sub+{Callable[Num:D]}|58001408) ... }␤»
15:26 p3rln00b m: my &fancyrand = &rand; fancyrand()
15:26 camelia rakudo-moar 033713: ( no output )
15:26 p3rln00b m: my &fancyrand = &rand; fancyrand().say
15:26 camelia rakudo-moar 033713: OUTPUT«0.45808259520736␤»
15:27 p3rln00b How come we got two of them? The other one is, allegedly, uncovered living as a sub in Num: http://perl6.wtf/src_core_Num.pm.coverage.html#L442
15:30 p3rln00b And from what I understand, the `rand` just calls rand(): https://github.com/rakudo/rakudo/blob/nom/src/Perl6/Actions.nqp#L5381
15:30 p3rln00b OOC, how come we can't call rand?
15:30 p3rln00b *rand()
15:31 moritz because it's a term
15:31 moritz if it were a function, rand - 0.5 wouldn't DWIM, or some such
15:32 p3rln00b Ahh. Thanks
15:47 p3rln00b m: my Num $v; ($v++).^name.say;
15:47 camelia rakudo-moar 033713: OUTPUT«Int␤»
15:48 p3rln00b Oh, it's a trivial fix. I can do it on my own :P
15:49 p3rln00b Making it another bug found by coverage reports \o/
15:55 japhb p3rln00b: How many is that now?
15:58 p3rln00b japhb: not sure. Lots. Enough to make a nice bug sandwich :) Second one just today.
16:00 dalek rakudo/nom: 8268ffb | (Zoffix Znet)++ | src/core/Num.pm:
16:00 dalek rakudo/nom: Fix Num:U++
16:00 dalek rakudo/nom:
16:00 dalek rakudo/nom: The postfix increment on a :U type is meant to return zero, but here it
16:00 dalek rakudo/nom: returns an Int zero instead of a Num zero.
16:00 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/8268ffbc1a
16:01 FROGGS m: my Num $v; ($v--).^name.say;
16:01 camelia rakudo-moar 033713: OUTPUT«Num␤»
16:01 FROGGS m: my Num $v; (++$v).^name.say;
16:01 camelia rakudo-moar 033713: OUTPUT«Num␤»
16:01 FROGGS m: my Num $v; (--$v).^name.say;
16:01 camelia rakudo-moar 033713: OUTPUT«Num␤»
16:01 FROGGS :o)
16:09 tbrowder Zoffix: ref roast and fudged tests: do I have to add the fudge-generated file to spectest.data?
16:10 p3rln00b tbrowder: no, the original
16:11 p3rln00b m: my int $x; my num $v; dd [ $x, $v ]
16:11 camelia rakudo-moar 033713: OUTPUT«[0, NaN]␤»
16:11 tbrowder Okay, thanks!
16:11 p3rln00b So default num is a NaN? That's correct, right?
16:12 ilmari m: say Num.new
16:12 camelia rakudo-moar 8268ff: OUTPUT«0␤»
16:12 ilmari m: say num.new
16:12 camelia rakudo-moar 8268ff: OUTPUT«0e0␤»
16:13 p3rln00b 'cause it messes up postfix ++/--
16:13 p3rln00b m: dd (my num $)++;
16:13 camelia rakudo-moar 8268ff: OUTPUT«NaN␤»
16:14 gfldex float does provide a undefined value. No reason not to use it.
16:15 gfldex m: say NaN.defined;
16:15 camelia rakudo-moar 8268ff: OUTPUT«True␤»
16:15 gfldex i take that back
16:16 p3rln00b Oh, prefix is also ded
16:16 gfldex problem is that natives don't fit all that well into the type system of Perl 6
16:16 p3rln00b m: dd --(my num $);
16:16 camelia rakudo-moar 8268ff: OUTPUT«NaN␤»
16:16 p3rln00b m: dd --(my Num $);
16:17 camelia rakudo-moar 8268ff: OUTPUT«-1e0␤»
16:17 gfldex also, --(my num $) may be platform dependent
16:17 p3rln00b Why?
16:18 gfldex num maps to double and that is meant to be handled by the CPU
16:18 p3rln00b What about --(my int $)?
16:19 timotimo no, it's just that the default value of a native num var is not 0.0, it's NaN
16:19 timotimo it's strange to have that differ from the Num default value, though
16:21 p3rln00b OK. Then I'm making the tests to expect a NaN
16:22 gfldex see http://design.perl6.org/S02.html#line_787
16:23 gfldex IIRC that is a hole in the spec/rakudo
16:23 gfldex p3rln00b: you may want to invoke [Larry]
16:23 timotimo Since native types cannot represent Perl's concept of undefined values, in the absence of explicit initialization, native floating-point types default to NaN, while integer types (including bit) default to 0.
16:25 p3rln00b m: use Test; is-deeply NaN, NaN
16:25 camelia rakudo-moar 8268ff: OUTPUT«not ok 1 - ␤␤# Failed test at <tmp> line 1␤# expected: NaN␤#      got: NaN␤»
16:26 p3rln00b Maybe we should amend it watch for this special case
16:26 timotimo m: use Test; is NaN, NaN
16:26 camelia rakudo-moar 8268ff: OUTPUT«ok 1 - ␤»
16:26 geekosaur NaN is a lousy choice, and I could argue that this is similar to how Date was using two different defaults (today vs. release date)
16:26 gfldex m: use Test; ok NaN === NaN
16:26 camelia rakudo-moar 8268ff: OUTPUT«ok 1 - ␤»
16:26 geekosaur 0 makes more sense, and doesn't drag IEEE754 semantics into things unexpectedly
16:27 p3rln00b m: use Test; is 'NaN', NaN
16:27 camelia rakudo-moar 8268ff: OUTPUT«ok 1 - ␤»
16:27 gfldex the whole point of native types is to drag IEEE754 semantics into Perl 6
16:28 gfldex that's why I wont use them :)
16:28 geekosaur I mean having them appear immediately when a value is created seems like asking for trouble
16:29 geekosaur basically it feels to me like someone wanted to treat NaN as a native type object (or perl5 undef). it is neither and this just causes confusion for zero gain
16:29 gfldex m: say 1/NaN, 1/0
16:29 camelia rakudo-moar 8268ff: OUTPUT«Attempt to divide 1 by zero using div␤  in block <unit> at <tmp> line 1␤␤Actually thrown at:␤  in block <unit> at <tmp> line 1␤␤»
16:29 geekosaur NaN is *stranger* than a type object
16:30 dalek roast: 2a3cdb2 | (Zoffix Znet)++ | S02-types/num.t:
16:30 dalek roast: [coverage] Num.pm: cover .Range, .new, and nude pre/postfix ++/-- candidates
16:30 dalek roast: review: https://github.com/perl6/roast/commit/2a3cdb2e25
16:31 p3rln00b .tell TimToady I've added tests for uninitialized num pre/post ++/-- that expect the values to be NaN. If that's incorrect behaviour, let me know and I'll amend them: https://github.com/perl6/roast/blob/2a3cdb2e257e97d8c6dafefecc8f6221f87da80f/S02-types/num.t#L215-L217
16:31 yoleaux2 p3rln00b: I'll pass your message to TimToady.
16:31 gfldex what do c/c++ do in that case? (asking because natives are used in NCI a lot)
16:31 * p3rln00b &
16:31 gfldex well, c++ defaults to 0
16:31 gfldex but not sure about C
16:32 geekosaur C doesn't do defaults
16:33 p3rln00b .ask jnthn based on https://github.com/perl6/doc/issues/970#issuecomment-253824298  ... then this can be tossed? https://github.com/rakudo/rakudo/blob/nom/src/core/Mu.pm#L686-L688
16:33 yoleaux2 p3rln00b: I'll pass your message to jnthn.
16:33 gfldex undefined undefinedness it is
16:33 geekosaur the "default" is whatever happened to be in the memory location. for malloc from a pristine heap or calloc, it'll be 0. for non-pristine malloc or stack allocation, it'll be some value left behind by the last user of that chunk of memory
17:12 hankache joined #perl6-dev
17:18 dalek roast: f1ab1c7 | (Tom Browder)++ | S26-documentation/07 (2 files):
17:18 dalek roast: Add tests for issue RT #129862
17:18 dalek roast:
17:18 dalek roast: * split table tests into current and 'skipped'; add tests for #129862, PR903
17:18 dalek roast:
17:18 dalek roast: * add a note ref future tests
17:18 dalek roast:
17:18 dalek roast: * move toward incorporating Zoffix's comments
17:18 dalek roast:
17:18 dalek roast: * add plan back in
17:18 dalek roast:
17:18 dalek roast: * removed 'done-testing' from both table test files
17:18 dalek roast: review: https://github.com/perl6/roast/commit/f1ab1c7616
17:19 dalek roast: e596ce6 | (Zoffix Znet)++ | S26-documentation/07a-tables-todo-skipped.t:
17:19 dalek roast: Add missing plan
17:19 dalek roast: review: https://github.com/perl6/roast/commit/e596ce6635
17:20 dalek rakudo/nom: 663b03a | (Tom Browder)++ | t/spectest.data:
17:20 dalek rakudo/nom: add new test
17:20 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/663b03a94f
17:20 dalek rakudo/nom: 41c0750 | (Zoffix Znet)++ | t/spectest.data:
17:20 dalek rakudo/nom: Merge pull request #904 from tbrowder/new-test
17:20 dalek rakudo/nom:
17:20 dalek rakudo/nom: add new test
17:20 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/41c0750171
17:32 p3rln00b ZOFVM: Files=1198, Tests=129754, 135 wallclock secs (21.22 usr  3.02 sys + 2397.80 cusr 211.15 csys = 2633.19 CPU)
17:43 travis-ci joined #perl6-dev
17:43 travis-ci Rakudo build passed. Zoffix Znet 'Fix Nil.chrs
17:43 travis-ci https://travis-ci.org/rakudo/rakudo/builds/167642174 https://github.com/rakudo/rakudo/compare/e4fdc32d6d90...b08ef9666e32
17:43 travis-ci left #perl6-dev
17:48 * p3rln00b spots a travis bug
17:49 p3rln00b The closing ' is missing :) And based on chat logs, looks like it flops from being there and not being there
17:59 geekosaur it's multiline commit messages
18:00 geekosaur travis chops at the embedded newline and loses the rest of that line of the template, including the close quote
18:03 p3rln00b Ah. Mistery solved :}
18:29 AlexDaniel joined #perl6-dev
18:36 lucasb_ joined #perl6-dev
18:36 lucasb_ FWIW, I am +1 for making 'my num $x' default to 0e0
18:37 lucasb_ would there be any problem in doing that?
18:37 lucasb_ this goes against the 6.c specification/roast?
18:40 lucasb_ and for the record, in C, if the variable is a 'static', then it *is* initialized to 0.0
18:43 p3rln00b Yeah, 6.c has explicit test: is $num, NaN, 'num default value';
18:43 p3rln00b in S02-types/native.t
18:44 lucasb_ ah, I didn't know that. I find that unfortunate :(
18:46 [Coke] well, if you want it changed for 6.d, it's a possibility
18:46 jdv79_ joined #perl6-dev
18:47 [Coke] probably open a ticket on https://github.com/perl6/specs/issues ?
18:47 p3rln00b We have a document for 6d: https://github.com/perl6/specs/blob/master/v6d.pod
18:48 [Coke] the doc does make it harder to discuss individual issues.
18:48 [Coke] which I didn't think about at the time.
18:49 FROGGS_ joined #perl6-dev
18:49 p3rln00b Maybe then Issues with a 6.d label on 'em
18:50 [Coke] added a 6.d label to specs, fwiw
18:51 [Coke] I mean, we need a place to talk about possible changes, we also need a place to map out a plan.
18:51 eviltwin_b joined #perl6-dev
18:51 lucasb_ 6.d is planned for this Xmas?
18:51 p3rln00b lucasb_: no, some time next summer
18:51 lucasb_ ah, ok
18:51 [Coke] suggestion: when copying roast to a 6.d branch, maybe rip out fudged tests instead of leaving them fudged.
18:51 [Coke] lucasb_: no
18:52 [Coke] p3rln00b: ... maybe. :)
18:52 * p3rln00b is in no hurry
18:53 p3rln00b My personal feedback on roast, from someone who never read the speculations: I wish organization was different. Maybe base it on types + features. Currently we have, lists in S02 and in S32-list (IIRC) and it's just really confusing to be finding tests in the current structure.
18:53 dalek roast: 836112b | usev6++ | S17-supply/zip-latest.t:
18:53 dalek roast: Skip test for RT #128694 for JVM (hangs)
18:53 dalek roast: review: https://github.com/perl6/roast/commit/836112bd9d
18:54 masak p3rln00b: maybe the current directory structure has indeed outlived its usefulness.
18:55 masak p3rln00b: I can see it as being entirely *possible* to re-arrange everything according to a better scheme. Git even makes it kind of cheap to rename everything.
18:55 p3rln00b yeah
18:55 masak p3rln00b: the challenge will be to do some up-front design of a better structure, IMO
18:55 * p3rln00b nods
18:56 ilmari[m] joined #perl6-dev
18:58 JimmyZ joined #perl6-dev
18:59 psch [Coke]: i'm assuming by "fudged" you mean "fudged for all backends"?
19:12 psch oh, also i agree that restructuring roast is probably a good idea, but might not be worth the effort to create something significantly better
19:12 psch i recognize the weirdness in order for people who haven't read the synopses, but there is at least some order in them
19:13 p3rln00b Maybe not on 6.d but later, when it'll become even gnarlier.
19:13 p3rln00b 'cause it's not just the test file locations only, but contents of files too.
19:14 psch right, it's the pitfall with marking the synopses out of date
19:14 psch because roast was based on the structure in the synopses, and we're now saying "better don't look at the synopses" it will get weird eventually
19:14 psch note, i'm *not* saying that we need to keep the synopses up to date
19:15 [Coke] well, and that structure is from the camel
19:16 psch so maybe, going forward, the question is "how would we want a perl6 camel to be structured"
19:16 psch and then the polyglot buffs can read the spec instead of a book and instantly know the whole language ;P
19:16 psch s/the spec/roast/ #
19:17 psch ooc, how prevalent are runnable test suites as language specification anyway?
19:21 [Coke] I suspect we'll know a lot more about how a 6amel will look -after- 6.d is released.
19:28 psch okay, so we somehow have to figure out how we -- that probably is the perl6 community, not the core devs -- would structure a 6amel so we can structure roast accordingly..?
19:30 dalek joined #perl6-dev
19:30 [Coke] I mean, someone is theoreticaly working on that book.
19:30 bisectable6 joined #perl6-dev
19:30 [Coke] but I have no idea when it's due
19:30 [Coke] *cally
19:35 psch i don't think we should toss tests fudged for less-than-all backends at all, and tests fudged for all backends probably should be tossed deliberately
19:35 psch ...to get back to that
19:35 psch reason being, that there's most likely nothing in roast that doesn't have any reason behind being there
19:36 psch of course, the validity of those reasons might have changed in cases, but that's a by-case decision
19:36 psch and if "it fails on jvm" could be a reason for tossing tests r-j would be spectest clean... :)
19:36 [Coke] psch: the problem is that some of these things were added back in early pugs days.
19:37 [Coke] so the rationale for anything older than, say, GLR might want to be questioned at that point
19:37 psch [Coke]: yes, but it still demands at least some @LARRY attention
19:37 psch i'm not categorically against removing fudged tests, i'm just saying that a spec that gets reduced because the primary implementation doesn't pass it is kind of weird
19:38 psch unfortunately i'm not speaking from a position where i do have the knowledge or authority to decide if any given fudged test should go, so i'm just making more work for other volunteers with my position
19:39 psch i am willing to do a first pass, but that would probably result in 95% "can't decide" rate :S
19:42 buggable joined #perl6-dev
19:42 huggable joined #perl6-dev
19:42 NeuralAnomaly joined #perl6-dev
19:43 yoleaux2 joined #perl6-dev
19:44 Undercover joined #perl6-dev
19:56 vendethiel joined #perl6-dev
20:24 psch re #129878, which i just got an email for
20:24 psch what even is a REGIONAL INDICATOR SYMBOL LETTER
20:26 [Coke] https://en.wikipedia.org/wiki/Regional_Indicator_Symbol ?
20:26 psch oh, right, the flag building ones
20:26 masak psch: it's one of 26 letters A..Z for specifying country codes.
20:27 psch i'm not sure that makes the bug report more clear or more confusing though
20:27 psch for the record, it's about
20:27 psch m:   say ("\c[REGIONAL INDICATOR SYMBOL LETTER G]" x 2).chars #=> 2
20:27 camelia rakudo-moar 41c075: OUTPUT«2␤»
20:27 psch m:  say ([~] "\c[REGIONAL INDICATOR SYMBOL LETTER G]" xx 2).chars #=> 1
20:27 camelia rakudo-moar 41c075: OUTPUT«1␤»
20:27 psch what trips me up is infix:<x> vs infix:<xx>
20:28 psch m:  say ([~] ("\c[REGIONAL INDICATOR SYMBOL LETTER G]" xx 2)).chars #=> 1 # but extra parens don't change it
20:28 camelia rakudo-moar 41c075: OUTPUT«1␤»
20:28 psch m: my $x = "\c[REGIONAL INDICATOR SYMBOL LETTER G]"; say [~] $x, $x
20:28 camelia rakudo-moar 41c075: OUTPUT«🇬🇬␤»
20:28 psch m: my $x = "\c[REGIONAL INDICATOR SYMBOL LETTER G]"; say ([~] $x, $x).chars
20:28 camelia rakudo-moar 41c075: OUTPUT«1␤»
20:29 psch m: my $x = "\c[REGIONAL INDICATOR SYMBOL LETTER G]"; say ($x ~ $x).chars
20:29 camelia rakudo-moar 41c075: OUTPUT«1␤»
20:29 psch so maybe infix:<x> is wrong and this is tangetially related to the substr thing?
20:29 stmuk joined #perl6-dev
20:30 * psch wishes to actually remember the substr thing...
20:30 travis-ci joined #perl6-dev
20:30 travis-ci Rakudo build passed. Elizabeth Mattijsen 'Guard .split when there is no .match
20:30 travis-ci https://travis-ci.org/rakudo/rakudo/builds/167650498 https://github.com/rakudo/rakudo/compare/b08ef9666e32...03371374760c
20:30 travis-ci left #perl6-dev
20:31 psch r: my $a = '.' x 4 ~ 'a'; $a.substr-rw(1,1) = ''; say $a
20:31 camelia rakudo-jvm 2a1605, rakudo-moar 41c075: OUTPUT«...a␤»
20:31 psch well, that apparently got fixed
20:31 * psch should probably head bedwards anyway o/
20:57 Zoffix left #perl6-dev
21:08 cygx joined #perl6-dev
21:08 cygx o/
21:10 cygx I went with regional indicators as an example because I was looking into the grapheme cluster algorithm, of which they are a special case
21:10 cygx the mail lacks details because I reported it just before heading out
21:11 cygx at a guess, the low-level grapheme count implementation for strands probably just multiplies the grapheme number of the base string with the repetition count, but I haven't checked
21:12 cygx again at a guess, the difference in the xx case is because it probably doesn't generate a strand, but flattens
21:13 * cygx heads out again
21:13 cygx early day tomorrow...
21:52 jnthn Yes, the problem is the strands opt (which came pre-NFG) should check if two of the chars in a row might form a grapheme
21:52 yoleaux2 16:33Z <p3rln00b> jnthn: based on https://github.com/perl6/doc/issues/970#issuecomment-253824298  ... then this can be tossed? https://github.com/rakudo/rakudo/blob/nom/src/core/Mu.pm#L686-L688
21:53 jnthn .tell p3rln00b I'd guess so, but do a spectest to be sure
21:53 yoleaux2 jnthn: I'll pass your message to p3rln00b.
21:53 jnthn psch: yes, I fixed that x and substr bug a few months ago :)
22:07 japhb jnthn: What's the state of your work on decoding and *::Async?  Is it finished?  Or still more to do?
22:08 jnthn japhb: A decoding error and no longer bring down the process
22:08 jnthn japhb: Just propagated as an async exception (e.g. quit)
22:09 jnthn uh, s/and no/can no/
22:09 japhb Yeah, I decoded that after a few seconds.  ;-)
22:09 jnthn Well, if that exception goes unhandled I guess it can :)
22:09 jnthn Yeah, bit tired ;)
22:09 japhb It's what, 1 AM or so?
22:09 jnthn Also I put in support for picking the encoding
22:09 jnthn Only midnight.
22:10 japhb Ah, +9 from here then.
22:10 japhb Picking the encoding per handle will be useful on Proc::Async.  I have an insane tool I need to work with that inputs binary and outputs JSON encoded in Latin-1.
22:11 jnthn Yeah, I put that in.
22:11 jnthn Just a couple of days back :)
22:11 japhb *excellent*
22:11 jnthn So, good timing ;)
22:11 japhb Heh
22:11 timotimo also different encoding on stdout and stderr :)
22:12 jnthn Plan to have streaming decoders separated out from I/O also, so you can re-use that building block in fancier situations
22:12 japhb Thank you!
22:13 jnthn Also to enable user-space encoders/decoders
22:14 jnthn So, plenty of stuff in the pipeline. Of course, that's competing with dozens of other things I want to look at :)
22:14 japhb Oh, when I was skimming backlog I saw some discussion about whether perl6 used as a filter should be allowed to canonify Unicode en passant, and ISTR the answer was something along the lines of "If you want that, declare that you want to input into Uni instead of Str".  Is that actually the real plan, or was that just a brainstorming idea?
22:14 japhb Er, If you *don't* want that
22:15 jnthn Well, if Str is a grapheme-level representation, it pretty much has to normalize
22:16 japhb Yeah, I saw some discussion about keeping two copies of the Str data (normalized and unnormalized), the former for comparisons, the latter to print back out, but that seemed to be not the general sentiment.
22:16 jnthn Yeah, I don't think everyone should pay for that
22:16 japhb Agreed.
22:17 japhb So in your new world, how does one ask for Proc::Async or IO::Socket::Async to return Uni instead of Str or Buf?
22:18 jnthn As the Unicode consortium's own FAQ notes, (a) any other Unicode-supporting program should compare things normalized anyway so this isn't a question of Perl 6 not roundtripping *Unicode*, but rather codepoints, and (b) NFC is already the common case anyway.
22:19 jnthn I'd expect something like :norm(Uni)
22:19 japhb Ah, OK
22:20 jnthn Where :norm(Str) is the default
22:20 japhb Right
22:20 jnthn Since that way :norm(NFC) will Just Work also
22:20 japhb :-)
22:21 japhb My main use case for caring that I roundtrip codepoints is dealing with making bulk changes to versioned files, and avoiding having files that didn't "change" in the Unicode sense, but merely got canonicalized, being added to the changeset.
22:22 jnthn Yeah. That's a case of other tools not understanding Unicode sufficiently yet. :)
22:23 jnthn In the meantime, it's reasonably enough to want to work at codepoint level in such situations.
22:23 japhb My secondary case is writing debugging tools that help me diagnose and fix other Unicode-broken tools.  (If I input as Str, I might either throw exceptions left and right, or not see that the other tool is outputing unnormalized junk.)
22:24 japhb Yeah
22:24 japhb Anyway, thanks for your work on this stuff!
22:27 jnthn np :)
22:40 jnthn eek, just tried to make install rakudo HEAD on windows and get:
22:40 jnthn .\perl6-m.bat tools/build/install-core-dist.pl C:\consulting\MoarVM\install/share/perl6 Failed to create directory 'C:\consulting\MoarVM\install\share\perl6\precomp\77F0C951005AAFB73434E4327826E9DE79524193.1476482719.86227' with mode '0o777': Failed to mkdir: 0
22:40 jnthn in any  at ././CORE.setting.moarvm line 1
22:40 jnthn in block <unit> at tools/build/install-core-dist.pl line 27
22:40 timotimo dir already exists? maybe?
22:40 timotimo is the 0 there the errno? it shouldn't be 0, right?
22:42 jnthn Pretty sure it's an errno
22:42 timotimo so basically "error: success"?
22:42 timotimo something in between reset errno because something else we did was successful?
22:42 timotimo like, a printf or something?
22:42 timotimo isn't that the common error?
22:43 jnthn Maybe so
22:43 jnthn Well, too tired to look now
22:43 timotimo understood
22:44 jnthn But yeah, the directory does already exist
22:44 timotimo probably the MVM_free right ni front of it
22:44 timotimo resets the errno
22:44 timotimo oh, wait, this is with GetLastError()
22:45 timotimo it's checking if it's != ERROR_ALREADY_EXISTS and only then will it throw
22:45 timotimo so mkdir_p returns nonzero, but GetLastError returns 0?
22:46 jnthn Odd
22:46 jnthn Thing is, if I try and mkdir something that already exists on Windows with a simple "mkdir" program it's totally fine
22:47 jnthn So there's a bit more do it than this, it seems
22:47 jnthn So yeah, harder than I have brane for right now :)
22:48 timotimo on linux it looks at errno after MVM_free is used, which could be bogus
22:50 jnthn http://stackoverflow.com/questions/30569981/does-free-set-errno fwiw
22:50 jnthn summary: "it's complicated" but yes, it could be bogus
22:51 geekosaur yep, free() is one of the functions that I make sure to grab errno before calling
22:53 timotimo i've put a few int blah_errno = errno into the code
22:54 timotimo probably wants a tiny bit of extra care across the whole codebase for trouble like that
22:54 timotimo this is only dirops.c
22:55 geekosaur the safest thing to do is always grab errno immediately after an operation that sets it, if you will need it. making sure it will survive across another call can be prohibitively difficult even if you control all the code in question
22:55 geekosaur (because you may have to change something such that it trashes errno and then you have to rewrite all the code that uses that something...)
22:58 jnthn bah, turns out if you run the thing enough times it eventually works
22:58 jnthn So it whines on each directory it creates but seems to have created it anyway
22:58 jnthn So the next time it gets a step further
22:58 timotimo god damn it. how is that possible?
22:59 jnthn No idea
22:59 timotimo maybe "directory already exists but the mode is wrong"?
22:59 timotimo and ... somehow it ends up setting the mode ?!?!?
22:59 jnthn Will be something silly anyway
22:59 timotimo the fuck? :)
22:59 jnthn Because everything "works" if only you retry sufficiently many times for it to trip over every directory it wants to make
23:02 travis-ci joined #perl6-dev
23:02 travis-ci Rakudo build errored. Zoffix Znet 'Fix Num:U++
23:02 travis-ci https://travis-ci.org/rakudo/rakudo/builds/167685259 https://github.com/rakudo/rakudo/compare/03371374760c...8268ffbc1ae5
23:02 travis-ci left #perl6-dev
23:02 buggable [travis build above] ✓ All failures are due to timeout (1), missing build log (0), or GitHub connectivity (0). All failures are on JVM only.
23:18 jnthn sleep; 'night
23:21 geekosaur joined #perl6-dev
23:34 literal joined #perl6-dev

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