[M3devel] M3 concerns

[Jay]

This is in reference to me.

I have been making pretty small safe tested changes.
But yeah I am impatient and impulsive and do commit
small bits, usually well tested.

I do have more than one copy of the source and at least
once recently checked in from the wrong copy.

And scripts/python is new and presumably as yet unused
so I don't see the harm in churn there.

I've been able to build the system many times under Windows
for quite a while, since around whenever scripts/win/*
was commited. Over a year ago I think.
I think self-buildability is a fairly good test already.
Please let me know what the errors are.
As for your code itself not working, well I can't promise as much
and maybe you can't send it, but if you can provide source
with problems I might be able to look into it.

There was a problem bootstrapping from 5.2.6,
since merely things weren't built in the right order, with the int64
work, but I fixed that a while ago.

I haven't really touched the gui stuff.
And the various gui apps do look very clunky, a bit hard to
figure out how to use, and maybe flaky and unreliable.
I guess I should try them on other systems.

One thing I changed which should be discussed more
is the entry code for .dlls. That's what the C/C++ interop
question was about. I think where it is "wrong", you will
get a link warning, but I didn't check that.
It is "only" on the config file, though not sure that's a mitigating
factor or not -- how much do people maintain local config
files vs. take the checked in one and apply any diffs.
The checked in Windows one is now designed to not need
any diffs, so then saying people can change it is a bit
hypocritical. So I guess I should remove that one line.

I use mainly Windows but have Mac PowerPC and
/maybe/ can commit to using others, like Linux PowerPC
and other x86 systems (Solaris x86 anyone? :), Linux, FreeBSD,
NetBSD)..gotta be a laptop though :) and VMware/VirtualPC are ok.

(Nothing seems to compare in producitivity to merely
older versions of Visual C++ (5.0, 6.0) and aggressive use of find in files,
esp. because of the ease of keyboard use. I've been using "TextWrangler"
on the Mac and it is ok but not as good, less keyboard accessible, annoying
how each find-in-files opens a new window (even though VC can be annoying
for lack of new windows there, usually not)..."kate" on Linux was ok, used
it a bit, will try a bit more..)

 - Jay


> To: rcoleburn at scires.com
> Date: Wed, 2 Jan 2008 16:10:42 -0800
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] M3 concerns
> 
> 
> I can happily volunteer FreeBSD 4.x and 5.x (i386) systems, Windows
> 2000, and, I believe, Digital Unix 4.0 systems to run nightly
> (daily?) builds.  Unfortunately I am of course a bit short on Time,
> which is probably what's lacking the most, anyhow...
> 
>      Mika
> 
> "Randy Coleburn" writes:
> >This is a MIME message. If you are reading this text, you may want to 
> >consider changing to a mail reader or gateway that understands how to 
> >properly handle MIME multipart messages.
> >
> >--=__Part103621A2.1__=
> >Content-Type: text/plain; charset=US-ASCII
> >Content-Transfer-Encoding: quoted-printable
> >
> >Tony:
> >=20
> >I'm thinking that with a little work we could set up an automated set of =
> >builds and regression tests that would make available a "scoreboard" via a =
> >web interface where everyone could see the results.  That way, as problems =
> >are uncovered, folks could begin working on them.
> >=20
> >For an example of how all this works, take a look at the scoreboard set up =
> >for the ACE+TAO+CIAO projects.  An overview is at http://www.dre.vanderbilt=
> >.edu/Scoreboard/ .  They provide instructions for setting up your own =
> >daily build and scoreboard at https://svn.dre.vanderbilt.edu/viewvc/autobui=
> >ld/trunk/README?revision=3DHEAD .  You can see the scoreboard in operation =
> >at http://remedy.nl/ .
> >=20
> >Regards,
> >Randy
> >
> >>>> Tony Hosking <hosking at cs.purdue.edu> 1/2/2008 1:36 PM >>>
> >
> >On Jan 2, 2008, at 11:31 AM, Randy Coleburn wrote:
> >
> >> I've seen quite a number of m3commit and m3devel messages lately.  =20
> >> Many of these give the appearance of "thinking out loud" with =20
> >> various commits followed by apparent reversals.  In many cases the =20
> >> m3commit log messages are terse and don't give the rationale behind =20
> >> the change.
> >
> >Yes, I agree.  Also, I tend to avoid committing multiple small =20
> >patches and rather defer until I have had a chance to test everything =20
> >and let it stabilize, before checking in as one single commit.   So, =20
> >less frequent, coherent commits, are preferable to many smaller, =20
> >incoherent commits.
> >
> >>  For those of us in the M3 community who rely upon the stability of =20
> >> the libraries and core M3 principles, these types of messages cause =20
> >> concern.  While I appreciate everyone's efforts to move forward, I =20
> >> don't want to abandon the great care that went into formulating =20
> >> this language.
> >
> >Indeed.
> >
> >>  Question:  As various people make contributions and changes, is =20
> >> there any group of folks who is verifying that the changes don't =20
> >> break existing code or core principles?  Another idea would be to =20
> >> have a series of test batteries that have to be passed before =20
> >> changes can be accepted.  I know of a number of projects where many =20
> >> people contribute, but the contributions have to be vetted by =20
> >> passing some tests.
> >
> >I try to verify that all my code doesn't break existing code (though =20
> >I admit GC/thread subsystems can be devilish to completely verify).  =20
> >We do need to have some sort of procedures in place for deciding what =20
> >commits make sense and should go into the CVS head.  Tentative work =20
> >should always be done to a CVS branch until it can be vetted.
> >
> >>  Without these types of controls, I fear that good forward progress =20
> >> will inevitably be hampered or compromised by changes made by =20
> >> someone who hasn't completely thought out and tested the =20
> >> ramifications of those changes.
> >
> >Agree!
> >
> >>  For example, I've tried to get cm3 working for me on Windows XP =20
> >> several times.  I still can't seem to get the "current" system to =20
> >> build correctly on XP.  In the past, I have on occasion gotten the =20
> >> "system" to build, but then some of my programs don't work =20
> >> correctly when rebuilt using the new cm3.  Thus, some changes =20
> >> somewhere have "broken" my code, yet all of my code uses the "safe" =20
> >> subset of the language.  If I go back to my old reliable cm3 =20
> >> version 4.1 (the last one put out before Critical Mass, Inc. threw =20
> >> in the towel), my code compiles and works, even on Windows XP, even =20
> >> using Trestle, FormsVBT, NetObj, cross-platform pickles (e.g., =20
> >> pickles shared between Windows & Unix boxes), etc.!  Much of my =20
> >> code was originally developed under Windows NT, so I think it is a =20
> >> tribute to the original language developers that my code and their =20
> >> compiler work through various OS version upgrades (NT, 2000, XP) =20
> >> and changes to the underlying C/C++ compilers used to build the =20
> >> core components.
> >
> >I thought we were getting closer to stability in this regard, though =20
> >I am not a heavy Windows user and have never built CM3 on Windows.
> >
> >>  I would appreciate constructive feedback on this topic.
> >
> >It would be great to have a set of regression tests run on a regular =20
> >basis to ensure that checkins don't break things.  What good =20
> >candidates do we have?  cm3 itself I suppose.  Any others?  I can =20
> >probably devise a couple of thread and GC stress tests pretty =20
> >easily.  Anyone willing to set up a testing regime? I have machines =20
> >that could be used to test on several supported platforms on a =20
> >nightly basis even.
> >
> >>
> >> Regards,
> >> Randy Coleburn
> >>
> >>
> >> Randy C. Coleburn, CISSP
> >> Senior Systems Engineer, Communications, Networks, & Electronics =20
> >> Division (CNE)
> >> Corporate & Atlanta Information Systems Security Manager (ISSM)
> >> Scientific Research Corporation
> >> 2300 Windy Ridge Parkway, Suite 400 South, Atlanta, Georgia 30339
> >> voice: (770) 989-9464, email: RColeburn at SciRes.com, fax: (770) =20
> >> 989-9497
> >>
> >> Quality Policy:  "SRC CNE Division is committed to delivering =20
> >> continually improving research & engineering excellence that meets =20
> >> or exceeds customer requirements."
> >
> >
> >
> >--=__Part103621A2.1__=
> >Content-Type: text/html; charset=US-ASCII
> >Content-Transfer-Encoding: quoted-printable
> >Content-Description: HTML
> >
> ><HTML><HEAD>
> ><META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-15=
> >">
> ><META content=3D"MSHTML 6.00.6000.16587" name=3DGENERATOR></HEAD>
> ><BODY style=3D"MARGIN: 4px 4px 1px; FONT: 10pt Tahoma">
> ><DIV>Tony:</DIV>
> ><DIV> </DIV>
> ><DIV>I'm thinking that with a little work we could set up an automated set =
> >of builds and regression tests that would make available a "scoreboard" =
> >via a web interface where everyone could see the results.  That way, =
> >as problems are uncovered, folks could begin working on them.</DIV>
> ><DIV> </DIV>
> ><DIV>For an example of how all this works, take a look at the scoreboard =
> >set up for the ACE+TAO+CIAO projects.  An overview is at <A href=3D"ht=
> >tp://www.dre.vanderbilt.edu/Scoreboard/">http://www.dre.vanderbilt.edu/Scor=
> >eboard/</A> .  They provide instructions for setting up your own =
> >daily build and scoreboard at <A href=3D"https://svn.dre.vanderbilt.edu/vie=
> >wvc/autobuild/trunk/README?revision=3DHEAD">https://svn.dre.vanderbilt.edu/=
> >viewvc/autobuild/trunk/README?revision=3DHEAD</A> .  You can see =
> >the scoreboard in operation at <A href=3D"http://remedy.nl/">http://remedy.=
> >nl/</A> .</DIV>
> ><DIV> </DIV>
> ><DIV>Regards,</DIV>
> ><DIV>Randy</DIV>
> ><DIV><BR>>>> Tony Hosking <hosking at cs.purdue.edu> 1/2/2008 =
> >1:36 PM >>><BR><BR>On Jan 2, 2008, at 11:31 AM, Randy Coleburn =
> >wrote:<BR><BR>> I've seen quite a number of m3commit and m3devel =
> >messages lately.   <BR>> Many of these give the appearance of =
> >"thinking out loud" with  <BR>> various commits followed by =
> >apparent reversals.  In many cases the  <BR>> m3commit log =
> >messages are terse and don't give the rationale behind  <BR>> the =
> >change.<BR><BR>Yes, I agree.  Also, I tend to avoid committing =
> >multiple small  <BR>patches and rather defer until I have had a =
> >chance to test everything  <BR>and let it stabilize, before checking =
> >in as one single commit.   So,  <BR>less frequent, coherent =
> >commits, are preferable to many smaller,  <BR>incoherent commits.<BR><=
> >BR>>  For those of us in the M3 community who rely upon the =
> >stability of  <BR>> the libraries and core M3 principles, these =
> >types of messages cause  <BR>> concern.  While I appreciate =
> >everyone's efforts to move forward, I  <BR>> don't want to abandon =
> >the great care that went into formulating  <BR>> this language.<BR>=
> ><BR>Indeed.<BR><BR>>  Question:  As various people make =
> >contributions and changes, is  <BR>> there any group of folks who =
> >is verifying that the changes don't  <BR>> break existing code or =
> >core principles?  Another idea would be to  <BR>> have a =
> >series of test batteries that have to be passed before  <BR>> =
> >changes can be accepted.  I know of a number of projects where =
> >many  <BR>> people contribute, but the contributions have to be =
> >vetted by  <BR>> passing some tests.<BR><BR>I try to verify that =
> >all my code doesn't break existing code (though  <BR>I admit =
> >GC/thread subsystems can be devilish to completely verify).   =
> ><BR>We do need to have some sort of procedures in place for deciding =
> >what  <BR>commits make sense and should go into the CVS head.  =
> >Tentative work  <BR>should always be done to a CVS branch until it =
> >can be vetted.<BR><BR>>  Without these types of controls, I fear =
> >that good forward progress  <BR>> will inevitably be hampered or =
> >compromised by changes made by  <BR>> someone who hasn't completely=
> > thought out and tested the  <BR>> ramifications of those =
> >changes.<BR><BR>Agree!<BR><BR>>  For example, I've tried to get =
> >cm3 working for me on Windows XP  <BR>> several times.  I =
> >still can't seem to get the "current" system to  <BR>> build =
> >correctly on XP.  In the past, I have on occasion gotten the  =
> ><BR>> "system" to build, but then some of my programs don't work  =
> ><BR>> correctly when rebuilt using the new cm3.  Thus, some =
> >changes  <BR>> somewhere have "broken" my code, yet all of my code =
> >uses the "safe"  <BR>> subset of the language.  If I go back =
> >to my old reliable cm3  <BR>> version 4.1 (the last one put out =
> >before Critical Mass, Inc. threw  <BR>> in the towel), my code =
> >compiles and works, even on Windows XP, even  <BR>> using Trestle, =
> >FormsVBT, NetObj, cross-platform pickles (e.g.,  <BR>> pickles =
> >shared between Windows & Unix boxes), etc.!  Much of my  =
> ><BR>> code was originally developed under Windows NT, so I think it is =
> >a  <BR>> tribute to the original language developers that my code =
> >and their  <BR>> compiler work through various OS version upgrades =
> >(NT, 2000, XP)  <BR>> and changes to the underlying C/C++ =
> >compilers used to build the  <BR>> core components.<BR><BR>I =
> >thought we were getting closer to stability in this regard, though  =
> ><BR>I am not a heavy Windows user and have never built CM3 on Windows.<BR><=
> >BR>>  I would appreciate constructive feedback on this topic.<BR><B=
> >R>It would be great to have a set of regression tests run on a regular&nbsp=
> >; <BR>basis to ensure that checkins don't break things.  What =
> >good  <BR>candidates do we have?  cm3 itself I suppose.  =
> >Any others?  I can  <BR>probably devise a couple of thread and =
> >GC stress tests pretty  <BR>easily.  Anyone willing to set up a =
> >testing regime? I have machines  <BR>that could be used to test on =
> >several supported platforms on a  <BR>nightly basis even.<BR><BR>><=
> >BR>> Regards,<BR>> Randy Coleburn<BR>><BR>><BR>> Randy C. =
> >Coleburn, CISSP<BR>> Senior Systems Engineer, Communications, Networks, =
> >& Electronics  <BR>> Division (CNE)<BR>> Corporate & =
> >Atlanta Information Systems Security Manager (ISSM)<BR>> Scientific =
> >Research Corporation<BR>> 2300 Windy Ridge Parkway, Suite 400 South, =
> >Atlanta, Georgia 30339<BR>> voice: (770) 989-9464, email: RColeburn at SciR=
> >es.com, fax: (770)  <BR>> 989-9497<BR>><BR>> Quality =
> >Policy:  "SRC CNE Division is committed to delivering  <BR>> =
> >continually improving research & engineering excellence that meets&nbsp=
> >; <BR>> or exceeds customer requirements."<BR><BR><BR></DIV></BODY></HTM=
> >L>
> >
> >--=__Part103621A2.1__=--

_________________________________________________________________
Don't get caught with egg on your face. Play Chicktionary!
http://club.live.com/chicktionary.aspx?icid=chick_wlhmtextlink1_dec
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080103/0492cdd0/attachment-0002.html>