llfourn FROGGS++ nine++ # fixing precomp 02:04
[Tux] This is Rakudo version 2016.05-143-g865bf36 built on MoarVM version 2016.05-18-g1339332 05:53
test 16.870
test-t 9.600
csv-parser 21.308
FROGGS that'd a bug, right? 06:11
m: class Foo { has $.a = 1; has $.b = 2 }; $_ = Foo.new; say .WHAT; say .a.WHAT ~~ .b.WHAT
camelia rakudo-moar 865bf3: OUTPUT«(Foo)␤Method 'b' not found for invocant of class 'Int'␤ in block <unit> at <tmp> line 1␤␤»
dalek p: 074f7fa | (Daniel Green)++ | docs/ops.markdown:
Add some documentation for the nqp::stmts op
 06:27
p: 5e1e41b | niner++ | docs/ops.markdown:
Merge pull request #290 from MasterDuke17/add_stmts_to_ops_doc

Add some documentation for the nqp::stmts op
timotimo .tell FROGGS don't forget that ~~ sets the $_ 06:49
FROGGS timotimo: yes, that's correct but still 07:13
m: class Foo { has $.a = 1; has $.b = 2 }; $_ = Foo.new; say .WHAT; say .a ~~ .b 07:14
camelia rakudo-moar 865bf3: OUTPUT«(Foo)␤Method 'b' not found for invocant of class 'Int'␤ in block <unit> at <tmp> line 1␤␤»
FROGGS m: class Foo { has $.a = 1; has $.b = 2 }; $_ = Foo.new; say .WHAT; say .a ~~ $_.b
camelia rakudo-moar 865bf3: OUTPUT«(Foo)␤Method 'b' not found for invocant of class 'Int'␤ in block <unit> at <tmp> line 1␤␤»
FROGGS I'm not sure it should do that
that it sets $_ behind the scenes should, well, stay behind the scenes 07:15
psch m: class Foo { has $.a = 1; has $.b = 2 }; $_ = Foo.new; say .WHAT; say { my $outer_ = $_; $_ = .a; .b.ACCEPTS($_); $_ = $outer_ }() # is what we do 07:20
camelia rakudo-moar 865bf3: OUTPUT«(Foo)␤Method 'b' not found for invocant of class 'Int'␤ in block <unit> at <tmp> line 1␤␤»
psch well, pretty close at least
there's no way to keep that behind the scenes
well, more than it is already
except if we don't actually use $_ there, but then we break other things
m: "foo" ~~ { .say } # like this 07:21
camelia rakudo-moar 865bf3: OUTPUT«foo␤»
psch heh, or $str ~~ rx// even
fwiw, i never really understood it as a "behind the scenes" thing 07:24
to me, setting setting $_ to the LHS inside the RHS thunk seems like an explicit feature
FROGGS_ well, I just wanted to say that "you cant see it in your code literally"
psch right, that's true. it's something to learn 07:25
FROGGS_ still I think we could resolve .b earlier than we do now 07:26
psch but how do you decide if we should do that or not? 07:27
'cause as mentioned, '$str ~~ /foo/' would either stop working, or we need heuristics to differentiate between those cases
FROGGS_ m: class Foo { has $.a = 1; has $.b = 2 }; $_ = Foo.new; say { my $outer_ = $_; my $rhs = .b; $_ = .a; $rhs.ACCEPTS($_); $_ = $outer_ }()
camelia rakudo-moar 865bf3: OUTPUT«Foo.new(a => 1, b => 2)␤»
FROGGS_ I dont see an issue (yet) with this line 07:28
maybe I try to implement it and see what happens 07:29
psch actually, i'm probably low on coffee, yeah
POC is a good idea :)
m: "foo" ~~ .say 07:35
camelia rakudo-moar 865bf3: OUTPUT«foo␤»
psch FROGGS_: ^^^ i think *that* is the case to be concerned about
FROGGS_: i suppose it depends on whether that's in roast
m: use Test; my $t = sub { Bool::True }; ok ($t ~~ .()), '~~ .() sub call truth (+)'; 07:37
camelia rakudo-moar 865bf3: OUTPUT«ok 1 - ~~ .() sub call truth (+)␤»
psch that's one test in S03-smartmatch/any-sub.t
FROGGS hmmm, true 07:43
yeah, we probably dont want to break that
eww, Missing or wrong version of dependency 'perl#sources/51E302443A2C8FF185ABC10CA1E5520EFEE885A1 (NativeCall::Types)' 08:02
nine meh 08:15
reproducible? 08:16
FROGGS probably by changing said source file and doing make install 08:17
psch hrm, this is troublesome 08:28
the hash i get from src/core/control in mast_frames is an actual Hash, not a BOOTHash or VMHash :/
nine psch: it is? I had hoped that my \mast_frames := nqp::hash(); is enough to avoid HLLization 08:29
psch nine: well, the case where it does have elems is the one that's hllized 08:30
nine: so i'd guess %*COMPILING<%?OPTIONS><mast_frames> hllizes
nine Or the call to $*W.add_additional_frames 08:31
psch yeah, or that
nine Probably the parameter needs to be \frames instead of $frames
psch actually, i'm wondering if i shouldn't detach the JCLASS carry-outer-around from what moar does there 08:33
it'd probably be easier to make that sensible that way
OTOH i'd probably also introduce a new #?if jvm
which i strongly dislike
oh, which reminds me, i wanted to try and see if we have the same kind of problem if we do BEGIN time EVAL-ish things in nqp 08:34
'cause if so, we'd probably want to fix it there anyway
which is of course kinda annoying to check for too, because it means spoofing EVAL somehow :/
nine psch: I'd go with an #?if jvm if it brings you closer to a working solution. The job is hard enough as it is and we can try reducing #?if again once we have a working baseline.
psch yeah, it's probably a similar case as with "i don't want to drag a sort sub into JAST::Compiler" yesterday :) 08:36
dalek kudo/nom: d927228 | lizmat++ | src/core/ (2 files):
Give IO::Special its own .new

Since that is faster with only one positional. The reason for this is that every time you start rakudo, this method gets called. So it's only a few microseconds, but it is for *every* invocation of rakudo.		 11:15
kudo/nom: ac0dcdd | FROGGS++ | / (4 files):
move HAS scope implementation from NativeCall to src/Perl6/

  See irclog.perlgeek.de/perl6/2016-06-14#i_12661602		 16:00
lizmat .tell FROGGS could you explain what ac0dcdd fixes (e.g. in the ChangeLog) ? 17:46
sexy-coder-girl .tell sexy-coder-girl about stuff 17:56
yoleaux2 sexy-coder-girl: Talking to yourself is the first sign of madness.
sexy-coder-girl yoleaux2: hey there, cheeky bot! Ctrl+C is a keystroke away! 17:57
.tell sexy-coder-guy hello
yoleaux2 sexy-coder-girl: I'll pass your message to sexy-coder-guy.
sexy-coder-guy yo
yoleaux2 17:57Z <sexy-coder-girl> sexy-coder-guy: hello
sexy-coder-girl Works \o/ 17:58
.join #perl6-release 18:01
FROGGS[mobile] lizmat: will do (tomorrow) 18:41
jnthn will get the JVM bits of the return stuff sorted out tomorrow :)
So hopefully it'll be mergable :)
FROGGS[mobile] is the release scheduled for this Thursday? 18:42
jnthn Possibly :)
FROGGS[mobile] heh 18:43
jnthn It feels a bit early in the month :P
sexy-coder-girl FROGGS[mobile]: Saturday
jnthn Oh...weeken
*weekend
OK, that means I'll feel OK about merging tomorrow :)
If the release was on Thursday it'd be cutting it a little close :P 18:44
Also in favor of the merge is that I can probably also fix a bug as part of the work
timotimo yay 18:47
FROGGS[mobile] all sounds nice :o) 18:48
timotimo and the performance implications for the future are also nice :) 18:49
FROGGS[mobile] timotimo: do you know if a profile exists for the Gtk::Simple precomp times? 18:50
jdv79 so does jnthn's recent remarks mean that explicit return could be the same cost of implicit?
timotimo i didn't make a profile 18:52
in particular, i'm not sure if running perl6 --profile-compile makes sense for that 18:54
but i can surely try
FROGGS[mobile] it spawns processes, right? 18:56
that would be a problem
timotimo i think it does, yes
jnthn jdv79: It eliminates some overhead from *all* routines whether they use return or not, and makes explicit `return` a good bit cheaper than it used to be 18:58
jdv79: And also opens the way to further optimizations to make it cheaper (close enough to "no difference") in the future 18:59
jdv79 cool 19:00
jnthn It also means that return is a real control exception and so will be possible to handle via CONTROL. 19:01
Which is probably of interest to nearly nobody :)
But does bring us in line with the design docs.
timotimo i can't install . in gtk-simple at the moment
jnthn Some day, somebody will probably do something terribly evil with it :)
dalek ast: 259cbf2 | (David Warring)++ | S02-types/pair.t:
fix test for RT #126369 - pair assignment
 19:02
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=126369
jdv79 one of my modules is still about an order of mag or a bit more slower than p5
timotimo gist.github.com/timo/246a9b4f5c69d...d8809b28ef - FROGGS[mobile] no clue what's up with that, but i'm about to hop out the door anyway
jdv79 its grammars mostly i think though which are still not optimized, right?
jnthn There's still a lot of room for improvement on those, yes. 19:03
afk for a bit :) 19:04
FROGGS[mobile] timotimo: I wanted to look into it anyway tomorrow 19:07
timotimo: perhaps I can reproduce
timotimo i was able to just rm the Build.pm and now it gets further 19:09
lizmat sanity check: if I have a for loop, and inside the loop "Routine.HOW.add_method" from Bookstrap is executed 19:12
that would be a bad thing, right ?
FROGGS[mobile] timotimo jnthn ^^^ ?
I mean, that's something you expect to run at compile time, no ? 19:13
FROGGS[mobile] since you can also programatically construct classes you can add methods in a loop 19:16
consider an ORM 19:17
lizmat yes, but sometthing like
for ^10000 { @a[4]:!delete:v }
shouldn't, right ?
FROGGS[mobile] but rakudo itself probably does not want to do this
what does that do? 19:18
what's the meaning of :!delete and :v? 19:19
lizmat well, I was looking at optimizing array / has slices with adverbs
:!delete:v is the worst case from the internal processing pov
FROGGS[mobile] do not delete the fifth element and return the value? 19:20
lizmat meaning: don't delete it, and give me the vaue
*value
yes
FROGGS[mobile] and this adds a method?
lizmat <anon> gen/moar/m-BOOTSTRAP.nqp:2048 is called 10009 for a 10000 iteration loop 19:21
taking 76.5% of CPU
FROGGS[mobile] what's the method name?
lizmat something is really wrong there
this is the code I profiled: 19:22
my @a = ^10; for ^10000 { my $b = @a[4]:exists }
actually:
my @a = ^10; for ^10000 { my $b = @a[4]:!delete:v }
ok, I should really be packing:
FROGGS[mobile] damn, now I have to boot up my laptop :o) 19:23
lizmat early trip to FRA tomorrow morning, then on to MCO 19:24
vendethiel MCO? 19:26
sexy-coder-girl m: my @a = ^4; say @a[2]:!delete:v; say @a 19:27
camelia rakudo-moar ac0dcd: OUTPUT«2␤[0 1 2 3]␤»
lizmat vendethiel: Orlande
*Orlando
vendethiel oh, okay :).
sexy-coder-girl What is :!delete:v do? What does it mean "not delete it and return value" isn't that the same as just @a[2]?
s/do/for/;
lizmat sexy-coder-girl: almost
m: my @a; dd @a[0]; dd @a[0]:v 19:28
camelia rakudo-moar ac0dcd: OUTPUT«Any @a = Any␤()␤»
FROGGS lizmat: it does not call add_method, it executes find_best_dispatchee
lizmat aaahhh, I think I know why...
sexy-coder-girl: the :v will not include missing values 19:29
sexy-coder-girl my @a[4]; say @a[2]:v; say @a[2]:!delete:v; say @a
m: my @a[4]; say @a[2]:v; say @a[2]:!delete:v; say @a
camelia rakudo-moar ac0dcd: OUTPUT«()␤()␤[(Any) (Any) (Any) (Any)]␤»
sexy-coder-girl lizmat: ok, then what's the :!delete? :)
lizmat do not delete
FROGGS a nnop?
noop*
lizmat usually you don't specify it like that
@a[4]:$delete 19:30
where $delete may be either True or False
sexy-coder-girl Ah, I see
FROGGS .oO( True or False or FileNotFound )
[Coke] hopes everyone has a good time in orlando at yapc. 19:31
FROGGS [Coke]: you wont be there? 19:32
[Coke] FROGGS: nope. only so much personal discretionary travel a year. 19:33
($dayjob won't cover my perl habit.)
FROGGS yeah, kinda the same here
[Coke] (though, really, if my kids and wife were out of school, orlando's a great place for family to visit while I'm hacking) 19:35
lizmat jnthn: I found something very disturbing: 21:27
m: multi sub a($a) { "none" }; multi sub a($a,:$foo!) { "foo" }; for ^100000 { a(42) }; say now - INIT now # this is fine!
camelia rakudo-moar ac0dcd: OUTPUT«0.041434␤»
lizmat m: multi sub a($a) { "none" }; multi sub a($a,:$foo!) { "foo" }; for ^100000 { a(42,:foo) }; say now - INIT now # WTF ?? 21:28
camelia rakudo-moar ac0dcd: OUTPUT«1.85012080␤»
lizmat m: say 1.85 / 0.04
camelia rakudo-moar ac0dcd: OUTPUT«46.25␤»
jnthn lizmat: Multi-dispatch caching doesn't know how to handle named parameters. 21:29
lizmat m: multi sub a($a,*%_) { "foo" }; for ^100000 { a(42,:foo) }; say now - INIT now # still bad, but better
camelia rakudo-moar ac0dcd: OUTPUT«0.68580747␤»
lizmat jnthn: I thought that required named params where treated like positionals? 21:30
or is that just a future plan ?
jnthn No
No that either.
There's just a special case to fast-reject incoming arguments that don't have the required name.
lizmat m: multi sub a($a,*%_) { "foo" }; for ^100000 { a(42) }; say now - INIT now # looks like I need to rewrite array_slice/hash_slice 21:31
jnthn (Which was put in to make trait dispatch a good bit faster)
camelia rakudo-moar ac0dcd: OUTPUT«0.041094␤»
lizmat ok, I guess I won't be translating perl6intro to Dutch while travelling after all 21:32
jnthn :)
lizmat but first, some sleep and some travel tomorrow 21:33
jnthn The caching mechanism can be extended to handle this.
It's just not entirely trivial.
And nameds on hot paths are relatively care.
*rare
lizmat except for things like @a[42]:exists
:-(
jnthn Right :)
Thing is 21:34
While that case isn't well-optimized *now*, it's the way that's most likely to be later 21:35
Because once the cache is smart enough, inlining can use it.
Meaning that :exists being present will be an optimization-time-resolved thing.
Uh, the was that's most likely to be *fastest* later 21:36
lizmat but until then, I guess we're better of with a single postcircumfix:<[ ]>($pos,*%_) candidate
jnthn I suspect I could get to trying the cache improvements this month.
I mean, in theory I can do them as the next thing I work on 21:37
Just means hyper/race get bumped down the list again.
But I'd rather do that than have you spend time rewriting them to a form that'll be somewhat faster now, but harder to make faster later. 21:38
lizmat no, fix hyper /race first
jnthn Well, guess I can look tomorrow how hard the cache improvement would be?
lizmat it will just be a matter of reverting the current state
jnthn I mean, if it's a day or two's work... :)
lizmat ok, can't stop you there 21:39
anyways, I think this should be lifted over the release anyay
anyway
sortiz FROGGS++ # Move HAS to perl6::GA, DBIish precomp time 1'34" -> 0'37", size 14M -> 3M
jnthn As in, solved after the release?
(In case it breaks anything)?
lizmat yeah
jnthn Sure...I can work in a branch :) 21:40
lizmat I won't be able to be much on the channel at least until Sunday
some R&R in Orlando :-)
jnthn OK. Give me the next days to look into it. If it's going to be really fraught, then we can go with the *%_ plan. 21:41
Then I'll really get to hyper/race after it :) 21:42
Also: safe journey, and enjoy the R&R :)
lizmat will do! 21:46
jnthn Talking of rest...time to sleep
'night 21:47
sortiz g'night jnthn
lizmat gnight! 21:49
sortiz g'night lizmat 21:52
timotimo wow, that precomp improvement could hit GTK::Simple noticably, too 21:57
sortiz Yep, I hope. 22:04

Powered by Cro and the Raku® Programming Language.

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

Thank you!