dalek ast: c57aa05 | (Zoffix Znet)++ | S32-num/base.t:
Test edge cases in .base's $digits arg

RT#125819: rt.perl.org/Ticket/Display.html?id=125819		 01:00
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=125819
dalek kudo/nom: 31e466c | (Zoffix Znet)++ | src/core/Range.pm:
Remove trailing whitespace
 02:26
samcv nice AlexDaniel 02:29
dalek rakudo/nom: 334d134 | (Zoffix Znet)++ | src/core/Range.pm: 02:35
rakudo/nom: Fix Range.rand generating value equal to excluded endpoints
rakudo/nom:
rakudo/nom: Fixes RT#129104: rt.perl.org/Ticket/Display.html?id=129104
rakudo/nom:
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=129104
dalek rakudo/nom: The discussion in the ticket speculates this only affects Num ranges,
rakudo/nom: however from the code I see other types are affected as well. For example
rakudo/nom: using a Rat 1.00000000000001 has the same issue in lizmat's one liner.
rakudo/nom: Reproducing with an Int is a bit harder due to much larger pool of
rakudo/nom: possible random numbers, but sometime... somewhere... in a nuclear plant
rakudo/nom: running on Perl 6, a .rand on Int range with endpoint exclusions will
rakudo/nom: produce a value equal to the excluded endpoint.
rakudo/nom:
rakudo/nom: The problem is due to us checking generated value against zero and
ugexe Anyone able to give permissions on the advent calender? I'm going to bed soon and need to post Friday's advent post 03:27
never mind, timotimo took care of it afterall! 03:28
[Tux] This is Rakudo version 2016.11-252-g334d1344a built on MoarVM version 2016.11-60-g21abc2a1 07:36
csv-ip5xs 3.164
test 14.281
test-t 6.164
csv-parser 15.141
lizmat Files=1155, Tests=53927, 197 wallclock secs (11.01 usr 4.56 sys + 1167.93 cusr 125.37 csys = 1308.87 CPU) 08:36
dalek p: ad00a7b | niner++ | tools/build/ (2 files):
Use NQP_LIB_DIR instead of manually assembling a path

This allows for changing the lib_dir in a centralized place, e.g. for installing libraries into /usr/lib64 instead of /usr/share.		 09:30
ast: acd8f24 | samcv++ | S15-unicode-information/uniprop.t:
uniprop: add tests for three more properties.

Hangul_Syllable_Type, East_Asian_Width and Case_Folding		 10:27
p: 0dce14b | niner++ | / (5 files):
Support Configure.pl --libdir=...

Allows for installing architecture dependent libraries in /usr/lib64 for example.		 11:06
kudo/nom: 1661511 | niner++ | tools/build/Makefile- (2 files):
Support NQP with non-standard libdir

Allows for storing architecture dependant library files in /usr/lib64		 11:08
nine This got rid of the last patch and scary sed call in the openSUSE spec files. Packaging rakudo/nqp/moar is now a real piece of cake :) 11:12
Oh, I should bump NQP_VERSIOn
jnthn mmm...cake :) 11:13
nine++
dalek kudo/nom: fe665fc | niner++ | tools/build/NQP_REVISION:
Bump NQP for build system updates needed by commit 1661511bba5861bfee3258dd1d3a69696f9395a7
kudo/nom: 124a0d9 | (Zoffix Znet)++ | docs/ChangeLog:
List sub MAIN Enum feature in ChangeLog

Previous release excluded the feature, due to the indentified problem
  (Str $x cannot accept strings True/False; same with any other enums).
We didn't come up with an alternate solution, but neither did any of our bleed users notice the issue. The problem can also be worked around with a Str() coercer, so I'm including the feature in December release.		 11:58
MasterDuke_ jnthn: unless i'm crazy, -n doesn't currently support NEXT/LAST/etc 13:14
jnthn o.O 13:18
Well... oops
MasterDuke_ yeah, given i've been messing around in that code recently i can try and add it 13:19
timotimo we don't even have spec tests that test that? wow.
MasterDuke_ though i thought i'd better benchmark the change i just got working last evening, went from 1m50s to -ne '' a 13million line file before my changes to 2m50s after 13:20
yoleaux2 13:20Z <Zoffix> MasterDuke_: there's a ticket for LAST in -n: rt.perl.org/Ticket/Display.html?id...et-history
jnthn So it got...slower? 13:21
MasterDuke_ so, yay for finally getting it working, boo for being much much slower
yeah. turns out get() is very slow
jnthn Oh, you're calling get every time?
Yeah, don't do that
:)
MasterDuke_ $filehandle.get() is fast
jnthn Probably best will be to use the lines iterator 13:22
And pull-one from it and check you don't get back IterationEnd
MasterDuke_ i'm gonna benchmark a bunch of ways 13:24
but the minimal number of tests is kind of annoying, just makes it harder to know if i'm changing desired/expected behavior 13:25
does S19 have much to say
?
jnthn: the current behaviour is lines(), but i was hoping for something faster. Perl 5 can -n over the same file much much faster 13:31
.tell Zoffix thanks for the link, i'll see if i can do something about it 13:44
yoleaux2 MasterDuke_: I'll pass your message to Zoffix.
|Tux| This is Rakudo version 2016.11-252-g334d1344a built on MoarVM version 2016.11-60-g21abc2a1 15:42
csv-ip5xs 3.082
test 13.311
test-t 6.053
csv-parser 13.830
[Coke] ok, have an 85 line htmlify.p6 segfaulting when running in parallel mode... still golfing. 16:23
jnthn: Down to 40 lines; looks like it needs a gather/take, an await. It also currently has precompilation involved, which we might be able to get rid of; 40 lines at github.com/perl6/doc/blob/coke/bug...htmlify.p6 16:55
moar(84521,0x70000082e000) malloc: *** error for object 0x7fba12f37400: pointer being freed was not allocated 17:03
*** set a breakpoint in malloc_error_break to debug
jnthn [Coke]: Thanks; bit tied up with advent post right now but will look later ;) 19:22
yoleaux2 15:21Z <Zoffix> jnthn: A friendly reminder: Rakudo's next release is tomorrow (Saturday) and we'll need a MoarVM release to use for it.
[Coke] jnthn: sure sure. advent first!
... and a moarvm releaes. ;)
*se
down to 29 lines, btw. :)
jnthn The advent deadline is sooner, so concentrating on that first ;) 19:23
(I'm about 75% of the way through writing, though, so not too worried by now :))
MasterDuke_ [Coke]: does it need the 'use nqp;'? 19:26
[Coke] MasterDuke_: nope. I had removed all the nqp:: calls and forgot that. 19:30
just doing one more run without to make sure the failures are the same.
actually, it does seem slightly happier without it 19:33
um, yah, leaving it in. :| 19:34
MasterDuke_ funny (not in a good way) 19:35
dalek kudo/nom: 4a16884 | samcv++ | docs/ChangeLog:
Update changelog.
 20:11
kudo/nom: 2a09e92 | (Zoffix Znet)++ | docs/ChangeLog:
Merge pull request #958 from samcv/changelog-update

Update changelog.
lizmat m: m/./ # RT #130363 21:15
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=130363
camelia rakudo-moar 2a09e9: OUTPUT«No such method 'match' for invocant of type 'Any'␤ in block <unit> at <tmp> line 1␤␤»
jnthn m: /./ 21:20
camelia ( no output )
jnthn I think that one calls out of sink 21:21
Quite why it doesn't also blow up in the same way I'm not sure
m: say 1 if /./
camelia ( no output )
jnthn m: if /./ -> $x { dd $x }
camelia ( no output )
jnthn m: unless /./ -> $x { dd $x } 21:22
camelia rakudo-moar 2a09e9: OUTPUT«Regex $x = /./␤»
jnthn m: $_ = 'x'; say 1 if /./
camelia rakudo-moar 2a09e9: OUTPUT«1␤»
jnthn m: my $_ = 'x'; if /./ -> $x { dd $x }
camelia rakudo-moar 2a09e9: OUTPUT«Potential difficulties:␤ Redeclaration of symbol '$_'␤ at <tmp>:1␤ ------> my $_⏏ = 'x'; if /./ -> $x { dd $x }␤Regex $x = /./␤»
jnthn m: $_ = 'x'; if /./ -> $x { dd $x }
camelia rakudo-moar 2a09e9: OUTPUT«Regex $x = /./␤»
jnthn m: $_ = 'x'; if /./ { say 1 } 21:23
camelia rakudo-moar 2a09e9: OUTPUT«1␤»
jnthn So, quiet on Bool too
(Don't see anything suspect in any of the above)
Agree it's a weird inconsistency, anyway
(between m and without it) 21:24
lizmat jnthn: I think the m// case assumes there will be named params 21:28
and that needs .match
or is that a wrong assumption ?
jnthn Well, it could still generate .can('match') ?? .match(/./) !! ($/ = Nil) or so 21:30
(or something appropriate, that may not be exactly it) 21:31
lizmat jnthn: but what would be against just adding a Any:U: candidate for .match ? 21:33
that would just set $/ to Nil ? 21:34
I mean, we have a candidate in Cool already
jnthn What does the one in Cool do? 21:36
lizmat call self.Stringy.match 21:37
jnthn Ah, that's reasonable 21:39
lizmat jnthn: adding a Any:U: match candidate makes one spectest fail: 21:40
throws-like 'm/%var/', Exception, 'cannot interpolate hashes into regexes';
dalek ast: 4d14891 | samcv++ | S15-unicode-information/uniprop.t:
uniprop: add tests for Block and Jamo_Short_Name
 21:41
lizmat m: my %var; /%var/ # should this bomb?
camelia ( no output )
samcv hopefully if i add ~3 tests per day, eventually there will be tests for all 124 properties :P
lizmat m: my %var; m/%var/ # then why do we expect this to bomb ? 21:42
camelia rakudo-moar 2a09e9: OUTPUT«No such method 'match' for invocant of type 'Any'␤ in block <unit> at <tmp> line 1␤␤»
lucasb sorry for intruding, plain /.../ creates a regex. do you want it to be a match operator?
lizmat lucasb: this is about the difference between /./ and m/./ 21:43
lucasb I understand
lizmat # RT #130363
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=130363
lizmat they should act the same
jnthn samcv++ # getting our test coverage up :)
lucasb in boolean context /.../ acts like m/.../, but otherwise, it just creates a regex object, no?
jnthn lucasb: Also in sink context
lizmat I don't particularly care what it means 21:44
lucasb they should act the same only in boolean context or also in sink context?
jnthn Phew, I think I finished my advent post
lucasb ah, ok
lizmat lucasb: they should be the same everywhere, as they should be semantically the same
samcv jnthn, may easier to do all the changes in unicode that need to happen in moarvm at the same time right? once we test for everything?
since there's so many
lizmat regardless of context
samcv potentially we might not have yet
nice RE the advent post jnthn 21:45
lucasb my $rx = rx/foo/; if $rx { say 'yes' } # should $rx in boolean context activates the matching behaviour or not?
because, now, it does try to match against $_
instead of just asking "is this object truthy or falsey?" 21:46
jnthn samcv: Hard to say, but I think there's a range of issues raised by the tests that will need different things.
samcv yeah
jnthn samcv: I mean, "we're totally missing this property" might be as simple as "oh, just tweak ucd2c.pl to read the file in and call it done"
samcv and i still need to figure out the distinctions between cjkNumeric and the other numeric properties and the accounting numeric ones. hah
yeah 21:47
jnthn But some of the other issues will likely be...harder :S
lizmat m: my %var; /%var/ # jnthn, is this supposed to throw ?
camelia ( no output )
jnthn m: say Any ~~ /%var/
camelia rakudo-moar 2a09e9: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Variable '%var' is not declared. Did you mean '&VAR'?␤at <tmp>:1␤------> say Any ~~ /⏏%var/␤»
jnthn m: my %var; say Any ~~ /%var/ 21:48
camelia rakudo-moar 2a09e9: OUTPUT«Use of uninitialized value of type Any in string context.␤Methods .^name, .perl, .gist, or .say can be used to stringify it to something meaningful.␤ in block <unit> at <tmp> line 1␤Nil␤»
jnthn I think it doesn't even make it into the regex
And then the hash check is runtime
lucasb IMO, /%h/ shouldn't throw, otherwise double string interpolation "%h" would also have to throw
jnthn lucasb: Don't see how that follows 21:49
Regexes are a totally different language to strings
Not even parsed by the same codepath
lucasb sorry, correct. I keep thinking with my Perl 5 head :(
jnthn :)
I thought that interpolation of hashes was reserved 21:50
lucasb my $x = /foo/; # should this create a regex object or try to match against $_ ?
jnthn So it might be that we could whine about it at compile time
Certainly a regex object there
lizmat well, yes, and there is a test in t/spec/S05-interpolation/regex-in-variable.t that now doesn't pass anymore
if I make m/./ not die
jnthn Yeah, well, it was apparently passing for the wrong reason 21:51
But we might be able to make a right reason :)
lizmat so the test as such was bogus, because it ok'd it on m/./ throwing rather than %var
anyways, going to keep this for post release
feels a bit like a can of worms that I don't want exploding in a new release :-) 21:52
jnthn Yeah 21:53
Jsut checked STD; it doesn't do a parse-time detect on that 21:54
m: my %var; /<%var>/
camelia ( no output )
jnthn m: my %var; 'a' ~~ /<%var>/
camelia ( no output )
jnthn o.O
jnthn quickly closes the can again :) 21:55
ugexe m: say (1,2).map({ LAST { say "DONE" } })[2]; # is this a bug? 22:00
camelia rakudo-moar 2a09e9: OUTPUT«DONE␤DONE␤Nil␤»
ugexe m: say (1..10).map({ LAST { say "DONE" } })[5]; # those were bad numbers to demonstrate
camelia rakudo-moar 2a09e9: OUTPUT«Nil␤»
ugexe m: say (1..10).map({ LAST { say "DONE" } })[10]; 22:01
camelia rakudo-moar 2a09e9: OUTPUT«DONE␤DONE␤Nil␤»
lizmat ugexe: feels to me the DONE should be done once
looks like it is trying top vivify element 11 a second time ?
ugexe: please RT 22:02
ugexe ok. should it also have fire on [9] though?
m: say (1..10).map({ LAST { say "DONE" } })[9];
camelia rakudo-moar 2a09e9: OUTPUT«Nil␤»
lizmat ugexe: no, because it can only know to fire LAST if the iterator returns InteratioEnd 22:18
and it won't know until it actually has tried to pull it
for index 10
m: say (^Inf).grep({last if $_ > 5; LAST say "foo"; True})[^20] 22:51
camelia rakudo-moar 2a09e9: OUTPUT«(0 1 2 3 4 5 Nil Nil Nil Nil Nil Nil Nil Nil Nil Nil Nil Nil Nil Nil)␤»
lizmat m: my $i = (^Inf).grep({last if $_ > 0; True}).iterator; dd $i.pull-one; dd $i.pull-one # RT #130365 22:53
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=130365
camelia rakudo-moar 2a09e9: OUTPUT«0␤1␤»
lizmat ^^^ push-exactly is not the issue here
jnthn is exhausted and will do the MoarVM release tomorrow morning when he wakes up :) 23:10
lizmat good night, jnthn 23:11
jnthn 'night 23:14
lizmat has a fix for RT #130365, but it doesn't fix this: 23:18
m: my $i = (^Inf).grep({last if $_ > 0; True}).iterator; dd $i.pull-one; dd $i.pull-one
camelia rakudo-moar 2a09e9: OUTPUT«0␤1␤»
lizmat that should have been 0 IterationEnd
gfldex I may need some sleep before I can plug the ENODOC of LAST in a .map. I also need to complain here about that fact so I don't forget until tomorrow. 23:40
good night :)
dalek kudo/nom: 7021861 | lizmat++ | src/core/Any-iterable-methods.pm:
Preliminary fix for RT #130365

Remove the optimization for non-phaser blocks, because they can have a "last" in them. This will make grep slower for the general case. Will try to restore the optimization and have it work properly after the 2016.12 release.
Meanwhile, this also makes some hyper/race tests TODO tests pass.		 23:47
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=130365
lizmat and with that, I wish #perl6-dev a good night! 23:49

Powered by Cro and the Raku® Programming Language.

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

Thank you!