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