<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Hi all:<br>even if we have non-faulty implementation the problem remains the same, the coding standard is non-uniformly used, but instead use old TEXT with C cross-compiled version seemed the way to win at least in Win flavors. I give that point to Jay, he is absolutely right,  I fear that if we don't do this correctly,  we could loss in C compiler intrinsics.<br>Perhaps before all this work continues we need to port this better we won't do real big advances more quickly.<br>Thanks in advance<br><br>--- El <b>mar, 26/6/12, Coleburn, Randy <i><rcolebur@SCIRES.COM></i></b> escribió:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>De: Coleburn, Randy <rcolebur@SCIRES.COM><br>Asunto: Re: [M3devel] EXT Re:  EXT Re:  AND (., 16_ff). Not serious - or so I hope!<br>Para: "m3devel@elegosoft.com"
 <m3devel@elegosoft.com><br>Fecha: martes, 26 de junio, 2012 18:44<br><br><div class="plainMail">I am willing to run tests on platforms that I have, mostly Windows flavors.<br>--Randy Coleburn<br><br>-----Original Message-----<br>From: Rodney M. Bates [mailto:<a ymailto="mailto:rodney_bates@lcwb.coop" href="/mc/compose?to=rodney_bates@lcwb.coop">rodney_bates@lcwb.coop</a>] <br>Sent: Tuesday, June 26, 2012 5:42 PM<br>To: <a ymailto="mailto:m3devel@elegosoft.com" href="/mc/compose?to=m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>Subject: EXT Re: [M3devel] EXT Re: AND (., 16_ff). Not serious - or so I hope!<br><br><br><br>On 06/26/2012 03:22 PM, Coleburn, Randy wrote:<br>> I seem to recall that Rodney did some work a while back relating to TEXT.<br>><br>> Rodney, can you weigh in on some of this?<br>><br><br>I wrote a modified implementation of cm3 TEXT.  It uses the same data structure and invariants, so any internal values it
 creates are useable by any existing code that imports the various revelations.  It improves performance problems deriving from Cat operations' building trees that actually degenerate into linear lists (fairly likely, as it happens whenever a string is constructed by a left-to-right or right-to-left series of concatenations.)  As usual, some operations on some values are slower, but it seems to be a gain overall.<br><br>I have an extensive test driver and statistics gatherer, which shows good results.  However, only tested it on LINUXLIBC6 and AMD64_LINUX, machines I have.  Olaf was not comfortable that it was fully tested this way, and I have never taken the time to figure out how to run tests on targets I don't have.<br><br>I think it is a significant improvement over the stock cm3 TEXT implementation.<br>Whether it is as good as just going back to the pm3 implementation is not so clear.<br><br>All three implementations correctly
 (except for possible bugs--none known at present, AFAIK) implement the language's abstract Text interface, and code that only uses Text would see only performance differences.<br><br><br>> --Randy Coleburn<br>><br>> *From:*Dragiša Durić [mailto:<a ymailto="mailto:dragisha@m3w.org" href="/mc/compose?to=dragisha@m3w.org">dragisha@m3w.org</a>]<br>> *Sent:* Tuesday, June 26, 2012 12:46 PM<br>> *To:* Jay<br>> *Cc:* m3devel<br>> *Subject:* EXT Re: [M3devel] AND (., 16_ff). Not serious - or so I hope!<br>><br>> You had idea in other message. Store length!<br>><br>> Another idea - store partial list of indices to character locations. So whatever one does, that list can be used/expanded. Whatever storage issues this makes, they are probably minor as compared to 32bit WIDECHAR for all idea.<br>><br>> Mika had performance problems with cm3 TEXT. I hope he follows and cares to refresh us on those issues?!<br>><br>> On
 Jun 26, 2012, at 6:34 PM, Jay wrote:<br>><br>><br>><br>> I'm torn on that. We'd have to consider ramifications like Text.Length vs buffer size requirements/expectations.<br>><br>> Is TEXT & its use abstracted enough to have been widened? Should we put it back and introduce WIDETEXT? That is essentially what C and C++ do. They are inconvenient for existing code but simple predictable make sense. Contrast with weird hybrid systems like Perl & Python for which I just can't get through the documentation and understand and predict how they work..<br>><br></div></blockquote></td></tr></table>