🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | log inspection situation still under development | For MoarVM see #moarvm
Set by lizmat on 22 May 2021.
00:02 reportable6 left 00:03 reportable6 left 01:04 reportable6 joined
Geth rakudo: 08f5448de0 | (Vadim Belman)++ | src/Perl6/Metamodel/ClassHOW.nqp
Fix a race in ClassHOW new_type

Anonymous class ID is storead in a class `my` variable and was incremented by `new_type` method without a lock protection. In my testing the probablity of creating a clashing name was ~0.25% for concurrently invoked `new_type` methods.		 01:52
rakudo: 83b0bca78a | (Vadim Belman)++ | src/Perl6/Metamodel/ClassHOW.nqp
Narrow the lock protected code down to the increment only

Minor performance improvement. Especially for cases where class name is provided.
rakudo: b7f088b5a1 | (Vadim Belman)++ (committed using GitHub Web editor) | src/Perl6/Metamodel/ClassHOW.nqp
Merge pull request #4482 from vrurg/fix-class-id-race

Fix a race in ClassHOW new_type
02:04 linkable6 left, evalable6 left 02:05 linkable6 joined 02:06 evalable6 joined
japhb vrurg: Any particular reason not to just make $anon_id an atomicint? 02:13
vrurg japhb: Aha, the simplest one: NQP doesn't do atomics. :D 02:14
Perhaps it's possible to declare an int with appropriate representation, but JVM would need a lock anyway. 02:17
japhb nodndo, makes sense 02:25
*nodnod
moon-child java doesn't have atomics??? 02:42
I knew they were focused on doing concurrency well...how can they not have atomics?
[Coke] I assumed they meant nqp atomics. 02:49
Java does have an AtomicInteger 02:50
japhb moon-child: [Coke] was reading (my side at least) correctly. The JVM port doesn't have enough active contributors right now to keep up with MoarVM improvements, so there are often deep things that we conditionally compile differently on MoarVM and JVM (and JS) backends, or that are only fully supported on MoarVM. 04:22
moon-child got it 04:33
04:44 linkable6 left, evalable6 left 04:47 linkable6 joined 05:46 evalable6 joined 06:04 reportable6 left 06:06 reportable6 joined
Xliff Is it possible for a raku script to start a stay-resident subroutine and return control to the executing shell? 08:09
Something like daemonize, but in pure 08:10
Raku?
Altai-man Xliff, "pure Raku" includes NativeCall or? 08:24
Xliff Sure! Why not? 08:29
Altai-man Xliff, if NativeCall is allowed you can look at github.com/hipek8/p6-UNIX-Daemonize if it's of any help. 08:33
Or other solutions I can think of are based on unix daemonize, which is C and so NativeCall.
Xliff, ah, except the tickets say it's broken, but with your experience you can bitrot it maybe? 08:34
oops, *de-bitrot
lizmat Xliff: maybe this is a simpler way: 08:39
m: sub daemonize(&code) { Thread.new(:&code).run }; daemonize { say "sleeping at {time}"; sleep 5; say "done at {time}" }
camelia sleeping at 1627634384
done at 1627634389
lizmat in combination with closing STDIN/STDOUT and such 08:40
moon-child lizmat: that's not really a daemon, though. You can't close the terminal and have that code continue to run 08:43
lizmat not even after closing STDIN/STDOUT/STDERR ? 08:44
moon-child afaik once the main thread returns from main, the c runtime (at least on linux) will call exit_group(), which kills all threads 08:47
lizmat indeed :-( 08:49
moon-child depends on how 'pure' pure raku is, maybe Proc::Async.new: 'raku', 'myscript.raku', '--doitforreal' would work 08:51
lizmat I think Cro does it somehow, for production purposes? 08:52
maybe #cro would be a good place to ask?
moon-child yeah, Proc::Async seems to work 08:54
Xliff: ix.io/3usR 08:58
Xliff Heh --doitforreal
moon-child I don't think it's going to get much better than that. C has to fork, and you can't really fork in raku
08:59 linkable6 left, evalable6 left
Xliff moon-child: Thanks! 08:59
moon-child alternative to closing in/out/error might be handling sighup and closing them only once you get that. Then you can post status messages until the terminal is closed
09:01 evalable6 joined
MasterDuke there is actually an nqp::fork, but it isn't used/exposed in rakudo 09:04
moon-child yeah, but mvm makes threads, and you can't really use fork together with threads 09:06
MasterDuke brrt figured something out, i think there was some relatively recent posix addition to handle threads better than before 09:07
moon-child ooh, really? Cool 09:08
(I mean, death to fork; but still that's cool) 09:09
09:32 patrickb joined 10:00 linkable6 joined 10:30 sena_kun joined
Geth nqp/new-disp: 3c39060361 | Altai-man++ (committed using GitHub Web editor) | tools/templates/MOAR_REVISION
Bump MoarVM to new-disp

This fixes building of nqp with --gen-moar option and partially unblocks Blin.		 10:49
rakudo/new-disp: 2491851012 | Altai-man++ (committed using GitHub Web editor) | tools/templates/NQP_REVISION
Bump NQP to new-disp

This fixes building of rakudo with --gen-moar --gen-nqp options and unblocks Blin.		 10:51
nine moon-child: actually, you can fork in Raku. As long as you've never started any worker threads 11:10
brrt++ implemented support for fork 11:11
lizmat but is it exposed? 11:26
nine I don't know 11:36
12:02 reportable6 left 12:05 reportable6 joined
ugexe i would think you couldnt have started any libuv based threads 12:50
leont Yeah, threads and forking don't really work well together. 12:52
Or to be precise, after forking a multi-threaded program you're limited to async-signal-safe functions, unless special precautions have been taken. 12:53
Precautions can be taken with help of pthread_at_fork; ironically making fork no longer async-signal-safe 12:54
13:22 [Coke]_ joined 13:24 raydiak_ joined 13:25 sjn_ joined 13:34 sjn left, raydiak left 15:24 sjn_ is now known as sjn
Geth nqp/new-disp: a258a33671 | (Jonathan Worthington)++ | src/core/dispatchers.nqp
Handle call sites megamorphic in method name

Build a lookup table and use it at such callsites, rather than blowing up the inline cache with a ton of entries.		 16:12
nqp/new-disp: 2e107b0de9 | (Jonathan Worthington)++ | src/core/NQPMu.nqp
Avoid a slurp/flatten in NQP object creation

Borrow a trick from Rakudo, except we can also assume that nobody will override bless in NQP.
rakudo/new-disp: 123046c75d | (Jonathan Worthington)++ | 13 files
Adapt to NQP API change
16:55 melezhik joined
melezhik the latest rakudo version (2021.07) started to produce `Please use exitcode and/or signal methods (status is to be removed in 2022.06) instead.` warning on my code 16:56
gist.github.com/melezhik/95b0778bd...edb7cde5a3
I wonder if this line of code confuses Rakudo? github.com/melezhik/Sparrow6/blob/...l.pm6#L143 16:57
my impression complain caused by method is named `foo-status`? 16:58
`handle-hook-status` status actually ...
sena_kun melezhik, can you please show the code?
m: sub foo-status {}; foo-status;
camelia ( no output )
melezhik already did - github.com/melezhik/Sparrow6/blob/...l.pm6#L143
oh, looks like it is here - github.com/melezhik/Sparrow6/blob/...n.pm6#L211 16:59
it's just trace from Rakudo does not show that ...
sena_kun melezhik, the name is kinda similar, so that's it confusing. the call to `status` you linked to was indeed deprecated 17:00
melezhik yeah, I see that now
what I am supposed to use instead?
sena_kun the exact same formula would be `($cmd.exitcode +< 8) +| $cmd.signal`, that's the implementation of the `status` method. 17:01
melezhik looks like in my case it'd be enough to have `.exitcode` instead .. 17:02
just because I use `status` like that - github.com/melezhik/Sparrow6/blob/...#L211-L213 17:03
sena_kun melezhik, could be, yes 17:04
lizmat I guess the bug is that the deprecation message is showing the wrong line number :-( 17:06
MasterDuke Xliff just mentioned getting some wrong line numbers as of recently over in #raku 17:07
melezhik lizmat - "I guess the bug is that the deprecation message is showing the wrong line number" that is correct 17:10
anyway my commit fixes the issue in Sparrow - github.com/melezhik/Sparrow6/commi...a801b467ac 17:11
but yeah, I guess if someone call `.status` from method named `foo-bar-status` it will produce wrong line number , and this is a bug
sena_kun melezhik, is hyphen at github.com/melezhik/Sparrow6/commi...856b86R194 correct? 17:12
17:17 Xliff left
melezhik upps, it's typo 17:19
thanks for pointing this out
17:52 sena_kun left 18:02 reportable6 left 18:05 reportable6 joined 18:29 [Coke]_ is now known as [Coke] 18:35 melezhik left
lizmat m: dd %(a => 42, b => 666) 20:10
camelia Hash % = {:a(42), :b(666)}
lizmat so, %() creates a mutable Hash
m: dd @(42,66)
camelia (42, 66)
lizmat yet @() creates an immutable list
I feel this is inconsistent: either %() should create a Map, or @() should create an Array 20:11
I'm leaning towards %() creating a Map, as we currently do not have syntactic sugar to create Maps and we *do* have { a => 42, b => 666 } to create Hashes 20:13
and [42,666] to create Arrays
japhb lizmat: What exactly is produced by `sub hash`? It's directly handing back the thing that was created by *%h, but what is that? 20:25
(IIRC it's decontainerized, but I don't know if it's a Hash with every key bound directly to a value, or a Map, or something else entirely.) 20:26
Also, it's not clear to me that hash(...named args...) and hash(...mixed positional and named args...) necessarily produce the same type out. 20:27
20:29 linkable6 left, evalable6 left
lizmat looking at the code, it slurps all positionals and all nameds and creates a Hash from that 20:29
20:31 linkable6 joined
lizmat re deprecation line numbers: yes, they appear meh 20:36
looks like it cannot handle the "is DEPRECATED" trait on a proto 20:43
afk& 20:47
21:39 patrickb left
Geth rakudo: 54f1b7a5f2 | (Elizabeth Mattijsen)++ | src/core.c/Proc.pm6
Fix location of Proc.status deprecation message

Apparently, putting an "is DEPRECATED" on a proto, breaks things. So move it to the candidates. This will at least fix the issue for now. Would be great if we could make "is DEPRECATED" work on protos as well.		 22:24
roast: 7c13d5d876 | (Elizabeth Mattijsen)++ | S02-types/isDEPRECATED.t
Add test for deprecation of Proc.status
 22:35
22:45 Xliff joined 22:48 casaca joined 23:16 casaca left 23:18 casaca joined 23:26 casaca left 23:27 casaca joined 23:30 evalable6 joined 23:31 casaca left 23:32 Xliff 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!