All,
I read a bunch of the code yesterday, after reading a few Python tutorials.
I follow it so much more.
Well, I've spent the day hacking about.
I refactored GumpBase to be GumpXMLObject (so I can use it for the gump
model plus xdocs) and I've broken things badly, & then fixed it a good few
times. Good lessons.
A few things:
1) I have no check-in permissions on gump, so I can't commit what I've done.
I've done a reasonably significant refactor (to move gump.GumpBase into
gump.xmlutils.GumpXMLObject and gump.model.GumpModelObject). Unless other
suggestions are made, I will submit a mungo patch when done. [BTW: I'm not
proud, I learned Python today, you can code review/change whatever I
submit.]
2) This took me a while, not sure if it was GC or something more
straightforward what, but a missing return here had me head scratching for
ages. I'd go from a Workspace to a NoneType. Maybe it is something that only
manifests itself in ActiveState Python.
def load(file):
try:
return loadWorkspace(file) <--- return was missing
except IOError, detail:
log.critical(detail)
sys.exit(1)
def loadWorkspace(file):
"""Run a file through a saxdispatcher.
3) I found the per module :
# init logging
log = logging.getLogger(__name__)
wasn't much help when I wanted a single default log level of DEBUG, so I
change it to:
from gump import log
I hope that doesn't upset anybody. I can put it back later if the former way
is better for log ini managed levels.
4) Exec
1) There is a TODO in the existing code to actually launch "cvs" or launch
"ant" and capture their exit status and output. I could see the need for
some sort of launcher class to do this, and an result class to capture
status & a file reference for stdout/stderr (combined?) [Perhaps this
launcher could have a "timeout" in it, that would zap a long running
process
& set another status.]
I've written this, but I need to consider (1) environment [CLASSPATH] (2)
CWD. I am calling "system", which is a tad OS sensetive (they say), but the
spawns didn't seem particularly nice either, I wasn't sure how to redirect
stdout/stderr to a file w/ them. Work to do here...
5) I'm about to start on this next. Input welcomed.
2) We need (IMHO) to represent the results of operations per project --
those operations are "configure" (merge/whatever), "update" and "build" & I
see the latter two having the output from above. I could see this having
"project gump status = SUCCESS/FAIL/PREREQ MISSING/TIMEOUT/CONFIG ERROR.
When I think of gump I think "batch builds" so I'd see this as one
aggregating class per project (and a named array per pro, but I fear that'd
impact use cases other prefer (simple re-testing, whatever). Any thoughts
on
this?
6) I got started w/ this ... then I noticed Cheetah mentioned & found out
about it. Anybody got any views on imposing such a dependency on gump?
3) Ok, so given that "result set" we need one or more presentations. I am
eager to work with forrest (via xdocs) so I was thinking of creating some
sort of simple XDoc class w/ Book/Tab/Page type sub-classes. Nothing fancy,
just enough to serialize out some simple xdocs.
regards
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
