[M3devel] [M3commit] CVS Update: cm3

[Tony Hosking]

On Jan 20, 2008, at 12:24 PM, Jay wrote:

> 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.

The debuggers do have most type information on POSIX platforms.  It's  
not that I don't like C, just that your use of it here was a little  
gratuitous.  For this sort of low-level debugging memory dumps are  
your friend -- if you want to read something a little more symbolic  
put in a temporary hack in your private space.  Just don't make the  
rest of us swallow it.

Jay, I'm not trying to be hypercritical, just trying to preserve some  
cleanliness in the core library code.  Please keep up your great work!

Best regards,

Tony

>
>
> 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". Check it out.