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

[Randy Coleburn]

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090413/9a6dff68/attachment-0002.html>