[M3devel] TextLiteral.MaxBytes again

Jay K jay.krell at cornell.edu
Tue Jun 16 10:43:42 CEST 2015


er..the proposal was old, but nevertheless..




From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu; rodney_bates at lcwb.coop
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] TextLiteral.MaxBytes again
Date: Tue, 16 Jun 2015 08:43:10 +0000




I must have missed this. I commited the "-15" solution. But this proposal sounds better. I need to revisit.. Thank you.




From: hosking at cs.purdue.edu
Date: Thu, 5 Sep 2013 12:05:07 -0400
To: rodney_bates at lcwb.coop
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] TextLiteral.MaxBytes again

Here is a modest proposal that should resolve this issue.
Declare TextLiteral.T to have a minimal buf: ARRAY [0..0] OF Byte;
Then use UNSAFE address arithmetic to access the bytes (TextLiteral.m3 already does the bounds checks explicitly using cnt).
 
Updated TextLiteral.i3 and TextLiteral.m3 attached.
 

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Mobile +1 765 427 5484





On Sep 5, 2013, at 10:42 AM, "Rodney M. Bates"  wrote:

> There is another issue here.  I want TextLiteral.MaxBytes to get a final size
> and not change.  Every time it changes, it creates compatibility problems by
> orphaning any existing pickle files and any compiled programs that write them.
> It changes the fingerprint, so a recently-compiled reading program can't find the
> type in its own list of known types.  This also affects network objects when two
> communicating programs are compiled with different TextLiteral versions.
> 
> MaxBytes' particular contribution to the type doesn't otherwise matter, because it's
> artificial, but it still undermines reading pickles.
> 
> I have been loading up the pickle reading code with hard-coded historical fingerprints
> of various older versions.  But it's a pain to keep doing, tedious to ferret out the
> values, and it still only helps those who constantly download and compile the latest
> CM3.
> 
> At some point, I am thinking of choosing some likely historical TextLiteral.T fingerprint
> and hard-coding the compiler to artificially deliver it , rather than the one computed from
> the version-of-the day of TextLiteral.  But this too would not help those who would
> rather not constantly download the latest, rebuild the compiler, then recompile their
> applications.
> 
> On 09/03/2013 01:02 AM, Jay K wrote:
>> ok, another question:
>> 
>> 
>> CONST
>>  (* DIV BITSIZE should not be here! *)
>>  (* MaxBytes = LAST (INTEGER) DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); *)
>>  MaxBytes = 16_7FFFFFFF DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64);
>> 
>> TYPE
>>   T = RTHooks.TextLiteral;
>> REVEAL
>>   T = TEXT BRANDED "TextLiteral.T" OBJECT
>>     cnt : INTEGER;
>>     buf : ARRAY [0..MaxBytes - 1] OF Byte;
>>   OVERRIDES ...
>> 
>> 
>> T is a reference type.
>> Is there a way to state this with no limit?
>> 
>> 
>> Isn't it already unsafe?
>> You know -- the array is usually smaller and the compiler is only going to check against this large size.
>> 
>> 
>>  - Jay
> 		 	   		   		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150616/a640dbf6/attachment-0002.html>


More information about the M3devel mailing list