[M3devel] current tinderbox status, broken by me?

[Daniel Alejandro Benavides D.]

In the case of adding procedures not in all the cases is Ok for INTERFACEs as pointed in the SPwM3 (green book, Chapter 6, page 156), also online available from ftp://gatekeeper.research.compaq.com/pub/DEC/SRC/research-reports/SRC-053.pdf " (page 26) "a module exporting a safe INTERFACE must guarantee that 'no programming error' by a safe client of that interface can lead to an unchecked runtime error."
Following the same idea exposed there, is possible to call the RegularFile functions of FilePosix Interface and get runtime errors? which are the guarantees that protect from causing an unchecked runtime error? 
For instance a buggy code could use concurrently threads locking when writing the files concurrently, it will make a mess in the file and so may hole/leaks in memory? (could the file could be an IO port like parallel or serial)?
I would like to hear your comments on that, let me know what else is missing to know the FilePosix is safe.
Thanks in advance,
 
--- El lun, 29/12/08, Jay <jay.krell at cornell.edu> wrote:
De: Jay <jay.krell at cornell.edu>
Asunto: [M3devel] current tinderbox status, broken by me?
Para: "m3devel" <m3devel at elegosoft.com>
Fecha: lunes, 29 diciembre, 2008 9:07

 NEXT    Fatal Error: bad version stamps: SocketPosix.m3
4678          
4679          version stamp mismatch: Compiler.Platform
4680             => SocketPosix.m3
4681             => Compiler.i3  
4682          version stamp mismatch: Compiler.ThisPlatform
4683             => SocketPosix.m3
4684             => Compiler.i3  
4685  NEXT     *** execution of cm3 -build
-DROOT=´/home/m3/work/cm3-ws/birch.elegosoft.com-2008-12-30-01-00-04/cm3´
-DCM3_VERSION_TEXT=´d5.7.0´ -DCM3_VERSION_NUMBER=´050700´
-DCM3_LAST_CHANGED=´2008-03-16´  && cm3 -ship
-DROOT=´/home/m3/work/cm3-ws/birch.elegosoft.com-2008-12-30-01-00-04/cm3´
-DCM3_VERSION_TEXT=´d5.7.0´ -DCM3_VERSION_NUMBER=´050700´
-DCM3_LAST_CHANGED=´2008-03-16´  failed ***
4686          compile return value: 0
4687          [end compile 2008.12.30 02:25:17]
4688          *** COMPILE FAILED
No More Errors
 
 
1)
Is it reasonable to suggest that the compiler output the source to clashing
definitions?
Or is that a bogus naive suggestion?
It is probably legitimate, at least to identify the files in question.
Could be that not enough information is around to identify "what
changed", just some "summary hash".
 

2) Is it really broken?
I did go slightly round and round on this.
I had another new platform defined in one or another file and then when I
backed down and just did one reasonly finished platform, I forgot at first to
cleanup all the debris.
But it certainly worked when I commited.
I'm progressing on the native build, so if it is broken, I expect to run
into it myself.
 
 
3) Is it reasonable to annotate a type with some sort of "relax, additions
are safe" annotation?
Probably not. It's probably too gray and more complicated than that, since
additions in general are not as safe as people thing. Adding to a record --
folks might be copying based on the size and might get back an older smaller
version. Adding to an enum, folks might be switching on it and expect to have
the range covered. Adding a function to an interface though, probably ok. Not
the case here, and perhaps not something the compiler even complains about.
One that that might be eek-out-able is adding to an enum, and such annotated
types, switches on them must have an else clause, and they must not be used for
array indexing?
Eh, maybe just leave it alone.
 
 
Anything else? Is this just basically how it has to be?
OR, how about, can the duplicity be eliminated?
Like, can Compiler.i3 be fully generated by the compiler?
Similarly, Csetjmp.i3 should be generated by the compiler, eh?
 Or at least partly? You know, the size and alignment of the jmp_buf is
recorded in both Csetjmp.i3 and Target.i3. Duplication is generally bad imho


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20081230/238c4888/attachment-0002.html>