Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-02-15

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:04 dalek MoarVM/eieio: 0066643 | jnthn++ | src/io/syncfile.c:
00:04 dalek MoarVM/eieio: Correct comments.
00:04 dalek MoarVM/eieio: review: https://github.com/MoarVM/MoarVM/commit/00666435f5
00:04 dalek MoarVM/eieio: 3a0c828 | jnthn++ | src/io/syncfile.c:
00:04 dalek MoarVM/eieio: Missing 'static'.
00:04 dalek MoarVM/eieio: review: https://github.com/MoarVM/MoarVM/commit/3a0c828dd1
00:10 jnthn Got a bunch of code here working towards moving TTYs and pipes over to the new IO model.
00:10 jnthn But tired, so will continue with it tomorrow.
00:25 timotimo good night, jnthn!
00:34 tgt joined #moarvm
00:44 benabik joined #moarvm
01:35 tgt joined #moarvm
02:22 tgt joined #moarvm
02:25 benabik joined #moarvm
02:47 ilbot3 joined #moarvm
02:47 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
03:05 FROGGS joined #moarvm
03:23 tgt joined #moarvm
04:22 dalek joined #moarvm
04:23 tgt joined #moarvm
05:24 tgt joined #moarvm
05:28 tgt joined #moarvm
06:29 tgt joined #moarvm
07:30 tgt joined #moarvm
07:39 timotimo lowering the lexicals to locals works again
07:39 timotimo it gives up as soon as it finds a QRegex, though, because we don't scan through there yet (as it transcends Optimizer classes)
07:39 timotimo and i can see no startup memory usage in perl6-m
07:39 timotimo improvement*
07:45 timotimo i don't have to manually remove entries from lexpads in the optimizer, right? replacing all the :decl('lexical') with 'local' should be enough, eh?
07:46 timotimo maybe it's just that the overwhelming majority of lexicals that *could* be lowered to locals are actually in perl6 code rather than in nqp code
07:46 timotimo where i'm pretty sure, analysis is going to prove very tricky indeed
07:47 timotimo i should look up how exactly locallifetime is supposed to work.
08:13 timotimo yeah, i apparently have no idea how the free list works.
08:15 timotimo oh
08:15 timotimo could it be that whenever there's a free block, you just write the address of the next free block whereever whatever object used to be?
08:15 timotimo that seems to make sense
08:20 timotimo now i've got much prettier graphs
08:20 timotimo so annoying that gdb's pager pushes its "press enter to continue" right in the middle, though
08:22 dalek MoarVM/gdb-support: b96b7eb | (Timo Paulssen)++ | moar-gdb.py:
08:22 dalek MoarVM/gdb-support: fix handling of free list.
08:22 dalek MoarVM/gdb-support: review: https://github.com/MoarVM/MoarVM/commit/b96b7eb1d1
08:22 dalek MoarVM/gdb-support: 61cdfce | (Timo Paulssen)++ | moar-gdb.py:
08:22 dalek MoarVM/gdb-support: remove double histogram for now
08:23 dalek MoarVM/gdb-support: review: https://github.com/MoarVM/MoarVM/commit/61cdfcec16
08:23 dalek MoarVM/gdb-support: 9f7631e | (Timo Paulssen)++ | moar-gdb.py:
08:23 dalek MoarVM/gdb-support: allow more samples
08:23 dalek MoarVM/gdb-support: review: https://github.com/MoarVM/MoarVM/commit/9f7631e46d
08:23 dalek MoarVM/gdb-support: cb98712 | (Timo Paulssen)++ | moar-gdb.py:
08:23 dalek MoarVM/gdb-support: don't try to sample free'd objects, mark remaining null objects
08:23 dalek MoarVM/gdb-support: review: https://github.com/MoarVM/MoarVM/commit/cb987120f6
08:24 timotimo https://gist.github.com/timo/4416af400d9c86fd0f3c
08:26 dalek MoarVM/gdb-support: 908cd2c | (Timo Paulssen)++ | moar-gdb.py:
08:26 dalek MoarVM/gdb-support: don't display useless size histograms
08:26 dalek MoarVM/gdb-support: review: https://github.com/MoarVM/MoarVM/commit/908cd2c896
08:30 tgt joined #moarvm
09:31 tgt joined #moarvm
10:00 tgt joined #moarvm
10:21 FROGGS o/
10:22 nwc10 \o
11:18 tgt joined #moarvm
11:22 jnthn timotimo++ # awesome wok on visualizing the gen2 pages!!
11:22 jnthn uh, work :)
11:22 jnthn mmm...wok...
11:58 tgt joined #moarvm
12:49 dalek MoarVM: 068ce44 | (Tobias Leich)++ | src/6model/reprs/SCRef.c:
12:49 dalek MoarVM: do nothing if sc->body already is NULL
12:49 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/068ce444f0
12:51 FROGGS that's about this btw: https://rt.perl.org/Ticket/Display.html?id=121253
13:01 hoelzro hi Moar hackers
13:01 hoelzro I had an idea while in the shower
13:02 hoelzro you know how a native application will share code/shared object pages with other applications using them?
13:02 hoelzro I wonder if it would be a good idea to emulate that in MoarV
13:02 hoelzro maybe it's overkill
13:02 hoelzro but I just thought I'd bring it up
13:19 dalek MoarVM/eieio: 5c1d25c | jnthn++ | / (10 files):
13:19 dalek MoarVM/eieio: Add syncstream, and move TTY over to it.
13:19 dalek MoarVM/eieio:
13:19 dalek MoarVM/eieio: A syncstream provides synchronous access to a libuv stream, using a
13:19 dalek MoarVM/eieio: MoarVM DecodeStream (like syncfile does) to handle bytes -> chars. At
13:19 dalek MoarVM/eieio: least on Windows, things like the REPL and piping files into Rakudo
13:19 dalek MoarVM/eieio: work out. Note that this breaks pipes; they still need updating to the
13:19 dalek MoarVM/eieio: new scheme.
13:19 dalek MoarVM/eieio: review: https://github.com/MoarVM/MoarVM/commit/5c1d25c5be
13:20 timotimo hoelzro: well, at least the .moarvm files are mmapped, so they are shared between instances
13:26 FROGGS ohh cool, need to try eieio soon
13:26 timotimo FROGGS: would you like help in figuring out how to use my gdb things?
13:26 timotimo or maybe you have a specific wish?
13:27 timotimo also, have you considered activating reverse debugging?
13:28 FROGGS umm... I can test you gdb plugins, but I am not sure I can make any sense out of comparing nursery snapshots
13:28 FROGGS at least that is what I think it does
13:28 timotimo hehe.
13:28 timotimo you can't even compare nursery snapshots right now
13:28 FROGGS and what do you mean aber reverse debugging?
13:28 FROGGS ahh
13:28 timotimo but the plugin also pretty-prints MVMString, so that's SUPER useful! :)
13:28 FROGGS hehe, yeah
13:28 FROGGS :o)
13:29 timotimo you can turn on reverse debugging and "cont", then it'll be 1000000x times slower, but afterwards you can single-step forwards *and* backwards
13:29 FROGGS ohh
13:29 FROGGS that sounds interesting
13:29 FROGGS and indeed very helpful
13:29 timotimo it's new in gdb7
13:30 timotimo what plugin functionality would make life easier for you?
13:30 FROGGS hmmm, let me think
13:32 FROGGS I don't know yet... but since I am using gdb right now I might feel the need for something :o)
13:32 timotimo fair enough :)
13:35 FROGGS can I run shell commands within gdb?
13:35 timotimo ctrl-z, use shell, fg, use gdb :P
13:35 FROGGS because that I could just do a "make install" in moarvm and rerun my script
13:36 FROGGS what?
13:36 timotimo not sure if gdb will re-load the stuff from disk when it changes, though
13:37 timotimo there is a way to give gdb a startup script that will run commands for you
13:37 timotimo like setting breakpoints and running and stuff
13:37 timotimo that could be helpful to you
13:38 FROGGS yeah, true
13:40 FROGGS damn, I'm not able to create a simple case that causes the STable bug
13:40 timotimo d'oh :(
13:45 * jnthn peers curiously at all the ref/unref going on in openpipe...
13:47 FROGGS ref all the things! /o/
13:48 timotimo i don't even know what that means/does
14:02 lizmat joined #moarvm
14:07 FROGGS okay, it seems like I can reduce panda to something that complains about STable
14:07 woolfy joined #moarvm
14:07 woolfy left #moarvm
14:07 timotimo jnthn: how about bumping MOAR_REVISION in nqp to get the intcache, then bumping NQP_REVISION + fixing the renaming fallout in rakudo?
14:08 jnthn Well, we should fix the fallout along with the bump...
14:08 timotimo yes
14:08 timotimo in the same commit, then?
14:08 jnthn Please.
14:08 timotimo will do
14:10 dalek MoarVM/gdb-support: 91f1240 | (Timo Paulssen)++ | moar-gdb.py:
14:10 dalek MoarVM/gdb-support: more robust stuff, bunch up output and analysis
14:10 dalek MoarVM/gdb-support: review: https://github.com/MoarVM/MoarVM/commit/91f12401ec
14:10 jnthn FROGGS: I'm a little dubious about the process close stuff.
14:11 FROGGS jnthn: you mean that we close one end of the pipe?
14:12 FROGGS s/that/where/
14:15 jnthn When you nqp::close a handle
14:15 jnthn That you got from openpipe
14:15 FROGGS yeah
14:16 FROGGS when we close our side of the pipe the child process should terminate, so we wait for that
14:25 dalek MoarVM/eieio: 0f70c62 | jnthn++ | / (9 files):
14:25 dalek MoarVM/eieio: Move openpipe over to the new IO scheme.
14:25 dalek MoarVM/eieio:
14:25 dalek MoarVM/eieio: With this, we're back (at least on Win32) to no spectest regressions
14:25 dalek MoarVM/eieio: and passing NQP tests.
14:25 dalek MoarVM/eieio: review: https://github.com/MoarVM/MoarVM/commit/0f70c62af8
14:30 dalek MoarVM/eieio: 5aa7bba | jnthn++ | src/6model/reprs/MVMOSHandle.h:
14:30 dalek MoarVM/eieio: Toss two now-unused members.
14:30 dalek MoarVM/eieio: review: https://github.com/MoarVM/MoarVM/commit/5aa7bbaea4
14:30 jnthn Testing on other platforms welcome
14:30 jnthn err&
14:31 timotimo will do
14:33 FROGGS jnthn: I know now how to trigger the STable thingy
14:33 FROGGS jnthn: see https://github.com/FROGGS/STable
14:39 woolfy joined #moarvm
14:39 woolfy left #moarvm
14:40 hoelzro timotimo: ah, I didn't know that.  cool!
14:44 FROGGS src/io/syncfile.c:39:13: error: conflicting types for ‘close’
14:44 FROGGS static void close(MVMThreadContext *tc, MVMOSHandle *h) {
14:44 FROGGS /usr/include/unistd.h:353:12: note: previous declaration of ‘close’ was here
14:44 FROGGS extern int close (int __fd);
14:45 FROGGS same about truncate
14:45 timotimo hoelzro: ww?
14:45 hoelzro timotimo: wrt mmaping of .moarvm files
14:45 timotimo oh, yes
14:45 FROGGS so, shall we rename it to closefh and truncatefh?
14:46 timotimo hoelzro: i'm still considering unmapping the serialized portions, as they are only ever read once and then we can forget about them
14:46 hoelzro seems reasonable
14:46 timotimo jnthn: https://gist.github.com/timo/aad915a9cff0f0cd928d
14:51 FROGGS timotimo: I pasted that already :o)
14:52 timotimo oh, ok
14:52 timotimo thank you :)
15:09 FROGGS jnthn: this makes it compile on linux: https://gist.github.com/FROGGS/b320bfe9140ddf193ac9
15:09 FROGGS jnthn: I did not push because you might prefer other names
15:13 jnthn Oh, how silly... :)
15:13 jnthn But yeah, those names will doo.
15:13 jnthn *do
15:15 FROGGS k
15:15 FROGGS will push
15:17 dalek MoarVM/eieio: 15944b1 | (Tobias Leich)++ | src/io/ (5 files):
15:17 dalek MoarVM/eieio: use names that work out on unix
15:17 dalek MoarVM/eieio: review: https://github.com/MoarVM/MoarVM/commit/15944b14d1
15:20 FROGGS [...]src/gen/m-CORE.setting
15:20 FROGGS Stage start      :   0.000
15:20 FROGGS Unexpected named parameter 'deserialize_past' passed
15:20 FROGGS at gen/moar/stage2/NQPHLL.nqp:1938  (/home/froggs/dev/nqp/install/languages/nqp/lib/NQPHLL.moarvm:add_load_dependency_task:12)
15:21 FROGGS but that might even be due to bumping nqp to HEAD
15:22 FROGGS ohh, yeah
15:22 jnthn Yeah, don't do that...
15:23 FROGGS that is due to a past/ast change
15:23 FROGGS np, I just switch back :o)
15:30 timotimo FROGGS: aye, that's what i'm going to fix today-ish
15:30 timotimo until then, just leave the newest 2 commits of nqp out
15:31 FROGGS jnthn: btw, I've tested this on windows and it shows the STable problem: https://github.com/FROGGS/STable
15:31 FROGGS jnthn: and it is very minimalistic too :o)
15:31 FROGGS timotimo++ # :o)
15:32 timotimo oh yeah, there isn't much left :D
15:38 jnthn FROGGS++
15:39 FROGGS jnthn: you'd just need to run the doit.bat then
15:45 FROGGS so it really is about using more than one precompiled module that has a class with an attribute in it
15:46 timotimo so we accidentally say "Attribute now belongs TO MEEEEEHHHh!!!kkk"?
15:47 FROGGS I guess both attributes share the same STable, so that triggers the reposession? in the using module?
15:47 FROGGS I just can guess wildly
16:22 jnthn FROGGS: argh, I thought you'd just renamed the static functions, not the vtable names... :/
16:23 FROGGS umm
16:23 FROGGS fix it?
16:23 jnthn Yeah, but it's made a huge merge conflict for the refactor I just did...
16:24 FROGGS ohh
16:24 FROGGS I'm sorry
16:25 FROGGS I don't even know how let the vtable names stay the same
16:26 FROGGS ahh, not touching src/io/io.h should have been the right thing I guess
16:26 FROGGS (besides src/io/fileops.c)
16:27 jnthn Right.
16:27 jnthn Should have only had to touch sync[file|stream|pipe].c
16:27 FROGGS yeah
16:27 jnthn Re-done it here, hopefully.
16:28 dalek MoarVM/eieio: 71c1650 | jnthn++ | src/io/ (5 files):
16:28 dalek MoarVM/eieio: Revert "use names that work out on unix"
16:28 dalek MoarVM/eieio:
16:28 dalek MoarVM/eieio: Renamed too much.
16:28 dalek MoarVM/eieio: review: https://github.com/MoarVM/MoarVM/commit/71c1650129
16:28 dalek MoarVM/eieio: 38fbf36 | jnthn++ | / (6 files):
16:28 dalek MoarVM/eieio: Move generic IO-related things into io.c.
16:28 dalek MoarVM/eieio:
16:28 dalek MoarVM/eieio: This leaves fileops.c (mostly) now just having things that only work
16:28 dalek MoarVM/eieio: on files.
16:28 dalek MoarVM/eieio: review: https://github.com/MoarVM/MoarVM/commit/38fbf360ed
16:29 dalek MoarVM/eieio: 3962173 | jnthn++ | src/io/sync (3 files):
16:29 jnthn That last one that didn't get reported was putting the needed renames back
16:30 FROGGS jnthn: can you put that include back in? https://github.com/MoarVM/MoarVM/commit/71c1650129#diff-beff3d4230b1ad1b250922477a3e1de5L6
16:31 jnthn bah, the commit message only mentioned renames...
16:32 dalek MoarVM/eieio: 474fb8c | jnthn++ | src/io/syncfile.c:
16:32 dalek MoarVM/eieio: Add missing #include; FROGGS++.
16:32 dalek MoarVM/eieio: review: https://github.com/MoarVM/MoarVM/commit/474fb8c188
16:33 FROGGS I'll be more careful in future
16:34 jnthn np
16:34 FROGGS it seems to build nqp right now
16:35 * jnthn crosses fingers for passing "make test" in NQP
16:37 FROGGS All tests successful.
16:37 FROGGS Files=89, Tests=3511, 24 wallclock secs ( 0.47 usr  0.07 sys + 21.39 cusr  1.34 csys = 23.27 CPU)
16:37 FROGGS Result: PASS
16:37 jnthn \o/
16:37 FROGGS jnthn++
16:38 FROGGS cool! I think I should get comfortable with the new api soon
16:39 jnthn I'm gradually clearing up
16:39 jnthn Currently looking at sockets.
16:39 jnthn Gonna make them work as far as they work on the JVM, but I can see that the socket class in Rakudo, and the JVM impl, are going to need some attention.
16:40 * FROGGS .oO( jnthn will be a Socket Scientist? )
16:41 jnthn :P
16:41 FROGGS had this in mind for two days now :o)
16:57 FROGGS in the m-spectest is nothing that catches the eye either...
16:57 jnthn Nice :)
16:59 timotimo Sock Surgery!
17:00 timotimo and yes, the socket classes are kind of bad
17:00 moritz the Hackiest Thing That Could Possibly Work
17:01 timotimo :D
18:04 dalek MoarVM/eieio: d450827 | jnthn++ | / (16 files):
18:04 dalek MoarVM/eieio: Very basic client socket support.
18:04 dalek MoarVM/eieio:
18:04 dalek MoarVM/eieio: With some NQP and Rakudo additions also, this is enough that we can
18:04 dalek MoarVM/eieio: connect to some IP address and port, and get stuff from it. Missing
18:04 dalek MoarVM/eieio: DNS resolution so far.
18:04 dalek MoarVM/eieio: review: https://github.com/MoarVM/MoarVM/commit/d450827f37
18:06 timotimo ooooh that sounds great! :D
18:09 jnthn My test was:
18:09 jnthn my $s = IO::Socket::INET.new(:host<193.200.132.135>, :port(3000));
18:09 jnthn $s.send("GET /projects.json HTTP/1.0\n\n");
18:09 jnthn .say for $s.lines;
18:09 jnthn $s.close;
18:09 jnthn That is, the one Panda uses :)
18:10 jnthn Now I "just" need to make it do host resolution...
18:11 dalek MoarVM/eieio: 4805a51 | jnthn++ | src/6model/reprs/MVMOSHandle.h:
18:11 dalek MoarVM/eieio: Clear up some leftovers of old I/O implementation.
18:11 dalek MoarVM/eieio: review: https://github.com/MoarVM/MoarVM/commit/4805a51f2f
18:47 FROGGS oh oh oh
18:47 FROGGS jnthn++
18:47 FROGGS somebody is working hard when I feed the pups :o)
18:48 timotimo pups refering to little dogs?
18:48 FROGGS in this case to my kids, yes
18:48 timotimo ah, ok
18:49 FROGGS I am musing how to implement that in v5 btw:
18:49 FROGGS perl -E 'use strict; our $foo = 42; my $bar = *foo; say $$bar'
18:49 FROGGS 42
18:49 timotimo *foo? o_O
18:50 FROGGS that is like a reference to a slot of name foo that holds $foo, @foo, %foo and &foo in the package.WHO
18:50 FROGGS so you can do that to alias subs
18:52 timotimo o_O
19:11 dalek MoarVM/eieio: 2ed615e | jnthn++ | src/io/syncsocket.c:
19:11 dalek MoarVM/eieio: Resolve hostnames in connect.
19:11 dalek MoarVM/eieio: review: https://github.com/MoarVM/MoarVM/commit/2ed615e16a
19:12 jnthn That means we can now run exactly the code Panda uses sockets for.
19:12 timotimo \o/
19:13 timotimo that'll definitely go in my weekly changes report :)
19:52 japhb jnthn++ # W00t!  Socket code on MoarVM!
19:52 japhb Are you going to merge eieio soon, or is there something else big that you want to land?
19:56 FROGGS japhb: there are no regression afaik, which (I hope) is half the answer :o)
20:01 nwc10 I am seeing a SEGV from t/moar/02-pipes.t on Linux and on OS X.
20:01 nwc10 I'm having trouble making sense of it, because it fails differently under valgrind and just under gdb
20:01 nwc10 but I end up with a NULL tc in some cases, which makes tc->loop a NULL pointer deference
20:02 nwc10 this is on eieio
20:02 nwc10 everything else is fine. Didn't try a rakudo spectest
20:10 FROGGS hmmm, gcc on linux does not show anything
20:13 nwc10 oh well, some progress
20:13 nwc10 *(MVMint64 *)req->data = (exit_status << 8) | term_signal;
20:13 nwc10 that's trashing tc
20:13 FROGGS that is my invention :/
20:13 timotimo oh whoops :D
20:14 nwc10 implying that req->data is bogus
20:14 FROGGS ahh, maybe that has changed :o)
20:17 jnthn That's the bit of code I was looking confusedly at earlier :)
20:18 nwc10 OK, so I'm stuck *how* it's happening, but req->data seems to be &tc
20:18 jnthn japhb: The sockets stuff is the last big piece, really
20:18 nwc10 so on "process exit" the callback is writing exit status information, and inadvertently wiping out the thread context
20:18 jnthn nwc10: Is this on the eieio branch?
20:18 nwc10 er, child process exit
20:18 nwc10 yes, eieio
20:19 jnthn oh, you said and I missed it :)
20:21 nwc10 oh, the SPAWN macro sucks.
20:21 nwc10 process->data               = &result; \
20:21 nwc10 it's taking the address of a variable on the C stack
20:21 FROGGS yes, result is a local variable there
20:21 nwc10 and somehow expecting it to be useful
20:22 timotimo hah, ouch
20:22 nwc10 and that address on the stack is getting written to much later
20:22 jnthn Uh...
20:22 nwc10 when it happens to be the tc parameter of a function
20:22 jnthn Oh, you just found it to...
20:22 nwc10 whoopsy
20:22 jnthn fail
20:22 nwc10 yes, fail :-)
20:22 FROGGS I thought this was already fixed in master... appearently not
20:22 nwc10 am I execused? Can I go to bed now?
20:22 FROGGS *g*
20:22 timotimo nwc10++
20:23 jnthn FROGGS: Does the error code get used anywhere when this is done with openpipe?
20:23 nwc10 hardware watchpoints for the win.
20:23 FROGGS jnthn: no, not for pipes
20:23 FROGGS only for spawn and shell, which are supposed to return within the function
20:24 FROGGS so, we should just set it to NULL and check for non NULL in the cb
20:24 jnthn yeah, doing that.
20:27 dalek MoarVM/eieio: 146ba4a | jnthn++ | src/io/procops.c:
20:27 dalek MoarVM/eieio: Avoid trashing the stack with process exit value.
20:27 dalek MoarVM/eieio:
20:27 dalek MoarVM/eieio: nwc10++ for report/hunting it down.
20:27 dalek MoarVM/eieio: review: https://github.com/MoarVM/MoarVM/commit/146ba4accd
20:49 jnthn OK, I can probably merge the branch at this point...
20:49 jnthn FROGGS, timotimo: Either of you up for doing a NQP/spectest run for me?
20:49 timotimo sure
20:49 jnthn I've more to do but I don't need to do the rest in a branch, since it's gentle refactors or new additions.
20:49 jnthn I'm done ripping stuff up :)
20:49 FROGGS sure
20:50 FROGGS the nqp test passes
21:00 FROGGS jnthn: no new fails in m-spectest
21:01 jnthn OK, let's merge this stuff.
21:12 dalek Heuristic branch merge: pushed 31 commits to MoarVM by jnthn
21:12 * FROGGS switches branches
21:16 * timotimo branches switches
21:17 * jnthn swinches bratches
21:20 * masak stitches brambles
21:21 timotimo ooooh, tasty brambles!
21:36 FROGGS jnthn: fwiw, fetching /projects.json does work here too
21:37 timotimo YAY \o/
21:37 timotimo moar panda for everyone!
21:39 FROGGS btw, fetching it takes 0.9s using perl6-p, which seems to split lines weirdly, and it only takes 0.58s on moar without weird splits
21:40 timotimo \o/
21:46 * jnthn just wrote the world's crappiest ever HTTP server so he can try and get server side sockets working
21:47 FROGGS hehe
21:50 timotimo IO-Socket-INET.t isn't going to work yet?
21:51 timotimo because of missing server sockets?
21:51 FROGGS correct
21:51 timotimo slowest test case ever :)
21:51 FROGGS perhaps you can spawn the server using perl6-p :o)
21:51 timotimo jnthn: do you have a good next step for me to do to get the lexical-to-local optimization bettered?
21:52 timotimo obviously i should descend into QRegex and mark any lexicals used in there as DO NOT TOUCH, instead of giving up on optimizing lexicals completely at that point
21:52 timotimo but even so, I saw lots of "yippie! i changed $foo to $bar" messages and no change in memory usage
21:52 jnthn Yeah. I guess descending onto closures and seeing what's captured is also a part of it.
21:53 jnthn I mean, a correct analysis has to do that.
21:53 jnthn Or are you doing that much already?
21:53 timotimo descending into closures?
21:53 timotimo i'm looking into any QAST::Block for usages of the lexicals
21:53 jnthn OK, and then...?
21:53 timotimo that's what makes the optimization consider a lexical "poisoned" for this specific optimization
21:53 jnthn Ah
21:54 timotimo if the lexical hasn't been used anywhere besides the very same QAST::Block they were defined in, i turn them into lexicals
21:54 jnthn Yeah, that's the incredibly conservative approach.
21:54 timotimo i turn them into locals*
21:54 jnthn *nod*
21:54 timotimo what would you suggest as the less incredibly conservative approach?
21:54 timotimo i would have to manually pass these locals around?
21:54 jnthn No, not that :) That's horrible :)
21:54 timotimo agreed! :)
21:54 jnthn The next step isn't too bad actually
21:54 jnthn So, here's what needs to happen.
21:54 timotimo 724.34user 36.68system 7:16.56elapsed 174%CPU (0avgtext+0avgdata 256908maxresident)k
21:55 jnthn 1) First, process any nested blocks.
21:55 timotimo except for the 5 minutes of waiting for IO-socket-INET.t to pass, that wasn't too bad )
21:55 timotimo :)
21:55 timotimo also, it seems like that test only fails every odd test, rather than all of them %)
21:55 jnthn 2) If, after processing a block, all of its lexicals have become locals, and it has blocktype immediate or immediate_static, you can now just inline that block into the place it was enclosed.
21:56 timotimo hm, do i have to follow QAST::BVal nodes into these blocks?
21:56 jnthn 3) After doing that for inner ones, now process the curent block. A bunch of lexicals that were out of reach before now may not be.
21:56 jnthn For immediate blocks, there's no QAST::BVal references to them.
21:56 timotimo ah
21:56 timotimo that would be good indeed
21:56 jnthn It's important to only inline blocks marked immediate or immediate_static.
21:57 jnthn Note that Rakduo is more involved.
21:57 jnthn But for NQP this should be OK.
21:57 timotimo what kind of fixups are needed to get this inlining happening?
21:57 timotimo yes, i'm not touching rakudo at all yet :)
21:57 timotimo (but since rakudo is implemented in nqp, i'm hoping it'll give benefits even there)
21:57 jnthn In theory, given $block which is immediate, replace it was a QAST::Stmt node.
21:58 timotimo oh!
21:58 jnthn Containing the nodes within the block.
21:58 timotimo that seems entirely doable in that case! :)
21:58 jnthn In practice...you may hit a tricky problem: overlapping local names.
21:58 jnthn I don't know. If your lowered names are unique enough, you're probably OK.
21:58 timotimo the lowered names look like ltol_originalname123_3241
21:59 timotimo the whole original name isn't used, because locals with - in them explode on parrot
21:59 jnthn Note that on Parrot, local names can only be \w+ :(
21:59 timotimo allows _, too, though
21:59 timotimo and numbers
21:59 jnthn So does \w+ :P
21:59 timotimo oh!
21:59 timotimo right :)
21:59 jnthn Is the number on the end unique?
21:59 jnthn as in, from a .unique(...) call?
21:59 timotimo it's the number that gets added by QAST::Node. ... yes
22:00 jnthn Yeah, then you should be good.
22:00 timotimo the other number is the lexical depth it was found at
22:00 timotimo cool
22:00 timotimo i'll try to sleep. which will inevitably fail at some point in the night and then i'll see if i can start implementing this! :)
22:00 jnthn :)
22:01 jnthn Try to sleep well :)
22:01 timotimo by "if all of its lexicals have become locals", do you mean only vars that were declared in that block that i'm looking to inline or also just mentions of lexical vars?
22:01 timotimo i'm thinking the latter should be just fine
22:01 jnthn Just declared
22:02 jnthn So you could be able to just look in the first QAST::Stmts of the block, which is where all the declarations live.
22:03 timotimo i'll have to do some extra magic to track lexicals that have previously been "poisoned" that are now no longer poisoned due to inlining
22:03 timotimo but other than that it seems kinda doable
22:03 timotimo should i expect awesome wins after this is done? :)
22:04 jnthn Oh, that's why I suggested that you inline first.
22:05 jnthn Since then the analysis of what's declared in this block is easier
22:05 timotimo hm, right, i guess i can do the analysis later, bottom-up.
22:05 jnthn Yeah, just pass up the posion.
22:05 jnthn I think you should get some wins out of this, yeah.
22:05 jnthn Hard to estimate
22:06 jnthn I suspect that early versions of the specializer will have a much better time with analyzing locals than lexicals also...
22:06 timotimo i'm hoping you'll be pleasantly surprised. and me, too, of course ;)
22:06 timotimo the specializer refering to moarvm's specializer?
22:06 jnthn Yes.
22:07 timotimo right. that can do the optimization for rakudo, then
22:46 jnthn http://127.0.0.1:4242/moar
22:46 jnthn OMG /moar
22:46 jnthn yays.
22:47 tadzik lol que :)
22:47 tadzik oh, a server!
22:47 jnthn yeay
22:47 tadzik \o/
22:47 tadzik jnthn++
22:47 jnthn It jsut takes the thing you GET and then emits <h1>OMG $that_url</h1> :)
22:48 tadzik so, first platform with actually useful poll() in 3...2...1.... ;)
22:49 FROGGS *g*
22:49 FROGGS jnthn++
22:50 FROGGS I'd return <marquee>OMG $that_url</marquee> or <blink>...</blink>, but h1 is cool too :P
22:55 dalek joined #moarvm
22:56 PerlJam joined #moarvm
22:57 masak joined #moarvm
23:28 dalek MoarVM: 9c4505f | jnthn++ | src/io/syncs (2 files):
23:28 dalek MoarVM: Server side sockets.
23:28 dalek MoarVM:
23:28 dalek MoarVM: Seem to work for a basic HTTP server. The IO socket tests don't work
23:28 dalek MoarVM: out on Windows, but the first one does successfully do the sockets
23:28 dalek MoarVM: bits, and the issue may be with qqx, used in the test.
23:28 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/9c4505fe24
23:41 cognominal joined #moarvm

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary