00:13 Kaiepi left 00:16 Kaiepi joined 01:40 Xliff left
ShimmerFairy I just noticed that S01-perl-5-integration/basic.t claims that { use v5; ... } isn't possible, but modify_inside_p5.t and modify_inside_p5_p6.t say you can. I'm having trouble seeing the difference. 03:23
timotimo i think that's a very recent feature? 05:15
Geth nqp: c814d3a6d5 | (Ben Davies)++ | src/vm/jvm/runtime/org/raku/nqp/io/AsyncServerSocketHandle.java
[jvm] Pass correct connection port in nqp::asynclisten

Before, it was passing the server's port, not the connection's port.		 05:36
nqp: c94da0e7a8 | (Christian Bartolomäus)++ (committed using GitHub Web editor) | src/vm/jvm/runtime/org/raku/nqp/io/AsyncServerSocketHandle.java
Merge pull request #514 from Kaiepi/async-sockets

  [jvm] Pass correct connection port in nqp::asynclisten
ShimmerFairy m: { use v5; } 05:55
camelia 5===SORRY!5=== Error while compiling <tmp>
Too late to switch language version. Must be used as the very first statement.
at <tmp>:1
------> 3{ use v57⏏5; }
ShimmerFairy So is one of them wrong, or are they both somehow right? 05:56
06:38 JJMerelo joined 06:44 Kaiepi left 06:48 Kaiepi joined 06:52 domidumont joined
nine Recent Inline::Perl5 supports { use v5-inline; ... } github.com/niner/Inline-Perl5/blob...5-inline.t 06:59
ShimmerFairy I would suggest that we drop 'use v5;' from the standard (future versions at least) since we're not even called Perl 6 anymore, but I don't know what most people would think. 07:10
07:37 JJMerelo left 08:03 tailgate joined 08:50 sena_kun joined 09:25 raku-bridge left, tyil left 09:26 raku-bridge joined, raku-bridge left, raku-bridge joined 09:27 tyilanmenyn joined 09:44 Geth left, Geth joined 09:45 raku-bridge left, tyilanmenyn left 09:47 tyilanmenyn joined, raku-bridge joined 09:49 tyilanmenyn is now known as tyil 10:13 lichtkind joined 10:27 Altai-man_ joined 10:30 sena_kun left 12:28 sena_kun joined 12:30 Altai-man_ left
tbrowder lizmat: i need some advice ref pod decl blocks, pls 12:47
lizmat I'm not sure I have anything sensible to say about that
tbrowder since the current code has an incomplete (interim) fix for it, i see having three states: current default (legacy), current attempt toward a fix (interim), and the goal the correct S26 fix (preserve). 12:50
any of the three behaviors should be selectable by a compiler option or an env var. 12:51
the current ross 12:52
lizmat I would have a slight preference for an env variable
as you could change those from "inside" a program
[Tux] next perl5 release will have all CORE references to "Perl 6" replaced with "Raku". My branch will be merged today 12:53
tbrowder *roast currently tests the legacy and interim behaviors so nothing needs to change for the moment.
[Tux] is surprised to see lizmat around. that was a *short* break! 12:54
tbrowder after my PR which will provide all three option, i will start adding a new set of tests for the correct behavior.
lizmat [Tux]: please do not take my being around to mean anything other than that I'm around now 12:55
[Tux] ok
[Tux] sends hugs anyway 12:56
tbrowder after that, you can decide when to deprecate or otherwise make the correct behavior the default or roll back if some user needs to use legacy behavior.
lizmat [Tux] thanks 12:57
tbrowder both compiler option and envvars are provided for all three states 12:58
lizmat then we're good ?
tbrowder hugs are good, and i have the solution for what i just stated. a complete solution is in my current PR (except for the new tests). 13:02
i should be able to push it in a couple of days. 13:03
i just want to make sure my plan makes sense. 13:04
lizmat sounds ok to me so far :-) 13:05
but the proof is always in the PRudding
:-)
[Tux] Rakudo version 2020.05.1-206-g986f8ab6b - MoarVM version 2020.05-17-g6c30ffed8
csv-ip5xs0.836 - 0.887
csv-ip5xs-208.314 - 8.553
csv-parser26.257 - 26.893
csv-test-xs-200.387 - 0.392
test8.271 - 8.369
test-t1.828 - 1.900
test-t --race0.816 - 0.833
test-t-2030.517 - 30.832
test-t-20 --race9.020 - 9.229
 13:07
tbrowder yepPR :-D 13:12
bye, hope you feel better soon 13:13
lizmat thanks, I hope so too
nine So, the failure to call VMNull seems to happen when exceptions get thrown and the code tries to look up &EXCEPTION, but not because the sub somehow gets lost but because the string passed to getlex_no is bogus 13:57
(rr) call MVM_cu_string(tc, cu, GET_UI32(cur_op, 2))
$5 = (MVMString *) 0xde
jnthn Wow. 13:58
Is the string index utterly bogus?
nine Thread 1 hit Breakpoint 2, MVM_cu_string (tc=0x89bde0, cu=0x935120, idx=1529) at src/core/compunit.h:9 13:59
1529 looks reasonable
jnthn Yeah
Though you can also check the number of 'em in cu
nine num_strings = 2137
jnthn They are lazily decoded
nine cu->body.strings[1529] is 0x0 14:00
so it enters MVM_cu_obtain_string 14:01
jnthn So far so normal.
nine It gets a reasonable entry from the fast table and then iterates to the actual index 14:04
ss is 20
which means a size of 10 which matches &EXCEPTION 14:05
and indeed cur_pos + 4 is (MVMuint8 *) 0x1ec945b8 "&EXCEPTION" 14:06
so the string heap in the bytecode is fine
Ok, apparently the result rr prints is just bogus. A breakpoint in MVM_frame_find_lexical_by_name shows a good string 14:08
Though a debug fprintf in MVM_frame_find_lexical_by_name never actually printed &EXCEPTION either 14:09
14:21 lucasb joined 14:27 Altai-man_ joined 14:29 sena_kun left
nine Maybe not finding &EXCEPTION is a red herring. In a working build we don't even try to find it until stage optimize. I.e. the actual exception doesn't get thrown. The exception is "Method 'nativesize' not found for invocant of class 'Perl6::Metamodel::GenericHOW'" 14:44
The call is (T.^nativesize / 8).Int in Buf.pm6:27 14:46
So....how could this fit together with me trying to share MAST::Frame's between inner and outer compiler? 14:48
vrurg nine: is it the same problem where lost outer was a suspect? 14:49
nine We're probably currently compiling "constant blob8 = Blob[uint8];" but apparently somehow the role body gets executed with a Generic instead of the uint8 now
vrurg: yes and no. I found out why there was no outer and got a fix for that. But to get the fix (load_setting in the deserialize frame) working, I need to share this frame between outer and nested compiler and to do that I need to share the comp unit's frames list in all cases 14:51
But if I do that, settings compilation fails with refusal to execute a VMNull. Which is an issue with exception handling during settings compilation with the exception being what I just described
vrurg I see. Familiar situation with 'pull a string, destroy the house'. 14:53
nine But even though it wasn't the same bug, the patch you dug out helped me understand what's going on, so thanks for that! 14:55
vrurg Welcome! I wonder why load_setting is needed? BEGIN actually must share its outer with the compunit, doesn't it? 14:56
nine I'm working on precompilation of raku { } blocks in Perl 5 modules into Raku modules that use them. In this case the setting is actually the correct outer for those blocks. I can't use anything else anyway since e.g. the caller's frame isn't even fully parsed at that point (it happens in a use statement) 14:58
So adding that load_setting with the forceouterctx is the right solution and trivial to do. It's just that currently the inner comp unit gets its own deserialization frame which never gets run since that inner comp unit never gets written to the bytecode file. 15:00
Geth rakudo: 6ead4ce16a | (Tom Browder)++ (committed using GitHub Web editor) | src/Perl6/Optimizer.nqp
Perl 6 _
 15:36
nine I think I got it! 15:42
of not
or not
16:28 sena_kun joined 16:30 Altai-man_ left 16:38 ShimmerFairy left 16:39 ShimmerFairy joined 16:53 domidumont left 17:15 sena_kun left 17:16 sena_kun joined 17:31 patrickb joined
patrickb o/ 17:38
Can someone with permissions to edit the problem-solving repo please take PR#20 to the review phase by adding reviewers?
.tell tony-o I'm still interested in your revamp of the ecosystem. Are you still planing on going forward with that? 17:39
tellable6 patrickb, I'll pass your message to tony-o
17:59 Xliff joined
patrickb I want to work on NQP#637, but haven't done much with NQP up to now. Whats 18:05
linkable6 NQP#637 [open]: github.com/Raku/nqp/issues/637 AzureCI test failures
patrickb What's the best place to look for documentation?
Currently I need an NQP way to do `$*PROGRAM` 18:06
That was wrong I need `$*EXECUTABLE` in NQP. 18:13
Found it: `nqp::execname()`. :-) 18:14
[Coke] patrickb: github.com/rakudo/rakudo/blob/mast...ss.pm6#L12 18:16
patrickb++
some (not all) nqp ops are also documented in nqp repo. github.com/Raku/nqp/blob/master/do...me-moar-js 18:17
18:27 Altai-man_ joined 18:30 sena_kun left 18:37 patrickb left 18:39 patrickb joined 18:54 patrickb left 19:31 Altai-man_ left
tbrowder o/ 19:40
is there any way to get a nice exception for an invalid compiler option input? all i see in Compiler.nqp is a panic. 19:42
i haven't looked at Compiler.pm6 yet... 19:43
19:45 patrickb joined
nine So, I've now got two cases where sharing frames between compilation units leads to lexicals not being found. In this second case GET_LEX(cur_op, 2, f) returns a NULL 19:46
tbrowder nothing there. stuff in World.nqp looks hairy but can that syntax be used in Compiler.nqp? 19:47
Geth nqp: patrickbkr++ created pull request #640:
Fix t/nqp/114-pod-panic with a relocated `nqp` executable		 19:49
nine Wait a minute! It's looking for lex_Frame_2116_lex??_obj 1 frame out, but that frame is actually Frame_2169 20:09
In both cases we have nested code blocks. The Buf one was a try and this time it's one passed to sequential-map in !grep-callable 20:10
timotimo not with "getlexvia" either, right? 20:12
nine getlex_no and getlex respectively
timotimo OK 20:13
i don't actually remember exactly how the names are made in the dumper
but that could give an interesting result
possibly based on outers?
i mean, probably
nine Ah, no, I just dumped the caller frame instead of the outer 20:15
timotimo is that why there's so many ?? all the damn time 20:18
lol
nine Ha! I've just looked at that. But I've just replaced the ?? with idx, as I have that at hand anyway when debugging 20:23
20:27 patrickb left 22:09 raiph 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!