[M3commit] [M3devel] CVS Update: cm3

[Jay]

You guys REALLY don't like C, eh?
It's not a hack, any more so than the tracing that was there, and the existing tracing could be not turned on until "much" later in startup, and the debuggers have no type information, even gdb and I think m3gdb just seem to have void* everywhere, true, I could just dump the memory.
 
Either way.
 
I have a contrary view, in that if something is particularly gnarly such that someone had to write printing code, someone might need it in the future, maybe better to leave it available. However, on the other hand..I write this sort of printing all the time and leaving it all in would really blow up the size of the code base, even while most stuff usually works.
In this case, printing code has been left there all along, an entire module dedicated to reduce-depending printing. Making it work much better, drastically cutting the dependency, seems reasonable. Actually RTIO should probably be rewritten in C instead of lumping the logging into RTLinker. It is a hack in that respect. I found it kind of disturbing how much RTIO reinvents, integer formating, buffering... (and yes I realize I have both such features under my code in stdio)
 
Anyway, I'm not wedded to it.
I wish it were easier to interface C with Modula-3. The type declarations I had to clone should be output by the Modula-3 compiler, and the names I chose should be either the default or easier to get, since they are the names used for Modula-3 code...
 
(I'm not going to jump for a fork. My CVS skills stink. I'll just leave the files uncommited.)
 
 - Jay



> From: hosking at cs.purdue.edu> Date: Sun, 20 Jan 2008 12:02:32 -0500> To: jkrell at elego.de> CC: m3devel at elegosoft.com; m3commit at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > Jay,> > I am particularly disturbed by these changes you just committed > because of the nasty reliance they impose on C in this part of the > run-time library. Part of the beauty of M3 is that its compiler and > libraries are almost entirely programmed in Modula-3. Your change > here has been made to satisfy a need to debug a severely broken run- > time system. Better in such situations to use a standard debugger > rather than pollute the Modula-3 code with nasty reliance on C. If > you need to use such hacks in your debugging please do so in your > privately checked out working directories rather than imposing them > on the rest of us by checking into the main tree. If you need a > debugging source tree in which to play then there is ample provision > using CVS to fork a development branch that is off the main trunk. > Shall I undo these hacks or will you?> > It is important in a collaborative effort such as this to make sure > that we all play nicely in the shared CVS space. In this case I > think you have regressed the code base by adding these C-based hacks.> > Best,> > -- Tony> > On Jan 20, 2008, at 12:01 PM, Jay Krell wrote:> > > CVSROOT: /usr/cvs> > Changes by: jkrell at birch. 08/01/20 12:01:09> >> > Modified files:> > cm3/m3-libs/m3core/src/runtime/common/: RTLinker.i3 RTLinker.m3> > m3makefile> > Added files:> > cm3/m3-libs/m3core/src/runtime/common/: RTLinkerC.c> >> > Log message:> > allow RTLinker's tracing to work when things are more broken> > the default behavior is unchanged, and the behavior with > > @M3tracelinker> > is preserved> > a change in behavior requires modifying RTLinkerC.c and rebuilding> > this also enables more verbose tracing> 
_________________________________________________________________
Need to know the score, the latest news, or you need your Hotmail®-get your "fix".
http://www.msnmobilefix.com/Default.aspx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20080120/71ebae28/attachment-0002.html>