gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam R. B. Jack" <>
Subject Re: [HEADSUP] Overrides/merging...
Date Wed, 11 Feb 2004 15:34:02 GMT
> > I seriously doubt that overrides work as (traditionally) intended,
> > and merging -- gosh knows, probably not.
> I don't have any overrides in my workspace anymore, I do merge in a
> <deliver> (which has to die) tag to the gump project.
> Is there an easy way in Gumpy to see whether this has been merged in,
> in "traditional" Gump I'd look into work/merge.xml.

Yes, and no. There is :

but I have a slight privacy issue with that, that I might have to knobble
it. [I have a suspicion that this, above, is stale.]

That said, as I understand it, merging works like this in Gumpy:

For things which are 'named' (Profiles, Modules, Projects, Repositories,
Servers) an object is created (and stored in a hash) when first encountered.
Subsequence XML representations of such an object with such a name get the
hashed object to work on. As such attributes ought be overridden.
Sub-element, they get set or added to (dependent upon if they are single or
mulitple, i.e. repeating). [P.S. I'll find a place to document this...]

I can't swear to it that sub-elements are handled correctly, actually, nor
any of this. I've not dug in to it too deep to exactly this.

Truth ... this is the only remaining area of code (Sam's, or some Sam
'borrowed') that I've not re-worked to a point I feel comfortable with it.
(Ok, not messed w/ the GUI much either.) This XML -> Object code is so
'intricate Python' (returning existing objects from constructors, delegating
method calls, attributes as methods) that it defeats me any time I try to
take control of it. I managed to put some error handling in (XML errors are
now reported as annotations on the parent object) but that nye on killed me.
There be dragons in there... ;-)

> Unit tests?

Meaning, does Gumpy have any? Yes, despite the fact they do me little
good -- as CVS re-re-re-re-commits show -- 'cos there is insufficient
coverage at this point. Still, we won't get coverage without unit tests, so
I just need to make these run (some directory problem) and then keep them

BTW: Gumpy uses a hacked up pyunit class I wrote instead of the real Python
pyunit, 'cos I didn't know the latter exists. I ought move to the real
pyunit, and see if there are any tools to exercise coverage.

FWIIW: Gumpy needs to move from basic Python (teaching myself as I go along)
to 'power Python', leveraging more packages & being 'nicer' Python code. We
currently require Python 2.2 (with logging bundled into our CVS repository)
we can remove that with Python 2.3, they added it. I tried to keep Gumpy
standalone/2.2, but I think it ought leverage Python more, so I might start
breaking that. Also, I need to go find that lint-like tool that Ted Leung
wrote about...



View raw message