<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'><div style="text-align: left;">This is in reference to me.<br><br>I have been making pretty small safe tested changes.<br>But yeah I am impatient and impulsive and do commit<br>small bits, usually well tested.<br><br>I do have more than one copy of the source and at least<br>once recently checked in from the wrong copy.<br><br>And scripts/python is new and presumably as yet unused<br>so I don't see the harm in churn there.<br><br>I've been able to build the system many times under Windows<br>for quite a while, since around whenever scripts/win/*<br>was commited. Over a year ago I think.<br>I think self-buildability is a fairly good test already.<br>Please let me know what the errors are.<br>As for your code itself not working, well I can't promise as much<br>and maybe you can't send it, but if you can provide source<br>with problems I might be able to look into it.<br><br>There was a problem bootstrapping from 5.2.6,<br>since merely things weren't built in the right order, with the int64<br>work, but I fixed that a while ago.<br><br>I haven't really touched the gui stuff.<br>And the various gui apps do look very clunky, a bit hard to<br>figure out how to use, and maybe flaky and unreliable.<br>I guess I should try them on other systems.<br><br>One thing I changed which should be discussed more<br>is the entry code for .dlls. That's what the C/C++ interop<br>question was about. I think where it is "wrong", you will<br>get a link warning, but I didn't check that.<br>It is "only" on the config file, though not sure that's a mitigating<br>factor or not -- how much do people maintain local config<br>files vs. take the checked in one and apply any diffs.<br>The checked in Windows one is now designed to not need<br>any diffs, so then saying people can change it is a bit<br>hypocritical. So I guess I should remove that one line.<br><br>I use mainly Windows but have Mac PowerPC and<br>/maybe/ can commit to using others, like Linux PowerPC<br>and other x86 systems (Solaris x86 anyone? :), Linux, FreeBSD,<br>NetBSD)..gotta be a laptop though :) and VMware/VirtualPC are ok.<br><br>(Nothing seems to compare in producitivity to merely<br>older versions of Visual C++ (5.0, 6.0) and aggressive use of find in files,<br>esp. because of the ease of keyboard use. I've been using "TextWrangler"<br>on the Mac and it is ok but not as good, less keyboard accessible, annoying<br>how each find-in-files opens a new window (even though VC can be annoying<br>for lack of new windows there, usually not)..."kate" on Linux was ok, used<br>it a bit, will try a bit more..)<br><br> - Jay<br></div><br><br><hr id="stopSpelling">> To: rcoleburn@scires.com<br>> Date: Wed, 2 Jan 2008 16:10:42 -0800<br>> From: mika@async.caltech.edu<br>> CC: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] M3 concerns<br>> <br>> <br>> I can happily volunteer FreeBSD 4.x and 5.x (i386) systems, Windows<br>> 2000, and, I believe, Digital Unix 4.0 systems to run nightly<br>> (daily?) builds. Unfortunately I am of course a bit short on Time,<br>> which is probably what's lacking the most, anyhow...<br>> <br>> Mika<br>> <br>> "Randy Coleburn" writes:<br>> >This is a MIME message. If you are reading this text, you may want to <br>> >consider changing to a mail reader or gateway that understands how to <br>> >properly handle MIME multipart messages.<br>> ><br>> >--=__Part103621A2.1__=<br>> >Content-Type: text/plain; charset=US-ASCII<br>> >Content-Transfer-Encoding: quoted-printable<br>> ><br>> >Tony:<br>> >=20<br>> >I'm thinking that with a little work we could set up an automated set of =<br>> >builds and regression tests that would make available a "scoreboard" via a =<br>> >web interface where everyone could see the results. That way, as problems =<br>> >are uncovered, folks could begin working on them.<br>> >=20<br>> >For an example of how all this works, take a look at the scoreboard set up =<br>> >for the ACE+TAO+CIAO projects. An overview is at http://www.dre.vanderbilt=<br>> >.edu/Scoreboard/ . They provide instructions for setting up your own =<br>> >daily build and scoreboard at https://svn.dre.vanderbilt.edu/viewvc/autobui=<br>> >ld/trunk/README?revision=3DHEAD . You can see the scoreboard in operation =<br>> >at http://remedy.nl/ .<br>> >=20<br>> >Regards,<br>> >Randy<br>> ><br>> >>>> Tony Hosking <hosking@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. =20<br>> >> Many of these give the appearance of "thinking out loud" with =20<br>> >> various commits followed by apparent reversals. In many cases the =20<br>> >> m3commit log messages are terse and don't give the rationale behind =20<br>> >> the change.<br>> ><br>> >Yes, I agree. Also, I tend to avoid committing multiple small =20<br>> >patches and rather defer until I have had a chance to test everything =20<br>> >and let it stabilize, before checking in as one single commit. So, =20<br>> >less frequent, coherent commits, are preferable to many smaller, =20<br>> >incoherent commits.<br>> ><br>> >> For those of us in the M3 community who rely upon the stability of =20<br>> >> the libraries and core M3 principles, these types of messages cause =20<br>> >> concern. While I appreciate everyone's efforts to move forward, I =20<br>> >> don't want to abandon the great care that went into formulating =20<br>> >> this language.<br>> ><br>> >Indeed.<br>> ><br>> >> Question: As various people make contributions and changes, is =20<br>> >> there any group of folks who is verifying that the changes don't =20<br>> >> break existing code or core principles? Another idea would be to =20<br>> >> have a series of test batteries that have to be passed before =20<br>> >> changes can be accepted. I know of a number of projects where many =20<br>> >> people contribute, but the contributions have to be vetted by =20<br>> >> passing some tests.<br>> ><br>> >I try to verify that all my code doesn't break existing code (though =20<br>> >I admit GC/thread subsystems can be devilish to completely verify). =20<br>> >We do need to have some sort of procedures in place for deciding what =20<br>> >commits make sense and should go into the CVS head. Tentative work =20<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 =20<br>> >> will inevitably be hampered or compromised by changes made by =20<br>> >> someone who hasn't completely thought out and tested the =20<br>> >> ramifications of those changes.<br>> ><br>> >Agree!<br>> ><br>> >> For example, I've tried to get cm3 working for me on Windows XP =20<br>> >> several times. I still can't seem to get the "current" system to =20<br>> >> build correctly on XP. In the past, I have on occasion gotten the =20<br>> >> "system" to build, but then some of my programs don't work =20<br>> >> correctly when rebuilt using the new cm3. Thus, some changes =20<br>> >> somewhere have "broken" my code, yet all of my code uses the "safe" =20<br>> >> subset of the language. If I go back to my old reliable cm3 =20<br>> >> version 4.1 (the last one put out before Critical Mass, Inc. threw =20<br>> >> in the towel), my code compiles and works, even on Windows XP, even =20<br>> >> using Trestle, FormsVBT, NetObj, cross-platform pickles (e.g., =20<br>> >> pickles shared between Windows & Unix boxes), etc.! Much of my =20<br>> >> code was originally developed under Windows NT, so I think it is a =20<br>> >> tribute to the original language developers that my code and their =20<br>> >> compiler work through various OS version upgrades (NT, 2000, XP) =20<br>> >> and changes to the underlying C/C++ compilers used to build the =20<br>> >> core components.<br>> ><br>> >I thought we were getting closer to stability in this regard, though =20<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>> ><br>> >It would be great to have a set of regression tests run on a regular =20<br>> >basis to ensure that checkins don't break things. What good =20<br>> >candidates do we have? cm3 itself I suppose. Any others? I can =20<br>> >probably devise a couple of thread and GC stress tests pretty =20<br>> >easily. Anyone willing to set up a testing regime? I have machines =20<br>> >that could be used to test on several supported platforms on a =20<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 =20<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@SciRes.com, fax: (770) =20<br>> >> 989-9497<br>> >><br>> >> Quality Policy: "SRC CNE Division is committed to delivering =20<br>> >> continually improving research & engineering excellence that meets =20<br>> >> or exceeds customer requirements."<br>> ><br>> ><br>> ><br>> >--=__Part103621A2.1__=<br>> >Content-Type: text/html; charset=US-ASCII<br>> >Content-Transfer-Encoding: quoted-printable<br>> >Content-Description: HTML<br>> ><br>> ><HTML><HEAD><br>> ><META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-15=<br>> >"><br>> ><META content=3D"MSHTML 6.00.6000.16587" name=3DGENERATOR></HEAD><br>> ><BODY style=3D"MARGIN: 4px 4px 1px; FONT: 10pt Tahoma"><br>> ><DIV>Tony:</DIV><br>> ><DIV> </DIV><br>> ><DIV>I'm thinking that with a little work we could set up an automated set =<br>> >of builds and regression tests that would make available a "scoreboard" =<br>> >via a web interface where everyone could see the results. That way, =<br>> >as problems are uncovered, folks could begin working on them.</DIV><br>> ><DIV> </DIV><br>> ><DIV>For an example of how all this works, take a look at the scoreboard =<br>> >set up for the ACE+TAO+CIAO projects. An overview is at <A href=3D"ht=<br>> >tp://www.dre.vanderbilt.edu/Scoreboard/">http://www.dre.vanderbilt.edu/Scor=<br>> >eboard/</A> . They provide instructions for setting up your own =<br>> >daily build and scoreboard at <A href=3D"https://svn.dre.vanderbilt.edu/vie=<br>> >wvc/autobuild/trunk/README?revision=3DHEAD">https://svn.dre.vanderbilt.edu/=<br>> >viewvc/autobuild/trunk/README?revision=3DHEAD</A> . You can see =<br>> >the scoreboard in operation at <A href=3D"http://remedy.nl/">http://remedy.=<br>> >nl/</A> .</DIV><br>> ><DIV> </DIV><br>> ><DIV>Regards,</DIV><br>> ><DIV>Randy</DIV><br>> ><DIV><BR>>>> Tony Hosking <hosking@cs.purdue.edu> 1/2/2008 =<br>> >1:36 PM >>><BR><BR>On Jan 2, 2008, at 11:31 AM, Randy Coleburn =<br>> >wrote:<BR><BR>> I've seen quite a number of m3commit and m3devel =<br>> >messages lately. <BR>> Many of these give the appearance of =<br>> >"thinking out loud" with <BR>> various commits followed by =<br>> >apparent reversals. In many cases the <BR>> m3commit log =<br>> >messages are terse and don't give the rationale behind <BR>> the =<br>> >change.<BR><BR>Yes, I agree. Also, I tend to avoid committing =<br>> >multiple small <BR>patches and rather defer until I have had a =<br>> >chance to test everything <BR>and let it stabilize, before checking =<br>> >in as one single commit. So, <BR>less frequent, coherent =<br>> >commits, are preferable to many smaller, <BR>incoherent commits.<BR><=<br>> >BR>> For those of us in the M3 community who rely upon the =<br>> >stability of <BR>> the libraries and core M3 principles, these =<br>> >types of messages cause <BR>> concern. While I appreciate =<br>> >everyone's efforts to move forward, I <BR>> don't want to abandon =<br>> >the great care that went into formulating <BR>> this language.<BR>=<br>> ><BR>Indeed.<BR><BR>> Question: As various people make =<br>> >contributions and changes, is <BR>> there any group of folks who =<br>> >is verifying that the changes don't <BR>> break existing code or =<br>> >core principles? Another idea would be to <BR>> have a =<br>> >series of test batteries that have to be passed before <BR>> =<br>> >changes can be accepted. I know of a number of projects where =<br>> >many <BR>> people contribute, but the contributions have to be =<br>> >vetted by <BR>> passing some tests.<BR><BR>I try to verify that =<br>> >all my code doesn't break existing code (though <BR>I admit =<br>> >GC/thread subsystems can be devilish to completely verify). =<br>> ><BR>We do need to have some sort of procedures in place for deciding =<br>> >what <BR>commits make sense and should go into the CVS head. =<br>> >Tentative work <BR>should always be done to a CVS branch until it =<br>> >can be vetted.<BR><BR>> Without these types of controls, I fear =<br>> >that good forward progress <BR>> will inevitably be hampered or =<br>> >compromised by changes made by <BR>> someone who hasn't completely=<br>> > thought out and tested the <BR>> ramifications of those =<br>> >changes.<BR><BR>Agree!<BR><BR>> For example, I've tried to get =<br>> >cm3 working for me on Windows XP <BR>> several times. I =<br>> >still can't seem to get the "current" system to <BR>> build =<br>> >correctly on XP. In the past, I have on occasion gotten the =<br>> ><BR>> "system" to build, but then some of my programs don't work =<br>> ><BR>> correctly when rebuilt using the new cm3. Thus, some =<br>> >changes <BR>> somewhere have "broken" my code, yet all of my code =<br>> >uses the "safe" <BR>> subset of the language. If I go back =<br>> >to my old reliable cm3 <BR>> version 4.1 (the last one put out =<br>> >before Critical Mass, Inc. threw <BR>> in the towel), my code =<br>> >compiles and works, even on Windows XP, even <BR>> using Trestle, =<br>> >FormsVBT, NetObj, cross-platform pickles (e.g., <BR>> pickles =<br>> >shared between Windows & Unix boxes), etc.! Much of my =<br>> ><BR>> code was originally developed under Windows NT, so I think it is =<br>> >a <BR>> tribute to the original language developers that my code =<br>> >and their <BR>> compiler work through various OS version upgrades =<br>> >(NT, 2000, XP) <BR>> and changes to the underlying C/C++ =<br>> >compilers used to build the <BR>> core components.<BR><BR>I =<br>> >thought we were getting closer to stability in this regard, though =<br>> ><BR>I am not a heavy Windows user and have never built CM3 on Windows.<BR><=<br>> >BR>> I would appreciate constructive feedback on this topic.<BR><B=<br>> >R>It would be great to have a set of regression tests run on a regular =<br>> >; <BR>basis to ensure that checkins don't break things. What =<br>> >good <BR>candidates do we have? cm3 itself I suppose. =<br>> >Any others? I can <BR>probably devise a couple of thread and =<br>> >GC stress tests pretty <BR>easily. Anyone willing to set up a =<br>> >testing regime? I have machines <BR>that could be used to test on =<br>> >several supported platforms on a <BR>nightly basis even.<BR><BR>><=<br>> >BR>> Regards,<BR>> Randy Coleburn<BR>><BR>><BR>> Randy C. =<br>> >Coleburn, CISSP<BR>> Senior Systems Engineer, Communications, Networks, =<br>> >& Electronics <BR>> Division (CNE)<BR>> Corporate & =<br>> >Atlanta Information Systems Security Manager (ISSM)<BR>> Scientific =<br>> >Research Corporation<BR>> 2300 Windy Ridge Parkway, Suite 400 South, =<br>> >Atlanta, Georgia 30339<BR>> voice: (770) 989-9464, email: RColeburn@SciR=<br>> >es.com, fax: (770) <BR>> 989-9497<BR>><BR>> Quality =<br>> >Policy: "SRC CNE Division is committed to delivering <BR>> =<br>> >continually improving research & engineering excellence that meets =<br>> >; <BR>> or exceeds customer requirements."<BR><BR><BR></DIV></BODY></HTM=<br>> >L><br>> ><br>> >--=__Part103621A2.1__=--<br><br /><hr />Don't get caught with egg on your face. Play Chicktionary! <a href='http://club.live.com/chicktionary.aspx?icid=chick_wlhmtextlink1_dec' target='_new'>Check it out!</a></body>
</html>