00:10 Kaiepi left 00:11 Kaiepi joined 00:12 Kaiepi left 00:13 Kaiepi joined, upupbb-user2 joined 00:22 Kaiepi left 00:29 hungrydonkey joined 00:31 Kaiepi joined 00:43 lucasb left 00:51 upupbb-user2 left 00:54 vrurg left 00:56 vrurg joined 01:01 tinmarino joined, vrurg left 01:03 vrurg joined
tinmarino Hi, all. I have a question. I am making a Slang to have varaible without any sigils. additionaly set "no strict" automatically. So I just permit `<?>` in sigil which is fine but some tests fails. I would like `$<sigil>.Str` to return '$' in case "<?>" was matched. 01:05
Here is the [module](github.com/tinmarino/nogil). Arne asked a similar question [here](stackoverflow.com/questions/55079169) 01:07
01:07 vrurg left
tinmarino I know it is 3am in Europe ... maybe you'll find the question tomorrow. Maybe some non-european on the list 01:09
01:27 vrurg joined 01:32 vrurg left 01:33 vrurg joined
tinmarino I described better my problem here : stackoverflow.com/questions/60982963 : I did not want to contaminate Arne post. 01:42
02:06 tinmarino left 02:21 hungrydonkey left 03:10 upupbb-user1 joined 04:09 squashable6 left 04:12 squashable6 joined 05:17 squashable6 left 05:18 squashable6 joined 05:35 tinmarino joined 05:36 tinmarino left 06:14 upupbb-user1 left 06:18 upupbb-user1 joined
tyil jjatria: at a glance it's a good start, I'll need to wake up properly to give actual feedback 06:22
jjatria: if you want to work with an MR, I can push the repo to gitlab 06:23
06:48 [TuxCM] left
AlexDaniel one thing I'll never understand in Raku is the whole is-lazy situation 07:00
for example: 07:01
m: my @a = 1, {last if $_ ≥ 10; $_ + 1} … ∞; say +@a
camelia Cannot .elems a lazy list
in block <unit> at <tmp> line 1
AlexDaniel so for some random reason I cannot even attempt to do certain operations on lists/arrays that are potentially infinite
even if they are in fact not 07:02
and the weird thing is that normally you don't know/don't care if it's lazy or not, you're just writing a sub or method that needs to get the job done 07:04
you can of course spread is-lazy checks all over your code but that's LTA
you can also do `eager` for whatever you get but again that's not as awesome 07:05
or, I don't know, maybe it makes sense?
I guess my point is that in real life most things are not infinite, but many things are is-lazy 07:06
07:29 AlexDaniel` left, unclechu left 07:32 Geth left, Geth joined 07:43 upupbb-user1 left
jjatria tyil: I was going to try the git email thing once this was in better shape, but if you don't mind working on eg. gitlab, then that would certainly be easier for me 07:54
tyil I would prefer to not depend on a centralized, non-free service, but I have a gitlab account regardless
07:57 unclechu joined 08:18 AlexDaniel` joined 08:36 sena_kun joined
lizmat Files=1306, Tests=111227, 224 wallclock secs (28.66 usr 8.28 sys + 3026.75 cusr 281.48 csys = 3345.17 CPU) 08:53
MasterDuke 224 wallclock? 09:01
jjatria tyil: I'll send you the patch on email, I just wanted to have something to show for now 09:02
MasterDuke nine: this is my WIP for writing bytecode on the fly. it's not building, but does it look like i'm on the right track? github.com/MasterDuke17/nqp/commit...6594b27e70 09:05
tyil jjatria: awesome :) 09:08
lizmat MasterDuke: yeah, with about 60 more CPU seconds as well :-(
could be my revert to make native array access faster 09:09
tyil jjatria: I'd put the Dockerfiles in lib/docker, also note that it's bash, not posix sh, so you should use [[ -z $test ]], as opposed to [ -z "$test" ]
MasterDuke or 4221f8225feae173c438b9c726b62898ec4c1e7c ?
linkable6 (2020-04-01) github.com/rakudo/rakudo/commit/4221f8225f Adopt MoarVM-provided value_desc_cont
tyil jjatria: there's a convenience wrapper for mktemp in the project, tmpfile, which will clean up afterwards for you, so you don't need to pay attention to it 09:10
nine lizmat: I'd be a bit surprised if native arrays make up such a large chunk of our spec test time
lizmat yeah, clutching at straws here... :-)
still, it could be a local anomaly
let's see what the next run will bring
MasterDuke ugh, opening a file read+write in nqp dies if it doesn't already exist 09:11
nine MasterDuke: looks sensible. You could write the header last instead of writing and updating single fields later. Do you have any performance numbers yet?
MasterDuke nine: is the header a fixed size? otherwise it'd be moving the file contents around to prepend it 09:12
only artificial benchmarks showing significantly less memory used for only a slight increase in time. but i'm not sure how representative they are 09:13
nine yes, it's a fixed size 09:14
MasterDuke i'm definitely not doing something right, since it currently complains that `Frame has invalid bytecode start point 0 (size 0)`
nine I'd actually be surprised if the memory savings were significant as even the full CORE.setting is just 2.4M in size. 09:15
MasterDuke but if the size are just wrong enough, but may need to resize (i think it defaults to twice the size) just before the last write or so and then there's a lot of wasted space 09:17
and there currently are increases in ssize of 6m during the rakudo compile when i add some logging to asplice 09:18
"increased by: elems = 6038832, start = 0, ssize = 6037504" with a backtrace of write_buf, write_serialized_data, assemble, assemble, assemble_to_file, ... 09:19
maybe heaptrack is getting confused. these are my artificial benchmarks if you want to confirm 09:22
heaptrack ./install/bin/raku --full-cleanup -e 'use nqp; my $a := buf8.new; my int $c = 0; my $f := nqp::open("atatime-reallocate0", "w"); while $c++ < 2_000_000 { $a.write-uint32(nqp::elems($a), $c); if $c %% 100_000 { nqp::writefh($f, $a); $a.reallocate(0) } }; nqp::closefh($f)'
heaptrack ./install/bin/raku --full-cleanup -e 'use nqp; my $a := buf8.new; my int $c = 0; my $f := nqp::open("all", "w"); while $c++ < 2_000_000 { $a.write-uint32(nqp::elems($a), $c) }; nqp::writefh($f, $a); nqp::closefh($f)'
i tried to just use nqp, but heaptrack wouldn't report anything at all 09:23
afk for a bit 09:24
09:35 Ven`` joined
nine I'm not convinced those allocations are a real problem. malloc does not actually reserve or activate the memory you request (memory overcommitment). The kernel will create the mapping, but the actual physical memory is only allocated by 4K page once you access the memory. 09:35
So even if we allocate generously, the actual memory usage may not grow nearly as much 09:36
09:53 upupbb-user1 joined
MasterDuke sure, i'm not saying it's *necessary*. but if it's not appreciably slower than doing the allocations, why not remove the memory pressure? 10:04
nine We usually want to reduce memory pressure because it hurts performance. If the fix turns out to be slower we haven't won but actually lost 10:05
10:06 Altai-man_ joined 10:08 sena_kun left
jjatria tyil: Ah, nice. I'll make those changes you pointed out. Thanks! 10:09
tyil \o/
jjatria One thing that still is not quite right, I think, is that I'm copying only the directory where Raku got installed to keep the image sizes small, but I think this does not include any shared libraries (eg. libreadline) 10:10
tyil jjatria: gitlab.com/tyil/docker-perl6/-/blo...ile/debian might these be of value to you? 10:18
last I checked, those were the smallest docker images with Raku publicly available 10:19
those times may have changed, as I've not been keeping an eye on that
but the dockerfiles remain good nonetheless, and you can see multi-stage builds in action :) 10:20
you can do the "heavy" steps in earlier stages, and in the final stage you only need to copy over the end-results from the earlier stages
so you can freely use apt to your heart's content, and only COPY the relevant library files in the last stage 10:21
jjatria tyil: Nice, yeah, I can use those. I was already doing some multistaging, to allow me to use the sources already fetched by rstar, for example, but it gives me a good model for eg. WORKDIR, etc 11:03
It also seems like we were copying the same bits, so that at least is reassuring 11:04
tyil :> 11:07
multistage builds are highly convenient
they're reasonably easy to understand, and they can make your dockerfile a whole lot cleaner on very big builds 11:08
nine So the docker world slowly rediscovers what the distro world learned in packaging over a couple of decades?
11:09 ufobat_ left, ufobat joined
jnthn There's nothing new under the sun... :) 11:11
tyil nine: its $current-year, it's not hip if you don't reinvent the wheel at least twice and still end up with an inferiour end-product 11:27
Altai-man_ .oO ( Lindy effect ) 11:40
12:07 sena_kun joined 12:08 Altai-man_ left 12:10 Ven`` left
lizmat spend a few hours on trying to make native array[42] access faster again, but gives up 12:15
*spent
12:22 Ven`` joined
lizmat is definitely not grokking the native shaped array implementation 12:29
13:09 masak joined, Guest54471 left
Geth rakudo: Kaiepi++ created pull request #3589:
Improve X::Syntax::Variable::MissingInitializer's message		 13:19
13:19 masak is now known as Guest16689
Geth roast: Kaiepi++ created pull request #632:
Update tests WRT X::Syntax::Variable::MissingInitializer's new msgs		 13:20
14:06 Altai-man_ joined 14:08 sena_kun left
MasterDuke getting close (i think), now the error is 'Special frame index out of bounds' 14:42
heh, one error condition is `rs->main_frame > rs->expected_frames`. i'm getting an rs->main_frame of 71976 and an rs->expected_frames of 176 14:45
14:52 tinmarino joined 14:55 tinmarino left 15:23 ufobat_ joined 15:27 ufobat left, [Coke] left 15:49 [Coke] joined, [Coke] left, [Coke] joined 16:06 sena_kun joined 16:09 Altai-man_ left 17:25 Ven`` left
nine So, why is my Inline::Perl5 testcase leaking memory? Because it doesn't read a package variable like $TestMemory::idontevenexistbutthatdoesntmatter 17:39
That's the difference between this test case and the existing test file that checks if destructors are called. The latter uses such variables to count destructor calls
Now why that variable access makes a difference? Why indeed 17:40
17:44 upupbb-user1 left
nine And no, that package global doesn't have to be anything related to Perl 5 17:45
So this grows and grows: 17:54
raku -Ilib -e 'use lib:from<Perl5> "t/lib"; use TestMemory:from<Perl5>; loop { { my $tm = TestMemory.new; $tm.noop; }; use nqp; nqp::force_gc; }'
While this doesn't:
raku -Ilib -e 'use lib:from<Perl5> "t/lib"; use TestMemory:from<Perl5>; loop { { my $tm = TestMemory.new; $tm.noop; }; use nqp; nqp::force_gc; $i::j }'
jnthn m: dd $i::j 18:03
camelia Any element{'$j'} = Any
jnthn nine: Is there any difference in how many DESTROY callbacks run between the two? 18:04
nine yes, the version with $i::j clearly runs those DESTROYers 18:05
The other one has been running for 10 minutes now without running a single one 18:06
18:06 Altai-man_ joined
jnthn OK. The thing is, destroy blocks are currently run by setting up a block exit handler. 18:06
I'm wondering if somehow the only place we ever attach that - perhaps thanks to inlining - ends up being the compunit 18:07
And allocations all happen there too
Whereas when we insert `$i::j` we make a Scalar allocation in another block, and that forces collects 18:08
18:08 sena_kun left
jnthn I'm...a little surprised that a real world application would suffer from this given it allocates all over. OTOH, now you mention this, I recall github.com/rakudo/rakudo/issues/28...-492688481 also (which I'd completely forgotten about) 18:09
vrurg jnthn: not sure if this is related, but there is another issue with DESTROYs not been invoked: github.com/rakudo/rakudo/issues/2898 18:10
oops... same link. 18:11
nine jnthn: running DESTROYers in their own thread would be pretty catastrophic for Inline::Perl5...
jnthn I'm...not sure to what degree thread affinity is promised there today, tbh 18:12
Ah, it is 18:13
github.com/MoarVM/MoarVM/blob/mast...lize.c#L31
There's a queue per thread context
I wonder what other mechanism we could find for ensuring this is run more often... 18:14
Well, or doesn't depend on the current frame existing 18:15
*exiting
nine In our Cro applications we use one Inline::Perl5 interpreter per thread via a role mixed into $*THREAD: gist.github.com/niner/13f6f2160ea6...55e9c7bdb9
I guess we're not keen on nested runloops? 18:16
jnthn No, plus I don't know that you'll be in a good state to invoke 18:17
Just 'cus something is an allocation safepoint doesn't mean anything else will go well.
I'm a bit confused how this happens in a Cro application that is processing requests though; surely the incoming request handler allocates all over the place too 18:18
nine To be clear: I don't say that this is what's causing our leaks in Cro applications. It's just what I came across when trying to get a reduced test case. So far it has yielded one actual leak in Inline::Perl5 and a source of segfaults. 18:19
jnthn OK
I'm still wondering based on #2989 if there's something else dubious going on...
nine Oh, I definitely found another Inline::Perl5 issue. While TestMemory.new.noop is fine, TestMemory.new.self leaks. The latter returns the invocant. This means that when returning we have 2 references to that object, so we won't sever the link from the Perl 5 object to the Raku object as if the Perl 5 object was still in use. But it actually isn't as both references will be from Raku. 18:28
Damn this stuff is complicated
20:07 sena_kun joined 20:08 Altai-man_ left 20:29 maggotbrain left
timotimo you can reference that twice 20:34
Geth ¦ nqp: vrurg self-assigned Building NQP on Windows github.com/Raku/nqp/issues/609 21:03
roast: vrurg++ created pull request #633:
Cover special case of wrapping first multi-candidate		 21:16
rakudo: vrurg++ created pull request #3590:
Fix for wrapping of parent's first multi-candidate		 21:23
vrurg .ask AlexDaniel don't you think it actually makes sense to have unified 'dispatching' label instead of specific 'multimethod' in rakudo repo? 21:25
tellable6 vrurg, I'll pass your message to AlexDaniel
AlexDaniel . 21:26
vrurg: change it!
vrurg Ok, didn't want to do it without asking. :)
cognominal Do you think it is possible to extend rakudo to support user defined dotty operators. Like for supporting optional chaining à la javsacript. Yea, dotty user, that's me. developer.mozilla.org/en-US/docs/W...l_chaining 21:33
AlexDaniel cognominal: well… we already have .? :) 21:37
m: say 5.Rat.succ.?nude 21:38
camelia (6 1)
AlexDaniel m: say Int.Rat.succ.?nude
camelia Invocant of method 'Rat' must be an object instance of type 'Int', not a type object of type 'Int'. Did you forget a '.new'?
in block <unit> at <tmp> line 1
AlexDaniel m: say 5.Rat.succ.?nude
camelia (6 1)
AlexDaniel m: say 5.succ.?nude
camelia Nil
AlexDaniel I mean, whatever
it's a bit different though, but it is sometimes useful 21:39
lizmat m: dd Nil.foo
camelia Nil
lizmat cognominal: also note that (almost) any method called on Nil will give Nil 21:40
m: 42.?foo.bar.baz.zippydoodah
camelia ( no output )
lizmat m: dd 42.?foo.bar.baz.zippydoodah
camelia Nil
AlexDaniel and then there's also andthen 21:41
lizmat m: dd 1 ... 5.5
camelia (1, 2, 3, 4, 5).Seq
lizmat m: dd 1 ...^ 5.5 21:42
camelia (1, 2, 3, 4, 5).Seq
lizmat huh? shouldn't that need to be 1,2,3,4 ?
AlexDaniel m: Nil andthen .nude.say
camelia ( no output )
AlexDaniel m: 5.5 andthen .nude.say
camelia (11 2)
AlexDaniel lizmat: why? who said that sequences are int-only?
m: dd 0.5, 1 ...^ 5.5 21:43
camelia (0.5, 1.0, 1.5, 2.0, 2.5, 3.0, 3.5, 4.0, 4.5, 5.0).Seq
lizmat my interpretation is that ...^ should exclude the final element
AlexDaniel it didn't include 5.5 for sure :)
lizmat but that case is clear to me... 21:44
AlexDaniel it's more about the condition
lizmat documentation: "For the ... operator, the final element is included, for the ...^ operator it's excluded." 21:45
AlexDaniel hmmmm
lizmat: actually, you're probably right… 21:47
at first I thought the docs are wrong but now that I look at it it's a bit weird :S
so these are currently identical: 21:48
m: dd 1 ... 5.5
camelia (1, 2, 3, 4, 5).Seq
AlexDaniel m: dd 1 ...^ 5.5
camelia (1, 2, 3, 4, 5).Seq
AlexDaniel lizmat: I guess it's because .. acts the same way? 21:51
lizmat well, I think ... exists because it wants to be different from ..
?
I don't think this case is tested 21:53
AlexDaniel c: all .say for 1 ...^ 5.5 21:56
22:06 Altai-man_ joined 22:09 sena_kun left
committable6 AlexDaniel, gist.github.com/bef124b41bb65f7606...e6bdf82e10 22:18
AlexDaniel heh gist.githubusercontent.com/Whateve...d3b/result 22:29
23:21 sena_kun joined 23:23 Altai-man_ left
Geth rakudo: 306d87b0df | (Vadim Belman)++ | src/Perl6/Metamodel/Dispatchers.nqp
Fix for wrapping of parent's first multi-candidate

Resolves the problem described by @jnthn in Raku/problem-solving#170. The point of this fix is to make wrapper dispatcher transparent for the wrapped routine. Whatever combination of dispatcher/nextdispatcher the wrapped routine was invoked with – the same combination must be used when invoking the last candidate which is the actual wrapped routine code.		 23:31
rakudo: 2cbf58372f | (Vadim Belman)++ (committed using GitHub Web editor) | src/Perl6/Metamodel/Dispatchers.nqp
Merge pull request #3590 from vrurg/problem-solving-170

Fix for wrapping of parent's first multi-candidate
roast: d96a5e1eee | (Vadim Belman)++ | S06-advanced/dispatching.t
Cover special case of wrapping first multi-candidate

Solves a problem described by @jnthn in Raku/problem-solving#170. When the first multi-candidate of a method is wrapped on a parent class the control is then returned to the `MethodDispatcher` causing the rest multi-candidates to be skipped.
roast: b3e3ecce95 | (Vadim Belman)++ (committed using GitHub Web editor) | S06-advanced/dispatching.t
Merge pull request #633 from vrurg/problem-solving-170

Cover special case of wrapping first multi-candidate
23:55 upupbb-user2 joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!