Commit | Line | Data |
8eeebd49 |
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 |
d03bd989 |
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 |
8eeebd49 |
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 |
d03bd989 |
108 | 19:37 <obra> 0.35 - 0.45 |
8eeebd49 |
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 |
d03bd989 |
173 | 19:46 <obra> . o O { Thank god I don't have a moose commit bit } |
8eeebd49 |
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 |