gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <>
Subject Re: Gump3 questions
Date Tue, 11 Jan 2005 11:28:09 GMT
On 11-01-2005 06:00, "Adam  Jack" <> wrote:
> Ok, I'm hooked.


> 1) Why do we have a shell script for running Gump? Ought we not try (this
> release) to be pure Python?

IMHO python is not so good at interfacing with the basic unix env as is
bash. I've got nothing against a rewrite of the gump script to be
python-only, but I suspect that'll be more painful to write and maintain. At
least right now, people that don't any python development can probably
figure out how to plug in new "commands".

> 2) Does Gump3 use Zope or work with Zope?

No, it doesn't use Zope. Why would you want to do that? Zope is overkill
IMNSHO and they made a lot of the wrong design decisions.

> 3) Does GumpSet have a future w/ Gump3? Alternatively, is walker savvy to
> dependency order?

The walker walks stuff in dependency order. It's supposed to be pretty
efficient at that, but I haven't tested that yet. It doesn't verify stuff
though, so acyclic dependency checking needs to end up elsewhere.

> 4) (BTW: For DynaGump) was phpmyadmin removed, or moved, from Brutus? [I can
> go look, just wondering if somebody did something intentional.] Alternative,
> might we open up SQL access on Brutus' firewall so we can use Control
> Center? [I believe I recall Stefano saying he trusted it's security
> sufficiently.]

You could also

  sudo ssh -L $MYSQL_PORT:localhost:$MYSQL_PORT

And pipe mysql through ssh.
> 5) Any ideas why this gives the help message and exits (SystemExit: 2) in
> the Wing IDE Python Shell? It acts as if I didn't pass the require CLI
> parameter.
>>>> import testrunner
>>>> testrunner.main('-a')

Nope. No idea. Try stepping through it in debug mode :-D

> Looking at what is there so far, I'm inclined to hope we don't code too much
> more too soon, 'cos I think we need/want to refine our plugin protocol, and
> our "property using" protocol some.

Sure thing! Big +1. Let's try and write some unit tests that show how the
"protocol" is lacking. I have a feeling that'll work a little better than an
abstract discussion about software architecture principles (ie like my
response below *blush*)...

> Having to pass log around isn't bad, but
> it's looking like we need to pass a few things. Ought that be an object, or
> a dictionary?

IMNSHO the answer is a big fat "no". Experience shows that when it is
annoying to pass in lots of things into a component because it looks
visually ugly, you pass in less stuff, and that is a Good Thing. Trust me on
this. If you need to pass more than 5 things around between components
that's a problem.

> Also, tell folks the names of start/stop timing properties
> seems odd. Maybe we need to pass some pre-dictionaries of terms or
> something.

I don't know what you're referring to here...

Let's try to prevent passing around generic dictionaries and the like as
much as possible. It is so much easier to figure out what is going on when
you don't have to do packaging and dereferencing throughout the code.

> Still ... more fun than Gump2 (which was too pseudo Java-like/fat) .. and
> Wing IDE 2.0 is an improvement on the older one.

:-D. Yah.

> BTW: I see quite a few area where simplistic code has been used, where Gump2
> needed to enhance it (e.g. SMTP handling w/ escape characters, setting sent
> date headers & process control -- e.g. timeouts, etc.) I'm more than game to
> keep things simple for as long as possible, but I suspect we'll need to work
> these things back in.

Well, its key that any small bit of code stays small. If python's SMTP
libraries ain't smart enough to handle stuff like escaping, let's write our
own that does do that stuff, but keep the main execution path simplistic.
There's actually a lot to be done to make that main execution path even
simpler :-D


- Leo

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message