<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-15">
<META content="MSHTML 6.00.6000.16587" name=GENERATOR></HEAD>
<BODY style="MARGIN: 4px 4px 1px; FONT: 10pt Tahoma">
<DIV>Given the current situation, I'm not sure that moderated commits are practical. I think the best route is to get enough tests in place so that all developers can run a regression test suite BEFORE committing changes. Having an automated scoreboard would also help point out where things are broken and need fixing so that folks can volunteer to help.</DIV>
<DIV> </DIV>
<DIV><STRONG>I'll try to find time again this weekend to do a build of cm3 on Windows XP again.</STRONG></DIV>
<DIV> </DIV>
<DIV>If one goes to the website, there seems to be several choices for getting started, so <STRONG><U>I need some advice on the best way to move forward</U></STRONG>.</DIV>
<DIV>1. Get current sources from head branch and try to build from scratch (after first installing free Microsoft Visual C/C++ tools).</DIV>
<DIV>2. Get an older variant (5.2.6, 4.1, etc.) and try to use it to build the new current sources from CVS.</DIV>
<DIV>3. Get Jay's d5.5.0 min Win32 and use it to build the current sources from CVS.</DIV>
<DIV>4. ??</DIV>
<DIV> </DIV>
<DIV>I know that there are some scripts that have been built to help in building things. One thing that would be helpful I think is to have a <U>text file</U> that lists the <U>correct build sequence order</U> for <U>all packages</U> in the repository. I know that some packages may not build on every platform, but if we keep this text file up-to-date, it would help folks as they work on scripts, etc. </DIV>
<DIV> </DIV>
<DIV>Also, I seem to recall that in the past that for some of the core packages, you had to build these twice in the process of getting everything up and running. Again, these facts need to be made very obvious so folks don't go down a wrong path.</DIV>
<DIV> </DIV>
<DIV>Once I get started on a path (1..4 above), I also need to know which of the current scripts to use in building on Windows XP to get the best results.</DIV>
<DIV> </DIV>
<DIV>I love the language and have been a zealous proponent of it for a long time, but we've got to make it easier for folks to get started with Modula-3. I will carefully document the steps I take in getting the system built on Windows so we can make this available to everyone.</DIV>
<DIV> </DIV>
<DIV>As for Jay's comment that he hasn't heard of anyone getting a "broken" version, please understand that I am not directing my comments at any one person, but rather to the system of "checks and balances" that need to be put in place for everyone. </DIV>
<DIV> </DIV>
<DIV>The last time I was able to get the sources and build on Windows was v5.26. That version didn't work correctly with some of my programs and I reported the problems to Olaf et al. The last time I checked out the sources and tried to build 5.40, I wound up with compiler errors. I recall some of these were related to LONGINT and some were related to the garbage collector. So yes, there was a situation where I checked out sources that represented a "broken" version in that it would not build. </DIV>
<DIV> </DIV>
<DIV>Thus, there are at least two types of "broken": (1) the system sources can't be built correctly, (2) the newly built system causes previously working code to misbehave when recompiled with the new system. Broken #1 should never be allowed to occur for the core system. From what Olaf said, the rule seems to be to keep broken #1 stuff in a branch and only merge it back into the main line when the broken state is resolved. Broken #2 should be avoided using regression test suites. </DIV>
<DIV> </DIV>
<DIV>The package status page at <A href="http://modula3.elegosoft.com/cm3/package-status.html">http://modula3.elegosoft.com/cm3/package-status.html</A> is headed up by the title CM3 v5.1. Is this page up-to-date? It would be helpful to know where we stand wrt each package on each supported platform relative to the current source tree. Again, I think an automated scoreboard could make this possible.</DIV>
<DIV> </DIV>
<DIV><STRONG>Sorry to ramble on so much in this post. <U>My main interest is in getting the current sources built and running on Windows XP.</U> As soon as I am successful, I will run tests using my code base. I have a number of programs that were built using cm3 v4.1 that are still in use. These use a lot of features, including pickles, netobj, trestle, etc. So, my tests should help uncover Broken #2 problems on Windows.</STRONG></DIV>
<DIV> </DIV>
<DIV>Finally, once I get a working cm3 system on Windows, I'll provide the new cm3-IDE (aka Reactor) package. </DIV>
<DIV> </DIV>
<DIV>Regards,</DIV>
<DIV>Randy<BR><BR>>>> Jay <jayk123@hotmail.com> 1/4/2008 8:04 PM >>><BR>I oppose most red tape.<BR> <BR>However branching can be good, as long as there are frequent merges (between once a week and once a month..well, those timelines are based on other contexts, in this context, I don't know) and automated testing/buildmonkeys/tinderboxes. That is, if I'm in a ghetto branch, I loose both the pressure not to break things, because few/nobody else is in the branch, and the feedback loop of hearing that I've broken someone, so automation would be nice to replace that.<BR> <BR>I am not experienced with CVS though. I don't know how to setup or merge branches. Even browsing history I find painful, in one branch.<BR><BR>Perforce I am quite familiar with.<BR>Subversion I learned enough about to know it doesn't suffice, so I'm leary of CVS, which is supposedly in all ways worse.<BR>In particular, Subversion doesn't track which changes have been merged from one branch to another. Whereas in Perforce that is a key feature of the system. Amazing that Subversion doesn't do it, but it is near the top of their wishlist.<BR> <BR>This is a small project.<BR>I haven't yet heard of anyone getting one of my possibly "in between" changes and being broken, and even when I checkin frequently, that doesn't mean any one state was broken or wrong.<BR> <BR>I haven't tested anything with Pickes. One set of tests I found failed all over the place, the m3tests stuff, floating point problems, I think a bunch of never implemented stuff on Windows around calling _fpcontrol or such (platform dependent).<BR> <BR>The system does build itself, the compiler and "std" packages. I consider that a pretty good start.<BR>I realize you can always do more, more and less obvious. There's probably no threading in the compiler, and maybe not even any garbage collection, nor any pickles.<BR> <BR>I'll look what Olaf commited over the weekend..<BR> <BR>Bah humbug and happy new year, :)<BR> - Jay<BR><BR></DIV>
<DIV>
<HR id=stopSpelling>
</DIV>
<DIV><BR>> Date: Sat, 5 Jan 2008 01:13:35 +0100<BR>> From: wagner@elegosoft.com<BR>> To: hosking@cs.purdue.edu; m3devel@elegosoft.com<BR>> CC: m3-support@elegosoft.com<BR>> Subject: Re: [M3devel] M3 concerns<BR>> <BR>> Quoting Tony Hosking <hosking@cs.purdue.edu>:<BR>> <BR>> > My comments embedded:<BR>> ><BR>> > On Jan 4, 2008, at 4:10 PM, Olaf Wagner wrote:<BR>> <BR>> >> Ah well, Windows is a somewhat special topic. I even haven't a system<BR>> >> here for tests, and most of the other contributors don't use it either.<BR>> >> I was of the opinion that Jay Krell had fixes or workarounds for most<BR>> >> current problems (except for the missing LONGINT support), but I haven't<BR>> >> tried his distribution archives yet. It would indeed be very helpful<BR>> >> if we could setup regression tests on Windows, too.<BR>> ><BR>> > LONGINT = INTEGER on Windows, which is fine as far as it goes<BR>> > (everything builds appropriately), but not particularly useful.<BR>> <BR>> I know that it should run this way, but pickles for example wouldn't<BR>> be exchangeable then, would they? Has anybody tested pickle support<BR>> for LONGINT yet?<BR>> <BR>> >> It would also be possible to define a group of reviewers for every<BR>> >> change, but I doubt that there would be enough competent volunteers,<BR>> >> and I'm afraid that it would rather repress development of CM3.<BR>> >> And we really need to have development, as the underlying systems and<BR>> >> techniques change and we need to adapt to that. So I'd vote for<BR>> >> free commits for everybody, as long as there are not too many<BR>> >> contributors, and setup of continually improved regression testing.<BR>> >> And we don't need to worry, as all changes can be reverted; we won't<BR>> >> lose development history with CVS.<BR>> ><BR>> > One option is to have moderated commits for non-core developers. After<BR>> > someone has earned the trust of the core developers they can be elected<BR>> > as a member of the core team. This approach is used with the Jikes RVM<BR>> > (www.jikesrvm.org).<BR>> <BR>> I wouldn't object to such a policy, though I don't really think that<BR>> it is currently necessary. But if more active committers do prefer<BR>> it, we can set up the necessary commit checks. I assume that Randy Coleburn<BR>> and you are in favour of restricted commits? What about the others?<BR>> <BR>> Who would volunteer to review commits from other people? Would this<BR>> be a responsibility inherited by the unrestricted access?<BR>> <BR>> Should we allow commits to branches and only restrict access to the<BR>> main line?<BR>> <BR>> Olaf<BR>> -- <BR>> Olaf Wagner -- elego Software Solutions GmbH<BR>> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany<BR>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95<BR>> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin<BR>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<BR>> <BR><BR><BR></DIV>
<DIV>
<HR>
</DIV>
<DIV>Share life as it happens with the new Windows Live. <A href="http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008" target=_new>Start sharing!</A> </DIV></BODY></HTML>