wayland76 Hmm. So my next question is, do we now need to make XML::Element do Iterator or something? Or will Positional take care of that in theory? 00:01
timo should not do Iterator, it could in theory do Iterable, but i think positional might do that 01:22
wayland76 timo: Thanks! According to the inheritance diagram at docs.raku.org/type/Iterable#typegraphrelations Positional and Iterable are independent. I think I might be able to pass through the Iterable.iterator method to the array that contains the XML children. 05:43
Yeah, that seems to fix the problem. Thanks! I'll put in a PR later today. 05:47
timo I pulled the trigger on tbrowder's docs PR 05:52
wayland76 Hi! Is there an easy way to borrow files from another module? I'm making some tests that are dependent on the XML module, and I'd like to reuse some of the XML files that come in the "t" directory of the XML module in my own tests. 10:59
wayland76 (Decided to hold off on the Iterable PR for now, in case I discover any other bugs in the near future) 11:00
Also, is it possible to define an operator that takes 3 parameters instead of 2? Would I use a sub-signature for that? 11:03
lizmat sure, and not necessarily 11:04
assuming you'd want to use it in a reduce ?
but how would that be different from a sub with 3 args
?
wayland76 I'm wanting to do something like the XPath, for example: html⪪body⪪h1{@id="red"} -- the ⪪ operator will look for matching children, and the {} is just a block, and that part works, it's the part between the ⪪ and {} that I'm trying to figure out. 11:08
Sorry, that should've been ".id", not "@id"
Let me rewrite the example: html⪪body⪪h1{.id eq "red"} 11:09
Going to bed now; will look at the answer next time I'm on (hopefully tomorrow, but otherwise the next day). 11:10
I'm happy if I have to make those things strings, and if necessary, I could put a comma before the {}. 11:11
What I currently have working is something like: @nodes ⪪ { .id eq 'red' }
lizmat sleep well... I'll mull over it some more today 11:18
lizmat weekly: dev.to/lizmat/repl-avalanche-45hh 13:37
notable6 lizmat, Noted! (weekly)
antononcube @lizmat REPL crashes 😭 15:58
I will try to reproduce the crash and file an issue. (I think it was repeated use of =context.) 16:00
Hmm... while trying to reproduce the crash it happened immediately with the message: [0] >rakudo(12052,0x1f4b10840) malloc: Heap corruption detected, free list is damaged at 0x60000267c240 *** Incorrect guard value: 9600 rakudo(12052,0x1f4b10840) malloc: *** set a breakpoint in malloc_error_break to debug 16:03
After doing rakubrew rehash I cannot reproduce the crash.
So, no issue filing for now.
lizmat antononcube the past months I've been suspecting that sometimes after an update, wrong bytecode files are being selected. Which can cause all sorts of weird crashes 17:58
this appears to confirm that suspicion
timo but that also looks like the crash you get with the not-updated-yet LineEditor module 20:13
where the struct definition was too small
so it literally immediately overwrites a pointer in the free list with bogus data

Powered by Cro and the Raku® Programming Language.

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

Thank you!