<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div apple-content-edited="true"><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><div style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><div>Keep up the good work Jay!</div></span></span></span></span></span></span></span></span></div></span> </div><br><div><div>On 17 Mar 2009, at 13:47, Jay wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><div class="hmmessage" style="font-size: 10pt; font-family: Verdana; ">I'm making the system more safe, not less.<br> <br> <br>The previous methodology was tedious, error prone, and didn't get any sort of checking.<br> <br> <br>Whatever was declared in the *.i3 files was presumed correct.<br> <br> <br>The linkage from the next layer to this layer gets the same amount of checking as it used.<br> <br> <br>The link you point to shows people fixing things the same way as I am making them.<br> <br> <br>unix/*.i3 must use <*EXTERNAL*> to declare C functions.<br>That is what it did. That is what it does.<br>Extend this out slightly to m3core/libm3.<br> Same thing.<br>The difference is whether or not those C functions are implemented right there, once, plain to see that they match the <*EXTERNAL*> declarations, or whether they are in a per-platform /usr/include and source tree somewhere, with tedious and error prone and per-platform verification as to if they are correct. As well as copy/pasting where there the "API" might be a macro.<br> <br> <br>Really, I am making the system more safe, not less.<br>There is no loss in checking but there is more obvious correctness by human inspection in what must be unsafe, one way or another.<br> <br> <br>The result is also more portable.<br> <br> <br> - Jay<br> <br><hr id="stopSpelling">Date: Mon, 16 Mar 2009 17:14:35 -0700<br>From:<span class="Apple-converted-space"> </span><a href="mailto:dabenavidesd@yahoo.es">dabenavidesd@yahoo.es</a><br>To:<span class="Apple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a>;<span class="Apple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>CC:<span class="Apple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>Subject: Re: [M3devel] recent problems?<br><br><table cellspacing="0" cellpadding="0" border="0"><tbody><tr><td valign="top">Hi all:<br>well, I know more about the kind of work done recently, which I can not just say is unsafe, but putting a layer of C code that obviously is dependent of each Linux/Unix, I guess in the past this is not always true, but having each Linux it's own headers and different implementations makes more unstable the system.<br>Besides the type checking made by C Compiler is not checked at link time, in contrast of Modula-3 that type checks whenever interfaces are changed and checks on link time.<br>So if you put change in your C code doesn't mean that Modula-3 will catch common silly but common true errors, like buffer overflows that if not checked at run time will crash (almost always) at runtime of a safe program, and it will not be safe (hidden code is beyond the Modula-3 compiler).<br>I strongly support simplifying and factoring as much as possible, but try to use what is there in Modula-3, not re-implementing in another Language if possible at all. I know but even more, the idea of having linking with C code on the kernel system calls allows to protect from so called side effects of Kernel code. Memory protection is exhausted here.<br>But when using true library user space system calls, this puts in a dangerous side the untrusted code. Here I reclaim again not using more that true system calls. I see that this started to be harder with AMD64 or x86_64 current platforms, so further development may be needed here see<span class="Apple-converted-space"> </span><a href="http://edoofus.blogspot.com/2008/08/interesting-bug-unbreaking-cvsupamd64.html">http://edoofus.blogspot.com/2008/08/interesting-bug-unbreaking-cvsupamd64.html</a><span class="Apple-converted-space"> </span>about ezm3 related problems, is this supposed to be handled in Cm3 like the same they did?<br>Jay and all seem to do the better job they can, but I don't want to miss the opportunity to say this if I may. I will tell you later more about the type system If this it is useful to be said.<br><br>Thanks in advance<br><br>--- El<span class="Apple-converted-space"> </span><b>lun, 16/3/09, Jay<span class="Apple-converted-space"> </span><i><<a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a>></i></b><span class="Apple-converted-space"> </span>escribió:<br><blockquote style="padding-left: 5px; margin-left: 5px; ">De: Jay <<a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a>><br>Asunto: Re: [M3devel] recent problems?<br>Para: "Tony" <<a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a>><br>CC: "m3devel" <<a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a>><br>Fecha: lunes, 16 marzo, 2009 3:55<br><br><pre>It's ok on LINUXLIBC6 with the "new headers" but<br>I believe PPC_DARWIN problem caused by them so <br>backed out pending debugging.<br>This one looks easy to solve, though my time<br>is scarser next week or two.<br> <br>I should have maybe considered:<br> "new headers" used on a number of Linux systems already <br> but no Darwin systems yet <br> <br> - Jay<br><br><br>----------------------------------------<br>> From: <a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>> To: <a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>> Date: Tue, 17 Mar 2009 01:54:34 +1100<br>> CC:
<a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>> Subject: Re: [M3devel] recent problems?<br>><br>> This is worrying as it seems some level of instability has been<br>> introduced by recent changes. mentor used to be fine.<br>><br>> On 17 Mar 2009, at 00:16, Jay wrote:<br>><br>>><br>>> mklib seems ok now, having started over with a new checkout, new<br>>> build.<br>>> Strange considering what I had already tried, this problem had been<br>>> plaguing me over a week.<br>>><br>>><br>>> stubgen doesn't hang with 1.5, will try 1.7 again/later.<br>>><br>>><br>>> But formsedit still crashes during startup intermittently,<br>>> and Cygwin X apps hang at startup.<br>>> ugh.<br>>> I know, I probably caused whatever problem..<br>>><br>>><br>>> - Jay<br>>><br>>><br>>><br>>> ----------------------------------------<br>>>> From:
<a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>>>> To: <a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>>>> CC: <a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>>>> Subject: RE: [M3devel] recent problems?<br>>>> Date: Mon, 16 Mar 2009 08:57:40 +0000<br>>>><br>>>><br>>>> Thanks.<br>>>><br>>>><br>>>> Here is another one.<br>>>> I found this testing moving PPC_DARWIN to "my headers".<br>>>> formsedit crashes during startup roughly more than<br>>>> half the times I start up, but not every time.<br>>>> The stack is always the same.<br>>>> I'll test it without my change.<br>>>> I think it'll happen either way, but I'll see.<br>>>> Yes, it recurs without my change, though I double<br>>>> check that my change is really undone.<br>>>> I'll have to dig into this.<br>>>><br>>>><br>>>> How does one get the code from CVS corresponding to a
date?<br>>>> cvs upd -D ?<br>>>> I'll try that or something, see if I can find when things<br>worked.<br>>>><br>>>><br>>>> I should also be able to try the mklib crashing scenario<br>>>> on other platforms. It normally doesn't run on other<br>platforms.<br>>>><br>>>><br>>>> stubgen..if I'm ambitious, I can run in a loop on another<br>platform.<br>>>> But I think just moving Cygwin off of pthreads will<br>"fix" it<br>>>> and provide a cleaner base (not due to pthreads, but the Cygwin<br>>>> stuff).<br>>>><br>>>><br>>>> Program received signal EXC_BAD_ACCESS, Could not access memory.<br>>>> Reason: KERN_PROTECTION_FAILURE at address: 0x00000004<br>>>> [Switching to process 19583 thread 0x2643]<br>>>> 0x0031798c in ScrollerVBTClass__PaintViewWithShadows<br>>>> (M3_Ao3CED_v=0x1f1eef4) at
../src/lego/POSIX/Sc<br>>>> rollerVBTClass.m3:325<br>>>> 325 VBT.PaintTint(v, r, v.shadow.bg);<br>>>> (gdb) bt<br>>>> #0 0x0031798c in ScrollerVBTClass__PaintViewWithShadows<br>>>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSI<br>>>> X/ScrollerVBTClass.m3:325<br>>>> #1 0x0031766c in ScrollerVBTClass__PaintView<br>>>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/ScrollerV<br>>>> BTClass.m3:292<br>>>> #2 0x0031a460 in ScrollerVBTClass__Repaint (M3_Ao3CED_v=0x1f1eef4,<br>>>> M3_A0Kbc5_rgn=0xf0284778) at ../<br>>>> src/lego/POSIX/ScrollerVBTClass.m3:693<br>>>> #3 0x0031a590 in ScrollerVBTClass__Redisplay<br>>>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/ScrollerV<br>>>> BTClass.m3:706<br>>>> #4 0x005c2870 in VBTClass__Redisplay (M3_BFdKo9_v=0x1f1eef4) at<br>../<br>>>> src/vbt/VBTClass.m3:367<br>>>>
#5 0x005cf1c0 in VBTRep__Redisplay () at ../src/vbt/VBTRep.m3:652<br>>>> #6 0x005ce59c in VBTRep__UncoverRedisplay () at ../src/vbt/<br>>>> VBTRep.m3:601<br>>>> #7 0x005ce724 in VBTRep__RdApply (M3_EMTrVz_self=0x1d554c8) at ../<br>>>> src/vbt/VBTRep.m3:606<br>>>> #8 0x0132ff88 in ThreadPThread__RunThread (M3_ChNkUD_me=0x1e23940)<br>>>> at ../src/thread/PTHREAD/ThreadP<br>>>> Thread.m3:531<br>>>> #9 0x0132fb58 in ThreadPThread__ThreadBase<br>>>> (M3_AJWxb1_param=0x1e23940) at ../src/thread/PTHREAD/Thr<br>>>> eadPThread.m3:508<br>>>> #10 0x9002b908 in _pthread_body ()<br>>>> (gdb)<br>>>><br>>>><br>>>><br>>>> - Jay<br>>>><br>>>><br>>>><br>>>> ----------------------------------------<br>>>>> From: <a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>>>>> To:
<a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>>>>> Date: Mon, 16 Mar 2009 08:10:05 +1100<br>>>>> CC: <a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>>>>> Subject: Re: [M3devel] recent problems?<br>>>>><br>>>>> You might have structure sizes wrong and your stack will get<br>shifted<br>>>>> around as the command line changes length. You get some data<br>in a<br>>>>> structure wrong and then hit the wrong stack org and you might<br>see<br>>>>> problems like this.<br>>>>><br>>>>> I am not running things totally off of the head, so if the<br>problem<br>>>>> was<br>>>>> introduced recently it might only now be seen.<br>>>>><br>>>>> On 16 Mar 2009, at 06:15, Jay wrote:<br>>>>><br>>>>>><br>>>>>> I'm seeing some problems lately. Maybe it is just me.<br>>>>>> Some of them I've had over
a week (ie: before my<br>(most) recent<br>>>>>> changes),<br>>>>>> some of them even if recently appeared I verified without<br>my (most)<br>>>>>> recent changes.<br>>>>>><br>>>>>> On Cygwin 1.5, mklib always crashes. I haven't been<br>able to debug<br>>>>>> it.<br>>>>>> This has been over a week.<br>>>>>> I've had to stop using Cygwin for Modula-3 development<br>on this<br>>>>>> machine.<br>>>>>> I have a good repro but hadn't had luck yet debugging<br>it.<br>>>>>> Basically if I shorten the mklib command line (in the<br>response<br>>>>>> file) substantially, no crash.<br>>>>>> There is a cut off somewhere.<br>>>>>><br>>>>>> On Cygwin 1.7 machine, stubgen in obliqparse usually but<br>not always<br>>>>>>
hangs.<br>>>>>> It hangs nowhere else.<br>>>>>> This I verified occured without my recent changes.<br>>>>>> I only just in the past few days tried Cygwin 1.7.<br>>>>>> mklib works fine here.<br>>>>>> Of course since this is somewhat intermittent, maybe it<br>isn't a new<br>>>>>> problem.<br>>>>>><br>>>>>> I've only tried Cygwin 1.5 and 1.7 on one machine<br>each, separate<br>>>>>> machines,<br>>>>>> though they do coexist ok on one machine.<br>>>>>> 1.7 seemed much faster (on an unimpressive machine),<br>though 1.7<br>>>>>> binares<br>>>>>> apparently don't run on 1.5 -- at least not if they<br>use assert().<br>>>>>> 1.7 is a recent past or future release, a long time in the<br>works,<br>>>>>> drops Win9x support, lots of good
sounding changes.<br>>>>>><br>>>>>> I should run m3tests more, maybe they will reveal the<br>crash or the<br>>>>>> hang as well.<br>>>>>><br>>>>>> On LINUXLIBC6 on one machine stubgen was crashing at least<br>in one<br>>>>>> directory.<br>>>>>> But I think this stopped happening.<br>>>>>><br>>>>>> Cygwin being broken pushes me to other platforms more,<br>probably a<br>>>>>> good thing.<br>>>>>> I'm loathe to debug the hang. When it occurs I<br>can't see any stacks<br>>>>>> in gdb. I can see in strace..<br>>>>>> I think we are waiting for all the threads to suspend<br>themselves.<br>>>>>> I'll probably try moving back to Win32 threads and see<br>if it clears<br>>>>>> up.<br>>>>>> I know that's not
great.<br>>>>>> There isn't a clear implied question and I know I<br>should/need to<br>>>>>> look into these,<br>>>>>> but I also thought I shouldn't keep this to myself. I<br>also<br>>>>>> understand the philosophy<br>>>>>> of stopping changes when there are problems, to stop<br>further<br>>>>>> damage, but, of course,<br>>>>>> I'm very confident in my changes (always..), have been<br>testing them<br>>>>>> on other platforms,<br>>>>>> and looking them over extra extra since I know of these<br>other<br>>>>>> problems.<br>>>>>><br>>>>>> I'm not sure any problem on Cygwin is worrisome<br>really.<br>>>>>> I think the underlying code is kind of gnarly and I<br>don't think<br>>>>>> anyone uses this platform, though people asked for
it.<br>>>>>> But I did have a crash on LINUXLIBC6.<br>>>>>><br>>>>>> - Jay<br>>>>><br>></pre></blockquote></td></tr></tbody></table><br></div></span><br class="Apple-interchange-newline"></blockquote></div><br></body></html>