[M3devel] M3 concerns

Sat Jan 5 05:24:17 CET 2008

Anything that was broken in 5.2.6 is "probably" still broken."Probably" as in that *I* haven't fixed much.Not that *I* am a big deal or anything.Other folks might have fixed stuff.
There's been some talk about GUI stuff and not much progress.I'm not much into GUI programming, though I can't standnot having a good GUI (hypocrite I am!)
The build stuff, yes and no.
There isn't QUITE a canonical build order it turns out.It's circular. I'll explain.
I agree work is needed here though.I put forward a very lame candiate for improvement here inscripts\python\pylib.py where at least all the "filters" are in one place.Now any of scripts\python\do*.py can ask for whatever, no need toknow what works on what platform, and the filtering is centralized.The ordering is not. Hey, that's easy.But still, my representation is wrong. It should be a more generic textformat and less actual Python code.
Except that there isn't one ordering. I will explain in a sec.
For your options 1-4, well, hey, I've endeavored to keep multiple options working.Don't be confused. Just pick one. :)
Specifically, you can start with 5.2.6 and run scripts\win\upgrade.It WAS broken recently, related to LONGINT, but it is fixed now.(There isn't yet scripts\python\upgrade, but I promise there will be. :) )
Or you can take my 5.5.0 distribution, and run "anything".
I would also recommend you take the exact checked in config file.m3-sys\cminstall\src\config\NT386.It shouldn't require any edits. Feel free to read it, and consider editing it,but it shouldn't require any.
I'm assuming current source.There should be no need to "sync backward" or such.I have even endeavored to make one cm3.cfg file work with latest and older source.That is still a developing story on PPC_DARWIN and PPC_LINUX.(And "autoconf-ish" instead of "version checking" checks might be good)
You should be able to use just about any Visual C++ toolset.I put in fixes to accomodate various versions.Of course, 8.0 is about the best. 9.0 is a recent release.The releases are all high quality in my experience.
Ok, let me explain the ordering thing.There is a necessary circular dependency between the compiler and runtime.You cannot build the runtime unless you have a compiler.You cannot build a compiler unless you have a runtime.An older compiler cannot compile the current runtime, because of LONGINT.   Or could be other reasons in the future.However if you already have a runtime (somehow), an older compiler cancompile a current compiler, and then you can use the new compiler tobuild the current runtime, and then rebuild (or at least relink),the compiler against the current runtime. (I'm not sure "compile" and "link"apply per se in Modula-3, I'm not sure it builds in quite the traditionalway.)
scripts\win\make-dist and scripts\win\upgrade both take care of this.They can both start with a 5.2.6 compiler/runtime, or a current compiler/runtime.They do waste time if starting with current.Yes, they do build the compiler twice.
At some point the first computers must have been built from sticks and rocks and dirt,but once they were working, the second computer could be built with more advanced materials.
In particular, the first Modula-3 compiler was probably written in C.The first C compiler was probably written in assembly.  Or maybe written in C and hand compiled into assembly.The first assembler was probably hand translated into "machine code".
Bootstrapping is a funny thing.Circular dependencies seem wrong, but they are necessary.
Bootstrappability from earlier than 5.2 I cannot at this time vouch for.I was thinking of trying with 3.6 which I have and 4.1 if I can find my CD.But it might not be easy and it might be fairly pointless.Bootstrapping does tend to lead to building up and up and up and an inabilityto jump from the initial step to the latest. You do, I expect, restthe starting level from time to time.
3.6 does still build quite easily out of the box on current systems.I built it last week. :)(Only NT386.)

Oh, also, the order "only" matters when you don't have a package store already and/or you are changing types.
If you are only changing code, and you already have a packge store you can build in any order.
When you are changing types, or don't have a package store, I believe you have to build from the bottom of the dependency graph and on up. If you ignore the compiler, the dependency graph that I have in my head is just m3core, then libm3, then everything else. The compiler, well, you get clear errors as to what is missing if you build it out of order.

I'll get some ordering into scripts\python, excluding the circularity.

I may be mispresenting the circularity. It's probably really m3core, libm3, then the compiler but in the bootstrapping case, you must already have m3core and libm3, from a different build. The circularity exists, but maybe in sort of different terms. You don't need the compiler's .i3 files published to build libm3/m3core, you just need a cm3.exe.
 - Jay

Date: Fri, 4 Jan 2008 21:12:24 -0500From: rcoleburn at scires.comTo: hosking at cs.purdue.edu; m3devel at elegosoft.com; wagner at elegosoft.com; jayk123 at hotmail.comCC: m3-support at elegosoft.comSubject: Re: [M3devel] M3 concerns

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! 
_________________________________________________________________
Share life as it happens with the new Windows Live.
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/20080105/6f13c218/attachment-0002.html>