🦋 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: ... | log inspection situation still under development | For MoarVM see #moarvm
Set by lizmat on 22 May 2021.
Geth tap-harness6: 1ececb26f2 | (Leon Timmermans)++ | 2 files
Fix Supplier name in Output::Supplier
00:00
tap-harness6: 6fb155162e | (Leon Timmermans)++ | 3 files
0.3.1
00:09 reportable6 left 00:12 reportable6 joined 00:52 evalable6 joined 01:35 frost joined 01:42 frost left 02:27 frost joined 02:39 frost left 03:10 frost joined 03:13 discord-raku-bot left, discord-raku-bot joined 03:17 discord-raku-bot left, discord-raku-bot joined 03:20 frost left 04:10 frost_ joined 04:14 frost_ left 04:16 frost joined 04:20 frost left 04:23 frost joined 04:30 frost left 05:10 frost joined 05:25 Kaipi joined 05:30 sjn_ joined 05:35 discord-raku-bot left, kjp left 05:37 RakuIRCLogger__ joined 05:38 RakuIRCLogger left 05:39 sjn_ left 05:40 discord-raku-bot joined, kjp joined, Altai-man joined, TempIRCLogger joined, japhb joined, Geth joined, sjn joined 06:08 reportable6 left 06:14 frost left 07:10 reportable6 joined 08:03 patrickb joined, patrickb left 08:12 patrickb joined
patrickb japhb: I have just seen the latest RSC minutes and the question about the state of the CI bot grant. The grant hasn't stalled. It is progressing slower than anticipated though. Latest report is here: news.perlfoundation.org/post/2021-...ant-update 08:17
tellable6 2021-12-19T14:46:51Z #raku <SmokeMachine> patrickb sorry I haven’t seen your issue before, but I’ve just answered: github.com/FCO/Red/issues/539#issu...-997403720
2021-12-19T14:56:28Z #raku <SmokeMachine> patrickb also this one: github.com/FCO/Red/issues/538#issu...-997405831
patrickb Am I assuming correctly, that we have no analytics whatsoever on rakudo.org and raku.org at the moment? 08:42
If yes, what do people think about adding goatcounter.com to both of them? 08:43
nine patrickb: oh, that report's a joy to read :) Thanks for doing the right thing (TM) about bugs you encounter. That may not be what the grant is actually about, but it's a great service to our users. 08:47
OTOH what's the point of CI if not to catch bugs? :D So this may very well be on topic
MasterDuke patrickb: does raku have a large userbase among goats? i would prefer we count visits by people 08:52
patrickb :-P But how could you know whether there are people or goats sitting in front of all those keyboards? I remain with goatcounter being just as legitimate a name as peoplecounter. 08:54
MasterDuke en.wikipedia.org/wiki/On_the_Inter...et_dog.jpg 08:56
nine MasterDuke: honestly, if goats find our software useful, I'm ok with that. 08:57
patrickb: I'm curious about that NativeCall issue... 09:01
MasterDuke nine: i'll have to look for a means to use raku next time i play goat simulator 09:03
nine patrickb: of course I cannot reproduce it locally... Can you still? 09:06
patrickb nine: I can't. 09:16
nine Not in the full app either? 09:17
patrickb This is a bit frustrating, as that golf is about 1.5 hours worth of golfing...
I'll try...
nine: I got a repo with the full app. 09:37
nine darn
patrickb Took 12 runs
nine: Are you interested in an explanation on how to set this up? Alternatively, would you recommend me to invest time in golfing this down once more? 09:42
nine I fear a golf would be much more useful, since it's hard to reproduce, will want some rr, etc. 09:45
patrickb OK 09:46
nine: I might still have the RR record lying around. Is that of any help? 10:03
10:23 frost joined 10:35 frost left
nine Only if you have exactly the same MoarVM + rakudo + OpenSSL installation to go with it. Unfortunately rr recordings do not include the program code and if the latter just differs slightly from the time of the recording rr will usually break 10:36
patrickb I just tried `rr replay` and it does run through. 10:39
nine Okidoki....so the first challenge would be to set a break point at the place where we notice things to go wrong 10:42
patrickb there is a print "Unable to read key" 10:43
can I break on stdout/err?
Uhm... there is also the warning: "warning: .dynamic section for "//home/patrick/rrepos/install/lib/libmoar.so" is not at the expected address (wrong library or version mismatch?)" 10:47
Will that mess things up?
wait 10:48
nine potentially yes
I'm not aware of a way to break on output
patrickb ugh
nine How is that printed?
patrickb the warning or the Unable to read key?
nine Unable to read key 10:49
patrickb die "Unable to read key" unless defined($rsa);
nine Maybe a break on MVM_exception_throw_adhoc will trigger
MasterDuke MVM_exception_die 10:50
patrickb ok. Lots of "unrecorded signal" warnings. I guess this won't do.
I'll try to get a live repro again. I'll report back if / once I succeed. 10:51
nine Well, if you've got to reproduce again anyway, you can at least make debugging easier, e.g. by putting something like nqp::sin_n(1e0) into a place where you want to break. Then place the break point on the sin_n implementation in src/core/interp.c 10:52
patrickb ok
10:53 frost joined 11:39 sena_kun joined 11:55 frost left 12:07 reportable6 left
patrickb nine: I can repro with a rakudo/MoarVM master as of 2021-11-27 and have it captured in rr, have put in a sin_n and have rr break on that sin_n right before the call to OpenSSL::PEM::PEM_read_bio_RSAPrivateKey (the call that fails to do what it should). 12:09
nine nice! 12:11
Btw. why the old master? 12:12
patrickb That's the build that was still lying around 12:16
I did a build with latest master and it didn't fail. I suspect it's not really fixed by latest master though as there are no changes in MoarVM since then that look like they could have fixed it and the bug is depending on soft factors (as can be seen by not failing any more on 2021.09). 12:17
So I think it's still worth debugging on this older build even though there is a chance it turns out to have already been fixed. 12:18
12:19 frost joined
nine Ok, so PEM_read_bio_RSAPrivateKey fails. What's the failure mode? Missing return value? 12:25
patrickb yes
nine What does the bytecode of the frame calling PEM_read_bio_RSAPrivateKey look like? 12:26
patrickb rr somehow still throws exceptions when stepping through the code. Should I try fixing rr or is there a chance of doing this with gdb?
How do I find out?
12:26 frost left
nine call MVM_dump_bytecode(tc) 12:26
patrickb paste.sr.ht/~patrickb/2935953d1e8a...a89c3afbdf 12:29
paste.sr.ht/~patrickb/47d0186b2afd...3a31763the corresponding raku code: 12:31
nine So this should be the failing call: 00081 dispatch_o loc_3_obj, 'lang-call', Callsite_8, loc_5_obj, loc_1_obj, loc_9_obj, loc_8_obj, loc_3_obj 12:34
Can you advance to just after this call and then have a look at what's in tc->cur_frame->work[3].o?
You can probably just set a break point at PEM_read_bio_RSAPrivateKey (should have thought of this earlier...) and then finish frames until you are back in src/core/interp.c
patrickb is trying 12:35
nine I find it odd that this is clearly unspeshed code while your bugreport says that with spesh disabled the bug bug disappears. 12:40
12:42 frost joined
bartolin Hmm, reading this I can't help to think of github.com/sergot/openssl/issues/82 and github.com/sergot/openssl/issues/87 which I tried to debug last year. The installation of OpenSSL failed (but not reliably) -- seemingly in the same place. My guess back then was that precomplication was somehow involved with these failures. 12:43
(hopefully this doesn't point you in the wrong direction and distract you from the real problem) 12:44
nine Looks like different issues 12:47
patrickb back in interp.c I am now looking at OP(return_o)
Have I mis-stepped? 12:48
nine You can always dump bytecode to see where you are. There's also call MVM_dump_backtrace(tc) 12:49
You could be in the dispatch program 12:50
patrickb that small arrow points to the currently executing op?
That's pointing at 00082 -> decont loc_3_obj, loc_3_obj 12:51
nine Sort of, mostly 12:54
patrickb stepping over the return_o I am now actually in the OP(decont) 12:55
nine on a good day
The one that's following the dispatch_o? Then yes, the return was in the dispatch program. Now tc->cur_frame->work[3].o is of interest
patrickb {header = {sc_forward_u = {forwarder = 0x550000001e, sc = {sc_idx = 30, idx = 85}, st = 0x550000001e}, owner = 1, flags1 = 1 '\001', flags2 = 2 '\002', size = 24}, st = 0x41a72f8} 12:56
nine What's in st?
patrickb {header = {sc_forward_u = {forwarder = 0x100000001e, sc = {sc_idx = 30, idx = 16}, st = 0x100000001e}, owner = 1, flags1 = 2 '\002', flags2 = 2 '\002', size = 168}, REPR = 0x7ffff7e41ec0 <CPointer_this_repr>, REPR_data = 0x0, size = 32, type_check_cache_length = 3, mode_flags = 0, type_check_cache = 0x34be6d0, type_cache_id = 849920, container_spec = 0x0, container_data = 0x0, boolification_spec = 0x34be6f0, hll_owner = 0x4dd190, hll_ro
what does st stand for?
nine STable
The object's flags1 is 1, which is MVM_CF_TYPE_OBJECT, so you got a NULL pointer there 12:58
Did PEM_read_bio_RSAPrivateKey really return NULL?
patrickb now I regret not having rr working...
nine s/got a NULL/got a CPointer type object which stands for NULL/
Oh, that's in gdb? Bummer :(
patrickb It's reproducible 12:59
but yes, somehow rr fails as soon as I start stepping
nine And with a break point on PEM_read_bio_RSAPrivateKey you should find the right spot quickly
patrickb true, as I previously did
nine Locally I use an rr built from source, so I always get the latest bug fixes
Still sometimes happens that a replay crashes but works when tried again. I guess rr does some really deep magic 13:00
patrickb AFK for a bit. Back in a few minutes...
13:11 sena_kun_ joined 13:13 sena_kun left 14:11 reportable6 joined
Geth rakudo: 186bd0b026 | (Elizabeth Mattijsen)++ | src/core.c/Any-iterable-methods.pm6
Rename Any.infer to Any.are

By popular request, also make sure that anything that has an
  .iterator method will work, not just Lists
14:45
14:52 frost left 14:55 discord-raku-bot left, discord-raku-bot joined 15:19 RakuIRCLogger__ left, lizmat left, Geth left 15:20 TempIRCLogger left 15:29 TempIRCLogger joined 15:30 lizmat joined, RakuIRCLogger joined 15:34 RakuIRCLogger left 15:35 RakuIRCLogger joined 15:46 TempIRCLogger left, RakuIRCLogger left 15:48 lizmat left 15:49 TempIRCLogger joined 16:03 Geth joined 16:11 discord-raku-bot left 16:12 discord-raku-bot joined, cognominal joined
patrickb nine: I think I found the error. It's a bug in our OpenSSL wrapper. The `BIO_new_mem_buf` creates a BIO struct and copies the Buf pointer passed as the first argument into it. My golf (just as the OpenSSL wrapper) passes `$key.encode` and thus Rakudo subsequently frees that Buf and leaves the BIO with a broken buf. 16:47
nine: According to the OpenSSL docs BIO_new_mem_buf does not take ownership of that buf. So the solution can't be to put `explicitly-manage()` around the arg. 16:49
Is there a way to guarantee that Rakudo will not GC-more a Buf around? I.e. I could just keep the Buf alive in Rakudo land by holding it in a variable. But I need to guarantee that that pointer that escaped into C land stays valid. Can I do that somehow? 16:51
lizmat if the Buf is big enough, it doesn't get created in the nursery? 16:53
nine patrickb: for that pointer to stay valid, the Buf object must be kept alive. And it must stay the same size (otherwise the VMArray may realloc the buffer).
lizmat ok, scratch my idea :-) 16:54
nine The buffer itself that's pointed at is malloced, so no worry about that.
patrickb I think my understanding of moar is flawed. Doesn't the GC shuffle about everything around as it likes? Are Bufs special? 16:57
nine Raku's Bufs (and Blobs) are REPR VMArray. VMArrays are GC-able 6model objects. They consist of the common header, and a body: github.com/MoarVM/MoarVM/blob/mast...rray.h#L39 17:01
The body then contains some information about the size of the array and the actual pointer to the memory holding the elements: github.com/MoarVM/MoarVM/blob/mast...Array.h#L8
This slots array is plain malloced memory and the GC doesn't care about this. The GC only cares about the object holding that pointer. C code just gets passed the pointer to the slots array 17:02
The slots array gets freed when the VMArray objects gets freed. This is by way of the GC calling the object's gc_free method which takes care of such things: github.com/MoarVM/MoarVM/blob/mast...ray.c#L112 17:04
patrickb I think I understand.
Does that general principle apply to all things one can pass to native functions? 17:05
patrickb starts to suspect this is one of the things all that REPR stuff is about. 17:06
nine Yes. We never actually pass a pointer to an MVMObject to C code. It depends on the REPR what the C code actually sees. Strings for example go through MVM_string_utf8_encode_C_string or the like. For integers, we pass whatever MVM_repr_get_int returns on that object. 17:10
17:10 dogbert17 left
patrickb nine: Nice. Then I think I know how to fix this bug. Thank you for explaining so much to me! 17:17
17:20 dogbert17 joined
nine You're welcome :) 17:50
17:54 [Coke] left 17:58 [Coke] joined 18:08 reportable6 left 18:09 reportable6 joined 18:15 Geth left, Geth joined 18:26 nebuchad` joined 18:27 SmokeMachine_ joined, kawaii__ joined, childlikempress joined, leont_ joined 18:29 sena_kun_ left 18:30 sjn_ joined 18:31 djinni`_ joined 18:32 moon-chi- joined 18:34 childlikempress left, sjn left, nine left, kawaii_ left, djinni` left, moon-child left, SmokeMachine left, nebuchadnezzar left, leont left, rba left, cognominal left, RakuIRCLogger left, sena_kun_ left, kjp left, Altai-man left, japhb left, patrickb left, MasterDuke left, bartolin left, lucs left, tonyo left, ugexe left, camelia left, zostay left, SmokeMachine_ is now known as SmokeMachine, kawaii__ is now known as kawaii_, rba_ is now known as rba, leont_ is now known as leont 18:35 sjn left, nine left, kawaii_ left, djinni` left, moon-child left, SmokeMachine left, nebuchadnezzar left, leont left, rba left, Skarsnik left, CIAvash left, eof left, Geth left, dogbert17 left, lizmat left, Voldenet left, gfldex left, maettu_ left, sivoais left, AlexDaniel left, JRaspass left, jdv left, masak left, samcv left, timo left, jjatria left, ilogger2 left, andinus left, samebchase left, [Tux] left, TempIRCLogger left, rypervenche left, tbrowder left, Util_ left, reportable6 left, [Coke] left, discord-raku-bot left, Kaipi left, evalable6 left, linkable6 left, squashable6 left, qorg11 left, sourceable6 left, quotable6 left, statisfiable6 left, unicodable6 left, notable6 left, committable6 left, releasable6 left, tellable6 left, bloatable6 left, benchable6 left, bisectable6 left, nativecallable6 left, coverable6 left, shareable6 left, greppable6 left, codesections left, vrurg left 18:38 discord-raku-bot left, discord-raku-bot joined, sjn_ joined, nebuchad` joined, cognominal joined, RakuIRCLogger joined, patrickb joined, japhb joined, Altai-man joined, kjp joined, MasterDuke joined, camelia joined, bartolin joined, lucs joined, tonyo joined, ugexe joined, zostay joined 18:39 moon-chi- joined, djinni`_ joined, nine_ joined, leont joined, kawaii_ joined, SmokeMachine joined, rba joined, Geth joined, reportable6 joined, [Coke] joined, dogbert17 joined, TempIRCLogger joined, lizmat joined, Kaipi joined, evalable6 joined, linkable6 joined, squashable6 joined, qorg11 joined, sourceable6 joined, quotable6 joined, statisfiable6 joined, unicodable6 joined, notable6 joined, committable6 joined, releasable6 joined, tellable6 joined, bloatable6 joined, benchable6 joined, bisectable6 joined, nativecallable6 joined, coverable6 joined, shareable6 joined, greppable6 joined, CIAvash joined, codesections joined, AlexDaniel joined, vrurg joined, Skarsnik joined, sivoais joined, maettu_ joined, gfldex joined, Voldenet joined, eof joined, masak joined, jdv joined, JRaspass joined, [Tux] joined, samebchase joined, andinus joined, timo joined, samcv joined, ilogger2 joined, jjatria joined, Util_ joined, tbrowder joined, rypervenche joined 18:40 discord-raku-bot joined 19:42 bloatable6 left, nativecallable6 left, coverable6 left, statisfiable6 left, notable6 left, sourceable6 left, reportable6 left, quotable6 left, greppable6 left, linkable6 left, bisectable6 left, evalable6 left, releasable6 left, benchable6 left, tellable6 left, committable6 left, shareable6 left, squashable6 left, unicodable6 left, evalable6 joined 19:43 greppable6 joined, benchable6 joined, committable6 joined, notable6 joined, nativecallable6 joined 19:55 moon-chi- is now known as moon-child 20:01 discord-raku-bot left, discord-raku-bot joined
gfldex m: (^∞).hyper.map({ last }); 20:03
camelia (signal XCPU)
gfldex Should that terminate properly? 20:04
lizmat interesting :-)
ugexe im imagine last short-circuits as soon as it can, but that might mean the other units of work need to get finished (but that no more would be created) 20:06
and of course all the other work is also infinite 20:07
well no, nevermind thats not right
gfldex usecase: gist.github.com/7b2f312317dc7a598c...367a05f3fd 20:08
Should I Rakudobug?
ugexe it looks like it works for `for` though 20:10
20:38 nine_ is now known as nine 20:42 bloatable6 joined 20:43 coverable6 joined, statisfiable6 joined 20:44 quotable6 joined, unicodable6 joined, bisectable6 joined
gfldex m: my atomicint $bail = 0; (^∞).hyper.map({ say $bail⚛++; last if $bail > 3; }); 21:02
camelia (signal XCPU)0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49…
gfldex The map seems to respect last, but the iterator that spawns batches doesn't know. 21:03
We are not really good at stopping threads in general. 21:04
filed as RT#4712 21:07
Geth rakudo/rakudo-4711: 28b512380b | (Vadim Belman)++ | src/Perl6/World.nqp
Make add_constant lookup setting symbols only

The compiler is only uses this method with core types. Limiting lookups to setting only prevents LTA errors in user code.
Fixes #4711
21:23
rakudo: vrurg++ created pull request #4713:
Make add_constant lookup setting symbols only
21:42 tellable6 joined 21:43 sourceable6 joined, reportable6 joined 21:44 shareable6 joined 21:45 releasable6 joined
Geth rakudo: 28b512380b | (Vadim Belman)++ | src/Perl6/World.nqp
Make add_constant lookup setting symbols only

The compiler is only uses this method with core types. Limiting lookups to setting only prevents LTA errors in user code.
Fixes #4711
22:01
rakudo: 94b9d497ef | (Vadim Belman)++ (committed using GitHub Web editor) | src/Perl6/World.nqp
Merge pull request #4713 from rakudo/rakudo-4711

Make add_constant lookup setting symbols only
japhb (backlogging) Ah, thank you patrickb for the clarity on the CI bot grant. Glad to know it's not stalled. :-) 22:31
23:44 linkable6 joined 23:52 Xliff joined