From rodney_bates at lcwb.coop Sun Oct 2 17:43:01 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 02 Oct 2016 10:43:01 -0500 Subject: [M3devel] Update on CM3 start error In-Reply-To: References: Message-ID: <57F12B05.6030107@lcwb.coop> On 10/01/2016 01:49 PM, Wolfgang Keller wrote: > Update: > > I downloaded the stable version cm3-bin-core-AMD64_LINUX-5.8.6-REL.tgz and cm3 is running there without problems. After some reading I managed to compile cm3ide of the Git version, which wasn't such a big issue. However, I'm not sure if everything went ok because cm3ide, though starting up, soon falls into endless looping - without memory waste - and takes all my three processors in the course of time. > Have you run "cm3ide -verbose"? For me, using the current git version of everything, it ran tens of minutes, apparently examining at least my entire home directory for coding projects. Without the "-verbose" option, there was no clue it was accomplishing anything. With it, there were messages showing progress. > I tried cm3ide in the 5.8.6 release and the effect was the same: endless loops. Noteworthy here that this version was running while the 5.9 originally, without your fix, wasn't running. Perhaps you can make sense of this. > This is a confident guess. My fix is for a time-dependent race condition in cm3ide. The git version (of the whole repository) uses a newer thread implementation, which probably changes the outcome of the race, causing the bug to manifest itself. > ----- > > With this state of affairs I mark cm3ide as unusable, at least here on Ubuntu. Whether the compiler can be used in a meaningful way remains to be seen. Would you say that it makes sense to prefer the latest (Git) version instead of 5.8.6? Have there been important modifications / fixes to the libraries? > There have been many fixes and improvements in the git version, since the 5.8.6 release, including in libraries that cm3ide uses. It would be good to use the git version for everything. I think probably, it is currently in a more stable condition than the release. Definitely so in many specific areas. But there are complex bootstrap interdependencies among the compiler and libraries. To build from the git repository using the release compiler, you need to go into scripts/python and run upgrade-full.sh. Do you have python installed? Jay, do I have that right? > Regards, > > - Wolfgang > > > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Sun Oct 2 18:01:28 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 02 Oct 2016 11:01:28 -0500 Subject: [M3devel] CM3 Next Problem (cm3 start msg) In-Reply-To: References: Message-ID: <57F12F58.3090808@lcwb.coop> On 09/30/2016 08:50 PM, Wolfgang Keller wrote: > Hello Rodney > > Coming back to the "next problem" series, I pick the following: > > constant error reaction of "cm3" compiler program > > 1) I am working with and referring to the pre-release which I downloaded from GitHub > > d5.9.0 AMD64_LINUX as of Aug 19 2014; I run Linux 4.4.0-36 in Ubuntu 14.04. > > 2) Problem: If "cm3" is started with unspecific or without parameter, the constant reaction is a fundamental error message: > > *** > *** runtime error: > *** Exception "PathnamePosix.CheckedRuntimeError" not in RAISES list > *** file "../src/os/POSIX/PathnamePosix.m3", line 98 > *** > > This error does not appear to refer to any source-text input. > I have been unable to reproduce this. It should not crash, and should give a helpful message. But this probably starts with an operational problem. I can easily see that the latest git repository still will show this behavior. What command, in what current directory, are you using? > > Regards > > - Wolfgang > > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Tue Oct 4 20:55:26 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 04 Oct 2016 13:55:26 -0500 Subject: [M3devel] CM3 Next Problem (cm3 start msg) In-Reply-To: References: Message-ID: <57F3FB1E.3050600@lcwb.coop> On 10/04/2016 06:53 AM, Wolfgang Keller wrote: > This is a bit of a philosophical problem how to compile a compiler. I noticed several elements of the compiler package are written in M3, so this poses the question with what compiler to compile a compiler,when the compiler is needed to compile it? Also there is the question what are the elemental libraries the compiler is referring to (runtime libraries) - without compiling them - and probably the 5.8.6 compiler refers to 5.8.6 runtime packages and linking them into the result, while the target system CM3 is located inside the latest Git system. This may cause confusion in references. So how to solve this? > Yes, almost all of the entire cm3 distribution, including the compiler and the libraries it uses, is written in Modula3. We work at keeping the latest version bootstrappable by the release compiler/libraries. In order to make some improvements, we've had to introduce compiler/library interdependencies that require nontrivial bootstrap process. The update.sh script takes care of this, if you want to compile the git version of everything. Don't be bothered by the amount of work it does. I recompiles some things two or three times, and takes quite a bit of time. We are really overdue to package up a new release. > - Wolfgang > > > Am 01.10.2016 um 03:50 schrieb Wolfgang Keller: >> >> Hello Rodney >> >> Coming back to the "next problem" series, I pick the following: >> >> constant error reaction of "cm3" compiler program >> >> 1) I am working with and referring to the pre-release which I downloaded from GitHub >> >> d5.9.0 AMD64_LINUX as of Aug 19 2014; I run Linux 4.4.0-36 in Ubuntu 14.04. >> >> 2) Problem: If "cm3" is started with unspecific or without parameter, the constant reaction is a fundamental error message: >> >> *** >> *** runtime error: >> *** Exception "PathnamePosix.CheckedRuntimeError" not in RAISES list >> *** file "../src/os/POSIX/PathnamePosix.m3", line 98 >> *** >> >> This error does not appear to refer to any source-text input. >> >> >> Regards >> >> - Wolfgang >> >> > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Wed Oct 5 01:22:33 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 04 Oct 2016 18:22:33 -0500 Subject: [M3devel] Update on CM3 start error In-Reply-To: References: <57F12B05.6030107@lcwb.coop> <21a99a6b-859c-b34a-020d-72ee4dd7a1bb@gmx.de> Message-ID: <57F439B9.5020907@lcwb.coop> On 10/04/2016 07:13 AM, Wolfgang Keller wrote: > I managed to provoke further action by starting "localhost:3800" in the browser and voila there is the IDE! But the loop continues, after a few extra messages which I give below. What platform + system are you working with? - My resume is that this IDE needs an overhaul! ;) > > scan done: Oct 4 14:05 > GET / HTTP/1.1 > GET /rsrc/CM3_IDE.gif HTTP/1.1 > GET /rsrc/pkg.gif HTTP/1.1 > GET /rsrc/config.gif HTTP/1.1 > GET /rsrc/lib.gif HTTP/1.1 > GET /rsrc/pgm.gif HTTP/1.1 > GET /rsrc/x-i3.gif HTTP/1.1 > GET /rsrc/x-m3.gif HTTP/1.1 > GET /rsrc/x-ig.gif HTTP/1.1 > GET /rsrc/type.gif HTTP/1.1 > GET /rsrc/man.gif HTTP/1.1 > GET /rsrc/x-mg.gif HTTP/1.1 > GET /rsrc/util.gif HTTP/1.1 > GET /rsrc/tut.gif HTTP/1.1 > GET /rsrc/ref.gif HTTP/1.1 > GET /rsrc/ex.gif HTTP/1.1 > GET /rsrc/doc.gif HTTP/1.1 > GET /favicon.ico HTTP/1.1 > GET /favicon.ico HTTP/1.1 > > ... unending loop, 3 processors at 100% - unbearable! > I have now reproduced this loop , but only after clicking in the web page on a package name. I need to make m3gdb improvements to diagnose this. I have no experience with cm3ide, up to now. I am on AMD46_LINUX, using the github version of Modula3. > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Thu Oct 6 17:03:43 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 06 Oct 2016 10:03:43 -0500 Subject: [M3devel] CM3 Next Problem (cm3 start msg) In-Reply-To: <9402da17-ebc8-6bbe-466c-fae99d6a74c4@gmx.de> References: <57F3FB1E.3050600@lcwb.coop> <9402da17-ebc8-6bbe-466c-fae99d6a74c4@gmx.de> Message-ID: <57F667CF.5050709@lcwb.coop> On 10/06/2016 05:08 AM, Wolfgang Keller wrote: > Under "scripts" I find a "upgrade.sh" script and also "make-src-update.sh", "make-src-files-update.sh". Which ones should I apply? > upgrade.sh Jay, what do the other two do? > Are you saying the update script is using 5.8.6 cm3 to compile everything needed for the next version? > yes. > - Wolfgang > > > Am 04.10.2016 um 20:55 schrieb Rodney M. Bates: >> >> >> On 10/04/2016 06:53 AM, Wolfgang Keller wrote: >>> This is a bit of a philosophical problem how to compile a compiler. I noticed several elements of the compiler package are written in M3, so this poses the question with what compiler to compile a compiler,when the compiler is needed to compile it? Also there is the question what are the elemental libraries the compiler is referring to (runtime libraries) - without compiling them - and probably the 5.8.6 compiler refers to 5.8.6 runtime packages and linking them into the result, while the target system CM3 is located inside the latest Git system. This may cause confusion in references. So how to solve this? >>> >> >> Yes, almost all of the entire cm3 distribution, including the compiler and the >> libraries it uses, is written in Modula3. We work at keeping the latest version >> bootstrappable by the release compiler/libraries. In order to make some improvements, >> we've had to introduce compiler/library interdependencies that require nontrivial >> bootstrap process. The update.sh script takes care of this, if you want to >> compile the git version of everything. Don't be bothered by the amount of work >> it does. I recompiles some things two or three times, and takes quite a bit of >> time. >> >> We are really overdue to package up a new release. >> >>> - Wolfgang >>> >>> >>> Am 01.10.2016 um 03:50 schrieb Wolfgang Keller: >>>> >>>> Hello Rodney >>>> >>>> Coming back to the "next problem" series, I pick the following: >>>> >>>> constant error reaction of "cm3" compiler program >>>> >>>> 1) I am working with and referring to the pre-release which I downloaded from GitHub >>>> >>>> d5.9.0 AMD64_LINUX as of Aug 19 2014; I run Linux 4.4.0-36 in Ubuntu 14.04. >>>> >>>> 2) Problem: If "cm3" is started with unspecific or without parameter, the constant reaction is a fundamental error message: >>>> >>>> *** >>>> *** runtime error: >>>> *** Exception "PathnamePosix.CheckedRuntimeError" not in RAISES list >>>> *** file "../src/os/POSIX/PathnamePosix.m3", line 98 >>>> *** >>>> >>>> This error does not appear to refer to any source-text input. >>>> >>>> >>>> Regards >>>> >>>> - Wolfgang >>>> >>>> >>> >> > > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Fri Oct 7 17:27:31 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 07 Oct 2016 10:27:31 -0500 Subject: [M3devel] Fwd: CM3 report compiler compilation In-Reply-To: <3e952b47-e471-764c-08ec-ba3f8e1df117@gmx.de> References: <3e952b47-e471-764c-08ec-ba3f8e1df117@gmx.de> Message-ID: <57F7BEE3.7030408@lcwb.coop> -------- Original Message -------- Subject: CM3 report compiler compilation Date: Fri, 7 Oct 2016 10:53:29 +0200 From: Wolfgang Keller <9103784 at gmx.de> To: rodney.m.bates at acm.org I attempted at compiler compilation and found a few peculiar things. 1. The Result Critical Mass Modula-3 version d5.10.0 last updated: 2015-05-21 compiled: 2016-10-07 03:58:31 configuration: /home/user/Projekte/M3-Test2/bin/cm3.cfg host: AMD64_LINUX target: AMD64_LINUX This is how cm3 identifies. a) "last updated" - since you modified the sources, should there be a younger date? b) compilation results (executables) as well as configuration file have been put into CM3 (Git version) folders and into the "independent" installation of the older version of CM3, i.e. 5.8.6. I see this critical! The independent installation should stay unmodified in its functionality. Users might wish to continue to use it, e.g. when the newer version proves buggy or otherwise undesirable. c) Erroneous execution. When calling "cm3" in the "cm3ide" directory it does not compile and the text result is -- begin -- --- building in AMD64_LINUX --- ignoring ../src/m3overrides Fatal Error: bad version stamps: ConnFD.i3 inconsistent opaque object info for type _t1541f475 super type: _te422a136 data: (size: 64, align: 64) method: (size: 0) => ConnFD.i3 super type: _te422a136 data: (size: 192, align: 64) method: (size: 0) => ThreadPThread.m3 -- end -- 2. The Way to the Result a) The following script files require the "executable" file attribute in the file system. By default theiy didn't have it set here, causing several broken compilations. Not sure whether Git provides file attributes conservation in this sense, if yes it is recommendable to make these file settings in the Git version! - upgrade.sh in scripts - do-pkg.sh in scripts - pkgmap.sh in scripts - configure in m3-sys/m3cc/gcc-4.7 - move-if-change in m3-sys/m3cc/gcc Regards - Wolfgang From rodney_bates at lcwb.coop Fri Oct 7 18:17:33 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 07 Oct 2016 11:17:33 -0500 Subject: [M3devel] CM3 report compiler compilation In-Reply-To: <3e952b47-e471-764c-08ec-ba3f8e1df117@gmx.de> References: <3e952b47-e471-764c-08ec-ba3f8e1df117@gmx.de> Message-ID: <57F7CA9D.50302@lcwb.coop> On 10/07/2016 03:53 AM, Wolfgang Keller wrote: > I attempted at compiler compilation and found a few peculiar things. > > 1. The Result > > Critical Mass Modula-3 version d5.10.0 > last updated: 2015-05-21 > compiled: 2016-10-07 03:58:31 > configuration: /home/user/Projekte/M3-Test2/bin/cm3.cfg > host: AMD64_LINUX > target: AMD64_LINUX > > This is how cm3 identifies. > > a) "last updated" - since you modified the sources, should there be a younger date? Yes. This is now manually updated in scripts/version.quake. m3devel list: We need to do this with every commit, or else automate it. > > b) compilation results (executables) as well as configuration file have been put into CM3 (Git version) folders and into the "independent" installation of the older version of CM3, i.e. 5.8.6. I see this critical! The independent installation should stay unmodified in its functionality. Users might wish to continue to use it, e.g. when the newer version proves buggy or otherwise undesirable. > Yes, we have been working on this. You can recreate a clean release installation at any time, but it's a real pain for intermediate versions during development. I am very conservative about saving existing versions before touching the compiler or its core libraries, either by copying critical executable file and library files, or making whole copies of /usr/local/cm3. > c) Erroneous execution. When calling "cm3" in the "cm3ide" directory it does not compile and the text result is > > -- begin -- > --- building in AMD64_LINUX --- > > ignoring ../src/m3overrides > > Fatal Error: bad version stamps: ConnFD.i3 > > inconsistent opaque object info for type _t1541f475 > super type: _te422a136 data: (size: 64, align: 64) method: (size: 0) > => ConnFD.i3 > super type: _te422a136 data: (size: 192, align: 64) method: (size: 0) > => ThreadPThread.m3 > > -- end -- > This is almost certainly a need for complete recompile of cm3ide. Try, in the cm3ide directory: cm3 -realclean cm3 Within a package, the compiler infers from source code what needs to be recompiled and does so. Between packages, and for certain kinds of changes in machine-level types, it can only detect incompatibilities. This is rare. The messages are highly uninformative, but fixing them requires changes to the compiler's internal intermediate representation, which entails widespread, but mundane code changes. I have undertaken some of this previously, but it hasn't had the highest priority. > > 2. The Way to the Result > > a) The following script files require the "executable" file attribute in the file system. By default theiy didn't have it set here, causing several broken compilations. Not sure whether Git provides file attributes conservation in this sense, if yes it is recommendable to make these file settings in the Git version! > Hmm, all these are already executable in my local directories. Possibly this was left over from when we used CVS. I didn't quickly find anything in git documentation about what it does with file attribute bits, but the github website labels upgrade.sh as "Executable File". > - upgrade.sh in scripts > > - do-pkg.sh in scripts > - pkgmap.sh in scripts > > - configure in m3-sys/m3cc/gcc-4.7 > - move-if-change in m3-sys/m3cc/gcc > > > Regards > > - Wolfgang > > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Fri Oct 7 18:34:34 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 07 Oct 2016 11:34:34 -0500 Subject: [M3devel] Please update CM3LASTCHANGED when appropriate Message-ID: <57F7CE9A.3030503@lcwb.coop> Please update variable CM3LASTCHANGED, in scripts/version.quake, to the current date, as part of any change that affects the compiler or its libraries m3core and libm3. -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Fri Oct 7 22:05:45 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 07 Oct 2016 15:05:45 -0500 Subject: [M3devel] What's with Atomic*.CompareSwap? Message-ID: <57F80019.3040103@lcwb.coop> In trying to remove code generator failures compling calls on Atomic*.CompareSwap, I find things very confusing. Parameter 'expected' is declared as VAR, and the front end is passing it by value, but M3CG_Check wants its type to be as if passed by value. All the back ends seem to think it is passed by value also, But this would mean it was never updated. The ubiquitous comment that it is "permitted to fail spuriously" is confusing. I would have thought "fail" meant return FALSE when it shouldn't, but the sample loop looks more like "fail" means return FALSE correctly, but not update 'expected'. Even then, I don't understand the loop. If it's trying to atomically update 'current' to 'function(current)' wouldn't it be better to keep refetching 'current' every time, instead of 'expected', which, if it differed,, due to a "spurious failure" (in the latter sense) would be older and less likely to result in a successful update the next try? And if 'expected' is never updated, as the back ends appear to be doing, this loop would have a low probability of ever terminating, since 'desired' would almost always fail to match 'current'. -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Sat Oct 8 01:24:00 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 07 Oct 2016 18:24:00 -0500 Subject: [M3devel] CM3 report compiler compilation In-Reply-To: References: <3e952b47-e471-764c-08ec-ba3f8e1df117@gmx.de> <57F7CA9D.50302@lcwb.coop> Message-ID: <57F82E90.1080108@lcwb.coop> On 10/07/2016 01:26 PM, Wolfgang Keller wrote: > > > Am 07.10.2016 um 18:17 schrieb Rodney M. Bates: >> >> >> On 10/07/2016 03:53 AM, Wolfgang Keller wrote: >>> I attempted at compiler compilation and found a few peculiar things. >>> >>> 1. The Result >>> >>> Critical Mass Modula-3 version d5.10.0 >>> last updated: 2015-05-21 >>> compiled: 2016-10-07 03:58:31 >>> configuration: /home/user/Projekte/M3-Test2/bin/cm3.cfg >>> host: AMD64_LINUX >>> target: AMD64_LINUX >>> >>> This is how cm3 identifies. >>> >>> a) "last updated" - since you modified the sources, should there be a younger date? >> >> Yes. This is now manually updated in scripts/version.quake. >> >> m3devel list: We need to do this with every commit, or else automate it. >> >>> >>> b) compilation results (executables) as well as configuration file have been put into CM3 (Git version) folders and into the "independent" installation of the older version of CM3, i.e. 5.8.6. I see this critical! The independent installation should stay unmodified in its functionality. Users might wish to continue to use it, e.g. when the newer version proves buggy or otherwise undesirable. >>> >> >> Yes, we have been working on this. You can recreate a clean release installation at >> any time, but it's a real pain for intermediate versions during development. I am >> very conservative about saving existing versions before touching the compiler or its >> core libraries, either by copying critical executable file and library files, or making >> whole copies of /usr/local/cm3. >> >>> c) Erroneous execution. When calling "cm3" in the "cm3ide" directory it does not compile and the text result is >>> >>> -- begin -- >>> --- building in AMD64_LINUX --- >>> >>> ignoring ../src/m3overrides >>> >>> Fatal Error: bad version stamps: ConnFD.i3 >>> >>> inconsistent opaque object info for type _t1541f475 >>> super type: _te422a136 data: (size: 64, align: 64) method: (size: 0) >>> => ConnFD.i3 >>> super type: _te422a136 data: (size: 192, align: 64) method: (size: 0) >>> => ThreadPThread.m3 >>> >>> -- end -- >>> >> >> This is almost certainly a need for complete recompile of cm3ide. Try, in >> the cm3ide directory: >> >> cm3 -realclean >> cm3 >> >> >> Within a package, the compiler infers from source code what needs to be recompiled >> and does so. Between packages, and for certain kinds of changes in machine-level >> types, it can only detect incompatibilities. This is rare. The messages are >> highly uninformative, but fixing them requires changes to the compiler's internal >> intermediate representation, which entails widespread, but mundane code changes. >> I have undertaken some of this previously, but it hasn't had the highest priority. > > Taking your advice it results in the following: > > -- begin -- > --- building in AMD64_LINUX --- > > ignoring ../src/m3overrides > > /home/user/Projekte/M3-Test2/bin/m3bundle -name CM3_IDE_Bundle -F/tmp/qk > new source -> compiling Buf.i3 > new source -> compiling Buf.m3 > new source -> compiling ErrLog.i3 > new source -> compiling ErrLog.m3 > > Fatal Error: bad version stamps: ConnFD.i3 > > inconsistent opaque object info for type _t1541f475 > super type: _te422a136 data: (size: 64, align: 64) method: (size: 0) > => ConnFD.i3 > super type: _te422a136 data: (size: 192, align: 64) method: (size: 0) > => ThreadPThread.m3 > -- end -- > > Obviously compilation takes reference into the "other" installation and resulting in inconsistencies. Why does it do so? This is the type of mixed up configurations that I have been speaking of! Up to now I don't quite understand how people are working with this system. Does it work for you? > It's the other way around. ConnFD.i3 has an old, already compiled version around that depends on something in ThreadPThread, which has changed and been recently recompiled. ConnFD.i3 now needs to be recompiled to adapt, now that a new libm3core is installed (which ThreadPThread is part of). I should have looked at where ConnFD.i3 is located. It's in package group m3-comm, which upgrade.sh apparently didn't rebuild. So try this, as I just did: in directory scripts: ./do-cm3-comm.sh realclean ,/do-cm3-comm.sh buildship Then try rebuilding cm3ide. There could be more things that haven't been rebuilt by update.sh. I would predict that m3-ui and m3-db haven't, though I doubt cm3ide needs m3-ui. There are do-cm3-*.sh scripts for a lot of these groups. I have worked in compilation systems for modular languages that have a two-level automatic rebuild system. Modula-3 does not. The automatic rebuild only works within a package. It would be nice to have one. > Theoretically, the missing file attributes may have had an impact on the results of the upgrade. Who knows? > > > > -- Rodney Bates rodney.m.bates at acm.org From jayk123 at hotmail.com Sat Oct 8 05:24:16 2016 From: jayk123 at hotmail.com (Jay K) Date: Sat, 8 Oct 2016 03:24:16 +0000 Subject: [M3devel] CM3 report compiler compilation In-Reply-To: <57F82E90.1080108@lcwb.coop> References: <3e952b47-e471-764c-08ec-ba3f8e1df117@gmx.de> <57F7CA9D.50302@lcwb.coop> ,<57F82E90.1080108@lcwb.coop> Message-ID: > I have worked in compilation systems for modular languages > that have a two-level > automatic rebuild system. Modula-3 does not. The automatic > rebuild only works > within a package. It would be nice to have one. We have another opportunity -- rebuild everything, but incrementally. do-cm3-all buildship or such. Already there. But there are some incrementality bugs in cm3. I know, for example, moving a module/interface between packages doesn't work. I think do-cm3-all-kinda should be easy to work into cm3 itself. It just needs to know where all the packages are. I believe package boundaries are already declared, via program(), library(), etc. occuring last in m3makefiles per package. > The independent installation should stay unmodified > in its functionality. Users might wish to continue to use it, > e.g. when the newer version proves buggy or otherwise undesirable. We all mostly agree but haven't been able to change it. Some of the build automation (make-dist.py) actually first copies the existing install, then builds and updates it in place. You might try it. - Jay ________________________________ From: M3devel on behalf of Rodney M. Bates Sent: Friday, October 7, 2016 11:24 PM To: Wolfgang Keller; rodney.m.bates at acm.org; m3devel Subject: Re: [M3devel] CM3 report compiler compilation On 10/07/2016 01:26 PM, Wolfgang Keller wrote: > > > Am 07.10.2016 um 18:17 schrieb Rodney M. Bates: >> >> >> On 10/07/2016 03:53 AM, Wolfgang Keller wrote: >>> I attempted at compiler compilation and found a few peculiar things. >>> >>> 1. The Result >>> >>> Critical Mass Modula-3 version d5.10.0 >>> last updated: 2015-05-21 >>> compiled: 2016-10-07 03:58:31 >>> configuration: /home/user/Projekte/M3-Test2/bin/cm3.cfg >>> host: AMD64_LINUX >>> target: AMD64_LINUX >>> >>> This is how cm3 identifies. >>> >>> a) "last updated" - since you modified the sources, should there be a younger date? >> >> Yes. This is now manually updated in scripts/version.quake. >> >> m3devel list: We need to do this with every commit, or else automate it. >> >>> >>> b) compilation results (executables) as well as configuration file have been put into CM3 (Git version) folders and into the "independent" installation of the older version of CM3, i.e. 5.8.6. I see this critical! The independent installation should stay unmodified in its functionality. Users might wish to continue to use it, e.g. when the newer version proves buggy or otherwise undesirable. >>> >> >> Yes, we have been working on this. You can recreate a clean release installation at >> any time, but it's a real pain for intermediate versions during development. I am >> very conservative about saving existing versions before touching the compiler or its >> core libraries, either by copying critical executable file and library files, or making >> whole copies of /usr/local/cm3. >> >>> c) Erroneous execution. When calling "cm3" in the "cm3ide" directory it does not compile and the text result is >>> >>> -- begin -- >>> --- building in AMD64_LINUX --- >>> >>> ignoring ../src/m3overrides >>> >>> Fatal Error: bad version stamps: ConnFD.i3 >>> >>> inconsistent opaque object info for type _t1541f475 >>> super type: _te422a136 data: (size: 64, align: 64) method: (size: 0) >>> => ConnFD.i3 >>> super type: _te422a136 data: (size: 192, align: 64) method: (size: 0) >>> => ThreadPThread.m3 >>> >>> -- end -- >>> >> >> This is almost certainly a need for complete recompile of cm3ide. Try, in >> the cm3ide directory: >> >> cm3 -realclean >> cm3 >> >> >> Within a package, the compiler infers from source code what needs to be recompiled >> and does so. Between packages, and for certain kinds of changes in machine-level >> types, it can only detect incompatibilities. This is rare. The messages are >> highly uninformative, but fixing them requires changes to the compiler's internal >> intermediate representation, which entails widespread, but mundane code changes. >> I have undertaken some of this previously, but it hasn't had the highest priority. > > Taking your advice it results in the following: > > -- begin -- > --- building in AMD64_LINUX --- > > ignoring ../src/m3overrides > > /home/user/Projekte/M3-Test2/bin/m3bundle -name CM3_IDE_Bundle -F/tmp/qk > new source -> compiling Buf.i3 > new source -> compiling Buf.m3 > new source -> compiling ErrLog.i3 > new source -> compiling ErrLog.m3 > > Fatal Error: bad version stamps: ConnFD.i3 > > inconsistent opaque object info for type _t1541f475 > super type: _te422a136 data: (size: 64, align: 64) method: (size: 0) > => ConnFD.i3 > super type: _te422a136 data: (size: 192, align: 64) method: (size: 0) > => ThreadPThread.m3 > -- end -- > > Obviously compilation takes reference into the "other" installation and resulting in inconsistencies. Why does it do so? This is the type of mixed up configurations that I have been speaking of! Up to now I don't quite understand how people are working with this system. Does it work for you? > It's the other way around. ConnFD.i3 has an old, already compiled version around that depends on something in ThreadPThread, which has changed and been recently recompiled. ConnFD.i3 now needs to be recompiled to adapt, now that a new libm3core is installed (which ThreadPThread is part of). I should have looked at where ConnFD.i3 is located. It's in package group m3-comm, which upgrade.sh apparently didn't rebuild. So try this, as I just did: in directory scripts: ./do-cm3-comm.sh realclean ,/do-cm3-comm.sh buildship Then try rebuilding cm3ide. There could be more things that haven't been rebuilt by update.sh. I would predict that m3-ui and m3-db haven't, though I doubt cm3ide needs m3-ui. There are do-cm3-*.sh scripts for a lot of these groups. I have worked in compilation systems for modular languages that have a two-level automatic rebuild system. Modula-3 does not. The automatic rebuild only works within a package. It would be nice to have one. > Theoretically, the missing file attributes may have had an impact on the results of the upgrade. Who knows? > > > > -- Rodney Bates rodney.m.bates at acm.org _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://m3lists.elegosoft.com/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Oct 8 05:26:40 2016 From: jayk123 at hotmail.com (Jay K) Date: Sat, 8 Oct 2016 03:26:40 +0000 Subject: [M3devel] CM3 Next Problem (cm3 start msg) In-Reply-To: <57F667CF.5050709@lcwb.coop> References: <57F3FB1E.3050600@lcwb.coop> <9402da17-ebc8-6bbe-466c-fae99d6a74c4@gmx.de>,<57F667CF.5050709@lcwb.coop> Message-ID: I never use any of the .sh files. I find .sh to be not a worthwhile language to use for much. I only use the .py files, or the occasional very small .sh file that just runs a litte .py. I very much recommend the .py files. When I wrote upgrade.py, based on upgrade.sh, I slightly misunderstood. So upgrade-full.sh is a close approximation (and look how trivial it is -- just calls others). - Jay ________________________________ From: M3devel on behalf of Rodney M. Bates Sent: Thursday, October 6, 2016 3:03 PM To: Wolfgang Keller; rodney.m.bates at acm.org; m3devel Subject: Re: [M3devel] CM3 Next Problem (cm3 start msg) On 10/06/2016 05:08 AM, Wolfgang Keller wrote: > Under "scripts" I find a "upgrade.sh" script and also "make-src-update.sh", "make-src-files-update.sh". Which ones should I apply? > upgrade.sh Jay, what do the other two do? > Are you saying the update script is using 5.8.6 cm3 to compile everything needed for the next version? > yes. > - Wolfgang > > > Am 04.10.2016 um 20:55 schrieb Rodney M. Bates: >> >> >> On 10/04/2016 06:53 AM, Wolfgang Keller wrote: >>> This is a bit of a philosophical problem how to compile a compiler. I noticed several elements of the compiler package are written in M3, so this poses the question with what compiler to compile a compiler,when the compiler is needed to compile it? Also there is the question what are the elemental libraries the compiler is referring to (runtime libraries) - without compiling them - and probably the 5.8.6 compiler refers to 5.8.6 runtime packages and linking them into the result, while the target system CM3 is located inside the latest Git system. This may cause confusion in references. So how to solve this? >>> >> >> Yes, almost all of the entire cm3 distribution, including the compiler and the >> libraries it uses, is written in Modula3. We work at keeping the latest version >> bootstrappable by the release compiler/libraries. In order to make some improvements, >> we've had to introduce compiler/library interdependencies that require nontrivial >> bootstrap process. The update.sh script takes care of this, if you want to >> compile the git version of everything. Don't be bothered by the amount of work >> it does. I recompiles some things two or three times, and takes quite a bit of >> time. >> >> We are really overdue to package up a new release. >> >>> - Wolfgang >>> >>> >>> Am 01.10.2016 um 03:50 schrieb Wolfgang Keller: >>>> >>>> Hello Rodney >>>> >>>> Coming back to the "next problem" series, I pick the following: >>>> >>>> constant error reaction of "cm3" compiler program >>>> >>>> 1) I am working with and referring to the pre-release which I downloaded from GitHub >>>> >>>> d5.9.0 AMD64_LINUX as of Aug 19 2014; I run Linux 4.4.0-36 in Ubuntu 14.04. [https://avatars3.githubusercontent.com/u/7759860?v=3&s=400] modula3/cm3 github.com cm3 - Critical Mass Modula-3 >>>> >>>> 2) Problem: If "cm3" is started with unspecific or without parameter, the constant reaction is a fundamental error message: >>>> >>>> *** >>>> *** runtime error: >>>> *** Exception "PathnamePosix.CheckedRuntimeError" not in RAISES list >>>> *** file "../src/os/POSIX/PathnamePosix.m3", line 98 >>>> *** >>>> >>>> This error does not appear to refer to any source-text input. >>>> >>>> >>>> Regards >>>> >>>> - Wolfgang >>>> >>>> >>> >> > > -- Rodney Bates rodney.m.bates at acm.org _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://m3lists.elegosoft.com/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmuysers at hotmail.com Sat Oct 8 19:01:06 2016 From: dmuysers at hotmail.com (dirk muysers) Date: Sat, 8 Oct 2016 17:01:06 +0000 Subject: [M3devel] Modula 3 and Oberon, some random thoughts Message-ID: In another life, my favorite Pascal child had been Oberon, and for many years now I use Modula 3, because of some programmer-friendly, or let's say laziness-encouraging :-) features such as constructors, default values and nested blocks, but the main reason was that I needed to make stand-alone distributable programs, while Oberon runs in a closed workstation IDE environment. Also Oberon --unlike Modula 3-- has no make facility, modules are compiled one par one interactively as they are written. To remain honest, it now also has a rather complicated release tool that kind of imitates Quake. I still prefer writing relatively big (but not huge) modules rather than a multitude of very small modules. What I still miss in Modula 3 is the possibility of read-only global and field exports, which let you avoid making many types opaque and providing their corresponding xxxRep modules. What makes compiling Modula 3 rather difficult is the possibility of n:m relationships between modules and interfaces, rather than the module and its interface like in Oberon. It also makes dynamic loading near impossible. An other sensitive point is the existence of packages. Note that the ComponentPascal dialect of Oberon also has packages (called subsystems) but modules are known as belonging to the package named by the characters until the first LC/UC transition of the module name which obviates the need to deal with it at the m3makefile level. Let's face it, the Modula 3 compiler with its four packages and hundreds of modules, is what I call a monster and what the French call "une usine 'a gaz". In comparison, the Fox compiler of the last Active Oberon avatar is much simpler, consisting of some 60 modules and compiles ultra fast. It doesn't need a Quake and yet, being used in a research environment, offers a great flexibility with regard to platforms, architectures and backends. Many problems that plague the Modula 3 implementations could be solved by having a look at Oberon. Unfortunately not many community members seem to be familiar with the Oberon world. In addition most of them are Linux based which makes them --unlike the Oberonists-- neglect the different Windows systems which still represent 80% of all desktop computers. I think the whole compiler should be rewritten from the ground. As for me, I am, at 82, just too old for such a workload. Having a look at Oberon's new very clever cooperative multitasking system that runs on as much processes as there are system processors (also heard about Go?) would be very beneficial for the Modula 3 community. As a final rant, if cm3 improved in many ways the compiler, many features were better in pm3 like texts and threading. I would have left the text system as it was, just encoding it in UTF-8 as nearly everybody does nowadays, and also --just a peanuts detail-- I prefer RUNE over WIDECHAR because it just has four letters that make RUNE/CHAR written one above the other as it often happens in selects and conditionals, more readable. I love readable programs. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Sat Oct 8 23:40:15 2016 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 8 Oct 2016 21:40:15 +0000 (UTC) Subject: [M3devel] Modula 3 and Oberon, some random thoughts In-Reply-To: References: Message-ID: <1581843928.2267903.1475962815431@mail.yahoo.com> Hello Dirk:have you seen this module systemhttp://bitsavers.trailing-edge.com/pdf/dec/prism/mica/Pillar_Language_Specification_Nov88.pdf Thanks in advance El S?bado 8 de octubre de 2016 12:01, dirk muysers escribi?: In another life, my favorite Pascal child had been Oberon, and for many years now I use Modula 3,? because of some programmer-friendly, or let's say laziness-encouraging :-) features??such as constructors, default values and nested blocks, but the main reason was that I needed to make stand-alone?distributableprograms, while Oberon runs in a closed workstation IDE environment. Also Oberon --unlike Modula 3-- has no make facility, modules are compiled one par one interactively as they are written. To remain honest, it now also has a rather complicated release tool that kind of imitates Quake. I still prefer writing relatively?big (but not huge) modules rather than a multitude of very small modules. What I still miss??in Modula 3 is the possibility of read-only global and field exports, which let you avoid making many types opaque?and providing their corresponding xxxRep modules. What makes compiling Modula 3 rather difficult is the possibility?of n:m relationships between modules and interfaces, rather thanthe module and its interface like in?Oberon. It also makes dynamic loading near impossible. An other sensitive point is the existence of packages.?Note that the ComponentPascal dialect of Oberon also has packages (called subsystems) but modules are known as belonging?to the package named by the characters until the first LC/UC transition of the module name which obviates the?need to deal with it at the m3makefile level.? Let's face it, the Modula 3 compiler?with its four packages and hundreds of modules,?is what I call a monster and?what the French call "une usine 'a gaz". In comparison, the Fox compiler of the last Active Oberon avatar?is much simpler, consisting of some 60 modules and compiles ultra fast.?It doesn't need a Quake and yet, being used in a research environment, offers a great flexibility with regard?to platforms, architectures and backends. Many problems that plague the Modula 3 implementations could be solved by having a look at Oberon.?Unfortunately not many community members seem to be familiar with the Oberon world.?In addition most of them are Linux based which makes them --unlike the Oberonists-- neglect the different Windows systems?which still represent 80% of all desktop computers. I think the whole compiler should be rewritten from the ground. As for me, I am, at 82, just too old for such a workload.?Having a look at Oberon's new?very clever cooperative multitasking system?that runs on as much processes as?there are system processors (also heard about Go?) ?would be very beneficial for the Modula 3 community. As a final rant, if cm3 improved in many ways the compiler, many features were better in pm3 like texts and threading. I would have left the text system as it was, just encoding it in UTF-8 as nearly everybody does nowadays, and also --just a peanuts detail-- I prefer RUNE over WIDECHAR because it just has four letters that make?RUNE/CHAR written one above the other as it often happens in selects and conditionals, more readable. I love?readable programs. _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://m3lists.elegosoft.com/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Sun Oct 9 22:22:53 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 09 Oct 2016 15:22:53 -0500 Subject: [M3devel] CM3 report compiler compilation In-Reply-To: References: <3e952b47-e471-764c-08ec-ba3f8e1df117@gmx.de> <57F7CA9D.50302@lcwb.coop> <57F82E90.1080108@lcwb.coop> Message-ID: <57FAA71D.6010608@lcwb.coop> While there is plenty of room for improvement in CM3, perhaps it has provoked for you, a crisis of rising expectations, leading you to apply a higher standard than to other build systems. The Modula-3 language and the CM3 implementation of it are already far ahead of the prevailing standard for software build systems. For *within* a package, CM3 automatically detects and carries out any recompilation necessary due to changes, and on a declaration granularity. If an interface you import has been changed only in declarations you do not actually reference, your code need not be recompiled. Compare this to C/C++/Make, where, if the file you depend on has been touched in any way, even just editing of comments or just changing its recorded date, your file has to be recompiled. Moreover, the dependencies have to be manually written into a Makefile, or the recompilation will not occur when it is necessary. There are side tools around that will automatically generate Makefile dependencies, but they can only judge on the basis of #include lines, not actual uses. They have to be rerun along with every recompilation, or else, inevitably, the Makefile will get out of date. That can lead to very difficult-to-diagnose bugs that often don't show up for a long time later, after many unrelated changes and rebuilds. Such tools cannot help with the very difficult task of discovering when a #include has become unnecessary. This is extremely difficult to find, and requires combing through the entire closure of #includes, in order, not just the direct ones, looking for referenced declarations. CM3, in contrast will warn of an IMPORT that is not needed. BTW, in Modula-3,only the direct IMPORTs need to be examined. Between packages, CM3 always detects incompatibilities. In most systems, the closest you get to this is via a package manager, e.g., APT or RPM. Again, for these to work, somebody has to manually note the dependencies in the package. These are even coarser than file-granularity. They can only use library names, with embedded version numbers, to detect problems. There is nothing to check whether the version numbers correctly reflect incompatibilities. What detection does happen is delayed from link time to install time. And you have to manually rebuild the library to fix it. CM3 will always detect, at declaration granularity, at link time, when such an incompatibility exists, with no extra manual effort beyond the actual modification itself. The worst you can criticize is that the messages are not very informative (but still much better), and as above, you have to ask for a recompile of your package. But the situation that brought this all up goes even deeper. There, package cm3ide links in file ConnFD.i3, in package tcp, with object code in libm3tcp.so, which needs to be recompiled because it links in ThreadPThread.m3, in package m3core, compiled into libm3core.so. This is (non-trivial) *transitive* dependency in the link closure of libraries. CM3 detected this, but has to be asked manually to do the necessary recompilation. I am far from knowledgeable about all build systems in existence, but I would be be very surprised if more than one or two others do even this detection. I am not even sure one would want a build system to automatically transitively rebuild across multiple libraries. It might work when all the libraries are in a single repository like Modula3-cm3. But often, programs use libraries from very different projects, with source code in far-flung places, if available at all. I suppose one could write a Makefile that notes when a linked-in library depends on another linked-in library. I doubt this has been done very often. Even so, it would at best, detect only at whole library granularity. On 10/08/2016 01:22 AM, Wolfgang Keller wrote: > The "upgrade" process claims to update a target installation system (perhaps also called the "work installation"). In my test case this was in " /home/user/Projekte/M3-Test2/". This is also the system which is made available in global environment paths. > > 1) If - after creation of the target system - compiling "cm3" within "cm3ide" of CM3 (git) fails then the claim to having built a valid upgrade has also failed (if we assume that cm3ide holds a valid composition of sources). > > 2) The compile process reports taking reference to m3bundle which appears to imply it is an essential part of the core compiler. > > "/home/user/Projekte/M3-Test2/bin/m3bundle -name CM3_IDE_Bundle -F/tmp/qk > new source -> compiling Buf.i3 > new source -> compiling Buf.m3 > new source -> compiling ErrLog.i3 > new source -> compiling ErrLog.m3 > > Fatal Error: bad version stamps: ConnFD.i3" > > 3) If we look at the /bin directory of the target system, we find some updated executables with the exception of "cm3ide" and "m3bundle" which still date to 12 July 2010. > > 4) Suspicion arises that omitting compilation or copy of m3bundle causes the failed compile process. > > 5) Obviously the "cm3" folder in CM3 (git) is not a sufficient source for executing the compiler. Hence I recommend there should be a target "build" system inside the git working repository as a result of any "upgrade" or "build" script. This build area should be the primary target of all scripts targeting at ensuring a workable compiler installation. Then in a secondary step, which may also be scripted but may also be omitted, copy from this area can be taken to update, upgrade or build new any other installation. The "build" area in git can be set to .gitignore so it doesn't litter up the tracking system. Is that an idea to follow? > > - Wolfgang > > Am 08.10.2016 um 01:24 schrieb Rodney M. Bates: >> >> >> On 10/07/2016 01:26 PM, Wolfgang Keller wrote: >>> >>> >>> Am 07.10.2016 um 18:17 schrieb Rodney M. Bates: >>>> >>>> >>>> On 10/07/2016 03:53 AM, Wolfgang Keller wrote: >>>>> I attempted at compiler compilation and found a few peculiar things. >>>>> >>>>> 1. The Result >>>>> >>>>> Critical Mass Modula-3 version d5.10.0 >>>>> last updated: 2015-05-21 >>>>> compiled: 2016-10-07 03:58:31 >>>>> configuration: /home/user/Projekte/M3-Test2/bin/cm3.cfg >>>>> host: AMD64_LINUX >>>>> target: AMD64_LINUX >>>>> >>>>> This is how cm3 identifies. >>>>> >>>>> a) "last updated" - since you modified the sources, should there be a younger date? >>>> >>>> Yes. This is now manually updated in scripts/version.quake. >>>> >>>> m3devel list: We need to do this with every commit, or else automate it. >>>> >>>>> >>>>> b) compilation results (executables) as well as configuration file have been put into CM3 (Git version) folders and into the "independent" installation of the older version of CM3, i.e. 5.8.6. I see this critical! The independent installation should stay unmodified in its functionality. Users might wish to continue to use it, e.g. when the newer version proves buggy or otherwise undesirable. >>>>> >>>> >>>> Yes, we have been working on this. You can recreate a clean release installation at >>>> any time, but it's a real pain for intermediate versions during development. I am >>>> very conservative about saving existing versions before touching the compiler or its >>>> core libraries, either by copying critical executable file and library files, or making >>>> whole copies of /usr/local/cm3. >>>> >>>>> c) Erroneous execution. When calling "cm3" in the "cm3ide" directory it does not compile and the text result is >>>>> >>>>> -- begin -- >>>>> --- building in AMD64_LINUX --- >>>>> >>>>> ignoring ../src/m3overrides >>>>> >>>>> Fatal Error: bad version stamps: ConnFD.i3 >>>>> >>>>> inconsistent opaque object info for type _t1541f475 >>>>> super type: _te422a136 data: (size: 64, align: 64) method: (size: 0) >>>>> => ConnFD.i3 >>>>> super type: _te422a136 data: (size: 192, align: 64) method: (size: 0) >>>>> => ThreadPThread.m3 >>>>> >>>>> -- end -- >>>>> >>>> >>>> This is almost certainly a need for complete recompile of cm3ide. Try, in >>>> the cm3ide directory: >>>> >>>> cm3 -realclean >>>> cm3 >>>> >>>> >>>> Within a package, the compiler infers from source code what needs to be recompiled >>>> and does so. Between packages, and for certain kinds of changes in machine-level >>>> types, it can only detect incompatibilities. This is rare. The messages are >>>> highly uninformative, but fixing them requires changes to the compiler's internal >>>> intermediate representation, which entails widespread, but mundane code changes. >>>> I have undertaken some of this previously, but it hasn't had the highest priority. >>> >>> Taking your advice it results in the following: >>> >>> -- begin -- >>> --- building in AMD64_LINUX --- >>> >>> ignoring ../src/m3overrides >>> >>> /home/user/Projekte/M3-Test2/bin/m3bundle -name CM3_IDE_Bundle -F/tmp/qk >>> new source -> compiling Buf.i3 >>> new source -> compiling Buf.m3 >>> new source -> compiling ErrLog.i3 >>> new source -> compiling ErrLog.m3 >>> >>> Fatal Error: bad version stamps: ConnFD.i3 >>> >>> inconsistent opaque object info for type _t1541f475 >>> super type: _te422a136 data: (size: 64, align: 64) method: (size: 0) >>> => ConnFD.i3 >>> super type: _te422a136 data: (size: 192, align: 64) method: (size: 0) >>> => ThreadPThread.m3 >>> -- end -- >>> >>> Obviously compilation takes reference into the "other" installation and resulting in inconsistencies. Why does it do so? This is the type of mixed up configurations that I have been speaking of! Up to now I don't quite understand how people are working with this system. Does it work for you? >>> >> >> It's the other way around. ConnFD.i3 has an old, already compiled version around that >> depends on something in ThreadPThread, which has changed and been recently recompiled. >> ConnFD.i3 now needs to be recompiled to adapt, now that a new libm3core is installed >> (which ThreadPThread is part of). >> >> I should have looked at where ConnFD.i3 is located. It's in package group m3-comm, which >> upgrade.sh apparently didn't rebuild. So try this, as I just did: >> >> in directory scripts: >> >> ./do-cm3-comm.sh realclean >> ,/do-cm3-comm.sh buildship >> >> Then try rebuilding cm3ide. There could be more things that haven't been rebuilt >> by update.sh. I would predict that m3-ui and m3-db haven't, though I doubt cm3ide >> needs m3-ui. There are do-cm3-*.sh scripts for a lot of these groups. >> >> I have worked in compilation systems for modular languages that have a two-level >> automatic rebuild system. Modula-3 does not. The automatic rebuild only works >> within a package. It would be nice to have one. >> >>> Theoretically, the missing file attributes may have had an impact on the results of the upgrade. Who knows? >>> >>> >>> >>> >> > > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Mon Oct 10 19:16:58 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 10 Oct 2016 12:16:58 -0500 Subject: [M3devel] CM3 report compiler compilation In-Reply-To: <57FAA71D.6010608@lcwb.coop> References: <3e952b47-e471-764c-08ec-ba3f8e1df117@gmx.de> <57F7CA9D.50302@lcwb.coop> <57F82E90.1080108@lcwb.coop> <57FAA71D.6010608@lcwb.coop> Message-ID: <57FBCD0A.7010502@lcwb.coop> On 10/09/2016 03:22 PM, Rodney M. Bates wrote: > While there is plenty of room for improvement in CM3, perhaps it has > provoked for you, a crisis of rising expectations, leading you to > apply a higher standard than to other build systems. The Modula-3 > language and the CM3 implementation of it are already far ahead of the > prevailing standard for software build systems. > > For *within* a package, CM3 automatically detects and carries out any > recompilation necessary due to changes, and on a declaration > granularity. If an interface you import has been changed only in > declarations you do not actually reference, your code need not be > recompiled. Compare this to C/C++/Make, where, if the file you depend > on has been touched in any way, even just editing of comments or just > changing its recorded date, your file has to be recompiled. > > Moreover, the dependencies have to be manually written into a > Makefile, or the recompilation will not occur when it is necessary. > There are side tools around that will automatically generate Makefile > dependencies, but they can only judge on the basis of #include lines, > not actual uses. They have to be rerun along with every > recompilation, or else, inevitably, the Makefile will get out of date. > That can lead to very difficult-to-diagnose bugs that often don't show > up for a long time later, after many unrelated changes and rebuilds. > > Such tools cannot help with the very difficult task of discovering > when a #include has become unnecessary. This is extremely difficult > to find, and requires combing through the entire closure of #includes, > in order, not just the direct ones, looking for referenced > declarations. CM3, in contrast will warn of an IMPORT that is not > needed. BTW, in Modula-3,only the direct IMPORTs need to be examined. > > Between packages, CM3 always detects incompatibilities. In most > systems, the closest you get to this is via a package manager, e.g., > APT or RPM. Again, for these to work, somebody has to manually note > the dependencies in the package. These are even coarser than > file-granularity. They can only use library names, with embedded > version numbers, to detect problems. There is nothing to check > whether the version numbers correctly reflect incompatibilities. What > detection does happen is delayed from link time to install time. And > you have to manually rebuild the library to fix it. > > CM3 will always detect, at declaration granularity, at link time, when > such an incompatibility exists, with no extra manual effort beyond the > actual modification itself. The worst you can criticize is that the > messages are not very informative (but still much better), and as > above, you have to ask for a recompile of your package. > > But the situation that brought this all up goes even deeper. There, > package cm3ide links in file ConnFD.i3, in package tcp, with object > code in libm3tcp.so, which needs to be recompiled because it links in > ThreadPThread.m3, in package m3core, compiled into libm3core.so. This > is (non-trivial) *transitive* dependency in the link closure of > libraries. CM3 detected this, but has to be asked manually to do the > necessary recompilation. I am far from knowledgeable about all build > systems in existence, but I would be be very surprised if more than > one or two others do even this detection. Actually, I described this wrongly, or at oversimplifiedly. What I am sure really happed here is cm3ide links in m3core directly, and also links in tcp, which, the last time it was compiled, linked in a different (earlier, in this case, but not necessarily, in general) version of m3core, which is what CM3 complained about. It detected this directly from type definitions, without needing version numbers, file names, dates, etc. It does however, rely on having the compiler-generated .M3WEB file for m3core properly installed beside the library. > > I am not even sure one would want a build system to automatically > transitively rebuild across multiple libraries. It might work > when all the libraries are in a single repository like Modula3-cm3. > But often, programs use libraries from very different projects, > with source code in far-flung places, if available at all. > > I suppose one could write a Makefile that notes when a linked-in > library depends on another linked-in library. I doubt this has been > done very often. Even so, it would at best, detect only at whole > library granularity. > > > > On 10/08/2016 01:22 AM, Wolfgang Keller wrote: >> The "upgrade" process claims to update a target installation system (perhaps also called the "work installation"). In my test case this was in " /home/user/Projekte/M3-Test2/". This is also the system which is made available in global environment paths. >> >> 1) If - after creation of the target system - compiling "cm3" within "cm3ide" of CM3 (git) fails then the claim to having built a valid upgrade has also failed (if we assume that cm3ide holds a valid composition of sources). >> >> 2) The compile process reports taking reference to m3bundle which appears to imply it is an essential part of the core compiler. >> >> "/home/user/Projekte/M3-Test2/bin/m3bundle -name CM3_IDE_Bundle -F/tmp/qk >> new source -> compiling Buf.i3 >> new source -> compiling Buf.m3 >> new source -> compiling ErrLog.i3 >> new source -> compiling ErrLog.m3 >> >> Fatal Error: bad version stamps: ConnFD.i3" >> >> 3) If we look at the /bin directory of the target system, we find some updated executables with the exception of "cm3ide" and "m3bundle" which still date to 12 July 2010. >> >> 4) Suspicion arises that omitting compilation or copy of m3bundle causes the failed compile process. >> >> 5) Obviously the "cm3" folder in CM3 (git) is not a sufficient source for executing the compiler. Hence I recommend there should be a target "build" system inside the git working repository as a result of any "upgrade" or "build" script. This build area should be the primary target of all scripts targeting at ensuring a workable compiler installation. Then in a secondary step, which may also be scripted but may also be omitted, copy from this area can be taken to update, upgrade or build new any other installation. The "build" area in git can be set to .gitignore so it doesn't litter up the tracking system. Is that an idea to follow? >> >> - Wolfgang >> >> Am 08.10.2016 um 01:24 schrieb Rodney M. Bates: >>> >>> >>> On 10/07/2016 01:26 PM, Wolfgang Keller wrote: >>>> >>>> >>>> Am 07.10.2016 um 18:17 schrieb Rodney M. Bates: >>>>> >>>>> >>>>> On 10/07/2016 03:53 AM, Wolfgang Keller wrote: >>>>>> I attempted at compiler compilation and found a few peculiar things. >>>>>> >>>>>> 1. The Result >>>>>> >>>>>> Critical Mass Modula-3 version d5.10.0 >>>>>> last updated: 2015-05-21 >>>>>> compiled: 2016-10-07 03:58:31 >>>>>> configuration: /home/user/Projekte/M3-Test2/bin/cm3.cfg >>>>>> host: AMD64_LINUX >>>>>> target: AMD64_LINUX >>>>>> >>>>>> This is how cm3 identifies. >>>>>> >>>>>> a) "last updated" - since you modified the sources, should there be a younger date? >>>>> >>>>> Yes. This is now manually updated in scripts/version.quake. >>>>> >>>>> m3devel list: We need to do this with every commit, or else automate it. >>>>> >>>>>> >>>>>> b) compilation results (executables) as well as configuration file have been put into CM3 (Git version) folders and into the "independent" installation of the older version of CM3, i.e. 5.8.6. I see this critical! The independent installation should stay unmodified in its functionality. Users might wish to continue to use it, e.g. when the newer version proves buggy or otherwise undesirable. >>>>>> >>>>> >>>>> Yes, we have been working on this. You can recreate a clean release installation at >>>>> any time, but it's a real pain for intermediate versions during development. I am >>>>> very conservative about saving existing versions before touching the compiler or its >>>>> core libraries, either by copying critical executable file and library files, or making >>>>> whole copies of /usr/local/cm3. >>>>> >>>>>> c) Erroneous execution. When calling "cm3" in the "cm3ide" directory it does not compile and the text result is >>>>>> >>>>>> -- begin -- >>>>>> --- building in AMD64_LINUX --- >>>>>> >>>>>> ignoring ../src/m3overrides >>>>>> >>>>>> Fatal Error: bad version stamps: ConnFD.i3 >>>>>> >>>>>> inconsistent opaque object info for type _t1541f475 >>>>>> super type: _te422a136 data: (size: 64, align: 64) method: (size: 0) >>>>>> => ConnFD.i3 >>>>>> super type: _te422a136 data: (size: 192, align: 64) method: (size: 0) >>>>>> => ThreadPThread.m3 >>>>>> >>>>>> -- end -- >>>>>> >>>>> >>>>> This is almost certainly a need for complete recompile of cm3ide. Try, in >>>>> the cm3ide directory: >>>>> >>>>> cm3 -realclean >>>>> cm3 >>>>> >>>>> >>>>> Within a package, the compiler infers from source code what needs to be recompiled >>>>> and does so. Between packages, and for certain kinds of changes in machine-level >>>>> types, it can only detect incompatibilities. This is rare. The messages are >>>>> highly uninformative, but fixing them requires changes to the compiler's internal >>>>> intermediate representation, which entails widespread, but mundane code changes. >>>>> I have undertaken some of this previously, but it hasn't had the highest priority. >>>> >>>> Taking your advice it results in the following: >>>> >>>> -- begin -- >>>> --- building in AMD64_LINUX --- >>>> >>>> ignoring ../src/m3overrides >>>> >>>> /home/user/Projekte/M3-Test2/bin/m3bundle -name CM3_IDE_Bundle -F/tmp/qk >>>> new source -> compiling Buf.i3 >>>> new source -> compiling Buf.m3 >>>> new source -> compiling ErrLog.i3 >>>> new source -> compiling ErrLog.m3 >>>> >>>> Fatal Error: bad version stamps: ConnFD.i3 >>>> >>>> inconsistent opaque object info for type _t1541f475 >>>> super type: _te422a136 data: (size: 64, align: 64) method: (size: 0) >>>> => ConnFD.i3 >>>> super type: _te422a136 data: (size: 192, align: 64) method: (size: 0) >>>> => ThreadPThread.m3 >>>> -- end -- >>>> >>>> Obviously compilation takes reference into the "other" installation and resulting in inconsistencies. Why does it do so? This is the type of mixed up configurations that I have been speaking of! Up to now I don't quite understand how people are working with this system. Does it work for you? >>>> >>> >>> It's the other way around. ConnFD.i3 has an old, already compiled version around that >>> depends on something in ThreadPThread, which has changed and been recently recompiled. >>> ConnFD.i3 now needs to be recompiled to adapt, now that a new libm3core is installed >>> (which ThreadPThread is part of). >>> >>> I should have looked at where ConnFD.i3 is located. It's in package group m3-comm, which >>> upgrade.sh apparently didn't rebuild. So try this, as I just did: >>> >>> in directory scripts: >>> >>> ./do-cm3-comm.sh realclean >>> ,/do-cm3-comm.sh buildship >>> >>> Then try rebuilding cm3ide. There could be more things that haven't been rebuilt >>> by update.sh. I would predict that m3-ui and m3-db haven't, though I doubt cm3ide >>> needs m3-ui. There are do-cm3-*.sh scripts for a lot of these groups. >>> >>> I have worked in compilation systems for modular languages that have a two-level >>> automatic rebuild system. Modula-3 does not. The automatic rebuild only works >>> within a package. It would be nice to have one. >>> >>>> Theoretically, the missing file attributes may have had an impact on the results of the upgrade. Who knows? >>>> >>>> >>>> >>>> >>> >> >> > -- Rodney Bates rodney.m.bates at acm.org From lists at darko.org Tue Oct 11 12:29:37 2016 From: lists at darko.org (Darko Volaric) Date: Tue, 11 Oct 2016 12:29:37 +0200 Subject: [M3devel] CM3 report compiler compilation In-Reply-To: <57FBCD0A.7010502@lcwb.coop> References: <3e952b47-e471-764c-08ec-ba3f8e1df117@gmx.de> <57F7CA9D.50302@lcwb.coop> <57F82E90.1080108@lcwb.coop> <57FAA71D.6010608@lcwb.coop> <57FBCD0A.7010502@lcwb.coop> Message-ID: Wolfgang - are you subscribed to the list? I can't see any of your original emails, just those quoted. I've been thinking about this what seems to be missing is a "project" based approach. I emulate this by using include_dir instead of import and makefile overrides (for technical reasons), but right now makefiles don't let you nominate what libraries/packages are part of the active project and what are a part of another project. When a large project, such as the compiler, involves several separate libraries/packages, you ought to be able to nominate them for rebuilding as required from the client package, instead of just importing whatever was last shipped. Instead we have the build scripts which are an unreliable and ugly hack. You may not want to have the compiler try to divine what should be rebuilt across arbitary packages, but you should be able to nominate what packages belong to the same project and have the compiler manage the builds. On Mon, Oct 10, 2016 at 7:16 PM, Rodney M. Bates wrote: > > > On 10/09/2016 03:22 PM, Rodney M. Bates wrote: > >> While there is plenty of room for improvement in CM3, perhaps it has >> provoked for you, a crisis of rising expectations, leading you to >> apply a higher standard than to other build systems. The Modula-3 >> language and the CM3 implementation of it are already far ahead of the >> prevailing standard for software build systems. >> >> For *within* a package, CM3 automatically detects and carries out any >> recompilation necessary due to changes, and on a declaration >> granularity. If an interface you import has been changed only in >> declarations you do not actually reference, your code need not be >> recompiled. Compare this to C/C++/Make, where, if the file you depend >> on has been touched in any way, even just editing of comments or just >> changing its recorded date, your file has to be recompiled. >> >> Moreover, the dependencies have to be manually written into a >> Makefile, or the recompilation will not occur when it is necessary. >> There are side tools around that will automatically generate Makefile >> dependencies, but they can only judge on the basis of #include lines, >> not actual uses. They have to be rerun along with every >> recompilation, or else, inevitably, the Makefile will get out of date. >> That can lead to very difficult-to-diagnose bugs that often don't show >> up for a long time later, after many unrelated changes and rebuilds. >> >> Such tools cannot help with the very difficult task of discovering >> when a #include has become unnecessary. This is extremely difficult >> to find, and requires combing through the entire closure of #includes, >> in order, not just the direct ones, looking for referenced >> declarations. CM3, in contrast will warn of an IMPORT that is not >> needed. BTW, in Modula-3,only the direct IMPORTs need to be examined. >> >> Between packages, CM3 always detects incompatibilities. In most >> systems, the closest you get to this is via a package manager, e.g., >> APT or RPM. Again, for these to work, somebody has to manually note >> the dependencies in the package. These are even coarser than >> file-granularity. They can only use library names, with embedded >> version numbers, to detect problems. There is nothing to check >> whether the version numbers correctly reflect incompatibilities. What >> detection does happen is delayed from link time to install time. And >> you have to manually rebuild the library to fix it. >> >> CM3 will always detect, at declaration granularity, at link time, when >> such an incompatibility exists, with no extra manual effort beyond the >> actual modification itself. The worst you can criticize is that the >> messages are not very informative (but still much better), and as >> above, you have to ask for a recompile of your package. >> >> But the situation that brought this all up goes even deeper. There, >> package cm3ide links in file ConnFD.i3, in package tcp, with object >> code in libm3tcp.so, which needs to be recompiled because it links in >> ThreadPThread.m3, in package m3core, compiled into libm3core.so. This >> is (non-trivial) *transitive* dependency in the link closure of >> libraries. CM3 detected this, but has to be asked manually to do the >> necessary recompilation. I am far from knowledgeable about all build >> systems in existence, but I would be be very surprised if more than >> one or two others do even this detection. >> > > Actually, I described this wrongly, or at oversimplifiedly. > What I am sure really happed here is cm3ide links in m3core directly, > and also links in tcp, which, the last time it was compiled, > linked in a different (earlier, in this case, but not necessarily, > in general) version of m3core, which is what CM3 > complained about. It detected this directly from type > definitions, without needing version numbers, file names, > dates, etc. It does however, rely on having the compiler-generated > .M3WEB file for m3core properly installed beside the library. > > > >> I am not even sure one would want a build system to automatically >> transitively rebuild across multiple libraries. It might work >> when all the libraries are in a single repository like Modula3-cm3. >> But often, programs use libraries from very different projects, >> with source code in far-flung places, if available at all. >> >> I suppose one could write a Makefile that notes when a linked-in >> library depends on another linked-in library. I doubt this has been >> done very often. Even so, it would at best, detect only at whole >> library granularity. >> >> >> >> On 10/08/2016 01:22 AM, Wolfgang Keller wrote: >> >>> The "upgrade" process claims to update a target installation system >>> (perhaps also called the "work installation"). In my test case this was in >>> " /home/user/Projekte/M3-Test2/". This is also the system which is made >>> available in global environment paths. >>> >>> 1) If - after creation of the target system - compiling "cm3" within >>> "cm3ide" of CM3 (git) fails then the claim to having built a valid upgrade >>> has also failed (if we assume that cm3ide holds a valid composition of >>> sources). >>> >>> 2) The compile process reports taking reference to m3bundle which >>> appears to imply it is an essential part of the core compiler. >>> >>> "/home/user/Projekte/M3-Test2/bin/m3bundle -name CM3_IDE_Bundle >>> -F/tmp/qk >>> new source -> compiling Buf.i3 >>> new source -> compiling Buf.m3 >>> new source -> compiling ErrLog.i3 >>> new source -> compiling ErrLog.m3 >>> >>> Fatal Error: bad version stamps: ConnFD.i3" >>> >>> 3) If we look at the /bin directory of the target system, we find some >>> updated executables with the exception of "cm3ide" and "m3bundle" which >>> still date to 12 July 2010. >>> >>> 4) Suspicion arises that omitting compilation or copy of m3bundle causes >>> the failed compile process. >>> >>> 5) Obviously the "cm3" folder in CM3 (git) is not a sufficient source >>> for executing the compiler. Hence I recommend there should be a target >>> "build" system inside the git working repository as a result of any >>> "upgrade" or "build" script. This build area should be the primary target >>> of all scripts targeting at ensuring a workable compiler installation. Then >>> in a secondary step, which may also be scripted but may also be omitted, >>> copy from this area can be taken to update, upgrade or build new any other >>> installation. The "build" area in git can be set to .gitignore so it >>> doesn't litter up the tracking system. Is that an idea to follow? >>> >>> - Wolfgang >>> >>> Am 08.10.2016 um 01:24 schrieb Rodney M. Bates: >>> >>>> >>>> >>>> On 10/07/2016 01:26 PM, Wolfgang Keller wrote: >>>> >>>>> >>>>> >>>>> Am 07.10.2016 um 18:17 schrieb Rodney M. Bates: >>>>> >>>>>> >>>>>> >>>>>> On 10/07/2016 03:53 AM, Wolfgang Keller wrote: >>>>>> >>>>>>> I attempted at compiler compilation and found a few peculiar things. >>>>>>> >>>>>>> 1. The Result >>>>>>> >>>>>>> Critical Mass Modula-3 version d5.10.0 >>>>>>> last updated: 2015-05-21 >>>>>>> compiled: 2016-10-07 03:58:31 >>>>>>> configuration: /home/user/Projekte/M3-Test2/bin/cm3.cfg >>>>>>> host: AMD64_LINUX >>>>>>> target: AMD64_LINUX >>>>>>> >>>>>>> This is how cm3 identifies. >>>>>>> >>>>>>> a) "last updated" - since you modified the sources, should there be >>>>>>> a younger date? >>>>>>> >>>>>> >>>>>> Yes. This is now manually updated in scripts/version.quake. >>>>>> >>>>>> m3devel list: We need to do this with every commit, or else automate >>>>>> it. >>>>>> >>>>>> >>>>>>> b) compilation results (executables) as well as configuration file >>>>>>> have been put into CM3 (Git version) folders and into the "independent" >>>>>>> installation of the older version of CM3, i.e. 5.8.6. I see this critical! >>>>>>> The independent installation should stay unmodified in its functionality. >>>>>>> Users might wish to continue to use it, e.g. when the newer version proves >>>>>>> buggy or otherwise undesirable. >>>>>>> >>>>>>> >>>>>> Yes, we have been working on this. You can recreate a clean release >>>>>> installation at >>>>>> any time, but it's a real pain for intermediate versions during >>>>>> development. I am >>>>>> very conservative about saving existing versions before touching the >>>>>> compiler or its >>>>>> core libraries, either by copying critical executable file and >>>>>> library files, or making >>>>>> whole copies of /usr/local/cm3. >>>>>> >>>>>> c) Erroneous execution. When calling "cm3" in the "cm3ide" directory >>>>>>> it does not compile and the text result is >>>>>>> >>>>>>> -- begin -- >>>>>>> --- building in AMD64_LINUX --- >>>>>>> >>>>>>> ignoring ../src/m3overrides >>>>>>> >>>>>>> Fatal Error: bad version stamps: ConnFD.i3 >>>>>>> >>>>>>> inconsistent opaque object info for type _t1541f475 >>>>>>> super type: _te422a136 data: (size: 64, align: 64) method: (size: >>>>>>> 0) >>>>>>> => ConnFD.i3 >>>>>>> super type: _te422a136 data: (size: 192, align: 64) method: (size: >>>>>>> 0) >>>>>>> => ThreadPThread.m3 >>>>>>> >>>>>>> -- end -- >>>>>>> >>>>>>> >>>>>> This is almost certainly a need for complete recompile of cm3ide. >>>>>> Try, in >>>>>> the cm3ide directory: >>>>>> >>>>>> cm3 -realclean >>>>>> cm3 >>>>>> >>>>>> >>>>>> Within a package, the compiler infers from source code what needs to >>>>>> be recompiled >>>>>> and does so. Between packages, and for certain kinds of changes in >>>>>> machine-level >>>>>> types, it can only detect incompatibilities. This is rare. The >>>>>> messages are >>>>>> highly uninformative, but fixing them requires changes to the >>>>>> compiler's internal >>>>>> intermediate representation, which entails widespread, but mundane >>>>>> code changes. >>>>>> I have undertaken some of this previously, but it hasn't had the >>>>>> highest priority. >>>>>> >>>>> >>>>> Taking your advice it results in the following: >>>>> >>>>> -- begin -- >>>>> --- building in AMD64_LINUX --- >>>>> >>>>> ignoring ../src/m3overrides >>>>> >>>>> /home/user/Projekte/M3-Test2/bin/m3bundle -name CM3_IDE_Bundle >>>>> -F/tmp/qk >>>>> new source -> compiling Buf.i3 >>>>> new source -> compiling Buf.m3 >>>>> new source -> compiling ErrLog.i3 >>>>> new source -> compiling ErrLog.m3 >>>>> >>>>> Fatal Error: bad version stamps: ConnFD.i3 >>>>> >>>>> inconsistent opaque object info for type _t1541f475 >>>>> super type: _te422a136 data: (size: 64, align: 64) method: (size: 0) >>>>> => ConnFD.i3 >>>>> super type: _te422a136 data: (size: 192, align: 64) method: (size: 0) >>>>> => ThreadPThread.m3 >>>>> -- end -- >>>>> >>>>> Obviously compilation takes reference into the "other" installation >>>>> and resulting in inconsistencies. Why does it do so? This is the type of >>>>> mixed up configurations that I have been speaking of! Up to now I don't >>>>> quite understand how people are working with this system. Does it work for >>>>> you? >>>>> >>>>> >>>> It's the other way around. ConnFD.i3 has an old, already compiled >>>> version around that >>>> depends on something in ThreadPThread, which has changed and been >>>> recently recompiled. >>>> ConnFD.i3 now needs to be recompiled to adapt, now that a new libm3core >>>> is installed >>>> (which ThreadPThread is part of). >>>> >>>> I should have looked at where ConnFD.i3 is located. It's in package >>>> group m3-comm, which >>>> upgrade.sh apparently didn't rebuild. So try this, as I just did: >>>> >>>> in directory scripts: >>>> >>>> ./do-cm3-comm.sh realclean >>>> ,/do-cm3-comm.sh buildship >>>> >>>> Then try rebuilding cm3ide. There could be more things that haven't >>>> been rebuilt >>>> by update.sh. I would predict that m3-ui and m3-db haven't, though I >>>> doubt cm3ide >>>> needs m3-ui. There are do-cm3-*.sh scripts for a lot of these groups. >>>> >>>> I have worked in compilation systems for modular languages that have a >>>> two-level >>>> automatic rebuild system. Modula-3 does not. The automatic rebuild >>>> only works >>>> within a package. It would be nice to have one. >>>> >>>> Theoretically, the missing file attributes may have had an impact on >>>>> the results of the upgrade. Who knows? >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >> > -- > Rodney Bates > rodney.m.bates at acm.org > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://m3lists.elegosoft.com/mailman/listinfo/m3devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Tue Oct 11 20:37:57 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 11 Oct 2016 13:37:57 -0500 Subject: [M3devel] CM3 report compiler compilation In-Reply-To: <5cbd0f6d-57f0-a283-cb40-32352a447513@gmx.de> References: <3e952b47-e471-764c-08ec-ba3f8e1df117@gmx.de> <57F7CA9D.50302@lcwb.coop> <57F82E90.1080108@lcwb.coop> <57FAA71D.6010608@lcwb.coop> <57FBCD0A.7010502@lcwb.coop> <5cbd0f6d-57f0-a283-cb40-32352a447513@gmx.de> Message-ID: <57FD3185.5020803@lcwb.coop> On 10/11/2016 02:48 AM, Wolfgang Keller wrote: > > > Am 10.10.2016 um 19:16 schrieb Rodney M. Bates: >> >> >> On 10/09/2016 03:22 PM, Rodney M. Bates wrote: >>> While there is plenty of room for improvement in CM3, perhaps it has >>> provoked for you, a crisis of rising expectations, leading you to >>> apply a higher standard than to other build systems. The Modula-3 >>> language and the CM3 implementation of it are already far ahead of the >>> prevailing standard for software build systems. > > The latter may be true when compared to COBOL and C. The C development system in antiquity of engineering and has only survived today because of its inviting openness for all sorts of unmaintainability manifestations. Many programmers and developers still measure their personal importance by means of length and difficulty of their work, not to forget! And some do get paid for. - For a reason, Pascal and Ada have been developed to allow for a better controlled building and development process, and these are the more suitable languages to compare to! > > >>> For *within* a package, CM3 automatically detects and carries out any >>> recompilation necessary due to changes, and on a declaration >>> granularity. If an interface you import has been changed only in >>> declarations you do not actually reference, your code need not be >>> recompiled. > > >>> Compare this to C/C++/Make, where, if the file you depend >>> on has been touched in any way, even just editing of comments or just >>> changing its recorded date, your file has to be recompiled. >>> >>> Moreover, the dependencies have to be manually written into a >>> Makefile, or the recompilation will not occur when it is necessary. >>> There are side tools around that will automatically generate Makefile >>> dependencies, but they can only judge on the basis of #include lines, >>> not actual uses. They have to be rerun along with every >>> recompilation, or else, inevitably, the Makefile will get out of date. >>> That can lead to very difficult-to-diagnose bugs that often don't show >>> up for a long time later, after many unrelated changes and rebuilds. >>> >>> Such tools cannot help with the very difficult task of discovering >>> when a #include has become unnecessary. This is extremely difficult >>> to find, and requires combing through the entire closure of #includes, >>> in order, not just the direct ones, looking for referenced >>> declarations. CM3, in contrast will warn of an IMPORT that is not >>> needed. BTW, in Modula-3,only the direct IMPORTs need to be examined. >>> >>> Between packages, CM3 always detects incompatibilities. In most >>> systems, the closest you get to this is via a package manager, e.g., >>> APT or RPM. Again, for these to work, somebody has to manually note >>> the dependencies in the package. These are even coarser than >>> file-granularity. They can only use library names, with embedded >>> version numbers, to detect problems. There is nothing to check >>> whether the version numbers correctly reflect incompatibilities. What >>> detection does happen is delayed from link time to install time. And >>> you have to manually rebuild the library to fix it. >>> >>> CM3 will always detect, at declaration granularity, at link time, when >>> such an incompatibility exists, with no extra manual effort beyond the >>> actual modification itself. The worst you can criticize is that the >>> messages are not very informative (but still much better), and as >>> above, you have to ask for a recompile of your package. > > That is one point, yes, that > > Fatal Error: bad version stamps: ConnFD.i3" > > is not informative above the core type of error. It should name all involved modules and result with a recommendation of action to be taken, if such an inference can be made. The current user feedback is not very practical! > >>> >>> But the situation that brought this all up goes even deeper. There, >>> package cm3ide links in file ConnFD.i3, in package tcp, with object >>> code in libm3tcp.so, which needs to be recompiled because it links in >>> ThreadPThread.m3, in package m3core, compiled into libm3core.so. This >>> is (non-trivial) *transitive* dependency in the link closure of >>> libraries. CM3 detected this, but has to be asked manually to do the >>> necessary recompilation. I am far from knowledgeable about all build >>> systems in existence, but I would be be very surprised if more than >>> one or two others do even this detection. >> >> Actually, I described this wrongly, or at oversimplifiedly. >> What I am sure really happed here is cm3ide links in m3core directly, >> and also links in tcp, which, the last time it was compiled, >> linked in a different (earlier, in this case, but not necessarily, >> in general) version of m3core, which is what CM3 >> complained about. It detected this directly from type >> definitions, without needing version numbers, file names, >> dates, etc. It does however, rely on having the compiler-generated >> .M3WEB file for m3core properly installed beside the library. >> > > What ever one may say about the depth of transitive recompiling, on thing is certain: a script inside CM3 which claims to build a target system must make sure it correctly does so. Can we agree on that? There may be a need to organise packages and compilations in a way that ensures a consistent rebuild. That is what the "make" files are traditionally good for. As it seems from your report, cm3 is not free for the need of such. > > The objective appears quite simple: make sure only packages are referenced which are of the same compiler version-id. If this is not the case and the source is available -> recompile, otherwise break with an error msg. If package + source are only available remote, consider to recompile to a local copy (not replacing the remote binary). Such behaviour can be made dependent on pragmas and compiler switches. There could be a problem with cyclic package references, but I assume you can also solve that during linkage. That's, I admit, my guess here. ;) > I has just occurred to me that you probably view an IDE as fundamental part of the development system. I have been thinking of it as an independent tool, similar to the many other executables in the repository, since I had never tried it until just recently. Apparently, not many others have either, or the looping would have been noticed earlier. BTW, I have tracked at least one instance of the looping to a LONGREAL arithmetic bug in ThreadPThread itself, so it's not cm3ide's fault. So far, it's not so clear what to do about it. It involves busy waiting for network traffic, and that's a delicate balance. >>> >>> I am not even sure one would want a build system to automatically >>> transitively rebuild across multiple libraries. It might work >>> when all the libraries are in a single repository like Modula3-cm3. >>> But often, programs use libraries from very different projects, >>> with source code in far-flung places, if available at all. >>> >>> I suppose one could write a Makefile that notes when a linked-in >>> library depends on another linked-in library. I doubt this has been >>> done very often. Even so, it would at best, detect only at whole >>> library granularity. >>> >>> >>> >>> On 10/08/2016 01:22 AM, Wolfgang Keller wrote: >>>> The "upgrade" process claims to update a target installation system (perhaps also called the "work installation"). In my test case this was in " /home/user/Projekte/M3-Test2/". This is also the system which is made available in global environment paths. >>>> >>>> 1) If - after creation of the target system - compiling "cm3" within "cm3ide" of CM3 (git) fails then the claim to having built a valid upgrade has also failed (if we assume that cm3ide holds a valid composition of sources). >>>> >>>> 2) The compile process reports taking reference to m3bundle which appears to imply it is an essential part of the core compiler. >>>> >>>> "/home/user/Projekte/M3-Test2/bin/m3bundle -name CM3_IDE_Bundle -F/tmp/qk >>>> new source -> compiling Buf.i3 >>>> new source -> compiling Buf.m3 >>>> new source -> compiling ErrLog.i3 >>>> new source -> compiling ErrLog.m3 >>>> >>>> Fatal Error: bad version stamps: ConnFD.i3" >>>> >>>> 3) If we look at the /bin directory of the target system, we find some updated executables with the exception of "cm3ide" and "m3bundle" which still date to 12 July 2010. >>>> >>>> 4) Suspicion arises that omitting compilation or copy of m3bundle causes the failed compile process. >>>> >>>> 5) Obviously the "cm3" folder in CM3 (git) is not a sufficient source for executing the compiler. Hence I recommend there should be a target "build" system inside the git working repository as a result of any "upgrade" or "build" script. This build area should be the primary target of all scripts targeting at ensuring a workable compiler installation. Then in a secondary step, which may also be scripted but may also be omitted, copy from this area can be taken to update, upgrade or build new any other installation. The "build" area in git can be set to .gitignore so it doesn't litter up the tracking system. Is that an idea to follow? >>>> >>>> - Wolfgang >>>> >>>> Am 08.10.2016 um 01:24 schrieb Rodney M. Bates: >>>>> >>>>> >>>>> On 10/07/2016 01:26 PM, Wolfgang Keller wrote: >>>>>> >>>>>> >>>>>> Am 07.10.2016 um 18:17 schrieb Rodney M. Bates: >>>>>>> >>>>>>> >>>>>>> On 10/07/2016 03:53 AM, Wolfgang Keller wrote: >>>>>>>> I attempted at compiler compilation and found a few peculiar things. >>>>>>>> >>>>>>>> 1. The Result >>>>>>>> >>>>>>>> Critical Mass Modula-3 version d5.10.0 >>>>>>>> last updated: 2015-05-21 >>>>>>>> compiled: 2016-10-07 03:58:31 >>>>>>>> configuration: /home/user/Projekte/M3-Test2/bin/cm3.cfg >>>>>>>> host: AMD64_LINUX >>>>>>>> target: AMD64_LINUX >>>>>>>> >>>>>>>> This is how cm3 identifies. >>>>>>>> >>>>>>>> a) "last updated" - since you modified the sources, should there be a younger date? >>>>>>> >>>>>>> Yes. This is now manually updated in scripts/version.quake. >>>>>>> >>>>>>> m3devel list: We need to do this with every commit, or else automate it. >>>>>>> >>>>>>>> >>>>>>>> b) compilation results (executables) as well as configuration file have been put into CM3 (Git version) folders and into the "independent" installation of the older version of CM3, i.e. 5.8.6. I see this critical! The independent installation should stay unmodified in its functionality. Users might wish to continue to use it, e.g. when the newer version proves buggy or otherwise undesirable. >>>>>>>> >>>>>>> >>>>>>> Yes, we have been working on this. You can recreate a clean release installation at >>>>>>> any time, but it's a real pain for intermediate versions during development. I am >>>>>>> very conservative about saving existing versions before touching the compiler or its >>>>>>> core libraries, either by copying critical executable file and library files, or making >>>>>>> whole copies of /usr/local/cm3. >>>>>>> >>>>>>>> c) Erroneous execution. When calling "cm3" in the "cm3ide" directory it does not compile and the text result is >>>>>>>> >>>>>>>> -- begin -- >>>>>>>> --- building in AMD64_LINUX --- >>>>>>>> >>>>>>>> ignoring ../src/m3overrides >>>>>>>> >>>>>>>> Fatal Error: bad version stamps: ConnFD.i3 >>>>>>>> >>>>>>>> inconsistent opaque object info for type _t1541f475 >>>>>>>> super type: _te422a136 data: (size: 64, align: 64) method: (size: 0) >>>>>>>> => ConnFD.i3 >>>>>>>> super type: _te422a136 data: (size: 192, align: 64) method: (size: 0) >>>>>>>> => ThreadPThread.m3 >>>>>>>> >>>>>>>> -- end -- >>>>>>>> >>>>>>> >>>>>>> This is almost certainly a need for complete recompile of cm3ide. Try, in >>>>>>> the cm3ide directory: >>>>>>> >>>>>>> cm3 -realclean >>>>>>> cm3 >>>>>>> >>>>>>> >>>>>>> Within a package, the compiler infers from source code what needs to be recompiled >>>>>>> and does so. Between packages, and for certain kinds of changes in machine-level >>>>>>> types, it can only detect incompatibilities. This is rare. The messages are >>>>>>> highly uninformative, but fixing them requires changes to the compiler's internal >>>>>>> intermediate representation, which entails widespread, but mundane code changes. >>>>>>> I have undertaken some of this previously, but it hasn't had the highest priority. >>>>>> >>>>>> Taking your advice it results in the following: >>>>>> >>>>>> -- begin -- >>>>>> --- building in AMD64_LINUX --- >>>>>> >>>>>> ignoring ../src/m3overrides >>>>>> >>>>>> /home/user/Projekte/M3-Test2/bin/m3bundle -name CM3_IDE_Bundle -F/tmp/qk >>>>>> new source -> compiling Buf.i3 >>>>>> new source -> compiling Buf.m3 >>>>>> new source -> compiling ErrLog.i3 >>>>>> new source -> compiling ErrLog.m3 >>>>>> >>>>>> Fatal Error: bad version stamps: ConnFD.i3 >>>>>> >>>>>> inconsistent opaque object info for type _t1541f475 >>>>>> super type: _te422a136 data: (size: 64, align: 64) method: (size: 0) >>>>>> => ConnFD.i3 >>>>>> super type: _te422a136 data: (size: 192, align: 64) method: (size: 0) >>>>>> => ThreadPThread.m3 >>>>>> -- end -- >>>>>> >>>>>> Obviously compilation takes reference into the "other" installation and resulting in inconsistencies. Why does it do so? This is the type of mixed up configurations that I have been speaking of! Up to now I don't quite understand how people are working with this system. Does it work for you? >>>>>> >>>>> >>>>> It's the other way around. ConnFD.i3 has an old, already compiled version around that >>>>> depends on something in ThreadPThread, which has changed and been recently recompiled. >>>>> ConnFD.i3 now needs to be recompiled to adapt, now that a new libm3core is installed >>>>> (which ThreadPThread is part of). >>>>> >>>>> I should have looked at where ConnFD.i3 is located. It's in package group m3-comm, which >>>>> upgrade.sh apparently didn't rebuild. So try this, as I just did: >>>>> >>>>> in directory scripts: >>>>> >>>>> ./do-cm3-comm.sh realclean >>>>> ,/do-cm3-comm.sh buildship >>>>> >>>>> Then try rebuilding cm3ide. There could be more things that haven't been rebuilt >>>>> by update.sh. I would predict that m3-ui and m3-db haven't, though I doubt cm3ide >>>>> needs m3-ui. There are do-cm3-*.sh scripts for a lot of these groups. >>>>> >>>>> I have worked in compilation systems for modular languages that have a two-level >>>>> automatic rebuild system. Modula-3 does not. The automatic rebuild only works >>>>> within a package. It would be nice to have one. >>>>> >>>>>> Theoretically, the missing file attributes may have had an impact on the results of the upgrade. Who knows? >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> > > -- Rodney Bates rodney.m.bates at acm.org From jayk123 at hotmail.com Wed Oct 12 10:23:52 2016 From: jayk123 at hotmail.com (Jay K) Date: Wed, 12 Oct 2016 08:23:52 +0000 Subject: [M3devel] CM3 report compiler compilation In-Reply-To: <57FD3185.5020803@lcwb.coop> References: <3e952b47-e471-764c-08ec-ba3f8e1df117@gmx.de> <57F7CA9D.50302@lcwb.coop> <57F82E90.1080108@lcwb.coop> <57FAA71D.6010608@lcwb.coop> <57FBCD0A.7010502@lcwb.coop> <5cbd0f6d-57f0-a283-cb40-32352a447513@gmx.de>,<57FD3185.5020803@lcwb.coop> Message-ID: Sorry if this is a bit meandering.. So...the "i" in IDE implies not really separate. But calling cm3ide an IDE, is a stretch of the imagination. Just because something got called an "x", does not really make it an "x". I have only used it for a few minutes and I think it'd best be called some strange web browser based thing. Kinda strange and not very useful. Now, I know there are actually semi-good web browse based development environments, but I don't think cm3ide counts. I understand command lines are unfriendly and hard to learn. I understand the browser is kinda the universal gui framework. Very tempting. Running in the browser makes you portable to Mac, Linux, Windows, phone. But it is still a struggle to make a good UI in this framework, esp. back when cm3ide was written. Modula-3 is/was ahead of its time, but a lot of systems have caught up. Modula-3 builds outside of the source tree, but only at the package level. Not at the multiple-package level. This would be good to fix. Via include_dir and flushing at package/program directives. Out of source tree builds have gained in popularity in other systems though still aren't the norm. Modula-3 compiles fast. So does everything else, except for C and C++. C++ should catch up finally with modules. Many systems don't bother even compiling these days, but are still pretty fast. The math has really inverted on this I think. Python is fast enough for many things. Java is fast enough for many things. C#. etc. Relative rarely do people resort to static compilation like C++ or Modula-3. Modula-3 is easily remoted. This isn't clearly a good feature. But many remoting facilities with varying automatedness, have been developed since. Modula-3 has a semi-platform-independent GUI. These are kinda common. Modula-3 has intra-file incremental build. That is rare, but, again, many systems compile quite fast anyway. And C and C++ still compile quite slow. The C++ compilers are actually extremely fast, but they are asked to do the same work countless times. Most other languages, with the exception of C, have surpassed Modula-3 in "expressiveness", while still stating enough that people don't complain ad nauseum about too much hidden or too many defaults. - Jay ________________________________ From: M3devel on behalf of Rodney M. Bates Sent: Tuesday, October 11, 2016 6:37 PM To: Wolfgang Keller; rodney.m.bates at acm.org; m3devel Subject: Re: [M3devel] CM3 report compiler compilation On 10/11/2016 02:48 AM, Wolfgang Keller wrote: > > > Am 10.10.2016 um 19:16 schrieb Rodney M. Bates: >> >> >> On 10/09/2016 03:22 PM, Rodney M. Bates wrote: >>> While there is plenty of room for improvement in CM3, perhaps it has >>> provoked for you, a crisis of rising expectations, leading you to >>> apply a higher standard than to other build systems. The Modula-3 >>> language and the CM3 implementation of it are already far ahead of the >>> prevailing standard for software build systems. > > The latter may be true when compared to COBOL and C. The C development system in antiquity of engineering and has only survived today because of its inviting openness for all sorts of unmaintainability manifestations. Many programmers and developers still measure their personal importance by means of length and difficulty of their work, not to forget! And some do get paid for. - For a reason, Pascal and Ada have been developed to allow for a better controlled building and development process, and these are the more suitable languages to compare to! > > >>> For *within* a package, CM3 automatically detects and carries out any >>> recompilation necessary due to changes, and on a declaration >>> granularity. If an interface you import has been changed only in >>> declarations you do not actually reference, your code need not be >>> recompiled. > > >>> Compare this to C/C++/Make, where, if the file you depend >>> on has been touched in any way, even just editing of comments or just >>> changing its recorded date, your file has to be recompiled. >>> >>> Moreover, the dependencies have to be manually written into a >>> Makefile, or the recompilation will not occur when it is necessary. >>> There are side tools around that will automatically generate Makefile >>> dependencies, but they can only judge on the basis of #include lines, >>> not actual uses. They have to be rerun along with every >>> recompilation, or else, inevitably, the Makefile will get out of date. >>> That can lead to very difficult-to-diagnose bugs that often don't show >>> up for a long time later, after many unrelated changes and rebuilds. >>> >>> Such tools cannot help with the very difficult task of discovering >>> when a #include has become unnecessary. This is extremely difficult >>> to find, and requires combing through the entire closure of #includes, >>> in order, not just the direct ones, looking for referenced >>> declarations. CM3, in contrast will warn of an IMPORT that is not >>> needed. BTW, in Modula-3,only the direct IMPORTs need to be examined. >>> >>> Between packages, CM3 always detects incompatibilities. In most >>> systems, the closest you get to this is via a package manager, e.g., >>> APT or RPM. Again, for these to work, somebody has to manually note >>> the dependencies in the package. These are even coarser than >>> file-granularity. They can only use library names, with embedded >>> version numbers, to detect problems. There is nothing to check >>> whether the version numbers correctly reflect incompatibilities. What >>> detection does happen is delayed from link time to install time. And >>> you have to manually rebuild the library to fix it. >>> >>> CM3 will always detect, at declaration granularity, at link time, when >>> such an incompatibility exists, with no extra manual effort beyond the >>> actual modification itself. The worst you can criticize is that the >>> messages are not very informative (but still much better), and as >>> above, you have to ask for a recompile of your package. > > That is one point, yes, that > > Fatal Error: bad version stamps: ConnFD.i3" > > is not informative above the core type of error. It should name all involved modules and result with a recommendation of action to be taken, if such an inference can be made. The current user feedback is not very practical! > >>> >>> But the situation that brought this all up goes even deeper. There, >>> package cm3ide links in file ConnFD.i3, in package tcp, with object >>> code in libm3tcp.so, which needs to be recompiled because it links in >>> ThreadPThread.m3, in package m3core, compiled into libm3core.so. This >>> is (non-trivial) *transitive* dependency in the link closure of >>> libraries. CM3 detected this, but has to be asked manually to do the >>> necessary recompilation. I am far from knowledgeable about all build >>> systems in existence, but I would be be very surprised if more than >>> one or two others do even this detection. >> >> Actually, I described this wrongly, or at oversimplifiedly. >> What I am sure really happed here is cm3ide links in m3core directly, >> and also links in tcp, which, the last time it was compiled, >> linked in a different (earlier, in this case, but not necessarily, >> in general) version of m3core, which is what CM3 >> complained about. It detected this directly from type >> definitions, without needing version numbers, file names, >> dates, etc. It does however, rely on having the compiler-generated >> .M3WEB file for m3core properly installed beside the library. >> > > What ever one may say about the depth of transitive recompiling, on thing is certain: a script inside CM3 which claims to build a target system must make sure it correctly does so. Can we agree on that? There may be a need to organise packages and compilations in a way that ensures a consistent rebuild. That is what the "make" files are traditionally good for. As it seems from your report, cm3 is not free for the need of such. > > The objective appears quite simple: make sure only packages are referenced which are of the same compiler version-id. If this is not the case and the source is available -> recompile, otherwise break with an error msg. If package + source are only available remote, consider to recompile to a local copy (not replacing the remote binary). Such behaviour can be made dependent on pragmas and compiler switches. There could be a problem with cyclic package references, but I assume you can also solve that during linkage. That's, I admit, my guess here. ;) > I has just occurred to me that you probably view an IDE as fundamental part of the development system. I have been thinking of it as an independent tool, similar to the many other executables in the repository, since I had never tried it until just recently. Apparently, not many others have either, or the looping would have been noticed earlier. BTW, I have tracked at least one instance of the looping to a LONGREAL arithmetic bug in ThreadPThread itself, so it's not cm3ide's fault. So far, it's not so clear what to do about it. It involves busy waiting for network traffic, and that's a delicate balance. >>> >>> I am not even sure one would want a build system to automatically >>> transitively rebuild across multiple libraries. It might work >>> when all the libraries are in a single repository like Modula3-cm3. >>> But often, programs use libraries from very different projects, >>> with source code in far-flung places, if available at all. >>> >>> I suppose one could write a Makefile that notes when a linked-in >>> library depends on another linked-in library. I doubt this has been >>> done very often. Even so, it would at best, detect only at whole >>> library granularity. >>> >>> >>> >>> On 10/08/2016 01:22 AM, Wolfgang Keller wrote: >>>> The "upgrade" process claims to update a target installation system (perhaps also called the "work installation"). In my test case this was in " /home/user/Projekte/M3-Test2/". This is also the system which is made available in global environment paths. >>>> >>>> 1) If - after creation of the target system - compiling "cm3" within "cm3ide" of CM3 (git) fails then the claim to having built a valid upgrade has also failed (if we assume that cm3ide holds a valid composition of sources). >>>> >>>> 2) The compile process reports taking reference to m3bundle which appears to imply it is an essential part of the core compiler. >>>> >>>> "/home/user/Projekte/M3-Test2/bin/m3bundle -name CM3_IDE_Bundle -F/tmp/qk >>>> new source -> compiling Buf.i3 >>>> new source -> compiling Buf.m3 >>>> new source -> compiling ErrLog.i3 >>>> new source -> compiling ErrLog.m3 >>>> >>>> Fatal Error: bad version stamps: ConnFD.i3" >>>> >>>> 3) If we look at the /bin directory of the target system, we find some updated executables with the exception of "cm3ide" and "m3bundle" which still date to 12 July 2010. >>>> >>>> 4) Suspicion arises that omitting compilation or copy of m3bundle causes the failed compile process. >>>> >>>> 5) Obviously the "cm3" folder in CM3 (git) is not a sufficient source for executing the compiler. Hence I recommend there should be a target "build" system inside the git working repository as a result of any "upgrade" or "build" script. This build area should be the primary target of all scripts targeting at ensuring a workable compiler installation. Then in a secondary step, which may also be scripted but may also be omitted, copy from this area can be taken to update, upgrade or build new any other installation. The "build" area in git can be set to .gitignore so it doesn't litter up the tracking system. Is that an idea to follow? >>>> >>>> - Wolfgang >>>> >>>> Am 08.10.2016 um 01:24 schrieb Rodney M. Bates: >>>>> >>>>> >>>>> On 10/07/2016 01:26 PM, Wolfgang Keller wrote: >>>>>> >>>>>> >>>>>> Am 07.10.2016 um 18:17 schrieb Rodney M. Bates: >>>>>>> >>>>>>> >>>>>>> On 10/07/2016 03:53 AM, Wolfgang Keller wrote: >>>>>>>> I attempted at compiler compilation and found a few peculiar things. >>>>>>>> >>>>>>>> 1. The Result >>>>>>>> >>>>>>>> Critical Mass Modula-3 version d5.10.0 >>>>>>>> last updated: 2015-05-21 >>>>>>>> compiled: 2016-10-07 03:58:31 >>>>>>>> configuration: /home/user/Projekte/M3-Test2/bin/cm3.cfg >>>>>>>> host: AMD64_LINUX >>>>>>>> target: AMD64_LINUX >>>>>>>> >>>>>>>> This is how cm3 identifies. >>>>>>>> >>>>>>>> a) "last updated" - since you modified the sources, should there be a younger date? >>>>>>> >>>>>>> Yes. This is now manually updated in scripts/version.quake. >>>>>>> >>>>>>> m3devel list: We need to do this with every commit, or else automate it. >>>>>>> >>>>>>>> >>>>>>>> b) compilation results (executables) as well as configuration file have been put into CM3 (Git version) folders and into the "independent" installation of the older version of CM3, i.e. 5.8.6. I see this critical! The independent installation should stay unmodified in its functionality. Users might wish to continue to use it, e.g. when the newer version proves buggy or otherwise undesirable. >>>>>>>> >>>>>>> >>>>>>> Yes, we have been working on this. You can recreate a clean release installation at >>>>>>> any time, but it's a real pain for intermediate versions during development. I am >>>>>>> very conservative about saving existing versions before touching the compiler or its >>>>>>> core libraries, either by copying critical executable file and library files, or making >>>>>>> whole copies of /usr/local/cm3. >>>>>>> >>>>>>>> c) Erroneous execution. When calling "cm3" in the "cm3ide" directory it does not compile and the text result is >>>>>>>> >>>>>>>> -- begin -- >>>>>>>> --- building in AMD64_LINUX --- >>>>>>>> >>>>>>>> ignoring ../src/m3overrides >>>>>>>> >>>>>>>> Fatal Error: bad version stamps: ConnFD.i3 >>>>>>>> >>>>>>>> inconsistent opaque object info for type _t1541f475 >>>>>>>> super type: _te422a136 data: (size: 64, align: 64) method: (size: 0) >>>>>>>> => ConnFD.i3 >>>>>>>> super type: _te422a136 data: (size: 192, align: 64) method: (size: 0) >>>>>>>> => ThreadPThread.m3 >>>>>>>> >>>>>>>> -- end -- >>>>>>>> >>>>>>> >>>>>>> This is almost certainly a need for complete recompile of cm3ide. Try, in >>>>>>> the cm3ide directory: >>>>>>> >>>>>>> cm3 -realclean >>>>>>> cm3 >>>>>>> >>>>>>> >>>>>>> Within a package, the compiler infers from source code what needs to be recompiled >>>>>>> and does so. Between packages, and for certain kinds of changes in machine-level >>>>>>> types, it can only detect incompatibilities. This is rare. The messages are >>>>>>> highly uninformative, but fixing them requires changes to the compiler's internal >>>>>>> intermediate representation, which entails widespread, but mundane code changes. >>>>>>> I have undertaken some of this previously, but it hasn't had the highest priority. >>>>>> >>>>>> Taking your advice it results in the following: >>>>>> >>>>>> -- begin -- >>>>>> --- building in AMD64_LINUX --- >>>>>> >>>>>> ignoring ../src/m3overrides >>>>>> >>>>>> /home/user/Projekte/M3-Test2/bin/m3bundle -name CM3_IDE_Bundle -F/tmp/qk >>>>>> new source -> compiling Buf.i3 >>>>>> new source -> compiling Buf.m3 >>>>>> new source -> compiling ErrLog.i3 >>>>>> new source -> compiling ErrLog.m3 >>>>>> >>>>>> Fatal Error: bad version stamps: ConnFD.i3 >>>>>> >>>>>> inconsistent opaque object info for type _t1541f475 >>>>>> super type: _te422a136 data: (size: 64, align: 64) method: (size: 0) >>>>>> => ConnFD.i3 >>>>>> super type: _te422a136 data: (size: 192, align: 64) method: (size: 0) >>>>>> => ThreadPThread.m3 >>>>>> -- end -- >>>>>> >>>>>> Obviously compilation takes reference into the "other" installation and resulting in inconsistencies. Why does it do so? This is the type of mixed up configurations that I have been speaking of! Up to now I don't quite understand how people are working with this system. Does it work for you? >>>>>> >>>>> >>>>> It's the other way around. ConnFD.i3 has an old, already compiled version around that >>>>> depends on something in ThreadPThread, which has changed and been recently recompiled. >>>>> ConnFD.i3 now needs to be recompiled to adapt, now that a new libm3core is installed >>>>> (which ThreadPThread is part of). >>>>> >>>>> I should have looked at where ConnFD.i3 is located. It's in package group m3-comm, which >>>>> upgrade.sh apparently didn't rebuild. So try this, as I just did: >>>>> >>>>> in directory scripts: >>>>> >>>>> ./do-cm3-comm.sh realclean >>>>> ,/do-cm3-comm.sh buildship >>>>> >>>>> Then try rebuilding cm3ide. There could be more things that haven't been rebuilt >>>>> by update.sh. I would predict that m3-ui and m3-db haven't, though I doubt cm3ide >>>>> needs m3-ui. There are do-cm3-*.sh scripts for a lot of these groups. >>>>> >>>>> I have worked in compilation systems for modular languages that have a two-level >>>>> automatic rebuild system. Modula-3 does not. The automatic rebuild only works >>>>> within a package. It would be nice to have one. >>>>> >>>>>> Theoretically, the missing file attributes may have had an impact on the results of the upgrade. Who knows? >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> > > -- Rodney Bates rodney.m.bates at acm.org _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://m3lists.elegosoft.com/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmuysers at hotmail.com Fri Oct 21 19:56:13 2016 From: dmuysers at hotmail.com (dirk muysers) Date: Fri, 21 Oct 2016 17:56:13 +0000 Subject: [M3devel] Rants about an improbable release Message-ID: If you want to improve your home you go to the builders market and acquire a drill, a hammer and so on. I you have taken a fancy to a programming language, you download and install --or pay for-- a compiler and start to program in it. Not so for Modula-3. Its source code is in the hands of a small community of dedicated people for which its maintenance has become an endeavour by itself. This is laudable and great, but what about the simple potential Modula 3 USER ? One cannot hope that he (or she, let's remain PC) will clone the whole shebang from Github and begin to dabble in configuration files, Python and Shell scripts to build his version of what represents only a tool after all. All he wants is to have a compiler and begin to work on his apps and favorite software projects. So keeping alive a language is not enough, it has also to be made easily available to those wanting to use it as their tool and who are not interested in compiler building or simply have more urgent things to do. So when will there be the next Modula 3 release? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Sat Oct 22 02:35:02 2016 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 22 Oct 2016 00:35:02 +0000 (UTC) Subject: [M3devel] Rants about an improbable release In-Reply-To: References: Message-ID: <1956264377.5564.1477096502674@mail.yahoo.com> Hi Dirk:good point; I thought some time ago about this usability of the environment issue; I just don't know how a m3middle is hardware independent, so one can re-use m3clipse Modula-3 front end for Eclipse (generate AST) and run remotely m3middle hosted in a central (Elego hosted) server to generate cm3cg IR, and finally call again a Java based M3 backend like Scale compiler or cm3cg? it self in situ to generate object code. I didn't get any show of support unfortunately.Thanks in advance El Viernes 21 de octubre de 2016 12:56, dirk muysers escribi?: If you want to improve your home you go to the builders market and acquire a drill, a hammer and so on. I you have taken a fancy to a programming language, you download and install --or pay for-- ?a compiler and start to program in it. Not so for Modula-3. Its source code is in the hands of a small community of dedicated people for which its maintenance has become an endeavour by itself. This is laudable and great, but what about the simple potential Modula 3 USER ? One cannot hope that he (or she, let's remain PC) will clone the whole shebang from Github and begin to dabble in configuration files, Python and Shell scripts to build his version of what represents only a tool after all. All he wants is to have a compiler and begin to work on his apps and favorite software projects. So keeping alive a language is not enough, it ?has also to be made easily available to those wanting to use it as their tool and who are not interested in compiler building or simply have more urgent things to do. So when will there be the next Modula 3 release? _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://m3lists.elegosoft.com/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sat Oct 22 03:31:09 2016 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Fri, 21 Oct 2016 21:31:09 -0400 Subject: [M3devel] Rants about an improbable release In-Reply-To: <1956264377.5564.1477096502674@mail.yahoo.com> References: <1956264377.5564.1477096502674@mail.yahoo.com> Message-ID: <20161022013109.GB13948@topoi.pooq.com> As far as Linux is conerned, what's needed is just to package it for a few major dostributions. But that's highly specialized work. -- hendrik On Sat, Oct 22, 2016 at 12:35:02AM +0000, Daniel Alejandro Benavides D. wrote: > Hi Dirk:good point; I thought some time ago about this usability of the environment issue; I just don't know how a m3middle is hardware independent, so one can re-use m3clipse Modula-3 front end for Eclipse (generate AST) and run remotely m3middle hosted in a central (Elego hosted) server to generate cm3cg IR, and finally call again a Java based M3 backend like Scale compiler or cm3cg? it self in situ to generate object code. I didn't get any show of support unfortunately.Thanks in advance > > > > El Viernes 21 de octubre de 2016 12:56, dirk muysers escribi?: > > > If you want to improve your home you go to the builders market and acquire a drill, a hammer and so on. I you have taken a fancy to a programming language, you download and install --or pay for-- ?a compiler and start to program in it. Not so for Modula-3. Its source code is in the hands of a small community of dedicated people for which its maintenance has become an endeavour by itself. This is laudable and great, but what about the simple potential Modula 3 USER ? One cannot hope that he (or she, let's remain PC) will clone the whole shebang from Github and begin to dabble in configuration files, Python and Shell scripts to build his version of what represents only a tool after all. All he wants is to have a compiler and begin to work on his apps and favorite software projects. So keeping alive a language is not enough, it ?has also to be made easily available to those wanting to use it as their tool and who are not interested in compiler building or simply have more urgent things to do. So when will there be the next Modula 3 release? > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://m3lists.elegosoft.com/mailman/listinfo/m3devel > > > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://m3lists.elegosoft.com/mailman/listinfo/m3devel From dabenavidesd at yahoo.es Sun Oct 23 04:29:54 2016 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sun, 23 Oct 2016 02:29:54 +0000 (UTC) Subject: [M3devel] Rants about an improbable release In-Reply-To: <20161022013109.GB13948@topoi.pooq.com> References: <1956264377.5564.1477096502674@mail.yahoo.com> <20161022013109.GB13948@topoi.pooq.com> Message-ID: <1438769398.817786.1477189794679@mail.yahoo.com> Hello Hendrik:would you think in using T2 Software Development Environmenthttp://www.t2-project.org/ Thanks in advance El Viernes 21 de octubre de 2016 20:31, Hendrik Boom escribi?: As far as Linux is conerned, what's needed is just to package it for a few major dostributions.? But that's highly specialized work. -- hendrik On Sat, Oct 22, 2016 at 12:35:02AM +0000, Daniel Alejandro Benavides D. wrote: > Hi Dirk:good point; I thought some time ago about this usability of the environment issue; I just don't know how a m3middle is hardware independent, so one can re-use m3clipse Modula-3 front end for Eclipse (generate AST) and run remotely m3middle hosted in a central (Elego hosted) server to generate cm3cg IR, and finally call again a Java based M3 backend like Scale compiler or cm3cg? it self in situ to generate object code. I didn't get any show of support unfortunately.Thanks in advance > >? > >? ? El Viernes 21 de octubre de 2016 12:56, dirk muysers escribi?: >? > >? If you want to improve your home you go to the builders market and acquire a drill, a hammer and so on. I you have taken a fancy to a programming language, you download and install --or pay for-- ?a compiler and start to program in it. Not so for Modula-3. Its source code is in the hands of a small community of dedicated people for which its maintenance has become an endeavour by itself. This is laudable and great, but what about the simple potential Modula 3 USER ? One cannot hope that he (or she, let's remain PC) will clone the whole shebang from Github and begin to dabble in configuration files, Python and Shell scripts to build his version of what represents only a tool after all. All he wants is to have a compiler and begin to work on his apps and favorite software projects. So keeping alive a language is not enough, it ?has also to be made easily available to those wanting to use it as their tool and who are not interested in compiler building or simply have more urgent things to do. So when will there be the next Modula 3 release? > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://m3lists.elegosoft.com/mailman/listinfo/m3devel > > >? ? > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://m3lists.elegosoft.com/mailman/listinfo/m3devel _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://m3lists.elegosoft.com/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Fri Oct 28 16:42:38 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 28 Oct 2016 09:42:38 -0500 Subject: [M3devel] Rants about an improbable release In-Reply-To: References: Message-ID: <581363DE.9060401@lcwb.coop> I agree, we very much need to make a new release. There has been a lot of development since the last one, especially for having a small developer community. I have often thought I would be willing to do the work to do it, but every time, I get stuck not having any idea what needs to be done. For one thing, I presume it entails verifying that things build and work on all the various targets, which would further entail having access to one of each of them. Are such machines available? Any advice on how to proceed? On a related topic, we need to make some changes to the compiler IR, as defined in M3CG.i3 and M3CG_Ops.i3. I have been collecting a list of my own for some time. This is a lot of (mostly rather mundane) work, and it creates front/back end compatibility issues. It would be best to do as many as possible at one time and get them in before a release, so those not doing compiler development could just use the release without being bothered. Anybody have any changes to propose? On 10/21/2016 12:56 PM, dirk muysers wrote: > If you want to improve your home you go to the builders market and acquire a drill, a hammer and so on. I you have taken a fancy to a programming language, you download and install --or pay for-- a compiler and start to program in it. Not so for Modula-3. Its source code is in the hands of a small community of dedicated people for which its maintenance has become an endeavour by itself. This is laudable and great, but what about the simple potential Modula 3 USER ? One cannot hope that he (or she, let's remain PC) will clone the whole shebang from Github and begin to dabble in configuration files, Python and Shell scripts to build his version of what represents only a tool after all. All he wants is to have a compiler and begin to work on his apps and favorite software projects. So keeping alive a language is not enough, it has also to be made easily available to those wanting to use it as their tool and who are not interested in compiler building or simply have more urgent > things to do. So when will there be the next Modula 3 release? > > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://m3lists.elegosoft.com/mailman/listinfo/m3devel > -- Rodney Bates rodney.m.bates at acm.org From wagner at elegosoft.com Fri Oct 28 17:44:01 2016 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 28 Oct 2016 17:44:01 +0200 Subject: [M3devel] Rants about an improbable release In-Reply-To: <581363DE.9060401@lcwb.coop> References: <581363DE.9060401@lcwb.coop> Message-ID: <20161028174401.406875f4bf526b8967680b8a@elegosoft.com> On Fri, 28 Oct 2016 09:42:38 -0500 "Rodney M. Bates" wrote: > I agree, we very much need to make a new release. There has been a lot > of development since the last one, especially for having a small developer > community. > > I have often thought I would be willing to do the work to do it, but every > time, I get stuck not having any idea what needs to be done. For one > thing, I presume it entails verifying that things build and work on all > the various targets, which would further entail having access to one > of each of them. > > Are such machines available? Any advice on how to proceed? I think the most important thing would be to have an agreement on - which platforms will be part of the release - how the release will be packaged and deployed. I'd advise to concentrate on a small number of important platforms, or to have a simple standard procedure for all platforms (for example cross-compiled bootstrap archives) and more convenient support for some of them (for example Debian packages). Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com 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 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney_bates at lcwb.coop Sat Oct 29 22:40:26 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 29 Oct 2016 15:40:26 -0500 Subject: [M3devel] Rants about an improbable release In-Reply-To: <20161028174401.406875f4bf526b8967680b8a@elegosoft.com> References: <581363DE.9060401@lcwb.coop> <20161028174401.406875f4bf526b8967680b8a@elegosoft.com> Message-ID: <5815093A.4080907@lcwb.coop> On 10/28/2016 10:44 AM, Olaf Wagner wrote: > On Fri, 28 Oct 2016 09:42:38 -0500 > "Rodney M. Bates" wrote: > >> I agree, we very much need to make a new release. There has been a lot >> of development since the last one, especially for having a small developer >> community. >> >> I have often thought I would be willing to do the work to do it, but every >> time, I get stuck not having any idea what needs to be done. For one >> thing, I presume it entails verifying that things build and work on all >> the various targets, which would further entail having access to one >> of each of them. >> >> Are such machines available? Any advice on how to proceed? > > I think the most important thing would be to have an agreement on > - which platforms will be part of the release > - how the release will be packaged and deployed. > > I'd advise to concentrate on a small number of important platforms, OK, let's hear some nominations for important platforms. I need AMD64_LINUX and LINUXLIBC6. For the future, I would probably want a Windows version, and there are some others using Windows regularly, I think. Jay, where can we look for the latest more-aptly-renamed platform names? or > to have a simple standard procedure for all platforms (for example > cross-compiled bootstrap archives) Are these just tar files of /usr/local/cm3? Do we want to keep using cminstall? We are still requiring several static libraries (that are not part of CM3). These present installation problems, as most distros now do not include them by default, and, worse, it is quite a detective job to track from a name like "libmumble.a not found" to what package needs to be installed. We probably want to configure to use mostly dynamic libraries. Or maybe be able to use either? and more convenient support for some > of them (for example Debian packages). > Yes, this would be very good. Then they could go in package archives, and installation would be much easier. But we would also need to decide how to break things up into packages. E.g., would the stuff in groups like do-cm3-comm and do-cm3-ui be separate? Just matching what is in the various do-cm3-* scripts or the named groups in pkginfo.txt won't work, because they are highly non-disjoint. We need a partition. Also, my understanding about packages is that, while putting together a package that will work is not too difficult, some Linux distros have stringent requirements about package contents that are a lot more work to create. > Olaf > -- Rodney Bates rodney.m.bates at acm.org From dabenavidesd at yahoo.es Sun Oct 30 02:34:50 2016 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sun, 30 Oct 2016 01:34:50 +0000 (UTC) Subject: [M3devel] Rants about an improbable release In-Reply-To: <5815093A.4080907@lcwb.coop> References: <581363DE.9060401@lcwb.coop> <20161028174401.406875f4bf526b8967680b8a@elegosoft.com> <5815093A.4080907@lcwb.coop> Message-ID: <759940168.749551.1477791290613@mail.yahoo.com> Hello all:contrary to most of you think; I still see cvsup update efficiency by file and compiler recompile only updated sources method as the most advanced build/update system of what I have seen in this world. Please keep it that way Thanks in advance El S?bado 29 de octubre de 2016 15:42, Rodney M. Bates escribi?: On 10/28/2016 10:44 AM, Olaf Wagner wrote: > On Fri, 28 Oct 2016 09:42:38 -0500 > "Rodney M. Bates" wrote: > >> I agree, we very much need to make a new release.? There has been a lot >> of development since the last one, especially for having a small developer >> community. >> >> I have often thought I would be willing to do the work to do it, but every >> time, I get stuck not having any idea what needs to be done.? For one >> thing, I presume it entails verifying that things build and work on all >> the various targets, which would further entail having access to one >> of each of them. >> >> Are such machines available?? Any advice on how to proceed? > > I think the most important thing would be to have an agreement on > - which platforms will be part of the release > - how the release will be packaged and deployed. > > I'd advise to concentrate on a small number of important platforms, OK, let's hear some nominations for important platforms. I need AMD64_LINUX and LINUXLIBC6.? For the future, I would probably want a Windows version, and there are some others using Windows regularly, I think. Jay, where can we look for the latest more-aptly-renamed platform names? or > to have a simple standard procedure for all platforms (for example > cross-compiled bootstrap archives) Are these just tar files of /usr/local/cm3?? Do we want to keep using cminstall? We are still requiring several static libraries (that are not part of CM3). These present installation problems, as most distros now do not include them by default, and, worse, it is quite a detective job to track from a name like "libmumble.a not found" to what package needs to be installed.? We probably want to configure to use mostly dynamic libraries.? Or maybe be able to use either? and more convenient support for some > of them (for example Debian packages). > Yes, this would be very good.? Then they could go in package archives, and installation would be much easier.? But we would also need to decide how to break things up into packages.? E.g., would the stuff in groups like do-cm3-comm and do-cm3-ui be separate?? Just matching what is in the various do-cm3-* scripts or the named groups in pkginfo.txt won't work, because they are highly non-disjoint.? We need a partition. Also, my understanding about packages is that, while putting together a package that will work is not too difficult, some Linux distros have stringent requirements about package contents that are a lot more work to create. > Olaf > -- Rodney Bates rodney.m.bates at acm.org _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://m3lists.elegosoft.com/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Sun Oct 30 17:14:48 2016 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 30 Oct 2016 11:14:48 -0500 Subject: [M3devel] Rants about an improbable release In-Reply-To: <759940168.749551.1477791290613@mail.yahoo.com> References: <581363DE.9060401@lcwb.coop> <20161028174401.406875f4bf526b8967680b8a@elegosoft.com> <5815093A.4080907@lcwb.coop> <759940168.749551.1477791290613@mail.yahoo.com> Message-ID: <58161C78.2080101@lcwb.coop> On 10/29/2016 08:34 PM, Daniel Alejandro Benavides D. wrote: > Hello all: > contrary to most of you think; I still see cvsup update efficiency by file and compiler recompile only updated sources method as the most advanced build/update system of what I have seen in this world. Please keep it that way > But this does not address what we need for a release. A release needs to provide a way for somebody who has no Modula3 compiler at all to download and install already-compiled binaries, not only for the compiler itself, but probably much of the other stuff as well, though not all in a single package. > Thanks in advance > > > El S?bado 29 de octubre de 2016 15:42, Rodney M. Bates escribi?: > > > > > On 10/28/2016 10:44 AM, Olaf Wagner wrote: > > On Fri, 28 Oct 2016 09:42:38 -0500 > > "Rodney M. Bates" > wrote: > > > >> I agree, we very much need to make a new release. There has been a lot > >> of development since the last one, especially for having a small developer > >> community. > >> > >> I have often thought I would be willing to do the work to do it, but every > >> time, I get stuck not having any idea what needs to be done. For one > >> thing, I presume it entails verifying that things build and work on all > >> the various targets, which would further entail having access to one > >> of each of them. > >> > >> Are such machines available? Any advice on how to proceed? > > > > I think the most important thing would be to have an agreement on > > - which platforms will be part of the release > > - how the release will be packaged and deployed. > > > > I'd advise to concentrate on a small number of important platforms, > > OK, let's hear some nominations for important platforms. > > I need AMD64_LINUX and LINUXLIBC6. For the future, I would probably want > a Windows version, and there are some others using Windows regularly, I think. > > Jay, where can we look for the latest more-aptly-renamed platform names? > > or > > to have a simple standard procedure for all platforms (for example > > cross-compiled bootstrap archives) > > Are these just tar files of /usr/local/cm3? Do we want to keep using > cminstall? > > We are still requiring several static libraries (that are not part of CM3). > These present installation problems, as most distros now do not include them > by default, and, worse, it is quite a detective job to track from a name > like "libmumble.a not found" to what package needs to be installed. We > probably want to configure to use mostly dynamic libraries. Or maybe > be able to use either? > > and more convenient support for some > > of them (for example Debian packages). > > > > Yes, this would be very good. Then they could go in package archives, and > installation would be much easier. But we would also need to decide how > to break things up into packages. E.g., would the stuff in groups like > do-cm3-comm and do-cm3-ui be separate? Just matching what is in the various > do-cm3-* scripts or the named groups in pkginfo.txt won't work, because they > are highly non-disjoint. We need a partition. > > Also, my understanding about packages is that, while putting together a > package that will work is not too difficult, some Linux distros have > stringent requirements about package contents that are a lot more work > to create. > > > > Olaf > > > > -- > Rodney Bates > rodney.m.bates at acm.org > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://m3lists.elegosoft.com/mailman/listinfo/m3devel > > > > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://m3lists.elegosoft.com/mailman/listinfo/m3devel > -- Rodney Bates rodney.m.bates at acm.org