make the 'reset' delegation for Counter respect builders
[gitmo/Moose.git] / doc / moosex-compile
CommitLineData
8eeebd49 1MooseX-Compile, wherein Yuval explains how MooseX::Compile is supposed to work and what needs doing.
2
3TODO: PLEASE EDIT ME
4
519:11 <obra> hiya
619:12 <nothingmuch> hola
719:13 <obra> so, my empty mail was an attempted abort
819:13 <obra> but was going to be "MX::Compile doesn't depend on MX::Compile::CLI. should it?"
919:13 <nothingmuch> ah, ok =)
1019:13 <obra> but i'm without my laptop, so i couldn't actually check my assumption
1119:14 <nothingmuch> no, because MX::Compile::CLI is "just a a frontend" and at the time the dependencies were a little sketchy
1219:14 <nothingmuch> they've since matured, so maybe it should dep
1319:21 * obra nods
1419:21 <obra> I was on a plane and was trying to see if MX::Compile was at the point where I could try trivial tests
1519:22 <nothingmuch> ah
1619:22 <nothingmuch> so the answer is definitely maybe ;-)
1719:22 <nothingmuch> i haven't been able to make time for it in the past week
1819:23 <nothingmuch> 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
1919:23 <nothingmuch> 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
2019:23 <nothingmuch> except without the Moose test suite's assumptions
2119:23 <nothingmuch> about state and module loading, and all that
2219:24 <nothingmuch> and doing that is a much more daunting prospect than hacking on MXC itself
d03bd989 2319:24 <obra> understood. the problem is that I still don't have a good sense of how to get it going, even manually
8eeebd49 2419:24 <nothingmuch> ah
2519:24 <obra> none of the test files seem to show off what I need
2619:24 <nothingmuch> i can walk you through thjat
2719:25 <nothingmuch> the assumptions of the system are:
2819:25 <nothingmuch> the class you are compiling is in its own .pm using standard moose sugar
2919:25 <nothingmuch> there is one package in that file
3019:26 <nothingmuch> the compiler object takes the metaclass and the .pm file as args
3119:26 <nothingmuch> it serializes the metaclass to a .mopc file, and the generated code into a .pmc
3219:26 <nothingmuch> the .pmc contains the original .pm verbatim
3319:26 <nothingmuch> except that all the moose sugar does nothing
3419:27 <nothingmuch> meta is overriden to lazy load .mopc
3519:27 <nothingmuch> and the class is supposed to be usable without loading Moose at all
3619:27 <obra> what is the point of containing the original pm verbatim?
3719:27 <nothingmuch> the user code
3819:28 <nothingmuch> could open and slurp and eval
3919:28 <nothingmuch> but this is a little more flexible
4019:28 <nothingmuch> basically any subroutines the user has written, global/lexical variable initialization, loading of assorted modules etc all must work
4119:28 <obra> are you using the flexibility?
4219:28 <obra> (open, slurp, eval sounds suspiciously like "do")
4319:29 <nothingmuch> can't use do/require/etc because it will go to the .pmc
4419:29 <nothingmuch> instead of the .pm
4519:29 <nothingmuch> the flexibility is helpful because you get a lexical set if the code is compiled
4619:29 <nothingmuch> for when you need to do trickery
4719:29 <nothingmuch> see Moose/Object.pm
4819:29 <obra> I didn't think 'do' had that logic. but ok :)
4919:30 <obra> anyway
5019:30 <obra> do go on
5119:30 <nothingmuch> now that we have Devel::Declare that might prove even simpler
5219:30 <nothingmuch> simply replacing has() etc to export the subs inline
5319:30 <nothingmuch> and write the resulting buffers to a .pmc
5419:30 <nothingmuch> but that's for Laterâ„¢
5519:30 <obra> The fact that the TM shows up in my terminal scare me
5619:30 <obra> but only a bit less than that you typed it ;)
5719:30 <nothingmuch> utf8++
5819:31 <obra> ubuntu++
5919:31 <nothingmuch> most linuxes seem to get that refreshingly right
6019:31 <nothingmuch> so, erm
6119:31 <obra> yeah. it's pleasant.
6219:31 <nothingmuch> mxcompile
6319:31 <obra> anyway
6419:31 <nothingmuch> that is a nice frontend to the compiler object
6519:31 <obra> I guess "what do I need to do to try MX::Compile for prophet+sd?"
6619:31 <nothingmuch> it can recurse through a directory of modules, or take a list of classes
6719:31 <nothingmuch> for starters, role support
6819:31 <nothingmuch> i know how to do it
6919:31 <nothingmuch> but haven't yet
7019:32 <nothingmuch> type constraint support is very primitive
7119:32 <obra> is that essentially the same code sartak needs to write to give Mouse roles?
7219:32 <nothingmuch> i don't know what that is but doesn't sound likely
7319:32 <nothingmuch> in MXC moose has already done the role composition
7419:32 <nothingmuch> i just need to figure where the data came from, load that file and realias the subs
7519:33 <nothingmuch> (at bootstrap time)
7619:33 <nothingmuch> no role composition per se
7719:33 <nothingmuch> it's nice to make clear that MXC has two "levels" of awesome
7819:33 <nothingmuch> so you can figure out what you can hope to achieve
7919:34 <nothingmuch> 100% compiled everything means you don't load Moose or Class::MOP
8019:34 <nothingmuch> until you need runtime reflection
8119:34 <nothingmuch> no codegen at compile time
8219:34 <nothingmuch> it should load as fast as hand written code
8319:34 <nothingmuch> i've had it beating Object::Tiny in some benchmarks =)
8419:35 <obra> oo
8519:35 <nothingmuch> Moose::XS should aid in making MooseX::Compile's supported feature set easier
8619:35 <nothingmuch> the less awesome level of awesome is just some classes
8719:35 <nothingmuch> you don't pay for those classes' compilation (Role composition, etc)
8819:35 <obra> (especially since for me perl -MMoose -e1 takes up 50% of "sd help"'s runtime
8919:36 <obra> (.4s here)
9019:36 <nothingmuch> 5.8.8/
9119:36 <nothingmuch> ?
9219:36 <obra> yeah
9319:36 <obra> "that's what's in the wild"
9419:36 <nothingmuch> i'm just curious if it makes a dfif
9519:36 * obra nods
9619:36 <obra> I don't have my macbook right now or I'd test
9719:36 <nothingmuch> trunk moose loads slower
9819:36 <obra> how much slower?
9919:36 <nothingmuch> but 5.10 loads faster
10019:36 <nothingmuch> negligiably
10119:36 <nothingmuch> i think like 10%
10219:36 <obra> this was trunk moose as of friday
10319:36 <nothingmuch> but we can fix that
10419:36 <nothingmuch> ah
10519:36 <obra> my tests aren't scientific.
10619:36 <nothingmuch> trunk moose as of you sending me nytprofs
10719:37 <nothingmuch> actually that's CPAN moose now
d03bd989 10819:37 <obra> 0.35 - 0.45
8eeebd49 10919:37 <nothingmuch> ouch
11019:37 <nothingmuch> well, part of the problem is that it loads *EVERYTHING*
11119:37 <nothingmuch> every type of meta method class, meta type constraint, the role system, etc
11219:37 <nothingmuch> for a big app these probably will get loaded
11319:38 <nothingmuch> but for a small app, especially if you load the various sub modules only as needed, you shouldn't pay for these
11419:38 <nothingmuch> that's a trivial fix that perigrin started working on
11519:38 <obra> yeah. I played with his branch and saw no change as of last night
11619:39 <obra> so yeah, we're using roles. if roles aren't ready yet, I won't get far at all.
11719:39 <obra> (Also, I do really appreciate all the work you're doing. That I'm not paying for, even ;)
11819:39 <obra> Thank you.
11919:39 <nothingmuch> i will try shaving Moose's own load time with a profile based approach
12019:39 <obra> It's SO MUCH better than it was
12119:39 <nothingmuch> well, everybody wins =)
12219:39 <nothingmuch> a. you're a friend
12319:40 <nothingmuch> b. part of my job is making Moose work well
12419:40 <nothingmuch> c. your using Moose helps moose directly and indirectly
12519:40 <nothingmuch> d. I LIKE TACOS
12619:40 <nothingmuch> erm, i mean sushi
12719:40 <nothingmuch> so no worries on that
12819:41 <nothingmuch> so, long term goals:
12919:41 <nothingmuch> App::SD etc has all the meta calculations already cached in .mopc and .pmc
13019:41 <nothingmuch> moose is not loaded
13119:41 <nothingmuch> all generated code is cached
13219:41 <nothingmuch> at worst Moose::XS is loaded to install subs with newXS
13319:41 <obra> that would be really cool
13419:41 <nothingmuch> depending on which actually fairs better
13519:42 <nothingmuch> that goal is realistic, but involves a lot of work
13619:42 <nothingmuch> more realistic short term goals:
13719:42 <obra> I started playing with try to dump the symbol table, etc
13819:42 <nothingmuch> MooseX::Compile partly speeding up SD
13919:42 <nothingmuch> we can incrementally improve on that
14019:42 <obra> 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
14119:43 <nothingmuch> Moose::XS replacing some code gen
14219:43 <nothingmuch> yes, the initial approach was to to try and marshall Moose classes into DDS
14319:43 <nothingmuch> but it wasn't stable enough
14419:43 <nothingmuch> and also there's the problem of imports
14519:43 <nothingmuch> you must serialize the whole table at once
14619:43 <nothingmuch> or manage an intricate web of inter dependencies
14719:43 * obra nods
14819:44 <nothingmuch> i sort of work around that by making all the require()/use() statements stay verbatim
14919:44 <nothingmuch> also it doesn't handle xsubs
15019:44 <obra> how hard would it be to get moose's codegen to write out source code instead of blowing subs into memory?
15119:44 <nothingmuch> so there's guesswork for where ::bootstrap was called
15219:44 <nothingmuch> i was just getting to that =
15319:44 <nothingmuch> =)
15419:44 <nothingmuch> pretty trivial
15519:44 <obra> heh
15619:44 <nothingmuch> just grunt work
15719:44 <obra> is that a more viable approach?
15819:44 <nothingmuch> it's one of the limiting parts of MooseX::Compile
15919:45 <nothingmuch> if we clean up that code it will be easier to add support for more features
16019:45 <nothingmuch> but it's not a huge hurdle since it's a very contained problem
16119:45 <nothingmuch> it doesn't directly affect the design of MXC
16219:45 <obra> is this stuff written down anywhere other than this buffer?
16319:45 <nothingmuch> i don't think so
16419:46 <obra> where should it get pasted?
16519:46 <nothingmuch> good question =)
16619:46 <nothingmuch> i think #moose-dev is pretty aware
16719:46 <obra> is there a moose wiki?
16819:46 <nothingmuch> but documenting is good for people to help out
16919:46 <nothingmuch> no, there should be
17019:46 <obra> yeah. but the goal is to turn it into written docs.
17119:46 <obra> ok. for now, it should end up in MooseX-Compile/doc/design
17219:46 <nothingmuch> sounds good
d03bd989 17319:46 <obra> . o O { Thank god I don't have a moose commit bit }
8eeebd49 17419:47 <nothingmuch> though most of this affects moose itself though
17519:47 * obra nods
17619:47 <obra> Moose/doc/moosex-compile, then