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

[Olaf Wagner]

If anybody could test Rodney's TEXT changes and provide some
information on the impacts on our applications, that would help a lot.

I also wasn't able to read and understand all the mails about small objects.
(Guessing, I'd say I'd need another day for that :-)
Can anybody summarize?
Has a conclusion been reached and what will be done/implemented?
Is this relevant for the next release, or will it take longer?

Olaf

Quoting Randy Coleburn <rcoleburn at scires.com>:

> Rodney, sorry but I haven't tried your changes.  If your test   
> program is available, I would be glad to compile and run it on   
> Windows to obtain results for that platform.  Just let me know how   
> to obtain/install your TEXT changes and the test program.
>
> I am ok with Olaf's suggestion of starting the release process in May.
>
> Again, I will be glad to help on Windows platforms.  If necessary, I  
>  can also test cygwin on Windows.
>
> If we need to test/build/release on HPUX, I have an old v10 system I  
>  can pull out of storage (note that v10 is an older version of HPUX   
> and not current).
>
> Regards,
> Randy Coleburn
>
>>>> "Rodney M. Bates" <rodney.m.bates at cox.net> 4/13/2009 5:24 PM >>>
> 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.
>
>
>
> 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
>>>
>>
>>
>>
>
>
>
> CONFIDENTIALITY NOTICE:  This email and any attachments are intended  
>  solely for the use of the named recipient(s). This e-mail may   
> contain confidential and/or proprietary information of Scientific   
> Research Corporation.  If you are not a named recipient, you are   
> prohibited from making any use of the information in the email and   
> attachments.  If you believe you have received this email in error,   
> please notify the sender immediately and permanently delete the   
> email, any attachments, and all copies thereof from any drives or   
> storage media and destroy any printouts of the email or attachments.
>
> EXPORT COMPLIANCE NOTICE:  This email and any attachments may   
> contain technical data subject to U.S export restrictions under the   
> International Traffic in Arms Regulations (ITAR) or the Export   
> Administration Regulations (EAR).  Export or transfer of this   
> technical data and/or related information to any foreign person(s)   
> or entity(ies), either within the U.S. or outside of the U.S., may   
> require export authorization by the appropriate U.S. Government   
> agency prior to export or transfer.  In addition, technical data may  
>  not be exported or transferred to certain countries or specified   
> designated nationals identified by U.S. embargo controls without   
> prior export authorization.  By accepting this email and any   
> attachments, all recipients confirm that they understand and will   
> comply with all applicable ITAR, EAR and embargo compliance   
> requirements.
>
>



-- 
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