🦋 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:55 sena_kun joined
ab5tract Should we do a similar cleanup in RakuAST? github.com/Raku/doc/pull/4397 10:13
(Curry -> prime)
lizmat probably 10:22
% rak curry -i ../../rakudo/ast --count-only 10:23
82 matches in 3 files
ab5tract That can wait for the new branch to be merged though, for sure 10:41
lizmat indeed... :-)
ab5tract nine: it's really strange.. I can't reproduce the CI issues locally 12:04
looks like `t/09-moar/00-misc.t` is failing at `Subtest: no SPESH crashes with duplicate `use Test``, but I see the same issue in `nqp` results for current main (dev.azure.com/jjmerelo0004/f5d947e.../logs/145) 12:07
Geth nqp/main: 808f0c367c | ab5tract++ | src/core/Hash.nqp
Add a few capabilities for NQP-level dd

Now we check for dump-ability and then ast-ness before going into the more specific checks.
Also, in the generic fallthrough case, we check for
  `gist` before using `Str` / ~.		 12:40
ab5tract is not making heads or tails of the CI situation :( 14:12
ugexe i think the moarvm CI relies on some existing version of nqp or some such 14:15
the failure seems the same across a few different runs 14:16
MoarVM panic: Memory allocation failed; could not allocate 2109040673 bytes
t\nqp/115-nums.t .......................
Dubious, test returned 1 (wstat 256, 0x100)
i guess that can't be the case since the CI is failing in multiple repos and not just moarvm 14:24
looking at the moarvm CI statuses, my guess would be github.com/MoarVM/MoarVM/commit/62...3582f7d78b is causing it
MasterDuke: ^ could those changes potentially cause that allocation error that is shown? 14:25
to be clear i'm talking specifically about windows failures 14:27
ab5tract indeed, the Mac and (occasionally Linux) failures appear to be consistently different 14:29
14:38 finanalyst joined
ugexe ah i see, those platforms are running into the SPESH crash you mention earlier 14:39
in these situations when i have sufficient motivation I generally start pushing up commits to rakudo, nqp, etc that build with older e.g. moarvm commits. once a commit is found where the failure stop, it is probably safe to assume it has been correctly manually bisected 14:41
the number of commits that have to be checked could also probably be reduced by only initially checking commits that contain a moarvm bump 14:42
ab5tract hmmm.. 14:48
with (maybe) give that a try .. hardly the most exciting work that can be done, though 14:50
especially since the failure doesn't happen locally :/
but ugexe++ thanks for the suggestion 14:52
ugexe hmmm 14:59
dev.azure.com/jjmerelo0004/jjmerel...amp;l=1475
those 0*-misc.t tests all have `use lib <t/packages>`, which would have a 'Test' namespace 15:00
like i wonder if that spesh failure would happen with some module other than Test
i'm gonna make a PR to fix up our use of t/packages to be more precise, which may or may not help 15:01
lizmat ugexe: fwiw, I think that many of the libraries in t/packages should just be part of Test 15:02
ugexe i dont think we should add or remove things from Test api until we have a way to properly version and depend on certain versions of core modules 15:03
additionally imo there is too much nuance in Test::Helpers to be something to provide in the core 15:07
Geth rakudo/ugexe/restructure-t-packages: 012cbf6267 | (Nick Logan)++ | 36 files
Restructure Test::Helpers

Previously packages were using the `t/packages` library path which would be seen as a distribution containing other unrelated modules. This commit restructures the file layout of Test::Helpers to match what an actual distribution would use, and then updating our tests to point at the new location. This ensures code using Test::Helpers doesn't inadvertantly have access to other modules in t/packages, and potentially avoids an issue when packages were using a sub directory t/packages/02-rakudo which would already have otherwise been precompiled from loading t/packages.		 15:43
rakudo/r1378: 897a93ccb9 | ab5tract++ | 2 files
Provide better feedback for ambiguous adverb usage

This fixes an LTA situation:
   > my %h = :1k; say 1 ~ %h<k>:exists ~ 1
   ===SORRY!===
   MVMArray: Can't pop from an empty array
... (10 more lines)		 15:46
rakudo: ab5tract++ created pull request #5572:
Provide better feedback for ambiguous adverb usage
rakudo/r1378: 3233f2a5a6 | ab5tract++ | 2 files
Provide better feedback for ambiguous adverb usage

This fixes an LTA situation:
   > my %h = :1k; say 1 ~ %h<k>:exists ~ 1
   ===SORRY!===
   MVMArray: Can't pop from an empty array
... (10 more lines)		 15:47
nqp/r1378: ff157a4f8e | ab5tract++ | src/HLL/Grammar.nqp
Provide better feedback for ambiguous adverb usage

This fixes an LTA situation:
   > my %h = :1k; say 1 ~ %h<k>:exists ~ 1
   ===SORRY!===
   MVMArray: Can't pop from an empty array
... (9 more lines)		 15:50
nqp: ab5tract++ created pull request #823:
Provide better feedback for ambiguous adverb usage		 15:51
ab5tract ugexe: don't forget to make a PR so that we can see the impact on the pipelines :) 15:52
(unless there's some other way to kick them?)
Geth rakudo: ugexe++ created pull request #5573:
Refactor t/packages		 15:58
ugexe looks like there are some roast tests that are using Test::Helpers from rakudo instead of from the one in the roast already :/ 16:50
as in they expect to use t/packages from rakudo
lizmat yikes 16:51
ugexe github.com/Raku/roast/blob/6aaf159...ion.t#L217 17:29
that line re-writes one of the modules in t/packages
i made some changes to unrelated files, ran spectest, then ran git diff and saw packages/RT128156/lib/RT128156/Needed.rakumod gets changed 17:30
lizmat yeah, seen that happen as well
ugexe that test should be copying files to a temp location first 17:31
MasterDuke ugexe: yeah, it looks like i copied the wrong #defines
Geth roast: 99b194bbda | (Nick Logan)++ | 2 files
Use Test::Util::is_run instead of Test::Helpers::is-run

Previously some tests were relying on using `is-run`, a test helper function from the rakudo (not roast) repo. This updates the code to use the `is_run` test helper that is already included in the roast.		 17:32
ugexe raku -e 'copy("S06-parameters", "foo")' 17:39
Failed to copy '/Users/nlogan/.rakubrew/versions/moar-blead/t/spec/S06-parameters' to '/Users/nlogan/.rakubrew/versions/moar-blead/t/spec/foo': Failed to copy file: operation not supported on socket
in block <unit> at -e line 1
wtf?
m: .say for dir 17:40
camelia ".cpanm".IO
".local".IO
".npm".IO
".rcc".IO
"Perlito".IO
"evalbot".IO
"log".IO
"nqp-js".IO
"p1".IO
"p2".IO
"std".IO
".bashrc".IO
"mbox".IO
".cpan".IO
"dalek-queue".IO
"rakudo-j-inst-1".IO
"rakudo-j-1".IO
"rakudo-j-ins…
ugexe m: copy(".cpanm","foo")
camelia Failed to copy '/home/camelia/.cpanm' to '/home/camelia/foo': Failed to copy file: illegal operation on a directory
in block <unit> at <tmp> line 1
lizmat wow: dalek-queue :-)
ugexe hmm 17:41
maybe its mac specific?
notice in my example it says the operation is not supported on socket
lizmat perhaps the error message is LTA ? 17:43
ab5tract m: dd (5..0).Slip
camelia slip()
ab5tract ^^ why do we even allow that to compile?
ugexe the error seems entirely wrong
lizmat ab5tract: perhaps a worry ? 17:44
ab5tract I feel like the range constructor should return a Failure, at the very least 17:45
anyway, didn't mean to jump in with another issue :)
lizmat I think I have argued that once, a long time ago (~10 years ago)
ab5tract ugexe: it does look mac specific -- I get the same failure locally 17:53
lizmat: I'll have to do an IRC log search and find some arguments to shed some tears about 17:54
ugexe here is an issue for the overwritten module files in roast - github.com/Raku/roast/issues/853 17:55
lizmat ab5tract: if you git blame Range.rakumod, then you should have some starting points, in time I mean
ab5tract m: (-6..6).rand ==> say() 18:07
camelia 2.6544324059042133
ab5tract m: (-6..6).rand xx 8 ==> say()
camelia (-4.738164827199453 5.159230762520579 5.975807979877603 -3.851074498988355 1.4637735675423649 5.836261947637158 3.9448290360490006 -4.77231175341916)
ab5tract why do we (poorly) attempt to restrict endpoints to positive numbers if it works fine with neegatives?
lizmat ab5tract: not sure I follow ? 18:18
ab5tract github.com/rakudo/rakudo/blob/5d6a...kumod#L704 18:20
that code appears to be attempting something that it is not succeeding at 18:21
and it's really not clear why it even cares 18:23
lizmat it fails if the min is larger than the max ? 18:26
MasterDuke doesn't "positive" there just mean size/length > 0?
ab5tract MasterDuke: then what on earth is a negative range? 18:31
lizmat: that's not what the failure message is describing 18:33
lizmat ok, maybe the wording is a bit LTA 18:34
m: say (2..-2).rand
camelia Can only get a random value if the range is positive
in block <unit> at <tmp> line 1
lizmat s/the range/max is larger than min 18:35
??
18:37 finanalyst left
ab5tract m: m: (1..1).rand ==> say() 18:37
camelia Can only get a random value if the range is positive
in block <unit> at <tmp> line 1
ab5tract lizmat: you mean that thing we don't actually support? 18:38
m: dd 3 ~~ 6..0
camelia Bool::False
lizmat m: dd 3 ~~ 0..6 18:39
camelia Bool::True
ab5tract ah, I thought you were clarifying what constitutes a "negative range" 18:40
lizmat no, I just meant the error message "Can only get a random value if the range is positive" is LTA 18:41
ab5tract what I have so far is: Impossible to get a random number from range containing no values.\nOnly the sequence (...) operator supoprts descension between $!min and $!max 18:42
lizmat yes, that was intentionally so 18:43
ab5tract just working on resolving R#1591 18:46
linkable6 R#1591 [open]: github.com/rakudo/rakudo/issues/1591 [LTA] LTAnesses with Range.rand
19:00 finanalyst joined
Geth rakudo/ugexe/restructure-t-packages: d25af712cd | (Nick Logan)++ | 36 files
Restructure Test::Helpers

Previously packages were using the `t/packages` library path which would be seen as a distribution containing other unrelated modules. This commit restructures the file layout of Test::Helpers to match what an actual distribution would use, and then updating our tests to point at the new location. This ensures code using Test::Helpers doesn't inadvertantly have access to other modules in t/packages, and potentially avoids an issue when packages were using a sub directory t/packages/02-rakudo which would already have otherwise been precompiled from loading t/packages.		 19:38
ugexe Just a force push after some minor formatting and comment changes 19:39
ab5tract m: dd .rand with 99..99.0000000000000001 20:03
camelia 99e0
ab5tract would it make sense to exclude such endpoints, the same way we do when they are are equal? 20:04
m: dd .rand with 99..99.0000000000000001e0 20:06
camelia Failure.new(exception => X::AdHoc.new(payload => "Can only get a random value if the range is positive"))
lizmat perhaps let =~= decide ?
afk&
ab5tract good idea! 20:07
Geth rakudo/main: d25af712cd | (Nick Logan)++ | 36 files
Restructure Test::Helpers

Previously packages were using the `t/packages` library path which would be seen as a distribution containing other unrelated modules. This commit restructures the file layout of Test::Helpers to match what an actual distribution would use, and then updating our tests to point at the new location. This ensures code using Test::Helpers doesn't inadvertantly have access to other modules in t/packages, and potentially avoids an issue when packages were using a sub directory t/packages/02-rakudo which would already have otherwise been precompiled from loading t/packages.		 20:34
rakudo/main: 1fc67b1f45 | (Nick Logan)++ (committed using GitHub Web editor) | 36 files
Merge pull request #5573 from rakudo/ugexe/restructure-t-packages

Refactor t/packages to follow idiomatic distribution file structure
ab5tract m: (7.94073749745355e-15).FatRat ==> say() 21:26
camelia 0
22:26 finanalyst left 22:33 sena_kun left
Geth rakudo/main: 06e45d89f2 | ab5tract++ | 2 files
Clarify Range.rand failure cases and fix infinite loop

Previously we would be quite unclear about the specific reasons for failing to produce a random number from a range:
   > .rand with NaN..NaN
... (47 more lines)		 22:45
23:00 azert joined
azert Is there an option to demote Rats as “never ever get one if I never asked for it”? What about modules using Rats against your wishes? 23:02
I just don’t care about 0.1 + 0.2 == 0.3 being true. It is actually an unexpected result for me due to floating point arithmetic 23:05
The slowdown is just unacceptable. There are things in Raku that are unexplainably slow, such as the Hash, but for arithmetic it is obvious 23:06
23:07 azert left
ab5tract Num is sticky 23:28
m: dd .WHAT with 1e-3 * 1/3
camelia Num
ab5tract Beyond that, I don't know of any mechanism to prefer Num over Rat, or any plans to provide one 23:30
Geth roast: 7749803e24 | ab5tract++ | 2 files
Provide test cases for X with baggy operators

While not comprehensive for the entire range of baggy ops, these should be enough tests to catch any regressions and satisfy the closure of R#1726.		 23:35
linkable6 R#1726 [open]: github.com/rakudo/rakudo/issues/1726 [tests needed][data types][operators] Baggy cross operators
ab5tract azert: patches are, of course, always welcome 23:36
tellable6 ab5tract, I'll pass your message to azert

Powered by Cro and the Raku® Programming Language.

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

Thank you!