Zoffix NeuralAnomaly, stats 04:14
NeuralAnomaly Zoffix, [✔] Next release will be in 1 week and 6 days. Since last release, there are 32 new still-open tickets (1 unreviewed and 0 blockers) and 83 unreviewed commits. See perl6.fail/release/stats for details
Zoffix \o/ (added commits tracker)
dalek ast: 4fbf6c0 | usev6++ | S06-signature/definite-return.t:
Skip test for RT #128964 for JVM

also put test in block in order to use '#?DOES 1'		 06:10
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128964
[Tux] This is Rakudo version 2016.08.1-83-gaceb4af built on MoarVM version 2016.08 09:08
csv-ip5xs 10.397
test 16.359
test-t 7.601
csv-parser 16.547
TheLemonMan lizmat, got a minute to triage a bug ? :) 10:21
nine Am I the only one who has a severe dislike for commit messages like "Fix RT #12345"?
TheLemonMan seconded, except for commits to roast heh 10:22
ShimmerFairy nine: I've not been bothered by it myself, but I definitely think it's a lacking message. I'd vastly prefer the kind of message that tacks on "This fixes RT#numbers" at the end :) 10:23
nine Or maybe I should embrace them. As I'm one of the few people who seem to actually like RT and those messages will make any migration much more difficult. 10:25
lizmat TheLemonMan: back 10:28
nine: will be more verbose when fixing RT's in the future :-)
TheLemonMan m: say :{ a => 1 }.Map.keys 10:29
camelia rakudo-moar aceb4a: OUTPUT«(Str|a)␤»
Zoffix nine++ Those messages aren't very useful when going over the commit log to see, for example, if the item is in the changelog, so you have to go into the ticket to see. I was gonna say something but kept quiet, since now I have an app that tracks what commits I reviewed :P 10:30
TheLemonMan lizmat, the typed hash -> Map conversion generates ugly keys (using WHICH ?)
nine At least I can now point at Lee's git talk about why such messages are less than useful :)
lizmat ah, I guess typed hashes are lacking a .Map coercer 10:31
yup
hmm... actually, there's a conceptual issue here 10:32
we don't have typed Maps at the moment
so either .Map will coerce the keys to .Str
or we will have to think about supporting typed Maps
nine lizmat: that does feel odd, doesn't it? But it's the same for List
lizmat nine : no, because List doesn't need to do mapping to .WHICH to simulate object hashes 10:33
I would prefer to not have to support object Maps until we have support for that type of thing in the VM's
TheLemonMan talking of RT...right now it's down 10:48
Zoffix If subject line is enough you can see it on perl6.fail/ 10:51
(coming soon: individual tickets)
dalek kudo/nom: f57fc0c | lizmat++ | src/core/Hash.pm:
Add a .Map coercer for object hashes

Not sure this is the utlimate right fix. But at this point in time, we do not have object Map's. So we cannot coerce an object Hash to an object Map, so we need to coerce to a normal Map. And that means that the objects will become stringified in the Map.
This solution will mostly do the right thing. On the other hand, there doesn't seem to be a reason to do this (from a performance point of view), because it will involve a lot of copying of data.		 10:55
TheLemonMan lizmat, does 'sub x(:$a) { say $a }; x(|:{a => 1})' work now ? :D 10:59
Woodi
.oO(requesting git feature - issues/bugs queue ?) ;)
 11:00
lizmat TheLemonMan: no
but what has that to do with .Map ?
TheLemonMan m: sub x(:$a) { say $a }; x(|:{a => 1}) 11:01
camelia rakudo-moar aceb4a: OUTPUT«Unexpected named parameter 'Str|a' passed␤ in sub x at <tmp> line 1␤ in block <unit> at <tmp> line 1␤␤»
TheLemonMan same issue, I thought those two problems were related :\
lizmat no, this is about the .Slip coercer it seems 11:02
and *that* cannot be fixed that way
this case feels like a DIHWIDT case 11:03
TheLemonMan heh 11:04
nine lizmat: my Proxy idea didn't work out at all in the end, btw. 11:05
lizmat TheLemonMan: actually, it's not the Slip in that context 11:09
we appropriated the prefix:<|> to be slip, but in that case it's actually about flattening a Capture I think 11:10
(the original semantic of prefix |) 11:11
afk for some sightseeing& 11:14
nine Have fun :)
Zoffix NeuralAnomaly, stats 11:26
NeuralAnomaly Zoffix, [✔] Next release will be in 1 week and 6 days. Since last release, there are 32 new still-open tickets (0 unreviewed and 0 blockers) and 83 unreviewed commits. See perl6.fail/release/stats for details
Zoffix How come slurpies cannot have defaults? From a language design perspective, are there any issues? ( thinking again about github.com/rakudo/rakudo/commit/56...4b2082626c ) 11:32
m: sub (*@files = $*IN) { ... }()
camelia rakudo-moar f57fc0: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Cannot put default on slurpy parameter @files␤at <tmp>:1␤------> sub (*@files = $*IN⏏) { ... }()␤ expecting any of:␤ constraint␤»
Zoffix RT is back up 11:44
When adding new features, if you can, please open a ticket on github.com/perl6/doc/issues for it to be documented. Otherwise few people will know of your work. 11:55
nine timotimo: I got rid of all the JSON reading, but cannot measure any difference in runtime of Gtk::Simple's tests :/ 12:08
Zoffix NeuralAnomaly, stats 12:29
NeuralAnomaly Zoffix, [✘] Next release will be in 1 week and 6 days. Since last release, there are 32 new still-open tickets (0 unreviewed and 0 blockers) and 6 unreviewed commits. See perl6.fail/release/stats for details
Zoffix waits for RT to come back up to get the last 6
Hah, RT gods heard my wishes \o/ 12:30
Well, I take back my reservations about not saying anything about non-descript commit messages. With RT down, I can't look up the ticket and have no idea what issues the commit fixes. 12:37
.ask MasterDuke if possible, would you include more descriptive messages in your commits so the gist of what the change introduces can be understood without requiring third party resources, like RT. 12:38
yoleaux2 Zoffix: I'll pass your message to MasterDuke.
dalek kudo/nom: f0df496 | (Zoffix Znet)++ | docs/ChangeLog:
Log all of the changes to date

Include changes made by commits: 933e9a 560170 9f5055 aaf7c3 2153bf 9a1616 a4cc1c 826d43 6ae6ec 7fa2ba aa1ec6 87887d 1a03ef 4efdd9 ede7c6 5dba97 9bafd6 ec9e81 631e2f b48c62 e8d0d0 0a90a5 b50857 157b46 5a7951 575971 a45202 417d97 fbeadb		 12:44
Zoffix NeuralAnomaly, stats
NeuralAnomaly Zoffix, [✔] Next release will be in 1 week and 6 days. Since last release, there are 32 new still-open tickets (0 unreviewed and 0 blockers) and 0 unreviewed commits. See perl6.fail/release/stats for details
Zoffix ReleaseReady™
(•_•)
( •_•)>⌐■-■
(⌐■_■)
nine Finally! Initial run 90s -> 68s, following runs 20s -> 8s. 12:48
Zoffix \o/
nine And ~ 25 minutes to clean up the commits 12:49
MasterDuke Zoffix: sure 12:52
yoleaux2 12:38Z <Zoffix> MasterDuke: if possible, would you include more descriptive messages in your commits so the gist of what the change introduces can be understood without requiring third party resources, like RT.
Zoffix MasterDuke++
Zoffix grabs mst 12:55
Am I doing it right? :) 12:56
(for those who don't listen to global notices: -spb- [Global Notice] I'll be shutting services down in around ten minutes, for (hopefully) around ten minutes. If you'd like to grab ops in your channels just in case, now is the time to do it. Apologies for the inconvenience! )
nine Even better: 62s and 7s respectively 12:57
TheLemonMan nine, I hope the call to 'can' is elided by the optimizer 13:03
nine TheLemonMan: is this really just hope or an educated guess? Of course benchmarks would be even better 13:06
ShimmerFairy How do people feel about nitpicky commits like whitespace cleanup? I ask because HLL::Grammar in NQP has a _lot_ of trailing whitespace, and if I had the commit access and it was OK to do so, I'd fix it up :P 13:08
TheLemonMan nine, I don't quite know what the optimizer does at the moment so it's just a hope
if you can suggest a set of benchmarks I could try I can run them
nine TheLemonMan: unfortunately when you just hope that rakudo's optimizer does something, most of the time it really doesn't :/ 13:09
TheLemonMan well you can still hope the spesh manages to do so :) 13:10
ShimmerFairy nine: hm, now that you got me thinking about it, I realize that having the optimizer all crammed into a single Optimizer.nqp is probably a bad idea. I only looked at it once for some reason, and it felt like a lot of alien code to me. 13:12
nine The static optimizer really could use some declarative way to specify what it should match. 13:14
ShimmerFairy That makes sense and sounds nice. I think ideally there'd be a "subgroup" for the optimizer, e.g. src/opt/ or src/Perl6/Optimizer/ or something 13:15
dalek rakudo/nom: 5fee7a1 | niner++ | src/core/CompUnit/PrecompilationStore/File.pm:
rakudo/nom: Cache CompUnit::PrecompilationUnits loaded from a store
rakudo/nom:
rakudo/nom: When a precompilation unit is accessed multiple times (because multiple
rakudo/nom: modules share a dependency) there's no need to read the file and
nine I hate it when dalek doea that :/ 13:18
timotimo: can you pleas test if GTK::Simple loads faster now? 13:19
timotimo: re-installing may help, too
timotimo nine: i've removed my install/ and will check now 13:24
though ... should i try a before-run, too?
arnsholt is going to push better-O as soon as the spectest comes back clean 13:34
Finally =)
timotimo nine: running into some trouble now ... currently gtk-simple requires cairo to run its tests (clearly a bug) but trying to install cairo makes moar crash :o
arnsholt A rebased version of better-O, truth be told, but still
timotimo ugh, moar crashed during the "Installing Cairo" step and then it thought Cairo was actually already installed 13:35
nine: i wonder what the "Installing GTK::Simple" step is doing such that it takes so long ... 13:37
nine precompiling a lot of modules 13:42
timotimo fair enough 13:44
just use GTK::Simple brings moar's memory usage up to 300 megs, wow.
but 7.7 seconds isn't bad
i don't remember how bad it was before
nine was 20 seconds here before 13:46
timotimo nice :) 13:48
glad to see it get into the upcoming release, too
i can't open the --profile-compile results in my browser >_> 13:49
the second one is "only" 5.7 megs big
ugh, heap snapshots are b0rked 13:51
dalek p: 3105e6a | arnsholt++ | src/ (2 files):
Make HLL::Grammar.O take named arguments.

This fixes the problem of the method manually parsing a string (#145). Since the old parser code allowed a construct like '%additive, :op<add>' to copy 6482f71 | timotimo++ | src/vm/moar/HLL/Backend.nqp: literal_subst doesn't take regexes, oops :)
fixes the heap snapshot profile		 13:52
arnsholt I'm not entirely sure why that keeps happening when I push, but it does ^_^ 13:58
timotimo hehe 14:00
arnsholt Maybe my commit messages are too long =D 14:01
DrForr Hrm, that may *actually* affect my grammar code. I'll have to check that out later... 14:02
timotimo holy crap, loading stage2/NQPHLL.nqp crashes my vim :o 14:03
[Tux] I am going to update my system from openSUSE 13.1 to 13.2 - I hope this will not influence the timings for perl6 14:05
timotimo it could; new gcc and such? :\ 14:06
TheLemonMan [Tux], could you also record the timings with PR#864 applied ? :) 14:09
[Tux] gcc will move from 4.8.1 to 4.8.3 I think. No major changes there 14:10
TheLemonMan, I time from blead. Has it been merged?
TheLemonMan [Tux], not yet, nine was concerned about some potential slowdowns caused by the extra call 14:11
[Tux] url?
TheLemonMan [Tux], patch-diff.githubusercontent.com/r.../864.patch
timotimo arnsholt: it seems like your code broke the build ?!?
Stage parse : Too few positionals passed; expected 2 or 3 arguments but got 1 14:12
at gen/moar/stage2/NQPHLL.nqp:615 (/home/timo/perl6/install/share/nqp/lib/NQPHLL.moarvm:O)
oh
wait
i didn't get the latest nqp, actually
arnsholt Oh, I broke it by not updating NQP_REVISION
timotimo: I can never remember the invocation to get the correct format for NQP_REVISION. You remember (or just want to do it)? 14:15
timotimo git describe --tags > ../rakudo/tools/build/NQP_REVISION
TheLemonMan talking of Actions.nqp...here (github.com/rakudo/rakudo/blob/3c98...007-L5009) we lose the information about the definedness of the type (you can see this come into play in RT#129005) 14:17
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=129005
kudo/nom: 957b527 | arnsholt++ | tools/build/NQP_REVISION:
Bump NQP revision to require version with better-O logic.
 14:22
arnsholt timotimo++ # Remembering the rituals of git 14:23
Also a propos Actions.nqp, for some reason we generate backend-specific Actions.nqp files 14:24
But AFAICT there're no magical comments in the file that require generating backend-specific files
timotimo ah, maybe there was some at some point 14:25
arnsholt Yeah, I assume there was 14:28
Zoffix I heard we don't need panda any more to install Inline::Perl5 for stresstest? What's the incantation to achieve that? 14:48
nine Zoffix: perl6 configure.pl6 --install 14:51
Zoffix :o
nine Zoffix: or perl6 configure.pl6 && make && make test && make install
Zoffix No idea how to do that. Either ./perl6-m doesn't find its stuff or configure.pl6 doesn't find its stuff, depending on which dir I attempt to run it from 14:56
panda it is \o/ 14:57
travis-ci Rakudo build failed. Arne Skjærholt 'Merge branch 'better-O' into nom' 14:58
travis-ci.org/rakudo/rakudo/builds/157449230 github.com/rakudo/rakudo/compare/6...a3de3443d2
Zoffix buggable, and? 14:59
buggable [travis build above] ☠ Did not recognize some failures. Check results manually 15:00
Zoffix 0.o buggable is using nearly 4GB of RAM. Looks like something is leaking (likely regexes) 15:01
arnsholt Zoffix: I forgot to update NQP_REVISION
Zoffix Yeah, it built fine locally.... stresstest: All tests successful. Files=1182, Tests=129093, 227 wallclock secs (21.64 usr 2.76 sys + 2395.70 cusr 166.58 csys = 2586.68 CPU) 15:04
timotimo sadly we can't just implement "send a signal USR2 and moar will give you a heap dump" 15:16
because we have to have a bit of code that turns the raw data into the files we're able to read 15:17
not sure if we want that to go into every program
also, i think installing a signal handler at startup would force every rakudo to get a second thread to handle eventloopy things
Zoffix m: say [90] ^10 15:28
camelia rakudo-moar 957b52: OUTPUT«one([90], 10)␤»
Zoffix m: say [lulz] ^10
camelia rakudo-moar 957b52: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Undeclared routine:␤ lulz used at line 1␤␤»
Zoffix m: say [&say] ^10
camelia rakudo-moar 957b52: OUTPUT«one([sub say (| is raw) { #`(Sub|62640464) ... }], 10)␤»
timotimo hah
Zoffix m: say [+] ^10 15:29
camelia rakudo-moar 957b52: OUTPUT«45␤»
TheLemonMan I wrote a small patch for the nqp optimizer so that '{add,sub} reg, 1' are turned into '{inc,dec} reg' but noticed just now that only moar has such opcodes :\ 15:44
Zoffix m: say $¢ 15:46
camelia rakudo-moar 957b52: OUTPUT«Nil␤»
timotimo TheLemonMan: it's probable that the jit already does that optimization. if it doesn't it'd probably be cheaper ot put it in there 15:48
TheLemonMan timotimo, it's ofc already done by the jit :) 15:49
timotimo on the other hand, inc and dec can cause bugs with unsigned registers
TheLemonMan there's no _u variant for most of the ops 15:50
timotimo yup, we ought to generate truncation ops 15:52
TheLemonMan m: multi sub x(int $x) { ... }; my int8 $y = 3; x($y); # talking of truncation ops.. is this supposed to succeed ? 15:56
camelia rakudo-moar 957b52: OUTPUT«Stub code executed␤ in sub x at <tmp> line 1␤ in block <unit> at <tmp> line 1␤␤Actually thrown at:␤ in block <unit> at <tmp> line 1␤␤»
timotimo i don't see a problem with it 16:01
TheLemonMan I'm a bit surprised by the implicit truncation of the native int 16:02
timotimo huh? 16:03
that's the inverse of truncation, though?
Zoffix m: multi sub x(int8 $x) { ... }; my int $y = 3; x($y);
camelia rakudo-moar 957b52: OUTPUT«Stub code executed␤ in sub x at <tmp> line 1␤ in block <unit> at <tmp> line 1␤␤Actually thrown at:␤ in block <unit> at <tmp> line 1␤␤»
timotimo AFK BBIAB 16:04
TheLemonMan timotimo, int(64) -> int8 is a truncation, you're throwing away some bits 16:05
I expected the multi dispatch to fail due to a type mismatch
Zoffix arnsholt, does your O work need to be logged in the ChangeLog or is it all entirely internal? 16:07
(in the Rakudo's changelog that is) 16:08
dalek kudo/nom: 7107976 | (Zoffix Znet)++ | docs/ChangeLog:
Log all changes to date

Include changes made by commits f57fc0c 5fee7a1 595b04c 9421f25 418894e 601f4f0 Does not include any of the arnsholt++ O-branch work, as I'm unsure if anything needs to be added.		 16:15
Zoffix NeuralAnomaly, stats
NeuralAnomaly Zoffix, [✔] Next release will be in 1 week and 5 days. Since last release, there are 32 new still-open tickets (0 unreviewed and 0 blockers) and 0 unreviewed commits. See perl6.fail/release/stats for details
Zoffix \o/
I love that app :D 16:16
bartolin Zoffix++ NeuralAnomaly++
arnsholt Zoffix: It's mostly internal, being a change in an NQP API, rather than a Rakudo one 16:17
But if people have gotten sufficiently deep into hacking on the Rakudo grammar, they may be impacted 16:18
DrForr waves his pinky in the air :)
timotimo arnsholt: have you made some measurements?
arnsholt So I guess it merits mention
timotimo like, do the .moarvm files get smaller? or the amount of ram used by moar at startup or during stage parse or something? 16:19
arnsholt I didn't actually measure anything
timotimo number of cpu cycles during ... dunno, parsing? where else would it have an impact?
Zoffix arnsholt, would you mind adding it? I don't understand what it's all about :)
arnsholt timotimo: I probably should have, come ot think of it
timotimo *shrug* 16:20
arnsholt jnthn speculated that it might help parse times somewhat, apparently the hashes cropping up where JITted code expected NQPMatch objects were a non-trivial cause of deopts
timotimo i'm just askign because i'm curious
our deopt logging leaves something to be desired, IMO 16:21
we only get a total count per routine, but each routine can easily have ten to thirty different places where deopts could happen
lizmat m: my %l = <<"Pig Latin" English>>.kv.reverse; dd %l # finally found a use case for .vk as a fast .kv.reverse 18:18
camelia rakudo-moar 710797: OUTPUT«Hash %l = {:English(1), "Pig Latin" => 0}␤»
AlexDaniel :O .vk
TheLemonMan RT#128655 appears to be fine now (or has been masked by another bug :) 18:27
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128655
dalek kudo/nom: e8ff93c | (Zoffix Znet)++ | docs/release_guide.pod:
Fix pod format
 18:32
kudo/nom: ea94132 | (Zoffix Znet)++ | docs/release_guide.pod:
Use full URL

GitHub links to S.C.O otherwise.		 18:33
MasterDuke has anybody else had problems when passing the output of one Proc to the input of another? i just created RT #129197 18:38
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=129197
TheLemonMan MasterDuke, your change to infix:<x> (586f7847) causes #128035, the repetitions number is big enough to fill the sign bits of an int64, making it negative 19:16
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128035
MasterDuke ahh, should be islt_I? 19:19
TheLemonMan yeah, just don't force nqp to coerce it to a native 19:23
dalek kudo/nom: f6c997b | arnsholt++ | docs/ChangeLog:
Describe better-O merge in ChangeLog.
 19:28
timotimo arnsholt: i would drop the "rakudo now requires an nqp with" part, honestly; a release (which is where you'd read the changelog, usually) contains a new-enough version of nqp already 19:31
arnsholt True dat, true dat 19:32
"now uses" perhaps?
timotimo i'd maybe word it "the O() operator configuration mumble has been changed from the ground up to be more precompilation-friendly" 19:35
[Tux] update complete, re-running timing … 19:39
TheLemonMan oh ffs, RT is down again! 19:40
dalek kudo/nom: 29e2cab | arnsholt++ | docs/ChangeLog:
Reword ChangeLog entry on better-O merge.
 19:43
timotimo oh
to be honest, i would have dropped the entire rest of that entry :S
MasterDuke TheLemonMan: as it see it the real problem is that nqp::x only takes an int: nqp -e 'nqp::x("a", 9999999999999999999)' errors out with "repeat count (-8446744073709551616) cannot be negative" 19:46
arnsholt timotimo: Or that. Feel free to edit =) 19:47
timotimo nah, it's not that bad :)
arnsholt I'm going to bed now. Parent-life turns out to be exhausting =) 19:48
timotimo oh
i didn't know you parented
congratulations :)
have a good rest
TheLemonMan MasterDuke, yep, but the islt_i prevented it to blow up
arnsholt Couple of months ago now
Thank you, and I will! =)
TheLemonMan maybe you should just cap it to an arbitrary limit
MasterDuke or re-write rakudo's x to not just blindly call nqp::x with its argument 19:49
nqp: nqp::islt_I(9, 0) 19:53
camelia nqp-moarvm: OUTPUT«This representation (P6int) cannot unbox to other types (for type BOOTInt)␤ at <tmp>:1 (<ephemeral file>:<mainline>)␤ from gen/moar/stage2/NQPHLL.nqp:1428 (/home/camelia/rakudo-m-inst-1/share/nqp/lib/NQPHLL.moarvm:eval)␤ from gen/moar/stage2/NQPHLL.nqp:1…»
dalek kudo/nom: e39ab83 | (Zoffix Znet)++ | tools/create-release-announcement.pl:
Remove "this is only some changes" para from template

At least for now... Our changelogs are short enough to be included in entirety, and there are usually just a couple of items that are omited. Including all the items also makes generation of release announcements entirely automatic, without requiring human intervention or extra infrastructure to filter out items of small-interest.		 19:59
[Tux] This is Rakudo version 2016.08.1-100-gf6c997b built on MoarVM version 2016.08-35-g5108035 20:32
csv-ip5xs 9.725
test 15.214
test-t 7.488
csv-parser 17.794
travis-ci Rakudo build errored. Zoffix Znet 'Use full URL 20:33
travis-ci.org/rakudo/rakudo/builds/157487091 github.com/rakudo/rakudo/compare/e...94132d983a
MasterDuke what's a good way to find the max value of an int (not Int)? 21:09
lizmat m: int32.Range.max.say 21:12
camelia rakudo-moar e39ab8: OUTPUT«2147483647␤»
lizmat m: uint32.Range.max.say 21:13
camelia rakudo-moar e39ab8: OUTPUT«4294967295␤»
[Coke] rt down *again* ? fwiw seems fine for me now 21:22
I cannot remember the last time it was down
MasterDuke lizmat: if you backlog about two hours, i'm trying to decide what to do about RT #128035
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128035
MasterDuke [Coke]: TheLemonMan mentioned it about 2 hours ago 21:23
the docs don't mention any limitation on the arguments to x, just that they're coerced to Str and Int 21:24
nor does S03 21:25
cap the size of the argument to the same arbitrary limitation nqp::x has?
or semi-manually do the repetition using nqp::x in a loop? 21:26
lizmat is looking
MasterDuke: I suggest a hard check for 1073741824 is best 21:28
MasterDuke that's pretty easy to do, but why limit to 2**30? 21:30
well, i know we also have a max size on strings 21:31
lizmat MasterDuke: I have no idea... 21:32
MasterDuke which IMHO is too small
lizmat but that's still pretty big
there are days when I don't handle 1Gb big strings of identical characters
MasterDuke but what about the days when you want to! 21:33
it just seems like an out-of-character limitation for Perl 6
we do automatic promotion to bigints 21:34
Unicode terms, operators, etc.
lizmat also: ("a" x 1073741824 / 4) x 4 is about 4x as fast as "a" x 1073741824 21:35
timotimo why would the time it takes to do an x change at all with the number? don't we just create a rope that says "repeat the a that many times"?
lizmat timotimo: I have no idea, I just observed.. 21:36
MasterDuke m: my $a = "a" x 1073741824; my $b = $a x 1073741824; say $b.chars 21:37
camelia rakudo-moar e39ab8: OUTPUT«Memory allocation failed; could not allocate 4294967296 bytes␤»
MasterDuke ugh. on my machine $b.chars is 0
with no warning or anything
but this is a bit of a rehash 21:39
irclog.perlgeek.de/p6dev/2016-04-23#i_12381309
lizmat is still too tired to think clearly and gets an early night 21:43
MasterDuke i'd forgotten about RT #127971, RT #127972, and RT #127973, three of the first tickets i filed 21:45
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=127971
Link: rt.perl.org/rt3//Public/Bug/Displa...?id=127972
Link: rt.perl.org/rt3//Public/Bug/Displa...?id=127973
timotimo huh. 21:48
MasterDuke bench: compare HEAD my $a = ("a" x 1073741824 / 4) x 4 ||| my $b = "a" x 1073741824 21:51
benchable6 MasterDuke, starting to benchmark the 1 given commits
MasterDuke, gist.github.com/257943ecdb9ca857e8...e285fed8aa
MasterDuke bench: releases my $b = "a" x 1073741824 21:53
benchable6 MasterDuke, starting to benchmark the 11 given commits
MasterDuke, benchmarked the given commits, now zooming in on performance differences
MasterDuke, gist.github.com/c6657c8b4d6c3cb716...18d420fc5c
timotimo wow, weird 21:58
it takes negative time 21:59
MasterDuke [Coke]: there are a couple people over in #perl6 having problems with their RT accounts 22:07

Powered by Cro and the Raku® Programming Language.

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

Thank you!