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 R. B. Jack" <aj...@trysybase.com> on 2004/07/12 21:20:05 UTC
Dymystifying Gump Code...
It is clear that for Python Gump to flourish, it's code needs to be clear &
documented (to make it readable/understandable to Java programmers). It need
to be transparent, and accessible. I'll do my best to help with that.
Could I get some feedback on this:
http://wiki.apache.org/gump/GumpCode
Also, how ought we go about getting me to understand what is not
understandable? 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? With them I'll try to understand what needs to be done, and go see
if the code is documented for the Python/Gump Python newbie to be able to do
those changes.
Also, any other input on ways to get this thing out into the open, and clear
for all?
Thanks in advance.
regards,
Adam
--
Experience the Unwired Enterprise:
http://www.sybase.com/unwiredenterprise
Try Sybase: http://www.try.sybase.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Dymystifying Gump Code...
Posted by Stephen McConnell <mc...@apache.org>.
Adam R. B. Jack wrote:
> Any takers? Pretty please...
I have stuff - just that at the moment there is other stuff I'm obliged
to take care of.
:-(
Steve.
--
|---------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org |
|---------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Dymystifying Gump Code...
Posted by "Adam R. B. Jack" <aj...@apache.org>.
Any takers? Pretty please...
regards
Adam
----- Original Message -----
From: "Adam R. B. Jack" <aj...@trysybase.com>
To: <ge...@gump.apache.org>
Sent: Monday, July 12, 2004 1:20 PM
Subject: Dymystifying Gump Code...
> It is clear that for Python Gump to flourish, it's code needs to be clear
&
> documented (to make it readable/understandable to Java programmers). It
need
> to be transparent, and accessible. I'll do my best to help with that.
>
> Could I get some feedback on this:
>
> http://wiki.apache.org/gump/GumpCode
>
> Also, how ought we go about getting me to understand what is not
> understandable? 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? With them I'll try to understand what needs to be done, and go
see
> if the code is documented for the Python/Gump Python newbie to be able to
do
> those changes.
>
> Also, any other input on ways to get this thing out into the open, and
clear
> for all?
>
> Thanks in advance.
>
> regards,
>
> Adam
> --
> Experience the Unwired Enterprise:
> http://www.sybase.com/unwiredenterprise
> Try Sybase: http://www.try.sybase.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Dymystifying Gump Code...
Posted by "Adam R. B. Jack" <aj...@apache.org>.
Along these lines, could I get feedback on these two modules? If folks can
grok these, maybe there is hope for Python Gump.
The builder: (see method buildProject):
http://cvs.apache.org/viewcvs.cgi/gump/python/gump/build/builder.py?rev=1.7&view=markup
The AntBuilder (there are also ScriptBuilder, MavenBuilder) -- called from
above:
http://cvs.apache.org/viewcvs.cgi/gump/python/gump/build/ant.py?view=markup
All feedback on style/comments (or lack) would be appreicated so I can
improve them.
Heck, even 'what the bleep does this XXXX mean, in Python?" would be fine.
regards
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Dymystifying Gump Code...
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> What I am trying to say... I would love to help out with Gump at code
> level, but Python is a hinder that I won't try to climb. Fishing
> sounds more tantalizing. ;o)
Yes, that was clear. Unfortunately, Gump is currently written in Python, so
your offer of assistance comes with too great a stipulation. There are lots
of ways you can help Gump without needing to code it, others have shown
that. Maybe you'd be willing to help there.
As you'll see from my next posting, I feel passionately that Python has not
failed Gump, that it is not a significant barrier to entry, and I don't wish
to see the investment/potential wasted because I failed to communicate. Old
dogs can learn new tricks, and I can learn to open this up and make it
accessible.
regards
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Dymystifying Gump Code...
Posted by Niclas Hedhman <ni...@hedhman.org>.
Adam R. B. Jack wrote:
>>Honestly, I am not capable of learn any more languages. I am an old
>>dog, and not interested in learning it. By the time Java is no longer
>>a "job opportunity" or fun, I will retire to fishing. Is that
>>understandable?
>
>
> Niclas, I understand. I should've said 'make it readable/understandable to
> Java programmers' ... ' who care to read it'. For those who don't, then I'll
> try to make Gump documented clearly enough (at user level) to work for you.
> (Not knowing Python doesn't stop folk from using a MoinMoin Wiki. Hopefully,
> I can achieve that for Gump users.)
What I am trying to say... I would love to help out with Gump at code
level, but Python is a hinder that I won't try to climb. Fishing
sounds more tantalizing. ;o)
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Dymystifying Gump Code...
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> > It is clear that for Python Gump to flourish, it's code needs to be
clear &
> > documented (to make it readable/understandable to Java programmers). It
need
> > to be transparent, and accessible. I'll do my best to help with that.
>
> Could you also post a link to a Python-to-Java translator?? :o)
Read right to left. ;-)
http://www.daimi.au.dk/~chili/CSS/pythonForJavaProgrammers.htm
http://www.razorvine.net/python/PythonComparedToJava
> Honestly, I am not capable of learn any more languages. I am an old
> dog, and not interested in learning it. By the time Java is no longer
> a "job opportunity" or fun, I will retire to fishing. Is that
> understandable?
Niclas, I understand. I should've said 'make it readable/understandable to
Java programmers' ... ' who care to read it'. For those who don't, then I'll
try to make Gump documented clearly enough (at user level) to work for you.
(Not knowing Python doesn't stop folk from using a MoinMoin Wiki. Hopefully,
I can achieve that for Gump users.)
The world doesn't wait for us old dogs to retire. Maybe I'm just hoping to
ride out a tad longer. ;-)
regards,
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Dymystifying Gump Code...
Posted by Niclas Hedhman <ni...@hedhman.org>.
Adam R. B. Jack wrote:
> It is clear that for Python Gump to flourish, it's code needs to be clear &
> documented (to make it readable/understandable to Java programmers). It need
> to be transparent, and accessible. I'll do my best to help with that.
Could you also post a link to a Python-to-Java translator?? :o)
Honestly, I am not capable of learn any more languages. I am an old
dog, and not interested in learning it. By the time Java is no longer
a "job opportunity" or fun, I will retire to fishing. Is that
understandable?
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Development (was Re: Dymystifying Gump Code...)
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> When I develop java software (I guess this holds for everything else as
> well though), I have this basic development process set up. Starting
> from scratch, we start with some idea of the basic abstractions, write
> interfaces, then unit tests. Compile. Doesn't work. Write a bit of
> implementation. Compile. Doesn't work. Write a bit more. First test
> green. etc etc. Every now and then, a "unit" is complete. Everything
> glues together using some common pattern (ie IoC, factories, servlet
> setup, xml config, little bit of scripting). Step through it all with a
> debugger to verify behaviour is as expected. Maybe profile a little.
>
> 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.
> So that's not just "how it works" but also "how do I change it".
>
> concrete question: what is your development process?
I think this is a good question, so please bear with me answering it as
fully as I can. Insights will hopefully help us move Gump forward...
Your above description seems realatively close to mine (for a new project
from scratch), although I'm not great about abstractions/interfaces, I think
in terms of models/players. I tend to have a long term goal/ideas that I am
working towards, but I can't really say I'm good at knowing what point I'm
at in a roadmap, things tend to be quite fluid. I tend to refactor a lot; I
look for re-use and I try to whittle that out of where it is, to share it. I
believe in good practices, good interfaces, good separations, but I think I
tend to allow them to fall by the wayside (since all the code is typically
in my head). I typically need good folks to criticise what I've done for me
to 'see the light' with these issue. I can code, I am not a great designer.
My code typically works, although it isn't beautiful (I typically describe
it as 'fluffy' .. i.e. straightforward, perhaps even if bloated, definately
not cryptic/tight).
With Python and Gump, things are different though. I took on somebody else's
codebase, in a language I didn't know, and I slowly morphed it. I've tried
to get things to work, despite not really understanding what was there,
despite not having a local environment to fully test with. I think this
environment has dominated my thinking; I tend to look for simple changes I
can make and unit test locally, but which I can debug (via CVS, on a remote
server) within short time (at worst the length of time of a Gump run), so I
don't break the Gump's out there. I realize this is limiting, and it has
been challenging, and I think it has disallowed me stepping back and making
bold/brave changed. The two times I've separated out to a branch I've been a
lot happier w/ the amount I can get done, with the boldness of the changes.
Only at these times do the unit tests really help out as they ought. Only
these times do I really step back and try to think big picture.
Basically, I code incremental changes into Gump, that is about all I have
done. I do know that not changing the Gump metadata ('cos of users, 'cos of
traditional) has limited big changes. Further, I don't think I ever
consciously set out to design a 'Gump Engine', although I've tinkered with a
few concepts along the way. For me, the Pythonic XML metadata to model
objects code was 'a foundation of sand' for a long time, since I couldn't
grok how to change it (every attempt hampered or broke it). With the DOM
interface (which isn't beautiful, but functional) I now feel that Gump is
simple (fluffy ;-) and I feel there is finally a basis we can easily
understand and build upon.
Another insight, I feel, is I think that although we all know that Gump 'can
really be something new', none of us quite know what or where it is going.
I've felt that there is power in the data that Gump generates accross
multiple projects, perhaps some opportunity to find some 'cross cutting
concerns' (right word?) within that data. As such, I've focused on trying to
present that data (via HTML) to see if some view of snippet became
singularly valuable. I spent some time generating dependencies diagrams (via
SVG) with different thickness/colour graphs, in the hope of visual insights.
Both these two ran into performance problems (with Forrest/Batik/Python) and
as such have been a struggle (lost in profiling) than a consistent
experiment building upon results. Basically, I don't think either of these
have had their opportunity yet, and I think there is work to do here.
Perhaps daft, but I feel I am (finally) just starting with Gump. I finally
think the codebase is ready for some work by this community (perhaps despite
me ;-). I beleive I finally understand the interactions and needs of code
players, in order to help design/develop a reasonable code base. I am more
than willing to share whatever I have with others here, so we can pool
strengths. [I think we have a fascinatingly eclectic set of
folks/interests/styles on this team, and I want Gump to be open to all those
benefits.]
It seems (to me) that if we can mature the context tree and the runner's
interactions with actors via event (and perhaps requests) then we can start
to allow more extension points w/o unreliability. If we teach folks how to
extend the metadata, and wire metadata changes to extensions, then I think
we have a suitable framework for extension. [As I said before, I'll work on
wiki pages for changes.] When we get to that point, I feel we'll have the
basis for auto-discovered (or workspace described) plug-ins for core aspects
(updaters|builders) and also core result processors (notification,
documentation, stats, whatever).
That said, this is just the fluid state I am in, in my current mental
roadmap -- I could easily see Gump turned on it's head, focus more on
shared/public webapp-based workflows, or focus on local end-user usage/GUIs,
or whatever. I'll do whatever I can to attempt to ensure I don't get in the
way of other's visions, and Gump is open to all.
regards,
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Dymystifying Gump Code...
Posted by Leo Simons <ls...@jicarilla.org>.
Adam R. B. Jack wrote:
> Could I get some feedback on this:
>
> 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...
> Also, how ought we go about getting me to understand what is not
> understandable?
When I develop java software (I guess this holds for everything else as
well though), I have this basic development process set up. Starting
from scratch, we start with some idea of the basic abstractions, write
interfaces, then unit tests. Compile. Doesn't work. Write a bit of
implementation. Compile. Doesn't work. Write a bit more. First test
green. etc etc. Every now and then, a "unit" is complete. Everything
glues together using some common pattern (ie IoC, factories, servlet
setup, xml config, little bit of scripting). Step through it all with a
debugger to verify behaviour is as expected. Maybe profile a little.
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.
So that's not just "how it works" but also "how do I change it".
concrete question: what is your development process?
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.
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.
> 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/>?
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?
-> 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)?
etc etc.
> 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...
cheers,
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org