github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:09 lucasb left 01:12 ggoebel left 07:11 domidumont joined 07:21 patrickb joined 07:30 zakharyas joined
patrickb .tell pamplemousse In your latest blog post you wrote that one currently can't call `moar` but has to call `perl6`. I believe this will always be so. Reason: The setup necessary to compile or call a perl6 program requires knowledge of where the perl6 libraries are located. That information is encoded in the `perl6` executable and not available anyw 07:55
yoleaux 24 Jun 2019 16:14Z <ugexe> patrickb: blead is not a typo. see dev.perl.org/perl5/source.html for instance
patrickb here else (it can't be).
yoleaux patrickb: I'll pass your message to pamplemousse.
24 Jun 2019 18:30Z <AlexDaniel> patrickb: it wasn't really a typo, it was meant to be that way
patrickb .tell pamplemousse Thus the only way forward I see is running the bytecode with the `perl6` executable and not the `moar` executable. I'm not sure if the `perl6` executable is currently able to run bytecode directly, but it could be extended to do so. 07:58
yoleaux patrickb: I'll pass your message to pamplemousse.
patrickb .tell pamplemousse If you need to know more about what setup steps the `perl6` executable does do ask! 08:01
yoleaux patrickb: I'll pass your message to pamplemousse.
patrickb .tell pamplemousse In addition and unrelated to the above there is the initialization part you also talk about in your post. I know little about that. niner might be the right person to ask. 08:05
yoleaux patrickb: I'll pass your message to pamplemousse.
08:45 squashable6 left 08:48 squashable6 joined 09:45 brrt joined 09:52 brrt left 10:06 domidumont left 10:48 brrt joined
brrt \o 10:54
nwc10 o/
brrt ohai nwc10 11:01
11:45 brrt left 11:55 domidumont joined 12:01 zakharyas left 12:08 brrt joined 12:14 ggoebel joined 12:28 squashable6 left 12:31 squashable6 joined 12:39 brrt left 12:52 squashable6 left 12:55 squashable6 joined, zakharyas joined 13:46 sena_kun joined 13:54 pamplemousse joined
dogbert17 heh, MoarVM panic: Corrupt multi dispatch cache: cur_node != 0, re-check == (nil) 14:15
patrickb ping pamplemousse 14:21
MasterDuke dogbert17: wow, never seen that before 14:26
14:26 pamplemousse left, pamplemousse joined
dogbert17 MasterDuke: got it when running t/spec/S17-supply/syntax.t. Having a hard time reproing it though :( 14:27
MasterDuke hm, that one's known to have problems, correct? though i don't remember seeing that particular error ever 14:28
dogbert17 yes, there's something odd going on with that file but it's very intermittent 14:30
pamplemousse o/ 14:36
yoleaux 07:55Z <patrickb> pamplemousse: In your latest blog post you wrote that one currently can't call `moar` but has to call `perl6`. I believe this will always be so. Reason: The setup necessary to compile or call a perl6 program requires knowledge of where the perl6 libraries are located. That information is encoded in the `perl6` executable and not available anyw
07:58Z <patrickb> pamplemousse: Thus the only way forward I see is running the bytecode with the `perl6` executable and not the `moar` executable. I'm not sure if the `perl6` executable is currently able to run bytecode directly, but it could be extended to do so.
08:01Z <patrickb> pamplemousse: If you need to know more about what setup steps the `perl6` executable does do ask!
08:05Z <patrickb> pamplemousse: In addition and unrelated to the above there is the initialization part you also talk about in your post. I know little about that. niner might be the right person to ask.
pamplemousse patrickb: Thank you for your ideas, I really appreciate the feedback
Right now, I'm feeling a bit lost and am unsure of what direction to go. I definitely think I'm missing some details on the setup steps the `perl6` executable does and would really appreciate any information you have on that/can point me at or there are specific parts in the code I could be pointed towards. I think that could provide a lot of guidance as to what my immediate next steps need to be.
If it does make more sense to continue to call the `perl6` executable, I'm also going to need to find some way to run bytecode directly, as you mentioned. I'm currently trying to figure out how that process currently happens since perl6 has to be talking with moarvm to make and run the bytecode at some point currently. Is that exposed anywhere that I could look at? 14:37
patrickb pamplemousse: That's the source of the perl6 executable: github.com/rakudo/rakudo/blob/mast...ner/main.c 14:43
pamplemousse: NQP_HOME="path/to/share/nqp/" PERL6_HOME="path/to/share/perl6" moar --execname="path/to/where/perl6/is/located" --libpath="path/to/share/nqp/lib" --libpath="path/to/share/perl6/lib" --libpath="path/to/share/perl6/runtime" "path/to/share/pelr6/runtime/perl6.moarvm" my_perl6_file.p6 14:45
That's a rough equivalent of what the perl6 executable actually does. 14:46
So in principle you can use the above command to run a .moarvm file. 14:52
NQP_HOME="path/to/share/nqp/" PERL6_HOME="path/to/share/perl6" moar --execname="path/to/where/perl6/is/located" --libpath="path/to/share/nqp/lib" --libpath="path/to/share/perl6/lib" --libpath="path/to/share/perl6/runtime" "path/to/your/bytecode.moarvm" 14:53
pamplemousse Neat, thank you 14:54
patrickb As far as I know that will then fail with an error message caused by the missing initialization stuff that you wrote about in your blog.
Oh, and there is an error in there. --execname needs to point to the perl6 executable itself, not the folder it's in: --execname="path/to/where/perl6/is/located/perl6" 14:55
14:56 lucasb joined
pamplemousse I'll try that and see if I can get it to fail at the initialization bit. I guess right now what I'm trying to decide/figure out is if it's better to try to do the initialization and adding the knowledge of where libraries are located to something that is run as part of the ELF or if it's better to call perl6 from the ELF file, let it handle all that, and figure out how to get it to run bytecode that's embedded in the ELF. 15:03
patrickb I recommend you try to get it working with the above command (directly using moar) and deal with using `perl6` instead of that huge command later on.
You won't be able to determine where the libraries are located. Depending on how perl6 was compiled these paths are hardcoded into the perl6 executable (and can be whatever was specified when building it) or are relative to where the perl6 executable is located. 15:06
Thus in the end you will have to use the perl6 executable (as long as you don't bundle all rakudo and nqp libraries into the elf files). 15:09
pamplemousse Yeah, right now I'm just trying to bundle up the program itself. A fully self contained executable as an option is a goal for the future but not at the moment. 15:11
nine pamplemousse: IIRC you're trying to fatpack executables that contain precompiled Perl 6 code and link moarvm, right? I think you're approaching it from the wrong end, making your job harder.
patrickb But as I said, I wouldn't deal with that now. Just use the above command to call moar.
pamplemousse nine: Yes, that's right. And yeah, it's definitely starting to feel like I'm working from the wrong direction 15:12
nine pamplemousse: I think the better first step would be to implement something in nqp that will run a precompiled Perl 6 file, i.e. find out what initialization is currently done implicitly by the compiler. 15:13
I.e. an alternative to rakudo/src/main.nqp
One part of initialization I definitely know is loading the Bootstrap and loading the setting: github.com/rakudo/rakudo/blob/mast...d.nqp#L744 15:15
github.com/rakudo/rakudo/blob/mast...d.nqp#L902
All compiled Perl 6 code will depend on those but this dependency is implicit - it's not recorded in the precomp files (as the compiler always loads them anyway) 15:16
Once you got that covered you can work on an executable that contains the precompiled code of this loader and the precompiled code of the actual script you're gonna run 15:17
By starting with the executable you're guaranteed to run into an endless stream of frustratingly nonsensical error messages.
pamplemousse nine: Okay, thank you so much for the guidance and the links. I'm going to switch gears and try working on the first step you suggested and see how far I can get that way. Starting there sounds a lot less mindwarping than what I've been attempting to do this week so far. 15:22
patrickb nine++ pamplemousse++ 15:23
pamplemousse Also, thank you patrickb++ for helping me realize that this was probably the wrong direction to be going 15:24
nine pamplemousse++ even if you don't reach your goal, the work you do on the way will have value all on its own. We've talked about precompiled scripts for years. I'd love to see them happening :) 15:33
15:44 pamplemousse left 15:45 pamplemousse joined 15:51 brrt joined 15:57 MasterDuke left 16:19 patrickb left
brrt \o 16:35
16:36 MasterDuke joined 16:55 domidumont left 17:16 patrickb joined 17:17 squashable6 left, squashable6 joined 17:42 zakharyas left 17:45 AlexDaniel joined 18:13 patrickb left 18:57 zakharyas joined 19:23 zakharyas left
Kaiepi lol the original way i tried to implement support for wchar_t and wint_t a year ago was really naive 20:10
instead of 2 loc worth of changes i have 500 now just to support the types alone and i'm still not done
ugexe i wrote a line of naive code once 20:11
timotimo Kaiepi: i'd assume you'll want to put something in the compose "protocol" for CString 20:12
Kaiepi ah
timotimo which is little more than a C function that gets called with an object (usually (or perhaps necessarily) a hash) where configuration happens
the newtype op is used to combine a REPR with the compose data to create a new type 20:13
which, among other things, gives you a fresh set of REPR_data
so anything you configure with the compose protocol will usually land in there
Kaiepi good to know, thanks
i likely need to add iswcharsigned and iswintsigned ops so rakudo can tell whether or not they're signed/unsigned 20:14
i'd like to just use nqp::const for that but it's impossible to tell from nqp 20:15
timotimo actually 20:16
perhaps parameterized types could be useful here
i just forgot how they work
there's docs about them in moarvm's docs folder though
perhaps in nqp's
Kaiepi actually wait, i can probably use nqp::const, but i still need the ops 20:19
that reminds me, i didn't know nqp::const existed at the time i wrote the pullreqs for portable socket families, i should be using it there 20:21
timotimo oh, good point 20:22
21:10 sena_kun left 21:11 sena_kun joined, sena_kun left 21:25 squashable6 left, squashable6 joined 21:26 pamplemousse left 21:39 brrt left 21:48 dogbert11 joined 21:49 krunen left 21:50 krunen joined, dogbert17 left 22:17 tobs left 22:35 tobs joined 22:53 pamplemousse joined 22:55 lucasb left 23:13 squashable6 left 23:18 squashable6 joined 23:40 pamplemousse left

Powered by Cro and the Raku® Programming Language.

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

Thank you!