🦋 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.
Geth rakudo: MasterDuke17++ created pull request #5316:
wip use new stat syscall in DirRecurse
03:02
lizmat nine: looks like support for :P5 would yield up to 28 test files 15:33
nine: a worthy new goal for me? 15:34
japhb I'm surprised it's that many ... but "yes please". :-) 15:39
[Coke] obligatory lizmat++ nine++
lizmat ok, so when I'm gonna do it, would it be a problem if the resulting AST would deparse as a Raku regex ? 15:44
japhb That's both an interesting question and a valuable feature. :-) 15:51
There's still the ability to grab the original *text* of the code that was parsed, yes? So it's not like the original :P5 variant is just *gone*, rather that it wouldn't be represented as special nodes 15:52
lizmat well, that depends on the approach I'm going to take 16:01
generally, the original source can currently not be fetched, but that *is* in the works (the Origins framework)
Geth rakudo/main: 5fc5c32ebd | (Elizabeth Mattijsen)++ | 7 files
RakuAST: refactor handling of rakudoc blocks

  - save margin with all remaining rakudoc objects
  - add "rakudoc-table" as highlighting category
  - use new :directive / :for flags
  - remove margins from paragraphs in RakuAST::Doc objects
  - make deparsing *much* closer to the original (by reproducing
... (11 more lines)
16:21
SmokeMachine What’s origin framework? 16:38
lizmat: ^^ 16:39
lizmat github.com/rakudo/rakudo/blob/main...ns.rakumod
SmokeMachine lizmat: thanks! Taking a look! 16:42
Geth JSON-Unmarshal/main: 5 commits pushed by (Vadim Belman)++ 20:38
Geth JSON-Unmarshal/main: 1d053cbf6d | (Vadim Belman)++ | lib/JSON/Unmarshal.rakumod
Make it possible to non-Any objects with unmarshal()

It's been previsouly done for `_unmarshal`, but this signature was overlooked accidentally.
21:26
JSON-Unmarshal/main: 209ec9e7ad | (Vadim Belman)++ | 2 files
Update documentation according to the latest changes

  - add signatures of the `unmarshal` sub
  - document its named parameters
  - move the part about `is unmarshalled-by` trait into its own section
   under DESCRIPTION
JSON-Unmarshal/main: fa28230ae9 | (Vadim Belman)++ | Changes
Updated Changes
JSON-Unmarshal/main: 344ec60f8d | (Vadim Belman)++ | 2 files
0.12
21:28
MasterDuke anyone see anything obviously wrong/missing in github.com/MoarVM/MoarVM/pull/1762 and github.com/rakudo/rakudo/pull/5316 ? i keep thinking it's just going to be some silly copy/paste-o, but i've looked them over a couple times without seeing it 21:30
vrurg MasterDuke: I haven't tried to analyze it, lacking time for that. But what's the advantage of using newdisp? 22:22
MasterDuke vrurg: jnthn and nine have suggested that particularly io-related ops should be done as syscalls. i guess because they can be better speshed? 22:30
vrurg I thought you know. :) Anyway, the advantage I see immediately is it should be easier to extend with new APIs. Though there must be something else too. 22:32
MasterDuke i believe the syscall allow for better description and analysis of their arguments, so lend themself to better optimization. but that's just my thought 22:35
ugexe i wonder if its related to the upgrade-repository function specifically, or if thats just the first instance it hits 22:52
i guess its from `for $short-dir.dir -> $file {` 22:55
MasterDuke yep 22:57
ugexe (next if $entry eq '.' or $entry eq '..') 22:58
MasterDuke that's from the first commit though, things were fine with just it 22:59
ugexe so its the IO::Path commit that gives the posted error? 23:01
MasterDuke yeah 23:02
ugexe thats odd, because if its the call to `.dir` that is causing the issue then it should be exercising only the code from the first commit 23:03
i.e. `method dir` uses DIR-RECURSE, and doesn't really use anything in IO::Path besides call $.absolute 23:04
ah, i guess it could also be related to github.com/rakudo/rakudo/blob/5fc5...#L176-L181 23:06
upgrade-repository calls !repository-version (linked above)
so seems like maybe the call to .f isn't working correctly? 23:07
MasterDuke yeah, it seems to be something where it thinks a dir is a file (i.e., `.f` is true when it should be false) 23:08
which is why i was hoping it was a silly typo in my .f edit (or its implementing syscall), but no luck so far 23:09
(and i confirmed that the first commit builds and installs ok, now running a spectest)
ugexe i think .f is returning false when it should be returning true fwiw 23:11
could probably try something like nqp -e 'nqp-stat-calls-to-check-dot-f' to test 23:13
MasterDuke it looks to me like it's trying to "open()" a directory
ugexe yeah. but 23:15
if ($version < 1) {
for $short-dir.dir -> $file {
for it to hit that second line, $version has to be 0. $version gets set to 0 if .f returns false
$version 0 is super old, so it probably doesn't even get exercised anymore 23:16
MasterDuke trivial examples are correct
ugexe in normal circumstances
maybe its the .unlink then?
MasterDuke [dan@alexandria rakudo]$ ./rakudo-m -e 'use nqp; my $s := nqp::dispatch("boot-syscall", "file-stat", "VERSION", 0); say nqp::dispatch("boot-syscall", "stat-is-reg", $s)'
1
[dan@alexandria rakudo]$ ./rakudo-m -e 'use nqp; my $s := nqp::dispatch("boot-syscall", "file-stat", "t", 0); say nqp::dispatch("boot-syscall", "stat-is-reg", $s)'
0
[dan@alexandria rakudo]$ ./rakudo-m -e 'use nqp; my $s := nqp::dispatch("boot-syscall", "file-stat", "t", 0); say nqp::dispatch("boot-syscall", "stat-is-dir", $s)'
1
[dan@alexandria rakudo]$ ./rakudo-m -e 'use nqp; my $s := nqp::dispatch("boot-syscall", "file-stat", "VERSION", 0); say nqp::dispatch("boot-syscall", "stat-is-dir", $s)'
0
i didn't touch .unlink though 23:17
ugexe i mention it because its the only file-like operation that gets done in that loop 23:18
oh, rather
the next line of the loop
my @ids is List = $file.lines.unique; 23:19
.lines on a path would try to open it i think
MasterDuke yep, that's the line where it's failing
ugexe i missed that part
MasterDuke the backtrace goes 195, 194, 193 23:20
but i think your right that it doesn't get into that `$version < 1` part of the code on main 23:21
ugexe still, for it to get inside that loop means the !repository-version is either incorrectly returning false for that call to .f, or the slurp it does is somehow returning 0
MasterDuke afk for a while, should be back later 23:22
ugexe raku -e '"lib".IO.lines' 23:27
'lib' is a directory, cannot do '.open' on a directory 23:28
on main, trying to call .lines on a directory gives a slightly different error
MasterDuke that's surprising, what's the error on main? (turns out i'm not afk just yet) 23:37
that comes from IO::Handle.open 23:40
huh. why an IO::Handle?
because IO::Path.lines calls self.open? but why is self an IO::Handle? 23:43