|
🦋 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
|
|||
