timo with a 26k deep call stack, i should maybe not ask moar-remote for "all lex" %) 01:32
oh, "step" asks for a backtrace of course, so stepping will now take multiple seconds for a tiny step 01:33
> find_macro_routine 01:46
hmm.
gist.github.com/timo/d8aa2c3924a99...566bd36550 01:58
i think we're forcing a deopt every time we enter token statement because there's an unconditional rebless in it 02:19
i wonder why i'm randomly ending up in handling an exception with message "could not locate compile-time value for symbol say" 02:29
that's from is_type it looks like
an authoritative cache every, say, 100 frames might be a good idea for ridiculous examples like 10000 deep nested for loop 02:30
otherwise i think we're doing a couple of things where we walk all the way up the call stack 02:31
oh, i wonder if we are going up the call chain to give every frame a "caller info needed" flag, if we hit one where it's already set, can we stop? 02:33
bartolin there is another spectest failure on the JVM backend which I golfed down to this: 07:43
m: proto sub foo ($) {*}; multi sub foo(Mu $a) { say "got a Mu" }; foo(Mu)
camelia got a Mu
bartolin I believe this is equivalent to
m: proto sub foo (Any $) {*}; multi sub foo(Mu $a) { say "got a Mu" }; foo(Mu)
camelia got a Mu
bartolin on the JVM backend both fail with: Type check failed in binding to parameter '<anon>'; expected Any but got Mu (Mu)
In the documentation it says (docs.raku.org/syntax/proto): "[...] arguments of multi candidates may have subtypes of those of the proto [...]" 07:45
but this doesn't seem to apply here, since Mu isn't a subtype of Any
I also noticed that there are different variants for signatures for protos in the core: often it's something like :(Mu, *%) or :(Mu, |) but other cases it's :($, *%). (And there are many more variants.) 07:49
btw, the test failure happens in integration/advent2011-day07.t and I believe that it fails to dispatch to the multi variants of Stash::ASSIGN-KEY github.com/rakudo/rakudo/blob/ba3b...akumod#L62 when something is passed in that doesn't derive from Any 07:54
but I'm mostly curious why/how MoarVM dispatches to the multi sub in my example. Does it ignore the types for the proto? 07:55
nine insane.raku with 10000 loops finished in 3:27.79 minutes. So at least we know that it does so eventually. 07:56
bartolin whoa 07:57
m: proto sub foo (Str $) {*}; multi sub foo(Mu $a) { say "got a Mu" }; foo(Int) 07:59
camelia ===SORRY!=== Error while compiling <tmp>
Calling foo(Int) will never work with signature of the proto (Str)
at <tmp>:1
------> ulti sub foo(Mu $a) { say "got a Mu" }; <HERE>foo(Int)
bartolin no, doesn't look like it bypasses it completely.
m: proto sub foo (Str $) {*}; multi sub foo(Mu $a) { say "got a Mu" }; foo(Cool) 08:00
camelia got a Mu
bartolin is puzzled
nine bartolin: the multi dispatcher optimizes away the call to the proto when it has an inconsequential signature and is an onlystar. Apparently the definition of "inconsequential" is a bit off with regards to Any vs. Mu 08:02
bartolin ah, thanks. would this be a place where I could start to look for the details? github.com/rakudo/rakudo/blob/ba3b....nqp#L1806 08:05
nine Yes, definitely 08:06
bartolin (I didn't remember the term "onlystar". I even looked for "multistar" and "protostar" ;))
cool, thanks, nine++
one thing I noticed: this just prints "got a Mu" when running with --optimize=off. so without the optimizer it seems to really just ignores the types of the proto for the "is-simple-args-proto" case. 08:28
m: proto sub foo (Str $) {*}; multi sub foo(Mu $a) { say "got a Mu" }; foo(Int)
camelia ===SORRY!=== Error while compiling <tmp>
Calling foo(Int) will never work with signature of the proto (Str)
at <tmp>:1
------> ulti sub foo(Mu $a) { say "got a Mu" }; <HERE>foo(Int)
Geth nqp/main: 5d3ba92f3d | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump MoarVM to get MasterDuke++ UBSAN fixes
 10:06
rakudo/main: 2147e6b81d | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP to get MasterDuke++ UBSAN fixes on MoarVM
 10:26
10:33 sena_kun joined
timo > 269.121712700 seconds time elapsed 10:36
10:42 sena_kun left
timo it's also using an impressive amount of memory. just hit a gigabyte before it finished 10:44
10:54 rba_ joined
lizmat
.oO( oh what a tangled web we weave )
 11:01
11:02 coleman left, japhb left, rba left, samebchase left, sjn left, rba_ is now known as rba 11:05 coleman joined, japhb joined, samebchase joined, sjn joined
timo so many more things i have to add to the debug protocol ... 11:07
time to invent yet another way to do pagination i guess
11:43 gfldex left 11:50 gfldex joined
timo <!!{ if !nqp::eqaddr($/.WHAT, (my $sgm := self.slang_grammar('MAIN'))) { note("reblessing " ~ $/.HOW.name($/) ~ " to " ~ $sgm.HOW.name($/)); nqp::rebless($/, $sgm); }; 1 }> 12:29
MVM_spesh_deopt_all goes from 23.7% to 2.41% of samples 12:30
lizmat doesn't follow 12:33
timo that's in Perl6/Grammar.nqp at the beginning of the "statement" rule 12:52
well, i changed it from just the rebless call to have the if wrapped around it
lizmat aha, so not reblessing if the .WHAT is already the same ? 13:02
timo yes 13:12
rebless unconditionally causes a full deoptimization
lizmat I seem to recall that that was on purpose... but maybe not needed if the .WHAT is already the same 13:13
but wouldn't that be better handled in nqp::rebless ?
I mean, check for .WHAT equality ?
nine No. Ops should be simple and dumb. If the checking logic is in HLL code, there's a possibility to optimize it away. 13:17
patrickb Is it right, that the t/12-rakuast tests are not run by default? 13:22
nine No, they should be run
patrickb They don't seem to be run when I look at the latest azure runs.
Looking at the code I don't see any logic to skip them, they do get run when I try locally. 13:23
It's doing `prove -e ../install/bin/perl6 -vlr t`. 13:24
But it stops at t/11-ts/eval-js.t 13:25
It's the file extension. 13:26
:facepalm:
t vs rakutest
it'd be better to replace the hard prove command with `make test` I'd say. Agreed? 13:27
o/ nine 13:28
Long time no read! How are you?
nine \o patrickb Doing great! Having my own product developing startup is surprise, surprise just a lot of work :) How're you? 13:30
patrickb Also good. I moved places recently. Still a huge mess everywhere. Tidying tends to take longer and if you don't pay attention reverse with two small ones... 13:33
nine I would just get used to that :D 13:36
patrickb :-P 13:39
Geth rakudo: patrickbkr++ created pull request #5699:
Azure run rakuast tests		 13:47
rakudo/main: ad3e9c5795 | (Patrick Böker)++ | azure-pipelines.yml
Run t as well as rakutest tests in azure
 14:48
rakudo/main: cfa5115c43 | (Patrick Böker)++ | azure-pipelines.yml
azure s/perl6/raku/
rakudo/main: 24a1cdbbbb | (Patrick Böker)++ (committed using GitHub Web editor) | azure-pipelines.yml
Merge pull request #5699 from patrickbkr/azure-run-rakuast-tests

Azure run rakuast tests
14:55 Xliff joined
Xliff timo: Here is fine. Probably better because scrollback can be used to write a guide. 14:55
timo OK 14:56
oh, MVM_JIT_DISABLE=1 while recording will give C stack traces back
Xliff WARNING: event 'N/A' not valid (bits 16,20,22 of config '5111c4' not supported by kernel)! 14:57
timo ah crap, your CPU may not be supported by rr yet
maybe there's a newer version of rr that you can install?
oh, do you have an amd zen? 14:58
it's not crucial that we use rr. with MVM_JIT_DISABLE=1 we will have more to work with as well 14:59
Xliff It should be. Unfortunately I have to split for a meeting in $dayJob. Can we pick up when I'm done?
timo how long will it be? i might have to go soon as well :( 15:00
my roadmap for figuring stuff out would be to find the object that we're trying to assign to, then printing STABLE(obj)->debug_name should give us an idea why it's telling us we have an immutable value on the receiving end 15:03
usually it's a bit annoying to get a handle on the "obj" because much of the time you just get "value has been optimized out"; if you can rebuild your moarvm with --optimize=0 that usually goes away, for a noticeable performance penalty
if you have the bytecode in front of you, and you're in MVM_interp_run, you can usually get reg_base[number_of_register].o for the right value 15:05
Xliff Oh thank god. It was short. 15:22
Let
Let's see if we can get it working without rr for now.
timo OK 15:24
Xliff First call to MVM_exception_throw_adhoc is "Cannot move to outers or callers with non-traversable context"
timo that's fine, that always happens and is an exception we expect and catch 15:26
Xliff OK, so how to move beyond this? 15:28
timo just "c" again will resume running until the next time a breakpoint is hit
Xliff Nevermind found it.
timo or you ctrl-c to manually interrupt execution
Xliff #0 MVM_exception_throw_adhoc (tc=0x3128a020100, messageFormat=0x7ffff79c2488 "Cannot assign to an immutable value") at src/core/exceptions.c:901
#1 0x00007ffff78357e0 in MVM_interp_run (tc=0x3128a020100, initial_invoke=0x7ffff79c2488, initial_invoke@entry=0x7ffff796c1b0 <toplevel_initial_invoke>,
invoke_data=0x7ffff79c2488, invoke_data@entry=0x7ffff796c1b0 <toplevel_initial_invoke>, outer_runloop=outer_runloop@entry=0x0) at src/core/interp.c:2805
#2 0x00007ffff796d269 in MVM_vm_run_file (instance=instance@entry=0x3128a010800,
filename=filename@entry=0x555555559570 "/home/cbwood/.rakubrew/versions/moar-blead/install/share/perl6/runtime/perl6.moarvm") at src/moar.c:524
#3 0x00005555555558de in main (argc=<optimized out>, argv=<optimized out>) at src/vm/moar/runner/main.c:480
timo ok, cool, so we're in the case where the object we are trying to assign to doesn't have a container spec in the first place 15:29
Xliff at src/vm/moar/dispatchers.nqp:222 (/home/cbwood/.rakubrew/versions/moar-blead/install/share/perl6/lib/Perl6/BOOTSTRAP/v6c.moarvm:)
from /home/cbwood/Work/RacquetAppServer/app/lib/Applications/Bizzell/Inventory/Instance.pm6 (Applications::Bizzell::Inventory::Instance):48 (/home/cbwood/Work/RacquetAppServer/app/lib/.precomp/D69BDF306EBF6CADBB78BF26AE45271D9FD3BB75/CA/CAAB3B2684593984EDC20968A2AA667B2CE6626E:BUILDALL)
from SETTING::src/core.c/Mu.rakumod:158 (/home/cbwood/.rakubrew/versions/moar-blead/install/share/perl6/runtime/CORE.c.setting.moarvm:bless)
from /home/cbwood/Work/RacquetAppServer/app/lib/Racquet/DB/ClassBase.pm6 (Racquet::DB::ClassBase):856 (/home/cbwood/Work/RacquetAppServer/app/lib/.precomp/D69BDF306EBF6CADBB78BF26AE45271D9FD3BB75/E5/E5804E959AB548F13781714DC8C6C7642F1B3556:new)
from /home/cbwood/Work/RacquetAppServer/app/lib/Racquet/DB/ClassBase.pm6 (Racquet::DB::ClassBase):852 (/home/cbwood/Work/RacquetAppServer/app/lib/.precomp/D69BDF306EBF6CADBB78BF26AE45271D9FD3BB75/E5/E5804E959AB548F13781714DC8C6C7642F1B3556:new)
from /home/cbwood/Work/RacquetAppServer/app/lib/Racquet/DB/ClassBase.pm6 (Racquet::DB::ClassBase):349 (/home/cbwood/Work/RacquetAppServer/app/lib/.precomp/D69BDF306EBF6CADBB78BF26AE45271D9FD3BB75/E5/E5804E959AB548F13781714DC8C6C7642F1B3556:getRecordReal)
timo "frame 1" will put you in the frame of the interpreter
Xliff from /home/cbwood/Work/RacquetAppServer/app/lib/Racquet/DB/ClassBase.pm6 (Racquet::DB::ClassBase):302 (/home/cbwood/Work/RacquetAppServer/app/lib/.precomp/D69BDF306EBF6CADBB78BF26AE45271D9FD3BB75/E5/E5804E959AB548F13781714DC8C6C7642F1B3556:getRecord)
from units/test-instance.raku:32 (<ephemeral file>:MAIN)
Ok. There.
timo please try if "print cont" gives you something 15:30
hopefully not "value has been optimized out"
Xliff (MVMObject *) 0x7ffff79c2488
timo but we can deal with it even if it does
perfect, then print STABLE(cont)->debug_name
Xliff "Cannot access memory at address 0x756d7d79206e6b18 15:31
And I had to type that out by hand! 15:32
timo ok that's odd. then let's look at print cont[0] to see if it looks reasonable or if it looks messed up 15:33
Xliff $3 = {header = {sc_forward_u = {forwarder = 0x6120746f6e6e6143, sc = {sc_idx = 1852727619, idx = 1629516911}, st = 0x6120746f6e6e6143}, owner = 1734964083,
flags1 = 110 'n', flags2 = 32 ' ', size = 28532}, st = 0x756d6d69206e6120}
timo yeah that's not an object at all 15:34
Xliff OK. Can you tell what it is?
timo can you paste the output of call MVM_dump_bytecode(tc) to gist or some pasting service? it'd be tens of lines long 15:35
IRC is not so great for multi-line output
Xliff OK. What do you need multi line of, and I'll create a gist or a pasty
timo actually we just need that one line with "assign reg_bla, reg_blubb" in it 15:36
Xliff And how can I get that?
timo call MVM_dump_bytecode(tc) 15:37
is the gdb command
Xliff OK. Creating pastebin. 15:38
pastebin.com/k5jd79Gp 15:39
timo perfect. see if reg_base[0].o is different from what we got when we did "print cont" 15:40
print reg_base[0].o
i would expect 0x7ffff79c2488 but it'd be better if it was something different
Xliff $4 = (MVMObject *) 0x3128a031728 15:46
timo now that looks more reasonable
print STABLE($4)->debug_name
Xliff Could have fooled me! :)
$5 = 0x3128f59df08 "Int" 15:47
timo well, one of the reasons is that 0x7ffff79c2488 is, or at least very suspiciously looks like, an address into the stack
Xliff So am I attempting to assing something to the Int type object?
timo let's look at print *$4 and see the flags to see if it's the type object, it's more likely an instance 15:48
Xliff $6 = {header = {sc_forward_u = {forwarder = 0x0, sc = {sc_idx = 0, idx = 0}, st = 0x0}, owner = 1, flags1 = 0 '\000', flags2 = 1 '\001', size = 40}, st = 0x3128a7334d0}
timo ok, flags1 is 0; if it's an odd number it's a type object, so that means it's an instance
we can look into the BUILDALL frame to get to know more 15:49
Xliff OK, and how can we do that?
This is where I got to when I logged into IRC
timo do this: call MVM_dump_bytecode_stackframe(tc, 1) 15:50
it will probably be much longer than the previous one, so pastebin again
Xliff Oh yes, it is.
timo if we're lucky - and i'm not sure why we sometimes aren't - we get a line that has a -> in it
but importantly, we should be seeing names of attributes and variables 15:51
Xliff And that looks like application code, but I've checked the BUILD for this object, and it supposedly exits.
timo BUILDALL is a submethod we automatically generate from the BUILDALLPLAN when a class gets composed
Xliff And yes, we are seeing attribute names.
timo it used to be a little interpreter of the build plan, but now we compile it because it go zoom instead of go snore 15:52
Xliff How can I throw that output into a file?
timo you can't copypaste from the terminal? i'll look up the gdb command that spits stuff into a file
though this goes into the stderr of the process, not exactly sure if gdb can steal that
Xliff This is a LONG list of attributes.
timo and there is no line with a -> ? 15:53
Xliff pastebin.com/RW4p7iZ7 - # Warning: LOTS of output. This is a very complex object. 15:55
timo oh hey look there's the ->
it should be the $!total-disk attrubte that's causing you trouble
Xliff OIC. Not $!free-disk? 15:56
So maybe $!total-disk is Nil? 15:57
OK. That's something to check on. Thanks!
timo oh we can output the hash that the values are coming from if you want, but i don't think it'd be nil, it should be some Int
Xliff OK, lets try! 15:58
I suspect it might not be in the hash.
timo i think the isnull a few lines further up guards against that
ok first we have to reach the hash, that should be ` print tc->cur_frame->caller->work[9].o[0] ` 15:59
that will give you a $99 to refer to this by
Xliff Hm. No it gives a $7 16:00
timo then you can ` print $99.st->debug_name ` to ensure it's actually a kind of hash
you can "print 1" 92 times then you should be at $99 :P
Xliff Yeah, "History has not yet reached $99;
timo otherwise replace $99 with $7 in my commands 16:01
Xliff $8 = 0x312959736c0 "Applications::Bizzell::Inventory::Instance"
timo ok i think i got the wrong register then
Xliff Should I try 8 or 10? 16:02
timo ah yes, we wanted work[4] rather than work[9]
9 is the object we're constructing
Xliff $10 = 0x3128a5f0240 "BOOTHash"
timo no, more accurately, 9 is the type of the object we're constructing 16:03
perfect, that's the one we want
Xliff OK. I am underatanding some of this.
OK. So how do I extract data from the BOOTHash? 16:05
timo a moment 16:06
` call MVM_str_hash_fsck(tc, &((MVMHash *)$10)->body.hashtable.table, 10) ` 16:08
.o( this really wants to become a more trivial to use function for debugging sessions ) 16:09
Xliff Hmm... I'm segfaulting with that. What member is body a part of? st? 16:21
timo no, one "outside" of st
in other words, st lives next to body, but st is a pointer and body is just a piece of the struct 16:22
was $10 wrong? it should have been the result of work[4].o
no, oops
$10 was the debug_name
it's probably $9 on your end then?
Xliff No. I had to restart. It 16:23
This is what I get from work[4].o
$14 = {header = {sc_forward_u = {forwarder = 0x0, sc = {sc_idx = 0, idx = 0}, st = 0x0}, owner = 1, flags1 = 0 '\000',
flags2 = 1 '\001', size = 32}, st = 0x4bb7c720498}
timo ah right because your call to fsck segfaulted
it's possible we're in a different spot now
because that content of register 4 there is a type object
Xliff OK, so now this is work[4].o after a restart 16:24
$17 = {header = {sc_forward_u = {forwarder = 0x0, sc = {sc_idx = 0, idx = 0}, st = 0x0}, owner = 1, flags1 = 0 '\000',
flags2 = 1 '\001', size = 32}, st = 0x3ab5e728498}
....And... that looks like a type object.
timo no, flags1 is where we have to look and that'? 0
that's 0, so concrete not type object 16:25
ok, let's verify again that $17->st->debug_name is BOOTHash or so
Xliff And it is BOOTHash, again.
timo good, then the fsck like but with $17 should work this time
Xliff so " 16:26
call MVM_str_hash_fsck(tc, &((MVMHash *)$17)->body.hashtable.table, 10) ... ?
timo that should work yeah
that'll show us the keys that have something 16:27
Xliff Still SEGV
timo the heck?
oh, can you print tc? that sometimes gets messed up
(the next time we've reached this spot, ahem) 16:28
i'm about to suggest we use moar-remote instead of gdb
Xliff $23 = (MVMThreadContext *) 0x3ab5e020280 16:29
One sec. Let me restart to make sure.
tc=0x5fb12020000 16:30
timo ok that doesn't look wrong 16:32
did it show what line it segfaulted on when you last tried it?
Xliff 0x00007ffff78378d9 in MVM_str_hash_fsck (tc=0x3ab5e020280, hashtable=0x18, mode=10) at src/core/str_hash_table.c:877 16:34
Does a MVMHash** get passed to MVM_str_hash_fsck? 16:35
timo oh that very looks wrong, yeah 16:36
Xliff &((MVMHash *)$17) -> MVMHash **
timo it's not supposed to be a MVMHash* or **, it should be the address of the hashtable that's embeded inside its body
Xliff So would that be $17.st?
timo the & is lower precedence than the -> after the closing parethesis 16:37
so you're turning $17 into an MVMHash *, then you're accessing ->body.hashtable and finally taking the address of that
but if the value that gets passed is 0x18, that's certainly not right
Xliff Yeah, but if I print $17, I don't see body
timo yeah because MVMObject doesn't have a body, but MVMHash does 16:38
Xliff Cannot access memory at address 0x3ab5e032c80
timo (gdb) print obj
$1 = (MVMObject *) 0x2bd1bd24e60
(gdb) print &((MVMHash *)$1)->body.hashtable
$2 = (MVMStrHashTable *) 0x2bd1bd24e78
m: say 0x78 - 0x60 16:39
camelia 24
timo d'oh
but that is probably where the 0x18 came from, it's only the offset. maybe $17 was actually 0 or NULL?
you're re-typing all these commands by hand? 16:40
Xliff That and using history. 16:42
So I'm currently here at frame 1: (gdb) print $29.st->debug_name 16:43
$30 = 0x5fb125f0240 "BOOTHash"
(gdb) print tc->cur_frame->caller->work[4].o[0]
$29 = {header = {sc_forward_u = {forwarder = 0x0, sc = {sc_idx = 0, idx = 0}, st = 0x0}, owner = 1, flags1 = 0 '\000',
flags2 = 1 '\001', size = 32}, st = 0x5fb12728498}
timo oh, is $29 the .o or the .o[0] because the latter might already be dereferenced? not exactly sure how that works with using history items as input for other things 16:44
Xliff .o[0]
timo ok let's try without the [0] there 16:45
Xliff print tc->cur_frame->caller->work[4].o is (MVMObject *) 0x5fb12033798
OK, so you want me to try the call with that?
timo yes, please
fingers crossed
oh wait
gdb has a kind of snapshot mechanism 16:46
Xliff So I'll be running: "call MVM_str_hash_fsck(tc, &((MVMHash *)$31)->body.hashtable.table, 10)"
timo never mind: "checkpoint: can't checkpoint multiple threads"
if $31 is equivalent to 0x5fb12033798 then yes, and if tc isn't messed up
Xliff \o/ 16:51
timo sorry that was an unnecessary amount of pain my oversight caused >_> 16:52
Xliff pastebin.com/S8Xcg8Cn # ROFLMAO!
s'okay.
BTW - This is the application server I've been writing for Raku for the last 4 years. 16:53
timo phew!
Xliff $dayJob released it!
timo awesome!
i'm not sure what was so funny about that paste though %)
Xliff Still. I need an app for it and the one it was written for still belongs to $dayJob.
Oh no. It wasn't the paste. It was your smiley.
This really isn't pain for me. I'm grateful for your help! 16:54
timo i'm glad
soon(?) App::MoarVM::Debugger will be good enough that I'd recommend it first instead of gdb
Xliff Now my largest concern for this is that I can't seem to find the line where this error is occurring. So it looks to me like it's occurring somewhere in new. Somewhere AFTER my ClassBase.BUILD and and Instance.TWEAK, but before new returns with the object. 16:55
timo if you find out why it was complaining about that one attribute, please drop a quick report so we can build a reproducer for the LTA error
Xliff ClassBase is Instance's parent.
timo yeah it's in the generated code from the buildplan
Xliff Along with other Micins.
Mixins even.
timo there's not really a source to go with it, so it doesn't actually have line numbers it could point to 16:56
Xliff So getting the attribute with the problem is still more than I had to go on.
timo in theory we could put the line numbers that any given attribute is defined on in there, but that will point all over the place for classes that have parents and mixins
Xliff Yeah. OK, so how can I get the value for "total-disk" from this MVMHash? 16:57
timo uh oh, you do need that? :S 16:58
Xliff he he he he
timo i mean, we have it in a register also at this point i think
we have the object we've tried to assign, and it comes from the hash 16:59
that should be good enough right?
Xliff Is getting the total-disk value that bad?
Is enough really enough?
timo haha 17:00
let's do the easier thing first
Xliff OK
timo in the MVM_interp_run frame again, we'd get the value we're trying to assign as work[9].o and the container it was in, if any, as work[25].o 17:01
these might be the same if it didn't have a container
we'd want to look at these objects' st again, in particular the debug_name, to see what they are
Xliff (gdb) print tc->cur_frame->caller->work[25].o[0].st->debug_name 17:02
$42 = 0x4a006710070 "VMNull"
timo if you just print the .o you'll see why i always put [0], because it just shows you the pointer value, not the struct members, so you have to ` print *$ ` or ` print $[0] ` as the next thing ($ by itself refers to the latest $99)
oh i read from the wrong part of the paste
we need 7 and/or 23 rather than 9 and 25 17:03
Xliff print tc->cur_frame->caller->work[23].o[0].st->debug_name
$43 = 0x4a00b5ba890 "Scalar"
(gdb) print tc->cur_frame->caller->work[7].o[0].st->debug_name 17:04
$44 = 0x4a00b5bda10 "Int"
timo hold on, we don't want to go to the caller frame 17:05
wait
Xliff This is frame 1
timo disregard my last message
OK we should be able to get the value of the number with ` print MVM_repr_get_int(tc, tc->cur_frame->caller->work[7].o) ` 17:06
Xliff $45 = 25821052928 -- Looks right
timo and we can get some info about the scalar, like what its descriptor looks like, though i expect it to not be very exciting, with ` call MVM_dump_p6opaque(tc, tc->cur_frame->caller->work[23].o) ` 17:07
Xliff call MVM_dump_p6opaque(tc, tc->cur_frame->caller->work[23].o) 17:08
Scalar.new(#`(from Scalar) $!descriptor=ContainerDescriptor::Untyped.new(#`(from ContainerDescriptor) $!of=(Mu), $!name='%', $!default=(Any), $!dynamic=0, $!complainee), $!value=Int.new(#`(from Int) $!valueError getting the string representation of a big integer: Buffer overflow))
???
Geth rakudo: patrickbkr++ created pull request #5700:
(Sort of) Fix is-run on Windows
Xliff OK. I'll attempt to debug this. If I run into this problem again, I should be able to continue to debug from what we've done tonight. It's a BIG help! 17:09
timo haha cool
ignore the wild output of the dump_p6opaque
Xliff I now know enough to hang myself umpteen times over! :>
Thanks for the rope.
I think I'll use it to attempt to free myself from the abyss. 17:10
timo don't hesitate to ask again
plenty of rope in my top drawer
yeah i think the code to dump bigints is just wrong; it's asking how many bits the number has, then divides that by 8 to allocate a buffer to write the string into, and tries to convert it to a base10 decimal string 17:13
we could divide by 4 and convert it to hexadecimal, that should work? since 8 bits of number translate into one two-character hex piece 17:15
otherwise there's a conversion factor, i think log2 / log10, that we need to multiply the number of bits with to get the right number of chars in the result
Xliff Why not just use log10.Int and use base10? 17:20
Actually....
Why not just use log10.Int.succ and use base10? 17:21
timo (gdb) call MVM_dump_p6opaque(tc, $19) 17:29
H�L�^▒D�T$I�Cf���t8H�E��H��HD�I�K �AH�H�rH�J▒H�FD�T$H���.new(
Thread 1 "rakudo" received signal SIGSEGV, Segmentation fault.
lmao
because it's C code ;)
(gdb) call MVM_dump_p6opaque(tc, tc->cur_frame->caller->caller->params.arg_info.source[0].o) 17:45
Foo.new(#`(from Foo) $!blorb=Scalar.new(#`(from Scalar) $!descriptor=ContainerDescriptor.new(#`(from ContainerDescriptor) $!of=(Int), $!name='$!blorb', $!default=<already seen>, $!dynamic=0, $!complainee), $!value=Int.new(#`(from Int) $!value=0x100000000000000000000000000000000)))
Scalar.new(#`(from Scalar) $!descriptor=ContainerDescriptor::Untyped.new(#`(from ContainerDescriptor) $!of=(Mu), $!name='$res', $!default=(Any), $!dynamic=0, $!complainee), $!value=Foo.new(#`(from Foo) $!blorb=Scalar.new(#`(from Scalar) $!descriptor=ContainerDescriptor.new(#`(from ContainerDescriptor) $!of=(Int), $!name='$!blorb', $!default=<already seen>, $!dynamic=0, $!complainee), 17:48
$!value=Int.new(#`(from Int) $!value=0x-BFE75246069C573EA404E45B8DDBF930C84F700E0B8A97F6099FCA6C5E92E4EBA229A0D50200F8F0F5E915DA01273A0DEE2F6D380D9CD368E2D1DD2FD7FEE9A5F174BAB7ED31A89D34CB738FD1919B8A1D31D0F684A3CDEF415E40FF11BC32F24EB66A5A))))
also works with negative values, here's one random value i picked from up to 2 ** 800 17:49
ok, fix for the "buffer overflow" in MVM_dump_p6opaque is pushed 17:55
"buffer overflow" makes it sound dangerous, but it's simply the error it returns when it reaches the end of the buffer and still has more number to write 17:56
18:49 sena_kun joined
tbrowder hi, i’m working on a new module for my upcoming advent article and was reminded once again that, as far as i know, Raku has no built-in method for converting a decimal number to a hexadecimal number. am i wrong? is there a way to use parse-base to do it? 19:29
ugexe m: say 255.base(16) 19:45
camelia FF
tbrowder ah, .base on the raw number, thanks! 20:28
21:56 sena_kun left
tbrowder 👍🏻 22:12
Xliff ===SORRY!=== Error while compiling /home/cbwood/Work/RacquetAppServer/app/lib/Racquet/Subs.pm6 (Racquet::Subs) 22:27
No such method 'protect' for invocant of type 'NQPArray'
??
Welcome to Rakudo™ v2024.10-48-g24a1cdbbb. 22:28
Implementing the Raku® Programming Language v6.d.
Built on MoarVM version 2024.10-26-gaec32b1f9.
That wasn't happening bnefore I took a nap.
patrickb timo: now that the RTL issue on Windows is solved, can we merge #5642? That's a pretty epic PR that would give us tremendously faster Windows tests and pretty test results to look at. 22:37
Xliff patrickb: I'm having some issues with the commits you've pushed. Code that was working prior will not even compile, now. 22:39
I'm attempting to isolate the commit.
Could you hold on merging until I do that? 22:40
patrickb Which commit?
Xliff That's what I'm attempting to determine. Within the last 5 hours, I would suspect.
patrickb Already merged or only in a PR? 22:41
Xliff Already merged. 22:46
patrickb Huh? The only PR I've merged is changing the azure pipelines file. That can't be related. 22:48
Xliff I'm going back further, now. Still getting this: 22:51
===SORRY!=== Error while compiling /home/cbwood/Work/RacquetAppServer/app/units/test-instance.raku 22:52
New type Block for List is not a mixin type
===SORRY!=== Error while compiling /home/cbwood/Work/RacquetAppServer/app/units/test-instance.raku
New type Block for List is not a mixin type
Which is definitely NOT what I was getting 5 hours ago.
OK, I guess if I am going backwards you can proceed with your merge. Just this issue is odd and it's in the code for a production system. 22:53

Powered by Cro and the Raku® Programming Language.

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

Thank you!