Re: agx: Moving forward

Daniel Nouri wrote:
>>There are a number of doctests around, don't fear. They're not in the
>>doc/ directory, but in the individual directories.
>>internalmodel/internalmodel.txt and so.
> 
> Let's rename all doctests that document a package to README.txt, which
> is the convention for Zope 3.

Good suggestion, I've fixed this in the train back home. Two directories 
had two doctest files, so I've only renamed the biggest one to 
README.txt for now.

> I have overseen the intermodel.txt
> doctests.  It looks pretty good, but then targets/python/target.txt is
> very minimal, and it seems like it doesn't get the model right:

I've only given real love and care to the internalmodel/* and the 
profile/* stuff. The rest is mostly left in the same state as it was at 
the end of the castle spring. I haven't had time to look at that and 
clean it up, neither have the original authors.

> Looking at this, ClassMethod seems not really to be what we want.  Plus,
> the API looks kinda tedious and the doctest itself is generally in a
> poor shape.  We need to doctest (i.e., unittest) every single function
> in the whole "Genesis".  Wake up lazy ArchGenXML programmers! ;-)

Ehm... I did write doctests. Especially for the internal model part and 
the profile part. Those are the two parts that I've given the most care 
and feeding. Writing doctests is a great way to figure out what you 
really want, what is elegant and what works best. And for the internal 
model I also added unittests for those parts that weren't simple getters 
and setters.

So: please be a bit more careful. You could also have asked about the 
current genesis state, asking which parts are good and which aren't, 
instead of complaining loudly about a cow-trodden, mud-splattered, 
rotting piece of squirrel entrails that has been left out in the sun for 
too long.

It *is* easy to find unfinished parts of code in genesis: that's the 
state we left it in when running for the train to the Vienna airport!

I'm desperately trying to extract useful pieces of advice and opinion 
from your posts (like the README.txt one), but I'm getting the idea that 
I'm treathened by a "svn rm" of the current code tree and an absolute 
ban on trying some preliminary archgenxml bootstrapping.

> This is really just an example to help you understand what I dislike
> about the current state the Genesis code is in.  50% of it is basically
> garbage.  Why bring us to a state where we have to first clean up the
> mess before we can get going?  I don't like this approach, and it kinda
> feels like developing with ArchGenXML in general.  First you generate
> all that mess, then you fix it, then you program what you actually want.

Point taken. That's not what we want, agreed. I'm sure we'll get to 
cleaning up the bad parts: *when* we go through them a second time in 
order to weave it all into a whole.

> I like the idea of having a prototype.  But getting something done
> shouldn't be the driving force.  This smells too much like the approach
> we had with ArchGenXML, i.e.  "get it done quickly".  If we don't land
> proper interfaces and a proper architecture now, we'll have lots of work
> more in the end.

Who's saying that there's no proper architecture? Not the people 
spending four days at the castle sprint discussing the proper 
architecture. Sure, it's in our head, mostly, but I'll whip up a blog 
post within the hour.

I'm the only one using archgenxml to generate his parts at the moment. 
The rest of the code is mostly just directly code python. And, hey, the 
internal model part is currently the best document, best tested and most 
ready part. => using archgenxml is no real impedement to progress.

 > I have a feeling that we want to discuss the architecture
> (even if it's only to make it clear to everyone) and come up sane
> interfaces and tests.  That's totally essential, IMO.

There has been enough architecture thinkwork. 70% will probably be 
replaced anyway, but the core thing to happen now is some basic 
implementation work. Just get it to generate *something*. I'll work on 
that tomorrow in the train. Working code with good doctests speaks so 
much clearly than 5 A4 papers full of textual explanation of somehting 
that isn't really fixed in stone yet.

Note that I'm not agains discussing it here, more clarification and more 
ideas is probably very handy :-)

> You end up spending your time fixing ArchGenXML, when all you want is to
> create a program that does it right.  Why carry on with the burden of
> extending the old ArchGenXML just so it fits our (ArchGenXML- wise)
> unusual kind of code?

Oh, some parts didn't fit and I've left them alone. The optionparser is 
not agx generated as that gave too much headaches. The rest of the code 
that I've more or less finished seems to do OK with it.

Reinout - plodding along actually building the thing

-- 
Reinout van Rees                       r.van.rees @ zestsoftware.nl
http://vanrees.org/weblog/                  http://zestsoftware.nl/
"Military engineers build missiles. Civil engineers build targets."



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642