merging CleanUp branch back into CVS HEAD

["Adam R. B. Jack" <aj...@trysybase.com>]

Are folks brave enough for me to merge the CleanUp branch back into CVS
HEAD? It is a major re-work (see some details below, so not guaranteed to be
bug-free ;-) but it has performed ok on this server:

    http://gump.try.sybase.com/buildLog.html

I think it'd be smart to turn off nagging for a few days, just to verify
nothing truly offensive occurs immediately.

Thoughts?

regards,

Adam
----- Original Message ----- 
From: "Adam R. B. Jack" <aj...@trysybase.com>
To: <ge...@gump.apache.org>
Sent: Thursday, June 17, 2004 10:50 AM
Subject: Gump work-in-progress (CleanUp branch)


> I've been struggling with Gump performance issues for months now. That is
> 'clogs up' (on large workspaces) has continually hampered usage &
(frankly)
> my progress .
>
> I've turned over every rock that comes to my mind, but I keep failing.
I've
> been getting pretty frustrated with Python (I find it somewhat immature in
> inspection/tuning) -- I've been very frustrated with my abilities (I
likely
> don't have the experience with Python to figure things out) -- and I've
been
> ultra frustrated with environmental issues. Since I can only cause the
> slowdown on large projects (small ones go fast) it is those monsters I
have
> to get inside, and I need to do that remotely.
>
> All this has basically hampered my progress, stopped me moving on with new
> features/functions ('cos I clearly didn't have a true grasp of the
basics.)
>
> I started to add a bunch of __del__ (destructor) overrides, so I could
> explicitly break circular links. I believe Python was failing to garbage
> collect because it needed a hand with these. I can't prove that, but I
felt
> it. So, I started the 'Clean-Up' branch to work on cleaning up memory,
> trying to avoid clog up. That is how I started down this path, which is
now
> quite a lot more than CleanUp...
>
> When I found that the SAX to Python object code was slowed by something
> minor I added (for no clear reason) I just lost it! I was building on sand
> (at least in my knowledge). So (not that DOM is pretty/thin) but I had to
> move to it, to simplify things & get control. Since we streamed SAX into
> memory, I saw no harm. [I don't think our problem is memory usage, so much
> as memory management.] For once, I felt good about ripping out clever code
> and adding pedestrian code ... I just needed controlled.
>
> Along the way I decided that moving to Python 2.3 (the latest/greatest bug
> fixed release per Python.org) was smart. If there were GC implementation
> fixes, that is where I'd find them. Also, it allowed me to use the boolean
> type & get away from 0 & 1. It felt a lot cleaner to be on Python 2.3. [I
> added code to allow usage of /usr/bin/python2.3 interpreter, in case (like
> on gump.try) on has RHEL.]
>
> I started to feel 'bold and brave'. I started work on calling Depot to
> download jars (kinda like we download code via CVS/SVN). I'll wiki more of
> this, and I'll mail here. I have some final things to resolve, but I am
> finally getting there. This is huge (for me) this is what I want to be
> working on...
>
> At the same time the Forrest folk divided to do some major (copyless)
work,
> and they removed the ability to pass work/site location parameters to the
> batch file. Gump used these. Since I've not managed to install Forrest
into
> TomCat (when I once tried it failed, and the Forrest guys were too busy w/
> "copyless" to fix it), I started to feel the same pain as others. I
finally
> decided I could cope no longer with the *effectively mandatory* Forrest
> dependency for Gump. The inability for Gump to generate pages w/o Forrest
> was too much. As it now stands Gump's page generator can now generate
XHTML
> or XDOCS. The XHTML isn't pretty, but with a little CSS it is perfectly
> adequate [and we get colours again, as it looks w/ might w/ Forrest also].
> Basically XDOCS and XHTML are similar enough that I can if/else
> sufficiently. Take a look at:
>
>     http://gump.try.sybase.com/buildLog.html
>
> At the same time I decided to add the 'view as you go' ability Sam had
been
> looking for. I need to optimise it (I think the buildLog.html|buildLog.xml
> page generation is fat) but it works. As of now, the site gets updated as
it
> goes.
>
> I've added/changed other stuff, but minor things (in comparison). I do
like
> how branching allows me to make bold moves; I think the nightly/continual
> builds were causing me too much stress & slowing down my progress. I know
> I've broken a bunch of things along the way (the DOM change was
non-trivial
> & I have bugs w/ 'merge' & duplicates and such) but I'll work through
those.
>
> My goal is to install this (on Gump.try, then probably on Brutus, possibly
> w/ JDK1.4 -- but to move to JDK 1.5 when stable) -- and work out the
issues.
> There are issues, but I feel I am seeing light at the end of the tunnel. I
> won't attempt any merge back into the main branch until I've resolved them
> all/worked through them w/ folks here.
>
> regards,
>
> Adam
> --
> Experience the Unwired Enterprise:
> http://www.sybase.com/unwiredenterprise
> Try Sybase: http://www.try.sybase.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
>


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