[M3devel] M3 concerns

Sat Jan 5 03:12:24 CET 2008

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.

I'll try to find time again this weekend to do a build of cm3 on
Windows XP again.

If one goes to the website, there seems to be several choices for
getting started, so I need some advice on the best way to move forward.
1.  Get current sources from head branch and try to build from scratch
(after first installing free Microsoft Visual C/C++ tools).
2.  Get an older variant (5.2.6, 4.1, etc.) and try to use it to build
the new current sources from CVS.
3.  Get Jay's d5.5.0 min Win32 and use it to build the current sources
from CVS.
4.  ??

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
text file that lists the correct build sequence order for all
packages 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.  

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.

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.

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.

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.  

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.  

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.  

The package status page at
http://modula3.elegosoft.com/cm3/package-status.html 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.

Sorry to ramble on so much in this post.  My main interest is in
getting the current sources built and running on Windows XP.  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.

Finally, once I get a working cm3 system on Windows, I'll provide the
new cm3-IDE (aka Reactor) package.  

Regards,
Randy

>>> Jay <jayk123 at hotmail.com> 1/4/2008 8:04 PM >>>
I oppose most red tape.

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.

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.

Perforce I am quite familiar with.
Subversion I learned enough about to know it doesn't suffice, so I'm
leary of CVS, which is supposedly in all ways worse.
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.

This is a small project.
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.

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

The system does build itself, the compiler and "std" packages. I
consider that a pretty good start.
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.

I'll look what Olaf commited over the weekend..

Bah humbug and happy new year, :)
 - Jay

> Date: Sat, 5 Jan 2008 01:13:35 +0100
> From: wagner at elegosoft.com 
> To: hosking at cs.purdue.edu; m3devel at elegosoft.com 
> CC: m3-support at elegosoft.com 
> Subject: Re: [M3devel] M3 concerns
> 
> Quoting Tony Hosking <hosking at cs.purdue.edu>:
> 
> > My comments embedded:
> >
> > On Jan 4, 2008, at 4:10 PM, Olaf Wagner wrote:
> 
> >> Ah well, Windows is a somewhat special topic. I even haven't a
system
> >> here for tests, and most of the other contributors don't use it
either.
> >> I was of the opinion that Jay Krell had fixes or workarounds for
most
> >> current problems (except for the missing LONGINT support), but I
haven't
> >> tried his distribution archives yet. It would indeed be very
helpful
> >> if we could setup regression tests on Windows, too.
> >
> > LONGINT = INTEGER on Windows, which is fine as far as it goes
> > (everything builds appropriately), but not particularly useful.
> 
> I know that it should run this way, but pickles for example wouldn't
> be exchangeable then, would they? Has anybody tested pickle support
> for LONGINT yet?
> 
> >> It would also be possible to define a group of reviewers for
every
> >> change, but I doubt that there would be enough competent
volunteers,
> >> and I'm afraid that it would rather repress development of CM3.
> >> And we really need to have development, as the underlying systems
and
> >> techniques change and we need to adapt to that. So I'd vote for
> >> free commits for everybody, as long as there are not too many
> >> contributors, and setup of continually improved regression
testing.
> >> And we don't need to worry, as all changes can be reverted; we
won't
> >> lose development history with CVS.
> >
> > One option is to have moderated commits for non-core developers.
After
> > someone has earned the trust of the core developers they can be
elected
> > as a member of the core team. This approach is used with the Jikes
RVM
> > (www.jikesrvm.org).
> 
> I wouldn't object to such a policy, though I don't really think that
> it is currently necessary. But if more active committers do prefer
> it, we can set up the necessary commit checks. I assume that Randy
Coleburn
> and you are in favour of restricted commits? What about the others?
> 
> Who would volunteer to review commits from other people? Would this
> be a responsibility inherited by the unrestricted access?
> 
> Should we allow commits to branches and only restrict access to the
> main line?
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45
86 95
> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz:
Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:
DE163214194
> 

Share life as it happens with the new Windows Live. Start sharing! (
http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008
) 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080104/785dcf74/attachment-0002.html>