dalek ast: 0300663 | usev6++ | S02-types/list.t:
Fudge test for RT #130160 on JVM

  (it works when run standalone but fails in S02-types/lists.t		 05:37
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=130160
gfldex m: class A {}; multi sub trait_mod:<is>(Variable, :$foo ($first, Pair $pair, $last) ){}; my $a is foo(1, A => 1, 3) = A.new; 07:44
camelia rakudo-moar 64343d: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Can't use unknown trait 'is foo' in a variable declaration.␤at <tmp>:1␤------> , $last) ){}; my $a is foo(1, A => 1, 3)⏏ = A.new;␤ expecting any of:␤ TypeObject␤ default…»
gfldex a sub-signature to destructure the named parameter of a trait 07:45
[TuxCM] This is Rakudo version 2016.11-53-g64343d7 built on MoarVM version 2016.11-20-g0f7277a 08:10
csv-ip5xs 3.241
test 14.390
test-t 6.640
csv-parser 14.154
lizmat Files=1154, Tests=53781, 208 wallclock secs (12.66 usr 3.61 sys + 1269.92 cusr 122.05 csys = 1408.24 CPU) 10:28
dalek kudo/nom: fce1a24 | (Zoffix Znet)++ | src/core/Iterable.pm:
Give Iterable.flat() iterator its own .push-all

Earlier fix[^1] removed custom .push-all() impl. for this Iterator, as crud brenchmarks showed no performance loss. However, more elaborate benches indicate the loss can be up to 30% in some cases.
Re-implement the custom push-all, with the fix[^1] present to regain lost performance.
  [1] github.com/rakudo/rakudo/commit/61...1fe4e2cb5e		 14:42
viki *crude 14:43
jnthn Heh, crud worked too :P 14:44
(synonym for "crap" where I'm from)
nine Oh boy. Bailador is 43 times slower than Dancer2 used via Inline::Perl5 15:12
dalek kudo/nom: 77e9d4b | (Zoffix Znet)++ | src/core/Buf.pm:
Add aritiy-1 infix:<~> for Blobs

Constructs like [~] @array-of-blobs currently fail when there's only one element in the list, as in such cases infix:<~>(Str) is used.
Fix by adding arity-1 infix:<~>(Blob:D) that simply returns its argument		 15:13
nine I bet it's EVALing the code generated from the templates on every request.
viki nine: :o ... in some way, that's pretty amusing :) 15:14
dalek ast: b51d3a6 | (Zoffix Znet)++ | S32-container/buf.t:
Test infix:<~>(Blob:D)

Added in commit
  github.com/rakudo/rakudo/commit/77e9d4b545		 15:16
nine viki: OTOH it's not completely surprising considering that Text::CSV_XS:from<Perl5> is still twice as fast as Text::CSV 15:29
[TuxCM] twice?
nine ~ 3.2 vs. 6.6 seconds?
[TuxCM] _XS = 0.033 15:32
nine I'm talking about using it from Perl 6 15:33
[TuxCM] tux.nl/Talks/CSV6/speed5.html
nine Dancer2 in a Perl 5 app is again 4-5 times faster than Dancer2 in Perl 6 which is 43 times as fast as Bailador in Perl 6
[TuxCM] Ahh
nine Oh yes, Bailador re-parses the template and re-EVALs the generated Perl 6 code every time one renders a template. That can only be slow as hell :) 15:40
tadzik (yep :P)
dalek ast: a8b70cc | (Zoffix Znet)++ | S16-filehandles/argfiles.t:
Teach create-temporary-file to take a part of filename

So we could create dmore than one temp file without risk of race conditions of creating same-named files.		 16:21
kudo/nom: 15f51a5 | (Zoffix Znet)++ | src/core/IO/ArgFiles.pm:
Fix slurp not propagating :bin and :enc args on $*ARGFILES

Reported by timotimo++ irclog.perlgeek.de/perl6/2016-11-25#i_13628118
The p6box_s removed due to possibility of getting Bufs; the Str version of slurp-rest already p6box_ss the return value. Also, change @chunks.join to [~] @chunks, so it calls appropriate infix:<~> op, whether it has Str or Buf in the @chunks.		 16:27
ast: 1db2692 | (Zoffix Znet)++ | S16-filehandles/argfiles.t:
Test slurp on $*ARGFILES passes through :bin and :enc args

Fixed in Rakudo in
  github.com/rakudo/rakudo/commit/15f51a52bd		 16:33
travis-ci Rakudo build errored. Zoffix Znet 'Fix slurp not propagating :bin and :enc args on $*ARGFILES 17:17
travis-ci.org/rakudo/rakudo/builds/178884454 github.com/rakudo/rakudo/compare/7...f51a52bd41
buggable [travis build above] ✓ All failures are due to timeout (1), missing build log (0), or GitHub connectivity (0).
viki "Normalization output must be native array of 32-bit integers" is there a simple way to get such an array in NQP? 17:46
timotimo not without a bit of weird amgic
magic*
i know that because in the last few days i've been wondering about getting smaller int-arrays into nqp 17:47
viki hmm
m: my $codes := nqp::list_i; nqp::strtocodes("foo", nqp::const::NORMALIZE_NFC, $codes);
camelia rakudo-moar 15f51a: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Could not find nqp::list_i, did you forget 'use nqp;' ?␤at <tmp>:1␤------> my $codes := nqp::list_i⏏; nqp::strtocodes("foo", nqp::const::NOR␤ expecting any of:␤ argument list␤»
viki Trying to get that inside Perl6/Grammar
well, what I'm trying to do is so .codes == .chars 17:49
but in P6/Grammar
and the reason I'm trying to do that is I want a \d+ token but that fails to match stuff like "7\x[308]" 17:50
timotimo a second, please 17:52
nqp/t/nqp/102-multidim.t shows how a multi-dim array type gets created, that gives you an idea how to pass arguments to the compose protocol 17:53
then, you can find the arguments that are interesting inside moarvm's src/6model/reprs/MVMArray.c in the "compose" function 17:54
viki :o
timotimo so here's my "what" of the day 17:55
m: say +"0x00000000002e88bb"
camelia rakudo-moar 15f51a: OUTPUT«3049659␤»
timotimo i've been meaning to write the number 12290094, and it comes out as 29217008 on the other end
and just parsing the hex values there gives me yet another value 17:56
viki m: say "2e88bb".parse-base(16)
camelia rakudo-moar 15f51a: OUTPUT«3049659␤»
viki doesn't see the wat
timotimo m: my $blob = "hello, and how are you?".encode("utf8"); Buf.new(flat(0 xx 8, ($blob.elems).polymod(256 xx *))[*-8..*])).perl.say 17:57
camelia rakudo-moar 15f51a: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Unexpected closing bracket␤at <tmp>:1␤------> $blob.elems).polymod(256 xx *))[*-8..*])⏏).perl.say␤»
timotimo m: my $blob = "hello, and how are you?".encode("utf8"); Buf.new(flat(0 xx 8, ($blob.elems).polymod(256 xx *))[*-8..*]).perl.say
camelia rakudo-moar 15f51a: OUTPUT«Buf.new(0,0,0,0,0,0,0,23)␤»
timotimo m: my $blob = ("hello, and how are you?" x 100).encode("utf8"); Buf.new(flat(0 xx 8, ($blob.elems).polymod(256 xx *))[*-8..*]).perl.say; say $blob.elems
camelia rakudo-moar 15f51a: OUTPUT«Buf.new(0,0,0,0,0,0,252,8)␤2300␤»
timotimo m: say :256[252, 8]
camelia rakudo-moar 15f51a: OUTPUT«64520␤»
timotimo i think i'm doing things the wrongest way ever devised 17:58
viki I'm no idea what you're even doing 17:59
timotimo oh, well
you know
just encoding a 64 bit number to bytes
i'd like to read it with a memcpy(&64_bit_int_variable, source, 8) 18:00
viki But what's with "hello, and how are you?" then? :) 18:01
timotimo the number is how big that piece of data is
you see the $blob.elems? 18:02
viki OK. 18:03
m: my $blob = ("hello, and how are you?" x 100).encode("utf8"); Buf.new(flat(0 xx 8, ($blob.elems).polymod(256 xx *))[*-8..*]).perl.say; say $blob.elems; say 8*256 + 252
camelia rakudo-moar 15f51a: OUTPUT«Buf.new(0,0,0,0,0,0,252,8)␤2300␤2300␤»
timotimo m: use experimental :pack; pack("L", 2300).perl.say
camelia rakudo-moar 15f51a: OUTPUT«Buf.new(252,8,0,0)␤»
viki It's working innit?
timotimo oh, it is? 18:04
how is my :256[252, 8] not the same as 252 * 255 + 8? ... oh
viki m: say :256[8, 252] 18:05
camelia rakudo-moar 15f51a: OUTPUT«2300␤»
viki m: say 64/8
camelia rakudo-moar 15f51a: OUTPUT«8␤»
timotimo now what's the magic incantation to make my C program eat it, too ...
viki the created buf is prolly in reverse? 18:06
Should be Buf.new(0,0,0,0,0,0,8,252), no?
oh wait
Yeah
Well, if the 252 in there is the one that is least signficinant bit or whatver 18:07
byte
timotimo m: say 0xbb882e; say 12290094.base(16); say 17621232.base(16)
camelia rakudo-moar 15f51a: OUTPUT«12290094␤BB882E␤10CE0F0␤» 18:08
timotimo jesus christ
i forgot to put the argument to fprint in 18:09
so it was just printing out what happens to be on the stack/in the register
viki heh
timotimo got the right number now! finally! 18:10
just needed two .reverse in there :)
thank you for being such a good rubber duckie
can i help you with the 32bit thing in turn? 18:11
viki m: my $blob = ("hello, and how are you?" x 100).encode("utf8"); Buf.new(flat(0 xx 8, ($blob.elems).polymod(256 xx *).reverse)[*-8..*]).perl.say
camelia rakudo-moar 15f51a: OUTPUT«Buf.new(0,0,0,0,0,0,8,252)␤»
viki Nah, I'll leave the 32gbit thing for now. 18:12
timotimo heh, 32gbit
viki Need to do some $work before the end of the week so I'll leave it for tomorrow :)
timotimo that's fair
b2gills I should not go three weeks between times looking at this channel. It took me three hours looking through just the commits. 19:05
viki :)
timotimo uh oh :S
i'm glad you're back, in any case :)
b2gills It didn't help that the power went off twice back when I was upgrading my computer, and had to reinstall from scratch. 19:12
viki m: gist.github.com/zoffixznet/af46dda...32fbde9f2f 19:13
camelia rakudo-moar 15f51a: OUTPUT«()␤()␤()␤()␤()␤()␤7␤»
viki So, is it too crazy to have this token in Perl6/Grammar?
With the immediate purpose of fixing :7̈a, but there may turn up other cases 19:14
b2gills If it does get added, there should be a script somewhere that creates it so that it is easier to update with a new version of Unicode 19:16
viki OK. I have the script gist.github.com/zoffixznet/e0cc87a...8b651fb9a0
timotimo is <:Nd> too slow? 19:18
viki timotimo: it doesn't work.
timotimo that's bad :)
viki the combiner obtains Nd property
timotimo of course it does
viki :)
timotimo i remember that now
jnthn It's not that the combiner obtains the Nd property, it's that the grapheme as a whole has it 19:20
(Nit pick, but perhaps an important one :))
b2gills Actually are there any composed variants of Nd values? because if not you could cheat by checking the ordinal in an implementation specific way. basically ask MOAR if it created a synthetic
jnthn Well, the easy way is chr(ord($x)) eq $x 19:21
japhb jnthn++ # Excellent blog post last night; I'm actually rethinking a bit of API because of it.
jnthn Glad it made some sense. :) 19:22
timotimo things i like: single source of truth. things i like to do: forget to do things well
jnthn had a bit of writers block for a while...
viki b2gills: I know checking .codes == .chars is a viable way, but I've no idea how to "ask MOAR if it created a synthetic" 19:26
timotimo if moar created a synthetic, then the .NFC isn't as long as the .chars 19:27
viki oh, so we're back to that 32-bit array thing :D 19:28
timotimo because then the NFC must contain some not-combined stuff
;(
i thought you were going to let it rest
viki Yeah, I should.
So I'll try that tomorrow. Thinking adding the token will end up with us forgetting to update it one day .... 19:29
timotimo unless you have a little generator script ;)
viki someone has to run it ;)
timotimo right
b2gills If you could ask MOAR what codepoint it internally has, it will be outside of the Unicode range ( actually I think it is negative ) I would assume there is no way currently to do that at the Perl 6 level
jnthn viki: II can't think of a case where doing $c.ord.chr eq $c would be true *and* you have a synthetic. 19:30
b2gills: Moar will never leak synthetics :)
viki jnthn: ok, I'll try that too.
jnthn viki: Either it's non-synthetic and so it roundtrips the codepoint 19:31
Or it's synthetic and it doesn't
viki it's just it's not 1 char, so I have to substr or something for each char
jnthn Yeah
viki ok
jnthn Noting that it'll work out 'cus each char is a grapheme, not a codepoint
In the longer run, I think a :NFC or similar adverb in the regex engine would be a way to do this (iirc S05 speculates about that) 19:32
It's not, however, entirely obvious how we'll implement that 19:33
(It's surely possible...just needs some thinking)
timotimo right, it'll be interesting
jnthn (Especially around the semantics of match objects and extents, which is where it gets really hairy) 19:34
b2gills unfortunately the bus-number for that area of the implementation is entirely too low
jnthn *nod* 19:35
The regex engine was one of the last parts of the codebase I understood when I was new to Rakudo :)
timotimo yeah, we don't have an easy way to get at .orig any more when we match on transformed parts of the source 19:38
we can't just take the original string and be careful about offsets in different normalizations, because we need to have sub-character indices :|
jnthn Yes, you can start to see why this hasn't been implemented yet. :) 19:39
timotimo at least we don't have to deal with "we matched these combiners, but not those, and they end up in a totally bullshit order in our orig string compared to NFC!"
imagine that, having a to, and also a mask of which combiners in the last (and first!) character ended up in the match as well
at least i'm having fun in my current project today %) 19:40
and i haven't run into a wall yet, so that's nice 19:41
cognominal better running into a Wall 19:49
timotimo heh

Powered by Cro and the Raku® Programming Language.

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

Thank you!