On 20-05-2005 22:33, "Adam R. B. Jack" <[EMAIL PROTECTED]> wrote: > That said, I was actually refering to plugins sharing the model (as > developers share the code, via SCM) and how one plugin's efforts, setting > properties, might (in plugin's real time) communicate. Just as we trust each > other to move things towards a common goal, and respect each others changes > (even reversions), and communicate via lists/blogs/SCMs -- I wonder if > plugins could. Perhaps some named dictionaries on model objects, that allow > plugins to say (I created x/y/z -- and modified a/b/c). I could see the > "core" (algorythm/walker) being able to do some nifty/helpful > tracing/debugging with that. If Gump3 ever gets so "big" (flexible) that it > loads plugins on the fly, from developers whove never spoken, I could see > this being very useful. For now, it is just a wild fancy. :-)
Adam, I had discussions like this for years and years over in avalon land. Simply put, I don't think we need explicit declarations, and I've grown to really really dislike them. I also know you can spend years debating this stuff without ever getting to agree. Lets not, and just see where we end up :-) >> Plugins should make an attempt to handle an expected failure, ie they >> should try and continue processing, and set the "failed" property on the >> model element that failed. They should raise exceptions on unexpected >> failure. They don't do anything else. >> >> The Builder nor the Walker nor any of the "core" code have anything to >> do with this, *except* the algorithm (in algorithm.py). All decisions >> about what should happen on a failure, all intelligence on what a >> failure *means* or what *consequences* a failure should have (for >> example, if you can't check out a module no use trying to build it) are >> made by the algorithm. > > Ok, then time for me to fess up. One thing I did was (in BuilderPlugin) was > setting the status to failed (using your protocol setter) if an exception > was thrown. I wondered (and added a #TODO) if we needed a > BuilderErrorHandler for that instead. I now see you have a third > alternative, and maybe we take the exception catch of out BuilderPlugin all > together. Didn't I change that back already? Hmm, I thought so :-) >> I'll be frank: I don't think so. I think that if properties become too >> big, they should be turned into functionality to access properties. For >> example, instead of keeping logs in the model, you store them on disk or >> in a database, and you load them into the plugin space (instead of onto >> the model) as you need them: > > This is exacly the example I think of where we might want to use the > property(get,set,del,'doc string') capability. I know I'm a little enamoured > w/ this beastie, but as we use properties more and more, I could see it be > interesting for a plugin to annotate a model object with both data and the > getter/setter/delete/docs logic behind it (e.g. to read from file on > demand). Other users don't need to know the implementation details, just > that it provides/consumes a string. Eh. I don't fully see why its so cool. I'll just have to trust you on that..."Show me the code!" >> Hmm. While typing that, I realized that you can actually build a reaper >> that way, and its just a plugin that looks for the "big" chunks of >> memory, writes them to your object db of choice (ie python's "shelf" >> module or whatever), then adds an accessor to load them back into memory. > > I think we will want a Reaper, not so much 'cos of the size of properties > (as discussed above) but the shear volume of them. Gump2 slowed to mollasses > as it grew, before I spent a month or so fighting it, and being careful to > assit GC. Python's runtime gets clogged with a few hundred thousand objects, > and (especially when Gump2 creates DOM trees for documentation during the > build) we were easily hitting that. Python GC is quite the "magic" I'd wish > it to be. Heh. That's why we won't use DOM. Next time we run into performance issues, we just ask help from some python experts ;) > I was thinking of the "update & build & document[to DB]" chain (say) for > ant. Once done, are all the details of the build, that documentation used, > still needed? Once done, don't we just exit the gump run? > I meant reaping to death, not paging out. We'll see if it is > needed, but somehow the algorythm would need to know when a model is "used > for this run", and/or the Reaper plugin would and/or we'd need a special > plugin the algoruthm "understood". Plugin writing would be a lot easier if you wouldn't have to worry about data that was there before not being there at a later point. >> Did I mention I hate cygwin? :) > > Me too (now). Top of my wishlist (since I don't have the spare dosh to fork > out for a box to install Linux on) is to get off it. Being Python on > Microsoft is a pain (w/o some posix abilities) but it is better (if we can > get there) than being on Python on Cygwin on Microsoft, it is too > confusing. Only real victim would be your bash "gump" script... I love that script :-) Seriously, I've been thinking about how easy it would be to rewrite in python. All the environment checking it does now would not be as easy from python, as on MS you can then not assume a lot of "posix environment basics". I wonder if it isn't a better idea to make sure that on cygwin we use the python version that comes with cygwin. - LSD --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
