<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-15">
<META content="MSHTML 6.00.6000.16809" name=GENERATOR></HEAD>
<BODY style="MARGIN: 4px 4px 1px">
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>I am ok with Olaf's suggestion of starting the release process in May.</DIV>
<DIV> </DIV>
<DIV>Again, I will be glad to help on Windows platforms. If necessary, I can also test cygwin on Windows. </DIV>
<DIV> </DIV>
<DIV>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).</DIV>
<DIV> </DIV>
<DIV>Regards,</DIV>
<DIV>Randy Coleburn<BR><BR>>>> "Rodney M. Bates" <rodney.m.bates@cox.net> 4/13/2009 5:24 PM >>><BR>Any opinions about the TEXT branch? Anybody tried it? To summarize:<BR><BR>- I have tested it extensively on LINUXLIBC6, with a large random<BR> test program and two successive rebuilds of CM3.<BR><BR>- It makes no changes in data structure, neither to static declarations<BR> nor to invariants. Thus it creates no compatibility problems with <BR>existing<BR> pickles, etc.<BR><BR>- It slows down concatenation, but more than makes it up in other<BR> string accessing operations, if the numbers of concatenations and<BR> accessing operations are equal.<BR><BR>- It cuts down on tree depth and even more or recursion depth<BR> (which implies needed stack space.)<BR><BR>- This effect is dramatic when strings are built by "linear" concatenations,<BR> i.e., strictly left-to-right, or vice versa. Gains are moderate when<BR> concatenations are random.<BR><BR>- It allocates a lot more storage, but abandons a lot more garbage,<BR> retaining somewhat more space when lots of old strings are retained<BR> along with newly-built ones. It probably retains less when operand<BR> strings of concatenations are not kept, but I haven't measured that.<BR><BR>- Strategies are partial rebalancing of concatenation trees, flattening<BR> of short concatenations, elimination of a lot of tail-recursion, and<BR> recursing on the shorter side.<BR><BR><BR><BR>Olaf Wagner wrote:<BR>> Well, that's a quite long list; but many things are bug fixes anyway,<BR>> and wouldn't be affected by a code freeze, while others are already<BR>> finished (as integrating CVSup, as I understand).<BR>><BR>> The only thing we should not do is introduce new platforms while<BR>> trying to get the system stable. We should concentrate on installation<BR>> support and bug fixing.<BR>><BR>> I'd suggest to start the release process in about two weeks at the<BR>> start of May. That should give everybody enough time to either finish<BR>> their ongoing work that shall make it into the release or decide to<BR>> postpone it ;-)<BR>><BR>> Any objections?<BR>><BR>> Olaf<BR>><BR>> Quoting Jay <jay.krell@cornell.edu>:<BR>><BR>>><BR>>> > > o When should we start? I.e. wha changes would you like to complete<BR>>> > > before we start the release process?<BR>>><BR>>><BR>>><BR>>><BR>>> I'd like to see the formsvbt crash debugged and fixed, unless I'm <BR>>> the only one seeing it.<BR>>><BR>>> I only see it on Solaris and PPC_DARWIN but haven't tried "everything".<BR>>><BR>>> I'll try to get this.<BR>>><BR>>><BR>>><BR>>><BR>>><BR>>> I'd also like to see:<BR>>><BR>>><BR>>><BR>>><BR>>><BR>>> FreeBSD/x86 switched to the new Unix/*.i3 files. I'll do this.<BR>>><BR>>> Maybe also I386_DARWIN, AMD64_DARWIN, but I don't have the hardware.<BR>>><BR>>><BR>>><BR>>><BR>>><BR>>> $ORIGIN/LD_LIBRARY_PATH resolved a bit further, probably very <BR>>> little work (I'll do this).<BR>>><BR>>> Basically just 1) put buildlocal back how it was 2) push it across <BR>>> more platforms e.g. I think FreeBSD/x86 is the main one missing, <BR>>> but I'll get to it.<BR>>><BR>>><BR>>><BR>>><BR>>><BR>>> cvsup building and in "std" (I'll do this, probably very little <BR>>> left here really.<BR>>><BR>>><BR>>><BR>>><BR>>><BR>>> -- beyond this, not required for release --<BR>>><BR>>><BR>>><BR>>><BR>>><BR>>> Maybe more AMD64 releases, e.g. NetBSD and Solaris. (If I get to it).<BR>>><BR>>> (could be "mingw64" is good enough to try AMD64_NT now).<BR>>><BR>>><BR>>><BR>>><BR>>><BR>>> Maybe update gmp/mpfr to fix the "maintainer" problem. (not likely <BR>>> by me)<BR>>><BR>>><BR>>><BR>>><BR>>><BR>>> Maybe more new/resuscitated platforms..HPPA64_HPUX, IA64_*, *_VMS, <BR>>> ALPHA_*, ARM_*, *_IRIX, *_AIX, MIPS64_*.... but these take back <BR>>> seat to important fixes in existing platforms.<BR>>><BR>>><BR>>><BR>>><BR>>><BR>>> Fix NT386 to use setjmp3 instead of setjmp so exceptions don't <BR>>> skip C __finally blocks. I've just been very lazy here, should <BR>>> demonstrate the behavior with a test case, then fix it..<BR>>><BR>>><BR>>><BR>>><BR>>><BR>>> Maybe fix cm3cg so other -g options besides -gstabs works, like <BR>>> plain -g, -ggdb, on at least one platform -gstabs isn't supported, <BR>>> leaving nothing, because others cause internal compiler errors, like <BR>>> on HPPA64_HPUX.<BR>>><BR>>><BR>>><BR>>><BR>>><BR>>> Oh, and NT386GNU probably switched back to Win32 threads. <BR>>> Otherwise one of the test cases hangs and it doesn't look easy to <BR>>> figure out. I'll do this shortly if I remember.<BR>>><BR>>> But I also wouldn't mind if this platform isn't officially released <BR>>> either (unless someone else wants to support it).<BR>>><BR>>><BR>>><BR>>><BR>>><BR>>> Debug why many NT386MINGNU gui apps crash..but also probably just <BR>>> don't release this platform and ok asis.<BR>>><BR>>><BR>>><BR>>><BR>>><BR>>> - Jay<BR>>><BR>><BR>><BR>><BR><BR><BR></DIV></BODY></HTML>