|
github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today Set by moderator on 3 August 2013. |
|||
|
01:40
lizmat joined
|
|||
| colomon | Fixed ABC module. Turns out I long ago used "our method" to declare a few of the methods, and early last week some Rakudo change broke that. | 02:07 | |
| timotimo | what was that supposed to do? | 02:08 | |
| colomon | heck if I remember | 02:11 | |
| probably just to export the method out of the module | |||
| might even have been an attempt to work around a bug that got left in the code by accident. | 02:12 | ||
| at any rate, it worked like just plain "method" would have a month ago in Rakudo, and still does in Niecza. | |||
| timotimo | :) | 02:13 | |
| colomon | bet the flower module failure is the same thing, I see it's using "our submethod" in a couple of places. | 02:41 | |
| and perl6-web-template is failing because flower is. | 02:44 | ||
| benabik | .oO( Wonders if colomon knows this is #moarvm and not #perl6 ) |
02:45 | |
| colomon | benabik: doh! | ||
| benabik | Not that there isn't a notable amount of overlap... | ||
| colomon | benabik++ | 02:47 | |
| colomon slinks back to #perl6.... | |||
|
04:33
lizmat joined
05:49
FROGGS joined
06:00
FROGGS joined
06:31
crab2313 joined
07:08
FROGGS joined
|
|||
| JimmyZ | Good afternoon | 07:22 | |
| sorear | o/ | 07:23 | |
| JimmyZ | \\o | 07:25 | |
|
09:26
FROGGS[mobile] joined
|
|||
| FROGGS[mobile] | o/ | 09:28 | |
| sorear: long time no see | 09:29 | ||
| jnthn | morning, #moarvm | 09:32 | |
| JimmyZ | morning, jnthn | 09:34 | |
| jnthn: how about merge readlineintfh2 branch? it works very well on windows, with ctrl+key(ctrl + r, etc) | 09:36 | ||
| jnthn | JimmyZ: I...didn't even see what branches have happened while I was gone yet:) | 09:37 | |
| JimmyZ | hehe | ||
| jnthn: how about remove 'type_object' args in MVM_decode_C_buffer_to_string and other decode functions? | 09:59 | ||
| FROGGS[mobile] | JimmyZ: you propose to change the nqp ops too? | 10:08 | |
| jnthn | JimmyZ: In favor of what? | 10:11 | |
| Building latest MoarVM fails for me :( | 10:12 | ||
| FROGGS[mobile] | oh dear | ||
| how? | 10:13 | ||
| jnthn | Loads of linker errors related to APR | ||
| FROGGS[mobile] | I hab to remove apr's build dir at some point | 10:14 | |
| jnthn | Like | ||
| apr-1.lib(filedup.obj) : error LNK2019: unresolved external symbol __imp_setvbuf referenced in function apr_file_dup2 | |||
| jnthn tries that | |||
| FROGGS[mobile] | I believe there is a Release dir in apr/, remove it and build afresh | 10:15 | |
| dunno why though, I'm building rarely on windows | 10:16 | ||
| jnthn | Yeah, git clean -fdx 3rdparty helped | 10:18 | |
| JimmyZ | jnthn: just looks like needless | 10:36 | |
| jnthn | JimmyZ: The param is being used, no? | ||
| JimmyZ | jnthn: just always tc->...VMstring | 10:37 | |
| re: apr build failed, for implementing getenvhash, I changed to link libcmt, instead of msvcrt | 10:39 | ||
| jnthn: the param looks like tc->...oshandle before in fileops.c | 10:41 | ||
| so for type_object param, Will there be any value instead of 'tc->instance->VMString' ? | 11:29 | ||
| jnthn | JimmyZ: Probably not for the time being. | 11:30 | |
| Potentially some day it'd come out of HLL config but we've no need/use for that right now. | 11:31 | ||
| Str in Perl 6 will point to a VMString. | |||
| So we could probably go same way as we did with fileops.c | 11:32 | ||
| JimmyZ | oh yeah, that's want I want to know also, jnthn++ | 11:33 | |
| s/want I/what I/ | |||
| jnthn: I was trying compiling QASTOperationsMAST.nqp, but got gist.github.com/zhuomingliang/6102349, the cause is the 'nqp::splice' line | 12:18 | ||
| jnthn | JimmyZ: k, will look, thanks | 12:19 | |
| JimmyZ | jnthn: thanks :P | 12:20 | |
| jnthn | Just working on porting the compile time bind analysis stuff on JVM at the moment. | ||
| JimmyZ | good | 12:22 | |
| timotimo | i'm heating up my benchmarking machine already, jnthn :) | 12:46 | |
|
14:19
birdwindupbird joined
14:39
FROGGS joined
15:03
crab2313 joined
15:24
benabik joined
|
|||
| diakopter | sorear: hi! :) | 15:25 | |
| jnthn: ping | 15:32 | ||
| jnthn: at oscon I met Damian Conway | 15:33 | ||
| we talked about MoarVM and things | |||
| jnthn | diakopter: o/ | ||
| diakopter: nice | |||
| diakopter | he said that after a couple weeks from now, he (suddenly) has the rest of the year open, so he's looking for things to tackle | ||
| jnthn | wow :) | 15:34 | |
| diakopter | I wasn't able to get him super-excited about anything in particular, but I'm guessing you or pm could | ||
| he was certainly interested | 15:35 | ||
| we couldn't think of an ultra-compelling demo use case for the p5interop - something that showcased the stackless cross-vm callbacks and/or .. hm, now I don't remember the other thing | 15:36 | ||
| jnthn: another thing from oscon: | 15:37 | ||
| discussed including the sregex library in MoarVM with a couple folks | |||
| (agentzh's regex JIT) | |||
| I think it would be VERY worth it to include that in MoarVM before any other JIT | 15:38 | ||
| since regexes are generally abominably slow compared to p5 currently | |||
| lizmat | why would you want to include another regex engine when rakudo has one? | ||
| diakopter | since it'd be thousands of times faster | ||
| lizmat | aren't there severe compatibility concerns ? | 15:39 | |
| yes, faster but wrong ? | |||
| diakopter | surely you're kidding | ||
| lizmat | let me rephrase that: why does rakudo have its own regex engine, when it could be done with sregex | ||
| diakopter | "but won't you incorporate it badly?" | 15:40 | |
| "it" is defined poorly there | |||
| "it could be done" | |||
| I wasn't saying "ALL regexes" could be done | |||
| lizmat | maybe I dpn't understand what sregex is then | ||
| benabik | diakopter: "but doesn't P6 have a different definition of regexen than other things" | ||
| diakopter | just the ones that sregex can handle | ||
| okay. | |||
| timotimo | is there a way to weave slow parts into sregex to make it cover all of p6 rules? | 15:41 | |
| diakopter | no; it'd be an optimization, just like the NFA one | ||
| we don't say "but doesn't P6 have a different definition of regexen than what NFA can handle?" | 15:42 | ||
| we simply don't use the NFA optimization when it can't be used | |||
| we don't say "why does rakudo have its own regex engine, when it could be done with a native NFA engine?" | |||
| timotimo | ah. but a complex rule could be sped up even if it has sregex-incompatible parts by using sregex on the whole rest? does that work? | ||
| diakopter | right, just like the nfa optimization | ||
| timotimo | that clears up everything for me | 15:43 | |
| sounds very nice to have, indeed. | |||
| diakopter | maybe. | ||
| but it's at least worth experimenting with | |||
| lizmat: you don't see value in making 80% of regexes 900000% faster? | 15:45 | ||
| lizmat | I do, I do | ||
| diakopter | because it's unfair to the other 20%? | ||
| lizmat | no no no | 15:46 | |
| timotimo | stop arguing, you've convinced us ;) | ||
| diakopter | I'm just speculating possible objections | ||
| because it makes the other 20% seem cripple and not useful | |||
| crippled* | |||
| punitive | |||
| lizmat | I sorta assumed "including" meant replacing, like you can sorta replace the regex engine in perl5 | 15:47 | |
| diakopter | oh | ||
| it would need extended to integrate with my libicu reimplementation | 15:48 | ||
| (which could ruin its entire speed benefit) | |||
| (if it uses jump/lookup tables of ascii/ansi size all over the place) | 15:49 | ||
| lizmat | well, let me put it this way: I'd rather see effort put into making the regex engine as a total faster | ||
| than going for a quick performance benefit that may be lost in the long run when doing e.g. NFC | |||
| diakopter | I'm not very confident that's possible | ||
| NFC? | 15:50 | ||
| it could be integrated with an NFG implementation without detriment | |||
| lizmat | NFG is what I meant | ||
| diakopter | well it would add another translation layer of index, but that's ok | 15:51 | |
| lizmat | when I hear you talking about ascii based jump tables, it makes me shudder in that respect | ||
| diakopter | I was definitely admitting that making it very unicode aware might kill any benefit... | 15:52 | |
| timotimo | let's invent an encoding that puts all of unicode into just 8 bits | ||
| diakopter | timotimo: actually, the storage optimization TimToady came up with for NFG will do that for NEARLY ALL strings | ||
| .. if not every string ever seen in actual non-pathological input | 15:53 | ||
| timotimo | that sounds great | ||
| arnsholt | diakopter: Using high-bit characters as index carriers, or something along those lines? | ||
| diakopter | but it does require another translation layer | ||
| arnsholt | (the storage optimisation, that is) | ||
| JimmyZ | sregex? looks good | ||
| diakopter | arnsholt: yes, to segment the point space into two areas, the lower area that map directly, and the upper area that map through another lookup table | 15:54 | |
| arnsholt | Yeah, that makes sense | 15:55 | |
| diakopter | so the only thing needing to be stored is that upper space lookup table (4,8,16,32,64,128 codepoint/nfg mappings) and the number of bits used for the high area | 15:56 | |
| jnthn | JIT compiling the NFAs used for LTM may help some, but that's not the dominant cost today | ||
| diakopter | I wasn't talking about just for LTM | ||
| JimmyZ | agentzh said sregex is based on swtch.com/~rsc/regexp/regexp2.html | 15:57 | |
| diakopter | jnthn: it can handle captures | ||
| JimmyZ saw Thompson and pike Implementation in that link | 15:58 | ||
| diakopter | jnthn: what's the dominant cost today? | ||
| jnthn | diakopter: Everything else after we decided where we're going, I think :) | 16:00 | |
| diakopter: Building match objects is one notable cost, iirc | |||
| timotimo | jnthn: could it be tweaked like the cursor object has been? | 16:02 | |
| diakopter | decided where we're going? | ||
| jnthn | timotimo: Perhaps some more, I think CAPHASH is partly where the cost is. I already did the LHF there :) | 16:03 | |
| diakopter: The NFAs only decide which alternation or protoregex to go down. | |||
| timotimo | until then, maybe i can speed up rakudo parsing by throwing dots into more subrules that are not used in the actions? | ||
| diakopter | jnthn: right.. what happens after that | 16:04 | |
| jnthn | diakopter: We run the code that the regex compiler produces. :) | ||
| diakopter | okay, that's hilarious, but why.. what do we need from it? just capture offsets? | 16:05 | |
| (if we had all the capture offsets, could you generate the match offsets) | |||
| er, generate the matches? | |||
| (make all the matches nested captures) | 16:06 | ||
|
16:07
FROGGS joined
|
|||
| jnthn | Probably, I'm just saying I'm not sure that (a) finding the offsets is the slow bit today, and (b) a normal JIT would not make a decent job of some of the code we generate anyway, given various bits of it are just nudging positions forward and calling into ops to do comparisons, char class lookups, etc. | 16:07 | |
| If there's anything that sregex may do a LOT better than we do today, it's almost certainly handling the backtracking cases. | 16:08 | ||
| diakopter | I think you're right about (b) | ||
| but I think that's so far away, and this could be a lot sooner | |||
| jnthn | But grammars don't backtrack, so while it'd be a boon for regexes, it'd not for grammars, or at least that's my expectation. | ||
| diakopter | and wouldn't take a huge amount of work | ||
| why don't grammars backtrack? | 16:09 | ||
| jnthn | 'cus keeping state to do that would be costly/really slow. | ||
| token and rule mean "don't backtrack" | |||
| Or rather | |||
| Don't store information needed to backtrack | |||
| diakopter | I know why token doesn't need to backtrack, but why doesn't rule need to backtrack? | 16:10 | |
| jnthn | rule = token + sigspace. | ||
| (the thing that turns whitespace into a <.ws> call) | |||
| diakopter | hm, ok | ||
| jnthn | It's only regex that has backtracking on by default. | 16:11 | |
| And that shows up only a few times in the Perl 6 grammar. | |||
| diakopter | I guess I don't get why rakudo regexes are so slow then, if it's not regex processing itself | ||
| *regex processing logic | |||
| sorry, rakudo grammars | |||
| jnthn suspects method call overhead and match/cursor construction overhead. | 16:12 | ||
| diakopter | why wouldn't a regex JIT (that converted entire grammars to regexes) eliminate all of those? | ||
| er, entire rules in grammars | 16:13 | ||
| jnthn | Perl 6 grammars are, by design, a mix of declarative (probably easy to regex JIT) and imperative (harder as we can get recursion) | ||
| Those that are declarative (that we build the NFA for today) probably can be handed off to a regex JIT. | 16:14 | ||
| One thing Pm and I discussed is whether in certain cases the NFA thing we do today can just say "oh, don't bother doing the work again once you get into this rule, just go right to this char" | |||
| (The answer is it almost certainly can, but finding a neat factoring is harder.) | 16:15 | ||
| diakopter | I was aware of all of that; I was asking what about the imperative portions makes them impossible to JIT to one of these engines | 16:16 | |
| (just recursion? b/c there are ways to eliminate that) | 16:17 | ||
| jnthn | Partly recursion, partly the need to evaluate code blocks | ||
| diakopter | well, in the Perl6 Grammar, are there really inline code blocks? | ||
| (if so, *why*) | |||
| I'd think the special things like bracket matching are just a special case of backreferences | 16:19 | ||
| jnthn | Yes, including in <.ws> | ||
| Which means you can hit 'em pretty quick :) | |||
| diakopter | what in the world is in .ws | ||
| jnthn | github.com/perl6/std/blob/master/STD.pm6#L607 is the STD one | 16:20 | |
| diakopter | so, what if we put fastfail death traps in there.. such as when it hit a point where it would normally do something imperative.. just fall out of the fast thing and back to the slow thing | 16:21 | |
| the only imperative things I see there are optimization attempts | |||
| and error handling | 16:22 | ||
| and the deadly inline comments | |||
| which need vast simplification | 16:23 | ||
| jnthn | "deadly inline comments"? | 16:24 | |
| diakopter | "deadly" with a wink for how they cause grammar slangs | ||
| pod should be moved up to the top level of .ws | 16:25 | ||
| so the rest can be one big declarative thing | 16:26 | ||
| oh boy, there's lots of work of automatic grammar refactoring to be done | 16:27 | ||
| commute & | |||
| well hi | 17:03 | ||
| japhb | o/ | 18:27 | |
| diakopter | japhb: hi | 18:32 | |
| japhb | Hey there! How goes it? | ||
| diakopter | good; how are you? | 18:36 | |
| japhb | Not too bad. | 18:37 | |
| Nice to be coming back to the community, let me tell you ... | |||
| diakopter | heh. | ||
| anyone: my nqp-cc Configure.pl is failing with git fetch failure | 18:39 | ||
| Permission denied (publickey). | |||
| fatal: Could not read from remote repository. | |||
| why would publickey fail to perl6/nqp | 18:40 | ||
| whatever.... rebuilding nqp. :( | 18:44 | ||
| benabik | diakopter: Sounds like an issue between you and github. Or perhaps file permissions in your ~/.ssh dir or something. | 18:46 | |
| diakopter | no | ||
| it didn't like that my nqp dir was empty, but its .git was there | |||
| silly corner case. | |||
| no clue what deleted nqp/ | 18:47 | ||
| .. and of course parrot configure failed too. D: :( :( not my day I guess | 19:00 | ||
| only error from parrot configure: | |||
| During configuration the following steps failed: 01: init::manifest | |||
| init::manifest - Check MANIFEST...No such file: examples/compilers/Makefile | 19:03 | ||
| No such file: examples/embed/Makefile | |||
| No such file: examples/tools/Makefile | |||
| argh..... | |||
| manually restored those files from git... | 19:04 | ||
| benabik | Sounds like you have a file deleting gremlin. | 19:05 | |
| diakopter | and now.. none of nqptest succeeds | 19:34 | |
| jeez. | |||
| japhb | diakopter, I'd just move that entire moarvm tree away and clone and build a completely new one. | 19:36 | |
| Too much strangeness going on, with too many mysterious "fixes" | 19:37 | ||
| diakopter | turns out there was a rogue nqp/moarvm still running | ||
| hidden | |||
| japhb | hidden? | ||
| diakopter | not visible from ther terminal | ||
| japhb | ?!? | ||
| diakopter | happens all teh time on windows | ||
| japhb | Oh. Yeah. WinFail, I forgot you used that. | 19:38 | |
| diakopter | bah, no iculib. | ||
| that's a fail. | |||
| japhb | (TBC, I wasn't calling Windows WinFail, I was referring to the thing that Windows *does* on a regular basis) | 19:39 | |
| japhb separates himself about a micron from fanboydom | |||
| diakopter | yes, I use those. ;) | ||
|
19:56
Alpha64 joined
|
|||
| diakopter | FROGGS: ping | 19:57 | |
| FROGGS | diakopter: pong | 20:04 | |
| diakopter | FROGGS: how do I reproduce your splice problem | 20:05 | |
| nm got it | 20:08 | ||
| FROGGS | k | ||
| $ nqp nqp-moar-cc.nqp -e 'my @a; nqp::splice(@a, @a, 0, 0) if 1;' | 20:09 | ||
| cannot box a void register | |||
| diakopter | whoa; nice golf | 20:10 | |
| FROGGS | had to compile first to make sure to dont paste crap | ||
| diakopter | actually, there's an easy fix here. | 20:22 | |
| FROGGS | diakopter: is it the right one? | 20:23 | |
| diakopter: see github.com/MoarVM/MoarVM/commit/9a...07ddbfc27f | 20:24 | ||
| diakopter | no | 20:27 | |
| nqptesting | 20:36 | ||
| FROGGS: pushed | 20:45 | ||
| dalek | arVM: 9b197c2 | diakopter++ | nqp-cc/src/QASTOperationsMAST.nqp: this actually works just fine. in void context the code to generate the result is thrown away anyway.... |
||
|
20:45
colomon joined
|
|||
| diakopter | FROGGS: what was that blocking? | 20:46 | |
| FROGGS | diakopter: this: irclog.perlgeek.de/moarvm/2013-07-29#i_7383597 | 20:49 | |
| diakopter | right, but.. | ||
|
20:49
Alpha64_ joined
|
|||
| diakopter | FROGGS: try with that patch | 20:51 | |
| git pull | |||
| FROGGS | currently doing | 20:52 | |
| diakopter | oh wait, that's not quite right | 20:53 | |
| meh, it's close enough :) | 20:54 | ||
| FROGGS | :o) | ||
| diakopter | well, that made QASTOperationsMAST.nqp fully compile | 20:59 | |
| FROGGS | cool | ||
| dalek | arVM: 18ce71d | diakopter++ | nqp-cc/tools/build/Makefile.in: cross-compile QASTOperationsMAST.nqp |
||
| diakopter | beat ya | 21:00 | |
| what next | 21:02 | ||
| FROGGS | make it selfhost nqp | 21:03 | |
| ;o) | |||
| diakopter | yeah but what's next to cross-ompile | ||
| FROGGS | no idea | ||
| I dunno at all what is needed in order to do that | 21:04 | ||
| diakopter | I guess MASTTesting and MASTCompiler | ||
|
21:05
crab2313 joined
|
|||
| diakopter | I like how the *.moarvm are 1/3 the size of the corresponding *.pbc | 21:06 | |
| FROGGS | yeah | ||
| diakopter | so.. how do I use this preprocessor to fudge things for moarvm | 21:07 | |
| does #?if moarvm work? | |||
| erm, how is this cross compiler working if it was able to cross-compile QASTCompilerMAST.nqp before it could do QASTOperationsMAST.nqp | 21:10 | ||
| arnsholt | Magic! | 21:26 | |
| diakopter | arnsholt: I guess it just ignores missing symbols? | ||
| arnsholt | Or that. I'm gonna go with magic, since it's past my bedtime =) | 21:28 | |
| diakopter | anyone know if jnthn wants moarvm integrated as a backend in the nqp source tree? | 21:38 | |
| jnthn: do you know? | |||
| nm, I see how to do it for now.. | 22:00 | ||
| jnthn | diakopter: When I did it for JVM, I had a small script that mangled the QASTCompilerMAST equivalent a bit. | 22:01 | |
| diakopter: You compile them a second time, is the trick. | 22:02 | ||
| diakopter: The nqp-jvm-prep repo probably has leftovers from how I did it there. | |||
| diakopter | well I certainly won't be able to tackle the bootstrapping | 22:10 | |
| but I think I can make the stage1 | |||
| or is it stage0 | |||
| heh, I wrote 0x1G | 22:11 | ||
| jnthn: how do I generate the initial NQP.pm? | 23:10 | ||
| gen_cat? | 23:11 | ||
| nm; | 23:24 | ||
|
23:31
benabik joined
|
|||
| jnthn | yes, that | 23:33 | |
| diakopter | jnthn: seems it relies on nqpp6qregex | 23:49 | |
| jnthn | diakopter: correct, that needs cross-compiling, then nqp | 23:53 | |
| Though it was a rather soft target in JVM port, since it doesn't demand all that much that won't already be in place. | |||
|
23:57
benabik joined
23:58
ggoebel joined
|
|||