github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
brrt \o 09:55
Not sure if you've seen but my grant application was approved 09:57
So, I guess I have to make the expression JIT a little better again now :-)
nwc10 poor you 10:05
sounds terrible
brrt hehe 10:08
I'm trying to figure out whether to start with the expression JIT optimizer, invoke-sequence, or floating point support 10:09
or, irregular instruction register allocation
I think the last two are the hardest, so I'm inclined to start there 10:10
jnthn morning o/ 10:42
brrt morning jnthn 11:29
brrt I'm thinking of making a graphviz visualization of the register allocators' work 11:58
for debugging purposes
dogbert2_ brrt, congratulations 12:50
I'm sad to say that I have no JIT related bugs to report :) 12:51
brrt you'll get them soon enough when I start working :-) 13:18
lucasb hey you C programmers! 16:16
any apache httpd user among you? 16:17
moarvm is supposed to be embeddable, right? 16:18
is the idea of a apache module feasible? I'm trying to do this: gist.github.com/lucasbuchala/7d850...fd7ab818d6
stderr managed to show up in apache errors log... 16:19
but now, idk what to do :-)
timotimo lucasb: if you want it to run perl6 code, you'll have to give it lots of extra arguments; check the contents of perl6-m to see what 16:36
oh
you're already passing the lib path
... derp
well, what do you want to happen next? 16:37
lucasb idk, just copied the contents of main.c and perl6.sh together
timotimo do you want stdout to go to the browser?
lucasb I guess I should study mod_perl (5) to learn what's possible
yes, that should be one simple thing that should happen :-) 16:38
timotimo there's surely a bunch of things in the request_rec that ought to go into the environment variables
lucasb ^^ showing, because... there's design work... just requesting some help :-) 16:39
for example, pick the right set of Apache directives to tune moarvm from apache
from apache server config or .htaccess in directories
well, I think this "view" is very much PHP-esque... 16:40
what's the P6 version of PSGI... should the design of mod_moarvm take that in consideration?
metacpan.org/release/mod_perl 16:42
should functionality be written in C and exposed as nativecall modules to Perl 6 (?)
each request a MVMInstance is instanciated? should there be a pool of instances? should I clean everything after a request? what about threads (server ones and moarvm ones)? 16:44
anyway, just random questions that occurred to me :-) lacking in knowledge, all I can do is wonder for now 16:45
lucasb for now, my current TODO item is: take a look at mod_perl, mod_php, mod_lua, mod_mruby and try to get some idea 16:48
lucasb ha! github.com/bdw/mod_parrot 16:56
lucasb forgot about it. didn't know brrt is the author 16:56
timotimo if you're doing "one MVMInstance per request", that's barely different from starting up a full perl6 via cgi, if you do pooling, you'll end up wanting to send request data/metadata via some IPC mechanism which makes it barely different from PSGI :) 17:07
also, since it's quite possible to cause an instance to segfault by using NativeCall, it'd be wise to have process separation between httpd and moarvm
if you don't set the full cleanup mode on the mvminstance, it'll also be leaking memory and resources 17:10
since we rely on the OS freeing up everything when the process exits by default
lucasb ah, thanks timotimo for the details! everything looks so hard :-) 17:11
does perl6 bytecode lives at "share/perl6/runtime/perl6.moarvm", right?
it's just... bytes? should I pre load this content into the module?
to... speed things?
timotimo that is just bytes, but it isn't most of what's loaded to start up a program 17:13
the biggest part by far is the core setting
parser, actions, and world are all a noticeable bit smaller
lucasb hm, that too should be pre-loaded then (?)
"rely on the OS freeing up everything when the process exits" <-- this doesn't look like a persistent-environment-friendly, is it?
timotimo yeah, not very persistent-environment-friendly 17:14
would you consider preforking "persistent environment"?
lucasb well, will the process handle more than one request... than yes, I think 17:15
should I pursue this as my personal project or will you, the core developers, be interested and set up a github.com/MoarVM/mod-moarvm repo? 17:16
timotimo well, we can always set it up later and you just push all your code there 17:17
personally, i'd not expect big wins from having a mod_moarvm 17:18
happy to be proven wrong, of course :)
lucasb yeah, you're right. I understand your position
timotimo on the other hand 17:21
reducing friction to getting a perl6 up and running on Your Favourite Web Server is definitely worth doing 17:22
and if that involves a less-than-perfect solution, so be it. as long as it's easy for the user to switch from that to, say, a PSGI server, that's fine
lucasb well, I run my own apache instance, at 127.0.0.1:PORT
binding to localhost, not accessible outside 17:23
the same way I put my scripts in ~/bin, I put my cgis in ~/cgi-bin :-D
it was always easy and convenient for my personal usage
timotimo do we need our own CGI.pm6? :) 17:24
lucasb I just thought being able to run Perl 6 code at slightest faster than CGI to be win already :D 17:24
timotimo oh, a mod_moarvm should probably come with its own module loader to handle precompilation, or maybe it just needs to set up a few paths or env vars or something
yeah, rakudo's startup time is A Thing
lucasb I don't usually say the word CGI out loud because I don't won't to be burned in the fire by the mob :) 17:26
*don't wanna
timotimo a big part of "CGI.pm is bad" is not the CGI itself, if i understand correctly 17:27