On Oct 1, 2008, at 3:09 PM, Brice Figureau wrote: > [...] >> Quite a few of them require design decisions -- such as a >> relationship >> syntax, class dependencies, and class 'confine's -- but many of them >> are relatively simple bugs. >> >> In addition, the language could really use a clean-up refactor and a >> performance refactor. >> >> I've never revisited the design, and I think it could stand some >> redoing. For instance, the 'each' methods are never actually used >> (as >> you could tell, since you didn't bother to write tests for the >> methods >> you created), and I expect there's a much better design available for >> how the AST is built up and evaluated. Somewhat obviously, this was >> one of the first designs to coalesce, and I've never had time to >> revisit it. > > How do you see it? > I plead guilty about the each method. Honestly I didn't bother to test > it because I didn't even understood what it was doing :-) > If you want a patch to get rid of them, let me know. If you want a > patch > to use them, you'll have to explain me what's their intended use.
Just get rid of them entirely, from all AST classes. The only thing you should need to do is make sure you don't suddenly break any of the language tests, but I'm nearly positive they're never used. Originally, the method had two purposes: A simple way to just evaluate all of the contained AST instances, and it was used in some simple debugging tools I removed a long time ago. The simple evaluation is no longer used, because it turned out that none of the classes could take advantage of something that simple. > >> I've also never done performance analysis on the parser, and my >> understanding is that for complex parsing jobs, things get a bit >> expensive. If you slapped this under profiling or (even better) >> DTrace, I expect just a few hours would yield really good results >> quickly. > > Profiling is something I'm usually good for. My testings back when I > was > looking for the performance issues with storeconfigs show that parsing > and compiling where the second performance hit (on the puppetmaster) > after storeconfigs, with (on my servers) compilation time of about 2 > to > 4s for an 800 resources node. I'm pretty sure there are room for > improvements here. > I'll run a few profiling sessions to see if I can find some > hotspots. I > have no knowledge of DTrace, though, and I don't have access to a > solaris machine, but I vaguely remember that macosx was running a > version (or did I dream it). Anyway, I can setup a virtual machine, if > needed. Yep, dtrace runs fine on OS X now, which is pretty awesome. Even ruby profiling would suffice, but it's basically 100x slower, so it's pretty painful to use. DTrace, OTOH, is plenty fast and much more powerful. Obviously, I don't care how you make things faster; just that dtrace seems like a great technology to get skills in. I've spent a bit of time on it, and hope to spend more. > >> If we step outside of the language, I'd say the next biggest >> priorities are testing and the REST/Indirector work for 0.25. >> >> There are quite a few tickets pointing to failing tests, and those >> all >> need to be fixed, most likely by rewriting the tests in rspec. We >> also want to get rid of all of the existing tests in test/, and doing >> so is likely to require a decent bit of refactoring in some places >> because a lot of the original code isn't written to be all that >> testable. > > I'm ok to contribute tests (even though that's not my cup of tea yet), > but I fear I don't really have enough puppet internal knowledge to > perform the said refactorings without breaking more things :-) > I ordered a couple of TDD books just to be in the mood :-P I highly recommend Jay Fields's blog -- I highly disagree with a lot of his posts (mostly, I think he's pretty extreme in plenty of ways), but I learned a helluva lot from him. > >> There are also quite a few tickets opened with a High priority for >> 0.25, pointing to the classes that still need to be converted. There >> are yet other classes that don't use any xmlrpc but should use the >> indirector/REST, like StoreConfigs -- I'd like to create a Resource >> class that can speak to ActiveRecord but also support other back- >> ends, >> for instance. This would make the language's query syntax much more >> flexible, because you could connect it to any arbitrary resource >> store. > > I'm waiting eagerly for this part ;-) > That'll open many new perspectives for storeconfigs. Someone > mentionned > a CouchDB implementation on this list. That's really interesting > stuff. > I still don't see how you'll decouple the resources from the > implementation, but I'm pretty sure you have an idea. You'd basically be in a position to use any ORM, including directly doing sql, using xml, yaml, or whatever -- you just have to meet the API. The complication here is that we actually want to be able to operate on both the catalog -- which has all of the resources plus a bunch of graph edges -- and on individual or sets of resources. If you're interested in that, I think a lot of people would appreciate it, and it's something I'm probably not going to get to work on for a while; I'd be glad to work with you to understand how to do it and come up with a plan of attack. > >> Obviously most of this isn't quite enough to actually get you >> started, >> but if any of them stand out as something you want to work on, then >> we >> can work out the details of how to actually do it. >> >> Sound good? > > Yes I have plenty to look at. I think I'll start by looking to the > language tickets, see if I can fix a few easily, then move to the > language profiling things. Meanwhile, I'll try to contribute tests for > parts I already know (providers, more parser tests...), if that's OK > with you. That'd be great. Just note that there will be plenty of cases where there is code that just doesn't make sense (see my recent patches to the user type, the file group attribute, and the base Type class), or where code isn't very testable. Feel free to ping me in those cases to ask for more detail on why things work the way they do; conversely, I'll try to point out where code is unnecessarily complicated. -- The great tragedy of Science - the slaying of a beautiful hypothesis by an ugly fact. --Thomas H. Huxley --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en -~----------~----~----~----~------~----~------~--~---
