🦋 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:50 coleman left, coleman joined 00:54 coleman left, coleman joined, coleman left 00:58 coleman joined 01:06 coleman left 01:07 coleman joined 07:45 sena_kun joined
ab5tract Currently dd on RakuAST calls deparse. This feels slightly contrary to the expectations that dd gives back the “nitty gritty” 07:53
Ahh… it’s probably arriving there via .raku, which does make sense to be calling deparse.. hmm 08:24
(All thoughts arriving from my phone, where it’s harder to properly verify these statements) 08:25
lizmat fwiw, dd checks specifically for RakuAST::Node 08:26
and then deparses
nine Well actually.... as quoted yesterday raku should "return a perlish representation of the object, so that calling EVAL on the returned string reproduces the object as accurately as possible". But EVALing the DEPARSE result does not result in those AST nodes getting re-created. It results in the result of running the Raku code.
lizmat the reason for it is that say of any RakuAST::Node class, will produce the RakuAST classes in a .raku style 08:27
having dd do that as well, felt sub-optimal
nine And dd being really just a debugging tool with no elaborate specs it can do just whatever it wants to :) 08:28
ab5tract That behavior of say is defined by what we currently do in RakuAST::Node.gist, IIUC 08:32
Anyway, not complaining or saying it’s wrong, only that I was a bit surprised :) 08:33
lizmat well, maybe the .gist should become .raku and vv
ab5tract it’s maybe a bit more aligned to expectations. for me at least the flow generally goes: “ah, ‘say $foo’ isn’t giving me all the info I need/expected. Let’s switch to ‘dd $foo’.” 08:39
Well, really I’m already using ‘dd’, but you get the idea ;) 08:40
It’s doesn’t come as naturally to think ‘dd is omitting details, let’s try say’ 08:41
But all of this begs a different question: if we are feeling iffy about including Q.AST, are we going to provide a different mechanism for converting expressions to RakuAST? 08:43
lizmat I think the consensus is that QAST us going to stay, as an intermediate to producing bytecode on different backends 08:44
*is
ab5tract Ah, I meant Q the quoting function :)
lizmat ahh oops
ok
well, maybe it should be renamed to .RakuAST but then we also have .IO which coerces to IO::Path 08:45
nine ab5tract: .AST is really just some sugar for running the compiler with :target<ast>
lizmat so...
ab5tract nine: it’s pretty tasty sugar though :) 08:46
nine For someone actively working on RakuAST itself yes. Is there really a case for this beeing appropriate huffmanization in general though? 08:47
ab5tract I shared it in #raku to a user who wants to create a signature with the same parameters as another signature and has been having some issues doing that via the OO interfaces 08:49
FWIW I could definitely see creating scaffolding via .AST in order to twiddle things around becoming a fairly standard interaction mode 08:51
Maybe it deserves a problem solving ticket though, to gather wider feedback.. 08:53
nine I'm all for making it easy to create ASTs, especially given that they will play a large role in macros. I just think that a method on Cool is the wrong place for it. Would you expect it to be there if it wasn't already? Would you look in the docs for Cool for something like this? 09:08
Also "any string can turn itself into an AST of code contained in this string" feels just off. Almost all strings will _not_ contain Raku code. Even if AST manipulation will become super common, compared to all other usages of strings using them for turning code into AST will still be exceptionally rare. 09:10
I think $*RAKU.compiler.to-ast($code) would still be nice enough 09:12
It still confuses me again and again that you can't actually use $*RAKU.compiler to...well....compile! 09:15
ab5tract Ah, as a method on Cool, no, that doesn’t really feel appropriate, no :) 09:18
But perhaps potentially as an adverb to Q? 09:20
Using $*RAKU.compiler also seems fine, but I would expect anything beyond light usage would immediately result in a wrapper sub :) 09:21
nine Which would be fine 09:22
ab5tract Sure! though it reminds me a bit of the situation surrounding &say in Perl 5. Still can’t enable it by default after all these years (but then again, that’s nothing next to some of their other things that can’t be enabled by default after all these years) 09:24
09:27 finanalyst joined
ab5tract Thanks for clarifying the situation with with .AST though. For some boneheaded reason I had assumed it was implemented via Q, not on the (super) class outputted by Q :) 09:28
09:29 sena_kun left 09:58 finanalyst left 10:02 quotable6 left, committable6 left, releasable6__ left, greppable6 left, evalable6 left, bisectable6 left, notable6 left, coverable6 left, tellable6 left, shareable6 left, benchable6 left, linkable6 left, nativecallable6 left, bloatable6 left, unicodable6 left, sourceable6 left 10:07 bisectable6 joined, unicodable6 joined, nativecallable6 joined, committable6 joined, coverable6 joined 10:08 sourceable6 joined, releasable6 joined, bloatable6 joined, tellable6 joined, evalable6 joined 10:09 linkable6 joined, shareable6 joined, quotable6 joined, greppable6 joined, benchable6 joined 10:10 notable6 joined
releasable6 Next release in ≈3 days and ≈7 hours. There are no known blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 11:00
ab5tract m: my %h; my $s = start { sleep 0.5; %h<555> }; my $p := $s.result; dd $p; $p = 42; dd %h 11:50
camelia Any
assign requires a concrete object (got a Any type object instead)
in block <unit> at <tmp> line 1
lizmat m: my %h; my $s = start { %h<555> }; my $p := $s.result; dd $p; $p = 42; dd % 11:51
camelia Any
assign requires a concrete object (got a Any type object instead)
in block <unit> at <tmp> line 1
lizmat you don't need the sleep, .result will block 11:52
ab5tract ah, good to know
is the loss of container-ship expected / desired?
lizmat m: my %h; my $s = Promise.start: -> is raw { %h<555> }; my $p := $s.result; dd $p; $p = 42; dd % 11:53
camelia ===SORRY!=== Error while compiling <tmp>
Invalid typename 'is' in parameter declaration.
at <tmp>:1
------> my %h; my $s = Promise.start: -> is⏏ raw { %h<555> }; my $p := $s.result; dd
ab5tract oh maybe with an anonymous sub
lizmat m: my %h; my $s = Promise.start: sub () is raw { %h<555> }; my $p := $s.result; dd $p; $p = 42; dd %
camelia Any
assign requires a concrete object (got a Any type object instead)
in block <unit> at <tmp> line 1
lizmat apparently not
ab5tract result would need to be marked is raw as well, I suspecgt 11:54
m: my %h; my $p := { %h<5> }(); $p = 42; dd %h 11:55
camelia {"5" => 42}
ab5tract so unless you need to mark a param is raw, a basic block should be fine 11:56
does `is raw` negatively impact performance? 11:57
lizmat well, on dispatch it might 12:00
ab5tract dang, speaking of dispatch... is there a way to "bind" callsame so that it doesn't unintentionally refer to the scope of another function call? 12:22
ie, in `multi f($whateva) { if $whateva { return start { callsame } } }`, start "swallows" the callsame 12:23
lizmat no idea off hand 12:24
ab5tract tried OUTER::<&callsame> but that didn't worl
lizmat: gotcha, thanks
(I did check the docs before asking :) ) 12:25
found it: docs.raku.org/syntax/nextcallee 12:35
lizmat ah, TIL you could use nextcallee for that :) 12:39
Geth rakudo/r4666: 5bd3ff3efb | ab5tract++ | lib/experimental.rakumod
First stab at a synchronized-cached
 12:41
lizmat ab5tract: why not use $lock.protect ? 12:42
ab5tract because I hadn't learned about nextcallee :D
that is, it was eating up the callsame 12:44
lizmat isn't the point of a threadsafe cache that you can access it from multiple threads? 12:45
ab5tract which part isn't allowing that? 12:49
lizmat I wonder what the point is of the start { } in there 12:50
starting a job for each value seems... overkil?
ab5tract so that the next caller isn't blocked on reading a (maybe already returned) value
otherwise every read is blocked while the cache is filled 12:51
s/returned/cached/ 12:52
nine This also increases the overhead of the cache. 12:53
Have you considered a copy on write solution?
ab5tract no, I hadn't 12:54
nine Would give advantages *if* writes are rare compared to reads 12:55
ab5tract the blocking of cached reads occurre to me while I was out on a walk and this seemed like a Raku-ish solution
lizmat also: start is pretty expensive 12:56
ab5tract I'll take a look later today :)
lizmat: I get that
but the whole point of is cached is that the call itself is expensive 12:57
nine That's the problem with a generic "is cached" solution. We have no idea about the actual use case, so we must not make any assumptions.
ab5tract so blocking cached reads feels super suboptimal
note I also made this a different trait :)
afk& 12:59
nine Considering how trivial it is to add adhoc-caching, is it even worth it to provide this as a builtin? We cannot know which trade-offs to pick. We also have no cache expiry.
lizmat yeah, the alternative could well be to remove this feature (in its current state) entirely into the ecosystem
and remove it from core: it *has* been experimental 13:00
either that, or make it threadsafe, document the behaviour re the key construction, and and no cache expiry, and put it in core 13:01
[Coke] +1 for removing the experimental feature. 13:30
ab5tract even if we want to punt it to the ecosystem, core probably needs to either ensure that unordered collections do a sort on their contents when .raku is generated or else provide some other usable caching key 14:01
lizmat agree on that 14:03
nine Thing is that neither .raku nor .gist nor .Str were meant to produce stable identifiers. They just incidentally kinda work mostly for that. 14:04
lizmat well, I'd say .raku (if sorted for Associatives) would work for 99.9% of cases as a stable identifier key 14:05
nine On the other hand do they really? my @a = <1 2 3>; my @b = <1 2 3>; some-caching-func(@a); some-caching-func(@b); # should @a and @b considered to be the same even though they are different non-value objects? I argue that depends on some-caching-func. Again it cannot really be decided a priori 14:06
lizmat fwiw, I'd worry more about thread-safety
nine Which in many cases won't be an issue at all 14:10
lizmat I seem to recall at least one issue about thread-safety and is-cached 14:12
ab5tract nine: that's fair, but if core doesn't give a cache implementor the option to consider them the same, then we've already made the choice for them 14:16
without causing a great deal more work on their side relative to a few sorts on the core side, at least
nine How comes? They are still free to write their own fit for purpose cache key generator. Even a somewhat generic one. 14:17
You assume that a few sorts are all that's needed and then we're good. I'm not sure that's really the case. And even if, that still includes hidden assumptions that may just not hold. 14:18
It also assumes that there's no downside to adding these sorts. 14:19
ab5tract "They are still free to write their own fit for purpose cache key generator." --> that's the great deal of work I was talking about :) 14:42
anyway, given those caveats you've mentioned it is clear that there is no place for `is cached` in core 14:43
lizmat still, moving it into core and making "use experimental :cache" a noop, would have one big advantage 14:58
no broken code in the ecosystem / darkpan
ab5tract true, it would at the very least need deprecation 14:59
lizmat if not moved to core, indeed 15:00
ab5tract but even fixing it to use raku instead of gist is a) controversial, b) could "break" code by changing its behavior (even if that behavior is more correct)
R#5197 --> I think it's long past time to drop the pretence of there being a genuine JVM backend. That definitely deserves a problem solving ticket though 15:10
linkable6 R#5197 [open]: github.com/rakudo/rakudo/issues/5197 [JVM] zef does not compile for rakudo jvm, 2022.12
lizmat 6120b009e3304bf93b4 15:20
linkable6 (2015-08-28) github.com/rakudo/rakudo/commit/6120b009e3 strict is now on by default, even for -e
ab5tract just opened my first problem-solving ticket about that very topic :) 15:40
I genuinely would never in a hundred years have guessed that this would happen :) 15:41
16:17 finanalyst joined 17:50 sena_kun joined 18:11 coleman left 18:12 coleman joined 18:18 samebchase joined
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2024/05/27/2024-...-incoming/ 18:32
ab5tract lizmat++ 19:24
gfldex .o(week++ lizmat++) 19:26
Geth rakudo/main: de12a755f3 | ab5tract++ | 3 files
RakuAST: Add test for using a shadowed package

This was failing in base:
   > use Foo::Bar;
   > use Foo;
   > Foo.new
but works as expected in RakuAST. Adding a test in order to prevent regression. R#1690 (#1690)		 21:18
linkable6 R#1690 [open]: github.com/rakudo/rakudo/issues/1690 [tests needed][REPL][Fixed in RakuAST] REPL messes up namespaces when Foo is `use`d after Foo::Bar
Geth rakudo/main: 5fb665ba27 | ab5tract++ | t/12-rakuast/xx-fixed-in-rakuast.rakutest
Bump test plan in xx-fixed-in-rakuast.rakutest
 21:20
roast: f93a66780f | ab5tract++ | 2 files
Add tests for no trailing zeros via Rat.Str and Rat.gist

This closes R#1818.		 21:41
21:41 finanalyst left
linkable6 R#1818 [open]: github.com/rakudo/rakudo/issues/1818 [tests needed][rationals][stringification] Stringified Rat has traling zeros 21:41
Geth roast: 8642114ba6 | ab5tract++ | 2 files
Revert "Add tests for no trailing zeros via Rat.Str and Rat.gist"

Unfortunately some extraneous tests leaked into this commit.
This reverts commit f93a66780f01a31b6792b5c8315a51c0f07721ea.		 21:43
roast: ee596d801f | ab5tract++ | S32-num/rat.t
Add tests for no trailing zeros via Rat.Str and Rat.gist

This closes R#1818.		 21:44
linkable6 R#1818 [open]: github.com/rakudo/rakudo/issues/1818 [tests needed][rationals][stringification] Stringified Rat has trailing zeros
[Coke] if you use the full URL in the roast commit message, it would close the rakudo ticket automatically. 21:45
also: Neat! 21:46
Geth roast: 3078dc2364 | ab5tract++ | 3 files
Add test for .pm shadowing .rakumod of the same name

If `Shadow.pm` and `Shadow.rakumod` live in the same directory, we should (and do) load the rakumod file.
This closes R#3783.		 22:11
linkable6 R#3783 [open]: github.com/rakudo/rakudo/issues/3783 [tests needed] Raku loads Perl modules first when Raku modules have the same base name
ab5tract [Coke]: ah, will put the url in the next one :) 22:12
ugexe hmm, we should follow the idiomatic distribution convention of putting module files in a lib folder, especially when it doesn't contain a META6.json in the root 22:19
ab5tract not to disagree, but why? 22:20
ugexe I converted all(?) the roast packages to follow that some time ago. the reasons to do so are primarily because when a library path does not contain a META6.json rakudo has to make some assumptions about what the module names are called, where an e.g. resources/ might be located, etc 22:21
ab5tract in that case I have to append a `/lib` to the path passed to use lib
which seems like a no-op
ugexe it is not
ab5tract I mean, I can take you word for it but I would rather understand why 22:23
Geth roast: d909f834c2 | ab5tract++ | 3 files
Migrate packages/R3783/* to packages/R3783/lib/*
 22:25
ugexe github.com/rakudo/rakudo/blob/5fb6...#L180-L185 22:26
in your specific case it is indeed fine, but generally one should use the more conventional naming pattern to avoid the issue mentioned there. and since people will copy what they see in the roast (or use it as a base for making their own roast contributions) we should try to follow the best practices we currently have 22:28
ab5tract ugexe: got it, thanks
ugexe i think you didn't commit the renamed files in that last commit 22:29
ab5tract damnit :)
Geth roast: 52f7b0002a | ab5tract++ | 2 files
Don't forget the renamed modules (ugexe++)
ab5tract ugexe: the only thing I'm struggling with in that comment is that it specifies `use lib 'packages'` .. but my experience demonstrates that for the well-formed case, that needs to be `use lib 'packages/lib'` 22:30
but probably I'm missing something, as often happens 22:31
ugexe gist.github.com/ugexe/b43dbb651d2a...a7ca80831e 22:40
the first example is a distribution that isn't using a lib/ directory 22:41
it lists no resources, and the provides relative path is seemingly not correct 22:42
To give a more contrived example, if you had a user with `/home/user1/mymodule.rakumod` and tried to `use lib '/home/user1'`, it would look for resource files for `%?RESOURCES`/`$?DISTRIBUTION` in `/home/resources` which is obviously not great. 22:55
23:06 sena_kun left
Geth roast: 36dadc1753 | ab5tract++ | S32-io/spurt.t
Add test for spurt failures

This addresses R#4619. While that ticket focuses on permissions, I've taken the approach of generating a failure purely based on trying to spurt a file into a non-existent path.
This feels much less fiddly than what it takes to do a permissions- specific test (checking for UID 0 and fudging a dummy test if so, which ignores Windows and also isn't comprehensive).
  (github.com/rakudo/rakudo/issues/4619)		 23:11
linkable6 R#4619 [open]: github.com/rakudo/rakudo/issues/4619 [tests needed] spurt-string throws Failure
ab5tract ugexe: thanks for the clarification, that makes sense to me
that'll be all from me tonight 23:13

Powered by Cro and the Raku® Programming Language.

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

Thank you!