Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-06-30

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

All times shown according to UTC.

Time Nick Message
01:38 vendethiel joined #moarvm
02:51 vendethiel joined #moarvm
03:00 JimmyZ_ joined #moarvm
04:15 vendethiel joined #moarvm
05:30 vendethiel joined #moarvm
07:02 zakharyas joined #moarvm
07:20 Ven joined #moarvm
08:21 brrt joined #moarvm
08:21 brrt \o
08:21 brrt hmm
08:22 brrt anyone know how to initialize an array of variable-sized int arrays
08:23 brrt hmm, you can't
08:23 brrt ok, that's clear enough
08:34 brrt why can't i have nice things
08:38 brrt because C
08:40 masak I think you need to take a step back and ask why it is you want that data structure.
08:41 masak and then do what is possible in C.
08:41 masak anyway, in True Perl 6 the answer is something like `my @array[20; *];`
08:48 Ven joined #moarvm
08:49 brrt i can answer that :-)
08:49 brrt in fact, that was supposed to be the topic of a blog post ;-)
08:51 brrt basically, my goal is to convert a spesh-graph basic block to a low-level expression tree (a machine-level IR), on which i can then run a pattern-matching code generation
08:51 jnthn moarning o/
08:51 brrt moarning
08:52 brrt now, the spesh graph is properly considered an SSA-annoteted form of three-address-code
08:52 brrt maybe sometimes more than three addresses, sometimes less, but that is beside the point
08:53 brrt so my first order of business would seem to be conversion of the spesh format to an expression tree (or actually expression set, but again, beside the point)
08:53 brrt agreed?
08:54 jnthn brrt: Sounds like what the pattern matching approach needs, yes.
08:54 * jnthn notes that usage counts could help a huge amount
08:54 brrt hmm
08:55 jnthn In that, if something has a single use, it is a candidate for moving into the tree under its user.
08:55 brrt agreed; however, my tree-building algorithm is more aggressive than that
08:56 brrt as in, it always moves it under the tree, it's just kept available until overwritten
08:56 brrt so in a sense, that generates a DAG
08:56 brrt because multiple parents can 'acquire' a child
08:57 brrt now, how to do this without it taking up the full 8 or so weeks i have left? :-)
08:58 brrt well, for that, i want to use expression templates
08:58 brrt much like dynasm, in fact
09:01 brrt these templates would be formed by a piece of IR tree and a set of fill-in instructions
09:02 brrt the fill-in instructions can conveniently be a string, because the set of opertions is quite small
09:02 nwc10 I admit that I've not studied luaJIT closely, but I've read a couple of the explanations of what it does for certain things
09:02 nwc10 am I right in thinking that it doesn't take any advantage of runtime type information?
09:03 nwc10 ie it is a "Just In Time" compilation of the static Lua code.
09:03 brrt ah, i can answer that, i think
09:03 nwc10 no guard clauses or similar "oh bother" bailout
09:03 brrt as far as i know, lua doesn't really support user-defined types
09:04 Ven joined #moarvm
09:04 brrt it supports user-defined classes and objects, but those are just extensions to the universal 'table' structure
09:04 brrt and, luajit is a trace compiler
09:05 brrt what that means is that for luajit to specialize on type, it just constant-folds the hash-table lookup it would otherwise do
09:06 brrt specialisation on method calls is 'for free' given the tracing, but that does mean you need to do trace guards
09:06 brrt i.e. if you leave the trace, you'll need to deopt
09:08 brrt this is all only possible because lua is a *much* simpler language than perl6
09:10 jnthn Yeah, LuaJIT is pretty specialized to Lua, which is why saying "just lift X idea from Lua to MoarVM" always frustrates me - because it's never gonna be "just".
09:11 brrt anyway, it looks like i'll need / want a preprocessor convert the expression-ir-templates to something that can be used at runtime, to fill those templates
09:12 nwc10 ah OK. thanks. So, my naive assumption is wrong - there are guards.
09:12 brrt alternatively, i could handcode it all, but that's timeconsuming and error-prone
09:12 brrt yes :-)
09:13 brrt oh, there's another fun thing about lua; lua only has floats
09:14 brrt heh. luajit in fact uses it's high-level IR directly for compilation, doesn't convert to a low-level IR set
09:15 brrt in effect, luajit uses peephole-optimized code generation
09:15 jnthn nwc10: Trace JIT is all about guards, pretty much...
09:15 jnthn nwc10: You eliminate all control flow for guards.
09:15 jnthn To a first approximation :)
09:16 * brrt nods
09:16 nwc10 OK, the bit my befuddled brain missed was that there was never mention of deoptimisation in any of the exmaples of stuff (or guards)
09:16 brrt and adds that loops or equally-taken-branches will likely end up in a trace
09:17 nwc10 and also, that there seemed to be no concept of an intermediate state of specialised bytecode. Or logging of control flow
09:17 nwc10 obviously logging has to happen, to make tracing work.
09:17 jnthn nwc10: It's a language thing; they don't call it "deopt", more like "trace exits"
09:17 brrt re: logging, i think it's embedded in the interpreter?
09:17 jnthn Yeah, though I suspect our logging is going to change with time
09:17 jnthn I'd like it to be more PIC-like
09:18 jnthn And cheaper
09:18 nwc10 PIC (in this context)?
09:18 * jnthn re-read the PIC paper on the train on Sat
09:18 brrt my same question
09:18 jnthn nwc10: Polymorphic Inline Cache
09:18 brrt aha
09:18 nwc10 aha. them
09:18 brrt i read the pypy guys had a new trick on their sleeve, dispatch chains
09:18 brrt but i'm not totally sure what that's about
09:19 nwc10 I'm a bit disappointed that there hasn't been a new entry on http://blog.pyston.org/ since Feb 24
09:19 nwc10 and even http://lists.pyston.org/pipermail/pyston-dev/ hasn't had a message (archived) since March 2015
09:20 nwc10 it's clear that they're busy doing stuff, given https://github.com/dropbox/pyston
09:20 nwc10 but I'd love something that summarises their progress. Because I'm curious.
09:20 brrt ehm, what's new about pyston?
09:20 jnthn brrt: I glanced over that paper recently.
09:20 brrt yes, my reading was also limited to a glance :-)
09:20 nwc10 particularly given that they thought that starting a new JIT was more likely to be a win for them than using/contributing to pypy
09:21 jnthn brrt: But it was on a day when my allergy stuff was horrid, so it was all a bit of a blur...
09:21 nwc10 brrt: in terms of technology - I have no idea, and I suspect "nothing" (and that might be a design choice - just do existing things well)
09:21 nwc10 I was far more curious about the "do another JIT" choice
09:21 * jnthn will re-read the paper at some point
09:21 brrt we're doing another JIT, just inside the old one :-P
09:24 brrt hmm...
09:24 brrt one of the greater disadvantages of pypy, imho, is that they've distanced themselves quite far from the mainstream, technically and intellectually
09:24 brrt nobody else is talking about a meta-tracing compiler
09:25 brrt ah, on llvm
09:25 brrt hmm... well, that can work.
09:26 nwc10 brrt: I wasn't aware of that. I was aware that I can't build the thing on my laptop, as I only have 4Gb
09:27 nwc10 and even on a desktop with >6Gb RAM it takes forever to build (ie about 40 minutes)
09:27 nwc10 which makes their development feedback cycle dog slow.
09:27 nwc10 which will hinder them massively
09:27 nwc10 and prevent them from getting many new contributors
09:28 brrt well, it's just my opinion, for one thing :-)
09:29 brrt but yes
09:29 brrt pypy takes literally forever to build
09:29 brrt forever to download (on a slow line)
09:29 brrt figuratively forever, perhaps
09:30 brrt and... what they write about it is barely comprehensible to an outsider (me)
09:42 JimmyZ_ joined #moarvm
09:53 brrt bbiab
10:31 brrt joined #moarvm
10:32 * brrt back
11:20 vendethiel joined #moarvm
11:23 hoelzro_trying_w joined #moarvm
11:24 hoelzro joined #moarvm
11:47 vendethiel joined #moarvm
12:30 brrt does MSVC support int array[runtime_variable] yet?
12:31 jnthn I don't *think* so...
12:33 brrt :-(
12:33 dalek MoarVM/even-moar-jit: 9885d9e | brrt++ | src/jit/expr.c:
12:33 dalek MoarVM/even-moar-jit: First draft of expression tree building algorithm
12:33 dalek MoarVM/even-moar-jit:
12:33 dalek MoarVM/even-moar-jit: This is not yet a useful implementation since it lacks any templates
12:33 dalek MoarVM/even-moar-jit: to fill, a template filling algorithm, definitions of the structures
12:33 dalek MoarVM/even-moar-jit: involved, and I'm fairly sure it doesn't compile. But its useful
12:33 dalek MoarVM/even-moar-jit: to have it out in the open anyway.
12:33 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/9885d9e7cd
12:33 brrt well, no matter
12:33 brrt it supports alloca, doesn't it?
12:35 brrt this wasn't meant to compile anyway
12:36 jnthn _alloca is in the MSDN: https://msdn.microsoft.com/cs-cz/library/wb1s57t5.aspx
12:36 jnthn uhh...
12:36 jnthn https://msdn.microsoft.com/en-us/library/wb1s57t5.aspx
12:38 brrt why the underscore
12:38 brrt does microsoft not like us
12:39 brrt ok, now for the next bits
12:39 brrt filling templates
12:40 brrt my hypothesis is that for constructing templates, i can just look at the asm code we meticulously wrote for dynasm can be a guide
12:40 vendethiel joined #moarvm
12:50 brrt hmmm
12:50 brrt i'd better get the whole spesh ins for acquiring the template
13:04 Ven joined #moarvm
13:09 vendethiel joined #moarvm
13:17 zakharyas joined #moarvm
13:22 dalek Heuristic branch merge: pushed 30 commits to MoarVM/even-moar-jit by bdw
13:24 timotimo is the "turn jitting to C invocations" thing going to be a priority soon?
13:25 brrt ehm, sorry, i don't get the context yet :-)
13:26 timotimo er
13:26 timotimo yeah, it's missing half the text in the quotes
13:26 timotimo "turn jitting to C invocations into a table lookup"
13:26 brrt ehm, yes
13:26 timotimo or maybe "build a jit interpreter" :P
13:26 brrt well
13:27 brrt let me explain my plan for now
13:27 brrt basically, as i said this morning, the first thing i have to do is lower the spesh graph ir to a low-level IR
13:28 timotimo mhm
13:28 brrt i want to use templates to do that
13:28 timotimo mhm
13:28 brrt as in, something, have a template for the tree, and fill it in
13:28 timotimo you mean "match something"?
13:28 brrt no, matching is much later
13:29 timotimo what's the something for, then? :)
13:29 brrt for each MVM instruction, find a template for the low-level IR, and fill it in with IR nodes generated for the instruction operands
13:29 timotimo ah, hm
13:29 brrt e.g. translate an immediate operand into an immediate node and fill this in
13:30 brrt in other words
13:30 timotimo ah, so even for operations that have a constant argument in the MVM bytecode, we'll emit something akin to a "load constant" operation?
13:30 brrt inc_i would becomde { mem-ref register (i}, immediate (1), add relative(0), relative(1) }
13:31 brrt yes
13:31 brrt actually
13:31 brrt that will exist in the IR
13:31 brrt not in the written bytecode
13:31 brrt the 3rd element (index 2) willl then be the root of the template
13:32 brrt hmm
13:32 brrt i didn't do that in my mockup implementation yet
13:32 brrt anyway, to make a long story short
13:32 timotimo i don't know what "root of the template" is necessary for
13:33 brrt basically, this creates a tree (in s-expr notation) (add (reg-val 1) (imm 1)); the add node is the root
13:33 timotimo oh, ok
13:33 brrt i need the root, because the root now stands for the value of that computation
13:34 timotimo and the "relative" is relative to the { }
13:34 brrt precisely
13:34 brrt anyway, that'd be the same thing as would be written for the c calls
13:36 brrt the c calls would have two nodes, the call pointer and the argument list, ensuring that (in recursive evaluation) the arguments are stored in the right place
13:37 timotimo "mem-ref register", "immediate 1" and friends are equivalent to the things we already put into the structs for generating c calls
13:37 timotimo right
13:37 brrt yes, but generalised, because they'll need a size
13:38 brrt i.e. they should generalise to getting stuff from like, euh
13:38 timotimo mhm
13:39 brrt getting the category mask from the MVMException ;-)
13:39 timotimo that's the first time we've needed sized reads :3
13:39 timotimo and we've reverted that again
13:40 brrt well, we need it for a lot of things, its just that most of those have been implemented by hand, in asm, in emit_x64
13:40 timotimo OK
13:40 timotimo so emit_x64 is going to shrink a bit, too?
13:40 brrt that is the goal, yes
13:40 timotimo well, i mean, a lot of the hand-coded things so far
13:41 timotimo we'll have the things that turn our IR into assembly, that'll be in a .dasc file, too
13:42 brrt yes, that's the final codegenerator
13:42 timotimo will it be a separate .dasc file?
13:42 brrt and a lot of what's in emit_x64.dasc will ocntinue to exist
13:42 timotimo mhm
13:42 brrt i am planning to split them, yes, and use dynasm-level .include to include them
13:42 timotimo sounds good
13:42 timotimo seems like you can stop explaining and continue working ;)
13:43 brrt :-)
13:43 jnthn brrt++ # plan sounds good, having just caught up reading :)
13:43 brrt :-) thanks
13:43 brrt that's a relief, really
13:44 timotimo should i try building a code analysis thing that can turn the current jit/graph.c into a table? :P
13:44 brrt you... could do that, yes, i've thought about it
13:44 timotimo sounds a bit painful
13:44 timotimo but maybe fun
13:45 timotimo and since it's a one-off, it'd be acceptable to make it do 90% of the work and do the rest by hand
13:45 brrt the thing is, i haven't settled on the format of the table just yet
13:45 timotimo mhm
13:45 brrt :-P
13:45 timotimo in that case, the generator can be changed
13:45 timotimo or we generate a more detailed table that can be turned into the final table
13:45 brrt yes, that's true
13:46 timotimo i heard xslt can be used to transform <table>s
13:46 brrt anyway, if you wanted to try and analyze the graph.c thingy, that'd help, definitely
13:46 timotimo having had something like that could have been a good thing earlier to figure out things like "passed n arguments, but claimed the argument list was m elements big"
13:47 * brrt nods
13:47 brrt anyway, the process is automatable as far as i care. so we should automate it :-)
13:47 brrt but i'll be back in a few hours
13:47 brrt i have a study colloquium to attend :-)
13:47 brrt see you!
13:47 timotimo K cya :)
13:50 JimmyZ_ joined #moarvm
13:51 JimmyZ_ joined #moarvm
14:26 Ven joined #moarvm
15:20 vendethiel joined #moarvm
15:21 JimmyZ__ joined #moarvm
15:29 timotimo we b0rked --asan
15:29 timotimo probing whether your compiler thinks that it is gcc  ==6073==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.
15:48 JimmyZ_ joined #moarvm
15:54 Ven joined #moarvm
16:35 vendethiel joined #moarvm
16:53 JimmyZ__ joined #moarvm
16:57 FROGGS joined #moarvm
16:57 FROGGS FYI: moarvm 2015.06-2 MIGRATED to testing
16:57 FROGGS The status of the moarvm source package
16:57 FROGGS in Debian's testing distribution has changed.
16:58 FROGGS Previous version: (not in testing)
16:58 FROGGS Current version:  2015.06-2
16:58 jnthn \o/
17:00 FROGGS much happy
17:01 FROGGS nebuchadnezzar: how does moarvm get into stable/main or what it is called?
17:02 vendethiel joined #moarvm
17:05 japhb FROGGS: ISTR the path was something like:  Unstable --> Testing: O(weeks) with no new bugs relative to existing Testing release; Testing --> Stable:  Whenever a new major release happens.
17:06 FROGGS japhb: the Unstable --> Testing happens after five days
17:06 japhb FROGGS: But it's been a while since I was following Debian day-to-day; I've drifted a couple forks away.  (I used to ride Debian Testing as a matter of course, but I got frustrated when the odd failure happened and I couldn't use my computer.)
17:06 japhb FROGGS: Methinks that's shortened over time.  I would swear it used to be 2 weeks, but maybe that's just a broken memory.
17:07 FROGGS and since moarvm is now in testing, I guess we should focus on nqp and then rakudo?
17:07 FROGGS and all of them will go into stable at some point
17:08 japhb Last time I switched distros at home, I went to Mint
17:08 FROGGS somehow
17:08 japhb Yeah, nqp seems next up.  Might be worth doing nqp-m and nqp-j.
17:08 * JimmyZ__ is using deepin linux..
17:08 FROGGS probably, yes
17:09 * FROGGS uses ubuntu
17:09 FROGGS bbl &
17:11 japhb Mint has the interesting structure that you can have either an Ubuntu-based one, or a Debian-based one.   # "Would you like your Debian at one level of indirection, or two?"
17:11 japhb JimmyZ: What made you choose that one?
17:12 Ven joined #moarvm
17:18 JimmyZ__ japhb: based on ubuntu, but much better ui , easier use.
17:19 JimmyZ__ and winxp/win7/osx similar theme switch
17:24 japhb Yeah, part of my reason for using Mint was the desktop replacement, my laptop not being a 7" tablet.
17:27 JimmyZ__ I have tried mint , but I think its ui is not better than deepin 😊
17:28 japhb JimmyZ__: I use the non-default desktop (the one that looks kinda like GNOME 2)
17:30 JimmyZ__ japhb: http://deepin.org/?language=en
17:33 JimmyZ__ japhb: http://deepin.org/system.html for quick view. 😊
17:34 * japhb chuckles at "Fashion mode"
17:35 japhb That felt an awful lot like "For those who love Linux but envy Apple products"
17:37 JimmyZ__ there are another two modes
17:38 japhb Fair enough.  :-)
17:40 Ven joined #moarvm
17:40 JimmyZ__ For those who love linux but envy Windows xp/7 , haha
17:58 brrt joined #moarvm
18:01 brrt \o
18:01 japhb o/
18:02 timotimo i've spent most of my evening getting rid of a headache ... though not thoroughly successfully :(
18:05 brrt hmm.. unfortunately there is no cure-all for headaches
18:05 vendethiel joined #moarvm
18:06 brrt just, wow (at the deepin thingy)
18:08 brrt to pursue perfectness and finely craft it
18:11 timotimo yeah, headaches can be any of a million types
18:11 timotimo i've tried taking a painkiller, but it didn't help much
18:11 timotimo and of course i drank lots of water
18:15 brrt sleep is also important :-)
18:19 timotimo i laid down for about an hour
18:20 timotimo didn't feel any better after that :(
18:20 timotimo and now i still have to shop some groceries
18:20 timotimo but dinner hasn't been decided yet
18:21 lucasb joined #moarvm
18:23 lucasb Hi there. iiuc, moarvm is tracking libuv at 1.0.0. any reasons for not updating to the latest 1.6.1?
18:25 brrt last time we upgraded it caused some fallout, iirc
18:26 brrt but it wouldn't harm too much just to check if we can upgrade
18:27 lucasb brrt: ok, thanks
18:28 brrt oh, there's another matter, libuv has had it's repo moved
18:28 lucasb yep, from joyent to libuv
18:32 timotimo huh, they are already at 1.6?
18:33 lucasb github says 1.6.1 is 25 days ago
18:34 brrt building and testing as we speak
18:34 brrt although i should've run a spectest before going all-in
18:37 brrt will TimToady be at YAPC::EU perchance?
18:42 nwc10 brrt: he's not yet marked as confirmed: http://act.yapc.eu/ye2015/search?country=us
18:42 brrt would be nice though
18:43 brrt hmm. S17-lowlevel/lock.rakudo.moar still flaps
18:48 TimToady yes, Glo and I will be there
18:50 brrt \o/
18:51 brrt i hope to finally meet you there
18:51 vendethiel joined #moarvm
18:54 dalek MoarVM/libuv-1.6.1-update: a5f39dd | brrt++ | / (2 files):
18:54 dalek MoarVM/libuv-1.6.1-update: Update libuv to 1.6.1.
18:54 dalek MoarVM/libuv-1.6.1-update:
18:54 dalek MoarVM/libuv-1.6.1-update: As far as I know, not associated with new spectest failures.
18:54 dalek MoarVM/libuv-1.6.1-update: review: https://github.com/MoarVM/MoarVM/commit/a5f39dd7f1
19:37 timotimo is there a little summary of what we get by going from 1.0 to 1.6?
19:42 FROGGS brrt:    Creating library moar.dll.lib and object moar.dll.exp
19:42 FROGGS uv.lib(util.obj) : error LNK2001: unresolved external symbol __imp_GetUserProfileDirectoryW
19:56 brrt joined #moarvm
19:56 zakharyas joined #moarvm
19:56 brrt hmmmm
19:57 brrt weird
19:57 brrt which windows are you on?
19:57 brrt i'll start a vm
19:57 FROGGS mine :P
19:57 FROGGS no problem, I've got a fix I think
19:59 dalek MoarVM/libuv-1.6.1-update: eedb1fb | FROGGS++ | build/setup.pm:
19:59 dalek MoarVM/libuv-1.6.1-update: link to userenv.dll on windows for latest libuv
19:59 dalek MoarVM/libuv-1.6.1-update: review: https://github.com/MoarVM/MoarVM/commit/eedb1fbb91
19:59 FROGGS brrt: ^^
19:59 brrt aha
19:59 brrt quick find
19:59 FROGGS now I continue testing
20:00 brrt thanks
20:00 brrt lizmat: i'm especially also interested in os x, winkwinknudgenudge ;-)
20:16 lucasb timotimo: for the changes from 1.0 to 1.6, maybe it is mostly bug fixes. (sorry for the delay, I was away)
20:17 lucasb https://github.com/libuv/libuv/blob/v1.x/ChangeLog
20:21 FROGGS brrt: that's the fallow: https://gist.github.com/FROGGS/49e998a91482821ec1bb
20:21 FROGGS brrt: I know it is usually not clean on windows, so I'll rerun with libuv 1.
20:21 brrt wow, that's actually pretty bad
20:21 FROGGS 1.0*
20:22 brrt please do
20:23 timotimo cool, thanks lucasb
20:24 nwc10 jnthn: http://paste.scsys.co.uk/491510 is what ASAN makes of MVM_SPESH_NODELAY=1 and t/moar/01-continuations.t
20:25 timotimo i've seen this sort of error where it kinda looks like we're returning into an already-freed spesh bytecode segment or something
20:25 timotimo it completely stumped me :\
20:30 japhb joined #moarvm
20:38 brrt FROGGS: i even see normal tests fail :-(
20:48 FROGGS brrt: I updated the gist
20:49 FROGGS and it seems that windows is just unhappy in general
20:50 FROGGS m: say <0x01/0x03> / (0x01/0x03) == 1
20:50 camelia rakudo-moar 7c35c5: OUTPUT«True␤»
20:50 brrt what's the diff?
20:51 FROGGS C:\rakudo>perl6-m -e "say <0x01/0x03> / (0x01/0x03)"
20:51 FROGGS Attempt to divide by zero using div
20:52 FROGGS brrt: the diff is that the sleep test worked on 1.6.1
20:52 brrt can be an accident, the sleep test working
20:52 FROGGS C:\rakudo>perl6-m -e "say <0x01/0x03>"
20:52 FROGGS Attempt to divide by zero using div
20:52 FROGGS true
20:52 FROGGS m: say <0x01/0x03>
20:52 camelia rakudo-moar 7c35c5: OUTPUT«0.333333␤»
20:53 brrt hmm, frustrating
20:53 FROGGS C:\rakudo>perl6-m -e "say <0x01/3>"
20:53 FROGGS 0
20:54 FROGGS that's weird
20:54 brrt rather
20:54 brrt i'm off for tonight
20:54 FROGGS gnight
21:05 japhb m: say +'0x01/0x03'
21:05 camelia rakudo-moar 7c35c5: OUTPUT«0.333333␤»
21:06 japhb Because Str.Numeric.  Boo-yah.
21:06 FROGGS but how can that be different on windows?
21:10 japhb FROGGS: <0x01/0x03> and +'0x01/0x03' are different parsers.  Though why it would be different on Windows, I have no idea.  Unless perhaps some obtuse compiler-sensitive bug in the grammar engine.
21:10 japhb *are parsed by different parsers
21:17 colomon joined #moarvm
21:18 TEttinger joined #moarvm
21:39 colomon joined #moarvm
22:29 colomon joined #moarvm
23:58 TimToady joined #moarvm

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