🦋 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.
00:25 donaldh left 03:12 guifa left 04:40 guifa joined
nine ab5tract: oh my....of course that my $_ in RakuAST::Call::Method.IMPL-INTERPRET would not help. We're looking for a $_ in the lexical outer frames, not the caller frames. 07:57
Ah, no. That's not it. As EVAL does my $context := nqp::defined($ctx) ?? $ctx !! CALLER::LEXICAL::; 07:58
08:52 finanalyst joined 09:34 finanalyst left
ab5tract What I’ve noticed is that the blow up is happening with a compile resolver, presumably being handed off from the eval resolver 10:24
But I was a bit surprised to be working with a compile resolver where I would have expected an eval resolver 10:25
nine: any idea what RakuAST::IMPL::InterpContext is for? It’s passed to all IMPL-INTERPRET calls but is an empty class and I never see anything done with it 10:26
I *think* the issue could be solved by correctly passing the eval resolver’s outer to the compile resolver constructor. But I’m really just stabbing at shadows at the moment 10:27
nine ab5tract: resolvers wont help you 10:48
The EVAL resolver is only for evaluating full RakuAST trees which is a different use case 10:49
That context is also unused for now
ab5tract that saves me from wasting time going down false paths. thanks! 10:51
I do wonder about that though.... `src/Raku/ast/resolver.rakumod:1004` appears near the top of the stack trace 10:52
But also: taking your word for it usually works out well for me :)
If you have any thoughts as to where I can direct my future stabbings, please share! 10:53
nine It's something about CALLER::LEXICAL not finding symbols from the nqp code. IOW I don'tknow how to give it a $_ 11:00
You can work around in EVAL itself
Check whether $ctx has a $_ and if not take a LEXICAL:: froma block as $ctx 11:01
I would really like to know if theres another way though. PseudoStash is not easy to understand though 11:02
ab5tract I think the from-context code is wrong because it disregards the resolver’s $!outer when constructing the new derived resolver 11:23
nothing changed when adjusting this, though :( 11:24
I'll try the less awesome approach first
Wow, you were not joking about PseudoStash :O 11:31
11:46 El_Che joined
El_Che timo: test mimalloc_alpine_fix_for_2025.04_release atm 12:00
12:01 guifa left
El_Che bad news: 12:03
productionresultssa18.blob.core.wi...4-997b-47e
9-b12b-9515b896b4de&skv=2025-01-05&sp=r&spr=https&sr=b&st=2025-04-21T12%3A03%3A07Z&sv=2025-01-05
ooops
to long url
summary on top, full log below: gist.github.com/nxadm/4109ec01e6cc...a8addcf0d3 12:04
timo is there a package that has the linux headers inside it? 12:20
i've seen a different patch where the include for prctl was moved inside the if(__GLIBC__) below, could you try that? that'd be the "if !defined(PR_SET_VMA)" and also the include for prctl.h 12:51
github.com/microsoft/mimalloc/comm...3518f5dde4 - so this patch that's already included from the moarvm branch, but moved one line down essentially 12:52
On musl-libc the required types for prctl are defined in sys/prctl.h and including linux/prctl.h fails either because the file does not exist or because it redefines the types. 12:54
^- from one of the issues on github
El_Che Hi 12:57
yes, linux-headers 12:58
and compiling with gcc
I addedd it before
before the branch, whilke debugging
but it then complains a function is redeclared
[Coke] Maybe it's better to go back than forward here. 13:08
timo the code below that also uses prctl uses "if defined" to make sure it doesn't try to call prctl with something that's missing
yeah coke i think you're right
[Coke] And only update mimalloc until after it's safe.
timo El_Che: can you easily change the mimalloc 3rdparty commit for the submodule? or just revert the individual commit that updates the mimalloc version? 13:09
13:33 finanalyst joined 13:34 finanalyst left
[Coke] patrickb: do we have any docs describing our current CI? 14:36
seeing a bunch of warnings in dev.azure.com/Rakudo/rakudo/_build...ew=results
patrickb [Coke]: Sadly I don't. It's only in my and timo's head... 15:01
I believe many of those warnings relate to the release build pipeline. 15:03
jdv it is slightly odd we only really guarantee any rando release will work on vanilla linux distros
patrickb Those have the special requirement to run on the oldest possible OS. 15:04
jdv might need to trade velocity for platform support i guess
patrickb That's because of glibc being forward, but not backward compatible.
timo ok so the warning about tools in the ubuntu image not working any more doesn't concern us i don't think
patrickb Thus I build on one of the distros with the oldest glibc still in use. 15:05
IIRC it's CentOS 6 in a docker container on an Ubuntu host. 15:07
[Coke] patrickb, timo: as time permits, getting that documented (wiki page in rakudo git repo?) would be great. Would have loved to have an early warning about the el_che issue for this release, e.g.
jdv id guess nobody else builds on alpine 15:08
timo we could maybe get people who have their own packaging to contribute a little bit to the rakudo release pipeline on azure pipelines? most should be able to get their build stuff into a dockerfile and we could build that in our pipeline 15:09
well, linux distros that is
jdv i only build on debian:|
[Coke] my azure box is ubuntu 15:29
(for blin & release stuff)
jdv ?ironic? that m$'s cloud stuff is basically linux 15:30
[Coke] oh, it's an option on the VMs - I could be using any of a number of windows boxes also 15:32
(looks like they also have some RHEL options, and then some one offs) 15:33
jdv even more odd is a friend of mine workscat amazon scripting azure stuff:) 15:34
timo where all my comet snowman lovers at? 17:20
22:15 guifa joined 22:38 guifa left