babydrop m: use nqp; class Z { method z (Mu \SELF:) { dd [ nqp::iscont(SELF), nqp::iscont(self) ] } }; my $z = Z.new; $z.z 00:43
camelia rakudo-moar 0c75e5: OUTPUT«[1, 0]␤»
babydrop Is there any case where self would be nqp::iscont()? I see nqp::decont(self) in Mu.clone which I think isn't needed, based on the above
dalek rakudo/nom: 9a161fa | (Zoffix Znet)++ | src/core/Mu.pm: 01:36
rakudo/nom: Prevent Mu.clone from incorrectly marking all attrs as inited
rakudo/nom:
rakudo/nom: Fixes RT#130271: rt.perl.org/Ticket/Display.html?id=130271
rakudo/nom:
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=130271
dalek rakudo/nom: Using nqp::getattr() or nqp::bindattr() on an attribute makes
rakudo/nom: nqp::attrinited return true. This made cloned Baggies lose their
rakudo/nom: .WHICH value, since its method uses nqp::attrinted to decide whether
rakudo/nom: to give its $!WHICH attribute. And in the ticket we have a cloned
rakudo/nom: Baggy, since the infix:<but> operator clones under the hood. And
rakudo/nom: this is the reason for the error in the ticket, since the .WHICH value
rakudo/nom: is unboxed into a native str at one point.
rakudo/nom:
rakudo/nom: Fix by checking whether an attribute is nqp::attrinted before to
babydrop rakudo/nom: decide whether to call getattr/bindattr. 01:37
review: github.com/rakudo/rakudo/commit/9a...d97ba81a50
dalek ast: ebfab26 | (Zoffix Znet)++ | S02-types/WHICH.t:
Test cloned Baggies have defined WHICH

RT#130271: rt.perl.org/Ticket/Display.html?id=130271 Rakudo fix: github.com/rakudo/rakudo/commit/9a161fa0c92ea7		 01:38
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=130271
babydrop samcv: BTW, to get a commit bit for rakudo, one has to sign the CLA and (e)mail it to The Perl Foundation: www.perlfoundation.org/contributor_..._agreement 01:57
samcv: just mentioning it, 'cause it took me months to find out that was a requirement :P
samcv ah
but why don't other pull requests make you agree? 01:58
babydrop No idea. 01:59
dalek kudo/nom: f9d34a9 | (Fernando Correa de Oliveira)++ | src/core/Int.pm:
Fix UInt not smartmatching undefined Int
 02:04
kudo/nom: d21d8ab | (Zoffix Znet)++ | src/core/Int.pm:
Merge pull request #947 from FCO/uint-match-unsigned-int

Fix UInt not smartmatching undefined Int
ast: c506ea5 | (Fernando Correa de Oliveira)++ | S32-num/int.t:
Add test for smatmatch UInt with undefined Int (#194)
samcv babydrop, the Linguist repo makes you do such a thing 02:10
for people who have not gotten a pull accepted before
it's one of the checks
wait did you actually have to mail it there 02:11
babydrop samcv: I'm pretty sure email is fine. When I mailed mine, I somehow managed to mail it to the wrong address and it got returned to me and then lizmat hooked me up with a contact whom I just emailed a digital version 02:12
samcv ah 02:13
would we want to have somebody look at the CLA ( could be on our project they read it) and click accept?
babydrop Just for PRs?
samcv yeah. or nobody cares? lol 02:14
babydrop I rather not add barriers to contribution.
samcv yeah. i thought that too
it wasn't the easiest. it just said "1 check failed" or whatever when you hadn't signed it
though courts have said that if you contribute source code, and they have a license it implies that you are submitting the code under that license unless you specify otherwise. 02:15
babydrop Makes sense. 02:16
geekosaur ...courts where though? 02:21
samcv oh USA i think? 02:41
maybe others. not sure
kalkin- who do I have to please to get github.com/rakudo/rakudo/pull/948 merged? (It passed all checks) 04:06
:) 04:07
samcv kalkin-, readline is initialized here already github.com/kalkin/rakudo/blob/9043...EPL.pm#L58 05:51
does it work if you remove that line? 05:52
actually hold on. just don't initialize readline inside that method
> my $read = $Readline.new; that will make it lexical
will be a nice feature to have 05:53
kalkin-, also see how it loads github.com/kalkin/rakudo/blob/9043...EPL.pm#L60 files here
make sure it doesn't read the history until after this 05:54
nine samcv: I emailed my CLA, too. If you don't get a reply in a reasonable time, Coke++ can help. 07:58
samcv oh i didn't fill out a CLA yet ;P 07:59
but will remember for in the future
brrt btw, nine, i've resolved the issue with rakudo building on even-moar-jit
thanks for pointing it out :-) 08:00
nine brrt++ 08:03
dalek kudo/nom: e9ce28a | samcv++ | src/core/io_operators.pm:
Make routines say, note and put 25% faster to stdout
 08:16
kudo/nom: 99f04e0 | niner++ | src/core/io_operators.pm:
Merge pull request #949 from samcv/say

Make routines say, note and put 25% faster to stdout.
nine lizmat: this ^^^ looks like something our static optimizer may be able to do automatically 08:21
[Tux] This is Rakudo version 2016.11-194-gd21d8abbd built on MoarVM version 2016.11-44-g8e24145d 08:26
csv-ip5xs 3.205
test 14.206
test-t 6.335
csv-parser 14.092
dalek nqp: 7fed81d | samcv++ | src/HLL/Grammar.nqp: 09:02
nqp: Add four new pairs of matched delimiters brackets/parens (#330)
nqp:
nqp: These are the only four pairs in Unicode that we don't have
nqp: added.
lizmat samcv++ # good catch on say and friends! 10:06
jnthn is a bit surprised it makes such a difference 10:08
The static optimizer should be able to lower such a lexical to a local at some point, though
Oh, I bet I can guess why it was costly... It probably created a nativeref 'cus it can't prove statically that .print doesn't want an "is rw" thing 10:10
And spesh can't strip them out in that case yet either
timotimo yup, native refs are a big reason our code isn't optimal 10:12
... IMHO
jnthn Yes, I need to spend a good chunk of time on spesh at some point 10:14
But I'm so burried in concurrency stuff it's hard to find the itme. 10:15
*time
dalek kudo/nom: 64b5c2f | samcv++ | src/core/Cool.pm:
Make uniprop return Bool or Str, also make it 15% faster and fix…

a bug in MoarVM where canonical Unicode shortnames return the incorrect property. It is 15% faster now, and adds these two fixes as well.		 10:16
kudo/nom: 71821dd | samcv++ | / (2 files):
Add the script used to generate the uniprop code.

Also make a comment saying the code was generated and where to find the file that generated it. 9043f58 | (Bahtiar `kalkin-` Gadimov)++ | src/core/REPL.pm: Add Historyfile support for Readline
kudo/nom: 1582e93 | lizmat++ | src/core/REPL.pm:
Merge pull request #948 from kalkin/readline-history

Add Historyfile support for Readline
rakudo/nom: 8965145 | samcv++ | tools/build/NQP_REVISION:
rakudo/nom: Bump nqp: Add 4 new sets of matching brackets
rakudo/nom:
rakudo/nom: For use in q [], #`[ and other things such as this.
rakudo/nom:
timotimo to be honest, it'd probably be worth more in the medium term to fix that nativeref problem in our static optimizer 10:18
jnthn We can't.
Methods are late bound. 10:19
We can handle more cases than we do today of course, but the general case needs handling in spesh 10:20
timotimo oh
of course
arnsholt And statically proving anything about $*ERR doesn't sound too plausible to me
timotimo we do have the same problem with operators, though
makes native ints and such not very fun to use
jnthn True. Question is if we really want to maintain such an opt twice :)
Well, we static inline a bunch of operators
And get away with it on those 10:21
timotimo are we going to turn rakudo into javac? ;) 10:22
jnthn What, does very few opts and leaves them to the VM? 10:23
timotimo right 10:24
jnthn It's an interesting question. For very short-lived scripts, it's usually a waste of time.
samcv thanks lizmat
timotimo so only turn on the optimizer for the core setting, then ;)
jnthn Well, we have levels too. "We're pre-compiling this" could push it up a level. 10:25
Though that only really helps if you get to skip analyses too
timotimo aye. we'll likely want to put a few more level checks into the optimizer 10:26
dalek ast: 425011c | lizmat++ | S15-unicode-information/uniprop.t:
Unfudge now passing test, samcv++
 10:36
babydrop say was 25% slower just 'cause it saved into a variable? 0.o 11:06
dalek kudo/nom: f4479d2 | dogbert17++ | CREDITS:
Added myself
 11:09
kudo/nom: e25a708 | (Zoffix Znet)++ | CREDITS:
Merge pull request #946 from dogbert17/update-credits

Added myself
nine So, hands up please! Merge lexical_module_load before the release, i.e. ~ today? 11:11
o/
babydrop +1
jnthn Umm 11:13
Surely immediately *after* a release is more sensible?
lizmat I think we already skipped 2 releases where we could have done that 11:14
if we say now: immediately merge after the next release, I can live with that also 11:15
jnthn Yes, but this time we've got (a) data showing the impact, and (b) it's documented
lizmat but please let's not skip another one :-)
jnthn Yes, I can very easily agree with "merge right after next release"
lizmat 👍 11:16
jnthn Full +1 on that. I'm just a tad more wary on sneaking it in 4-5 days beforehand.
nine I'd be fine with right after the release, too. The "before release" plan certainly provoked responses faster though ;) 11:17
Also now that emmentaler is up and running again, we should use it more extensively. Thinking about jnthn++'s release plan from January. 11:18
jnthn Yes, we really should take advantage of that better to catch ecosystem-breaking changes sooner. 11:19
And perhaps even start doing the automatic release branch thing I proposed.
(Where we use an automated process of spectest + selected module smoke pass = fast-foward branch we relesae from) 11:20
babydrop Is that proposal written down somewhere I could read the details? 11:33
.oO( we need a place for RFCs.... )
 11:35
jnthn babydrop: github.com/rakudo/rakudo/blob/nom/...ersions.md 11:36
babydrop
.oO( we have a place for RFCs.... )
thanks
Well, with that naming scheme I just can see myself doing a checkout for a quick fix and accidentally forgetting to switch branches and ending up pushing to master :/ 11:39
dalek kudo/nom: e1d92e5 | (Zoffix Znet)++ | docs/language_versions.md:
Fix typo
 11:41
babydrop And I guess most PRs will be made off master and not nom and requested to be merged to master and not nom? 11:43
babydrop isn't sure how that's works outs
jnthn Hm
I think github may have some branch-level protection at these days? 11:44
help.github.com/articles/about-bra...trictions/
timotimo we can make an orphaned master branch with only a single commit that says "this isn't the branch you're looking for"
jnthn We could leave nom as the default 11:45
timotimo then pushing will basically always tell you it's not a fast-forward
oh, wait
we're talking about making master only pushable by the automated thing
jnthn Right
babydrop But if I'm a random dude walking through decided to submit a fix, I'll just do it off master 'cause that's what everyone uses and I never heard of this `nom`
jnthn Right
Yeah, we should probably then stick with not having a master.
To avoid such confusion 11:46
And call the release target one something else
babydrop +1
timotimo release-target-one
jnthn At the time the doc was written, people using rakudobrew to obtain a Rakudo build was a more important use-case than it is now; now it seems we discourage that. 11:47
nine But we already have a massively outdated master and there hasn't been a PR for master ever?
jnthn And people who want stability are pushed towards releases, packages, etc. Which is a good thing.
nine: We don't have a master afaik
Anyway, if there are users who want to be sort-of-bleeding-edge but not-so-rare-you-see-it-bleeds then I guess they can choose to track the release branch. 11:49
nine Oh, indeed.
jnthn I figure that will be an increasingly small group however.
timotimo we might have a master that's been created by accident
i think i've done that once?
nine Seems like I have a master in my fork 11:51
jnthn goes to put a fork in his lunch :) 11:57
arnsholt jnthn: Is lunch return of revenge of the son of pulao mountain, or are you done with that now? =) 11:58
kalkin- samcv: ohh i see, double initialization of my read 11:59
why did you guys merged it? should i make another pr fixing this?
babydrop kalkin-: if something's broken, yeah, please submit another PR fixing the issue. 12:00
kalkin- babydrop: ok 12:01
nine kalkin-: we usually operate in a "when in doubt, merge it" mode 12:06
kalkin- i see 12:07
masak we do? exactly how much doubt to we allow? :P 12:11
masak .oO( "I'm really not sure about this PR! let's merge it!" )
nine "Wait, why would rakudo need to open an IRC connection and fork into background? And I have never read this account name. But the commit message explains that the patches just fix some indentation, so let's merge it!" 12:13
babydrop Ummm... no, we don't? 12:27
babydrop doesn't want to start rumours that Perl 6 core devs will merge just any old thing
lucasb github.com/rakudo-acceptanything 12:30
babydrop heh
lizmat m: my $a <== join(",") <== <a b c>; dd $a # this seems wrong ? 12:33
camelia rakudo-moar e1d92e: OUTPUT«Array $a = $["a,b,c"]␤»
lizmat sorta expected to see "a,b,c" there ?
psch m: my $x <== 1; say $x
camelia rakudo-moar e1d92e: OUTPUT«[1]␤»
psch i always assumed feed operators to implictly always leave arrays behind 12:34
potentially lazy i wanna say, but i'm not sure about that
kalkin- Am I right that only rakudo/rakudo uses the nom branch as the current development branch while MoarVM/MoarVM and perl6/nqp use master branch?
lizmat kalkin-: yes 12:35
nine kalkin-: correct
lucasb on nom nom 12:36
kalkin- thanks
pmurias masak: isn't Angular 2 supposed to be faster? I have used only Angular 1 (and had performance problems with it) 12:37
pmurias meant to say that in #perl6 :( 12:38
masak pmurias: you switch channels for the Angular 2 discussion?
ah :)
please do.
Woodi m: my @a = |<| / - \ | / - \ > xx *; say @a[0]; say @a[0]; 12:41
camelia rakudo-moar e1d92e: OUTPUT«|␤|␤»
Woodi @a[0] do not shift Slip ?
babydrop What does that mean? 12:44
Why not use .rotate instead of that? 12:45
Woodi babydrop: it's another way, not circular but infinite! ;)
babydrop ummmmm 12:46
Well, don't let me stop you..
psch that just wastes RAM, and you still need to either $++ or shift
...if we can shift from lazy lists?
Woodi babydrop: and I should stil have that blogpost open, for closer reread :)
psch well, or overwrite AT-POS(0) of course vOv 12:47
that's probably gonna be perfectly fine and usable
babydrop I've no idea what blog post you mean :/
Woodi psch: it is just short example, just put lazy there ?
psch Woodi: sure
Woodi m: my @b = |<| / - \ | / - \ > xx *; say shift @b; say shift @b; # shift shifts ? 12:48
camelia rakudo-moar e1d92e: OUTPUT«|␤/␤»
Woodi but it is Slip, not Array...
psch m: my @b = |<| / - \ | / - \ > xx *; say @a.WHAT 12:49
camelia rakudo-moar e1d92e: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Variable '@a' is not declared␤at <tmp>:1␤------> my @b = |<| / - \ | / - \ > xx *; say ⏏@a.WHAT␤»
psch m: my @b = |<| / - \ | / - \ > xx *; say @b.WHAT
camelia rakudo-moar e1d92e: OUTPUT«(Array)␤»
psch yeah
Woodi is afk; Perl6 is hard. let's deliver some cakes for kids ;) 12:50
jnthn arnsholt: Thankfully, I finished that up by the end of last week. :-) 13:01
kalkin- samcv: i fixed the double initialization of Readline you mentioned github.com/rakudo/rakudo/pull/951/...679435cf6b 13:02
MasterDuke_ hopefully nobody minds if i ask about this again. i'm trying to get -n to codegen 'while ($_ := get()).DEFINITE { $code }' instead of 'for lines() { $code }' 13:05
dalek kudo/nom: 0c6d142 | kalkin++ | src/core/REPL.pm:
REPL fix readline double initialization
kudo/nom: e296a14 | kalkin++ | CREDITS:
Add myself to CREADITS file
kudo/nom: af2ff23 | niner++ | / (2 files):
Merge pull request #951 from kalkin/readline-history

REPL fix readline double initialization
babydrop doesn't mind but doesn't know the answer either :(
MasterDuke_ the AST i get looks reasonable, but depending on different tweaks to it, i get no output, or the error "Cannot call method 'sink' on a null object in block <unit> at -e line 1"
here's a gist with some diffs gist.github.com/MasterDuke17/6e09e...2a0348ef7b
kalkin- ups typo 13:07
too late :)
lizmat thinks it's creative :-)_ 13:14
m: my @a = ^10; say -« @a # works fine 13:18
camelia rakudo-moar af2ff2: OUTPUT«[0 -1 -2 -3 -4 -5 -6 -7 -8 -9]␤»
lizmat m: my @a = ^10; say -<< @a # doesn't parse
camelia rakudo-moar af2ff2: OUTPUT«[0 -1 -2 -3 -4 -5 -6 -7 -8 -9]␤»
lizmat huh?
oops, seen the error of my ways :-)
babydrop m: my @a = 0e0..9e0; say -« @a 13:41
camelia rakudo-moar af2ff2: OUTPUT«[-0 -1 -2 -3 -4 -5 -6 -7 -8 -9]␤»
babydrop m: my @a = 0e0..9e0; dd -« @a
camelia rakudo-moar af2ff2: OUTPUT«[-0e0, -1e0, -2e0, -3e0, -4e0, -5e0, -6e0, -7e0, -8e0, -9e0]␤»
babydrop (good, negative zero works)
A ton of failures in make j-test on nqp.... I guess I'm learning Java today. 13:44
psch babydrop: irclog.perlgeek.de/perl6-dev/2016-...i_13713553 and the next two or so pages will probably be helpful 13:46
babydrop: i'm assuming the contextual.t additions suffer from a similar problem, which is completely-different-codegen-architecture 13:47
babydrop: so, yes, you probably have to learn some Java, but most of it is like in src/vm/jvm/QAST/Compiler.nqp
*likely
travis-ci Rakudo build passed. Bahtiar `kalkin-` Gadimov 'Add Historyfile support for Readline' 13:48
travis-ci.org/kalkin/rakudo/builds/183241465 github.com/kalkin/rakudo/compare/1...43f5897a75
babydrop ummm
I don't undertstand any of it. 13:49
I guess I'm too optimistic about my ability to fix those tests :)
I just didn't want to fudge anything 3rd release in a row... 13:50
psch understandable, and maybe sufficient grounds to park r-j
i mean, considering it's probably mostly new tests that test previously-assumed-correct behavior... 13:51
babydrop So would I release nqp with those failing tests unfudged or should I fudge them? 13:52
where by "fudge" I mean skipping them for both moarvm and jvm
psch i don't have a strong opinion on that, but it seems justifiable to not release nqp-j or r-j is what i wanted to say before 13:53
babydrop OK.
psch like, it's new tests, but we should've been passing them all along 13:54
if people really want an nqp-j that we cannot confidently say fits notably relevant semantics -- like closure cloning and lexical references -- they probably can build it themselves
and in turn take note of the failing tests 13:55
but afaik releases should pass all the fudged tests, and it feels a bit weird to me at least to fudge tests that at time of release are only a few days old but pass on the other backend
especially in nqp
on the other hand that's previously been policy, so you could also fudge and release both
as i said, i don't really have a strong opinion either way, and i'm sadly not capable of fixing anything in the lexrel and closure cloning area quickly 13:56
babydrop I think I'll fudge them just so if someone's packaging this downstream they don't stop and think there's some new breakage 13:58
pmurias suspects he should run make j-test more often to avoid failing tests on nqp-j 13:59
psch pmurias: honestly, i'm not sure. if they're passing on moar and nobody notices bad semantics it's better to have failing tests than no tests 14:00
pmurias: if you're fixing nqp-j in the process... well great, i've troubles getting into some of the deeper parts of the compiler
pmurias wouldn't fudging my having a list of tests that nqp-j fails rather then modifing tests on release and reverting that be saner? 14:01
s/my/by/ 14:02
psch well, sure, we can bring the fudger into nqp tests too
but currently we're just straight running them through -exec nqp ...
pmurias I just meant having a list of whole test files that we fail 14:03
Woodi hmm, Slip is just "kind of List that automatically flattens into an outer container" so what was that kind of list that do not keep used values ? Seq ? 14:09
babydrop Woodi: FWIW, there are more users in #perl6 channel 14:13
Woodi damn, wrong channel... sorry 14:15
pmurias psch: 104-method-cache, 01-qast and serialization/01-basic fail? 14:17
lunch&
babydrop yeah, those look like the ones that fail to me: gist.github.com/zoffixznet/f4e1e1c...8defd3eb38 14:19
psch right
01-qast is the one affected by the closure model differences
babydrop But I'm unsure what you mean by "make a list" of files that fail. To what end? To just keep them in a directory that's not tested on j-test? 14:20
psch ah, 01-qast also has the bit where we don't look for the right boxing type for some reason 14:23
i don't remember offhand what's going on with the other two
dogbert17_ babydrop: I'm getting quite a few fails when running 'make spectest' normally. Is something up?
babydrop dogbert17_: what are the failures? 14:24
dogbert17_ bizarre to say the least, I even nuked my rakuda install and started from scratch. Let me pu up a gist. 14:25
babydrop: gist.github.com/dogbert17/5916d833...06ac49e278 14:26
babydrop Just one file fails? 14:27
dogbert17_ babydrop: sry, was afk, no several failures 14:36
five or six files: t/spec/S17-promise/basic.t, t/spec/S17-supply/syntax.t, t/spec/S29-context/sleep.t, t/spec/S05-substitution/subst.rakudo.moar, t/spec/S16-io/handles-between-threads.rakudo.moar, t/spec/S17-promise/basic.t 14:38
babydrop No idea. Doesn't look like anything I could've broken :} 14:40
jnthn dogbert17_: Still got extra debug checks turned on, perhaps? 14:43
pmurias I'll look into those nqp-j failures 14:48
babydrop pmurias++ 14:49
dalek kudo/nom: e5e81e4 | (Zoffix Znet)++ | src/core/Rakudo/Internals/VMBackedDecoder.pm:
Re-instate comment about why the `with` is in the code

And expand on why it was removed/re-added		 14:51
p: 069d9ea | (Pawel Murias)++ | t/qast/01-qast.t:
[jvm] Add a takeclosure op needed for JVM's old closure handling.
 14:52
pmurias when is nqp-j release planned? 14:59
babydrop This Saturday. 15:01
NeuralAnomaly: status
NeuralAnomaly babydrop, [✘] Next release will be in 4 days and 14 hours. Since last release, there are 48 new still-open tickets (2 unreviewed and 0 blockers) and 28 unreviewed commits. See perl6.fail/release/stats for details
dogbert17_ jnthn: no, I started from scratch 15:02
dogbert17_ hopes he's made some stupid mistake 15:03
MasterDuke_ dogbert17_: pretty sure i've seen some failures in some of those files also 15:05
dogbert17_ MasterDuke to the rescue :)
bizarre: # Failed test 'huge values to sleep() work' 15:06
# at /home/dogbert/repos/rakudo/t/spec/packages/Test/Util.pm (Test::Util) line 76
# got err: "Thread 3 bound to a hash key of an object (BOOTHash) allocated by thread 1\n at <unknown>:1 (./CORE.setting.moarvm:BIND-KEY)\n from SETTING::src/core/hash_slice.pm:12
babydrop I'm not getting any failures in the entire stresstest. In fact the opposite: 15:11
t/spec/S17-procasync/kill.rakudo.moar (Wstat: 0 Tests: 9 Failed: 0)
TODO passed: 9
Files=1204, Tests=130277, 139 wallclock secs (21.52 usr 3.56 sys + 2945.33 cusr 287.87 csys = 3258.28 CPU)
Result: PASS
dalek kudo/nom: aa27d5c | (Zoffix Znet)++ | src/core/Date.pm:
Make all Date constructors check validity of dates

Fixes RT#130313: rt.perl.org/Ticket/Display.html?id=130313		 15:13
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=130313
dalek ast: fecfa65 | (Zoffix Znet)++ | S32-temporal/Date.t:
Test all Date contructors check validity of dates

RT#130313: rt.perl.org/Ticket/Display.html?id=130313 Rakudo fix: github.com/rakudo/rakudo/commit/aa27d5ce94
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=130313
pmurias babydrop: I'll try fixing the failures later today/tommorow, the don't look like they require a closure handling refactor or anything that serious 15:18
babydrop cool
lizmat babydrop: are you sure you didn't break the subclassability of Date ?
ah, read the commit wrong 15:19
dogbert17_ babydrop: it's very strange, for me the following code spits out lots of strange output: await ^30 .map: { start { S/.+/{$/.chars.print}/ given "abc"; } }
m: await ^30 .map: { start { S/.+/{$/.chars.print}/ given "abc"; } }
camelia rakudo-moar e5e81e: OUTPUT«333333333333333333333333333333»
dogbert17_ odd
lizmat babydrop: but I do think you've severely slowed down Date.new(y,m,d) creation :-( 15:20
dogbert17_ babydrop: if it's no to much trouble, are you close to your 32-bit dev machine? 15:21
ilmari s: Range, 'in-range', \(Int, Str)
SourceBaby ilmari, Something's wrong: ␤ERR: Unhandled exception: Missing or wrong version of dependency 'src/Perl6/Grammar.nqp' (from 'gen/moar/main.nqp')␤ at <unknown>:1 (/home/zoffix/services/sourceable/building-perl6/perl6.moarvm:<dependencies+deserialize>)␤
lizmat since that now has to go through the (much slower) named variant :-(
babydrop dogbert17_: it's kinda of "trouble" tho, beucase I don't use it to dev Perl 6. So any time you ask me for something I have to rebuild Perl 6 which takes ages. 15:22
ilmari resorts to ag
dogbert17_ babydrop: that's cool just wanted to check. will try with slightly older releases 15:23
babydrop lizmat: it's slower just due to named args? 15:24
I see it's now 3 times slower :o
lizmat oh, yes
babydrop makes changes
lizmat named parameters are *way* slower than positionals
that's the whole point of not using BUILD in the core setting, but custom SET-SELF methods instead 15:25
babydrop s: Range, 'in-range', \(Int, Str) 15:28
SourceBaby babydrop, Sauce is at github.com/rakudo/rakudo/blob/aa27...ge.pm#L629
babydrop ilmari: you just caught it in the middle of building a new commit
ilmari ah
jnthn m: class C { method m($a, $b) { } }; C.m(1, 2) for ^100000; say now - INIT now 15:30
camelia rakudo-moar e5e81e: OUTPUT«0.21150674␤»
jnthn m: class C { method m($a, $b) { } }; C.m(1, 2) for ^1000000; say now - INIT now
camelia rakudo-moar e5e81e: OUTPUT«2.0623987␤»
jnthn m: class C { method m(:$a!, :$b!) { } }; C.m(:1a, :2b) for ^1000000; say now - INIT now 15:31
camelia rakudo-moar aa27d5: OUTPUT«2.0579070␤»
jnthn lizmat: Really? :)
babydrop m: class C { method m(:$a, :$b) { } }; C.m(:1a, :2b) for ^1000000; say now - INIT now
camelia rakudo-moar aa27d5: OUTPUT«2.22023755␤»
lizmat well, :$a! is essentially the same as a positional
jnthn Uh 15:32
No, it's passed as a named :)
Spesh rewrites it into a positional
But it does that in the optinal case too
lizmat well, as babydrop showed, it's clearly slower
if you don't use !
jnthn m: class C { method m($a?, $b?) { } }; C.m(1, 2) for ^1000000; say now - INIT now
camelia rakudo-moar aa27d5: OUTPUT«1.8460138␤»
jnthn huh, how come that one is a bunch faster... 15:33
m: class C { method m($a?, $b?) { } }; C.m(1, 2) for ^1000000; say now - INIT now
camelia rakudo-moar aa27d5: OUTPUT«2.10225324␤»
jnthn Oh, just noise :)
ilmari
.oO( dumbbench? )
jnthn I suspect that if it boils down to "if you don't use !" then it's not too much to do with nameds and much more to do with optional, anyways.