Zoffix m: sub (int $i) { $i() } 04:13
camelia rakudo-moar 1f29cb: OUTPUT«===SORRY!===␤callee expression must be an object␤»
Zoffix still no 'New Ticket' button on RT? :/ 04:14
huggable, rakudobug
huggable Zoffix, [email@hidden.address] or use perl6 query on rt.perl.org ; see github.com/rakudo/rakudo/#reporting-bugs
Zoffix
.oO( have you people heard of reCAPTCHA.... )
 04:16
Ticket for the above rt.perl.org/Ticket/Display.html?id=129772 04:19
m: use nqp; sub foo (Int:D $offset) { dd nqp::islt_i(nqp::unbox_i($offset),0) }(-1) 05:07
camelia rakudo-moar 1f29cb: OUTPUT«1␤»
Zoffix m: use nqp; sub foo (Int:D $offset) { dd nqp::islt_i($offset,0) }(-1)
camelia rakudo-moar 1f29cb: OUTPUT«1␤»
Zoffix What is the purpose of nqp::unbox_i() in that code? 05:08
e.g. here: github.com/rakudo/rakudo/blob/nom/...y.pm#L1058 05:09
geekosaur m: use nqp; my $x = -1; sub foo (Int:D $offset) { dd nqp::islt_i($offset,0) }($x) 05:12
camelia rakudo-moar 1f29cb: OUTPUT«1␤»
Zoffix m: [].splice: 0, [] # weeeeeeeeeeee 05:42
camelia rakudo-moar 1f29cb: OUTPUT«Memory allocation failed; could not allocate 80320 bytes␤» 05:43
Zoffix s: [], 'splice', \(0, []) 05:44
SourceBaby Zoffix, Sauce is at github.com/rakudo/rakudo/blob/1f29...y.pm#L1142
Zoffix
.oO( well, there's yer problem )
dalek kudo/nom: 28bf874 | (Zoffix Znet)++ | / (2 files):
Fix hang on incorrect .splice arguments

Fixes RT#129773: rt.perl.org/Ticket/Display.html?id=129773		 06:17
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=129773
dalek ast: 3253db3 | (Zoffix Znet)++ | S32-array/splice.t:
Test .splice(offset, array) throws

RT#129773: rt.perl.org/Ticket/Display.html?id=129773		 06:20
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=129773
dalek kudo/nom: 4ffeeab | bartolin++ | src/vm/jvm/runtime/org/perl6/rakudo/RakOps.java:
Mention typename in X::Assignment::RO on JVM
 06:21
kudo/nom: 3299111 | (Zoffix Znet)++ | src/vm/jvm/runtime/org/perl6/rakudo/RakOps.java:
Merge pull request #892 from usev6/patch-3

Mention typename in X::Assignment::RO on JVM
ast: f56934b | usev6++ | S (2 files):
Unfudge passing tests for JVM
 07:11
Zoffix aw, crap 07:21
travis-ci Rakudo build errored. Zoffix Znet 'Fix hang on incorrect .splice arguments
travis-ci.org/rakudo/rakudo/builds/164218938 github.com/rakudo/rakudo/compare/1...bf87439e4c
Zoffix [].splice: 0e0, 0 also hangs
'cause there's no type constraint on $offset 07:22
Is there a better way than adding 9 candidates for this case?
m: multi foo (Int:D $x, $y, @a) {say "got it"}; multi foo ($x, $y, *@a) { &foo.cando(\($x, $y, @a))[0].signature eqv &?BLOCK.signature and die; foo $x, $y, @a }(0e0, 0, 1, 2, 3) 07:29
camelia rakudo-moar 329911: OUTPUT«Died␤ in sub foo at <tmp> line 1␤ in block <unit> at <tmp> line 1␤␤»
Zoffix benches
:/ or not... seems I hit a module loading hang now :\ 07:39
yup \o/ 07:44
dalek p: 726735e | peschwa++ | src/vm/jvm/runtime/org/perl6/nqp/sixmodel/reprs/CStruct.java:
Adjust error message for zero size CStruct, jnthn++.
 07:55
travis-ci Rakudo build failed. Zoffix Znet 'Merge pull request #892 from usev6/patch-3 07:59
travis-ci.org/rakudo/rakudo/builds/164219328 github.com/rakudo/rakudo/compare/2...991113917a
Zoffix this is just weird.... 08:16
bug happens just when a particular checkout is present in current directory :) 08:17
psch which bug? 08:22
the multi one?
Zoffix Nah, the module loading one :) 08:23
Zoffix is debugging it atm
psch oh
pmurias should the nqp test suit use and &is sub instead of using ok(... eq 'expected') all over the place 08:56
?
dalek p: 815ecaf | (Pawel Murias)++ | src/vm/js/nqp-runtime/co (2 files):
[js] Fix nqp::iscont on typeobjects.
 08:57
p: 503b29a | (Pawel Murias)++ | t/nqp/067-container.t:
Test nqp::iscont on typeobjects.
p: 2934378 | (Pawel Murias)++ | src/vm/js/Compiler.nqp:
[js] Remove dead commented out code.
p: 0da41f3 | (Pawel Murias)++ | t/qast/01-qast.t:
Add a test for mixing a QAST::Var param with setup with a contvar.
p: 66e5843 | (Pawel Murias)++ | / (2 files):
[js] Setup contvars and statics before we are running the setup code inside the params.

Bump MOAR_REVISION for CStruct fix
Zoffix Hm. I see what the issue is. CompUnit::Repository::FileSystem basically recurses and finds all .pm6? files, slurps all of them, concatenates all of them, and then sha1s the result. 09:02
So if you happen to run stuff in a dir with lots of .pm6 files, you're screwed.
Wouldn't using an absolute path as repo ID work? 09:08
(well, sha version of it) 09:09
.tell nine maybe you'll have a better idea of how this can be fixed: rt.perl.org/Ticket/Display.html?id=129776 09:11
yoleaux2 Zoffix: I'll pass your message to nine.
psch oh, that's a regex, not a question 09:22
pm6? i mean
arnsholt I'm not sure that one's easily fixed 09:26
It needs to generate what is essentially a GUID for a tree, but in such a way that the same tree will always get the same GUID 09:28
That'll have to depend on the file contents in some way 09:29
Best we can do is probably faster SHA computations 09:32
Might be faster to SHA individual files, and XOR those together 09:33
[Tux] This is Rakudo version 2016.09-98-g3299111 built on MoarVM version 2016.09-3-g9b39aa5 09:40
csv-ip5xs 3.392
test 16.304
test-t 7.220
csv-parser 17.856
arnsholt, timotimo, csv-ip5xs is perl6 + Inline::Perl5 + Text::CSV_XS, test is the first simple draft of what became test-t, no optimisations, pure perl6, test-t is the full-fledged implementation of Text::CSV_XS in pure perl6 with all options enabled and language specific optimizations applied 09:42
csv-parser is the perl6 CSV::Parser module
arnsholt Cool. Thanks! 09:43
kudo/nom: c4a8855 | peschwa++ | tools/build/NQP_REVISION:
Bump NQP_REVISION for CStruct fix
kudo/nom: 46e0ede | peschwa++ | t/04-nativecall/06-struct.t:
Adjust error message in zero size CStruct test
travis-ci Rakudo build passed. Pepe Schwarz 'Adjust error message in zero size CStruct test' 10:45
travis-ci.org/rakudo/rakudo/builds/164237981 github.com/rakudo/rakudo/compare/3...e0edebc593
Zoffix arnsholt, but why does it need file tree contents? 12:08
As in, why is the absolute path alone not enough
lizmat Files=1144, Tests=53182, 228 wallclock secs (12.88 usr 3.61 sys + 1400.44 cusr 131.94 csys = 1548.87 CPU) 12:10
timotimo that seems like a low number
lizmat timotimo: in what sense? 12:11
timotimo 228 wallclock seconds?
is that lower than usual?
lizmat not for me...
timotimo OK
lizmat it's been around 228 the past week 12:12
timotimo OK!
lizmat irclog.perlgeek.de/perl6-dev/search...ck+secs%22
Zoffix The mu repo has 1022 module files and perl6 chokes on that. By comparison, Perl 5's Date::Manip distro has 862 module files. So our Filesystem *repository* would choke on a single distro like that in it. 12:15
lizmat Zoffix: yup, ran into that myself some weeks ago :-( 12:17
feels to me we should actually be ok with shaing the last modified / file size of a dir 12:19
Zoffix m: gist.github.com/zoffixznet/f2e9744...56c903972e 12:43
camelia rakudo-moar 46e0ed: OUTPUT«===SORRY!===␤Failed to create directory '/home/zoffix/CPANPRC/rakudo/bug/.precomp/F0F0ACA3B2DE672560EA87C94EF371AC81E75BC9.1475316625.64084' with mode '0o777': Failed to mkdir: 13␤»
Zoffix heh 12:44
m: gist.github.com/zoffixznet/f72faa3...ef6d194e8f
camelia rakudo-moar 46e0ed: OUTPUT«(timeout)starting␤*** Error in `/home/camelia/rakudo-m-inst-2/bin/moar': malloc(): smallbin double linked list corrupted: 0x0000000005aad5c0 ***␤» 12:45
Zoffix \o/
I don't get the timeout, just the consistent segfault locally
"Your session has expired. Please log in again"... And yes, please, do delete the email I spent 5 minutes typing and wanted to send. 12:52
ugh
m: my ($x, $y, @a); say \(Array:D: $x, $y, @a) 12:59
camelia rakudo-moar 46e0ed: OUTPUT«Cannot resolve caller say(Array:D: Capture); none of these signatures match:␤ (Mu $: *%_)␤ in block <unit> at <tmp> line 1␤␤»
Zoffix m: my ($x, $y, @a); say \(Array:D $: $x, $y, @a)
camelia rakudo-moar 46e0ed: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Two terms in a row␤at <tmp>:1␤------> my ($x, $y, @a); say \(Array:D⏏ $: $x, $y, @a)␤ expecting any of:␤ infix␤ infix stopper␤ statement end␤ statement m…»
Zoffix Apparently today is Annoy Zoffix With Bugs day :/
oh maybe not 13:00
m: my ($x, $y, @a); say \(Array:D, $x, $y, @a)
camelia rakudo-moar 46e0ed: OUTPUT«\(Array:D, Any, Any, [])␤»
Zoffix \o/
m: gist.github.com/zoffixznet/c31428d...8a2bb25969 13:05
camelia rakudo-moar 46e0ed: OUTPUT«starting␤Before: 0.61891633␤ After: 5.1659245␤ Diff: -88.02%␤»
Zoffix This kinda looks daft, gist.github.com/zoffixznet/da2703d...a11d140a32 13:12
Alternate solutions: checking lookup signature 88% relative difference (slower); checking istype on all args 30% rel.dif (slower). 13:13
m: [].splice: 0e0, 0 # fix for this hang
camelia rakudo-moar 46e0ed: OUTPUT«Memory allocation failed; could not allocate 40816 bytes␤»
Zoffix Should I commit that?
and using where {} clauses is also ridiculously slow in the 98% rel dif 13:14
dalek kudo/js: 936b5a5 | (Pawel Murias)++ | src/vm/js/perl6-runtime/runtime.js:
[js] Update due to nqp changes.
 14:14
kudo/js: 424d190 | (Pawel Murias)++ | src/vm/js/ (2 files):
[js] Implement nqp::p6var.
p: 76815d2 | (Pawel Murias)++ | t/qast/01-qast.t:
Update skip count in test.
 14:15
p: 34b2df3 | (Pawel Murias)++ | src/core/testing.nqp:
Add &is to the setting for better failure diagnostics.
p: 1ca74f3 | (Pawel Murias)++ | src/vm/js/ (4 files):
[js] Evaluate arguments to a method/sub in proper order, requires refactoring how we handle the arguments.
p: 556fc2e | (Pawel Murias)++ | t/qast/01-qast.t:
Test that named and positional (flattened or otherwise) arguments to a methodcall are evaluated in the proper order.
AlexDaniel jnthn: here is the thing we were talking about yesterday: await (for ^7 { start ‘/any/file/really’.IO ~~ :e }) 15:02
hmm perhaps camelia can also do it
m: await (for ^7 { start ‘/any/file/really’.IO ~~ :e })
camelia ( no output )
AlexDaniel m: await (for ^7 { start ‘/any/file/really’.IO ~~ :e }) 15:03
camelia ( no output )
AlexDaniel m: await (for ^7 { start ‘/any/file/really’.IO ~~ :e })
camelia ( no output )
AlexDaniel m: await (for ^7 { start ‘/any/file/really’.IO ~~ :e })
camelia ( no output )
AlexDaniel m: await (for ^7 { start ‘/any/file/really’.IO ~~ :e })
camelia ( no output )
AlexDaniel m: await (for ^7 { start ‘/any/file/really’.IO ~~ :e })
camelia ( no output )
AlexDaniel maybe not
m: for ^100 {await (for ^7 { start ‘/any/file/really’.IO ~~ :e }) }
camelia rakudo-moar 46e0ed: OUTPUT«Memory allocation failed; could not allocate 4 bytes␤»
AlexDaniel m: for ^10 {await (for ^7 { start ‘/any/file/really’.IO ~~ :e }) }
camelia rakudo-moar 46e0ed: OUTPUT«Memory allocation failed; could not allocate 4 bytes␤Memory allocation failed; could not allocate 4 bytes␤»
MasterDuke gist of the valgrind output: gist.github.com/MasterDuke17/9ab9e...bf26f82316
AlexDaniel gc_free huh? Who would've thought 15:04
gfldex jnthn: would it make sense to return $!closed from Channel.send? 15:34
jnthn: the exception could be .resume and a Bool check after send could be done via `or last` to leave a loop that got a .send inside 15:37
jnthn: catching the exception is a bit tricky if there are any methods/subs called that could also do some Channeling. 15:39
jnthn: i found a way to handle it by having a block around the sends with `CATCH { when X::Channel::ReceiveOnClosed { last } }` inside 15:44
[Tux] github.com/Tux/CSV/blob/master/nc-c.pl => Internal error: Unwound entire stack and missed handler 16:18
$ perl6 nc-c.pl </tmp/hello.c
NativeCall eroor. I'm stuck
dalek ast: 34ee3d8 | usev6++ | / (5 files):
Add ticket number to fudged tests (RT #129782)
 16:22
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=129782
MasterDuke jnthn: btw, RT #129781 is for the segfault AlexDaniel was talking about earlier 16:41
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=129781
Zoffix Quick! Let's all give jnthn things to do! \o/ :) 16:48
MasterDuke i also have a house that needs to be painted... 16:51
dalek kudo/nom: 058de71 | (Zoffix Znet)++ | src/core/Array.pm:
Remove trailing whitespace
 17:00
kudo/nom: b77d2b7 | (Zoffix Znet)++ | src/core/Array.pm:
Fix infinihang on incorrect .split offset

Further fix for RT#129773: rt.perl.org/Ticket/Display.html?id=129773
This is really gross, but all alternatives I could think of take at least 1.5x more time to run. The `where` clause makes things ~14x slower. The nqp::istype checks, make things ~1.5x slower. The .^lookup+cando candidate signature check is about 10x slower.		 17:06
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=129773
Zoffix damn.... s/.split/.splice/; 17:10
dalek ast: 5d87503 | (Zoffix Znet)++ | S32-array/splice.t:
.splice with incorrect offset type does not hang

Further test for RT#129773: rt.perl.org/Ticket/Display.html?id=129773		 17:12
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=129773
dalek kudo/nom: 2dd6230 | MasterDuke17++ | src/Perl6/Actions.nqp:
Error when multiple *s are in a double closure

Fixes RT #129780		 17:21
kudo/nom: c4c0718 | lizmat++ | src/Perl6/Actions.nqp:
Merge pull request #893 from MasterDuke17/RT129780

Error when multiple *s are in a double closure
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=129780
travis-ci Rakudo build errored. Zoffix Znet 'Remove trailing whitespace' 18:01
travis-ci.org/rakudo/rakudo/builds/164292885 github.com/rakudo/rakudo/compare/4...8de71fab55
lucasb_ whitespace considered significant? :)
Zoffix In what context? 18:02
geekosaur docs, I believe
Zoffix kicks bug[TAB]
lucasb_ I was just kidding. dunno why travis errored
Zoffix AWOL! That's punnishable by death!
It errored due to timed out build 18:03
geekosaur death? bit late for that, no?
Zoffix travis-ci.org/rakudo/rakudo/builds/164292885
buggable [travis build above] ✓ All failures are due to timeout (1), missing build log (0), or GitHub connectivity (0)
Zoffix there :) 18:04
lucasb_ oh, it's just the jvm build, right? 18:05
Zoffix yup 18:06
Oh, god.... 18:22
Zoffix spots another missing splice candidate that infinihangs 18:23
m: [].splice: *, {;}
camelia rakudo-moar c4c071: OUTPUT«Memory allocation failed; could not allocate 131072 bytes␤»
Zoffix There's a lesson in all of this: don't go mental with letting your arguments be super flexible
YAGNI
travis-ci Rakudo build errored. lizmat 'Merge pull request #893 from MasterDuke17/RT129780 19:07
travis-ci.org/rakudo/rakudo/builds/164296325 github.com/rakudo/rakudo/compare/b...c071859fec
buggable [travis build above] ✓ All failures are due to timeout (1), missing build log (0), or GitHub connectivity (0)
psch i'm wondering if we should bug travis about that 19:27
or is their timeout only changable with some paid plan?
still, i'm kinda happy to have r-j in there again with (usually) passing 'make test' :) 19:28
in any case, the no-output timeout is somewhat weird and probably hints at a resource limitation on travis' end 19:30
'cause that step shouldn't really take more than maybe 3 or so minutes on a reasonable machine, barring any osx bugs
geekosaur I'm not actually sure that's a travis thing. I've seen enough failures with automated github accesses to make me wonder if github is actually that unreliable... 19:32
japhb .tell timotimo Awww, now I haz a sad. Any idea *why* changing the calling convention for enqueue made almost no difference if it was 50% of your runtime?
yoleaux2 japhb: I'll pass your message to timotimo.
geekosaur but mostly instead of extended failures it's one access fails the next works 19:33
psch geekosaur: well, the travis failure (and similar ones before) happens during compilation of one specific .nqp file
geekosaur oh, I didn't actually look and thought this was the usual timeout issue (travis access github and fail)
psch geekosaur: in this case it was NQPHLL.nqp that produced no output
geekosaur (which pretty much every travis-using project seems to have on a regilar basis) 19:34
psch geekosaur: ah. no, this is travis timing out the build because there was no output for 10 minutes
and subsequently killing it because it must be stuck
which, honestly, i wouldn't discount as a possibility, but afair it's consistenly osx that does that
geekosaur osx is probably oversubscribed
they didn't support it at all for a long time, because apple licensing means you have to have a bunch of (mostly rack-unfriendly) macs --- can't use vms 19:35
unless theyre running on macs
psch so, yeah, maybe we have some weird race on osx that keeps happening only on nqp master (which sounds kind of ridiculous because nqp master is a moving target) or osx doesn't have enough hardware behind it on travis
right, yeah, that's what i'm thinking
geekosaur the latter is very very likely :/
TimToady read that as VMS, not VMs
yoleaux2 28 Sep 2016 12:56Z <jnthn> TimToady: I've ran into a Unicode regex syntax ambiguity issue if you've a moment to look: github.com/perl6/specs/issues/118
psch as i said, that file in particular should take something like 3 or so minutes on reasonable hardware, and it's one of the longer-running ones too 19:36
so, yeah, seems more likely that they don't have enough power behind it to serve it in time
i mean, optimizing nqp-j somehow might help 19:37
but that's kind of a really hard thing to do, especially considering there's hardly anyone around who really gets the jvm backend *and* wants to work on it :P
Zoffix IIRC there's an option to make it wait longer
psch docs.travis-ci.com/user/customizin...d-Timeouts suggests otherwise 19:38
Zoffix It's in the link the failing build suggests at the end
psch ah, you're right, Zoffix++
not sure it's a good idea though, 'cause we just move the same target further 19:39
and, well, buggable++ is pretty great too
thing is, it shouldn't even time out with 10 minutes, honestly
hrm 19:40
"If you expect the command to take more than 20 minutes, prefix travis_wait with a greater number."
"install: travis_wait 30 mvn install"
that's not a prefix travis
Zoffix :) 19:41
dalek kudo/nom: 4abc28c | (Zoffix Znet)++ | src/core/Array.pm:
Add splice(Whatever, Callable) candidates

This should be the last nail in the coffin of infinihang in RT#129773: rt.perl.org/Ticket/Display.html?id=129773
These candidates aren't super useful and another way to fix it is to get rid of slurpy candidates for this, but then we lose the consistency that both offset and size can be any of Int:D|Callable|Whatever and introduce a special exception to the rule, along with forcing the users to add special checks for it when types of args aren't known.		 19:45
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=129773
ast: 8a702b9 | (Zoffix Znet)++ | S32-array/splice.t:
Test splice(Whatever, Callable) candidates

Part of RT#129773: rt.perl.org/Ticket/Display.html?id=129773
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=129773
timotimo japhb: did you try running the thing locally? 19:53
yoleaux2 19:32Z <japhb> timotimo: Awww, now I haz a sad. Any idea *why* changing the calling convention for enqueue made almost no difference if it was 50% of your runtime?
gfldex :-| i just got a segfault with Concurrent::File::Find 19:58
timotimo :( 20:00
.tell japhb i imagine if i don't clear the frame buffer and only enqueue blocks that have changed, it'd give a decent performance win ... 20:05
yoleaux2 timotimo: I'll pass your message to japhb.
japhb . 20:10
yoleaux2 20:05Z <timotimo> japhb: i imagine if i don't clear the frame buffer and only enqueue blocks that have changed, it'd give a decent performance win ...
japhb timotimo: Can't run it locally at the moment, I'm remoting through a couple tunnels, so have no way to test SDL stuff.
timotimo hehe 20:16
it'd probably be enough to just rip out every mention of SDL ;)
the slowest piece of the whole thing is enqueue, which only does some CArray stuff
travis-ci Rakudo build passed. Zoffix Znet 'Add splice(Whatever, Callable) candidates 20:39
travis-ci.org/rakudo/rakudo/builds/164317706 github.com/rakudo/rakudo/compare/c...bc28ca0712
timotimo japhb: my idea was worth a whole lot 20:42
put enqueue in the 11th spot when sorting by exclusive time 20:43
and it has less than 50% exclusive time of its inclusive time
japhb Wheeee 20:48
How's the overall speed improved? 20:49
timotimo it's ~44sec for 500 frames now 20:50
gfldex is there a way how much RAM rakudo hogs from within a script? 20:51
timotimo used to be 1:36m 20:52
gfldex: you can get an approximation from malloc with their stats function, but i forgot its name 20:53
japhb: ^^^
lucasb_ gfldex: a crazy idea is to use $*PID and pass that to 'top -p 1234' or something :D 20:54
gfldex: idk if that would work, or how to get a simple text output 20:55
probably better to call "ps" and pass the pid and scan the output 20:58
alternatively, read the file /proc/PIDNUMBER/stat :) 21:01
geekosaur ps -p$*PID -o vsz
or use /proc yeh
japhb timotimo: That's not a bad improvement. Still not a rockin' frame rate, but better than 5 fps was .... 21:15
timotimo of course 21:16
japhb What's the top cost now? Is it back to SDL?
timotimo down to 40 seconds by rendering the rects immediately rather than bunching them up 21:18
now the costliest part is the inner loop 21:19
i.e. the one looping over y values that's inside the loop that loops over x values
by over 2x, next one is the min method, then postcircumfix:<[ ]>
japhb timotimo: I guess then you get to TimToady's idea to precompute all neighborhoods, like he did with forest-fire. 21:25
timotimo i'm not 100% on that, but if someone else would implement it, i'd measure it :P 21:27
gfldex m: say (slurp '/proc/' ~ $*PID ~ '/stat').lines[0].split(' ')[23-1] 21:34
camelia rakudo-moar 4abc28: OUTPUT«93929472␤»
gfldex :)
m: say (slurp '/proc/' ~ $*PID ~ '/stat').lines[0].split(' ')[23-1,20-1] 21:35
camelia rakudo-moar 4abc28: OUTPUT«(93945856 1)␤»
lucasb_ other relevant proc files are /proc/1234/statm and /proc/1234/status. maybe they are better suited for your task :) 21:39
FROGGS m: my $statm = slurp "/proc/$*PID/statm"; my $mem = $statm ~~ /(\d+)\s+\d+$$/ && $0 * 4 / 1024; say $mem > 1024 ?? sprintf("%.3fG", $mem/1024) !! sprintf("%.1fM", $mem); 22:12
camelia rakudo-moar 4abc28: OUTPUT«53.4M␤»
FROGGS gfldex: ^^
m: my @a = ^999999; say @a.elems; my $statm = slurp "/proc/$*PID/statm"; my $mem = $statm ~~ /(\d+)\s+\d+$$/ && $0 * 4 / 1024; say $mem > 1024 ?? sprintf("%.3fG", $mem/1024) !! sprintf("%.1fM", $mem); 22:13
camelia rakudo-moar 4abc28: OUTPUT«999999␤160.7M␤»
Zoffix m: [].^lookup('splice').canidates.elems.say 22:27
camelia rakudo-moar 4abc28: OUTPUT«No such method 'canidates' for invocant of type 'Method+{<anon|73481792>}'␤ in block <unit> at <tmp> line 1␤␤»
Zoffix m: [].^lookup('splice').candidates.elems.say
camelia rakudo-moar 4abc28: OUTPUT«31␤»
Zoffix :}
timotimo yeesh :) 22:28
psch huh 22:29
that's a bit harsh
Zoffix Yeah. Speed is the reason.
psch i mean, i caught a bit of what brought this on, but yeah
Zoffix m: Buf.new.^lookup('splice').canidates.elems.say
camelia rakudo-moar 4abc28: OUTPUT«No such method 'canidates' for invocant of type 'Method'␤ in block <unit> at <tmp> line 1␤␤»
Zoffix m: Buf.new.^lookup('splice').candidates.elems.say 22:30
camelia rakudo-moar 4abc28: OUTPUT«8␤»
gfldex m: say (slurp '/proc/'~$*PID~'/status').lines».split(":\t")[*;1]».trim[16, 15]
camelia rakudo-moar 4abc28: OUTPUT«(69448 kB 69448 kB)␤»
lucasb_ Zoffix: does Buf.splice needs the same fixing you did for Array.splice? 22:31
gfldex that is VmSize and VmPeak
Zoffix lucasb_, yeah. It's what I'm working on now. That's how I discovered all the hanging cases in Array.splice
lucasb_ ok, Zoffix++
dalek ast: 0892f24 | (Zoffix Znet)++ | S32-array/splice.t:
[coverage] Test all Array.splice candidates
 23:32
ast: b8d710f | (Zoffix Znet)++ | S32-array/splice.t:
OCD
 23:34
AlexDaniel ++ for OCD commit ;D 23:41

Powered by Cro and the Raku® Programming Language.

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

Thank you!