🦋 Welcome to the MAIN() IRC channel of the Raku Programming Language (raku.org). Log available at irclogs.raku.org/raku/live.html . If you're a beginner, you can also check out the #raku-beginner channel!
Set by lizmat on 6 September 2022.
00:59 stanrifkin joined 01:28 stanrifkin left 02:01 kylese left, hulk joined 02:15 hulk left, kylese joined 02:41 stanrifkin joined 03:45 kylese left 03:49 kylese joined 03:53 stanrifkin_ joined 03:56 stanrifkin left 04:47 Aedil joined 05:02 stanrifkin_ left 06:28 abraxxa-home joined 06:39 Aedil left 06:40 Sgeo left 07:10 wayland joined 07:11 guifa left, guifa_ joined
coranila oh, question: identity and names and policies around those are weird and confusing; as such i'm not sure how i should treat the (assumed persistent) presence of my commit bit on my previous personal github account. changing the nickname on github breaks continuity for anything that links to the nickname, which ties in with that whole legal fiction of persistent identity etc etc which, well, is a bit out of scope but 07:15
also is the actual underlying problem. practically im mostly wondering how to resolve permissions for iterative improvements; for example i locally reverted a78033f1d6, because obviously i need jvm debug information...
and well, carrying that upstream even if i dont fix all of the jvm seems reasonable, especially because the revert documents why we want debug symbols
07:19 jjido joined 07:45 jjido left 08:17 abraxxa-home left 08:27 samebchase left 08:32 samebchase joined 08:45 samebchase left 08:52 jjido joined
lizmat coranila what is the new github nick 08:59
coranila crnlskn is what im using now! 09:00
its already in the perl6 org for some reason, i forgot what that was about?
oh that reminds me that i might still have to finish 2fa migration on github! 09:01
hm, no, did finish it but have to add a backup method 09:02
yeah that's all solid now 09:05
fwiw rakudo-j builds with 12 GB heap size for me, which seems to indicate we might wanna pull the 6.c settings appart some for nqp-j as one solution 09:06
another issue i found is that apparently we're busy waiting on $*IN which doesn't play nice with e.g. the new (and so good) REPL 09:07
ISTR that there was some thread scheduling deep cleaning necessary, and RakuAST has problems with lexical lookup -- both on main as well as on bootstrap-rakuast 09:08
these might be vaguely related, but i dont really think so; if anything a potential higher-order architectural issue might be resolved by unifying them, but for that we'd have to identify the right higher-order symmetry we want to fix in the first place, which is kind of where most of the current issues grew from, as far as i can see.. 09:09
thanks lizmat! :-) 09:12
lizmat yw :-)
09:17 jjido left 09:34 wayland left
coranila lizmat: actually, it seems 51b0ef256137240b0539ebdc74b990a6388c01ad might have been another manifestation of the same problem we're running into with RakuAST on JVM; do you happen to have any idea how we could lift the "extra nqp::getlexcaller" into general dispatch logic on JVM? 09:39
linkable6 (2024-04-30) github.com/rakudo/rakudo/commit/51b0ef2561 Final tweaks in Any.match fixes
coranila i suspect not; the details of the jvm dispatcher are kinda spooky, but i figured i'd ask 0:-)
09:43 wayland76 joined 09:44 wayland76 left, wayland76 joined 10:02 jjido joined
lizmat coranila my JVM foo is null and void.... the basic problem appears to be that empty protos don't disappear on the JVM backend... so maybe that should be a focus for fixing? 10:03
coranila ahh, okay yeah that does give me an angle to investigate, thanks! 10:16
as in, it seems to indicate that we're mixing up the lexical structure somewhere between dispatch and incovation 10:17
which i think could be an artifact of the STable/REPRs impl, or could be a structural oversight in lowering, but that's what I'll have to investigate; it's possible it's neither 10:18
because as i understand it, protos are similar to lexical scope in that they represent a closure over possible candidates; i suspect that's exactly what we're leaking into the JVM and the empty protos manifest the same lexical structure leakage that also manifests as a missing &Nodify on main and a missing lexical $_ on bootstrap-rakuast 10:19
10:21 abraxxa-home joined
lizmat in my understanding, protos are *not* a closure over possible candidates 10:22
they are basically an only sub that runs the dispatch logic ({*}) by default 10:23
and on MoarVM disappear from the stack if they just consist of the dispatch logic
coranila oh! so they are supposed to be monadic!
and not membranes
lizmat nine timo did I describe that correctly ?
coranila which i think should be viewed as projective 10:24
lizmat I wouldn't want to send coranila in the wrong direction...
coranila oh i'm poking at the binider anyway; we're still throwing ll exceptions that cascade into X::AdHoc wrappers from there 10:25
which should be at least somewhat tractable with what i already am aware of :-)
nine I would love to understand what "monadic but not membranes" means. 10:47
coranila: could you please dumb that down for me? :)
coranila nine: a membrane imposes a structure, a monad doesn't 10:48
that's to say, a proto doesn't do anything except hand the Capture through; it's purpose is not to bind, just to check if it could bnid
*bind 10:49
nine lizmat: yes. Protos are really just routines that know a list of candidates and resume dispatch at a fixed point
coranila at least that's how i understood lizmats explanatoin
although maybe im mixing metaphors too, that's certainly possible! 10:50
wayland76 I thought protos could also override the dispatch mechanism. Is that correct? 10:59
nine m: proto foo(|c) { return "not with me"; {*} }; multi foo(Str $s) { $s }; say foo("foo!")' 11:00
camelia ===SORRY!=== Error while compiling <tmp>
Two terms in a row
at <tmp>:1
------> ulti foo(Str $s) { $s }; say foo("foo!")<HERE>'
expecting any of:
infix
infix stopper
postfix
statement end
st…		 11:01
nine m: proto foo(|c) { return "not with me"; {*} }; multi foo(Str $s) { $s }; say foo("foo!")
camelia not with me
coranila so every proto would have a lexical scope and the jvm struggles to dissolve some lexical scopes that should dissolve
which does smell like it could be the general bug underlying the &Nodify behavior as well as the bootstrap-rakuast compilation failure 11:02
is it always deterministic which scopes dissolve when?
nine Again, I don't know what "dissolving lexical scopes" means. 11:06
Btw. since you are working on rakudo itself, shouldn't this discussion be on #raku-dev?
coranila that channel does not seem to be available to me on the discord server 11:07
probably because im shy about roles and their implied responsibilities and authority, sorry about that! 11:08
as for 'dissolving lexical scope'; as per github.com/rakudo/rakudo/commit/51b0ef2561 there seem to be multiple spots in the code base where the JVM needs on more "nqp::getlexcaller"; one of them seems to be when a proto is empty 11:09
this, to me, seems to indicate that, conceptually, moar is dissolving a scope that the jvm maintanis 11:10
whether this scope should or should not be constructed is a different question
im mostly wondering where parity between the backends should lie
nine Ah. I think this isn't really about lexical scopes per se. It's just that the raku-multi dispatcher does not actually generate a call to an onlystar-proto (i.e. a proto that does not have any real body). Instead it dispatches directly to the appropriate multi-candidate. That's an optimization. 11:15
Arguably in that specific case nqp::getlexcaller('$/') = Nil is just wrong. It depends on this specific optimization.
11:16 jjido left
nine Conceptually we always call the proto and the proto will be on the call stack. It's just in practice we cheat for performance reasons. 11:17
coranila this here is rakudo/main gist.github.com/crnlskn/cd4e35836f...2ecedea1ad and this is boostrap-rakuast gist.github.com/crnlskn/9413e4346b...b6a6e1b92a
both exhibit the same kind of lexical miss; by extension this means this "specific optimization" is rather widely deployed or something of a similar shape is happening somewhere else 11:18
nine coranila: the bootstrap-rakuast branch *requires* RAKUDO_RAKUAST=1 to be set. Looks like you're missing that 11:19
coranila oh, yes i did in fact miss that, thank you!
nine The &Nodify problem cannot have anything to do with multi-dispatch as that's in pure NQP code (Raku::Actions) 11:20
coranila but it can have something to do with lexical resolution differences between moar and jvm? 11:21
nine I have too little information to exclude that possibility, but also don't have any indications that would push me to such a conclusion. After all it seems to find an object by that name. It just cannot invoke it for some unknown reason. 11:22
coranila fair enough! i guess that's as much as we can find out with the information that's available, thanks!
nine Oh, no, it finds null. But I don't know whether that indicates that it couldn't find anything at all or if it means that it found a symbol but got no value for it. 11:23
coranila Ops.isnull should be HLL semantics 11:24
i.e. nqp::null
nine Ah, the invocationSpec is null. So it did find something but that something is not invokable.
Disregard. I again posted too quickly. Looked at the wrong line. 11:25
coranila very relatable :-)
nine Looking at the getlex implementation it could be both: an nqp::null stored under that name or the name not being found at all 11:27
Do you know which specific call to Nodify fails?
coranila no, i'm still struggling to recover debug info for lines and files and so on 11:28
nine That sounds quite useful :)
coranila i thought reverting the commit that removed them would do it! 11:29
nine Removed line numbers? I wonder what the reason for that was 11:32
coranila a78033f1d69a95363aebae519593b64c90b0a751
linkable6 (2022-08-09) github.com/rakudo/rakudo/commit/a78033f1d6 [JVM] Do not produce debug symbols
coranila i cannot tell! 11:33
lizmat and sadly we cannot ask Ben Davies why anymore :-(
coranila probably some notion of "production code", but for that the solution would probably include not building rakudo-jdb-server
nine Well it does say it's about jar size. But anyway I kinda doubt that this is the kind of debug information we need here. 11:34
coranila it does let us inspect the stack from the inside
on the jvm itself that is
nine Or maybe it is
coranila that's why the diff includes the differentiation between the three identical debug messages for distinct failures modes; i want to know the line number 11:35
nine But that's the line number in the Java code which is only somewhat helpful. My question was more about the line number in the NQP source, i.e. Raku/Actions.nqp 11:36
coranila also, my condolensces; i do vaguely remember ben davies, but i dont think i ever exchanged many words, if any 11:37
with himm
nine: well, we have the entire thread context on the JVM; i'm pretty sure i can find a line number 11:38
but for that i need to be able to look at what the JVM is doing, hence debug symbols; hopefully i actually adjusted the CLI switches correctly for this build!
nine dieInternal tries to set an origin on the exception but if an error happens during that, it will just throw a RuntimeException with the original message
I'd be curious what that exception is that prevents it from throwing the more helpful message 11:39
coranila ohh i need to rebootstrap dont i 11:40
this is IndyBootstrap after all, i can rebuild NQP as much as i like... 11:41
or. orrrr.. i only reverted it on rakudo and not on nqp :-) 11:44
11:49 MoC joined 12:11 wayland joined 12:12 wayland76 left 12:16 Aedil joined, Aedil left 12:20 Aedil joined 12:45 abraxxa-home left 12:46 swaggboi left 12:59 swaggboi joined
nine: gist.github.com/crnlskn/d366b7786c...1fac9801d1 anything stand out? maybe you have a better idea for a diagnostic snippet? 13:04
wait i might simply be missing the env var again... 13:05
updated the gist; second file is with setting RAKUDO_RAKUAST=1 explicitly 13:10
13:13 swaggboi left
nine Well there are only 3 places where Nodify is called with 'Node' as argument 13:22
Can you confirm that Nodify can be called successfully at all? 13:23
13:26 swaggboi joined
tbrowder hi, question for users of non-ascii keyboards: what symbols do you use with Rakudoc formatting codes? i always use <> (but <<>> is legal) because of less keystrokes. 14:05
if i published code that only recognized <>, would that be usable to you? if so, would it not be normal practice for you? 14:09
14:41 Sgeo joined 15:15 stanrifkin joined
[Coke] in raku/doc, I think we use <, <<, and « 15:19
(we could use < in most cases, but to avoid confusion on some contents, you might need whitespace, like < foo< >, and the whitespace is now rendered and we don't want that, so need a quote that doesn't conflict. 15:20
(but I only do this stuff in the context of raku/doc)
coranila nine: i think i explicitly cannot; i added another example to the gist (and remembered we wanted Actions line numbers) which throws from RakuActions.nqp:124 coming from line 112 and then 3643 15:27
nine I'd just add some debug output or even an nqp::die to Nodify and start a run. That'd be clear confirmation :) 16:09
Never underestimate the debug output! Oldest, most versatile and most reliable debugging tool ever
coranila gist.github.com/crnlskn/d366b7786c...e3-txt-L90 the stack trace explicitly points at RakuActions.nqp:124 16:12
nine That means an earlier call must have succeeded. After all we can only set the origin on an actual node and all of those are created by Nodify 16:14
Can you reproduce it with a simple NQP program? Like sub foo() { note("foo!") }; role Bar { method bar() { foo() } }; class Baz does Bar { method baz() { self.bar } }; Baz.baz 16:17
coranila github.com/rakudo/rakudo/blob/main....nqp#L3651 is where we come from fwiw 16:20
i'm not sure what to try vis reproducing with nqp; generating an ast from the snippet...? 16:22
nine Just run nqp-j -e 'sub foo() { note("foo!") }; role Bar { method bar() { foo() } }; class Baz does Bar { method baz() { self.bar } }; Baz.baz' 16:24
Though that line number makes me suspect that we not only successfully ran Nodify before the crash, but actually did so a lot. 16:25
coranila $ ./nqp-j -e 'sub foo() { note("foo!") }; role Bar { method bar() { foo() } }; class Baz does Bar { method baz() { self.bar } }; Baz.baz' Can not invoke object '&foo' (subcallResolve_noa) 16:26
different resolution method, same failure mode
the settings compile fails with callstatic, for reference 16:27
..or is that "in" or "through"? anyway
nine nqp: nqp-j -e 'sub foo() { note("foo!") }; role Bar { method bar() { foo() } }; class Baz does Bar { method baz() { self.bar } }; Baz.baz'
camelia
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility…
nine nqp: -e 'sub foo() { note("foo!") }; role Bar { method bar() { foo() } }; class Baz does Bar { method baz() { self.bar } }; Baz.baz'
camelia
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility…
nine What the?
coranila uh 16:28
that's the sudo disclaimer..?
nine Exactly. How on earth does that make it into camelia's output? 16:29
[Coke] coleman: ^^ ?
16:33 clarkema2 joined
tonyo ::: cat /etc/passwd 16:50
nine Anyway: > nqp -e 'sub foo() { note("foo!") }; role Bar { method bar() { foo() } }; class Baz does Bar { method baz() { self.bar } }; Baz.baz' 16:53
lang-call cannot invoke object of type 'VMNull' belonging to no language
Either my NQP is bad or there's something fishy here even on MoarVM
SmokeMachine Hi! I’ve been reading about prolog and I was wondering if something like that would be possible in Raku… so I started playing with that ideia… I think it still needs some syntactic sugar with some kind of slang. I’m not sure if that’s a good way of doing that… does anyone have any idea of how doing that better? Is that something useful? Any suggestion? glot.io/snippets/h7dttlmhws 17:26
17:29 jdv left
coleman i don't know where Camelia is deployed but I do know it shouldn't be calling sudo 17:38
17:47 jdv joined 17:53 MoC left 17:54 apac joined
Voldenet intriguingly, the error is exactly the same if you call it without sub foo() 18:21
nqp: -e 'role Bar { method bar() { foo() } }; class Baz does Bar { method baz() { self.bar } }; Baz.baz'
camelia
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility…
coranila :D 18:22
Voldenet I mean, the actual error, not the sudo ;p 18:23
coranila i know that the intent probably was to demonstrate that the same vmnull pops up, but that is still a bit funny
Voldenet nqp: blep
camelia
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility…
Voldenet yep, perfectly reproducible ;>
coranila that seems to suggest that Bar can't find it's OUTER:: as CALLER::CALLER:: or something? 18:24
wait no it must be before that already; we dont even have a foo to look for so trying to look for it must be what fails
nine coleman: calemia is running in a VM on a rootprompt server 18:28
camelia: it works when Bar is also a class. So maybe just to satisfy curiousity you can try turning Raku::CommonActions into a base class? 18:30
coleman nine: neat. I've never heard of rootprompt before. who manages it? 18:32
I like the vibe of the website 18:33
coranila nine: i'm assuming that was for me; just replacing the role keyword with class throws <Method 'specialize' not found for invocant of class 'NQPClassHOW'>: gist.github.com/crnlskn/d79a830452...796b4fdb35 18:34
i'd probably need to dig in quite a bit more to figure out if/how that would have to be adjusted on the Rakudo side; i've no idea if we can treat classes as roles? 18:35
nine nqp: note("hi")
camelia hi
nine coleman: I do :) 18:36
The use of sudo is legit: sudo -u evalbot $home/rakudo-m-inst/bin/nqp-m %program"
coleman well if youve taken precautions, I suppose it's okay 👍 18:38
nine coranila: nah, won't work due to lack of multiple inheritance 18:39
coranila alright; just to check if i understand where we are right now: the issue seems to be some kind of ambiguity in how the backends handle role composition early in Rakudo HLL lifetime/ 18:40
?
nine nqp-m: sub foo() { note("foo!") }; role Bar { method bar() { foo() } }; class Baz does Bar { method baz() { self.bar } }; Baz.baz 18:46
camelia lang-call cannot invoke object of type 'VMNull' belonging to no language
at <tmp>:1 (<ephemeral file>:bar)
from <tmp>:1 (<ephemeral file>:baz)
from <tmp>:1 (<ephemeral file>:<mainline>)
from NQP::src/HLL/Compiler.nqp:197 (/home/camelia/rakudo-m…
nine nqp-j: sub foo() { note("foo!") }; role Bar { method bar() { foo() } }; class Baz does Bar { method baz() { self.bar } }; Baz.baz
coranila: I'm not sure yet. There's clearly a problem even in the very reduced example ^^^ even on MoarVM. On the other hand, Raku/Actions.nqp seems to compile and run just fine on MoarVM. 18:47
coranila could that lead back to the getlexcaller optimizations or am i grasping for vindication here? :-)
nine I fear the latter is the case :) 18:48
coranila ah, alright! it would be nice if it was the same problem that keeps us from building on bootstrap-rakuast, but hoping for simple, unifying solutions from a distance is, well... 18:50
"unproductive", i think fits best
18:56 Aedil left, leah2 left, leah2 joined 18:57 japhb left, japhb joined 18:58 Aedil joined 19:27 frankthetank358 joined 19:39 Aedil left 19:51 silug left 20:45 apac left 21:18 stanrifkin left 21:49 jjido joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!