Retry... ----- Original Message ----- From: "Adam R. B. Jack" <[EMAIL PROTECTED]> To: "Gump code and data" <[EMAIL PROTECTED]> Sent: Saturday, July 17, 2004 3:16 PM Subject: Re: Dymystifying Gump Code...
> First, thanks for these question Leo, they are useful input in themselves. > > > > http://wiki.apache.org/gump/GumpCode > > > > finally read it. Pretty much the big picture view as it is in my head > > (good thing!). Thanks for taking the time to do this... > > > > Thanks, it is a start. More to document in the code [for pydoc], and also > (perhaps) whatever patterns are in play. Along with that some 'how tos' (see > below). > > > When I try to get to work on gump, it is just not clear how to start, > > and how to go from there. For example, lets say I want to write a > > <magic/> tag like steve requested. Where do I start, how do I test > > things, etc. > > On how to start, I can't think of a clear answer for in general. In this > case (and a few of the examples you give) the place to start is with > metadata & the model package. There is a gump/test/model.py that tests > various model pieces. It uses the 'workspace' in gump/test/resources/full1 > (and others) to do this. Whenever I add new metadata & model objects I start > there. > > I've not found a debugger, nor looked, but then I'm more a debug by logging > kinda guy. How to test/debug? Best I have is here: > > http://wiki.apache.org/gump/GumpDevelopment > > [I will add how to add more tests.] > > > So that's not just "how it works" but also "how do I change it". > > > > concrete question: what is your development process? > > See next mail. > > > This is not just about python. I've got no problem writing basic python > > shell scripts or even cgi apps (with the manual lying on the desk that > > is :-D). Atomized pieces of program with a simple entrance and simple > > exit. I remember the same feeling from adding a feature to gump when it > > was still java+xslt. > > I hear you, it isn't the language, it is the codebase. Best I can tell you > for now is, I created the Actor (works on the tree, typically on one entity > [module|project] or all) to help this. I hope to (eventually) move updating > and building to a similar pattern (partly for mutlithreading) one day. That > might help with more 'active' actors, such as these two, and some of yours > (below). > > > What I'm also missing is an idea of what code is used and what code is > > not. There's loads of utility material, and I suspect a lot of code > > that's never used. In java I can find this code using a tool like > > clover. I can't in python. > > I've not found one (nor looked as hard as I should). My guess though is that > everything (save a very few stray corners) is used, and I say that > confidently 'cos I add things as I went. I wasn't doing a lot of 'this is > cool' type stuff, merely adding what I thought I needed, or thought would > help clean-up. > > > > Could we come up with a few real or pseudo code changes, and > > > document/discuss what would need to be done in order to achieve them? I > know > > > Stefan has a pet task (Javadoc?), and we have MagicBuilder. Could we get > a > > > few more? > > > > <junitreport/>. Also <clover/> and other reports commonly used by > > projects (take a look at the reports maven generates); perhaps > > <configure/> and <make/>? > > Good questions. Ok, I see (1) wiring in new metadata (2) wiring in new > tasks. I'll write a Wiki page for both. > > > I'm also interested in change as opposed to addition... > > > > -> you stated the model is modified rather than decorated. How would one > > change that? What do we look for to isolate all the modifications > > happening and all the code depending on those modifications? > > > > I've like to see us split the run/workspace/module/project objects into too, > putting Workable (work done), Annotabable (a little 'error log'), Stateful > (state/propogation), Stats, etc. onto the former. > > > -> how would I make the state propagation feature more granular (ie > > propagate a complex state and make the html output different based on > > whether we're FAILED or FAILED MISERABLY FOR 3 WEEKS)? > > Not quite following why this is a propogation. We have state (failed) and we > have stats for that project (that show in same state for 3 weeks). What > ought be propogated? > > > > Also, any other input on ways to get this thing out into the open, and > clear > > > for all? > > > > ehm, ... maybe some big, fat, visible boundaries between the different > > bits of code. Big java projects, might be split into seperate > > subprojects or packages in seperate jar files that are independently > > reusable and have a small well-defined public interface. Public/private > > also helps there I guess. In gump, method X from package Y may be in use > > in package Z and its not so easy to figure that out for me. No "find > > usages" button in my IDE... > > Maybe we can start to split off the various actors/workers & refine that > 'protocol', it'd be a start. Python doesn't do public/private, but I think > I'll start using _methodName() for private (or at least, think before you > use this method). > > Eventually it'd be nice to have this bundled into a plug-in so we could load > what we fine (or what the workspace says is to be found). The main challenge > here would be to allow metadata extensions, and processing extensions, in > one plug-in interface. > > Thanks for your questions, I'll write more when I get more time. > > regards > > Adam > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
