melezhik. . 08:07
tellable6 2025-03-25T20:26:35Z #raku <librasteve> melezhik: please do - but i am worried about the ease of installing the Air deps since I’m struggling on macOS with DBIish on pq with 2025.02
wayland76 Voldenet: Regarding RED, thanks! I'll have a look at it. 10:12
.tellable6: Voldenet Regarding RED, thanks! I'll have a look at it. 10:16
wayland76 .tellable6 Voldenet Regarding your simplified xpath, it'd be even simpler with: sub xpath(*@n) {}; xpath <html head h1>, { .id eq "red" }, <h2>, { .className eq "x1" } 10:19
SmokeMachine wayland76: did you see this? glot.io/snippets/h5t1sg55xd 10:21
wayland76 SmokeMachine: Wow, very nice! Had not considered that AT-KEY might work for this! 10:37
Voldenet I've pondered about syntax similar to `(html <- "body" <- "h1"){ *.id eq "red" }`, but then I've realized that "h1" should be logically glued to that block 11:53
SmokeMachine Im thinking that now too… but before, I thought it should be related to the “relationship “ because of the 2nd example, the join one… 11:57
Voldenet yeah, they're both not the same example
in fact, I like sql, after seeing how weird is left joins syntax in efcore 11:58
> SELECT bar_id, foo_id FROM foo LEFT JOIN bar ON bar_id = bar.id 12:00
vs
SmokeMachine But now I think, maybe, the best solution would be an Slang that would translate that to something like this: glot.io/snippets/h5u6pwid3l
Voldenet > c.Foo.GroupJoin(c.Bar, foo => foo.BarId, bar => bar.Id, (foo, barGroup) => new { foo.FooId, BarGroup = barGroup }).SelectMany(x => x.BarGroup.DefaultIfEmpty(), (x, bar) => new { x.FooId, BarId = bar?.BarId }); 12:01
Slang is fun, but you can write similar thing using `sub xpath(*@n)`, it gets really simple 12:04
it's all a list of strings and blocks after all 12:05
SmokeMachine I don’t know if that’s the case, but I would assume it would not only have < but also, maybe, << to deep search? 12:06
Voldenet simple apis require simple solutions: xpath(<// h1 span // h2>) 12:08
SmokeMachine About the join, I like: `Foo.^all.join-model: :left, Bar, *.bar-id == *.id` :) 12:09
Voldenet yeah, it's sane
in fact, efcore has it, except it's marked as internal, with all the warnings included 12:10
SmokeMachine (That’s Red syntax if it’s not clear… :) ) 12:11
But that has a problem, if you do not call a map to specify the fields you want there, it will return only the Bar objects… it should return Foo and Bar… I’m still trying to find a good way to return both… 12:14
Voldenet there are multiple pain points possible with the entity-based syntax overall 12:17
expressing things like `select bar_id from bar cross apply openjson(bar.json) with (x int) as j join foo on foo.x_id = j.id` gets difficult 12:18
erm, there should be j.x on the end 12:19
It can be possible, but syntax would very likely close to sql at some point 12:21
SmokeMachine I’m not sure if I get that openjson stuff… but I think it would look something like: `Bar.^all.join-model(:cross, Foo, *.json.x == *.x-id).map: { Bar.id }` but I probably missed something… 12:29
Sorry: `*.json<x>` 12:30
Voldenet that json stuff for every varchar() `{"x":42}` extracts that x 12:37
and then appends that to resultset, so it can be joined to another table somehow 12:39
my point is that sql has a lot of things that can't be easily expressed in simplified syntax 12:43
or rather, it would turn your simplified syntax to sql 12:44
so imo there should be strong focus on composing over sql 12:47
SmokeMachine usercontent.irccloud-cdn.com/file/...997453.JPG 13:57
Fritz14 Hi Raku experts, I am getting a Segmentation fault with my Raku programm and have no clue how to debug this. 14:35
```
PERL5LIB=thirdparty/lib/perl5 raku -Ilib bin/agrammon.raku --cfg-file=etc/agrammon.single.yaml web version6/End.nhd
Segmentation fault (core dumped)
```
is all I get. My suspicion is that it could be related to using `Inline::Perl5` with `Excel::Writer::XLSX:from<Perl5>`, but I am not sure.
Unfortunately, so far I could not reproduce the seg fault with a minimal program using these two modules.
I tried running it under `raku-remote-debug`, but only got this output:
```
> received:
85 a2 69 64 12 a4 74 79 70 65 9 a6 74 68 72 65 61 64 d a9 6e 61 74 69 76 65 5f 69 64 cf 0 0 76 93 eb e0 6 c0 ac 61
70 70 5f 6c 69 66 65 74 69 6d 65 1
```
Any help on how to proceed would be much appreciated.
Oh well, I guess my formatting attempts only partially succeeded ...
ugexe i think you're gonna have to post some source code 14:37
Xliff Fritz14, try running raku with the --ll-exception 14:38
Fritz14, You can also use this to disable SPESH: MVM_SPESH_DISABLE=1 14:41
Fritz14, and the following to disable JIT: MVM_JIT_DISABLE=1
Try with all 3 and see if that helps. 14:42
Also, you might want to try updating your Raku and Inline::Perl5
Fritz14 Xliff neither of the three helped. 14:46
I am running
Welcome to Rakudo™ v2025.03.
Implementing the Raku® Programming Language v6.d.
Built on MoarVM version 2025.03.
and a freshly installed Inline::Perl5.
I am using this in production with Rakudo/MoarVM 2024.10 without problem.
I had tried to upgrade to 2025.02 and 2025.03 and both fail.
ugexe I'd be happy to provide source could, but couldn't get a small failing example so far. The whole thing is a bit bigish: github.com/oposs/agrammon 14:48
melezhik. .tell librasteve: this is an example of validating arbitrary html table structure , it checks for “outside of table / rows ” table rows and cells , maybe something worth try out for Air unit tests - gist.github.com/melezhik/115dde6e3...b6c2d86df5 14:50
tellable6 melezhik., I'll pass your message to librasteve
lizmat Fritz14 o/
Fritz14 I'll try 2024.10, 2024.12, 2025.01 on the development machine now to see if I can narrow it down.
lizmat that would be helpful!
melezhik. The advantage of the approach it works with ANY table structure , not just of fixed size 14:53
Fritz14 The segfault is not happening on Rakudo version up to 2025.01. Both 2025.02 and 2025.03 ARE sefaulting. 16:02
Fritz14 Found this now via `journalctl`: 16:17
Mar 26 17:16:39 thinlinc-aarweg-01 kernel: 4: GeneralWorke[157826]: segfault at c ip 00007a52b5b31151 sp 00007a52b2bff530 error 4 in libperl.so.5.38.2[7a52b5a43000+1ab000] likely on CPU 27 (core 27, socket 0)
Mar 26 17:16:39 thinlinc-aarweg-01 kernel: Code: ff 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 55 48 89 e5 41 57 49 89 f7 41 56 41 89 ce 41 55 49 89 d5 41 54 4d 89 cc 53 48 83 ec 18 <80> 7e 0c 06 48 89 7d c0 4c 89 45 c8 0f 86 65 01 00 00 be 30 00 00
Fritz81 A minimal program for reproducing the segfault is: 16:42
use lib:from<Perl5> 'perl5';
use Excel::Writer::XLSX:from<Perl5>;
my $workbook = Excel::Writer::XLSX.new('testseg.xlsx');
# next line leads to segfault
my $bold-format = $workbook.add_format();
# below only needed to show that things are working
# without the call to add_format();
my $sheet = $workbook.add_worksheet('Test'); 16:43
$sheet.write(0, 2, 'Testing');
$workbook.close();
with `perl5/` containing an installation of the Perl5 module `Excel::Writer::XLSX`
Calling this script with
    `raku test.raku`
segfaults. Commenting out the line calling `add_format()` avoids the segfault
and testseg.xlsx is created.
jdv wut 16:45
nopaste or gist or wutever 16:46
Fritz81 gist.github.com/zaucker/5800adb925...00f5a717bc 16:56
lizmat Fritz is used to MatterMost :-) 17:20
Xliff_ lizmat: Can the methods Inline::Perl5.unwrap-perl5-object and .p6-to-p5 safely return Nil? 18:28
lizmat I have no idea: nine probably knows :-) 18:29
Xliff_ That's the source of the segfault.
$o === Pointer and is passed to $!p5.add_magic which attempts to deref and BOOM!
This is what Fritz is running into. 18:30
antononcube I expected lizmat to say: "use a wrapper."
lizmat so why doesn't that happen before 2025.02 ?
Xliff_ lizmat: *shrug*
lizmat Inline::Perl5 didn't change 18:31
Xliff_ Doesn't really matter if Inline::Perl5 isn't performing a null check on $o?
s/\?//
nine: Any thoughts? 18:32
lizmat NativeCall hasn't seen any changes this year
so that can't be it either, I'd say
Xliff_ A changed in MoarVM that was masking the issue was probably removed, maybe? 18:33
lizmat Inline::Perl5 hasn't seen a release since august 2022
that's why I suspect 6f19ada9cb30a2477a9 in MoarVM
but we probably should take this to #moarvm
Xliff_ OK
antononcube @lizmat I have an "Acme::Text::UpsideDown" question: is this a known limitation, not being able to write "π" upside down? 18:35
lizmat if you can tell me the codepoint to use for π upside down, we'd be in business 18:36
antononcube Hmm.... I can use a Chinese or Korean character for that.
E.g. 'ㅛ'.
If I figure out a good replacement I will file an issue / PR. 18:37
lizmat ㅛ looks good to me 18:38
Xliff_ Oh my god! There really is an upside down smiley!
lizmat antononcube a PR would be appreciated
Xliff_ “🙃” U+1F643 Upside-Down Face Unicode Character
antononcube @Xliff Extremely important package! I use it at least twice every three months.
Xliff_ 🙃.unichar.say 18:39
m: "🙃".unichar.say
camelia No such method 'unichar' for string '🙃'
in block <unit> at <tmp> line 1
Xliff_ m: "🙃".uniname.say
camelia UPSIDE-DOWN FACE
Xliff_ OK, now for what I REALLY wanted to ask. Do RakuAST knows support a .parent method? 18:40
Or does such tree navigation require special processing?
lizmat Xliff_: it does not at the moment, afaik
that said, I think you could create something like that by a specially crafted code block for .visit-children 18:42
lizmat Xliff_: try @*LINEAGE.tail inside .map / .grep ? 18:44
melezhik. . 18:47
Xliff_ lizmat: Dynamic variable @*LINEAGE not found 18:55
lizmat: This is the invocation I used: RAKUDO_RAKUAST=1 raku -e 'use experimental :rakuast; class Post { method a { }; method b { }; }; CHECK { $*CU.grep( RakuAST::Method ).map({ @*LINEAGE.gist.say; $_ }) }' 18:57
lizmat I did: RAKUDO_RAKUAST=1 raku -e 'CHECK .say for $*CU.grep({ when RakuAST::StrLiteral { say @*LINEAGE.tail.^name } }); say "hello world"' 18:59
librasteve there’s a 2025.02 moar issue over here on the Discord raku channel (not the same as the raku-irc channel) btw 19:03
tellable6 hey librasteve, you have a message: gist.github.com/7e25825012e715a193...128dbab468
Xliff_ lizmat: Only available in .grep then. Not in .map 19:09
lizmat Xliff_: CHECK Nil for $*CU.map({ when RakuAST::StrLiteral { say @*LINEAGE.tail.^name; $_ } }); say "hello world" 19:18
tells me otherwise ?
argh 19:19
s/tail/head
I had it backwards 19:20
CHECK $*CU.map({ when RakuAST::StrLiteral { say @*LINEAGE.head; $_ } }); say "hello world" 19:21
Xliff_: .parent method coming up, but only inside .grep / .map 19:26
Xliff_ lizmat: Thanks! 19:31
lizmat github.com/rakudo/rakudo/commit/6fd413c05f
Xliff_ Wow! Elegant! 19:32
lizmat: Actually, maybe (int $generation = 0) ?? 19:33
lizmat we might want to change the Nil to a Failure...
why? native ints default to 0
Xliff_ Oh! Nevermind then. 19:34
I'm a little worried now that something like .parent.parent might not work.
Xliff_ I think the fix is an act of documentation. 19:36
lizmat .parent.parent would not work
Xliff_ Yeah. That would have to be rewritten to .parent(1)
lizmat indeed
Xliff_ Like it, though. lizmat++ 19:37
Xliff_ So this is what I was hoping to get at runtime: RAKUDO_RAKUAST=1 raku -e 'use experimental :rakuast; our ($CU-CLASSES, $CU-METHODS); class Post { method a { }; method b { }; }; CHECK { $*CU.grep({ when RakuAST::Class { $CU-CLASSES.push: $_; for .find-nodes( RakuAST::Method ){} { $CU-METHODS{ $CU-CLASSES.tail.name.simple-identifier }{ .name.simple-identifier } = $_ }; }; }); $CU-METHODS.gist.say }'... unfortunately I don't think 20:15
it will survive serialization for various reasons.
lizmat we still have serialization issues in RakuAST, that's why I had to revert the new .assuming implementation 20:18
Xliff_ OK. So I can put that on hold for awhile then. 20:19
lizmat well, I'm hoping we can fix that before the 2025.04 release 20:19
Xliff_ Sounds good!
melezhik. . 20:26

Powered by Cro and the Raku® Programming Language.

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

Thank you!