From: Jesse Vincent Date: Wed, 3 Sep 2008 00:01:47 +0000 (+0000) Subject: i* Added the first version of rough notes on how MooseX::Compile is to X-Git-Tag: 0.57~23 X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=commitdiff_plain;h=8eeebd49a30fa4fc5f30d56018fa02cd89300792;p=gitmo%2FMoose.git i* Added the first version of rough notes on how MooseX::Compile is to work in the form of an IRC conversation with yuval --- diff --git a/MANIFEST.SKIP b/MANIFEST.SKIP index 9495dd8..97affd5 100644 --- a/MANIFEST.SKIP +++ b/MANIFEST.SKIP @@ -17,6 +17,7 @@ cover_db ^\.# ^TODO$ ^PLANS$ +^doc/ ^benchmarks ^\._.*$ ^t\/600_todo_tests\/$ diff --git a/doc/moosex-compile b/doc/moosex-compile new file mode 100644 index 0000000..7d72f81 --- /dev/null +++ b/doc/moosex-compile @@ -0,0 +1,176 @@ +MooseX-Compile, wherein Yuval explains how MooseX::Compile is supposed to work and what needs doing. + +TODO: PLEASE EDIT ME + +19:11 hiya +19:12 hola +19:13 so, my empty mail was an attempted abort +19:13 but was going to be "MX::Compile doesn't depend on MX::Compile::CLI. should it?" +19:13 ah, ok =) +19:13 but i'm without my laptop, so i couldn't actually check my assumption +19:14 no, because MX::Compile::CLI is "just a a frontend" and at the time the dependencies were a little sketchy +19:14 they've since matured, so maybe it should dep +19:21 * obra nods +19:21 I was on a plane and was trying to see if MX::Compile was at the point where I could try trivial tests +19:22 ah +19:22 so the answer is definitely maybe ;-) +19:22 i haven't been able to make time for it in the past week +19:23 if you guys hand me small, targetted test cases (just commit to it) of code that passes under plain Moose and should pass with MX::Compile i can probably do that stuff pretty quickly +19:23 but the biggest barrier MXC has right now is testing, in order for it to progress towards something production worthy it basically needs to pass the Moose test suite +19:23 except without the Moose test suite's assumptions +19:23 about state and module loading, and all that +19:24 and doing that is a much more daunting prospect than hacking on MXC itself +19:24 understood. the problem is that I still don't have a good sense of how to get it going, even manually +19:24 ah +19:24 none of the test files seem to show off what I need +19:24 i can walk you through thjat +19:25 the assumptions of the system are: +19:25 the class you are compiling is in its own .pm using standard moose sugar +19:25 there is one package in that file +19:26 the compiler object takes the metaclass and the .pm file as args +19:26 it serializes the metaclass to a .mopc file, and the generated code into a .pmc +19:26 the .pmc contains the original .pm verbatim +19:26 except that all the moose sugar does nothing +19:27 meta is overriden to lazy load .mopc +19:27 and the class is supposed to be usable without loading Moose at all +19:27 what is the point of containing the original pm verbatim? +19:27 the user code +19:28 could open and slurp and eval +19:28 but this is a little more flexible +19:28 basically any subroutines the user has written, global/lexical variable initialization, loading of assorted modules etc all must work +19:28 are you using the flexibility? +19:28 (open, slurp, eval sounds suspiciously like "do") +19:29 can't use do/require/etc because it will go to the .pmc +19:29 instead of the .pm +19:29 the flexibility is helpful because you get a lexical set if the code is compiled +19:29 for when you need to do trickery +19:29 see Moose/Object.pm +19:29 I didn't think 'do' had that logic. but ok :) +19:30 anyway +19:30 do go on +19:30 now that we have Devel::Declare that might prove even simpler +19:30 simply replacing has() etc to export the subs inline +19:30 and write the resulting buffers to a .pmc +19:30 but that's for Later™ +19:30 The fact that the TM shows up in my terminal scare me +19:30 but only a bit less than that you typed it ;) +19:30 utf8++ +19:31 ubuntu++ +19:31 most linuxes seem to get that refreshingly right +19:31 so, erm +19:31 yeah. it's pleasant. +19:31 mxcompile +19:31 anyway +19:31 that is a nice frontend to the compiler object +19:31 I guess "what do I need to do to try MX::Compile for prophet+sd?" +19:31 it can recurse through a directory of modules, or take a list of classes +19:31 for starters, role support +19:31 i know how to do it +19:31 but haven't yet +19:32 type constraint support is very primitive +19:32 is that essentially the same code sartak needs to write to give Mouse roles? +19:32 i don't know what that is but doesn't sound likely +19:32 in MXC moose has already done the role composition +19:32 i just need to figure where the data came from, load that file and realias the subs +19:33 (at bootstrap time) +19:33 no role composition per se +19:33 it's nice to make clear that MXC has two "levels" of awesome +19:33 so you can figure out what you can hope to achieve +19:34 100% compiled everything means you don't load Moose or Class::MOP +19:34 until you need runtime reflection +19:34 no codegen at compile time +19:34 it should load as fast as hand written code +19:34 i've had it beating Object::Tiny in some benchmarks =) +19:35 oo +19:35 Moose::XS should aid in making MooseX::Compile's supported feature set easier +19:35 the less awesome level of awesome is just some classes +19:35 you don't pay for those classes' compilation (Role composition, etc) +19:35 (especially since for me perl -MMoose -e1 takes up 50% of "sd help"'s runtime +19:36 (.4s here) +19:36 5.8.8/ +19:36 ? +19:36 yeah +19:36 "that's what's in the wild" +19:36 i'm just curious if it makes a dfif +19:36 * obra nods +19:36 I don't have my macbook right now or I'd test +19:36 trunk moose loads slower +19:36 how much slower? +19:36 but 5.10 loads faster +19:36 negligiably +19:36 i think like 10% +19:36 this was trunk moose as of friday +19:36 but we can fix that +19:36 ah +19:36 my tests aren't scientific. +19:36 trunk moose as of you sending me nytprofs +19:37 actually that's CPAN moose now +19:37 0.35 - 0.45 +19:37 ouch +19:37 well, part of the problem is that it loads *EVERYTHING* +19:37 every type of meta method class, meta type constraint, the role system, etc +19:37 for a big app these probably will get loaded +19:38 but for a small app, especially if you load the various sub modules only as needed, you shouldn't pay for these +19:38 that's a trivial fix that perigrin started working on +19:38 yeah. I played with his branch and saw no change as of last night +19:39 so yeah, we're using roles. if roles aren't ready yet, I won't get far at all. +19:39 (Also, I do really appreciate all the work you're doing. That I'm not paying for, even ;) +19:39 Thank you. +19:39 i will try shaving Moose's own load time with a profile based approach +19:39 It's SO MUCH better than it was +19:39 well, everybody wins =) +19:39 a. you're a friend +19:40 b. part of my job is making Moose work well +19:40 c. your using Moose helps moose directly and indirectly +19:40 d. I LIKE TACOS +19:40 erm, i mean sushi +19:40 so no worries on that +19:41 so, long term goals: +19:41 App::SD etc has all the meta calculations already cached in .mopc and .pmc +19:41 moose is not loaded +19:41 all generated code is cached +19:41 at worst Moose::XS is loaded to install subs with newXS +19:41 that would be really cool +19:41 depending on which actually fairs better +19:42 that goal is realistic, but involves a lot of work +19:42 more realistic short term goals: +19:42 I started playing with try to dump the symbol table, etc +19:42 MooseX::Compile partly speeding up SD +19:42 we can incrementally improve on that +19:42 and found that DD::Streamer is a lot closer than anything has ever been, but it craps out around not being able to dump lvalue subs +19:43 Moose::XS replacing some code gen +19:43 yes, the initial approach was to to try and marshall Moose classes into DDS +19:43 but it wasn't stable enough +19:43 and also there's the problem of imports +19:43 you must serialize the whole table at once +19:43 or manage an intricate web of inter dependencies +19:43 * obra nods +19:44 i sort of work around that by making all the require()/use() statements stay verbatim +19:44 also it doesn't handle xsubs +19:44 how hard would it be to get moose's codegen to write out source code instead of blowing subs into memory? +19:44 so there's guesswork for where ::bootstrap was called +19:44 i was just getting to that = +19:44 =) +19:44 pretty trivial +19:44 heh +19:44 just grunt work +19:44 is that a more viable approach? +19:44 it's one of the limiting parts of MooseX::Compile +19:45 if we clean up that code it will be easier to add support for more features +19:45 but it's not a huge hurdle since it's a very contained problem +19:45 it doesn't directly affect the design of MXC +19:45 is this stuff written down anywhere other than this buffer? +19:45 i don't think so +19:46 where should it get pasted? +19:46 good question =) +19:46 i think #moose-dev is pretty aware +19:46 is there a moose wiki? +19:46 but documenting is good for people to help out +19:46 no, there should be +19:46 yeah. but the goal is to turn it into written docs. +19:46 ok. for now, it should end up in MooseX-Compile/doc/design +19:46 sounds good +19:46 . o O { Thank god I don't have a moose commit bit } +19:47 though most of this affects moose itself though +19:47 * obra nods +19:47 Moose/doc/moosex-compile, then