AlexDaniel oh! 00:02
00:04 lichtkind left
rba help.github.com/en/github/getting-...hubs-plans 01:00
Geth_ rakudo: softmoth++ created pull request #3628:
Add :$chomp to Str.lines()		 01:34
01:36 softmoth joined
softmoth ^- I'm not sure if this is wanted by anyone other than me. I think it makes the language more consistent, and avoids devs having to re-invent the wheel with .comb() every time this comes up 01:38
...and I assume I'd need to add something to roast, I'm just not sure where exactly. 01:39
05:18 softmoth left 05:19 softmoth joined 05:22 toddr left 05:50 softmoth left, softmoth joined 06:01 reportable6 left 06:04 reportable6 joined 07:07 softmoth left
nine What do attributes without twigils (like `has $foo`) even mean? They don't seem to be documented and I can't find a single use of this in any of our tests. 07:51
m: class Foo { has $foo; method set_foo($v) { $!foo = $v; }; method get_foo() { $!foo }; }; my $a = Foo.new; my $b = Foo.new; $a.set_foo(1); say $b.get_foo; say Foo.^attributes
camelia (Any)
(Mu $!foo)
08:42 sena_kun joined
lizmat Files=1306, Tests=111232, 215 wallclock secs (28.80 usr 8.00 sys + 3022.80 cusr 277.40 csys = 3337.00 CPU) 09:05
nine The speculations say that has $a; will create a $!a attribute and install $a as a lexical alias to that attribute. But it doesn't say what other effects this would have and I really can't think of any. I also have no idea why that would make anything faster. 10:02
An attribute lookup is already one of the fastest things you can do (at least on MoarVM). In speshed and JITed code it's devirtualized and can access the memory location of the attribute directly. 10:03
10:04 Altai-man_ joined
Altai-man_ nine, `has $foo` is really weird if you ask me, but I do know such an occurrence in examples repo. 10:04
nine I wouldn't be surprised if support for that syntax was just an implementation accident, coming from sharing code between variable and attribute declarations 10:05
lizmat I think it's a source of obfuscation: if installing it as a lexical is so beneficial, the codegen should do that, regardless of the twigil
I would be in favour of deprecating it for 6.e 10:06
10:06 sena_kun left
Altai-man_ github.com/Raku/examples/blob/mast...p6#L83-L89 10:10
^
lizmat fixed 10:22
AlexDaniel Altai-man_: oh, I was about to commit a `sleep 20;` change :)
Altai-man_ AlexDaniel, I started with `loop sleep die` pattern, but then was like, ugghhgh, but it's raku.... ;) 10:23
AlexDaniel Altai-man_: interval(1) is too small though, but yeah 10:24
Altai-man_++
Altai-man_ AlexDaniel, what do you mean by "too small"?
you mean, it should be bigger? I don't think so. 10:25
AlexDaniel Altai-man_: in my measurements it takes 20s, so we're wasting 20 requests
Altai-man_ It's arguable, but I'd rather fire another request than wait for more. Woah, 20 seconds... For me it's usually about 5-6 seconds to remove a gist. :S
well, if that works that works, I guess 10:26
AlexDaniel Altai-man_: the limit is about 5000 requests per hour, which is fine I guess, but then if we start testing the module on a bunch of revisions then it could be a problem 10:35
still shouldn't be a problem, but 4 requests instead of 20 is probably a good idea, especially if it makes no difference anyway :)
Altai-man_ Yes, and if we get much more users doing testing a lot... But in this case this simple test file would need a Real Revision. 10:36
AlexDaniel, you can commit s/1/3/ if you want. :)
AlexDaniel already did :) github.com/raku-community-modules/...9a6d6f05a1 github.com/raku-community-modules/...540fb3ebc8
hmm why am I not using my own bot… c5734fa81c90dffa1cf41f005aff6c9a6d6f05a1 5f6d1fc667c5a293243c78a5e977d4540fb3ebc8
linkable6 (2020-04-15) github.com/raku-community-modules/...c5734fa81c Bump the sleep interval a bit
AlexDaniel aaand?
5f6d1fc667c5a293243c78a5e977d4540fb3ebc8
linkable6 (2020-04-15) github.com/raku-community-modules/...5f6d1fc667 Make sure tests finish in about a minute
AlexDaniel I should really figure out why it doesn't print the last one… 10:37
10:41 MasterDuke left
AlexDaniel nine: IIRC it is intentional, but yes I also don't see why we must support that 10:41
greppable6: has\s+\$[^.]
greppable6 AlexDaniel, 967 lines, 276 modules: gist.github.com/2627511a3e7ff6677a...f00835fa4c
AlexDaniel greppable6: has\s+\$[^.!]
greppable6 AlexDaniel, 38 lines, 24 modules: gist.github.com/0845a42a8ea3c6b942...6aab6f48b7 10:42
AlexDaniel nine: I think it's relatively popular simply because people forget ! or .
nine What the? So after another round of big refactors to Inline::Perl5 everythin including our production application works just fine and the code is yet more powerful and simpler. 10:46
Everything? No, a single test in a single test file fails when I run make test. It's a check if a destructor got called. 10:47
It also fails when I run it with `raku -Ilib t/v6.t`, BUT it succeeds when run with `raku -I. t/v6.t`
I hate destructor issues :/ They're cronically hard to test but also mandatory because memory leaks are real 10:49
jnthn I read that as "comically hard to test" and was confused for a moment... 10:55
nine Depends on hour humor I guess :) 10:56
s/hour/your/ 10:58
Apparently I shouldn't try typing today... 10:59
It's amazing. raku -I. t/v6.t reliably runs the destructors on the first try. raku -Ilib t/v6.t reliably fails to run destructors even when I put the whole test file into a loop doing 10K iterations 11:13
12:04 sena_kun joined 12:06 Altai-man_ left
Geth_ rakudo: 7bbf12d3e8 | (Elizabeth Mattijsen)++ | src/core.c/Parameter.pm6
nqp::eqat beats nqp::iseq_s(nqp::substr)

For two reasons:
  - no need to take a substr
  - no need to specify the number of characters in the needle		 12:11
lizmat nine: wouldn't that be accessing different versions of libraries ? 12:14
[Coke] lizmat++ nice find.
lizmat: did you have a tool that helped find that, or just reading source?
lizmat there's two more cases in the core, but they're part of a PR that we're discussing atm, and I don't want to bork its mergebility 12:15
that's where I saw it and did a search on the rest of the core
well, if they happened to be on the same line 12:16
nine lizmat: no, it's from the same directory. So the difference is really just CompUnit::Repository::FileSystem trusting META6.json in the -I. case vs. indexing modules on the file system in the -Ilib case. I guess what happens is that a different number of objects get allocated/GCed 12:18
lizmat or somehow we create a circular "reference" ?
in the -Ilib case ?
[Coke] the search was basically 'ack nqp::iseq_s src/core.c | ack substr' 12:19
[Coke] lizmat++ 12:20
nine Those aren't a problem for the GC :) What would be a problem is persistent references from a cache or something. But I don't have the slightest idea for a path through the module loader that would lead to the test's objects getting referenced
lizmat we're taking a nqp::sha1 for each file in the -Ilib case, no? 12:21
perhaps it's inside the nqp::sha1 ?
jnthn nine: If you can do a heap snapshot and find the non-destroy'd object still in the heap, there's a path command to tell you the path to it
nine jnthn: doing exactly that right now :)
12:24 pmurias joined
nine All look like Root 0 --[ Thread Roots ]--> Thread Roots (8) --[ Native callback cache target ]--> BOOTCode (Object) (159935) --[ Unknown ]--> initialize (Perl5.pm6 (Inline::Perl5):1139) (Frame) (159864) --[ self ]--> Inline::Perl5 (Object) (155820) --[ Unknown ]--> Scalar (Object) (155821) --[ Unknown ]--> Inline::Language::ObjectKeeper (Object) (155873) --[ Unknown ]--> Array (Object) (155876) --[ 12:33
Unknown ]--> IterationBuffer (Object) (51) --[ Index 25 ]--> Scalar (Object) (653166) --[ Unknown ]--> Foo::Bar::TestV6 (Object) (656478)
timotimo the ObjectKeeper is keeping it around, eh? :) 12:41
i wonder why exactly it calls the connection from the ObjectKeeper "unknown", i think it's supposed to give attribute names and such 12:51
jnthn Yeah, I thought so too 12:52
nine This thing gets stranger all the time. I actually have a fix. Now I don't know why it did work correctly in some cases. 13:22
The thing is that when extending a Perl 5 package with Raku via use v6-inline; I create an accompanying Raku class to hold the extensions. I create wrappers for all the Perl 5 methods, so they can be called on that Raku class. One of these methods was DESTROY, which overwrote the destructor that would free up the wrapped Perl 5 object 13:24
jnthn oops :) 13:33
Obvious in hindsight
nine Yep, it's obvious why that's wrong. What's not obvious is why it's only an issue with -Ilib, not -I. 13:34
Btw. I only discovered this discrepancy because I was becoming desparate. I added a couple fprintfs to p5helper.c but their output wouldn't show up. That's why I tried -I. 13:35
Turned out I added a #define fprintf(...) yesterday night to turn of the debug info...
13:59 softmoth joined 14:04 Altai-man_ joined 14:06 sena_kun left
nine OMG I finally found it. And....it's kinda embarassing, really. I forgot to add Inline::Perl5::Perl5Class to META6.json. This is the module I `require` as a workaround for the precomp issue I described last week. So raku -I. didn't find it locally, but some older installed version 14:17
14:18 finsternis left
nine Ok, to be precise, I'm pretty sure that I actually added it to META6.json, because I remember noticing that it's the only .rakumod file in the list, with the others still using .pm6 extensions. Must have accidentally removed it when resolving rebase merge issues 14:19
[Tux] Rakudo version 2020.02.1-315-g7bbf12d3e - MoarVM version 2020.02.1-80-g32dfe7507
csv-ip5xs0.731 - 0.755
csv-ip5xs-206.434 - 6.708
csv-parser24.557 - 27.006
csv-test-xs-200.400 - 0.404
test7.742 - 7.928
test-t1.985 - 2.028
test-t --race1.026 - 1.042
test-t-2031.558 - 34.054
test-t-20 --race10.886 - 11.341
 14:36
15:13 toddr joined, toddr left 15:15 toddr joined
[Coke] nine++ 15:36
15:47 Kaiepi left, Kaiepi joined
timotimo whew. 15:51
16:05 sena_kun joined 16:06 Altai-man_ left 16:22 MasterDuke joined 16:34 vrurg left 16:35 vrurg joined 16:39 vrurg_ joined 16:41 vrurg left
MasterDuke huh, forgot that profiling things that use proc::async just leads to lots of ThreadPoolScheduler stuff sitting at the top 16:52
timotimo yeah, it usually spends the entirety of the program's time waiting for tasks to arrive 16:54
and there's the supervisor that sleeps and does calculations many times a second
MasterDuke anyone have an objection to merging github.com/MoarVM/MoarVM/pull/1270 ? i've now profiled a bunch of random stuff and haven't run into any problems 16:58
or do people want to take a closer look at the list?
timotimo: can i assume that the time for all the other stuff is correct if what i actually care about is the code i wrote? i.e., i can just ignore all the ThreadPoolScheduler stuff? 17:00
timotimo yeah, that's a fine suggestion
17:01 vrurg joined, vrurg_ left
timotimo i wonder if i should put something in that measures how often an allocation was accepted vs ignored for every op before the prof_allocated 17:01
MasterDuke profiling gist.github.com/MasterDuke17/7aafa...f04494525e shows 38m BOOTCodes allocated 17:10
17:34 patrickb joined, vrurg left 17:35 vrurg joined 18:03 Altai-man_ joined 18:06 sena_kun left 18:08 squashable6 left, squashable6 joined 18:59 squashable6 left 19:01 squashable6 joined
Geth_ rakudo/master: 4 commits pushed by (Ben Davies)++, (Elizabeth Mattijsen)++ 19:35
19:45 softmoth left, softmoth joined
Geth_ nqp: 0fbca34681 | Coke++ | 2 files
Remove sayfh opcode

Resolves #614		 19:56
nqp: c1ffc0ecfc | (Will Coleda)++ (committed using GitHub Web editor) | 2 files
Merge pull request #615 from Raku/jvm-sayfh-rm

Remove sayfh opcode
linkable6 NQP#614 [closed]: github.com/Raku/nqp/issues/614 [JVM] Remove sayfh opcode
20:05 sena_kun joined 20:06 Altai-man_ left 20:07 softmoth left 20:08 softmoth joined
[Coke] \o/ 20:09
nice to get a commit that involves actual code.
lizmat [Coke]++ 20:10
20:11 pmurias left
Kaiepi so i wrote a small script for benchmarking that takes iterations over 5 minutes and calculates how many iterations are done per second. this probably still isn't entirely accurate, but is better than doing a million iterations and hoping for the best i guess 20:12
with that, the Capture.WHICH commits make things closer to around 10% faster, which makes more sense since i doubt the way it was building strings was *that* big a bottleneck 20:13
so i was probably just overreacting
[Coke] benchmarks++ 20:23
Geth_ nqp: 1342e203e0 | (Daniel Green)++ | src/vm/moar/HLL/Backend.nqp
Fix profile kind detection

Before it was only checking if the strings '.html' or '.json' existed at all in the given filename, not that they were at the end (like it correctly did for '.sql').		 20:27
[Coke] Is there an easy way to grep through the ecosystem of use of an nqp opcode? 20:30
(spurtasync is the one I'm looking at right now)
MasterDuke [Coke]: greppable6 20:32
greppable6: spurtasync
20:33 Kaiepi left
greppable6 MasterDuke, Found nothing! 20:33
[Coke] MasterDuke++ 20:35
greppable6: printfh 20:36
greppable6 [Coke], Found nothing!
lizmat nqp: nqp::spurtasync()
camelia No registered operation handler for 'spurtasync'
at gen/moar/stage2/QAST.nqp:1504 (/home/camelia/rakudo-m-inst-1/share/nqp/lib/QAST.moarvm:compile_op)
from gen/moar/stage2/QAST.nqp:6145 (/home/camelia/rakudo-m-inst-1/share/nqp/lib/QAST.moarvm:compile_n…
lizmat [Coke]: say what? :-)
20:36 Kaiepi joined
[Coke] greppable6: readlinechompfh 20:36
greppable6 [Coke], Found nothing!
[Coke] lizmat: it's jvm specific 20:37
jnthn That op was implemented on the jvm during the early experimentations with concurrency
lizmat aaahhh ok
[Coke] nqp-j: nqp::spurtasync()
jnthn: I think there's probably a dozen ops I can cut out.
Easier than documenting them, anyway.
jnthn Yeah, indeed
readlinechompfh is a leftover also, from when we had the VM doing string-y IO 20:38
[Coke] greppable6: setinputlinesep
greppable6 [Coke], Found nothing!
jnthn Nowadays we just have the VM do byte I/O and provide a decoder API and plumb 'em in NQP/Rakudo
[Coke] greppable6: setencoding
jnthn That's another one from the now-gone string I/O collection
greppable6 [Coke], Found nothing! 20:39
jnthn And that :)
[Coke] if something appears in stage1's definition, but still isn't actually used, we can still remove it, just have to regen the stages, right?
jnthn Yes
[Coke] greppable6: linesasync 20:40
greppable6 [Coke], Found nothing!
[Coke] (sorry about the noise)
greppable6: readlinefh 20:41
greppable6 [Coke], Found nothing!
[Coke] greppable6: readlinechompfh
greppable6 [Coke], Found nothing!
[Coke] greppable6: readallfh 20:42
greppable6 [Coke], Found nothing!
jnthn Ditto for those :) 20:43
I wonder what lineasync did and if I really thought that was a good idea... :)
[Coke] greppable6: spurtasync
greppable6 [Coke], Found nothing!
[Coke] crap, I think I looped back. :)
greppable6: syncpipe 20:44
greppable6 [Coke], Found nothing!
[Coke] greppable6: nfatostatelist
greppable6 [Coke], Found nothing!
MasterDuke [Coke] is doing his own work async 20:45
[Coke] there's a jvm spawn opcode, - there's a lot of matches to "spawn", but it doesn't look like that opcode is actually used... 20:46
greppable6: slurpasync 20:47
greppable6 [Coke], Found nothing!
[Coke] greppable6: readcharsfh
greppable6 [Coke], Found nothing!
[Coke] greppable6: setup_blv
greppable6 [Coke], Found nothing!
[Coke] greppable6: closefh_i 20:48
greppable6 [Coke], Found nothing!
[Coke] greppable6: closefhi
greppable6 [Coke], Found nothing!
[Coke] greppable6: continuationclone 20:49
greppable6 [Coke], Found nothing!
[Coke] greppable6: attrhintfor 20:50
greppable6 [Coke], Found nothing!
20:51 rypervenche left
[Coke] there's a shell which similarly has a lot of stuff named like it, but it doesn't look like we're using nqp::shell for jvm. 20:51
Geth_ nqp: coke self-assigned Remove unused jvm opcodes github.com/Raku/nqp/issues/616
3cc09bdf83 | MasterDuke17++ (committed using GitHub Web editor) | docs/ops.markdown
 20:54
20:56 Ven`` joined 20:57 Kaiepi left, Kaiepi joined
AlexDaniel greppable6: nqp:: 21:07
greppable6 AlexDaniel, 744 lines, 90 modules: gist.github.com/fc82cf283b8b39269f...05b8184929 21:08
AlexDaniel 90 modules oh my
jnthn greppable6: QAST::
greppable6 jnthn, 37 lines, 10 modules: gist.github.com/e2ae1bd446a68955ef...3b0ebfe9f1 21:09
jnthn Phew, not so bad
Though the nqp:: ones are not at risk of being all broken in one swoop, and those using QAST will be. 21:10
[Coke] greppable6: openasync
greppable6 [Coke], Found nothing! 21:11
[Coke] finding more that *have* documentation but are unused. (like openasync)
(clustered together in the source)
21:13 Altai-man_ joined 21:15 sena_kun left
[Coke] nfafromstatelist - this is defined and used for all 3 backends. jvm had a nfa*to*statelist that was unused. 21:16
21:20 patrickb left
MasterDuke timotimo: ah ha! nine++'s patch gist.github.com/niner/8ebb8c6a1052...12759d85c4 gets a --profile-compile of compiling CORE.c to in fact try to write out the profile (after 28 min to compile), but it is reaped by the oom killer 21:25
timotimo oh jeez
MasterDuke oO(guess i do need that 64gb after all) 21:26
22:20 Altai-man_ left 22:33 Kaeipi joined, Kaiepi left
nqp: a5332ac14e | MasterDuke17++ (committed using GitHub Web editor) | docs/ops.markdown
smrt_(int|num|str)ify -> (int|num|str)ify
 22:54
23:09 softmoth left 23:10 softmoth joined 23:13 softmoth left, softmoth joined 23:19 softmoth left 23:20 softmoth joined 23:38 Ven`` left 23:46 MasterDuke left

Powered by Cro and the Raku® Programming Language.

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

Thank you!