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
psch yeah, camelia was killed by some anti-spam/network-hammer-abuse-protection plugin 07:24
but the immediately preceeding output doesn't look particular in any way, so i'm wondering if freenode changed something... :)
nine__ Sucks big time :( I already wrote them an email, but no idea how long it's gonna take and how they'll react
psch i mean, it's just 6 replies in a 2 minute window vOv 07:25
timotimo "bots are forbidden!!!!" 07:34
psch i did at first think it might be a net op, that Sigyn 07:36
but it's just a plugin, so *probably* no drama coming :)
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:02
psch nine: i get (Any) 08:05
nine ok, thanks!
Maybe I should send this interaction to freenode admins as example for why camelia is invaluable ;) 08:06
psch hehe
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:55
I mean, I've written PROCESS::<$REPO> := ...; a hundred times :) And the variable should be available everywhere once a Perl 5 module is loaded. 08:56
lizmat nine: I think you could even make that lazy 09:29
nine Wonder if it would be worth it as you already have the cost of loading Inline::Perl5. 09:30
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?
lizmat oooh... eh... 09:32
no, because they're PROCESS::
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...
lizmat not GLOBAL:: or SETTING:: or whatever
PROCESS:: is out of everything and the final place where we look for dynamic vars before giving up 09:33
dalek kudo/nom: 131cad2 | lizmat++ | src/core/ (2 files):
Streamline dynamic variables setup/initialization

  - write in all nqp ops
  - create a Failure in INITIALIZE-DYNAMIC
   so we don't need to check for it in DYNAMIC
Looks like this shaved off 1msec of bare startup time		 10:32
timotimo lizmat: i wonder if the X metaop can be optimized at all? :)
lizmat timotimo: it's on my list :-) 10:33
meanwhile, in other news, TheDamian alerted me to some really strange behaviour wrt postcircumfix
timotimo just because larry showed that particular function in his "it's the end of the world ..." talk
oh crap!
lizmat $ 6 'multi postcircumfix:<< ⦋ ⦌ >>($a, $b) { }' 10:34
real0m0.178s
$ 6 'multi postcircumfix:<< ⦋ ⦌ >>($a, $b) { $a }
real0m0.462s
timotimo ... huh 10:36
lizmat try creating --profile-compile with these :-) 10:37
timotimo actually ... i think i need to take a little nap before i do anything anywhere 10:38
lizmat hehe,,,
anyways, the first has about 19K NQPArray allocations, the latter has about 10x as many NQPArray allocations
timotimo o_O
NQPArray could very well be from regex NFAs
lizmat why would the *body* of the postcircumfix make that change ? 10:39
mergesubstates in NQP seems to be the largest user
anyways, having multiple ones seems to make things O2 worse 10:40
jnthn: could you shed light on gist.github.com/lizmat/7243e7abd32...c0a6f65025 ? 10:47
psch oh boy, i gotta run that on perl6-j :) 10:48
real 0m23.483s 10:49
that's lots better than i feared
lizmat the slowdown is really in NQP, so... 10:50
it feels as a worst case of needing to rewrite the P6 grammar 4 times 10:51
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:52
psch right, still i'd have expected a somewhat comparable scaling 10:53
and "perl6-j -e'1'" takes almost 5 seconds
whereas on moar that's probably at around .5 or so seconds?
so r-j only taking twice as long as moar on a given piece of slow code is surprising to me 10:54
lizmat psch: about .115 for me 10:57
psch right, and .115 : 5 != 11 : 23 10:58
that's all, just a bit of a surprise :)
timotimo lizmat: would it be enough to --target=parse?
for the profile, i mean 11:00
in theory, we could put in a --profile-compile=STAGE flag that'll only run profiling for a part of the compilation process
because the difference is just when you call nqp::startprofile and nqp::endprofile
lizmat well, --target=parse apparently generates a lot of output 11:01
timotimo oh, yeah, that's true
maybe --output=/dev/null :)
lizmat several GB's worth, by the look of it
it builds it all in memory, I killed it at 1.5GB 11:02
timotimo oh crap.
lizmat timotimo: get a nap first :-)
this has been sitting there possibly for years already :-) 11:03
timotimo mhh
i don't have time for a nap, i have some place to be real soon >_<
and then i'll spend all the rest of the day on my feet
lizmat at least since Christmas, as the problem also exists in 2015.12
timotimo and my legs are already mad at me for running around town this morning, and also sprinting to catch a tram
dalek kudo/nom: 79f9be1 | lizmat++ | src/core/ (3 files):
More of the same of a37cd221210bf242b5ad

  - Bag.total
  - Mix.WHICH/total
  - Set.WHICH/total		 11:19
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:18
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:19
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
top by exclusive time: mergesubstates (gen/moar/stage2/QRegex.nqp:617)
mergesubrule (gen/moar/stage2/QRegex.nqp:514)
find_method (gen/moar/stage2/nqpmo.nqp:1296)
optimize (gen/moar/stage2/QRegex.nqp:780)
jnthn Yup, mergesub* is all NFA computation 12:21
And probably optimize too
lizmat: Well, less of one perhaps 12:22
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 :)
lizmat hehe, so, should I make a ticket for it with TheDamian's original mail?
and this conversation ? 12:23
jnthn Well, there's two issues
One is that we seemingly re-compute the grammar for the very same postcircumfix.
We should only be doing it once.
e.g. I'd only expect a big delay between Compiling... and First after 12:24
I'd expect it to be nearly nothing from then on.
lizmat ah, ok, yes, that makes sense
jnthn So that's a fairly clear-cut bug and that one should be comparatively easy to fix.
Then there's the second issue of adding new operators wanting a smarter NFA invalidation (or re-use) approach 12:25
Which is more a missing optimization than a bug. And a headache for one of us some day. :-)
To be fair it's not really *that* bad.
I just fear there'll be corner cases hiding. :) 12:26
lizmat will it disappear in precomp ?
psch i had thought a bit about canonicalization of categorical, but there doesn't seem to be a great solution
+s
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
especially considering ::() lookup
jnthn I think if you precomp a module defining a new operator then yeah, you should pay for it only during the compile
Of course if you *export* such an operator then the thing importing it will need its local languge tweaked and so have to pay
lizmat but of course, if that gets precompiled, then we shouldn't have that issue during runtime, right ? 12:28
jnthn Right 12:30
Noting though that lack of NFA re-use implies the precomp files will be sizable which may impact initial load time.
dalek kudo/nom: e5c909c | lizmat++ | src/core/Hash.pm:
Make Hash[Any,Any].ASSIGN-KEY about 15% faster

  - rewritten using nqp ops
  - smarter handling of empty typed hashes
Almost not worth it, but such a basic functionality can use all the optimization it can get		 12:31
lizmat afk& 12:55
psch well, add_categorical seems to bail correctly for the multi test case above 13:25
at least it doesn't reenter the postcircumfix branch
gfldex camelia has fallen, can someone help her up please? 13:57
psch gfldex: not really, no. the server hosting camelia got banned 13:58
AlexDaniel here too, evalable will be doing the job of camelia for now, just kick it when camelia comes back 14:55
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:04
jnthn: i got about a 20% chance to get all sorts of errors, including segfaults 15:05
jnthn: you would greatly improve my productivity if you could make them go away :)
jnthn gfldex: Does it use race/hyper? Those are certainly near the top of my list of things to look at 15:07
(Basically, top once I have a day when my brane is up for concurrency work :))
MasterDuke gfldex: do you mean --parallel=2? 15:08
jnthn: if that's what he means then no, it's using start and Proc::Async 15:11
mst possibly stupid question - let's say I install moar, then nqp, then rakudo, all separately 15:27
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:28
gfldex jnthn: just `do await start {}` 15:29
gfldex: no, I did not mean parallel
MasterDuke: no, I did not mean parallel 15:30
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:38
*are some MoarVM... 15:39
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.
*kill off
mst jnthn: hmm. ok, let me /achieve myself
it seems like the --gen-foo options to configure scripts do an install of whatever the foo was
which is totally fine for "I'm doing a build into ~/local" or whatever 15:40
but 15:42
if I can't configure nqp without moar installed, then I need to split the packages really
and if I can't configure rkaudo without nqp, same
OTOH if I could get rakduo to configure against an nqp build dir and nqp to configure against a moar build dir
*that* I could work with 15:43
jnthn: so, basically, it seems like my options are (a) bend the build system or (b) make it three packages
and you're saying that (b) is currently 'mostly', moving to 'yes' later 15:44
so I wonder if that means that's the best idea?
jnthn mst: I'm guessing --prefix is not useful?
mst hrm?
--prefix is already involved and not really the point I don't think
jnthn Yeah, I suspected not because you're talking about configuring against an NQP build dir rather than the install dir... 15:45
...which gives me the slight problem that I can't figure out what you're trying to do.
But yeah, 3 separate packages has been the more typical way so far.
mst lemme /achieve myself harder then
(when I say that, it's short for
step back. explain what you're trying to achieve.
jnthn Though at present they're forced to be exactly in step with each other.
mst which is an irssi alias of mine) 15:46
fundamentally
I am trying to achieve "nothing gets installed into the prefix except during 'make install' time"
if that means I need to have three 'make install' phases, that's what I'll do
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.
mst right, which, boo :) 15:48
and I'm guessing that 'install to scratch dir, move it later' will run into relocatability issues and fun 15:49
(my *eventual* goal here is to revive the Rakudo::Star cpan dist)
jnthn Right
mst I think Alien::MoarVM, Alien::NQP, then Rakudo::Star as separate dists 15:50
is going to be least confusing for the moment
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?
mst I want to honour the principle that any given cpan dist only installs things during 'make install' time
I am completely open as to how toa chieve that
'3 dists' is fine
jnthn Yeah, which is fair enough. But does imply 3 packages that depend on each other.
At the moment, anyway
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"
just before I went and tried the 3 dist thing I figured I'd check
like, if I'd done it and then you'd gone "but why didn't you just X?" I'd've facedesked hard
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: rt.perl.org/Ticket/Display.html?id...et-history and discussion: irclog.perlgeek.de/perl6-dev/2016-0...i_12889080
mst jnthn: so, basically, "given the constraints, 3 dists makes sense" ? 15:53
jnthn mst: Yes, it's how I'd do it 15:55
mst cool. I'll get round to that at some point then 15:56
jnthn TimToady: Hope you had a nice trip :)
TimToady the catacombs were nice and cool when it was 39℃ on the surface :) 15:57
jnthn Ouch...that's hot
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
lotsa smartfolk doing cool stuff there
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
jnthn ah, OK :)
TimToady when I'm outside the echo chamber, I don't have to make up as much new stuffs :)
next year is in Barcelona, would encourage anyone to go and talk there 16:01
jnthn Hm, that'll be hot too :P
TimToady that's the problem with going to cheap conferences
mst I dunno, the less cheap ones keep moving to Austin 16:07
that's not really cool either
TimToady oscon also moved up to May 16:25
gfldex jnthn: i left it running in a loop and produced the following output. It seams not to segfault anymore. gist.github.com/gfldex/8beab4e4025...538178398d 19:04
jnthn gfldex: Interesting, looks like an occasional bogus multi-dispatch fail 19:12
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?
22 Jul 2016 12:53Z <unmatched}> pmichaud: is there a possibility of adding several trusted users to twitter.com/rakudoperl Twitter account, so we could post announcements such us weeklies and R* releases?
jnthn evening, pmichaud o/ 19:15
gfldex jnthn: there is a 2nd file in the gist where i put the outlier in
pmichaud unmatched}: Sure, we can add trusted users to the twitter account. Umm.... how do I do that? 19:16
TimToady I was just offered the perl6 twitter account, which we might maybe could do something with 19:17
timotimo hey pm 19:19
what should the sub that turns a uni codepoint's name into the char be called in p6?
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.
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128586
pmichaud evening, jnthn o/ 19:22
TimToady pmichaud: first undefined doesn't work so well for purposes of list comprehensions 19:26
and that bit of spec was written before Slip even existed
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
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
to be able to help with the Str.Int issue that came up a couple of weeks ago
andthen looked promising, but if that's not the way to do it, I'm curious as to what is the way :) 19:30
with/else doesn't really do waht I wanted either 19:31
TimToady how 'bout notandthen 19:32
pmichaud well, here's the issue
originally the Int method of class Str had the following:
return self.Numeric.Int;
(or something like that) 19:33
the problem was that for a non-numeric string, the exception would be immediately thrown
so "a".Int would throw an exception, while "a".Numeric would return an unthrown Failure
so, one could potentially do something like return self.Numeric andthen .Int
but only if infix:<andthen> returned its LHS 19:34
TimToady with self.Numeric { return .Int } else { .return } 19:35
pmichaud Feels "heavy", especially for a built-in.
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
*general
?
pmichaud lizmat: functionality in general
lizmat ok, *phew* :-)
pmichaud I'm fine with the nqp:: stuff that lives in the setting now
but being able to pass-through Failures is something we perhaps should address
what I *really* wanted was to be able to say self.Numeric.¤Int 19:38
where .¤ really meant "invoke this method if the invocate is not failure, otherwise return the invocant"
*invocant
also, I think that with self.Numeric { return .Int } else { .return } might have the effect of marking the Failure as handled 19:39
m: my $a = "a".Numeric; with $a { 1 } else { 0 }; say $a.handled;
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
pmichaud the best I came up with was given self.Numeric { when Failure { $_ }; .Int } 19:41
TimToady m: say "a".Numeric.?Int
evalable TimToady: gist.github.com/fed73dd2a70004922e...5e9f832e33
pmichaud I believe .?Int means "invoke Int if it exists" 19:42
in this case, .Int definitely exists on both Failure and Str
(and Numeric)
TimToady m: say Failure ~~ Nil
evalable TimToady: |«HEAD»: True
TimToady m: my $a = "a".Numeric.?Int; say $a.WHAT 19:43
evalable TimToady: gist.github.com/0bf8426ad6df2c3b31...c3c6ac66b7
TimToady what's up with the gists?
lizmat TimToady: camelia got banned from freenode
geekosaur this isn't camelia (which apparently got klined or something?)
TimToady ah
pmichaud ...but I'm not getting gists for my requests. Does it have to do with length of output? 19:44
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.
my $a = "a".Numeric; say ($a.xyz).WHAT
m: my $a = "a".Numeric; say ($a.xyz).WHAT
evalable pmichaud: gist.github.com/d9348c3b0edfa7c0cf...3780583a1a
timotimo bengoldberg also just got killed by the same antispam thing
TimToady remind me not to be too productive :) 19:46
pmichaud timotimo: doesn't look like the failure got pass-throughed
mst timotimo: antispam thing?
lizmat: wait, what?
you have a bot banned and nobody bothered telling me?
lizmat it's banning people now as well, apparently 19:47
BenGoldberg (~BenGoldbe@ool-457214ac.dyn.optonline.net) left IRC (Killed (Sigyn (Spam is off topic on freenode.)))
just now on #perl6
pmichaud m: my $a = "a".Numeric; say $a.WHAT; say ($a.?xyz).WHAT 19:48
evalable pmichaud: gist.github.com/f71d89e868002cbc98...c92e10b324
pmichaud I think my general off-the-top-of-my-head thoughts on Failure passthrough are at irclog.perlgeek.de/perl6/2016-07-09#i_12813298 19:49
and the difference between (if unless with) and (&& || //) discussed at irclog.perlgeek.de/perl6/2016-07-09#i_12813421 19:50
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)
so that andthen, passthen, defthen are like && || // but topicalize the LHS 19:52
and test for truth, failure, and definedness
dalek kudo/nom: 78915a8 | lizmat++ | src/core/Hash.pm:
Make my %h{Any}; (%h<a> = 42) = 666 work

Not sure if this ever worked before, but it should, as
   my %h; (%h<a> = 42) = 666
and:
   my Int %h; (%h<a> = 42) = 666
have always worked.
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
and without them automatically being thrown
but perhaps it's not common enough to worry about. 19:54
TimToady there could maybe be a .? variant that checked for ~~ Nil
pmichaud right, that's where I was going with .¤
TimToady that's why we made failure derived from Nil
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
pmichaud Nil sure has morphed a lot in the development of this language. :) 19:56
But "Nil is the most mild form of Failure" doesn't raise any alarm bells for me.
I won't take exception to it. :) 19:57
timotimo pm, yes, those methods are special cased iirc
pmichaud timotimo: which methods are special cased?
timotimo Int and such, on Failure 19:58
i seem to recall
pmichaud I think they're just defined for Failure
I don't think there's anything really "special" about them.
essentially, if you ask a Failure for its value, you throw its underlying exception 19:59
timotimo defined, yes
all others go through fallback
pmichaud I didn't see that.
m: my $a = "a".Numeric; say $a.WHAT; say ($a.xyz).WHAT
evalable pmichaud: gist.github.com/013b6cf05c15345010...fb817bc2b1
pmichaud in that one, the Failure gets thrown -- it's not passed through (i.e., no fallback) 20:00
anyway, these are all food-for-thought notions. 20:03
I have to get back to $dayjob, so bbl
dalek kudo/nom: 944e439 | lizmat++ | src/core/Hash.pm:
Make Hash[Any,Any].BIND-KEY about 15% faster

  - rewrite in nqp ops
  - be smarter about handling uninitialized hashes		 20:11
kudo/nom: 60100c9 | lizmat++ | src/core/Hash.pm:
Make Hash[Any,Any].EXISTS-KEY about 10% faster

On an initialized hash. Again, not much, but basic functionality.		 20:39
kudo/nom: 1724f8d | lizmat++ | src/core/Hash.pm:
Make Hash[Any,Any].DELETE-KEY 10% faster

  - rewrite in nqp::ops
  - actually 25x faster when checking hash without storage
   well, could be more, because this is now not doing an unneccesary .WHICH		 21:14
kudo/nom: 32c08b1 | lizmat++ | src/core/Hash.pm:
Streamline Hash[Any,Any].keys|value|kv|pairs|antipairs

  - the MappyIterator role already handles uninited / empty hashes
   so no need to check for definedness here as well
  - rewrite pull-one's in nqp::ops
   which should specifically help .kv
  - this now returns Seq for uninited / empty hashes (before: List)
   as it should have from the beginning		 21:48
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()␤»
gfldex what should that do?
awwaiid I guess that's the problem with types only being checked at assignment time. Maybe :delete should similarly raise an exception 21:59
lizmat gfldex: I'm not sure what you think the problem is ? 22:00
gfldex may be related to: github.com/rakudo/rakudo/pull/829
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␤»
lizmat m: my Int:D @a = 1; @a[0]:delete; say @a.elems # deleting from the end reduces size
camelia rakudo-moar 1724f8: OUTPUT«0␤»
gfldex lizmat: it's all good then
lizmat yeah, :delete "removes" value, Nil assigns the default value
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;
camelia rakudo-moar 1724f8: OUTPUT«Array[Int:D] @a = Array[Int:D].new(Int:D, 1)␤2␤»
lizmat m: my Int:D @a = 1; @a[0] = Nil; say @a.elems # deleting from the end reduces size
camelia rakudo-moar 1724f8: OUTPUT«1␤»
gfldex well ...
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]␤»
lizmat m: my @a is default(42) = 666; dd @a; @a[0]:delete; dd @a
camelia rakudo-moar 1724f8: OUTPUT«Array @a = [666]␤Array @a = []␤»
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␤»
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␤»
lizmat m: my @a; dd @a[0] # same, without default
camelia rakudo-moar 1724f8: OUTPUT«Any @a = Any␤»
lizmat m: my Int:D @a; dd @a[0] # same, but typed
camelia rakudo-moar 1724f8: OUTPUT«Int:D @a = Int:D␤»
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)␤»
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)␤»
lizmat so, afaics, it's all good
awwaiid m: my Int:D @a = 1, 2; @a[0] = Int:D
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␤␤»
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)␤»
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␤»
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
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.
mst must admit, that seems a trifle odd to me as well
gfldex That bug report will be rereported over and over again. 22:12
lizmat well, Nil is defined as returning a container to its default state 22:13
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␤»
lizmat and that's exactly what it is doing
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.
lizmat m: my Int:D $a = 42; dd $a; $a = Int; dd $a
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␤␤»
awwaiid m: my Int $x where * > 3 = 7; $x = Nil; say $x # similar thing I noticed
camelia rakudo-moar 32c08b: OUTPUT«(<anon>)␤»
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
Nil is a sort of Failure
it is *not* an undefined value as such
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
awwaiid m: my $n where *.defined = 7; $n = Nil; say $n; say Nil.defined
camelia rakudo-moar 32c08b: OUTPUT«(<anon>)␤False␤»
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.
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
awwaiid yeah. exactly what makes me nervous :) 22:19
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␤␤»
lizmat m: say Int:D.defined
camelia rakudo-moar 32c08b: OUTPUT«False␤»
gfldex so if you really mean Int:D you have to write `Int:D where * !=:= Nil`
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␤␤»
gfldex that's even more absurd
small Python children will point with fingers at us :( 22:22
awwaiid But at least JS will continue to admire our prowess
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␤␤»
awwaiid hm! 22:24
m: my Int:D $a = Nil # but this
camelia ( no output )
lizmat m: my Int:D $a := Nil
camelia rakudo-moar 32c08b: OUTPUT«Type check failed in binding; expected Int:D but got Nil (Nil)␤ in block <unit> at <tmp> line 1␤␤»
lizmat because that's assignment, not binding 22:25
awwaiid oh
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
generally I feel like bindings are a smell of me doing something abnormal or fancy to some degree, so I avoid it
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␤␤»
gfldex m: sub niler{Nil}; my Int:D @a; @a[0] = niler(); for @a -> Int:D $i { say $i }
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␤␤»
awwaiid lizmat: ya, that one makes sense
gfldex m: sub niler{Nil}; my Int:D @a; @a[0] = niler(); for @a { say $i }
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 }␤»
gfldex m: sub niler{Nil}; my Int:D @a; @a[0] = niler(); for @a { .say } 22:28
camelia rakudo-moar 32c08b: OUTPUT«(Int:D)␤»
awwaiid oh well. I'm off to whatch Ghostbusters! C'y'all later
gfldex that makes it really hard to reason about values for @a. A novice programmer will almost always get it wrong.
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.
lizmat but that's the entire point of Failures: that they *don't* blow on assignment
and since Nil is a form of Failure, the same goes for that 22:31
gfldex I agree that this is a good idea for any container but the ones that explicitely ask for defined values. 22:32
lizmat well, I suggest you make a rakudobug @LARRY for this 22:34
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;
camelia rakudo-moar 32c08b: OUTPUT«Int:D $i1 = Int:D␤<anon> $i2 = <anon>␤»
lizmat is tired and goes to bed 22:36
good night, #perl6-dev
gfldex lizmat: there is one already and also a PR by skids
i was just wondering what Int:D @a does.
pmurias lizmat: good night
yoleaux2 21 Jul 2016 10:56Z <jnthn> pmurias: it seems you forgot to commit t/nqp/019-chars.txt in 3f34d27f95
travis-ci Rakudo build errored. Elizabeth Mattijsen 'Make Hash[Any,Any].DELETE-KEY 10% faster 22:38
travis-ci.org/rakudo/rakudo/builds/146909422 github.com/rakudo/rakudo/compare/6...24f8d7a813
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>)␤»
gfldex this really seams to need more thinking
filed as #128710 22:58
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128710

Powered by Cro and the Raku® Programming Language.

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

Thank you!