[M3devel] HEADS UP: Release engineering, was: Re: CM3 Release

[Olaf Wagner]

Quoting "Rodney M. Bates" <rodney.m.bates at cox.net>:

> Any opinions about the TEXT branch?  Anybody tried it? To summarize:
>
> - I have tested it extensively on LINUXLIBC6, with a large random
>  test program and two successive rebuilds of CM3.
>
> - It makes no changes in data structure, neither to static declarations
>  nor to invariants.  Thus it creates no compatibility problems with existing
>  pickles, etc.
>
> - It slows down concatenation, but more than makes it up in other
>  string accessing operations, if the numbers of concatenations and
>  accessing operations are equal.
>
> - It cuts down on tree depth and even more or recursion depth
>  (which implies needed stack space.)
>
> - This effect is dramatic when strings are built by "linear" concatenations,
>  i.e., strictly left-to-right, or vice versa.  Gains are moderate when
>  concatenations are random.
>
> - It allocates a lot more storage, but abandons a lot more garbage,
>  retaining somewhat more space when lots of old strings are retained
>  along with newly-built ones.  It probably retains less when operand
>  strings of concatenations are not kept, but I haven't measured that.
>
> - Strategies are partial rebalancing of concatenation trees, flattening
>  of short concatenations, elimination of a lot of tail-recursion, and
>  recursing on the shorter side.

I would tend to give it a try, i.e. include it in the release candiates,
but I'd like to have some data about the impacts on real applications,
let's say the cm3 compiler itself, the caltech parser generator, and
cvsup. How do these perform for a small set of sample data?

I won't have the time to do these tests though, so I'll trust the
opinion of others regarding the inclusion in the next release.

Olaf

> Olaf Wagner wrote:
>> Well, that's a quite long list; but many things are bug fixes anyway,
>> and wouldn't be affected by a code freeze, while others are already
>> finished (as integrating CVSup, as I understand).
>>
>> The only thing we should not do is introduce new platforms while
>> trying to get the system stable. We should concentrate on installation
>> support and bug fixing.
>>
>> I'd suggest to start the release process in about two weeks at the
>> start of May. That should give everybody enough time to either finish
>> their ongoing work that shall make it into the release or decide to
>> postpone it ;-)
>>
>> Any objections?
>>
>> Olaf
>>
>> Quoting Jay <jay.krell at cornell.edu>:
>>
>>>
>>> > > o When should we start? I.e. wha changes would you like to complete
>>> > > before we start the release process?
>>>
>>>
>>>
>>>
>>> I'd like to see the formsvbt crash debugged and fixed, unless I'm   
>>>  the only one seeing it.
>>>
>>> I only see it on Solaris and PPC_DARWIN but haven't tried "everything".
>>>
>>> I'll try to get this.
>>>
>>>
>>>
>>>
>>>
>>> I'd also like to see:
>>>
>>>
>>>
>>>
>>>
>>>  FreeBSD/x86 switched to the new Unix/*.i3 files. I'll do this.
>>>
>>>    Maybe also I386_DARWIN, AMD64_DARWIN, but I don't have the hardware.
>>>
>>>
>>>
>>>
>>>
>>>  $ORIGIN/LD_LIBRARY_PATH resolved a bit further, probably very    
>>> little work  (I'll do this).
>>>
>>>  Basically just 1) put buildlocal back how it was 2) push it   
>>> across  more platforms e.g. I think FreeBSD/x86 is the main one   
>>> missing, but  I'll get to it.
>>>
>>>
>>>
>>>
>>>
>>>  cvsup building and in "std"  (I'll do this, probably very little   
>>>  left here really.
>>>
>>>
>>>
>>>
>>>
>>>  -- beyond this, not required for release --
>>>
>>>
>>>
>>>
>>>
>>>  Maybe more AMD64 releases, e.g. NetBSD and Solaris. (If I get to it).
>>>
>>>   (could be "mingw64" is good enough to try AMD64_NT now).
>>>
>>>
>>>
>>>
>>>
>>>  Maybe update gmp/mpfr to fix the "maintainer" problem. (not likely by me)
>>>
>>>
>>>
>>>
>>>
>>>  Maybe more new/resuscitated platforms..HPPA64_HPUX, IA64_*,   
>>> *_VMS,  ALPHA_*, ARM_*, *_IRIX, *_AIX, MIPS64_*.... but these take  
>>>  back seat  to important fixes in existing platforms.
>>>
>>>
>>>
>>>
>>>
>>>  Fix NT386 to use setjmp3 instead of setjmp so exceptions don't    
>>> skip C __finally blocks. I've just been very lazy here, should    
>>> demonstrate the behavior with a test case, then fix it..
>>>
>>>
>>>
>>>
>>>
>>>  Maybe fix cm3cg so other -g options besides -gstabs works, like    
>>> plain -g, -ggdb, on at least one platform -gstabs isn't supported,  
>>>   leaving nothing, because others cause internal compiler errors,   
>>> like  on HPPA64_HPUX.
>>>
>>>
>>>
>>>
>>>
>>>  Oh, and NT386GNU probably switched back to Win32 threads.    
>>> Otherwise one of the test cases hangs and it doesn't look easy to   
>>>  figure out. I'll do this shortly if I remember.
>>>
>>> But I also wouldn't mind if this platform isn't officially   
>>> released  either (unless someone else wants to support it).
>>>
>>>
>>>
>>>
>>>
>>> Debug why many NT386MINGNU gui apps crash..but also probably just   
>>>  don't release this platform and ok asis.
>>>
>>>
>>>
>>>
>>>
>>>  - Jay
>>>
>>
>>
>>



-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194