<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
1) There is little evidence that supporting cvsup has been a bad thing. Maybe it is breaking user threads on poorly designed systems, and may<font style="" color="#000000">be that includes Linux, but it can be fixed while still</font><font style="" color="#000000"> supporting cvsup.</font><font style="" color="#000000"><br>The problems remain to be understood. cvsup and fork-and-do-more-work are very possibly just a red herring that everyone is rat-holing on.<br>We really need to know what is wrong before jumping to conclusions about cvsup and fork-and-do-more-work.<br>Very little has been done or said by anyone (including me!) except for speculation.<br><br></font><font style="" color="#000000">IF IF IF we find cvsup and supporting fork-and-do-more-work are really a problem, then we should consider breaking them.<br>But first we must understand what is going wrong.<br><br><br></font><font style="" color="#000000">2) We absolutely should use C, at least in certain places. Not using C caused major maintenance headaches and bugs in the system.</font><font style="" color="#000000"><br></font><font style="" color="#000000"><br><br></font><span style="font-size: 11pt; font-family: 'Calibri','sans-serif'; color: rgb(31, 73, 125);"><font style="" color="#000000"> > the more library stuff we can code in Modula-3 the better,</font><font style="" color="#000000"><br></font><font style="" color="#000000"><br></font><font style="" color="#000000">Not necessarily.</font><font style="" color="#000000"><br></font><font style="" color="#000000"><br></font><font style="" color="#000000"> > as it gives us the platform independence, as expressed by Mika</font><font style="" color="#000000"><br></font><font style="" color="#000000"><br></font><font style="" color="#000000">Absolutely not. The opposite is the truth. Coding more stuff, <i>certain stuff, </i>in Modula-3 gave us more platform dependence, not less.</font><br><font style="" color="#000000">Language does not buy portability. Library use does. And someone has to implement the libraries. Layered on top of something.</font><br><br></span> - Jay<br><br><br><hr id="stopSpelling">From: rcolebur@SCIRES.COM<br>To: m3devel@elegosoft.com<br>Date: Thu, 21 Apr 2011 18:23:41 -0400<br>Subject: Re: [M3devel] 5.8.6 LINUXLIBC6 breakage, kernel 2.6.23, glibc-2.6-4<br><br>
<meta http-equiv="Content-Type" content="text/html; charset=unicode">
<meta name="Generator" content="Microsoft SafeHTML"><style>
.ExternalClass p.ecxMsoNormal, .ExternalClass li.ecxMsoNormal, .ExternalClass div.ecxMsoNormal
{margin-bottom:.0001pt;font-size:12.0pt;font-family:'Times New Roman','serif';}
.ExternalClass a:link, .ExternalClass span.ecxMsoHyperlink
{color:blue;text-decoration:underline;}
.ExternalClass a:visited, .ExternalClass span.ecxMsoHyperlinkFollowed
{color:purple;text-decoration:underline;}
.ExternalClass p
{margin-right:0in;margin-left:0in;font-size:12.0pt;font-family:'Times New Roman','serif';}
.ExternalClass span.ecxEmailStyle18
{font-family:'Calibri','sans-serif';color:#1F497D;}
.ExternalClass .ecxMsoChpDefault
{font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;}
.ExternalClass div.ecxWordSection1
{page:WordSection1;}
</style><div class="ecxWordSection1"><p class="ecxMsoNormal"><span style="font-size: 11pt; font-family: 'Calibri','sans-serif'; color: rgb(31, 73, 125);">Regarding CVSup, I am probably not the one to ask how important it is because I have never used it.</span></p><p class="ecxMsoNormal"><span style="font-size: 11pt; font-family: 'Calibri','sans-serif'; color: rgb(31, 73, 125);">But, I say don’t break everything else just to make CVSup work.</span></p><p class="ecxMsoNormal"><span style="font-size: 11pt; font-family: 'Calibri','sans-serif'; color: rgb(31, 73, 125);">I want the tenants of the “Green Book” to hold true for CM3 across all platforms.</span></p><p class="ecxMsoNormal"><span style="font-size: 11pt; font-family: 'Calibri','sans-serif'; color: rgb(31, 73, 125);">It would seem to me that CVSup needs to change; it is the “tail wagging the dog” at this point.</span></p><p class="ecxMsoNormal"><span style="font-size: 11pt; font-family: 'Calibri','sans-serif'; color: rgb(31, 73, 125);">Let’s make sure threading is fixed to work reliably again on all platforms; then go back and look at adjusting CVSup.</span></p><p class="ecxMsoNormal"><span style="font-size: 11pt; font-family: 'Calibri','sans-serif'; color: rgb(31, 73, 125);"> </span></p><p class="ecxMsoNormal"><span style="font-size: 11pt; font-family: 'Calibri','sans-serif'; color: rgb(31, 73, 125);">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. </span></p><p class="ecxMsoNormal"><span style="font-size: 11pt; font-family: 'Calibri','sans-serif'; color: rgb(31, 73, 125);"> </span></p><p class="ecxMsoNormal"><span style="font-size: 11pt; font-family: 'Calibri','sans-serif'; color: rgb(31, 73, 125);">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.</span></p><p class="ecxMsoNormal"><span style="font-size: 11pt; font-family: 'Calibri','sans-serif'; color: rgb(31, 73, 125);"> </span></p><p class="ecxMsoNormal"><span style="font-size: 11pt; font-family: 'Calibri','sans-serif'; color: rgb(31, 73, 125);">Regards,</span></p><p class="ecxMsoNormal"><span style="font-size: 11pt; font-family: 'Calibri','sans-serif'; color: rgb(31, 73, 125);">Randy Coleburn</span></p><p class="ecxMsoNormal"><span style="font-size: 11pt; font-family: 'Calibri','sans-serif'; color: rgb(31, 73, 125);"> </span></p><div><div style="border-right: medium none; border-width: 1pt medium medium; border-style: solid none none; border-color: rgb(181, 196, 223) -moz-use-text-color -moz-use-text-color; padding: 3pt 0in 0in;"><p class="ecxMsoNormal" style="margin-left: 0.5in;"><b><span style="font-size: 10pt; font-family: 'Tahoma','sans-serif';">From:</span></b><span style="font-size: 10pt; 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</span></p></div></div><p class="ecxMsoNormal" style="margin-left: 0.5in;"> </p><p class="ecxMsoNormal" style="margin-left: 0.5in;"><span style="font-size: 10pt; 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</span></p></div> </body>
</html>