AlexDaniel m: 0x1F63A.uniname.say 00:19
camelia SMILING CAT FACE WITH OPEN MOUTH?
AlexDaniel .tell moritz FWIW, somehow I was under impression that only new unicody messages are broken, but everything seems to be affected: irclog.perlgeek.de/perl6/2016-09-05#i_13155366 . Maybe you know already, I just thought that I'll mention it just in case… 00:21
yoleaux AlexDaniel: I'll pass your message to moritz.
Zoffix AlexDaniel: yeah, I started a file for that stuff: temp.perl6.party/inconsistencies.txt 02:08
huggable: in :is: temp.perl6.party/inconsistencies.txt 02:12
huggable Zoffix, Added in as temp.perl6.party/inconsistencies.txt
MasterDuke aren't those first couple addressable by adding aliases (is that what they're called?) to the different parameters? e.g., :ENV in the one gets an 'env' alias and :env in the other gets an 'ENV' alias 02:23
AlexDaniel Zoffix: maybe it'd be better to have this page on rakudo wiki? 02:24
huggable: wiki
huggable AlexDaniel, nothing found
AlexDaniel huggable: wiki :is: github.com/rakudo/rakudo/wiki
huggable AlexDaniel, Added wiki as github.com/rakudo/rakudo/wiki
AlexDaniel MasterDuke: yeah, probably 02:25
Zoffix AlexDaniel: it's my own list 02:26
MasterDuke: not fully. You'd just have multiple ways to do the same thing and there's no good reason to standardize that behaviour on language level. If you gonna fix it, fix it right, instead of patching it over. 02:28
AlexDaniel now that I think about it, we can even have these things filed as bugs :)
Zoffix There's enough stupid tickets.
AlexDaniel heh, that's a very interesting way to look at it 02:29
Zoffix Keep it a list in a single place. Fix them all when it gets large enough. 02:30
What's the point of there being dozens of tickets for this.
It's not a bug. It's a design failure.
And one that isn't easy to fix.
MasterDuke i guess i don't fully understand what can be changed in 6.c+n, but i thought there wasn't complete freedom to remove things. i agree that aliasing isn't the "best" option, but at least it's likely backwards compatible 02:33
Zoffix From what I recall, the aliases come with a performance penalty 02:35
MasterDuke i don't have strong feelings about any particular solution, but agree that the inconsistency is bad and should be addressed somehow
Zoffix Methods can't be changed in language update. Our only option is going through deprecation period. I figure we collect all of these and then put them up for deprecation in 6.e for removal in 6.f. So it'd be a large "consitifying" event instead of patching them all 1-by-1, a lot of which will likely fly under the hood 02:37
The other two big things are Intifying numerics vs. Not accepting non-Ints and treating type objects as 0 vs crashing with MultiNoMatch 02:38
AlexDaniel fwiw :ENV is not doc-ed
Zoffix s/under the hood/under the radar/; 02:40
MasterDuke m: sub foo(:color(:$colour)) { $colour + 1 }; my $s; for ^1000000 { $s += foo(:color($_)) }; say $s; say now - INIT now 02:44
camelia Unexpected named argument 'color' passed? in sub foo at <tmp> line 1? in block <unit> at <tmp> line 1??
MasterDuke bisectable6: sub foo(:color(:$colour)) { $colour + 1 }; my $s; for ^1000000 { $s += foo(:color($_)) }; say $s;
bisectable6 MasterDuke, Bisecting by exit code (old=2015.12 new=a91ad2d). Old exit code: 0
MasterDuke, bisect log: gist.github.com/651d00f77245537de7...9316f4513e
MasterDuke, (2017-08-04) github.com/rakudo/rakudo/commit/8b...2f0ea5d8cd
Zoffix haw 02:45
MasterDuke c: 2017.07 sub foo(:color(:$colour)) { $colour + 1 }; my $s; for ^1000000 { $s += foo(:color($_)) }; say $s; say now - INIT now
committable6 MasterDuke, ¦2017.07: «500000500000?1.4953885»
MasterDuke c: 2017.07 sub foo(:$color) { $color + 1 }; my $s; for ^1000000 { $s += foo(:color($_)) }; say $s; say now - INIT now
committable6 MasterDuke, ¦2017.07: «500000500000?1.403580» 02:46
MasterDuke c: 2017.07 sub foo(:color(:$colour)) { $colour + 1 }; my $s; for ^1000000 { $s += foo(:colour($_)) }; say $s; say now - INIT now
committable6 MasterDuke, ¦2017.07: «500000500000?1.46995942»
MasterDuke fwiw, not a huge performance difference
Zoffix good 02:47
MasterDuke rakudobugged 02:48
RT #131857 02:49
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=131857
Zoffix m: "aaaaaa
camelia 5===SORRY!5=== Error while compiling <tmp>?Unable to parse expression in double quotes; couldn't find final '"' ?at <tmp>:1?------> 3"aaaaaa7?5<EOL>? expecting any of:? double quotes? term?
Zoffix m: dd "aaaaaa".subt: :2nd, 'a', 'b'
camelia No such method 'subt' for invocant of type 'Str'. Did you mean any of these?? put? sort? sqrt? subst?? in block <unit> at <tmp> line 1??
Zoffix m: dd "aaaaaa".susbt: :2nd, 'a', 'b' 02:50
camelia No such method 'susbt' for invocant of type 'Str'. Did you mean 'subst'?? in block <unit> at <tmp> line 1??
Zoffix m: dd "aaaaaa".subst: :2nd, 'a', 'b'
camelia "abaaaa"?
Zoffix m: dd "aaaaaa".subst: :ii, 'A', 'B'
camelia "aaaaaa"?
Zoffix m: dd "aaaaaa".subst: :ii, 'a', 'B' 02:51
camelia "baaaaa"?
Zoffix m: dd "aaaaaa".subst: :samecase, 'a', 'B'
camelia "baaaaa"?
Zoffix Seems methods aren't affected
AlexDaniel: MasterDuke is trisectable around? I need to bisect this code: gist.github.com/zoffixznet/0c2cbd7...ad2e2bc737 02:56
AlexDaniel sure, one sec
Zoffix: what about this? gist.github.com/Whateverable/b26f4...b50fdbabb4 02:58
Zoffix Hmm
AlexDaniel Zoffix: ¦c63c57e9a823^: «"hello,"» ¦c63c57e: «"hello,\r\nworld!\r\n"»
Zoffix AlexDaniel: really weird :/ I guess travis was failing back for awhile now but the bot never came to IRC 02:59
I thought it broke only today
AlexDaniel but wasn't it reverted later? 03:02
github.com/rakudo/rakudo/commit/a801627
Zoffix AlexDaniel: reverted back: github.com/rakudo/rakudo/commit/7f...60ba934f95 03:03
AlexDaniel although I remember some was re-reverted
right
Zoffix class Z is IO::Handle { method get { dd [$.nl-in]; } }; Z.new.get; # gives me [["\n"],]
Needs to give [["\x0A", "\r\n"],]
or [["\n", "\r\n"],] 03:04
m: class Foo { has $.nl-in is default(["\x0A", "\r\n"]); }; class Z is Foo { method get { dd [$.nl-in]; } }; Z.new.get;
camelia [["\n", "\r\n"],]?
Zoffix And ^ that gives right value... wtf?
samcv: nevermind. That earlier doc failures? Seems to be due to `is default` thing 03:06
Oh, IO::Handle has a proxy in nl-in 03:07
.ask lizmat any idea why this gives only `"\n"` in the list instead of both `"\n"` and `"\r\n"`? Bisectbot points to the `is default` change in IO::Handle. I'm failing to golf it out of IO::Handle tho even after copying all the relevant bits. Code: class Z is IO::Handle { method x { dd $.nl-in } }.new.x; 03:11
yoleaux Zoffix: I'll pass your message to lizmat.
lizmat ok, so what *should* a List.join do if one of the elements is a Junction? 08:19
One could argue that it should return a Junction
rather than a Str
m: dd ("a"|"b","c").join # jnthn, should this return a Str or a Junction ? 09:14
camelia "any(\"a\", \"b\")c"?
jnthn No idea.
lizmat as in any("ac","bc")
jnthn What does Junction.Str do? 09:15
m: say any(1, 2).Str
camelia any(1, 2)?
lizmat so for it.s self.perl
jnthn m: say any(1, 2).Str.WHAT
camelia (Str)?
lizmat *far
jnthn OK, then I'd expect it to do what it's doing.
Though worth running by TimToady :)
I don't know that we can reasonably go auto-threading slurpy things 09:16
It doesn't really make sense anyway
lizmat FWIW, this is about #131856
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=131856
jnthn Since auto-threaded is a binding failover
But *@a has Mu-typed containers
So there's nothing to fail
lizmat well, the issue is really wth List.join 09:17
which in turn makes it an issue of Junction.Str
jnthn I'm not sure I see the issue 09:18
List.join calls .Str on any of its inputs that ain't a Str and then joins the results
I'm not sure Junction.Str can reasonably do much different tbh 09:19
The ~ inconsistency is a tad unfortunate, though 09:20
lizmat well, I have a patch that returns a new Junction with its elements .Stringified
jnthn But Str is a coercion method
It *must* return a Str
Or fail
lizmat well, do we want to have a difference between ("a"|"b") ~ "c" and join("a"|"b","c") ? 09:21
jnthn Did you intend an extra "" at the start of join, since the first arg is taken as the separator? 09:22
m: say ("a"|"b") ~ "c"
camelia any("a", "b")c?
lizmat fwiw, I think I can make it DWIM, but it breaks some expectations in roast
jnthn m: say join("", "a"|"b","c")
camelia any("a", "b")c?
jnthn Looks they they do the same today 09:23
I mean, on the one hand we could just say that list precedence things don't auto-thread
lizmat yeah, because ~ is expressed in terms of .join
jnthn ops, list associativity 09:24
lizmat so I thought about fixing List.joi, so that we would at least be consistent
jnthn But on the other, many people perhaps won't expect ~ to be list assoc
We already *are* consistent though, so far as ~ and join go
lizmat m: dd [~] "a","b","c"
camelia "abc"?
lizmat jnthn: true, but you said: "The ~ inconsistency is a tad unfortunate, though" 09:25
jnthn It is, but "a tad unfortunate" doesn't mean "must be changed"
lizmat I took that as "maybe fix the ("a"|"b") ~ "c" case
jnthn I'm not yet seeing something that isn't worse, though 09:26
We could see how consistently the "if it's list associative it doesn't auto-thread" rule is
lizmat maybe the solution is to have Junction.Str warn ?
meanwhile, I can see many uses for ("a"|"b") ~ "c" simply DWIM :-) 09:27
jnthn Maybe but otoh you'll probably see the output
:)
Anyway, I think it wants running by TimToady 09:28
But I think the answer to "Is it possible to make slurpies junct, same as non-Mu scalar candidates?" is no.
lizmat m: my @a = <a b c>; dd any(@a) ~ ".html" 09:29
camelia "any(\"a\", \"b\", \"c\").html"?
jnthn That...gives you a junction though
Not the filenames
lizmat m: my @a = <a b c> >>~>> ".html"; dd any(@a) 09:30
camelia any("a.html", "b.html", "c.html")?
jnthn Right, that's a much nicer way to write it :)
Especially as a list is probably more useful as a result
I think junctions are best used in situations that will collapse to a boolean 09:31
lizmat m: dd (1|2) + 3
camelia any(4, 5)?
lizmat so, should that then not work either ?
jnthn It can work
lizmat m: dd (1|2|3) + 3
camelia any(4, 5, 6)?
jnthn Just saying that I sometimes feel people reach for junctions to solve stuff that could be done more easily with boring old list operations :) 09:32
lizmat yeah, true, but it's a bit of a WHAT, so maybe we should at least warn on Junction.Str 09:33
jnthn Maybe so
lizmat because it doesn't do what people think ?
jnthn Not soemthing I can make a call on really though
lizmat yeah, ok
I'll bug TimToady about it after his keynote
jnthn What I *can* make a call on is "can slurpys junct", and I think that has to be "no"
It runs into laziness issues for one 09:34
lizmat yeah, in general, I agree
jnthn But for two, it'd further complicate slurpy handling.
Slurpy and flattening are...really not good cases for performance at the moment.
lizmat agree :-)
jnthn Spesh largely throws its hands up when it sees flattening today
I recently made slurpy hash stuff come out better but even then only when you have a non-flattening on the other side 09:35
Which does help most calls to .new a bit i guess. 09:36
Even putting performance aside I just can't see a good way to make slurpy stuff do magical beheavior on junctions, however.
nine Hm...at compile time I don't have the full signature yet while at compose time I don't have a $*W anymore...
dogbert17 lizmat++, another excellent Weekly 09:46
nine Is there any way I can transplant a signature from one Code object to another? 09:56
jnthn Not really, because signatures are compiled 10:05
In the common case
So will already have been code-generated
Well, unless you can somehow do it earlier than that
nine How can -> \arg1 is raw, \arg2 is raw { my $args := nqp::list(); nqp::push($args, arg1); nqp::push 10:42
|($args, arg2); nqp::nativecall($!rettype, self, $args); }
How can -> \arg1 is raw, \arg2 is raw { my $args := nqp::list(); nqp::push($args, arg1); nqp::push($args, arg2); nqp::nativecall($!rettype, self, $args); }
not be massively faster than -> |args { my Mu $args := nqp::getattr(nqp::decont(args), Capture, '@!list'); if nqp::elems($args) != $!arity { X::TypeCheck::Argument.new( :objname($.name), :arguments($args.map(*.^name)) :signature(try $r.signature.gist),).throw } nqp::nativecall($!rettype, self, $args); };
jnthn nine: Well, |args is pretty cheap 10:45
On the accepting side
nine IOW the high level code won't get much better than this and I'll have to look at the lower levels for further improvements 10:46
jnthn For native call?
Yeah, what we really want is some kind of mechanism that will let us be able to JIT the calls in some cases
nine yes
jnthn But that's...not quite obvious how to design
I suspect it may end up being related to the whole invocation spec mechanism though 10:47
It's almost like we want something a tad like indy on JVM
That is, we "link" it on first call
nine Sounds a bit daunting to someone who hasn't done anything with the JIT yet :) 10:50
jnthn :-) 10:52
This one is very much on my list of "if it was esay I'd have done it already" :) 10:53
nine Maybe as a start, I could try to create an op for the common case of having 2 pointers as arguments and trying to JIT that. Just to gather some familiarity. 10:55
jnthn Yeah 10:57
I'd take a look at how native calls are handled in QAST -> MAST also
I think there's a freaky decont loop in the way of serious opts also that we could really do with being able to specialize out
nine Oh, I didn't notice that there was a layer in between 10:58
That decont loop looks awful. It even involves an nqp::can($obj, 'cstr') 11:01
jnthn eww 11:04
nine There's definitely room for improvement there as we do know all the types involved at the time we choose the code to run. So if the arguments are just pointers, we could use an optimized version that doesn't do this check.
jnthn Yeah 11:05
nine Also this check really means to just handle ExplicitlyManagedString correctly, not all objects that happen to have a cstr method. 11:06
And ExplicitlyManagedString can probably only appear if we have a Str argument, so we can actually special case that. 11:09
jnthn Part of me wonders if we want to code-gen (e.g. QAST tree and compile it) something per native call
That would do the deconts and checks as needed 11:10
And then have some kind of nativeinvoke ops
That just use the normal args buffer
That way spesh can rip out the deconts/checks and can provide the args without packaging them up 11:11
And later JIT the call itself 11:12
Geth rakudo/nom: 67455170ca | (Elizabeth Mattijsen)++ | src/core/IO/Handle.pm
Revert "Use "is default" for IO::Handle atttributes"

This reverts commit c63c57e9a823303e74c06afdee10a99d6cb137ad.
Hopefully fix the problems in IO::String.		 11:17
jnthn lunch & 11:19
nine jnthn: yes, that was kinda the plan until I came acress the cheapness of |args. With the decont loop it makes more sense again. Though I guess for influencing code-gen like that we'd have to pull the "is native" trait into the grammar? 11:26
Not spectacular, but the numbers are moving into the right direction :) 11:53
13.6 seconds for 100000 iterations. That is about half a second faster 11:59
timotimo the problem with generating some qast "per native call" is we have to have something different for the CALL-ME function we install on native subs i think? 12:01
nine timotimo: what do you mean? 12:02
timotimo well, there's a single function at the moment that serves every native call 12:03
nine timotimo: github.com/rakudo/rakudo/commit/46...ea9779a104 12:04
just so we are on thevsame page 12:05
timotimo ah, hm, but then that's just closure clones of the same static frame
i.e. only variable contents differ, not the actual bytecode underneith 12:06
underneath?
nine I'm experimenting with differentiating it for some common cases. Especially when there are no stringvarguments we don't have to check for cstr() 12:07
timotimo right, that'd be good
nine Doesn't safe much but every bit helps
timotimo we can put multiple different nativecall candidates into the list of ops or we put a literal parameter in there that tells it what kind of nativecall code to generate 12:08
i.e. it'd want a QAST::IVal in that parameter and decide based upon that
nine I just have a couple of code blocks to choose from in !setup. And a lovely named nqp::nativecallwithstrargs op 12:10
jnthn timotimo: That's kinda why I was pondering a indy-like link option for invocation spec 12:11
That is, on the first call it runs some code
Which should return some code ref 12:12
Which is then installed as the think to usually call
*the thing
Presumably by being able to specify a linked_result attribute 12:13
nine jnthn: how could I compile that when we are already at the first run?
jnthn nine: Compile the stub I talked about?
The QAST compiler is just as available at runtime :)
And we can inline across compilation units :)
nine Ok, will have a look. Should turn off now though as I'm already aboard the plane to Amsterdam :) 12:14
jnthn Have a good flight :)
nine thanks :) 12:15
[TuxCM] This is Rakudo version 2017.07-139-g67455170c built on MoarVM version 2017.07-320-g600c2e9c 12:16
csv-ip5xs 2.083 - 2.127
test 11.662
test-t 3.587 - 3.590
csv-parser 13.815
Zoffix =o \o\ |o| /o/ o= 12:17
Yey for sub 4s times \o/
jnthn wonders if the stuff he's working on today might help some more also
jnthn also hopes the lunch pizza won't cause a carb crash... 12:18
[TuxCM] BTW greetings from the TPCiA prep 12:20
Zoffix \o/ 12:24
dogbert17 I'm suddenly getting several test failures in t/spec/S32-io/IO-Socket-INET.t 14:31
seems to be tests relating to \n \n\r 14:35
nine Oh I'm just .25 seconds away from my comfortable 50 % advantage ;)
timotimo cool
Zoffix dogbert17: are you sure you got latest and greatest rakudo? 14:38
IO::String was failing with \n \r\n stuff recently and latest commit fixed that; dunno if the test is failing for same reason (on second thought, probably not)
nine On the plane I figured out how to compile QAST at runtime and get at the code 14:39
Off to the hotel now 14:40
dogbert17 Zoffix: I belive so This is Rakudo version 2017.07-139-g67455170c built on MoarVM version 2017.07-318-g604da4d06
Zoffix yeah that's latest 14:41
ZofBot: say something
ZofBot Zoffix, nqp')' “The largest point release before was
dogbert17 not ok 12 - \r\n separator, not ok 13 - \r was not left behind on the string, not ok 14 - . as a separator
nine What I haven't found out so far is how my newly compiled block of code can get at the subroutine's arguments... 15:27
Free wifi on the bus to the hotel btw 15:28
Zoffix is reminded of www.complex.com/life/2017/07/22-th...s-for-wifi 15:32
Does the bus have a toilet? :) 15:33
ugexe why is precedence such that `my $x := 1,2` is (1,2) but `my $x = 1,2` is 1? My gut instinct would think := and = would be pretty close; close enough that a comma wouldn't interfere in this instance 15:49
nine is now on the hotel wifi 16:08
llfourn is at dutch design hotel artemis 16:09
geekosaur because = deconstructs but := is raw binding, I think
"destructuring assignment"
nine llfourn: perl/#yapc 16:11
llfourn nine: irc.perl.org?
nine llfourn: yes 16:12
llfourn nine: cheers :)
Zoffix geekosaur: wouldn't then a list in a variable be similarly destructured? 16:19
m: my $l := (1,2); my $x = $l; quietly my $y = 1, 2; dd [$x, $y] 16:20
camelia [(1, 2), 1]?
geekosaur wouldn't you need to flatten the list? 16:21
Zoffix It's already flat :D 16:23
What do you mean?
m: my $l := (1,2); my $x = | $l.flat; quietly my $y = 1, 2; dd [[$x], [$y]] 16:24
camelia [[slip(1, 2),], [1]]?
jnthn The precedence of = is based on the sigil
my $a = 1, my $b = 2 # does the right thing 16:25
Zoffix Ah
OK
dogbert11 the failing tests in t/spec/S32-io/IO-Socket-INET.t seems to caused by 67455170 16:30
ugexe maybe because IO::Socket still uses the is default? 16:35
dogbert11 ugexe: you mean line like 'has $.nl-in is rw is default(["\n", "\r\n"]);' 16:54
*lines
ugexe right. but the commit you say is the cause was only on IO::Handle, so there has to be some intersetion somewhere 16:58
dogbert11 indeed 17:01
ugexe i dont see anything obvious 17:11
Zoffix I'm guessing the `is default` bug that was affecting IO::Handle now affects `is default` on socket, 'cause it was removed from handle. 17:14
try disabling spesh and stuff
Wonder how long it'll take people to notice the logotypes are missing from the modules.perl6.org :) 17:17
I think I'm not gonna put 'em back on search page; only on the (upcoming) dist page. With a lot of dists, we can't just make a sprite of all the logotypes any more and using them one-by-one on a search page, triggering hundreds of requests per page is also LTA 17:19
(also, they look like shit) 17:20
timotimo you got something against my art? :P 18:04
github.com/timo/ADT/blob/master/lo..._32x32.png
it's falwelss
AlexDaniel huh… 18:42
nvm :) 18:49
Zoffix No, but lots of art all one page is bad. 19:15
pmurias jnthn: do you have any suggestions how to make EVAL(q:to/END/) work with MONKEY-SEE-NO-EVAL cleanly? 20:58
jnthn pmurias: In what way does it not work? 21:04
m: EVAL 'say 42' 21:05
camelia 42?
jnthn m: EVAL "EVAL q:to/END/\nsay 42\nEND\n"
camelia 5===SORRY!5=== Error while compiling /home/camelia/EVAL_0?EVAL is a very dangerous function!!! (use the MONKEY-SEE-NO-EVAL pragma to override this error,?but only if you're VERY sure your data contains no injection attacks)?at /home/camelia/EVA…
jnthn Ah, it shouldn't warn 'cus it's literal? 21:06
Hmmm
pmurias: I'd dump the QAST at github.com/rakudo/rakudo/blob/nom/....nqp#L9205 and see what it's coming out as 21:11
timotimo yeah, it happens so early tha twe can't even get the --target=ast :D
maybe it barfs because the WVal(Str) is inside a Stmts?
jnthn Right, maybe something like that
Or because at that point all it has is a placeholder 21:12
timotimo we've had that kind of thing prevent the for optimization a bunch of times :)
like when you put in superstitious parens
it does show the error to be after the END
jnthn Well, that'll teach folks not to be superstitious :P
timotimo we'll just codegen a little sleep(0.01) at the end of every Stmts that only has one child node 21:13

Powered by Cro and the Raku® Programming Language.

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

Thank you!