You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@gump.apache.org by Leo Simons <ma...@leosimons.com> on 2005/04/05 11:11:26 UTC
Walking around gump code (svn commit: r160101...)
Adam,
Quick Q: how do you find the location to make small changes like this when
you fire up your development environment, and how do you test to make sure
its the only thing to change? How do you test a simple change like this
works?
Cheers,
Leo
On 04-04-2005 23:31, "ajack@apache.org" <aj...@apache.org> wrote:
> Author: ajack
> Date: Mon Apr 4 14:31:23 2005
> New Revision: 160101
>
> URL: http://svn.apache.org/viewcvs?view=rev&rev=160101
> Log:
> 1) Default java to $JAVA_HOME/bin/java (if JAVA_HOME set).
> 2) Add test data to .svn:ignore
>
> Modified:
> gump/trunk/python/gump/core/run/gumpenv.py
> gump/trunk/test/ (props changed)
>
> Modified: gump/trunk/python/gump/core/run/gumpenv.py
> URL:
> http://svn.apache.org/viewcvs/gump/trunk/python/gump/core/run/gumpenv.py?view=
> diff&r1=160100&r2=160101
> ==============================================================================
> --- gump/trunk/python/gump/core/run/gumpenv.py (original)
> +++ gump/trunk/python/gump/core/run/gumpenv.py Mon Apr 4 14:31:23 2005
> @@ -90,6 +90,11 @@
> self.javaCommand = 'java'
> self.javacCommand = 'javac'
>
> + # Default to $JAVA_HOME/bin/java, can be overridden with $JAVA_CMD.
> + if os.environ.has_key('JAVA_HOME'):
> + self.javaCommand =
> os.path.join(os.environ['JAVA_HOME'],'bin',self.javaCommand)
> + self.addInfo('JAVA_CMD set to $JAVA_HOME/bin/java = ' +
> self.javaCommand )
> +
> # Timezone and offset from UTC
> self.timezone = time.tzname
> self.timezoneOffset = time.timezone
>
> Propchange: gump/trunk/test/
> ------------------------------------------------------------------------------
> --- svn:ignore (added)
> +++ svn:ignore Mon Apr 4 14:31:23 2005
> @@ -0,0 +1,2 @@
> +
> +gump
>
>
Re: Walking around gump code (svn commit: r160101...)
Posted by Leo Simons <ma...@leosimons.com>.
On 05-04-2005 15:16, "Adam R. B. Jack" <aj...@apache.org> wrote:
>> Quick Q: how do you find the location to make small changes like this when
>> you fire up your development environment, and how do you test to make sure
>> its the only thing to change?
>
> In this case, I guess I believed I knew it, based on prior knowledge of the
> code, i.e that all things to do with environment checking are in that
> location. That said, I pretty much do a text search through the code. [Given
> I reverted to Eclipse, Wings still is a bit flaky for me and I haven't found
> a Python IDE I like, I don't have a better solution. Do you? I'd like to
> find one.]
I've been using a whole lot of command line coupled with SubEthaEdit
(mac-only reasonable quality editor that does syntax highlighting) more and
more. I tend to have Wing open next to it as well, which I love most for its
ability to parse out doc strings (I always have the "Source Assistant" open
on the left panel) and for its autocomplete functionality. When writing
serious bits of new code I do tend to do it in Wing.
I keep a few terminals open and find,grep,cat,ls my way around the code. I
keep a python interpeter open in a console to test whether I get the syntax
right. I find myself doing more and more stuff like
$ python
>>> from gump.model import Workspace
>>> dir(Workspace)
>>> Workspace.__doc__
>> How do you test a simple change like this works?
>
> I run "gump" in the cron directory, and my local environment has:
^^^^^
> GUMP_NO_CVS_UPDATE=true
> GUMP_NO_SVN_UPDATE=true
> GUMP_WORKSPACE=python\gump\test\resources\full1\tsws1
That's a bit of a problem, in terms of "getting involved". Ideally one
should be able to
$ svn co http:..../trunk gump
$ cd gump
$ ./gump test
And make that run the tests.
> this causes a run of the test workspace data. Unfortunately (as your mail
> made me realize) this isn't as good a test as I'd like. This is fine for a
> lot of the 'mechanics' but not for a true full run.
Hmm. I guess what you test here is that your change didn't break things in
so far that a run won't start. Gump simply has a whole lot of features and
very tricky behaviourisms :-D
> Basically, the data in
> that workspace does not cover enough codepaths. [Clearly this has been
> noticed w/ my 'multiple commits', so I can test on TEST.]
Yep. For me, running tests on a remote machine or waiting for long runs
*really* takes a whole lot of the fun out of development. I can get really
bitchy about waiting on things like compilation. Running stuff on brutus
isn't going to do it for me.
> I've always struggled with testing Gump 'cos I don't have the most conducive
> environment (no Linux, slow link, etc.) That said, I think I need to make a
> better effort, and make a small workspace I can really work on.
Heh. You need linux!
> BTW: This brings me back to the point you made about me not using unit test.
> Interestingly, I consider myself a reasonably test infected kinda guy, but
> you aren't wrong ... I'm not using them aggressively for Gump any more. I've
> tried to consider why, and lack of IDE/(Pant = PyAnt ;-)scriptability and
> all are factors. That said, I did really try. Python needs code coverage or
> it is a walking time bomb of runtime errors, so I really wanted to...
Amen to that! Python is productive because it is very conductive to making
assumptions about stuff "just working", and a whole lot of python code is
set up in a way that encourages trying it and looking at the output of
"print" statements to make sure things work. I find you always only ever
cover half of the execution paths when debugging using "print".
> I added the gump unit tests to the workspace, I added a script to try to run
> tests, to run pychecker, etc. I suspect I simply stretched myself too thin,
> and didn't get things right, but one big factor was 'environment'. There is
> something (IMHO wrong) about Python launching other Python scripts, and not
> using the PYTHONPATH for it, but having to know the path to the main script.
> That caused some of these things to be harder than they ought be, and hence
> fall by the wayside.
Yeah. I agree, it ain't all that easy. I feel the OptionParser and friends
are workable for a "single mode" commandline, ie for KISS utilities. Doing
multi-mode commandlines feels awkward. That's why I figured we do need a CLI
front end in something like bash (which is just really really good for
glue). I feel what I got so far for the Gump3 branch is pretty userfriendly
by now, but haven't had much feedback at all, so it might just be me :-D
Running tests in python seems awkward at best. The Zope people rewrite their
crappy test runner (which I cloned in the Gump3 branch) every few releases.
I tried moving from the one I copied over from Zope 2.6 to the one used in
Zope3, and it was a nightmare so I abandoned it. I also tried writing
something from scratch, but unfortunately it isn't as easy as it should be.
Another thing python misses is good code coverage reporting like Clover does
for java. The hard technological problem (introspection and tracing) is
solved in some standard python module, but after that everyone seemingly
lost interest in perfecting it.
> [Take for example the fact of how nobody seems to have
> a decent Gump command line interface. It isn't just us, the 4 or more people
> who have tried, there is something (IMHO) hard about doing this right in
> Python. If I could put my finger on it I'd blog about it in detail looking
> for assistance, or better yet ... fixed it! ;-)]
Maybe we could take a look at backporting the bash script from the branch
over to the trunk. It's not feasible to write such a thing in a .bat file
though, imnsho, so I'm not going to put effort in there if it isn't going to
help you :-D.
> Also, I think Gump problems always seemed to show up in runs, due to
> metadata or environment or something, and not in simple Python code (other
> than time bombs). I wrote unit tests, I wrote test environments, but I
> always had a gap between this coverage and live. Even when Gump passed it's
> unit tests, it still failed in runs. Perhaps the implementation was too
> shallow, or something, but I found it too hard to write unit test for the
> main/core parts. [One of the reason I went to runners/actors/etc. was to see
> if I could get inside this aspect.] Perhaps I needed integration tests, but
> those ended up best being the TEST environment.
I dunno. My feeling is that gump is simply a complex program with a very
complex set of requirements and hence a complex design. You went very
quickly from the toy program Sam built to implenting a *huge* range of
features. That kind of thing is very hard to do while at the same time
having test coverage. Testing difficult things is difficult. We're spoiled
with java IDEs that make it a whole lot easier!
> In short think it is part Python, and part Gump's functionality, and part
> individuals/time/focus as to why unit testing isn't playing a bigger role.
Yeah, I guess.
> Basically, I love testing, I believe it is more critical for Python than
> anything else, and I'm game to give it another shot.
What triggered the question for me is that I thought about trying to patch
in this change, looked around for 10 minutes, and couldn't really figure out
where to start. And by now I probably am second in terms of gump code
knowledge after you. We need to fix that!
I think the first step in making it easy to do development on a project is
to make it easy for yourself to do development on that project. Completely
clean out your environment (or use a different machine :-D), do the svn
checkouts, compile, run tests. Make that cycle easier. And easier. And
easier.
Allowing people to help you is hard work :-D
Cheers,
Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Walking around gump code (svn commit: r160101...)
Posted by "Adam R. B. Jack" <aj...@apache.org>.
> Quick Q: how do you find the location to make small changes like this when
> you fire up your development environment, and how do you test to make sure
> its the only thing to change?
In this case, I guess I believed I knew it, based on prior knowledge of the
code, i.e that all things to do with environment checking are in that
location. That said, I pretty much do a text search through the code. [Given
I reverted to Eclipse, Wings still is a bit flaky for me and I haven't found
a Python IDE I like, I don't have a better solution. Do you? I'd like to
find one.]
> How do you test a simple change like this works?
I run "gump" in the cron directory, and my local environment has:
GUMP_NO_CVS_UPDATE=true
GUMP_NO_SVN_UPDATE=true
GUMP_WORKSPACE=python\gump\test\resources\full1\tsws1
this causes a run of the test workspace data. Unfortunately (as your mail
made me realize) this isn't as good a test as I'd like. This is fine for a
lot of the 'mechanics' but not for a true full run. Basically, the data in
that workspace does not cover enough codepaths. [Clearly this has been
noticed w/ my 'multiple commits', so I can test on TEST.]
I've always struggled with testing Gump 'cos I don't have the most conducive
environment (no Linux, slow link, etc.) That said, I think I need to make a
better effort, and make a small workspace I can really work on.
BTW: This brings me back to the point you made about me not using unit test.
Interestingly, I consider myself a reasonably test infected kinda guy, but
you aren't wrong ... I'm not using them aggressively for Gump any more. I've
tried to consider why, and lack of IDE/(Pant = PyAnt ;-)scriptability and
all are factors. That said, I did really try. Python needs code coverage or
it is a walking time bomb of runtime errors, so I really wanted to...
I added the gump unit tests to the workspace, I added a script to try to run
tests, to run pychecker, etc. I suspect I simply stretched myself too thin,
and didn't get things right, but one big factor was 'environment'. There is
something (IMHO wrong) about Python launching other Python scripts, and not
using the PYTHONPATH for it, but having to know the path to the main script.
That caused some of these things to be harder than they ought be, and hence
fall by the wayside. [Take for example the fact of how nobody seems to have
a decent Gump command line interface. It isn't just us, the 4 or more people
who have tried, there is something (IMHO) hard about doing this right in
Python. If I could put my finger on it I'd blog about it in detail looking
for assistance, or better yet ... fixed it! ;-)]
Also, I think Gump problems always seemed to show up in runs, due to
metadata or environment or something, and not in simple Python code (other
than time bombs). I wrote unit tests, I wrote test environments, but I
always had a gap between this coverage and live. Even when Gump passed it's
unit tests, it still failed in runs. Perhaps the implementation was too
shallow, or something, but I found it too hard to write unit test for the
main/core parts. [One of the reason I went to runners/actors/etc. was to see
if I could get inside this aspect.] Perhaps I needed integration tests, but
those ended up best being the TEST environment.
In short think it is part Python, and part Gump's functionality, and part
individuals/time/focus as to why unit testing isn't playing a bigger role.
Basically, I love testing, I believe it is more critical for Python than
anything else, and I'm game to give it another shot.
regards,
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
FW: Walking around gump code (svn commit: r160101...)
Posted by Leo Simons <ma...@leosimons.com>.
Wrong list! :-D
------ Forwarded Message
From: Leo Simons <ma...@leosimons.com>
Reply-To: <co...@gump.apache.org>
Date: Tue, 05 Apr 2005 11:11:26 +0200
To: <co...@gump.apache.org>
Subject: Walking around gump code (svn commit: r160101...)
Adam,
Quick Q: how do you find the location to make small changes like this when
you fire up your development environment, and how do you test to make sure
its the only thing to change? How do you test a simple change like this
works?
Cheers,
Leo
On 04-04-2005 23:31, "ajack@apache.org" <aj...@apache.org> wrote:
> Author: ajack
> Date: Mon Apr 4 14:31:23 2005
> New Revision: 160101
>
> URL: http://svn.apache.org/viewcvs?view=rev&rev=160101
> Log:
> 1) Default java to $JAVA_HOME/bin/java (if JAVA_HOME set).
> 2) Add test data to .svn:ignore
>
> Modified:
> gump/trunk/python/gump/core/run/gumpenv.py
> gump/trunk/test/ (props changed)
>
> Modified: gump/trunk/python/gump/core/run/gumpenv.py
> URL:
> http://svn.apache.org/viewcvs/gump/trunk/python/gump/core/run/gumpenv.py?view=
> diff&r1=160100&r2=160101
> ==============================================================================
> --- gump/trunk/python/gump/core/run/gumpenv.py (original)
> +++ gump/trunk/python/gump/core/run/gumpenv.py Mon Apr 4 14:31:23 2005
> @@ -90,6 +90,11 @@
> self.javaCommand = 'java'
> self.javacCommand = 'javac'
>
> + # Default to $JAVA_HOME/bin/java, can be overridden with $JAVA_CMD.
> + if os.environ.has_key('JAVA_HOME'):
> + self.javaCommand =
> os.path.join(os.environ['JAVA_HOME'],'bin',self.javaCommand)
> + self.addInfo('JAVA_CMD set to $JAVA_HOME/bin/java = ' +
> self.javaCommand )
> +
> # Timezone and offset from UTC
> self.timezone = time.tzname
> self.timezoneOffset = time.timezone
>
> Propchange: gump/trunk/test/
> ------------------------------------------------------------------------------
> --- svn:ignore (added)
> +++ svn:ignore Mon Apr 4 14:31:23 2005
> @@ -0,0 +1,2 @@
> +
> +gump
>
>
------ End of Forwarded Message
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org