<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Hi all:<br>Well you have created a chicken and egg problem/opportunity you can create your theory and move forward.<br>I guess history has shown that big chunks of memory won't make higher speed execution programs, but distributed machines with less memory.<br>The problem is I could set a theory that explains how computers could actually evolve and so on, based on family of computers, you know like Stack Computers, and it turns out that in reality it doesn't work like that, and by the reality it's not true (also I don't consider the "reality" to be that, I don't think tablets and stuff will be takers of tomorrow as today, it's very very useful, as were Micros in their time but can't come back and do that again, Micros are gone). I don't think or hate devices or people who uses it (perhaps I'm old for that) but this things are mostly used to send messages to set

 up quickly a web page (an every day task which I still consider for talented people)<br>Frankly we can say many thing sin theory again but just good people and companies can make a standard way of doing things.<br>Thanks in advance<br><br>--- El <b>mar, 26/6/12, Mika Nystrom <i><mika@async.caltech.edu></i></b> escribió:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>De: Mika Nystrom <mika@async.caltech.edu><br>Asunto: Re: [M3devel] AND (…, 16_ff)… Not serious - or so I hope!<br>Para: "Dirk Muysers" <dmuysers@hotmail.com><br>CC: m3devel@elegosoft.com<br>Fecha: martes, 26 de junio, 2012 20:54<br><br><div class="plainMail">Memory is always potentially a problem!!!!<br><br>One of the main reasons my group was slow at switching from PM3 to CM3<br>was because we were processing node names for chip designs as TEXTs.<br><br>Chip designs tend to be deeply hierarchical and you wind

 up printing a<br>lot of strings such as<br><br>a.b.c.d.e.f.g.h<br><br>to files.<br><br>That's when you run into problems with Text.Cat.<br><br>And memory will always be a problem since you are always designing the<br>next generation of computers with the current generation of computers.<br><br>Also even if memory weren't a problem, speed is always a problem, and<br>speed isn't entirely unrelated to memory.  The Text.Hash I was alluding<br>to earlier hashes eight characters per iteration on a 64-bit machine,<br>as long as characters are 8 bits...  If you go to 16 bits it'll take<br>at least twice as long.  Furthermore if there is more than one way<br>(bit pattern) to represent a single CHAR it becomes difficult to use<br>algorithms that take more than one at a time.<br><br>    Mika<br><br>"Dirk Muysers" writes:<br>>So let them hate it. Memory is not a problem

anymore. > >-------------------------------------------------- >From: "Hendrik Boom" <<a ymailto="mailto:hendrik@topoi.pooq.com" href="/mc/compose?to=hendrik@topoi.pooq.com">hendrik@topoi.pooq.com</a>> >Sent: Tuesday, June 26, 2012 8:19 PM >To: <<a ymailto="mailto:m3devel@elegosoft.com" href="/mc/compose?to=m3devel@elegosoft.com">m3devel@elegosoft.com</a>> >Subject: Re: [M3devel]AND (…, 16_ff)… Not serious - or so I hope! > >> On Tue, Jun 26, 2012 at 12:18:41PM +0200, Dragiša Durić wrote: >>> This piece of code, from TextClass.m3, disturbs me… a lot. >>> >>> If we are to use WIDECHAR, I think we must be a lot more serious than  >>> this. >>> >>> Probably, text pieces are limited to 128 bytes by design, somewhere.  >>> But - whose idea was to "narrow" by ignoring everything except 8 LSB's?

 <br>>>> By mapping set of 2^20 elements to set of 2^8 elements.<br>>>><br>>>> Probably by someone whose mother tongue is fully writeable with ASCII :).<br>>><br>>> I'm told the Japanese hate UTF-8, because it expands  their characters<br>>> from two bytes to three.<br>>><br>>> -- hendrik<br>>> <br></div></blockquote></td></tr></table>