Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6-dev, 2016-07-23

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

All times shown according to UTC.

Time Nick Message
06:55 RabidGravy joined #perl6-dev
07:08 vendethiel- joined #perl6-dev
07:19 nine__ joined #perl6-dev
07:23 * psch wonders if something about freenodes anti-spam policy changed
07:23 nine__ My server was banned on freenode this night :( I guess it's because I host camelia
07:24 psch yeah, camelia was killed by some anti-spam/network-hammer-abuse-protection plugin
07:24 psch but the immediately preceeding output doesn't look particular in any way, so i'm wondering if freenode changed something... :)
07:24 nine__ Sucks big time :( I already wrote them an email, but no idea how long it's gonna take and how they'll react
07:25 psch i mean, it's just 6 replies in a 2 minute window vOv
07:32 [TuxCM] joined #perl6-dev
07:34 timotimo "bots are forbidden!!!!"
07:36 psch i did at first think it might be a net op, that Sigyn
07:36 psch but it's just a plugin, so *probably* no drama coming :)
07:59 nine joined #perl6-dev
08:02 nine psch: do you have a rakudo-j at hand and can give me the output of: module Foo { our %h := class :: does Associative { method AT-KEY($name) { "foo" } }.new; %Foo::h<bar>.say; };
08:05 psch nine: i get (Any)
08:05 nine ok, thanks!
08:06 nine Maybe I should send this interaction to freenode admins as example for why camelia is invaluable ;)
08:06 psch hehe
08:55 nine Suddenly the solution was so obvious: PROCESS::<%PERL5> := class :: does Associative { multi method AT-KEY($name) { Inline::Perl5.default_perl5.global($name) } }.new;
08:56 nine I mean, I've written PROCESS::<$REPO> := ...; a hundred times :) And the variable should be available everywhere once a Perl 5 module is loaded.
09:29 lizmat nine: I think you could even make that lazy
09:30 nine Wonder if it would be worth it as you already have the cost of loading Inline::Perl5.
09:31 lizmat yeah, probably  :-)
09:31 nine Now that I think of it, I wonder how this actually works with precompilation. Are those PROCESS:: variables part of the GLOBALish that gets merged on module loading?
09:32 lizmat oooh...  eh...
09:32 lizmat no, because they're PROCESS::
09:32 nine I mean it does obviously work. I'm just not sure how :) And that after spending quite some time in this part ouf our code base...
09:32 lizmat not GLOBAL:: or SETTING:: or whatever
09:33 lizmat PROCESS:: is out of everything and the final place where we look for dynamic vars before giving up
09:44 FROGGS joined #perl6-dev
10:32 dalek rakudo/nom: 131cad2 | lizmat++ | src/core/ (2 files):
10:32 dalek rakudo/nom: Streamline dynamic variables setup/initialization
10:32 dalek rakudo/nom:
10:32 dalek rakudo/nom: - write in all nqp ops
10:32 dalek rakudo/nom: - create a Failure in INITIALIZE-DYNAMIC
10:32 dalek rakudo/nom:   so we don't need to check for it in DYNAMIC
10:32 dalek rakudo/nom:
10:32 dalek rakudo/nom: Looks like this shaved off 1msec of bare startup time
10:32 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/131cad2c21
10:32 timotimo lizmat: i wonder if the X metaop can be optimized at all? :)
10:33 lizmat timotimo: it's on my list  :-)
10:33 lizmat meanwhile, in other news, TheDamian alerted me to some really strange behaviour wrt postcircumfix
10:33 timotimo just because larry showed that particular function in his "it's the end of the world ..." talk
10:33 timotimo oh crap!
10:34 lizmat $ 6 'multi postcircumfix:<< ⦋ ⦌ >>($a, $b) { }'
10:34 lizmat real0m0.178s
10:34 lizmat $ 6 'multi postcircumfix:<< ⦋ ⦌ >>($a, $b) { $a }
10:34 lizmat real0m0.462s
10:36 timotimo ... huh
10:37 lizmat try creating --profile-compile with these  :-)
10:38 timotimo actually ... i think i need to take a little nap before i do anything anywhere
10:38 lizmat hehe,,,
10:38 lizmat anyways, the first has about 19K NQPArray allocations, the latter has about 10x as many NQPArray allocations
10:38 timotimo o_O
10:38 timotimo NQPArray could very well be from regex NFAs
10:39 lizmat why would the *body* of the postcircumfix make that change ?
10:39 lizmat mergesubstates in NQP seems to be the largest user
10:40 lizmat anyways, having multiple ones seems to make things O2 worse
10:47 lizmat jnthn: could you shed light on https://gist.github.com/lizmat/7243e7abd32bbe9eab56ddc0a6f65025 ?
10:48 psch oh boy, i gotta run that on perl6-j :)
10:49 psch real    0m23.483s
10:49 psch that's lots better than i feared
10:50 lizmat the slowdown is really in NQP, so...
10:51 lizmat it feels as a worst case of needing to rewrite the P6 grammar 4 times
10:52 lizmat anyways, if I --profile-compile the gist, I get a file so large my browser won't eat it before my patience runs out
10:53 psch right, still i'd have expected a somewhat comparable scaling
10:53 psch and "perl6-j -e'1'" takes almost 5 seconds
10:53 psch whereas on moar that's probably at around .5 or so seconds?
10:54 psch so r-j only taking twice as long as moar on a given piece of slow code is surprising to me
10:57 lizmat psch: about .115 for me
10:58 psch right, and .115 : 5 != 11 : 23
10:58 psch that's all, just a bit of a surprise :)
10:58 timotimo lizmat: would it be enough to --target=parse?
11:00 timotimo for the profile, i mean
11:00 timotimo in theory, we could put in a --profile-compile=STAGE flag that'll only run profiling for a part of the compilation process
11:00 timotimo because the difference is just when you call nqp::startprofile and nqp::endprofile
11:01 lizmat well, --target=parse apparently generates a lot of output
11:01 timotimo oh, yeah, that's true
11:01 timotimo maybe --output=/dev/null :)
11:01 lizmat several GB's worth, by the look of it
11:02 lizmat it builds it all in memory, I killed it at 1.5GB
11:02 timotimo oh crap.
11:02 lizmat timotimo: get a nap first  :-)
11:03 lizmat this has been sitting there possibly for years already  :-)
11:03 timotimo mhh
11:03 timotimo i don't have time for a nap, i have some place to be real soon >_<
11:03 timotimo and then i'll spend all the rest of the day on my feet
11:03 lizmat at least since Christmas, as the problem also exists in 2015.12
11:03 timotimo and my legs are already mad at me for running around town this morning, and also sprinting to catch a tram
11:19 dalek rakudo/nom: 79f9be1 | lizmat++ | src/core/ (3 files):
11:19 dalek rakudo/nom: More of the same of a37cd221210bf242b5ad
11:19 dalek rakudo/nom:
11:19 dalek rakudo/nom: - Bag.total
11:19 dalek rakudo/nom: - Mix.WHICH/total
11:19 dalek rakudo/nom: - Set.WHICH/total
11:19 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/79f9be158e
11:41 MasterDuke joined #perl6-dev
11:49 cognominal joined #perl6-dev
12:17 lucs joined #perl6-dev
12:18 jnthn lizmat: I suspect that it's somehow failing to realize it already added the postcircumfix to the grammar the first time, so re-derives. Probably some kind of bug in name canonicalization.
12:19 jnthn lizmat: And of course that combines badly with us completely re-computing the NFAs for the Perl 6 grammar rather than trying to only figure out the impacted ones.
12:20 lizmat and when we had a smaller Perl 6 grammar, that wasn't such an issue maybe ?
12:20 MasterDuke jnthn, lizmat, timotimo: fwiw, i looked at a profile-compile of that gist in the QT profiler viewer
12:20 MasterDuke top by exclusive time: mergesubstates (gen/moar/stage2/QRegex.nqp:617)
12:20 MasterDuke mergesubrule (gen/moar/stage2/QRegex.nqp:514)
12:20 MasterDuke find_method (gen/moar/stage2/nqpmo.nqp:1296)
12:20 MasterDuke optimize (gen/moar/stage2/QRegex.nqp:780)
12:21 jnthn Yup, mergesub* is all NFA computation
12:21 jnthn And probably optimize too
12:22 jnthn lizmat: Well, less of one perhaps
12:22 jnthn lizmat: But it's always been a known thing that we're putting off until somebody wants to do the kinda tricky work to improve it :)
12:22 lizmat hehe, so, should I make a ticket for it with TheDamian's original mail?
12:23 lizmat and this conversation ?
12:23 jnthn Well, there's two issues
12:23 jnthn One is that we seemingly re-compute the grammar for the very same postcircumfix.
12:23 jnthn We should only be doing it once.
12:24 jnthn e.g. I'd only expect a big delay between Compiling... and First after
12:24 jnthn I'd expect it to be nearly nothing from then on.
12:24 lizmat ah, ok, yes, that makes sense
12:24 jnthn So that's a fairly clear-cut bug and that one should be comparatively easy to fix.
12:25 jnthn Then there's the second issue of adding new operators wanting a smarter NFA invalidation (or re-use) approach
12:25 jnthn Which is more a missing optimization than a bug. And a headache for one of us some day. :-)
12:25 jnthn To be fair it's not really *that* bad.
12:26 jnthn I just fear there'll be corner cases hiding. :)
12:26 lizmat will it disappear in precomp ?
12:26 psch i had thought a bit about canonicalization of categorical, but there doesn't seem to be a great solution
12:26 psch +s
12:27 psch i mean, we always have at least one grapheme that has to have different delimiters, and that makes it all a bit annoying
12:27 psch especially considering ::() lookup
12:27 jnthn I think if you precomp a module defining a new operator then yeah, you should pay for it only during the compile
12:27 jnthn Of course if you *export* such an operator then the thing importing it will need its local languge tweaked and so have to pay
12:28 lizmat but of course, if that gets precompiled, then we shouldn't have that issue during runtime, right ?
12:30 jnthn Right
12:30 jnthn Noting though that lack of NFA re-use implies the precomp files will be sizable which may impact initial load time.
12:31 dalek rakudo/nom: e5c909c | lizmat++ | src/core/Hash.pm:
12:31 dalek rakudo/nom: Make Hash[Any,Any].ASSIGN-KEY about 15% faster
12:31 dalek rakudo/nom:
12:31 dalek rakudo/nom: - rewritten using nqp ops
12:31 dalek rakudo/nom: - smarter handling of empty typed hashes
12:31 dalek rakudo/nom:
12:31 dalek rakudo/nom: Almost not worth it, but such a basic functionality can use all the
12:31 dalek rakudo/nom: optimization it can get
12:31 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/e5c909cf36
12:55 lizmat afk&
13:25 psch well, add_categorical seems to bail correctly for the multi test case above
13:25 psch at least it doesn't reenter the postcircumfix branch
13:42 geekosaur joined #perl6-dev
13:43 geekosaur joined #perl6-dev
13:46 skids joined #perl6-dev
13:57 gfldex camelia has fallen, can someone help her up please?
13:58 psch gfldex: not really, no.  the server hosting camelia got banned
14:26 AlexDaniel joined #perl6-dev
14:53 evalable joined #perl6-dev
14:55 AlexDaniel here too, evalable will be doing the job of camelia for now, just kick it when camelia comes back
15:01 RabidGravy joined #perl6-dev
15:04 gfldex jnthn: if you want to dig into problems with threading, you can pull the docs, edit Makefile to have --threads=2 and run `make bigpage` a few times. You can also add --no-cache to rule out precomp interactions.
15:05 gfldex jnthn: i got about a 20% chance to get all sorts of errors, including segfaults
15:05 gfldex jnthn: you would greatly improve my productivity if you could make them go away :)
15:07 jnthn gfldex: Does it use race/hyper? Those are certainly near the top of my list of things to look at
15:07 jnthn (Basically, top once I have a day when my brane is up for concurrency work :))
15:08 MasterDuke gfldex: do you mean --parallel=2?
15:11 MasterDuke jnthn: if that's what he means then no, it's using start and Proc::Async
15:27 mst possibly stupid question - let's say I install moar, then nqp, then rakudo, all separately
15:28 mst if I install a newer version of moar to the same prefix, should I expect the things on top of it to still be happy?
15:29 gfldex jnthn: just `do await start {}`
15:29 gfldex gfldex: no, I did not mean parallel
15:30 gfldex MasterDuke: no, I did not mean parallel
15:38 jnthn mst: NQP will be; Rakudo, thanks to its current use of extension ops, will *usually* be, but can't be relied on (e.g. it's useful in development to avoid rebuilding all the things all the time, but there are MoarVM changes that need a re-comp of the extension ops).
15:39 jnthn *are some MoarVM...
15:39 jnthn I'm aiming to kill of our need for ext op stuff and that'll mean the answer can be a straight "yes" in the future.
15:39 jnthn *kill off
15:39 mst jnthn: hmm. ok, let me /achieve myself
15:39 mst it seems like the --gen-foo options to configure scripts do an install of whatever the foo was
15:40 mst which is totally fine for "I'm doing a build into ~/local" or whatever
15:42 mst but
15:42 mst if I can't configure nqp without moar installed, then I need to split the packages really
15:42 mst and if I can't configure rkaudo without nqp, same
15:42 mst OTOH if I could get rakduo to configure against an nqp build dir and nqp to configure against a moar build dir
15:43 mst *that* I could work with
15:43 mst jnthn: so, basically, it seems like my options are (a) bend the build system or (b) make it three packages
15:44 mst and you're saying that (b) is currently 'mostly', moving to 'yes' later
15:44 mst so I wonder if that means that's the best idea?
15:44 jnthn mst: I'm guessing --prefix is not useful?
15:44 mst hrm?
15:44 mst --prefix is already involved and not really the point I don't think
15:45 jnthn Yeah, I suspected not because you're talking about configuring against an NQP build dir rather than the install dir...
15:45 jnthn ...which gives me the slight problem that I can't figure out what you're trying to do.
15:45 jnthn But yeah, 3 separate packages has been the more typical way so far.
15:45 mst lemme /achieve myself harder then
15:45 mst (when I say that, it's short for
15:45 mst step back. explain what you're trying to achieve.
15:45 jnthn Though at present they're forced to be exactly in step with each other.
15:46 mst which is an irssi alias of mine)
15:46 mst fundamentally
15:46 mst I am trying to achieve "nothing gets installed into the prefix except during 'make install' time"
15:46 mst if that means I need to have three 'make install' phases, that's what I'll do
15:47 mst but if I can do it so I only have one at the end, that would be moar awesome
15:47 jnthn Ah...yeah, the build system assumes that you have an installed Moar before doing NQP, and so on.
15:48 mst right, which, boo :)
15:49 mst and I'm guessing that 'install to scratch dir, move it later' will run into relocatability issues and fun
15:49 mst (my *eventual* goal here is to revive the Rakudo::Star cpan dist)
15:49 jnthn Right
15:50 mst I think Alien::MoarVM, Alien::NQP, then Rakudo::Star as separate dists
15:50 mst is going to be least confusing for the moment
15:50 jnthn Ah, and you want one "make install" for everything rather than things being able to fail part way through and have only some of it installed?
15:50 mst I want to honour the principle that any given cpan dist only installs things during 'make install' time
15:50 mst I am completely open as to how toa chieve that
15:50 mst '3 dists' is fine
15:50 jnthn Yeah, which is fair enough. But does imply 3 packages that depend on each other.
15:50 jnthn At the moment, anyway
15:51 jnthn Getting relocation to work would solve this various other things.
15:51 mst yeah. I have no problem with doing that, especially since you said basically "it'll mostly work now, and become totally reliable later"
15:51 mst just before I went and tried the 3 dist thing I figured I'd check
15:51 mst like, if I'd done it and then you'd gone "but why didn't you just X?" I'd've facedesked hard
15:52 * TimToady back home from Rome
15:52 yoleaux2 22 Jul 2016 14:48Z <unmatched}> TimToady: would you offer comments on whether my Int:D $i = Nil; should be accepted? There's a ticket for it: https://rt.perl.org/Ticket/Display.html?id=127958#ticket-history and discussion: http://irclog.perlgeek.de/perl6-dev/2016-07-22#i_12889080
15:53 mst jnthn: so, basically, "given the constraints, 3 dists makes sense" ?
15:55 jnthn mst: Yes, it's how I'd do it
15:56 mst cool. I'll get round to that at some point then
15:56 jnthn TimToady: Hope you had a nice trip :)
15:57 TimToady the catacombs were nice and cool when it was 39℃ on the surface :)
15:57 jnthn Ouch...that's hot
15:58 * jnthn was in Rome last October and it felt like half of things he wanted to see were undergoing reconstruction...
15:58 TimToady Curry On was a good conference
15:58 TimToady lotsa smartfolk doing cool stuff there
15:59 jnthn I saw the video of your talk already made it online...didn't see it yet :)
15:59 TimToady well, it's mostly the release talk rewarmed
15:59 jnthn ah, OK :)
15:59 TimToady when I'm outside the echo chamber, I don't have to make up as much new stuffs :)
16:01 TimToady next year is in Barcelona, would encourage anyone to go and talk there
16:01 jnthn Hm, that'll be hot too :P
16:01 TimToady that's the problem with going to cheap conferences
16:02 [TuxCM] joined #perl6-dev
16:07 mst I dunno, the less cheap ones keep moving to Austin
16:07 mst that's not really cool either
16:25 TimToady oscon also moved up to May
18:40 awwaiid joined #perl6-dev
19:04 gfldex jnthn: i left it running in a loop and produced the following output. It seams not to segfault anymore. https://gist.github.com/gfldex/8beab4e40250ad5c27e1ad538178398d
19:12 jnthn gfldex: Interesting, looks like an occasional bogus multi-dispatch fail
19:14 pmichaud hello perl6-dev
19:14 yoleaux2 12 Jul 2016 17:57Z <[Coke]> pmichaud: - I thought the SYN were not the spec, why are you opening tickets citing the syn as the source of truth?
19:14 yoleaux2 22 Jul 2016 12:53Z <unmatched}> pmichaud: is there a possibility of adding several trusted users to https://twitter.com/rakudoperl Twitter account, so we could post announcements such us weeklies and R* releases?
19:15 jnthn evening, pmichaud o/
19:15 gfldex jnthn: there is a 2nd file in the gist where i put the outlier in
19:16 pmichaud unmatched}: Sure, we can add trusted users to the twitter account.  Umm.... how do I do that?
19:17 TimToady I was just offered the perl6 twitter account, which we might maybe could do something with
19:19 timotimo hey pm
19:19 timotimo what should the sub that turns a uni codepoint's name into the char be called in p6?
19:20 lizmat mst: we've already let O'Reilly know that we're not going to go to OSCON in Austin on account of some stupid laws that have been passed recently in TX
19:20 pmichaud Coke: In your yoleaux message of 12 Jul, I think you're referring to RT #128586.  If so, it's not so much that I'm citing S03 as authoritative as that I think I prefer S03's description to what Rakudo is actually doing.
19:20 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=128586
19:22 pmichaud evening, jnthn   o/
19:26 TimToady pmichaud: first undefined doesn't work so well for purposes of list comprehensions
19:26 TimToady and that bit of spec was written before Slip even existed
19:28 pmichaud TimToady:  sure, I can go with that.
19:28 TimToady plus we now have the with/else construct when you really care about the undef
19:29 pmichaud I was mainly looking for a way to have a test that returned the left-hand-side if it's a Failure
19:29 pmichaud to be able to help with the Str.Int issue that came up a couple of weeks ago
19:30 pmichaud andthen looked promising, but if that's not the way to do it, I'm curious as to what is the way :)
19:31 pmichaud with/else doesn't really do waht I wanted either
19:32 TimToady how 'bout notandthen
19:32 pmichaud well, here's the issue
19:32 pmichaud originally   the Int method of class Str had the following:
19:32 pmichaud return self.Numeric.Int;
19:33 pmichaud (or something like that)
19:33 pmichaud the problem was that for a non-numeric string, the exception would be immediately thrown
19:33 pmichaud so   "a".Int would throw an exception, while "a".Numeric would return an unthrown Failure
19:33 pmichaud so, one could potentially do something like     return self.Numeric andthen .Int
19:34 pmichaud but only if infix:<andthen> returned its LHS
19:35 TimToady with self.Numeric { return .Int } else { .return }
19:35 pmichaud Feels "heavy", especially for a built-in.
19:37 pmichaud what I *really* wanted was to be able to say     self.Numeric.¤Int
19:37 lizmat pmichaud: is this about changing the code that now lives in the setting, or is this more about the functionality in genetal
19:37 lizmat *general
19:37 lizmat ?
19:37 pmichaud lizmat: functionality in general
19:37 lizmat ok, *phew*  :-)
19:37 pmichaud I'm fine with the nqp:: stuff that lives in the setting now
19:37 pmichaud but being able to pass-through Failures is something we perhaps should address
19:38 pmichaud what I *really* wanted was to be able to say     self.Numeric.¤Int
19:38 pmichaud where .¤   really meant  "invoke this method if the invocate is not failure, otherwise return the invocant"
19:38 pmichaud *invocant
19:39 pmichaud also, I think that    with self.Numeric { return .Int } else { .return }   might have the effect of marking the Failure as handled
19:39 pmichaud m:  my $a = "a".Numeric;   with $a { 1 } else { 0 };  say $a.handled;
19:39 evalable pmichaud: |«HEAD»: WARNINGS for /tmp/ZOJXe9RSjI:␤Useless use of constant integer 0 in sink context (line 1)␤Useless use of constant integer 1 in sink context (line 1)␤True
19:41 pmichaud the best I came up with was     given self.Numeric { when Failure { $_ }; .Int }
19:41 TimToady m: say "a".Numeric.?Int
19:41 evalable TimToady: https://gist.github.com/fed73dd2a70004922e0dfa5e9f832e33
19:42 pmichaud I believe .?Int  means "invoke Int if it exists"
19:42 pmichaud in this case, .Int definitely exists on both Failure and Str
19:42 pmichaud (and Numeric)
19:42 TimToady m: say Failure ~~ Nil
19:42 evalable TimToady: |«HEAD»: True
19:43 TimToady m: my $a = "a".Numeric.?Int; say $a.WHAT
19:43 evalable TimToady: https://gist.github.com/0bf8426ad6df2c3b31c02bc3c6ac66b7
19:43 TimToady what's up with the gists?
19:43 lizmat TimToady: camelia got banned from freenode
19:43 geekosaur this isn't camelia (which apparently got klined or something?)
19:43 TimToady ah
19:44 pmichaud ...but I'm not getting gists for my requests.  Does it have to do with length of output?
19:45 timotimo dont we already return self from any method called on failures, but .Int and other coercers throw?
19:45 pmichaud timotimo: possibly, but that doesn't help in this case.
19:45 pmichaud my $a = "a".Numeric;  say ($a.xyz).WHAT
19:45 pmichaud m: my $a = "a".Numeric;  say ($a.xyz).WHAT
19:45 evalable pmichaud: https://gist.github.com/d9348c3b0edfa7c0cf2c4b3780583a1a
19:45 timotimo bengoldberg also just got killed by the same antispam thing
19:46 TimToady remind me not to be too productive :)
19:46 pmichaud timotimo: doesn't look like the failure got pass-throughed
19:46 mst timotimo: antispam thing?
19:46 mst lizmat: wait, what?
19:46 mst you have a bot banned and nobody bothered telling me?
19:47 lizmat it's banning people now as well, apparently
19:47 lizmat BenGoldberg (~BenGoldbe@ool-457214ac.dyn.optonline.net) left IRC (Killed (Sigyn (Spam is off topic on freenode.)))
19:47 lizmat just now on #perl6
19:48 pmichaud m: my $a = "a".Numeric;  say $a.WHAT; say ($a.?xyz).WHAT
19:48 evalable pmichaud: https://gist.github.com/f71d89e868002cbc98eefac92e10b324
19:49 pmichaud I think my general off-the-top-of-my-head thoughts on Failure passthrough are at http://irclog.perlgeek.de/perl6/2016-07-09#i_12813298
19:50 pmichaud and the difference between   (if unless with)  and  (&& || //)  discussed at http://irclog.perlgeek.de/perl6/2016-07-09#i_12813421
19:51 TimToady perhaps .fail on a handled failure should return the unhandled version
19:51 pmichaud the if/unless/with work well for comprehensions, returning slips when the condition isn't met.  whereas the && || // forms return the last evaluated operand (that didn't meet the test)
19:52 pmichaud so that   andthen, passthen, defthen    are like && || //  but topicalize the LHS
19:52 pmichaud and test for truth, failure, and definedness
19:52 dalek rakudo/nom: 78915a8 | lizmat++ | src/core/Hash.pm:
19:52 dalek rakudo/nom: Make my %h{Any}; (%h<a> = 42) = 666 work
19:52 dalek rakudo/nom:
19:52 dalek rakudo/nom: Not sure if this ever worked before, but it should, as
19:52 dalek rakudo/nom:
19:52 dalek rakudo/nom:   my %h; (%h<a> = 42) = 666
19:52 dalek rakudo/nom:
19:52 dalek rakudo/nom: and:
19:52 dalek rakudo/nom:
19:52 dalek rakudo/nom:   my Int %h; (%h<a> = 42) = 666
19:52 dalek rakudo/nom:
19:52 dalek rakudo/nom: have always worked.
19:52 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/78915a8276
19:53 pmichaud It just really felt like there ought to be a concise way to pass Failure objects through a sequence of method calls without having to do a lot of smartmatching and testing along the way
19:53 pmichaud and without them automatically being thrown
19:54 pmichaud but perhaps it's not common enough to worry about.
19:54 TimToady there could maybe be a .? variant that checked for ~~ Nil
19:54 pmichaud right, that's where I was going with .¤
19:54 TimToady that's why we made failure derived from Nil
19:55 pmichaud Failure derived from Nil is new to me... I'll have to think about that.  But yes, at first blush that feels more "generalized" than explicitly testing for Failure.
19:55 TimToady Nil is just the most mild form of Failure, as it were
19:56 pmichaud Nil sure has morphed a lot in the development of this language.  :)
19:56 pmichaud But "Nil is the most mild form of Failure" doesn't raise any alarm bells for me.
19:57 pmichaud I won't take exception to it.  :)
19:57 timotimo pm, yes, those methods are special cased iirc
19:57 pmichaud timotimo: which methods are special cased?
19:58 timotimo Int and such, on Failure
19:58 timotimo i seem to recall
19:58 pmichaud I think they're just defined for Failure
19:58 pmichaud I don't think there's anything really "special" about them.
19:59 pmichaud essentially, if you ask a Failure for its value, you throw its underlying exception
19:59 timotimo defined, yes
19:59 timotimo all others go through fallback
19:59 pmichaud I didn't see that.
19:59 pmichaud m: my $a = "a".Numeric;  say $a.WHAT; say ($a.xyz).WHAT
19:59 evalable pmichaud: https://gist.github.com/013b6cf05c153450101651fb817bc2b1
20:00 pmichaud in that one, the Failure gets thrown -- it's not passed through (i.e., no fallback)
20:03 pmichaud anyway, these are all food-for-thought notions.
20:03 pmichaud I have to get back to $dayjob, so bbl
20:11 dalek rakudo/nom: 944e439 | lizmat++ | src/core/Hash.pm:
20:11 dalek rakudo/nom: Make Hash[Any,Any].BIND-KEY about 15% faster
20:11 dalek rakudo/nom:
20:11 dalek rakudo/nom: - rewrite in nqp ops
20:11 dalek rakudo/nom: - be smarter about handling uninitialized hashes
20:11 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/944e43963d
20:26 camelia joined #perl6-dev
20:39 dalek rakudo/nom: 60100c9 | lizmat++ | src/core/Hash.pm:
20:39 dalek rakudo/nom: Make Hash[Any,Any].EXISTS-KEY about 10% faster
20:39 dalek rakudo/nom:
20:39 dalek rakudo/nom: On an initialized hash.  Again, not much, but basic functionality.
20:39 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/60100c92ca
21:14 dalek rakudo/nom: 1724f8d | lizmat++ | src/core/Hash.pm:
21:14 dalek rakudo/nom: Make Hash[Any,Any].DELETE-KEY 10% faster
21:14 dalek rakudo/nom:
21:14 dalek rakudo/nom: - rewrite in nqp::ops
21:14 dalek rakudo/nom: - actually 25x faster when checking hash without storage
21:14 dalek rakudo/nom:   well, could be more, because this is now not doing an unneccesary .WHICH
21:14 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/1724f8d7a8
21:17 TimToady joined #perl6-dev
21:27 RabidGravy joined #perl6-dev
21:48 dalek rakudo/nom: 32c08b1 | lizmat++ | src/core/Hash.pm:
21:48 dalek rakudo/nom: Streamline Hash[Any,Any].keys|value|kv|pairs|antipairs
21:48 dalek rakudo/nom:
21:48 dalek rakudo/nom: - the MappyIterator role already handles uninited / empty hashes
21:48 dalek rakudo/nom:   so no need to check for definedness here as well
21:48 dalek rakudo/nom: - rewrite pull-one's in nqp::ops
21:48 dalek rakudo/nom:   which should specifically help .kv
21:48 dalek rakudo/nom: - this now returns Seq for uninited / empty hashes (before: List)
21:48 dalek rakudo/nom:   as it should have from the beginning
21:48 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/32c08b17cd
21:55 gfldex m: my Int:D @a; @a[0] = 1; @a[0]:delete; dd @a;
21:55 camelia rakudo-moar 1724f8: OUTPUT«Array[Int:D] @a = Array[Int:D].new()␤»
21:55 gfldex what should that do?
21:59 awwaiid I guess that's the problem with types only being checked at assignment time. Maybe :delete should similarly raise an exception
22:00 lizmat gfldex: I'm not sure what you think the problem is ?
22:00 gfldex may be related to: https://github.com/rakudo/rakudo/pull/829
22:01 lizmat m: my @a = 1; @a[0]:delete; say @a.elems   # deleting from the end reduces size
22:01 camelia rakudo-moar 1724f8: OUTPUT«0␤»
22:01 lizmat m: my Int:D @a = 1; @a[0]:delete; say @a.elems   # deleting from the end reduces size
22:01 camelia rakudo-moar 1724f8: OUTPUT«0␤»
22:01 gfldex lizmat: it's all good then
22:01 lizmat yeah, :delete "removes" value, Nil assigns the default value
22:02 lizmat but keeps the element alive
22:02 gfldex m: my Int:D @a; @a[0,1] = 1,1; @a[0] = Nil; dd @a, @a.elems;
22:02 camelia rakudo-moar 1724f8: OUTPUT«Array[Int:D] @a = Array[Int:D].new(Int:D, 1)␤2␤»
22:02 lizmat m: my Int:D @a = 1; @a[0] = Nil; say @a.elems   # deleting from the end reduces size
22:02 camelia rakudo-moar 1724f8: OUTPUT«1␤»
22:02 gfldex well ...
22:03 lizmat m: my @a is default(42) = 666; dd @a; @a[0] = Nil; dd @a
22:03 camelia rakudo-moar 1724f8: OUTPUT«Array @a = [666]␤Array @a = [42]␤»
22:03 lizmat m: my @a is default(42) = 666; dd @a; @a[0]:delete; dd @a
22:03 camelia rakudo-moar 1724f8: OUTPUT«Array @a = [666]␤Array @a = []␤»
22:04 lizmat m: my @a is default(42) = 666; dd @a; @a[0]:delete; dd @a[0]
22:04 camelia rakudo-moar 1724f8: OUTPUT«Array @a = [666]␤Int @a = 42␤»
22:05 lizmat m: my @a is default(42); dd @a[0]  # also when not assigned to begin with
22:05 camelia rakudo-moar 1724f8: OUTPUT«Int @a = 42␤»
22:05 lizmat m: my @a; dd @a[0]  # same, without default
22:05 camelia rakudo-moar 1724f8: OUTPUT«Any @a = Any␤»
22:05 lizmat m: my Int:D @a; dd @a[0]  # same, but typed
22:05 camelia rakudo-moar 1724f8: OUTPUT«Int:D @a = Int:D␤»
22:06 gfldex m: my Int:D @a = 1; dd @a; @a[0] = Nil; for @a { .say };
22:06 camelia rakudo-moar 1724f8: OUTPUT«Array[Int:D] @a = Array[Int:D].new(1)␤(Int:D)␤»
22:07 awwaiid m: my Int:D @a = 1, 2; @a[0]:delete; dd @a
22:07 camelia rakudo-moar 1724f8: OUTPUT«Array[Int:D] @a = Array[Int:D].new(Int:D, 2)␤»
22:07 lizmat so, afaics, it's all good
22:07 awwaiid m: my Int:D @a = 1, 2; @a[0] = Int:D
22:07 camelia rakudo-moar 1724f8: OUTPUT«Type check failed in assignment to @a; expected Int:D but got Int:D␤  in block <unit> at <tmp> line 1␤␤»
22:08 gfldex m: my Int:D @a = 1; dd @a; @a[0]:delete; for @a { .say };
22:08 camelia rakudo-moar 1724f8: OUTPUT«Array[Int:D] @a = Array[Int:D].new(1)␤»
22:09 gfldex m: my Int:D @a = 1; dd @a; @a[0] = Nil; for @a { .defined.say };
22:09 camelia rakudo-moar 1724f8: OUTPUT«Array[Int:D] @a = Array[Int:D].new(1)␤False␤»
22:10 gfldex I do not agree on that one. I asked for an Array of defined values and when I iterate over it, I get a undefined value. Not what I asked for.
22:10 awwaiid gfldex: I think this has been a long-running confusion of mine, that you can assign Nil
22:11 awwaiid but I asked a while back and was told that it's expected. I think this was an explicit decision at some point about how the type system works
22:11 gfldex I'm fine that you can assign Nil, but I do not agree that you can assign Nil to a :D-typesmilied container.
22:11 mst must admit, that seems a trifle odd to me as well
22:12 gfldex That bug report will be rereported over and over again.
22:13 lizmat well, Nil is defined as returning a container to its default state
22:14 lizmat m: my Int:D $a = 42; dd $a; $a = Nil; dd $a
22:14 camelia rakudo-moar 32c08b: OUTPUT«Int $a = 42␤Int:D $a = Int:D␤»
22:14 lizmat and that's exactly what it is doing
22:14 gfldex that doesn't change the fact that I asked for a defined value, what means I want an exception if something undefined is assigned to it.
22:14 [TuxCM] joined #perl6-dev
22:14 lizmat m: my Int:D $a = 42; dd $a; $a = Int; dd $a
22:14 camelia rakudo-moar 32c08b: OUTPUT«Int $a = 42␤Type check failed in assignment to $a; expected Int:D but got Int (Int)␤  in block <unit> at <tmp> line 1␤␤»
22:14 awwaiid m: my Int $x where * > 3 = 7; $x = Nil; say $x # similar thing I noticed
22:14 camelia rakudo-moar 32c08b: OUTPUT«(<anon>)␤»
22:15 gfldex lizmat: if :D is not the way to guard against undefined values, what is the proper way then?
22:15 lizmat but that's the whole thing
22:15 lizmat Nil is a sort of Failure
22:15 lizmat it is *not* an undefined value as such
22:16 awwaiid my $n where *.defined = 7; $n = Nil; say $n; say Nil.defined
22:16 lizmat when assigning Nil, it should return the container to its default state
22:16 awwaiid m: my $n where *.defined = 7; $n = Nil; say $n; say Nil.defined
22:16 camelia rakudo-moar 32c08b: OUTPUT«(<anon>)␤False␤»
22:17 lizmat well, one could argue that Nil.defined should return Bool rather than False
22:17 gfldex The problem is then the contradiction of a :D-typesmilied container and it's default value.
22:18 awwaiid but since it returns false, seems like the guard should fail. I have no idea why it works. In general Nil does unintuitive things -- so far I've just avoided it altogether, but it scares me that it could pass so many safety checks
22:18 gfldex awwaiid: you can't avoid Nil as any sub/method call can return it
22:19 awwaiid yeah. exactly what makes me nervous :)
22:20 gfldex m: sub f(Int:D $i where * !=:= Nil){ say 'glad' }; sub niler{Nil}; f(niler());
22:20 camelia rakudo-moar 32c08b: OUTPUT«Type check failed in binding $i; expected Int but got Nil (Nil)␤  in sub f at <tmp> line 1␤  in block <unit> at <tmp> line 1␤␤»
22:20 lizmat m: say Int:D.defined
22:20 camelia rakudo-moar 32c08b: OUTPUT«False␤»
22:20 gfldex so if you really mean Int:D you have to write `Int:D where * !=:= Nil`
22:21 gfldex m: sub f(Int:D $i where .defined){ say 'glad' }; sub niler{Nil}; f(niler());
22:21 camelia rakudo-moar 32c08b: OUTPUT«Type check failed in binding $i; expected Int but got Nil (Nil)␤  in sub f at <tmp> line 1␤  in block <unit> at <tmp> line 1␤␤»
22:21 gfldex that's even more absurd
22:22 gfldex small Python children will point with fingers at us :(
22:22 awwaiid But at least JS will continue to admire our prowess
22:23 lizmat m: sub a(Int:D $a) { }; a Nil  # what's wrong with this then ?
22:23 camelia rakudo-moar 32c08b: OUTPUT«Type check failed in binding $a; expected Int but got Nil (Nil)␤  in sub a at <tmp> line 1␤  in block <unit> at <tmp> line 1␤␤»
22:24 awwaiid hm!
22:24 awwaiid m: my Int:D $a = Nil # but this
22:24 camelia rakudo-moar 32c08b: ( no output )
22:24 lizmat m: my Int:D $a := Nil
22:24 camelia rakudo-moar 32c08b: OUTPUT«Type check failed in binding; expected Int:D but got Nil (Nil)␤  in block <unit> at <tmp> line 1␤␤»
22:25 lizmat because that's assignment, not binding
22:25 awwaiid oh
22:26 awwaiid I get so confused between assignment and binding when it comes to things like this. I guess I should figure it out more deeply
22:26 awwaiid generally I feel like bindings are a smell of me doing something abnormal or fancy to some degree, so I avoid it
22:27 lizmat m: my $a := 42; $a = 666
22:27 camelia rakudo-moar 32c08b: OUTPUT«Cannot assign to an immutable value␤  in block <unit> at <tmp> line 1␤␤»
22:27 gfldex m: sub niler{Nil}; my Int:D @a; @a[0] = niler(); for @a -> Int:D $i { say $i }
22:27 camelia rakudo-moar 32c08b: OUTPUT«Parameter '$i' requires an instance of type Int:D, but a type object was passed.  Did you forget a .new?␤  in block <unit> at <tmp> line 1␤␤»
22:27 awwaiid lizmat: ya, that one makes sense
22:27 gfldex m: sub niler{Nil}; my Int:D @a; @a[0] = niler(); for @a { say $i }
22:27 camelia rakudo-moar 32c08b: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Variable '$i' is not declared␤at <tmp>:1␤------> Int:D @a; @a[0] = niler(); for @a { say ⏏$i }␤»
22:28 gfldex m: sub niler{Nil}; my Int:D @a; @a[0] = niler(); for @a { .say }
22:28 camelia rakudo-moar 32c08b: OUTPUT«(Int:D)␤»
22:28 awwaiid oh well. I'm off to whatch Ghostbusters! C'y'all later
22:28 gfldex that makes it really hard to reason about values for @a. A novice programmer will almost always get it wrong.
22:30 lizmat gfldex: what is your expected outcome of that ?
22:30 gfldex I would prefer any Nil or Failure to blow at the assignment, rather on useage of the value. Because between the two 10 minutes could pass, given I work with big datasets.
22:30 lizmat but that's the entire point of Failures: that they *don't* blow on assignment
22:31 lizmat and since Nil is a form of Failure, the same goes for that
22:32 gfldex I agree that this is a good idea for any container but the ones that explicitely ask for defined values.
22:34 lizmat well, I suggest you make a rakudobug @LARRY for this
22:35 lizmat complete support for the type smileys were added quite near Christmas, and maybe we haven't thought this out well enough
22:35 gfldex m: sub niler{Nil}; my Int:D $i1 = niler(); my Int:D $i2 where .defined = niler(); dd $i1, $i2;
22:35 camelia rakudo-moar 32c08b: OUTPUT«Int:D $i1 = Int:D␤<anon> $i2 = <anon>␤»
22:35 pmurias joined #perl6-dev
22:36 * lizmat is tired and goes to bed
22:36 lizmat good night, #perl6-dev
22:36 gfldex lizmat: there is one already and also a PR by skids
22:36 gfldex i was just wondering what Int:D @a does.
22:36 pmurias lizmat: good night
22:36 yoleaux2 21 Jul 2016 10:56Z <jnthn> pmurias: it seems you forgot to commit t/nqp/019-chars.txt in 3f34d27f95
22:38 travis-ci joined #perl6-dev
22:38 travis-ci Rakudo build errored. Elizabeth Mattijsen 'Make Hash[Any,Any].DELETE-KEY 10% faster
22:38 travis-ci https://travis-ci.org/rakudo/rakudo/builds/146909422 https://github.com/rakudo/rakudo/compare/60100c92ca58...1724f8d7a813
22:38 travis-ci left #perl6-dev
22:40 gfldex m: sub niler{Nil}; my Int:D $i where .defined = niler(); say $i; say $i.WHAT;
22:40 camelia rakudo-moar 32c08b: OUTPUT«(<anon>)␤(<anon>)␤»
22:40 gfldex this really seams to need more thinking
22:44 [TuxCM] joined #perl6-dev
22:58 gfldex filed as #128710
22:58 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=128710

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