<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Regarding CVSup, I am probably not the one to ask how important it is because I have never used it.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>But, I say don’t break everything else just to make CVSup work.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I want the tenants of the “Green Book” to hold true for CM3 across all platforms.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>It would seem to me that CVSup needs to change; it is the “tail wagging the dog” at this point.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Let’s make sure threading is fixed to work reliably again on all platforms; then go back and look at adjusting CVSup.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Further, I think it safe to say that most of the folks on m3devel have bought into the philosophy and design tenants of Modula-3, as expressed in the “Green Book.” I’m not saying we shouldn’t be open to new ideas or discussion, but I for one don’t want to spend a lot of time here debating the merits of other languages. I want to spend time here trying to ensure the stability, evolution, and continued availability of Modula-3 on as many platforms as possible. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I also believe strongly that all developers should avoid resorting to coding something in C, because Modula-3 is a “systems language”. The more library stuff we can code in Modula-3 the better, as it gives us the platform independence, as expressed by Mika. It is only when using the UNSAFE subset of the language that you should ever run into a situation where an implementation has to be changed to accommodate a different platform. And, then you know exactly where to go for the changes—the UNSAFE module and use of UNSAFE features only. Everything else is completely portable.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Regards,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Randy Coleburn<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='margin-left:.5in'><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> jayk123@hotmail.com [mailto:jayk123@hotmail.com] <b>On Behalf Of </b>Jay K<br><b>Sent:</b> Thursday, April 21, 2011 2:42 PM<br><b>To:</b> Coleburn, Randy; m3devel<br><b>Subject:</b> RE: [M3devel] 5.8.6 LINUXLIBC6 breakage, kernel 2.6.23, glibc-2.6-4<o:p></o:p></span></p></div></div><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>> I concur with Mika !<br>> We need to stick to the design tennants of Modula-3.<br><br>ok...so..is someone volunteering to fix cvsup? Or are we willing to break it?<br>And does this solve any larger problems?<br>ie: are the changes to support cvsup really what broke anything?<br> ok, yes, for now, they have broken user threads.<br><br><br>> You mean that the application needs a global (partial) lock order<br>> for it? Somehow an application that wants to use facilities to<br>> fork-and-do-more-work has to call pthread_atfork with the order<br>> established, or have I misunderstood? That means every library<br>> that has locks has to register them somewhere?<br><br>Yes.<br>Not register the locks per se, but register callbacks.<br>Those callbacks need to acquire/release locks though.<br>Essentially what you said though.<br><br>> Well there are versions of C that don't define threads at all (especially<br>> historical versions of C). A programmer using such a version might legitimately<br>> assume there are no threads except the main program.<br><br><br>Hardly.<br>Threads have been widespread for a long time now.<br>Pretending they don't exist seems kind of dumb.<br><br>> people who want to fork-and-do-more-work are<br>> on their own.<br><br>"on their own" meaning they have an arbitrary unbounded set of problems?<br>We will completely ignore them?<br>Will break cvsup?<br>Is using pthread_atfork really so difficult??<br><br><br>> I also think one of the valuable aspects of Modula-3 is that it defines<br>> a complete systems programming environment already with the facilities in<br>> Thread and Process, and that adding support for more facilities in m3core<br><br><br>Modula-3 is several things. It is a language. It is libraries. Maybe other things.<br>The libraries might might be split into "green book" and others.<br>To what extent should we support "others"?<br>Just the fact that m3core exposes Unix.fork() gets us into "others".<br>Anyway..I think there is this idea of Modula-3 being a closed system.<br>Limit yourself to a smaller set of libraries and practises and ok.<br>Go to far into the world of other libraries and things that work in C and can<br>work in Modula-3, and things start breaking.<br>It seems gray to me, what should work, what the overall approach should be.<br><br><br>> bifurcation of application programs: some programs for "POSIX Modula-3"<br>> and some for "other Modula-3".<br><br>I believe this exists. Do we not have X-Windows apps in Modula-3 and Win32 apps in Modula-3?<br><br><br>> It was definitely a design goal of the<br>> language to provide interfaces that were simple and general enough that<br>> application code would be "write once, run anywhere"---and to do it in a<br><br>You can make a big push in this direction, but you'll never get there.<br>People will always want more libraries. Some they will write brand new in Modula-3, good.<br>Many others will already exist in C and C++ and they will want to reuse.<br><br><br>> it was a point of pride with SRC M3 that no conditional compilation was needed to account for<br>> OS and architecture differences even though the SRC distribution had<br>> been ported to a rather large variety of computers.<br><br><br>They did worse things instead.<br>They had large swaths of duplicated code, per-target, that was almost the same per-target.<br>Sometimes the code was code, sometimes declarations. The declarations were very<br>tedious and error-prone to write and recieved no static checking.<br>They had runtime checks for what the target was -- thus the problem where libm3 was<br>tied to the exact list of targets available.<br><br><br>Conditional compilation can be a good thing.<br><br><br>- Jay<o:p></o:p></span></p></div></body></html>