[M3devel] 5.8.6 LINUXLIBC6 breakage, kernel 2.6.23, glibc-2.6-4

[Jay K]

 > As for the use of C vs. Modula-3, it obvious that you and I have a difference of opinion.
Exchanging Modula-3 for C has tremendously improved the maintainability, portability, correctness, size-in-source, and correctness-by-inspection of the system.
Debuggability has improved as well, though hopefully that will "even out" -- hopefully Modula-3 code will become just as debuggable with stock gdb, and on systems without stabs support.

 - Jay

From: rcolebur at SCIRES.COM
To: m3devel at elegosoft.com
Date: Thu, 21 Apr 2011 23:24:02 -0400
Subject: Re: [M3devel] 5.8.6 LINUXLIBC6 breakage, kernel 2.6.23, glibc-2.6-4



Jay: Re CVSup, I agree that we need to get to the bottom of things as soon as possible.  I’m not advocating we “throw the baby out with the bath water”, but if the “fork-and-do-more” pattern used by CVSup is causing problems, I vote we remove it until those problems can be resolved.  Better to break one app, than a bunch. As for the use of C vs. Modula-3, it obvious that you and I have a difference of opinion. Regards,Randy Coleburn  From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Thursday, April 21, 2011 7:15 PM
To: Coleburn, Randy; m3devel
Subject: RE: [M3devel] 5.8.6 LINUXLIBC6 breakage, kernel 2.6.23, glibc-2.6-4 1) There is little evidence that supporting cvsup has been a bad thing. Maybe it is breaking user threads on poorly designed systems, and maybe that includes Linux, but it can be fixed while still supporting cvsup.
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.
We really need to know what is wrong before jumping to conclusions about cvsup and fork-and-do-more-work.
Very little has been done or said by anyone (including me!) except for speculation.

IF IF IF we find cvsup and supporting fork-and-do-more-work are really a problem, then we should consider breaking them.
But first we must understand what is going wrong.


2) We absolutely should use C, at least in certain places. Not using C caused major maintenance headaches and bugs in the system.


 > the more library stuff we can code in Modula-3 the better,

Not necessarily.

 > as it gives us the platform independence, as expressed by Mika

Absolutely not. The opposite is the truth. Coding more stuff, certain stuff, in Modula-3 gave us more platform dependence, not less.
Language does not buy portability. Library use does. And someone has to implement the libraries. Layered on top of something.

 - Jay

From: rcolebur at SCIRES.COM
To: m3devel at elegosoft.com
Date: Thu, 21 Apr 2011 18:23:41 -0400
Subject: Re: [M3devel] 5.8.6 LINUXLIBC6 breakage, kernel 2.6.23, glibc-2.6-4Regarding CVSup, I am probably not the one to ask how important it is because I have never used it.But, I say don’t break everything else just to make CVSup work.I want the tenants of the “Green Book” to hold true for CM3 across all platforms.It would seem to me that CVSup needs to change; it is the “tail wagging the dog” at this point.Let’s make sure threading is fixed to work reliably again on all platforms; then go back and look at adjusting CVSup. 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.   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. Regards,Randy Coleburn From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Thursday, April 21, 2011 2:42 PM
To: Coleburn, Randy; m3devel
Subject: RE: [M3devel] 5.8.6 LINUXLIBC6 breakage, kernel 2.6.23, glibc-2.6-4 > I concur with Mika !
> We need to stick to the design tennants of Modula-3.

ok...so..is someone volunteering to fix cvsup? Or are we willing to break it?
And does this solve any larger problems?
ie: are the changes to support cvsup really what broke anything?
  ok, yes, for now, they have broken user threads.


> You mean that the application needs a global (partial) lock order
> for it? Somehow an application that wants to use facilities to
> fork-and-do-more-work has to call pthread_atfork with the order
> established, or have I misunderstood? That means every library
> that has locks has to register them somewhere?

Yes.
Not register the locks per se, but register callbacks.
Those callbacks need to acquire/release locks though.
Essentially what you said though.

> Well there are versions of C that don't define threads at all (especially
> historical versions of C). A programmer using such a version might legitimately
> assume there are no threads except the main program.


Hardly.
Threads have been widespread for a long time now.
Pretending they don't exist seems kind of dumb.

> people who want to fork-and-do-more-work are
> on their own.

"on their own" meaning they have an arbitrary unbounded set of problems?
We will completely ignore them?
Will break cvsup?
Is using pthread_atfork really so difficult??


> I also think one of the valuable aspects of Modula-3 is that it defines
> a complete systems programming environment already with the facilities in
> Thread and Process, and that adding support for more facilities in m3core


Modula-3 is several things. It is a language. It is libraries. Maybe other things.
The libraries might might be split into "green book" and others.
To what extent should we support "others"?
Just the fact that m3core exposes Unix.fork() gets us into "others".
Anyway..I think there is this idea of Modula-3 being a closed system.
Limit yourself to a smaller set of libraries and practises and ok.
Go to far into the world of other libraries and things that work in C and can
work in Modula-3, and things start breaking.
It seems gray to me, what should work, what the overall approach should be.


> bifurcation of application programs: some programs for "POSIX Modula-3"
> and some for "other Modula-3".

I believe this exists. Do we not have X-Windows apps in Modula-3 and Win32 apps in Modula-3?


> It was definitely a design goal of the
> language to provide interfaces that were simple and general enough that
> application code would be "write once, run anywhere"---and to do it in a

You can make a big push in this direction, but you'll never get there.
People will always want more libraries. Some they will write brand new in Modula-3, good.
Many others will already exist in C and C++ and they will want to reuse.


> it was a point of pride with SRC M3 that no conditional compilation was needed to account for
> OS and architecture differences even though the SRC distribution had
> been ported to a rather large variety of computers.


They did worse things instead.
They had large swaths of duplicated code, per-target, that was almost the same per-target.
Sometimes the code was code, sometimes declarations. The declarations were very
tedious and error-prone to write and recieved no static checking.
They had runtime checks for what the target was -- thus the problem where libm3 was
tied to the exact list of targets available.


Conditional compilation can be a good thing.


- Jay 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110422/f789550f/attachment-0002.html>