gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam R. B. Jack" <aj...@trysybase.com>
Subject Fw: Dymystifying Gump Code...
Date Sat, 17 Jul 2004 21:51:32 GMT
Retry...
----- Original Message ----- 
From: "Adam R. B. Jack" <ajack@trysybase.com>
To: "Gump code and data" <general@gump.apache.org>
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: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Mime
View raw message