You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@gump.apache.org by Adam Jack <aj...@trysybase.com> on 2003/08/07 20:21:18 UTC
Python Gump
All,
I would like to see some changes to gump (especially around package support,
around customisation for "personal" gumps, and around statistics -- FOG
factor -- depended upon (reverse tree) -- and debugging. Also, Nick Chalko
had the awesome idea (random thought) of combining Gump with Forrest for
presentation. Finally, I recently relived some of the usual hell of
ascertaining a trimmed stack combined w/ packages, and Nick/I both feel the
need for automated "missing package determination and download" (perhaps via
Ruper/or other).
Much as I know Python gump has gone dormant, I believe it is a better
starting place for all these things -- especially given the fact that that
it doesn't have batch support "HTML output". (I know it also determines
missing projects, so could help there.) As such, I'd really appreciate any
pointers that folks could give in order to get me started.
I'd like to finish off (and make work) the "gumppy.sh" I started, and see
what I can do to make it work for command line (from cron) for batch builds.
Although on Linux I only have telnet access, on W2K I can do GUI -- if that
helps me get started. I know a GUI was added in front of Gump, could
somebody point me to what I need to install for that, and where I get start
running it?
Any other advice/pointers on python in general, python gump and command
line, etc. would be appreciated.
BTW: Yes, I understand the risks of investment here, but I think it is worth
the shot...
regards
Adam
--
<http://www.try.sybase.com>
Experience Sybase Technology ...
Re: Python Gump
Posted by Leo Simons <le...@apache.org>.
Adam Jack wrote:
> that'd be http://nagoya.apache.org/wiki/apachewiki.cgi?GumpPython
> Ah yes, forgot that, sorry.
no worries dude!
> 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 like XP. Do the simplest thing you can do to get it working :D.
Combining stdout and stderr is probably a good idea. So is a timeout
(the gump bash scripts I run have a timeout).
> 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.
good plan.
> 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?
you mean one aggregating object per project, all of the same class,
right? Again: just go for it.
> 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.
also a good idea.
> Ought I create gump/xdocs for this (as opposed to xdocs)?
dunno. We can always move it later ;)
> I would love input on what the xdocs tabs ought be.
I believe jakarta-gump/stylesheets contains or contained at one point
some kind of stylesheet for publishing gump run results in xml; maybe
you can learn from there
> BTW: I see something for RSS, do we need multiple output presenters?
need? It would be nice, for sure :D
> 4) I see that GumpBase and gen.py xmlize are pretty useful XML to/from
> Object mechanisms. I assume they are not 100% generic
oh, I think they are :D. Sam's an xml wizard, 'member ;)
> All feedback appreciated.
I'll find time to submit your patches, at least :D
- Leo
RE: Python Gump
Posted by Adam Jack <aj...@trysybase.com>.
and another mail...programming python is fun, innit? ;)
It is pretty free form, which can be efficient in the hands of somebody who
knows what they are doing. :) Me, I'm still frequently biting myself in the
butt and having to scratch my head to figure out what on earth I broke and
how. Still, I can see I'll get past that, and yes --- it is nicely .
> I've written this, but I need to consider (1) environment [CLASSPATH] (2)
> CWD.
Did you look at the code that's commented out in the commandline
version? I recall thinking about those....
Yup, I see them. They aren't everywhere, but I can steal that code & move
it. Thanks.
regards
Adam
Re: Python Gump
Posted by Leo Simons <le...@apache.org>.
and another mail...programming python is fun, innit? ;)
Adam Jack wrote:
> 4) Exec
>
> I've written this, but I need to consider (1) environment [CLASSPATH] (2)
> CWD.
Did you look at the code that's commented out in the commandline
version? I recall thinking about those....
> 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?
go for it. Cheetah is cool.
- LSD
RE: Python Gump
Posted by Adam Jack <aj...@trysybase.com>.
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
RE: Python Gump
Posted by Adam Jack <aj...@trysybase.com>.
Leo wrote:
that'd be http://nagoya.apache.org/wiki/apachewiki.cgi?GumpPython
Ah yes, forgot that, sorry.
I can get you X-over-SSH to a box running red hat if you need it to test
linux GUI stuff.
I am somewhat modem challenged (up the mountain I live) and have slow
connectivity that I can't upgrade. Thanks for the offer though.
I downloaded the wxPython stuff to my M$ and after a few tweaks (and a hack
to wx) it got the GUI working. I must say -- I was very impressed -- repeat
very! I had previously (and privately) thought that I'd not use the Python
GUI (Eclipse does ordered builds fine for small projects) but I completely
take that back that thought. For viewing/manipulating gump metadata, for
testing ant/centipede builds, for displaying "as gump sees it" ... it is
awesome. I will use the significantly. Great job guys!
> BTW: Yes, I understand the risks of investment here, but I think it is
worth
> the shot...
go for it dude! (and keep us informed and the wiki updated ;)
I read a bunch of the code yesterday, after reading a few Python tutorials.
I follow it so much more.
Here are some initial thoughts -- provide feedback if you have time,
otherwise I'll just experiment:
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.]
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?
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.
Ought I create gump/xdocs for this (as opposed to xdocs)? No point getting
ahead of ourselves and thinking we are creating anything more than just for
gump.
I would love input on what the xdocs tabs ought be. I saw those for the GUI,
and they are very good for a dynamic GUI, but don't see right for tabs for
HTML pages. Perhaps the tabs ought be by object type, module/project/repo,
etc. I'd like to give the user good insight" into everything (like
statistics, like dependencies/dependers) in an easily navigable mechanism
but I don't have it in mind yet. I want to quickly eyeball multiple
projects (typically krysalis group) and I want to see all related result,
I'd like this gump to give better higher level views like groups.
BTW: I see something for RSS, do we need multiple output presenters?
4) I see that GumpBase and gen.py xmlize are pretty useful XML to/from
Object mechanisms. I assume they are not 100% generic (or they'd be in
Python core) but I can see that they'd work for us. Ought these be moved to
a gump/xml ?
All feedback appreciated.
regards
Adam
Re: Python Gump
Posted by Leo Simons <le...@apache.org>.
Adam Jack wrote:
> As such, I'd really appreciate any
> pointers that folks could give in order to get me started.
that'd be http://nagoya.apache.org/wiki/apachewiki.cgi?GumpPython
> I'd like to finish off (and make work) the "gumppy.sh" I started, and see
> what I can do to make it work for command line (from cron) for batch builds.
> Although on Linux I only have telnet access, on W2K I can do GUI -- if that
> helps me get started. I know a GUI was added in front of Gump, could
> somebody point me to what I need to install for that, and where I get start
> running it?
same link.
I can get you X-over-SSH to a box running red hat if you need it to test
linux GUI stuff.
> Any other advice/pointers on python in general, python gump and command
> line, etc. would be appreciated.
the messages posted after this one:
http://marc.theaimsgroup.com/?l=alexandria-dev&m=105024330711316&w=2
contain lots of useful snippets. I like the PyCrust editor as an
alternative to emacs. There's dozens of those. Google works nicely :D
> BTW: Yes, I understand the risks of investment here, but I think it is worth
> the shot...
go for it dude! (and keep us informed and the wiki updated ;)
cheers,
- Leo