You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@gump.apache.org by Leo Simons <le...@apache.org> on 2003/04/28 17:30:55 UTC
[gumpy] refactoring halfway
Hi gang,
wanting to restructure gump to be more in line with "regular" python
module organisation, only got about halfway (not tested), so not
committed. Did stuff like addition of licensing and conversion to use
docstrings as well. Zip attached for interested peeps.
cheers!
- LSD
Re: [gumpy] refactoring halfway
Posted by Sam Ruby <ru...@apache.org>.
Leo Simons wrote:
>
> on a further sidenote, it seems both more difficult and less required to
> do complete seperation of concerns in python....<tag/>.complete() feels
> like a bad idea, but it works quite nicely. Hmm. Need to beat up the
> java guy in me a little more.
I actually don't think this is a language thing. The design of the
Java/XSLT version of Gump is also multi-pass and wholistic. It might be
the nature of the problem. It might be a limitation of my ability to
view the problem solution space.
It also might be my focus on performance.
A prime example of the problem. One project can 'inherit' dependencies
from another. This needs to include any dependencies that project may
inherit. This can't be done statically when the the project is first
read in, and doing it completely dynamically when it is time to build
means that cycle detection and a complete recursive decent is required
when visiting each node (an n**2 proposition).
In the java/xslt version, inherit dependencies was done during the
processing of Project.sort... not exacly a clean solution. In this new
Python version, it is done as a clearly identified second pass. A
noticable improvement, IMHO, but still not architecturally pure.
- Sam Ruby
Re: [gumpy] refactoring halfway
Posted by Sam Ruby <ru...@apache.org>.
Leo Simons wrote:
>
>> 2) the ../../.. as conf.dir.base. [2]
>
> It seems the cygwin and native windows versions of this code decide a
> little differently on the base environment. ".." works for the windoze
> one, "../../.." for the unix port. Weird as well. I'll have a look at
> the os.path docs.......
I'm not sure why this might be, in any case, that is not the point I was
trying to make.
IMHO, if a document contains an href, that href should be evaluated
relative to that document's location, not relative to some location
hardcoded to be two or three directories above one's current working
directory at the time the command is issued.
- Sam Ruby
Re: [gumpy] refactoring halfway
Posted by Leo Simons <le...@apache.org>.
Sam Ruby wrote:
> OK, there are two things about this commit that irritate me.
>
> 1) my last set of changes [1] seem to be lost.
totally weird. I'm sure I cvs upped *after* those. Maybe I shouldn't be
learning emacs and python at the same time ;). Anyway, will travel.
> 2) the ../../.. as conf.dir.base. [2]
It seems the cygwin and native windows versions of this code decide a
little differently on the base environment. ".." works for the windoze
one, "../../.." for the unix port. Weird as well. I'll have a look at
the os.path docs.......
on a further sidenote, it seems both more difficult and less required to
do complete seperation of concerns in python....<tag/>.complete() feels
like a bad idea, but it works quite nicely. Hmm. Need to beat up the
java guy in me a little more.
more from the front on friday!
- LSD
Re: [gumpy] refactoring halfway
Posted by Sam Ruby <ru...@apache.org>.
Leo Simons wrote:
> Sam Ruby wrote:
>
>> Leo Simons wrote:
>>
>>> Hi gang,
>>>
>>> wanting to restructure gump to be more in line with "regular" python
>>> module organisation, only got about halfway (not tested), so not
>>> committed.
>>
>>
>> Don't be shy. Commit. If you break something, it will be fixed.
>
> Shy, me? :D
>
> XP Sam, XP! Test b4 commit. This is the first asf codebase I've been
> involved with from its inception, and I intent to drive this point home
> early on in the process :D
>
> anyway, squashed half of the bugs I introduced, committed. Python is
> cool, but I miss my IDEA...
OK, there are two things about this commit that irritate me.
1) my last set of changes [1] seem to be lost.
2) the ../../.. as conf.dir.base. [2]
- Sam Ruby
[1] http://marc.theaimsgroup.com/?l=alexandria-dev&m=105155169104572&w=2
[2]
http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-gump/python/gump/conf.py?rev=1.1&content-type=text/plain
Re: [gumpy] refactoring halfway
Posted by Leo Simons <le...@apache.org>.
Sam Ruby wrote:
> Leo Simons wrote:
>
>> Hi gang,
>>
>> wanting to restructure gump to be more in line with "regular" python
>> module organisation, only got about halfway (not tested), so not
>> committed.
>
> Don't be shy. Commit. If you break something, it will be fixed.
Shy, me? :D
XP Sam, XP! Test b4 commit. This is the first asf codebase I've been
involved with from its inception, and I intent to drive this point home
early on in the process :D
anyway, squashed half of the bugs I introduced, committed. Python is
cool, but I miss my IDEA...
cheers!
- Leo
Re: [gumpy] refactoring halfway
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Simons wrote, On 28/04/2003 23.03:
> rant rant rant below :D
>
> Nicola Ken Barozzi wrote:
>
>> Wait a sec, I just had time to look at it, and it's basically the same
>> as I did before, but backed away because of these questions:
>>
>> 1 - why rss is in gump and not next to build?
>
> rss can prolly be refactored to be 99% generic RSS and 1% specific to
> gump, however as currently written its not. Belongs with gump 'till then.
:-PPP
>> 2 - shouldn't properties be also in the main dir? (user override)
>
> hmm. I would think user override should happen in the profile.xml,
+1
> and
> there would eventually be a jakarta-gump/run.py file which would defer
> to build.py functions:
>
> ----
> #!/usr/bin/env python
>
> """
> Frontend to gump.build....
> """
> import gump.conf
>
> # override config here if you don't do it in xml
> gump.conf.dir.base = '.'
> gump.conf.basicConfig()
>
> # kick tyres, light fires
> import gump.build
> build.run()
> ----
>
> boy, python is easy. I suspect the above might actually almost work!
Don't see the need for a run.py.
What I see is these scripts:
1 - build = build a/var project/s
2 - gump.py = run the complete gump run with nags et all
3 - gumpgui.py = gui with viewew, editor, etc
>> 3 - shouldn't core be in the init module, so it is called as gump?
>> (IIUC)
>
> yes :D
ok
>> 4 - shouldn't view be in teh base dir?
>
> why?
>
> just like org.apache.avalon.phoenix.cli.CLIMain is a subpackage of
> avalon.phoenix, so view is a subpackage of gump. Python packaging is
> like java packaging, only slightly more ugly :D
Hmmm, but as I already said, what if I want to add Gump to my PATH? Can
I call gump/view.py from anywhere?
>> The only thing I'm sure is that the core needs to go somewhere in the
>> gump package, for the rest I'm confused -> not committed it myself.
>
> fortunately, its easy to change ;)
>
> general docs about packaging are at
> http://www.python.org/doc/essays/packages.html but most non-core python
> packages I've found so far break at least one rule! Ni!
>
> [OT] Python stuff
> -----------------
> I've played with python and jython (latest thought: drop Jelly again
> from my personal projects and replace with jython :D), and ruby (ruby is
> actually way cooler than python but less used and known atm!).
I've seen ruby too, and it's very cool too. I tend to agree :-)
> Some
> observations:
>
> - python is exactly the right tool for gump. Gump is 90% glue and 15%
> text/xml handling.
+1000!
> - docutils.sf.net could be way nicer...IIUC its python's future
> 'javadoc'....we should prepare to use it
Yup.
> - the pydoc util in the python distro is interesting as well...in
> remarkably little code it is a tty tool, a gui tool and a webserver. I
> see possibilities for implementing gump/server.py or something like that...
>
> - lacking an editor with stuff like refactoring support and code
> insight; I find the emacs python-mode to still be way less productive
> than something like IDEA; this is one area where PHP still has the edge
> over python imho
Try Boa, it works very well also as a debugger, or the Wintel HapDebugger.
> - python is absolutely great for coding stuff like blogs, wikis, little
> CMSes, config tools. I think I'm building my next website in python :D
I still like Cocoon ;-)
But I'll surely write my next GUI app in Jython.
> - python is hands-down the best all-round "glue" available (too bad
> CPython and Jython don't integrate seamlessly though)
Yeah, but maybe we can make Gump work in Jthon... hint hint
> - Cheetah (velocity for python) rocks
+1
> - ZopeX3 (development version of zope, www.zope.org) is basically aiming
> to recreate the whole interface/component/service/composition idiom (ie
> avalon ;D) in Python, and it clearly shows that python's meta model and
> security fails there. There is an upper limit to python complexity.
> Implementing an EE framework in python is not a good idea... (should do
> that in Ruby, perhaps...) ...interesting effort though!
Yeah. I think that Python is the glue king. I really wish M$ Office
could be scripted in Python... I'm using VB and it really sucks :-(
> TODOs
> -----
> 0) put this stuff in some kind of tracker
status.xml
...
> 3) uncomment the exec() calls and start making things actually work
I want first to make runs with an automatic installation. I will not run
it if I have to download jars manually. This should ensure that it will
be easier for all to use.
> 4) look at unittest.py and write tests
+1000
> 5) incorporate a callback/interceptor style setup which sends output and
> info to cheetah or something else (ie you plug in gen.py or cheetah.py
> into build.py)
And Alexandria. This is very important, as Gump then becomes
> 8) support <maven/>
+1
> 9) investigate running gumpy with jython, perhaps calling ant in-process
> (might be a lot quicker; no need to start up JVMs all the time)
We can run in process with Python too. I'd work only in CPython for now.
> 11) integrate functionality of nag.pl, gendoc.pl, etc.
gendoc +1
nag.py +0
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [gumpy] refactoring halfway
Posted by Leo Simons <le...@apache.org>.
rant rant rant below :D
Nicola Ken Barozzi wrote:
> Wait a sec, I just had time to look at it, and it's basically the same
> as I did before, but backed away because of these questions:
>
> 1 - why rss is in gump and not next to build?
rss can prolly be refactored to be 99% generic RSS and 1% specific to
gump, however as currently written its not. Belongs with gump 'till then.
> 2 - shouldn't properties be also in the main dir? (user override)
hmm. I would think user override should happen in the profile.xml, and
there would eventually be a jakarta-gump/run.py file which would defer
to build.py functions:
----
#!/usr/bin/env python
"""
Frontend to gump.build....
"""
import gump.conf
# override config here if you don't do it in xml
gump.conf.dir.base = '.'
gump.conf.basicConfig()
# kick tyres, light fires
import gump.build
build.run()
----
boy, python is easy. I suspect the above might actually almost work!
> 3 - shouldn't core be in the init module, so it is called as gump?
> (IIUC)
yes :D
> 4 - shouldn't view be in teh base dir?
why?
just like org.apache.avalon.phoenix.cli.CLIMain is a subpackage of
avalon.phoenix, so view is a subpackage of gump. Python packaging is
like java packaging, only slightly more ugly :D
> The only thing I'm sure is that the core needs to go somewhere in the
> gump package, for the rest I'm confused -> not committed it myself.
fortunately, its easy to change ;)
general docs about packaging are at
http://www.python.org/doc/essays/packages.html but most non-core python
packages I've found so far break at least one rule! Ni!
[OT] Python stuff
-----------------
I've played with python and jython (latest thought: drop Jelly again
from my personal projects and replace with jython :D), and ruby (ruby is
actually way cooler than python but less used and known atm!). Some
observations:
- python is exactly the right tool for gump. Gump is 90% glue and 15%
text/xml handling.
- docutils.sf.net could be way nicer...IIUC its python's future
'javadoc'....we should prepare to use it
- the pydoc util in the python distro is interesting as well...in
remarkably little code it is a tty tool, a gui tool and a webserver. I
see possibilities for implementing gump/server.py or something like that...
- lacking an editor with stuff like refactoring support and code
insight; I find the emacs python-mode to still be way less productive
than something like IDEA; this is one area where PHP still has the edge
over python imho
- python is absolutely great for coding stuff like blogs, wikis, little
CMSes, config tools. I think I'm building my next website in python :D
- python is hands-down the best all-round "glue" available (too bad
CPython and Jython don't integrate seamlessly though)
- Cheetah (velocity for python) rocks
- ZopeX3 (development version of zope, www.zope.org) is basically aiming
to recreate the whole interface/component/service/composition idiom (ie
avalon ;D) in Python, and it clearly shows that python's meta model and
security fails there. There is an upper limit to python complexity.
Implementing an EE framework in python is not a good idea... (should do
that in Ruby, perhaps...) ...interesting effort though!
TODOs
-----
0) put this stuff in some kind of tracker
1) figure out the dynamism in the GOM completely (ugh. Prototype OOP
always makes my head hurt)
2) put some stuff up on wiki, make noise
3) uncomment the exec() calls and start making things actually work
4) look at unittest.py and write tests
5) incorporate a callback/interceptor style setup which sends output and
info to cheetah or something else (ie you plug in gen.py or cheetah.py
into build.py)
6) install stuff on lsd.student.utwente.nl
7) do some rough speed comparisons
8) support <maven/>
9) investigate running gumpy with jython, perhaps calling ant in-process
(might be a lot quicker; no need to start up JVMs all the time)
10) refactor to be more OO and less function-oriented, figure out an
extension/plugin setup
11) integrate functionality of nag.pl, gendoc.pl, etc.
12) more refactoring (no doubt)
13) create a gumpy release which works like:
1) unpack (with GUI)
2) ./first-time-wizard.py (with GUI)
3) ./run.py (with GUI)
14) create a gumpy rpm which enables
rpm -i gumpy-0.3.5.rpm
gumpy install-service
gumpy build-all --result-email-to=gump@jakarta.apache.org \
gumpy clean
15) figure out how to make installing binary packages a lot less difficult
16) take a look at POM <-> GOM conversion
cheers!
- LSD
Re: [gumpy] refactoring halfway
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Sam Ruby wrote, On 29/04/2003 14.31:
> Nicola Ken Barozzi wrote:
>>
>> Sam Ruby wrote, On 29/04/2003 12.19:
>>
>>> Nicola Ken Barozzi wrote:
>> ...
>>> I still have a strong urge to make each class a separate file. But
>>> when an entire class is only a dozen lines or so, it does seem better
>>> to group related classes together.
>>
>> I'm *strongly* against making each class a separate file. IMNSHO
>> having the Gump OM in a single file is very important for
>> understanding the code.
>
> You will find that there are few implementation details that I am
> strongly for or against.
;-) I have strong feelings on this instead because I personally had
difficulty in understanding the Java version, but understood the Python
one almost immediately, and I fear it goes back to that ;-)
The fact is that separate classes seem to make me loose focus of the
overall picture, dunno why. Probably it's just me.
> But I did invest a lot of time into building
> support classes so that it would be possible to express the object
> module so concisely and expressively. And so far I am quite pleased
> with the result.
>
> In Jenny, I opted for major groupings: Project, Workspace, Module, etc.
> In the Python version, so far this does not seem to be necessary.
I was and still am impressed by the Python version: I am quite sure that
it's also due to using SAX instead of the DOM and because of Python's
conciseness. Also the use of Single, Multi, etc is very intriguing.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [gumpy] refactoring halfway
Posted by Sam Ruby <ru...@apache.org>.
Nicola Ken Barozzi wrote:
>
> Sam Ruby wrote, On 29/04/2003 12.19:
>
>> Nicola Ken Barozzi wrote:
>
> ...
>
>> I still have a strong urge to make each class a separate file. But
>> when an entire class is only a dozen lines or so, it does seem better
>> to group related classes together.
>
> I'm *strongly* against making each class a separate file. IMNSHO having
> the Gump OM in a single file is very important for understanding the code.
You will find that there are few implementation details that I am
strongly for or against. But I did invest a lot of time into building
support classes so that it would be possible to express the object
module so consisely and expressively. And so far I am quite pleased
with the result.
In Jenny, I opted for major groupings: Project, Workspace, Module, etc.
In the Python version, so far this does not seem to be necessary.
- Sam Ruby
Re: [gumpy] refactoring halfway
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Sam Ruby wrote, On 29/04/2003 12.19:
> Nicola Ken Barozzi wrote:
...
> I still have a strong urge to make each
> class a separate file. But when an entire class is only a dozen lines
> or so, it does seem better to group related classes together.
I'm *strongly* against making each class a separate file. IMNSHO having
the Gump OM in a single file is very important for understanding the code.
>> As far as I'm concerned, this Gump is a success, and I feel it mine as
>> much as your's or Leo's or anyone's. :-)
>
> That's the goal. ;-)
:-D
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [gumpy] refactoring halfway
Posted by Sam Ruby <ru...@apache.org>.
Nicola Ken Barozzi wrote:
>
>>
>> The one thing I most desparately want in this version of gump is not
>> to be viewed as the central authority or maintainer. So, please don't
>> wait for my approval on anything.
>
> Sam, I appreciate this, but honestly it's just help that I need. I'm not
> asking you to validate the design as a central authority, but since you
> are the only Python man here, I need help about how things usually work
> out in Python.
However much it may appear otherwise, my Python knowledge is only weeks
ahead of yours.
Gump was my first application of XSLT. I learned everything I now know
about XSLT during the coding of that implementation. This Python
version of Gump is only my third application written in Python. (The
rss validator and my weblog are the first two).
> I already moved stuff twice, but on my hd, and never was I satisfied:
> that's why I was asking you now if you gan give us an idea on what is
> best to do as a Pyhon programmer, not as a Gump preacher :-)
I'm never satisified either. I still have a strong urge to make each
class a separate file. But when an entire class is only a dozen lines
or so, it does seem better to group related classes together.
> As far as I'm concerned, this Gump is a success, and I feel it mine as
> much as your's or Leo's or anyone's. :-)
That's the goal. ;-)
- Sam Ruby
Re: [gumpy] refactoring halfway
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Sam Ruby wrote, On 28/04/2003 20.35:
> Nicola Ken Barozzi wrote:
>
...
>> 1 - why rss is in gump and not next to build?
>> 2 - shouldn't properties be also in the main dir? (user override)
>> 3 - shouldn't core be in the init module, so it is called as gump?
>> (IIUC)
>> 4 - shouldn't view be in teh base dir?
>>
>> The only thing I'm sure is that the core needs to go somewhere in the
>> gump package, for the rest I'm confused -> not committed it myself.
>
> I'm not waiting. Move things around as you see fit. It is easier to
> move things twice than to get things right the first time.
>
> I'll keep up.
>
> The one thing I most desparately want in this version of gump is not to
> be viewed as the central authority or maintainer. So, please don't wait
> for my approval on anything.
Sam, I appreciate this, but honestly it's just help that I need. I'm not
asking you to validate the design as a central authority, but since you
are the only Python man here, I need help about how things usually work
out in Python.
I already moved stuff twice, but on my hd, and never was I satisfied:
that's why I was asking you now if you gan give us an idea on what is
best to do as a Pyhon programmer, not as a Gump preacher :-)
As far as I'm concerned, this Gump is a success, and I feel it mine as
much as your's or Leo's or anyone's. :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [gumpy] refactoring halfway
Posted by Sam Ruby <ru...@apache.org>.
Nicola Ken Barozzi wrote:
>>
>> Don't be shy. Commit. If you break something, it will be fixed.
>> Nobody is depending on this just yet.
>
> Wait a sec, I just had time to look at it, and it's basically the same
> as I did before, but backed away because of these questions:
>
> 1 - why rss is in gump and not next to build?
> 2 - shouldn't properties be also in the main dir? (user override)
> 3 - shouldn't core be in the init module, so it is called as gump?
> (IIUC)
> 4 - shouldn't view be in teh base dir?
>
> The only thing I'm sure is that the core needs to go somewhere in the
> gump package, for the rest I'm confused -> not committed it myself.
I'm not waiting. Move things around as you see fit. It is easier to
move things twice than to get things right the first time.
I'll keep up.
The one thing I most desparately want in this version of gump is not to
be viewed as the central authority or maintainer. So, please don't wait
for my approval on anything.
- Sam Ruby
Re: [gumpy] refactoring halfway
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Sam Ruby wrote, On 28/04/2003 19.43:
> Leo Simons wrote:
>
>> Hi gang,
>>
>> wanting to restructure gump to be more in line with "regular" python
>> module organisation, only got about halfway (not tested), so not
>> committed. Did stuff like addition of licensing and conversion to use
>> docstrings as well. Zip attached for interested peeps.
>
> Don't be shy. Commit. If you break something, it will be fixed. Nobody
> is depending on this just yet.
Wait a sec, I just had time to look at it, and it's basically the same
as I did before, but backed away because of these questions:
1 - why rss is in gump and not next to build?
2 - shouldn't properties be also in the main dir? (user override)
3 - shouldn't core be in the init module, so it is called as gump?
(IIUC)
4 - shouldn't view be in teh base dir?
The only thing I'm sure is that the core needs to go somewhere in the
gump package, for the rest I'm confused -> not committed it myself.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [gumpy] refactoring halfway
Posted by Sam Ruby <ru...@apache.org>.
Leo Simons wrote:
> Hi gang,
>
> wanting to restructure gump to be more in line with "regular" python
> module organisation, only got about halfway (not tested), so not
> committed. Did stuff like addition of licensing and conversion to use
> docstrings as well. Zip attached for interested peeps.
Don't be shy. Commit. If you break something, it will be fixed.
Nobody is depending on this just yet.
- Sam Ruby