🦋 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: ... | Logs available at irclogs.raku.org/raku-dev/live.html | For MoarVM see #moarvm
Set by lizmat on 8 June 2022.
00:51 vrurg left 00:53 vrurg joined 00:56 vrurg left 01:03 vrurg joined 01:14 vrurg left 01:15 vrurg joined 01:21 vrurg left 01:23 vrurg joined 05:10 kjp left 05:11 kjp joined 05:13 kjp left 05:14 kjp joined 06:11 guifa left 06:16 guifa joined
patrickb ab5tract, timo: I believe Coleman is working on a new build system starting with Moar. Maybe based on Ninja or Meson? 06:23
07:28 donaldh- joined 07:30 donaldh left, guifa left 07:31 guifa joined 07:33 Voldenet left, Voldenet joined
[Coke] thought I saw an alert on an email from patrickb in the past 24h but now don't see it. Was I perhaps sleep-emailing at the time? :) 12:07
patrickb I do not recall sending you a mail... 12:08
[Coke] ok. thought maybe it was a github update on something. 12:14
I am now *kind of* back on my schedule, but not 100%. :) 12:15
Geth rakudo/main: 5341a3dff7 | (Elizabeth Mattijsen)++ | lib/RakuDoc/To/RakuDoc.rakumod
RakuAST: make RakuDoc::To::RakuDoc work on declarator docs

This should fix the case of:
   $ raku -MRakuDoc::To::RakuDoc -e 'say RakuDoc::To::RakuDoc.render("file".IO.slurp.AST)
This fix comprises of: ... (5 more lines)		 12:42
coleman I stopped working on the Meson build last summer. I still think it's a good idea, though 12:51
github.com/MoarVM/MoarVM/issues/1795 has links to some branches 12:53
Meson has patterns for config.h generation and other codegen stuff that requires running random scripts. 12:54
here's the root meson file I came up with github.com/dontlaugh/MoarVM/blob/m...eson.build 12:55
And (almost) every subdirectory will need its own. 12:56
ab5tract Each one needs its own? :( 14:14
16:13 kjp left 16:14 kjp joined
ab5tract I'm working on the JVM build process so that it can be converted to Kotlin and perhaps improved 16:56
but holy moly , this crap is complicated
crap = generated Makefile 16:57
lizmat ab5tract: one of the discussions we had at the RCS summit was about the benefits of an Inline::Java module, versus a JVM backend
the thought being that perhaps it would be better to spend effort on a fully functional Inline::Java module than on a JVM backend which e.g. misses NFG support 16:58
ab5tract Hmm... I guess I don't see how you can have one or the other
*without the other 16:59
lizmat well, we can use Inline::Perl5 without having a Perl backend? 17:00
ab5tract :O
how?
oh, sorry, I thought you meant without having libperl.so installed :)
I haven't looked at JNI recently but my understanding was that it was less fun than XS 17:02
lizmat but maybe better documented ?
ab5tract one would hope :)
how did the NativeCall conversations go? 17:06
there was some mentions of varargs support meaning that we could get away with not even writing the glue code, IIRC?
lizmat I wasn't really part of that discussion, perhaps nine / MasterDuke17 / patrickb can enlighten us 17:08
ab5tract This looks promising! blog.payara.fish/java-21-foreign-f...memory-api 17:09
Alright, I'm on board. One less moving piece to worry about. Though Inline::Kotlin > Inline::Java ;) 17:10
ugexe to play devils advocate here, the advantage of JVM backend is that raku then theoretically run anywhere the jvm does. with Inline::Java we do not get to say that 17:12
lizmat true, but the argument was also that non-Java users could benefit from access to the Java extensive library system (as long as the JVM runs on that architecture) 17:14
ab5tract ugexe: True. I guess ideally we could have both
but the JVM backend doesn't even really provide much interop with the Java ecosystem, IIRC 17:15
to me it's sort of hanging around as a perpetually-almost-finished thingy that can do more harm than good to first impressions
ugexe on the other hand if the jvm is always going to be a second class citizen (see aforementioned lack nfg support comment among other things) it isn't really fair to use those theoreticals as reasons to keep it around 17:16
ab5tract yeah, that's been my feeling on it for a while now 17:17
there's quite a bit more prior art for implementing a language on JVM that "feels native" than there was back in 2010 or whenever it was 17:18
lobste.rs/s/r0spkl/raku_s_core
I can invite anyone who wants to weigh in on the comment section
lizmat weekly: lobste.rs/s/r0spkl/raku_s_core 17:22
notable6 lizmat, Noted! (weekly)
Geth rakudo/main: 0eef26e188 | (Elizabeth Mattijsen)++ | src/Raku/ast/variable-declaration.rakumod
RakuAST: micro-opt for collecting RakuDoc from source

Prevent repeated lookups of $*RAKUDOC dynamic variable		 17:28
lizmat hmmm... did we bork --doc somehow? I can't get it to output anything? 17:37
raku lib/Test.rakumod --doc
I sorta expect something to show ?
[Coke] --doc first?
yah, it matters 17:38
(I am testing on 2025.04, no results if comes last)
lizmat aah.... hmmm
aah, duh
lizmat tries to restart her brain 17:39
yeah, otherwise it's just an argument to the raku program, instead of to raku itself 17:40
[Coke] my brain is only slightly more awake than yours, no worries 17:41
[Coke] checks and realizes he's drinking caffeine free soda. 17:42
oops
ab5tract hmm... can we be smart about this in the case that the file doesn't contain a MAIN?
it would maybe collide with someone doing manual processing of @*ARGS to find a `--doc` flag, but that feels a bit like DIHWIDT? 17:43
lizmat you can still handle your own @*ARGS without a MAIN
right
ab5tract or maybe we could some proxying logic to @*ARGS and emit a worry if an argument was passed but @*ARGS was not accessed in any way? 17:45
or maybe I'm overthinking :)
lizmat that would affect all argument parsing... 17:46
ab5tract yeah, but it's awkward that you can pass unsupported, unused arguments without complaint 17:48
anyway, it's a minor pain in the foot at best
lizmat although thinking about this, maybe an environment variable to force doc production may make more sense in that respect? 17:49
meh... dunno 17:50
ab5tract yeah.. the solutions are all a bit awkward compared to the scope of the problem (brains)
another option could be to disregard the before / after file name distinction for all `raku` supported flags but emit a worry saying it is better provided before any file name rather than after 17:52
dunno, though. the problem is that it is pretty annoying when you forget this, but probably not annoying enough to add a whole song and dance around it 17:54
[Coke] this feels like a DIHWIDT to me. 17:58
ab5tract [Coke]: which part? 18:02
usually when we can give some info back to the user that they may be in the process of repeatedly hurting themselves, we do so 18:03
[Coke] If I read it write, is the suggestion to have 'raku foo --doc' try to emit a helpful error? 18:04
"it right"
ab5tract I was brainstorming to see if there were any reasonable ways to do so. The conclusion so far is that no, there isn't 18:05
but DIHWIDT is not traditionally an indicator that "we shouldn't bother to help" 18:06
[Coke] ... did I say "we shouldn't bother to help"? 18:07
ab5tract I didn't say that you did
[Coke] ... ok, then I have no idea what conversation we're having now. 18:08
ab5tract maybe I interrupted your thought
[Coke] I will drop out and return
18:08 [Coke] left 18:30 librasteve_ joined
patrickb ab5tract: varargs support is sorted out. I only need to finish the implementation. (I'm obviously naive here.) 18:50
I was the strong proponent of Inline::Java. I fully realize that this is subjective and I do not want to discourage any effort to continue with our JVM backend. 18:52
But I do see the bigger benefits in Inline::Java compared to a JVM backend. But creating an Inline:: module from scratch is a huge amount of work. Because of that it is literally the last point on my personal Raku to-do list. 18:55
For anyone interested: boekernet.de/~patrick/finger.txt 18:56
ab5tract patrickb: :D 18:57
timo leont: i've got something that makes YAMLish not be as unhappy when run multiple times in parallel 19:13
leont Oooh 19:14
timo i don't exactly understand why it behaves that way only when run in parallel though
github.com/timo/yamlish/commit/19a...a0bdfeb610 with this commit i can run this without getting warnings about Nil in string context: rakudo -I . -MYAMLish -e 'my $input = "xt/data/config.yml".IO.slurp; await do for ^1000 { start say load-yaml $input }' 19:20
the {} in between the $<sp>=... and the stuff using it is load-bearing 19:21
but this only changes root-block and block, there's more places that do indent handling. i don't immediately have a good example yaml file to exercise those code paths though 19:22
i love that the first example yaml i downloaded wasn't parseable because it ended with `---` and either yamlish doesn't like that, or it might just actually be invalid yaml? 19:30
ab5tract m: my $role-how = Rational.HOW; my &floor = $role-how.find_method(Rational, "floor"); floor(1.5) # :( 20:58
camelia Invocant of method 'floor' must be an object instance of type
'Rational', not a type object of type 'Rational'. Did you forget a
'.new'?
in block <unit> at <tmp> line 1
coleman Unparsable yaml, what is this, Thursday? 21:29
22:12 rakkable__ left, rakkable 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!