šŸ¦‹ 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.
08:04 samebchase left 08:22 finanalyst joined 09:48 sena_kun joined 09:49 finanalyst left
Geth rakudo/main: 23b94de650 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/core.c/Any-iterable-methods.rakumod
Introduce Any.are(type --> Bool:D)

This would allow a shorter way to say:
   sub a(@a where .are ~~ Int) { }
namely: ... (11 more lines)		 10:17
ab5tract lizmat++ 10:29
m: for "some\nlines".lines -> $_ is raw { $_ ~= "EXTRA"; say $_ } 10:51
camelia Cannot assign to an immutable value
in block <unit> at <tmp> line 1
lizmat a line from a string with lines is a Str without container 10:52
making $_ is raw doesn't change that
m: for "some\nlines".lines -> $_ is sopy { $_ ~= "EXTRA"; say $_ }
camelia ===SORRY!=== Error while compiling <tmp>
Can't use unknown trait 'is' -> 'sopy' in a parameter declaration.
at <tmp>:1
expecting any of:
rw
readonly
copy
required
raw
leading_ā€¦
lizmat m: for "some\nlines".lines -> $_ is copy { $_ ~= "EXTRA"; say $_ }
camelia someEXTRA
linesEXTRA
ab5tract ahh
there we go
that was the question I was typing out
lizmat read your mind :-) 10:53
ab5tract makes total sense, of course
geez, RakuAST is so freaking lovely 10:54
lizmat reading your mind? :-)
ab5tract that too :)
Geth rakudo/main: f17cd58f3d | ab5tract++ (committed using GitHub Web editor) | src/core.c/Parameter.rakumod
Add :invocant option to Parameter.new

Previously a user would be required to `use nqp` in order to get access to the `nqp::const::SIG_ELEM_INVOCANT` constant and manually twiddle that flags being provided to the `Parameter` constructor.		 11:03
rakudo/main: a690eeccb5 | ab5tract++ | src/Raku/Actions.nqp
Maintain the entire list of package names in Nodify

The previous approach would provide incomplete failure messages:
   Nodify('NotFound')
   # No such node RakuAST::
... (8 more lines)		 11:05
lizmat ab5tract++ 11:07
Geth rakudo/r1915: c382350bef | ab5tract++ | src/Raku/Actions.nqp
RakuAST: Add -n and -p compiler options

Once again RakuAST proves itself by making the implementation of this feature dead-simple while also fixing a long-standing bug.
From R#1915 (#1915):
... (7 more lines)		 11:14
linkable6 R#1915 [open]: github.com/rakudo/rakudo/issues/1915 [LTA] LTA error message when using ${_}
ab5tract now to figure out how to actually test this :) 11:15
11:17 samcv left
Geth rakudo: ab5tract++ created pull request #5581:
RakuAST: Add -n and -p compiler options		 11:18
nine patrickb: finally managed to concentrate enough to give you an answer :) Sorry for the delay 11:30
ab5tract: that PR of yours makes me wonder how -n and -p are implemented in the old frontend. Do I even want to look? :D 11:31
ab5tract probably not :)
As usual, there's a fair amount of indirection with and of course our good friend `make_topic_block_ref` makes an appearance 11:33
honestly it's not the most gruesome of base examples, but in terms of actually resolving the bug? that's where the sausage factory lives
Geth rakudo/r1590: 81c7064ba7 | ab5tract++ | 3 files
Provide deeper context into `run` failures

After 92bd7e4, we stopped returning an exit code of `-1` for cases when attempting to `run` a nonexistent command.
This patch returns the previous behavior while also surfacing the underlying error from `libuv`, which makes it much more ... (10 more lines)		 11:57
ab5tract nine: adding the error code to the callback was indeed easy :) 12:00
Geth rakudo/main: c021e6889c | (Elizabeth Mattijsen)++ | src/core.c/Any-iterable-methods.rakumod
Also handle type.Int(type) in 6.e

Spotted while writing tests		 12:10
roast: 103a9f4a11 | (Elizabeth Mattijsen)++ | S29-any/are.t
Add tests for .are(type)
 12:11
rakudo/r1915: 4ac06e5da4 | ab5tract++ | src/Raku/Actions.nqp
RakuAST: Add -n and -p compiler options

Once again RakuAST proves itself by making the implementation of this feature dead-simple while also fixing a long-standing bug.
From R#1915 (#1915):
... (7 more lines)		 12:24
linkable6 R#1915 [open]: github.com/rakudo/rakudo/issues/1915 [LTA][Fixed in RakuAST] LTA error message when using ${_} 12:25
rakudo/r1915: a61a0dd7ea | ab5tract++ | 2 files
RakuAST: Add -n and -p compiler options

Once again RakuAST proves itself by making the implementation of this feature dead-simple while also fixing a long-standing bug.
From R#1915 (#1915):
... (7 more lines)		 12:51
linkable6 R#1915 [open]: github.com/rakudo/rakudo/issues/1915 [LTA][Fixed in RakuAST] LTA error message when using ${_}
rakudo/main: 53eebb7c58 | ab5tract++ | 2 files
RakuAST: Add -n and -p compiler options

Once again RakuAST proves itself by making the implementation of this feature dead-simple while also fixing a long-standing bug.
From R#1915 (#1915):
... (7 more lines)
rakudo/main: aca5e4c129 | ab5tract++ | 3 files
Provide deeper context into `run` failures

After 92bd7e4, we stopped returning an exit code of `-1` for cases when attempting to `run` a nonexistent command.
This patch returns the previous behavior while also surfacing the underlying error from `libuv`, which makes it much more ... (10 more lines)		 12:57
nqp/main: d8a7e5c440 | ab5tract++ | tools/templates/MOAR_REVISION
Bump MoarVM
 13:06
nqp/main: 3003541701 | ab5tract++ | tools/templates/MOAR_REVISION
Bump MoarVM

Includes the return of error codes from failed proc runs via the error handling callback.
rakudo/main: 1ace350e08 | ab5tract++ | tools/templates/NQP_REVISION
Bump NQP to bump MoarVM

Moar now provides the error codes for failed proc runs by passing it into the error handling callback declared in Proc::Async.		 13:08
ab5tract hmm, looks like a transient bump was included in the nqp push... my bad :/ 13:09
Geth roast: 3805504e59 | ab5tract++ | S29-os/system.t
Cover run's exception when passed a non-existent command

This address R#1590 and should prevent future regressions.
Obviously if you are working on `run()` or `Proc` related features and you are adjusting the exception text to be even more accurate, do not hesitate to change this test again. It's only here to prevent regressions, not improvements.		 14:04
linkable6 R#1590 [open]: github.com/rakudo/rakudo/issues/1590 [tests needed][regression][severe][procs] Procs should not get back with ā€œexit code: 1ā€ if the program does not exist at all
ab5tract nine: any particular reason that R#5578 has been left all on its lonesome? :) 14:21
linkable6 R#5578 [open]: github.com/rakudo/rakudo/pull/5578 Allow reduce to return containers as generated
nine No. Approved it 14:45
Geth rakudo/main: ecd7580993 | ab5tract++ | 2 files
Allow reduce to return containers as generated

As pointed out in R#2000 (#2000), using `reduce` on a list that includes a container was losing all knowledge of this container.
The following would previously fail: ... (19 more lines)		 14:48
linkable6 R#2000 [open]: github.com/rakudo/rakudo/issues/2000 [data types][metaop] `reduce` needlessly deconts
releasable6__ Next release in ā‰ˆ4 days and ā‰ˆ3 hours. There are no known blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 15:00
Geth roast: 8c34c67aac | ab5tract++ | S32-list/reduce.t
Test for reduce with `is raw`

Containers are now returned when reduce is provided with callables that utilize `is raw`.
This resolves R#2000.		 15:01
linkable6 R#2000 [open]: github.com/rakudo/rakudo/issues/2000 [data types][metaop] `reduce` needlessly deconts
Geth Ā¦ rakudo: ab5tract self-assigned feed operator does not recognise sub-form of method calls github.com/rakudo/rakudo/issues/4991 15:15
rakudo/main: cd74aa79a0 | ab5tract++ | t/12-rakuast/xx-fixed-in-rakuast.rakutest
Add test for andthen chaining with WhateverCodes

This tests the behavior described in R#5004 (#5004).
Note that the product of `problems(16)` is non-deterministic. However, since this test only relies on knowing that the expression lived ok, this is not actually an issue.		 15:26
linkable6 R#5004 [open]: github.com/rakudo/rakudo/issues/5004 [Fixed in RakuAST] Bad variable resolution inside WhateverCode in an andthen chain
ab5tract so, if we actually consider the 'Fixed in RakuAST' tests to be "closed", then we are below 1300 open issues :D \o/ 15:28
nine nice :) 16:05
lizmat kudos! 16:20
ab5tract re: R#4666 ... do we avoid sorting in Set.gist exclusively for performance reasons? or, maybe a more pertinent question: are we planning to move forward with using `.gist` as the basis for caching? 16:39
linkable6 R#4666 [open]: github.com/rakudo/rakudo/issues/4666 is cached sometimes fails to cache invocations with hash-like arguments.
ab5tract there's probably also an argument against sort based solely on disabusing users of any expectations towards stable ordering 16:42
nine Wait.... .gist as basis for caching? How? gist has always been meant for human consumption and it often doesn't even show the whole data 16:49
ab5tract github.com/rakudo/rakudo/blob/cd74...akumod#L11 16:54
so, maybe I'm an evil genius or maybe I'm simply mad... but changing that hash to `my %cache{Capture}` seems to DWIM :) 16:55
nine Well that comes from a commit quite aptly called "Naively implement "is cached" on Routines" from 2014 and hasn't really been updated since 16:58
ab5tract apparently so :) 17:00
nine Wait, that's actually wrong. Initially it used .WHICH but was changed to .gist in commit 07dcb22d6c3a611ac71441a0be4abe96b8413bf4
"Use .perl instead of .WHICH on Capture as key" "Suggested by masak++. This will however cause cache misses for named parameters as the keys in Hash.perl are not sorted. Perhaps they should be? Even though it is not necessary for roundtripping per se, SortKeys *is* one of the features I always used to switch on on Perl 5's Data::Dumpern when debugging." 17:01
Sadly this does not give any indication for why .WHICH wasn't good. lizmat: Remember what the problem was? It's only been 10 years since :D 17:02
ab5tract I've been assuming that it didn't use WHICH because then `my $a = set <a b c>` and `my $b = set <a b c>` would be cached separately 17:06
unfortunately that sort of causes the same issue when using `cache{Capture}` 17:09
nine "Marks a subroutine as being memoized, or at least memoizable. In the abstract, this cache is just a hash where incoming argument Captures are mapped to return values. If the Capture is found in the hash, the return value need not be recalculated. If you use this trait, the compiler will assume two things: 17:12
A given Capture would always calculate the same return value. That is, there is no state hidden within the dynamic scope of the call.
The cache lookup is likely to be more efficient than recalculating the value in at least some cases, because either most uncached calls would be slower (and reduce throughput), or you're trying to avoid a significant number of pathological cases that are unacceptably slow (and increase latency)."
Unfortunately this also doesn't really tell us how the cache key was intended to be calculated. 17:13
ab5tract Well, at least `.raku` is probably more appropriate than `.gist` .. we fall through to this in `eqv`, IIUC 17:14
nine .gist can't be the answer as it's for human consumption and will e.g. include all values of a long list 17:15
ab5tract yeah, hmm
nine .Str has ambiguous output, e.g. <a b c> vs <<a "b c">>
So .raku seems to be the top contender
ab5tract however, if .raku doesn't include all the values of a long list, then it might create keys that match for more than one Capture, right? 17:16
thorny problem :) 17:17
presumably you start to lose the efficiency of caching really quickly if you resort to keeping a list and calling first with a smartmatch on it 17:18
nine But .raku definitely should include all values. It's purpose is to "return a perlish representation of the object, so that calling EVAL on the returned string reproduces the object as accurately as possible." 17:19
ab5tract ah, ok. I must have misinterpreted your comment about .gist and long lists 17:20
nine gist bad, raku good :)
ab5tract then I guess the last missing puzzle piece for raku is: do we add sorting to unordered collections just to satisfy this experimental caching? 17:21
*sorting to .raku on unordered collections
nine Interestingly we already do sort on Maps and thus Hashes 17:22
ab5tract wild! TIL 17:23
nine And we sort in Setty.gist but not in .Str or .raku
I doubt there's a system there
ab5tract ah, that's weird... Capture.gist would call Setty.gist, it contained a set, right? but then 17:28
the code in the github issue should actually work ...
lizmat I think the implementation of is cached predates ValuObjAt 18:03
and that was the reason .WHICH didn't make any sense
nowadays I guess one could introspect the .WHICH of value types
in any case, "is cached" is not threadsafe 18:04
[Coke] I wouldn't expect we'd be able to cache with gist since it's by definition not the full data all the time. 18:07
lizmat m: sub a(|c) { say c; say c.WHICH }; a 1,2,3 18:20
camelia \(1, 2, 3)
Capture|(Int|1)(Int|2)(Int|3)
lizmat I guess nowadays I would think .WHICH *would* be the best choice
sub a(|c) { say c; say c.WHICH }; a 1,2,3, Date.today'
m: sub a(|c) { say c; say c.WHICH }; a 1,2,3, Blob.new(1,2,3) 18:21
camelia \(1, 2, 3, Blob.new(1,2,3))
Capture|(Int|1)(Int|2)(Int|3)(Blob|7037807198C22A7D2B0807371D763779A84FDFCF)
lizmat m: sub a(|c) { say c; say c.WHICH }; a 1,2,3, Blob.new(1,2,4)
camelia \(1, 2, 3, Blob.new(1,2,4))
Capture|(Int|1)(Int|2)(Int|3)(Blob|AB7911513DEBC7015AD50429A8159771458B24CE)
lizmat aaah... I know the reason; 18:27
m: sub a(|c) { say c; say c.WHICH }; my @b = 1,2,3; a @b
camelia \([1, 2, 3])
Capture|(Array|5008854635240)
lizmat *that*'s why .gist was being used 18:28
m: sub a(|c) { say c; say c.WHICH }; a 1,2e0,3 18:31
camelia \(1, 2e0, 3)
Capture|(Int|1)(Num|2)(Int|3)
lizmat m: sub a(|c) { say c; say c.WHICH }; a 1,2/1,3
camelia \(1, 2.0, 3)
Capture|(Int|1)(Rat|2/1)(Int|3)
ab5tract m: sub a(|c) { say c; say c.WHICH }; my @b = 1,2,3; a @b; a my @c = 1,2,3; 18:35
camelia \([1, 2, 3])
Capture|(Array|4205024385712)
\([1, 2, 3])
Capture|(Array|4204923602656)
ab5tract because it would create two cache entries in this case, right? 18:36
lizmat right 18:37
you would have to look into Positionals, get the .WHICH of each element (potentially recursively)
also for Associatives 18:38
and %_
ab5tract m: sub a(|c) { say c; say c.WHICH }; my $a = set <a z r v x>; a($a) xx 4; 18:39
camelia \(Set.new("x","z","r","v","a"))
Capture|(Scalar|2793189052704)
\(Set.new("x","z","r","v","a"))
Capture|(Scalar|2793189052704)
\(Set.new("x","z","r","v","a"))
Capture|(Scalar|2793189052704)
\(Set.new("x","z","r","v","a"))
Capture|(Scalar|ā€¦
ab5tract m: sub a(|c) { say c; }; my $a = set <a z r v x>; a($a) xx 4; 18:40
camelia \(Set.new("x","a","z","v","r"))
\(Set.new("x","a","z","v","r"))
\(Set.new("x","a","z","v","r"))
\(Set.new("x","a","z","v","r"))
lizmat m: sub a(|c) { say c.WHICH; }; my $a = set <a z r v x>; a($a) xx 4;
camelia Capture|(Scalar|3630406314496)
Capture|(Scalar|3630406314496)
Capture|(Scalar|3630406314496)
Capture|(Scalar|3630406314496)
lizmat m: sub a(|c) { say c.WHICH; }; my $a := set <a z r v x>; a($a) xx 4; 18:41
camelia Capture|(Set|FAC542F2B0E327C881C5BDC6F6FDD9B0AC03DBB3)
Capture|(Set|FAC542F2B0E327C881C5BDC6F6FDD9B0AC03DBB3)
Capture|(Set|FAC542F2B0E327C881C5BDC6F6FDD9B0AC03DBB3)
Capture|(Set|FAC542F2B0E327C881C5BDC6F6FDD9B0AC03DBB3)
ab5tract m: use experimental :cache; sub a($s) is cached { say $s; }; my $a = set <a z r v>; a($a) xx 44;
camelia ===SORRY!=== Error while compiling <tmp>
Error while importing from 'experimental': no such tag 'cache'
at <tmp>:1
------> use experimental :cacheā; sub a($s) is cached { say $s; }; my $a
ab5tract m: use experimental :cached; sub a($s) is cached { say $s; }; my $a = set <a z r v>; a($a) xx 44; 18:42
camelia Set(a r v z)
ab5tract so weird.. locally I get multiple orderings, just like in R#4666
linkable6 R#4666 [open]: github.com/rakudo/rakudo/issues/4666 is cached sometimes fails to cache invocations with hash-like arguments.
lizmat anyways, I think the correct approach would be: 18:43
drill down Positionals and Associatives
if any value is not an ObjValueAt, then stop trying to cache
create a key and add a lock for thread-safety 18:44
and rewrite using nqp :-)
ab5tract ugh
lizmat well, "is cached" is an optimization
ab5tract agreed 18:45
lizmat so deciding it is too much trouble to create a key somewhere, is also valid
ab5tract m: use experimental :cached; sub a($s) is cached { say $s; }; a(<a z r v>.Set) xx 44; 18:47
camelia Set(a r v z)
Set(a r v z)
Set(a r v z)
Set(a r v z)
Set(a r v z)
Set(a r v z)
Set(a r v z)
Set(a r v z)
Set(a r v z)
Set(a r v z)
Set(a r v z)
Set(a r v z)
Set(a r v z)
Set(a r v z)
Set(a r v z)
Set(a r v z)
Set(a r v zā€¦
ab5tract that was unexpected :)
18:49 finanalyst joined
ab5tract evalable6: gist.githubusercontent.com/ab5trac...r4666.raku 18:59
evalable6 ab5tract, Successfully fetched the code from the provided URL
not cached: 2 3 1
Saw 1 occurrence of deprecateā€¦
ab5tract, Full output: gist.github.com/cb2d292e232f158d5a...585819ec63
19:01 sena_kun left 19:02 sena_kun joined
lizmat meh looks like Github is having issues 19:18
19:31 finanalyst left
ab5tract trying again: 19:35
m: gist.githubusercontent.com/ab5trac...r4666.raku
camelia ===SORRY!=== Error while compiling <tmp>
Confused
at <tmp>:1
------> https:ā//gist.githubusercontent.com/ab5tract/10
expecting any of:
colon pair
ab5tract evalable6: gist.githubusercontent.com/ab5trac...r4666.raku
evalable6 ab5tract, Successfully fetched the code from the provided URL
not cached: 3 1 2
Saw 1 occurrence of deprecateā€¦
ab5tract, Full output: gist.github.com/523921d71054bf84e2...449ff13aca
ab5tract šŸ¤· 19:36
Geth rakudo/r4666: b02dc31bc2 | ab5tract++ | 3 files
Provide some fixups to experimental :cached

Addresses R#4666 (#4666), the discussion of which raised several issues with the previous `is cached` implementation:
  - `.gist` is not appropriate as details may be truncated,
... (10 more lines)		 20:18
linkable6 R#4666 [open]: github.com/rakudo/rakudo/issues/4666 is cached sometimes fails to cache invocations with hash-like arguments.
rakudo: ab5tract++ created pull request #5582:
Provide some fixups to experimental :cached
ab5tract I don't imagine that it's actually possible, but it would be pretty nice to be able to only use a lock when actually necessary 20:30
ie, not pay their price in single-threaded code. though I guess the cost is reduced when there is no contention... 20:31
lizmat indeed... the overhead is pretty minimal when single threaded 20:39
ab5tract lizmat: from the commit message - "Additionally, Setty.raku and Baggy.raku have been adjusted to produce sorted contents." 20:42
otherwise there will be cache misses for these unordered collections
lizmat ah... ok... hmmm
ab5tract Hash.raku already does this 20:43
20:49 hankache joined
ab5tract I considered doing the recursive checking of the capture elements, but it would end up looking almost exactly like calling `.raku`, since the goal would be to end up with a unique identifier for values :) 20:54
21:17 hankache left
Geth Ā¦ rakudo: ab5tract self-assigned Inconsistencies when defining postcircumfix operators github.com/rakudo/rakudo/issues/4722 22:25
23:09 sena_kun 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!