Gump3 or Gump 2.1

[Adam Jack <aj...@mric.coop>]

I've been pretty flaky these last months; not able to commit the time/effort
I'd enjoy committing. Basically, of the three days a week I can work (the
others I grow with my daughter) I've been working for a start-up that
consumes me. It is fun to build something from scratch, but I need to let
things mature/settle now that the live customers using it. So, maybe (this
attempt) I can eke out a little time.

So, I keep coming back to this ... what Gump can I make increment
improvements on, given that small amount of time. Could I tweak Gump2 to a
Gump 2.1 that is closer to what we want, or is Gump3 really the starting
point. Just 'cos there is a bunch of code in Gump2 doesn't mean Gump3
ougtn't be the primary move, it is just very daunting to start from scratch
(again).

I know that a Gump 2.1 could be valuable, it really isn't very far from
where we are to populating the database (as Gump3 wishes to do) and maybe it
is a valuable contribution, for comparing Gump3 to. That said, I can't write
the Cocoon-based DB presentation layer, so w/o some good will/interest from
others that could be a pointless venture.

So, I'm looking to see what other's thoughts are, to see if I could tie in.
Thanks in advance.

regards,

Adam


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org

Re: Gump3 or Gump 2.1

[Leo Simons <ma...@leosimons.com>]

Brain dump :-D

On 16-03-2005 22:39, "Adam R. B. Jack" <aj...@apache.org> wrote:
>> What would you enjoy most? :-D
>> 
> Getting insights into a worldview outside of my head, and learning from/with
> others. :-)
> 
>> /I/ would love to see you helping out with Gump3.
> 
> I'll give it a shot.
> 
> I don't quite share your views that Gump needs to be so componentized, but
> (1) I don't object to them and (2) I do see a lot I'd do differently another
> time around & would like to tinker.

It doesn't have to be "components" or "plugins". Those are big words that
are fun because they sound intelligent and ring a bell with many people. As
long as its "KISS" I'm happy. Small testable units. Small testable functions
would do just as well and I'm definitely springkling those around where it
makes sense. The subwiki codebase is one example of a function table based
design in python that's extremely "componentized" in many ways :-D.

It's just that I'm so used to class-based programming, so that's how some of
it wound up. I'll argue though that plugging in various instances in
different locations is easier to understand than having lambda functions,
along with apply() and eval() and lots of metaprogramming. The latter is
perhaps less coding work, but a lot more thinking work :-D.

As I pick a new piece of work to get started on (built the beginnings of a
model verifier for example), I tend to spend a lot of time reading through a
lot of the code you wrote, which really is very educational. Try it :-D. It
works both ways...

1) Where is the code in Gump2 that handles the stuff that the
gump.engine.modellier.Verifier is supposed to do in Gump3? How do both of
them work and what's the difference?

2) Where is the code in Gump3 that handles the complete() functionality
found throughout the gump.model in Gump2? Why is it there and not part of
the model?

3) What are the extension points in Gump2 for adding a new build command
(for example, an <automake/>)? Where are they in Gump3? Which one is easier,
which one more intuitive? What would be optimal?

4) How does classpath management work in Gump2 and how could that be
"componentized" into the Gump3 system without leading to clutter or making
the core bits "language-aware"?

There are *so* many design questions like that to ask and so many answers to
be devised. It would amount to a whole lot of e-mails ;-)

--

Talking about "worldviews", I'm guessing that this test-based approach to
development I'm advocating is also something you're not that used to along
with a lot of people around here (I guess that's an assumption based on the
fact that gump2 doesn't have that many unit tests in relationship to the
amount of code and features it has, and gump1 was totally untestable). I
admit I've not been very disciplined about full test coverage, but I'm
definitely working towards it.

Maybe you'd like to take a stab at that as well, it's very liberating.
Really!

For example, look at my last commit on the Gump3 branch. Among other things,
I changed a whole bunch of

  assert isinstance(blah,str)

to

  assert isintance(blah,basestring)

Which I had to do because the DOM library returns unicode strings (which I
found out when doing a './gump run', which I hadn't done in a while as I was
cleaning up code. I got an AssertionError). When I found that problem, I
scattered some new code throughout the testModel.py test suite, creating
unicode() strings and feeding them to the model object. I wound up with a
nice list of test failures, making it trivial to be sort-of sure I fixed all
the assertions in the modelling code. Feels good! Of course, you can just
run tests using './gump test' and it takes only a few seconds to run them
all, which is kinda vital to productive test-based development.

Now, this made me realize that we probably need an assert_string(foo) method
in a utility library somewhere.

  test_assert_string(self):
    a = "blah"
    b = unicode(a)
    c = ""
    d = unicode(c)
    f = None
    f2 = self

    self.assert_(assert_string(a))
    self.assert_(assert_string(b))
    self.assert_(assert_string(c))
    self.assert_(assert_string(d))
    self.assert_(not assert_string(f))
    self.assert_(not assert_string(f2))

Followed by

  assert_string(argument):
    """Raises an AssertionError if the provided argument is not an instance
    of a string type. String types include 'str' and 'unicode'."""
    # Implementation note: unicode strings didn't exist in early versions
    # of python, but since we require 2.3 anyway for gump, that's not a
    # problem
    assert isinstance(argument,basestring), \
      "'%s' is not a string instance!" % argument

I've yet to implement that change. Anyone feel up to it? :-P

It gets more fun when the problem is complex and/or more difficult to test.
For example, could we figure out the test cases for our process management
woes? Once we do, writing the code that satisfies the tests will no doubt be
easy enough, or at least a lot easier.

Its those kinds of small steps which will lead to a much cleaner and much
more understandable codebase in the end. I'm sure it's worth it!


Cheers,


Leo



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org

Re: Gump3 or Gump 2.1

["Adam R. B. Jack" <aj...@apache.org>]

>
> What would you enjoy most? :-D
>
Getting insights into a worldview outside of my head, and learning from/with
others. :-)

> /I/ would love to see you helping out with Gump3.

I'll give it a shot.

I don't quite share your views that Gump needs to be so componentized, but
(1) I don't object to them and (2) I do see a lot I'd do differently another
time around & would like to tinker.

regards,

Adam


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org

Re: Gump3 or Gump 2.1

[Leo Simons <ma...@leosimons.com>]

Hi Adam!

Good to hear from you.

On 14-03-2005 15:01, "Adam  Jack" <aj...@mric.coop> wrote:
> I've been pretty flaky these last months; not able to commit the time/effort
> I'd enjoy committing. Basically, of the three days a week I can work (the
> others I grow with my daughter) I've been working for a start-up that
> consumes me. It is fun to build something from scratch, but I need to let
> things mature/settle now that the live customers using it. So, maybe (this
> attempt) I can eke out a little time.
> 
> So, I keep coming back to this ... what Gump can I make increment
> improvements on, given that small amount of time. Could I tweak Gump2 to a
> Gump 2.1 that is closer to what we want, or is Gump3 really the starting
> point. Just 'cos there is a bunch of code in Gump2 doesn't mean Gump3
> ougtn't be the primary move, it is just very daunting to start from scratch
> (again).

What would you enjoy most? :-D

/I/ would love to see you helping out with Gump3. I'm making some slow
progress. Doing things componentized with big barriers between components,
and unit tested (working my way up to test-first), is a lot of work. Going
on my own we're months away from something usable. I would love to engage in
discussion about how to componentize Gump2 into many small utilities and
plugins. I'm still a few weeks away from having most of the boring "kinks"
worked out so that I can lower the barrier for others to contribute, but I
doubt they'd get in your way.

The current live/trunk gumps really are suffering a little from less tender
love and care from you. There's a lot of work that really needs to be done
(like making sure we can use one CVS|SVN master tree and properly testing
all that) if at all possible. And Stefan could no doubt use some help
polishing the configure|make integration?

I wouldn't worry too much about duplication of effort. I find that with
python, writing the code isn't the problem, its figuring out how to write it
(like how to properly and portably run programs from the shell), and that
kind of stuff isn't duplicated.

> I know that a Gump 2.1 could be valuable, it really isn't very far from
> where we are to populating the database (as Gump3 wishes to do) and maybe it
> is a valuable contribution, for comparing Gump3 to. That said, I can't write
> the Cocoon-based DB presentation layer, so w/o some good will/interest from
> others that could be a pointless venture.

Even not talking about the actual programming, I don't know yet what the
presentation of our data /should/ look like, so I have some doubts about
spending a lot of time conforming to a data model of which we are currently
not quite sure it offers exactly what we need. I for one need some more
"hard" requirements in the form of, O, I dunno, GUI mockups.

> So, I'm looking to see what other's thoughts are, to see if I could tie in.
> Thanks in advance.

There's a whole lot of stuff you could do. Just make sure to have fun :-D


Cheers,


Leo



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org