bump version for next release
[gitmo/Moose.git] / doc / moosex-compile
1 MooseX-Compile, wherein Yuval explains how MooseX::Compile is supposed to work and what needs doing.
2
3 TODO: PLEASE EDIT ME
4
5 19:11 <obra> hiya
6 19:12 <nothingmuch> hola
7 19:13 <obra> so, my empty mail was an attempted abort
8 19:13 <obra> but was going to be "MX::Compile doesn't depend on MX::Compile::CLI. should it?"
9 19:13 <nothingmuch> ah, ok =)
10 19:13 <obra> but i'm without my laptop, so i couldn't actually check my assumption
11 19:14 <nothingmuch> no, because MX::Compile::CLI is "just a a frontend" and at the time the dependencies were a little sketchy
12 19:14 <nothingmuch> they've since matured, so maybe it should dep
13 19:21  * obra nods
14 19: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
15 19:22 <nothingmuch> ah
16 19:22 <nothingmuch> so the answer is definitely maybe ;-)
17 19:22 <nothingmuch> i haven't been able to make time for it in the past week
18 19: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
19 19: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
20 19:23 <nothingmuch> except without the Moose test suite's assumptions
21 19:23 <nothingmuch> about state and module loading, and all that
22 19:24 <nothingmuch> and doing that is a much more daunting prospect than hacking on MXC itself
23 19:24 <obra> understood. the problem is that I still don't have a good sense of how to get it going, even manually
24 19:24 <nothingmuch> ah
25 19:24 <obra> none of the test files seem to show off what I need
26 19:24 <nothingmuch> i can walk you through thjat
27 19:25 <nothingmuch> the assumptions of the system are:
28 19:25 <nothingmuch> the class you are compiling is in its own .pm using standard moose sugar
29 19:25 <nothingmuch> there is one package in that file
30 19:26 <nothingmuch> the compiler object takes the metaclass and the .pm file as args
31 19:26 <nothingmuch> it serializes the metaclass to a .mopc file, and the generated code into a .pmc
32 19:26 <nothingmuch> the .pmc contains the original .pm verbatim
33 19:26 <nothingmuch> except that all the moose sugar does nothing
34 19:27 <nothingmuch> meta is overriden to lazy load .mopc
35 19:27 <nothingmuch> and the class is supposed to be usable without loading Moose at all
36 19:27 <obra> what is the point of containing the original pm verbatim?
37 19:27 <nothingmuch> the user code
38 19:28 <nothingmuch> could open and slurp and eval
39 19:28 <nothingmuch> but this is a little more flexible
40 19:28 <nothingmuch> basically any subroutines the user has written, global/lexical variable initialization, loading of assorted modules etc all must work
41 19:28 <obra> are you using the flexibility?
42 19:28 <obra> (open, slurp, eval sounds suspiciously like "do")
43 19:29 <nothingmuch> can't use do/require/etc because it will go to the .pmc
44 19:29 <nothingmuch> instead of the .pm
45 19:29 <nothingmuch> the flexibility is helpful because you get a lexical set if the code is compiled
46 19:29 <nothingmuch> for when you need to do trickery
47 19:29 <nothingmuch> see Moose/Object.pm
48 19:29 <obra> I didn't think 'do' had that logic. but ok :)
49 19:30 <obra> anyway
50 19:30 <obra> do go on
51 19:30 <nothingmuch> now that we have Devel::Declare that might prove even simpler
52 19:30 <nothingmuch> simply replacing has() etc to export the subs inline
53 19:30 <nothingmuch> and write the resulting buffers to a .pmc
54 19:30 <nothingmuch> but that's for Laterâ„¢
55 19:30 <obra> The fact that the TM shows up in my terminal scare me
56 19:30 <obra> but only a bit less than that you typed it ;)
57 19:30 <nothingmuch> utf8++
58 19:31 <obra> ubuntu++
59 19:31 <nothingmuch> most linuxes seem to get that refreshingly right
60 19:31 <nothingmuch> so, erm
61 19:31 <obra> yeah. it's pleasant.
62 19:31 <nothingmuch> mxcompile
63 19:31 <obra> anyway
64 19:31 <nothingmuch> that is a nice frontend to the compiler object
65 19:31 <obra> I guess "what do I need to do to try MX::Compile for prophet+sd?"
66 19:31 <nothingmuch> it can recurse through a directory of modules, or take a list of classes
67 19:31 <nothingmuch> for starters, role support
68 19:31 <nothingmuch> i know how to do it
69 19:31 <nothingmuch> but haven't yet
70 19:32 <nothingmuch> type constraint support is very primitive
71 19:32 <obra> is that essentially the same code sartak needs to write to give Mouse roles?
72 19:32 <nothingmuch> i don't know what that is but doesn't sound likely
73 19:32 <nothingmuch> in MXC moose has already done the role composition
74 19:32 <nothingmuch> i just need to figure where the data came from, load that file and realias the subs
75 19:33 <nothingmuch> (at bootstrap time)
76 19:33 <nothingmuch> no role composition per se
77 19:33 <nothingmuch> it's nice to make clear that MXC has two "levels" of awesome
78 19:33 <nothingmuch> so you can figure out what you can hope to achieve
79 19:34 <nothingmuch> 100% compiled everything means you don't load Moose or Class::MOP
80 19:34 <nothingmuch> until you need runtime reflection
81 19:34 <nothingmuch> no codegen at compile time
82 19:34 <nothingmuch> it should load as fast as hand written code
83 19:34 <nothingmuch> i've had it beating Object::Tiny in some benchmarks =)
84 19:35 <obra> oo
85 19:35 <nothingmuch> Moose::XS should aid in making MooseX::Compile's supported feature set easier
86 19:35 <nothingmuch> the less awesome level of awesome is just some classes
87 19:35 <nothingmuch> you don't pay for those classes' compilation (Role composition, etc)
88 19:35 <obra> (especially since for me perl -MMoose -e1 takes up 50% of "sd help"'s runtime
89 19:36 <obra> (.4s here)
90 19:36 <nothingmuch> 5.8.8/
91 19:36 <nothingmuch> ?
92 19:36 <obra> yeah
93 19:36 <obra> "that's what's in the wild"
94 19:36 <nothingmuch> i'm just curious if it makes a dfif
95 19:36  * obra nods
96 19:36 <obra> I don't have my macbook right now or I'd test
97 19:36 <nothingmuch> trunk moose loads slower
98 19:36 <obra> how much slower?
99 19:36 <nothingmuch> but 5.10 loads faster
100 19:36 <nothingmuch> negligiably
101 19:36 <nothingmuch> i think like 10%
102 19:36 <obra> this was trunk moose as of friday
103 19:36 <nothingmuch> but we can fix that
104 19:36 <nothingmuch> ah
105 19:36 <obra> my tests aren't scientific.
106 19:36 <nothingmuch> trunk moose as of you sending me nytprofs
107 19:37 <nothingmuch> actually that's CPAN moose now
108 19:37 <obra> 0.35 - 0.45
109 19:37 <nothingmuch> ouch
110 19:37 <nothingmuch> well, part of the problem is that it loads *EVERYTHING*
111 19:37 <nothingmuch> every type of meta method class, meta type constraint, the role system, etc
112 19:37 <nothingmuch> for a big app these probably will get loaded
113 19:38 <nothingmuch> but for a small app, especially if you load the various sub modules only as needed, you shouldn't pay for these
114 19:38 <nothingmuch> that's a trivial fix that perigrin started working on
115 19:38 <obra> yeah. I played with his branch and saw no change as of last night
116 19:39 <obra> so yeah, we're using roles. if roles aren't ready yet, I won't get far at all.
117 19:39 <obra> (Also, I do really appreciate all the work you're doing. That I'm not paying for, even ;)
118 19:39 <obra> Thank you.
119 19:39 <nothingmuch> i will try shaving Moose's own load time with a profile based approach
120 19:39 <obra> It's SO MUCH better than it was
121 19:39 <nothingmuch> well, everybody wins =)
122 19:39 <nothingmuch> a. you're a friend
123 19:40 <nothingmuch> b. part of my job is making Moose work well
124 19:40 <nothingmuch> c. your using Moose helps moose directly and indirectly
125 19:40 <nothingmuch> d. I LIKE TACOS
126 19:40 <nothingmuch> erm, i mean sushi
127 19:40 <nothingmuch> so no worries on that
128 19:41 <nothingmuch> so, long term goals:
129 19:41 <nothingmuch> App::SD etc has all the meta calculations already cached in .mopc and .pmc
130 19:41 <nothingmuch> moose is not loaded
131 19:41 <nothingmuch> all generated code is cached
132 19:41 <nothingmuch> at worst Moose::XS is loaded to install subs with newXS
133 19:41 <obra> that would be really cool
134 19:41 <nothingmuch> depending on which actually fairs better
135 19:42 <nothingmuch> that goal is realistic, but involves a lot of work
136 19:42 <nothingmuch> more realistic short term goals:
137 19:42 <obra> I started playing with try to dump the symbol table, etc
138 19:42 <nothingmuch> MooseX::Compile partly speeding up SD
139 19:42 <nothingmuch> we can incrementally improve on that
140 19: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
141 19:43 <nothingmuch> Moose::XS replacing some code gen
142 19:43 <nothingmuch> yes, the initial approach was to to try and marshall Moose classes into DDS
143 19:43 <nothingmuch> but it wasn't stable enough
144 19:43 <nothingmuch> and also there's the problem of imports
145 19:43 <nothingmuch> you must serialize the whole table at once
146 19:43 <nothingmuch> or manage an intricate web of inter dependencies
147 19:43  * obra nods
148 19:44 <nothingmuch> i sort of work around that by making all the require()/use() statements stay verbatim
149 19:44 <nothingmuch> also it doesn't handle xsubs
150 19:44 <obra> how hard would it be to get moose's codegen to write out source code instead of blowing subs into memory?
151 19:44 <nothingmuch> so there's guesswork for where ::bootstrap was called
152 19:44 <nothingmuch> i was just getting to that =
153 19:44 <nothingmuch> =)
154 19:44 <nothingmuch> pretty trivial
155 19:44 <obra> heh
156 19:44 <nothingmuch> just grunt work
157 19:44 <obra> is that a more viable approach?
158 19:44 <nothingmuch> it's one of the limiting parts of MooseX::Compile
159 19:45 <nothingmuch> if we clean up that code it will be easier to add support for more features
160 19:45 <nothingmuch> but it's not a huge hurdle since it's a very contained problem
161 19:45 <nothingmuch> it doesn't directly affect the design of MXC
162 19:45 <obra> is this stuff written down anywhere other than this buffer?
163 19:45 <nothingmuch> i don't think so
164 19:46 <obra> where should it get pasted?
165 19:46 <nothingmuch> good question =)
166 19:46 <nothingmuch> i think #moose-dev is pretty aware
167 19:46 <obra> is there a moose wiki?
168 19:46 <nothingmuch> but documenting is good for people to help out
169 19:46 <nothingmuch> no, there should be
170 19:46 <obra> yeah. but the goal is to turn it into written docs.
171 19:46 <obra> ok. for now, it should end up in MooseX-Compile/doc/design
172 19:46 <nothingmuch> sounds good
173 19:46 <obra> . o O { Thank god I don't have a moose commit bit }
174 19:47 <nothingmuch> though most of this affects moose itself though
175 19:47  * obra nods
176 19:47 <obra> Moose/doc/moosex-compile, then