Geth star: 86d29b73d8 | (Zoffix Znet)++ (committed using GitHub Web editor) | tools/star/release-guide.pod
Update release guide for new rakudo.org
 03:40
lizmat Files=1236, Tests=76274, 315 wallclock secs (14.79 usr 5.31 sys + 2166.09 cusr 215.97 csys = 2402.16 CPU) 11:20
tyil with github.com/ugexe/zef/issues/233#is...-373969352 in mind, would it be possible to implement semver? 11:57
versions right now apparently don't support it, and it seems like there's no interest to put it in zef, which would be a shame 11:58
nine tyil: I think there's a bit of a misunderstanding here. I'm quite sure ugexe++ is interested in having semver in zef. I also know that he cares for it to be useful which in his eyes it would only be if rakudo behaved in a similar way. 13:01
tyil his first reply surely doesn't come over that way 13:02
disregarding any benefit of supporting it with the notion it only works if every package uses it 13:03
nine tyil: there's no dismissal in general in his answer. He didn't write "doesn't make sense" but wrote "only makes sense" instead - he gave what he sees as the preconditions that have to be met for semver to actually become useful in the Perl 6 world. 13:05
tyil I'm not well versed in the internals of Perl 6, but would it be possible to implement some syntax in the Perl 6 Version object that allows one to use it in the way I describe 13:06
yes, and that precondition is very incorrect
there's no need to force everyone to semver at all, nor do I even imply that anywhere 13:07
it's a baseless assumption that this is required for it to work
nine I'd call it debatable :) The requirement for every package to use it may be over the top. Where I'm firmly of the same opinion is that zef and rakudo should treat versions as the same. Otherwise you'd only ever be able to solve half of the problem and not gain anything.
tyil which is why I ask if its doable to implement this in perl 6 version objects 13:08
it's the only point he makes which is valid
nine Taking a step back and looking at the larger picture, you can have what you want without any changes to zef or rakudo at all.
tyil but as I said, I'm not versed in the Perl 6 internals, so I don't know if it can e doable 13:09
I've asked about how to do what I want plenty of times before, yet never gotten an answer
it just went by, ignored
if you have the solution, do tell me 13:10
nine There's a difference between ignoring something and simply not having any idea or anything else to contribute. I'm quite sure the latter was usually the case.
What you want is increasing versions in general being treated as improvements but still being able to make a cut in compatibility. Semver's idea is to encode this as convention in the version itself. But in Perl 6 there's another thing that can solve the problem: :api 13:11
tyil this sounds like a workaround, but please go on 13:13
how would I use it to achieve what I want?
nine Foo:api<2> is incompatible with Foo:api<1> independent of a version number. By increasing :api you can explicitly mark the new version as incompatible (instead of relying on convention) and zef and rakudo will honor this by treating the module as fundamentally different to the older api version. No need for treating versions specially.
So Bar depends on Foo:api<1>:ver<1.2.3+>. We will completely ignore any Foo:api<2>, regardless of its higher version because we know it wouldn't work. 13:14
In a sense you could call :api semver's major version.
It's the same concept but written in a more explicit way.
jnthn Wow, I didn't know about that. 13:15
nine++
tyil api is not referenced in the META6.json documentation
I'll add it later if you don't mind
nine tyil: please :) 13:16
tyil and describe how it can be used to enforce a semver-like behaviour
does zef support the api part?
nine tyil: yes
tyil I've been told by the creator that I can *only* rely on the things in docs.perl6.org
since I cannot rely on the actual spec
nine Disclaimer: since :api is not widely known, I'd not be surprised if there were a couple of bugs in various implementations. OTOH it's simply another part of matching a module's long name, like :auth 13:17
tyil bugs can be resolved 13:18
nine If there are bugs, we will simply fix them, yes.
tyil but better docs would be the first step in getting it all right
are there any other things that zef supports but are not in the docs right now? 13:19
nine No idea, sorry :)
MasterDuke m: my @a = ^100000; my @b; @b = @a[$_, $_+1, $_+2] for ^99997; say @b; say now - INIT now 13:24
camelia [99996 99997 99998]
3.0243672
MasterDuke m: my @a = ^100000; my @b; @b = @a[$_], @a[$_+1], @a[$_+2] for ^99997; say @b; say now - INIT now
camelia [99996 99997 99998]
0.8848975
AlexDaniel fwiw check out this doc issue: github.com/perl6/doc/issues/764
it's about META6.json stuff that is not documented yet
MasterDuke jnthn, et al.: any suggestions for optimizing that first case i ran (i.e., array slicing)? 13:25
nine I won't be surprised if in the long term :api actually proves to be more useful to the community than :auth.
AlexDaniel and given that JJ self-assigned that issue, we can resolve it very quickly if someone more knowledgeable just says what should be there and what it does 13:26
MasterDuke nine: is :api meant to be a number one can compare other numbers against? or just a string one compares for equality?
AlexDaniel (hint-hint) :)
nine MasterDuke: I'm not sure. The design documents only talk about "different values": design.perl6.org/S11.html#Tie-breaking 13:31
Oh boy. Bug indeed. I think, I forgot to actually match on :api 13:32
There's all the machinery for supporting it in the META6.json, in the short name lookup files and everything. Just not the actual matching 13:33
tyil nine: would api be a string or an int in the META6.json? 13:34
and is 0 allowed as an api value? 13:37
nine I think....this needs some thinking. E.g. how to upgrade from having no explicitly specified :api to actually using one. Something that can be true for all our ecosystem 13:42
tyil github.com/Tyil/perl6-doc/commit/e...b76b9cc10c 13:43
I wonder if it would make sense to split it up in mandatory and optional fields 13:44
[Tux] Rakudo version 2018.02.1-175-gb75d9b1e1 - MoarVM version 2018.02-171-geee5be412
csv-ip5xs0.807 - 0.815
csv-ip5xs-207.663 - 7.724
csv-parser36.562 - 36.681
csv-test-xs-200.427 - 0.429
test8.990 - 9.273
test-t2.607 - 2.619
test-t --race1.064 - 1.075
test-t-2045.756 - 46.335
test-t-20 --race15.940 - 16.204
 15:14
nine Ok, I've now got a patch for rakudo for properly supporting :api 15:38
There's still the open question of whether :api is a Version or a dumb string/number. I'm leaning towards the latter. You will want an exact match as the whole point of :api is that it signifies incompatibility. 15:39
Geth rakudo/post-release-2018.03: 32c5c83c6e | (Stefan Seifert)++ | 4 files
Support the "api" adverb when loading modules

  :api is semver's major version, i.e. it signifies a backards incompatible
change. So whenever a module author changes the module's API in a backwards incompatible way (i.e. not just an extension), changing the value of :api gives a signal to the user. This way on the receiving end, one can specify
  "give me the newest version of the module, but stay in the range that still
... (5 more lines)		 15:52
rakudo/post-release-2018.03: 16daf02f7f | (Stefan Seifert)++ | 6 files
Make builds reproducible

We replace the compilation timestamp by a hash of the complete source (both the setting and the metamodel), so a recompilation without changes will give the exactly same result. This helps distro packagers as it makes the installation path predictable and removes the requirement to re-build all modules after a re-build of rakudo.
roast/post-release-2018.03: 7d4d402cfa | (Stefan Seifert)++ | S11-repository/curli-install.t
Test support for :api adverb when loading modules
 15:57
japhb I love this post-release-* convention we seem to have settled on. Very useful for keeping people unblocked while allowing a release to stabilize. 16:35
pmurias m: say 6.0221409e+23.Rat 16:41
camelia 602214089999999939117056
pmurias m: say 602214090000000000000000.Num 16:43
camelia 6.0221409e+23
pmurias m: say 602214090000000000000000.Num.Rat
camelia 602214090000000006225920
pmurias it seems that our scientific notation parsing is broken 16:44
am I correct?
Zoffix pmurias: there are a couple of bugs in that area... but broken how? 16:45
pmurias by broken I mean buggy 16:46
a 6.0221408999999994e+23 is read in
Zoffix m: say 6.0221409e+23; say 602214090000000000000000.Num
camelia 6.0221409e+23
6.0221409e+23
Geth rakudo/post-release-2018.03: 7d978fb266 | (Elizabeth Mattijsen)++ | src/core/Array.pm6
Add .append(IterationBuffer) methods to ReificationTargets

So that we have a better change of .append working in iterators.		 16:47
Zoffix looks fine to me
Buggy how?
pmurias it seems to be it's also stringified incorrectly
Zoffix Yeah, it's missing one char of precision. 16:48
RT#127184 16:49
synopsebot RT#127184 [open]: rt.perl.org/Ticket/Display.html?id=127184 [BUG] One digit short to correctly stringify a double
Zoffix I think there was another ticket too
pmurias Zoffix: we are both missing a char of precision and parsing numbers wrong 16:50
so the bugs mask themselves
Zoffix Ah 16:51
pmurias and the reading numbers in wrong bug causes a test fail on the js backend which doesn't stringify numbers incorrectly
./perl6-m -e 'say 6.0221409 * 1e+23'
Zoffix m: say 602214090000000000000000.Num.FatRat; say 6.0221409e+23.FatRat
camelia 602214090000000006225920
602214089999999939117056
pmurias Zoffix: ^^ that's what the grammer does 16:52
but on say node.js that doesn't give you 6.0221409e+23
Zoffix I see Num.Rat does a bunch of calculations: github.com/rakudo/rakudo/blob/mast...m6#L46-L91
It probably don't need to do 'em for FatRat and maybe even for Rat either, cause the biggest Int you can get is like 15 chars long, innit? So just pass that to constructors without doing any math. 16:53
m: say 1.234567890123456789e0
camelia 1.23456789012346
Zoffix m: dd chars '1.23456789012346' 16:54
camelia 16
Zoffix m: dd (9x16).Int.log: 2
camelia 5===SORRY!5=== Error while compiling <tmp>
Confused
at <tmp>:1
------> 3dd (97⏏5x16).Int.log: 2
expecting any of:
whitespace
Zoffix m: dd (9 x 16).Int.log: 2 16:55
camelia 53.1508495181978e0
Zoffix m: say 12345678901234567/10_000_000_000_000_000
camelia 1.2345678901234567
Zoffix m: say 10_000_000_000_000_000.log: 2 16:56
camelia 53.1508495181978
Zoffix So the largest num can be held inside a Rat pricely. Cause stuff beyond 16+ chars is noise, innit?
pmurias Zoffix: isn't it 17 according to wikipedia (I'm too tired atm to pass my own judgment ;) 16:59
Zoffix m: dd (9 x 17).Int.log: 2
camelia 56.4727776130852e0
Zoffix Still fits :)
pmurias Zoffix: there are some super small nums you can't keep inside a Rat precisly 17:03
Zoffix Looking at en.wikipedia.org/wiki/Floating-point_arithmetic double precision got 60bit mantissa, so the idea is we shove the mantissa into the numerator, and shove a 100000000000 (with enough zeros to divide mantissa to have 1 sigit before the dot), and the rest of the exponent zeros get simply reduced and we end up basically keeping all of the precision 17:04
all of the avilable precision that is
pmurias: the "subnormal" stuff? Do we do that for nums?
lizmat hmm... I would like to import 3e8ee99116e61773f674b into the post-release-2018-03 branch 17:05
pmurias Zoffix: how do you want to represent something smaller than 1/2**64 in a Rat?
lizmat what would be the git magic for that ?
git cherry-pick ? 17:06
Zoffix lizmat: maybe `git cherry-pick 3e8ee99116e61773f674b` while on the post-release-2018.03 branch and then revert it while on master branch?
m: say (1/2**64).Num
camelia 5.42101086242752e-20
lizmat Zoffix: ok, will do that
Zoffix pmurias: it'd be 542101086242752/100000000000000 17:07
pmurias: I'm saying we can keep full precision available in any Num
And 1/2**64 does lose precision when converted to a Num
Geth rakudo: 2a0b90f83c | (Elizabeth Mattijsen)++ | src/core/IterationBuffer.pm6
Revert "Give IterationBuffer an .append for IterationBuffers"

This reverts commit 3e8ee99116e61773f674bf7b5949c321c077ad3b.
Doing this in the post-release.2018-03 branch		 17:09
rakudo/post-release-2018.03: 228495927c | (Elizabeth Mattijsen)++ | src/core/IterationBuffer.pm6
Give IterationBuffer an .append for IterationBuffers

This should come in handy when re-assembling HyperWorkBatches in the
  .push-all case, and probably some other cases.
Zoffix Well, 542101086242752X/1000000000000000; once we fix the one-missing-digit bug in Num.Str
m: say Rat.new(542101086242752,100000000000000).nude 17:10
camelia (8470329472543 1562500000000)
Zoffix And we let Rat.new reduce the numerator/denominator instead of doing that in Num.Rat
pmurias Zoffix: isn't 542101086242752/100000000000000 like ~ 5
Zoffix m: say 542101086242752/100000000000000 =~= 5.42101086242752e-20 17:11
camelia False
Zoffix m: say 542101086242752/100000000000000
camelia 5.42101086242752
Zoffix Oh, shit, right
:D
ZofBot: math is hard. Let's go shopping!
ZofBot Zoffix, And opened my eyes but couldn’t see anything at first because there were too many people
Zoffix Though the idea still stands for Num.FatRat, I think :) 17:14
There's even a ticket for that RT#128828
synopsebot RT#128828 [new]: rt.perl.org/Ticket/Display.html?id=128828 [BUG] Num.FatRat coercion is inexact
lizmat grr I need to cherry-pick lots more :- 17:15
(
Zoffix lizmat: I think AlexDaniel ran full toaster on latest master and all was green 17:16
AlexDaniel yes
Zoffix on (current HEAD)~1; before that last revert
lizmat yeah, but what I want to add potentially could break toaster even if spectest is green 17:17
the area I'm working in is really undertested :-
(
AlexDaniel it could've been left in there I think 17:18
but ok
lizmat any idea of an ETA for the release ?
AlexDaniel samcv: ↑ 17:19
Zoffix m: say 5.42101086242752e+20.Rat.nude 17:24
camelia (542101086242752036864 1)
Zoffix m: say 5.42101086242752e-20.Rat(1e-21).nude
camelia (1 18446744073709559808)
Zoffix
.oO( int64 denominator Rats, where negative denominator signifies numerator/denominator should be reversed )
FlipRat :"D 17:25
.seen TimToady
yoleaux I saw TimToady 5 Mar 2018 19:21Z in #perl6-dev: <TimToady> well, that's what the Str part of RatStr was supposed to be
Zoffix is still waiting for TimToady to feedback on MidRat stuff github.com/rakudo/rakudo/blob/mast...-rationals 17:26
samcv lizmat: working on the moarvm release now 19:44
lizmat samcv++ 19:54
AlexDaniel yay 20:06
please ping me when it's committed 20:07
tyil nine: I'd go for a simple number (on the "api" field type) 20:12
timotimo i'd say sometimes an actual name is warranted 20:13
for example, what if you have some functionality that's famously implemented in a python library and a ruby library and your module wants to be exactly what the users of each library are used to; so you'd perhaps have :api<python> and :api<ruby> or names of the modules in question ro what 20:14
tyil "So whenever a module author changes the module's API in a backwards 20:16
incompatible way (i.e. not just an extension), changing the value of :api
gives a signal to the use
"
as far as I can tell the intention is not to specify anything about how it is implementing an interface 20:17
lizmat fwiw, I see the API as an identifier, not a version 20:18
:api actually
tyil also, the only reason I want it so I can reasanbly use semver standards
not to specify I'm going to get a vastly different interface 20:19
that's what module names are already good at
lizmat so if you just request something with an api string, then the highest version available with that :api should be selected / loaded
AlexDaniel samcv: really don't want to interrupt you from the release stuff, but can't help myself not to ask this question 20:21
m: say (0x7FFFFFFF).chr.ord.base(16)'
camelia 5===SORRY!5=== Error while compiling <tmp>
Two terms in a row
at <tmp>:1
------> 3say (0x7FFFFFFF).chr.ord.base(16)7⏏5'
expecting any of:
infix
infix stopper
postfix
statement end
…
AlexDaniel m: say (0x7FFFFFFF).chr.ord.base(16)
camelia 7FFFFFFF
AlexDaniel how come this is valid?
yeah you can't use that in anything that takes utf-8, but why does .chr allow it in the first place?
m: say (0x7FFFFFFF+1).chr.ord.base(16) 20:22
camelia chr codepoint 2147483648 (0x80000000) is too large
in block <unit> at <tmp> line 1
samcv AlexDaniel: because it's not in utf8 20:28
only when it gets converted to utf8 is it invalid
AlexDaniel but unicode only has characters up to 0x10FFFF, right? Isn't the encoding irrelevant? 20:29
pmurias what's a difference between :api and an extra name part? 20:30
AlexDaniel unicodable6: U+7FFFFFFF 20:33
unicodable6 AlexDaniel, U+7FFFFFFF <unassigned> [] (unencodable character)
AlexDaniel unidump: U+7FFFFFFF
unicodable6 AlexDaniel, gist.github.com/3912777bc21e882b52...21fbb41745
samcv AlexDaniel: well so far 20:34
it may be a while but it could happen eventually
AlexDaniel m: say (0x7FFFFFFF).chr.unival
camelia 0
AlexDaniel that looks wrong
samcv m: say (0.chr.unival) 20:35
camelia NaN
AlexDaniel nvm I'll submit a ticket
samcv AlexDaniel: yes it does. please file a bug
AlexDaniel j: say (0.chr.unival)
camelia unival NYI on jvm backend
in block <unit> at <tmp> line 1
 20:36
samcv AlexDaniel: but 0x10FFFF is just the limit due to limitations in utf16 and afaik characters above 0x10FFFF are just unassigned and unlikely to be assigned for the forseeable future. until they run out I suspect 20:38
AlexDaniel R#1625 20:39
synopsebot R#1625 [open]: github.com/rakudo/rakudo/issues/1625 [Moar] .unival of characters beyond 0x10FFFF is 0 but should be NaN
AlexDaniel samcv: yea but then we also have implementation-specific limit of 2147483647
why not bring it down to 0x10FFFF and make the implementation consistent with unicode itself 20:40
samcv 2147483647 is much higher than 0x10FFFF
AlexDaniel say 2147483647 / 0x10FFFF
m: say 2147483647 / 0x10FFFF
camelia 1927.53114097
samcv we're pretty safe :P
AlexDaniel EVALABLE!! I'LL KILL YOU 20:41
evalable6: leave your position during working hours again and you're fired
evalable6 (exit code 1) 04===SORRY!04=== Error while compiling /tmp/Irk_IvQjOW
Undecla…
AlexDaniel, Full output: gist.github.com/7e1a0c361e14fdb9cb...f1f9b518c7
AlexDaniel errrr 22:26
c: 2018.02.1,HEAD :10<1.a>
committable6 AlexDaniel, gist.github.com/dd34783a3879c371d8...a326e85c06
AlexDaniel this hang is a regression of this release
bisect: old=2018.02.1 :10<1.a>
bisectable6 AlexDaniel, Bisecting by exit signal (old=2018.02.1 new=2a0b90f). Old exit signal: 0 (None) 22:27
AlexDaniel, bisect log: gist.github.com/04773eb61e74818252...f643d0b82c
AlexDaniel, (2018-02-28) github.com/rakudo/rakudo/commit/78...4814bec925
AlexDaniel lizmat: ↑ 22:28
bisect: 7835652d54^,7835652d54 :10<1.a>
bisectable6 AlexDaniel, On both starting points (old=2015.12 new=2a0b90f) the exit code is 1 and the output is identical as well
AlexDaniel, Output on both points: «04===SORRY!04=== Error while compiling /tmp/pzyuVKaFzj␤Confused␤at /tmp/pzyuVKaFzj:1␤------> 03783565208⏏04d54^,7835652d54 :10<1.a>␤ expecting any of:␤ whitespace␤»
AlexDaniel oops
c: 7835652d54^,7835652d54 :10<1.a>
committable6 AlexDaniel, gist.github.com/e7585f093916069f22...67fe205a20 22:29
lizmat so, which commit is causing the problem?
AlexDaniel lizmat: (2018-02-28) github.com/rakudo/rakudo/commit/78...4814bec925
lizmat that can only mean that it goes awol in the error reproting 22:30
AlexDaniel to anyone who fixes this, please commit to master
lizmat is looking at it 22:31
AlexDaniel there's also Zoffix self-assigned to that issue 22:32
lizmat well, if I don't find it in the next 20 minutes or so, it'll have to be someone else 22:33
because I need to get up early tomorrow and may not be in a position to look at it before I need to be away for the most of the day
AlexDaniel fwiw I'm going to bed relatively soon also 22:34
Zoffix Yeah, I marked as assigned, but was planning to stash it until later in the week.
Zoffix starts looking at it too 22:35
ah hehe 22:37
lizmat Zoffix: ?? 22:39
Zoffix Well, I'm guessing it's infinilooping somewhere in UNBASE, cause there's a condition that shoves it through ":$base<$ch>" syntax again 22:40
Zoffix sticks debug prints in
nope :) 22:42
lizmat does it actually get to UNBASE ? 22:43
Zoffix no, I thought it did, but it was just a guess.
lizmat: if you wanna go to bed, then just go, I'll track it down adn fix
lizmat ok, my reasoning so far: 22:46
before, it was caught at compile time by the <.malformed: 'radix number'> at Grammar:3696 (I think) 22:47
now I just verified it doesn't even get there 22:48
Zoffix s: X::Str::Numeric, 'message', \() 22:49
SourceBaby Zoffix, Sauce is at github.com/rakudo/rakudo/blob/2a0b....pm6#L2033
Zoffix dreams of the day when re-compile time won't be nearly 2m :) 22:51
got it 22:54
c: 2018.01 say [.file, .line] with "1.g".^lookup("substr").cando(\("", 2e0)).head 22:55
committable6 Zoffix, ¦2018.01: «[SETTING::src/core/Cool.pm 75]␤»
Zoffix c: HEAD say [.file, .line] with "1.g".^lookup("substr").cando(\("", 2e0)).head
committable6 Zoffix, ¦HEAD(2a0b90f): «[SETTING::src/core/Cool.pm6 155]␤»
Zoffix reaaly
yeah
There only Int candidates in Str.pm, and it's infinitlooping with that Num between Cool and Str 22:56
lizmat ok
lemme look at that 22:57
testing a fix 22:58
running spectest now 23:00
Zoffix huh 23:04
m: :3<111.a11>
camelia MoarVM panic: Memory allocation failed; could not allocate 90112 bytes
Zoffix This is already in the spectest :/
in S02-literals/radix.t
lizmat how come I haven't seen this fail so far then? or was it just added ? 23:05
Zoffix No, seems old. Doesn't fail in `throws-like` seems 23:06
m: use Test; throws-like ':3<111.a11>', X::Str::Numeric
camelia 1..2
ok 1 - ':3<111.a11>' died
ok 2 - right exception type (X::Str::Numeric)
ok 1 - did we throws-like X::Str::Numeric?
lizmat perhaps the EVAL makes a difference ?
Zoffix m: try ':3<111.a11>'.EVAL; say $!.^name 23:07
camelia X::Str::Numeric+{X::Comp}
Zoffix yeah. weird
Geth rakudo: 15ccfd3331 | (Elizabeth Mattijsen)++ | src/core/Str.pm6
Add missing Str.substr(Any x) candidate

Fixes #1624, tests needed.
synopsebot RAKUDO#1624 [open]: github.com/rakudo/rakudo/issues/1624 [regression][⚠ blocker ⚠] fp numbers with outside-range chars hang
Zoffix m: try "\n:3<111.a11>\n".EVAL; say $!.^name
camelia X::Str::Numeric+{X::Comp}
lizmat calls it a day 23:08
good night, #perl6-dev!
Zoffix lizmat++ night \o
AlexDaniel btw, is substr-rw free of this issue? 23:09
(whatever it is, haven't looked at the commits yet) 23:10
Zoffix m: say ($ = "x").substr-rw: 1e0
camelia
Zoffix yeah, free
AlexDaniel ok. Well, that was quick. Zoffix++ lizmat++ 23:11
Geth roast: 8bfcb7c64a | (Zoffix Znet)++ | S02-literals/radix.t
Cover hang in rad numbers/substr with Num

Closes github.com/rakudo/rakudo/issues/1624 R#1624 Rakudo fix: github.com/rakudo/rakudo/commit/15ccfd3331		 23:20
synopsebot R#1624 [open]: github.com/rakudo/rakudo/issues/1624 [regression] fp numbers with outside-range chars hang
Zoffix ZofBot: teamwork o/\o
ZofBot Zoffix, ” And when Mother came into the spare room before went to sleep said, “ have to go to Swindon to take my level
MasterDuke m: use nqp; class :: { has $!a; has $!b; method new(\a, \b) { my \rt = nqp::create(self); nqp::bindattr(rt, self, q|$!a|, a); nqp::bindattr(rt, self, q|$!b|, b); rt } }.new($_, $_) for ^1_000_000; say now - INIT now 23:38
camelia 0.6247775
MasterDuke m: class :: { has $!a; has $!b }.new(:a($_), :b($_)) for ^1_000_000; say now - INIT now 23:39
camelia 1.100576
MasterDuke i wouldn't have guessed the first ^^^ would be that much faster
timotimo MasterDuke: going through BUILDALL and BUILD perhaps does that? 23:44
that's why we have so many SET_SELFs in core
MasterDuke yeah, BUILDALL and Mu's new
timotimo though we try to compile custom BUILDALL methods 23:45

Powered by Cro and the Raku® Programming Language.

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

Thank you!