From hosking at cs.purdue.edu Sat Aug 1 04:24:49 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 31 Jul 2009 22:24:49 -0400 Subject: [M3devel] package groups question In-Reply-To: References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> <20090731160546.z0n1l2nxa8w008sw@mail.elegosoft.com> <20090731151357.GA18289@topoi.pooq.com> <20090731152047.GC18289@topoi.pooq.com> <20090731182747.5zo12gu1og0os4cg@mail.elegosoft.com> <7E5CE55F-0F6D-48BA-ADEF-35D7C59FB321@cs.purdue.edu> Message-ID: Good to hear that you think the numeric format errors have been stamped out. Not so good to hear that we don't fully support host/ target distinctions in the front-end. Text .mc would need conversion to binary .mc for cm3cg to parse. On 31 Jul 2009, at 12:43, Jay K wrote: > > That reminds me, darn it.. > > Yes I think the INTEGER/FLOAT things are ok now. > I had hit problems in float and/or double bootstrapping where host > and target differed in endian and fixed it. There were also 32bit/ > 64bit problems there maybe, also now believed fixed. > > > And gcc used to be partly to blame for problems here, but has been > fixed. > I even suggested they rev the documented caveats about building for > Alpha and I think they did. > > I do bootstrap from host-generated .s files. > > I understand you could bootstrap from .mc files instead. > Maybe even textual ones? > That you use as a distribution format? > Advantages/disadvantages? > Minor one is that you'd have to build m3cc without the small aid > of cm3..not a big deal, just configure -disable-bootstrap -disable- > multilibs && make and ignore all my little tweaks in the m3makefile. > If not textual, mc files are less readable..but assembly is > unreadable to most people anyway.. > > There are bugs here though. > - I left in the hack you didn't like in order to bootstrap from > 32bit to 64bit, where TEXTs are limited to 4gig, rather than some > much larger value on 64bit systems. The front end should be doing > target math there not host math. > > - You can't bootstrap from 64bit to 32bit due to some similar small > bug in the front end. > Probably also a target math vs. host math thing. > > We already have the code to simulate target math, we just have to > use it a little more. > (This is what gcc now uses gmp/mpfr for presumably, like wrt > constant propagation.) > > > - Jay > > > ________________________________ >> From: hosking at cs.purdue.edu >> To: wagner at elegosoft.com >> Date: Fri, 31 Jul 2009 12:31:49 -0400 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] package groups question >> >> I think cross-compilation should always be the default approach, >> simply because it avoids all the version issues. We should be able >> to bootstrap from any host to any target. I know there have been >> deficiencies in the gcc-based cm3cg backend (for example when host >> and target INTEGER or FLOAT have different formats), but I think we >> are on the way to eliminating those. Bootstrapping from .mc files >> using a native cm3cg probably avoids that though, rather than >> bootstrapping from host-generated .s files. Jay, perhaps you have >> more to add? >> >> On 31 Jul 2009, at 12:27, Olaf Wagner wrote: >> >> I meant getting the first instance of cm3 5.1 run on a certain >> platform. >> And there was of course a first platform. We used the SRC compiler, >> the cm3 4.1 from Critical Mass, and the PM3 compiler on different >> platforms. Later we used cross-compilation almost exclusively. >> >> I assume that cross-compilation support has improved dramatically >> with all your changes. >> >> Olaf >> >> Quoting Jay K>: >> >> >> What does it mean to boot the compiler? >> >> >> I build the compiler from nothing but the compiler itself, >> and config files, and C compiler and linker, cvs >> to get all the source. >> That's not nothing, but it about the smallest start you can have, >> unless you rewrite the compiler in C, then you can start without >> the Modula-3 compiler. But at certain points in time this >> would not work, due to m3core and/or libm3 problems. >> It does work today. >> >> >> Is that booting? >> >> >> In future I'd like to dynamically link cm3, so I'd start with >> cm3, libm3.so, libm3core.so, etc. -- just cm3 and its "static >> dynamic" >> dependencies. Many other systems do dynamically link to this extent >> and we can to. >> >> >> I'm not just being obnoxious. >> Really, what does it mean? >> >> >> Should we just ship std and that's it? >> And even drop the name from it? >> cm3-PPC_LINUX-5.8.2.tar.gz ? >> >> >> (No need to say "POSIX", it is redundant). >> Just one download per platform? >> Not a big matrix of packages to test? >> >> >> Or do we look too fat in that packaging? :) >> >> >> Will too much stuff confuse users? >> >> >> Or mitigate the bulk with a little documentation/tutorial? >> >> >> Something like this: >> >> There are many libraries and packages. >> You do not need to worry about them. >> Here is hello world for a command line program: >> ... >> And for a gui program: >> ... >> And a minimal sample interoperating with C: >> ... >> And a minimal sample using Modula-3's RPC called "network objects": >> ... >> >> CM3 4.1 had some like this that were nice, presumably we have them. >> >> - Jay >> >> >> >> >> ---------------------------------------- >> Date: Fri, 31 Jul 2009 11:20:48 -0400 >> From: hendrik at topoi.pooq.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] package groups question >> >> On Fri, Jul 31, 2009 at 11:13:58AM -0400, hendrik at topoi.pooq.com >> wrote: >> On Fri, Jul 31, 2009 at 04:05:46PM +0200, Olaf Wagner wrote: >> Quoting Tony Hosking : >> >> I don't care if future versions are not compilable with old cm3. But, >> vice versa, old versions should always be compilable with new cm3. >> >> My gut feelings run along the lines of what Randy has said. I do >> think that the average user should accept std as the install, while >> min is for power-users who know what they are doing. Does that jive >> with other people's expectations? >> >> Sorry, I only now caught up with _some_ of the mails on the m3devel >> list. Too much traffic for me to digest. >> >> I gather there's been a long discussion that `min' is not really >> useful as it is not enough to build the system. When we started >> the cm3 5 business many years ago with lots of uncompilable sources >> from Farshad Nayeri, we invented the following sets of packages: >> >> all - obvious meaning. most packages did not compile at all. >> std - the set of packages shipped as compilable and usable with >> every new release >> core - a useful but small set of packages including everything to >> bootstrap the compiler >> boot - the minimal set to bootstrap the compiler >> min - the minimal set useful for anyone (not wanting to compiler cm3) >> >> As of today, std = all, and boot isn't used any more as far as a I >> see. >> >> Is that becaouse no one ever boots the compiler any more? Or because >> there are better ways to do it? >> >> -- hendrik >> >> I guess I should mention that ebian is perfectly happy if one source >> parckage (possibly the entire working cm3 system) generates multiple >> binary packages. >> >> -- hendrik >> >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >> 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >> Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Aug 1 08:51:41 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Fri, 31 Jul 2009 23:51:41 -0700 Subject: [M3devel] package groups question In-Reply-To: <4A72DD14020000D70005DF68@scires.com> References: <4A72DD14020000D70005DF68@scires.com> Message-ID: <27E6BB5F-1852-469E-8CA8-1299389734C7@hotmail.com> | From what I've gleaned in the discussions and the current documentation, I think most everyone has settled on the idea of having 2 "binary" distributions for this release: "min" and "std". > Really? How about just "std" and don't even label it as such? How many expert users are clamoring for "min"? There was actually a push for several non overlaping package sets and Olaf did work for that. But I'm not sure that is worth it. - Jay From wagner at elegosoft.com Sat Aug 1 12:34:09 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 01 Aug 2009 12:34:09 +0200 Subject: [M3devel] CM3 5.8 release engineering status Message-ID: <20090801123409.pgfzat70hco480o4@mail.elegosoft.com> Hi again, I just updated https://projects.elego.de/cm3/roadmap. The current Tinderbox and Hudson status look OK, so I've started to build some installation archives for RC2. Several machines have been integrated into the Hudson regression; there are some connection problems though, which sometimes lead to broken builds. I've been able to create installation archives for AMD64_LINUX, LINUXLIBC6, FreeBSD4 and PPC_DARWIN. SOLgnu and I386_OPENBSD maybe tomorrow, if nobody else is faster. To contribute, check out the release branch and execute make-dist.sh cvs checkout -r release_branch_cm3_5_8 cm3 cd cm3/scripts SHIPRC=yes ./make-dist.sh should do the trick and copy the resulting packages to birch via scp. I'll be away for most of the remaining weekend, but will look into the mail now and then. I've moved the downloads to their own page, but otherwise not changed much in the documentation. There's still a lot to do. I'd appreciate feedback of any installation successes and failures. So long, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Sat Aug 1 23:03:18 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sat, 1 Aug 2009 17:03:18 -0400 Subject: [M3devel] package groups question In-Reply-To: <27E6BB5F-1852-469E-8CA8-1299389734C7@hotmail.com> References: <4A72DD14020000D70005DF68@scires.com> <27E6BB5F-1852-469E-8CA8-1299389734C7@hotmail.com> Message-ID: <20090801210318.GA21289@topoi.pooq.com> On Fri, Jul 31, 2009 at 11:51:41PM -0700, jay.krell at cornell.edu wrote: > | From what I've gleaned in the discussions and the current > documentation, I think most everyone has settled on the idea of having > 2 "binary" distributions for this release: "min" and "std". > > > > Really? How about just "std" and don't even label it as such? How many > expert users are clamoring for "min"? > > There was actually a push for several non overlaping package sets and > Olaf did work for that. But I'm not sure that is worth it. The packages probably shouldn't overlap (at least if we want them to be adopted by Linux distributions, whose installers know about package dependencies) But there are packages that should be optional. There's no way I'm going to be able to install Xorg on a text-only machine just so I can install cm3 because, say, Trestle is part of the standard package and it's compiled for X. -- hendrik From jay.krell at cornell.edu Sat Aug 1 23:16:28 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 1 Aug 2009 21:16:28 +0000 Subject: [M3devel] package groups question In-Reply-To: <20090801210318.GA21289@topoi.pooq.com> References: <4A72DD14020000D70005DF68@scires.com> <27E6BB5F-1852-469E-8CA8-1299389734C7@hotmail.com> <20090801210318.GA21289@topoi.pooq.com> Message-ID: Nobody is going to make you install Xorg. - we only have X clients, no dependencies on an X server - if we just omit any dependencies and leave the obvious errors to occur if you happen to run those binaries (unable to find libX11.so...) that's not terrible imho. Granted that might be a little unfriendly to people who actually want to run..uh..formsedit, and don't yet have X client libraries and are willing to install them if only it is suggested to them.. Keep in mind that Olaf isn't building .debs and .rpms, just these .tar.gz files, that, indeed, have no stated dependencies -- leading to exactly what I said, no suggestion to install anything else, leaving forsmedit et. al. to fail to launch. Are their tools to turn dynamic link dependencies into package dependencies?? - Jay ---------------------------------------- > Date: Sat, 1 Aug 2009 17:03:18 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] package groups question > > On Fri, Jul 31, 2009 at 11:51:41PM -0700, jay.krell at cornell.edu wrote: >> | From what I've gleaned in the discussions and the current >> documentation, I think most everyone has settled on the idea of having >> 2 "binary" distributions for this release: "min" and "std". >>> >> >> Really? How about just "std" and don't even label it as such? How many >> expert users are clamoring for "min"? >> >> There was actually a push for several non overlaping package sets and >> Olaf did work for that. But I'm not sure that is worth it. > > The packages probably shouldn't overlap (at least if we want them to be > adopted by Linux distributions, whose installers know about package > dependencies) > > But there are packages that should be optional. There's no way I'm > going to be able to install Xorg on a text-only machine just so I can > install cm3 because, say, Trestle is part of the standard package and > it's compiled for X. > > -- hendrik From hendrik at topoi.pooq.com Sat Aug 1 23:20:29 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sat, 1 Aug 2009 17:20:29 -0400 Subject: [M3devel] package groups question In-Reply-To: References: <4A72DD14020000D70005DF68@scires.com> <27E6BB5F-1852-469E-8CA8-1299389734C7@hotmail.com> <20090801210318.GA21289@topoi.pooq.com> Message-ID: <20090801212029.GD21289@topoi.pooq.com> On Sat, Aug 01, 2009 at 09:16:28PM +0000, Jay K wrote: > > Nobody is going to make you install Xorg. > > - we only have X clients, no dependencies on an X server > > > - if we just omit any dependencies and leave the obvious errors to > occur if you happen to run those binaries (unable to find > libX11.so...) that's not terrible imho. > Granted that might be a little unfriendly to people who actually want > to run..uh..formsedit, and don't yet have X client libraries and > are willing to install them if only it is suggested to them.. > > > Keep in mind that Olaf isn't building .debs and .rpms, just these .tar.gz files, that, indeed, have no stated dependencies -- leading to exactly what I said, no suggestion to install anything else, leaving forsmedit et. al. to fail to launch. Well, that's OK for now, then. > > > Are their tools to turn dynamic link dependencies into package dependencies?? I don't think Debian does this. I think package dependencies are determined manually, judging form the occasional package I've encountered that lacks a few. -- hendrik > > > - Jay > > > ---------------------------------------- > > Date: Sat, 1 Aug 2009 17:03:18 -0400 > > From: hendrik at topoi.pooq.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] package groups question > > > > On Fri, Jul 31, 2009 at 11:51:41PM -0700, jay.krell at cornell.edu wrote: > >> | From what I've gleaned in the discussions and the current > >> documentation, I think most everyone has settled on the idea of having > >> 2 "binary" distributions for this release: "min" and "std". > >>> > >> > >> Really? How about just "std" and don't even label it as such? How many > >> expert users are clamoring for "min"? > >> > >> There was actually a push for several non overlaping package sets and > >> Olaf did work for that. But I'm not sure that is worth it. > > > > The packages probably shouldn't overlap (at least if we want them to be > > adopted by Linux distributions, whose installers know about package > > dependencies) > > > > But there are packages that should be optional. There's no way I'm > > going to be able to install Xorg on a text-only machine just so I can > > install cm3 because, say, Trestle is part of the standard package and > > it's compiled for X. > > > > -- hendrik From rcolebur at scires.com Sun Aug 2 05:46:38 2009 From: rcolebur at scires.com (Randy Coleburn) Date: Sat, 1 Aug 2009 23:46:38 -0400 Subject: [M3devel] package groups question In-Reply-To: <27E6BB5F-1852-469E-8CA8-1299389734C7@hotmail.com> References: <4A72DD14020000D70005DF68@scires.com> <27E6BB5F-1852-469E-8CA8-1299389734C7@hotmail.com> Message-ID: <4A74D3DB.1E75.00D7.1@scires.com> Jay: That's ok with me if you just want to do "std" and leave out "min". Regards, Randy >>> 8/1/2009 2:51 AM >>> | From what I've gleaned in the discussions and the current documentation, I think most everyone has settled on the idea of having 2 "binary" distributions for this release: "min" and "std". > Really? How about just "std" and don't even label it as such? How many expert users are clamoring for "min"? There was actually a push for several non overlaping package sets and Olaf did work for that. But I'm not sure that is worth it. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4550 bytes Desc: S/MIME Cryptographic Signature URL: From jay.krell at cornell.edu Sun Aug 2 11:18:51 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 2 Aug 2009 09:18:51 +0000 Subject: [M3devel] use of the old config files? Message-ID: I noticed this in the build output: === package m3-sys/cminstall === --- building in SOLgnu --- ignoring ../src/m3overrides /home/hudson/work/cm3-inst/ssol/current--release-build/bin/../bin/m3bundle -name Setup -element config ../src/config/SOLgnu Maybe it is just unused now? - Jay From jay.krell at cornell.edu Sun Aug 2 14:26:21 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 2 Aug 2009 12:26:21 +0000 Subject: [M3devel] some cvs errors? Message-ID: "/tmp/cvsUsaGYO" 61 lines, 1835 characters /usr/cvs/cm3/m3-sys/m3cc/src/m3makefile,v <-- src/m3makefile new revision: 1.111.2.4; previous revision: 1.111.2.3 Cannot Open data file (cwd: /usr/local/tinderbox/bonsai; data/temp.8776): Bad fi ? PKGS /usr/cvs/cm3/scripts/find-packages.sh,v <-- find-packages.sh new revision: 1.9.2.1; previous revision: 1.9 /usr/cvs/cm3/scripts/find-src-dirs.sh,v <-- find-src-dirs.sh new revision: 1.2.2.1; previous revision: 1.2 /usr/cvs/cm3/scripts/list-pkg-dirs.sh,v <-- list-pkg-dirs.sh new revision: 1.2.2.1; previous revision: 1.2 /usr/cvs/cm3/scripts/make-dist.sh,v <-- make-dist.sh new revision: 1.26.2.5; previous revision: 1.26.2.4 cvs [commit aborted]: cannot rename file .new.make-dist.sh to make-dist.sh: Perm ission denied ? I think the commits made it. - Jay From wagner at elegosoft.com Sun Aug 2 14:39:54 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 02 Aug 2009 14:39:54 +0200 Subject: [M3devel] the branch? In-Reply-To: References: Message-ID: <20090802143954.xhdv2b7b8ao40ggw@mail.elegosoft.com> Quoting Jay K : > I checked out/updated in the branch. > Then make-dist did an update and picked up somewhat old stuff, like > the old caltech "term" stuff and the toplevel compat.quake. Jay, make-dist.sh on the release branch is supposed to just build the RC2 tag and nothing else. If we want anything else for that RC, we have to move the tag and rebuild all archives affected by the change. Probably days later then. If SOLgnu is broken and we cannot build anything with the sources, then its broken in RC2. That's life. I thought averything had stabilized. Let's keep it that way on the branch. Feel free to test out different tool setups in the regression or commit changes to the trunk. If we need to merge fixes, let's just merge those absolutely necessary. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Sun Aug 2 14:57:41 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 02 Aug 2009 14:57:41 +0200 Subject: [M3devel] HEADS UP: release engineering procedure clarification Message-ID: <20090802145741.noi5p5y40s4cgg8c@mail.elegosoft.com> Hi all, it seems I may need to explain the current procedure adopted for release engineering in order to avoid some confusion and chaos. (1) All release engineering occurs on the release_branch_cm3_5_8. The trunk is currently unaffected. (2) All RCs will be built from the release branch. (3) Fixes may be merged as necessary to the branch, but not arbitrary changes. Fixes comprise actual source fixes to make the CM3 code work on some platform as well as changes to the scripts to correct building or regression testing. (4) The tag release_CM3_5_8_RC2 defines the release candiate 2. I've made the last adaptions yesterday and started packaging the archives. make-dist.sh is currently supposed to just build this RC. (5) If we move the RC2 tag, we always need to rebuild a number of archives. We cannot do that indefinitely, as it takes a long time. If something is broken in RC2, it can be fixed in RC3. If we don't accept some bugs, we'll never make any release. (6) The Hudson regression and I think most of the tinderbox regression follows the release branch and not the trunk. Please heed these rules and help by building packages, improving the documentation and testing the available installation archives. I'm going to setup some automated tests for installation archives during the next days, but they will only cover some very basic aspects. Thanks for your cooperation, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sun Aug 2 15:06:16 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 2 Aug 2009 13:06:16 +0000 Subject: [M3devel] the branch? In-Reply-To: <20090802143954.xhdv2b7b8ao40ggw@mail.elegosoft.com> References: <20090802143954.xhdv2b7b8ao40ggw@mail.elegosoft.com> Message-ID: I understand, but it's very wierd, I run make-dist and it updates my source. bash-3.2$ rm PKGS rm: cannot remove `PKGS': No such file or directory bash-3.2$ SHIPRC=yes ./make-dist.sh making /cygdrive/c/dev2/cm3.release_branch_cm3_5_8/scripts/PKGS (slow but rare) ? scripts/PKGS U compat.quake U caltech-parser/term/src/cfmakeraw.c U caltech-parser/term/src/termios.h I don't even know why make-dist would be running any cvs upd command at all. I'll have to investigate further. - Jay ---------------------------------------- > Date: Sun, 2 Aug 2009 14:39:54 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: the branch? > > Quoting Jay K : > >> I checked out/updated in the branch. >> Then make-dist did an update and picked up somewhat old stuff, like >> the old caltech "term" stuff and the toplevel compat.quake. > > Jay, > > make-dist.sh on the release branch is supposed to just build the > RC2 tag and nothing else. > > If we want anything else for that RC, we have to move the tag > and rebuild all archives affected by the change. Probably days later then. > > If SOLgnu is broken and we cannot build anything with the sources, > then its broken in RC2. That's life. > > I thought averything had stabilized. Let's keep it that way on the > branch. Feel free to test out different tool setups in the regression > or commit changes to the trunk. > > If we need to merge fixes, let's just merge those absolutely necessary. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Sun Aug 2 15:07:24 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 2 Aug 2009 13:07:24 +0000 Subject: [M3devel] the branch? In-Reply-To: <20090802143954.xhdv2b7b8ao40ggw@mail.elegosoft.com> References: <20090802143954.xhdv2b7b8ao40ggw@mail.elegosoft.com> Message-ID: Oh, it is updating from release_CM3_5_8 to release_CM3_5_8_RC2. I thought we were supposed to checkout release_CM3_5_8. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > CC: m3devel at elegosoft.com > Subject: RE: the branch? > Date: Sun, 2 Aug 2009 13:06:16 +0000 > > > I understand, but it's very wierd, I run make-dist and it updates my source. > > bash-3.2$ rm PKGS > rm: cannot remove `PKGS': No such file or directory > bash-3.2$ SHIPRC=yes ./make-dist.sh > making /cygdrive/c/dev2/cm3.release_branch_cm3_5_8/scripts/PKGS (slow but rare) > ? scripts/PKGS > U compat.quake > U caltech-parser/term/src/cfmakeraw.c > U caltech-parser/term/src/termios.h > > I don't even know why make-dist would be running any cvs upd command at all. > I'll have to investigate further. > > - Jay > > > ---------------------------------------- >> Date: Sun, 2 Aug 2009 14:39:54 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: the branch? >> >> Quoting Jay K : >> >>> I checked out/updated in the branch. >>> Then make-dist did an update and picked up somewhat old stuff, like >>> the old caltech "term" stuff and the toplevel compat.quake. >> >> Jay, >> >> make-dist.sh on the release branch is supposed to just build the >> RC2 tag and nothing else. >> >> If we want anything else for that RC, we have to move the tag >> and rebuild all archives affected by the change. Probably days later then. >> >> If SOLgnu is broken and we cannot build anything with the sources, >> then its broken in RC2. That's life. >> >> I thought averything had stabilized. Let's keep it that way on the >> branch. Feel free to test out different tool setups in the regression >> or commit changes to the trunk. >> >> If we need to merge fixes, let's just merge those absolutely necessary. >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> From wagner at elegosoft.com Sun Aug 2 15:36:29 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 02 Aug 2009 15:36:29 +0200 Subject: [M3devel] HEADS UP: release engineering procedure clarification In-Reply-To: References: <20090802145741.noi5p5y40s4cgg8c@mail.elegosoft.com> Message-ID: <20090802153629.lqe9usnzocs4okwk@mail.elegosoft.com> Quoting Jay K : >> the CM3 code work on some platform as well as changes to the >> scripts to correct building or regression testing. > > That's what I was doing. > > SOLgnu probably shouldn't require a custom gcc, and the changes, > e.g. in m3cc only affect SOLgnu/SOLsun. > You don't really have to rebuild everything due to that change. > That's just an artifact of how CVS triggers Hudson. You can keep > whatever preexisting built packages exist. > > Changes in scripts were so Cygwin sh could build NT386. Likewise. It's all OK until now AFAIK. We can selectively rebuild packages. I've just move the RC2 tag to reflect your changes in scripts and will rebuild the source archive. We haven't got any archives yet for SOLgnu, so we can change anything platform speccific there and move the tag forward, as long as it doesn't affect other targets. Olaf > > - Jay > > > ---------------------------------------- >> Date: Sun, 2 Aug 2009 14:57:41 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] HEADS UP: release engineering procedure clarification >> >> Hi all, >> >> it seems I may need to explain the current procedure adopted for >> release engineering in order to avoid some confusion and chaos. >> >> (1) All release engineering occurs on the release_branch_cm3_5_8. >> The trunk is currently unaffected. >> (2) All RCs will be built from the release branch. >> (3) Fixes may be merged as necessary to the branch, but not >> arbitrary changes. Fixes comprise actual source fixes to make >> the CM3 code work on some platform as well as changes to the >> scripts to correct building or regression testing. >> (4) The tag release_CM3_5_8_RC2 defines the release candiate 2. >> I've made the last adaptions yesterday and started packaging >> the archives. make-dist.sh is currently supposed to just build >> this RC. >> (5) If we move the RC2 tag, we always need to rebuild a number of >> archives. We cannot do that indefinitely, as it takes a long >> time. If something is broken in RC2, it can be fixed in RC3. >> If we don't accept some bugs, we'll never make any release. >> (6) The Hudson regression and I think most of the tinderbox >> regression follows the release branch and not the trunk. >> >> Please heed these rules and help by building packages, improving >> the documentation and testing the available installation archives. >> >> I'm going to setup some automated tests for installation archives >> during the next days, but they will only cover some very basic >> aspects. >> >> Thanks for your cooperation, >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sun Aug 2 15:44:54 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 2 Aug 2009 13:44:54 +0000 Subject: [M3devel] HEADS UP: release engineering procedure clarification In-Reply-To: <20090802153629.lqe9usnzocs4okwk@mail.elegosoft.com> References: <20090802145741.noi5p5y40s4cgg8c@mail.elegosoft.com> <20090802153629.lqe9usnzocs4okwk@mail.elegosoft.com> Message-ID: I'll give up on SOLgnu now building with /usr/sfw/bin/gcc, since it failed again. There is another experiment to try -- -with-as=/usr/sfw/bin/as -with-gnu-as. I've changed hudson's .profile back to have /usr/local/bin in front and trying again. It looks like release and lastok are mixed up, ok. - Jay ---------------------------------------- > Date: Sun, 2 Aug 2009 15:36:29 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] HEADS UP: release engineering procedure clarification > > Quoting Jay K : > >>> the CM3 code work on some platform as well as changes to the >>> scripts to correct building or regression testing. >> >> That's what I was doing. >> >> SOLgnu probably shouldn't require a custom gcc, and the changes, >> e.g. in m3cc only affect SOLgnu/SOLsun. >> You don't really have to rebuild everything due to that change. >> That's just an artifact of how CVS triggers Hudson. You can keep >> whatever preexisting built packages exist. >> >> Changes in scripts were so Cygwin sh could build NT386. Likewise. > > It's all OK until now AFAIK. We can selectively rebuild packages. > I've just move the RC2 tag to reflect your changes in scripts > and will rebuild the source archive. > > We haven't got any archives yet for SOLgnu, so we can change > anything platform speccific there and move the tag forward, as long > as it doesn't affect other targets. > > Olaf > >> >> - Jay >> >> >> ---------------------------------------- >>> Date: Sun, 2 Aug 2009 14:57:41 +0200 >>> From: wagner at elegosoft.com >>> To: m3devel at elegosoft.com >>> Subject: [M3devel] HEADS UP: release engineering procedure clarification >>> >>> Hi all, >>> >>> it seems I may need to explain the current procedure adopted for >>> release engineering in order to avoid some confusion and chaos. >>> >>> (1) All release engineering occurs on the release_branch_cm3_5_8. >>> The trunk is currently unaffected. >>> (2) All RCs will be built from the release branch. >>> (3) Fixes may be merged as necessary to the branch, but not >>> arbitrary changes. Fixes comprise actual source fixes to make >>> the CM3 code work on some platform as well as changes to the >>> scripts to correct building or regression testing. >>> (4) The tag release_CM3_5_8_RC2 defines the release candiate 2. >>> I've made the last adaptions yesterday and started packaging >>> the archives. make-dist.sh is currently supposed to just build >>> this RC. >>> (5) If we move the RC2 tag, we always need to rebuild a number of >>> archives. We cannot do that indefinitely, as it takes a long >>> time. If something is broken in RC2, it can be fixed in RC3. >>> If we don't accept some bugs, we'll never make any release. >>> (6) The Hudson regression and I think most of the tinderbox >>> regression follows the release branch and not the trunk. >>> >>> Please heed these rules and help by building packages, improving >>> the documentation and testing the available installation archives. >>> >>> I'm going to setup some automated tests for installation archives >>> during the next days, but they will only cover some very basic >>> aspects. >>> >>> Thanks for your cooperation, >>> >>> Olaf >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From rcoleburn at scires.com Mon Aug 3 06:52:45 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 03 Aug 2009 00:52:45 -0400 Subject: [M3devel] problems with cm3.cfg and MxConfig Message-ID: <4A763446.1E75.00D7.1@scires.com> I have been working on the problem of cm3ide not getting the BUILD_DIR from cm3.cfg. I've run across some perplexing test results. MxConfig.Get("BUILD_DIR") is returning NIL on Windows XP & Vista. I've tracked it down a bit further. There seem to be two issues that must be fixed to solve this problem: 1. HOST does not seem to be defined. In particular my "C:\cm3\bin\cm3.cfg" file appears as follows (this is the file Jay recommended): INSTALL_ROOT = path() & "/.." include (path() & "/config/" & HOST) Is HOST a variable? Or, was I supposed to replace it by "NT386"? If the latter, my bad on this one--I took Jay's message literally. 2. path() does not appear to always yield the path to the bin folder. In particular, it seems to work fine unless you invoke the program when the current directory is actually set to the bin folder, in which case path() seems to return the empty string. So, if %CD%=C:\, and I run cm3ide, path() returns "C:\cm3\bin" as it should. But, if %CD%=C:\cm3\bin, and I run cm3ide, path() returns "". So in the latter case, the include statement winds up trying to pull a file from the wrong place, e.g. "/config/NT386" rather than "C:\cm3\bin/config/NT386" Regards, Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Aug 3 08:42:17 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Sun, 2 Aug 2009 23:42:17 -0700 Subject: [M3devel] problems with cm3.cfg and MxConfig In-Reply-To: <4A763446.1E75.00D7.1@scires.com> References: <4A763446.1E75.00D7.1@scires.com> Message-ID: Host, hm, I think probably my mistake. It is defined by cm3 but not all m3quake users. Path() should be the directory containing the file with the call. - Jay (phone) On Aug 2, 2009, at 9:52 PM, "Randy Coleburn" wrote: > I have been working on the problem of cm3ide not getting the > BUILD_DIR from cm3.cfg. I've run across some perplexing test results. > > MxConfig.Get("BUILD_DIR") is returning NIL on Windows XP & Vista. > I've tracked it down a bit further. There seem to be two issues > that must be fixed to solve this problem: > > 1. HOST does not seem to be defined. In particular my "C:\cm3\bin > \cm3.cfg" file appears as follows (this is the file Jay recommended): > INSTALL_ROOT = path() & "/.." > include (path() & "/config/" & HOST) > > Is HOST a variable? Or, was I supposed to replace it by "NT386"? > If the latter, my bad on this one--I took Jay's message literally. > > 2. path() does not appear to always yield the path to the bin > folder. In particular, it seems to work fine unless you invoke the > program when the current directory is actually set to the bin > folder, in which case path() seems to return the empty string. > > So, if ?%=C:\, and I run cm3ide, path() returns "C:\cm3\bin" as it s > hould. > But, if ?%=C:\cm3\bin, and I run cm3ide, path() returns "". > > So in the latter case, the include statement winds up trying to pull > a file from the wrong place, e.g. "/config/NT386" rather than "C: > \cm3\bin/config/NT386" > > Regards, > Randy Coleburn From jay.krell at cornell.edu Mon Aug 3 09:37:23 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 07:37:23 +0000 Subject: [M3devel] problems with cm3.cfg and MxConfig In-Reply-To: <4A763446.1E75.00D7.1@scires.com> References: <4A763446.1E75.00D7.1@scires.com> Message-ID: I will address #1 by changing the cm3.cfg files to say the actual target instead of depending on host. I still have to look into #2, that's the first I heard of it, but it could be again some difference between cm3 and all the other m3quake users. - Jay ________________________________ > Date: Mon, 3 Aug 2009 00:52:45 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: [M3devel] problems with cm3.cfg and MxConfig > > > > > > > > I have been working on the problem of cm3ide not getting the BUILD_DIR from cm3.cfg. I've run across some perplexing test results. > > > > MxConfig.Get("BUILD_DIR") is returning NIL on Windows XP & Vista. I've tracked it down a bit further. There seem to be two issues that must be fixed to solve this problem: > > > > 1. HOST does not seem to be defined. In particular my "C:\cm3\bin\cm3.cfg" file appears as follows (this is the file Jay recommended): > > INSTALL_ROOT = path() & "/.." > > include (path() & "/config/" & HOST) > > > > Is HOST a variable? Or, was I supposed to replace it by "NT386"? If the latter, my bad on this one--I took Jay's message literally. > > > > 2. path() does not appear to always yield the path to the bin folder. In particular, it seems to work fine unless you invoke the program when the current directory is actually set to the bin folder, in which case path() seems to return the empty string. > > > > So, if ?%=C:\, and I run cm3ide, path() returns "C:\cm3\bin" as it should. > > But, if ?%=C:\cm3\bin, and I run cm3ide, path() returns "". > > > > So in the latter case, the include statement winds up trying to pull a file from the wrong place, e.g. "/config/NT386" rather than "C:\cm3\bin/config/NT386" > > > > Regards, > > Randy Coleburn From jay.krell at cornell.edu Mon Aug 3 09:38:25 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 07:38:25 +0000 Subject: [M3devel] cm3 vs. m3quake Message-ID: cm3 defines some things, like: C:\dev2\cm3.2\m3-sys\cm3\src\Main.m3(54): Quake.Define(mach, "TARGET", MxConfig.HOST); C:\dev2\cm3.2\m3-sys\cm3\src\Main.m3(55): Quake.Define(mach, "OS_TYPE", MxConfig.HOST_OS_TYPE); C:\dev2\cm3.2\m3-sys\cm3\src\Main.m3(61): Quake.Define(mach, "WORD_SIZE", MxConfig.HOST_WORD_SIZE); C:\dev2\cm3.2\m3-sys\cm3\src\Main.m3(66): Quake.Define(mach, "HOST", MxConfig.HOST); C:\dev2\cm3.2\m3-sys\cm3\src\Main.m3(67): Quake.Define(mach, "HOST_OS_TYPE", MxConfig.HOST_OS_TYPE); C:\dev2\cm3.2\m3-sys\cm3\src\Main.m3(68): Quake.Define(mach, "HOST_GNU_MAKE", Version.GNUMake); all the other m3quake users don't get this. Would it be too polluting to move this to m3quake, thereby making m3quake just not a generic scripting language, but slightly specific to building Modula-3 stuff? I'll hold off for now. - Jay From jay.krell at cornell.edu Mon Aug 3 09:41:26 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 07:41:26 +0000 Subject: [M3devel] assembly goes to C compiler? Message-ID: Does this surprising anyone else: PROCEDURE CompileS (s: State; u: M3Unit.T) = ... ELSIF (u.kind = UK.S) THEN RunCC (s, UnitPath (u), u.object, u.debug, u.optimize); I kept modifying SYSTEM_ASM thinking it would affect how RTMachineASM.s is assembled, but it doesn't. I actually was thinking it might be nice to have two assembly functions, one for the output of m3cg, one for user written code. So, we do in fact have two functions, but one is the function for compiling C!. I'd want a third function, ideally. I'll leave this alone and just special case RTMachineASM.s in the config file, if that works out. That is, I'll try a very targeted slighly inelegant change, goal being to assemble this particular file with /usr/ccs/bin/as instead of the C compiler, on SOLgnu only. - Jay From dragisha at m3w.org Mon Aug 3 10:08:55 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 03 Aug 2009 10:08:55 +0200 Subject: [M3devel] More MxConfig Message-ID: <1249286935.28197.731.camel@faramir.m3w.org> This MxConfig thing looks like a bloody mess. To access former M3Config data I must have cm3.cfg suite present (to date I only had it in -devel packages, but ok...) Except cm3.cfg - ok, it's only set of text files, I must have sysutils, m3middle and m3quake.... A chunk of compiler. All this to read three or five variables from system. Also, this: VAR PKG_INSTALL := MxConfig.Get("PKG_INSTALL"); BUILD_DIR := MxConfig.Get("BUILD_DIR"); PROCEDURE DoImportBase() = BEGIN EVAL DoImportFile(PKG_INSTALL & "/libm3/" & BUILD_DIR & "/.M3WEB", TRUE); Fails on Concat in DoImportFile line - both variables NIL. Do I have some more voodoo to do to initialize MxConfig subsystem? -- Dragi?a Duri? From jay.krell at cornell.edu Mon Aug 3 10:36:24 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 08:36:24 +0000 Subject: [M3devel] the SOLgnu alignment problem finally understood Message-ID: Here finally is a small example of the SOLgnu problem I've been looking at it. It is specific to using /usr/sfw/bin/gcc -g to asssemble. No problem without -g, no problem with /usr/bin/cc, no problem with whatever I built in /usr/local/bin/gcc, no problem if you assemble with anything else and then link with /usr/sfw/bin/gcc -g. -bash-3.00$ cat 4.c asm.s 4.c void Asm(void); #include int main() { Asm(); printf("\n"); return 0; } asm.s .section ".text",#alloc,#execinstr .align 4 .global Asm .type Asm,#function Asm: retl nop .size Asm, (.-Asm) Not all possibilities shown here: -bash-3.00$ /usr/local/bin/gcc -g asm.s 4.c ok -bash-3.00$ /usr/sfw/bin/gcc -g asm.s 4.c ld: fatal: relocation error: R_SPARC_32: file /var/tmp//ccICgvny.o: symbol : offset 0xfeed139e is non-aligned ld: fatal: relocation error: R_SPARC_32: file /var/tmp//ccICgvny.o: symbol : offset 0xfeed14c2 is non-aligned ld: fatal: relocation error: R_SPARC_32: file /var/tmp//ccICgvny.o: symbol : offset 0xfeed15f6 is non-aligned collect2: ld returned 1 exit status -bash-3.00$ /usr/bin/cc -g asm.s 4.c asm.s: 4.c: ok -bash-3.00$ /usr/bin/cc asm.s 4.c asm.s: 4.c: ok -bash-3.00$ /usr/sfw/bin/gcc asm.s 4.c ok -bash-3.00$ /usr/local/bin/gcc asm.s 4.c ok -bash-3.00$ /usr/sfw/bin/gcc -g -c asm.s ok but haven't linked yet, input to later steps -bash-3.00$ /usr/bin/cc asm.o 4.c ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x ff10148e is non-aligned ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x ff1014ca is non-aligned ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x ff1015be is non-aligned -bash-3.00$ /usr/local/bin/gcc asm.o 4.c ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x feee1213 is non-aligned ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x feee122a is non-aligned ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x feee122e is non-aligned ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x feee1232 is non-aligned ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x feee126e is non-aligned collect2: ld returned 1 exit status -bash-3.00$ /usr/local/bin/gcc -g -c asm.s ok, try linking with others -bash-3.00$ /usr/bin/cc asm.o 4.c ok -bash-3.00$ /usr/sfw/bin/gcc asm.o 4.c ok Actually even -gstabs or -gstabs+ instead of -g make it work. -g resolves to -gdwarf2. - Jay From jay.krell at cornell.edu Mon Aug 3 10:42:22 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 08:42:22 +0000 Subject: [M3devel] More MxConfig In-Reply-To: <1249286935.28197.731.camel@faramir.m3w.org> References: <1249286935.28197.731.camel@faramir.m3w.org> Message-ID: Do you want to be able to move your cm3 install around, without editing the config file? You know, "be relocatable without any fixup code"? That is the big question. That is what MxConfig buys. These "variables" are computed, by running quake code. They are in fact known at install time, unless you later move the install around, and require something (cminstall) to modify the config files at install time. If nobody cares about moving installs around without invalidating their config file, we could put it back to a bunch of string constants. And we'd have to put back the markers that trigger cminstall to replace stuff. BUILD_DIR is basically constant either way. But, do you care about profiling? I don't really. Actually probably none of the tools properly support profiling anyway, except cm3. They would have to accept a command line switch. Dragi?a, do you have the symbolic HOST vs. actual string problem in cm3.cfg? A difference biting us is that cm3 does set a few values, such as PROFILING, SL, HOST. I haven't solved the path() problem yet that Randy reported. - Jay ---------------------------------------- > From: dragisha at m3w.org > To: m3devel at elegosoft.com > Date: Mon, 3 Aug 2009 10:08:55 +0200 > Subject: [M3devel] More MxConfig > > This MxConfig thing looks like a bloody mess. > > To access former M3Config data I must have cm3.cfg suite present (to > date I only had it in -devel packages, but ok...) > > Except cm3.cfg - ok, it's only set of text files, I must have sysutils, > m3middle and m3quake.... A chunk of compiler. > > All this to read three or five variables from system. > > Also, this: > > VAR > PKG_INSTALL := MxConfig.Get("PKG_INSTALL"); > BUILD_DIR := MxConfig.Get("BUILD_DIR"); > > PROCEDURE DoImportBase() = > BEGIN > EVAL DoImportFile(PKG_INSTALL & "/libm3/" & BUILD_DIR & > "/.M3WEB", TRUE); > > Fails on Concat in DoImportFile line - both variables NIL. > > Do I have some more voodoo to do to initialize MxConfig subsystem? > > -- > Dragi?a Duri? > From jay.krell at cornell.edu Mon Aug 3 10:51:28 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 08:51:28 +0000 Subject: [M3devel] More MxConfig In-Reply-To: References: <1249286935.28197.731.camel@faramir.m3w.org> Message-ID: ps: I should add that the way it was before was broken from a certain legitimate point of view. The M3Config paths were computed at build time, i.e. on Olaf's machine, i.e. they would point into /tmp or /home/hudson/work/cm3-inst or such. If you built things yourself, then ok, they worked. cminstall did not handle this. They were just constant strings in a generated M3Config.i3. cminstall could only "fix" MxConfig. I still think this is progress, though it would be nice if HOST worked and I have to look into path(). - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: dragisha at m3w.org; m3devel at elegosoft.com > Date: Mon, 3 Aug 2009 08:42:22 +0000 > Subject: Re: [M3devel] More MxConfig > > > Do you want to be able to move your cm3 install around, without editing the config file? > You know, "be relocatable without any fixup code"? > That is the big question. That is what MxConfig buys. > These "variables" are computed, by running quake code. > They are in fact known at install time, unless you later move the install around, > and require something (cminstall) to modify the config files at install time. > If nobody cares about moving installs around without invalidating their config file, > we could put it back to a bunch of string constants. And we'd have to put back > the markers that trigger cminstall to replace stuff. > > > BUILD_DIR is basically constant either way. But, do you care about profiling? I don't really. > Actually probably none of the tools properly support profiling anyway, except cm3. > They would have to accept a command line switch. > > > Dragi?a, do you have the symbolic HOST vs. actual string problem in cm3.cfg? > > > A difference biting us is that cm3 does set a few values, such as PROFILING, SL, HOST. > > > I haven't solved the path() problem yet that Randy reported. > > > - Jay > > > > ---------------------------------------- >> From: dragisha at m3w.org >> To: m3devel at elegosoft.com >> Date: Mon, 3 Aug 2009 10:08:55 +0200 >> Subject: [M3devel] More MxConfig >> >> This MxConfig thing looks like a bloody mess. >> >> To access former M3Config data I must have cm3.cfg suite present (to >> date I only had it in -devel packages, but ok...) >> >> Except cm3.cfg - ok, it's only set of text files, I must have sysutils, >> m3middle and m3quake.... A chunk of compiler. >> >> All this to read three or five variables from system. >> >> Also, this: >> >> VAR >> PKG_INSTALL := MxConfig.Get("PKG_INSTALL"); >> BUILD_DIR := MxConfig.Get("BUILD_DIR"); >> >> PROCEDURE DoImportBase() = >> BEGIN >> EVAL DoImportFile(PKG_INSTALL & "/libm3/" & BUILD_DIR & >> "/.M3WEB", TRUE); >> >> Fails on Concat in DoImportFile line - both variables NIL. >> >> Do I have some more voodoo to do to initialize MxConfig subsystem? >> >> -- >> Dragi?a Duri? >> From dragisha at m3w.org Mon Aug 3 10:55:48 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 03 Aug 2009 10:55:48 +0200 Subject: [M3devel] More MxConfig In-Reply-To: References: <1249286935.28197.731.camel@faramir.m3w.org> Message-ID: <1249289748.28197.740.camel@faramir.m3w.org> New auto-configuring cm3.cfg stuff is all ok. Great! I don't see importance of "moveable around" in that. Only "no need for cminstall and markers". "moveable around" is good when building from source using some kind of cm3-min. While at that, cm3-supermin with only cm3 binary and config files (probably cm3cg) would be supersmart feature. I am curently using cm3-min as a bootstraping device, and first thing I do is making libm3 and m3core over from supplied source. "Moveable around" is probably good, but if a chunk of compiler infrastructure included in any program reading those variables is price - I think it's good point to reconsider goals and ways. On Mon, 2009-08-03 at 08:42 +0000, Jay K wrote: > Do you want to be able to move your cm3 install around, without > editing the config file? > You know, "be relocatable without any fixup code"? > That is the big question. That is what MxConfig buys. > These "variables" are computed, by running quake code. > They are in fact known at install time, unless you later move the > install around, > and require something (cminstall) to modify the config files at > install time. > If nobody cares about moving installs around without invalidating > their config file, > we could put it back to a bunch of string constants. And we'd have > to put back > the markers that trigger cminstall to replace stuff. -- Dragi?a Duri? From jay.krell at cornell.edu Mon Aug 3 11:05:09 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 09:05:09 +0000 Subject: [M3devel] problems with cm3.cfg and MxConfig In-Reply-To: References: <4A763446.1E75.00D7.1@scires.com> Message-ID: Sorry about #1 Randy, my mistake. Sitting in the bin directory...seems a little wierd, eh? What source are you going to build sitting there? I guess um some custom quake code?? Good enough if empty is instead just "."? This falls out of the fact that cm3 actually probes all over the place for the cm3.cfg file and the first place it looks in is the current directory. Another good option I think would be just to remove that probe. It looks in way too many places. Here is the current code. I think it is gross. Too much probing make things quite ambiguous. PROCEDURE FindConfig () = (* LL = mu *) VAR txt: TEXT; BEGIN IF (found) THEN RETURN END; (* try the current directory *) IF TryConfig (Filename) THEN RETURN END; (* try the immediate source directory *) IF TryConfig ("src", Filename) THEN RETURN END; (* try the sibling source directory *) IF TryConfig ("..", "src", Filename) THEN RETURN END; (* try the M3CONFIG environment variable *) txt := QMachine.GetEnv (NIL, "M3CONFIG"); IF (txt # NIL) THEN IF TryConfig (txt) THEN RETURN END; IF TryConfig (txt, Filename) THEN RETURN END; END; (* try the directory containing the current executable *) txt := Pathname.Prefix (Params.Get (0)); IF Text.Length (txt)> 0 THEN IF TryConfig (txt, Filename) THEN RETURN END; END; (* try the directories named by the PATH environment variable. *) txt := Env.Get ("PATH"); FindConfigInPath (txt); IF found THEN RETURN END; (* try the etc directories *) IF TryConfig("/usr/local/cm3/etc", Filename) THEN RETURN END; IF TryConfig("/usr/cm3/etc", Filename) THEN RETURN END; IF TryConfig("/cm3/etc", Filename) THEN RETURN END; IF TryConfig("/usr/contrib/etc", Filename) THEN RETURN END; IF TryConfig("/usr/local/etc", Filename) THEN RETURN END; IF TryConfig("/usr/etc", Filename) THEN RETURN END; IF TryConfig("/opt/etc", Filename) THEN RETURN END; IF TryConfig("/sw/etc", Filename) THEN RETURN END; IF TryConfig("/etc", Filename) THEN RETURN END; (* oh well, make sure we don't try this silly exercise again... *) config := NIL; found := TRUE; END FindConfig; I propose..roughly roughly, we make it like this instead: PROCEDURE FindConfig () = (* LL = mu *) VAR txt: TEXT; BEGIN IF (found) THEN RETURN END; (* try the M3CONFIG environment variable *) txt := QMachine.GetEnv (NIL, "M3CONFIG"); IF (txt # NIL) THEN IF TryConfig (txt) THEN RETURN END; IF TryConfig (txt, Filename) THEN RETURN END; END; (* try the directory containing the current executable *) txt := Pathname.Prefix (Params.Get (0)); IF Text.Length (txt)> 0 THEN IF TryConfig (txt, Filename) THEN RETURN END; END; (* oh well, make sure we don't try this silly exercise again... *) config := NIL; found := TRUE; END FindConfig; or, if people really like it looking all over the place, fixing the case of it being in the current working directory is probably like this: (* try the current directory *) < IF TryConfig (Filename) THEN RETURN END; > IF TryConfig (".", Filename) THEN RETURN END; - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: rcoleburn at scires.com > Date: Sun, 2 Aug 2009 23:42:17 -0700 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] problems with cm3.cfg and MxConfig > > Host, hm, I think probably my mistake. It is defined by cm3 but not > all m3quake users. Path() should be the directory containing the file > with the call. > > - Jay (phone) > > On Aug 2, 2009, at 9:52 PM, "Randy Coleburn" > wrote: > >> I have been working on the problem of cm3ide not getting the >> BUILD_DIR from cm3.cfg. I've run across some perplexing test results. >> >> MxConfig.Get("BUILD_DIR") is returning NIL on Windows XP & Vista. >> I've tracked it down a bit further. There seem to be two issues >> that must be fixed to solve this problem: >> >> 1. HOST does not seem to be defined. In particular my "C:\cm3\bin >> \cm3.cfg" file appears as follows (this is the file Jay recommended): >> INSTALL_ROOT = path() & "/.." >> include (path() & "/config/" & HOST) >> >> Is HOST a variable? Or, was I supposed to replace it by "NT386"? >> If the latter, my bad on this one--I took Jay's message literally. >> >> 2. path() does not appear to always yield the path to the bin >> folder. In particular, it seems to work fine unless you invoke the >> program when the current directory is actually set to the bin >> folder, in which case path() seems to return the empty string. >> >> So, if ?%=C:\, and I run cm3ide, path() returns "C:\cm3\bin" as it s >> hould. >> But, if ?%=C:\cm3\bin, and I run cm3ide, path() returns "". >> >> So in the latter case, the include statement winds up trying to pull >> a file from the wrong place, e.g. "/config/NT386" rather than "C: >> \cm3\bin/config/NT386" >> >> Regards, >> Randy Coleburn From jay.krell at cornell.edu Mon Aug 3 11:13:25 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 09:13:25 +0000 Subject: [M3devel] More MxConfig In-Reply-To: <1249289748.28197.740.camel@faramir.m3w.org> References: <1249286935.28197.731.camel@faramir.m3w.org> <1249289748.28197.740.camel@faramir.m3w.org> Message-ID: Supermin is just cm3 + config files. And the config files we could/should m3bundle into cm3, leaving it to just be cm3. Providing cm3cg is a nice optimization, but then, you know, is the point to: build as much as possible or build as little as possible? build nothing, just get "std" or all of Olaf's packages. I would actually like to make cm3 dynamically linked, so supermin would also include m3core, libm3, sysutils. You could use ldd or whatever to discover. Look at gcc for example -- it doesn't statically link to libc. "Imagine if everyone statically linked the stuff they worked on and wanted to easily backup" -- everything would be statically linked. In terms of distribution purposes, well, I think providing just one large .tar.gz archive per platform is ideal, and one .msi for Windows, and a small number of .deb and .rpm files, like just x86 and AMD64. Arguing about all the subsets has been very wasteful. I don't want to add supermin and supermin+cm3cg to the debate. Meanwhile what we are going to have is probably Olaf's package breakdown. > "Moveable around" is probably good, but if a chunk of compiler > infrastructure included in any program reading those variables is price > - I think it's good point to reconsider goals and ways. Given how broken it was before, I don't see changing it back. I realize I've foisted "the compiler" on you, and there's a larger issue as to the finding of cm3.cfg by the executable. What about something like: cm3 -print-variable INSTALL_ROOT cm3 -print-variable HOST or for that matter: echo print(HOST)> fo o.quake cm3 -eval foo.quake or echo print(HOST) | cm3 -eval foo.quake Better or worse? Heck, you could just: type cm3 and compute the rest yourself. or you know the usual SearchPath function... - Jay ---------------------------------------- > From: dragisha at m3w.org > To: jay.krell at cornell.edu > Date: Mon, 3 Aug 2009 10:55:48 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] More MxConfig > > New auto-configuring cm3.cfg stuff is all ok. Great! > > I don't see importance of "moveable around" in that. Only "no need for > cminstall and markers". "moveable around" is good when building from > source using some kind of cm3-min. > > While at that, cm3-supermin with only cm3 binary and config files > (probably cm3cg) would be supersmart feature. I am curently using > cm3-min as a bootstraping device, and first thing I do is making libm3 > and m3core over from supplied source. > > "Moveable around" is probably good, but if a chunk of compiler > infrastructure included in any program reading those variables is price > - I think it's good point to reconsider goals and ways. > > On Mon, 2009-08-03 at 08:42 +0000, Jay K wrote: >> Do you want to be able to move your cm3 install around, without >> editing the config file? >> You know, "be relocatable without any fixup code"? >> That is the big question. That is what MxConfig buys. >> These "variables" are computed, by running quake code. >> They are in fact known at install time, unless you later move the >> install around, >> and require something (cminstall) to modify the config files at >> install time. >> If nobody cares about moving installs around without invalidating >> their config file, >> we could put it back to a bunch of string constants. And we'd have >> to put back >> the markers that trigger cminstall to replace stuff. > -- > Dragi?a Duri? > From wagner at elegosoft.com Mon Aug 3 12:30:54 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 03 Aug 2009 12:30:54 +0200 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: References: <4A763446.1E75.00D7.1@scires.com> Message-ID: <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> It was a specific request from the people building platform specific installation packages that config files reside and are found in the `usual' locations on their system and not somewhere beneath cm3. Place don't change that unless there is no objection from anyone on m3devel. Olaf Quoting Jay K : > Sorry about #1 Randy, my mistake. > > > Sitting in the bin directory...seems a little wierd, eh? > What source are you going to build sitting there? > I guess um some custom quake code?? > Good enough if empty is instead just "."? > > This falls out of the fact that cm3 actually probes all over the > place for the cm3.cfg file and the first place it looks in is the > current directory. > > > Another good option I think would be just to remove that probe. > It looks in way too many places. > > > Here is the current code. I think it is gross. > Too much probing make things quite ambiguous. > > > PROCEDURE FindConfig () = > (* LL = mu *) > VAR txt: TEXT; > BEGIN > IF (found) THEN RETURN END; > > (* try the current directory *) > IF TryConfig (Filename) THEN RETURN END; > > (* try the immediate source directory *) > IF TryConfig ("src", Filename) THEN RETURN END; > > (* try the sibling source directory *) > IF TryConfig ("..", "src", Filename) THEN RETURN END; > > (* try the M3CONFIG environment variable *) > txt := QMachine.GetEnv (NIL, "M3CONFIG"); > IF (txt # NIL) THEN > IF TryConfig (txt) THEN RETURN END; > IF TryConfig (txt, Filename) THEN RETURN END; > END; > > (* try the directory containing the current executable *) > txt := Pathname.Prefix (Params.Get (0)); > > IF Text.Length (txt)> 0 THEN > IF TryConfig (txt, Filename) THEN RETURN END; > END; > > (* try the directories named by the PATH environment variable. *) > txt := Env.Get ("PATH"); > FindConfigInPath (txt); > > IF found THEN RETURN END; > > (* try the etc directories *) > IF TryConfig("/usr/local/cm3/etc", Filename) THEN RETURN END; > IF TryConfig("/usr/cm3/etc", Filename) THEN RETURN END; > IF TryConfig("/cm3/etc", Filename) THEN RETURN END; > IF TryConfig("/usr/contrib/etc", Filename) THEN RETURN END; > IF TryConfig("/usr/local/etc", Filename) THEN RETURN END; > IF TryConfig("/usr/etc", Filename) THEN RETURN END; > IF TryConfig("/opt/etc", Filename) THEN RETURN END; > IF TryConfig("/sw/etc", Filename) THEN RETURN END; > IF TryConfig("/etc", Filename) THEN RETURN END; > > (* oh well, make sure we don't try this silly exercise again... *) > config := NIL; > found := TRUE; > END FindConfig; > > > I propose..roughly roughly, we make it like this instead: > > > PROCEDURE FindConfig () = > (* LL = mu *) > VAR txt: TEXT; > BEGIN > IF (found) THEN RETURN END; > > (* try the M3CONFIG environment variable *) > txt := QMachine.GetEnv (NIL, "M3CONFIG"); > IF (txt # NIL) THEN > IF TryConfig (txt) THEN RETURN END; > IF TryConfig (txt, Filename) THEN RETURN END; > END; > > (* try the directory containing the current executable *) > txt := Pathname.Prefix (Params.Get (0)); > IF Text.Length (txt)> 0 THEN > IF TryConfig (txt, Filename) THEN RETURN END; > END; > > (* oh well, make sure we don't try this silly exercise again... *) > config := NIL; > found := TRUE; > END FindConfig; > > > or, if people really like it looking all over the place, fixing the > case of it being in the current working directory is probably like > this: > > > (* try the current directory *) > < IF TryConfig (Filename) THEN RETURN END; >> IF TryConfig (".", Filename) THEN RETURN END; > > > - Jay > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: rcoleburn at scires.com >> Date: Sun, 2 Aug 2009 23:42:17 -0700 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] problems with cm3.cfg and MxConfig >> >> Host, hm, I think probably my mistake. It is defined by cm3 but not >> all m3quake users. Path() should be the directory containing the file >> with the call. >> >> - Jay (phone) >> >> On Aug 2, 2009, at 9:52 PM, "Randy Coleburn" >> wrote: >> >>> I have been working on the problem of cm3ide not getting the >>> BUILD_DIR from cm3.cfg. I've run across some perplexing test results. >>> >>> MxConfig.Get("BUILD_DIR") is returning NIL on Windows XP & Vista. >>> I've tracked it down a bit further. There seem to be two issues >>> that must be fixed to solve this problem: >>> >>> 1. HOST does not seem to be defined. In particular my "C:\cm3\bin >>> \cm3.cfg" file appears as follows (this is the file Jay recommended): >>> INSTALL_ROOT = path() & "/.." >>> include (path() & "/config/" & HOST) >>> >>> Is HOST a variable? Or, was I supposed to replace it by "NT386"? >>> If the latter, my bad on this one--I took Jay's message literally. >>> >>> 2. path() does not appear to always yield the path to the bin >>> folder. In particular, it seems to work fine unless you invoke the >>> program when the current directory is actually set to the bin >>> folder, in which case path() seems to return the empty string. >>> >>> So, if ?%=C:\, and I run cm3ide, path() returns "C:\cm3\bin" as it s >>> hould. >>> But, if ?%=C:\cm3\bin, and I run cm3ide, path() returns "". >>> >>> So in the latter case, the include statement winds up trying to pull >>> a file from the wrong place, e.g. "/config/NT386" rather than "C: >>> \cm3\bin/config/NT386" >>> >>> Regards, >>> Randy Coleburn -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Mon Aug 3 13:14:45 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 03 Aug 2009 13:14:45 +0200 Subject: [M3devel] some cvs errors? In-Reply-To: References: Message-ID: <20090803131445.d5u1i1vaf484kg4s@mail.elegosoft.com> Quoting Jay K : > "/tmp/cvsUsaGYO" 61 lines, 1835 characters > /usr/cvs/cm3/m3-sys/m3cc/src/m3makefile,v <-- src/m3makefile > new revision: 1.111.2.4; previous revision: 1.111.2.3 > Cannot Open data file (cwd: /usr/local/tinderbox/bonsai; > data/temp.8776): Bad fi > > ? PKGS > /usr/cvs/cm3/scripts/find-packages.sh,v <-- find-packages.sh > new revision: 1.9.2.1; previous revision: 1.9 > /usr/cvs/cm3/scripts/find-src-dirs.sh,v <-- find-src-dirs.sh > new revision: 1.2.2.1; previous revision: 1.2 > /usr/cvs/cm3/scripts/list-pkg-dirs.sh,v <-- list-pkg-dirs.sh > new revision: 1.2.2.1; previous revision: 1.2 > /usr/cvs/cm3/scripts/make-dist.sh,v <-- make-dist.sh > new revision: 1.26.2.5; previous revision: 1.26.2.4 > cvs [commit aborted]: cannot rename file .new.make-dist.sh to > make-dist.sh: Permission denied > > > ? > > I think the commits made it. What were these? Do we need to investigate them? Or is everything OK now? Still trying to catch up with all my mails, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Mon Aug 3 13:21:58 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 03 Aug 2009 13:21:58 +0200 Subject: [M3devel] assembly goes to C compiler? In-Reply-To: References: Message-ID: <20090803132158.walcuy2s00wck04g@mail.elegosoft.com> Quoting Jay K : > Does this surprising anyone else: > > PROCEDURE CompileS (s: State; u: M3Unit.T) = > ... > ELSIF (u.kind = UK.S) THEN > RunCC (s, UnitPath (u), u.object, u.debug, u.optimize); Indeed! I must say that I was not aware of it. Im not sure if it is an oversight, a hack, or an intended feature. In the last case we should eliminate the assembly methods from the config files. What happens if we run the quake assembly method instead? Does that break lots of systems? > I kept modifying SYSTEM_ASM thinking it would affect how > RTMachineASM.s is assembled, > but it doesn't. I actually was thinking it might be nice to have two > assembly functions, > one for the output of m3cg, one for user written code. So, we do in fact have > two functions, but one is the function for compiling C!. I'd want a > third function, ideally. > > I'll leave this alone and just special case RTMachineASM.s in the > config file, if that works out. > > That is, I'll try a very targeted slighly inelegant change, goal being > to assemble this particular file with /usr/ccs/bin/as instead of the > C compiler, > on SOLgnu only. That doesn't sound very nice. We should really investigate why RunCC is used even for assembly code. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Mon Aug 3 13:26:28 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 03 Aug 2009 13:26:28 +0200 Subject: [M3devel] the SOLgnu alignment problem finally understood In-Reply-To: References: Message-ID: <20090803132628.krcbd41hy8ggs8s8@mail.elegosoft.com> We had similar problems before with -g. CM3 never supported dwarf debugging format, just stabs. I think we changed all -g occurences in the config files to -gstabs some years ago. It sounds like a small fix in the config files after all, correct? At least for this RC? Olaf Quoting Jay K : > > Here finally is a small example of the SOLgnu problem I've been > looking at it. > > > It is specific to using /usr/sfw/bin/gcc -g to asssemble. > No problem without -g, no problem with /usr/bin/cc, no problem with > whatever I built in /usr/local/bin/gcc, no problem if you assemble > with anything else and then link with /usr/sfw/bin/gcc -g. > > > -bash-3.00$ cat 4.c asm.s > > 4.c > void Asm(void); > #include > > int main() > { > Asm(); > printf("\n"); > return 0; > } > > asm.s > > .section ".text",#alloc,#execinstr > .align 4 > .global Asm > .type Asm,#function > Asm: > retl > nop > .size Asm, (.-Asm) > > > Not all possibilities shown here: > > > -bash-3.00$ /usr/local/bin/gcc -g asm.s 4.c > ok > > > -bash-3.00$ /usr/sfw/bin/gcc -g asm.s 4.c > ld: fatal: relocation error: R_SPARC_32: file /var/tmp//ccICgvny.o: > symbol : offset 0xfeed139e is non-aligned > ld: fatal: relocation error: R_SPARC_32: file /var/tmp//ccICgvny.o: > symbol : offset 0xfeed14c2 is non-aligned > ld: fatal: relocation error: R_SPARC_32: file /var/tmp//ccICgvny.o: > symbol : offset 0xfeed15f6 is non-aligned > collect2: ld returned 1 exit status > > > -bash-3.00$ /usr/bin/cc -g asm.s 4.c > asm.s: > 4.c: > ok > > -bash-3.00$ /usr/bin/cc asm.s 4.c > asm.s: > 4.c: > ok > > > -bash-3.00$ /usr/sfw/bin/gcc asm.s 4.c > ok > > > -bash-3.00$ /usr/local/bin/gcc asm.s 4.c > ok > > > -bash-3.00$ /usr/sfw/bin/gcc -g -c asm.s > ok but haven't linked yet, input to later steps > > > -bash-3.00$ /usr/bin/cc asm.o 4.c > ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x > ff10148e is non-aligned > ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x > ff1014ca is non-aligned > ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x > ff1015be is non-aligned > > > -bash-3.00$ /usr/local/bin/gcc asm.o 4.c > ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x > feee1213 is non-aligned > ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x > feee122a is non-aligned > ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x > feee122e is non-aligned > ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x > feee1232 is non-aligned > ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x > feee126e is non-aligned > collect2: ld returned 1 exit status > > > > -bash-3.00$ /usr/local/bin/gcc -g -c asm.s > ok, try linking with others > > > -bash-3.00$ /usr/bin/cc asm.o 4.c > ok > > > > -bash-3.00$ /usr/sfw/bin/gcc asm.o 4.c > ok > > > Actually even -gstabs or -gstabs+ instead of -g make it work. > -g resolves to -gdwarf2. > > > - Jay -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Mon Aug 3 15:10:48 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 3 Aug 2009 09:10:48 -0400 Subject: [M3devel] assembly goes to C compiler? In-Reply-To: <20090803132158.walcuy2s00wck04g@mail.elegosoft.com> References: <20090803132158.walcuy2s00wck04g@mail.elegosoft.com> Message-ID: <20090803131048.GB24864@topoi.pooq.com> On Mon, Aug 03, 2009 at 01:21:58PM +0200, Olaf Wagner wrote: > > That doesn't sound very nice. We should really investigate why > RunCC is used even for assembly code. Just a guess -- could using a C compiler give the assembler code access to the X library? - hendrik From hosking at cs.purdue.edu Mon Aug 3 15:54:19 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 3 Aug 2009 09:54:19 -0400 Subject: [M3devel] cm3 vs. m3quake In-Reply-To: References: Message-ID: Prefer not to pollute. On 3 Aug 2009, at 03:38, Jay K wrote: > > cm3 defines some things, like: > > C:\dev2\cm3.2\m3-sys\cm3\src\Main.m3(54): Quake.Define(mach, > "TARGET", MxConfig.HOST); > C:\dev2\cm3.2\m3-sys\cm3\src\Main.m3(55): Quake.Define(mach, > "OS_TYPE", MxConfig.HOST_OS_TYPE); > C:\dev2\cm3.2\m3-sys\cm3\src\Main.m3(61): Quake.Define(mach, > "WORD_SIZE", MxConfig.HOST_WORD_SIZE); > C:\dev2\cm3.2\m3-sys\cm3\src\Main.m3(66): Quake.Define(mach, > "HOST", MxConfig.HOST); > C:\dev2\cm3.2\m3-sys\cm3\src\Main.m3(67): Quake.Define(mach, > "HOST_OS_TYPE", MxConfig.HOST_OS_TYPE); > C:\dev2\cm3.2\m3-sys\cm3\src\Main.m3(68): Quake.Define(mach, > "HOST_GNU_MAKE", Version.GNUMake); > > > all the other m3quake users don't get this. > > Would it be too polluting to move this to m3quake, thereby making > m3quake just not a generic scripting language, but slightly specific > to building Modula-3 stuff? > > I'll hold off for now. > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Aug 3 15:57:19 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 3 Aug 2009 09:57:19 -0400 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> Message-ID: I don't think we did agree that config files reside other than in the cm3 hierarchy. On 3 Aug 2009, at 06:30, Olaf Wagner wrote: > It was a specific request from the people building platform specific > installation packages that config files reside and are found in the > `usual' locations on their system and not somewhere beneath cm3. > > Place don't change that unless there is no objection from anyone > on m3devel. > > Olaf > > Quoting Jay K : > >> Sorry about #1 Randy, my mistake. >> >> >> Sitting in the bin directory...seems a little wierd, eh? >> What source are you going to build sitting there? >> I guess um some custom quake code?? >> Good enough if empty is instead just "."? >> >> This falls out of the fact that cm3 actually probes all over the >> place for the cm3.cfg file and the first place it looks in is the >> current directory. >> >> >> Another good option I think would be just to remove that probe. >> It looks in way too many places. >> >> >> Here is the current code. I think it is gross. >> Too much probing make things quite ambiguous. >> >> >> PROCEDURE FindConfig () = >> (* LL = mu *) >> VAR txt: TEXT; >> BEGIN >> IF (found) THEN RETURN END; >> >> (* try the current directory *) >> IF TryConfig (Filename) THEN RETURN END; >> >> (* try the immediate source directory *) >> IF TryConfig ("src", Filename) THEN RETURN END; >> >> (* try the sibling source directory *) >> IF TryConfig ("..", "src", Filename) THEN RETURN END; >> >> (* try the M3CONFIG environment variable *) >> txt := QMachine.GetEnv (NIL, "M3CONFIG"); >> IF (txt # NIL) THEN >> IF TryConfig (txt) THEN RETURN END; >> IF TryConfig (txt, Filename) THEN RETURN END; >> END; >> >> (* try the directory containing the current executable *) >> txt := Pathname.Prefix (Params.Get (0)); >> >> IF Text.Length (txt)> 0 THEN >> IF TryConfig (txt, Filename) THEN RETURN END; >> END; >> >> (* try the directories named by the PATH environment variable. *) >> txt := Env.Get ("PATH"); >> FindConfigInPath (txt); >> >> IF found THEN RETURN END; >> >> (* try the etc directories *) >> IF TryConfig("/usr/local/cm3/etc", Filename) THEN RETURN END; >> IF TryConfig("/usr/cm3/etc", Filename) THEN RETURN END; >> IF TryConfig("/cm3/etc", Filename) THEN RETURN END; >> IF TryConfig("/usr/contrib/etc", Filename) THEN RETURN END; >> IF TryConfig("/usr/local/etc", Filename) THEN RETURN END; >> IF TryConfig("/usr/etc", Filename) THEN RETURN END; >> IF TryConfig("/opt/etc", Filename) THEN RETURN END; >> IF TryConfig("/sw/etc", Filename) THEN RETURN END; >> IF TryConfig("/etc", Filename) THEN RETURN END; >> >> (* oh well, make sure we don't try this silly exercise again... *) >> config := NIL; >> found := TRUE; >> END FindConfig; >> >> >> I propose..roughly roughly, we make it like this instead: >> >> >> PROCEDURE FindConfig () = >> (* LL = mu *) >> VAR txt: TEXT; >> BEGIN >> IF (found) THEN RETURN END; >> >> (* try the M3CONFIG environment variable *) >> txt := QMachine.GetEnv (NIL, "M3CONFIG"); >> IF (txt # NIL) THEN >> IF TryConfig (txt) THEN RETURN END; >> IF TryConfig (txt, Filename) THEN RETURN END; >> END; >> >> (* try the directory containing the current executable *) >> txt := Pathname.Prefix (Params.Get (0)); >> IF Text.Length (txt)> 0 THEN >> IF TryConfig (txt, Filename) THEN RETURN END; >> END; >> >> (* oh well, make sure we don't try this silly exercise again... *) >> config := NIL; >> found := TRUE; >> END FindConfig; >> >> >> or, if people really like it looking all over the place, fixing >> the case of it being in the current working directory is probably >> like this: >> >> >> (* try the current directory *) >> < IF TryConfig (Filename) THEN RETURN END; >>> IF TryConfig (".", Filename) THEN RETURN END; >> >> >> - Jay >> >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: rcoleburn at scires.com >>> Date: Sun, 2 Aug 2009 23:42:17 -0700 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] problems with cm3.cfg and MxConfig >>> >>> Host, hm, I think probably my mistake. It is defined by cm3 but not >>> all m3quake users. Path() should be the directory containing the >>> file >>> with the call. >>> >>> - Jay (phone) >>> >>> On Aug 2, 2009, at 9:52 PM, "Randy Coleburn" >>> wrote: >>> >>>> I have been working on the problem of cm3ide not getting the >>>> BUILD_DIR from cm3.cfg. I've run across some perplexing test >>>> results. >>>> >>>> MxConfig.Get("BUILD_DIR") is returning NIL on Windows XP & Vista. >>>> I've tracked it down a bit further. There seem to be two issues >>>> that must be fixed to solve this problem: >>>> >>>> 1. HOST does not seem to be defined. In particular my "C:\cm3\bin >>>> \cm3.cfg" file appears as follows (this is the file Jay >>>> recommended): >>>> INSTALL_ROOT = path() & "/.." >>>> include (path() & "/config/" & HOST) >>>> >>>> Is HOST a variable? Or, was I supposed to replace it by "NT386"? >>>> If the latter, my bad on this one--I took Jay's message literally. >>>> >>>> 2. path() does not appear to always yield the path to the bin >>>> folder. In particular, it seems to work fine unless you invoke the >>>> program when the current directory is actually set to the bin >>>> folder, in which case path() seems to return the empty string. >>>> >>>> So, if ?%=C:\, and I run cm3ide, path() returns "C:\cm3\bin" as >>>> it s >>>> hould. >>>> But, if ?%=C:\cm3\bin, and I run cm3ide, path() returns "". >>>> >>>> So in the latter case, the include statement winds up trying to >>>> pull >>>> a file from the wrong place, e.g. "/config/NT386" rather than "C: >>>> \cm3\bin/config/NT386" >>>> >>>> Regards, >>>> Randy Coleburn > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Aug 3 16:02:12 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 3 Aug 2009 10:02:12 -0400 Subject: [M3devel] assembly goes to C compiler? In-Reply-To: <20090803131048.GB24864@topoi.pooq.com> References: <20090803132158.walcuy2s00wck04g@mail.elegosoft.com> <20090803131048.GB24864@topoi.pooq.com> Message-ID: <4AD30F1F-90E6-48F8-B93C-6889E8D2BAF4@cs.purdue.edu> Using the C compiler allows the assembly to have preprocessor directives. On 3 Aug 2009, at 09:10, hendrik at topoi.pooq.com wrote: > On Mon, Aug 03, 2009 at 01:21:58PM +0200, Olaf Wagner wrote: >> >> That doesn't sound very nice. We should really investigate why >> RunCC is used even for assembly code. > > Just a guess -- could using a C compiler give the assembler code > access > to the X library? > > - hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Aug 3 16:36:25 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 03 Aug 2009 16:36:25 +0200 Subject: [M3devel] assembly goes to C compiler? In-Reply-To: <4AD30F1F-90E6-48F8-B93C-6889E8D2BAF4@cs.purdue.edu> References: <20090803132158.walcuy2s00wck04g@mail.elegosoft.com> <20090803131048.GB24864@topoi.pooq.com> <4AD30F1F-90E6-48F8-B93C-6889E8D2BAF4@cs.purdue.edu> Message-ID: <20090803163625.qm007v2pfog8s8sg@mail.elegosoft.com> Quoting Tony Hosking : > Using the C compiler allows the assembly to have preprocessor directives. So you think it's a feature. Why do we have the assemble methods in the config file then? Or are they just legacy? %---------------------------------------------------------------- assembler --- % "assemble" is called to assemble .s or .asm files. Note that this function % is only called if your program or library explicitly includes assembly source % code, the system distributed by Critical Mass does not. proc assemble(source, object) is if defined("configure_assembler") configure_assembler() end return try_exec("@" & SYSTEM_ASM, source, "-o", object) end Probably a remnant of DEC SRC M3? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Mon Aug 3 16:42:21 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 03 Aug 2009 16:42:21 +0200 Subject: [M3devel] cm3.cfg et all, loc Message-ID: <1249310541.28197.746.camel@faramir.m3w.org> Excuse me for being a Martian here, esp on this topic, but I must agree, and loudly, with few voices on cm3.cfg location. In non-Windows world, /etc/ is natural place for anything config. Would it, or would it not be editable is another concern, mostly not important - if it's so absolutely uneditable then let it be m3bundled. It's up to packager to decide, of course... But I think everything will be much easier (esp this path() bussiness) if we decide to put these files somewhere standard. In Linux case, /etc. And included files in /etc/cm3/. MxConfig will have less problems to work as advertised, if nothing else :). -- Dragi?a Duri? From wagner at elegosoft.com Mon Aug 3 17:25:37 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 03 Aug 2009 17:25:37 +0200 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> Message-ID: <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> Quoting Tony Hosking : > I don't think we did agree that config files reside other than in the > cm3 hierarchy. I may have been too quick to extend the search path some weeks ago. I'm really undecided myself. I guess the score currently is +2 for cm3/ +1 /etc :-) But we should perhaps really come to an agreement that is acceptable for all here. Olaf > On 3 Aug 2009, at 06:30, Olaf Wagner wrote: > >> It was a specific request from the people building platform specific >> installation packages that config files reside and are found in the >> `usual' locations on their system and not somewhere beneath cm3. >> >> Place don't change that unless there is no objection from anyone >> on m3devel. >> >> Olaf >> >> Quoting Jay K : >> >>> Sorry about #1 Randy, my mistake. >>> >>> >>> Sitting in the bin directory...seems a little wierd, eh? >>> What source are you going to build sitting there? >>> I guess um some custom quake code?? >>> Good enough if empty is instead just "."? >>> >>> This falls out of the fact that cm3 actually probes all over the >>> place for the cm3.cfg file and the first place it looks in is the >>> current directory. >>> >>> >>> Another good option I think would be just to remove that probe. >>> It looks in way too many places. >>> >>> >>> Here is the current code. I think it is gross. >>> Too much probing make things quite ambiguous. >>> >>> >>> PROCEDURE FindConfig () = >>> (* LL = mu *) >>> VAR txt: TEXT; >>> BEGIN >>> IF (found) THEN RETURN END; >>> >>> (* try the current directory *) >>> IF TryConfig (Filename) THEN RETURN END; >>> >>> (* try the immediate source directory *) >>> IF TryConfig ("src", Filename) THEN RETURN END; >>> >>> (* try the sibling source directory *) >>> IF TryConfig ("..", "src", Filename) THEN RETURN END; >>> >>> (* try the M3CONFIG environment variable *) >>> txt := QMachine.GetEnv (NIL, "M3CONFIG"); >>> IF (txt # NIL) THEN >>> IF TryConfig (txt) THEN RETURN END; >>> IF TryConfig (txt, Filename) THEN RETURN END; >>> END; >>> >>> (* try the directory containing the current executable *) >>> txt := Pathname.Prefix (Params.Get (0)); >>> >>> IF Text.Length (txt)> 0 THEN >>> IF TryConfig (txt, Filename) THEN RETURN END; >>> END; >>> >>> (* try the directories named by the PATH environment variable. *) >>> txt := Env.Get ("PATH"); >>> FindConfigInPath (txt); >>> >>> IF found THEN RETURN END; >>> >>> (* try the etc directories *) >>> IF TryConfig("/usr/local/cm3/etc", Filename) THEN RETURN END; >>> IF TryConfig("/usr/cm3/etc", Filename) THEN RETURN END; >>> IF TryConfig("/cm3/etc", Filename) THEN RETURN END; >>> IF TryConfig("/usr/contrib/etc", Filename) THEN RETURN END; >>> IF TryConfig("/usr/local/etc", Filename) THEN RETURN END; >>> IF TryConfig("/usr/etc", Filename) THEN RETURN END; >>> IF TryConfig("/opt/etc", Filename) THEN RETURN END; >>> IF TryConfig("/sw/etc", Filename) THEN RETURN END; >>> IF TryConfig("/etc", Filename) THEN RETURN END; >>> >>> (* oh well, make sure we don't try this silly exercise again... *) >>> config := NIL; >>> found := TRUE; >>> END FindConfig; >>> >>> >>> I propose..roughly roughly, we make it like this instead: >>> >>> >>> PROCEDURE FindConfig () = >>> (* LL = mu *) >>> VAR txt: TEXT; >>> BEGIN >>> IF (found) THEN RETURN END; >>> >>> (* try the M3CONFIG environment variable *) >>> txt := QMachine.GetEnv (NIL, "M3CONFIG"); >>> IF (txt # NIL) THEN >>> IF TryConfig (txt) THEN RETURN END; >>> IF TryConfig (txt, Filename) THEN RETURN END; >>> END; >>> >>> (* try the directory containing the current executable *) >>> txt := Pathname.Prefix (Params.Get (0)); >>> IF Text.Length (txt)> 0 THEN >>> IF TryConfig (txt, Filename) THEN RETURN END; >>> END; >>> >>> (* oh well, make sure we don't try this silly exercise again... *) >>> config := NIL; >>> found := TRUE; >>> END FindConfig; >>> >>> >>> or, if people really like it looking all over the place, fixing >>> the case of it being in the current working directory is probably >>> like this: >>> >>> >>> (* try the current directory *) >>> < IF TryConfig (Filename) THEN RETURN END; >>>> IF TryConfig (".", Filename) THEN RETURN END; >>> >>> >>> - Jay >>> >>> >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: rcoleburn at scires.com >>>> Date: Sun, 2 Aug 2009 23:42:17 -0700 >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] problems with cm3.cfg and MxConfig >>>> >>>> Host, hm, I think probably my mistake. It is defined by cm3 but not >>>> all m3quake users. Path() should be the directory containing the file >>>> with the call. >>>> >>>> - Jay (phone) >>>> >>>> On Aug 2, 2009, at 9:52 PM, "Randy Coleburn" >>>> wrote: >>>> >>>>> I have been working on the problem of cm3ide not getting the >>>>> BUILD_DIR from cm3.cfg. I've run across some perplexing test results. >>>>> >>>>> MxConfig.Get("BUILD_DIR") is returning NIL on Windows XP & Vista. >>>>> I've tracked it down a bit further. There seem to be two issues >>>>> that must be fixed to solve this problem: >>>>> >>>>> 1. HOST does not seem to be defined. In particular my "C:\cm3\bin >>>>> \cm3.cfg" file appears as follows (this is the file Jay recommended): >>>>> INSTALL_ROOT = path() & "/.." >>>>> include (path() & "/config/" & HOST) >>>>> >>>>> Is HOST a variable? Or, was I supposed to replace it by "NT386"? >>>>> If the latter, my bad on this one--I took Jay's message literally. >>>>> >>>>> 2. path() does not appear to always yield the path to the bin >>>>> folder. In particular, it seems to work fine unless you invoke the >>>>> program when the current directory is actually set to the bin >>>>> folder, in which case path() seems to return the empty string. >>>>> >>>>> So, if ?%=C:\, and I run cm3ide, path() returns "C:\cm3\bin" as it s >>>>> hould. >>>>> But, if ?%=C:\cm3\bin, and I run cm3ide, path() returns "". >>>>> >>>>> So in the latter case, the include statement winds up trying to pull >>>>> a file from the wrong place, e.g. "/config/NT386" rather than "C: >>>>> \cm3\bin/config/NT386" >>>>> >>>>> Regards, >>>>> Randy Coleburn >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >> 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rcoleburn at scires.com Mon Aug 3 17:27:44 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 03 Aug 2009 11:27:44 -0400 Subject: [M3devel] problems with cm3.cfg and MxConfig In-Reply-To: References: <4A763446.1E75.00D7.1@scires.com> Message-ID: <4A76C915.1E75.00D7.1@scires.com> Jay: No problem. I think you are trying to make it more flexible, and that is good. I just ran into a problem with cm3ide. The shortcut I use to launch cm3ide causes the current dir to be the "bin" folder. So, using your new cm3.cfg, I was always having a problem with (path() & "/config/"), since it would be trying to find "config" at the root of the file system when path() returned the empty string. Since "/config" wasn't found, none of the other parts of your include file were ever processed, hence, BUILD_DIR would never be found. I gather that path() is supposed to return the path to the cm3.cfg file. If this is true, then returning "" is not really a path, so the function seems broken when cm3.cfg is in the current dir. Returning "." makes more sense for this case and would allow the rest of your cm3.cfg file to work I think, provided that HOST is defined or that it is replaced by the actual text. Regards, Randy >>> Jay K 8/3/2009 5:05 AM >>> Sorry about #1 Randy, my mistake. Sitting in the bin directory...seems a little wierd, eh? What source are you going to build sitting there? I guess um some custom quake code?? Good enough if empty is instead just "."? This falls out of the fact that cm3 actually probes all over the place for the cm3.cfg file and the first place it looks in is the current directory. Another good option I think would be just to remove that probe. It looks in way too many places. Here is the current code. I think it is gross. Too much probing make things quite ambiguous. PROCEDURE FindConfig () = (* LL = mu *) VAR txt: TEXT; BEGIN IF (found) THEN RETURN END; (* try the current directory *) IF TryConfig (Filename) THEN RETURN END; (* try the immediate source directory *) IF TryConfig ("src", Filename) THEN RETURN END; (* try the sibling source directory *) IF TryConfig ("..", "src", Filename) THEN RETURN END; (* try the M3CONFIG environment variable *) txt := QMachine.GetEnv (NIL, "M3CONFIG"); IF (txt # NIL) THEN IF TryConfig (txt) THEN RETURN END; IF TryConfig (txt, Filename) THEN RETURN END; END; (* try the directory containing the current executable *) txt := Pathname.Prefix (Params.Get (0)); IF Text.Length (txt)> 0 THEN IF TryConfig (txt, Filename) THEN RETURN END; END; (* try the directories named by the PATH environment variable. *) txt := Env.Get ("PATH"); FindConfigInPath (txt); IF found THEN RETURN END; (* try the etc directories *) IF TryConfig("/usr/local/cm3/etc", Filename) THEN RETURN END; IF TryConfig("/usr/cm3/etc", Filename) THEN RETURN END; IF TryConfig("/cm3/etc", Filename) THEN RETURN END; IF TryConfig("/usr/contrib/etc", Filename) THEN RETURN END; IF TryConfig("/usr/local/etc", Filename) THEN RETURN END; IF TryConfig("/usr/etc", Filename) THEN RETURN END; IF TryConfig("/opt/etc", Filename) THEN RETURN END; IF TryConfig("/sw/etc", Filename) THEN RETURN END; IF TryConfig("/etc", Filename) THEN RETURN END; (* oh well, make sure we don't try this silly exercise again... *) config := NIL; found := TRUE; END FindConfig; I propose..roughly roughly, we make it like this instead: PROCEDURE FindConfig () = (* LL = mu *) VAR txt: TEXT; BEGIN IF (found) THEN RETURN END; (* try the M3CONFIG environment variable *) txt := QMachine.GetEnv (NIL, "M3CONFIG"); IF (txt # NIL) THEN IF TryConfig (txt) THEN RETURN END; IF TryConfig (txt, Filename) THEN RETURN END; END; (* try the directory containing the current executable *) txt := Pathname.Prefix (Params.Get (0)); IF Text.Length (txt)> 0 THEN IF TryConfig (txt, Filename) THEN RETURN END; END; (* oh well, make sure we don't try this silly exercise again... *) config := NIL; found := TRUE; END FindConfig; or, if people really like it looking all over the place, fixing the case of it being in the current working directory is probably like this: (* try the current directory *) < IF TryConfig (Filename) THEN RETURN END; > IF TryConfig (".", Filename) THEN RETURN END; - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: rcoleburn at scires.com > Date: Sun, 2 Aug 2009 23:42:17 -0700 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] problems with cm3.cfg and MxConfig > > Host, hm, I think probably my mistake. It is defined by cm3 but not > all m3quake users. Path() should be the directory containing the file > with the call. > > - Jay (phone) > > On Aug 2, 2009, at 9:52 PM, "Randy Coleburn" > wrote: > >> I have been working on the problem of cm3ide not getting the >> BUILD_DIR from cm3.cfg. I've run across some perplexing test results. >> >> MxConfig.Get("BUILD_DIR") is returning NIL on Windows XP & Vista. >> I've tracked it down a bit further. There seem to be two issues >> that must be fixed to solve this problem: >> >> 1. HOST does not seem to be defined. In particular my "C:\cm3\bin >> \cm3.cfg" file appears as follows (this is the file Jay recommended): >> INSTALL_ROOT = path() & "/.." >> include (path() & "/config/" & HOST) >> >> Is HOST a variable? Or, was I supposed to replace it by "NT386"? >> If the latter, my bad on this one--I took Jay's message literally. >> >> 2. path() does not appear to always yield the path to the bin >> folder. In particular, it seems to work fine unless you invoke the >> program when the current directory is actually set to the bin >> folder, in which case path() seems to return the empty string. >> >> So, if ?%=C:\, and I run cm3ide, path() returns "C:\cm3\bin" as it s >> hould. >> But, if ?%=C:\cm3\bin, and I run cm3ide, path() returns "". >> >> So in the latter case, the include statement winds up trying to pull >> a file from the wrong place, e.g. "/config/NT386" rather than "C: >> \cm3\bin/config/NT386" >> >> Regards, >> Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Mon Aug 3 17:35:18 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 03 Aug 2009 11:35:18 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20090803093135.3F59DCC81B@birch.elegosoft.com> References: <20090803093135.3F59DCC81B@birch.elegosoft.com> Message-ID: <4A76CADA.1E75.00D7.1@scires.com> Jay: I agree that running cm3 from "bin" folder is not going to be productive; however, other programs (such as cm3ide) also use the quake stuff and they don't have this limitation. I think your change is a good one. I'll run some tests and see how cm3ide fares. Thanks. --Randy >>> Jay Krell 8/3/2009 11:31 AM >>> CVSROOT:/usr/cvs Changes by:jkrell at birch.09/08/03 11:31:35 Modified files: cm3/m3-sys/m3quake/src/: MxConfig.m3 Log message: use "." instead of empty string for path() when current working directory is the actual directory of cm3; not sure what good running cm3 here is, and we probe way too many places.. CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at darko.org Mon Aug 3 20:59:26 2009 From: lists at darko.org (Darko Volaric) Date: Mon, 3 Aug 2009 20:59:26 +0200 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> Message-ID: Putting it in /etc would mean that having different active versions of compiler would e a pain, which is useful when developing, debugging or trying out new versions of the compiler and when compilers are not self hosted, which will be the case for ARM_DARWIN. What's the benefit of having it /etc other than being "standard"? On 03/08/2009, at 5:25 PM, Olaf Wagner wrote: > Quoting Tony Hosking : > >> I don't think we did agree that config files reside other than in the >> cm3 hierarchy. > > I may have been too quick to extend the search path some weeks ago. > I'm really undecided myself. I guess the score currently is > +2 for cm3/ +1 /etc :-) > > But we should perhaps really come to an agreement that is acceptable > for all here. > > Olaf > >> On 3 Aug 2009, at 06:30, Olaf Wagner wrote: >> >>> It was a specific request from the people building platform specific >>> installation packages that config files reside and are found in the >>> `usual' locations on their system and not somewhere beneath cm3. >>> >>> Place don't change that unless there is no objection from anyone >>> on m3devel. >>> >>> Olaf >>> >>> Quoting Jay K : >>> >>>> Sorry about #1 Randy, my mistake. >>>> >>>> >>>> Sitting in the bin directory...seems a little wierd, eh? >>>> What source are you going to build sitting there? >>>> I guess um some custom quake code?? >>>> Good enough if empty is instead just "."? >>>> >>>> This falls out of the fact that cm3 actually probes all over >>>> the place for the cm3.cfg file and the first place it looks in >>>> is the current directory. >>>> >>>> >>>> Another good option I think would be just to remove that probe. >>>> It looks in way too many places. >>>> >>>> >>>> Here is the current code. I think it is gross. >>>> Too much probing make things quite ambiguous. >>>> >>>> >>>> PROCEDURE FindConfig () = >>>> (* LL = mu *) >>>> VAR txt: TEXT; >>>> BEGIN >>>> IF (found) THEN RETURN END; >>>> >>>> (* try the current directory *) >>>> IF TryConfig (Filename) THEN RETURN END; >>>> >>>> (* try the immediate source directory *) >>>> IF TryConfig ("src", Filename) THEN RETURN END; >>>> >>>> (* try the sibling source directory *) >>>> IF TryConfig ("..", "src", Filename) THEN RETURN END; >>>> >>>> (* try the M3CONFIG environment variable *) >>>> txt := QMachine.GetEnv (NIL, "M3CONFIG"); >>>> IF (txt # NIL) THEN >>>> IF TryConfig (txt) THEN RETURN END; >>>> IF TryConfig (txt, Filename) THEN RETURN END; >>>> END; >>>> >>>> (* try the directory containing the current executable *) >>>> txt := Pathname.Prefix (Params.Get (0)); >>>> >>>> IF Text.Length (txt)> 0 THEN >>>> IF TryConfig (txt, Filename) THEN RETURN END; >>>> END; >>>> >>>> (* try the directories named by the PATH environment variable. *) >>>> txt := Env.Get ("PATH"); >>>> FindConfigInPath (txt); >>>> >>>> IF found THEN RETURN END; >>>> >>>> (* try the etc directories *) >>>> IF TryConfig("/usr/local/cm3/etc", Filename) THEN RETURN END; >>>> IF TryConfig("/usr/cm3/etc", Filename) THEN RETURN END; >>>> IF TryConfig("/cm3/etc", Filename) THEN RETURN END; >>>> IF TryConfig("/usr/contrib/etc", Filename) THEN RETURN END; >>>> IF TryConfig("/usr/local/etc", Filename) THEN RETURN END; >>>> IF TryConfig("/usr/etc", Filename) THEN RETURN END; >>>> IF TryConfig("/opt/etc", Filename) THEN RETURN END; >>>> IF TryConfig("/sw/etc", Filename) THEN RETURN END; >>>> IF TryConfig("/etc", Filename) THEN RETURN END; >>>> >>>> (* oh well, make sure we don't try this silly exercise again... *) >>>> config := NIL; >>>> found := TRUE; >>>> END FindConfig; >>>> >>>> >>>> I propose..roughly roughly, we make it like this instead: >>>> >>>> >>>> PROCEDURE FindConfig () = >>>> (* LL = mu *) >>>> VAR txt: TEXT; >>>> BEGIN >>>> IF (found) THEN RETURN END; >>>> >>>> (* try the M3CONFIG environment variable *) >>>> txt := QMachine.GetEnv (NIL, "M3CONFIG"); >>>> IF (txt # NIL) THEN >>>> IF TryConfig (txt) THEN RETURN END; >>>> IF TryConfig (txt, Filename) THEN RETURN END; >>>> END; >>>> >>>> (* try the directory containing the current executable *) >>>> txt := Pathname.Prefix (Params.Get (0)); >>>> IF Text.Length (txt)> 0 THEN >>>> IF TryConfig (txt, Filename) THEN RETURN END; >>>> END; >>>> >>>> (* oh well, make sure we don't try this silly exercise again... *) >>>> config := NIL; >>>> found := TRUE; >>>> END FindConfig; >>>> >>>> >>>> or, if people really like it looking all over the place, fixing >>>> the case of it being in the current working directory is >>>> probably like this: >>>> >>>> >>>> (* try the current directory *) >>>> < IF TryConfig (Filename) THEN RETURN END; >>>>> IF TryConfig (".", Filename) THEN RETURN END; >>>> >>>> >>>> - Jay >>>> >>>> >>>> >>>> ---------------------------------------- >>>>> From: jay.krell at cornell.edu >>>>> To: rcoleburn at scires.com >>>>> Date: Sun, 2 Aug 2009 23:42:17 -0700 >>>>> CC: m3devel at elegosoft.com >>>>> Subject: Re: [M3devel] problems with cm3.cfg and MxConfig >>>>> >>>>> Host, hm, I think probably my mistake. It is defined by cm3 but >>>>> not >>>>> all m3quake users. Path() should be the directory containing >>>>> the file >>>>> with the call. >>>>> >>>>> - Jay (phone) >>>>> >>>>> On Aug 2, 2009, at 9:52 PM, "Randy Coleburn" >>>>> wrote: >>>>> >>>>>> I have been working on the problem of cm3ide not getting the >>>>>> BUILD_DIR from cm3.cfg. I've run across some perplexing test >>>>>> results. >>>>>> >>>>>> MxConfig.Get("BUILD_DIR") is returning NIL on Windows XP & Vista. >>>>>> I've tracked it down a bit further. There seem to be two issues >>>>>> that must be fixed to solve this problem: >>>>>> >>>>>> 1. HOST does not seem to be defined. In particular my "C:\cm3\bin >>>>>> \cm3.cfg" file appears as follows (this is the file Jay >>>>>> recommended): >>>>>> INSTALL_ROOT = path() & "/.." >>>>>> include (path() & "/config/" & HOST) >>>>>> >>>>>> Is HOST a variable? Or, was I supposed to replace it by "NT386"? >>>>>> If the latter, my bad on this one--I took Jay's message >>>>>> literally. >>>>>> >>>>>> 2. path() does not appear to always yield the path to the bin >>>>>> folder. In particular, it seems to work fine unless you invoke >>>>>> the >>>>>> program when the current directory is actually set to the bin >>>>>> folder, in which case path() seems to return the empty string. >>>>>> >>>>>> So, if ?%=C:\, and I run cm3ide, path() returns "C:\cm3\bin" >>>>>> as it s >>>>>> hould. >>>>>> But, if ?%=C:\cm3\bin, and I run cm3ide, path() returns "". >>>>>> >>>>>> So in the latter case, the include statement winds up trying >>>>>> to pull >>>>>> a file from the wrong place, e.g. "/config/NT386" rather than "C: >>>>>> \cm3\bin/config/NT386" >>>>>> >>>>>> Regards, >>>>>> Randy Coleburn >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>> Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>> 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>> Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From rcoleburn at scires.com Mon Aug 3 21:17:30 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 03 Aug 2009 15:17:30 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <4A76CADA.1E75.00D7.1@scires.com> References: <20090803093135.3F59DCC81B@birch.elegosoft.com> <4A76CADA.1E75.00D7.1@scires.com> Message-ID: <4A76FEED.1E75.00D7.1@scires.com> Jay: Your change to MxConfig.m3 seems to work fine for cm3ide, provided that I replace HOST by "NT386" in my cm3.cfg is as follows: INSTALL_ROOT = path() & "/.." include (path() & "/config/NT386") Thank you! Can we get your revised MxConfig.m3 put into the RC2 branch? Regards, Randy >>> "Randy Coleburn" 8/3/2009 11:35 AM >>> Jay: I agree that running cm3 from "bin" folder is not going to be productive; however, other programs (such as cm3ide) also use the quake stuff and they don't have this limitation. I think your change is a good one. I'll run some tests and see how cm3ide fares. Thanks. --Randy >>> Jay Krell 8/3/2009 11:31 AM >>> CVSROOT:/usr/cvs Changes by:jkrell at birch.09/08/03 11:31:35 Modified files: cm3/m3-sys/m3quake/src/: MxConfig.m3 Log message: use "." instead of empty string for path() when current working directory is the actual directory of cm3; not sure what good running cm3 here is, and we probe way too many places.. CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Mon Aug 3 22:10:02 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 03 Aug 2009 22:10:02 +0200 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> Message-ID: <1249330202.28197.748.camel@faramir.m3w.org> One day when we start thinking about configurations other than "developing, debugging or trying out new versions of the compiler" we will be ready for people other than m3devel readership. On Mon, 2009-08-03 at 20:59 +0200, Darko Volaric wrote: > Putting it in /etc would mean that having different active versions of > compiler would e a pain, which is useful when developing, debugging or > trying out new versions of the compiler and when compilers are not > self hosted, which will be the case for ARM_DARWIN. > > What's the benefit of having it /etc other than being "standard"? > > > On 03/08/2009, at 5:25 PM, Olaf Wagner wrote: > > > Quoting Tony Hosking : > > > >> I don't think we did agree that config files reside other than in the > >> cm3 hierarchy. > > > > I may have been too quick to extend the search path some weeks ago. > > I'm really undecided myself. I guess the score currently is > > +2 for cm3/ +1 /etc :-) > > > > But we should perhaps really come to an agreement that is acceptable > > for all here. > > > > Olaf > > > >> On 3 Aug 2009, at 06:30, Olaf Wagner wrote: > >> > >>> It was a specific request from the people building platform specific > >>> installation packages that config files reside and are found in the > >>> `usual' locations on their system and not somewhere beneath cm3. > >>> > >>> Place don't change that unless there is no objection from anyone > >>> on m3devel. > >>> > >>> Olaf > >>> > >>> Quoting Jay K : > >>> > >>>> Sorry about #1 Randy, my mistake. > >>>> > >>>> > >>>> Sitting in the bin directory...seems a little wierd, eh? > >>>> What source are you going to build sitting there? > >>>> I guess um some custom quake code?? > >>>> Good enough if empty is instead just "."? > >>>> > >>>> This falls out of the fact that cm3 actually probes all over > >>>> the place for the cm3.cfg file and the first place it looks in > >>>> is the current directory. > >>>> > >>>> > >>>> Another good option I think would be just to remove that probe. > >>>> It looks in way too many places. > >>>> > >>>> > >>>> Here is the current code. I think it is gross. > >>>> Too much probing make things quite ambiguous. > >>>> > >>>> > >>>> PROCEDURE FindConfig () = > >>>> (* LL = mu *) > >>>> VAR txt: TEXT; > >>>> BEGIN > >>>> IF (found) THEN RETURN END; > >>>> > >>>> (* try the current directory *) > >>>> IF TryConfig (Filename) THEN RETURN END; > >>>> > >>>> (* try the immediate source directory *) > >>>> IF TryConfig ("src", Filename) THEN RETURN END; > >>>> > >>>> (* try the sibling source directory *) > >>>> IF TryConfig ("..", "src", Filename) THEN RETURN END; > >>>> > >>>> (* try the M3CONFIG environment variable *) > >>>> txt := QMachine.GetEnv (NIL, "M3CONFIG"); > >>>> IF (txt # NIL) THEN > >>>> IF TryConfig (txt) THEN RETURN END; > >>>> IF TryConfig (txt, Filename) THEN RETURN END; > >>>> END; > >>>> > >>>> (* try the directory containing the current executable *) > >>>> txt := Pathname.Prefix (Params.Get (0)); > >>>> > >>>> IF Text.Length (txt)> 0 THEN > >>>> IF TryConfig (txt, Filename) THEN RETURN END; > >>>> END; > >>>> > >>>> (* try the directories named by the PATH environment variable. *) > >>>> txt := Env.Get ("PATH"); > >>>> FindConfigInPath (txt); > >>>> > >>>> IF found THEN RETURN END; > >>>> > >>>> (* try the etc directories *) > >>>> IF TryConfig("/usr/local/cm3/etc", Filename) THEN RETURN END; > >>>> IF TryConfig("/usr/cm3/etc", Filename) THEN RETURN END; > >>>> IF TryConfig("/cm3/etc", Filename) THEN RETURN END; > >>>> IF TryConfig("/usr/contrib/etc", Filename) THEN RETURN END; > >>>> IF TryConfig("/usr/local/etc", Filename) THEN RETURN END; > >>>> IF TryConfig("/usr/etc", Filename) THEN RETURN END; > >>>> IF TryConfig("/opt/etc", Filename) THEN RETURN END; > >>>> IF TryConfig("/sw/etc", Filename) THEN RETURN END; > >>>> IF TryConfig("/etc", Filename) THEN RETURN END; > >>>> > >>>> (* oh well, make sure we don't try this silly exercise again... *) > >>>> config := NIL; > >>>> found := TRUE; > >>>> END FindConfig; > >>>> > >>>> > >>>> I propose..roughly roughly, we make it like this instead: > >>>> > >>>> > >>>> PROCEDURE FindConfig () = > >>>> (* LL = mu *) > >>>> VAR txt: TEXT; > >>>> BEGIN > >>>> IF (found) THEN RETURN END; > >>>> > >>>> (* try the M3CONFIG environment variable *) > >>>> txt := QMachine.GetEnv (NIL, "M3CONFIG"); > >>>> IF (txt # NIL) THEN > >>>> IF TryConfig (txt) THEN RETURN END; > >>>> IF TryConfig (txt, Filename) THEN RETURN END; > >>>> END; > >>>> > >>>> (* try the directory containing the current executable *) > >>>> txt := Pathname.Prefix (Params.Get (0)); > >>>> IF Text.Length (txt)> 0 THEN > >>>> IF TryConfig (txt, Filename) THEN RETURN END; > >>>> END; > >>>> > >>>> (* oh well, make sure we don't try this silly exercise again... *) > >>>> config := NIL; > >>>> found := TRUE; > >>>> END FindConfig; > >>>> > >>>> > >>>> or, if people really like it looking all over the place, fixing > >>>> the case of it being in the current working directory is > >>>> probably like this: > >>>> > >>>> > >>>> (* try the current directory *) > >>>> < IF TryConfig (Filename) THEN RETURN END; > >>>>> IF TryConfig (".", Filename) THEN RETURN END; > >>>> > >>>> > >>>> - Jay > >>>> > >>>> > >>>> > >>>> ---------------------------------------- > >>>>> From: jay.krell at cornell.edu > >>>>> To: rcoleburn at scires.com > >>>>> Date: Sun, 2 Aug 2009 23:42:17 -0700 > >>>>> CC: m3devel at elegosoft.com > >>>>> Subject: Re: [M3devel] problems with cm3.cfg and MxConfig > >>>>> > >>>>> Host, hm, I think probably my mistake. It is defined by cm3 but > >>>>> not > >>>>> all m3quake users. Path() should be the directory containing > >>>>> the file > >>>>> with the call. > >>>>> > >>>>> - Jay (phone) > >>>>> > >>>>> On Aug 2, 2009, at 9:52 PM, "Randy Coleburn" > >>>>> wrote: > >>>>> > >>>>>> I have been working on the problem of cm3ide not getting the > >>>>>> BUILD_DIR from cm3.cfg. I've run across some perplexing test > >>>>>> results. > >>>>>> > >>>>>> MxConfig.Get("BUILD_DIR") is returning NIL on Windows XP & Vista. > >>>>>> I've tracked it down a bit further. There seem to be two issues > >>>>>> that must be fixed to solve this problem: > >>>>>> > >>>>>> 1. HOST does not seem to be defined. In particular my "C:\cm3\bin > >>>>>> \cm3.cfg" file appears as follows (this is the file Jay > >>>>>> recommended): > >>>>>> INSTALL_ROOT = path() & "/.." > >>>>>> include (path() & "/config/" & HOST) > >>>>>> > >>>>>> Is HOST a variable? Or, was I supposed to replace it by "NT386"? > >>>>>> If the latter, my bad on this one--I took Jay's message > >>>>>> literally. > >>>>>> > >>>>>> 2. path() does not appear to always yield the path to the bin > >>>>>> folder. In particular, it seems to work fine unless you invoke > >>>>>> the > >>>>>> program when the current directory is actually set to the bin > >>>>>> folder, in which case path() seems to return the empty string. > >>>>>> > >>>>>> So, if ?%=C:\, and I run cm3ide, path() returns "C:\cm3\bin" > >>>>>> as it s > >>>>>> hould. > >>>>>> But, if ?%=C:\cm3\bin, and I run cm3ide, path() returns "". > >>>>>> > >>>>>> So in the latter case, the include statement winds up trying > >>>>>> to pull > >>>>>> a file from the wrong place, e.g. "/config/NT386" rather than "C: > >>>>>> \cm3\bin/config/NT386" > >>>>>> > >>>>>> Regards, > >>>>>> Randy Coleburn > >>> > >>> > >>> > >>> -- > >>> Olaf Wagner -- elego Software Solutions GmbH > >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > >>> Germany > >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 > >>> 23 45 86 95 > >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > >>> Berlin > >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > >>> DE163214194 > >>> > > > > > > > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > > Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > > 45 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > > Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > > DE163214194 > > > -- Dragi?a Duri? From wagner at elegosoft.com Mon Aug 3 23:15:45 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 03 Aug 2009 23:15:45 +0200 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> Message-ID: <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> Quoting Darko Volaric : > Putting it in /etc would mean that having different active versions of > compiler would e a pain, which is useful when developing, debugging or > trying out new versions of the compiler and when compilers are not self > hosted, which will be the case for ARM_DARWIN. > > What's the benefit of having it /etc other than being "standard"? The compiler searches in a list of locations and takes the first one found, as is the convention when doing path searches. AFAIK /etc is currently the last option at all. Perhaps we should try to gather the facts and write up a pro/cons list for different options. In all previous releases cm3 used the following strategy to find its configuration: "traditional" (1) ./cm3.cfg (2) src/cm3.cfg (3) ../src/cm3.cfg (4) $M3CONFIG (5) Pathname.Prefix( Params.Get( 0 )) (6) for p in $PATH: try p/cm3.cfg (7) give up... Because people were complaining that it wasn't possible to adhere to common system conventions with CM3 installation packages, I extended this strategy like this: "extended" (1)..(6) same as above (7) /usr/local/cm3/etc/cm3.cfg (8) /usr/cm3/etc/cm3.cfg (9) /cm3/etc/cm3.cfg (10) /usr/contrib/etc/cm3.cfg (11) /usr/local/etc/cm3.cfg (12) /usr/etc/cm3.cfg (13) /opt/etc/cm3.cfg (14) /sw/etc/cm3.cfg (15) /etc/cm3.cfg I do insist neither on this list nor the order or the locations themselves. On the other hand I do not see much harm in an extension like this, allowing a certain degree of freedom for those preparing system dependent installation packages. Recently Jay suggested to radically change the strategy: "reduced" (1) $M3CONFIG (2) Pathname.Prefix( Params.Get( 0 )) (3) give up We should now consider the advantages and disadvantages of each of the proposals. The following lists are not complete; I just make a start and others please extend as they see fit: "traditional" advantages: o seems to have worked OK with cm3, cm3ide etc. until now -- never change a running system (not very convincing ;-) disadvantages: o system dependent non-standard values only possible via environment settings M3CONFIG or PATH o not simple and easy to remember "extended" advantages: o just an extension to existing strategy o allows for several conventional standard locations for config files disadvantages: o not simple and easy to remember, may be confusing "reduced" advantages: o simple and easy to remember disadvantages: o system dependent non-standard values only possible via environment setting of M3CONFIG o may be incompatible with certain use cases of cm3 and cm3ide (to be investigated) There are also the general arguments saying that "no (user) configuration of cm3 is needed at all" (really?) and "that may be said of a lot of tools and services whose config files live in /etc/ and may just be adapted by root" "we should heed the standards and conventions of existing systems in order to be used" That's of course just a start, I'm sure I have forgotten many good arguments. Let's try to keep to the facts as much as possible though. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Mon Aug 3 23:21:41 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 03 Aug 2009 23:21:41 +0200 Subject: [M3devel] /etc/cm3.cfg (was: HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig) In-Reply-To: <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> Message-ID: <1249334501.28197.750.camel@faramir.m3w.org> On Mon, 2009-08-03 at 23:15 +0200, Olaf Wagner wrote: > The compiler searches in a list of locations and takes the first > one found, as is the convention when doing path searches. AFAIK > /etc is currently the last option at all. Tried this today, and what happened was - cm3 set PKG_INSTALL to "/" and I was unable to build anything until I moved cm3.cfg back to where cm3 binary is. -- Dragi?a Duri? From hendrik at topoi.pooq.com Mon Aug 3 23:29:36 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 3 Aug 2009 17:29:36 -0400 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> Message-ID: <20090803212936.GA25621@topoi.pooq.com> On Mon, Aug 03, 2009 at 08:59:26PM +0200, Darko Volaric wrote: > Putting it in /etc would mean that having different active versions of > compiler would e a pain, which is useful when developing, debugging or > trying out new versions of the compiler and when compilers are not > self hosted, which will be the case for ARM_DARWIN. > > What's the benefit of having it /etc other than being "standard"? Things in /etc/ are things that a system administrator might want to tweak. At least that was the idea originally. These options we're talking about seem somewhat different, in that they are tightly bound with the software itself. I say they are more like executable code than like configuration files. If a Debian user were to install cm3.deb, they had damn well point to the place the package put the compiler and friends. I don't see the being usefully modified at all on a user's machine.. So, I'd say, look in /etc if some architecture policeman forces it; otherwise treat the so-called configuration as if it were part of the executable, in .../cm3/... . The environment variables are another good place to look, because that makes it easy to experiment with multiple systems on one machine. -- hendrik From hendrik at topoi.pooq.com Mon Aug 3 23:49:02 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 3 Aug 2009 17:49:02 -0400 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> Message-ID: <20090803214902.GB25621@topoi.pooq.com> One could have the configuration file contain the locations where to find other configuration file(s). The file names in tis file could have explicit notations indicating "where the compiler is", "current directory", "User's home directory", "check the environment variable", and so forth. This would make things somewhat more flexible, It's not clear whether the added complexity would get in our way. -- hendrik From jay.krell at cornell.edu Mon Aug 3 23:53:22 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 21:53:22 +0000 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> Message-ID: > advantages: > o seems to have worked OK with cm3, cm3ide etc. until now -- > never change a running system (not very convincing ;-) This is mixing up ideas. It still works, except that now I have path() instead of an actual path in the config file. That is relocatable, but turns "." into "", and requires an assumption how to navigate from path() to the root of the install. - Jay From jay.krell at cornell.edu Mon Aug 3 23:55:08 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 21:55:08 +0000 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: <20090803214902.GB25621@topoi.pooq.com> References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> <20090803214902.GB25621@topoi.pooq.com> Message-ID: Correct. cm3 could probe for exceedingly few places, and those could then include whatever they want. Like how I moved everything to config, except the initial cm3.cfg (but then ran afoul briefly of my own INSTALL_ROOT = function of path() approach) Of course there is the tension of this being user editable or not, and therefore having to put every probe in on the theory that it isn't user editable. - Jay ---------------------------------------- > Date: Mon, 3 Aug 2009 17:49:02 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig > > One could have the configuration file contain the locations where to > find other configuration file(s). The file names in tis file could have > explicit notations indicating "where the compiler is", "current > directory", "User's home directory", "check the environment variable", > and so forth. > > This would make things somewhat more flexible, It's not clear whether > the added complexity would get in our way. > > -- hendrik From lists at darko.org Mon Aug 3 23:54:44 2009 From: lists at darko.org (Darko Volaric) Date: Mon, 3 Aug 2009 23:54:44 +0200 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> Message-ID: <13F24306-B7AF-4AEE-AC24-748B44FF3D86@darko.org> Besides advantages/disadvantages, can we consider user requirements? People who do native Mac development would need to (regularly) build for 3 targets: I386_DARWIN, AMD64_DARWIN and PPC_DARWIN which requires three different compilers, different libraries and different cfg files. In my mind the simplest solution would be to look next to the binary first as it does now, unless some new arrangement selects cfg files by the compiler target arch. Do we need to break the existing system and compatibility with existing installations and processes and if so, what is the payoff, besides simplification? On 03/08/2009, at 11:15 PM, Olaf Wagner wrote: > Quoting Darko Volaric : > >> Putting it in /etc would mean that having different active versions >> of >> compiler would e a pain, which is useful when developing, debugging >> or >> trying out new versions of the compiler and when compilers are not >> self >> hosted, which will be the case for ARM_DARWIN. >> >> What's the benefit of having it /etc other than being "standard"? > > The compiler searches in a list of locations and takes the first > one found, as is the convention when doing path searches. AFAIK > /etc is currently the last option at all. > > Perhaps we should try to gather the facts and write up a pro/cons > list for different options. > > In all previous releases cm3 used the following strategy to find > its configuration: > > "traditional" > > (1) ./cm3.cfg > (2) src/cm3.cfg > (3) ../src/cm3.cfg > (4) $M3CONFIG > (5) Pathname.Prefix( Params.Get( 0 )) > (6) for p in $PATH: try p/cm3.cfg > (7) give up... > > Because people were complaining that it wasn't possible to adhere > to common system conventions with CM3 installation packages, > I extended this strategy like this: > > "extended" > > (1)..(6) same as above > (7) /usr/local/cm3/etc/cm3.cfg > (8) /usr/cm3/etc/cm3.cfg > (9) /cm3/etc/cm3.cfg > (10) /usr/contrib/etc/cm3.cfg > (11) /usr/local/etc/cm3.cfg > (12) /usr/etc/cm3.cfg > (13) /opt/etc/cm3.cfg > (14) /sw/etc/cm3.cfg > (15) /etc/cm3.cfg > > I do insist neither on this list nor the order or the locations > themselves. On the other hand I do not see much harm in an extension > like this, allowing a certain degree of freedom for those preparing > system dependent installation packages. > > Recently Jay suggested to radically change the strategy: > > "reduced" > > (1) $M3CONFIG > (2) Pathname.Prefix( Params.Get( 0 )) > (3) give up > > We should now consider the advantages and disadvantages of each > of the proposals. The following lists are not complete; I just make > a start and others please extend as they see fit: > > "traditional" > > advantages: > o seems to have worked OK with cm3, cm3ide etc. until now -- > never change a running system (not very convincing ;-) > > disadvantages: > o system dependent non-standard values only possible via environment > settings M3CONFIG or PATH > o not simple and easy to remember > > "extended" > > advantages: > o just an extension to existing strategy > o allows for several conventional standard locations for config files > > disadvantages: > o not simple and easy to remember, may be confusing > > "reduced" > > advantages: > o simple and easy to remember > > disadvantages: > o system dependent non-standard values only possible via environment > setting of M3CONFIG > o may be incompatible with certain use cases of cm3 and cm3ide (to > be investigated) > > There are also the general arguments saying that > > "no (user) configuration of cm3 is needed at all" (really?) > > and > > "that may be said of a lot of tools and services whose config files > live in /etc/ and may just be adapted by root" > > "we should heed the standards and conventions of existing systems > in order to be used" > > That's of course just a start, I'm sure I have forgotten many good > arguments. Let's try to keep to the facts as much as possible though. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From jay.krell at cornell.edu Mon Aug 3 23:56:50 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 21:56:50 +0000 Subject: [M3devel] assembly goes to C compiler? In-Reply-To: <20090803163625.qm007v2pfog8s8sg@mail.elegosoft.com> References: <20090803132158.walcuy2s00wck04g@mail.elegosoft.com> <20090803131048.GB24864@topoi.pooq.com> <4AD30F1F-90E6-48F8-B93C-6889E8D2BAF4@cs.purdue.edu> <20090803163625.qm007v2pfog8s8sg@mail.elegosoft.com> Message-ID: asssemble is used for cm3cg output C is used for user-written assembly - Jay ---------------------------------------- > Date: Mon, 3 Aug 2009 16:36:25 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] assembly goes to C compiler? > > Quoting Tony Hosking : > >> Using the C compiler allows the assembly to have preprocessor directives. > > So you think it's a feature. Why do we have the assemble methods > in the config file then? Or are they just legacy? > > %---------------------------------------------------------------- > assembler --- > % "assemble" is called to assemble .s or .asm files. Note that this function > % is only called if your program or library explicitly includes > assembly source > % code, the system distributed by Critical Mass does not. > > proc assemble(source, object) is > if defined("configure_assembler") > configure_assembler() > end > return try_exec("@" & SYSTEM_ASM, source, "-o", object) > end > > Probably a remnant of DEC SRC M3? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From lists at darko.org Mon Aug 3 23:59:43 2009 From: lists at darko.org (Darko Volaric) Date: Mon, 3 Aug 2009 23:59:43 +0200 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: <20090803212936.GA25621@topoi.pooq.com> References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803212936.GA25621@topoi.pooq.com> Message-ID: The cfg files contain library lists which I change all the time. I understand there is a lot of build scripting in there too, but I ignore that and assume it's correct and see it only as a user config file. Maybe the "executable" bits need to moved elsewhere? Environment variables are pretty loathsome in my opinion. This is a bit of creeping unixism, but not everyone likes unix. On 03/08/2009, at 11:29 PM, hendrik at topoi.pooq.com wrote: > On Mon, Aug 03, 2009 at 08:59:26PM +0200, Darko Volaric wrote: >> Putting it in /etc would mean that having different active versions >> of >> compiler would e a pain, which is useful when developing, debugging >> or >> trying out new versions of the compiler and when compilers are not >> self hosted, which will be the case for ARM_DARWIN. >> >> What's the benefit of having it /etc other than being "standard"? > > Things in /etc/ are things that a system administrator might want to > tweak. At least that was the idea originally. These options we're > talking about seem somewhat different, in that they are tightly bound > with the software itself. I say they are more like executable code > than > like configuration files. If a Debian user were to install cm3.deb, > they had damn well point to the place the package put the compiler and > friends. I don't see the being usefully modified at all on a user's > machine.. > > So, I'd say, look in /etc if some architecture policeman forces it; > otherwise treat the so-called configuration as if it were part of the > executable, in .../cm3/... . > > The environment variables are another good place to look, because that > makes it easy to experiment with multiple systems on one machine. > > -- hendrik From jay.krell at cornell.edu Tue Aug 4 00:00:52 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 22:00:52 +0000 Subject: [M3devel] some cvs errors? In-Reply-To: <20090803131445.d5u1i1vaf484kg4s@mail.elegosoft.com> References: <20090803131445.d5u1i1vaf484kg4s@mail.elegosoft.com> Message-ID: One error, the second one, was maybe local, not on the server. I saw it again later while running make-dist.sh, it tries to update itself. Not clear why it occured here, maybe I had one running and the use of $Id$ caused an attempted and failed write. Or maybe the error was on the server. With CVS, can't be sure of much imho. The other seems ok. +2 for replacing cvs with something better.. after we invent more time... - Jay ---------------------------------------- > Date: Mon, 3 Aug 2009 13:14:45 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; m3-support at elego.de > Subject: Re: some cvs errors? > > Quoting Jay K : > >> "/tmp/cvsUsaGYO" 61 lines, 1835 characters >> /usr/cvs/cm3/m3-sys/m3cc/src/m3makefile,v <-- src/m3makefile >> new revision: 1.111.2.4; previous revision: 1.111.2.3 >> Cannot Open data file (cwd: /usr/local/tinderbox/bonsai; >> data/temp.8776): Bad fi >> >> ? PKGS >> /usr/cvs/cm3/scripts/find-packages.sh,v <-- find-packages.sh >> new revision: 1.9.2.1; previous revision: 1.9 >> /usr/cvs/cm3/scripts/find-src-dirs.sh,v <-- find-src-dirs.sh >> new revision: 1.2.2.1; previous revision: 1.2 >> /usr/cvs/cm3/scripts/list-pkg-dirs.sh,v <-- list-pkg-dirs.sh >> new revision: 1.2.2.1; previous revision: 1.2 >> /usr/cvs/cm3/scripts/make-dist.sh,v <-- make-dist.sh >> new revision: 1.26.2.5; previous revision: 1.26.2.4 >> cvs [commit aborted]: cannot rename file .new.make-dist.sh to >> make-dist.sh: Permission denied >> >> >> ? >> >> I think the commits made it. > > What were these? Do we need to investigate them? > Or is everything OK now? > > Still trying to catch up with all my mails, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Tue Aug 4 00:05:27 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 22:05:27 +0000 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803212936.GA25621@topoi.pooq.com> Message-ID: I have to admit there is a mix of "clearly almost always correct, maybe really always" and "perhaps user editable code" in there. I have hoped for no user editing but can't claim I got there, due to the library issues as you say, and maybe even -gstabs vs. -gstabs+ vs. -g, etc. -- heck maybe user wants slightly smaller binaries and doesn't mind slight loss of debugging, and doesn't want to strip afterward. I did try to find "fairly canonical" places for libraries, such as wherever the platform package system installs things, but ultimately you can build yourself and get /usr/local instead of /usr/pkg, etc. A possible solution is for the cm3.cfg file itself to probe, "at certain well defined points" for "certain well defined data", as well as leaving things not readonly. For example at the very end it might probe for $HOME/etc/cm3.cfg and /etc/cm3.cfg and include them if they exist, or just the first. I also don't want to get into the business of merging these files on user machines, either automatically or making people do it. I guess we are in the second situation now however. A partial approach is to move more of the code into cm3, perhaps merely as Quake snippets, but that is perhaps overkill. - Jay ---------------------------------------- > From: lists at darko.org > To: hendrik at topoi.pooq.com > Date: Mon, 3 Aug 2009 23:59:43 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig > > The cfg files contain library lists which I change all the time. I > understand there is a lot of build scripting in there too, but I > ignore that and assume it's correct and see it only as a user config > file. Maybe the "executable" bits need to moved elsewhere? > > Environment variables are pretty loathsome in my opinion. This is a > bit of creeping unixism, but not everyone likes unix. > > > On 03/08/2009, at 11:29 PM, hendrik at topoi.pooq.com wrote: > >> On Mon, Aug 03, 2009 at 08:59:26PM +0200, Darko Volaric wrote: >>> Putting it in /etc would mean that having different active versions >>> of >>> compiler would e a pain, which is useful when developing, debugging >>> or >>> trying out new versions of the compiler and when compilers are not >>> self hosted, which will be the case for ARM_DARWIN. >>> >>> What's the benefit of having it /etc other than being "standard"? >> >> Things in /etc/ are things that a system administrator might want to >> tweak. At least that was the idea originally. These options we're >> talking about seem somewhat different, in that they are tightly bound >> with the software itself. I say they are more like executable code >> than >> like configuration files. If a Debian user were to install cm3.deb, >> they had damn well point to the place the package put the compiler and >> friends. I don't see the being usefully modified at all on a user's >> machine.. >> >> So, I'd say, look in /etc if some architecture policeman forces it; >> otherwise treat the so-called configuration as if it were part of the >> executable, in .../cm3/... . >> >> The environment variables are another good place to look, because that >> makes it easy to experiment with multiple systems on one machine. >> >> -- hendrik > From jay.krell at cornell.edu Tue Aug 4 00:21:36 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 22:21:36 +0000 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803212936.GA25621@topoi.pooq.com> Message-ID: I'm on the fence wrt environment variables. It is fairly rare for users to run executables by full path. $PATH search and changing $PATH seems to be the way. But what paths code tends to use, not sure. It might also be blurry as "code" that runs stuff is initially users coding up their command lines in sh and then gradually formalizing things, and "formal" might or might not mean using full paths. On Windows, there is no /usr/include. You either set $INCLUDE and $LIB and/or you give paths to the compiler/linker on the command line. Or a mix. Environment variables are The way to set something and have it be inherited by child processes, but not inherited by the rest of the system. They lead to a process tree that works in one setup/configured temporary way. But don't lead to an overall system that works a particular way, unless you set them somewhere with enough impact. There is a larger problem in software wrt how to handle "settings". There are environment variables. There are lots of text files in /etc. There is the Windows registry. They all have pluses and minuses. Really, the Windows registry does have pluses. The problem is related to just how many settings there are. The more you need, the more general a solution is needed, and the less satisfactory it is bound to be. It is far more complicated than most people realize. "settings" are contextual. They can be per user, per machine, per user+machine combination, and more. I'm sure people will claim "but such and such system solves it all", and maybe, but unlikely imho. I mean, heck, per user but I have multiple machines. How do I instantly change all my machines to use an orange desktop? Oh, well, there are "roaming profiles" on Windows and networked $HOME directories on Windows. Maybe. But I've basically never used them, so maybe they do solve it? There are also settings that shouldn't be settings. My terminal emulation usually doesn't quite work. (Amzazing how much does not work..). I find myself messing with $TERM but I should never have to. And still it doesn't work so maybe I don't have to, the problem is elsewhere.. - Jay ---------------------------------------- > From: lists at darko.org > To: hendrik at topoi.pooq.com > Date: Mon, 3 Aug 2009 23:59:43 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig > > The cfg files contain library lists which I change all the time. I > understand there is a lot of build scripting in there too, but I > ignore that and assume it's correct and see it only as a user config > file. Maybe the "executable" bits need to moved elsewhere? > > Environment variables are pretty loathsome in my opinion. This is a > bit of creeping unixism, but not everyone likes unix. > > > On 03/08/2009, at 11:29 PM, hendrik at topoi.pooq.com wrote: > >> On Mon, Aug 03, 2009 at 08:59:26PM +0200, Darko Volaric wrote: >>> Putting it in /etc would mean that having different active versions >>> of >>> compiler would e a pain, which is useful when developing, debugging >>> or >>> trying out new versions of the compiler and when compilers are not >>> self hosted, which will be the case for ARM_DARWIN. >>> >>> What's the benefit of having it /etc other than being "standard"? >> >> Things in /etc/ are things that a system administrator might want to >> tweak. At least that was the idea originally. These options we're >> talking about seem somewhat different, in that they are tightly bound >> with the software itself. I say they are more like executable code >> than >> like configuration files. If a Debian user were to install cm3.deb, >> they had damn well point to the place the package put the compiler and >> friends. I don't see the being usefully modified at all on a user's >> machine.. >> >> So, I'd say, look in /etc if some architecture policeman forces it; >> otherwise treat the so-called configuration as if it were part of the >> executable, in .../cm3/... . >> >> The environment variables are another good place to look, because that >> makes it easy to experiment with multiple systems on one machine. >> >> -- hendrik > From jay.krell at cornell.edu Tue Aug 4 00:23:56 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 22:23:56 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <4A76FEED.1E75.00D7.1@scires.com> References: <20090803093135.3F59DCC81B@birch.elegosoft.com> <4A76CADA.1E75.00D7.1@scires.com> <4A76FEED.1E75.00D7.1@scires.com> Message-ID: I failed to figure how to move anything at all to RC2 (perhaps that is by-design, Olaf escalating and using more and more arcane features of cvs to stay ahead of me), but I moved it to the release branch, which should get it at least into whatever if anything follows RC2. The fix seems fragile though. Converting to a full path would probably be better. (Full paths are still contextual, but most people/code seem ok ignoring that. Could be net used or chroot..) - Jay ________________________________ > Date: Mon, 3 Aug 2009 15:17:30 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > > > > > Jay: > > > > Your change to MxConfig.m3 seems to work fine for cm3ide, provided that I replace HOST by "NT386" in my cm3.cfg is as follows: > > > > INSTALL_ROOT = path() & "/.." > include (path() & "/config/NT386") > > > > Thank you! > > > > Can we get your revised MxConfig.m3 put into the RC2 branch? > > > > Regards, > > Randy > >>>> "Randy Coleburn" 8/3/2009 11:35 AM>>> > > Jay: > > I agree that running cm3 from "bin" folder is not going to be productive; however, other programs (such as cm3ide) also use the quake stuff and they don't have this limitation. I think your change is a good one. I'll run some tests and see how cm3ide fares. Thanks. > > --Randy > >>>> Jay Krell 8/3/2009 11:31 AM>>> > CVSROOT:/usr/cvs > Changes by:jkrell at birch.09/08/03 11:31:35 > > Modified files: > cm3/m3-sys/m3quake/src/: MxConfig.m3 > > Log message: > use "." instead of empty string for path() when current working > directory is the actual directory of cm3; not sure what good > running cm3 here is, and we probe way too many places.. > From jay.krell at cornell.edu Tue Aug 4 00:25:25 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 22:25:25 +0000 Subject: [M3devel] /etc/cm3.cfg (was: HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig) In-Reply-To: <1249334501.28197.750.camel@faramir.m3w.org> References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> <1249334501.28197.750.camel@faramir.m3w.org> Message-ID: If you put your cm3.cfg in /etc, you will have to edit it. INSTALL_ROOT = path() & "/.." won't be correct, and then everything computed from it. - Jay ---------------------------------------- > From: dragisha at m3w.org > To: wagner at elegosoft.com > Date: Mon, 3 Aug 2009 23:21:41 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] /etc/cm3.cfg (was: HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig) > > On Mon, 2009-08-03 at 23:15 +0200, Olaf Wagner wrote: >> The compiler searches in a list of locations and takes the first >> one found, as is the convention when doing path searches. AFAIK >> /etc is currently the last option at all. > > Tried this today, and what happened was - cm3 set PKG_INSTALL to "/" and > I was unable to build anything until I moved cm3.cfg back to where cm3 > binary is. > -- > Dragi?a Duri? > From jay.krell at cornell.edu Tue Aug 4 00:25:42 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 22:25:42 +0000 Subject: [M3devel] /etc/cm3.cfg (was: HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig) In-Reply-To: <1249334501.28197.750.camel@faramir.m3w.org> References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> <1249334501.28197.750.camel@faramir.m3w.org> Message-ID: (unless cm3 is in /etc and / is your install root) ---------------------------------------- > From: jay.krell at cornell.edu > To: dragisha at m3w.org; wagner at elegosoft.com > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] /etc/cm3.cfg (was: HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig) > Date: Mon, 3 Aug 2009 22:25:25 +0000 > > > If you put your cm3.cfg in /etc, you will have to edit it. > INSTALL_ROOT = path() & "/.." won't be correct, and then everything computed from it. > > - Jay > > > ---------------------------------------- >> From: dragisha at m3w.org >> To: wagner at elegosoft.com >> Date: Mon, 3 Aug 2009 23:21:41 +0200 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] /etc/cm3.cfg (was: HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig) >> >> On Mon, 2009-08-03 at 23:15 +0200, Olaf Wagner wrote: >>> The compiler searches in a list of locations and takes the first >>> one found, as is the convention when doing path searches. AFAIK >>> /etc is currently the last option at all. >> >> Tried this today, and what happened was - cm3 set PKG_INSTALL to "/" and >> I was unable to build anything until I moved cm3.cfg back to where cm3 >> binary is. >> -- >> Dragi?a Duri? >> From jay.krell at cornell.edu Tue Aug 4 00:29:48 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 22:29:48 +0000 Subject: [M3devel] the SOLgnu alignment problem finally understood In-Reply-To: <20090803132628.krcbd41hy8ggs8s8@mail.elegosoft.com> References: <20090803132628.krcbd41hy8ggs8s8@mail.elegosoft.com> Message-ID: cm3cg's lack of support for -g or -gdwarf etc. shouldn't mean gcc/gas doesn't support -g. Yes, -g is rare in the config files. This was perhaps an oversight. This seems like a gcc or gas bug, but oh well. My gcc is old 3.x. Note that on some systems -gstabs isn't supported, like PA64_HPUX I think. But using cm3cg -g tends to "internal compiler error" and such. A problem for the potential future, things are adequate for now. - Jay ---------------------------------------- > Date: Mon, 3 Aug 2009 13:26:28 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: the SOLgnu alignment problem finally understood > > We had similar problems before with -g. CM3 never supported dwarf > debugging format, just stabs. I think we changed all -g occurences > in the config files to -gstabs some years ago. > > It sounds like a small fix in the config files after all, correct? > At least for this RC? > > Olaf > > Quoting Jay K : > >> >> Here finally is a small example of the SOLgnu problem I've been >> looking at it. >> >> >> It is specific to using /usr/sfw/bin/gcc -g to asssemble. >> No problem without -g, no problem with /usr/bin/cc, no problem with >> whatever I built in /usr/local/bin/gcc, no problem if you assemble >> with anything else and then link with /usr/sfw/bin/gcc -g. >> >> >> -bash-3.00$ cat 4.c asm.s >> >> 4.c >> void Asm(void); >> #include >> >> int main() >> { >> Asm(); >> printf("\n"); >> return 0; >> } >> >> asm.s >> >> .section ".text",#alloc,#execinstr >> .align 4 >> .global Asm >> .type Asm,#function >> Asm: >> retl >> nop >> .size Asm, (.-Asm) >> >> >> Not all possibilities shown here: >> >> >> -bash-3.00$ /usr/local/bin/gcc -g asm.s 4.c >> ok >> >> >> -bash-3.00$ /usr/sfw/bin/gcc -g asm.s 4.c >> ld: fatal: relocation error: R_SPARC_32: file /var/tmp//ccICgvny.o: >> symbol : offset 0xfeed139e is non-aligned >> ld: fatal: relocation error: R_SPARC_32: file /var/tmp//ccICgvny.o: >> symbol : offset 0xfeed14c2 is non-aligned >> ld: fatal: relocation error: R_SPARC_32: file /var/tmp//ccICgvny.o: >> symbol : offset 0xfeed15f6 is non-aligned >> collect2: ld returned 1 exit status >> >> >> -bash-3.00$ /usr/bin/cc -g asm.s 4.c >> asm.s: >> 4.c: >> ok >> >> -bash-3.00$ /usr/bin/cc asm.s 4.c >> asm.s: >> 4.c: >> ok >> >> >> -bash-3.00$ /usr/sfw/bin/gcc asm.s 4.c >> ok >> >> >> -bash-3.00$ /usr/local/bin/gcc asm.s 4.c >> ok >> >> >> -bash-3.00$ /usr/sfw/bin/gcc -g -c asm.s >> ok but haven't linked yet, input to later steps >> >> >> -bash-3.00$ /usr/bin/cc asm.o 4.c >> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >> ff10148e is non-aligned >> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >> ff1014ca is non-aligned >> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >> ff1015be is non-aligned >> >> >> -bash-3.00$ /usr/local/bin/gcc asm.o 4.c >> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >> feee1213 is non-aligned >> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >> feee122a is non-aligned >> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >> feee122e is non-aligned >> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >> feee1232 is non-aligned >> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >> feee126e is non-aligned >> collect2: ld returned 1 exit status >> >> >> >> -bash-3.00$ /usr/local/bin/gcc -g -c asm.s >> ok, try linking with others >> >> >> -bash-3.00$ /usr/bin/cc asm.o 4.c >> ok >> >> >> >> -bash-3.00$ /usr/sfw/bin/gcc asm.o 4.c >> ok >> >> >> Actually even -gstabs or -gstabs+ instead of -g make it work. >> -g resolves to -gdwarf2. >> >> >> - Jay > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Tue Aug 4 00:31:04 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 22:31:04 +0000 Subject: [M3devel] the SOLgnu alignment problem finally understood In-Reply-To: <20090803132628.krcbd41hy8ggs8s8@mail.elegosoft.com> References: <20090803132628.krcbd41hy8ggs8s8@mail.elegosoft.com> Message-ID: ps: building RC2 with my /usr/local/bin/gcc is also viable That is how things were working. It is confused to use /usr/ccs/bin/as, and the -g doesn't get passed down to it I think it was. I might not get anything else in for ~two days.. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > CC: m3devel at elegosoft.com > Subject: RE: the SOLgnu alignment problem finally understood > Date: Mon, 3 Aug 2009 22:29:48 +0000 > > > cm3cg's lack of support for -g or -gdwarf etc. shouldn't mean gcc/gas doesn't support -g. > Yes, -g is rare in the config files. This was perhaps an oversight. > This seems like a gcc or gas bug, but oh well. > My gcc is old 3.x. > Note that on some systems -gstabs isn't supported, like PA64_HPUX I think. > But using cm3cg -g tends to "internal compiler error" and such. > A problem for the potential future, things are adequate for now. > > - Jay > > > ---------------------------------------- >> Date: Mon, 3 Aug 2009 13:26:28 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: the SOLgnu alignment problem finally understood >> >> We had similar problems before with -g. CM3 never supported dwarf >> debugging format, just stabs. I think we changed all -g occurences >> in the config files to -gstabs some years ago. >> >> It sounds like a small fix in the config files after all, correct? >> At least for this RC? >> >> Olaf >> >> Quoting Jay K : >> >>> >>> Here finally is a small example of the SOLgnu problem I've been >>> looking at it. >>> >>> >>> It is specific to using /usr/sfw/bin/gcc -g to asssemble. >>> No problem without -g, no problem with /usr/bin/cc, no problem with >>> whatever I built in /usr/local/bin/gcc, no problem if you assemble >>> with anything else and then link with /usr/sfw/bin/gcc -g. >>> >>> >>> -bash-3.00$ cat 4.c asm.s >>> >>> 4.c >>> void Asm(void); >>> #include >>> >>> int main() >>> { >>> Asm(); >>> printf("\n"); >>> return 0; >>> } >>> >>> asm.s >>> >>> .section ".text",#alloc,#execinstr >>> .align 4 >>> .global Asm >>> .type Asm,#function >>> Asm: >>> retl >>> nop >>> .size Asm, (.-Asm) >>> >>> >>> Not all possibilities shown here: >>> >>> >>> -bash-3.00$ /usr/local/bin/gcc -g asm.s 4.c >>> ok >>> >>> >>> -bash-3.00$ /usr/sfw/bin/gcc -g asm.s 4.c >>> ld: fatal: relocation error: R_SPARC_32: file /var/tmp//ccICgvny.o: >>> symbol : offset 0xfeed139e is non-aligned >>> ld: fatal: relocation error: R_SPARC_32: file /var/tmp//ccICgvny.o: >>> symbol : offset 0xfeed14c2 is non-aligned >>> ld: fatal: relocation error: R_SPARC_32: file /var/tmp//ccICgvny.o: >>> symbol : offset 0xfeed15f6 is non-aligned >>> collect2: ld returned 1 exit status >>> >>> >>> -bash-3.00$ /usr/bin/cc -g asm.s 4.c >>> asm.s: >>> 4.c: >>> ok >>> >>> -bash-3.00$ /usr/bin/cc asm.s 4.c >>> asm.s: >>> 4.c: >>> ok >>> >>> >>> -bash-3.00$ /usr/sfw/bin/gcc asm.s 4.c >>> ok >>> >>> >>> -bash-3.00$ /usr/local/bin/gcc asm.s 4.c >>> ok >>> >>> >>> -bash-3.00$ /usr/sfw/bin/gcc -g -c asm.s >>> ok but haven't linked yet, input to later steps >>> >>> >>> -bash-3.00$ /usr/bin/cc asm.o 4.c >>> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >>> ff10148e is non-aligned >>> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >>> ff1014ca is non-aligned >>> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >>> ff1015be is non-aligned >>> >>> >>> -bash-3.00$ /usr/local/bin/gcc asm.o 4.c >>> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >>> feee1213 is non-aligned >>> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >>> feee122a is non-aligned >>> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >>> feee122e is non-aligned >>> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >>> feee1232 is non-aligned >>> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >>> feee126e is non-aligned >>> collect2: ld returned 1 exit status >>> >>> >>> >>> -bash-3.00$ /usr/local/bin/gcc -g -c asm.s >>> ok, try linking with others >>> >>> >>> -bash-3.00$ /usr/bin/cc asm.o 4.c >>> ok >>> >>> >>> >>> -bash-3.00$ /usr/sfw/bin/gcc asm.o 4.c >>> ok >>> >>> >>> Actually even -gstabs or -gstabs+ instead of -g make it work. >>> -g resolves to -gdwarf2. >>> >>> >>> - Jay >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> From jay.krell at cornell.edu Tue Aug 4 00:33:40 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 22:33:40 +0000 Subject: [M3devel] the SOLgnu alignment problem finally understood In-Reply-To: References: <20090803132628.krcbd41hy8ggs8s8@mail.elegosoft.com> Message-ID: < confused > configured oops ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > Date: Mon, 3 Aug 2009 22:31:04 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] the SOLgnu alignment problem finally understood > > > ps: building RC2 with my /usr/local/bin/gcc is also viable > That is how things were working. > It is confused to use /usr/ccs/bin/as, and the -g doesn't get passed down to it I think it was. > I might not get anything else in for ~two days.. > > > - Jay > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com >> CC: m3devel at elegosoft.com >> Subject: RE: the SOLgnu alignment problem finally understood >> Date: Mon, 3 Aug 2009 22:29:48 +0000 >> >> >> cm3cg's lack of support for -g or -gdwarf etc. shouldn't mean gcc/gas doesn't support -g. >> Yes, -g is rare in the config files. This was perhaps an oversight. >> This seems like a gcc or gas bug, but oh well. >> My gcc is old 3.x. >> Note that on some systems -gstabs isn't supported, like PA64_HPUX I think. >> But using cm3cg -g tends to "internal compiler error" and such. >> A problem for the potential future, things are adequate for now. >> >> - Jay >> >> >> ---------------------------------------- >>> Date: Mon, 3 Aug 2009 13:26:28 +0200 >>> From: wagner at elegosoft.com >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com >>> Subject: Re: the SOLgnu alignment problem finally understood >>> >>> We had similar problems before with -g. CM3 never supported dwarf >>> debugging format, just stabs. I think we changed all -g occurences >>> in the config files to -gstabs some years ago. >>> >>> It sounds like a small fix in the config files after all, correct? >>> At least for this RC? >>> >>> Olaf >>> >>> Quoting Jay K : >>> >>>> >>>> Here finally is a small example of the SOLgnu problem I've been >>>> looking at it. >>>> >>>> >>>> It is specific to using /usr/sfw/bin/gcc -g to asssemble. >>>> No problem without -g, no problem with /usr/bin/cc, no problem with >>>> whatever I built in /usr/local/bin/gcc, no problem if you assemble >>>> with anything else and then link with /usr/sfw/bin/gcc -g. >>>> >>>> >>>> -bash-3.00$ cat 4.c asm.s >>>> >>>> 4.c >>>> void Asm(void); >>>> #include >>>> >>>> int main() >>>> { >>>> Asm(); >>>> printf("\n"); >>>> return 0; >>>> } >>>> >>>> asm.s >>>> >>>> .section ".text",#alloc,#execinstr >>>> .align 4 >>>> .global Asm >>>> .type Asm,#function >>>> Asm: >>>> retl >>>> nop >>>> .size Asm, (.-Asm) >>>> >>>> >>>> Not all possibilities shown here: >>>> >>>> >>>> -bash-3.00$ /usr/local/bin/gcc -g asm.s 4.c >>>> ok >>>> >>>> >>>> -bash-3.00$ /usr/sfw/bin/gcc -g asm.s 4.c >>>> ld: fatal: relocation error: R_SPARC_32: file /var/tmp//ccICgvny.o: >>>> symbol : offset 0xfeed139e is non-aligned >>>> ld: fatal: relocation error: R_SPARC_32: file /var/tmp//ccICgvny.o: >>>> symbol : offset 0xfeed14c2 is non-aligned >>>> ld: fatal: relocation error: R_SPARC_32: file /var/tmp//ccICgvny.o: >>>> symbol : offset 0xfeed15f6 is non-aligned >>>> collect2: ld returned 1 exit status >>>> >>>> >>>> -bash-3.00$ /usr/bin/cc -g asm.s 4.c >>>> asm.s: >>>> 4.c: >>>> ok >>>> >>>> -bash-3.00$ /usr/bin/cc asm.s 4.c >>>> asm.s: >>>> 4.c: >>>> ok >>>> >>>> >>>> -bash-3.00$ /usr/sfw/bin/gcc asm.s 4.c >>>> ok >>>> >>>> >>>> -bash-3.00$ /usr/local/bin/gcc asm.s 4.c >>>> ok >>>> >>>> >>>> -bash-3.00$ /usr/sfw/bin/gcc -g -c asm.s >>>> ok but haven't linked yet, input to later steps >>>> >>>> >>>> -bash-3.00$ /usr/bin/cc asm.o 4.c >>>> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >>>> ff10148e is non-aligned >>>> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >>>> ff1014ca is non-aligned >>>> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >>>> ff1015be is non-aligned >>>> >>>> >>>> -bash-3.00$ /usr/local/bin/gcc asm.o 4.c >>>> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >>>> feee1213 is non-aligned >>>> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >>>> feee122a is non-aligned >>>> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >>>> feee122e is non-aligned >>>> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >>>> feee1232 is non-aligned >>>> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >>>> feee126e is non-aligned >>>> collect2: ld returned 1 exit status >>>> >>>> >>>> >>>> -bash-3.00$ /usr/local/bin/gcc -g -c asm.s >>>> ok, try linking with others >>>> >>>> >>>> -bash-3.00$ /usr/bin/cc asm.o 4.c >>>> ok >>>> >>>> >>>> >>>> -bash-3.00$ /usr/sfw/bin/gcc asm.o 4.c >>>> ok >>>> >>>> >>>> Actually even -gstabs or -gstabs+ instead of -g make it work. >>>> -g resolves to -gdwarf2. >>>> >>>> >>>> - Jay >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >>> From hendrik at topoi.pooq.com Tue Aug 4 00:37:10 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 3 Aug 2009 18:37:10 -0400 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803212936.GA25621@topoi.pooq.com> Message-ID: <20090803223710.GE25621@topoi.pooq.com> On Mon, Aug 03, 2009 at 10:21:36PM +0000, Jay K wrote: > > I'm on the fence wrt environment variables. > > > It is fairly rare for users to run executables by full path. > $PATH search and changing $PATH seems to be the way. > > > But what paths code tends to use, not sure. > It might also be blurry as "code" that runs stuff is initially users coding up their command lines in sh and then gradually formalizing things, and "formal" might or might not mean using full paths. > > > On Windows, there is no /usr/include. > You either set $INCLUDE and $LIB and/or you give paths to the > compiler/linker on the command line. Or a mix. > > > Environment variables are The way to set something and have it be > inherited by child processes, but not inherited by the rest of the > system. > > > They lead to a process tree that works in one setup/configured temporary way. > But don't lead to an overall system that works a particular way, > unless you set them somewhere with enough impact. > That is exactly the mad scientist whill want when he's tinkering with deviant Modula 3 compilers. But it's not what the average user will want. And it's not what the mad compiler tinkerer will want when he's just compiling ordinary programs. So let an environment variable override whatever else would be used to find the configuration file. And leave it undefined for the average user. > > There is a larger problem in software wrt how to handle "settings". > There are environment variables. There are lots of text files in > /etc. There is the Windows registry. > They all have pluses and minuses. Really, the Windows registry does > have pluses. > The problem is related to just how many settings there are. > The more you need, the more general a solution is needed, and the less > satisfactory it is bound to be. > > > It is far more complicated than most people realize. > "settings" are contextual. They can be per user, per machine, per > user+machine combination, and more. > I'm sure people will claim "but such and such system solves it all", > and maybe, but unlikely imho. > I mean, heck, per user but I have multiple machines. > How do I instantly change all my machines to use an orange desktop? > Oh, well, there are "roaming profiles" on Windows and networked > $HOME directories on Windows. Maybe. But I've basically never used > them, so maybe they do solve it? Let the user provide a program that, when run, will write the configuration file to stdout? Let the user provide a web page with an applet that .... etc. etc. > > There are also settings that shouldn't be settings. > My terminal emulation usually doesn't quite work. (Amzazing how much > does not work..). I find myself messing with $TERM but I should never > have to. And still it doesn't work so maybe I don't have to, the > problem is elsewhere.. My terminal won't come up at all unless I first start iceweasel or gnucash or Pan (maybe some others). But messing with $TERM won't fix this. The problem is elsewhere. :-) > > > > - Jay From jay.krell at cornell.edu Tue Aug 4 01:42:12 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 23:42:12 +0000 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: <20090803223710.GE25621@topoi.pooq.com> References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803212936.GA25621@topoi.pooq.com> <20090803223710.GE25621@topoi.pooq.com> Message-ID: > That is exactly the mad scientist whill want when he's tinkering with > deviant Modula 3 compilers. But it's not what the average user will > want. And it's not what the mad compiler tinkerer will want when he's > just compiling ordinary programs. So let an environment variable > override whatever else would be used to find the configuration file. > And leave it undefined for the average user. I have been a proponent of what you say. And I have tried to achieve it. However it is not clear if I got there. The system-wide library paths, one example, are what the "(mad) Linux tinkerer" might alter, once and be done, not merely the "compiler tinkerer". There may be too many such people. Even for the mad tinkerer to have his own system-wide gcc might be common? Again, more of a "once and be done" mode, not often changing? The config files ultimately don't even that much. The previous authors did factor them fairly well. Just not /quite/ enough to my taste. :) I think primarly it was due to the times. There was more variety back then perhaps, and fewer cases of the same compiler (gcc) being on multiple systems or the same kernels being on multiple processors. For example, Solaris.common would not have made sense, there was just 32bit SPARC. For example, Linux.common would not have made sense, there was just x86. FreeBSD/OpenBSD/NetBSD all fairly young too. Ultimately I gather..and I haven't gotten here yet, but ultimately I think the tinkering escapes to chroot, whereupon from our point of view it ceases being tinkering. The contents of the files might change but the the names are restored to normal. :) As well though, the mad tinkerer is root? And is ok editing text files outside of /etc? - Jay From jay.krell at cornell.edu Tue Aug 4 02:18:06 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 4 Aug 2009 00:18:06 +0000 Subject: [M3devel] FW: HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: <20090803223710.GE25621@topoi.pooq.com> References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803212936.GA25621@topoi.pooq.com> <20090803223710.GE25621@topoi.pooq.com> Message-ID: [was truncated] ---------------------------------------- > From: jay.krell at cornell.edu > To: hendrik at topoi.pooq.com; m3devel at elegosoft.com > Subject: RE: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig > Date: Mon, 3 Aug 2009 23:42:12 +0000 > > >> That is exactly the mad scientist whill want when he's tinkering with >> deviant Modula 3 compilers. But it's not what the average user will >> want. And it's not what the mad compiler tinkerer will want when he's >> just compiling ordinary programs. So let an environment variable >> override whatever else would be used to find the configuration file. >> And leave it undefined for the average user. > > > I have been a proponent of what you say. > And I have tried to achieve it. > > > However it is not clear if I got there. > > > The system-wide library paths, one example, > are what the "(mad) Linux tinkerer" might > alter, once and be done, not merely the > "compiler tinkerer". There may be too many such people. > > > Even for the mad tinkerer to have his own > system-wide gcc might be common? > Again, more of a "once and be done" mode, > not often changing? > > > The config files ultimately don't even that much. > The previous authors did factor them fairly well. > Just not /quite/ enough to my taste. :) > I think primarly it was due to the times. > There was more variety back then perhaps, and fewer > cases of the same compiler (gcc) being on multiple > systems or the same kernels being on multiple processors. > > > For example, Solaris.common would not have made sense, there was just 32bit SPARC. > For example, Linux.common would not have made sense, there was just x86. > FreeBSD/OpenBSD/NetBSD all fairly young too. > > > Ultimately I gather..and I haven't gotten here yet, > but ultimately I think the tinkering escapes to chroot, > whereupon from our point of view it ceases being tinkering. > The contents of the files might change but the the names > are restored to normal. :) > > > As well though, the mad tinkerer is root? > And is ok editing text files outside of /etc? > > > > - Jay From hendrik at topoi.pooq.com Tue Aug 4 02:27:54 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 3 Aug 2009 20:27:54 -0400 Subject: [M3devel] testing RC2. Message-ID: <20090804002754.GF25621@topoi.pooq.com> Now that I've updated the wikipedia entry, it's easier to find the RC2 downloads page. How can I update the other places that are easy to find on the google? Specifically, the Modula 3 resource page, www.modula3.org/ Modula-3 Frequently Asked Questions (FAQ), www.faqs.org/faqs/Modula-3-faq/ I'll soon be trying another installation fromscratch, using RC2, and I'll let you know how it went. -- hendrik From hendrik at topoi.pooq.com Tue Aug 4 02:38:27 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 3 Aug 2009 20:38:27 -0400 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: References: <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803212936.GA25621@topoi.pooq.com> <20090803223710.GE25621@topoi.pooq.com> Message-ID: <20090804003826.GG25621@topoi.pooq.com> On Mon, Aug 03, 2009 at 11:42:12PM +0000, Jay K wrote: > > > That is exactly the mad scientist whill want when he's tinkering with > > deviant Modula 3 compilers. But it's not what the average user will > > want. And it's not what the mad compiler tinkerer will want when he's > > just compiling ordinary programs. So let an environment variable > > override whatever else would be used to find the configuration file. > > And leave it undefined for the average user. > > > I have been a proponent of what you say. > And I have tried to achieve it. > > > However it is not clear if I got there. > > > The system-wide library paths, one example, > are what the "(mad) Linux tinkerer" might > alter, once and be done, not merely the > "compiler tinkerer". There may be too many such people. I was thinking of the mad scientist who writes his own variations into Modula 3, and wants to use his version without it getting mixed up with the standard one available on his system. He'd want his own m3 configuration file for sure. As for the OS's other paths, on Linux the OS provides those, and lets them be overridden by the user as environment variables. He'd just better make sure they point to the ones he needs. That's his job, not ours. I'm not advocating replacing the OS. That's someone else's job, too. oh... wait a moment. Didn't we try something like that with SPIN (for suitable values of "we" that don't include "me")? -- hendrik From jay.krell at cornell.edu Tue Aug 4 02:59:32 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Mon, 3 Aug 2009 17:59:32 -0700 Subject: [M3devel] testing RC2. In-Reply-To: <20090804002754.GF25621@topoi.pooq.com> References: <20090804002754.GF25621@topoi.pooq.com> Message-ID: <1C5F772D-930B-472B-A83B-32DEC364D2FA@hotmail.com> Wikipedia: Aren't you subverting release manager Olaf? Not ready for exposure beyond m3devel? - Jay (phone) On Aug 3, 2009, at 5:27 PM, hendrik at topoi.pooq.com wrote: > Now that I've updated the wikipedia entry, it's easier to find the RC2 > downloads page. > > How can I update the other places that are easy to find on the google? > Specifically, > the Modula 3 resource page, www.modula3.org/ > Modula-3 Frequently Asked Questions (FAQ), > www.faqs.org/faqs/Modula-3-faq/ > > I'll soon be trying another installation fromscratch, using RC2, > and I'll let you know how it went. > > -- hendrik > > From wagner at elegosoft.com Tue Aug 4 08:40:32 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 04 Aug 2009 08:40:32 +0200 Subject: [M3devel] /etc/cm3.cfg (was: HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig) In-Reply-To: <1249334501.28197.750.camel@faramir.m3w.org> References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> <1249334501.28197.750.camel@faramir.m3w.org> Message-ID: <20090804084032.m4ytooeqs04cokcs@mail.elegosoft.com> Quoting Dragi?a Duri? : > On Mon, 2009-08-03 at 23:15 +0200, Olaf Wagner wrote: >> The compiler searches in a list of locations and takes the first >> one found, as is the convention when doing path searches. AFAIK >> /etc is currently the last option at all. > > Tried this today, and what happened was - cm3 set PKG_INSTALL to "/" and > I was unable to build anything until I moved cm3.cfg back to where cm3 > binary is. Well, this is just a matter of the correct contents of the configuration files then. Jay has tailored the suite to be located in .../cm3 currently. Nobody stops you to set PKG_INSTALL and other variables at the top level. If you use a 'non-standard' setup, then the files must be adapted. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Tue Aug 4 09:50:05 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 04 Aug 2009 09:50:05 +0200 Subject: [M3devel] /etc/cm3.cfg (was: HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig) In-Reply-To: <20090804084032.m4ytooeqs04cokcs@mail.elegosoft.com> References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> <1249334501.28197.750.camel@faramir.m3w.org> <20090804084032.m4ytooeqs04cokcs@mail.elegosoft.com> Message-ID: <1249372205.28197.1238.camel@faramir.m3w.org> On Tue, 2009-08-04 at 08:40 +0200, Olaf Wagner wrote: > Well, this is just a matter of the correct contents of the > configuration > files then. Jay has tailored the suite to be located in .../cm3 > currently. Nobody stops you to set PKG_INSTALL and other variables > at the top level. If you use a 'non-standard' setup, then the files > must be adapted. Figured it all out.. As cm3.cfg is twoliner, I've only created it from my RPM recipe with exact PKG_INSTALL location... Another question... While here... is there a separation of runtime and development packages in RELENG process? -- Dragi?a Duri? From wagner at elegosoft.com Tue Aug 4 10:22:54 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 04 Aug 2009 10:22:54 +0200 Subject: [M3devel] some cvs errors? In-Reply-To: References: <20090803131445.d5u1i1vaf484kg4s@mail.elegosoft.com> Message-ID: <20090804102254.yakamff0ysscccs8@mail.elegosoft.com> Quoting Jay K : > > One error, the second one, was maybe local, not on the server. > I saw it again later while running make-dist.sh, it tries to update itself. > Not clear why it occured here, maybe I had one running and the use > of $Id$ caused an attempted and failed write. Or maybe the error was > on the server. With CVS, can't be sure of much imho. > The other seems ok. > +2 for replacing cvs with something better.. after we invent more time... That something better would then be Perforce or AccuRev? Elego has got 3 committers to the Subversion project, and there are lots of problems, too. We've got several customers who are regularly pushing it over the edge of its capabilities... But I'm not against a change, as long as others will do the work ;-) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Aug 4 10:26:27 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 04 Aug 2009 10:26:27 +0200 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: <20090803214902.GB25621@topoi.pooq.com> References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> <20090803214902.GB25621@topoi.pooq.com> Message-ID: <20090804102627.bh1po5bfk0s4ggwo@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > One could have the configuration file contain the locations where to > find other configuration file(s). The file names in tis file could have > explicit notations indicating "where the compiler is", "current > directory", "User's home directory", "check the environment variable", > and so forth. > > This would make things somewhat more flexible, It's not clear whether > the added complexity would get in our way. That's just a matter of adding the appropriate quake code, isn't it? All that flexibility is already there. Getting such things correct in the details is much work though. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Aug 4 10:44:24 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 04 Aug 2009 10:44:24 +0200 Subject: [M3devel] /etc/cm3.cfg (was: HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig) In-Reply-To: <1249372205.28197.1238.camel@faramir.m3w.org> References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> <1249334501.28197.750.camel@faramir.m3w.org> <20090804084032.m4ytooeqs04cokcs@mail.elegosoft.com> <1249372205.28197.1238.camel@faramir.m3w.org> Message-ID: <20090804104424.zh0k8n7nvo8sk80g@mail.elegosoft.com> Quoting Dragi?a Duri? : > On Tue, 2009-08-04 at 08:40 +0200, Olaf Wagner wrote: >> Well, this is just a matter of the correct contents of the >> configuration >> files then. Jay has tailored the suite to be located in .../cm3 >> currently. Nobody stops you to set PKG_INSTALL and other variables >> at the top level. If you use a 'non-standard' setup, then the files >> must be adapted. > > Figured it all out.. As cm3.cfg is twoliner, I've only created it from > my RPM recipe with exact PKG_INSTALL location... > > Another question... While here... is there a separation of runtime and > development packages in RELENG process? Not really. The only real `runtime package' we currently have would be cm3-ws-bin-min..., containing m3core and libm3. But then you'r probably thinking of `binary' packages and `source packages', aren't you? M3 doesn't really do these distinctions... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Aug 4 10:58:35 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 04 Aug 2009 10:58:35 +0200 Subject: [M3devel] testing RC2. In-Reply-To: <1C5F772D-930B-472B-A83B-32DEC364D2FA@hotmail.com> References: <20090804002754.GF25621@topoi.pooq.com> <1C5F772D-930B-472B-A83B-32DEC364D2FA@hotmail.com> Message-ID: <20090804105835.vs1925r2kg480ccg@mail.elegosoft.com> Quoting jay.krell at cornell.edu: > Wikipedia: Aren't you subverting release manager Olaf? Not ready for > exposure beyond m3devel? I just moved the date for RC2 another week :-/ Too many things still to be done. See https://projects.elego.de/cm3/milestone/CM3%20Release%205.8%20RC2 We need o to improve the WWW presentation (there were suggestions from Peter Eiserloh and others but no concrete changes/commits AFAIK) o build some missing installation packages (for I386_DARWIN for example) o automate some installation tests (next thing I'll do) o get some feedback from manual tests If there are no commits to the web pages till Wednesday, I'll make some small adaptions there to be ready for RC2 then. Olaf > - Jay (phone) > > On Aug 3, 2009, at 5:27 PM, hendrik at topoi.pooq.com wrote: > >> Now that I've updated the wikipedia entry, it's easier to find the RC2 >> downloads page. >> >> How can I update the other places that are easy to find on the google? >> Specifically, >> the Modula 3 resource page, www.modula3.org/ >> Modula-3 Frequently Asked Questions (FAQ), >> www.faqs.org/faqs/Modula-3-faq/ >> >> I'll soon be trying another installation fromscratch, using RC2, >> and I'll let you know how it went. >> >> -- hendrik >> >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Tue Aug 4 13:16:47 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 04 Aug 2009 13:16:47 +0200 Subject: [M3devel] runtime/devel separation. was: Re: /etc/cm3.cfg (was: HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig) In-Reply-To: <20090804104424.zh0k8n7nvo8sk80g@mail.elegosoft.com> References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> <1249334501.28197.750.camel@faramir.m3w.org> <20090804084032.m4ytooeqs04cokcs@mail.elegosoft.com> <1249372205.28197.1238.camel@faramir.m3w.org> <20090804104424.zh0k8n7nvo8sk80g@mail.elegosoft.com> Message-ID: <1249384607.28197.1251.camel@faramir.m3w.org> On Tue, 2009-08-04 at 10:44 +0200, Olaf Wagner wrote: > Not really. > > The only real `runtime package' we currently have would be > cm3-ws-bin-min..., containing m3core and libm3. > > But then you'r probably thinking of `binary' packages and > `source packages', aren't you? M3 doesn't really do these > distinctions... No, I am not thinking about source packages. These we have - tar.gz's packed with building recipes. What I did in my RPM packaging is to separate contents (roughly): $BIN_INSTALL except compiler/debugger/related tools, $LIB_INSTALL and $PKG_INSTALL/*/$BUILD_DIR, /etc/cm3.cfg, /etc/cm3/ --> into runtime compiler/debugger, $PKG_INSTALL/*/src --> into development This way I can have my packages installed without library/program source shipped to end user. In case I need them, I just pull -devel package. I am using this scheme for some time now. What I have to work on is man1 vs. man7 and similar. Little bits and pieces. -- Dragi?a Duri? From jay.krell at cornell.edu Tue Aug 4 13:40:53 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 4 Aug 2009 11:40:53 +0000 Subject: [M3devel] some cvs errors? In-Reply-To: <20090804102254.yakamff0ysscccs8@mail.elegosoft.com> References: <20090803131445.d5u1i1vaf484kg4s@mail.elegosoft.com> <20090804102254.yakamff0ysscccs8@mail.elegosoft.com> Message-ID: Perforce is great. I'm already trained. If we can get a good deal (for being opensource) on it and someone provides hosting (with a good deal). I could never find anyone to host it. So I went with Date: Tue, 4 Aug 2009 10:22:54 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; m3-support at elego.de > Subject: Re: [M3devel] some cvs errors? > > Quoting Jay K : > >> >> One error, the second one, was maybe local, not on the server. >> I saw it again later while running make-dist.sh, it tries to update itself. >> Not clear why it occured here, maybe I had one running and the use >> of $Id$ caused an attempted and failed write. Or maybe the error was >> on the server. With CVS, can't be sure of much imho. >> The other seems ok. >> +2 for replacing cvs with something better.. after we invent more time... > > That something better would then be Perforce or AccuRev? > > Elego has got 3 committers to the Subversion project, and there are > lots of problems, too. We've got several customers who are regularly > pushing it over the edge of its capabilities... > > But I'm not against a change, as long as others will do the work ;-) > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Tue Aug 4 13:47:32 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 4 Aug 2009 11:47:32 +0000 Subject: [M3devel] some cvs errors? In-Reply-To: <20090804102254.yakamff0ysscccs8@mail.elegosoft.com> References: <20090803131445.d5u1i1vaf484kg4s@mail.elegosoft.com> <20090804102254.yakamff0ysscccs8@mail.elegosoft.com> Message-ID: Don't know what happened there..lost the content. Just that I use subversion at home, no branching, cheap. Subversion seems to do branching horribly though. Perforce does it maybe perfectly. Mercurial and monotone and git all sound good. If someone else does it, agreed. They pretty much all claim pretty good easy conversion. Not perfect, but ok. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > CC: m3devel at elegosoft.com; m3-support at elego.de > Subject: RE: [M3devel] some cvs errors? > Date: Tue, 4 Aug 2009 11:40:53 +0000 > > > Perforce is great. I'm already trained. > If we can get a good deal (for being opensource) on it and someone provides hosting (with a good deal). > I could never find anyone to host it. > So I went with Date: Tue, 4 Aug 2009 10:22:54 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com; m3-support at elego.de >> Subject: Re: [M3devel] some cvs errors? >> >> Quoting Jay K : >> >>> >>> One error, the second one, was maybe local, not on the server. >>> I saw it again later while running make-dist.sh, it tries to update itself. >>> Not clear why it occured here, maybe I had one running and the use >>> of $Id$ caused an attempted and failed write. Or maybe the error was >>> on the server. With CVS, can't be sure of much imho. >>> The other seems ok. >>> +2 for replacing cvs with something better.. after we invent more time... >> >> That something better would then be Perforce or AccuRev? >> >> Elego has got 3 committers to the Subversion project, and there are >> lots of problems, too. We've got several customers who are regularly >> pushing it over the edge of its capabilities... >> >> But I'm not against a change, as long as others will do the work ;-) >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> From jay.krell at cornell.edu Tue Aug 4 13:49:29 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 4 Aug 2009 11:49:29 +0000 Subject: [M3devel] testing RC2. In-Reply-To: <20090804105835.vs1925r2kg480ccg@mail.elegosoft.com> References: <20090804002754.GF25621@topoi.pooq.com> <1C5F772D-930B-472B-A83B-32DEC364D2FA@hotmail.com> <20090804105835.vs1925r2kg480ccg@mail.elegosoft.com> Message-ID: > build some missing installation packages (for I386_DARWIN for example) I have a new computer arriving roughly Friday on which I can setup near arbitrary x86/AMD64 VMs, as well as doing native I386_DARWIN and AMD64_DARWIN. AMD64_FREEBSD is also missing for example. Tony should also be able to do {I386,AMD64}_DARWIN. - Jay ---------------------------------------- > Date: Tue, 4 Aug 2009 10:58:35 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] testing RC2. > > Quoting jay.krell at cornell.edu: > >> Wikipedia: Aren't you subverting release manager Olaf? Not ready for >> exposure beyond m3devel? > > I just moved the date for RC2 another week :-/ Too many things still > to be done. See > > https://projects.elego.de/cm3/milestone/CM3%20Release%205.8%20RC2 > > We need > > o to improve the WWW presentation (there were suggestions from > Peter Eiserloh and others but no concrete changes/commits AFAIK) > > o build some missing installation packages (for I386_DARWIN for example) > > o automate some installation tests (next thing I'll do) > > o get some feedback from manual tests > > If there are no commits to the web pages till Wednesday, I'll make > some small adaptions there to be ready for RC2 then. > > Olaf > >> - Jay (phone) >> >> On Aug 3, 2009, at 5:27 PM, hendrik at topoi.pooq.com wrote: >> >>> Now that I've updated the wikipedia entry, it's easier to find the RC2 >>> downloads page. >>> >>> How can I update the other places that are easy to find on the google? >>> Specifically, >>> the Modula 3 resource page, www.modula3.org/ >>> Modula-3 Frequently Asked Questions (FAQ), >>> www.faqs.org/faqs/Modula-3-faq/ >>> >>> I'll soon be trying another installation fromscratch, using RC2, >>> and I'll let you know how it went. >>> >>> -- hendrik >>> >>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From rcoleburn at scires.com Tue Aug 4 17:09:32 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 04 Aug 2009 11:09:32 -0400 Subject: [M3devel] some cvs errors? In-Reply-To: <20090804102254.yakamff0ysscccs8@mail.elegosoft.com> References: <20090803131445.d5u1i1vaf484kg4s@mail.elegosoft.com> <20090804102254.yakamff0ysscccs8@mail.elegosoft.com> Message-ID: <4A78164A.1E75.00D7.1@scires.com> As far as replacing CVS with something else, I have "no dog in the race" so to speak, but I will say that CVS has worked fine for my purposes and the TortoiseCVS integration with Windows Explorer makes life easy for me on Windows. I don't have to remember all the CVS command line switches; I just use the TortoiseCVS GUI and it works. If we switch to something else that doesn't have this level of GUI, it will present a learning curve for me. Regards, Randy Coleburn >>> Olaf Wagner 8/4/2009 4:22 AM >>> Quoting Jay K : > > One error, the second one, was maybe local, not on the server. > I saw it again later while running make-dist.sh, it tries to update itself. > Not clear why it occured here, maybe I had one running and the use > of $Id$ caused an attempted and failed write. Or maybe the error was > on the server. With CVS, can't be sure of much imho. > The other seems ok. > +2 for replacing cvs with something better.. after we invent more time... That something better would then be Perforce or AccuRev? Elego has got 3 committers to the Subversion project, and there are lots of problems, too. We've got several customers who are regularly pushing it over the edge of its capabilities... But I'm not against a change, as long as others will do the work ;-) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Tue Aug 4 17:22:56 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 4 Aug 2009 11:22:56 -0400 Subject: [M3devel] /etc/cm3.cfg (was: HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig) In-Reply-To: <20090804104424.zh0k8n7nvo8sk80g@mail.elegosoft.com> References: <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> <1249334501.28197.750.camel@faramir.m3w.org> <20090804084032.m4ytooeqs04cokcs@mail.elegosoft.com> <1249372205.28197.1238.camel@faramir.m3w.org> <20090804104424.zh0k8n7nvo8sk80g@mail.elegosoft.com> Message-ID: <20090804152255.GA27699@topoi.pooq.com> On Tue, Aug 04, 2009 at 10:44:24AM +0200, Olaf Wagner wrote: > Quoting Dragi?a Duri? : > > >On Tue, 2009-08-04 at 08:40 +0200, Olaf Wagner wrote: > >>Well, this is just a matter of the correct contents of the > >>configuration > >>files then. Jay has tailored the suite to be located in .../cm3 > >>currently. Nobody stops you to set PKG_INSTALL and other variables > >>at the top level. If you use a 'non-standard' setup, then the files > >>must be adapted. > > > >Figured it all out.. As cm3.cfg is twoliner, I've only created it from > >my RPM recipe with exact PKG_INSTALL location... > > > >Another question... While here... is there a separation of runtime and > >development packages in RELENG process? > > Not really. > > The only real `runtime package' we currently have would be > cm3-ws-bin-min..., containing m3core and libm3. > > But then you'r probably thinking of `binary' packages and > `source packages', aren't you? M3 doesn't really do these distinctions... The distinction is what you need to run an executable image that uses libraries, versus what you need to compile things using them. M3 may not enable you to compile a library-using application without the library source code, but it should enable you to run the compiled code without it. That said, for the current release, I don't see it to be important to make the distinctio for the current release. It's more important to make available something up-to-date and reliably usable out soon so that people can use it. -- hendrik From hendrik at topoi.pooq.com Tue Aug 4 17:37:21 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 4 Aug 2009 11:37:21 -0400 Subject: [M3devel] testing RC2. In-Reply-To: <1C5F772D-930B-472B-A83B-32DEC364D2FA@hotmail.com> References: <20090804002754.GF25621@topoi.pooq.com> <1C5F772D-930B-472B-A83B-32DEC364D2FA@hotmail.com> Message-ID: <20090804153721.GC27699@topoi.pooq.com> On Mon, Aug 03, 2009 at 05:59:32PM -0700, jay.krell at cornell.edu wrote: > Wikipedia: Aren't you subverting release manager Olaf? Not ready for > exposure beyond m3devel? > > - Jay (phone) I asked in this list shortly before my vacation, and someone gave the go-ahead. If it's a problem, let me know, and I'll gladly revert the change. The entry I provided does say it's the place to go for release candidates, and I intend to replace it with a pinter to the real release when it's ready. Given the difficulty of finding any usable m3 implementation after the great file-system disaster, I thought this was an essential interim measure. > > On Aug 3, 2009, at 5:27 PM, hendrik at topoi.pooq.com wrote: > > >Now that I've updated the wikipedia entry, it's easier to find the RC2 > >downloads page. > > > >How can I update the other places that are easy to find on the google? > >Specifically, > > the Modula 3 resource page, www.modula3.org/ > > Modula-3 Frequently Asked Questions (FAQ), > > www.faqs.org/faqs/Modula-3-faq/ > > > >I'll soon be trying another installation fromscratch, using RC2, > >and I'll let you know how it went. > > > >-- hendrik > > > > From hendrik at topoi.pooq.com Tue Aug 4 17:49:27 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 4 Aug 2009 11:49:27 -0400 Subject: [M3devel] some cvs errors? In-Reply-To: <20090804102254.yakamff0ysscccs8@mail.elegosoft.com> References: <20090803131445.d5u1i1vaf484kg4s@mail.elegosoft.com> <20090804102254.yakamff0ysscccs8@mail.elegosoft.com> Message-ID: <20090804154927.GD27699@topoi.pooq.com> On Tue, Aug 04, 2009 at 10:22:54AM +0200, Olaf Wagner wrote: > Quoting Jay K : > > > > >One error, the second one, was maybe local, not on the server. > > I saw it again later while running make-dist.sh, it tries to update > > itself. > > Not clear why it occured here, maybe I had one running and the use > >of $Id$ caused an attempted and failed write. Or maybe the error was > > on the server. With CVS, can't be sure of much imho. > >The other seems ok. > >+2 for replacing cvs with something better.. after we invent more time... > > That something better would then be Perforce or AccuRev? > > Elego has got 3 committers to the Subversion project, and there are > lots of problems, too. We've got several customers who are regularly > pushing it over the edge of its capabilities... > > But I'm not against a change, as long as others will do the work ;-) > > Olaf I'm being slow on teh cvs->monotone conversion project I was looking into. Once again, sorry. Other things, ostly personal, keep getting in the way. One thing that's delaying it is that I see no point in doing the conversion while we're in the throes of getting a release out. It looks as if the conversion, should we go through with it, will be one-way; that is, monotone will not conveniently pass updates on to cvs. I don't know yet whether it will be possible to regularly pass cvs changes on to monotone, though. It would be a lot easier if it were. -- hendrik From wagner at elegosoft.com Tue Aug 4 17:54:04 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 04 Aug 2009 17:54:04 +0200 Subject: [M3devel] testing RC2. Message-ID: <20090804175404.k6tkhj4i6804ck4c@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > On Mon, Aug 03, 2009 at 05:59:32PM -0700, jay.krell at cornell.edu wrote: >> Wikipedia: Aren't you subverting release manager Olaf? Not ready for >> exposure beyond m3devel? >> >> - Jay (phone) > > I asked in this list shortly before my vacation, and someone gave the > go-ahead. > > If it's a problem, let me know, and I'll gladly revert the change. > > The entry I provided does say it's the place to go for release > candidates, and I intend to replace it with a pinter to the real release > when it's ready. > > Given the difficulty of finding any usable m3 implementation after the > great file-system disaster, I thought this was an essential interim > measure. I think it's OK now; several tests have passed successfully. I'll try to improve the web pages on Wednesday evening, unless someone does that before (hint!). Peter Eiserloh sent several suggestions. Hopefully we'll finally deliver at the next weekend :-) Olaf > > >> >> On Aug 3, 2009, at 5:27 PM, hendrik at topoi.pooq.com wrote: >> >> >Now that I've updated the wikipedia entry, it's easier to find the RC2 >> >downloads page. >> > >> >How can I update the other places that are easy to find on the google? >> >Specifically, >> > the Modula 3 resource page, www.modula3.org/ >> > Modula-3 Frequently Asked Questions (FAQ), >> > www.faqs.org/faqs/Modula-3-faq/ >> > >> >I'll soon be trying another installation fromscratch, using RC2, >> >and I'll let you know how it went. >> > >> >-- hendrik >> > >> > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Aug 4 17:56:26 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 04 Aug 2009 17:56:26 +0200 Subject: [M3devel] automated installation tests on Hudson Message-ID: <20090804175626.xtce1l8jnoc844s8@mail.elegosoft.com> It's not much, but a start: http://hudson.modula3.com:8080/view/test-install/ SOLgnu and SOLsun packages should also be complete tomorrow. Some installation problems found though, but they won't stop the release. That's it for today, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From neels at elego.de Wed Aug 5 00:12:59 2009 From: neels at elego.de (Neels J Hofmeyr) Date: Wed, 05 Aug 2009 00:12:59 +0200 Subject: [M3devel] some cvs errors? In-Reply-To: <4A78164A.1E75.00D7.1@scires.com> References: <20090803131445.d5u1i1vaf484kg4s@mail.elegosoft.com> <20090804102254.yakamff0ysscccs8@mail.elegosoft.com> <4A78164A.1E75.00D7.1@scires.com> Message-ID: <4A78B26B.2010207@elego.de> Randy Coleburn wrote: > > As far as replacing CVS with something else, I have "no dog in the race" > so to speak, but I will say that CVS has worked fine for my purposes and > the TortoiseCVS integration with Windows Explorer makes life easy for me Well, there is TortoiseSVN. I'm not convinced that the branching strategies needed for CM3 dev would indeed push svn over the edge of its capabilities -- not if CVS worked fine all these years. And I would certainly prefer a free SCM to one with a price tag and a restrictive license. You guessed it, one of the Subversion committers speaking ;) ...and this discussion remains empty until anyone wants to actually do the work ;) ~Neels > on Windows. I don't have to remember all the CVS command line switches; > I just use the TortoiseCVS GUI and it works. If we switch to something > else that doesn't have this level of GUI, it will present a learning > curve for me. > Regards, > Randy Coleburn > >>>> Olaf Wagner 8/4/2009 4:22 AM >>> > Quoting Jay K : > >> >> One error, the second one, was maybe local, not on the server. >> I saw it again later while running make-dist.sh, it tries to update > itself. >> Not clear why it occured here, maybe I had one running and the use >> of $Id$ caused an attempted and failed write. Or maybe the error was >> on the server. With CVS, can't be sure of much imho. >> The other seems ok. >> +2 for replacing cvs with something better.. after we invent more time... > > That something better would then be Perforce or AccuRev? > > Elego has got 3 committers to the Subversion project, and there are > lots of problems, too. We've got several customers who are regularly > pushing it over the edge of its capabilities... > > But I'm not against a change, as long as others will do the work ;-) > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From wagner at elegosoft.com Wed Aug 5 13:18:42 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 05 Aug 2009 13:18:42 +0200 Subject: [M3devel] SOLgnu still broken on ssol Message-ID: <20090805131842.5ha3ycwcbkkc448s@mail.elegosoft.com> The SOLgnu builds are still broken, though the makedist job claims to be successful (still need to fix the script): === package m3-libs/m3core === +++ cm3 -build -override $RARGS -DROOT='/home/hudson/workspace/cm3-makedist-SOLgnu/cm3' -DCM3_VERSION_TEXT='d5.8.2' -DCM3_VERSION_NUMBER='050802' -DCM3_LAST_CHANGED='2009-07-15' +++ ld: fatal: relocation error: R_SPARC_32: file RTMachineASM.o: symbol : offset 0xfd951bee is non-aligned ld: fatal: relocation error: R_SPARC_32: file RTMachineASM.o: symbol : offset 0xfd951bf2 is non-aligned ld: fatal: relocation error: R_SPARC_32: file RTMachineASM.o: symbol : offset 0xfd951bf6 is non-aligned ld: fatal: relocation error: R_SPARC_32: file RTMachineASM.o: symbol : offset 0xfd95d2bf is non-aligned ld: fatal: relocation error: R_SPARC_32: file RTMachineASM.o: symbol : offset 0xfd9669ce is non-aligned collect2: ld returned 1 exit status make_lib => 1 librarian failed building: m3core See http://hudson.modula3.com:8080/view/SOLgnu/job/cm3-makedist-SOLgnu/3/consoleFull for more details. Argh... I forgot to include the path preference for /usr/local again to use the pre-built gcc. Now it will run another 4 hours... SOLsun seems to be OK. I'll run the installation tests on it soon. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From lists at darko.org Wed Aug 5 14:06:54 2009 From: lists at darko.org (Darko Volaric) Date: Wed, 5 Aug 2009 14:06:54 +0200 Subject: [M3devel] some cvs errors? In-Reply-To: <4A78B26B.2010207@elego.de> References: <20090803131445.d5u1i1vaf484kg4s@mail.elegosoft.com> <20090804102254.yakamff0ysscccs8@mail.elegosoft.com> <4A78164A.1E75.00D7.1@scires.com> <4A78B26B.2010207@elego.de> Message-ID: <825BD2B1-CCCE-4906-A666-CAA1AE0C3CAB@darko.org> Has anyone considered git? It seems particularly well suited to distributed development, having been essentially designed for open source groups, and seems to be undergoing intensive development. On 05/08/2009, at 12:12 AM, Neels J Hofmeyr wrote: > Randy Coleburn wrote: >> >> As far as replacing CVS with something else, I have "no dog in the >> race" >> so to speak, but I will say that CVS has worked fine for my >> purposes and >> the TortoiseCVS integration with Windows Explorer makes life easy >> for me > > Well, there is TortoiseSVN. > > I'm not convinced that the branching strategies needed for CM3 dev > would > indeed push svn over the edge of its capabilities -- not if CVS > worked fine > all these years. > > And I would certainly prefer a free SCM to one with a price tag and a > restrictive license. You guessed it, one of the Subversion committers > speaking ;) > > ...and this discussion remains empty until anyone wants to actually > do the > work ;) > ~Neels > >> on Windows. I don't have to remember all the CVS command line >> switches; >> I just use the TortoiseCVS GUI and it works. If we switch to >> something >> else that doesn't have this level of GUI, it will present a learning >> curve for me. >> Regards, >> Randy Coleburn >> >>>>> Olaf Wagner 8/4/2009 4:22 AM >>> >> Quoting Jay K : >> >>> >>> One error, the second one, was maybe local, not on the server. >>> I saw it again later while running make-dist.sh, it tries to update >> itself. >>> Not clear why it occured here, maybe I had one running and the use >>> of $Id$ caused an attempted and failed write. Or maybe the error was >>> on the server. With CVS, can't be sure of much imho. >>> The other seems ok. >>> +2 for replacing cvs with something better.. after we invent more >>> time... >> >> That something better would then be Perforce or AccuRev? >> >> Elego has got 3 committers to the Subversion project, and there are >> lots of problems, too. We've got several customers who are regularly >> pushing it over the edge of its capabilities... >> >> But I'm not against a change, as long as others will do the work ;-) >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >> Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >> 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >> Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 >> > From wagner at elegosoft.com Wed Aug 5 15:54:46 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 05 Aug 2009 15:54:46 +0200 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090803093135.3F59DCC81B@birch.elegosoft.com> <4A76CADA.1E75.00D7.1@scires.com> <4A76FEED.1E75.00D7.1@scires.com> Message-ID: <20090805155446.wgsqqqclm8skggkw@mail.elegosoft.com> I just found this mail... too many of them. Quoting Jay K : > I failed to figure how to move anything at all to RC2 (perhaps that > is by-design, Olaf escalating and using more and more arcane > features of cvs to stay ahead of me), but I moved it to the release > branch, which should get it at least into whatever if anything > follows RC2. This is no arcane feature, just the conventional way to pin a bound configuration. We use the release branch to improve the release quality, and certain points on it are marked with RC1, RC2, ... The CVS concept for bound configurations is called a tag (non-branch tag). RC2 is now in the past. We've already built most of the packages. If there is something really important, we can move the tag again, which means that we will probably have to rebuild a number of installation packages. If it's something that severely breaks the system, we may have to do that. What do you say? > The fix seems fragile though. Converting to a full path would > probably be better. > (Full paths are still contextual, but most people/code seem ok > ignoring that. Could be net used or chroot..) RC3 should be faster, as most of the needed infrastructure is now in place. So it may be best to just know that the fix is in there. Olaf > ________________________________ >> Date: Mon, 3 Aug 2009 15:17:30 -0400 >> From: rcoleburn at scires.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] [M3commit] CVS Update: cm3 >> >> Jay: >> >> Your change to MxConfig.m3 seems to work fine for cm3ide, provided >> that I replace HOST by "NT386" in my cm3.cfg is as follows: >> >> INSTALL_ROOT = path() & "/.." >> include (path() & "/config/NT386") >> >> Thank you! >> >> Can we get your revised MxConfig.m3 put into the RC2 branch? >> >> >> Regards, >> >> Randy >> >>>>> "Randy Coleburn" 8/3/2009 11:35 AM>>> >> >> Jay: >> >> I agree that running cm3 from "bin" folder is not going to be >> productive; however, other programs (such as cm3ide) also use the >> quake stuff and they don't have this limitation. I think your >> change is a good one. I'll run some tests and see how cm3ide fares. >> Thanks. >> >> --Randy >> >>>>> Jay Krell 8/3/2009 11:31 AM>>> >> CVSROOT:/usr/cvs >> Changes by:jkrell at birch.09/08/03 11:31:35 >> >> Modified files: >> cm3/m3-sys/m3quake/src/: MxConfig.m3 >> >> Log message: >> use "." instead of empty string for path() when current working >> directory is the actual directory of cm3; not sure what good >> running cm3 here is, and we probe way too many places.. >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Wed Aug 5 20:50:21 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 05 Aug 2009 20:50:21 +0200 Subject: [M3devel] WWW updates for the release Message-ID: <20090805205021.6ag1s0evoc0cggc0@mail.elegosoft.com> I've made some small additions and updates for the pending release, mostly based on https://projects.elego.de/cm3/ticket/1019. Some target platform archives are still missing, but we can add them during the next days. I'd like to have some broader feedback now if possible. The following topics are still unaddressed; perhaps anybody cares to fill them in: (c) The major changes to the compiler should be listed somewhere, since the last release shown on the download page. Right now the last release indicated is 5.4. There are some snapshots of 5.5, but not final release of 5.5. 3 - About-CM3: The "About CM3" page, should have a section listing all the changes / enhancements to the language that it accepts vice that described in the language reference from Nelson's SPWM3. For example, WIDECHAR, LONGINT are two new primitive types. Also list all the pragmas recognized by the compiler as that is a compiler unique issue. http://opencm3.net/about-cm3.html It should also list all the architectures that are supported by the compiler. These should always reflect those of the latest "release" version of the compiler. Please note that the latest changes are only checked-in on the release branch. Everything will be merged back to the main trunk later. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Fri Aug 7 11:56:24 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 07 Aug 2009 11:56:24 +0200 Subject: [M3devel] More Unix constants missing.... Message-ID: <1249638984.2745.11.camel@faramir.m3w.org> Can we have them, in both HEAD ad RC2 branch? TIA, dd === CONST TIOCMGET = 16_5415; TIOCMSET = 16_5418; Bits = ARRAY StatusBits OF CARDINAL { Unix.TIOCM_LE, Unix.TIOCM_DTR, Unix.TIOCM_RTS, Unix.TIOCM_ST, Unix.TIOCM_SR, Unix.TIOCM_CTS, Unix.TIOCM_CAR, Unix.TIOCM_RNG, Unix.TIOCM_DSR }; -- Dragi?a Duri? From wagner at elegosoft.com Fri Aug 7 12:18:07 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 07 Aug 2009 12:18:07 +0200 Subject: [M3devel] More Unix constants missing.... In-Reply-To: <1249638984.2745.11.camel@faramir.m3w.org> References: <1249638984.2745.11.camel@faramir.m3w.org> Message-ID: <20090807121807.ydy78qp4oww0og0c@mail.elegosoft.com> Quoting Dragi?a Duri? : > Can we have them, in both HEAD ad RC2 branch? > > TIA, > dd > > === > CONST > TIOCMGET = 16_5415; > TIOCMSET = 16_5418; > > Bits = ARRAY StatusBits OF CARDINAL { > Unix.TIOCM_LE, > Unix.TIOCM_DTR, > Unix.TIOCM_RTS, > Unix.TIOCM_ST, > Unix.TIOCM_SR, > Unix.TIOCM_CTS, > Unix.TIOCM_CAR, > Unix.TIOCM_RNG, > Unix.TIOCM_DSR > }; > > -- > Dragi?a Duri? If additional constants are missing, just merge them over to the release branch. There is no RC2 branch by the way and will never be. RC2 was just one version several days ago on the 5.8 release branch. If you want me to do it, knowing the file(s) and versions involved would certainly help ;-) As I'm not at home this weekend, it may take some time though. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Fri Aug 7 12:35:38 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 07 Aug 2009 12:35:38 +0200 Subject: [M3devel] More Unix constants missing.... In-Reply-To: <20090807121807.ydy78qp4oww0og0c@mail.elegosoft.com> References: <1249638984.2745.11.camel@faramir.m3w.org> <20090807121807.ydy78qp4oww0og0c@mail.elegosoft.com> Message-ID: <1249641338.2745.13.camel@faramir.m3w.org> I am not at home with CVS, really. It's probably 22 seconds job for Jay-who-cut-them-out-in-the-first-place :). I can make fast fix in my code till I wait proper one, in line with nest style guidelines for UNIX constants. On Fri, 2009-08-07 at 12:18 +0200, Olaf Wagner wrote: > If additional constants are missing, just merge them over to the > release branch. There is no RC2 branch by the way and will never be. > RC2 was just one version several days ago on the 5.8 release branch. > > If you want me to do it, knowing the file(s) and versions involved > would certainly help ;-) As I'm not at home this weekend, it may take > some time though. -- Dragi?a Duri? From hendrik at topoi.pooq.com Sat Aug 8 13:46:19 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sat, 8 Aug 2009 07:46:19 -0400 Subject: [M3devel] trouble with RC2 -- maybe with hudson? Message-ID: <20090808114619.GA3806@topoi.pooq.com> Installing cm3-bin-core-LINUXLIBC6-d5.8.2-RC2.tgz on my 32-bit intel Debian squeeze laptop went fine. But when I tried cm3-bin-core-LINUXLIBC6-d5.8.2-RC2.tgz (downloaded a few days ago) I got: hendrik at notlookedfor:~/cm3$ mkdir gui hendrik at notlookedfor:~/cm3$ cd gui hendrik at notlookedfor:~/cm3/gui$ tar -zxf ../../Desktop/cm3-bin-ws-gui-LINUXLIBC6-d5.8.2-RC2.tgz hendrik at notlookedfor:~/cm3/gui$ ls collection-gui.html install.sh m3-comm m3-tools m3-ui m3-win setup.cmd hendrik at notlookedfor:~/cm3/gui$ ./install.sh --- shipping from LINUXLIBC6 --- --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/tcp/LINUXLIBC6 .M3EXPORTS . => /usr/local/cm3/lib libm3tcp.so.5 "/home/hendrik/cm3/gui/m3-comm/tcp/LINUXLIBC6/.M3SHIP", line 6: quake runtime error: unable to create directory "/home/hudson": errno=13 --procedure-- -line- -file--- make_dir -- 6 /home/hendrik/cm3/gui/m3-comm/tcp/LINUXLIBC6/.M3SHIP Fatal Error: package build failed --- shipping from LINUXLIBC6 --- missing ".M3SHIP" file, build the package first. --- shipping from LINUXLIBC6 --- missing ".M3SHIP" file, build the package first. --- shipping from LINUXLIBC6 --- missing ".M3SHIP" file, build the package first. --- shipping from LINUXLIBC6 --- missing ".M3SHIP" file, build the package first. --- shipping from LINUXLIBC6 --- missing ".M3SHIP" file, build the package first. --- shipping from LINUXLIBC6 --- missing ".M3SHIP" file, build the package first. --- shipping from LINUXLIBC6 --- missing ".M3SHIP" file, build the package first. --- shipping from LINUXLIBC6 --- missing ".M3SHIP" file, build the package first. --- shipping from LINUXLIBC6 --- missing ".M3SHIP" file, build the package first. --- shipping from LINUXLIBC6 --- missing ".M3SHIP" file, build the package first. --- shipping from LINUXLIBC6 --- missing ".M3SHIP" file, build the package first. --- shipping from LINUXLIBC6 --- missing ".M3SHIP" file, build the package first. --- shipping from LINUXLIBC6 --- missing ".M3SHIP" file, build the package first. --- shipping from LINUXLIBC6 --- missing ".M3SHIP" file, build the package first. hendrik at notlookedfor:~/cm3/gui$ exit It looks to me as if hudson has gotten in the way. -- hendrik From wagner at elegosoft.com Sat Aug 8 13:54:30 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 08 Aug 2009 13:54:30 +0200 Subject: [M3devel] trouble with RC2 -- maybe with hudson? In-Reply-To: <20090808114619.GA3806@topoi.pooq.com> References: <20090808114619.GA3806@topoi.pooq.com> Message-ID: <20090808135430.1iy8os9eogwwcss0@mail.elegosoft.com> Please create a ticket for that and attach the contents of file "/home/hendrik/cm3/gui/m3-comm/tcp/LINUXLIBC6/.M3SHIP"/ I'll have a look at it ASAP. Olaf Quoting hendrik at topoi.pooq.com: > Installing cm3-bin-core-LINUXLIBC6-d5.8.2-RC2.tgz on my 32-bit > intel Debian squeeze laptop went fine. > > But when I tried cm3-bin-core-LINUXLIBC6-d5.8.2-RC2.tgz (downloaded a > few days ago) I got: > > hendrik at notlookedfor:~/cm3$ mkdir gui > hendrik at notlookedfor:~/cm3$ cd gui > hendrik at notlookedfor:~/cm3/gui$ tar -zxf > ../../Desktop/cm3-bin-ws-gui-LINUXLIBC6-d5.8.2-RC2.tgz > hendrik at notlookedfor:~/cm3/gui$ ls > collection-gui.html install.sh m3-comm m3-tools m3-ui m3-win > setup.cmd > hendrik at notlookedfor:~/cm3/gui$ ./install.sh > --- shipping from LINUXLIBC6 --- > > --- shipping from LINUXLIBC6 --- > > . => /usr/local/cm3/pkg/tcp/LINUXLIBC6 > .M3EXPORTS > . => /usr/local/cm3/lib > libm3tcp.so.5 > "/home/hendrik/cm3/gui/m3-comm/tcp/LINUXLIBC6/.M3SHIP", line 6: quake > runtime error: unable to create directory "/home/hudson": errno=13 > > --procedure-- -line- -file--- > make_dir -- > 6 > /home/hendrik/cm3/gui/m3-comm/tcp/LINUXLIBC6/.M3SHIP > > Fatal Error: package build failed > --- shipping from LINUXLIBC6 --- > > missing ".M3SHIP" file, build the package first. > --- shipping from LINUXLIBC6 --- > > missing ".M3SHIP" file, build the package first. > --- shipping from LINUXLIBC6 --- > > missing ".M3SHIP" file, build the package first. > --- shipping from LINUXLIBC6 --- > > missing ".M3SHIP" file, build the package first. > --- shipping from LINUXLIBC6 --- > > missing ".M3SHIP" file, build the package first. > --- shipping from LINUXLIBC6 --- > > missing ".M3SHIP" file, build the package first. > --- shipping from LINUXLIBC6 --- > > missing ".M3SHIP" file, build the package first. > --- shipping from LINUXLIBC6 --- > > missing ".M3SHIP" file, build the package first. > --- shipping from LINUXLIBC6 --- > > missing ".M3SHIP" file, build the package first. > --- shipping from LINUXLIBC6 --- > > missing ".M3SHIP" file, build the package first. > --- shipping from LINUXLIBC6 --- > > missing ".M3SHIP" file, build the package first. > --- shipping from LINUXLIBC6 --- > > missing ".M3SHIP" file, build the package first. > --- shipping from LINUXLIBC6 --- > > missing ".M3SHIP" file, build the package first. > --- shipping from LINUXLIBC6 --- > > missing ".M3SHIP" file, build the package first. > hendrik at notlookedfor:~/cm3/gui$ exit > > > > It looks to me as if hudson has gotten in the way. > > -- hendrik > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sat Aug 8 15:03:38 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 8 Aug 2009 13:03:38 +0000 Subject: [M3devel] trouble with RC2 -- maybe with hudson? In-Reply-To: <20090808135430.1iy8os9eogwwcss0@mail.elegosoft.com> References: <20090808114619.GA3806@topoi.pooq.com> <20090808135430.1iy8os9eogwwcss0@mail.elegosoft.com> Message-ID: I rewrote the m3ship-no-resolve stuff some weeks ago. There must be a hole in my rewrite. The feature is very nice, though not well implemented either at first or with my rewrite, maybe no good way to do it. - Jay ---------------------------------------- > Date: Sat, 8 Aug 2009 13:54:30 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] trouble with RC2 -- maybe with hudson? > > Please create a ticket for that and attach the contents of file > "/home/hendrik/cm3/gui/m3-comm/tcp/LINUXLIBC6/.M3SHIP"/ > > I'll have a look at it ASAP. > > Olaf > > Quoting hendrik at topoi.pooq.com: > >> Installing cm3-bin-core-LINUXLIBC6-d5.8.2-RC2.tgz on my 32-bit >> intel Debian squeeze laptop went fine. >> >> But when I tried cm3-bin-core-LINUXLIBC6-d5.8.2-RC2.tgz (downloaded a >> few days ago) I got: >> >> hendrik at notlookedfor:~/cm3$ mkdir gui >> hendrik at notlookedfor:~/cm3$ cd gui >> hendrik at notlookedfor:~/cm3/gui$ tar -zxf >> ../../Desktop/cm3-bin-ws-gui-LINUXLIBC6-d5.8.2-RC2.tgz >> hendrik at notlookedfor:~/cm3/gui$ ls >> collection-gui.html install.sh m3-comm m3-tools m3-ui m3-win >> setup.cmd >> hendrik at notlookedfor:~/cm3/gui$ ./install.sh >> --- shipping from LINUXLIBC6 --- >> >> --- shipping from LINUXLIBC6 --- >> >> . => /usr/local/cm3/pkg/tcp/LINUXLIBC6 >> .M3EXPORTS >> . => /usr/local/cm3/lib >> libm3tcp.so.5 >> "/home/hendrik/cm3/gui/m3-comm/tcp/LINUXLIBC6/.M3SHIP", line 6: quake >> runtime error: unable to create directory "/home/hudson": errno=13 >> >> --procedure-- -line- -file--- >> make_dir -- >> 6 >> /home/hendrik/cm3/gui/m3-comm/tcp/LINUXLIBC6/.M3SHIP >> >> Fatal Error: package build failed >> --- shipping from LINUXLIBC6 --- >> >> missing ".M3SHIP" file, build the package first. >> --- shipping from LINUXLIBC6 --- >> >> missing ".M3SHIP" file, build the package first. >> --- shipping from LINUXLIBC6 --- >> >> missing ".M3SHIP" file, build the package first. >> --- shipping from LINUXLIBC6 --- >> >> missing ".M3SHIP" file, build the package first. >> --- shipping from LINUXLIBC6 --- >> >> missing ".M3SHIP" file, build the package first. >> --- shipping from LINUXLIBC6 --- >> >> missing ".M3SHIP" file, build the package first. >> --- shipping from LINUXLIBC6 --- >> >> missing ".M3SHIP" file, build the package first. >> --- shipping from LINUXLIBC6 --- >> >> missing ".M3SHIP" file, build the package first. >> --- shipping from LINUXLIBC6 --- >> >> missing ".M3SHIP" file, build the package first. >> --- shipping from LINUXLIBC6 --- >> >> missing ".M3SHIP" file, build the package first. >> --- shipping from LINUXLIBC6 --- >> >> missing ".M3SHIP" file, build the package first. >> --- shipping from LINUXLIBC6 --- >> >> missing ".M3SHIP" file, build the package first. >> --- shipping from LINUXLIBC6 --- >> >> missing ".M3SHIP" file, build the package first. >> --- shipping from LINUXLIBC6 --- >> >> missing ".M3SHIP" file, build the package first. >> hendrik at notlookedfor:~/cm3/gui$ exit >> >> >> >> It looks to me as if hudson has gotten in the way. >> >> -- hendrik >> >> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From hendrik at topoi.pooq.com Sat Aug 8 15:15:50 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sat, 8 Aug 2009 09:15:50 -0400 Subject: [M3devel] trouble with RC2 -- maybe with hudson? In-Reply-To: <20090808135430.1iy8os9eogwwcss0@mail.elegosoft.com> References: <20090808114619.GA3806@topoi.pooq.com> <20090808135430.1iy8os9eogwwcss0@mail.elegosoft.com> Message-ID: <20090808131549.GA3891@topoi.pooq.com> On Sat, Aug 08, 2009 at 01:54:30PM +0200, Olaf Wagner wrote: > Please create a ticket for that and attach the contents of file > "/home/hendrik/cm3/gui/m3-comm/tcp/LINUXLIBC6/.M3SHIP"/ Done. Ticket # 1052(new sw-bug) -- hendrik From wagner at elegosoft.com Sat Aug 8 16:38:22 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 08 Aug 2009 16:38:22 +0200 Subject: [M3devel] trouble with RC2 -- maybe with hudson? In-Reply-To: References: <20090808114619.GA3806@topoi.pooq.com> <20090808135430.1iy8os9eogwwcss0@mail.elegosoft.com> Message-ID: <20090808163822.9tr379n4q8skkscw@mail.elegosoft.com> Quoting Jay K : > I rewrote the m3ship-no-resolve stuff some weeks ago. > There must be a hole in my rewrite. > The feature is very nice, though not well implemented > either at first or with my rewrite, maybe no good way > to do it. I assigned that ticket to you. Perhaps it's easy to fix; please have a look. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sat Aug 8 19:00:17 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 8 Aug 2009 17:00:17 +0000 Subject: [M3devel] trouble with RC2 -- maybe with hudson? In-Reply-To: References: <20090808114619.GA3806@topoi.pooq.com> <20090808135430.1iy8os9eogwwcss0@mail.elegosoft.com> Message-ID: Olaf you are missing the flag some places maybe? You can see it working sometimes but not others. Just make it the default and only behavior? It is not specific to m3-comm-tcp. I'll poke around more. udson at xlin2:~$ uname -a Linux xlin2 2.6.18-6-686 #1 SMP Tue May 5 00:40:20 UTC 2009 i686 GNU/Linux hudson at xlin2:~$ pwd /home/hudson hudson at xlin2:~$ grep make_dir `find . | grep m3-comm/tcp/LINUXLIBC6/.M3SHIP` ./workspace/cm3-lastok-build-LINUXLIBC6/cm3/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/work/cm3-inst/xlin2/current--lastok-build//pkg/tcp/LINUXLIBC6") ./workspace/cm3-lastok-build-LINUXLIBC6/cm3/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/work/cm3-inst/xlin2/current--lastok-build//lib") ./workspace/cm3-lastok-build-LINUXLIBC6/cm3/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/work/cm3-inst/xlin2/current--lastok-build//pkg/tcp/src/POSIX") ./workspace/cm3-lastok-build-LINUXLIBC6/cm3/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/work/cm3-inst/xlin2/current--lastok-build//pkg/tcp/src/common") ./workspace/cm3-test-install-LINUXLIBC6/work/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir(PKG_INSTALL & "/tcp/" & TARGET) ./workspace/cm3-test-install-LINUXLIBC6/work/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir(LIB_INSTALL) ./workspace/cm3-test-install-LINUXLIBC6/work/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/tmp/cm3/bin/../lib") ./workspace/cm3-test-install-LINUXLIBC6/work/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir(PKG_INSTALL & "/tcp/src/POSIX") ./workspace/cm3-test-install-LINUXLIBC6/work/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir(PKG_INSTALL & "/tcp/src/common") ./workspace/cm3-test-all-pkgs-LINUXLIBC6/cm3/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/work/cm3-inst/xlin2/last-ok//pkg/tcp/LINUXLIBC6") ./workspace/cm3-test-all-pkgs-LINUXLIBC6/cm3/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/work/cm3-inst/xlin2/last-ok//lib") ./workspace/cm3-test-all-pkgs-LINUXLIBC6/cm3/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/work/cm3-inst/xlin2/last-ok//pkg/tcp/src/POSIX") ./workspace/cm3-test-all-pkgs-LINUXLIBC6/cm3/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/work/cm3-inst/xlin2/last-ok//pkg/tcp/src/common") - Jay > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Date: Sat, 8 Aug 2009 13:03:38 +0000 > Subject: Re: [M3devel] trouble with RC2 -- maybe with hudson? > > > I rewrote the m3ship-no-resolve stuff some weeks ago. > There must be a hole in my rewrite. > The feature is very nice, though not well implemented > either at first or with my rewrite, maybe no good way > to do it. > > > - Jay > > > > ---------------------------------------- > > Date: Sat, 8 Aug 2009 13:54:30 +0200 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] trouble with RC2 -- maybe with hudson? > > > > Please create a ticket for that and attach the contents of file > > "/home/hendrik/cm3/gui/m3-comm/tcp/LINUXLIBC6/.M3SHIP"/ > > > > I'll have a look at it ASAP. > > > > Olaf > > > > Quoting hendrik at topoi.pooq.com: > > > >> Installing cm3-bin-core-LINUXLIBC6-d5.8.2-RC2.tgz on my 32-bit > >> intel Debian squeeze laptop went fine. > >> > >> But when I tried cm3-bin-core-LINUXLIBC6-d5.8.2-RC2.tgz (downloaded a > >> few days ago) I got: > >> > >> hendrik at notlookedfor:~/cm3$ mkdir gui > >> hendrik at notlookedfor:~/cm3$ cd gui > >> hendrik at notlookedfor:~/cm3/gui$ tar -zxf > >> ../../Desktop/cm3-bin-ws-gui-LINUXLIBC6-d5.8.2-RC2.tgz > >> hendrik at notlookedfor:~/cm3/gui$ ls > >> collection-gui.html install.sh m3-comm m3-tools m3-ui m3-win > >> setup.cmd > >> hendrik at notlookedfor:~/cm3/gui$ ./install.sh > >> --- shipping from LINUXLIBC6 --- > >> > >> --- shipping from LINUXLIBC6 --- > >> > >> . => /usr/local/cm3/pkg/tcp/LINUXLIBC6 > >> .M3EXPORTS > >> . => /usr/local/cm3/lib > >> libm3tcp.so.5 > >> "/home/hendrik/cm3/gui/m3-comm/tcp/LINUXLIBC6/.M3SHIP", line 6: quake > >> runtime error: unable to create directory "/home/hudson": errno=13 > >> > >> --procedure-- -line- -file--- > >> make_dir -- > >> 6 > >> /home/hendrik/cm3/gui/m3-comm/tcp/LINUXLIBC6/.M3SHIP > >> > >> Fatal Error: package build failed > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> hendrik at notlookedfor:~/cm3/gui$ exit > >> > >> > >> > >> It looks to me as if hudson has gotten in the way. > >> > >> -- hendrik > >> > >> > > > > > > > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Aug 8 19:33:48 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 8 Aug 2009 17:33:48 +0000 Subject: [M3devel] trouble with RC2 -- maybe with hudson? In-Reply-To: References: <20090808114619.GA3806@topoi.pooq.com> <20090808135430.1iy8os9eogwwcss0@mail.elegosoft.com> Message-ID: The various make-dist console outputs show a literal $RARGS, not the expected switches. -10 for sh? - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Date: Sat, 8 Aug 2009 17:00:17 +0000 Subject: Re: [M3devel] trouble with RC2 -- maybe with hudson? Olaf you are missing the flag some places maybe? You can see it working sometimes but not others. Just make it the default and only behavior? It is not specific to m3-comm-tcp. I'll poke around more. udson at xlin2:~$ uname -a Linux xlin2 2.6.18-6-686 #1 SMP Tue May 5 00:40:20 UTC 2009 i686 GNU/Linux hudson at xlin2:~$ pwd /home/hudson hudson at xlin2:~$ grep make_dir `find . | grep m3-comm/tcp/LINUXLIBC6/.M3SHIP` ./workspace/cm3-lastok-build-LINUXLIBC6/cm3/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/work/cm3-inst/xlin2/current--lastok-build//pkg/tcp/LINUXLIBC6") ./workspace/cm3-lastok-build-LINUXLIBC6/cm3/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/work/cm3-inst/xlin2/current--lastok-build//lib") ./workspace/cm3-lastok-build-LINUXLIBC6/cm3/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/work/cm3-inst/xlin2/current--lastok-build//pkg/tcp/src/POSIX") ./workspace/cm3-lastok-build-LINUXLIBC6/cm3/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/work/cm3-inst/xlin2/current--lastok-build//pkg/tcp/src/common") ./workspace/cm3-test-install-LINUXLIBC6/work/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir(PKG_INSTALL & "/tcp/" & TARGET) ./workspace/cm3-test-install-LINUXLIBC6/work/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir(LIB_INSTALL) ./workspace/cm3-test-install-LINUXLIBC6/work/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/tmp/cm3/bin/../lib") ./workspace/cm3-test-install-LINUXLIBC6/work/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir(PKG_INSTALL & "/tcp/src/POSIX") ./workspace/cm3-test-install-LINUXLIBC6/work/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir(PKG_INSTALL & "/tcp/src/common") ./workspace/cm3-test-all-pkgs-LINUXLIBC6/cm3/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/work/cm3-inst/xlin2/last-ok//pkg/tcp/LINUXLIBC6") ./workspace/cm3-test-all-pkgs-LINUXLIBC6/cm3/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/work/cm3-inst/xlin2/last-ok//lib") ./workspace/cm3-test-all-pkgs-LINUXLIBC6/cm3/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/work/cm3-inst/xlin2/last-ok//pkg/tcp/src/POSIX") ./workspace/cm3-test-all-pkgs-LINUXLIBC6/cm3/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/work/cm3-inst/xlin2/last-ok//pkg/tcp/src/common") - Jay > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Date: Sat, 8 Aug 2009 13:03:38 +0000 > Subject: Re: [M3devel] trouble with RC2 -- maybe with hudson? > > > I rewrote the m3ship-no-resolve stuff some weeks ago. > There must be a hole in my rewrite. > The feature is very nice, though not well implemented > either at first or with my rewrite, maybe no good way > to do it. > > > - Jay > > > > ---------------------------------------- > > Date: Sat, 8 Aug 2009 13:54:30 +0200 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] trouble with RC2 -- maybe with hudson? > > > > Please create a ticket for that and attach the contents of file > > "/home/hendrik/cm3/gui/m3-comm/tcp/LINUXLIBC6/.M3SHIP"/ > > > > I'll have a look at it ASAP. > > > > Olaf > > > > Quoting hendrik at topoi.pooq.com: > > > >> Installing cm3-bin-core-LINUXLIBC6-d5.8.2-RC2.tgz on my 32-bit > >> intel Debian squeeze laptop went fine. > >> > >> But when I tried cm3-bin-core-LINUXLIBC6-d5.8.2-RC2.tgz (downloaded a > >> few days ago) I got: > >> > >> hendrik at notlookedfor:~/cm3$ mkdir gui > >> hendrik at notlookedfor:~/cm3$ cd gui > >> hendrik at notlookedfor:~/cm3/gui$ tar -zxf > >> ../../Desktop/cm3-bin-ws-gui-LINUXLIBC6-d5.8.2-RC2.tgz > >> hendrik at notlookedfor:~/cm3/gui$ ls > >> collection-gui.html install.sh m3-comm m3-tools m3-ui m3-win > >> setup.cmd > >> hendrik at notlookedfor:~/cm3/gui$ ./install.sh > >> --- shipping from LINUXLIBC6 --- > >> > >> --- shipping from LINUXLIBC6 --- > >> > >> . => /usr/local/cm3/pkg/tcp/LINUXLIBC6 > >> .M3EXPORTS > >> . => /usr/local/cm3/lib > >> libm3tcp.so.5 > >> "/home/hendrik/cm3/gui/m3-comm/tcp/LINUXLIBC6/.M3SHIP", line 6: quake > >> runtime error: unable to create directory "/home/hudson": errno=13 > >> > >> --procedure-- -line- -file--- > >> make_dir -- > >> 6 > >> /home/hendrik/cm3/gui/m3-comm/tcp/LINUXLIBC6/.M3SHIP > >> > >> Fatal Error: package build failed > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> hendrik at notlookedfor:~/cm3/gui$ exit > >> > >> > >> > >> It looks to me as if hudson has gotten in the way. > >> > >> -- hendrik > >> > >> > > > > > > > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Aug 8 22:12:20 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 8 Aug 2009 20:12:20 +0000 Subject: [M3devel] lots of problems in gui on AMD64_DARWIN? Message-ID: Not all gui apps fail. Some 32bit-isms in TimeStamp.m3. gdb doesn't seem to be working at all for me, arg. jbook2:bin jay$ ./mentor *** *** runtime error: *** An enumeration or subrange value was out of range. *** file "../src/uid/Common/TimeStamp.m3", line 63 *** Abort trap jbook2:bin jay$ ./formsedit *** *** runtime error: *** An enumeration or subrange value was out of range. *** file "../src/uid/Common/TimeStamp.m3", line 63 *** jbook2:bin jay$ ./BadBricks *** *** runtime error: *** An enumeration or subrange value was out of range. *** file "../src/uid/Common/TimeStamp.m3", line 63 *** Abort trap book2:bin jay$ ./Calculator *** *** runtime error: *** An enumeration or subrange value was out of range. *** file "../src/uid/Common/TimeStamp.m3", line 63 *** -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Aug 8 22:17:09 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 8 Aug 2009 20:17:09 +0000 Subject: [M3devel] make-dist vs. $CM3_TARGET/AMD64_DARWIN Message-ID: I tried to make AMD64_DARWIN distribution with: PATH=/cm3.amd64/bin:$PATH CM3CVSUSER=jkrell SHIPRC=y CM3_TARGET=AMD64_DARWIN ./make-dist.sh I got a bunch of files with I386_DARWIN in their names. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Aug 8 22:44:18 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 08 Aug 2009 22:44:18 +0200 Subject: [M3devel] make-dist vs. $CM3_TARGET/AMD64_DARWIN In-Reply-To: References: Message-ID: <20090808224418.oel9aad5w8w8w0wc@mail.elegosoft.com> Quoting Jay K : > I tried to make AMD64_DARWIN distribution with: > > PATH=/cm3.amd64/bin:$PATH CM3CVSUSER=jkrell SHIPRC=y > CM3_TARGET=AMD64_DARWIN ./make-dist.sh > > I got a bunch of files with I386_DARWIN in their names. Have you added support for all those new AMD64 targets to sysinfo.sh? I assume you expect CM3_TARGET to override everything, but I'm not sure that it will work everywhere. You should trace with set -x. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sat Aug 8 22:48:24 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 8 Aug 2009 20:48:24 +0000 Subject: [M3devel] make-dist vs. $CM3_TARGET/AMD64_DARWIN In-Reply-To: <20090808224418.oel9aad5w8w8w0wc@mail.elegosoft.com> References: <20090808224418.oel9aad5w8w8w0wc@mail.elegosoft.com> Message-ID: I added it to python/pylib.py and I expected CM3_TARGET to override. The code in python/pylib.py: elif UName.startswith("darwin"): # detect the m3 platform (Darwin runs on ppc32, ppc64, x86, amd64) if UNameArchP == "powerpc": Host = "PPC_DARWIN" elif re.match("i[3456]86", UNameArchP): if os.popen("sysctl hw.cpu64bit_capable").read() == "hw.cpu64bit_capable: 1\n": Host = "AMD64_DARWIN" else: Host = "I386_DARWIN" elif UNameArchP == "x86-64": Host = "AMD64_DARWIN" elif UNameArchP == "powerpc64": Host = "PPC64_DARWIN" That was mostly guessing, a few things in sysctl report 64bit stuff, but nothing in uname seems to indicate it. I guess I'll update sysinfo.sh and defs.sh..yuck. I opened tickets. - Jay > Date: Sat, 8 Aug 2009 22:44:18 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] make-dist vs. $CM3_TARGET/AMD64_DARWIN > > Quoting Jay K : > > > I tried to make AMD64_DARWIN distribution with: > > > > PATH=/cm3.amd64/bin:$PATH CM3CVSUSER=jkrell SHIPRC=y > > CM3_TARGET=AMD64_DARWIN ./make-dist.sh > > > > I got a bunch of files with I386_DARWIN in their names. > > Have you added support for all those new AMD64 targets to sysinfo.sh? > I assume you expect CM3_TARGET to override everything, but I'm not sure > that it will work everywhere. > > You should trace with set -x. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Aug 8 22:54:49 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 08 Aug 2009 22:54:49 +0200 Subject: [M3devel] trouble with RC2 -- maybe with hudson? In-Reply-To: References: <20090808114619.GA3806@topoi.pooq.com> <20090808135430.1iy8os9eogwwcss0@mail.elegosoft.com> Message-ID: <20090808225449.q4lgftjzpcsso8os@mail.elegosoft.com> Quoting Jay K : > The various make-dist console outputs show a literal $RARGS, not the > expected switches. > -10 for sh? Jay, the .M3SHIP file mostly looks OK, i.e. the expected variables are found, which would not be the case if the parameters aren't passed correctly. make_dir(PKG_INSTALL & "/tcp/" & TARGET) install_file(".M3EXPORTS", PKG_INSTALL & "/tcp/" & TARGET, "0664") make_dir(LIB_INSTALL) install_file("libm3tcp.so.5", LIB_INSTALL, "0775") symbolic_link_file(PKG_INSTALL & "/tcp/" & TARGET & "/libm3tcp.a", LIB_INSTALL & "/libm3tcp.a") make_dir("/home/hudson/tmp/cm3/bin/../lib") symbolic_link_file("libm3tcp.so.5", "/home/hudson/tmp/cm3/bin/../lib/libm3tcp.so") symbolic_link_file(LIB_INSTALL & "/libm3tcp.so.5", PKG_INSTALL & "/tcp/" & TARGET & "/libm3tcp.so") symbolic_link_file(LIB_INSTALL & "/libm3tcp.so.5", PKG_INSTALL & "/tcp/" & TARGET & "/libm3tcp.so.5") install_file("libm3tcp.a", PKG_INSTALL & "/tcp/" & TARGET, "0664") install_file("libm3tcp.m3x", PKG_INSTALL & "/tcp/" & TARGET, "0664") install_file(".M3WEB", PKG_INSTALL & "/tcp/" & TARGET, "0664") make_dir(PKG_INSTALL & "/tcp/src/POSIX") install_file("../src/POSIX/TCP.m3", PKG_INSTALL & "/tcp/src/POSIX", "0664") install_file("../src/POSIX/TCPPosix.i3", PKG_INSTALL & "/tcp/src/POSIX", "0664") install_file("../src/POSIX/Herrno.i3", PKG_INSTALL & "/tcp/src/POSIX", "0664") install_file("../src/POSIX/HerrnoC.c", PKG_INSTALL & "/tcp/src/POSIX", "0664") install_file("../src/POSIX/IP.m3", PKG_INSTALL & "/tcp/src/POSIX", "0664") install_file("../src/POSIX/IPErrorPosix.m3", PKG_INSTALL & "/tcp/src/POSIX", "0664") install_file("../src/POSIX/TCPExtras.m3", PKG_INSTALL & "/tcp/src/POSIX", "0664") install_file("../src/POSIX/TCPPeer.m3", PKG_INSTALL & "/tcp/src/POSIX", "0664") I had tested that with several different packages some weeks ago. I still think you overlooked some case when applying your changes. Can you please check again? We probably have to rebuild lots of packages... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sat Aug 8 23:15:48 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 8 Aug 2009 21:15:48 +0000 Subject: [M3devel] trouble with RC2 -- maybe with hudson? In-Reply-To: <20090808225449.q4lgftjzpcsso8os@mail.elegosoft.com> References: <20090808114619.GA3806@topoi.pooq.com> <20090808135430.1iy8os9eogwwcss0@mail.elegosoft.com> <20090808225449.q4lgftjzpcsso8os@mail.elegosoft.com> Message-ID: These contain no binaries at all, just source: m3-bin-ws-anim-LINUXLIBC6-d5.8.2-RC2.tgz m3-bin-ws-cvsup-LINUXLIBC6-d5.8.2-RC2.tgz intentional? I see. You are right: cm3-bin-ws-core-LINUXLIBC6-d5.8.2-RC2.tgz jbook2:t jay$ more m3-tools/m3bundle/LINUXLIBC6/.M3SHIP make_dir(PKG_INSTALL & "/m3bundle/" & TARGET) install_file(".M3EXPORTS", PKG_INSTALL & "/m3bundle/" & TARGET, "0664" ) make_dir("/home/hudson/tmp/cm3/bin") install_file("m3bundle", "/home/hudson/tmp/cm3/bin", "0775") install_file(".M3WEB", PKG_INSTALL & "/m3bundle/" & TARGET, "0664") m - Jay > Date: Sat, 8 Aug 2009 22:54:49 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] trouble with RC2 -- maybe with hudson? > > Quoting Jay K : > > > The various make-dist console outputs show a literal $RARGS, not the > > expected switches. > > -10 for sh? > > Jay, the .M3SHIP file mostly looks OK, i.e. the expected variables > are found, which would not be the case if the parameters aren't > passed correctly. > > make_dir(PKG_INSTALL & "/tcp/" & TARGET) > install_file(".M3EXPORTS", PKG_INSTALL & "/tcp/" & TARGET, "0664") > make_dir(LIB_INSTALL) > install_file("libm3tcp.so.5", LIB_INSTALL, "0775") > symbolic_link_file(PKG_INSTALL & "/tcp/" & TARGET & "/libm3tcp.a", > LIB_INSTALL & "/libm3tcp.a") > make_dir("/home/hudson/tmp/cm3/bin/../lib") > symbolic_link_file("libm3tcp.so.5", > "/home/hudson/tmp/cm3/bin/../lib/libm3tcp.so") > symbolic_link_file(LIB_INSTALL & "/libm3tcp.so.5", PKG_INSTALL & > "/tcp/" & TARGET & "/libm3tcp.so") > symbolic_link_file(LIB_INSTALL & "/libm3tcp.so.5", PKG_INSTALL & > "/tcp/" & TARGET & "/libm3tcp.so.5") > install_file("libm3tcp.a", PKG_INSTALL & "/tcp/" & TARGET, "0664") > install_file("libm3tcp.m3x", PKG_INSTALL & "/tcp/" & TARGET, "0664") > install_file(".M3WEB", PKG_INSTALL & "/tcp/" & TARGET, "0664") > make_dir(PKG_INSTALL & "/tcp/src/POSIX") > install_file("../src/POSIX/TCP.m3", PKG_INSTALL & "/tcp/src/POSIX", "0664") > install_file("../src/POSIX/TCPPosix.i3", PKG_INSTALL & > "/tcp/src/POSIX", "0664") > install_file("../src/POSIX/Herrno.i3", PKG_INSTALL & "/tcp/src/POSIX", "0664") > install_file("../src/POSIX/HerrnoC.c", PKG_INSTALL & "/tcp/src/POSIX", "0664") > install_file("../src/POSIX/IP.m3", PKG_INSTALL & "/tcp/src/POSIX", "0664") > install_file("../src/POSIX/IPErrorPosix.m3", PKG_INSTALL & > "/tcp/src/POSIX", "0664") > install_file("../src/POSIX/TCPExtras.m3", PKG_INSTALL & > "/tcp/src/POSIX", "0664") > install_file("../src/POSIX/TCPPeer.m3", PKG_INSTALL & > "/tcp/src/POSIX", "0664") > > I had tested that with several different packages some weeks ago. > > I still think you overlooked some case when applying your changes. > > Can you please check again? We probably have to rebuild lots of > packages... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Aug 8 23:21:34 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 08 Aug 2009 23:21:34 +0200 Subject: [M3devel] trouble with RC2 -- maybe with hudson? In-Reply-To: References: <20090808114619.GA3806@topoi.pooq.com> <20090808135430.1iy8os9eogwwcss0@mail.elegosoft.com> Message-ID: <20090808232134.abs0ft0zgo4ocssk@mail.elegosoft.com> Quoting Jay K : > The various make-dist console outputs show a literal $RARGS, not the > expected switches. > -10 for sh? I've just tested the -no-m3ship-resolution switch on the current cm3 on birch. It mostly works, but some shipping destinations do not use the variable names. So it's nothing to do with shell incompatibilities, but with our programming mistakes. It may be that such paths containing // (perfectly legal in POSIX) and .../bin/../lib/... are the culprit. I should not have relied on the automatic installation testing by hudson; everything worked there, as it is the same user who built the packages. To find such errors, we need to test with different users... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sat Aug 8 23:31:23 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 8 Aug 2009 21:31:23 +0000 Subject: [M3devel] trouble with RC2 -- maybe with hudson? In-Reply-To: <20090808232134.abs0ft0zgo4ocssk@mail.elegosoft.com> References: <20090808114619.GA3806@topoi.pooq.com> <20090808135430.1iy8os9eogwwcss0@mail.elegosoft.com> <20090808232134.abs0ft0zgo4ocssk@mail.elegosoft.com> Message-ID: It's not that. dot and dotdot get smushed out. What does // mean? My code changes any // to just /, except at the start of a path. That is what GetFullPathname on Windows with backward slashes. I was missing BIN_INSTALL and worst case fallback INSTALL_ROOT. - Jay > Date: Sat, 8 Aug 2009 23:21:34 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] trouble with RC2 -- maybe with hudson? > > Quoting Jay K : > > > The various make-dist console outputs show a literal $RARGS, not the > > expected switches. > > -10 for sh? > > I've just tested the -no-m3ship-resolution switch on the current > cm3 on birch. It mostly works, but some shipping destinations do not > use the variable names. So it's nothing to do with shell incompatibilities, > but with our programming mistakes. > > It may be that such paths containing // (perfectly legal in POSIX) > and .../bin/../lib/... are the culprit. > > I should not have relied on the automatic installation testing by hudson; > everything worked there, as it is the same user who built the > packages. To find such errors, we need to test with different > users... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Aug 8 23:40:38 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 08 Aug 2009 23:40:38 +0200 Subject: [M3devel] trouble with RC2 -- maybe with hudson? In-Reply-To: References: <20090808114619.GA3806@topoi.pooq.com> <20090808135430.1iy8os9eogwwcss0@mail.elegosoft.com> <20090808232134.abs0ft0zgo4ocssk@mail.elegosoft.com> Message-ID: <20090808234038.2u68sn81cs04gc40@mail.elegosoft.com> Quoting Jay K : > It's not that. dot and dotdot get smushed out. > What does // mean? > My code changes any // to just /, except at the start of a path. > That is what GetFullPathname on Windows with backward slashes. That's OK. > I was missing BIN_INSTALL and worst case fallback INSTALL_ROOT. So we may have to build RC3 sooner than intended. There's always the workaround to just call cm3 -build before shipping, but many of the install.sh scripts will fail for RC2. Can you check in a fix to the release branch? We may be able to build new packages tomorrow evening or at the start of the week. Olaf > - Jay > >> Date: Sat, 8 Aug 2009 23:21:34 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] trouble with RC2 -- maybe with hudson? >> >> Quoting Jay K : >> >> > The various make-dist console outputs show a literal $RARGS, not the >> > expected switches. >> > -10 for sh? >> >> I've just tested the -no-m3ship-resolution switch on the current >> cm3 on birch. It mostly works, but some shipping destinations do not >> use the variable names. So it's nothing to do with shell incompatibilities, >> but with our programming mistakes. >> >> It may be that such paths containing // (perfectly legal in POSIX) >> and .../bin/../lib/... are the culprit. >> >> I should not have relied on the automatic installation testing by hudson; >> everything worked there, as it is the same user who built the >> packages. To find such errors, we need to test with different >> users... >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sun Aug 9 01:58:25 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Sat, 8 Aug 2009 16:58:25 -0700 Subject: [M3devel] make-dist vs. $CM3_TARGET/AMD64_DARWIN In-Reply-To: <20090808224418.oel9aad5w8w8w0wc@mail.elegosoft.com> References: <20090808224418.oel9aad5w8w8w0wc@mail.elegosoft.com> Message-ID: <25BD6284-E323-4C6D-837C-E853A1B15119@hotmail.com> Ps amd64_Darwin is not new. It was the first Amd64 target. - Jay (phone) On Aug 8, 2009, at 1:44 PM, Olaf Wagner wrote: > Quoting Jay K : > >> I tried to make AMD64_DARWIN distribution with: >> >> PATH=/cm3.amd64/bin:$PATH CM3CVSUSER=jkrell SHIPRC=y >> CM3_TARGET=AMD64_DARWIN ./make-dist.sh >> >> I got a bunch of files with I386_DARWIN in their names. > > Have you added support for all those new AMD64 targets to sysinfo.sh? > I assume you expect CM3_TARGET to override everything, but I'm not > sure > that it will work everywhere. > > You should trace with set -x. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ > any > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be > rlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > From wagner at elegosoft.com Mon Aug 10 00:32:36 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 10 Aug 2009 00:32:36 +0200 Subject: [M3devel] make-dist vs. $CM3_TARGET/AMD64_DARWIN In-Reply-To: <25BD6284-E323-4C6D-837C-E853A1B15119@hotmail.com> References: <20090808224418.oel9aad5w8w8w0wc@mail.elegosoft.com> <25BD6284-E323-4C6D-837C-E853A1B15119@hotmail.com> Message-ID: <20090810003236.8v14j0kpccosscow@mail.elegosoft.com> Quoting jay.krell at cornell.edu: > Ps amd64_Darwin is not new. It was the first Amd64 target. Right, I was confused here. But I guess it was never integrated into the sysinfo.sh script nonetheless. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Aug 10 00:56:32 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 9 Aug 2009 22:56:32 +0000 Subject: [M3devel] caltech-parser m3overrides? Message-ID: Anyone know about all (not all, many) these packages in caltech-parser m3overrides? They no longer exist? We didn't get all the source? override("prsparse",TOP) override("magic",TOP) override("magicextras",TOP) override("cit_common",TOP) override("cit_util",TOP) override("bdd",TOP) override("cptr",TOP) override("bool",TOP) override("boxes",TOP) override("simplegrid",TOP) override("router",TOP) override("term",TOP) override("m3-3",TOP) override("paneman",TOP) override("parserlib",TOP & SL & "parserlib") override("ktoklib",TOP & SL & "parserlib") override("cit_parse",TOP) override("drawcontext",TOP) override("dcpane",TOP & SL & "drawcontext") override("tasks",TOP) override("matrix",TOP) override("layout",TOP) From jay.krell at cornell.edu Mon Aug 10 12:53:43 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 10 Aug 2009 10:53:43 +0000 Subject: [M3devel] proposal for next release: moving some config file content into cm3 Message-ID: Native builds are the usual. Cross builds are rarer. It is dumb for config files to even specify TARGET. As well as thing I recently added: TARGET_OS, TARGET_ENDIAN. It should default to "HOST". Furthermore, a command line option rather than editing/replacing config file should achieve a cross build. One (or more?) of: cm3 I386_LINUX cm3 -target I386_LINUX cm3 -target:I386_LINUX cm3 -target=I386_LINUX cm3 --target I386_LINUX cm3 --target:I386_LINUX cm3 --target=I386_LINUX cm3 -DTARGET=I386_LINUX I like the first, but perhaps it is too implicit/sleazy. User should have to say what the random freestanding platform name means? pylib.py does support this. There is much precedent for the last, as cm3 already supports -D. I have found that -D tends to be processed too late to be as useful as it could/should be. We should probably fix this. Any changes along these lines would "by default" (if not done along with other changes) break other m3quake/m3config users -- m3tohtml, cm3ide, etc. The code in cm3 that "predefines" stuff, such "HOST", such as defaulting TARGET, shall move into the m3quake package, but not be run "automatically". m3quake shall remain by default ignorant of its usual use in support of compiling Modula-3 and remain by default "just a scripting language". Something like m3-sys/m3quake/M3Predefines.i3 m3-sys/m3quake/M3Predefines.Init Should they start with "Q" or M3"? Should cm3 be split up into cm3lib and cm3exe and these would be m3-sys/cm3lib/M3Predefines? m3quake users who are attempting to act "like the compiler" shall call M3Predefines.Init(). Furthermore, the following should all be "correctly default" and therefore moved out of config files: INSTALL_ROOT (based on cm3's location) BIN_INSTALL LIB_INSTALL MAN_INSTALL PKG_INSTALL USE_ROOT LIB_USE PKG_USE etc. (so much for a precise spec. :) ) The config file shall still be able to override this. As well as the command line. I think. There is some order ambiguity. Normally LIB_USE defaults to LIB_INSTALL, etc. If the command line overrides LIB_INSTALL, should that also change LIB_USE? Perhaps these are not changable on the command line. Does anyone really ever vary them? Sure, people install to custom place, but do they all not follow directly from cm3.exe location? Well, I sometimes run unshipped cm3. That is something to consider. cm3 should perhaps even move to an archictecture-specific directory. /cm3/bin/I386_LINUX/cm3 However, aside, I've given up on that idea. While the pkg store has all these nice target-specific directories already, instead of solving the problem for bin and lib, and then having savings due to not duplicating "man", I've just been going with separate entire roots. On a Mac for example, I'd have /cm3.x86 /cm3.amd64 /cm3.ppc /cm3.ppc64 (hypothetical) or on Windows: /cm3 ("native") /cm3.cygwin /cm3.interix The "man" directory would be wastefully duplicated. For the rare user of unshipped cm3 to have to say -DINSTALL_ROOT=/usr/local/bin/cm3 doesn't seem terrible. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Aug 10 14:13:54 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 10 Aug 2009 14:13:54 +0200 Subject: [M3devel] proposal for next release: moving some config file content into cm3 In-Reply-To: References: Message-ID: <20090810141354.9co7e8rxss8g8o48@mail.elegosoft.com> Quoting Jay K : > Furthermore, the following should all be "correctly default" > and therefore moved out of config files: > INSTALL_ROOT (based on cm3's location) > BIN_INSTALL > LIB_INSTALL > MAN_INSTALL > PKG_INSTALL > USE_ROOT > LIB_USE > PKG_USE > > etc. (so much for a precise spec. :) ) > > The config file shall still be able to override this. > As well as the command line. I think. If these cannot be overriden by the config files, system specific installations not adhering to the standard layout won't be possible. > There is some order ambiguity. > Normally LIB_USE defaults to LIB_INSTALL, etc. > If the command line overrides LIB_INSTALL, should > that also change LIB_USE? > > Perhaps these are not changable on the command line. > Does anyone really ever vary them? > Sure, people install to custom place, but > do they all not follow directly from cm3.exe location? > > Well, I sometimes run unshipped cm3. > That is something to consider. > cm3 should perhaps even move to an archictecture-specific directory. > /cm3/bin/I386_LINUX/cm3 > > However, aside, I've given up on that idea. Why? Too complex? Is there some strong argument against it? (I don't remember offhand.) > While the pkg store has all these nice target-specific directories already, > instead of solving the problem for bin and lib, and then having > savings due to not duplicating "man", I've just been > going with separate entire roots. > > On a Mac for example, I'd have > /cm3.x86 > /cm3.amd64 > /cm3.ppc > /cm3.ppc64 (hypothetical) > > or on Windows: > /cm3 ("native") > /cm3.cygwin > /cm3.interix > > The "man" directory would be wastefully duplicated. > > For the rare user of unshipped cm3 to have to say > -DINSTALL_ROOT=/usr/local/bin/cm3 > > doesn't seem terrible. -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Mon Aug 10 14:35:23 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 10 Aug 2009 14:35:23 +0200 Subject: [M3devel] CM3 Hudson Config in CVS Message-ID: <20090810143523.ntayisdvpc4wsgc0@mail.elegosoft.com> I've added a small script that saves all the XML config files of the various Hudson jobs for CM3 into birch's CVS repository below /usr/cvs/hudson-config. It should be accessible for all M3 users, but should be treated as read-only. It is only there to record the history and for backup purposes. It is still very dumb and needs to be improved, so that only actual changes get imported and tagged. The corresponding Hudson job is http://hudson.modula3.com:8080/view/www/job/save-xml-config/ Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Aug 10 19:17:12 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 10 Aug 2009 17:17:12 +0000 Subject: [M3devel] testing RC2. In-Reply-To: <6A0491CD-BC10-49BB-8100-3137A406DBE7@darko.org> References: <20090804002754.GF25621@topoi.pooq.com> <1C5F772D-930B-472B-A83B-32DEC364D2FA@hotmail.com> <20090804105835.vs1925r2kg480ccg@mail.elegosoft.com> <6A0491CD-BC10-49BB-8100-3137A406DBE7@darko.org> Message-ID: My attempt to do an AMD64_DARWIN build messed up the I386_DARWIN files. I386_DARWIN needs to be rebuilt, preferably this time via Hudson. Please give it a day or two at least. - Jay ---------------------------------------- > CC: m3devel at elegosoft.com > From: darko at darko.org > To: jay.krell at cornell.edu > Subject: Re: [M3devel] testing RC2. > Date: Mon, 10 Aug 2009 17:24:53 +0200 > > Just looking into a Mac installer but found the RC2 "optional" > archives seem to have AMD64_DARWIN libraries instead of I386_DARWIN. > I'm looking in http://www.opencm3.net/releng/download.html > > > On 04/08/2009, at 1:49 PM, Jay K wrote: > >> >>> build some missing installation packages (for I386_DARWIN for >>> example) >> >> >> I have a new computer arriving roughly Friday on which I can setup >> near arbitrary x86/AMD64 VMs, as well as doing native I386_DARWIN >> and AMD64_DARWIN. AMD64_FREEBSD is also missing for example. >> Tony should also be able to do {I386,AMD64}_DARWIN. >> >> >> - Jay >> >> >> >> ---------------------------------------- >>> Date: Tue, 4 Aug 2009 10:58:35 +0200 >>> From: wagner at elegosoft.com >>> To: m3devel at elegosoft.com >>> Subject: Re: [M3devel] testing RC2. >>> >>> Quoting jay.krell at cornell.edu: >>> >>>> Wikipedia: Aren't you subverting release manager Olaf? Not ready for >>>> exposure beyond m3devel? >>> >>> I just moved the date for RC2 another week :-/ Too many things still >>> to be done. See >>> >>> https://projects.elego.de/cm3/milestone/CM3%20Release%205.8%20RC2 >>> >>> We need >>> >>> o to improve the WWW presentation (there were suggestions from >>> Peter Eiserloh and others but no concrete changes/commits AFAIK) >>> >>> o build some missing installation packages (for I386_DARWIN for >>> example) >>> >>> o automate some installation tests (next thing I'll do) >>> >>> o get some feedback from manual tests >>> >>> If there are no commits to the web pages till Wednesday, I'll make >>> some small adaptions there to be ready for RC2 then. >>> >>> Olaf >>> >>>> - Jay (phone) >>>> >>>> On Aug 3, 2009, at 5:27 PM, hendrik at topoi.pooq.com wrote: >>>> >>>>> Now that I've updated the wikipedia entry, it's easier to find >>>>> the RC2 >>>>> downloads page. >>>>> >>>>> How can I update the other places that are easy to find on the >>>>> google? >>>>> Specifically, >>>>> the Modula 3 resource page, www.modula3.org/ >>>>> Modula-3 Frequently Asked Questions (FAQ), >>>>> www.faqs.org/faqs/Modula-3-faq/ >>>>> >>>>> I'll soon be trying another installation fromscratch, using RC2, >>>>> and I'll let you know how it went. >>>>> >>>>> -- hendrik >>>>> >>>>> >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>> 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>> Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> > From hosking at cs.purdue.edu Mon Aug 10 20:19:38 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 10 Aug 2009 14:19:38 -0400 Subject: [M3devel] lots of problems in gui on AMD64_DARWIN? In-Reply-To: References: Message-ID: <224E3743-8052-4D90-B49E-BC7CFD01FFF0@cs.purdue.edu> I believe this code used to work on 64-bit ALPHA_OSF, unless something changed since then. Just looking at it, it claims to be 64-bit safe. On 8 Aug 2009, at 16:12, Jay K wrote: > Not all gui apps fail. > Some 32bit-isms in TimeStamp.m3. > gdb doesn't seem to be working at all for me, arg. > > jbook2:bin jay$ ./mentor > > > *** > *** runtime error: > *** An enumeration or subrange value was out of range. > *** file "../src/uid/Common/TimeStamp.m3", line 63 > *** > > Abort trap > > jbook2:bin jay$ ./formsedit > > > *** > *** runtime error: > *** An enumeration or subrange value was out of range. > *** file "../src/uid/Common/TimeStamp.m3", line 63 > *** > > > jbook2:bin jay$ ./BadBricks > > > *** > *** runtime error: > *** An enumeration or subrange value was out of range. > *** file "../src/uid/Common/TimeStamp.m3", line 63 > *** > > Abort trap > > book2:bin jay$ ./Calculator > > > *** > *** runtime error: > *** An enumeration or subrange value was out of range. > *** file "../src/uid/Common/TimeStamp.m3", line 63 > *** > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Aug 10 20:37:26 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 10 Aug 2009 14:37:26 -0400 Subject: [M3devel] lots of problems in gui on AMD64_DARWIN? In-Reply-To: References: Message-ID: <54CE76F0-8422-4124-8981-9B91B08F374D@cs.purdue.edu> I have no problem invoking TimeStamp.New() with my AMD64_DARWIN build. I'm not sure why you are seeing problems with your build. On 8 Aug 2009, at 16:12, Jay K wrote: > Not all gui apps fail. > Some 32bit-isms in TimeStamp.m3. > gdb doesn't seem to be working at all for me, arg. > > jbook2:bin jay$ ./mentor > > > *** > *** runtime error: > *** An enumeration or subrange value was out of range. > *** file "../src/uid/Common/TimeStamp.m3", line 63 > *** > > Abort trap > > jbook2:bin jay$ ./formsedit > > > *** > *** runtime error: > *** An enumeration or subrange value was out of range. > *** file "../src/uid/Common/TimeStamp.m3", line 63 > *** > > > jbook2:bin jay$ ./BadBricks > > > *** > *** runtime error: > *** An enumeration or subrange value was out of range. > *** file "../src/uid/Common/TimeStamp.m3", line 63 > *** > > Abort trap > > book2:bin jay$ ./Calculator > > > *** > *** runtime error: > *** An enumeration or subrange value was out of range. > *** file "../src/uid/Common/TimeStamp.m3", line 63 > *** > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Aug 10 21:17:47 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 10 Aug 2009 19:17:47 +0000 Subject: [M3devel] testing RC2. In-Reply-To: References: <20090804002754.GF25621@topoi.pooq.com> <1C5F772D-930B-472B-A83B-32DEC364D2FA@hotmail.com> <20090804105835.vs1925r2kg480ccg@mail.elegosoft.com> <6A0491CD-BC10-49BB-8100-3137A406DBE7@darko.org> Message-ID: New (untested) I386_DARWIN packages are uploading right now. cm3-bin-core-I386_DARWIN-d5.8.2-RC2.tgz 100% 15MB 65.3KB/s 03:50 cm3-bin-min-I386_DARWIN-d5.8.2-RC2.tgz 100% 7511KB 62.1KB/s 02:01 cm3-bin-ws-anim-I386_DARWIN-d5.8.2-RC2.tgz 100% 5033KB 65.4KB/s 01:17 cm3-bin-ws-caltech-parser-I386_DARWIN-d5.8.2- 100% 4205KB 64.7KB/s 01:05 are done. - Jay > From: jay.krell at cornell.edu > To: darko at darko.org > Date: Mon, 10 Aug 2009 17:17:12 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] testing RC2. > > > My attempt to do an AMD64_DARWIN build messed up the I386_DARWIN files. > I386_DARWIN needs to be rebuilt, preferably this time via Hudson. > Please give it a day or two at least. > > - Jay > > > ---------------------------------------- > > CC: m3devel at elegosoft.com > > From: darko at darko.org > > To: jay.krell at cornell.edu > > Subject: Re: [M3devel] testing RC2. > > Date: Mon, 10 Aug 2009 17:24:53 +0200 > > > > Just looking into a Mac installer but found the RC2 "optional" > > archives seem to have AMD64_DARWIN libraries instead of I386_DARWIN. > > I'm looking in http://www.opencm3.net/releng/download.html > > > > > > On 04/08/2009, at 1:49 PM, Jay K wrote: > > > >> > >>> build some missing installation packages (for I386_DARWIN for > >>> example) > >> > >> > >> I have a new computer arriving roughly Friday on which I can setup > >> near arbitrary x86/AMD64 VMs, as well as doing native I386_DARWIN > >> and AMD64_DARWIN. AMD64_FREEBSD is also missing for example. > >> Tony should also be able to do {I386,AMD64}_DARWIN. > >> > >> > >> - Jay > >> > >> > >> > >> ---------------------------------------- > >>> Date: Tue, 4 Aug 2009 10:58:35 +0200 > >>> From: wagner at elegosoft.com > >>> To: m3devel at elegosoft.com > >>> Subject: Re: [M3devel] testing RC2. > >>> > >>> Quoting jay.krell at cornell.edu: > >>> > >>>> Wikipedia: Aren't you subverting release manager Olaf? Not ready for > >>>> exposure beyond m3devel? > >>> > >>> I just moved the date for RC2 another week :-/ Too many things still > >>> to be done. See > >>> > >>> https://projects.elego.de/cm3/milestone/CM3%20Release%205.8%20RC2 > >>> > >>> We need > >>> > >>> o to improve the WWW presentation (there were suggestions from > >>> Peter Eiserloh and others but no concrete changes/commits AFAIK) > >>> > >>> o build some missing installation packages (for I386_DARWIN for > >>> example) > >>> > >>> o automate some installation tests (next thing I'll do) > >>> > >>> o get some feedback from manual tests > >>> > >>> If there are no commits to the web pages till Wednesday, I'll make > >>> some small adaptions there to be ready for RC2 then. > >>> > >>> Olaf > >>> > >>>> - Jay (phone) > >>>> > >>>> On Aug 3, 2009, at 5:27 PM, hendrik at topoi.pooq.com wrote: > >>>> > >>>>> Now that I've updated the wikipedia entry, it's easier to find > >>>>> the RC2 > >>>>> downloads page. > >>>>> > >>>>> How can I update the other places that are easy to find on the > >>>>> google? > >>>>> Specifically, > >>>>> the Modula 3 resource page, www.modula3.org/ > >>>>> Modula-3 Frequently Asked Questions (FAQ), > >>>>> www.faqs.org/faqs/Modula-3-faq/ > >>>>> > >>>>> I'll soon be trying another installation fromscratch, using RC2, > >>>>> and I'll let you know how it went. > >>>>> > >>>>> -- hendrik > >>>>> > >>>>> > >>> > >>> > >>> > >>> -- > >>> Olaf Wagner -- elego Software Solutions GmbH > >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > >>> 45 86 95 > >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > >>> Berlin > >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > >>> DE163214194 > >>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Aug 10 21:52:16 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 10 Aug 2009 19:52:16 +0000 Subject: [M3devel] proposal for next release: moving some config file content into cm3 In-Reply-To: <20090810141354.9co7e8rxss8g8o48@mail.elegosoft.com> References: <20090810141354.9co7e8rxss8g8o48@mail.elegosoft.com> Message-ID: > If these cannot be overriden by the config files, system specific > installations not adhering to the standard layout won't be possible. They shall be overridable, but perhaps only INSTALL_ROOT? It becomes ambiguous, as to when to resolve INSTALL_ROOT in code like PKG_INSTALL = INSTALL_ROOT & /pkg PKG_USE = INSTALL_ROOT & /pkg or PKG_USE = PKG_INSTALL You have to decide what order things are processed -- builtin defines then command line, or command line then builtin defines, or loop while things change. Could I on the command line say -DPKG_USE="INSTALL_ROOT & '/foo'" ? Does cm3 -DINSTALL_ROOT=/foo imply PKG_USE=/foo/pkg? An easy answer is to only allow overriding USE_ROOT and INSTALL_ROOT. That all the rest follow directly by appending /bin, /pkg, /lib. I guess as well each one is "fully" overridable, but overriding "part of an expression" won't cause that expression to be reevaluated, and all the builtins are evaluated..first? last? Can I say PKG_USE=INSTALL_ROOT & /foo? Is INSTALL_ROOT defined before or after the command line is processed? I don't mean currently, but ideally. > > That is something to consider. > > cm3 should perhaps even move to an archictecture-specific directory. > > /cm3/bin/I386_LINUX/cm3 > > > > However, aside, I've given up on that idea. > > Why? Too complex? Is there some strong argument against it? > (I don't remember offhand.) If I'm going to have /cm3/bin/target, /cm3/lib/target, /cm3/pkg/m3core/target, and it is going to take work to teach things about this, it seems easier and almost equivalent to use /cm3.target/bin, /cm3.target/lib, or /cm3/target/bin, /cm3/target/lib, etc. The downside is some duplication, of the src directories in pkg, the config files (we can fix that, but very minor), doc, man..all fairly small..on Windows at least there is something called the "single instance store" that opportunistically finds identical files and combines their storage but makes them copy-on-write. I know I know -- "make whatever is different, different; leave whatever is the same, the same". But sometimes it is easier to just pretend everything is different, when it is almost true anyway. I wonder how cross builds fit here however. That might be a reason to have /cm3/bin/cm3 /cm3/lib/target /cm3/pkg/m3core/target (already the case) in that, you know, even though "biarch" and "multiarch" are "limited" to a maximum of around 3 (ppc, x86, amd64 darwin; cygwin, interix, native NT), cross combinations occupy the whole matrix, but only lib would get duplicated, not bin. The thing is, I find "full" cross builds to be too much of a pain -- the actual C compilation, assembly, link, so I don't account for them. You need to build or copy the C runtime and headers, build the cross compiler and assembler. The problem imho is that 1) it isn't even always possible, consider the case when the native tools are preferred over GNU and aren't open source (Irix, AIX, HP-UX?) 2) when it is possible, it varies, as the C runtime/headers have to be gotten a different way for each system (*BSD, Solaris, Linux, Windows). It is only "the same everywhere" if you define "everywhere" as one system such as FreeBSD OR Linux OR NetBSD. I have done this, copied /usr, /lib etc. from Solaris to a cross build host..but..as well..you don't even know which files. Perhaps I should use NFS and therefore get all the files more cheaply.. Hm. so /cm3/lib/target. And we use that for native too? Using symlinks for compat? And /cm3/bin/target. And /cm3/bin/cm3 is a .sh file with an except of sysinfo.sh? (and cm3.cmd would exist) And adjust the computation of INSTALL_ROOT? And the location of cm3.cfg? For the sake of "full" cross builds (ie: C compilation, assemble, link)? In either case, these are separate. Except that they relate regarding the computation of INSTALL_ROOT. The code for INSTALL_ROOT computation could be smart. If cm3's directory ends in "bin/host", remove two elements. If it ends in "bin", remove one element. If it ends in "m3-sys/host" error probably, or maybe search $PATH for another cm3 and apply the logic to its location. If anything else, error. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Aug 10 22:04:39 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 10 Aug 2009 20:04:39 +0000 Subject: [M3devel] testing RC2. In-Reply-To: References: <20090804002754.GF25621@topoi.pooq.com> <1C5F772D-930B-472B-A83B-32DEC364D2FA@hotmail.com> <20090804105835.vs1925r2kg480ccg@mail.elegosoft.com> <6A0491CD-BC10-49BB-8100-3137A406DBE7@darko.org> Message-ID: They should all be there now. - Jay From: jay To: darko CC: m3devel Subject: RE: [M3devel] testing RC2. Date: Mon, 10 Aug 2009 19:17:47 +0000 New (untested) I386_DARWIN packages are uploading right now. [snip] -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Aug 10 22:17:35 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 10 Aug 2009 22:17:35 +0200 Subject: [M3devel] testing RC2. In-Reply-To: References: <20090804002754.GF25621@topoi.pooq.com> <1C5F772D-930B-472B-A83B-32DEC364D2FA@hotmail.com> <20090804105835.vs1925r2kg480ccg@mail.elegosoft.com> <6A0491CD-BC10-49BB-8100-3137A406DBE7@darko.org> Message-ID: <20090810221735.covpvzsf4gosogoc@mail.elegosoft.com> Quoting Jay K : > They should all be there now. Great, thanks. Olaf > - Jay > > From: jay > To: darko > CC: m3devel > Subject: RE: [M3devel] testing RC2. > Date: Mon, 10 Aug 2009 19:17:47 +0000 > > > > > > > > > New (untested) I386_DARWIN packages are uploading right now. > > [snip] > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Aug 10 23:10:02 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 10 Aug 2009 21:10:02 +0000 Subject: [M3devel] the beauty of a C backend.. Message-ID: The beauty of a C backend.. We'd just release source and be done. No platform build matrix -- only what we'd test. Leave all the less used architectures to their users. Leave all the packaging to the distribution packaging people. Maybe use autoconf for some of the platform specific stuff, though we have very little anyway. You know, you don't see binary packages for many projects provided by their owners, and then not for many architectures. You know, we'd just do like NT/x86, Linux/x86, maybe Linux/amd64, and that'd be it. Anyone running anything else is an advanced or unusual user. (the x86 packages would generally work on the popular AMD64 machines, anyone wanting native could build from source) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Aug 10 23:19:42 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 10 Aug 2009 17:19:42 -0400 Subject: [M3devel] the beauty of a C backend.. In-Reply-To: References: Message-ID: These are observations, but I don't see how they reach any conclusion, nor whether the conclusion is desirable. I'm not sure exactly what you are trying to say. On 10 Aug 2009, at 17:10, Jay K wrote: > The beauty of a C backend.. > We'd just release source and be done. > No platform build matrix -- only what we'd test. > Leave all the less used architectures to their users. > Leave all the packaging to the distribution packaging people. > Maybe use autoconf for some of the platform specific stuff, though > we have very little anyway. > > > You know, you don't see binary packages for many > projects provided by their owners, and then not for many > architectures. > You know, we'd just do like NT/x86, Linux/x86, maybe Linux/amd64, > and that'd be it. > Anyone running anything else is an advanced or unusual user. > (the x86 packages would generally work on the popular AMD64 > machines, anyone wanting > native could build from source) > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Aug 11 07:24:45 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 11 Aug 2009 05:24:45 +0000 Subject: [M3devel] platform names? Message-ID: Can folks humor me and decide on names for the following: ALPHA_VMS or ALPHA_OPENVMS VMS is shorter IA64_VMS or IA64_OPENVMS VMS is shorter "Open" implies "Posix" as I understand IA64_HPUX -- probably that is it PA32_LINUX or PA or HPPA or HPPA32 PA64_LINUX or HPPA64 gcc uses "hppa" and "hppa64". ALPHA_TRU64 or ALPHA_OSF or ALPHA_OSF1? gcc seems to use "osf1" MIPS32_IRIX probably right, new abi, ignore old abi or MIPSO32_IRIX or MIPSN32_IRIX ? MIPS64_IRIX probably right PPC32_AIX probably right PPC64_AIX probably right ARM_LINUX_UCLIBC? ARM_LINUX24? ARM_LINUX_USERTHREADS? ? Eventually I'd like to get to these, as long gcc supports them, unless I get a C backend working and porting work therefore declines. I have already run some of these OSes recently: AIX, Irix, Linux/hppa. Nothing on Alpha yet, nor VMS. Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Aug 11 07:34:28 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 11 Aug 2009 05:34:28 +0000 Subject: [M3devel] proposal for next release: moving some config file content into cm3 Message-ID: > cm3 should perhaps even move to an archictecture-specific directory. > /cm3/bin/I386_LINUX/cm3 One thing I forgot about here is where to install the likes of: jbook2:m3cc jay$ ls -1 */cm3cg I386_DARWIN-AMD64_FREEBSD/cm3cg I386_DARWIN-AMD64_LINUX/cm3cg I386_DARWIN-AMD64_NETBSD/cm3cg I386_DARWIN-AMD64_OPENBSD/cm3cg I386_DARWIN-FreeBSD4/cm3cg I386_DARWIN-I386_INTERIX/cm3cg I386_DARWIN-I386_OPENBSD/cm3cg Probably /cm3/bin/AMD64_FREEBSD/cm3cg This doesn't necessarily imply "solving" "where to put host specific files". These are target-specific. Eventually it might be nice provide cross compiler packages, for folks that have cross gcc/ld. I just have the config file probe around in the uninstalled tree for backends. If anyone could tackle writing a linker/loader for some systems, I'd be willing to reconsider all the extra C code, for some systems. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Aug 11 07:37:34 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 11 Aug 2009 05:37:34 +0000 Subject: [M3devel] targeting kernel instead of libc/pthreads? Message-ID: Does anyone - like the idea - can work on implementing Modula-3 threads over one/some/all of the kernel interfaces? In particular on Linux pthreads are usermode layer over something else. If we targeted the kernel interface, we could ignore uclibc vc. glibc vc. newlib. On the flip side -- is pthreads viable on non-NPTL kernels? It's not like the C interfaces weren't there. Or is Modula-3 sensitive to the odd semantics? Or is it just slightly or much too slow? Just throwing ideas out.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Aug 11 07:38:05 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 11 Aug 2009 05:38:05 +0000 Subject: [M3devel] proposal for next release: moving some config file content into cm3 Message-ID: [truncated again..] From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: RE: proposal for next release: moving some config file content into cm3 Date: Tue, 11 Aug 2009 05:34:28 +0000 > cm3 should perhaps even move to an archictecture-specific directory. > /cm3/bin/I386_LINUX/cm3 One thing I forgot about here is where to install the likes of: jbook2:m3cc jay$ ls -1 */cm3cg I386_DARWIN-AMD64_FREEBSD/cm3cg I386_DARWIN-AMD64_LINUX/cm3cg I386_DARWIN-AMD64_NETBSD/cm3cg I386_DARWIN-AMD64_OPENBSD/cm3cg I386_DARWIN-FreeBSD4/cm3cg I386_DARWIN-I386_INTERIX/cm3cg I386_DARWIN-I386_OPENBSD/cm3cg Probably /cm3/bin/AMD64_FREEBSD/cm3cg This doesn't necessarily imply "solving" "where to put host specific files". These are target-specific. Eventually it might be nice provide cross compiler packages, for folks that have cross gcc/ld. I just have the config file probe around in the uninstalled tree for backends. If anyone could tackle writing a linker/loader for some systems, I'd be willing to reconsider all the extra C code, for some systems. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Aug 11 08:11:17 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 11 Aug 2009 08:11:17 +0200 Subject: [M3devel] Package build/link errors on Solaris Message-ID: <20090811081117.xdm8121yu8ogw0o4@mail.elegosoft.com> There are lots of strage build/link errors on the two Solaris targets, see http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLsun/ http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/ Does anybody know offhand what's missing there? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Aug 11 08:22:13 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 11 Aug 2009 08:22:13 +0200 Subject: [M3devel] Package build/link errors on Solaris In-Reply-To: <20090811081117.xdm8121yu8ogw0o4@mail.elegosoft.com> References: <20090811081117.xdm8121yu8ogw0o4@mail.elegosoft.com> Message-ID: <20090811082213.o7sxi1znhgkg88gk@mail.elegosoft.com> Quoting Olaf Wagner : > There are lots of strage build/link errors on the two Solaris > targets, see > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLsun/ > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/ > > Does anybody know offhand what's missing there? Bad style to answer my own posts, but I've already found it. The X libraries are missing: -> archiving libm3ui.a ld: fatal: library -lXaw: not found ld: fatal: library -lXmu: not found ld: fatal: library -lXext: not found ld: fatal: library -lXt: not found ld: fatal: library -lX11: not found ld: fatal: File processing errors. No output written to libm3ui.so.5 collect2: ld returned 1 exit status make_lib => 1 Jay, did you remove the X installation? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Aug 11 15:37:30 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 11 Aug 2009 13:37:30 +0000 Subject: [M3devel] More Unix constants missing.... In-Reply-To: <1249638984.2745.11.camel@faramir.m3w.org> References: <1249638984.2745.11.camel@faramir.m3w.org> Message-ID: please review: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/unix/Common/Uconstants.c.diff?r1=1.36;r2=1.37 http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/unix/Common/Unix.i3.diff?r1=1.26;r2=1.27 and for a longer list of potentially removed constants to be restored: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/unix/Common/Unix.txt?rev=1.1;content-type=text%2Fplain - Jay > From: dragisha at m3w.org > To: m3devel at elegosoft.com > Date: Fri, 7 Aug 2009 11:56:24 +0200 > Subject: [M3devel] More Unix constants missing.... > > Can we have them, in both HEAD ad RC2 branch? > > TIA, > dd > > === > CONST > TIOCMGET = 16_5415; > TIOCMSET = 16_5418; > > Bits = ARRAY StatusBits OF CARDINAL { > Unix.TIOCM_LE, > Unix.TIOCM_DTR, > Unix.TIOCM_RTS, > Unix.TIOCM_ST, > Unix.TIOCM_SR, > Unix.TIOCM_CTS, > Unix.TIOCM_CAR, > Unix.TIOCM_RNG, > Unix.TIOCM_DSR > }; > > -- > Dragi?a Duri? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Aug 11 15:41:39 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 11 Aug 2009 13:41:39 +0000 Subject: [M3devel] Package build/link errors on Solaris In-Reply-To: <20090811082213.o7sxi1znhgkg88gk@mail.elegosoft.com> References: <20090811081117.xdm8121yu8ogw0o4@mail.elegosoft.com> <20090811082213.o7sxi1znhgkg88gk@mail.elegosoft.com> Message-ID: I thought I only removed static archives, in a quest for diskspace, arg. Not sure how to fix, might have to reinstall. Sorry. - Jay > Date: Tue, 11 Aug 2009 08:22:13 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Package build/link errors on Solaris > > Quoting Olaf Wagner : > > > There are lots of strage build/link errors on the two Solaris > > targets, see > > > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLsun/ > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/ > > > > Does anybody know offhand what's missing there? > > Bad style to answer my own posts, but I've already found it. The X > libraries are missing: > > -> archiving libm3ui.a > ld: fatal: library -lXaw: not found > ld: fatal: library -lXmu: not found > ld: fatal: library -lXext: not found > ld: fatal: library -lXt: not found > ld: fatal: library -lX11: not found > ld: fatal: File processing errors. No output written to libm3ui.so.5 > collect2: ld returned 1 exit status > make_lib => 1 > > Jay, did you remove the X installation? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Aug 11 15:48:01 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 11 Aug 2009 09:48:01 -0400 Subject: [M3devel] targeting kernel instead of libc/pthreads? In-Reply-To: References: Message-ID: <5E49131B-9F6E-4E8E-AEB3-398B401B38EF@cs.purdue.edu> On 11 Aug 2009, at 01:37, Jay K wrote: > Does anyone > - like the idea Perhaps an interesting "research" idea. Probably not for the mainstream, because it is so platform-specific and puts you at the mercy of changes to kernel interfaces as opposed to more stable POSIX APIs. > - can work on implementing > > Modula-3 threads over one/some/all of the kernel interfaces? > In particular on Linux pthreads are usermode layer over something > else. > > If we targeted the kernel interface, we could ignore uclibc vc. > glibc vc. newlib. > > On the flip side -- is pthreads viable on non-NPTL kernels? > It's not like the C interfaces weren't there. > Or is Modula-3 sensitive to the odd semantics? > Or is it just slightly or much too slow? > > Just throwing ideas out.. > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Aug 11 15:53:23 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 11 Aug 2009 13:53:23 +0000 Subject: [M3devel] Package build/link errors on Solaris In-Reply-To: <20090811082213.o7sxi1znhgkg88gk@mail.elegosoft.com> References: <20090811081117.xdm8121yu8ogw0o4@mail.elegosoft.com> <20090811082213.o7sxi1znhgkg88gk@mail.elegosoft.com> Message-ID: I think I'll attempt a new install this week, sorry. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Subject: RE: [M3devel] Package build/link errors on Solaris Date: Tue, 11 Aug 2009 13:41:39 +0000 I thought I only removed static archives, in a quest for diskspace, arg. Not sure how to fix, might have to reinstall. Sorry. - Jay > Date: Tue, 11 Aug 2009 08:22:13 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Package build/link errors on Solaris > > Quoting Olaf Wagner : > > > There are lots of strage build/link errors on the two Solaris > > targets, see > > > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLsun/ > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/ > > > > Does anybody know offhand what's missing there? > > Bad style to answer my own posts, but I've already found it. The X > libraries are missing: > > -> archiving libm3ui.a > ld: fatal: library -lXaw: not found > ld: fatal: library -lXmu: not found > ld: fatal: library -lXext: not found > ld: fatal: library -lXt: not found > ld: fatal: library -lX11: not found > ld: fatal: File processing errors. No output written to libm3ui.so.5 > collect2: ld returned 1 exit status > make_lib => 1 > > Jay, did you remove the X installation? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Tue Aug 11 16:14:10 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 11 Aug 2009 16:14:10 +0200 Subject: [M3devel] targeting kernel instead of libc/pthreads? In-Reply-To: References: Message-ID: <1250000050.14316.15.camel@faramir.m3w.org> Your data is pretty rusty here :) pthreads as library is of course "usermode layer over something". That something being O(1) kernel space thread implementation. On Tue, 2009-08-11 at 05:37 +0000, Jay K wrote: > > In particular on Linux pthreads are usermode layer over something > else. -- Dragi?a Duri? From jay.krell at cornell.edu Tue Aug 11 16:22:23 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 11 Aug 2009 14:22:23 +0000 Subject: [M3devel] targeting kernel instead of libc/pthreads? In-Reply-To: <1250000050.14316.15.camel@faramir.m3w.org> References: <1250000050.14316.15.camel@faramir.m3w.org> Message-ID: I'm aware of that. But I don't think it matches pthreads closely, but provides sufficient primitives. It is clone and futex. I expect the kernel interfaces to be stable and there are multiple, binary incompatible?, pthreads implementations. - Jay > Subject: Re: [M3devel] targeting kernel instead of libc/pthreads? > From: dragisha at m3w.org > To: jay.krell at cornell.edu > CC: hosking at cs.purdue.edu; m3devel at elegosoft.com > Date: Tue, 11 Aug 2009 16:14:10 +0200 > > Your data is pretty rusty here :) > > pthreads as library is of course "usermode layer over something". That > something being O(1) kernel space thread implementation. > > On Tue, 2009-08-11 at 05:37 +0000, Jay K wrote: > > > > In particular on Linux pthreads are usermode layer over something > > else. > -- > Dragi?a Duri? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Tue Aug 11 16:57:59 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 11 Aug 2009 16:57:59 +0200 Subject: [M3devel] targeting kernel instead of libc/pthreads? In-Reply-To: References: <1250000050.14316.15.camel@faramir.m3w.org> Message-ID: <1250002679.14316.26.camel@faramir.m3w.org> There is exactly one pthreads implementation in use, NPTL. That is really thin layer providing pthreads API. I don't think we can afford anything by reimplementing there, but we can loose pthreads abstraction. I'we not read Anthony's implementation for some time, but I remember he had some state tracking structures resembling earlier behaviour of user-space Modula-3 threads. These are not needed,really, except for some obscure tools and for at-all-prices compatibility. I don't know if it's still there, but if it is, it imposes some non-O(1)-ness, at least in Linux case where we have it. On Tue, 2009-08-11 at 14:22 +0000, Jay K wrote: > I'm aware of that. But I don't think it matches pthreads closely, but > provides sufficient primitives. It is clone and futex. > I expect the kernel interfaces to be stable and there are multiple, > binary incompatible?, pthreads implementations. > > - Jay > > > > Subject: Re: [M3devel] targeting kernel instead of libc/pthreads? > > From: dragisha at m3w.org > > To: jay.krell at cornell.edu > > CC: hosking at cs.purdue.edu; m3devel at elegosoft.com > > Date: Tue, 11 Aug 2009 16:14:10 +0200 > > > > Your data is pretty rusty here :) > > > > pthreads as library is of course "usermode layer over something". > That > > something being O(1) kernel space thread implementation. > > > > On Tue, 2009-08-11 at 05:37 +0000, Jay K wrote: > > > > > > In particular on Linux pthreads are usermode layer over something > > > else. > > -- > > Dragi?a Duri? > > -- Dragi?a Duri? From hosking at cs.purdue.edu Tue Aug 11 17:52:30 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 11 Aug 2009 11:52:30 -0400 Subject: [M3devel] targeting kernel instead of libc/pthreads? In-Reply-To: <1250002679.14316.26.camel@faramir.m3w.org> References: <1250000050.14316.15.camel@faramir.m3w.org> <1250002679.14316.26.camel@faramir.m3w.org> Message-ID: <423DD036-8AA3-4ECE-A364-F90672F35670@cs.purdue.edu> On 11 Aug 2009, at 10:57, Dragi?a Duri? wrote: > There is exactly one pthreads implementation in use, NPTL. > > That is really thin layer providing pthreads API. > > I don't think we can afford anything by reimplementing there, but we > can > loose pthreads abstraction. Agreed, I don't see the win. > I'we not read Anthony's implementation for some time, but I remember > he > had some state tracking structures resembling earlier behaviour of > user-space Modula-3 threads. These are not needed,really, except for > some obscure tools and for at-all-prices compatibility. I don't know > if > it's still there, but if it is, it imposes some non-O(1)-ness, at > least > in Linux case where we have it. My implementation is much lighter now -- thread state information is only ever used for the signal handling needed to suspend/resume thread during GC. Otherwise, no additional accounting in the normal case. LOCK is essentially pthread_mutex_lock/unlock. As far as I recall, for purposes of notification (Alert) we still manage wait queues explicitly, mostly because the semantics of signals and threads in different pthreads implementations varies significantly (I seem to remember Dragi?a's original approach was sufficient for Linux NPTL, but not portable to other platforms). > > On Tue, 2009-08-11 at 14:22 +0000, Jay K wrote: >> I'm aware of that. But I don't think it matches pthreads closely, but >> provides sufficient primitives. It is clone and futex. >> I expect the kernel interfaces to be stable and there are multiple, >> binary incompatible?, pthreads implementations. >> >> - Jay >> >> >>> Subject: Re: [M3devel] targeting kernel instead of libc/pthreads? >>> From: dragisha at m3w.org >>> To: jay.krell at cornell.edu >>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com >>> Date: Tue, 11 Aug 2009 16:14:10 +0200 >>> >>> Your data is pretty rusty here :) >>> >>> pthreads as library is of course "usermode layer over something". >> That >>> something being O(1) kernel space thread implementation. >>> >>> On Tue, 2009-08-11 at 05:37 +0000, Jay K wrote: >>>> >>>> In particular on Linux pthreads are usermode layer over something >>>> else. >>> -- >>> Dragi?a Duri? >>> > -- > Dragi?a Duri? From dragisha at m3w.org Tue Aug 11 21:48:31 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 11 Aug 2009 21:48:31 +0200 Subject: [M3devel] targeting kernel instead of libc/pthreads? In-Reply-To: <423DD036-8AA3-4ECE-A364-F90672F35670@cs.purdue.edu> References: <1250000050.14316.15.camel@faramir.m3w.org> <1250002679.14316.26.camel@faramir.m3w.org> <423DD036-8AA3-4ECE-A364-F90672F35670@cs.purdue.edu> Message-ID: <1250020111.14316.38.camel@faramir.m3w.org> Dragi?a used trusty techniques of reading existing source code, in this case Boehm's GC and testing his approach vs. one similar implementation he was able to find and compare. It checked well, and worked flawlessly for about 4 years in many applications and esp important in one I've designed to stress test it (my DC hub sw). But it was also many yrs ago. December of 2003.... I surely did not execute my code on anything else. And I also stopped using it once you made your code available and supported. It's nice when other fullfill your dreams - mine being first class citizenship of Modula-3 on modern OS's. And that includes relying on established standards like pthreads. On Tue, 2009-08-11 at 11:52 -0400, Tony Hosking wrote: > mostly because the semantics of signals and threads in > different pthreads implementations varies significantly (I seem to > remember Dragi?a's original approach was sufficient for Linux NPTL, > but not portable to other platforms). -- Dragi?a Duri? From wagner at elegosoft.com Wed Aug 12 01:10:38 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 12 Aug 2009 01:10:38 +0200 Subject: [M3devel] CM3 Release Engineering and Feedback Message-ID: <20090812011038.n57fqtq0m8o0s8so@mail.elegosoft.com> Hi again, I can imagine that everybody is a bit tired of all the mails concerning the public release of CM3 5.8 and its problems, but nonetheless I don't want this to become a one or two man show, so I'll summarize the current status again. o RC2 has been released and publicly announced on the m3announce list and in comp.lang.modul3. There are several problems though with the packages, so that we should provide another release candidate, hopefullly at the end of this week. o There hasn't been much feedback, neither from the list of active developers nor from end users for RC2. I'd really appreciate some more reports about installation attempts and the problems encountered. o There's still the open discussion about the location and search strategy for config files where no conclusion or agreement has been reached as far as I know. o There are also still open issues about the integration of system-dependent installation archives, update/improvement/rewrite of the web presentation etc. o There are several open issues concerned with concrete test failures and installation problems that would need to be taken care of. o Documentation for non-POSIX, especially Windows systems is still lacking, too. o The Hudson infrastructure for automatic continuous build and regression testing has grown significantly (mostly due to contributions of Jay Krell) that we will be able to build almost all major target platforms for this and possibly future releases with it. I won't be able to care for all these tasks and issues alone. All help is still appreciated. It shouldn't be difficult, as everything is checked-in (sources, documents) and/or publicly accessible (WWW, Hudson, Trac). As for me, I'm going to build RC3 and the final release, and may then invest some time in reviewing and improving the distributed Hudson setup, which has been created in a rather ad-hoc fashion, because I needed tools to control the release engineering process. There are also still the Elego ComPact and DCVS M3 packages which I started to review for publishing long ago, but have never had the time and energy to finish. I won't promise anything though. I'd really enjoy if the group of active CM3 users and developers would become more engaged and agile in the discussions and open tasks and make active use of the tools and infrastructure provided (Trac, Hudson, WiKi, etc.). And if we could use all the experience and passion assembled here to inspire others and create more interest in this great language. Thanks for your support and patience, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Aug 12 02:05:46 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 12 Aug 2009 00:05:46 +0000 Subject: [M3devel] cd / on Windows Message-ID: Just a note that forward slashes work with cd, but not with pushd. I'll fix "this" "soon". ("this" being setup.cmd and its production, not that pushd doesn't with forward slashes. :) My ideal is that setup.cmd and install.sh are constant, and driven by a text file next to them, setup.txt or install.txt or such. Or possibly appeneded to them if people really like that "static linkage"). - Jay From jay.krell at cornell.edu Wed Aug 12 02:14:35 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 12 Aug 2009 00:14:35 +0000 Subject: [M3devel] targeting kernel instead of libc/pthreads? In-Reply-To: <1250002679.14316.26.camel@faramir.m3w.org> References: <1250000050.14316.15.camel@faramir.m3w.org> <1250002679.14316.26.camel@faramir.m3w.org> Message-ID: > There is exactly one pthreads implementation in use, NPTL. > That is really thin layer providing pthreads API. Is it thin? Is it really the same and binary compatible among the various C libraries -- glibc, uclibc, newlib? Same struct sizes and initializers? (I'd hope the initializers are all NULL and the structs all just the size of a pointer, but that isn't always the case.) - Jay From dragisha at m3w.org Wed Aug 12 11:16:34 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 12 Aug 2009 11:16:34 +0200 Subject: [M3devel] targeting kernel instead of libc/pthreads? In-Reply-To: References: <1250000050.14316.15.camel@faramir.m3w.org> <1250002679.14316.26.camel@faramir.m3w.org> Message-ID: <1250068594.14316.49.camel@faramir.m3w.org> I believe it is as thin as it's realistic. Ulrich Drepper is.... rigorous :) As for various libs, I don't know. I use only glibc. But we speak pthreads here.... glibc has implementation of pthreads over NPTL. pthreads structures are what we look for - Anthony used these, portable parts of glibc pthreads... If structs differ, then differing ones are not pthreads. Period. On Wed, 2009-08-12 at 00:14 +0000, Jay K wrote: > > There is exactly one pthreads implementation in use, NPTL. > > That is really thin layer providing pthreads API. > > Is it thin? > Is it really the same and binary compatible among the various C libraries -- glibc, uclibc, newlib? Same struct sizes and initializers? (I'd hope the initializers are all NULL and the structs all just the size of a pointer, but that isn't always the case.) > > - Jay -- Dragi?a Duri? From wagner at elegosoft.com Wed Aug 12 15:22:10 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 12 Aug 2009 15:22:10 +0200 Subject: [M3devel] cd / on Windows In-Reply-To: References: Message-ID: <20090812152210.fa2rrrpa80go8088@mail.elegosoft.com> Quoting Jay K : > Just a note that forward slashes work with cd, but not with pushd. > I'll fix "this" "soon". > > ("this" being setup.cmd and its production, not that pushd doesn't > with forward slashes. :) My ideal is that setup.cmd and install.sh > are constant, and driven by a text file next to them, setup.txt or > install.txt or such. Or possibly appeneded to them if people really > like that "static linkage"). Please make setup.cmd report shipping failures, too. I don't think I've done that yet. And please include your Windows-specific installation packaging into make-dist.sh if the current platform is NT386. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Wed Aug 12 21:54:10 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 12 Aug 2009 21:54:10 +0200 Subject: [M3devel] A compile-time type is missing Message-ID: <1250106850.3281.20.camel@faramir.m3w.org> Any hint on debugging this? -- Dragi?a Duri? From jay.krell at cornell.edu Wed Aug 12 22:29:15 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 12 Aug 2009 20:29:15 +0000 Subject: [M3devel] A compile-time type is missing In-Reply-To: <1250106850.3281.20.camel@faramir.m3w.org> References: <1250106850.3281.20.camel@faramir.m3w.org> Message-ID: cd scripts OMIT_GCC=yes ./do-cm3-std.sh realclean OMIT_GCC=yes ./do-cm3-std.sh buildship ? - Jay ---------------------------------------- > From: dragisha at m3w.org > To: m3devel at elegosoft.com > Date: Wed, 12 Aug 2009 21:54:10 +0200 > Subject: [M3devel] A compile-time type is missing > > Any hint on debugging this? > > -- > Dragi?a Duri? > From dragisha at m3w.org Thu Aug 13 03:09:06 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 13 Aug 2009 03:09:06 +0200 Subject: [M3devel] A compile-time type is missing In-Reply-To: References: <1250106850.3281.20.camel@faramir.m3w.org> Message-ID: <1250125746.3281.27.camel@faramir.m3w.org> It was my code.. Dynamically loaded shared lib plugins... Don't ask. Works ok now. On Wed, 2009-08-12 at 20:29 +0000, Jay K wrote: > cd scripts > OMIT_GCC=yes ./do-cm3-std.sh realclean > OMIT_GCC=yes ./do-cm3-std.sh buildship > ? > > - Jay > > > > > ---------------------------------------- > > From: dragisha at m3w.org > > To: m3devel at elegosoft.com > > Date: Wed, 12 Aug 2009 21:54:10 +0200 > > Subject: [M3devel] A compile-time type is missing > > > > Any hint on debugging this? > > > > -- > > Dragi?a Duri? > > -- Dragi?a Duri? From vapier at gentoo.org Thu Aug 13 05:29:19 2009 From: vapier at gentoo.org (Mike Frysinger) Date: Wed, 12 Aug 2009 23:29:19 -0400 Subject: [M3devel] targeting kernel instead of libc/pthreads? In-Reply-To: References: <1250002679.14316.26.camel@faramir.m3w.org> Message-ID: <200908122329.23246.vapier@gentoo.org> On Tuesday 11 August 2009 20:14:35 Jay K wrote: > > There is exactly one pthreads implementation in use, NPTL. > > That is really thin layer providing pthreads API. > > Is it thin? > Is it really the same and binary compatible among the various C libraries > -- glibc, uclibc, newlib? Same struct sizes and initializers? (I'd hope the > initializers are all NULL and the structs all just the size of a pointer, > but that isn't always the case.) you can never expect binary compatibility across C libraries. uClibc does use the NPTL source tree from glibc, but that doesnt mean it's binary compatible at either the libc or libpthread level. newlib doesnt do shared libraries, so binary compatibility is irrelevant. but i too think it's absolutely crazy to attempt to write your own threading layer on top of clone(). -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From wagner at elegosoft.com Thu Aug 13 10:51:51 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 13 Aug 2009 10:51:51 +0200 Subject: [M3devel] cm3-tst-all-pkgs failures Message-ID: <20090813105151.dlgyga1y0csgkc4k@mail.elegosoft.com> I've made a mistake this morning adding the example packages to scripts/pkginfo.txt. For reasons still to be investigated it seems that the package examples/istvan is not in the repository (at least on the branch) but the package objects is (which is missing). I just took an ls listing from one of my workspaces. As I haven't got CVS access for some time, can somebody remove the examples/istvan package from scripts/pkginfo.txt on the 5.8 release branch? Thanks in advance, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Thu Aug 13 12:47:47 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 13 Aug 2009 06:47:47 -0400 Subject: [M3devel] CM3 Release Engineering and Feedback In-Reply-To: <20090812011038.n57fqtq0m8o0s8so@mail.elegosoft.com> References: <20090812011038.n57fqtq0m8o0s8so@mail.elegosoft.com> Message-ID: <20090813104747.GA18662@topoi.pooq.com> On Wed, Aug 12, 2009 at 01:10:38AM +0200, Olaf Wagner wrote: > Hi again, > > I can imagine that everybody is a bit tired of all the mails concerning > the public release of CM3 5.8 and its problems, but nonetheless I > don't want this to become a one or two man show, so I'll summarize > the current status again. > > o RC2 has been released and publicly announced on the m3announce list > and in comp.lang.modul3. There are several problems though with the > packages, so that we should provide another release candidate, hopefullly > at the end of this week. > > o There hasn't been much feedback, neither from the list of active > developers nor from end users for RC2. I'd really appreciate some > more reports about installation attempts and the problems encountered. Well, I'll provide more with the next RC. The hudson directpry was pretty much a show-stopper. I'd expect the same problem to be there on the other platforms. -- hendrik > > o There's still the open discussion about the location and search > strategy for config files where no conclusion or agreement has > been reached as far as I know. As long as (1) it is found in a platform-standard place, and (2) there's an easy way for a user to override this via command-line parameter or environment variable, the further details probably don't matter that much. > ... > > There are also still the Elego ComPact and DCVS M3 packages which > I started to review for publishing long ago, but have never had > the time and energy to finish. I won't promise anything though. What are these DCVS packages? > > Thanks for your support and patience, You're welcome. -- hendrik From wagner at elegosoft.com Thu Aug 13 14:38:06 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 13 Aug 2009 14:38:06 +0200 Subject: [M3devel] CM3 Release Engineering and Feedback Message-ID: <20090813143806.udmpiz76ecg0scgs@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > On Wed, Aug 12, 2009 at 01:10:38AM +0200, Olaf Wagner wrote: >> o There hasn't been much feedback, neither from the list of active >> developers nor from end users for RC2. I'd really appreciate some >> more reports about installation attempts and the problems encountered. > > Well, I'll provide more with the next RC. The hudson directory was > pretty much a show-stopper. I'd expect the same problem to be there on > the other platforms. The simple work-around would be to call cm3 -build on the packages again, which should only adapt the broken .M3SHIP files. I've added a check to make-dist.sh which should prevent such accidents in the future. Probably something slightly different will then remain undetected though ;-) But never mind, I'll try to build some RC3 packages for AMD64_LINUX at least at the weekend. >> o There's still the open discussion about the location and search >> strategy for config files where no conclusion or agreement has >> been reached as far as I know. > > As long as > (1) it is found in a platform-standard place, and > (2) there's an easy way for a user to override this via command-line > parameter or environment variable, > the further details probably don't matter that much. I had the impression that there were decidedly different and contradicting opinions on that matter. Maybe I mistook that though. >> There are also still the Elego ComPact and DCVS M3 packages which >> I started to review for publishing long ago, but have never had >> the time and energy to finish. I won't promise anything though. > > What are these DCVS packages? A distributed version of CVS. It's already available, but I'd like to add some or all of the M3 packages to CM3. The distribution part is mainly based on an extended CVSup. There were more interesting features added to CVS like snapshots and changesets, too. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Thu Aug 13 14:49:12 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 13 Aug 2009 08:49:12 -0400 Subject: [M3devel] CM3 Release Engineering and Feedback In-Reply-To: <20090813143806.udmpiz76ecg0scgs@mail.elegosoft.com> References: <20090813143806.udmpiz76ecg0scgs@mail.elegosoft.com> Message-ID: <20090813124912.GA18887@topoi.pooq.com> On Thu, Aug 13, 2009 at 02:38:06PM +0200, Olaf Wagner wrote: > Quoting hendrik at topoi.pooq.com: > > >On Wed, Aug 12, 2009 at 01:10:38AM +0200, Olaf Wagner wrote: > >> o There hasn't been much feedback, neither from the list of active > >> developers nor from end users for RC2. I'd really appreciate some > >> more reports about installation attempts and the problems encountered. > > > >Well, I'll provide more with the next RC. The hudson directory was > >pretty much a show-stopper. I'd expect the same problem to be there on > >the other platforms. > > The simple work-around would be to call cm3 -build on the packages > again, which should only adapt the broken .M3SHIP files. > > I've added a check to make-dist.sh which should prevent such > accidents in the future. Probably something slightly different > will then remain undetected though ;-) > > But never mind, I'll try to build some RC3 packages for AMD64_LINUX > at least at the weekend. > > >> o There's still the open discussion about the location and search > >> strategy for config files where no conclusion or agreement has > >> been reached as far as I know. > > > >As long as > > (1) it is found in a platform-standard place, and > > (2) there's an easy way for a user to override this via command-line > >parameter or environment variable, > >the further details probably don't matter that much. > > I had the impression that there were decidedly different and > contradicting opinions on that matter. Maybe I mistook that though. There may be. But as long as what's implemented meets these criteria, I don't think further details matter as much as havein a release out. The requirement that the standard config file is in a platform-standard place will require platform-dependent code somewhere. But as long as we still put everything in /usr/local/cm3, there's not all that much to be done. Getting Modula 3 into Debian will require us to be fussy, though. But I didn't think that was teh goal for this release. > > >>There are also still the Elego ComPact and DCVS M3 packages which > >>I started to review for publishing long ago, but have never had > >>the time and energy to finish. I won't promise anything though. > > > >What are these DCVS packages? > > A distributed version of CVS. It's already available, but I'd like > to add some or all of the M3 packages to CM3. The distribution part > is mainly based on an extended CVSup. There were more interesting > features added to CVS like snapshots and changesets, too. It seems that migration to DCVS might be easier than migration to monotone or svn or ... -- hendrik From wagner at elegosoft.com Thu Aug 13 17:35:41 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 13 Aug 2009 17:35:41 +0200 Subject: [M3devel] CM3 Release Engineering and Feedback In-Reply-To: <20090813124912.GA18887@topoi.pooq.com> References: <20090813143806.udmpiz76ecg0scgs@mail.elegosoft.com> <20090813124912.GA18887@topoi.pooq.com> Message-ID: <20090813173541.782ks2dyjkg8o84s@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > On Thu, Aug 13, 2009 at 02:38:06PM +0200, Olaf Wagner wrote: >> >What are these DCVS packages? >> >> A distributed version of CVS. It's already available, but I'd like >> to add some or all of the M3 packages to CM3. The distribution part >> is mainly based on an extended CVSup. There were more interesting >> features added to CVS like snapshots and changesets, too. > > It seems that migration to DCVS might be easier than migration to > monotone or svn or ... It wasn't my intention to suggest such a migration, nor would I recommend it. I still think CVS is sufficient for our requirements, but if developers want something newer or better we should try Subversion or Perforce or indeed one of the distributed tools like git or mercurial etc. Though I don't really see the advantages of such a tool for our use. Migration would be easy though, as DCVS is only an extension of CVS, so the actual database does not need to be changed, except for the administrative data. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Fri Aug 14 01:25:42 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 13 Aug 2009 19:25:42 -0400 Subject: [M3devel] CM3 Release Engineering and Feedback In-Reply-To: <20090813173541.782ks2dyjkg8o84s@mail.elegosoft.com> References: <20090813143806.udmpiz76ecg0scgs@mail.elegosoft.com> <20090813124912.GA18887@topoi.pooq.com> <20090813173541.782ks2dyjkg8o84s@mail.elegosoft.com> Message-ID: <20090813232542.GA19898@topoi.pooq.com> On Thu, Aug 13, 2009 at 05:35:41PM +0200, Olaf Wagner wrote: > Quoting hendrik at topoi.pooq.com: > > >On Thu, Aug 13, 2009 at 02:38:06PM +0200, Olaf Wagner wrote: > >>>What are these DCVS packages? > >> > >>A distributed version of CVS. It's already available, but I'd like > >>to add some or all of the M3 packages to CM3. The distribution part > >>is mainly based on an extended CVSup. There were more interesting > >>features added to CVS like snapshots and changesets, too. > > > >It seems that migration to DCVS might be easier than migration to > >monotone or svn or ... > > It wasn't my intention to suggest such a migration, nor would I > recommend it. I still think CVS is sufficient for our requirements, > but if developers want something newer or better we should try Subversion > or Perforce or indeed one of the distributed tools like git or > mercurial etc. Though I don't really see the advantages of such > a tool for our use. If I thought CVS wsa great, I'd be using it for my own stuff. I'm not. I'm using monotone. > > Migration would be easy though, as DCVS is only an extension of CVS, > so the actual database does not need to be changed, except for the > administrative data. That's the one (and prossibly only) advantage of DVCS. -- hendrik From rcoleburn at scires.com Fri Aug 14 17:21:51 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 14 Aug 2009 11:21:51 -0400 Subject: [M3devel] something broken on Windows Message-ID: <4A8547DB.1E75.00D7.1@scires.com> Not sure what is wrong, but something is broken on Windows. I can't get anything to compile anymore after updating. Tried both my scripts and Jay's python. Both fail. Don't have time to debug right now. Here is the failure from using Jay's upgrade.py script: .... no packages left == package C:\cm3\Sandbox\cm3\m3-win\import-libs == +++ C:\cm3\bin\cm3.exe -build -DROOT=C:/cm3/Sandbox/cm3 -DCM3_VERSION_TEXT=d5. 8.2 -DCM3_VERSION_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ C:\cm3\Sandbox\cm3\m3-sys\cminstall\src\config-no-install\NT386, line 115: synta x error: missing: = (found: ) Fatal Error: package build failed *** execution of [, ] failed *** C:\cm3\Sandbox\cm3\scripts\python> Regards, Randy CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Fri Aug 14 17:27:11 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 14 Aug 2009 11:27:11 -0400 Subject: [M3devel] examples should not be in PkgInfo.txt Message-ID: <4A85491C.1E75.00D7.1@scires.com> I see that someone has put some of the examples folder packages into PkgInfo.txt std group. None of these packages in the "examples" folder should go into PkgInfo.txt. Reason is that these are examples meant to be built using CM3IDE. CM3IDE will create a package folder in the user's private repository for the example and build it there locally. We don't want to build and ship these as part of the std distribution. Only the sources are needed. The "examples" folder and its contents need to be copied to the root of your cm3 installation. That's all. Regards, Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Aug 14 18:18:38 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 14 Aug 2009 18:18:38 +0200 Subject: [M3devel] examples should not be in PkgInfo.txt In-Reply-To: <4A85491C.1E75.00D7.1@scires.com> References: <4A85491C.1E75.00D7.1@scires.com> Message-ID: <20090814181838.byoxem2jkkwww8og@mail.elegosoft.com> Quoting Randy Coleburn : > I see that someone has put some of the examples folder packages into > PkgInfo.txt std group. > > None of these packages in the "examples" folder should go into PkgInfo.txt. > > Reason is that these are examples meant to be built using CM3IDE. > CM3IDE will create a package folder in the user's private repository > for the example and build it there locally. We don't want to build > and ship these as part of the std distribution. Only the sources > are needed. The "examples" folder and its contents need to be > copied to the root of your cm3 installation. That's all. I put them there, because they were not packed into the installation archives. They can also not be build with the usual tooling at all. What's the problem with them being included in the package list? If they are only useful for cm3ide, they should probably be part of that package (i.e. moved from cm3/examples to cm3/m3-sys/cm3ide/examples). Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Aug 14 22:55:13 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 14 Aug 2009 20:55:13 +0000 Subject: [M3devel] something broken on Windows In-Reply-To: <4A8547DB.1E75.00D7.1@scires.com> References: <4A8547DB.1E75.00D7.1@scires.com> Message-ID: head or release? It's a simple quake syntax error either way. ________________________________ > Date: Fri, 14 Aug 2009 11:21:51 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: [M3devel] something broken on Windows > > > > > > > > Not sure what is wrong, but something is broken on Windows. I can't get anything to compile anymore after updating. > > > > Tried both my scripts and Jay's python. Both fail. > > > > Don't have time to debug right now. > > > > Here is the failure from using Jay's upgrade.py script: > > > > .... > > no packages left > == package C:\cm3\Sandbox\cm3\m3-win\import-libs == > > > > +++ C:\cm3\bin\cm3.exe -build -DROOT=C:/cm3/Sandbox/cm3 -DCM3_VERSION_TEXT=d5. > 8.2 -DCM3_VERSION_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ > C:\cm3\Sandbox\cm3\m3-sys\cminstall\src\config-no-install\NT386, line 115: synta > x error: missing: = (found: ) > Fatal Error: package build failed > *** execution of [,> pFunction at 0x00B599B0>] failed *** > > > > C:\cm3\Sandbox\cm3\scripts\python> > > > > Regards, > > Randy From rcoleburn at scires.com Sat Aug 15 00:11:41 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 14 Aug 2009 18:11:41 -0400 Subject: [M3devel] something broken on Windows In-Reply-To: References: <4A8547DB.1E75.00D7.1@scires.com> Message-ID: <4A85A7E8.1E75.00D7.1@scires.com> Jay: For the output below, it was taken from an XP machine that gets the HEAD branch. I did find some differences in the way it "works" by getting the release branch on a different machine (Vista). Both of these used to work, so not sure what is wrong now. Regards, Randy >>> Jay K 8/14/2009 4:55 PM >>> head or release? It's a simple quake syntax error either way. ________________________________ > Date: Fri, 14 Aug 2009 11:21:51 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: [M3devel] something broken on Windows > > > > > > > > Not sure what is wrong, but something is broken on Windows. I can't get anything to compile anymore after updating. > > > > Tried both my scripts and Jay's python. Both fail. > > > > Don't have time to debug right now. > > > > Here is the failure from using Jay's upgrade.py script: > > > > .... > > no packages left > == package C:\cm3\Sandbox\cm3\m3-win\import-libs == > > > > +++ C:\cm3\bin\cm3.exe -build -DROOT=C:/cm3/Sandbox/cm3 -DCM3_VERSION_TEXT=d5. > 8.2 -DCM3_VERSION_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ > C:\cm3\Sandbox\cm3\m3-sys\cminstall\src\config-no-install\NT386, line 115: synta > x error: missing: = (found: ) > Fatal Error: package build failed > *** execution of [,> pFunction at 0x00B599B0>] failed *** > > > > C:\cm3\Sandbox\cm3\scripts\python> > > > > Regards, > > Randy CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Aug 15 01:13:50 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 14 Aug 2009 23:13:50 +0000 Subject: [M3devel] something broken on Windows In-Reply-To: <4A85A7E8.1E75.00D7.1@scires.com> References: <4A8547DB.1E75.00D7.1@scires.com> <4A85A7E8.1E75.00D7.1@scires.com> Message-ID: Look at the file/line the error complains about: >> C:\cm3\Sandbox\cm3\m3-sys\cminstall\src\config-no-install\NT386, line 115: synta >> x error: missing: = (found: ) no mystery; fixed. - Jay ________________________________ > Date: Fri, 14 Aug 2009 18:11:41 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] something broken on Windows > > > > > > > > Jay: For the output below, it was taken from an XP machine that gets the HEAD branch. > > I did find some differences in the way it "works" by getting the release branch on a different machine (Vista). > > > > Both of these used to work, so not sure what is wrong now. > > > > Regards, > > Randy > >>>> Jay K 8/14/2009 4:55 PM>>> > > head or release? > It's a simple quake syntax error either way. > > > > > ________________________________ >> Date: Fri, 14 Aug 2009 11:21:51 -0400 >> From: rcoleburn at scires.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] something broken on Windows >> >> >> >> >> >> >> >> Not sure what is wrong, but something is broken on Windows. I can't get anything to compile anymore after updating. >> >> >> >> Tried both my scripts and Jay's python. Both fail. >> >> >> >> Don't have time to debug right now. >> >> >> >> Here is the failure from using Jay's upgrade.py script: >> >> >> >> .... >> >> no packages left >> == package C:\cm3\Sandbox\cm3\m3-win\import-libs == >> >> >> >> +++ C:\cm3\bin\cm3.exe -build -DROOT=C:/cm3/Sandbox/cm3 -DCM3_VERSION_TEXT=d5. >> 8.2 -DCM3_VERSION_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ >> C:\cm3\Sandbox\cm3\m3-sys\cminstall\src\config-no-install\NT386, line 115: synta >> x error: missing: = (found: ) >> Fatal Error: package build failed >> *** execution of [,> pFunction at 0x00B599B0>] failed *** >> >> >> >> C:\cm3\Sandbox\cm3\scripts\python> >> >> >> >> Regards, >> >> Randy From rcoleburn at scires.com Sat Aug 15 01:53:40 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 14 Aug 2009 19:53:40 -0400 Subject: [M3devel] examples should not be in PkgInfo.txt In-Reply-To: <20090814181838.byoxem2jkkwww8og@mail.elegosoft.com> References: <4A85491C.1E75.00D7.1@scires.com> <20090814181838.byoxem2jkkwww8og@mail.elegosoft.com> Message-ID: <4A85BFCE.1E75.00D7.1@scires.com> Agree that they are useful for CM3IDE. Is there a way to have CM3IDE ship this folder to the cm3 root, e.g., C:\cm3\examples, when it is built and shipped? Otherwise, user has to know to copy the folder there. This only has to be done once, so copying the folder at the time CM3IDE is built and installed seems logical. Examples folder is strictly a set of source packages. There should be no derived files there. When user browses to a particular example in CM3IDE and asks to build it, CM3IDE will create a package containing the source of the example and the derived files in the user's private repository. That way each user gets their own private copy to muck around with. Indeed, entire examples folder tree can be marked read-only without any ill-effect because of the way CM3IDE works. Regards, Randy >>> Olaf Wagner 8/14/2009 12:18 PM >>> Quoting Randy Coleburn : > I see that someone has put some of the examples folder packages into > PkgInfo.txt std group. > > None of these packages in the "examples" folder should go into PkgInfo.txt. > > Reason is that these are examples meant to be built using CM3IDE. > CM3IDE will create a package folder in the user's private repository > for the example and build it there locally. We don't want to build > and ship these as part of the std distribution. Only the sources > are needed. The "examples" folder and its contents need to be > copied to the root of your cm3 installation. That's all. I put them there, because they were not packed into the installation archives. They can also not be build with the usual tooling at all. What's the problem with them being included in the package list? If they are only useful for cm3ide, they should probably be part of that package (i.e. moved from cm3/examples to cm3/m3-sys/cm3ide/examples). Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Aug 15 06:14:38 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 15 Aug 2009 04:14:38 +0000 Subject: [M3devel] examples should not be in PkgInfo.txt In-Reply-To: <4A85BFCE.1E75.00D7.1@scires.com> References: <4A85491C.1E75.00D7.1@scires.com> <20090814181838.byoxem2jkkwww8og@mail.elegosoft.com> <4A85BFCE.1E75.00D7.1@scires.com> Message-ID: > when it is built Trivial. > when it is shipped Maybe trivial. An empty directory or with contents? If it has contents, just ship the contents. If it is empty, there may or may not be a way currently. Generally you shouldn't write anything to the installation during build, only ship. And if under the influence of overrides, you shouldn't touch the installation at all -- which falls out of not touching during build and ship isn't allowed. (but maybe for next release this whole override thing goes away -- just clone the existing install and ship to it while building, no need to ever split build from ship) You can in general do pretty arbirary things in build and ship. You are limited by the quake builtins, which are fairly substantial, what you can do by running comamnd lines which is also pretty substantial but a recurring portability hazard (Olaf write some .sh; I write some .cmd or .py; repeat), and what you add to quake, which is basically unlimited, though then a hazard regarding building with old versions, you can probe for what is there with if defined("foo") use foo end. I haven't seen that there is a good clean way to add stuff and make it trivially available either at build or ship. I was accidentally doing ship stuff at build time like with the symlinks and stuff. Some folks resort to writing into .m3ship which seems sleazy. It is the underlying mechanism, but seems maybe worth abstracting. You know -- what if it is open by cm3 and disallowing other writers or has been flushed at other than a line boundary? I think maybe better would be to have .m3ship say if exists(m3user.ship) include(m3user.ship) end or such, and then m3user.ship is where users can write to. or even simply, ship("foo") writes "foo" into .m3ship. There is an ambiguity between declarative and imperative code -- the stuff in .m3ship might be order dependent and you might not know where in the order you are. - Jay ________________________________ > Date: Fri, 14 Aug 2009 19:53:40 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] examples should not be in PkgInfo.txt > > > > > > > > Agree that they are useful for CM3IDE. > > > > Is there a way to have CM3IDE ship this folder to the cm3 root, e.g., C:\cm3\examples, when it is built and shipped? Otherwise, user has to know to copy the folder there. This only has to be done once, so copying the folder at the time CM3IDE is built and installed seems logical. > > > > Examples folder is strictly a set of source packages. There should be no derived files there. When user browses to a particular example in CM3IDE and asks to build it, CM3IDE will create a package containing the source of the example and the derived files in the user's private repository. That way each user gets their own private copy to muck around with. > > > > Indeed, entire examples folder tree can be marked read-only without any ill-effect because of the way CM3IDE works. > > > > Regards, > > Randy > >>>> Olaf Wagner 8/14/2009 12:18 PM>>> > Quoting Randy Coleburn : > >> I see that someone has put some of the examples folder packages into >> PkgInfo.txt std group. >> >> None of these packages in the "examples" folder should go into PkgInfo.txt. >> >> Reason is that these are examples meant to be built using CM3IDE. >> CM3IDE will create a package folder in the user's private repository >> for the example and build it there locally. We don't want to build >> and ship these as part of the std distribution. Only the sources >> are needed. The "examples" folder and its contents need to be >> copied to the root of your cm3 installation. That's all. > > I put them there, because they were not packed into the installation > archives. They can also not be build with the usual tooling at all. > > What's the problem with them being included in the package list? > > If they are only useful for cm3ide, they should probably be part of > that package (i.e. moved from cm3/examples to cm3/m3-sys/cm3ide/examples). > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From rcoleburn at scires.com Sat Aug 15 07:59:10 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Sat, 15 Aug 2009 01:59:10 -0400 Subject: [M3devel] examples should not be in PkgInfo.txt In-Reply-To: References: <4A85491C.1E75.00D7.1@scires.com> <20090814181838.byoxem2jkkwww8og@mail.elegosoft.com> <4A85BFCE.1E75.00D7.1@scires.com> Message-ID: <4A861576.1E75.00D7.1@scires.com> Sorry, I should be more precise. I meant when "shipped", not when "built". The examples folder is just a collection of source packages. Each source package has an HTML file that CM3IDE displays to the user as instructive information about how to use the example. The entire examples folder and its contents need to be at the root of your cm3 install, e.g., C:\cm3\examples, in order for CM3IDE to locate and use it. Of course, if one is not going to use CM3IDE, the folder isn't necessary. Thus, the thought is that when you do "cm3 -ship" on the CM3IDE package it would be good to ensure the example folder is instantiated in the cm3 tree at that time. Thus, if there is a way to do this via some extra code in the m3makefile for CM3IDE that would be fine and we could keep the examples folder as part of the CM3IDE package source tree. Regards, Randy >>> Jay K 8/15/2009 12:14 AM >>> > when it is built Trivial. > when it is shipped Maybe trivial. An empty directory or with contents? If it has contents, just ship the contents. If it is empty, there may or may not be a way currently. Generally you shouldn't write anything to the installation during build, only ship. And if under the influence of overrides, you shouldn't touch the installation at all -- which falls out of not touching during build and ship isn't allowed. (but maybe for next release this whole override thing goes away -- just clone the existing install and ship to it while building, no need to ever split build from ship) You can in general do pretty arbirary things in build and ship. You are limited by the quake builtins, which are fairly substantial, what you can do by running comamnd lines which is also pretty substantial but a recurring portability hazard (Olaf write some .sh; I write some .cmd or .py; repeat), and what you add to quake, which is basically unlimited, though then a hazard regarding building with old versions, you can probe for what is there with if defined("foo") use foo end. I haven't seen that there is a good clean way to add stuff and make it trivially available either at build or ship. I was accidentally doing ship stuff at build time like with the symlinks and stuff. Some folks resort to writing into .m3ship which seems sleazy. It is the underlying mechanism, but seems maybe worth abstracting. You know -- what if it is open by cm3 and disallowing other writers or has been flushed at other than a line boundary? I think maybe better would be to have .m3ship say if exists(m3user.ship) include(m3user.ship) end or such, and then m3user.ship is where users can write to. or even simply, ship("foo") writes "foo" into .m3ship. There is an ambiguity between declarative and imperative code -- the stuff in .m3ship might be order dependent and you might not know where in the order you are. - Jay ________________________________ > Date: Fri, 14 Aug 2009 19:53:40 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] examples should not be in PkgInfo.txt > > > > > > > > Agree that they are useful for CM3IDE. > > > > Is there a way to have CM3IDE ship this folder to the cm3 root, e.g., C:\cm3\examples, when it is built and shipped? Otherwise, user has to know to copy the folder there. This only has to be done once, so copying the folder at the time CM3IDE is built and installed seems logical. > > > > Examples folder is strictly a set of source packages. There should be no derived files there. When user browses to a particular example in CM3IDE and asks to build it, CM3IDE will create a package containing the source of the example and the derived files in the user's private repository. That way each user gets their own private copy to muck around with. > > > > Indeed, entire examples folder tree can be marked read-only without any ill-effect because of the way CM3IDE works. > > > > Regards, > > Randy > >>>> Olaf Wagner 8/14/2009 12:18 PM>>> > Quoting Randy Coleburn : > >> I see that someone has put some of the examples folder packages into >> PkgInfo.txt std group. >> >> None of these packages in the "examples" folder should go into PkgInfo.txt. >> >> Reason is that these are examples meant to be built using CM3IDE. >> CM3IDE will create a package folder in the user's private repository >> for the example and build it there locally. We don't want to build >> and ship these as part of the std distribution. Only the sources >> are needed. The "examples" folder and its contents need to be >> copied to the root of your cm3 installation. That's all. > > I put them there, because they were not packed into the installation > archives. They can also not be build with the usual tooling at all. > > What's the problem with them being included in the package list? > > If they are only useful for cm3ide, they should probably be part of > that package (i.e. moved from cm3/examples to cm3/m3-sys/cm3ide/examples). > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Aug 15 10:37:21 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 15 Aug 2009 10:37:21 +0200 Subject: [M3devel] examples should not be in PkgInfo.txt In-Reply-To: <4A861576.1E75.00D7.1@scires.com> References: <4A85491C.1E75.00D7.1@scires.com> <20090814181838.byoxem2jkkwww8og@mail.elegosoft.com> <4A85BFCE.1E75.00D7.1@scires.com> <4A861576.1E75.00D7.1@scires.com> Message-ID: <20090815103721.a5ded2wusc4ow8wk@mail.elegosoft.com> So the correct way to handle the cm3ide examples would be o mv the sources from the top of cm3 to cm3/m3-sys/cm3ide/examples (or rather cm3ide/src/exmaples?) o remove them from the pkginfo.txt file o ensure that they get shipped to INSTALL_ROOT/examples when cm3ide is installed ? I can take care of that over the weekend, or one of you can do it if you like. Just let me know. Olaf Quoting Randy Coleburn : > Sorry, I should be more precise. I meant when "shipped", not when > "built". > The examples folder is just a collection of source packages. Each > source package has an HTML file that CM3IDE displays to the user as > instructive information about how to use the example. The entire > examples folder and its contents need to be at the root of your cm3 > install, e.g., C:\cm3\examples, in order for CM3IDE to locate and use > it. Of course, if one is not going to use CM3IDE, the folder isn't > necessary. Thus, the thought is that when you do "cm3 -ship" on the > CM3IDE package it would be good to ensure the example folder is > instantiated in the cm3 tree at that time. Thus, if there is a way to > do this via some extra code in the m3makefile for CM3IDE that would be > fine and we could keep the examples folder as part of the CM3IDE package > source tree. > Regards, > Randy > >>>> Jay K 8/15/2009 12:14 AM >>> > >> when it is built > > Trivial. > >> when it is shipped > > Maybe trivial. An empty directory or with contents? > If it has contents, just ship the contents. > If it is empty, there may or may not be a way currently. > > > Generally you shouldn't write anything to the installation during > build, only ship. > And if under the influence of overrides, you shouldn't touch the > installation at all -- which falls out of not touching during build and > ship isn't allowed. > (but maybe for next release this whole override thing goes away -- just > clone the existing install and ship to it while building, no need to > ever split build from ship) > > > You can in general do pretty arbirary things in build and ship. > You are limited by the quake builtins, which are fairly substantial, > what you can do by running comamnd lines which is also pretty > substantial but a recurring portability hazard (Olaf write some .sh; I > write some .cmd or .py; repeat), and what you add to quake, which is > basically unlimited, though then a hazard regarding building with old > versions, you can probe for what is there with if defined("foo") use foo > end. > > > I haven't seen that there is a good clean way to add stuff and make it > trivially available either at build or ship. > > I was accidentally doing ship stuff at build time like with the > symlinks and stuff. > > Some folks resort to writing into .m3ship which seems sleazy. > It is the underlying mechanism, but seems maybe worth abstracting. > You know -- what if it is open by cm3 and disallowing other writers > or has been flushed at other than a line boundary? > > I think maybe better would be to have .m3ship > say if exists(m3user.ship) > include(m3user.ship) > end > > or such, and then m3user.ship is where users can write to. > > or even simply, ship("foo") writes "foo" into .m3ship. > > There is an ambiguity between declarative and imperative code -- the > stuff in .m3ship might be order dependent and you might not know where > in the order you are. > > > - Jay > > > ________________________________ >> Date: Fri, 14 Aug 2009 19:53:40 -0400 >> From: rcoleburn at scires.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] examples should not be in PkgInfo.txt >> >> >> >> >> >> >> >> Agree that they are useful for CM3IDE. >> >> >> >> Is there a way to have CM3IDE ship this folder to the cm3 root, e.g., > C:\cm3\examples, when it is built and shipped? Otherwise, user has to > know to copy the folder there. This only has to be done once, so copying > the folder at the time CM3IDE is built and installed seems logical. >> >> >> >> Examples folder is strictly a set of source packages. There should be > no derived files there. When user browses to a particular example in > CM3IDE and asks to build it, CM3IDE will create a package containing the > source of the example and the derived files in the user's private > repository. That way each user gets their own private copy to muck > around with. >> >> >> >> Indeed, entire examples folder tree can be marked read-only without > any ill-effect because of the way CM3IDE works. >> >> >> >> Regards, >> >> Randy >> >>>>> Olaf Wagner 8/14/2009 12:18 PM>>> >> Quoting Randy Coleburn : >> >>> I see that someone has put some of the examples folder packages > into >>> PkgInfo.txt std group. >>> >>> None of these packages in the "examples" folder should go into > PkgInfo.txt. >>> >>> Reason is that these are examples meant to be built using CM3IDE. >>> CM3IDE will create a package folder in the user's private > repository >>> for the example and build it there locally. We don't want to build >>> and ship these as part of the std distribution. Only the sources >>> are needed. The "examples" folder and its contents need to be >>> copied to the root of your cm3 installation. That's all. >> >> I put them there, because they were not packed into the installation >> archives. They can also not be build with the usual tooling at all. >> >> What's the problem with them being included in the package list? >> >> If they are only useful for cm3ide, they should probably be part of >> that package (i.e. moved from cm3/examples to > cm3/m3-sys/cm3ide/examples). >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 > 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 >> > > CONFIDENTIALITY NOTICE: This email and any attachments are intended > solely for the use of the named recipient(s). This e-mail may contain > confidential and/or proprietary information of Scientific Research > Corporation. If you are not a named recipient, you are prohibited from > making any use of the information in the email and attachments. If you > believe you have received this email in error, please notify the sender > immediately and permanently delete the email, any attachments, and all > copies thereof from any drives or storage media and destroy any > printouts of the email or attachments. > > EXPORT COMPLIANCE NOTICE: This email and any attachments may contain > technical data subject to U.S export restrictions under the > International Traffic in Arms Regulations (ITAR) or the Export > Administration Regulations (EAR). Export or transfer of this technical > data and/or related information to any foreign person(s) or entity(ies), > either within the U.S. or outside of the U.S., may require export > authorization by the appropriate U.S. Government agency prior to export > or transfer. In addition, technical data may not be exported or > transferred to certain countries or specified designated nationals > identified by U.S. embargo controls without prior export authorization. > By accepting this email and any attachments, all recipients confirm that > they understand and will comply with all applicable ITAR, EAR and > embargo compliance requirements. > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Sat Aug 15 12:01:42 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 15 Aug 2009 12:01:42 +0200 Subject: [M3devel] CM3 web presentation Message-ID: <20090815120142.cb14l4zj4k844004@mail.elegosoft.com> I've made some further small improvments (as I think) to the structure and look of the web pages. The green colour scheme was suggested by Peter Eiserloh. It can easily be reverted or changed again in case the majority doesn't like it. As I think it's an improvement and no other suggestions have been made so far, I took the liberty to just try it, because I haven't much time to spare for these topics besides the installation package building and testing. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sat Aug 15 14:14:53 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 15 Aug 2009 12:14:53 +0000 Subject: [M3devel] CM3 web presentation In-Reply-To: <20090815120142.cb14l4zj4k844004@mail.elegosoft.com> References: <20090815120142.cb14l4zj4k844004@mail.elegosoft.com> Message-ID: Please just use white on black or black on white. The old was ugly. Maybe I'm an old curmudgeon before my time, but all this use of color seems gratuitous. Black on white or white on black would be best imho. mostly black and white: http://gcc.gnu.org/ http://www.debian.org/ almost black and white: gray text, some orange text, white background http://www.netbsd.org/ blue text, white background: http://www.redhat.com/ some black on white, some blue on white http://news.cnet.com/ sort of black on white, and some black on gray www.apple.com blue text on white background: blue is links, lots of them, but then articles are black on white www.cnn.com If you want to be unusual I would suggest white or green on black. If you want to be normal I would suggest black on white, except links end up other, I guess blue I was taught that blue is to be avoided in general, because of its longish wave length it focuses poorly. I don't know why purple wasn't indicted the same, maybe it isn't popular? Blue IS my favorite color, but I do avoid it for this very reason. My grandmother didn't like knitting in blue for this reason. I'm amazed at the frequent occurences of blue in large swaths such as Apple and KDE desktop themes. I think PowerShell gets this wrong too. Also while super high contrast can be or seem bright, introduction of colors and shades and grays tends to imho unnecessarily reduce contract. The default Windows cmd scheme is actually gray almost white text on a black background. I change it to white. red (devil/daemon theme) http://www.freebsd.org/ - Jay > Date: Sat, 15 Aug 2009 12:01:42 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] CM3 web presentation > > I've made some further small improvments (as I think) to the > structure and look of the web pages. The green colour scheme was > suggested by Peter Eiserloh. It can easily be reverted or changed > again in case the majority doesn't like it. As I think it's an > improvement and no other suggestions have been made so far, I took > the liberty to just try it, because I haven't much time to spare > for these topics besides the installation package building and testing. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sat Aug 15 15:59:45 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sat, 15 Aug 2009 09:59:45 -0400 Subject: [M3devel] CM3 web presentation In-Reply-To: References: <20090815120142.cb14l4zj4k844004@mail.elegosoft.com> Message-ID: <20090815135945.GA24494@topoi.pooq.com> On Sat, Aug 15, 2009 at 12:14:53PM +0000, Jay K wrote: > > Please just use white on black or black on white. Colour or no colour, prefer light on dark. It's much easier for migraine sufferers. -- hendrik From wagner at elegosoft.com Sat Aug 15 20:24:16 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 15 Aug 2009 20:24:16 +0200 Subject: [M3devel] CM3 web presentation In-Reply-To: References: <20090815120142.cb14l4zj4k844004@mail.elegosoft.com> Message-ID: <20090815202416.mo45s1ftkcsssgo0@mail.elegosoft.com> Well, if someone just wants black on white or vice versa for everything, that should be easy with modern browsers (just don't allow pages to use their own colours). I also don't want to spend time on this now; so a collection of other sites with better layout and design is of no help. There was one concrete suggestion which I think is a improvement, so I tried that while doing some structural changes. I can switch back if needed. Everything else is left for people with more ambition and knowledge in graphical design. To make everyone happy concerning colours, we'll probably have to offer several schemes which can be switched via the GUI. If someone can implement that quickly, I'll happily apply it, too :-) I don't know offhand how to do that with style sheets. I'll now concentrate again on the issues for the next RC. Olaf Quoting Jay K : > Please just use white on black or black on white. > > > > > > The old was ugly. > Maybe I'm an old curmudgeon before my time, but all this use of > color seems gratuitous. > > > > > Black on white or white on black would be best imho. > > > > > mostly black and white: > http://gcc.gnu.org/ > http://www.debian.org/ > > > > > almost black and white: > gray text, some orange text, white background > http://www.netbsd.org/ > > > > > blue text, white background: > http://www.redhat.com/ > > > > > some black on white, some blue on white > http://news.cnet.com/ > > > > sort of black on white, and some black on gray > www.apple.com > > > > blue text on white background: > blue is links, lots of them, but then articles are black on white > www.cnn.com > > > > If you want to be unusual I would suggest > white or green on black. > > > > If you want to be normal I would suggest > black on white, except links end up other, I guess blue > > > > > I was taught that blue is to be avoided in general, > because of its longish wave length it focuses poorly. > I don't know why purple wasn't indicted the same, maybe > it isn't popular? Blue IS my favorite color, but I do > avoid it for this very reason. > My grandmother didn't like knitting in blue for this reason. > > > > > I'm amazed at the frequent occurences of blue in > large swaths such as Apple and KDE desktop themes. > I think PowerShell gets this wrong too. > > > > > Also while super high contrast can be or seem bright, > introduction of colors and shades and grays tends to > imho unnecessarily reduce contract. > > > > > The default Windows cmd scheme is actually gray almost > white text on a black background. I change it to white. > > > > > > red (devil/daemon theme) > http://www.freebsd.org/ > > > > > - Jay > > > >> Date: Sat, 15 Aug 2009 12:01:42 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] CM3 web presentation >> >> I've made some further small improvments (as I think) to the >> structure and look of the web pages. The green colour scheme was >> suggested by Peter Eiserloh. It can easily be reverted or changed >> again in case the majority doesn't like it. As I think it's an >> improvement and no other suggestions have been made so far, I took >> the liberty to just try it, because I haven't much time to spare >> for these topics besides the installation package building and testing. >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sun Aug 16 12:06:15 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 16 Aug 2009 10:06:15 +0000 Subject: [M3devel] more crashers Message-ID: This is head on SOLgnu: I'll try another and debug and see if fix is easy. -bash-3.00$ ./m3browser *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/String16.m3 *** -bash-3.00$ ./visobliq Internal Obliq interpreter installed... Establishing 'templates' (Created frame 'templates') let Templates = {boolean=> ... , browser=> ... , button=> ... , choice=> ... , filebrowser=> ... , form=> ... , frame=> ... , hscroll=> ... , menu=> ... , numeric=> ... , text=> ... , textedit=> ... , typein=> ... , video=> ... , vscroll=> ... } Establishing 'vowidgets' (Created frame 'vowidgets') ok Establishing 'vocheckpt' (Created frame 'vocheckpt') ok Establishing 'volib' (Created frame 'volib') Segmentation Fault (core dumped) -bash-3.00$ From wagner at elegosoft.com Sun Aug 16 14:31:14 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 16 Aug 2009 14:31:14 +0200 Subject: [M3devel] hudson suggestions In-Reply-To: References: <20090816134758.cil4twz0004cwo8g@mail.elegosoft.com> Message-ID: <20090816143114.wijmtla8000gwok8@mail.elegosoft.com> I agree copy & paste and GUI administration isn't great. But as long as I'm doing most of the release engineering from a closed network without ssh access, it's the easiest way. So please let's keep it this way until the release. As I said, I'll write up generic scripts afterwards. I won't be able to change those then during the day. (Cc'ed to m3devel as others may have the same ideas) Olaf Quoting Jay K : > > I think many jobs can be ok, setup as a pipeline, as long the > tedious gui editing is minimized. > Tedious text file editing can be not so bad. > But if they are short and usually succeed and always run in the same > sequence then maybe no point. > I can't stand when things get copied around many times and it > becomes difficult to keep them in sync where they can or should be > the same. For another example some of the m3cc tasks have "clean", > some do not. > > > I don't know if Hudson allows it easily, but e.g. there should be > just one m3cc task, assigned "sticky" to all nodes except NT386 and > then either with "sticky parameters" per-node, or the task uses the > Hudson environment variables to figure stuff out. Large that's not > even needed, due to the uname sniffing, but e.g. if there were > separate SOLsun and SOLgnu nodes or tasks, the Hudson task could set > a parameter. > > > Ok the initial cvs checkout can be non-anonymous. > And right certainly it should be minimal. > Like just get one file or just the scripts directory. > Probably should should be scripts/hudson. > > > scripts/hudson/m3cc > scripts/hudson/release-build > scripts/hudson/last-ok-build > scripts/hudson/test-install > scripts/hudson/makedist > etc. > > > preferably NOT multiplied out per target. > Whenever I see "multiplication" happening I cringe. > Sure, there is some variation but usually stuff is mostly the same > and parameters or #ifdef are imho preferred over copying.. > I understand copy/paste/edit is easier. You don't always know what > all the parameters are or how to even have any. > > Ideally there is: > scripts/hudson/install > > that takes a hostname, port number, node name, maybe CM3_TARGET > value, and sets up a node from scratch. > > Currently I don't know enough to do all this and it's much easier to > sit back and suggest it than do any of it, while I lazily continue > to edit the gui tediously... > > > > - Jay > > > ---------------------------------------- >> Date: Sun, 16 Aug 2009 13:47:58 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> Subject: Re: hudson suggestions >> >> Quoting Jay K : >> >>> two suggestions: >>> >>> 1) all tasks start with: >>> >>> echo hostname >>> hostname >>> uname -a >> >> That should be no problem, but I haven't got the infrastructure set up >> to do multiple XML edits, anyway, I only have HTTP access most of the >> times. So it can just be done incrementally for now. >> >>> or more similar >>> >>> 2) all tasks >>> just do roughly but almost exactly >>> cvs something >>> run something >> >> That's basically what most tasks do. But >> >> o CVS needs to be controlled by Hudson to be able to track the changes >> o we haven't set up generic scripts yet (I'm going to do that ASAP) >> o We don't want all tasks to check out everything, because that takes >> rather long depending on the network connections (yours are the >> best) >> >>> It can actually be anonymous cvs to get the intial code. >> Anonymous CVS asks for a password even if there is none. >> As we need ssh for reporting anyway, there's no reason not to >> use it. >> >>> They would all get the same thing generally. >>> Hudson probably sets enough environment variables -- task name -- for >>> cvs+run to then decide what to do, and what architecture on >>> multiarch systems >>> to use, based on strings in the task name. >>> >>> We can/should also check more stuff up front. >>> Like availability of cc and/or gcc, bc, gnu tar, simple C link tests >>> against -lX11, etc. >>> But first transform the tasks into cvs+run only. >>> >>> I started putting in the hostname/uname -- make sure I put nodes >>> back where you >>> expect them, but it is too tedious to go through the gui. >> >> That's all I have most of the time ;-) >> >> We also need to reduce the number of jobs; I'm thinking of >> combining the builds and the package tests. >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Sun Aug 16 19:00:22 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 16 Aug 2009 13:00:22 -0400 Subject: [M3devel] more crashers In-Reply-To: References: Message-ID: <1409BB96-A7AD-4ED1-8D91-FC3F1991F528@cs.purdue.edu> OK, these are just plain weird given that they ran just fine for me fairly recently. I am very concerned that the churn with all the recent Unix header unification has left us with a much less solid system than we used to have. If we release something that is this broken then we will not win any converts. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 16 Aug 2009, at 06:06, Jay K wrote: > > This is head on SOLgnu: > I'll try another and debug and see if fix is easy. > > -bash-3.00$ ./m3browser > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/String16.m3 > *** > > -bash-3.00$ ./visobliq > Internal Obliq interpreter installed... > Establishing 'templates' > (Created frame 'templates') > let > Templates = > {boolean=> ... , > browser=> ... , > button=> ... , > choice=> ... , > filebrowser=> ... , > form=> ... , > frame=> ... , > hscroll=> ... , > menu=> ... , > numeric=> ... , > text=> ... , > textedit=> ... , > typein=> ... , > video=> ... , > vscroll=> ... } > Establishing 'vowidgets' > (Created frame 'vowidgets') > ok > Establishing 'vocheckpt' > (Created frame 'vocheckpt') > ok > Establishing 'volib' > (Created frame 'volib') > Segmentation Fault (core dumped) > -bash-3.00$ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sun Aug 16 19:10:32 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 16 Aug 2009 13:10:32 -0400 Subject: [M3devel] CM3 Release Engineering and Feedback In-Reply-To: <20090813143806.udmpiz76ecg0scgs@mail.elegosoft.com> References: <20090813143806.udmpiz76ecg0scgs@mail.elegosoft.com> Message-ID: <20090816171032.GA27461@topoi.pooq.com> On Thu, Aug 13, 2009 at 02:38:06PM +0200, Olaf Wagner wrote: > Quoting hendrik at topoi.pooq.com: > > >On Wed, Aug 12, 2009 at 01:10:38AM +0200, Olaf Wagner wrote: > >> o There hasn't been much feedback, neither from the list of active > >> developers nor from end users for RC2. I'd really appreciate some > >> more reports about installation attempts and the problems encountered. > > > >Well, I'll provide more with the next RC. The hudson directory was > >pretty much a show-stopper. I'd expect the same problem to be there on > >the other platforms. > > The simple work-around would be to call cm3 -build on the packages > again, which should only adapt the broken .M3SHIP files. I tried that , but it failed, complaining hendrik at notlookedfor:~/cm3/RC2/gui/m3-ui$ cd cmvbt hendrik at notlookedfor:~/cm3/RC2/gui/m3-ui/cmvbt$ cm3 -build --- building in LINUXLIBC6 --- ignoring ../src/m3overrides "/home/hendrik/cm3/RC2/gui/m3-ui/cmvbt/src/m3makefile", line 3: quake runtime error: unable to open "/usr/local/cm3/pkg/ui/LINUXLIBC6/.M3EXPORTS" for reading --procedure-- -line- -file--- import -- include_dir 3 /home/hendrik/cm3/RC2/gui/m3-ui/cmvbt/src/m3makefile 4 /home/hendrik/cm3/RC2/gui/m3-ui/cmvbt/LINUXLIBC6/m3make.args Fatal Error: package build failed hendrik at notlookedfor:~/cm3/RC2/gui/m3-ui/cmvbt$ I guess I'll wait for RC3 to do further testing. Unless, of course, I've used cm3 -build wrong. In which case the workaround mentinoed on http://www.opencm3.net/releng/known-problems.html needs to be more explicit. In any case, this will be an obsolete by the time RC3 starts to roll out. So focus on that rather than fixing the workaround. -- hendrik From jay.krell at cornell.edu Sun Aug 16 21:21:14 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 16 Aug 2009 19:21:14 +0000 Subject: [M3devel] more crashers Message-ID: I see the assertion failure on PPC_LINUX too. I tried VAR defaultStackSize := 1024 * 1024; (not sure why there was any suspicion of stack size). Debugging doesn't work PPC_LINUX. jay at plin:/cm3/bin$ gdb ./cm3 GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "powerpc-linux-gnu"... break ma(gdb) break main Breakpoint 1 at 0x86fc4: file _m3main.mc, line 2. (gdb) r Starting program: /home/jay/cm3/bin/cm3 Warning: Cannot insert breakpoint 1. Error accessing memory address 0x86fc4: Input/output error. No problem with C: jay at plin:/cm3/bin$ echo "main(){}"> 1.c jay at plin:/cm3/bin$ gcc -g 1.c jay at plin:/cm3/bin$ gdb ./a.out GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "powerpc-linux-gnu"... (gdb) break main Breakpoint 1 at 0x10000448: file 1.c, line 1. (gdb) r Starting program: /home/jay/cm3/bin/a.out Breakpoint 1, main () at 1.c:1 1 main(){} (gdb) jay at plin:/cm3/bin$ gcc -gstabs+ 1.c jay at plin:/cm3/bin$ gdb ./a.out GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "powerpc-linux-gnu"... (gdb) break main Breakpoint 1 at 0x10000448: file 1.c, line 1. (gdb) r Starting program: /home/jay/cm3/bin/a.out Breakpoint 1, main () at 1.c:1 1 main(){} jay at plin:/cm3/bin$ gcc -gstabs 1.c jay at plin:/cm3/bin$ gdb ./a.out GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "powerpc-linux-gnu"... (gdb) break main Breakpoint 1 at 0x10000448: file 1.c, line 1. (gdb) r Starting program: /home/jay/cm3/bin/a.out Breakpoint 1, main () at 1.c:1 1 main(){} (gdb) - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: more crashers > Date: Sun, 16 Aug 2009 10:06:15 +0000 > > > This is head on SOLgnu: > I'll try another and debug and see if fix is easy. > > -bash-3.00$ ./m3browser > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/String16.m3 > *** > > -bash-3.00$ ./visobliq > Internal Obliq interpreter installed... > Establishing 'templates' > (Created frame 'templates') > let > Templates = > {boolean=> ... , > browser=> ... , > button=> ... , > choice=> ... , > filebrowser=> ... , > form=> ... , > frame=> ... , > hscroll=> ... , > menu=> ... , > numeric=> ... , > text=> ... , > textedit=> ... , > typein=> ... , > video=> ... , > vscroll=> ... } > Establishing 'vowidgets' > (Created frame 'vowidgets') > ok > Establishing 'vocheckpt' > (Created frame 'vocheckpt') > ok > Establishing 'volib' > (Created frame 'volib') > Segmentation Fault (core dumped) > -bash-3.00$ > From hosking at cs.purdue.edu Sun Aug 16 21:26:49 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 16 Aug 2009 15:26:49 -0400 Subject: [M3devel] more crashers In-Reply-To: References: Message-ID: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> Could this be endianness-related? On 16 Aug 2009, at 15:21, Jay K wrote: > > I see the assertion failure on PPC_LINUX too. > I tried VAR defaultStackSize := 1024 * 1024; (not sure why there was > any suspicion of stack size). > > > Debugging doesn't work PPC_LINUX. > > > jay at plin:/cm3/bin$ gdb ./cm3 > GNU gdb 6.8-debian > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show > copying" > and "show warranty" for details. > This GDB was configured as "powerpc-linux-gnu"... > break ma(gdb) break main > Breakpoint 1 at 0x86fc4: file _m3main.mc, line 2. > (gdb) r > Starting program: /home/jay/cm3/bin/cm3 > Warning: > Cannot insert breakpoint 1. > Error accessing memory address 0x86fc4: Input/output error. > > > No problem with C: > > > jay at plin:/cm3/bin$ echo "main(){}"> 1.c > jay at plin:/cm3/bin$ gcc -g 1.c > jay at plin:/cm3/bin$ gdb ./a.out > GNU gdb 6.8-debian > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show > copying" > and "show warranty" for details. > This GDB was configured as "powerpc-linux-gnu"... > (gdb) break main > Breakpoint 1 at 0x10000448: file 1.c, line 1. > (gdb) r > Starting program: /home/jay/cm3/bin/a.out > Breakpoint 1, main () at 1.c:1 > 1 main(){} > (gdb) > > > jay at plin:/cm3/bin$ gcc -gstabs+ 1.c > jay at plin:/cm3/bin$ gdb ./a.out > GNU gdb 6.8-debian > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show > copying" > and "show warranty" for details. > This GDB was configured as "powerpc-linux-gnu"... > (gdb) break main > Breakpoint 1 at 0x10000448: file 1.c, line 1. > (gdb) r > Starting program: /home/jay/cm3/bin/a.out > Breakpoint 1, main () at 1.c:1 > 1 main(){} > > > jay at plin:/cm3/bin$ gcc -gstabs 1.c > jay at plin:/cm3/bin$ gdb ./a.out > GNU gdb 6.8-debian > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show > copying" > and "show warranty" for details. > This GDB was configured as "powerpc-linux-gnu"... > (gdb) break main > Breakpoint 1 at 0x10000448: file 1.c, line 1. > (gdb) r > Starting program: /home/jay/cm3/bin/a.out > Breakpoint 1, main () at 1.c:1 > 1 main(){} > (gdb) > > > - Jay > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Subject: more crashers >> Date: Sun, 16 Aug 2009 10:06:15 +0000 >> >> >> This is head on SOLgnu: >> I'll try another and debug and see if fix is easy. >> >> -bash-3.00$ ./m3browser >> >> *** >> *** runtime error: >> *** Segmentation violation - possible attempt to dereference NIL >> *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/String16.m3 >> *** >> >> -bash-3.00$ ./visobliq >> Internal Obliq interpreter installed... >> Establishing 'templates' >> (Created frame 'templates') >> let >> Templates = >> {boolean=> ... , >> browser=> ... , >> button=> ... , >> choice=> ... , >> filebrowser=> ... , >> form=> ... , >> frame=> ... , >> hscroll=> ... , >> menu=> ... , >> numeric=> ... , >> text=> ... , >> textedit=> ... , >> typein=> ... , >> video=> ... , >> vscroll=> ... } >> Establishing 'vowidgets' >> (Created frame 'vowidgets') >> ok >> Establishing 'vocheckpt' >> (Created frame 'vocheckpt') >> ok >> Establishing 'volib' >> (Created frame 'volib') >> Segmentation Fault (core dumped) >> -bash-3.00$ >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Aug 16 21:27:03 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 16 Aug 2009 19:27:03 +0000 Subject: [M3devel] Errors building Juno on PPC_LINUX (Debian 5) Message-ID: Errors building Juno on PPC_LINUX (Debian 5) == package /home/jay/dev2/cm3/m3-ui/juno-2/juno-app == +++ /cm3/bin/cm3 -build -DROOT=/home/jay/dev2/cm3 -DCM3_VERSION_TEXT=d5.8.2 -D CM3_VERSION_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ --- building in PPC_LINUX --- ... new source -> compiling Editor.m3 ../src/Editor.m3: In function 'Editor__Parse2': ../src/Editor.m3:248: fatal error: *** bad opcode: 0x229, at m3cg_lineno 18629 compilation terminated. m3_backend => 1 m3cc (aka cm3cg) failed compiling: Editor.mc new opaque info -> recompiling Drag.m3 Drag.ms: Assembler messages: Drag.ms:3949: Error: unknown pseudo-op: `.s' assemble => 1 assembler failed assembling: Drag.ms *** execution of [, ] failed *** jay at plin:/dev2/cm3/scripts/python$ More details to follow. I'm going to rebuild m3cc clean, make sure it was built native not copied from another machine, but I think it already was native. - Jay From jay.krell at cornell.edu Sun Aug 16 21:33:34 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 16 Aug 2009 19:33:34 +0000 Subject: [M3devel] more crashers In-Reply-To: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> References: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> Message-ID: Could be. I've also seen it on PPC_DARWIN a while ago. I only recall seeing it on sparc and ppc. It doesn't always occur. Here is the m3browser crash on a system that can be debugged. See why I want the full paths in the debug info? C:\Users\jay\Desktop>\cygwin\bin\ssh xobsd. $ cd /cm3 $ cd bin $ export DISPLAY=192.168.1.120:0.0 $ gdb ./m3browser GNU gdb 6.3 This GDB was configured as "i386-unknown-openbsd4.5"... (gdb) r Starting program: /home/jay/cm3/bin/m3browser Program received signal SIGSEGV, Segmentation fault. [Switching to process 31063, thread 0x7eafe800] 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 16 t.get_info (i); (gdb) bt #0 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 #1 0x09fd9464 in ID__Add (M3_Bd56fi_x=0x0) at ../src/ID.m3:48 #2 0x1c01e644 in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:37 #3 0x0156f1bc in RTLinker__RunMainBody (M3_DjPxE3_m=0x3c003ec0) at ../src/runtime/common/RTLinker.m3:399 #4 0x0156e576 in RTLinker__AddUnitI (M3_DjPxE3_m=0x3c003ec0) at ../src/runtime/common/RTLinker.m3:113 #5 0x0156e604 in RTLinker__AddUnit (M3_DjPxE5_b=0x1c01e54d) at ../src/runtime/common/RTLinker.m3:122 #6 0x1c004676 in main (argc=1, argv=0xcfbf6a3c, envp=0xcfbf6a44) at _m3main.mc:4 - Jay ________________________________ > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Sun, 16 Aug 2009 15:26:49 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] more crashers > > Could this be endianness-related? > > On 16 Aug 2009, at 15:21, Jay K wrote: > > > I see the assertion failure on PPC_LINUX too. > I tried VAR defaultStackSize := 1024 * 1024; (not sure why there was any suspicion of stack size). > > > Debugging doesn't work PPC_LINUX. > > > jay at plin:/cm3/bin$ gdb ./cm3 > GNU gdb 6.8-debian > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "powerpc-linux-gnu"... > break ma(gdb) break main > Breakpoint 1 at 0x86fc4: file _m3main.mc, line 2. > (gdb) r > Starting program: /home/jay/cm3/bin/cm3 > Warning: > Cannot insert breakpoint 1. > Error accessing memory address 0x86fc4: Input/output error. > > > No problem with C: > > > jay at plin:/cm3/bin$ echo "main(){}"> 1.c > jay at plin:/cm3/bin$ gcc -g 1.c > jay at plin:/cm3/bin$ gdb ./a.out > GNU gdb 6.8-debian > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "powerpc-linux-gnu"... > (gdb) break main > Breakpoint 1 at 0x10000448: file 1.c, line 1. > (gdb) r > Starting program: /home/jay/cm3/bin/a.out > Breakpoint 1, main () at 1.c:1 > 1 main(){} > (gdb) > > > jay at plin:/cm3/bin$ gcc -gstabs+ 1.c > jay at plin:/cm3/bin$ gdb ./a.out > GNU gdb 6.8-debian > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "powerpc-linux-gnu"... > (gdb) break main > Breakpoint 1 at 0x10000448: file 1.c, line 1. > (gdb) r > Starting program: /home/jay/cm3/bin/a.out > Breakpoint 1, main () at 1.c:1 > 1 main(){} > > > jay at plin:/cm3/bin$ gcc -gstabs 1.c > jay at plin:/cm3/bin$ gdb ./a.out > GNU gdb 6.8-debian > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "powerpc-linux-gnu"... > (gdb) break main > Breakpoint 1 at 0x10000448: file 1.c, line 1. > (gdb) r > Starting program: /home/jay/cm3/bin/a.out > Breakpoint 1, main () at 1.c:1 > 1 main(){} > (gdb) > > > - Jay > > > ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: more crashers > Date: Sun, 16 Aug 2009 10:06:15 +0000 > > > This is head on SOLgnu: > I'll try another and debug and see if fix is easy. > > -bash-3.00$ ./m3browser > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/String16.m3 > *** > > -bash-3.00$ ./visobliq > Internal Obliq interpreter installed... > Establishing 'templates' > (Created frame 'templates') > let > Templates = > {boolean=> ... , > browser=> ... , > button=> ... , > choice=> ... , > filebrowser=> ... , > form=> ... , > frame=> ... , > hscroll=> ... , > menu=> ... , > numeric=> ... , > text=> ... , > textedit=> ... , > typein=> ... , > video=> ... , > vscroll=> ... } > Establishing 'vowidgets' > (Created frame 'vowidgets') > ok > Establishing 'vocheckpt' > (Created frame 'vocheckpt') > ok > Establishing 'volib' > (Created frame 'volib') > Segmentation Fault (core dumped) > -bash-3.00$ > > From jay.krell at cornell.edu Sun Aug 16 21:52:03 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 16 Aug 2009 19:52:03 +0000 Subject: [M3devel] more crashers In-Reply-To: References: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> Message-ID: Here is the relevant code in m3browser ID.m3: C:\dev2\cm3.2\m3-tools\m3markup\src\ID.m3(38): empty_id := Add (""); empty_id := Add (""); (*-------------------------------------------------------------- exported ---*) PROCEDURE Add (x: TEXT): T = VAR t: T; a: REF ARRAY OF CHAR; l: INTEGER; BEGIN l := Text.Length(x); ... END Add; The empty string constant ends up as null. .stabn 68,0,38,.LM115-.LFBB10 .LM115: movl L_1 at GOT(%ebx), %eax leal 24(%eax), %eax movl %eax, (%esp) call ID__Add at PLT movl %eax, -8(%ebp) movl -8(%ebp), %ecx movl MM_ID at GOT(%ebx), %edx movl 248(%edx), %eax andl $0, %eax orl %ecx, %eax movl %eax, 248(%edx) .L136: movl MM_ID at GOT(%ebx), %eax .LBE16: addl $52, %esp popl %ebx popl %ebp ret L_1: 0 .long RTHooks__TextLitInfo 4 .long RTHooks__TextLitGetChar 8 .long RTHooks__TextLitGetWideChar 12 .long RTHooks__TextLitGetChars 16 .long RTHooks__TextLitGetWideChars 20 .long 2 24 .long L_1 .long 0 .zero 4 .ascii "ID_M3" .zero 1 .ascii "ExpandHashTable" .zero 1 .ascii "ExpandIDs" .zero 1 .ascii "ExpandChars" .zero 1 .ascii "Compare" .zero 1 If I change "" to "foo", I get: L_1: 0 .long RTHooks__TextLitInfo 4 .long RTHooks__TextLitGetChar 8 .long RTHooks__TextLitGetWideChar 12 .long RTHooks__TextLitGetChars 16 .long RTHooks__TextLitGetWideChars 20 .long 2 24 .long L_1 .long 3 .ascii "foo" .zero 1 .ascii "ID_M3" and it still crashes. It seems to hit ID__Add twice when only once would be expected. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Sun, 16 Aug 2009 19:33:34 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] more crashers > > > Could be. I've also seen it on PPC_DARWIN a while ago. I only recall seeing it on sparc and ppc. > It doesn't always occur. > > > Here is the m3browser crash on a system that can be debugged. > See why I want the full paths in the debug info? > > > C:\Users\jay\Desktop>\cygwin\bin\ssh xobsd. > $ cd /cm3 > $ cd bin > $ export DISPLAY=192.168.1.120:0.0 > $ gdb ./m3browser > GNU gdb 6.3 > This GDB was configured as "i386-unknown-openbsd4.5"... > (gdb) r > Starting program: /home/jay/cm3/bin/m3browser > Program received signal SIGSEGV, Segmentation fault. > [Switching to process 31063, thread 0x7eafe800] > 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 > 16 t.get_info (i); > (gdb) bt > #0 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 > #1 0x09fd9464 in ID__Add (M3_Bd56fi_x=0x0) at ../src/ID.m3:48 > #2 0x1c01e644 in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:37 > #3 0x0156f1bc in RTLinker__RunMainBody (M3_DjPxE3_m=0x3c003ec0) > at ../src/runtime/common/RTLinker.m3:399 > #4 0x0156e576 in RTLinker__AddUnitI (M3_DjPxE3_m=0x3c003ec0) > at ../src/runtime/common/RTLinker.m3:113 > #5 0x0156e604 in RTLinker__AddUnit (M3_DjPxE5_b=0x1c01e54d) > at ../src/runtime/common/RTLinker.m3:122 > #6 0x1c004676 in main (argc=1, argv=0xcfbf6a3c, envp=0xcfbf6a44) > at _m3main.mc:4 > > > - Jay > > > ________________________________ >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Sun, 16 Aug 2009 15:26:49 -0400 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] more crashers >> >> Could this be endianness-related? >> >> On 16 Aug 2009, at 15:21, Jay K wrote: >> >> >> I see the assertion failure on PPC_LINUX too. >> I tried VAR defaultStackSize := 1024 * 1024; (not sure why there was any suspicion of stack size). >> >> >> Debugging doesn't work PPC_LINUX. >> >> >> jay at plin:/cm3/bin$ gdb ./cm3 >> GNU gdb 6.8-debian >> Copyright (C) 2008 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >> and "show warranty" for details. >> This GDB was configured as "powerpc-linux-gnu"... >> break ma(gdb) break main >> Breakpoint 1 at 0x86fc4: file _m3main.mc, line 2. >> (gdb) r >> Starting program: /home/jay/cm3/bin/cm3 >> Warning: >> Cannot insert breakpoint 1. >> Error accessing memory address 0x86fc4: Input/output error. >> >> >> No problem with C: >> >> >> jay at plin:/cm3/bin$ echo "main(){}"> 1.c >> jay at plin:/cm3/bin$ gcc -g 1.c >> jay at plin:/cm3/bin$ gdb ./a.out >> GNU gdb 6.8-debian >> Copyright (C) 2008 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >> and "show warranty" for details. >> This GDB was configured as "powerpc-linux-gnu"... >> (gdb) break main >> Breakpoint 1 at 0x10000448: file 1.c, line 1. >> (gdb) r >> Starting program: /home/jay/cm3/bin/a.out >> Breakpoint 1, main () at 1.c:1 >> 1 main(){} >> (gdb) >> >> >> jay at plin:/cm3/bin$ gcc -gstabs+ 1.c >> jay at plin:/cm3/bin$ gdb ./a.out >> GNU gdb 6.8-debian >> Copyright (C) 2008 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >> and "show warranty" for details. >> This GDB was configured as "powerpc-linux-gnu"... >> (gdb) break main >> Breakpoint 1 at 0x10000448: file 1.c, line 1. >> (gdb) r >> Starting program: /home/jay/cm3/bin/a.out >> Breakpoint 1, main () at 1.c:1 >> 1 main(){} >> >> >> jay at plin:/cm3/bin$ gcc -gstabs 1.c >> jay at plin:/cm3/bin$ gdb ./a.out >> GNU gdb 6.8-debian >> Copyright (C) 2008 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >> and "show warranty" for details. >> This GDB was configured as "powerpc-linux-gnu"... >> (gdb) break main >> Breakpoint 1 at 0x10000448: file 1.c, line 1. >> (gdb) r >> Starting program: /home/jay/cm3/bin/a.out >> Breakpoint 1, main () at 1.c:1 >> 1 main(){} >> (gdb) >> >> >> - Jay >> >> >> ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Subject: more crashers >> Date: Sun, 16 Aug 2009 10:06:15 +0000 >> >> >> This is head on SOLgnu: >> I'll try another and debug and see if fix is easy. >> >> -bash-3.00$ ./m3browser >> >> *** >> *** runtime error: >> *** Segmentation violation - possible attempt to dereference NIL >> *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/String16.m3 >> *** >> >> -bash-3.00$ ./visobliq >> Internal Obliq interpreter installed... >> Establishing 'templates' >> (Created frame 'templates') >> let >> Templates = >> {boolean=> ... , >> browser=> ... , >> button=> ... , >> choice=> ... , >> filebrowser=> ... , >> form=> ... , >> frame=> ... , >> hscroll=> ... , >> menu=> ... , >> numeric=> ... , >> text=> ... , >> textedit=> ... , >> typein=> ... , >> video=> ... , >> vscroll=> ... } >> Establishing 'vowidgets' >> (Created frame 'vowidgets') >> ok >> Establishing 'vocheckpt' >> (Created frame 'vocheckpt') >> ok >> Establishing 'volib' >> (Created frame 'volib') >> Segmentation Fault (core dumped) >> -bash-3.00$ >> >> From jay.krell at cornell.edu Sun Aug 16 22:22:49 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 16 Aug 2009 20:22:49 +0000 Subject: [M3devel] more crashers In-Reply-To: References: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> Message-ID: sorry, this is simple. derived_dirs := IntList.List1 (ID.Add (MxConfig.Get("BUILD_DIR"))); - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Sun, 16 Aug 2009 19:52:03 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] more crashers > > > Here is the relevant code in m3browser ID.m3: > > > C:\dev2\cm3.2\m3-tools\m3markup\src\ID.m3(38): empty_id := Add (""); > > empty_id := Add (""); > > (*-------------------------------------------------------------- exported ---*) > PROCEDURE Add (x: TEXT): T = > VAR > t: T; > a: REF ARRAY OF CHAR; > l: INTEGER; > BEGIN > l := Text.Length(x); > ... > END Add; > > > The empty string constant ends up as null. > > .stabn 68,0,38,.LM115-.LFBB10 > .LM115: > movl L_1 at GOT(%ebx), %eax > leal 24(%eax), %eax > movl %eax, (%esp) > call ID__Add at PLT > movl %eax, -8(%ebp) > movl -8(%ebp), %ecx > movl MM_ID at GOT(%ebx), %edx > movl 248(%edx), %eax > andl $0, %eax > orl %ecx, %eax > movl %eax, 248(%edx) > .L136: > movl MM_ID at GOT(%ebx), %eax > .LBE16: > addl $52, %esp > popl %ebx > popl %ebp > ret > > L_1: > 0 .long RTHooks__TextLitInfo > 4 .long RTHooks__TextLitGetChar > 8 .long RTHooks__TextLitGetWideChar > 12 .long RTHooks__TextLitGetChars > 16 .long RTHooks__TextLitGetWideChars > 20 .long 2 > 24 .long L_1 > .long 0 > .zero 4 > .ascii "ID_M3" > .zero 1 > .ascii "ExpandHashTable" > .zero 1 > .ascii "ExpandIDs" > .zero 1 > .ascii "ExpandChars" > .zero 1 > .ascii "Compare" > .zero 1 > > If I change "" to "foo", I get: > > L_1: > 0 .long RTHooks__TextLitInfo > 4 .long RTHooks__TextLitGetChar > 8 .long RTHooks__TextLitGetWideChar > 12 .long RTHooks__TextLitGetChars > 16 .long RTHooks__TextLitGetWideChars > 20 .long 2 > 24 .long L_1 > .long 3 > .ascii "foo" > .zero 1 > .ascii "ID_M3" > > and it still crashes. > > > It seems to hit ID__Add twice when only once would be expected. > > > - Jay > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> Date: Sun, 16 Aug 2009 19:33:34 +0000 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] more crashers >> >> >> Could be. I've also seen it on PPC_DARWIN a while ago. I only recall seeing it on sparc and ppc. >> It doesn't always occur. >> >> >> Here is the m3browser crash on a system that can be debugged. >> See why I want the full paths in the debug info? >> >> >> C:\Users\jay\Desktop>\cygwin\bin\ssh xobsd. >> $ cd /cm3 >> $ cd bin >> $ export DISPLAY=192.168.1.120:0.0 >> $ gdb ./m3browser >> GNU gdb 6.3 >> This GDB was configured as "i386-unknown-openbsd4.5"... >> (gdb) r >> Starting program: /home/jay/cm3/bin/m3browser >> Program received signal SIGSEGV, Segmentation fault. >> [Switching to process 31063, thread 0x7eafe800] >> 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 >> 16 t.get_info (i); >> (gdb) bt >> #0 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 >> #1 0x09fd9464 in ID__Add (M3_Bd56fi_x=0x0) at ../src/ID.m3:48 >> #2 0x1c01e644 in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:37 >> #3 0x0156f1bc in RTLinker__RunMainBody (M3_DjPxE3_m=0x3c003ec0) >> at ../src/runtime/common/RTLinker.m3:399 >> #4 0x0156e576 in RTLinker__AddUnitI (M3_DjPxE3_m=0x3c003ec0) >> at ../src/runtime/common/RTLinker.m3:113 >> #5 0x0156e604 in RTLinker__AddUnit (M3_DjPxE5_b=0x1c01e54d) >> at ../src/runtime/common/RTLinker.m3:122 >> #6 0x1c004676 in main (argc=1, argv=0xcfbf6a3c, envp=0xcfbf6a44) >> at _m3main.mc:4 >> >> >> - Jay >> >> >> ________________________________ >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Date: Sun, 16 Aug 2009 15:26:49 -0400 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] more crashers >>> >>> Could this be endianness-related? >>> >>> On 16 Aug 2009, at 15:21, Jay K wrote: >>> >>> >>> I see the assertion failure on PPC_LINUX too. >>> I tried VAR defaultStackSize := 1024 * 1024; (not sure why there was any suspicion of stack size). >>> >>> >>> Debugging doesn't work PPC_LINUX. >>> >>> >>> jay at plin:/cm3/bin$ gdb ./cm3 >>> GNU gdb 6.8-debian >>> Copyright (C) 2008 Free Software Foundation, Inc. >>> License GPLv3+: GNU GPL version 3 or later >>> This is free software: you are free to change and redistribute it. >>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >>> and "show warranty" for details. >>> This GDB was configured as "powerpc-linux-gnu"... >>> break ma(gdb) break main >>> Breakpoint 1 at 0x86fc4: file _m3main.mc, line 2. >>> (gdb) r >>> Starting program: /home/jay/cm3/bin/cm3 >>> Warning: >>> Cannot insert breakpoint 1. >>> Error accessing memory address 0x86fc4: Input/output error. >>> >>> >>> No problem with C: >>> >>> >>> jay at plin:/cm3/bin$ echo "main(){}"> 1.c >>> jay at plin:/cm3/bin$ gcc -g 1.c >>> jay at plin:/cm3/bin$ gdb ./a.out >>> GNU gdb 6.8-debian >>> Copyright (C) 2008 Free Software Foundation, Inc. >>> License GPLv3+: GNU GPL version 3 or later >>> This is free software: you are free to change and redistribute it. >>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >>> and "show warranty" for details. >>> This GDB was configured as "powerpc-linux-gnu"... >>> (gdb) break main >>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>> (gdb) r >>> Starting program: /home/jay/cm3/bin/a.out >>> Breakpoint 1, main () at 1.c:1 >>> 1 main(){} >>> (gdb) >>> >>> >>> jay at plin:/cm3/bin$ gcc -gstabs+ 1.c >>> jay at plin:/cm3/bin$ gdb ./a.out >>> GNU gdb 6.8-debian >>> Copyright (C) 2008 Free Software Foundation, Inc. >>> License GPLv3+: GNU GPL version 3 or later >>> This is free software: you are free to change and redistribute it. >>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >>> and "show warranty" for details. >>> This GDB was configured as "powerpc-linux-gnu"... >>> (gdb) break main >>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>> (gdb) r >>> Starting program: /home/jay/cm3/bin/a.out >>> Breakpoint 1, main () at 1.c:1 >>> 1 main(){} >>> >>> >>> jay at plin:/cm3/bin$ gcc -gstabs 1.c >>> jay at plin:/cm3/bin$ gdb ./a.out >>> GNU gdb 6.8-debian >>> Copyright (C) 2008 Free Software Foundation, Inc. >>> License GPLv3+: GNU GPL version 3 or later >>> This is free software: you are free to change and redistribute it. >>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >>> and "show warranty" for details. >>> This GDB was configured as "powerpc-linux-gnu"... >>> (gdb) break main >>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>> (gdb) r >>> Starting program: /home/jay/cm3/bin/a.out >>> Breakpoint 1, main () at 1.c:1 >>> 1 main(){} >>> (gdb) >>> >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: m3devel at elegosoft.com >>> Subject: more crashers >>> Date: Sun, 16 Aug 2009 10:06:15 +0000 >>> >>> >>> This is head on SOLgnu: >>> I'll try another and debug and see if fix is easy. >>> >>> -bash-3.00$ ./m3browser >>> >>> *** >>> *** runtime error: >>> *** Segmentation violation - possible attempt to dereference NIL >>> *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/String16.m3 >>> *** >>> >>> -bash-3.00$ ./visobliq >>> Internal Obliq interpreter installed... >>> Establishing 'templates' >>> (Created frame 'templates') >>> let >>> Templates = >>> {boolean=> ... , >>> browser=> ... , >>> button=> ... , >>> choice=> ... , >>> filebrowser=> ... , >>> form=> ... , >>> frame=> ... , >>> hscroll=> ... , >>> menu=> ... , >>> numeric=> ... , >>> text=> ... , >>> textedit=> ... , >>> typein=> ... , >>> video=> ... , >>> vscroll=> ... } >>> Establishing 'vowidgets' >>> (Created frame 'vowidgets') >>> ok >>> Establishing 'vocheckpt' >>> (Created frame 'vocheckpt') >>> ok >>> Establishing 'volib' >>> (Created frame 'volib') >>> Segmentation Fault (core dumped) >>> -bash-3.00$ >>> >>> From jay.krell at cornell.edu Sun Aug 16 22:32:31 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 16 Aug 2009 20:32:31 +0000 Subject: [M3devel] more crashers In-Reply-To: References: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> Message-ID: m3browser: It is specific to my config file m3-sys/cminstall/src/config-no-install/cm3.cfg that reachs back into the source tree. It won't happen with what most people do. I have to do that M3Predefines or such work so that all the uses of m3quake besides cm3 are much more like cm3. visobliq: not the same thing Does not occur on Linux/x86 or Linux/sparc. They do print Syntax error just before: -helvetica-bold-\*R-\*240-\*\") (LabelFo ... ill-formed character escape sequence Error detected (file file generated by Visual Obliq) (line 18, char 10) VideoVBT.Start Jv ServerFailure:errno=0 but then gui comes up. I'll have to finish my Solaris reinstall and get dbx. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Sun, 16 Aug 2009 20:22:49 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] more crashers > > > sorry, this is simple. > > derived_dirs := IntList.List1 (ID.Add (MxConfig.Get("BUILD_DIR"))); > > > - Jay > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> Date: Sun, 16 Aug 2009 19:52:03 +0000 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] more crashers >> >> >> Here is the relevant code in m3browser ID.m3: >> >> >> C:\dev2\cm3.2\m3-tools\m3markup\src\ID.m3(38): empty_id := Add (""); >> >> empty_id := Add (""); >> >> (*-------------------------------------------------------------- exported ---*) >> PROCEDURE Add (x: TEXT): T = >> VAR >> t: T; >> a: REF ARRAY OF CHAR; >> l: INTEGER; >> BEGIN >> l := Text.Length(x); >> ... >> END Add; >> >> >> The empty string constant ends up as null. >> >> .stabn 68,0,38,.LM115-.LFBB10 >> .LM115: >> movl L_1 at GOT(%ebx), %eax >> leal 24(%eax), %eax >> movl %eax, (%esp) >> call ID__Add at PLT >> movl %eax, -8(%ebp) >> movl -8(%ebp), %ecx >> movl MM_ID at GOT(%ebx), %edx >> movl 248(%edx), %eax >> andl $0, %eax >> orl %ecx, %eax >> movl %eax, 248(%edx) >> .L136: >> movl MM_ID at GOT(%ebx), %eax >> .LBE16: >> addl $52, %esp >> popl %ebx >> popl %ebp >> ret >> >> L_1: >> 0 .long RTHooks__TextLitInfo >> 4 .long RTHooks__TextLitGetChar >> 8 .long RTHooks__TextLitGetWideChar >> 12 .long RTHooks__TextLitGetChars >> 16 .long RTHooks__TextLitGetWideChars >> 20 .long 2 >> 24 .long L_1 >> .long 0 >> .zero 4 >> .ascii "ID_M3" >> .zero 1 >> .ascii "ExpandHashTable" >> .zero 1 >> .ascii "ExpandIDs" >> .zero 1 >> .ascii "ExpandChars" >> .zero 1 >> .ascii "Compare" >> .zero 1 >> >> If I change "" to "foo", I get: >> >> L_1: >> 0 .long RTHooks__TextLitInfo >> 4 .long RTHooks__TextLitGetChar >> 8 .long RTHooks__TextLitGetWideChar >> 12 .long RTHooks__TextLitGetChars >> 16 .long RTHooks__TextLitGetWideChars >> 20 .long 2 >> 24 .long L_1 >> .long 3 >> .ascii "foo" >> .zero 1 >> .ascii "ID_M3" >> >> and it still crashes. >> >> >> It seems to hit ID__Add twice when only once would be expected. >> >> >> - Jay >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu >>> Date: Sun, 16 Aug 2009 19:33:34 +0000 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] more crashers >>> >>> >>> Could be. I've also seen it on PPC_DARWIN a while ago. I only recall seeing it on sparc and ppc. >>> It doesn't always occur. >>> >>> >>> Here is the m3browser crash on a system that can be debugged. >>> See why I want the full paths in the debug info? >>> >>> >>> C:\Users\jay\Desktop>\cygwin\bin\ssh xobsd. >>> $ cd /cm3 >>> $ cd bin >>> $ export DISPLAY=192.168.1.120:0.0 >>> $ gdb ./m3browser >>> GNU gdb 6.3 >>> This GDB was configured as "i386-unknown-openbsd4.5"... >>> (gdb) r >>> Starting program: /home/jay/cm3/bin/m3browser >>> Program received signal SIGSEGV, Segmentation fault. >>> [Switching to process 31063, thread 0x7eafe800] >>> 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 >>> 16 t.get_info (i); >>> (gdb) bt >>> #0 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 >>> #1 0x09fd9464 in ID__Add (M3_Bd56fi_x=0x0) at ../src/ID.m3:48 >>> #2 0x1c01e644 in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:37 >>> #3 0x0156f1bc in RTLinker__RunMainBody (M3_DjPxE3_m=0x3c003ec0) >>> at ../src/runtime/common/RTLinker.m3:399 >>> #4 0x0156e576 in RTLinker__AddUnitI (M3_DjPxE3_m=0x3c003ec0) >>> at ../src/runtime/common/RTLinker.m3:113 >>> #5 0x0156e604 in RTLinker__AddUnit (M3_DjPxE5_b=0x1c01e54d) >>> at ../src/runtime/common/RTLinker.m3:122 >>> #6 0x1c004676 in main (argc=1, argv=0xcfbf6a3c, envp=0xcfbf6a44) >>> at _m3main.mc:4 >>> >>> >>> - Jay >>> >>> >>> ________________________________ >>>> From: hosking at cs.purdue.edu >>>> To: jay.krell at cornell.edu >>>> Date: Sun, 16 Aug 2009 15:26:49 -0400 >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] more crashers >>>> >>>> Could this be endianness-related? >>>> >>>> On 16 Aug 2009, at 15:21, Jay K wrote: >>>> >>>> >>>> I see the assertion failure on PPC_LINUX too. >>>> I tried VAR defaultStackSize := 1024 * 1024; (not sure why there was any suspicion of stack size). >>>> >>>> >>>> Debugging doesn't work PPC_LINUX. >>>> >>>> >>>> jay at plin:/cm3/bin$ gdb ./cm3 >>>> GNU gdb 6.8-debian >>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>> License GPLv3+: GNU GPL version 3 or later >>>> This is free software: you are free to change and redistribute it. >>>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >>>> and "show warranty" for details. >>>> This GDB was configured as "powerpc-linux-gnu"... >>>> break ma(gdb) break main >>>> Breakpoint 1 at 0x86fc4: file _m3main.mc, line 2. >>>> (gdb) r >>>> Starting program: /home/jay/cm3/bin/cm3 >>>> Warning: >>>> Cannot insert breakpoint 1. >>>> Error accessing memory address 0x86fc4: Input/output error. >>>> >>>> >>>> No problem with C: >>>> >>>> >>>> jay at plin:/cm3/bin$ echo "main(){}"> 1.c >>>> jay at plin:/cm3/bin$ gcc -g 1.c >>>> jay at plin:/cm3/bin$ gdb ./a.out >>>> GNU gdb 6.8-debian >>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>> License GPLv3+: GNU GPL version 3 or later >>>> This is free software: you are free to change and redistribute it. >>>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >>>> and "show warranty" for details. >>>> This GDB was configured as "powerpc-linux-gnu"... >>>> (gdb) break main >>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>> (gdb) r >>>> Starting program: /home/jay/cm3/bin/a.out >>>> Breakpoint 1, main () at 1.c:1 >>>> 1 main(){} >>>> (gdb) >>>> >>>> >>>> jay at plin:/cm3/bin$ gcc -gstabs+ 1.c >>>> jay at plin:/cm3/bin$ gdb ./a.out >>>> GNU gdb 6.8-debian >>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>> License GPLv3+: GNU GPL version 3 or later >>>> This is free software: you are free to change and redistribute it. >>>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >>>> and "show warranty" for details. >>>> This GDB was configured as "powerpc-linux-gnu"... >>>> (gdb) break main >>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>> (gdb) r >>>> Starting program: /home/jay/cm3/bin/a.out >>>> Breakpoint 1, main () at 1.c:1 >>>> 1 main(){} >>>> >>>> >>>> jay at plin:/cm3/bin$ gcc -gstabs 1.c >>>> jay at plin:/cm3/bin$ gdb ./a.out >>>> GNU gdb 6.8-debian >>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>> License GPLv3+: GNU GPL version 3 or later >>>> This is free software: you are free to change and redistribute it. >>>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >>>> and "show warranty" for details. >>>> This GDB was configured as "powerpc-linux-gnu"... >>>> (gdb) break main >>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>> (gdb) r >>>> Starting program: /home/jay/cm3/bin/a.out >>>> Breakpoint 1, main () at 1.c:1 >>>> 1 main(){} >>>> (gdb) >>>> >>>> >>>> - Jay >>>> >>>> >>>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: m3devel at elegosoft.com >>>> Subject: more crashers >>>> Date: Sun, 16 Aug 2009 10:06:15 +0000 >>>> >>>> >>>> This is head on SOLgnu: >>>> I'll try another and debug and see if fix is easy. >>>> >>>> -bash-3.00$ ./m3browser >>>> >>>> *** >>>> *** runtime error: >>>> *** Segmentation violation - possible attempt to dereference NIL >>>> *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/String16.m3 >>>> *** >>>> >>>> -bash-3.00$ ./visobliq >>>> Internal Obliq interpreter installed... >>>> Establishing 'templates' >>>> (Created frame 'templates') >>>> let >>>> Templates = >>>> {boolean=> ... , >>>> browser=> ... , >>>> button=> ... , >>>> choice=> ... , >>>> filebrowser=> ... , >>>> form=> ... , >>>> frame=> ... , >>>> hscroll=> ... , >>>> menu=> ... , >>>> numeric=> ... , >>>> text=> ... , >>>> textedit=> ... , >>>> typein=> ... , >>>> video=> ... , >>>> vscroll=> ... } >>>> Establishing 'vowidgets' >>>> (Created frame 'vowidgets') >>>> ok >>>> Establishing 'vocheckpt' >>>> (Created frame 'vocheckpt') >>>> ok >>>> Establishing 'volib' >>>> (Created frame 'volib') >>>> Segmentation Fault (core dumped) >>>> -bash-3.00$ >>>> >>>> From hosking at cs.purdue.edu Mon Aug 17 01:10:15 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 16 Aug 2009 19:10:15 -0400 Subject: [M3devel] more crashers In-Reply-To: References: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> Message-ID: So now I am worried about the recent changes to Text... On 16 Aug 2009, at 15:33, Jay K wrote: > > Could be. I've also seen it on PPC_DARWIN a while ago. I only recall > seeing it on sparc and ppc. > It doesn't always occur. > > > Here is the m3browser crash on a system that can be debugged. > See why I want the full paths in the debug info? > > > C:\Users\jay\Desktop>\cygwin\bin\ssh xobsd. > $ cd /cm3 > $ cd bin > $ export DISPLAY=192.168.1.120:0.0 > $ gdb ./m3browser > GNU gdb 6.3 > This GDB was configured as "i386-unknown-openbsd4.5"... > (gdb) r > Starting program: /home/jay/cm3/bin/m3browser > Program received signal SIGSEGV, Segmentation fault. > [Switching to process 31063, thread 0x7eafe800] > 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 > 16 t.get_info (i); > (gdb) bt > #0 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/ > Text.m3:16 > #1 0x09fd9464 in ID__Add (M3_Bd56fi_x=0x0) at ../src/ID.m3:48 > #2 0x1c01e644 in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:37 > #3 0x0156f1bc in RTLinker__RunMainBody (M3_DjPxE3_m=0x3c003ec0) > at ../src/runtime/common/RTLinker.m3:399 > #4 0x0156e576 in RTLinker__AddUnitI (M3_DjPxE3_m=0x3c003ec0) > at ../src/runtime/common/RTLinker.m3:113 > #5 0x0156e604 in RTLinker__AddUnit (M3_DjPxE5_b=0x1c01e54d) > at ../src/runtime/common/RTLinker.m3:122 > #6 0x1c004676 in main (argc=1, argv=0xcfbf6a3c, envp=0xcfbf6a44) > at _m3main.mc:4 > > > - Jay > > > ________________________________ >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Sun, 16 Aug 2009 15:26:49 -0400 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] more crashers >> >> Could this be endianness-related? >> >> On 16 Aug 2009, at 15:21, Jay K wrote: >> >> >> I see the assertion failure on PPC_LINUX too. >> I tried VAR defaultStackSize := 1024 * 1024; (not sure why there >> was any suspicion of stack size). >> >> >> Debugging doesn't work PPC_LINUX. >> >> >> jay at plin:/cm3/bin$ gdb ./cm3 >> GNU gdb 6.8-debian >> Copyright (C) 2008 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. Type "show >> copying" >> and "show warranty" for details. >> This GDB was configured as "powerpc-linux-gnu"... >> break ma(gdb) break main >> Breakpoint 1 at 0x86fc4: file _m3main.mc, line 2. >> (gdb) r >> Starting program: /home/jay/cm3/bin/cm3 >> Warning: >> Cannot insert breakpoint 1. >> Error accessing memory address 0x86fc4: Input/output error. >> >> >> No problem with C: >> >> >> jay at plin:/cm3/bin$ echo "main(){}"> 1.c >> jay at plin:/cm3/bin$ gcc -g 1.c >> jay at plin:/cm3/bin$ gdb ./a.out >> GNU gdb 6.8-debian >> Copyright (C) 2008 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. Type "show >> copying" >> and "show warranty" for details. >> This GDB was configured as "powerpc-linux-gnu"... >> (gdb) break main >> Breakpoint 1 at 0x10000448: file 1.c, line 1. >> (gdb) r >> Starting program: /home/jay/cm3/bin/a.out >> Breakpoint 1, main () at 1.c:1 >> 1 main(){} >> (gdb) >> >> >> jay at plin:/cm3/bin$ gcc -gstabs+ 1.c >> jay at plin:/cm3/bin$ gdb ./a.out >> GNU gdb 6.8-debian >> Copyright (C) 2008 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. Type "show >> copying" >> and "show warranty" for details. >> This GDB was configured as "powerpc-linux-gnu"... >> (gdb) break main >> Breakpoint 1 at 0x10000448: file 1.c, line 1. >> (gdb) r >> Starting program: /home/jay/cm3/bin/a.out >> Breakpoint 1, main () at 1.c:1 >> 1 main(){} >> >> >> jay at plin:/cm3/bin$ gcc -gstabs 1.c >> jay at plin:/cm3/bin$ gdb ./a.out >> GNU gdb 6.8-debian >> Copyright (C) 2008 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. Type "show >> copying" >> and "show warranty" for details. >> This GDB was configured as "powerpc-linux-gnu"... >> (gdb) break main >> Breakpoint 1 at 0x10000448: file 1.c, line 1. >> (gdb) r >> Starting program: /home/jay/cm3/bin/a.out >> Breakpoint 1, main () at 1.c:1 >> 1 main(){} >> (gdb) >> >> >> - Jay >> >> >> ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Subject: more crashers >> Date: Sun, 16 Aug 2009 10:06:15 +0000 >> >> >> This is head on SOLgnu: >> I'll try another and debug and see if fix is easy. >> >> -bash-3.00$ ./m3browser >> >> *** >> *** runtime error: >> *** Segmentation violation - possible attempt to dereference NIL >> *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/String16.m3 >> *** >> >> -bash-3.00$ ./visobliq >> Internal Obliq interpreter installed... >> Establishing 'templates' >> (Created frame 'templates') >> let >> Templates = >> {boolean=> ... , >> browser=> ... , >> button=> ... , >> choice=> ... , >> filebrowser=> ... , >> form=> ... , >> frame=> ... , >> hscroll=> ... , >> menu=> ... , >> numeric=> ... , >> text=> ... , >> textedit=> ... , >> typein=> ... , >> video=> ... , >> vscroll=> ... } >> Establishing 'vowidgets' >> (Created frame 'vowidgets') >> ok >> Establishing 'vocheckpt' >> (Created frame 'vocheckpt') >> ok >> Establishing 'volib' >> (Created frame 'volib') >> Segmentation Fault (core dumped) >> -bash-3.00$ >> >> From jay.krell at cornell.edu Mon Aug 17 03:14:02 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 17 Aug 2009 01:14:02 +0000 Subject: [M3devel] more crashers In-Reply-To: References: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> Message-ID: Don't worry because of this. This was changing folks from M3Config to MxConfig plus that my config doesn't go out of its way to be compatible with code that doesn't predefine stuff -- ie: mxconfig clients other than cm3. The "normal" config files have been adapted to be compatible. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Sun, 16 Aug 2009 19:10:15 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] more crashers > > So now I am worried about the recent changes to Text... > > On 16 Aug 2009, at 15:33, Jay K wrote: > >> >> Could be. I've also seen it on PPC_DARWIN a while ago. I only recall >> seeing it on sparc and ppc. >> It doesn't always occur. >> >> >> Here is the m3browser crash on a system that can be debugged. >> See why I want the full paths in the debug info? >> >> >> C:\Users\jay\Desktop>\cygwin\bin\ssh xobsd. >> $ cd /cm3 >> $ cd bin >> $ export DISPLAY=192.168.1.120:0.0 >> $ gdb ./m3browser >> GNU gdb 6.3 >> This GDB was configured as "i386-unknown-openbsd4.5"... >> (gdb) r >> Starting program: /home/jay/cm3/bin/m3browser >> Program received signal SIGSEGV, Segmentation fault. >> [Switching to process 31063, thread 0x7eafe800] >> 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 >> 16 t.get_info (i); >> (gdb) bt >> #0 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/ >> Text.m3:16 >> #1 0x09fd9464 in ID__Add (M3_Bd56fi_x=0x0) at ../src/ID.m3:48 >> #2 0x1c01e644 in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:37 >> #3 0x0156f1bc in RTLinker__RunMainBody (M3_DjPxE3_m=0x3c003ec0) >> at ../src/runtime/common/RTLinker.m3:399 >> #4 0x0156e576 in RTLinker__AddUnitI (M3_DjPxE3_m=0x3c003ec0) >> at ../src/runtime/common/RTLinker.m3:113 >> #5 0x0156e604 in RTLinker__AddUnit (M3_DjPxE5_b=0x1c01e54d) >> at ../src/runtime/common/RTLinker.m3:122 >> #6 0x1c004676 in main (argc=1, argv=0xcfbf6a3c, envp=0xcfbf6a44) >> at _m3main.mc:4 >> >> >> - Jay >> >> >> ________________________________ >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Date: Sun, 16 Aug 2009 15:26:49 -0400 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] more crashers >>> >>> Could this be endianness-related? >>> >>> On 16 Aug 2009, at 15:21, Jay K wrote: >>> >>> >>> I see the assertion failure on PPC_LINUX too. >>> I tried VAR defaultStackSize := 1024 * 1024; (not sure why there >>> was any suspicion of stack size). >>> >>> >>> Debugging doesn't work PPC_LINUX. >>> >>> >>> jay at plin:/cm3/bin$ gdb ./cm3 >>> GNU gdb 6.8-debian >>> Copyright (C) 2008 Free Software Foundation, Inc. >>> License GPLv3+: GNU GPL version 3 or later >>> This is free software: you are free to change and redistribute it. >>> There is NO WARRANTY, to the extent permitted by law. Type "show >>> copying" >>> and "show warranty" for details. >>> This GDB was configured as "powerpc-linux-gnu"... >>> break ma(gdb) break main >>> Breakpoint 1 at 0x86fc4: file _m3main.mc, line 2. >>> (gdb) r >>> Starting program: /home/jay/cm3/bin/cm3 >>> Warning: >>> Cannot insert breakpoint 1. >>> Error accessing memory address 0x86fc4: Input/output error. >>> >>> >>> No problem with C: >>> >>> >>> jay at plin:/cm3/bin$ echo "main(){}"> 1.c >>> jay at plin:/cm3/bin$ gcc -g 1.c >>> jay at plin:/cm3/bin$ gdb ./a.out >>> GNU gdb 6.8-debian >>> Copyright (C) 2008 Free Software Foundation, Inc. >>> License GPLv3+: GNU GPL version 3 or later >>> This is free software: you are free to change and redistribute it. >>> There is NO WARRANTY, to the extent permitted by law. Type "show >>> copying" >>> and "show warranty" for details. >>> This GDB was configured as "powerpc-linux-gnu"... >>> (gdb) break main >>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>> (gdb) r >>> Starting program: /home/jay/cm3/bin/a.out >>> Breakpoint 1, main () at 1.c:1 >>> 1 main(){} >>> (gdb) >>> >>> >>> jay at plin:/cm3/bin$ gcc -gstabs+ 1.c >>> jay at plin:/cm3/bin$ gdb ./a.out >>> GNU gdb 6.8-debian >>> Copyright (C) 2008 Free Software Foundation, Inc. >>> License GPLv3+: GNU GPL version 3 or later >>> This is free software: you are free to change and redistribute it. >>> There is NO WARRANTY, to the extent permitted by law. Type "show >>> copying" >>> and "show warranty" for details. >>> This GDB was configured as "powerpc-linux-gnu"... >>> (gdb) break main >>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>> (gdb) r >>> Starting program: /home/jay/cm3/bin/a.out >>> Breakpoint 1, main () at 1.c:1 >>> 1 main(){} >>> >>> >>> jay at plin:/cm3/bin$ gcc -gstabs 1.c >>> jay at plin:/cm3/bin$ gdb ./a.out >>> GNU gdb 6.8-debian >>> Copyright (C) 2008 Free Software Foundation, Inc. >>> License GPLv3+: GNU GPL version 3 or later >>> This is free software: you are free to change and redistribute it. >>> There is NO WARRANTY, to the extent permitted by law. Type "show >>> copying" >>> and "show warranty" for details. >>> This GDB was configured as "powerpc-linux-gnu"... >>> (gdb) break main >>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>> (gdb) r >>> Starting program: /home/jay/cm3/bin/a.out >>> Breakpoint 1, main () at 1.c:1 >>> 1 main(){} >>> (gdb) >>> >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: m3devel at elegosoft.com >>> Subject: more crashers >>> Date: Sun, 16 Aug 2009 10:06:15 +0000 >>> >>> >>> This is head on SOLgnu: >>> I'll try another and debug and see if fix is easy. >>> >>> -bash-3.00$ ./m3browser >>> >>> *** >>> *** runtime error: >>> *** Segmentation violation - possible attempt to dereference NIL >>> *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/String16.m3 >>> *** >>> >>> -bash-3.00$ ./visobliq >>> Internal Obliq interpreter installed... >>> Establishing 'templates' >>> (Created frame 'templates') >>> let >>> Templates = >>> {boolean=> ... , >>> browser=> ... , >>> button=> ... , >>> choice=> ... , >>> filebrowser=> ... , >>> form=> ... , >>> frame=> ... , >>> hscroll=> ... , >>> menu=> ... , >>> numeric=> ... , >>> text=> ... , >>> textedit=> ... , >>> typein=> ... , >>> video=> ... , >>> vscroll=> ... } >>> Establishing 'vowidgets' >>> (Created frame 'vowidgets') >>> ok >>> Establishing 'vocheckpt' >>> (Created frame 'vocheckpt') >>> ok >>> Establishing 'volib' >>> (Created frame 'volib') >>> Segmentation Fault (core dumped) >>> -bash-3.00$ >>> >>> > From jay.krell at cornell.edu Mon Aug 17 03:33:03 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 17 Aug 2009 01:33:03 +0000 Subject: [M3devel] Errors building Juno on PPC_LINUX (Debian 5) Message-ID: > I'm going to rebuild m3cc clean Did not reoccur after that. Possibly some mismatch with an cm3cg built on Debian 4 vs. Debian 5's binutils. Though that only really makes sense for one of the errors. (Debian 5 has nice property of Sun Java being available for all but hppa, good for Hudson's sake.) - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: Errors building Juno on PPC_LINUX (Debian 5) > Date: Sun, 16 Aug 2009 19:27:03 +0000 > > > Errors building Juno on PPC_LINUX (Debian 5) > > == package /home/jay/dev2/cm3/m3-ui/juno-2/juno-app == > +++ /cm3/bin/cm3 -build -DROOT=/home/jay/dev2/cm3 -DCM3_VERSION_TEXT=d5.8.2 -D > CM3_VERSION_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ > --- building in PPC_LINUX --- > ... > new source -> compiling Editor.m3 > ../src/Editor.m3: In function 'Editor__Parse2': > ../src/Editor.m3:248: fatal error: *** bad opcode: 0x229, at m3cg_lineno 18629 > compilation terminated. > m3_backend => 1 > m3cc (aka cm3cg) failed compiling: Editor.mc > new opaque info -> recompiling Drag.m3 > Drag.ms: Assembler messages: > Drag.ms:3949: Error: unknown pseudo-op: `.s' > assemble => 1 > assembler failed assembling: Drag.ms > *** execution of [, ] failed *** > jay at plin:/dev2/cm3/scripts/python$ > > > More details to follow. > I'm going to rebuild m3cc clean, make sure it was built native not copied from another machine, but I think it already was native. > > > - Jay From jay.krell at cornell.edu Mon Aug 17 06:01:01 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 17 Aug 2009 04:01:01 +0000 Subject: [M3devel] more crashers In-Reply-To: References: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> Message-ID: visobliq was stack overflow. Raising the default from 4K to 16K didn't fix, but 32K did. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] more crashers > Date: Sun, 16 Aug 2009 20:32:31 +0000 > > > m3browser: > > It is specific to my config file m3-sys/cminstall/src/config-no-install/cm3.cfg that reachs back into the source tree. It won't happen with what most people do. I have to do that M3Predefines or such work so that all the uses of m3quake besides cm3 are much more like cm3. > > > visobliq: > not the same thing > Does not occur on Linux/x86 or Linux/sparc. > They do print > Syntax error just before: -helvetica-bold-\*R-\*240-\*\") (LabelFo ... > ill-formed character escape sequence > Error detected (file file generated by Visual Obliq) (line 18, char 10) > VideoVBT.Start Jv ServerFailure:errno=0 > > but then gui comes up. > I'll have to finish my Solaris reinstall and get dbx. > > > - Jay > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> Date: Sun, 16 Aug 2009 20:22:49 +0000 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] more crashers >> >> >> sorry, this is simple. >> >> derived_dirs := IntList.List1 (ID.Add (MxConfig.Get("BUILD_DIR"))); >> >> >> - Jay >> >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu >>> Date: Sun, 16 Aug 2009 19:52:03 +0000 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] more crashers >>> >>> >>> Here is the relevant code in m3browser ID.m3: >>> >>> >>> C:\dev2\cm3.2\m3-tools\m3markup\src\ID.m3(38): empty_id := Add (""); >>> >>> empty_id := Add (""); >>> >>> (*-------------------------------------------------------------- exported ---*) >>> PROCEDURE Add (x: TEXT): T = >>> VAR >>> t: T; >>> a: REF ARRAY OF CHAR; >>> l: INTEGER; >>> BEGIN >>> l := Text.Length(x); >>> ... >>> END Add; >>> >>> >>> The empty string constant ends up as null. >>> >>> .stabn 68,0,38,.LM115-.LFBB10 >>> .LM115: >>> movl L_1 at GOT(%ebx), %eax >>> leal 24(%eax), %eax >>> movl %eax, (%esp) >>> call ID__Add at PLT >>> movl %eax, -8(%ebp) >>> movl -8(%ebp), %ecx >>> movl MM_ID at GOT(%ebx), %edx >>> movl 248(%edx), %eax >>> andl $0, %eax >>> orl %ecx, %eax >>> movl %eax, 248(%edx) >>> .L136: >>> movl MM_ID at GOT(%ebx), %eax >>> .LBE16: >>> addl $52, %esp >>> popl %ebx >>> popl %ebp >>> ret >>> >>> L_1: >>> 0 .long RTHooks__TextLitInfo >>> 4 .long RTHooks__TextLitGetChar >>> 8 .long RTHooks__TextLitGetWideChar >>> 12 .long RTHooks__TextLitGetChars >>> 16 .long RTHooks__TextLitGetWideChars >>> 20 .long 2 >>> 24 .long L_1 >>> .long 0 >>> .zero 4 >>> .ascii "ID_M3" >>> .zero 1 >>> .ascii "ExpandHashTable" >>> .zero 1 >>> .ascii "ExpandIDs" >>> .zero 1 >>> .ascii "ExpandChars" >>> .zero 1 >>> .ascii "Compare" >>> .zero 1 >>> >>> If I change "" to "foo", I get: >>> >>> L_1: >>> 0 .long RTHooks__TextLitInfo >>> 4 .long RTHooks__TextLitGetChar >>> 8 .long RTHooks__TextLitGetWideChar >>> 12 .long RTHooks__TextLitGetChars >>> 16 .long RTHooks__TextLitGetWideChars >>> 20 .long 2 >>> 24 .long L_1 >>> .long 3 >>> .ascii "foo" >>> .zero 1 >>> .ascii "ID_M3" >>> >>> and it still crashes. >>> >>> >>> It seems to hit ID__Add twice when only once would be expected. >>> >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: hosking at cs.purdue.edu >>>> Date: Sun, 16 Aug 2009 19:33:34 +0000 >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] more crashers >>>> >>>> >>>> Could be. I've also seen it on PPC_DARWIN a while ago. I only recall seeing it on sparc and ppc. >>>> It doesn't always occur. >>>> >>>> >>>> Here is the m3browser crash on a system that can be debugged. >>>> See why I want the full paths in the debug info? >>>> >>>> >>>> C:\Users\jay\Desktop>\cygwin\bin\ssh xobsd. >>>> $ cd /cm3 >>>> $ cd bin >>>> $ export DISPLAY=192.168.1.120:0.0 >>>> $ gdb ./m3browser >>>> GNU gdb 6.3 >>>> This GDB was configured as "i386-unknown-openbsd4.5"... >>>> (gdb) r >>>> Starting program: /home/jay/cm3/bin/m3browser >>>> Program received signal SIGSEGV, Segmentation fault. >>>> [Switching to process 31063, thread 0x7eafe800] >>>> 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 >>>> 16 t.get_info (i); >>>> (gdb) bt >>>> #0 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 >>>> #1 0x09fd9464 in ID__Add (M3_Bd56fi_x=0x0) at ../src/ID.m3:48 >>>> #2 0x1c01e644 in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:37 >>>> #3 0x0156f1bc in RTLinker__RunMainBody (M3_DjPxE3_m=0x3c003ec0) >>>> at ../src/runtime/common/RTLinker.m3:399 >>>> #4 0x0156e576 in RTLinker__AddUnitI (M3_DjPxE3_m=0x3c003ec0) >>>> at ../src/runtime/common/RTLinker.m3:113 >>>> #5 0x0156e604 in RTLinker__AddUnit (M3_DjPxE5_b=0x1c01e54d) >>>> at ../src/runtime/common/RTLinker.m3:122 >>>> #6 0x1c004676 in main (argc=1, argv=0xcfbf6a3c, envp=0xcfbf6a44) >>>> at _m3main.mc:4 >>>> >>>> >>>> - Jay >>>> >>>> >>>> ________________________________ >>>>> From: hosking at cs.purdue.edu >>>>> To: jay.krell at cornell.edu >>>>> Date: Sun, 16 Aug 2009 15:26:49 -0400 >>>>> CC: m3devel at elegosoft.com >>>>> Subject: Re: [M3devel] more crashers >>>>> >>>>> Could this be endianness-related? >>>>> >>>>> On 16 Aug 2009, at 15:21, Jay K wrote: >>>>> >>>>> >>>>> I see the assertion failure on PPC_LINUX too. >>>>> I tried VAR defaultStackSize := 1024 * 1024; (not sure why there was any suspicion of stack size). >>>>> >>>>> >>>>> Debugging doesn't work PPC_LINUX. >>>>> >>>>> >>>>> jay at plin:/cm3/bin$ gdb ./cm3 >>>>> GNU gdb 6.8-debian >>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>> License GPLv3+: GNU GPL version 3 or later >>>>> This is free software: you are free to change and redistribute it. >>>>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >>>>> and "show warranty" for details. >>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>> break ma(gdb) break main >>>>> Breakpoint 1 at 0x86fc4: file _m3main.mc, line 2. >>>>> (gdb) r >>>>> Starting program: /home/jay/cm3/bin/cm3 >>>>> Warning: >>>>> Cannot insert breakpoint 1. >>>>> Error accessing memory address 0x86fc4: Input/output error. >>>>> >>>>> >>>>> No problem with C: >>>>> >>>>> >>>>> jay at plin:/cm3/bin$ echo "main(){}"> 1.c >>>>> jay at plin:/cm3/bin$ gcc -g 1.c >>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>> GNU gdb 6.8-debian >>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>> License GPLv3+: GNU GPL version 3 or later >>>>> This is free software: you are free to change and redistribute it. >>>>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >>>>> and "show warranty" for details. >>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>> (gdb) break main >>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>> (gdb) r >>>>> Starting program: /home/jay/cm3/bin/a.out >>>>> Breakpoint 1, main () at 1.c:1 >>>>> 1 main(){} >>>>> (gdb) >>>>> >>>>> >>>>> jay at plin:/cm3/bin$ gcc -gstabs+ 1.c >>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>> GNU gdb 6.8-debian >>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>> License GPLv3+: GNU GPL version 3 or later >>>>> This is free software: you are free to change and redistribute it. >>>>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >>>>> and "show warranty" for details. >>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>> (gdb) break main >>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>> (gdb) r >>>>> Starting program: /home/jay/cm3/bin/a.out >>>>> Breakpoint 1, main () at 1.c:1 >>>>> 1 main(){} >>>>> >>>>> >>>>> jay at plin:/cm3/bin$ gcc -gstabs 1.c >>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>> GNU gdb 6.8-debian >>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>> License GPLv3+: GNU GPL version 3 or later >>>>> This is free software: you are free to change and redistribute it. >>>>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >>>>> and "show warranty" for details. >>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>> (gdb) break main >>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>> (gdb) r >>>>> Starting program: /home/jay/cm3/bin/a.out >>>>> Breakpoint 1, main () at 1.c:1 >>>>> 1 main(){} >>>>> (gdb) >>>>> >>>>> >>>>> - Jay >>>>> >>>>> >>>>> ---------------------------------------- >>>>> From: jay.krell at cornell.edu >>>>> To: m3devel at elegosoft.com >>>>> Subject: more crashers >>>>> Date: Sun, 16 Aug 2009 10:06:15 +0000 >>>>> >>>>> >>>>> This is head on SOLgnu: >>>>> I'll try another and debug and see if fix is easy. >>>>> >>>>> -bash-3.00$ ./m3browser >>>>> >>>>> *** >>>>> *** runtime error: >>>>> *** Segmentation violation - possible attempt to dereference NIL >>>>> *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/String16.m3 >>>>> *** >>>>> >>>>> -bash-3.00$ ./visobliq >>>>> Internal Obliq interpreter installed... >>>>> Establishing 'templates' >>>>> (Created frame 'templates') >>>>> let >>>>> Templates = >>>>> {boolean=> ... , >>>>> browser=> ... , >>>>> button=> ... , >>>>> choice=> ... , >>>>> filebrowser=> ... , >>>>> form=> ... , >>>>> frame=> ... , >>>>> hscroll=> ... , >>>>> menu=> ... , >>>>> numeric=> ... , >>>>> text=> ... , >>>>> textedit=> ... , >>>>> typein=> ... , >>>>> video=> ... , >>>>> vscroll=> ... } >>>>> Establishing 'vowidgets' >>>>> (Created frame 'vowidgets') >>>>> ok >>>>> Establishing 'vocheckpt' >>>>> (Created frame 'vocheckpt') >>>>> ok >>>>> Establishing 'volib' >>>>> (Created frame 'volib') >>>>> Segmentation Fault (core dumped) >>>>> -bash-3.00$ >>>>> >>>>> From jay.krell at cornell.edu Mon Aug 17 06:01:45 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 17 Aug 2009 04:01:45 +0000 Subject: [M3devel] more crashers In-Reply-To: References: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> Message-ID: visobliq was stack overflow. Raising the default from 4K to 16K didn't fix, but 32K did. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] more crashers > Date: Sun, 16 Aug 2009 20:32:31 +0000 > > > m3browser: > > It is specific to my config file m3-sys/cminstall/src/config-no-install/cm3.cfg that reachs back into the source tree. It won't happen with what most people do. I have to do that M3Predefines or such work so that all the uses of m3quake besides cm3 are much more like cm3. > > > visobliq: > not the same thing > Does not occur on Linux/x86 or Linux/sparc. > They do print > Syntax error just before: -helvetica-bold-\*R-\*240-\*\") (LabelFo ... > ill-formed character escape sequence > Error detected (file file generated by Visual Obliq) (line 18, char 10) > VideoVBT.Start Jv ServerFailure:errno=0 > > but then gui comes up. > I'll have to finish my Solaris reinstall and get dbx. > > > - Jay > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> Date: Sun, 16 Aug 2009 20:22:49 +0000 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] more crashers >> >> >> sorry, this is simple. >> >> derived_dirs := IntList.List1 (ID.Add (MxConfig.Get("BUILD_DIR"))); >> >> >> - Jay >> >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu >>> Date: Sun, 16 Aug 2009 19:52:03 +0000 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] more crashers >>> >>> >>> Here is the relevant code in m3browser ID.m3: >>> >>> >>> C:\dev2\cm3.2\m3-tools\m3markup\src\ID.m3(38): empty_id := Add (""); >>> >>> empty_id := Add (""); >>> >>> (*-------------------------------------------------------------- exported ---*) >>> PROCEDURE Add (x: TEXT): T = >>> VAR >>> t: T; >>> a: REF ARRAY OF CHAR; >>> l: INTEGER; >>> BEGIN >>> l := Text.Length(x); >>> ... >>> END Add; >>> >>> >>> The empty string constant ends up as null. >>> >>> .stabn 68,0,38,.LM115-.LFBB10 >>> .LM115: >>> movl L_1 at GOT(%ebx), %eax >>> leal 24(%eax), %eax >>> movl %eax, (%esp) >>> call ID__Add at PLT >>> movl %eax, -8(%ebp) >>> movl -8(%ebp), %ecx >>> movl MM_ID at GOT(%ebx), %edx >>> movl 248(%edx), %eax >>> andl $0, %eax >>> orl %ecx, %eax >>> movl %eax, 248(%edx) >>> .L136: >>> movl MM_ID at GOT(%ebx), %eax >>> .LBE16: >>> addl $52, %esp >>> popl %ebx >>> popl %ebp >>> ret >>> >>> L_1: >>> 0 .long RTHooks__TextLitInfo >>> 4 .long RTHooks__TextLitGetChar >>> 8 .long RTHooks__TextLitGetWideChar >>> 12 .long RTHooks__TextLitGetChars >>> 16 .long RTHooks__TextLitGetWideChars >>> 20 .long 2 >>> 24 .long L_1 >>> .long 0 >>> .zero 4 >>> .ascii "ID_M3" >>> .zero 1 >>> .ascii "ExpandHashTable" >>> .zero 1 >>> .ascii "ExpandIDs" >>> .zero 1 >>> .ascii "ExpandChars" >>> .zero 1 >>> .ascii "Compare" >>> .zero 1 >>> >>> If I change "" to "foo", I get: >>> >>> L_1: >>> 0 .long RTHooks__TextLitInfo >>> 4 .long RTHooks__TextLitGetChar >>> 8 .long RTHooks__TextLitGetWideChar >>> 12 .long RTHooks__TextLitGetChars >>> 16 .long RTHooks__TextLitGetWideChars >>> 20 .long 2 >>> 24 .long L_1 >>> .long 3 >>> .ascii "foo" >>> .zero 1 >>> .ascii "ID_M3" >>> >>> and it still crashes. >>> >>> >>> It seems to hit ID__Add twice when only once would be expected. >>> >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: hosking at cs.purdue.edu >>>> Date: Sun, 16 Aug 2009 19:33:34 +0000 >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] more crashers >>>> >>>> >>>> Could be. I've also seen it on PPC_DARWIN a while ago. I only recall seeing it on sparc and ppc. >>>> It doesn't always occur. >>>> >>>> >>>> Here is the m3browser crash on a system that can be debugged. >>>> See why I want the full paths in the debug info? >>>> >>>> >>>> C:\Users\jay\Desktop>\cygwin\bin\ssh xobsd. >>>> $ cd /cm3 >>>> $ cd bin >>>> $ export DISPLAY=192.168.1.120:0.0 >>>> $ gdb ./m3browser >>>> GNU gdb 6.3 >>>> This GDB was configured as "i386-unknown-openbsd4.5"... >>>> (gdb) r >>>> Starting program: /home/jay/cm3/bin/m3browser >>>> Program received signal SIGSEGV, Segmentation fault. >>>> [Switching to process 31063, thread 0x7eafe800] >>>> 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 >>>> 16 t.get_info (i); >>>> (gdb) bt >>>> #0 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 >>>> #1 0x09fd9464 in ID__Add (M3_Bd56fi_x=0x0) at ../src/ID.m3:48 >>>> #2 0x1c01e644 in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:37 >>>> #3 0x0156f1bc in RTLinker__RunMainBody (M3_DjPxE3_m=0x3c003ec0) >>>> at ../src/runtime/common/RTLinker.m3:399 >>>> #4 0x0156e576 in RTLinker__AddUnitI (M3_DjPxE3_m=0x3c003ec0) >>>> at ../src/runtime/common/RTLinker.m3:113 >>>> #5 0x0156e604 in RTLinker__AddUnit (M3_DjPxE5_b=0x1c01e54d) >>>> at ../src/runtime/common/RTLinker.m3:122 >>>> #6 0x1c004676 in main (argc=1, argv=0xcfbf6a3c, envp=0xcfbf6a44) >>>> at _m3main.mc:4 >>>> >>>> >>>> - Jay >>>> >>>> >>>> ________________________________ >>>>> From: hosking at cs.purdue.edu >>>>> To: jay.krell at cornell.edu >>>>> Date: Sun, 16 Aug 2009 15:26:49 -0400 >>>>> CC: m3devel at elegosoft.com >>>>> Subject: Re: [M3devel] more crashers >>>>> >>>>> Could this be endianness-related? >>>>> >>>>> On 16 Aug 2009, at 15:21, Jay K wrote: >>>>> >>>>> >>>>> I see the assertion failure on PPC_LINUX too. >>>>> I tried VAR defaultStackSize := 1024 * 1024; (not sure why there was any suspicion of stack size). >>>>> >>>>> >>>>> Debugging doesn't work PPC_LINUX. >>>>> >>>>> >>>>> jay at plin:/cm3/bin$ gdb ./cm3 >>>>> GNU gdb 6.8-debian >>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>> License GPLv3+: GNU GPL version 3 or later >>>>> This is free software: you are free to change and redistribute it. >>>>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >>>>> and "show warranty" for details. >>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>> break ma(gdb) break main >>>>> Breakpoint 1 at 0x86fc4: file _m3main.mc, line 2. >>>>> (gdb) r >>>>> Starting program: /home/jay/cm3/bin/cm3 >>>>> Warning: >>>>> Cannot insert breakpoint 1. >>>>> Error accessing memory address 0x86fc4: Input/output error. >>>>> >>>>> >>>>> No problem with C: >>>>> >>>>> >>>>> jay at plin:/cm3/bin$ echo "main(){}"> 1.c >>>>> jay at plin:/cm3/bin$ gcc -g 1.c >>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>> GNU gdb 6.8-debian >>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>> License GPLv3+: GNU GPL version 3 or later >>>>> This is free software: you are free to change and redistribute it. >>>>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >>>>> and "show warranty" for details. >>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>> (gdb) break main >>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>> (gdb) r >>>>> Starting program: /home/jay/cm3/bin/a.out >>>>> Breakpoint 1, main () at 1.c:1 >>>>> 1 main(){} >>>>> (gdb) >>>>> >>>>> >>>>> jay at plin:/cm3/bin$ gcc -gstabs+ 1.c >>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>> GNU gdb 6.8-debian >>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>> License GPLv3+: GNU GPL version 3 or later >>>>> This is free software: you are free to change and redistribute it. >>>>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >>>>> and "show warranty" for details. >>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>> (gdb) break main >>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>> (gdb) r >>>>> Starting program: /home/jay/cm3/bin/a.out >>>>> Breakpoint 1, main () at 1.c:1 >>>>> 1 main(){} >>>>> >>>>> >>>>> jay at plin:/cm3/bin$ gcc -gstabs 1.c >>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>> GNU gdb 6.8-debian >>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>> License GPLv3+: GNU GPL version 3 or later >>>>> This is free software: you are free to change and redistribute it. >>>>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >>>>> and "show warranty" for details. >>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>> (gdb) break main >>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>> (gdb) r >>>>> Starting program: /home/jay/cm3/bin/a.out >>>>> Breakpoint 1, main () at 1.c:1 >>>>> 1 main(){} >>>>> (gdb) >>>>> >>>>> >>>>> - Jay >>>>> >>>>> >>>>> ---------------------------------------- >>>>> From: jay.krell at cornell.edu >>>>> To: m3devel at elegosoft.com >>>>> Subject: more crashers >>>>> Date: Sun, 16 Aug 2009 10:06:15 +0000 >>>>> >>>>> >>>>> This is head on SOLgnu: >>>>> I'll try another and debug and see if fix is easy. >>>>> >>>>> -bash-3.00$ ./m3browser >>>>> >>>>> *** >>>>> *** runtime error: >>>>> *** Segmentation violation - possible attempt to dereference NIL >>>>> *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/String16.m3 >>>>> *** >>>>> >>>>> -bash-3.00$ ./visobliq >>>>> Internal Obliq interpreter installed... >>>>> Establishing 'templates' >>>>> (Created frame 'templates') >>>>> let >>>>> Templates = >>>>> {boolean=> ... , >>>>> browser=> ... , >>>>> button=> ... , >>>>> choice=> ... , >>>>> filebrowser=> ... , >>>>> form=> ... , >>>>> frame=> ... , >>>>> hscroll=> ... , >>>>> menu=> ... , >>>>> numeric=> ... , >>>>> text=> ... , >>>>> textedit=> ... , >>>>> typein=> ... , >>>>> video=> ... , >>>>> vscroll=> ... } >>>>> Establishing 'vowidgets' >>>>> (Created frame 'vowidgets') >>>>> ok >>>>> Establishing 'vocheckpt' >>>>> (Created frame 'vocheckpt') >>>>> ok >>>>> Establishing 'volib' >>>>> (Created frame 'volib') >>>>> Segmentation Fault (core dumped) >>>>> -bash-3.00$ >>>>> >>>>> From jay.krell at cornell.edu Mon Aug 17 10:10:33 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Mon, 17 Aug 2009 01:10:33 -0700 Subject: [M3devel] more crashers In-Reply-To: References: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> Message-ID: Ps a few things We should see about reducing stack usage. We should see about eliminating recursion on the machine stack. Recursion is ok but use a heap allocated data structure. We should experiment to see what some behaviors are specifically default stack sizes, if the stack size is actually changable, and how small it can actually be made on the various platforms. For *hypothetical* example if other than solaris rounds stack size up to 64k boundary then default should be increased to 64k. It depends what behaviors exist. I find the machine stack to the extent that I am familiar with it's implementations, broken. It is fast but it has two severe problems vs heap. 1 you generally have to somehow guess at its maximum size which is approx impossible and approx never done 2 generally no code deals with stack exhaustion, with good reason, it is difficult/impossible/not portable. Compare that to malloc where it is generally limited only by address space, everyone knows what failure looks like, and you can easily detect and react to failure, portably. It would be cool if alloca could return Null for out of stack but that doesn't nearly solve the problem. (yes I understand, alloca is not used for the vast majority of stack allocation, and isn't even portable) - Jay (phone) On Aug 16, 2009, at 9:01 PM, Jay K wrote: > > visobliq was stack overflow. > Raising the default from 4K to 16K didn't fix, but 32K did. > > - Jay > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] more crashers >> Date: Sun, 16 Aug 2009 20:32:31 +0000 >> >> >> m3browser: >> >> It is specific to my config file m3-sys/cminstall/src/config-no- >> install/cm3.cfg that reachs back into the source tree. It won't >> happen with what most people do. I have to do that M3Predefines or >> such work so that all the uses of m3quake besides cm3 are much more >> like cm3. >> >> >> visobliq: >> not the same thing >> Does not occur on Linux/x86 or Linux/sparc. >> They do print >> Syntax error just before: -helvetica-bold-\*R-\*240-\*\") >> (LabelFo ... >> ill-formed character escape sequence >> Error detected (file file generated by Visual Obliq) (line 18, char >> 10) >> VideoVBT.Start Jv ServerFailure:errno=0 >> >> but then gui comes up. >> I'll have to finish my Solaris reinstall and get dbx. >> >> >> - Jay >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu > From wagner at elegosoft.com Mon Aug 17 13:30:26 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 17 Aug 2009 13:30:26 +0200 Subject: [M3devel] more crashers In-Reply-To: References: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> Message-ID: <20090817133026.6v9cm3cu0wwkc08k@mail.elegosoft.com> Quoting Jay K : > visobliq was stack overflow. > Raising the default from 4K to 16K didn't fix, but 32K did. We need to address this somehow. It cannot be correct if the user needs to increase the default stack size on one platform by 8 and not at all on another. Do we have any concept of a 'standard stack size unit' ;-)? Something that can be easily understood and implemented and be used instead of the machine words in the current interfaces? Any ideas? Olaf > - Jay > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] more crashers >> Date: Sun, 16 Aug 2009 20:32:31 +0000 >> >> >> m3browser: >> >> It is specific to my config file >> m3-sys/cminstall/src/config-no-install/cm3.cfg that reachs back >> into the source tree. It won't happen with what most people do. I >> have to do that M3Predefines or such work so that all the uses of >> m3quake besides cm3 are much more like cm3. >> >> >> visobliq: >> not the same thing >> Does not occur on Linux/x86 or Linux/sparc. >> They do print >> Syntax error just before: -helvetica-bold-\*R-\*240-\*\") (LabelFo ... >> ill-formed character escape sequence >> Error detected (file file generated by Visual Obliq) (line 18, char 10) >> VideoVBT.Start Jv ServerFailure:errno=0 >> >> but then gui comes up. >> I'll have to finish my Solaris reinstall and get dbx. >> >> >> - Jay >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu >>> Date: Sun, 16 Aug 2009 20:22:49 +0000 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] more crashers >>> >>> >>> sorry, this is simple. >>> >>> derived_dirs := IntList.List1 (ID.Add (MxConfig.Get("BUILD_DIR"))); >>> >>> >>> - Jay >>> >>> >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: hosking at cs.purdue.edu >>>> Date: Sun, 16 Aug 2009 19:52:03 +0000 >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] more crashers >>>> >>>> >>>> Here is the relevant code in m3browser ID.m3: >>>> >>>> >>>> C:\dev2\cm3.2\m3-tools\m3markup\src\ID.m3(38): empty_id := Add (""); >>>> >>>> empty_id := Add (""); >>>> >>>> (*-------------------------------------------------------------- >>>> exported ---*) >>>> PROCEDURE Add (x: TEXT): T = >>>> VAR >>>> t: T; >>>> a: REF ARRAY OF CHAR; >>>> l: INTEGER; >>>> BEGIN >>>> l := Text.Length(x); >>>> ... >>>> END Add; >>>> >>>> >>>> The empty string constant ends up as null. >>>> >>>> .stabn 68,0,38,.LM115-.LFBB10 >>>> .LM115: >>>> movl L_1 at GOT(%ebx), %eax >>>> leal 24(%eax), %eax >>>> movl %eax, (%esp) >>>> call ID__Add at PLT >>>> movl %eax, -8(%ebp) >>>> movl -8(%ebp), %ecx >>>> movl MM_ID at GOT(%ebx), %edx >>>> movl 248(%edx), %eax >>>> andl $0, %eax >>>> orl %ecx, %eax >>>> movl %eax, 248(%edx) >>>> .L136: >>>> movl MM_ID at GOT(%ebx), %eax >>>> .LBE16: >>>> addl $52, %esp >>>> popl %ebx >>>> popl %ebp >>>> ret >>>> >>>> L_1: >>>> 0 .long RTHooks__TextLitInfo >>>> 4 .long RTHooks__TextLitGetChar >>>> 8 .long RTHooks__TextLitGetWideChar >>>> 12 .long RTHooks__TextLitGetChars >>>> 16 .long RTHooks__TextLitGetWideChars >>>> 20 .long 2 >>>> 24 .long L_1 >>>> .long 0 >>>> .zero 4 >>>> .ascii "ID_M3" >>>> .zero 1 >>>> .ascii "ExpandHashTable" >>>> .zero 1 >>>> .ascii "ExpandIDs" >>>> .zero 1 >>>> .ascii "ExpandChars" >>>> .zero 1 >>>> .ascii "Compare" >>>> .zero 1 >>>> >>>> If I change "" to "foo", I get: >>>> >>>> L_1: >>>> 0 .long RTHooks__TextLitInfo >>>> 4 .long RTHooks__TextLitGetChar >>>> 8 .long RTHooks__TextLitGetWideChar >>>> 12 .long RTHooks__TextLitGetChars >>>> 16 .long RTHooks__TextLitGetWideChars >>>> 20 .long 2 >>>> 24 .long L_1 >>>> .long 3 >>>> .ascii "foo" >>>> .zero 1 >>>> .ascii "ID_M3" >>>> >>>> and it still crashes. >>>> >>>> >>>> It seems to hit ID__Add twice when only once would be expected. >>>> >>>> >>>> - Jay >>>> >>>> >>>> ---------------------------------------- >>>>> From: jay.krell at cornell.edu >>>>> To: hosking at cs.purdue.edu >>>>> Date: Sun, 16 Aug 2009 19:33:34 +0000 >>>>> CC: m3devel at elegosoft.com >>>>> Subject: Re: [M3devel] more crashers >>>>> >>>>> >>>>> Could be. I've also seen it on PPC_DARWIN a while ago. I only >>>>> recall seeing it on sparc and ppc. >>>>> It doesn't always occur. >>>>> >>>>> >>>>> Here is the m3browser crash on a system that can be debugged. >>>>> See why I want the full paths in the debug info? >>>>> >>>>> >>>>> C:\Users\jay\Desktop>\cygwin\bin\ssh xobsd. >>>>> $ cd /cm3 >>>>> $ cd bin >>>>> $ export DISPLAY=192.168.1.120:0.0 >>>>> $ gdb ./m3browser >>>>> GNU gdb 6.3 >>>>> This GDB was configured as "i386-unknown-openbsd4.5"... >>>>> (gdb) r >>>>> Starting program: /home/jay/cm3/bin/m3browser >>>>> Program received signal SIGSEGV, Segmentation fault. >>>>> [Switching to process 31063, thread 0x7eafe800] >>>>> 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 >>>>> 16 t.get_info (i); >>>>> (gdb) bt >>>>> #0 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 >>>>> #1 0x09fd9464 in ID__Add (M3_Bd56fi_x=0x0) at ../src/ID.m3:48 >>>>> #2 0x1c01e644 in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:37 >>>>> #3 0x0156f1bc in RTLinker__RunMainBody (M3_DjPxE3_m=0x3c003ec0) >>>>> at ../src/runtime/common/RTLinker.m3:399 >>>>> #4 0x0156e576 in RTLinker__AddUnitI (M3_DjPxE3_m=0x3c003ec0) >>>>> at ../src/runtime/common/RTLinker.m3:113 >>>>> #5 0x0156e604 in RTLinker__AddUnit (M3_DjPxE5_b=0x1c01e54d) >>>>> at ../src/runtime/common/RTLinker.m3:122 >>>>> #6 0x1c004676 in main (argc=1, argv=0xcfbf6a3c, envp=0xcfbf6a44) >>>>> at _m3main.mc:4 >>>>> >>>>> >>>>> - Jay >>>>> >>>>> >>>>> ________________________________ >>>>>> From: hosking at cs.purdue.edu >>>>>> To: jay.krell at cornell.edu >>>>>> Date: Sun, 16 Aug 2009 15:26:49 -0400 >>>>>> CC: m3devel at elegosoft.com >>>>>> Subject: Re: [M3devel] more crashers >>>>>> >>>>>> Could this be endianness-related? >>>>>> >>>>>> On 16 Aug 2009, at 15:21, Jay K wrote: >>>>>> >>>>>> >>>>>> I see the assertion failure on PPC_LINUX too. >>>>>> I tried VAR defaultStackSize := 1024 * 1024; (not sure why >>>>>> there was any suspicion of stack size). >>>>>> >>>>>> >>>>>> Debugging doesn't work PPC_LINUX. >>>>>> >>>>>> >>>>>> jay at plin:/cm3/bin$ gdb ./cm3 >>>>>> GNU gdb 6.8-debian >>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>> This is free software: you are free to change and redistribute it. >>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>> "show copying" >>>>>> and "show warranty" for details. >>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>> break ma(gdb) break main >>>>>> Breakpoint 1 at 0x86fc4: file _m3main.mc, line 2. >>>>>> (gdb) r >>>>>> Starting program: /home/jay/cm3/bin/cm3 >>>>>> Warning: >>>>>> Cannot insert breakpoint 1. >>>>>> Error accessing memory address 0x86fc4: Input/output error. >>>>>> >>>>>> >>>>>> No problem with C: >>>>>> >>>>>> >>>>>> jay at plin:/cm3/bin$ echo "main(){}"> 1.c >>>>>> jay at plin:/cm3/bin$ gcc -g 1.c >>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>> GNU gdb 6.8-debian >>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>> This is free software: you are free to change and redistribute it. >>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>> "show copying" >>>>>> and "show warranty" for details. >>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>> (gdb) break main >>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>> (gdb) r >>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>> Breakpoint 1, main () at 1.c:1 >>>>>> 1 main(){} >>>>>> (gdb) >>>>>> >>>>>> >>>>>> jay at plin:/cm3/bin$ gcc -gstabs+ 1.c >>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>> GNU gdb 6.8-debian >>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>> This is free software: you are free to change and redistribute it. >>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>> "show copying" >>>>>> and "show warranty" for details. >>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>> (gdb) break main >>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>> (gdb) r >>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>> Breakpoint 1, main () at 1.c:1 >>>>>> 1 main(){} >>>>>> >>>>>> >>>>>> jay at plin:/cm3/bin$ gcc -gstabs 1.c >>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>> GNU gdb 6.8-debian >>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>> This is free software: you are free to change and redistribute it. >>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>> "show copying" >>>>>> and "show warranty" for details. >>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>> (gdb) break main >>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>> (gdb) r >>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>> Breakpoint 1, main () at 1.c:1 >>>>>> 1 main(){} >>>>>> (gdb) >>>>>> >>>>>> >>>>>> - Jay >>>>>> >>>>>> >>>>>> ---------------------------------------- >>>>>> From: jay.krell at cornell.edu >>>>>> To: m3devel at elegosoft.com >>>>>> Subject: more crashers >>>>>> Date: Sun, 16 Aug 2009 10:06:15 +0000 >>>>>> >>>>>> >>>>>> This is head on SOLgnu: >>>>>> I'll try another and debug and see if fix is easy. >>>>>> >>>>>> -bash-3.00$ ./m3browser >>>>>> >>>>>> *** >>>>>> *** runtime error: >>>>>> *** Segmentation violation - possible attempt to dereference NIL >>>>>> *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/String16.m3 >>>>>> *** >>>>>> >>>>>> -bash-3.00$ ./visobliq >>>>>> Internal Obliq interpreter installed... >>>>>> Establishing 'templates' >>>>>> (Created frame 'templates') >>>>>> let >>>>>> Templates = >>>>>> {boolean=> ... , >>>>>> browser=> ... , >>>>>> button=> ... , >>>>>> choice=> ... , >>>>>> filebrowser=> ... , >>>>>> form=> ... , >>>>>> frame=> ... , >>>>>> hscroll=> ... , >>>>>> menu=> ... , >>>>>> numeric=> ... , >>>>>> text=> ... , >>>>>> textedit=> ... , >>>>>> typein=> ... , >>>>>> video=> ... , >>>>>> vscroll=> ... } >>>>>> Establishing 'vowidgets' >>>>>> (Created frame 'vowidgets') >>>>>> ok >>>>>> Establishing 'vocheckpt' >>>>>> (Created frame 'vocheckpt') >>>>>> ok >>>>>> Establishing 'volib' >>>>>> (Created frame 'volib') >>>>>> Segmentation Fault (core dumped) >>>>>> -bash-3.00$ >>>>>> >>>>>> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Mon Aug 17 13:35:25 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 17 Aug 2009 13:35:25 +0200 Subject: [M3devel] CM3 Release Engineering and Feedback In-Reply-To: <20090816171032.GA27461@topoi.pooq.com> References: <20090813143806.udmpiz76ecg0scgs@mail.elegosoft.com> <20090816171032.GA27461@topoi.pooq.com> Message-ID: <20090817133525.c8kdk3g0o4w4g0ok@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > On Thu, Aug 13, 2009 at 02:38:06PM +0200, Olaf Wagner wrote: >> Quoting hendrik at topoi.pooq.com: >> >> >On Wed, Aug 12, 2009 at 01:10:38AM +0200, Olaf Wagner wrote: >> >> o There hasn't been much feedback, neither from the list of active >> >> developers nor from end users for RC2. I'd really appreciate some >> >> more reports about installation attempts and the problems encountered. >> > >> >Well, I'll provide more with the next RC. The hudson directory was >> >pretty much a show-stopper. I'd expect the same problem to be there on >> >the other platforms. >> >> The simple work-around would be to call cm3 -build on the packages >> again, which should only adapt the broken .M3SHIP files. > > I tried that , but it failed, complaining Yes. Sorry. Those were the bogus collection dependencies. They should now be 'fixed', too (at least much easier to understand). I've invested some hours to compute the depdenencies on package and collection level several times and made some changes to the collection classification in pkginfo.txt. [...] > In any case, this will be an obsolete by the time RC3 starts to roll > out. So focus on that rather than fixing the workaround. If there are no more new unexpected crashes, I'll build the RC3 archives soon. It should be much easier this time. We'll see... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Aug 17 13:35:40 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 17 Aug 2009 11:35:40 +0000 Subject: [M3devel] more crashers In-Reply-To: <20090817133026.6v9cm3cu0wwkc08k@mail.elegosoft.com> References: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> <20090817133026.6v9cm3cu0wwkc08k@mail.elegosoft.com> Message-ID: - I think the whole machine stack mechanism is pretty hopelessly broken. Not just in Modula-3. Therefore my enthusiasm to attempt to "fix" it -- which is impossible -- isn't very high. - I'm hoping to find that no platform other than Solaris lets you even use such a small stack. I have to experiment some in a bit. Depending on that experiment, we'll be in a better position, without any further changes, but again, depending on what I find. That is, if every other platform already had a larger stack, then this just brings Solaris inline with the rest. If the other platforms were actually successfully using a 4K stack, then indeed a problem. - It could also be a factor of optimization. Maybe ensuring -O2 or -O3 is used more would cover it up?? - Or some other changes. That is, if we have drastically increased stack usage, we should try to reduce it back down. But given that 4K was the previous value and even 16K doesn't work...I'm not hopeful we could fit it back down in 4K. It is easy enough to see the bug and then look at the various frames and see if they use a lot of stack and can be reduced. - Jay ---------------------------------------- > Date: Mon, 17 Aug 2009 13:30:26 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] more crashers > > Quoting Jay K : > >> visobliq was stack overflow. >> Raising the default from 4K to 16K didn't fix, but 32K did. > > We need to address this somehow. It cannot be correct if the user > needs to increase the default stack size on one platform by 8 > and not at all on another. Do we have any concept of a 'standard > stack size unit' ;-)? Something that can be easily understood and > implemented and be used instead of the machine words in the current > interfaces? Any ideas? > > Olaf > > >> - Jay >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu >>> CC: m3devel at elegosoft.com >>> Subject: RE: [M3devel] more crashers >>> Date: Sun, 16 Aug 2009 20:32:31 +0000 >>> >>> >>> m3browser: >>> >>> It is specific to my config file >>> m3-sys/cminstall/src/config-no-install/cm3.cfg that reachs back >>> into the source tree. It won't happen with what most people do. I >>> have to do that M3Predefines or such work so that all the uses of >>> m3quake besides cm3 are much more like cm3. >>> >>> >>> visobliq: >>> not the same thing >>> Does not occur on Linux/x86 or Linux/sparc. >>> They do print >>> Syntax error just before: -helvetica-bold-\*R-\*240-\*\") (LabelFo ... >>> ill-formed character escape sequence >>> Error detected (file file generated by Visual Obliq) (line 18, char 10) >>> VideoVBT.Start Jv ServerFailure:errno=0 >>> >>> but then gui comes up. >>> I'll have to finish my Solaris reinstall and get dbx. >>> >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: hosking at cs.purdue.edu >>>> Date: Sun, 16 Aug 2009 20:22:49 +0000 >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] more crashers >>>> >>>> >>>> sorry, this is simple. >>>> >>>> derived_dirs := IntList.List1 (ID.Add (MxConfig.Get("BUILD_DIR"))); >>>> >>>> >>>> - Jay >>>> >>>> >>>> >>>> ---------------------------------------- >>>>> From: jay.krell at cornell.edu >>>>> To: hosking at cs.purdue.edu >>>>> Date: Sun, 16 Aug 2009 19:52:03 +0000 >>>>> CC: m3devel at elegosoft.com >>>>> Subject: Re: [M3devel] more crashers >>>>> >>>>> >>>>> Here is the relevant code in m3browser ID.m3: >>>>> >>>>> >>>>> C:\dev2\cm3.2\m3-tools\m3markup\src\ID.m3(38): empty_id := Add (""); >>>>> >>>>> empty_id := Add (""); >>>>> >>>>> (*-------------------------------------------------------------- >>>>> exported ---*) >>>>> PROCEDURE Add (x: TEXT): T = >>>>> VAR >>>>> t: T; >>>>> a: REF ARRAY OF CHAR; >>>>> l: INTEGER; >>>>> BEGIN >>>>> l := Text.Length(x); >>>>> ... >>>>> END Add; >>>>> >>>>> >>>>> The empty string constant ends up as null. >>>>> >>>>> .stabn 68,0,38,.LM115-.LFBB10 >>>>> .LM115: >>>>> movl L_1 at GOT(%ebx), %eax >>>>> leal 24(%eax), %eax >>>>> movl %eax, (%esp) >>>>> call ID__Add at PLT >>>>> movl %eax, -8(%ebp) >>>>> movl -8(%ebp), %ecx >>>>> movl MM_ID at GOT(%ebx), %edx >>>>> movl 248(%edx), %eax >>>>> andl $0, %eax >>>>> orl %ecx, %eax >>>>> movl %eax, 248(%edx) >>>>> .L136: >>>>> movl MM_ID at GOT(%ebx), %eax >>>>> .LBE16: >>>>> addl $52, %esp >>>>> popl %ebx >>>>> popl %ebp >>>>> ret >>>>> >>>>> L_1: >>>>> 0 .long RTHooks__TextLitInfo >>>>> 4 .long RTHooks__TextLitGetChar >>>>> 8 .long RTHooks__TextLitGetWideChar >>>>> 12 .long RTHooks__TextLitGetChars >>>>> 16 .long RTHooks__TextLitGetWideChars >>>>> 20 .long 2 >>>>> 24 .long L_1 >>>>> .long 0 >>>>> .zero 4 >>>>> .ascii "ID_M3" >>>>> .zero 1 >>>>> .ascii "ExpandHashTable" >>>>> .zero 1 >>>>> .ascii "ExpandIDs" >>>>> .zero 1 >>>>> .ascii "ExpandChars" >>>>> .zero 1 >>>>> .ascii "Compare" >>>>> .zero 1 >>>>> >>>>> If I change "" to "foo", I get: >>>>> >>>>> L_1: >>>>> 0 .long RTHooks__TextLitInfo >>>>> 4 .long RTHooks__TextLitGetChar >>>>> 8 .long RTHooks__TextLitGetWideChar >>>>> 12 .long RTHooks__TextLitGetChars >>>>> 16 .long RTHooks__TextLitGetWideChars >>>>> 20 .long 2 >>>>> 24 .long L_1 >>>>> .long 3 >>>>> .ascii "foo" >>>>> .zero 1 >>>>> .ascii "ID_M3" >>>>> >>>>> and it still crashes. >>>>> >>>>> >>>>> It seems to hit ID__Add twice when only once would be expected. >>>>> >>>>> >>>>> - Jay >>>>> >>>>> >>>>> ---------------------------------------- >>>>>> From: jay.krell at cornell.edu >>>>>> To: hosking at cs.purdue.edu >>>>>> Date: Sun, 16 Aug 2009 19:33:34 +0000 >>>>>> CC: m3devel at elegosoft.com >>>>>> Subject: Re: [M3devel] more crashers >>>>>> >>>>>> >>>>>> Could be. I've also seen it on PPC_DARWIN a while ago. I only >>>>>> recall seeing it on sparc and ppc. >>>>>> It doesn't always occur. >>>>>> >>>>>> >>>>>> Here is the m3browser crash on a system that can be debugged. >>>>>> See why I want the full paths in the debug info? >>>>>> >>>>>> >>>>>> C:\Users\jay\Desktop>\cygwin\bin\ssh xobsd. >>>>>> $ cd /cm3 >>>>>> $ cd bin >>>>>> $ export DISPLAY=192.168.1.120:0.0 >>>>>> $ gdb ./m3browser >>>>>> GNU gdb 6.3 >>>>>> This GDB was configured as "i386-unknown-openbsd4.5"... >>>>>> (gdb) r >>>>>> Starting program: /home/jay/cm3/bin/m3browser >>>>>> Program received signal SIGSEGV, Segmentation fault. >>>>>> [Switching to process 31063, thread 0x7eafe800] >>>>>> 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 >>>>>> 16 t.get_info (i); >>>>>> (gdb) bt >>>>>> #0 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 >>>>>> #1 0x09fd9464 in ID__Add (M3_Bd56fi_x=0x0) at ../src/ID.m3:48 >>>>>> #2 0x1c01e644 in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:37 >>>>>> #3 0x0156f1bc in RTLinker__RunMainBody (M3_DjPxE3_m=0x3c003ec0) >>>>>> at ../src/runtime/common/RTLinker.m3:399 >>>>>> #4 0x0156e576 in RTLinker__AddUnitI (M3_DjPxE3_m=0x3c003ec0) >>>>>> at ../src/runtime/common/RTLinker.m3:113 >>>>>> #5 0x0156e604 in RTLinker__AddUnit (M3_DjPxE5_b=0x1c01e54d) >>>>>> at ../src/runtime/common/RTLinker.m3:122 >>>>>> #6 0x1c004676 in main (argc=1, argv=0xcfbf6a3c, envp=0xcfbf6a44) >>>>>> at _m3main.mc:4 >>>>>> >>>>>> >>>>>> - Jay >>>>>> >>>>>> >>>>>> ________________________________ >>>>>>> From: hosking at cs.purdue.edu >>>>>>> To: jay.krell at cornell.edu >>>>>>> Date: Sun, 16 Aug 2009 15:26:49 -0400 >>>>>>> CC: m3devel at elegosoft.com >>>>>>> Subject: Re: [M3devel] more crashers >>>>>>> >>>>>>> Could this be endianness-related? >>>>>>> >>>>>>> On 16 Aug 2009, at 15:21, Jay K wrote: >>>>>>> >>>>>>> >>>>>>> I see the assertion failure on PPC_LINUX too. >>>>>>> I tried VAR defaultStackSize := 1024 * 1024; (not sure why >>>>>>> there was any suspicion of stack size). >>>>>>> >>>>>>> >>>>>>> Debugging doesn't work PPC_LINUX. >>>>>>> >>>>>>> >>>>>>> jay at plin:/cm3/bin$ gdb ./cm3 >>>>>>> GNU gdb 6.8-debian >>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>> This is free software: you are free to change and redistribute it. >>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>> "show copying" >>>>>>> and "show warranty" for details. >>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>> break ma(gdb) break main >>>>>>> Breakpoint 1 at 0x86fc4: file _m3main.mc, line 2. >>>>>>> (gdb) r >>>>>>> Starting program: /home/jay/cm3/bin/cm3 >>>>>>> Warning: >>>>>>> Cannot insert breakpoint 1. >>>>>>> Error accessing memory address 0x86fc4: Input/output error. >>>>>>> >>>>>>> >>>>>>> No problem with C: >>>>>>> >>>>>>> >>>>>>> jay at plin:/cm3/bin$ echo "main(){}"> 1.c >>>>>>> jay at plin:/cm3/bin$ gcc -g 1.c >>>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>>> GNU gdb 6.8-debian >>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>> This is free software: you are free to change and redistribute it. >>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>> "show copying" >>>>>>> and "show warranty" for details. >>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>> (gdb) break main >>>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>>> (gdb) r >>>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>>> Breakpoint 1, main () at 1.c:1 >>>>>>> 1 main(){} >>>>>>> (gdb) >>>>>>> >>>>>>> >>>>>>> jay at plin:/cm3/bin$ gcc -gstabs+ 1.c >>>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>>> GNU gdb 6.8-debian >>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>> This is free software: you are free to change and redistribute it. >>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>> "show copying" >>>>>>> and "show warranty" for details. >>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>> (gdb) break main >>>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>>> (gdb) r >>>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>>> Breakpoint 1, main () at 1.c:1 >>>>>>> 1 main(){} >>>>>>> >>>>>>> >>>>>>> jay at plin:/cm3/bin$ gcc -gstabs 1.c >>>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>>> GNU gdb 6.8-debian >>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>> This is free software: you are free to change and redistribute it. >>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>> "show copying" >>>>>>> and "show warranty" for details. >>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>> (gdb) break main >>>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>>> (gdb) r >>>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>>> Breakpoint 1, main () at 1.c:1 >>>>>>> 1 main(){} >>>>>>> (gdb) >>>>>>> >>>>>>> >>>>>>> - Jay >>>>>>> >>>>>>> >>>>>>> ---------------------------------------- >>>>>>> From: jay.krell at cornell.edu >>>>>>> To: m3devel at elegosoft.com >>>>>>> Subject: more crashers >>>>>>> Date: Sun, 16 Aug 2009 10:06:15 +0000 >>>>>>> >>>>>>> >>>>>>> This is head on SOLgnu: >>>>>>> I'll try another and debug and see if fix is easy. >>>>>>> >>>>>>> -bash-3.00$ ./m3browser >>>>>>> >>>>>>> *** >>>>>>> *** runtime error: >>>>>>> *** Segmentation violation - possible attempt to dereference NIL >>>>>>> *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/String16.m3 >>>>>>> *** >>>>>>> >>>>>>> -bash-3.00$ ./visobliq >>>>>>> Internal Obliq interpreter installed... >>>>>>> Establishing 'templates' >>>>>>> (Created frame 'templates') >>>>>>> let >>>>>>> Templates = >>>>>>> {boolean=> ... , >>>>>>> browser=> ... , >>>>>>> button=> ... , >>>>>>> choice=> ... , >>>>>>> filebrowser=> ... , >>>>>>> form=> ... , >>>>>>> frame=> ... , >>>>>>> hscroll=> ... , >>>>>>> menu=> ... , >>>>>>> numeric=> ... , >>>>>>> text=> ... , >>>>>>> textedit=> ... , >>>>>>> typein=> ... , >>>>>>> video=> ... , >>>>>>> vscroll=> ... } >>>>>>> Establishing 'vowidgets' >>>>>>> (Created frame 'vowidgets') >>>>>>> ok >>>>>>> Establishing 'vocheckpt' >>>>>>> (Created frame 'vocheckpt') >>>>>>> ok >>>>>>> Establishing 'volib' >>>>>>> (Created frame 'volib') >>>>>>> Segmentation Fault (core dumped) >>>>>>> -bash-3.00$ >>>>>>> >>>>>>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Mon Aug 17 13:37:06 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 17 Aug 2009 11:37:06 +0000 Subject: [M3devel] CM3 Release Engineering and Feedback In-Reply-To: <20090817133525.c8kdk3g0o4w4g0ok@mail.elegosoft.com> References: <20090813143806.udmpiz76ecg0scgs@mail.elegosoft.com> <20090816171032.GA27461@topoi.pooq.com> <20090817133525.c8kdk3g0o4w4g0ok@mail.elegosoft.com> Message-ID: > If there are no more new unexpected crashes I cried wolf by accident. Neither the m3browser nor visobliq crashes were particularly interesting, though somewhat. There is still formsedit though. :( - Jay ---------------------------------------- > Date: Mon, 17 Aug 2009 13:35:25 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] CM3 Release Engineering and Feedback > > Quoting hendrik at topoi.pooq.com: > >> On Thu, Aug 13, 2009 at 02:38:06PM +0200, Olaf Wagner wrote: >>> Quoting hendrik at topoi.pooq.com: >>> >>>>On Wed, Aug 12, 2009 at 01:10:38AM +0200, Olaf Wagner wrote: >>>>> o There hasn't been much feedback, neither from the list of active >>>>> developers nor from end users for RC2. I'd really appreciate some >>>>> more reports about installation attempts and the problems encountered. >>>> >>>>Well, I'll provide more with the next RC. The hudson directory was >>>>pretty much a show-stopper. I'd expect the same problem to be there on >>>>the other platforms. >>> >>> The simple work-around would be to call cm3 -build on the packages >>> again, which should only adapt the broken .M3SHIP files. >> >> I tried that , but it failed, complaining > > Yes. Sorry. Those were the bogus collection dependencies. They should > now be 'fixed', too (at least much easier to understand). I've invested > some hours to compute the depdenencies on package and collection level > several times and made some changes to the collection classification > in pkginfo.txt. > > [...] > >> In any case, this will be an obsolete by the time RC3 starts to roll >> out. So focus on that rather than fixing the workaround. > > If there are no more new unexpected crashes, I'll build the RC3 archives > soon. It should be much easier this time. We'll see... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Mon Aug 17 13:48:30 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 17 Aug 2009 11:48:30 +0000 Subject: [M3devel] i386 vs. i486 vs. i586 vs. i686? Message-ID: At some point I'd like to merge m3cc/src/platforms.quake and m3gdb/src/platforms.quake, and put the result in cm3cfg.common, or even cm3. A small sticking point here is which of [3-6]i86 to use in various places. i386 is pretty darn old (1985?), missing some useful instructions, and I believe not particularly well supported by anyone any longer. Beyond that I'm not sure. I don't think i486 has been available for sale in over 10 years, but maybe in embedded systems?? I believe i686 encompasses Pentium Pro, Pentium II, Pentium III, Pentium IV, Core, Core 2, etc. I think I bought a Pentium in 1995. However I have two machines that I'm not sure are i686. Hm, er, I guess just one machine. I thought the "Pentium M" sticker might imply i586, but there is evidence otherwise: The OpenBSD/i386 Hudson machine: $ sysctl | grep hw hw.machine=i386 hw.model=Intel(R) Pentium(R) M processor 1.70GHz ("GenuineIntel" 686-class) hw.ncpu=1 hw.product=HP Compaq nc4010 (PF672AA#ABA) $ a "Fit PC 2.0", doesn't get much use: jay at xlin ~ $ uname -a Linux xlin 2.6.25-gentoo-r7 #5 Sun Oct 5 18:59:56 Local time zone must be set--s ee zic manua i586 Geode(TM) Integrated Processor by AMD PCS AuthenticAMD GNU/Lin ux jay at xlin ~ $ That really might might not be "i686". I guess, er, um, for m3gdb, there's no point in going past i386? The point is the target really, not the host. gdb is not performance sensitive. gcc is probably always going to be slow, but it can produce faster/slower code. This stuff is only used currently for cross builds, though it might be reasonable to use it for native builds too. Like, you know, if I build on a Core 2, you probably don't want the cm3cg producing code that doesn't work on a Pentium IV or somesuch. - Jay From jay.krell at cornell.edu Mon Aug 17 15:18:43 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 17 Aug 2009 13:18:43 +0000 Subject: [M3devel] more crashers In-Reply-To: <20090817133026.6v9cm3cu0wwkc08k@mail.elegosoft.com> References: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> <20090817133026.6v9cm3cu0wwkc08k@mail.elegosoft.com> Message-ID: Not as much luck as I'd like. PTHREAD_STACK_MIN Solaris: 4K Linux/sparc: 24K Linux/x86: 16K Linux/powerpc: 128K The overflowing stack, with 16K: current thread: t at 12 =>[1] Rd__CharsReady(0xfd61a00c, 0xfd617410, 0xfd59fb6c, 0x0, 0xfd59fb84, 0xfd59 fb8c), at 0xfec58578 ---- 1 following frame from gwindows -- possible stack overflow [2] SynScan__LookChar(0xfd883670, 0xfd8aa81c, 0xfd59fb6c, 0x0, 0xfd59fb84, 0xf d59fb8c), at 0xfead71fc [3] SynScan__NextToken(0xfd883670, 0xfd8ab980, 0x9, 0x0, 0xfd59fb84, 0xfd59fb8 c), at 0xfead91c4 [4] SynScan__LookToken(0xfd883670, 0x4ae, 0x9, 0x0, 0xfd59fb84, 0xfd59fb8c), a t 0xfead9628 [5] SynScan__HaveTokenName(0xfd883670, 0xfd5f7768, 0x8, 0x0, 0xfd59fb84, 0xfd5 9fb8c), at 0xfeadd084 [6] SynParse__Read0(0xfd883654, 0xfd6174ac, 0xfd59fb6c, 0x0, 0xfd59fb84, 0xfd5 9fb8c), at 0xfeae4760 [7] SynParse__Read0(0xfd883654, 0xfd617460, 0xfd59fb6c, 0x0, 0xfd59fb84, 0xfd5 9fb8c), at 0xfeae5e8c hundreds of frames of Lots of SynParse__Read0, using about 1K per frame; there is a try in there. d59fb8c), at 0xfeae348c [666] SynParse__Read0(0xfd883654, 0xfd6172d8, 0xfd59fb6c, 0x0, 0xfd59fb84, 0xf d59fb8c), at 0xfeae5e8c [667] SynParse__Read0(0xfd883654, 0xfd8aaa6c, 0xfd59fb6c, 0x0, 0xfd59fb84, 0xf d59fb8c), at 0xfeae3dd4 [668] SynParse__Read0(0xfd883654, 0xfd617288, 0xfd59fb6c, 0x0, 0xfd59fb84, 0xf d59fb8c), at 0xfeae3168 [669] SynParse__Read0(0xfd883654, 0xfd8aacec, 0xfd59fb6c, 0x0, 0xfd59fb84, 0xf d59fb8c), at 0xfeae6230 [670] SynParse__Read1(0xfd883654, 0xfd8aacec, 0x0, 0xfd59fb84, 0xfd59fb8c, 0x0 ), at 0xfeae2674 [671] SynParse__Read(0xfd883654, 0xfd8aacec, 0x0, 0xfd803a00, 0x0, 0xfebee308) , at 0xfeadfb60 [672] SynParse__ReadNonTerminal(0xfd883654, 0xfefed45c, 0xfd61b250, 0xfd61b8cc , 0xfd61b280, 0xfd89a27c), at 0xfeadfae8 [673] ObliqParser__ParsePhrase(0xfd883654, 0x0, 0xfd61b250, 0xfd61b8cc, 0xfd61 b280, 0x0), at 0xfefd5ff0 [674] ObliqOnline__Interact(0xfd89a848, 0xc32a0, 0xfd61a00c, 0x1, 0x1, 0xfebee 308), at 0xff36b80c [675] ObliqRuntime__ForkedDo(0xfd3ddfb8, 0x9658aac0, 0xff000000, 0x0, 0xfd9100 90, 0x0), at 0x80db0 [676] ThreadPThread__RunThread(0xef2b0, 0x0, 0x0, 0x0, 0xfd803a00, 0x1), at 0x fe06bc88 [677] ThreadPThread__ThreadBase(0xef2b0, 0xfd5a0000, 0x0, 0x0, 0xfe06b7c8, 0x1 ), at 0xfe06b818 One of the problems with defining a unit of stack size is the large variety of jmpbuf size. But heck, why 1K per frame here when SOLsun has a stack walker? Hm. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Subject: RE: [M3devel] more crashers > Date: Mon, 17 Aug 2009 11:35:40 +0000 > > > - I think the whole machine stack mechanism is pretty hopelessly broken. > Not just in Modula-3. Therefore my enthusiasm to attempt to "fix" > it -- which is impossible -- isn't very high. > > - I'm hoping to find that no platform other than Solaris lets you > even use such a small stack. I have to experiment some in a bit. > Depending on that experiment, we'll be in a better position, without > any further changes, but again, depending on what I find. > That is, if every other platform already had a larger stack, then this > just brings Solaris inline with the rest. If the other platforms > were actually successfully using a 4K stack, then indeed a problem. > > > - It could also be a factor of optimization. > Maybe ensuring -O2 or -O3 is used more would cover it up?? > > > - Or some other changes. > That is, if we have drastically increased stack usage, we should try > to reduce it back down. But given that 4K was the previous value > and even 16K doesn't work...I'm not hopeful we could fit it back down in 4K. > > It is easy enough to see the bug and then look at the various frames > and see if they use a lot of stack and can be reduced. > > - Jay > > > > ---------------------------------------- >> Date: Mon, 17 Aug 2009 13:30:26 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] more crashers >> >> Quoting Jay K : >> >>> visobliq was stack overflow. >>> Raising the default from 4K to 16K didn't fix, but 32K did. >> >> We need to address this somehow. It cannot be correct if the user >> needs to increase the default stack size on one platform by 8 >> and not at all on another. Do we have any concept of a 'standard >> stack size unit' ;-)? Something that can be easily understood and >> implemented and be used instead of the machine words in the current >> interfaces? Any ideas? >> >> Olaf >> >> >>> - Jay >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: hosking at cs.purdue.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: RE: [M3devel] more crashers >>>> Date: Sun, 16 Aug 2009 20:32:31 +0000 >>>> >>>> >>>> m3browser: >>>> >>>> It is specific to my config file >>>> m3-sys/cminstall/src/config-no-install/cm3.cfg that reachs back >>>> into the source tree. It won't happen with what most people do. I >>>> have to do that M3Predefines or such work so that all the uses of >>>> m3quake besides cm3 are much more like cm3. >>>> >>>> >>>> visobliq: >>>> not the same thing >>>> Does not occur on Linux/x86 or Linux/sparc. >>>> They do print >>>> Syntax error just before: -helvetica-bold-\*R-\*240-\*\") (LabelFo ... >>>> ill-formed character escape sequence >>>> Error detected (file file generated by Visual Obliq) (line 18, char 10) >>>> VideoVBT.Start Jv ServerFailure:errno=0 >>>> >>>> but then gui comes up. >>>> I'll have to finish my Solaris reinstall and get dbx. >>>> >>>> >>>> - Jay >>>> >>>> >>>> ---------------------------------------- >>>>> From: jay.krell at cornell.edu >>>>> To: hosking at cs.purdue.edu >>>>> Date: Sun, 16 Aug 2009 20:22:49 +0000 >>>>> CC: m3devel at elegosoft.com >>>>> Subject: Re: [M3devel] more crashers >>>>> >>>>> >>>>> sorry, this is simple. >>>>> >>>>> derived_dirs := IntList.List1 (ID.Add (MxConfig.Get("BUILD_DIR"))); >>>>> >>>>> >>>>> - Jay >>>>> >>>>> >>>>> >>>>> ---------------------------------------- >>>>>> From: jay.krell at cornell.edu >>>>>> To: hosking at cs.purdue.edu >>>>>> Date: Sun, 16 Aug 2009 19:52:03 +0000 >>>>>> CC: m3devel at elegosoft.com >>>>>> Subject: Re: [M3devel] more crashers >>>>>> >>>>>> >>>>>> Here is the relevant code in m3browser ID.m3: >>>>>> >>>>>> >>>>>> C:\dev2\cm3.2\m3-tools\m3markup\src\ID.m3(38): empty_id := Add (""); >>>>>> >>>>>> empty_id := Add (""); >>>>>> >>>>>> (*-------------------------------------------------------------- >>>>>> exported ---*) >>>>>> PROCEDURE Add (x: TEXT): T = >>>>>> VAR >>>>>> t: T; >>>>>> a: REF ARRAY OF CHAR; >>>>>> l: INTEGER; >>>>>> BEGIN >>>>>> l := Text.Length(x); >>>>>> ... >>>>>> END Add; >>>>>> >>>>>> >>>>>> The empty string constant ends up as null. >>>>>> >>>>>> .stabn 68,0,38,.LM115-.LFBB10 >>>>>> .LM115: >>>>>> movl L_1 at GOT(%ebx), %eax >>>>>> leal 24(%eax), %eax >>>>>> movl %eax, (%esp) >>>>>> call ID__Add at PLT >>>>>> movl %eax, -8(%ebp) >>>>>> movl -8(%ebp), %ecx >>>>>> movl MM_ID at GOT(%ebx), %edx >>>>>> movl 248(%edx), %eax >>>>>> andl $0, %eax >>>>>> orl %ecx, %eax >>>>>> movl %eax, 248(%edx) >>>>>> .L136: >>>>>> movl MM_ID at GOT(%ebx), %eax >>>>>> .LBE16: >>>>>> addl $52, %esp >>>>>> popl %ebx >>>>>> popl %ebp >>>>>> ret >>>>>> >>>>>> L_1: >>>>>> 0 .long RTHooks__TextLitInfo >>>>>> 4 .long RTHooks__TextLitGetChar >>>>>> 8 .long RTHooks__TextLitGetWideChar >>>>>> 12 .long RTHooks__TextLitGetChars >>>>>> 16 .long RTHooks__TextLitGetWideChars >>>>>> 20 .long 2 >>>>>> 24 .long L_1 >>>>>> .long 0 >>>>>> .zero 4 >>>>>> .ascii "ID_M3" >>>>>> .zero 1 >>>>>> .ascii "ExpandHashTable" >>>>>> .zero 1 >>>>>> .ascii "ExpandIDs" >>>>>> .zero 1 >>>>>> .ascii "ExpandChars" >>>>>> .zero 1 >>>>>> .ascii "Compare" >>>>>> .zero 1 >>>>>> >>>>>> If I change "" to "foo", I get: >>>>>> >>>>>> L_1: >>>>>> 0 .long RTHooks__TextLitInfo >>>>>> 4 .long RTHooks__TextLitGetChar >>>>>> 8 .long RTHooks__TextLitGetWideChar >>>>>> 12 .long RTHooks__TextLitGetChars >>>>>> 16 .long RTHooks__TextLitGetWideChars >>>>>> 20 .long 2 >>>>>> 24 .long L_1 >>>>>> .long 3 >>>>>> .ascii "foo" >>>>>> .zero 1 >>>>>> .ascii "ID_M3" >>>>>> >>>>>> and it still crashes. >>>>>> >>>>>> >>>>>> It seems to hit ID__Add twice when only once would be expected. >>>>>> >>>>>> >>>>>> - Jay >>>>>> >>>>>> >>>>>> ---------------------------------------- >>>>>>> From: jay.krell at cornell.edu >>>>>>> To: hosking at cs.purdue.edu >>>>>>> Date: Sun, 16 Aug 2009 19:33:34 +0000 >>>>>>> CC: m3devel at elegosoft.com >>>>>>> Subject: Re: [M3devel] more crashers >>>>>>> >>>>>>> >>>>>>> Could be. I've also seen it on PPC_DARWIN a while ago. I only >>>>>>> recall seeing it on sparc and ppc. >>>>>>> It doesn't always occur. >>>>>>> >>>>>>> >>>>>>> Here is the m3browser crash on a system that can be debugged. >>>>>>> See why I want the full paths in the debug info? >>>>>>> >>>>>>> >>>>>>> C:\Users\jay\Desktop>\cygwin\bin\ssh xobsd. >>>>>>> $ cd /cm3 >>>>>>> $ cd bin >>>>>>> $ export DISPLAY=192.168.1.120:0.0 >>>>>>> $ gdb ./m3browser >>>>>>> GNU gdb 6.3 >>>>>>> This GDB was configured as "i386-unknown-openbsd4.5"... >>>>>>> (gdb) r >>>>>>> Starting program: /home/jay/cm3/bin/m3browser >>>>>>> Program received signal SIGSEGV, Segmentation fault. >>>>>>> [Switching to process 31063, thread 0x7eafe800] >>>>>>> 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 >>>>>>> 16 t.get_info (i); >>>>>>> (gdb) bt >>>>>>> #0 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 >>>>>>> #1 0x09fd9464 in ID__Add (M3_Bd56fi_x=0x0) at ../src/ID.m3:48 >>>>>>> #2 0x1c01e644 in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:37 >>>>>>> #3 0x0156f1bc in RTLinker__RunMainBody (M3_DjPxE3_m=0x3c003ec0) >>>>>>> at ../src/runtime/common/RTLinker.m3:399 >>>>>>> #4 0x0156e576 in RTLinker__AddUnitI (M3_DjPxE3_m=0x3c003ec0) >>>>>>> at ../src/runtime/common/RTLinker.m3:113 >>>>>>> #5 0x0156e604 in RTLinker__AddUnit (M3_DjPxE5_b=0x1c01e54d) >>>>>>> at ../src/runtime/common/RTLinker.m3:122 >>>>>>> #6 0x1c004676 in main (argc=1, argv=0xcfbf6a3c, envp=0xcfbf6a44) >>>>>>> at _m3main.mc:4 >>>>>>> >>>>>>> >>>>>>> - Jay >>>>>>> >>>>>>> >>>>>>> ________________________________ >>>>>>>> From: hosking at cs.purdue.edu >>>>>>>> To: jay.krell at cornell.edu >>>>>>>> Date: Sun, 16 Aug 2009 15:26:49 -0400 >>>>>>>> CC: m3devel at elegosoft.com >>>>>>>> Subject: Re: [M3devel] more crashers >>>>>>>> >>>>>>>> Could this be endianness-related? >>>>>>>> >>>>>>>> On 16 Aug 2009, at 15:21, Jay K wrote: >>>>>>>> >>>>>>>> >>>>>>>> I see the assertion failure on PPC_LINUX too. >>>>>>>> I tried VAR defaultStackSize := 1024 * 1024; (not sure why >>>>>>>> there was any suspicion of stack size). >>>>>>>> >>>>>>>> >>>>>>>> Debugging doesn't work PPC_LINUX. >>>>>>>> >>>>>>>> >>>>>>>> jay at plin:/cm3/bin$ gdb ./cm3 >>>>>>>> GNU gdb 6.8-debian >>>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>> This is free software: you are free to change and redistribute it. >>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>> "show copying" >>>>>>>> and "show warranty" for details. >>>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>>> break ma(gdb) break main >>>>>>>> Breakpoint 1 at 0x86fc4: file _m3main.mc, line 2. >>>>>>>> (gdb) r >>>>>>>> Starting program: /home/jay/cm3/bin/cm3 >>>>>>>> Warning: >>>>>>>> Cannot insert breakpoint 1. >>>>>>>> Error accessing memory address 0x86fc4: Input/output error. >>>>>>>> >>>>>>>> >>>>>>>> No problem with C: >>>>>>>> >>>>>>>> >>>>>>>> jay at plin:/cm3/bin$ echo "main(){}"> 1.c >>>>>>>> jay at plin:/cm3/bin$ gcc -g 1.c >>>>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>>>> GNU gdb 6.8-debian >>>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>> This is free software: you are free to change and redistribute it. >>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>> "show copying" >>>>>>>> and "show warranty" for details. >>>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>>> (gdb) break main >>>>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>>>> (gdb) r >>>>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>>>> Breakpoint 1, main () at 1.c:1 >>>>>>>> 1 main(){} >>>>>>>> (gdb) >>>>>>>> >>>>>>>> >>>>>>>> jay at plin:/cm3/bin$ gcc -gstabs+ 1.c >>>>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>>>> GNU gdb 6.8-debian >>>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>> This is free software: you are free to change and redistribute it. >>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>> "show copying" >>>>>>>> and "show warranty" for details. >>>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>>> (gdb) break main >>>>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>>>> (gdb) r >>>>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>>>> Breakpoint 1, main () at 1.c:1 >>>>>>>> 1 main(){} >>>>>>>> >>>>>>>> >>>>>>>> jay at plin:/cm3/bin$ gcc -gstabs 1.c >>>>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>>>> GNU gdb 6.8-debian >>>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>> This is free software: you are free to change and redistribute it. >>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>> "show copying" >>>>>>>> and "show warranty" for details. >>>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>>> (gdb) break main >>>>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>>>> (gdb) r >>>>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>>>> Breakpoint 1, main () at 1.c:1 >>>>>>>> 1 main(){} >>>>>>>> (gdb) >>>>>>>> >>>>>>>> >>>>>>>> - Jay >>>>>>>> >>>>>>>> >>>>>>>> ---------------------------------------- >>>>>>>> From: jay.krell at cornell.edu >>>>>>>> To: m3devel at elegosoft.com >>>>>>>> Subject: more crashers >>>>>>>> Date: Sun, 16 Aug 2009 10:06:15 +0000 >>>>>>>> >>>>>>>> >>>>>>>> This is head on SOLgnu: >>>>>>>> I'll try another and debug and see if fix is easy. >>>>>>>> >>>>>>>> -bash-3.00$ ./m3browser >>>>>>>> >>>>>>>> *** >>>>>>>> *** runtime error: >>>>>>>> *** Segmentation violation - possible attempt to dereference NIL >>>>>>>> *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/String16.m3 >>>>>>>> *** >>>>>>>> >>>>>>>> -bash-3.00$ ./visobliq >>>>>>>> Internal Obliq interpreter installed... >>>>>>>> Establishing 'templates' >>>>>>>> (Created frame 'templates') >>>>>>>> let >>>>>>>> Templates = >>>>>>>> {boolean=> ... , >>>>>>>> browser=> ... , >>>>>>>> button=> ... , >>>>>>>> choice=> ... , >>>>>>>> filebrowser=> ... , >>>>>>>> form=> ... , >>>>>>>> frame=> ... , >>>>>>>> hscroll=> ... , >>>>>>>> menu=> ... , >>>>>>>> numeric=> ... , >>>>>>>> text=> ... , >>>>>>>> textedit=> ... , >>>>>>>> typein=> ... , >>>>>>>> video=> ... , >>>>>>>> vscroll=> ... } >>>>>>>> Establishing 'vowidgets' >>>>>>>> (Created frame 'vowidgets') >>>>>>>> ok >>>>>>>> Establishing 'vocheckpt' >>>>>>>> (Created frame 'vocheckpt') >>>>>>>> ok >>>>>>>> Establishing 'volib' >>>>>>>> (Created frame 'volib') >>>>>>>> Segmentation Fault (core dumped) >>>>>>>> -bash-3.00$ >>>>>>>> >>>>>>>> >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> From hosking at cs.purdue.edu Mon Aug 17 16:47:46 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 17 Aug 2009 10:47:46 -0400 Subject: [M3devel] more crashers In-Reply-To: References: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> <20090817133026.6v9cm3cu0wwkc08k@mail.elegosoft.com> Message-ID: Indeed, we might be better off investing effort in getting rid of try- blocks implemented using setjmp/longjmp so as to avoid the stack- allocated jmpbuf state. Or perhaps allocate that state in the heap. On 17 Aug 2009, at 09:18, Jay K wrote: > > Not as much luck as I'd like. > > > PTHREAD_STACK_MIN > Solaris: 4K > Linux/sparc: 24K > Linux/x86: 16K > Linux/powerpc: 128K > > > The overflowing stack, with 16K: > > > current thread: t at 12 > =>[1] Rd__CharsReady(0xfd61a00c, 0xfd617410, 0xfd59fb6c, 0x0, > 0xfd59fb84, 0xfd59 > fb8c), at 0xfec58578 > ---- 1 following frame from gwindows -- possible stack overflow > [2] SynScan__LookChar(0xfd883670, 0xfd8aa81c, 0xfd59fb6c, 0x0, > 0xfd59fb84, 0xf > d59fb8c), at 0xfead71fc > [3] SynScan__NextToken(0xfd883670, 0xfd8ab980, 0x9, 0x0, > 0xfd59fb84, 0xfd59fb8 > c), at 0xfead91c4 > [4] SynScan__LookToken(0xfd883670, 0x4ae, 0x9, 0x0, 0xfd59fb84, > 0xfd59fb8c), a > t 0xfead9628 > [5] SynScan__HaveTokenName(0xfd883670, 0xfd5f7768, 0x8, 0x0, > 0xfd59fb84, 0xfd5 > 9fb8c), at 0xfeadd084 > [6] SynParse__Read0(0xfd883654, 0xfd6174ac, 0xfd59fb6c, 0x0, > 0xfd59fb84, 0xfd5 > 9fb8c), at 0xfeae4760 > [7] SynParse__Read0(0xfd883654, 0xfd617460, 0xfd59fb6c, 0x0, > 0xfd59fb84, 0xfd5 > 9fb8c), at 0xfeae5e8c > > > hundreds of frames of Lots of SynParse__Read0, using about 1K per > frame; there is a try in there. > > d59fb8c), at 0xfeae348c > [666] SynParse__Read0(0xfd883654, 0xfd6172d8, 0xfd59fb6c, 0x0, > 0xfd59fb84, 0xf > d59fb8c), at 0xfeae5e8c > [667] SynParse__Read0(0xfd883654, 0xfd8aaa6c, 0xfd59fb6c, 0x0, > 0xfd59fb84, 0xf > d59fb8c), at 0xfeae3dd4 > [668] SynParse__Read0(0xfd883654, 0xfd617288, 0xfd59fb6c, 0x0, > 0xfd59fb84, 0xf > d59fb8c), at 0xfeae3168 > [669] SynParse__Read0(0xfd883654, 0xfd8aacec, 0xfd59fb6c, 0x0, > 0xfd59fb84, 0xf > d59fb8c), at 0xfeae6230 > [670] SynParse__Read1(0xfd883654, 0xfd8aacec, 0x0, 0xfd59fb84, > 0xfd59fb8c, 0x0 > ), at 0xfeae2674 > [671] SynParse__Read(0xfd883654, 0xfd8aacec, 0x0, 0xfd803a00, 0x0, > 0xfebee308) > , at 0xfeadfb60 > [672] SynParse__ReadNonTerminal(0xfd883654, 0xfefed45c, 0xfd61b250, > 0xfd61b8cc > , 0xfd61b280, 0xfd89a27c), at 0xfeadfae8 > [673] ObliqParser__ParsePhrase(0xfd883654, 0x0, 0xfd61b250, > 0xfd61b8cc, 0xfd61 > b280, 0x0), at 0xfefd5ff0 > [674] ObliqOnline__Interact(0xfd89a848, 0xc32a0, 0xfd61a00c, 0x1, > 0x1, 0xfebee > 308), at 0xff36b80c > [675] ObliqRuntime__ForkedDo(0xfd3ddfb8, 0x9658aac0, 0xff000000, > 0x0, 0xfd9100 > 90, 0x0), at 0x80db0 > [676] ThreadPThread__RunThread(0xef2b0, 0x0, 0x0, 0x0, 0xfd803a00, > 0x1), at 0x > fe06bc88 > [677] ThreadPThread__ThreadBase(0xef2b0, 0xfd5a0000, 0x0, 0x0, > 0xfe06b7c8, 0x1 > ), at 0xfe06b818 > > > One of the problems with defining a unit of stack size is the large > variety of jmpbuf size. > But heck, why 1K per frame here when SOLsun has a stack walker? Hm. > > - Jay > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com; m3devel at elegosoft.com >> Subject: RE: [M3devel] more crashers >> Date: Mon, 17 Aug 2009 11:35:40 +0000 >> >> >> - I think the whole machine stack mechanism is pretty hopelessly >> broken. >> Not just in Modula-3. Therefore my enthusiasm to attempt to "fix" >> it -- which is impossible -- isn't very high. >> >> - I'm hoping to find that no platform other than Solaris lets you >> even use such a small stack. I have to experiment some in a bit. >> Depending on that experiment, we'll be in a better position, without >> any further changes, but again, depending on what I find. >> That is, if every other platform already had a larger stack, then >> this >> just brings Solaris inline with the rest. If the other platforms >> were actually successfully using a 4K stack, then indeed a problem. >> >> >> - It could also be a factor of optimization. >> Maybe ensuring -O2 or -O3 is used more would cover it up?? >> >> >> - Or some other changes. >> That is, if we have drastically increased stack usage, we should try >> to reduce it back down. But given that 4K was the previous value >> and even 16K doesn't work...I'm not hopeful we could fit it back >> down in 4K. >> >> It is easy enough to see the bug and then look at the various frames >> and see if they use a lot of stack and can be reduced. >> >> - Jay >> >> >> >> ---------------------------------------- >>> Date: Mon, 17 Aug 2009 13:30:26 +0200 >>> From: wagner at elegosoft.com >>> To: m3devel at elegosoft.com >>> Subject: Re: [M3devel] more crashers >>> >>> Quoting Jay K : >>> >>>> visobliq was stack overflow. >>>> Raising the default from 4K to 16K didn't fix, but 32K did. >>> >>> We need to address this somehow. It cannot be correct if the user >>> needs to increase the default stack size on one platform by 8 >>> and not at all on another. Do we have any concept of a 'standard >>> stack size unit' ;-)? Something that can be easily understood and >>> implemented and be used instead of the machine words in the current >>> interfaces? Any ideas? >>> >>> Olaf >>> >>> >>>> - Jay >>>> >>>> ---------------------------------------- >>>>> From: jay.krell at cornell.edu >>>>> To: hosking at cs.purdue.edu >>>>> CC: m3devel at elegosoft.com >>>>> Subject: RE: [M3devel] more crashers >>>>> Date: Sun, 16 Aug 2009 20:32:31 +0000 >>>>> >>>>> >>>>> m3browser: >>>>> >>>>> It is specific to my config file >>>>> m3-sys/cminstall/src/config-no-install/cm3.cfg that reachs back >>>>> into the source tree. It won't happen with what most people do. I >>>>> have to do that M3Predefines or such work so that all the uses of >>>>> m3quake besides cm3 are much more like cm3. >>>>> >>>>> >>>>> visobliq: >>>>> not the same thing >>>>> Does not occur on Linux/x86 or Linux/sparc. >>>>> They do print >>>>> Syntax error just before: -helvetica-bold-\*R-\*240-\*\") >>>>> (LabelFo ... >>>>> ill-formed character escape sequence >>>>> Error detected (file file generated by Visual Obliq) (line 18, >>>>> char 10) >>>>> VideoVBT.Start Jv ServerFailure:errno=0 >>>>> >>>>> but then gui comes up. >>>>> I'll have to finish my Solaris reinstall and get dbx. >>>>> >>>>> >>>>> - Jay >>>>> >>>>> >>>>> ---------------------------------------- >>>>>> From: jay.krell at cornell.edu >>>>>> To: hosking at cs.purdue.edu >>>>>> Date: Sun, 16 Aug 2009 20:22:49 +0000 >>>>>> CC: m3devel at elegosoft.com >>>>>> Subject: Re: [M3devel] more crashers >>>>>> >>>>>> >>>>>> sorry, this is simple. >>>>>> >>>>>> derived_dirs := IntList.List1 (ID.Add >>>>>> (MxConfig.Get("BUILD_DIR"))); >>>>>> >>>>>> >>>>>> - Jay >>>>>> >>>>>> >>>>>> >>>>>> ---------------------------------------- >>>>>>> From: jay.krell at cornell.edu >>>>>>> To: hosking at cs.purdue.edu >>>>>>> Date: Sun, 16 Aug 2009 19:52:03 +0000 >>>>>>> CC: m3devel at elegosoft.com >>>>>>> Subject: Re: [M3devel] more crashers >>>>>>> >>>>>>> >>>>>>> Here is the relevant code in m3browser ID.m3: >>>>>>> >>>>>>> >>>>>>> C:\dev2\cm3.2\m3-tools\m3markup\src\ID.m3(38): empty_id := Add >>>>>>> (""); >>>>>>> >>>>>>> empty_id := Add (""); >>>>>>> >>>>>>> (*-------------------------------------------------------------- >>>>>>> exported ---*) >>>>>>> PROCEDURE Add (x: TEXT): T = >>>>>>> VAR >>>>>>> t: T; >>>>>>> a: REF ARRAY OF CHAR; >>>>>>> l: INTEGER; >>>>>>> BEGIN >>>>>>> l := Text.Length(x); >>>>>>> ... >>>>>>> END Add; >>>>>>> >>>>>>> >>>>>>> The empty string constant ends up as null. >>>>>>> >>>>>>> .stabn 68,0,38,.LM115-.LFBB10 >>>>>>> .LM115: >>>>>>> movl L_1 at GOT(%ebx), %eax >>>>>>> leal 24(%eax), %eax >>>>>>> movl %eax, (%esp) >>>>>>> call ID__Add at PLT >>>>>>> movl %eax, -8(%ebp) >>>>>>> movl -8(%ebp), %ecx >>>>>>> movl MM_ID at GOT(%ebx), %edx >>>>>>> movl 248(%edx), %eax >>>>>>> andl $0, %eax >>>>>>> orl %ecx, %eax >>>>>>> movl %eax, 248(%edx) >>>>>>> .L136: >>>>>>> movl MM_ID at GOT(%ebx), %eax >>>>>>> .LBE16: >>>>>>> addl $52, %esp >>>>>>> popl %ebx >>>>>>> popl %ebp >>>>>>> ret >>>>>>> >>>>>>> L_1: >>>>>>> 0 .long RTHooks__TextLitInfo >>>>>>> 4 .long RTHooks__TextLitGetChar >>>>>>> 8 .long RTHooks__TextLitGetWideChar >>>>>>> 12 .long RTHooks__TextLitGetChars >>>>>>> 16 .long RTHooks__TextLitGetWideChars >>>>>>> 20 .long 2 >>>>>>> 24 .long L_1 >>>>>>> .long 0 >>>>>>> .zero 4 >>>>>>> .ascii "ID_M3" >>>>>>> .zero 1 >>>>>>> .ascii "ExpandHashTable" >>>>>>> .zero 1 >>>>>>> .ascii "ExpandIDs" >>>>>>> .zero 1 >>>>>>> .ascii "ExpandChars" >>>>>>> .zero 1 >>>>>>> .ascii "Compare" >>>>>>> .zero 1 >>>>>>> >>>>>>> If I change "" to "foo", I get: >>>>>>> >>>>>>> L_1: >>>>>>> 0 .long RTHooks__TextLitInfo >>>>>>> 4 .long RTHooks__TextLitGetChar >>>>>>> 8 .long RTHooks__TextLitGetWideChar >>>>>>> 12 .long RTHooks__TextLitGetChars >>>>>>> 16 .long RTHooks__TextLitGetWideChars >>>>>>> 20 .long 2 >>>>>>> 24 .long L_1 >>>>>>> .long 3 >>>>>>> .ascii "foo" >>>>>>> .zero 1 >>>>>>> .ascii "ID_M3" >>>>>>> >>>>>>> and it still crashes. >>>>>>> >>>>>>> >>>>>>> It seems to hit ID__Add twice when only once would be expected. >>>>>>> >>>>>>> >>>>>>> - Jay >>>>>>> >>>>>>> >>>>>>> ---------------------------------------- >>>>>>>> From: jay.krell at cornell.edu >>>>>>>> To: hosking at cs.purdue.edu >>>>>>>> Date: Sun, 16 Aug 2009 19:33:34 +0000 >>>>>>>> CC: m3devel at elegosoft.com >>>>>>>> Subject: Re: [M3devel] more crashers >>>>>>>> >>>>>>>> >>>>>>>> Could be. I've also seen it on PPC_DARWIN a while ago. I only >>>>>>>> recall seeing it on sparc and ppc. >>>>>>>> It doesn't always occur. >>>>>>>> >>>>>>>> >>>>>>>> Here is the m3browser crash on a system that can be debugged. >>>>>>>> See why I want the full paths in the debug info? >>>>>>>> >>>>>>>> >>>>>>>> C:\Users\jay\Desktop>\cygwin\bin\ssh xobsd. >>>>>>>> $ cd /cm3 >>>>>>>> $ cd bin >>>>>>>> $ export DISPLAY=192.168.1.120:0.0 >>>>>>>> $ gdb ./m3browser >>>>>>>> GNU gdb 6.3 >>>>>>>> This GDB was configured as "i386-unknown-openbsd4.5"... >>>>>>>> (gdb) r >>>>>>>> Starting program: /home/jay/cm3/bin/m3browser >>>>>>>> Program received signal SIGSEGV, Segmentation fault. >>>>>>>> [Switching to process 31063, thread 0x7eafe800] >>>>>>>> 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/ >>>>>>>> Text.m3:16 >>>>>>>> 16 t.get_info (i); >>>>>>>> (gdb) bt >>>>>>>> #0 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/ >>>>>>>> text/Text.m3:16 >>>>>>>> #1 0x09fd9464 in ID__Add (M3_Bd56fi_x=0x0) at ../src/ID.m3:48 >>>>>>>> #2 0x1c01e644 in Main_M3 (M3_AcxOUs_mode=1) at ../src/ >>>>>>>> Main.m3:37 >>>>>>>> #3 0x0156f1bc in RTLinker__RunMainBody (M3_DjPxE3_m=0x3c003ec0) >>>>>>>> at ../src/runtime/common/RTLinker.m3:399 >>>>>>>> #4 0x0156e576 in RTLinker__AddUnitI (M3_DjPxE3_m=0x3c003ec0) >>>>>>>> at ../src/runtime/common/RTLinker.m3:113 >>>>>>>> #5 0x0156e604 in RTLinker__AddUnit (M3_DjPxE5_b=0x1c01e54d) >>>>>>>> at ../src/runtime/common/RTLinker.m3:122 >>>>>>>> #6 0x1c004676 in main (argc=1, argv=0xcfbf6a3c, >>>>>>>> envp=0xcfbf6a44) >>>>>>>> at _m3main.mc:4 >>>>>>>> >>>>>>>> >>>>>>>> - Jay >>>>>>>> >>>>>>>> >>>>>>>> ________________________________ >>>>>>>>> From: hosking at cs.purdue.edu >>>>>>>>> To: jay.krell at cornell.edu >>>>>>>>> Date: Sun, 16 Aug 2009 15:26:49 -0400 >>>>>>>>> CC: m3devel at elegosoft.com >>>>>>>>> Subject: Re: [M3devel] more crashers >>>>>>>>> >>>>>>>>> Could this be endianness-related? >>>>>>>>> >>>>>>>>> On 16 Aug 2009, at 15:21, Jay K wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> I see the assertion failure on PPC_LINUX too. >>>>>>>>> I tried VAR defaultStackSize := 1024 * 1024; (not sure why >>>>>>>>> there was any suspicion of stack size). >>>>>>>>> >>>>>>>>> >>>>>>>>> Debugging doesn't work PPC_LINUX. >>>>>>>>> >>>>>>>>> >>>>>>>>> jay at plin:/cm3/bin$ gdb ./cm3 >>>>>>>>> GNU gdb 6.8-debian >>>>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>>> This is free software: you are free to change and >>>>>>>>> redistribute it. >>>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>>> "show copying" >>>>>>>>> and "show warranty" for details. >>>>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>>>> break ma(gdb) break main >>>>>>>>> Breakpoint 1 at 0x86fc4: file _m3main.mc, line 2. >>>>>>>>> (gdb) r >>>>>>>>> Starting program: /home/jay/cm3/bin/cm3 >>>>>>>>> Warning: >>>>>>>>> Cannot insert breakpoint 1. >>>>>>>>> Error accessing memory address 0x86fc4: Input/output error. >>>>>>>>> >>>>>>>>> >>>>>>>>> No problem with C: >>>>>>>>> >>>>>>>>> >>>>>>>>> jay at plin:/cm3/bin$ echo "main(){}"> 1.c >>>>>>>>> jay at plin:/cm3/bin$ gcc -g 1.c >>>>>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>>>>> GNU gdb 6.8-debian >>>>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>>> This is free software: you are free to change and >>>>>>>>> redistribute it. >>>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>>> "show copying" >>>>>>>>> and "show warranty" for details. >>>>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>>>> (gdb) break main >>>>>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>>>>> (gdb) r >>>>>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>>>>> Breakpoint 1, main () at 1.c:1 >>>>>>>>> 1 main(){} >>>>>>>>> (gdb) >>>>>>>>> >>>>>>>>> >>>>>>>>> jay at plin:/cm3/bin$ gcc -gstabs+ 1.c >>>>>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>>>>> GNU gdb 6.8-debian >>>>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>>> This is free software: you are free to change and >>>>>>>>> redistribute it. >>>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>>> "show copying" >>>>>>>>> and "show warranty" for details. >>>>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>>>> (gdb) break main >>>>>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>>>>> (gdb) r >>>>>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>>>>> Breakpoint 1, main () at 1.c:1 >>>>>>>>> 1 main(){} >>>>>>>>> >>>>>>>>> >>>>>>>>> jay at plin:/cm3/bin$ gcc -gstabs 1.c >>>>>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>>>>> GNU gdb 6.8-debian >>>>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>>> This is free software: you are free to change and >>>>>>>>> redistribute it. >>>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>>> "show copying" >>>>>>>>> and "show warranty" for details. >>>>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>>>> (gdb) break main >>>>>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>>>>> (gdb) r >>>>>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>>>>> Breakpoint 1, main () at 1.c:1 >>>>>>>>> 1 main(){} >>>>>>>>> (gdb) >>>>>>>>> >>>>>>>>> >>>>>>>>> - Jay >>>>>>>>> >>>>>>>>> >>>>>>>>> ---------------------------------------- >>>>>>>>> From: jay.krell at cornell.edu >>>>>>>>> To: m3devel at elegosoft.com >>>>>>>>> Subject: more crashers >>>>>>>>> Date: Sun, 16 Aug 2009 10:06:15 +0000 >>>>>>>>> >>>>>>>>> >>>>>>>>> This is head on SOLgnu: >>>>>>>>> I'll try another and debug and see if fix is easy. >>>>>>>>> >>>>>>>>> -bash-3.00$ ./m3browser >>>>>>>>> >>>>>>>>> *** >>>>>>>>> *** runtime error: >>>>>>>>> *** Segmentation violation - possible attempt to dereference >>>>>>>>> NIL >>>>>>>>> *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/ >>>>>>>>> String16.m3 >>>>>>>>> *** >>>>>>>>> >>>>>>>>> -bash-3.00$ ./visobliq >>>>>>>>> Internal Obliq interpreter installed... >>>>>>>>> Establishing 'templates' >>>>>>>>> (Created frame 'templates') >>>>>>>>> let >>>>>>>>> Templates = >>>>>>>>> {boolean=> ... , >>>>>>>>> browser=> ... , >>>>>>>>> button=> ... , >>>>>>>>> choice=> ... , >>>>>>>>> filebrowser=> ... , >>>>>>>>> form=> ... , >>>>>>>>> frame=> ... , >>>>>>>>> hscroll=> ... , >>>>>>>>> menu=> ... , >>>>>>>>> numeric=> ... , >>>>>>>>> text=> ... , >>>>>>>>> textedit=> ... , >>>>>>>>> typein=> ... , >>>>>>>>> video=> ... , >>>>>>>>> vscroll=> ... } >>>>>>>>> Establishing 'vowidgets' >>>>>>>>> (Created frame 'vowidgets') >>>>>>>>> ok >>>>>>>>> Establishing 'vocheckpt' >>>>>>>>> (Created frame 'vocheckpt') >>>>>>>>> ok >>>>>>>>> Establishing 'volib' >>>>>>>>> (Created frame 'volib') >>>>>>>>> Segmentation Fault (core dumped) >>>>>>>>> -bash-3.00$ >>>>>>>>> >>>>>>>>> >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>> 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>> Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Aug 17 17:13:29 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 17 Aug 2009 17:13:29 +0200 Subject: [M3devel] more crashers In-Reply-To: References: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> <20090817133026.6v9cm3cu0wwkc08k@mail.elegosoft.com> Message-ID: <20090817171329.dsbfoh9s04k0o84w@mail.elegosoft.com> Quoting Tony Hosking : > Indeed, we might be better off investing effort in getting rid of try- > blocks implemented using setjmp/longjmp so as to avoid the stack- > allocated jmpbuf state. Or perhaps allocate that state in the heap. Is this a feature for 5.9 then? ;-) Olaf > On 17 Aug 2009, at 09:18, Jay K wrote: > >> >> Not as much luck as I'd like. >> >> >> PTHREAD_STACK_MIN >> Solaris: 4K >> Linux/sparc: 24K >> Linux/x86: 16K >> Linux/powerpc: 128K >> >> >> The overflowing stack, with 16K: >> >> >> current thread: t at 12 >> =>[1] Rd__CharsReady(0xfd61a00c, 0xfd617410, 0xfd59fb6c, 0x0, >> 0xfd59fb84, 0xfd59 >> fb8c), at 0xfec58578 >> ---- 1 following frame from gwindows -- possible stack overflow >> [2] SynScan__LookChar(0xfd883670, 0xfd8aa81c, 0xfd59fb6c, 0x0, >> 0xfd59fb84, 0xf >> d59fb8c), at 0xfead71fc >> [3] SynScan__NextToken(0xfd883670, 0xfd8ab980, 0x9, 0x0, >> 0xfd59fb84, 0xfd59fb8 >> c), at 0xfead91c4 >> [4] SynScan__LookToken(0xfd883670, 0x4ae, 0x9, 0x0, 0xfd59fb84, >> 0xfd59fb8c), a >> t 0xfead9628 >> [5] SynScan__HaveTokenName(0xfd883670, 0xfd5f7768, 0x8, 0x0, >> 0xfd59fb84, 0xfd5 >> 9fb8c), at 0xfeadd084 >> [6] SynParse__Read0(0xfd883654, 0xfd6174ac, 0xfd59fb6c, 0x0, >> 0xfd59fb84, 0xfd5 >> 9fb8c), at 0xfeae4760 >> [7] SynParse__Read0(0xfd883654, 0xfd617460, 0xfd59fb6c, 0x0, >> 0xfd59fb84, 0xfd5 >> 9fb8c), at 0xfeae5e8c >> >> >> hundreds of frames of Lots of SynParse__Read0, using about 1K per >> frame; there is a try in there. >> >> d59fb8c), at 0xfeae348c >> [666] SynParse__Read0(0xfd883654, 0xfd6172d8, 0xfd59fb6c, 0x0, >> 0xfd59fb84, 0xf >> d59fb8c), at 0xfeae5e8c >> [667] SynParse__Read0(0xfd883654, 0xfd8aaa6c, 0xfd59fb6c, 0x0, >> 0xfd59fb84, 0xf >> d59fb8c), at 0xfeae3dd4 >> [668] SynParse__Read0(0xfd883654, 0xfd617288, 0xfd59fb6c, 0x0, >> 0xfd59fb84, 0xf >> d59fb8c), at 0xfeae3168 >> [669] SynParse__Read0(0xfd883654, 0xfd8aacec, 0xfd59fb6c, 0x0, >> 0xfd59fb84, 0xf >> d59fb8c), at 0xfeae6230 >> [670] SynParse__Read1(0xfd883654, 0xfd8aacec, 0x0, 0xfd59fb84, >> 0xfd59fb8c, 0x0 >> ), at 0xfeae2674 >> [671] SynParse__Read(0xfd883654, 0xfd8aacec, 0x0, 0xfd803a00, 0x0, >> 0xfebee308) >> , at 0xfeadfb60 >> [672] SynParse__ReadNonTerminal(0xfd883654, 0xfefed45c, 0xfd61b250, >> 0xfd61b8cc >> , 0xfd61b280, 0xfd89a27c), at 0xfeadfae8 >> [673] ObliqParser__ParsePhrase(0xfd883654, 0x0, 0xfd61b250, >> 0xfd61b8cc, 0xfd61 >> b280, 0x0), at 0xfefd5ff0 >> [674] ObliqOnline__Interact(0xfd89a848, 0xc32a0, 0xfd61a00c, 0x1, >> 0x1, 0xfebee >> 308), at 0xff36b80c >> [675] ObliqRuntime__ForkedDo(0xfd3ddfb8, 0x9658aac0, 0xff000000, >> 0x0, 0xfd9100 >> 90, 0x0), at 0x80db0 >> [676] ThreadPThread__RunThread(0xef2b0, 0x0, 0x0, 0x0, 0xfd803a00, >> 0x1), at 0x >> fe06bc88 >> [677] ThreadPThread__ThreadBase(0xef2b0, 0xfd5a0000, 0x0, 0x0, >> 0xfe06b7c8, 0x1 >> ), at 0xfe06b818 >> >> >> One of the problems with defining a unit of stack size is the large >> variety of jmpbuf size. >> But heck, why 1K per frame here when SOLsun has a stack walker? Hm. >> >> - Jay >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: wagner at elegosoft.com; m3devel at elegosoft.com >>> Subject: RE: [M3devel] more crashers >>> Date: Mon, 17 Aug 2009 11:35:40 +0000 >>> >>> >>> - I think the whole machine stack mechanism is pretty hopelessly broken. >>> Not just in Modula-3. Therefore my enthusiasm to attempt to "fix" >>> it -- which is impossible -- isn't very high. >>> >>> - I'm hoping to find that no platform other than Solaris lets you >>> even use such a small stack. I have to experiment some in a bit. >>> Depending on that experiment, we'll be in a better position, without >>> any further changes, but again, depending on what I find. >>> That is, if every other platform already had a larger stack, then this >>> just brings Solaris inline with the rest. If the other platforms >>> were actually successfully using a 4K stack, then indeed a problem. >>> >>> >>> - It could also be a factor of optimization. >>> Maybe ensuring -O2 or -O3 is used more would cover it up?? >>> >>> >>> - Or some other changes. >>> That is, if we have drastically increased stack usage, we should try >>> to reduce it back down. But given that 4K was the previous value >>> and even 16K doesn't work...I'm not hopeful we could fit it back >>> down in 4K. >>> >>> It is easy enough to see the bug and then look at the various frames >>> and see if they use a lot of stack and can be reduced. >>> >>> - Jay >>> >>> >>> >>> ---------------------------------------- >>>> Date: Mon, 17 Aug 2009 13:30:26 +0200 >>>> From: wagner at elegosoft.com >>>> To: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] more crashers >>>> >>>> Quoting Jay K : >>>> >>>>> visobliq was stack overflow. >>>>> Raising the default from 4K to 16K didn't fix, but 32K did. >>>> >>>> We need to address this somehow. It cannot be correct if the user >>>> needs to increase the default stack size on one platform by 8 >>>> and not at all on another. Do we have any concept of a 'standard >>>> stack size unit' ;-)? Something that can be easily understood and >>>> implemented and be used instead of the machine words in the current >>>> interfaces? Any ideas? >>>> >>>> Olaf >>>> >>>> >>>>> - Jay >>>>> >>>>> ---------------------------------------- >>>>>> From: jay.krell at cornell.edu >>>>>> To: hosking at cs.purdue.edu >>>>>> CC: m3devel at elegosoft.com >>>>>> Subject: RE: [M3devel] more crashers >>>>>> Date: Sun, 16 Aug 2009 20:32:31 +0000 >>>>>> >>>>>> >>>>>> m3browser: >>>>>> >>>>>> It is specific to my config file >>>>>> m3-sys/cminstall/src/config-no-install/cm3.cfg that reachs back >>>>>> into the source tree. It won't happen with what most people do. I >>>>>> have to do that M3Predefines or such work so that all the uses of >>>>>> m3quake besides cm3 are much more like cm3. >>>>>> >>>>>> >>>>>> visobliq: >>>>>> not the same thing >>>>>> Does not occur on Linux/x86 or Linux/sparc. >>>>>> They do print >>>>>> Syntax error just before: -helvetica-bold-\*R-\*240-\*\") (LabelFo ... >>>>>> ill-formed character escape sequence >>>>>> Error detected (file file generated by Visual Obliq) (line 18, char 10) >>>>>> VideoVBT.Start Jv ServerFailure:errno=0 >>>>>> >>>>>> but then gui comes up. >>>>>> I'll have to finish my Solaris reinstall and get dbx. >>>>>> >>>>>> >>>>>> - Jay >>>>>> >>>>>> >>>>>> ---------------------------------------- >>>>>>> From: jay.krell at cornell.edu >>>>>>> To: hosking at cs.purdue.edu >>>>>>> Date: Sun, 16 Aug 2009 20:22:49 +0000 >>>>>>> CC: m3devel at elegosoft.com >>>>>>> Subject: Re: [M3devel] more crashers >>>>>>> >>>>>>> >>>>>>> sorry, this is simple. >>>>>>> >>>>>>> derived_dirs := IntList.List1 (ID.Add (MxConfig.Get("BUILD_DIR"))); >>>>>>> >>>>>>> >>>>>>> - Jay >>>>>>> >>>>>>> >>>>>>> >>>>>>> ---------------------------------------- >>>>>>>> From: jay.krell at cornell.edu >>>>>>>> To: hosking at cs.purdue.edu >>>>>>>> Date: Sun, 16 Aug 2009 19:52:03 +0000 >>>>>>>> CC: m3devel at elegosoft.com >>>>>>>> Subject: Re: [M3devel] more crashers >>>>>>>> >>>>>>>> >>>>>>>> Here is the relevant code in m3browser ID.m3: >>>>>>>> >>>>>>>> >>>>>>>> C:\dev2\cm3.2\m3-tools\m3markup\src\ID.m3(38): empty_id := Add (""); >>>>>>>> >>>>>>>> empty_id := Add (""); >>>>>>>> >>>>>>>> (*-------------------------------------------------------------- >>>>>>>> exported ---*) >>>>>>>> PROCEDURE Add (x: TEXT): T = >>>>>>>> VAR >>>>>>>> t: T; >>>>>>>> a: REF ARRAY OF CHAR; >>>>>>>> l: INTEGER; >>>>>>>> BEGIN >>>>>>>> l := Text.Length(x); >>>>>>>> ... >>>>>>>> END Add; >>>>>>>> >>>>>>>> >>>>>>>> The empty string constant ends up as null. >>>>>>>> >>>>>>>> .stabn 68,0,38,.LM115-.LFBB10 >>>>>>>> .LM115: >>>>>>>> movl L_1 at GOT(%ebx), %eax >>>>>>>> leal 24(%eax), %eax >>>>>>>> movl %eax, (%esp) >>>>>>>> call ID__Add at PLT >>>>>>>> movl %eax, -8(%ebp) >>>>>>>> movl -8(%ebp), %ecx >>>>>>>> movl MM_ID at GOT(%ebx), %edx >>>>>>>> movl 248(%edx), %eax >>>>>>>> andl $0, %eax >>>>>>>> orl %ecx, %eax >>>>>>>> movl %eax, 248(%edx) >>>>>>>> .L136: >>>>>>>> movl MM_ID at GOT(%ebx), %eax >>>>>>>> .LBE16: >>>>>>>> addl $52, %esp >>>>>>>> popl %ebx >>>>>>>> popl %ebp >>>>>>>> ret >>>>>>>> >>>>>>>> L_1: >>>>>>>> 0 .long RTHooks__TextLitInfo >>>>>>>> 4 .long RTHooks__TextLitGetChar >>>>>>>> 8 .long RTHooks__TextLitGetWideChar >>>>>>>> 12 .long RTHooks__TextLitGetChars >>>>>>>> 16 .long RTHooks__TextLitGetWideChars >>>>>>>> 20 .long 2 >>>>>>>> 24 .long L_1 >>>>>>>> .long 0 >>>>>>>> .zero 4 >>>>>>>> .ascii "ID_M3" >>>>>>>> .zero 1 >>>>>>>> .ascii "ExpandHashTable" >>>>>>>> .zero 1 >>>>>>>> .ascii "ExpandIDs" >>>>>>>> .zero 1 >>>>>>>> .ascii "ExpandChars" >>>>>>>> .zero 1 >>>>>>>> .ascii "Compare" >>>>>>>> .zero 1 >>>>>>>> >>>>>>>> If I change "" to "foo", I get: >>>>>>>> >>>>>>>> L_1: >>>>>>>> 0 .long RTHooks__TextLitInfo >>>>>>>> 4 .long RTHooks__TextLitGetChar >>>>>>>> 8 .long RTHooks__TextLitGetWideChar >>>>>>>> 12 .long RTHooks__TextLitGetChars >>>>>>>> 16 .long RTHooks__TextLitGetWideChars >>>>>>>> 20 .long 2 >>>>>>>> 24 .long L_1 >>>>>>>> .long 3 >>>>>>>> .ascii "foo" >>>>>>>> .zero 1 >>>>>>>> .ascii "ID_M3" >>>>>>>> >>>>>>>> and it still crashes. >>>>>>>> >>>>>>>> >>>>>>>> It seems to hit ID__Add twice when only once would be expected. >>>>>>>> >>>>>>>> >>>>>>>> - Jay >>>>>>>> >>>>>>>> >>>>>>>> ---------------------------------------- >>>>>>>>> From: jay.krell at cornell.edu >>>>>>>>> To: hosking at cs.purdue.edu >>>>>>>>> Date: Sun, 16 Aug 2009 19:33:34 +0000 >>>>>>>>> CC: m3devel at elegosoft.com >>>>>>>>> Subject: Re: [M3devel] more crashers >>>>>>>>> >>>>>>>>> >>>>>>>>> Could be. I've also seen it on PPC_DARWIN a while ago. I only >>>>>>>>> recall seeing it on sparc and ppc. >>>>>>>>> It doesn't always occur. >>>>>>>>> >>>>>>>>> >>>>>>>>> Here is the m3browser crash on a system that can be debugged. >>>>>>>>> See why I want the full paths in the debug info? >>>>>>>>> >>>>>>>>> >>>>>>>>> C:\Users\jay\Desktop>\cygwin\bin\ssh xobsd. >>>>>>>>> $ cd /cm3 >>>>>>>>> $ cd bin >>>>>>>>> $ export DISPLAY=192.168.1.120:0.0 >>>>>>>>> $ gdb ./m3browser >>>>>>>>> GNU gdb 6.3 >>>>>>>>> This GDB was configured as "i386-unknown-openbsd4.5"... >>>>>>>>> (gdb) r >>>>>>>>> Starting program: /home/jay/cm3/bin/m3browser >>>>>>>>> Program received signal SIGSEGV, Segmentation fault. >>>>>>>>> [Switching to process 31063, thread 0x7eafe800] >>>>>>>>> 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/ >>>>>>>>> Text.m3:16 >>>>>>>>> 16 t.get_info (i); >>>>>>>>> (gdb) bt >>>>>>>>> #0 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/ >>>>>>>>> text/Text.m3:16 >>>>>>>>> #1 0x09fd9464 in ID__Add (M3_Bd56fi_x=0x0) at ../src/ID.m3:48 >>>>>>>>> #2 0x1c01e644 in Main_M3 (M3_AcxOUs_mode=1) at ../src/ Main.m3:37 >>>>>>>>> #3 0x0156f1bc in RTLinker__RunMainBody (M3_DjPxE3_m=0x3c003ec0) >>>>>>>>> at ../src/runtime/common/RTLinker.m3:399 >>>>>>>>> #4 0x0156e576 in RTLinker__AddUnitI (M3_DjPxE3_m=0x3c003ec0) >>>>>>>>> at ../src/runtime/common/RTLinker.m3:113 >>>>>>>>> #5 0x0156e604 in RTLinker__AddUnit (M3_DjPxE5_b=0x1c01e54d) >>>>>>>>> at ../src/runtime/common/RTLinker.m3:122 >>>>>>>>> #6 0x1c004676 in main (argc=1, argv=0xcfbf6a3c, envp=0xcfbf6a44) >>>>>>>>> at _m3main.mc:4 >>>>>>>>> >>>>>>>>> >>>>>>>>> - Jay >>>>>>>>> >>>>>>>>> >>>>>>>>> ________________________________ >>>>>>>>>> From: hosking at cs.purdue.edu >>>>>>>>>> To: jay.krell at cornell.edu >>>>>>>>>> Date: Sun, 16 Aug 2009 15:26:49 -0400 >>>>>>>>>> CC: m3devel at elegosoft.com >>>>>>>>>> Subject: Re: [M3devel] more crashers >>>>>>>>>> >>>>>>>>>> Could this be endianness-related? >>>>>>>>>> >>>>>>>>>> On 16 Aug 2009, at 15:21, Jay K wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I see the assertion failure on PPC_LINUX too. >>>>>>>>>> I tried VAR defaultStackSize := 1024 * 1024; (not sure why >>>>>>>>>> there was any suspicion of stack size). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Debugging doesn't work PPC_LINUX. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> jay at plin:/cm3/bin$ gdb ./cm3 >>>>>>>>>> GNU gdb 6.8-debian >>>>>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>>>> This is free software: you are free to change and redistribute it. >>>>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>>>> "show copying" >>>>>>>>>> and "show warranty" for details. >>>>>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>>>>> break ma(gdb) break main >>>>>>>>>> Breakpoint 1 at 0x86fc4: file _m3main.mc, line 2. >>>>>>>>>> (gdb) r >>>>>>>>>> Starting program: /home/jay/cm3/bin/cm3 >>>>>>>>>> Warning: >>>>>>>>>> Cannot insert breakpoint 1. >>>>>>>>>> Error accessing memory address 0x86fc4: Input/output error. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> No problem with C: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> jay at plin:/cm3/bin$ echo "main(){}"> 1.c >>>>>>>>>> jay at plin:/cm3/bin$ gcc -g 1.c >>>>>>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>>>>>> GNU gdb 6.8-debian >>>>>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>>>> This is free software: you are free to change and redistribute it. >>>>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>>>> "show copying" >>>>>>>>>> and "show warranty" for details. >>>>>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>>>>> (gdb) break main >>>>>>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>>>>>> (gdb) r >>>>>>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>>>>>> Breakpoint 1, main () at 1.c:1 >>>>>>>>>> 1 main(){} >>>>>>>>>> (gdb) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> jay at plin:/cm3/bin$ gcc -gstabs+ 1.c >>>>>>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>>>>>> GNU gdb 6.8-debian >>>>>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>>>> This is free software: you are free to change and redistribute it. >>>>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>>>> "show copying" >>>>>>>>>> and "show warranty" for details. >>>>>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>>>>> (gdb) break main >>>>>>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>>>>>> (gdb) r >>>>>>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>>>>>> Breakpoint 1, main () at 1.c:1 >>>>>>>>>> 1 main(){} >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> jay at plin:/cm3/bin$ gcc -gstabs 1.c >>>>>>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>>>>>> GNU gdb 6.8-debian >>>>>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>>>> This is free software: you are free to change and redistribute it. >>>>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>>>> "show copying" >>>>>>>>>> and "show warranty" for details. >>>>>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>>>>> (gdb) break main >>>>>>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>>>>>> (gdb) r >>>>>>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>>>>>> Breakpoint 1, main () at 1.c:1 >>>>>>>>>> 1 main(){} >>>>>>>>>> (gdb) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> - Jay >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ---------------------------------------- >>>>>>>>>> From: jay.krell at cornell.edu >>>>>>>>>> To: m3devel at elegosoft.com >>>>>>>>>> Subject: more crashers >>>>>>>>>> Date: Sun, 16 Aug 2009 10:06:15 +0000 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> This is head on SOLgnu: >>>>>>>>>> I'll try another and debug and see if fix is easy. >>>>>>>>>> >>>>>>>>>> -bash-3.00$ ./m3browser >>>>>>>>>> >>>>>>>>>> *** >>>>>>>>>> *** runtime error: >>>>>>>>>> *** Segmentation violation - possible attempt to dereference NIL >>>>>>>>>> *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/ String16.m3 >>>>>>>>>> *** >>>>>>>>>> >>>>>>>>>> -bash-3.00$ ./visobliq >>>>>>>>>> Internal Obliq interpreter installed... >>>>>>>>>> Establishing 'templates' >>>>>>>>>> (Created frame 'templates') >>>>>>>>>> let >>>>>>>>>> Templates = >>>>>>>>>> {boolean=> ... , >>>>>>>>>> browser=> ... , >>>>>>>>>> button=> ... , >>>>>>>>>> choice=> ... , >>>>>>>>>> filebrowser=> ... , >>>>>>>>>> form=> ... , >>>>>>>>>> frame=> ... , >>>>>>>>>> hscroll=> ... , >>>>>>>>>> menu=> ... , >>>>>>>>>> numeric=> ... , >>>>>>>>>> text=> ... , >>>>>>>>>> textedit=> ... , >>>>>>>>>> typein=> ... , >>>>>>>>>> video=> ... , >>>>>>>>>> vscroll=> ... } >>>>>>>>>> Establishing 'vowidgets' >>>>>>>>>> (Created frame 'vowidgets') >>>>>>>>>> ok >>>>>>>>>> Establishing 'vocheckpt' >>>>>>>>>> (Created frame 'vocheckpt') >>>>>>>>>> ok >>>>>>>>>> Establishing 'volib' >>>>>>>>>> (Created frame 'volib') >>>>>>>>>> Segmentation Fault (core dumped) >>>>>>>>>> -bash-3.00$ >>>>>>>>>> >>>>>>>>>> >>>> >>>> >>>> >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>> 45 86 95 >>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>> DE163214194 >>>> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Aug 17 17:14:44 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 17 Aug 2009 15:14:44 +0000 Subject: [M3devel] more crashers In-Reply-To: <20090817171329.dsbfoh9s04k0o84w@mail.elegosoft.com> References: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> <20090817133026.6v9cm3cu0wwkc08k@mail.elegosoft.com> <20090817171329.dsbfoh9s04k0o84w@mail.elegosoft.com> Message-ID: For 5.9 we should look into the libunwind/libgcc stuff. - Jay ---------------------------------------- > Date: Mon, 17 Aug 2009 17:13:29 +0200 > From: wagner at elegosoft.com > To: hosking at cs.purdue.edu > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > Subject: Re: [M3devel] more crashers > > Quoting Tony Hosking : > >> Indeed, we might be better off investing effort in getting rid of try- >> blocks implemented using setjmp/longjmp so as to avoid the stack- >> allocated jmpbuf state. Or perhaps allocate that state in the heap. > > Is this a feature for 5.9 then? ;-) > > Olaf > >> On 17 Aug 2009, at 09:18, Jay K wrote: >> >>> >>> Not as much luck as I'd like. >>> >>> >>> PTHREAD_STACK_MIN >>> Solaris: 4K >>> Linux/sparc: 24K >>> Linux/x86: 16K >>> Linux/powerpc: 128K >>> >>> >>> The overflowing stack, with 16K: >>> >>> >>> current thread: t at 12 >>> =>[1] Rd__CharsReady(0xfd61a00c, 0xfd617410, 0xfd59fb6c, 0x0, >>> 0xfd59fb84, 0xfd59 >>> fb8c), at 0xfec58578 >>> ---- 1 following frame from gwindows -- possible stack overflow >>> [2] SynScan__LookChar(0xfd883670, 0xfd8aa81c, 0xfd59fb6c, 0x0, >>> 0xfd59fb84, 0xf >>> d59fb8c), at 0xfead71fc >>> [3] SynScan__NextToken(0xfd883670, 0xfd8ab980, 0x9, 0x0, >>> 0xfd59fb84, 0xfd59fb8 >>> c), at 0xfead91c4 >>> [4] SynScan__LookToken(0xfd883670, 0x4ae, 0x9, 0x0, 0xfd59fb84, >>> 0xfd59fb8c), a >>> t 0xfead9628 >>> [5] SynScan__HaveTokenName(0xfd883670, 0xfd5f7768, 0x8, 0x0, >>> 0xfd59fb84, 0xfd5 >>> 9fb8c), at 0xfeadd084 >>> [6] SynParse__Read0(0xfd883654, 0xfd6174ac, 0xfd59fb6c, 0x0, >>> 0xfd59fb84, 0xfd5 >>> 9fb8c), at 0xfeae4760 >>> [7] SynParse__Read0(0xfd883654, 0xfd617460, 0xfd59fb6c, 0x0, >>> 0xfd59fb84, 0xfd5 >>> 9fb8c), at 0xfeae5e8c >>> >>> >>> hundreds of frames of Lots of SynParse__Read0, using about 1K per >>> frame; there is a try in there. >>> >>> d59fb8c), at 0xfeae348c >>> [666] SynParse__Read0(0xfd883654, 0xfd6172d8, 0xfd59fb6c, 0x0, >>> 0xfd59fb84, 0xf >>> d59fb8c), at 0xfeae5e8c >>> [667] SynParse__Read0(0xfd883654, 0xfd8aaa6c, 0xfd59fb6c, 0x0, >>> 0xfd59fb84, 0xf >>> d59fb8c), at 0xfeae3dd4 >>> [668] SynParse__Read0(0xfd883654, 0xfd617288, 0xfd59fb6c, 0x0, >>> 0xfd59fb84, 0xf >>> d59fb8c), at 0xfeae3168 >>> [669] SynParse__Read0(0xfd883654, 0xfd8aacec, 0xfd59fb6c, 0x0, >>> 0xfd59fb84, 0xf >>> d59fb8c), at 0xfeae6230 >>> [670] SynParse__Read1(0xfd883654, 0xfd8aacec, 0x0, 0xfd59fb84, >>> 0xfd59fb8c, 0x0 >>> ), at 0xfeae2674 >>> [671] SynParse__Read(0xfd883654, 0xfd8aacec, 0x0, 0xfd803a00, 0x0, >>> 0xfebee308) >>> , at 0xfeadfb60 >>> [672] SynParse__ReadNonTerminal(0xfd883654, 0xfefed45c, 0xfd61b250, >>> 0xfd61b8cc >>> , 0xfd61b280, 0xfd89a27c), at 0xfeadfae8 >>> [673] ObliqParser__ParsePhrase(0xfd883654, 0x0, 0xfd61b250, >>> 0xfd61b8cc, 0xfd61 >>> b280, 0x0), at 0xfefd5ff0 >>> [674] ObliqOnline__Interact(0xfd89a848, 0xc32a0, 0xfd61a00c, 0x1, >>> 0x1, 0xfebee >>> 308), at 0xff36b80c >>> [675] ObliqRuntime__ForkedDo(0xfd3ddfb8, 0x9658aac0, 0xff000000, >>> 0x0, 0xfd9100 >>> 90, 0x0), at 0x80db0 >>> [676] ThreadPThread__RunThread(0xef2b0, 0x0, 0x0, 0x0, 0xfd803a00, >>> 0x1), at 0x >>> fe06bc88 >>> [677] ThreadPThread__ThreadBase(0xef2b0, 0xfd5a0000, 0x0, 0x0, >>> 0xfe06b7c8, 0x1 >>> ), at 0xfe06b818 >>> >>> >>> One of the problems with defining a unit of stack size is the large >>> variety of jmpbuf size. >>> But heck, why 1K per frame here when SOLsun has a stack walker? Hm. >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: wagner at elegosoft.com; m3devel at elegosoft.com >>>> Subject: RE: [M3devel] more crashers >>>> Date: Mon, 17 Aug 2009 11:35:40 +0000 >>>> >>>> >>>> - I think the whole machine stack mechanism is pretty hopelessly broken. >>>> Not just in Modula-3. Therefore my enthusiasm to attempt to "fix" >>>> it -- which is impossible -- isn't very high. >>>> >>>> - I'm hoping to find that no platform other than Solaris lets you >>>> even use such a small stack. I have to experiment some in a bit. >>>> Depending on that experiment, we'll be in a better position, without >>>> any further changes, but again, depending on what I find. >>>> That is, if every other platform already had a larger stack, then this >>>> just brings Solaris inline with the rest. If the other platforms >>>> were actually successfully using a 4K stack, then indeed a problem. >>>> >>>> >>>> - It could also be a factor of optimization. >>>> Maybe ensuring -O2 or -O3 is used more would cover it up?? >>>> >>>> >>>> - Or some other changes. >>>> That is, if we have drastically increased stack usage, we should try >>>> to reduce it back down. But given that 4K was the previous value >>>> and even 16K doesn't work...I'm not hopeful we could fit it back >>>> down in 4K. >>>> >>>> It is easy enough to see the bug and then look at the various frames >>>> and see if they use a lot of stack and can be reduced. >>>> >>>> - Jay >>>> >>>> >>>> >>>> ---------------------------------------- >>>>> Date: Mon, 17 Aug 2009 13:30:26 +0200 >>>>> From: wagner at elegosoft.com >>>>> To: m3devel at elegosoft.com >>>>> Subject: Re: [M3devel] more crashers >>>>> >>>>> Quoting Jay K : >>>>> >>>>>> visobliq was stack overflow. >>>>>> Raising the default from 4K to 16K didn't fix, but 32K did. >>>>> >>>>> We need to address this somehow. It cannot be correct if the user >>>>> needs to increase the default stack size on one platform by 8 >>>>> and not at all on another. Do we have any concept of a 'standard >>>>> stack size unit' ;-)? Something that can be easily understood and >>>>> implemented and be used instead of the machine words in the current >>>>> interfaces? Any ideas? >>>>> >>>>> Olaf >>>>> >>>>> >>>>>> - Jay >>>>>> >>>>>> ---------------------------------------- >>>>>>> From: jay.krell at cornell.edu >>>>>>> To: hosking at cs.purdue.edu >>>>>>> CC: m3devel at elegosoft.com >>>>>>> Subject: RE: [M3devel] more crashers >>>>>>> Date: Sun, 16 Aug 2009 20:32:31 +0000 >>>>>>> >>>>>>> >>>>>>> m3browser: >>>>>>> >>>>>>> It is specific to my config file >>>>>>> m3-sys/cminstall/src/config-no-install/cm3.cfg that reachs back >>>>>>> into the source tree. It won't happen with what most people do. I >>>>>>> have to do that M3Predefines or such work so that all the uses of >>>>>>> m3quake besides cm3 are much more like cm3. >>>>>>> >>>>>>> >>>>>>> visobliq: >>>>>>> not the same thing >>>>>>> Does not occur on Linux/x86 or Linux/sparc. >>>>>>> They do print >>>>>>> Syntax error just before: -helvetica-bold-\*R-\*240-\*\") (LabelFo ... >>>>>>> ill-formed character escape sequence >>>>>>> Error detected (file file generated by Visual Obliq) (line 18, char 10) >>>>>>> VideoVBT.Start Jv ServerFailure:errno=0 >>>>>>> >>>>>>> but then gui comes up. >>>>>>> I'll have to finish my Solaris reinstall and get dbx. >>>>>>> >>>>>>> >>>>>>> - Jay >>>>>>> >>>>>>> >>>>>>> ---------------------------------------- >>>>>>>> From: jay.krell at cornell.edu >>>>>>>> To: hosking at cs.purdue.edu >>>>>>>> Date: Sun, 16 Aug 2009 20:22:49 +0000 >>>>>>>> CC: m3devel at elegosoft.com >>>>>>>> Subject: Re: [M3devel] more crashers >>>>>>>> >>>>>>>> >>>>>>>> sorry, this is simple. >>>>>>>> >>>>>>>> derived_dirs := IntList.List1 (ID.Add (MxConfig.Get("BUILD_DIR"))); >>>>>>>> >>>>>>>> >>>>>>>> - Jay >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ---------------------------------------- >>>>>>>>> From: jay.krell at cornell.edu >>>>>>>>> To: hosking at cs.purdue.edu >>>>>>>>> Date: Sun, 16 Aug 2009 19:52:03 +0000 >>>>>>>>> CC: m3devel at elegosoft.com >>>>>>>>> Subject: Re: [M3devel] more crashers >>>>>>>>> >>>>>>>>> >>>>>>>>> Here is the relevant code in m3browser ID.m3: >>>>>>>>> >>>>>>>>> >>>>>>>>> C:\dev2\cm3.2\m3-tools\m3markup\src\ID.m3(38): empty_id := Add (""); >>>>>>>>> >>>>>>>>> empty_id := Add (""); >>>>>>>>> >>>>>>>>> (*-------------------------------------------------------------- >>>>>>>>> exported ---*) >>>>>>>>> PROCEDURE Add (x: TEXT): T = >>>>>>>>> VAR >>>>>>>>> t: T; >>>>>>>>> a: REF ARRAY OF CHAR; >>>>>>>>> l: INTEGER; >>>>>>>>> BEGIN >>>>>>>>> l := Text.Length(x); >>>>>>>>> ... >>>>>>>>> END Add; >>>>>>>>> >>>>>>>>> >>>>>>>>> The empty string constant ends up as null. >>>>>>>>> >>>>>>>>> .stabn 68,0,38,.LM115-.LFBB10 >>>>>>>>> .LM115: >>>>>>>>> movl L_1 at GOT(%ebx), %eax >>>>>>>>> leal 24(%eax), %eax >>>>>>>>> movl %eax, (%esp) >>>>>>>>> call ID__Add at PLT >>>>>>>>> movl %eax, -8(%ebp) >>>>>>>>> movl -8(%ebp), %ecx >>>>>>>>> movl MM_ID at GOT(%ebx), %edx >>>>>>>>> movl 248(%edx), %eax >>>>>>>>> andl $0, %eax >>>>>>>>> orl %ecx, %eax >>>>>>>>> movl %eax, 248(%edx) >>>>>>>>> .L136: >>>>>>>>> movl MM_ID at GOT(%ebx), %eax >>>>>>>>> .LBE16: >>>>>>>>> addl $52, %esp >>>>>>>>> popl %ebx >>>>>>>>> popl %ebp >>>>>>>>> ret >>>>>>>>> >>>>>>>>> L_1: >>>>>>>>> 0 .long RTHooks__TextLitInfo >>>>>>>>> 4 .long RTHooks__TextLitGetChar >>>>>>>>> 8 .long RTHooks__TextLitGetWideChar >>>>>>>>> 12 .long RTHooks__TextLitGetChars >>>>>>>>> 16 .long RTHooks__TextLitGetWideChars >>>>>>>>> 20 .long 2 >>>>>>>>> 24 .long L_1 >>>>>>>>> .long 0 >>>>>>>>> .zero 4 >>>>>>>>> .ascii "ID_M3" >>>>>>>>> .zero 1 >>>>>>>>> .ascii "ExpandHashTable" >>>>>>>>> .zero 1 >>>>>>>>> .ascii "ExpandIDs" >>>>>>>>> .zero 1 >>>>>>>>> .ascii "ExpandChars" >>>>>>>>> .zero 1 >>>>>>>>> .ascii "Compare" >>>>>>>>> .zero 1 >>>>>>>>> >>>>>>>>> If I change "" to "foo", I get: >>>>>>>>> >>>>>>>>> L_1: >>>>>>>>> 0 .long RTHooks__TextLitInfo >>>>>>>>> 4 .long RTHooks__TextLitGetChar >>>>>>>>> 8 .long RTHooks__TextLitGetWideChar >>>>>>>>> 12 .long RTHooks__TextLitGetChars >>>>>>>>> 16 .long RTHooks__TextLitGetWideChars >>>>>>>>> 20 .long 2 >>>>>>>>> 24 .long L_1 >>>>>>>>> .long 3 >>>>>>>>> .ascii "foo" >>>>>>>>> .zero 1 >>>>>>>>> .ascii "ID_M3" >>>>>>>>> >>>>>>>>> and it still crashes. >>>>>>>>> >>>>>>>>> >>>>>>>>> It seems to hit ID__Add twice when only once would be expected. >>>>>>>>> >>>>>>>>> >>>>>>>>> - Jay >>>>>>>>> >>>>>>>>> >>>>>>>>> ---------------------------------------- >>>>>>>>>> From: jay.krell at cornell.edu >>>>>>>>>> To: hosking at cs.purdue.edu >>>>>>>>>> Date: Sun, 16 Aug 2009 19:33:34 +0000 >>>>>>>>>> CC: m3devel at elegosoft.com >>>>>>>>>> Subject: Re: [M3devel] more crashers >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Could be. I've also seen it on PPC_DARWIN a while ago. I only >>>>>>>>>> recall seeing it on sparc and ppc. >>>>>>>>>> It doesn't always occur. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Here is the m3browser crash on a system that can be debugged. >>>>>>>>>> See why I want the full paths in the debug info? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> C:\Users\jay\Desktop>\cygwin\bin\ssh xobsd. >>>>>>>>>> $ cd /cm3 >>>>>>>>>> $ cd bin >>>>>>>>>> $ export DISPLAY=192.168.1.120:0.0 >>>>>>>>>> $ gdb ./m3browser >>>>>>>>>> GNU gdb 6.3 >>>>>>>>>> This GDB was configured as "i386-unknown-openbsd4.5"... >>>>>>>>>> (gdb) r >>>>>>>>>> Starting program: /home/jay/cm3/bin/m3browser >>>>>>>>>> Program received signal SIGSEGV, Segmentation fault. >>>>>>>>>> [Switching to process 31063, thread 0x7eafe800] >>>>>>>>>> 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/ >>>>>>>>>> Text.m3:16 >>>>>>>>>> 16 t.get_info (i); >>>>>>>>>> (gdb) bt >>>>>>>>>> #0 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/ >>>>>>>>>> text/Text.m3:16 >>>>>>>>>> #1 0x09fd9464 in ID__Add (M3_Bd56fi_x=0x0) at ../src/ID.m3:48 >>>>>>>>>> #2 0x1c01e644 in Main_M3 (M3_AcxOUs_mode=1) at ../src/ Main.m3:37 >>>>>>>>>> #3 0x0156f1bc in RTLinker__RunMainBody (M3_DjPxE3_m=0x3c003ec0) >>>>>>>>>> at ../src/runtime/common/RTLinker.m3:399 >>>>>>>>>> #4 0x0156e576 in RTLinker__AddUnitI (M3_DjPxE3_m=0x3c003ec0) >>>>>>>>>> at ../src/runtime/common/RTLinker.m3:113 >>>>>>>>>> #5 0x0156e604 in RTLinker__AddUnit (M3_DjPxE5_b=0x1c01e54d) >>>>>>>>>> at ../src/runtime/common/RTLinker.m3:122 >>>>>>>>>> #6 0x1c004676 in main (argc=1, argv=0xcfbf6a3c, envp=0xcfbf6a44) >>>>>>>>>> at _m3main.mc:4 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> - Jay >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ________________________________ >>>>>>>>>>> From: hosking at cs.purdue.edu >>>>>>>>>>> To: jay.krell at cornell.edu >>>>>>>>>>> Date: Sun, 16 Aug 2009 15:26:49 -0400 >>>>>>>>>>> CC: m3devel at elegosoft.com >>>>>>>>>>> Subject: Re: [M3devel] more crashers >>>>>>>>>>> >>>>>>>>>>> Could this be endianness-related? >>>>>>>>>>> >>>>>>>>>>> On 16 Aug 2009, at 15:21, Jay K wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I see the assertion failure on PPC_LINUX too. >>>>>>>>>>> I tried VAR defaultStackSize := 1024 * 1024; (not sure why >>>>>>>>>>> there was any suspicion of stack size). >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Debugging doesn't work PPC_LINUX. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> jay at plin:/cm3/bin$ gdb ./cm3 >>>>>>>>>>> GNU gdb 6.8-debian >>>>>>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>>>>> This is free software: you are free to change and redistribute it. >>>>>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>>>>> "show copying" >>>>>>>>>>> and "show warranty" for details. >>>>>>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>>>>>> break ma(gdb) break main >>>>>>>>>>> Breakpoint 1 at 0x86fc4: file _m3main.mc, line 2. >>>>>>>>>>> (gdb) r >>>>>>>>>>> Starting program: /home/jay/cm3/bin/cm3 >>>>>>>>>>> Warning: >>>>>>>>>>> Cannot insert breakpoint 1. >>>>>>>>>>> Error accessing memory address 0x86fc4: Input/output error. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> No problem with C: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> jay at plin:/cm3/bin$ echo "main(){}"> 1.c >>>>>>>>>>> jay at plin:/cm3/bin$ gcc -g 1.c >>>>>>>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>>>>>>> GNU gdb 6.8-debian >>>>>>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>>>>> This is free software: you are free to change and redistribute it. >>>>>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>>>>> "show copying" >>>>>>>>>>> and "show warranty" for details. >>>>>>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>>>>>> (gdb) break main >>>>>>>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>>>>>>> (gdb) r >>>>>>>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>>>>>>> Breakpoint 1, main () at 1.c:1 >>>>>>>>>>> 1 main(){} >>>>>>>>>>> (gdb) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> jay at plin:/cm3/bin$ gcc -gstabs+ 1.c >>>>>>>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>>>>>>> GNU gdb 6.8-debian >>>>>>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>>>>> This is free software: you are free to change and redistribute it. >>>>>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>>>>> "show copying" >>>>>>>>>>> and "show warranty" for details. >>>>>>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>>>>>> (gdb) break main >>>>>>>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>>>>>>> (gdb) r >>>>>>>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>>>>>>> Breakpoint 1, main () at 1.c:1 >>>>>>>>>>> 1 main(){} >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> jay at plin:/cm3/bin$ gcc -gstabs 1.c >>>>>>>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>>>>>>> GNU gdb 6.8-debian >>>>>>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>>>>> This is free software: you are free to change and redistribute it. >>>>>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>>>>> "show copying" >>>>>>>>>>> and "show warranty" for details. >>>>>>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>>>>>> (gdb) break main >>>>>>>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>>>>>>> (gdb) r >>>>>>>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>>>>>>> Breakpoint 1, main () at 1.c:1 >>>>>>>>>>> 1 main(){} >>>>>>>>>>> (gdb) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> - Jay >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ---------------------------------------- >>>>>>>>>>> From: jay.krell at cornell.edu >>>>>>>>>>> To: m3devel at elegosoft.com >>>>>>>>>>> Subject: more crashers >>>>>>>>>>> Date: Sun, 16 Aug 2009 10:06:15 +0000 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> This is head on SOLgnu: >>>>>>>>>>> I'll try another and debug and see if fix is easy. >>>>>>>>>>> >>>>>>>>>>> -bash-3.00$ ./m3browser >>>>>>>>>>> >>>>>>>>>>> *** >>>>>>>>>>> *** runtime error: >>>>>>>>>>> *** Segmentation violation - possible attempt to dereference NIL >>>>>>>>>>> *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/ String16.m3 >>>>>>>>>>> *** >>>>>>>>>>> >>>>>>>>>>> -bash-3.00$ ./visobliq >>>>>>>>>>> Internal Obliq interpreter installed... >>>>>>>>>>> Establishing 'templates' >>>>>>>>>>> (Created frame 'templates') >>>>>>>>>>> let >>>>>>>>>>> Templates = >>>>>>>>>>> {boolean=> ... , >>>>>>>>>>> browser=> ... , >>>>>>>>>>> button=> ... , >>>>>>>>>>> choice=> ... , >>>>>>>>>>> filebrowser=> ... , >>>>>>>>>>> form=> ... , >>>>>>>>>>> frame=> ... , >>>>>>>>>>> hscroll=> ... , >>>>>>>>>>> menu=> ... , >>>>>>>>>>> numeric=> ... , >>>>>>>>>>> text=> ... , >>>>>>>>>>> textedit=> ... , >>>>>>>>>>> typein=> ... , >>>>>>>>>>> video=> ... , >>>>>>>>>>> vscroll=> ... } >>>>>>>>>>> Establishing 'vowidgets' >>>>>>>>>>> (Created frame 'vowidgets') >>>>>>>>>>> ok >>>>>>>>>>> Establishing 'vocheckpt' >>>>>>>>>>> (Created frame 'vocheckpt') >>>>>>>>>>> ok >>>>>>>>>>> Establishing 'volib' >>>>>>>>>>> (Created frame 'volib') >>>>>>>>>>> Segmentation Fault (core dumped) >>>>>>>>>>> -bash-3.00$ >>>>>>>>>>> >>>>>>>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>>> 45 86 95 >>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>> DE163214194 >>>>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From dragisha at m3w.org Mon Aug 17 16:59:23 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 17 Aug 2009 16:59:23 +0200 Subject: [M3devel] more crashers In-Reply-To: References: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> <20090817133026.6v9cm3cu0wwkc08k@mail.elegosoft.com> Message-ID: <1250521163.11420.12.camel@faramir.m3w.org> Isn't that setjmp/longjmp bussiness direct intruction set dependant? Some pushall or something like that? On Mon, 2009-08-17 at 10:47 -0400, Tony Hosking wrote: > Indeed, we might be better off investing effort in getting rid of > try-blocks implemented using setjmp/longjmp so as to avoid the > stack-allocated jmpbuf state. Or perhaps allocate that state in the > heap. -- Dragi?a Duri? From jay.krell at cornell.edu Tue Aug 18 03:23:00 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 18 Aug 2009 01:23:00 +0000 Subject: [M3devel] more crashers In-Reply-To: <1250521163.11420.12.camel@faramir.m3w.org> References: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> <20090817133026.6v9cm3cu0wwkc08k@mail.elegosoft.com> <1250521163.11420.12.camel@faramir.m3w.org> Message-ID: Yes, something like that. I was likely mistaken -- no try/except/finally here. Still need to look into a bit more, make sure the resulting stack is now very small as I removed all the locals and put them in nested functions -- the function is a big switch and most arms of the switch have their own locals, and some are recursive, every recursion paid for every arm's locals, I assume. 900+ bytes of locals, in a recursive function! That recurses hundreds of times! Blech. The front-end IMHO should "stack pack" "parallel scopes" as a matter of course, not just depend on the optimizer. That wouldn't reduce it as much as my transform though. My transform can sometimes increase stack usage, but not typically. Also of course my transform slows it down in multiple ways, more function calls, slower access to parameters. But preserving stack is important imho. Interesting little area.. - Jay > From: dragisha at m3w.org > To: hosking at cs.purdue.edu > Date: Mon, 17 Aug 2009 16:59:23 +0200 > CC: m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3devel] more crashers > > Isn't that setjmp/longjmp bussiness direct intruction set dependant? > Some pushall or something like that? > > On Mon, 2009-08-17 at 10:47 -0400, Tony Hosking wrote: > > Indeed, we might be better off investing effort in getting rid of > > try-blocks implemented using setjmp/longjmp so as to avoid the > > stack-allocated jmpbuf state. Or perhaps allocate that state in the > > heap. > -- > Dragi?a Duri? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.m.bates at cox.net Tue Aug 18 03:57:54 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Mon, 17 Aug 2009 20:57:54 -0500 Subject: [M3devel] Some big-endian info needed Message-ID: <4A8A0AA2.7080008@cox.net> I need a favor. I need some info from the following program, compiled on a 32-bit big endian and a 64-bit big-endian machine. Would someone who has such machines with working cm3 installed please send it to me? In particular, I need it compiled with -O0 -gstabs+, then the output of: objdump -dG BitNos.mo Alternatively, if you don't have a working objdump, compiling with cm3 -keep and sending me BitNos.ms would probably give me what I need. Thanks. Rodney Bates ------------------------------------------------------------- MODULE BitNos EXPORTS Main ; TYPE Packed = RECORD F0 : BITS 2 FOR [ 0 .. 3 ] := 3 ; F1 : BITS 3 FOR [ 0 .. 7 ] := 7 ; F2 : BITS 10 FOR [ 0 .. 1023 ] := 9 ; F3 : BITS 17 FOR [ 0 .. 131071 ] := 11 ; F4 : BITS 4 FOR [ 0 .. 15 ] := 15 ; F5 : BITS 5 FOR [ 0 .. 31 ] := 17 ; F6 : BITS 12 FOR [ 0 .. 4095] := 19 ; F7 : BITS 11 FOR [ 0 .. 2047 ] := 21 ; F8 : BITS 8 FOR [ 0 .. 255 ] := 23 END ; PROCEDURE P ( ) = VAR Local : Packed ; BEGIN EVAL Local . F3 END P ; PROCEDURE Q ( ) = BEGIN END Q ; BEGIN P ( ) ; Q ( ) END BitNos . --------------------------------------------------------------------- From rodney.m.bates at cox.net Tue Aug 18 04:01:20 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Mon, 17 Aug 2009 21:01:20 -0500 Subject: [M3devel] CM3 web presentation In-Reply-To: <20090815135945.GA24494@topoi.pooq.com> References: <20090815120142.cb14l4zj4k844004@mail.elegosoft.com> <20090815135945.GA24494@topoi.pooq.com> Message-ID: <4A8A0B70.9010601@cox.net> hendrik at topoi.pooq.com wrote: > On Sat, Aug 15, 2009 at 12:14:53PM +0000, Jay K wrote: > >> Please just use white on black or black on white. >> > > Colour or no colour, prefer light on dark. It's much easier for > migraine sufferers. > Interesting. I had severe migraines for years and greatly preferred dark letters on light background. But it's now moot, as the headaches have almost entirely gone in my old age. > -- hendrik > > From jay.krell at cornell.edu Tue Aug 18 04:24:49 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 18 Aug 2009 02:24:49 +0000 Subject: [M3devel] Some big-endian info needed In-Reply-To: <4A8A0AA2.7080008@cox.net> References: <4A8A0AA2.7080008@cox.net> Message-ID: You don't need the target machine to get the .ms file. You can cross build. # build some cross compilers cd $CM3_ROOT/m3-sys/m3cc cm3 -DM3CC_TARGET=PPC_LINUX cm3 -DM3CC_TARGET=SOLgnu cm3 -DM3CC_TARGET=PPC_DARWIN cm3 -DM3CC_TARGET=PA32_HPUX cm3 -DM3CC_TARGET=PA64_HPUX cm3 -DM3CC_TARGET=SPARC64_OPENBSD cm3 -DM3CC_TARGET=MIPS64_OPENBSD cm3 -DM3CC_TARGET=SPARC64_SOLARIS # use cm3.cfg that honors CM3_TARGET environment variable cp m3-sys/cminstall/src/config-no-install/* /cm3/bin cd to where your code is CM3_TARGET=PPC_LINUX cm3 -boot CM3_TARGET=PPC_DARWIN cm3 -boot CM3_TARGET=MIPS64_OPENBSD cm3 -boot CM3_TARGET=SPARC64_OPENBSD cm3 -boot CM3_TARGET=SPARC64_SOLARIS cm3 -boot CM3_TARGET=PA32_HPUX cm3 -boot CM3_TARGET=PA64_HPUX cm3 -boot I don't think we have any actually working big endian 64bit targets, but the ones above almost work. - Jay > Date: Mon, 17 Aug 2009 20:57:54 -0500 > From: rodney.m.bates at cox.net > To: m3devel at elegosoft.com > Subject: [M3devel] Some big-endian info needed > > I need a favor. I need some info from the following program, > compiled on a 32-bit big endian and a 64-bit big-endian machine. > Would someone who has such machines with working cm3 installed > please send it to me? > > In particular, I need it compiled with -O0 -gstabs+, then the > output of: > > objdump -dG BitNos.mo > > Alternatively, if you don't have a working objdump, compiling > with cm3 -keep and sending me BitNos.ms would probably give me > what I need. > > Thanks. > > Rodney Bates > > ------------------------------------------------------------- > > MODULE BitNos EXPORTS Main > > ; TYPE Packed = RECORD > F0 : BITS 2 FOR [ 0 .. 3 ] := 3 > ; F1 : BITS 3 FOR [ 0 .. 7 ] := 7 > ; F2 : BITS 10 FOR [ 0 .. 1023 ] := 9 > ; F3 : BITS 17 FOR [ 0 .. 131071 ] := 11 > ; F4 : BITS 4 FOR [ 0 .. 15 ] := 15 > ; F5 : BITS 5 FOR [ 0 .. 31 ] := 17 > ; F6 : BITS 12 FOR [ 0 .. 4095] := 19 > ; F7 : BITS 11 FOR [ 0 .. 2047 ] := 21 > ; F8 : BITS 8 FOR [ 0 .. 255 ] := 23 > END > > ; PROCEDURE P ( ) > > = VAR Local : Packed > > ; BEGIN > EVAL Local . F3 > END P > > ; PROCEDURE Q ( ) > > = BEGIN > END Q > > ; BEGIN > P ( ) > ; Q ( ) > END BitNos -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Aug 18 15:34:08 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 18 Aug 2009 13:34:08 +0000 Subject: [M3devel] missing error checks in makedist? Message-ID: http://www.modula3.com:8080/view/I386_OPENBSD/job/cm3-makedist-I386_OPENBSD/1/console === package m3-db/odbc === +++ cm3 -build -DROOT='/home/hudson/workspace/cm3-makedist-I386_OPENBSD/cm3' -DCM3_VERSION_TEXT='d5.8.2' -DCM3_VERSION_NUMBER='050802' -DCM3_LAST_CHANGED='2009-07-15' $RARGS && cm3 -ship $RARGS -DROOT='/home/hudson/workspace/cm3-makedist-I386_OPENBSD/cm3' -DCM3_VERSION_TEXT='d5.8.2' -DCM3_VERSION_NUMBER='050802' -DCM3_LAST_CHANGED='2009-07-15' +++ /usr/bin/ld: cannot find -lodbc collect2: ld returned 1 exit status make_lib => 1 librarian failed building: m3odbc From hendrik at topoi.pooq.com Tue Aug 18 16:17:09 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 18 Aug 2009 10:17:09 -0400 Subject: [M3devel] CM3 web presentation In-Reply-To: <4A8A0B70.9010601@cox.net> References: <20090815120142.cb14l4zj4k844004@mail.elegosoft.com> <20090815135945.GA24494@topoi.pooq.com> <4A8A0B70.9010601@cox.net> Message-ID: <20090818141709.GB31203@topoi.pooq.com> On Mon, Aug 17, 2009 at 09:01:20PM -0500, Rodney M. Bates wrote: > hendrik at topoi.pooq.com wrote: > >On Sat, Aug 15, 2009 at 12:14:53PM +0000, Jay K wrote: > > > >>Please just use white on black or black on white. > >> > > > >Colour or no colour, prefer light on dark. It's much easier for > >migraine sufferers. > > > > Interesting. I had severe migraines for years and greatly > preferred dark letters on light background. But it's now > moot, as the headaches have almost entirely gone in my > old age. Evidently all the evidence isn't in yet. It seems to be the amount of subliminal or perceived flicker that aggaravates a migraine. Having a *really* good monitor will likely make a difference. Did the migraines make you fotofugic? -- hendrik From wagner at elegosoft.com Tue Aug 18 16:46:40 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 18 Aug 2009 16:46:40 +0200 Subject: [M3devel] missing error checks in makedist? In-Reply-To: References: Message-ID: <20090818164640.7qet0p9uogsgwks4@mail.elegosoft.com> Quoting Jay K : > > http://www.modula3.com:8080/view/I386_OPENBSD/job/cm3-makedist-I386_OPENBSD/1/console > === package m3-db/odbc === > +++ cm3 -build > -DROOT='/home/hudson/workspace/cm3-makedist-I386_OPENBSD/cm3' > -DCM3_VERSION_TEXT='d5.8.2' -DCM3_VERSION_NUMBER='050802' > -DCM3_LAST_CHANGED='2009-07-15' $RARGS && cm3 -ship $RARGS > -DROOT='/home/hudson/workspace/cm3-makedist-I386_OPENBSD/cm3' > -DCM3_VERSION_TEXT='d5.8.2' -DCM3_VERSION_NUMBER='050802' > -DCM3_LAST_CHANGED='2009-07-15' +++ > /usr/bin/ld: cannot find -lodbc > collect2: ld returned 1 exit status > make_lib => 1 > librarian failed building: m3odbc I reopened ticket 1047. It would help if such failures were immediately fed into trac to be tracked ;-) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Aug 18 17:25:56 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 18 Aug 2009 17:25:56 +0200 Subject: [M3devel] m3gdb build errors Message-ID: <20090818172556.ktlh757rc4gg440o@mail.elegosoft.com> Why does building m3gdb now even fail on FreeBSD for some time? http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-FreeBSD4/107/testReport/ Olaf From wagner at elegosoft.com Wed Aug 19 00:22:53 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 19 Aug 2009 00:22:53 +0200 Subject: [M3devel] m3gdb build errors In-Reply-To: <20090818172556.ktlh757rc4gg440o@mail.elegosoft.com> References: <20090818172556.ktlh757rc4gg440o@mail.elegosoft.com> Message-ID: <20090819002253.esfhmrovogc44gcg@mail.elegosoft.com> Quoting Olaf Wagner : > Why does building m3gdb now even fail on FreeBSD for some time? > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-FreeBSD4/107/testReport/ Something surprising every day: checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... configure: error: ls -t appears to fail. Make sure there is not a broken alias in your environment configure: error: newly created file is older than distributed files! Check your system clock gmake[1]: *** [configure-bfd] Error 1 gmake[1]: Leaving directory `/ad0e/home/hudson/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb/FreeBSD4' gmake: *** [all] Error 2 "/ad0e/home/hudson/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb/src/m3makefile", line 84: quake runtime error: exit 2: gmake CFLAGS="-g" MAKEINFO=echo --procedure-- -line- -file--- exec -- m3gdb_Run 84 /ad0e/home/hudson/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb/src/m3makefile include_dir 123 /ad0e/home/hudson/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb/src/m3makefile 4 /ad0e/home/hudson/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb/FreeBSD4/m3make.args Fatal Error: package build failed ls is aliased to `ls -F' luthien [~/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb] hudson % ls -t "-F" is not a file or directory. "-t" is not a file or directory. luthien [~/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb] hudson % unalias ls luthien [~/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb] hudson % ls -t "-t" is not a file or directory. luthien [~/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb] hudson % ls . ----------- CVS directory gdb directory src directory .cvsignore file (length =516) DESC file (length =56) PkgTags file (length =76) FreeBSD4 directory luthien [~/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb] hudson % type ls ls is hashed (/ad0e/home/hudson/work/cm3-inst/luthien/last-ok/bin/ls) Since when do we provide our own ls? Oh, I see, it's probably one of the examples that should never have been shipped... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Wed Aug 19 00:32:50 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 19 Aug 2009 00:32:50 +0200 Subject: [M3devel] m3gdb build errors In-Reply-To: <20090819002253.esfhmrovogc44gcg@mail.elegosoft.com> References: <20090818172556.ktlh757rc4gg440o@mail.elegosoft.com> <20090819002253.esfhmrovogc44gcg@mail.elegosoft.com> Message-ID: <20090819003250.go8ismls04kogg44@mail.elegosoft.com> Hm, my mails seem to get truncated too, now. Quoting Olaf Wagner : > Quoting Olaf Wagner : > "-t" is not a file or directory. > luthien [~/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb] hudson > % ls Why has this ls been shipped to bin though? The makefile says ./m3-sys/cm3ide/src/examples/files/src/m3makefile:program ("ls") Has anybody changed the shipping semantics? If yes, it is an incompatible change which should be reverted. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Aug 19 01:27:03 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Tue, 18 Aug 2009 16:27:03 -0700 Subject: [M3devel] m3gdb build errors In-Reply-To: <20090819003250.go8ismls04kogg44@mail.elegosoft.com> References: <20090818172556.ktlh757rc4gg440o@mail.elegosoft.com> <20090819002253.esfhmrovogc44gcg@mail.elegosoft.com> <20090819003250.go8ismls04kogg44@mail.elegosoft.com> Message-ID: <4CA7696C-C79F-4E9F-BC0D-5F68566679BC@hotmail.com> I agree that would be wrong. The no-resolution changes? (case sensitivity is too subtle I think but I've known about it) - Jay (phone) On Aug 18, 2009, at 3:32 PM, Olaf Wagner wrote: > Hm, my mails seem to get truncated too, now. > > Quoting Olaf Wagner : > >> Quoting Olaf Wagner : >> "-t" is not a file or directory. >> luthien [~/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb] >> hudson >> % ls > > Why has this ls been shipped to bin though? The makefile says > > ./m3-sys/cm3ide/src/examples/files/src/m3makefile:program ("ls") > > Has anybody changed the shipping semantics? If yes, it is an > incompatible change which should be reverted. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ > any > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be > rlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > From jay.krell at cornell.edu Wed Aug 19 05:46:36 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 19 Aug 2009 03:46:36 +0000 Subject: [M3devel] m3gdb build errors In-Reply-To: <20090819003250.go8ismls04kogg44@mail.elegosoft.com> References: <20090818172556.ktlh757rc4gg440o@mail.elegosoft.com> <20090819002253.esfhmrovogc44gcg@mail.elegosoft.com> <20090819003250.go8ismls04kogg44@mail.elegosoft.com> Message-ID: > Hm, my mails seem to get truncated too, now. I think this is a matter of playing the odds. The more mail you send, the more frequently you send, the longer the mails, the more likely they are to be truncated. - Jay ---------------------------------------- > Date: Wed, 19 Aug 2009 00:32:50 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] m3gdb build errors > > Hm, my mails seem to get truncated too, now. > > Quoting Olaf Wagner : > >> Quoting Olaf Wagner : >> "-t" is not a file or directory. >> luthien [~/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb] hudson >> % ls > > Why has this ls been shipped to bin though? The makefile says > > ./m3-sys/cm3ide/src/examples/files/src/m3makefile:program ("ls") > > Has anybody changed the shipping semantics? If yes, it is an > incompatible change which should be reverted. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From wagner at elegosoft.com Wed Aug 19 08:47:12 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 19 Aug 2009 08:47:12 +0200 Subject: [M3devel] Wrong shipping needs investigation, was: Re: m3gdb build errors In-Reply-To: <4CA7696C-C79F-4E9F-BC0D-5F68566679BC@hotmail.com> References: <20090818172556.ktlh757rc4gg440o@mail.elegosoft.com> <20090819002253.esfhmrovogc44gcg@mail.elegosoft.com> <20090819003250.go8ismls04kogg44@mail.elegosoft.com> <4CA7696C-C79F-4E9F-BC0D-5F68566679BC@hotmail.com> Message-ID: <20090819084712.deqwnkyk0s488go8@mail.elegosoft.com> Quoting jay.krell at cornell.edu: > I agree that would be wrong. The no-resolution changes? (case > sensitivity is too subtle I think but I've known about it) I thought so, too. but it is at least not obvious. The implementation of program and Program looks innocent enough, and the diffs to 2009-07-15 don't bring up anything related. At least in m3-sys/cm3. Perhaps it's a side-effect of another package? But how could this be? Can anybody investigate this further? If we don't fix it soon, RC3 won't be ready at the weekend, as building packages for all platforms takes rather long. We also need to add some tests for the correct contents of shipping files to m3-sys/m3tests. Any volunteers there? Olaf PS: I'm off to work now and not home again until tomorrow evening. Connectivity will be infrequent and slow. PPS: I've opened ticket #1060 for this. > - Jay (phone) >> Quoting Olaf Wagner : >> >>> Quoting Olaf Wagner : >>> "-t" is not a file or directory. >>> luthien [~/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb] hudson >>> % ls >> >> Why has this ls been shipped to bin though? The makefile says >> >> ./m3-sys/cm3ide/src/examples/files/src/m3makefile:program ("ls") >> >> Has anybody changed the shipping semantics? If yes, it is an >> incompatible change which should be reverted. -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Wed Aug 19 21:22:47 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 19 Aug 2009 21:22:47 +0200 Subject: [M3devel] m3gdb build errors In-Reply-To: <20090819003250.go8ismls04kogg44@mail.elegosoft.com> References: <20090818172556.ktlh757rc4gg440o@mail.elegosoft.com> <20090819002253.esfhmrovogc44gcg@mail.elegosoft.com> <20090819003250.go8ismls04kogg44@mail.elegosoft.com> Message-ID: <20090819212247.xlgbut6jtcccs0sw@mail.elegosoft.com> Quoting Olaf Wagner : > Hm, my mails seem to get truncated too, now. > > Quoting Olaf Wagner : > >> Quoting Olaf Wagner : >> "-t" is not a file or directory. >> luthien [~/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb] hudson >> % ls > > Why has this ls been shipped to bin though? The makefile says > > ./m3-sys/cm3ide/src/examples/files/src/m3makefile:program ("ls") > > Has anybody changed the shipping semantics? If yes, it is an > incompatible change which should be reverted. This is a strange day. I don't seem to be able to reproduce this any more. If I hadn't saved the .M3SHIP file in the ticket I'd say I was still dreaming this morning. Has anybody fixed it already? Ah, browsing the changelog I find this: 2009-08-19 13:06 jkrell * m3-sys/cminstall/src/config-no-install/: NT386.common, cm3cfg.common: manual merge from release_branch_cm3_5_8 to head: let cm3 decide where to ship stuff -- not everything goes to BinInstall So it was only in the config files? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Aug 19 21:56:10 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 19 Aug 2009 19:56:10 +0000 Subject: [M3devel] m3gdb build errors In-Reply-To: <20090819212247.xlgbut6jtcccs0sw@mail.elegosoft.com> References: <20090818172556.ktlh757rc4gg440o@mail.elegosoft.com> <20090819002253.esfhmrovogc44gcg@mail.elegosoft.com> <20090819003250.go8ismls04kogg44@mail.elegosoft.com> <20090819212247.xlgbut6jtcccs0sw@mail.elegosoft.com> Message-ID: Yes it was in the config files. Only if skip_ was called -- you have to run cm3 twice or such. - Jay ---------------------------------------- > Date: Wed, 19 Aug 2009 21:22:47 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] m3gdb build errors > > Quoting Olaf Wagner : > >> Hm, my mails seem to get truncated too, now. >> >> Quoting Olaf Wagner : >> >>> Quoting Olaf Wagner : >>> "-t" is not a file or directory. >>> luthien [~/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb] hudson >>> % ls >> >> Why has this ls been shipped to bin though? The makefile says >> >> ./m3-sys/cm3ide/src/examples/files/src/m3makefile:program ("ls") >> >> Has anybody changed the shipping semantics? If yes, it is an >> incompatible change which should be reverted. > > This is a strange day. I don't seem to be able to reproduce this > any more. If I hadn't saved the .M3SHIP file in the ticket I'd > say I was still dreaming this morning. > > Has anybody fixed it already? > > Ah, browsing the changelog I find this: > > 2009-08-19 13:06 jkrell > > * m3-sys/cminstall/src/config-no-install/: NT386.common, cm3cfg.common: > > manual merge from release_branch_cm3_5_8 to head: let cm3 decide > where to ship stuff -- not everything goes to BinInstall > > So it was only in the config files? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Wed Aug 19 22:44:26 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 19 Aug 2009 20:44:26 +0000 Subject: [M3devel] m3gdb build errors In-Reply-To: <20090819212247.xlgbut6jtcccs0sw@mail.elegosoft.com> References: <20090818172556.ktlh757rc4gg440o@mail.elegosoft.com> <20090819002253.esfhmrovogc44gcg@mail.elegosoft.com> <20090819003250.go8ismls04kogg44@mail.elegosoft.com> <20090819212247.xlgbut6jtcccs0sw@mail.elegosoft.com> Message-ID: ps: There's a related small NT specific problem where the symbols -- the .pdb file -- always gets shipped to the bin directory, whereas the intent was to ship next to the binary. I believe the fix is to move the code, very few lines, into cm3. The catch I couldn't solve right away is that the file isn't always present, even on NT, depending on config file details, so it's probably best done "only if exists", ignoring the corner case where it existed in an earlier run, config file changed, doesn't exist in later run -- though that can be dealt with too by deleting the destination if the source doesn't exist. I don't think we have a CopyIfExists primitive though. I can add one. The name should probaby be different to reflect...you know..like... CopyIfExistsElseDeleteDestination?? - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Subject: RE: [M3devel] m3gdb build errors > Date: Wed, 19 Aug 2009 19:56:10 +0000 > > > Yes it was in the config files. > Only if skip_ was called -- you have to run cm3 twice or such. > > - Jay > > > ---------------------------------------- >> Date: Wed, 19 Aug 2009 21:22:47 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] m3gdb build errors >> >> Quoting Olaf Wagner : >> >>> Hm, my mails seem to get truncated too, now. >>> >>> Quoting Olaf Wagner : >>> >>>> Quoting Olaf Wagner : >>>> "-t" is not a file or directory. >>>> luthien [~/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb] hudson >>>> % ls >>> >>> Why has this ls been shipped to bin though? The makefile says >>> >>> ./m3-sys/cm3ide/src/examples/files/src/m3makefile:program ("ls") >>> >>> Has anybody changed the shipping semantics? If yes, it is an >>> incompatible change which should be reverted. >> >> This is a strange day. I don't seem to be able to reproduce this >> any more. If I hadn't saved the .M3SHIP file in the ticket I'd >> say I was still dreaming this morning. >> >> Has anybody fixed it already? >> >> Ah, browsing the changelog I find this: >> >> 2009-08-19 13:06 jkrell >> >> * m3-sys/cminstall/src/config-no-install/: NT386.common, cm3cfg.common: >> >> manual merge from release_branch_cm3_5_8 to head: let cm3 decide >> where to ship stuff -- not everything goes to BinInstall >> >> So it was only in the config files? >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> From wagner at elegosoft.com Thu Aug 20 08:58:07 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 20 Aug 2009 08:58:07 +0200 Subject: [M3devel] m3gdb build errors In-Reply-To: References: <20090818172556.ktlh757rc4gg440o@mail.elegosoft.com> <20090819002253.esfhmrovogc44gcg@mail.elegosoft.com> <20090819003250.go8ismls04kogg44@mail.elegosoft.com> <20090819212247.xlgbut6jtcccs0sw@mail.elegosoft.com> Message-ID: <20090820085807.qxd84gjkcg40g4cg@mail.elegosoft.com> Quoting Jay K : > ps: There's a related small NT specific problem where the symbols -- > the .pdb file -- always gets shipped to the bin directory, whereas > the intent was to ship next to the binary. I believe the fix is to > move the code, very few lines, into cm3. The catch I couldn't solve > right away is that the file isn't always present, even on NT, > depending on config file details, so it's probably best done "only > if exists", ignoring the corner case where it existed in an earlier > run, config file changed, doesn't exist in later run -- though that > can be dealt with too by deleting the destination if the source > doesn't exist. I don't think we have a CopyIfExists primitive > though. I can add one. The name should probaby be different to > reflect...you know..like... CopyIfExistsElseDeleteDestination?? Can you please add a reference to the fix to the ticket, and the above information, too? If we need a complex installation function, we can add it, but perhaps somebody can suggest a better name? Olaf > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com; m3devel at elegosoft.com >> Subject: RE: [M3devel] m3gdb build errors >> Date: Wed, 19 Aug 2009 19:56:10 +0000 >> >> >> Yes it was in the config files. >> Only if skip_ was called -- you have to run cm3 twice or such. >> >> - Jay >> >> ---------------------------------------- >>> Date: Wed, 19 Aug 2009 21:22:47 +0200 >>> From: wagner at elegosoft.com >>> To: m3devel at elegosoft.com >>> Subject: Re: [M3devel] m3gdb build errors >>> >>> Quoting Olaf Wagner : >>> >>>> Hm, my mails seem to get truncated too, now. >>>> >>>> Quoting Olaf Wagner : >>>> >>>>> Quoting Olaf Wagner : >>>>> "-t" is not a file or directory. >>>>> luthien [~/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb] hudson >>>>> % ls >>>> >>>> Why has this ls been shipped to bin though? The makefile says >>>> >>>> ./m3-sys/cm3ide/src/examples/files/src/m3makefile:program ("ls") >>>> >>>> Has anybody changed the shipping semantics? If yes, it is an >>>> incompatible change which should be reverted. >>> >>> This is a strange day. I don't seem to be able to reproduce this >>> any more. If I hadn't saved the .M3SHIP file in the ticket I'd >>> say I was still dreaming this morning. >>> >>> Has anybody fixed it already? >>> >>> Ah, browsing the changelog I find this: >>> >>> 2009-08-19 13:06 jkrell >>> >>> * m3-sys/cminstall/src/config-no-install/: NT386.common, cm3cfg.common: >>> >>> manual merge from release_branch_cm3_5_8 to head: let cm3 decide >>> where to ship stuff -- not everything goes to BinInstall >>> >>> So it was only in the config files? -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Thu Aug 20 09:03:54 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 20 Aug 2009 09:03:54 +0200 Subject: [M3devel] Trac/CVS/Hudson integration Message-ID: <20090820090354.pki6jxajokgsgwo0@mail.elegosoft.com> If you commit a fix for a change related to a ticket in trac, you should add the ticket number in the form # to the commit message. Then Hudson (and other tools) will be able to cross-reference tickets and version changes. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Aug 20 11:45:21 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 20 Aug 2009 09:45:21 +0000 Subject: [M3devel] formedit crash Message-ID: Just a note that I have 5.4.0 running on Solaris. I've run its formsedit many times, never a crash. It crashes at least 10% of the time in the current tree. I tried copying all the "nearby" code, that merely turned my assertion back into SIGSEGV. Indeed the nearby diffs are not significant. - Jay From jay.krell at cornell.edu Thu Aug 20 11:55:07 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 20 Aug 2009 09:55:07 +0000 Subject: [M3devel] @M3paranoidgc always crashes Message-ID: Verified on SOLgnu and AMD64_LINUX. Probably related to initialization order changes that let user threads work again. Probably should just use untraced? % gdb --args ./cm3 @M3paranoidgc GNU gdb 6.4.90-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run Starting program: /home/jkrell/cm3/bin/cm3 @M3paranoidgc [Thread debugging using libthread_db enabled] [New Thread 47899659458256 (LWP 29607)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 47899659458256 (LWP 29607)] 0x00000000006934c5 in RTAllocator__GetTracedObj (M3_Eic7CK_def=Cannot access mem ory at address 0x800028d97718 ) at ../src/runtime/common/RTAllocator.m3:221 221 INC(thread.inCritical); (gdb) bt #0 0x00000000006934c5 in RTAllocator__GetTracedObj (M3_Eic7CK_def=Cannot access memory at address 0x800028d97718 ) at ../src/runtime/common/RTAllocator.m3:221 #1 0x0000000000692e1f in RTHooks__AllocateTracedObj (M3_AJWxb1_defn=Cannot acce ss memory at address 0x800028d97788 ) at ../src/runtime/common/RTAllocator.m3:120 #2 0x000000000069b3ae in RTCollector__InstallSanityCheck () at ../src/runtime/common/RTCollector.m3:1637 #3 0x00000000006a1747 in RTHeapRep__Init () at ../src/runtime/common/RTCollector.m3:2769 #4 0x00000000006a2a1d in RTLinker__InitRuntime (M3_AcxOUs_p_argc=Cannot access memory at address 0x800028d97858 ) at ../src/runtime/common/RTLinker.m3:58 #5 0x00000000004160bc in main (argc=Cannot access memory at address 0x800028d97 8a8 ) at _m3main.mc:3 (gdb) From hosking at cs.purdue.edu Thu Aug 20 16:03:19 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 20 Aug 2009 10:03:19 -0400 Subject: [M3devel] @M3paranoidgc always crashes In-Reply-To: References: Message-ID: Indeed, the use of paranoidgc itself now seems to be broken (independently of any other bug you might be trying to track down by invoking paranoidgc). This is a serious bug, that should be rectified *before* any release. Without it, we cannot easily diagnose GC bugs in the field. I have little to no time to devote to this right now, but it does look like the recent changes to threading initialisation has broken things. I remember being very careful about initialization of threads and heap components of the run-time when working on the original native threads. In particular, the ability to invoke ThreadF.GetActivation was allowed before ThreadF.Init had been called, because ThreadF.InitActivations was able to be invoked on-demand independently of ThreadF.Init. This independence now seems to have been eliminated so as to eliminate a run-time check in GetActivation. On 20 Aug 2009, at 05:55, Jay K wrote: > > Verified on SOLgnu and AMD64_LINUX. > Probably related to initialization order changes that let user > threads work again. > Probably should just use untraced? > > > > % gdb --args ./cm3 @M3paranoidgc > GNU gdb 6.4.90-debian > Copyright (C) 2006 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and > you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "x86_64-linux-gnu"...Using host > libthread_db library > "/lib/libthread_db.so.1". > (gdb) run > Starting program: /home/jkrell/cm3/bin/cm3 @M3paranoidgc > [Thread debugging using libthread_db enabled] > [New Thread 47899659458256 (LWP 29607)] > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 47899659458256 (LWP 29607)] > 0x00000000006934c5 in RTAllocator__GetTracedObj > (M3_Eic7CK_def=Cannot access mem > ory at address 0x800028d97718 > ) > at ../src/runtime/common/RTAllocator.m3:221 > 221 INC(thread.inCritical); > (gdb) bt > #0 0x00000000006934c5 in RTAllocator__GetTracedObj > (M3_Eic7CK_def=Cannot access > memory at address 0x800028d97718 > ) > at ../src/runtime/common/RTAllocator.m3:221 > #1 0x0000000000692e1f in RTHooks__AllocateTracedObj > (M3_AJWxb1_defn=Cannot acce > ss memory at address 0x800028d97788 > ) > at ../src/runtime/common/RTAllocator.m3:120 > #2 0x000000000069b3ae in RTCollector__InstallSanityCheck () > at ../src/runtime/common/RTCollector.m3:1637 > #3 0x00000000006a1747 in RTHeapRep__Init () > at ../src/runtime/common/RTCollector.m3:2769 > #4 0x00000000006a2a1d in RTLinker__InitRuntime > (M3_AcxOUs_p_argc=Cannot access > memory at address 0x800028d97858 > ) > at ../src/runtime/common/RTLinker.m3:58 > #5 0x00000000004160bc in main (argc=Cannot access memory at address > 0x800028d97 > 8a8 > ) at _m3main.mc:3 > (gdb) > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Thu Aug 20 16:37:31 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 20 Aug 2009 16:37:31 +0200 Subject: [M3devel] SYSTEM_LIBS, quake, ./configure Message-ID: <1250779051.3002.6.camel@faramir.m3w.org> In this ticket, https://projects.elego.de/cm3/ticket/1048, cvsup problem with libz on some systems is described. But, that problem is bigger than this - whole C portability issue. We need quake standardized way for locating (or not allocating:) system libraries. That way, it'll be possible to have Modula-3 programs and libraries which depend on C libraries like.... expat, tidy, mysqlclient, sqlite... distributed as wide as cm3 is. This is solvable with some quake magic? -- Dragi?a Duri? From wagner at elegosoft.com Thu Aug 20 17:07:37 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 20 Aug 2009 17:07:37 +0200 Subject: [M3devel] SYSTEM_LIBS, quake, ./configure In-Reply-To: <1250779051.3002.6.camel@faramir.m3w.org> References: <1250779051.3002.6.camel@faramir.m3w.org> Message-ID: <20090820170737.xlylo4e268oo480o@mail.elegosoft.com> Quoting Dragi?a Duri? : > In this ticket, https://projects.elego.de/cm3/ticket/1048, cvsup problem > with libz on some systems is described. But, that problem is bigger than > this - whole C portability issue. > > We need quake standardized way for locating (or not allocating:) system > libraries. That way, it'll be possible to have Modula-3 programs and > libraries which depend on C libraries like.... expat, tidy, mysqlclient, > sqlite... distributed as wide as cm3 is. > > This is solvable with some quake magic? This kind of configure-function was part of the old CM3 installer, but has become unused now, because Jay insists that it is unnecessary. I don't think this should be a quake function executed at compile time. Interfaces to a well-known set of system libraries are contained in the config files. A quake definition of such a function would necessarily be system- dependent, as it would need to know about all standard locations to search on a certain platform. Or search all known locations, but then the problem of resolving multiple hits comes up... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Thu Aug 20 17:10:58 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 20 Aug 2009 17:10:58 +0200 Subject: [M3devel] @M3paranoidgc always crashes In-Reply-To: References: Message-ID: <20090820171058.0stkh5eu68cw0ksk@mail.elegosoft.com> Quoting Tony Hosking : > Indeed, the use of paranoidgc itself now seems to be broken > (independently of any other bug you might be trying to track down by > invoking paranoidgc). > This is a serious bug, that should be rectified *before* any release. > Without it, we cannot easily diagnose GC bugs in the field. I have > little to no time to devote to this right now, but it does look like > the recent changes to threading initialisation has broken things. I > remember being very careful about initialization of threads and heap > components of the run-time when working on the original native > threads. In particular, the ability to invoke ThreadF.GetActivation > was allowed before ThreadF.Init had been called, because > ThreadF.InitActivations was able to be invoked on-demand independently > of ThreadF.Init. This independence now seems to have been eliminated > so as to eliminate a run-time check in GetActivation. Jay, could you open a ticket for that, too? And we also need to add tests for running with various @M3 options... Olaf > > On 20 Aug 2009, at 05:55, Jay K wrote: > >> >> Verified on SOLgnu and AMD64_LINUX. >> Probably related to initialization order changes that let user >> threads work again. >> Probably should just use untraced? >> >> >> >> % gdb --args ./cm3 @M3paranoidgc >> GNU gdb 6.4.90-debian >> Copyright (C) 2006 Free Software Foundation, Inc. >> GDB is free software, covered by the GNU General Public License, >> and you are >> welcome to change it and/or distribute copies of it under certain >> conditions. >> Type "show copying" to see the conditions. >> There is absolutely no warranty for GDB. Type "show warranty" for details. >> This GDB was configured as "x86_64-linux-gnu"...Using host >> libthread_db library >> "/lib/libthread_db.so.1". >> (gdb) run >> Starting program: /home/jkrell/cm3/bin/cm3 @M3paranoidgc >> [Thread debugging using libthread_db enabled] >> [New Thread 47899659458256 (LWP 29607)] >> Program received signal SIGSEGV, Segmentation fault. >> [Switching to Thread 47899659458256 (LWP 29607)] >> 0x00000000006934c5 in RTAllocator__GetTracedObj >> (M3_Eic7CK_def=Cannot access mem >> ory at address 0x800028d97718 >> ) >> at ../src/runtime/common/RTAllocator.m3:221 >> 221 INC(thread.inCritical); >> (gdb) bt >> #0 0x00000000006934c5 in RTAllocator__GetTracedObj >> (M3_Eic7CK_def=Cannot access >> memory at address 0x800028d97718 >> ) >> at ../src/runtime/common/RTAllocator.m3:221 >> #1 0x0000000000692e1f in RTHooks__AllocateTracedObj >> (M3_AJWxb1_defn=Cannot acce >> ss memory at address 0x800028d97788 >> ) >> at ../src/runtime/common/RTAllocator.m3:120 >> #2 0x000000000069b3ae in RTCollector__InstallSanityCheck () >> at ../src/runtime/common/RTCollector.m3:1637 >> #3 0x00000000006a1747 in RTHeapRep__Init () >> at ../src/runtime/common/RTCollector.m3:2769 >> #4 0x00000000006a2a1d in RTLinker__InitRuntime >> (M3_AcxOUs_p_argc=Cannot access >> memory at address 0x800028d97858 >> ) >> at ../src/runtime/common/RTLinker.m3:58 >> #5 0x00000000004160bc in main (argc=Cannot access memory at >> address 0x800028d97 >> 8a8 >> ) at _m3main.mc:3 >> (gdb) >> >> >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Thu Aug 20 17:26:52 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 20 Aug 2009 11:26:52 -0400 Subject: [M3devel] @M3paranoidgc always crashes In-Reply-To: <20090820171058.0stkh5eu68cw0ksk@mail.elegosoft.com> References: <20090820171058.0stkh5eu68cw0ksk@mail.elegosoft.com> Message-ID: <007DD8EA-4A1C-447A-B8FB-56396A8F6560@cs.purdue.edu> Jay may have fixed this for now. On 20 Aug 2009, at 11:10, Olaf Wagner wrote: > Quoting Tony Hosking : > >> Indeed, the use of paranoidgc itself now seems to be broken >> (independently of any other bug you might be trying to track down by >> invoking paranoidgc). >> This is a serious bug, that should be rectified *before* any release. >> Without it, we cannot easily diagnose GC bugs in the field. I have >> little to no time to devote to this right now, but it does look like >> the recent changes to threading initialisation has broken things. I >> remember being very careful about initialization of threads and heap >> components of the run-time when working on the original native >> threads. In particular, the ability to invoke ThreadF.GetActivation >> was allowed before ThreadF.Init had been called, because >> ThreadF.InitActivations was able to be invoked on-demand >> independently >> of ThreadF.Init. This independence now seems to have been eliminated >> so as to eliminate a run-time check in GetActivation. > > Jay, could you open a ticket for that, too? > > And we also need to add tests for running with various @M3 options... > > Olaf > >> >> On 20 Aug 2009, at 05:55, Jay K wrote: >> >>> >>> Verified on SOLgnu and AMD64_LINUX. >>> Probably related to initialization order changes that let user >>> threads work again. >>> Probably should just use untraced? >>> >>> >>> >>> % gdb --args ./cm3 @M3paranoidgc >>> GNU gdb 6.4.90-debian >>> Copyright (C) 2006 Free Software Foundation, Inc. >>> GDB is free software, covered by the GNU General Public License, >>> and you are >>> welcome to change it and/or distribute copies of it under >>> certain conditions. >>> Type "show copying" to see the conditions. >>> There is absolutely no warranty for GDB. Type "show warranty" >>> for details. >>> This GDB was configured as "x86_64-linux-gnu"...Using host >>> libthread_db library >>> "/lib/libthread_db.so.1". >>> (gdb) run >>> Starting program: /home/jkrell/cm3/bin/cm3 @M3paranoidgc >>> [Thread debugging using libthread_db enabled] >>> [New Thread 47899659458256 (LWP 29607)] >>> Program received signal SIGSEGV, Segmentation fault. >>> [Switching to Thread 47899659458256 (LWP 29607)] >>> 0x00000000006934c5 in RTAllocator__GetTracedObj >>> (M3_Eic7CK_def=Cannot access mem >>> ory at address 0x800028d97718 >>> ) >>> at ../src/runtime/common/RTAllocator.m3:221 >>> 221 INC(thread.inCritical); >>> (gdb) bt >>> #0 0x00000000006934c5 in RTAllocator__GetTracedObj >>> (M3_Eic7CK_def=Cannot access >>> memory at address 0x800028d97718 >>> ) >>> at ../src/runtime/common/RTAllocator.m3:221 >>> #1 0x0000000000692e1f in RTHooks__AllocateTracedObj >>> (M3_AJWxb1_defn=Cannot acce >>> ss memory at address 0x800028d97788 >>> ) >>> at ../src/runtime/common/RTAllocator.m3:120 >>> #2 0x000000000069b3ae in RTCollector__InstallSanityCheck () >>> at ../src/runtime/common/RTCollector.m3:1637 >>> #3 0x00000000006a1747 in RTHeapRep__Init () >>> at ../src/runtime/common/RTCollector.m3:2769 >>> #4 0x00000000006a2a1d in RTLinker__InitRuntime >>> (M3_AcxOUs_p_argc=Cannot access >>> memory at address 0x800028d97858 >>> ) >>> at ../src/runtime/common/RTLinker.m3:58 >>> #5 0x00000000004160bc in main (argc=Cannot access memory at >>> address 0x800028d97 >>> 8a8 >>> ) at _m3main.mc:3 >>> (gdb) >>> >>> >>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lchretien at mac.com Thu Aug 20 20:57:36 2009 From: lchretien at mac.com (Louis =?ISO-8859-1?B?Q2hy6XRpZW4=?=) Date: Thu, 20 Aug 2009 14:57:36 -0400 Subject: [M3devel] A question about the M3 licensing... Message-ID: I remember reading on this list (or was it the website...) that the way the licensing of Modula-3 is written, it would make it incompatible/impossible to merge this project with the GCC front-end from the GCC foundation, the way that GNU Ada was incorporated into that project. Because M3 uses a modified GCC code generator, it would have a made sense to go that way. But another, intriguing possibility exists: the LLVM project (http://www.llvm.org). It looks like a very high-performance, optimizing, multiple target infrastructure, that would make Modula-3 highly portable. I'm sure i'm not the first to think of this, but what are the obstacle to porting M3 to that environment (apart from the obvious effort in programming required... ;-))) -- Louis Chr?tien lchretien at mac.com From mbishop at esoteriq.org Thu Aug 20 22:30:06 2009 From: mbishop at esoteriq.org (Martin Bishop) Date: Thu, 20 Aug 2009 15:30:06 -0500 Subject: [M3devel] A question about the M3 licensing... In-Reply-To: References: Message-ID: <4A8DB24E.7010807@esoteriq.org> I definitely wondered about getting CM3 to use LLVM as well. I have none of the skills required to make it happen, but just wondered about doing so. LLVM is the "hot thing" now (deservedly so) and it would be nice if Modula-3 could get a little bit of life in it by association. Louis Chr?tien wrote: > I remember reading on this list (or was it the website...) that the way the > licensing of Modula-3 is written, it would make it incompatible/impossible > to merge this project with the GCC front-end from the GCC foundation, the > way that GNU Ada was incorporated into that project. > > Because M3 uses a modified GCC code generator, it would have a made sense to > go that way. > > But another, intriguing possibility exists: the LLVM project > (http://www.llvm.org). It looks like a very high-performance, optimizing, > multiple target infrastructure, that would make Modula-3 highly portable. > > I'm sure i'm not the first to think of this, but what are the obstacle to > porting M3 to that environment (apart from the obvious effort in programming > required... ;-))) > > -- > Louis Chr?tien > lchretien at mac.com > > > > From hosking at cs.purdue.edu Thu Aug 20 23:50:16 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 20 Aug 2009 17:50:16 -0400 Subject: [M3devel] A question about the M3 licensing... In-Reply-To: References: Message-ID: <1F753DA1-D9A2-46C5-B490-8F4D08A4392F@cs.purdue.edu> Yes, I have thought that this would be a great idea for some time now. Similarly for .NET. The only obstacle of course is time... :-) On 20 Aug 2009, at 14:57, Louis Chr?tien wrote: > I remember reading on this list (or was it the website...) that the > way the > licensing of Modula-3 is written, it would make it incompatible/ > impossible > to merge this project with the GCC front-end from the GCC > foundation, the > way that GNU Ada was incorporated into that project. > > Because M3 uses a modified GCC code generator, it would have a made > sense to > go that way. > > But another, intriguing possibility exists: the LLVM project > (http://www.llvm.org). It looks like a very high-performance, > optimizing, > multiple target infrastructure, that would make Modula-3 highly > portable. > > I'm sure i'm not the first to think of this, but what are the > obstacle to > porting M3 to that environment (apart from the obvious effort in > programming > required... ;-))) > > -- > Louis Chr?tien > lchretien at mac.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.m.bates at cox.net Thu Aug 20 22:37:21 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Thu, 20 Aug 2009 15:37:21 -0500 Subject: [M3devel] How to update tickets myself Message-ID: <4A8DB401.2020209@cox.net> I just checked in fixed to ticket #1058. How can I access the ticket system and update it myself? Sorry, I forgot the # before the ticket number in the commit message. Rodney Bates From hendrik at topoi.pooq.com Fri Aug 21 01:48:26 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 20 Aug 2009 19:48:26 -0400 Subject: [M3devel] A question about the M3 licensing... In-Reply-To: References: Message-ID: <20090820234825.GB3925@topoi.pooq.com> On Thu, Aug 20, 2009 at 02:57:36PM -0400, Louis Chr?tien wrote: > I remember reading on this list (or was it the website...) that the way the > licensing of Modula-3 is written, it would make it incompatible/impossible > to merge this project with the GCC front-end from the GCC foundation, the > way that GNU Ada was incorporated into that project. > > Because M3 uses a modified GCC code generator, it would have a made sense to > go that way. > > But another, intriguing possibility exists: the LLVM project > (http://www.llvm.org). It looks like a very high-performance, optimizing, > multiple target infrastructure, that would make Modula-3 highly portable. I looked into LLVM for another language, with the idea of using its in-memory interface and constructing the parse tree directly. It turns out that it does type calculation during parse tree construction. THe result is that any type I want to use has to be completely defined before I can use it anywhere in the parse tree I'm trying to build. For compiler-synthesized records whose fields are invented while generating the intermediate code that uses them, this turned out to be an unacceptable ordering constraint. There are ways around this by storing the entire intermediate code in RAM as a kind of insertable-text data structure, and then writing it all to a disk file, and then having the LLVM back end read that file .... but it got messy. > > I'm sure i'm not the first to think of this, but what are the obstacle to > porting M3 to that environment (apart from the obvious effort in programming > required... ;-))) I suppose there's another possibility -- writing a new M3 front end with a different licence, and being free of SRC forever. Except that if some of our libraries are compiled from SRC source code, will we have to compile at installation tiem to avould distributing mixed GNU/SRC binaries? -- hendrik From hendrik at topoi.pooq.com Fri Aug 21 02:04:29 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 20 Aug 2009 20:04:29 -0400 Subject: [M3devel] Using LLVM (WAS; A question about the M3 licensing...) In-Reply-To: <20090820234825.GB3925@topoi.pooq.com> References: <20090820234825.GB3925@topoi.pooq.com> Message-ID: <20090821000429.GC3925@topoi.pooq.com> On Thu, Aug 20, 2009 at 07:48:26PM -0400, hendrik at topoi.pooq.com wrote: > > I looked into LLVM for another language, with the idea of using its > in-memory interface and constructing the parse tree directly. It turns > out that it does type calculation during parse tree construction. THe > result is that any type I want to use has to be completely defined > before I can use it anywhere in the parse tree I'm trying to build. For > compiler-synthesized records whose fields are invented while generating > the intermediate code that uses them, this turned out to be an > unacceptable ordering constraint. > > There are ways around this by storing the entire intermediate code in > RAM as a kind of insertable-text data structure, and then writing it all > to a disk file, and then having the LLVM back end read that file .... > but it got messy. By the way, I ended up using C-- for the project, which looks like a better-designed langauge, but with less of an organisation backing it for when things go wrong. I ended uo using the insertable-text data structure to generate the C-- code, too. But at least C-- was designed to have the text file be the primary form of inout; LLVM was designed to have parse trees built in RAM by the front end. -- hendrik. From jay.krell at cornell.edu Fri Aug 21 10:03:11 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 21 Aug 2009 08:03:11 +0000 Subject: [M3devel] SYSTEM_LIBS, quake, ./configure In-Reply-To: <20090820170737.xlylo4e268oo480o@mail.elegosoft.com> References: <1250779051.3002.6.camel@faramir.m3w.org> <20090820170737.xlylo4e268oo480o@mail.elegosoft.com> Message-ID: I know I'm guilty, and I'm a little on the fence. I think /maybe/ we should have m3-sys/cminstall/src/config-no-install/Solaris.libraries m3-sys/cminstall/src/config-no-install/Linux.libraries m3-sys/cminstall/src/config-no-install/NetBSD.libraries m3-sys/cminstall/src/config-no-install/OpenBSD.libraries m3-sys/cminstall/src/config-no-install/FreeBSD.libraries m3-sys/cminstall/src/config-no-install/IRIX.libraries m3-sys/cminstall/src/config-no-install/HPUX.libraries etc. and in packages we'd copy one of these to /usr/local/cm3/bin/config/cm3cfg.libraries so that we'd maintain the "codify the 'standard' locations" while also easing custom editing. More generally there's probably install/cm3/bin/config/libraries/*.quake. X11.quake c.quake ODBC.quake z.quake possibly install/cm3/bin/config/libraries/TARGET/*.quake. possibly probe between them. Each one or two lines. m3makefile dependent on ODBC would read: UseLibrary("X11") and/or UseLibraries(["X11", "ODBC"]) proc UseLibraries(a) is foreach b in a local c = CONFIG_ROOT & "/" & a & ".quake" if exists(c) include(c) else print("WARNING: not building package " & package_name & " because library " & a " is missing)" inform_cm3_to_skip_current_directory() end end proc UseLibrary(a) is UseLibraries([a]) end cm3 and scripts would have switches like: -error-for-missing-libraries -error-for-missing-library:X11 -ignore-missing-libraries -ignore-missing-libraries:X11,ODBC -ignore-missing-library:X11 and where I have print above, well, more like: inform_cm3_of_missing_library(a) but for that matter, move all the logic to cm3 probably. Probably should be using Modula-3 more and Quake less. But it's just so adequate and reasonably pleasant.. As well, need to consider what the "two level" aspect of the current design allows for and how to preserve that. I think it is "how to link library FOO" and "what global order to link libraries in". What I find ambiguous is code that checks for presence in SYSTEM_LIBORDER or SYSTEM_LIBRARIES. Seems to me like, probably, their members should always be the same? (The keys in one should be the members in the other and vice versa). ?? There are like three main scenarios I think. - It is a "package" available on the system, and therefore in a known platform specific location on the vast majority of systems. e.g. /usr on Debian, /usr/pkg on NetBSD, /usr/local on FreeBSD, /usr/sfw or /opt on Solaris. - It may or may not be an available package and user builds it from source and it goes to the library owner's default, usually /usr/local - Sometimes this is the same as the first. - User builds it from source and it goes to the system owner's preference. I have really only catered to the first. And since I emphasize folding common code, the other two have suffered. There is also the possibility of knowing about "pkgconfig". Which only solves the problem for packages that use it. Similarly I'm on the fence regarding autoconf and/or its approach. Autoconf seems quite messy and slow, but doing similar sorts of things in Quake hasn't seemed so bad. - Jay > Date: Thu, 20 Aug 2009 17:07:37 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] SYSTEM_LIBS, quake, ./configure > > Quoting Dragi?a Duri? : > > > In this ticket, https://projects.elego.de/cm3/ticket/1048, cvsup problem > > with libz on some systems is described. But, that problem is bigger than > > this - whole C portability issue. > > > > We need quake standardized way for locating (or not allocating:) system > > libraries. That way, it'll be possible to have Modula-3 programs and > > libraries which depend on C libraries like.... expat, tidy, mysqlclient, > > sqlite... distributed as wide as cm3 is. > > > > This is solvable with some quake magic? > > This kind of configure-function was part of the old CM3 installer, > but has become unused now, because Jay insists that it is unnecessary. > I don't think this should be a quake function executed at compile time. > Interfaces to a well-known set of system libraries are contained in > the config files. > > A quake definition of such a function would necessarily be system- > dependent, as it would need to know about all standard locations to > search on a certain platform. Or search all known locations, but then > the problem of resolving multiple hits comes up... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Aug 21 10:06:14 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 21 Aug 2009 10:06:14 +0200 Subject: [M3devel] How to update tickets myself In-Reply-To: <4A8DB401.2020209@cox.net> References: <4A8DB401.2020209@cox.net> Message-ID: <20090821100614.1hrjhbdou80ggowg@mail.elegosoft.com> Quoting "Rodney M. Bates" : > I just checked in fixed to ticket #1058. How can I > access the ticket system and update it myself? You need to login to trac to view further menu options, but you don't have an account yet as far as I can see. I'll create one for you this evening. Unfortunately the HTTP administration is broken in our trac setup (will be fixed and upgraded when our sysadmin stuff is complete again). > Sorry, I forgot the # > before the ticket number in > the commit message. You can correct/change CVS commit messages with the `cvs admin' command. Use something like cvs admin '-m:message text' Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Fri Aug 21 10:20:56 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 21 Aug 2009 10:20:56 +0200 Subject: [M3devel] A question about the M3 licensing... In-Reply-To: <20090820234825.GB3925@topoi.pooq.com> References: <20090820234825.GB3925@topoi.pooq.com> Message-ID: <20090821102056.nbcql8hsc8ww80cc@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > I suppose there's another possibility -- writing a new M3 front end with > a different licence, and being free of SRC forever. Except that if > some of our libraries are compiled from SRC source code, will we have to > compile at installation tiem to avould distributing mixed GNU/SRC > binaries? I don't think this is correct. The SRC license allows much more than the GNU FSF license. That was exactly the stumbling block when it came to integrating the M3 extensions to gcc into the gcc distribution. The FSF didn't like the way the backend was used in a different process context in order to avoid infecting all compiler code with the FSF license. Of course you can write another compiler front-end under the FSF license. I'd assume this will take several man-years though until you reach the quality of the current system. And any commercial use will then be much more difficult, but this is probably moot regarding the current widespread user base :-) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Aug 21 11:32:31 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 21 Aug 2009 09:32:31 +0000 Subject: [M3devel] A question about the M3 licensing... In-Reply-To: <20090821102056.nbcql8hsc8ww80cc@mail.elegosoft.com> References: <20090820234825.GB3925@topoi.pooq.com> <20090821102056.nbcql8hsc8ww80cc@mail.elegosoft.com> Message-ID: > Of course you can write another compiler front-end under the FSF It's surprising how similar Ada looks to Modula-3.. I've looked into llvm but haven't really got my head around it and/or the cm3 intermediate representation. If I could get my head around the latter I'd really like to try to translate that into C, for better and worse. Gcc relatively recently grew a plugin interface. That might be useful to us. Might -- you know, like, we'd say gcc -plugin-something-somesuch *.mc and gcc would load cm3cg.so or somesuch. Potentially m3-sys/m3cc would drop in size dramatically. - Jay > Date: Fri, 21 Aug 2009 10:20:56 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] A question about the M3 licensing... > > Quoting hendrik at topoi.pooq.com: > > > I suppose there's another possibility -- writing a new M3 front end with > > a different licence, and being free of SRC forever. Except that if > > some of our libraries are compiled from SRC source code, will we have to > > compile at installation tiem to avould distributing mixed GNU/SRC > > binaries? > > I don't think this is correct. The SRC license allows much more than > the GNU FSF license. That was exactly the stumbling block when it came > to integrating the M3 extensions to gcc into the gcc distribution. > The FSF didn't like the way the backend was used in a different process > context in order to avoid infecting all compiler code with the FSF > license. > > Of course you can write another compiler front-end under the FSF > license. I'd assume this will take several man-years though until > you reach the quality of the current system. And any commercial use > will then be much more difficult, but this is probably moot > regarding the current widespread user base :-) > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Fri Aug 21 11:47:16 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 21 Aug 2009 05:47:16 -0400 Subject: [M3devel] A question about the M3 licensing... In-Reply-To: References: <20090820234825.GB3925@topoi.pooq.com> <20090821102056.nbcql8hsc8ww80cc@mail.elegosoft.com> Message-ID: <20090821094716.GA5222@topoi.pooq.com> On Fri, Aug 21, 2009 at 09:32:31AM +0000, Jay K wrote: > > It's surprising how similar Ada looks to Modula-3.. I think they both dated from the same era, and both are ultimately based on Pascal syntax. > I've looked into llvm but haven't really got my head around it and/or > the cm3 intermediate representation. Do you mean the internal parse tree? > If I could get my head around the > latter I'd really like to try to translate that into C, for better and > worse. Didn't there use to be a translator from Modula 3 to C before people gave up on C as not being a good object code language? Wouldn't it still be lurking in anckent CVS branches somewhere? -- hendrik From wagner at elegosoft.com Fri Aug 21 12:18:25 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 21 Aug 2009 12:18:25 +0200 Subject: [M3devel] A question about the M3 licensing... In-Reply-To: References: <20090820234825.GB3925@topoi.pooq.com> <20090821102056.nbcql8hsc8ww80cc@mail.elegosoft.com> Message-ID: <20090821121825.pk6wsoyrb4w4gkgo@mail.elegosoft.com> Quoting Jay K : > > Of course you can write another compiler front-end under the FSF > > It's surprising how similar Ada looks to Modula-3.. > > I've looked into llvm but haven't really got my head around it > and/or the cm3 intermediate representation. If I could get my head > around the latter I'd really like to try to translate that into C, > for better and worse. Perhaps it would be best if we start to document the intermediate code representation. I.e. write a short but useful interface spec? Who would be able and willing to do that? > Gcc relatively recently grew a plugin interface. > > That might be useful to us. Might -- you know, like, we'd say gcc > -plugin-something-somesuch *.mc and gcc would load cm3cg.so or > somesuch. Potentially m3-sys/m3cc would drop in size dramatically. This sounds interesting, too. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Fri Aug 21 12:31:39 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 21 Aug 2009 12:31:39 +0200 Subject: [M3devel] A question about the M3 licensing... In-Reply-To: <20090821094716.GA5222@topoi.pooq.com> References: <20090820234825.GB3925@topoi.pooq.com> <20090821102056.nbcql8hsc8ww80cc@mail.elegosoft.com> <20090821094716.GA5222@topoi.pooq.com> Message-ID: <20090821123139.wy7bo0jhmgwg8s8c@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > On Fri, Aug 21, 2009 at 09:32:31AM +0000, Jay K wrote: >> >> It's surprising how similar Ada looks to Modula-3.. > > I think they both dated from the same era, and both are ultimately based > on Pascal syntax. > >> I've looked into llvm but haven't really got my head around it and/or >> the cm3 intermediate representation. > > Do you mean the internal parse tree? > >> If I could get my head around the >> latter I'd really like to try to translate that into C, for better and >> worse. > > Didn't there use to be a translator from Modula 3 to C before people > gave up on C as not being a good object code language? Wouldn't it > still be lurking in anckent CVS branches somewhere? AFAIK only the first release of M3 used C as intermediate code. Later SRC releases used gcc as backend. I don't know if any of the old archives are still accessible somewhere. SRC never used/provided a public version control system (though they internally had bindings for Vesta AFAIK). (For Vesta, see http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-168.pdf.) So there will be no public record of the old compiler sources in any repository. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dmuysers at hotmail.com Fri Aug 21 13:25:36 2009 From: dmuysers at hotmail.com (Dirk Muysers) Date: Fri, 21 Aug 2009 13:25:36 +0200 Subject: [M3devel] A question about the M3 licensing... In-Reply-To: <20090820234825.GB3925@topoi.pooq.com><20090821102056.nbcql8hsc8ww80cc@mail.elegosoft.com><20090821094716.GA5222@topoi.pooq.com> <20090821123139.wy7bo0jhmgwg8s8c@mail.elegosoft.com> References: <20090820234825.GB3925@topoi.pooq.com><20090821102056.nbcql8hsc8ww80cc@mail.elegosoft.com><20090821094716.GA5222@topoi.pooq.com> <20090821123139.wy7bo0jhmgwg8s8c@mail.elegosoft.com> Message-ID: Have a look at the Klagenfurt site (http://www.cs.tut.fi/lintula/manual/modula3/modula-3/html/m3pc.html) Maybe it still hangs around. If not, I have the source on my hard disk. -------------------------------------------------- From: "Olaf Wagner" Sent: Friday, August 21, 2009 12:31 PM To: Subject: Re: [M3devel] A question about the M3 licensing... > Quoting hendrik at topoi.pooq.com: > >> On Fri, Aug 21, 2009 at 09:32:31AM +0000, Jay K wrote: >>> >>> It's surprising how similar Ada looks to Modula-3.. >> >> I think they both dated from the same era, and both are ultimately based >> on Pascal syntax. >> >>> I've looked into llvm but haven't really got my head around it and/or >>> the cm3 intermediate representation. >> >> Do you mean the internal parse tree? >> >>> If I could get my head around the >>> latter I'd really like to try to translate that into C, for better and >>> worse. >> >> Didn't there use to be a translator from Modula 3 to C before people >> gave up on C as not being a good object code language? Wouldn't it >> still be lurking in anckent CVS branches somewhere? > > AFAIK only the first release of M3 used C as intermediate code. > Later SRC releases used gcc as backend. I don't know if any of > the old archives are still accessible somewhere. > > SRC never used/provided a public version control system (though they > internally had bindings for Vesta AFAIK). > (For Vesta, see > http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-168.pdf.) > > So there will be no public record of the old compiler sources in any > repository. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 > 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > From jay.krell at cornell.edu Fri Aug 21 16:19:18 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 21 Aug 2009 14:19:18 +0000 Subject: [M3devel] lock before or after try? Message-ID: lock try stuff finally unlock end or try lock stuff finally unlock end Lock can't fail so no difference? - Jay From lchretien at mac.com Fri Aug 21 20:35:03 2009 From: lchretien at mac.com (Louis =?ISO-8859-1?B?Q2hy6XRpZW4=?=) Date: Fri, 21 Aug 2009 14:35:03 -0400 Subject: [M3devel] A more precise question about M3 licensing... Message-ID: >From what I gathered so far on this thread, the SRC licence was quite a bit more liberal than the FSF license, which led to this "separate process" business for the code generation phase, which displeased the FSF somewhat... After having read the licence for the LLVM project (a one pager on their website), i find it quite liberal and you can basically do anything with the code, as long as you give proper credit and keep the license with the files. I'm no lawyer, but it seems that the SRC and LLVM licenses could play along fine, as opposed to the FSF trying to "infect" everything it touches... So, here's the idea I had: Combine the existing CM3 (and/or PM3) front-end, and modify it to emit LLVM bytecodes, so that we could use the LLVM back-end and infrastructure to create a complete compiler/linker. Would such a beast, by combining code from both licenses, be viable? I would like to keep the licensing as liberal as possible. I sure would like your ideas on this subject, P.S.: Olaf, I think your suggestion of documenting the existing intermidiate representation of the CM3 compiler would be an absolute first step... -- Louis Chr?tien lchretien at mac.com From wagner at elegosoft.com Fri Aug 21 21:36:52 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 21 Aug 2009 21:36:52 +0200 Subject: [M3devel] @M3paranoidgc always crashes In-Reply-To: <007DD8EA-4A1C-447A-B8FB-56396A8F6560@cs.purdue.edu> References: <20090820171058.0stkh5eu68cw0ksk@mail.elegosoft.com> <007DD8EA-4A1C-447A-B8FB-56396A8F6560@cs.purdue.edu> Message-ID: <20090821213652.nd7w7ddirkwookgk@mail.elegosoft.com> Quoting Tony Hosking : > Jay may have fixed this for now. It seems to be still broken, at least in the release branch. I'm currently adding some tests. Running a simple test program with @M3paranoidgc does not terminate: % ../src/p2/p213/FreeBSD4/pgm `Hello world' and `Hello world' are equal. The length of the first is 11 Extracting four chars from position 3 yields --lo w-- Salut = Hello done. luthien [~/work/cm3/m3-sys/m3tests/src] wagner % ../src/p2/p213/FreeBSD4/pgm @M3paranoidgc *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL^C It only prints half of the message and eats lots of CPU afterwards. I'll open a ticket for it and won't build release packages until it is fixed. Ticket is #1063. Olaf > > On 20 Aug 2009, at 11:10, Olaf Wagner wrote: > >> Quoting Tony Hosking : >> >>> Indeed, the use of paranoidgc itself now seems to be broken >>> (independently of any other bug you might be trying to track down by >>> invoking paranoidgc). >>> This is a serious bug, that should be rectified *before* any release. >>> Without it, we cannot easily diagnose GC bugs in the field. I have >>> little to no time to devote to this right now, but it does look like >>> the recent changes to threading initialisation has broken things. I >>> remember being very careful about initialization of threads and heap >>> components of the run-time when working on the original native >>> threads. In particular, the ability to invoke ThreadF.GetActivation >>> was allowed before ThreadF.Init had been called, because >>> ThreadF.InitActivations was able to be invoked on-demand independently >>> of ThreadF.Init. This independence now seems to have been eliminated >>> so as to eliminate a run-time check in GetActivation. >> >> Jay, could you open a ticket for that, too? >> >> And we also need to add tests for running with various @M3 options... >> >> Olaf >> >>> >>> On 20 Aug 2009, at 05:55, Jay K wrote: >>> >>>> >>>> Verified on SOLgnu and AMD64_LINUX. >>>> Probably related to initialization order changes that let user >>>> threads work again. >>>> Probably should just use untraced? >>>> >>>> >>>> >>>> % gdb --args ./cm3 @M3paranoidgc >>>> GNU gdb 6.4.90-debian >>>> Copyright (C) 2006 Free Software Foundation, Inc. >>>> GDB is free software, covered by the GNU General Public License, >>>> and you are >>>> welcome to change it and/or distribute copies of it under >>>> certain conditions. >>>> Type "show copying" to see the conditions. >>>> There is absolutely no warranty for GDB. Type "show warranty" >>>> for details. >>>> This GDB was configured as "x86_64-linux-gnu"...Using host >>>> libthread_db library >>>> "/lib/libthread_db.so.1". >>>> (gdb) run >>>> Starting program: /home/jkrell/cm3/bin/cm3 @M3paranoidgc >>>> [Thread debugging using libthread_db enabled] >>>> [New Thread 47899659458256 (LWP 29607)] >>>> Program received signal SIGSEGV, Segmentation fault. >>>> [Switching to Thread 47899659458256 (LWP 29607)] >>>> 0x00000000006934c5 in RTAllocator__GetTracedObj >>>> (M3_Eic7CK_def=Cannot access mem >>>> ory at address 0x800028d97718 >>>> ) >>>> at ../src/runtime/common/RTAllocator.m3:221 >>>> 221 INC(thread.inCritical); >>>> (gdb) bt >>>> #0 0x00000000006934c5 in RTAllocator__GetTracedObj >>>> (M3_Eic7CK_def=Cannot access >>>> memory at address 0x800028d97718 >>>> ) >>>> at ../src/runtime/common/RTAllocator.m3:221 >>>> #1 0x0000000000692e1f in RTHooks__AllocateTracedObj >>>> (M3_AJWxb1_defn=Cannot acce >>>> ss memory at address 0x800028d97788 >>>> ) >>>> at ../src/runtime/common/RTAllocator.m3:120 >>>> #2 0x000000000069b3ae in RTCollector__InstallSanityCheck () >>>> at ../src/runtime/common/RTCollector.m3:1637 >>>> #3 0x00000000006a1747 in RTHeapRep__Init () >>>> at ../src/runtime/common/RTCollector.m3:2769 >>>> #4 0x00000000006a2a1d in RTLinker__InitRuntime >>>> (M3_AcxOUs_p_argc=Cannot access >>>> memory at address 0x800028d97858 >>>> ) >>>> at ../src/runtime/common/RTLinker.m3:58 >>>> #5 0x00000000004160bc in main (argc=Cannot access memory at >>>> address 0x800028d97 >>>> 8a8 >>>> ) at _m3main.mc:3 >>>> (gdb) -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From roland.illig at gmx.de Fri Aug 21 21:44:50 2009 From: roland.illig at gmx.de (Roland Illig) Date: Fri, 21 Aug 2009 21:44:50 +0200 Subject: [M3devel] lock before or after try? In-Reply-To: References: Message-ID: <4A8EF932.2020804@gmx.de> Jay K schrieb: > lock > try > stuff > finally > unlock > end > > or > try > lock > stuff > finally > unlock > end > > Lock can't fail so no difference? I would always choose the first variant, because if locking fails for some reason (although it cannot, I know), unlock will not be called without a corresponding lock. At least in Java, it may happen that another thread interrupts this one just in the very nanosecond between the try and lock, throwing an exception, and then you would unlock something that hasn't been locked before. Roland From lchretien at mac.com Fri Aug 21 21:57:48 2009 From: lchretien at mac.com (Louis =?ISO-8859-1?B?Q2hy6XRpZW4=?=) Date: Fri, 21 Aug 2009 15:57:48 -0400 Subject: [M3devel] A more precise question about M3 licensing... Message-ID: (I don't know why it was truncated the first time...) >From what I gathered so far on this thread, the SRC licence was quite a bit more liberal than the FSF license, which led to this "separate process" business for the code generation phase, which displeased the FSF somewhat... After having read the licence for the LLVM project (a one pager on their website), i find it quite liberal and you can basically do anything with the code, as long as you give proper credit and keep the license with the files. I'm no lawyer, but it seems that the SRC and LLVM licenses could play along fine, as opposed to the FSF trying to "infect" everything it touches... So, here's the idea I had: Combine the existing CM3 (and/or PM3) front-end, and modify it to emit LLVM bytecodes, so that we could use the LLVM back-end and infrastructure to create a complete compiler/linker. Would such a beast, by combining code from both licenses, be viable? I would like to keep the licensing as liberal as possible. I sure would like your ideas on this subject, P.S.: Olaf, I think your suggestion of documenting the existing intermidiate representation of the CM3 compiler would be an absolute first step... -- Louis Chr?tien lchretien at mac.com From jay.krell at cornell.edu Fri Aug 21 23:47:35 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 21 Aug 2009 21:47:35 +0000 Subject: [M3devel] @M3paranoidgc always crashes In-Reply-To: <20090821213652.nd7w7ddirkwookgk@mail.elegosoft.com> References: <20090820171058.0stkh5eu68cw0ksk@mail.elegosoft.com> <007DD8EA-4A1C-447A-B8FB-56396A8F6560@cs.purdue.edu> <20090821213652.nd7w7ddirkwookgk@mail.elegosoft.com> Message-ID: Fix is in head. - Jay > Date: Fri, 21 Aug 2009 21:36:52 +0200 > From: wagner at elegosoft.com > To: hosking at cs.purdue.edu; jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] @M3paranoidgc always crashes > > Quoting Tony Hosking : > > > Jay may have fixed this for now. > > It seems to be still broken, at least in the release branch. I'm currently > adding some tests. Running a simple test program with @M3paranoidgc > does not terminate: > > % ../src/p2/p213/FreeBSD4/pgm > `Hello world' and `Hello world' are equal. > The length of the first is 11 > Extracting four chars from position 3 yields --lo w-- > Salut = Hello > > done. > luthien [~/work/cm3/m3-sys/m3tests/src] wagner > % ../src/p2/p213/FreeBSD4/pgm @M3paranoidgc > > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL^C > > It only prints half of the message and eats lots of CPU afterwards. > > I'll open a ticket for it and won't build release packages until it is > fixed. > > Ticket is #1063. > > Olaf > > > > > On 20 Aug 2009, at 11:10, Olaf Wagner wrote: > > > >> Quoting Tony Hosking : > >> > >>> Indeed, the use of paranoidgc itself now seems to be broken > >>> (independently of any other bug you might be trying to track down by > >>> invoking paranoidgc). > >>> This is a serious bug, that should be rectified *before* any release. > >>> Without it, we cannot easily diagnose GC bugs in the field. I have > >>> little to no time to devote to this right now, but it does look like > >>> the recent changes to threading initialisation has broken things. I > >>> remember being very careful about initialization of threads and heap > >>> components of the run-time when working on the original native > >>> threads. In particular, the ability to invoke ThreadF.GetActivation > >>> was allowed before ThreadF.Init had been called, because > >>> ThreadF.InitActivations was able to be invoked on-demand independently > >>> of ThreadF.Init. This independence now seems to have been eliminated > >>> so as to eliminate a run-time check in GetActivation. > >> > >> Jay, could you open a ticket for that, too? > >> > >> And we also need to add tests for running with various @M3 options... > >> > >> Olaf > >> > >>> > >>> On 20 Aug 2009, at 05:55, Jay K wrote: > >>> > >>>> > >>>> Verified on SOLgnu and AMD64_LINUX. > >>>> Probably related to initialization order changes that let user > >>>> threads work again. > >>>> Probably should just use untraced? > >>>> > >>>> > >>>> > >>>> % gdb --args ./cm3 @M3paranoidgc > >>>> GNU gdb 6.4.90-debian > >>>> Copyright (C) 2006 Free Software Foundation, Inc. > >>>> GDB is free software, covered by the GNU General Public License, > >>>> and you are > >>>> welcome to change it and/or distribute copies of it under > >>>> certain conditions. > >>>> Type "show copying" to see the conditions. > >>>> There is absolutely no warranty for GDB. Type "show warranty" > >>>> for details. > >>>> This GDB was configured as "x86_64-linux-gnu"...Using host > >>>> libthread_db library > >>>> "/lib/libthread_db.so.1". > >>>> (gdb) run > >>>> Starting program: /home/jkrell/cm3/bin/cm3 @M3paranoidgc > >>>> [Thread debugging using libthread_db enabled] > >>>> [New Thread 47899659458256 (LWP 29607)] > >>>> Program received signal SIGSEGV, Segmentation fault. > >>>> [Switching to Thread 47899659458256 (LWP 29607)] > >>>> 0x00000000006934c5 in RTAllocator__GetTracedObj > >>>> (M3_Eic7CK_def=Cannot access mem > >>>> ory at address 0x800028d97718 > >>>> ) > >>>> at ../src/runtime/common/RTAllocator.m3:221 > >>>> 221 INC(thread.inCritical); > >>>> (gdb) bt > >>>> #0 0x00000000006934c5 in RTAllocator__GetTracedObj > >>>> (M3_Eic7CK_def=Cannot access > >>>> memory at address 0x800028d97718 > >>>> ) > >>>> at ../src/runtime/common/RTAllocator.m3:221 > >>>> #1 0x0000000000692e1f in RTHooks__AllocateTracedObj > >>>> (M3_AJWxb1_defn=Cannot acce > >>>> ss memory at address 0x800028d97788 > >>>> ) > >>>> at ../src/runtime/common/RTAllocator.m3:120 > >>>> #2 0x000000000069b3ae in RTCollector__InstallSanityCheck () > >>>> at ../src/runtime/common/RTCollector.m3:1637 > >>>> #3 0x00000000006a1747 in RTHeapRep__Init () > >>>> at ../src/runtime/common/RTCollector.m3:2769 > >>>> #4 0x00000000006a2a1d in RTLinker__InitRuntime > >>>> (M3_AcxOUs_p_argc=Cannot access > >>>> memory at address 0x800028d97858 > >>>> ) > >>>> at ../src/runtime/common/RTLinker.m3:58 > >>>> #5 0x00000000004160bc in main (argc=Cannot access memory at > >>>> address 0x800028d97 > >>>> 8a8 > >>>> ) at _m3main.mc:3 > >>>> (gdb) > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Aug 22 00:32:44 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 22 Aug 2009 00:32:44 +0200 Subject: [M3devel] A more precise question about M3 licensing... In-Reply-To: References: Message-ID: <20090822003244.xwf5l3f5icswcgks@mail.elegosoft.com> Quoting Louis Chr?tien : > (I don't know why it was truncated the first time...) I've got a theory now regarding mail truncation. > From what I gathered so far on this thread, the SRC licence was quite a bit > more liberal than the FSF license, which led to this "separate process" > business for the code generation phase, which displeased the FSF somewhat.. It happens when a period gets wrapped to the start of a line. A line starting with a period is the ancient way to end a message or a file. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Sat Aug 22 00:36:24 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 22 Aug 2009 00:36:24 +0200 Subject: [M3devel] @M3paranoidgc always crashes In-Reply-To: References: <20090820171058.0stkh5eu68cw0ksk@mail.elegosoft.com> <007DD8EA-4A1C-447A-B8FB-56396A8F6560@cs.purdue.edu> <20090821213652.nd7w7ddirkwookgk@mail.elegosoft.com> Message-ID: <20090822003624.i5xcphcf4gsgo44o@mail.elegosoft.com> Quoting Jay K : > Fix is in head. OK. I merged runtime and thread from the trunk head. I couldn't compile it though. Some imports were missing. Strange. With the added imports, the tests seem to run fine. Thanks, Olaf > - Jay > >> Date: Fri, 21 Aug 2009 21:36:52 +0200 >> From: wagner at elegosoft.com >> To: hosking at cs.purdue.edu; jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] @M3paranoidgc always crashes >> >> Quoting Tony Hosking : >> >> > Jay may have fixed this for now. >> >> It seems to be still broken, at least in the release branch. I'm currently >> adding some tests. Running a simple test program with @M3paranoidgc >> does not terminate: >> >> % ../src/p2/p213/FreeBSD4/pgm >> `Hello world' and `Hello world' are equal. >> The length of the first is 11 >> Extracting four chars from position 3 yields --lo w-- >> Salut = Hello >> >> done. >> luthien [~/work/cm3/m3-sys/m3tests/src] wagner >> % ../src/p2/p213/FreeBSD4/pgm @M3paranoidgc >> >> >> *** >> *** runtime error: >> *** Segmentation violation - possible attempt to dereference NIL^C >> >> It only prints half of the message and eats lots of CPU afterwards. >> >> I'll open a ticket for it and won't build release packages until it is >> fixed. >> >> Ticket is #1063. >> >> Olaf >> >> > >> > On 20 Aug 2009, at 11:10, Olaf Wagner wrote: >> > >> >> Quoting Tony Hosking : >> >> >> >>> Indeed, the use of paranoidgc itself now seems to be broken >> >>> (independently of any other bug you might be trying to track down by >> >>> invoking paranoidgc). >> >>> This is a serious bug, that should be rectified *before* any release. >> >>> Without it, we cannot easily diagnose GC bugs in the field. I have >> >>> little to no time to devote to this right now, but it does look like >> >>> the recent changes to threading initialisation has broken things. I >> >>> remember being very careful about initialization of threads and heap >> >>> components of the run-time when working on the original native >> >>> threads. In particular, the ability to invoke ThreadF.GetActivation >> >>> was allowed before ThreadF.Init had been called, because >> >>> ThreadF.InitActivations was able to be invoked on-demand independently >> >>> of ThreadF.Init. This independence now seems to have been eliminated >> >>> so as to eliminate a run-time check in GetActivation. >> >> >> >> Jay, could you open a ticket for that, too? >> >> >> >> And we also need to add tests for running with various @M3 options... >> >> >> >> Olaf >> >> >> >>> >> >>> On 20 Aug 2009, at 05:55, Jay K wrote: >> >>> >> >>>> >> >>>> Verified on SOLgnu and AMD64_LINUX. >> >>>> Probably related to initialization order changes that let user >> >>>> threads work again. >> >>>> Probably should just use untraced? >> >>>> >> >>>> >> >>>> >> >>>> % gdb --args ./cm3 @M3paranoidgc >> >>>> GNU gdb 6.4.90-debian >> >>>> Copyright (C) 2006 Free Software Foundation, Inc. >> >>>> GDB is free software, covered by the GNU General Public License, >> >>>> and you are >> >>>> welcome to change it and/or distribute copies of it under >> >>>> certain conditions. >> >>>> Type "show copying" to see the conditions. >> >>>> There is absolutely no warranty for GDB. Type "show warranty" >> >>>> for details. >> >>>> This GDB was configured as "x86_64-linux-gnu"...Using host >> >>>> libthread_db library >> >>>> "/lib/libthread_db.so.1". >> >>>> (gdb) run >> >>>> Starting program: /home/jkrell/cm3/bin/cm3 @M3paranoidgc >> >>>> [Thread debugging using libthread_db enabled] >> >>>> [New Thread 47899659458256 (LWP 29607)] >> >>>> Program received signal SIGSEGV, Segmentation fault. >> >>>> [Switching to Thread 47899659458256 (LWP 29607)] >> >>>> 0x00000000006934c5 in RTAllocator__GetTracedObj >> >>>> (M3_Eic7CK_def=Cannot access mem >> >>>> ory at address 0x800028d97718 >> >>>> ) >> >>>> at ../src/runtime/common/RTAllocator.m3:221 >> >>>> 221 INC(thread.inCritical); >> >>>> (gdb) bt >> >>>> #0 0x00000000006934c5 in RTAllocator__GetTracedObj >> >>>> (M3_Eic7CK_def=Cannot access >> >>>> memory at address 0x800028d97718 >> >>>> ) >> >>>> at ../src/runtime/common/RTAllocator.m3:221 >> >>>> #1 0x0000000000692e1f in RTHooks__AllocateTracedObj >> >>>> (M3_AJWxb1_defn=Cannot acce >> >>>> ss memory at address 0x800028d97788 >> >>>> ) >> >>>> at ../src/runtime/common/RTAllocator.m3:120 >> >>>> #2 0x000000000069b3ae in RTCollector__InstallSanityCheck () >> >>>> at ../src/runtime/common/RTCollector.m3:1637 >> >>>> #3 0x00000000006a1747 in RTHeapRep__Init () >> >>>> at ../src/runtime/common/RTCollector.m3:2769 >> >>>> #4 0x00000000006a2a1d in RTLinker__InitRuntime >> >>>> (M3_AcxOUs_p_argc=Cannot access >> >>>> memory at address 0x800028d97858 >> >>>> ) >> >>>> at ../src/runtime/common/RTLinker.m3:58 >> >>>> #5 0x00000000004160bc in main (argc=Cannot access memory at >> >>>> address 0x800028d97 >> >>>> 8a8 >> >>>> ) at _m3main.mc:3 >> >>>> (gdb) >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From lchretien at mac.com Fri Aug 21 23:40:27 2009 From: lchretien at mac.com (Louis =?ISO-8859-1?B?Q2hy6XRpZW4=?=) Date: Fri, 21 Aug 2009 17:40:27 -0400 Subject: [M3devel] A more precise question about M3 licensing... Message-ID: (Real sorry about this, I don't know why it keeps being truncated...) >From what I gathered so far on this thread, the SRC licence was quite a bit more liberal than the FSF license, which led to this "separate process" business for the code generation phase, which displeased the FSF somewhat. ;-) After having read the licence for the LLVM project (a one pager on their website), i find it quite liberal and you can basically do anything with the code, as long as you give proper credit and keep the license with the files. I'm no lawyer, but it seems that the SRC and LLVM licenses could play along fine, as opposed to the FSF trying to "infect" everything it touches... So, here's the idea I had: Combine the existing CM3 (and/or PM3) front-end, and modify it to emit LLVM bytecodes, so that we could use the LLVM back-end and infrastructure to create a complete compiler/linker. Would such a beast, by combining code from both licenses, be viable? I would like to keep the licensing as liberal as possible. I sure would like your ideas on this subject, P.S.: Olaf, I think your suggestion of documenting the existing intermidiate representation of the CM3 compiler would be an absolute first step... -- Louis Chr?tien lchretien at mac.com From wagner at elegosoft.com Sat Aug 22 01:16:49 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 22 Aug 2009 01:16:49 +0200 Subject: [M3devel] config init problem Message-ID: <20090822011649.81l7rnebgg8884k4@mail.elegosoft.com> In MxConfig.m3 quake runtime exception were ignored and thrown away in EvalConfig. Writing them to stderr, we get the following output for a simple cm3.cfg file: % cat ~/cm3-rc3/bin/cm3.cfg %INSTALL_ROOT = "/ad0e/home/wagner/cm3-rc3" INSTALL_ROOT = path() & SL & ".." include(path() & "/config/FreeBSD4") luthien [~/work/cm3] wagner % cm3 -trace -version Critical Mass Modula-3 version p5.8.3 last updated: 2009-08-10 compiled: 2009-08-21 22:59:34 configuration: /ad0e/home/wagner/cm3-rc3/bin/cm3.cfg host: FreeBSD4 ****** /ad0e/home/wagner/cm3-rc3/bin/cm3.cfg ****** .0 SetLine 1 .1 SetLine 3 .2 LoadVar (193) "path" .3 StartCall .4 CallFunc 0 .5 LoadVar (373) "SL" quake runtime error: "/ad0e/home/wagner/cm3-rc3/bin/cm3.cfg", line 3: quake runtime error: undefined variable: SL --procedure-- -line- -file--- 3 /ad0e/home/wagner/cm3-rc3/bin/cm3.cfg target: SL gets defined in M3Build.m3 in cm3, along with all the other builtins that the compiler may use (and the config file author). Of course MxConfig in package m3quake does not know about these, as it creates its own quake machine on the fly. So configuration evaluation won't work in general currently, unless only standard quake functions and definitions are used. Any ideas? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sat Aug 22 04:13:59 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 22 Aug 2009 02:13:59 +0000 Subject: [M3devel] config init problem In-Reply-To: <20090822011649.81l7rnebgg8884k4@mail.elegosoft.com> References: <20090822011649.81l7rnebgg8884k4@mail.elegosoft.com> Message-ID: In the top of cm3.cfg put if not defined("SL") SL = "/" and/or just hardcode forward slash -- it works on Windows. There is already similar in a few places. Look at cminstall/src/config-no-install/cm3.cfg. This is why m3tohtml and such were crashing, but I dealt with them. I thought. Again, see the cm3.cfg and cm3cfg.common, etc. I have a proposal for next release that the predefines that cm3 does be made available to all quake clients via some new function. - Jay > Date: Sat, 22 Aug 2009 01:16:49 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] config init problem > > In MxConfig.m3 quake runtime exception were ignored and thrown away > in EvalConfig. Writing them to stderr, we get the following output > for a simple cm3.cfg file: > > % cat ~/cm3-rc3/bin/cm3.cfg > > %INSTALL_ROOT = "/ad0e/home/wagner/cm3-rc3" > INSTALL_ROOT = path() & SL & ".." > > include(path() & "/config/FreeBSD4") > > luthien [~/work/cm3] wagner > % cm3 -trace -version > Critical Mass Modula-3 version p5.8.3 > last updated: 2009-08-10 > compiled: 2009-08-21 22:59:34 > configuration: /ad0e/home/wagner/cm3-rc3/bin/cm3.cfg > host: FreeBSD4 > ****** /ad0e/home/wagner/cm3-rc3/bin/cm3.cfg ****** > .0 SetLine 1 > .1 SetLine 3 > .2 LoadVar (193) "path" > .3 StartCall > .4 CallFunc 0 > .5 LoadVar (373) "SL" > quake runtime error: "/ad0e/home/wagner/cm3-rc3/bin/cm3.cfg", line 3: > quake runtime error: undefined variable: SL > > --procedure-- -line- -file--- > 3 /ad0e/home/wagner/cm3-rc3/bin/cm3.cfg > target: > > SL gets defined in M3Build.m3 in cm3, along with all the other > builtins that the compiler may use (and the config file author). > Of course MxConfig in package m3quake does not know about these, > as it creates its own quake machine on the fly. > > So configuration evaluation won't work in general currently, > unless only standard quake functions and definitions are used. > > Any ideas? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Aug 22 11:07:41 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 22 Aug 2009 11:07:41 +0200 Subject: [M3devel] A more precise question about M3 licensing... In-Reply-To: <20090822003244.xwf5l3f5icswcgks@mail.elegosoft.com> References: <20090822003244.xwf5l3f5icswcgks@mail.elegosoft.com> Message-ID: <20090822110741.s6vo69beo000k8c8@mail.elegosoft.com> Quoting Olaf Wagner : > Quoting Louis Chr?tien : > >> (I don't know why it was truncated the first time...) > > I've got a theory now regarding mail truncation. > >> From what I gathered so far on this thread, the SRC licence was quite a bit >> more liberal than the FSF license, which led to this "separate process" >> business for the code generation phase, which displeased the FSF somewhat > > It happens when a period gets wrapped to the start of a line. A line > starting with a period is the ancient way to end a message or a > file. This got truncated, too. Another attempt with some periods removed. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Sat Aug 22 11:45:44 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 22 Aug 2009 11:45:44 +0200 Subject: [M3devel] config init problem In-Reply-To: References: <20090822011649.81l7rnebgg8884k4@mail.elegosoft.com> Message-ID: <20090822114544.i2wwhjp1wsgwws0c@mail.elegosoft.com> Quoting Jay K : > In the top of cm3.cfg put > if not defined("SL") SL = "/" > and/or just hardcode forward slash -- it works on Windows. > > There is already similar in a few places. > Look at cminstall/src/config-no-install/cm3.cfg. I'm not really comfortable with this solution. And I don't think you are ;-) It's just a workaround for SL, but doesn't deal with the other several dozens of definitions whiche _might_ be used in the config scripts. > This is why m3tohtml and such were crashing, but I dealt with them. > I thought. Again, see the cm3.cfg and cm3cfg.common, etc. If the exception wouldn't have been silently ignored in MxConfig.m3, that should have been easy to diagnose. We probably need to build some kind of quality-check tool for M3, which warns about such coding, or should review our changes more often and better. Alas, I'm afraid that won't happen because nobody has enougth time :-( Or perhpas just add a warning to the compiler if a caught exception is just thrown away? > I have a proposal for next release that the predefines that cm3 does > be made available to all quake clients via some new function. We could of course pass down the correctly initialized QM in cm3 (M3Build -> Makefile -> MxConfig). That would fix the problem for cm3, but not for other clients, unless we make them depend on most of the build functions. The latter seems rather unnecessary and inconvenient if only some simple definitions like TARGET are needed. Perhaps we need to distinguish between two kinds of config files: one level for simple clients which may only contain assignments and basic quake functions from m3quake, and more complex initialization for cm3. I agree we should probably not make such changes in the release branch now and postpone them. Olaf >> Date: Sat, 22 Aug 2009 01:16:49 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] config init problem >> >> In MxConfig.m3 quake runtime exception were ignored and thrown away >> in EvalConfig. Writing them to stderr, we get the following output >> for a simple cm3.cfg file: >> >> % cat ~/cm3-rc3/bin/cm3.cfg >> >> %INSTALL_ROOT = "/ad0e/home/wagner/cm3-rc3" >> INSTALL_ROOT = path() & SL & ".." >> >> include(path() & "/config/FreeBSD4") >> >> luthien [~/work/cm3] wagner >> % cm3 -trace -version >> Critical Mass Modula-3 version p5.8.3 >> last updated: 2009-08-10 >> compiled: 2009-08-21 22:59:34 >> configuration: /ad0e/home/wagner/cm3-rc3/bin/cm3.cfg >> host: FreeBSD4 >> ****** /ad0e/home/wagner/cm3-rc3/bin/cm3.cfg ****** >> .0 SetLine 1 >> .1 SetLine 3 >> .2 LoadVar (193) "path" >> .3 StartCall >> .4 CallFunc 0 >> .5 LoadVar (373) "SL" >> quake runtime error: "/ad0e/home/wagner/cm3-rc3/bin/cm3.cfg", line 3: >> quake runtime error: undefined variable: SL >> >> --procedure-- -line- -file--- >> 3 /ad0e/home/wagner/cm3-rc3/bin/cm3.cfg >> target: >> >> SL gets defined in M3Build.m3 in cm3, along with all the other >> builtins that the compiler may use (and the config file author). >> Of course MxConfig in package m3quake does not know about these, >> as it creates its own quake machine on the fly. >> >> So configuration evaluation won't work in general currently, >> unless only standard quake functions and definitions are used. >> >> Any ideas? -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From lchretien at mac.com Sat Aug 22 13:19:09 2009 From: lchretien at mac.com (Louis =?ISO-8859-1?B?Q2hy6XRpZW4=?=) Date: Sat, 22 Aug 2009 07:19:09 -0400 Subject: [M3devel] A more precise question about M3 licensing Message-ID: (Real sorry about this, I don't know why it keeps being truncated...) >From what I gathered so far on this thread, the SRC licence was quite a bit more liberal than the FSF license, which led to this "separate process" business for the code generation phase, which displeased the FSF somewhat. ;-) After having read the licence for the LLVM project (a one pager on their website), i find it quite liberal and you can basically do anything with the code, as long as you give proper credit and keep the license with the files. I'm no lawyer, but it seems that the SRC and LLVM licenses could play along fine, as opposed to the FSF trying to "infect" everything it touches. So, here's the idea I had: Combine the existing CM3 (and/or PM3) front-end, and modify it to emit LLVM bytecodes, so that we could use the LLVM back-end and infrastructure to create a complete compiler/linker. Would such a beast, by combining code from both licenses, be viable? I would like to keep the licensing as liberal as possible. I sure would like your ideas on this subject, P.S.: Olaf, I think your suggestion of documenting the existing intermidiate representation of the CM3 compiler would be an absolute first step. -- Louis Chr?tien lchretien at mac.com From jay.krell at cornell.edu Sat Aug 22 12:34:29 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Sat, 22 Aug 2009 05:34:29 -0500 Subject: [M3devel] config init problem In-Reply-To: <20090822011649.81l7rnebgg8884k4@mail.elegosoft.com> References: <20090822011649.81l7rnebgg8884k4@mail.elegosoft.com> Message-ID: Ignoring errors is very common and usually wrong. Better to have a system terminate than keep running in an unknown state.. "exceptions are better than error return codes" because they have the proper default -- to propagate -- but 1 they still lead to many bugs because lazy programmers still do play along in the escalating game and put in extra code to do the wrong thing and eat exceptions 2 disciplined C programmers know that almost anything can fail and can spot missing error checks at a glance. To wit even simple integer arithmetic can overflow. Look at the intsafe.h header on windows for what to do about that. - Jay (phone) On Aug 21, 2009, at 6:16 PM, Olaf Wagner wrote: > In MxConfig.m3 quake runtime exception were ignored and thrown away > in EvalConfig. Writing them to stderr, we get the following output > for a simple cm3.cfg file: > > % cat ~/cm3-rc3/bin/cm3.cfg > > %INSTALL_ROOT = "/ad0e/home/wagner/cm3-rc3" > INSTALL_ROOT = path() & SL & ".." > > include(path() & "/config/FreeBSD4") > > luthien [~/work/cm3] wagner > % cm3 -trace -version > Critical Mass Modula-3 version p5.8.3 > last updated: 2009-08-10 > compiled: 2009-08-21 22:59:34 > configuration: /ad0e/home/wagner/cm3-rc3/bin/cm3.cfg > host: FreeBSD4 > ****** /ad0e/home/wagner/cm3-rc3/bin/cm3.cfg ****** > .0 SetLine 1 > .1 SetLine 3 > .2 LoadVar (193) "path" > .3 StartCall > .4 CallFunc 0 > .5 LoadVar (373) "SL" > quake runtime error: "/ad0e/home/wagner/cm3-rc3/bin/cm3.cfg", line > 3: quake runtime error: undefined variable: SL > > --procedure-- -line- -file--- > 3 /ad0e/home/wagner/cm3-rc3/bin/cm3.cfg > target: > > SL gets defined in M3Build.m3 in cm3, along with all the other > builtins that the compiler may use (and the config file author). > Of course MxConfig in package m3quake does not know about these, > as it creates its own quake machine on the fly. > > So configuration evaluation won't work in general currently, > unless only standard quake functions and definitions are used. > > Any ideas? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ > any > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be > rlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > From hendrik at topoi.pooq.com Sat Aug 22 13:38:26 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sat, 22 Aug 2009 07:38:26 -0400 Subject: [M3devel] A more precise question about M3 licensing... In-Reply-To: References: Message-ID: <20090822113826.GC7643@topoi.pooq.com> On Fri, Aug 21, 2009 at 02:35:03PM -0400, Louis Chr?tien wrote: > >From what I gathered so far on this thread, the SRC licence was quite a bit > more liberal than the FSF license, which led to this "separate process" > business for the code generation phase, which displeased the FSF somewhat.. The SRC licence specified that if any of this code, whether the original SRC code or other peoples' modifications or additions, ever got back to SRC, they could do anything they wanted with it. This means that if you add code to the M3 system, you have to allow SRC to do anything they want to it. This clause is incompatible with the GPL, which restricts the freedom to distribute binary code without source. Existing GPL'd code can therefore not be incorporated into the Modula 3 system because SRC would not have the freedom to do anything they want with it. -- hendrik From hendrik at topoi.pooq.com Sat Aug 22 13:40:55 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sat, 22 Aug 2009 07:40:55 -0400 Subject: [M3devel] A more precise question about M3 licensing... In-Reply-To: References: Message-ID: <20090822114055.GD7643@topoi.pooq.com> On Fri, Aug 21, 2009 at 05:40:27PM -0400, Louis Chr?tien wrote: > (Real sorry about this, I don't know why it keeps being truncated...) > > >From what I gathered so far on this thread, the SRC licence was quite a bit > more liberal than the FSF license, which led to this "separate process" > business for the code generation phase, which displeased the FSF somewhat. > ;-) > > After having read the licence for the LLVM project (a one pager on their > website), i find it quite liberal and you can basically do anything with the > code, as long as you give proper credit and keep the license with the files So is the licence for C--, which I believe says simply "This software can be used by anyone for any purpose". -- hendrik From jay.krell at cornell.edu Sat Aug 22 13:41:31 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Sat, 22 Aug 2009 06:41:31 -0500 Subject: [M3devel] config init problem In-Reply-To: <20090822114544.i2wwhjp1wsgwws0c@mail.elegosoft.com> References: <20090822011649.81l7rnebgg8884k4@mail.elegosoft.com> <20090822114544.i2wwhjp1wsgwws0c@mail.elegosoft.com> Message-ID: <2190F957-A6DE-426A-9159-8E498373F140@hotmail.com> Most config file readers need very little -- the paths and target. I think we can probably get by with very little change. I don't think we need worry much about all the functions in cm3 but not m3quake. I dare suggest a small library instead if quake that parses command line for target, defaults it to host, maybe checks $cm3_path, searches $path to decide the paths. A wrinkle is like profiling twiddling build_dir. Has that ever worked in reactor?? - Jay (phone) On Aug 22, 2009, at 4:45 AM, Olaf Wagner wrote: > Quoting Jay K : > >> In the top of cm3.cfg put >> if not defined("SL") SL = "/" >> and/or just hardcode forward slash -- it works on Windows. >> >> There is already similar in a few places. >> Look at cminstall/src/config-no-install/cm3.cfg. > > I'm not really comfortable with this solution. And I don't think > you are ;-) It's just a workaround for SL, but doesn't deal with the > other several dozens of definitions whiche _might_ be used in the > config scripts. > >> This is why m3tohtml and such were crashing, but I dealt with them. >> I thought. Again, see the cm3.cfg and cm3cfg.common, etc. > > If the exception wouldn't have been silently ignored in MxConfig.m3, > that should have been easy to diagnose. We probably need to build > some kind of quality-check tool for M3, which warns about such > coding, or should review our changes more often and better. Alas, > I'm afraid that won't happen because nobody has enougth time :-( > > Or perhpas just add a warning to the compiler if a caught exception > is just thrown away? > >> I have a proposal for next release that the predefines that cm3 does >> be made available to all quake clients via some new function. > > We could of course pass down the correctly initialized QM in cm3 > (M3Build -> Makefile -> MxConfig). That would fix the problem for > cm3, but not for other clients, unless we make them depend on most > of the build functions. The latter seems rather unnecessary and > inconvenient if only some simple definitions like TARGET are needed. > Perhaps we need to distinguish between two kinds of config files: > one level for simple clients which may only contain assignments > and basic quake functions from m3quake, and more complex > initialization > for cm3. > > I agree we should probably not make such changes in the release branch > now and postpone them. > > Olaf > >>> Date: Sat, 22 Aug 2009 01:16:49 +0200 >>> From: wagner at elegosoft.com >>> To: m3devel at elegosoft.com >>> Subject: [M3devel] config init problem >>> >>> In MxConfig.m3 quake runtime exception were ignored and thrown away >>> in EvalConfig. Writing them to stderr, we get the following output >>> for a simple cm3.cfg file: >>> >>> % cat ~/cm3-rc3/bin/cm3.cfg >>> >>> %INSTALL_ROOT = "/ad0e/home/wagner/cm3-rc3" >>> INSTALL_ROOT = path() & SL & ".." >>> >>> include(path() & "/config/FreeBSD4") >>> >>> luthien [~/work/cm3] wagner >>> % cm3 -trace -version >>> Critical Mass Modula-3 version p5.8.3 >>> last updated: 2009-08-10 >>> compiled: 2009-08-21 22:59:34 >>> configuration: /ad0e/home/wagner/cm3-rc3/bin/cm3.cfg >>> host: FreeBSD4 >>> ****** /ad0e/home/wagner/cm3-rc3/bin/cm3.cfg ****** >>> .0 SetLine 1 >>> .1 SetLine 3 >>> .2 LoadVar (193) "path" >>> .3 StartCall >>> .4 CallFunc 0 >>> .5 LoadVar (373) "SL" >>> quake runtime error: "/ad0e/home/wagner/cm3-rc3/bin/cm3.cfg", line >>> 3: >>> quake runtime error: undefined variable: SL >>> >>> --procedure-- -line- -file--- >>> 3 /ad0e/home/wagner/cm3-rc3/bin/cm3.cfg >>> target: >>> >>> SL gets defined in M3Build.m3 in cm3, along with all the other >>> builtins that the compiler may use (and the config file author). >>> Of course MxConfig in package m3quake does not know about these, >>> as it creates its own quake machine on the fly. >>> >>> So configuration evaluation won't work in general currently, >>> unless only standard quake functions and definitions are used. >>> >>> Any ideas? > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ > any > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be > rlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > From rodney.m.bates at cox.net Sat Aug 22 21:17:46 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Sat, 22 Aug 2009 14:17:46 -0500 Subject: [M3devel] A question about the M3 licensing... In-Reply-To: <20090821102056.nbcql8hsc8ww80cc@mail.elegosoft.com> References: <20090820234825.GB3925@topoi.pooq.com> <20090821102056.nbcql8hsc8ww80cc@mail.elegosoft.com> Message-ID: <4A90445A.9070201@cox.net> Olaf Wagner wrote: > Quoting hendrik at topoi.pooq.com: > >> I suppose there's another possibility -- writing a new M3 front end with >> a different licence, and being free of SRC forever. Except that if >> some of our libraries are compiled from SRC source code, will we have to >> compile at installation tiem to avould distributing mixed GNU/SRC >> binaries? > > I don't think this is correct. The SRC license allows much more than > the GNU FSF license. That was exactly the stumbling block when it came > to integrating the M3 extensions to gcc into the gcc distribution. > The FSF didn't like the way the backend was used in a different process > context in order to avoid infecting all compiler code with the FSF > license. > > Of course you can write another compiler front-end under the FSF > license. I'd assume this will take several man-years though until > you reach the quality of the current system. And any commercial use > will then be much more difficult, but this is probably moot > regarding the current widespread user base :-) This could be very hard to pull off, or maybe not so hard, but I think the best result would be if HP, as SRC's successor, could be persuaded to assign copyright ownership to FSF, or maybe even some other entity, such as a nonprofit foundation or something. I can't think how keeping it themselves would have any business value to HP, and anything to get it more widely used might have positive value to them. Of course, it would be complicated by the fact that there are some files around with a half-dozen or so other copyright owners and licenses. > > Olaf From wagner at elegosoft.com Sun Aug 23 01:51:25 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 23 Aug 2009 01:51:25 +0200 Subject: [M3devel] CM3 Release 5.8 RC3 Message-ID: <20090823015125.e1mq5xiogc4gkkw8@mail.elegosoft.com> The first packages of CM3 release 5.8 RC3 are now available on www.opencm3.net. More packages will be built during the next days. As there are still 11 open tickets for 5.8 and more are to be expected when RC3 is tested by more users, I've also retargeted the date for the final release to the end of September. Please let me know of any problems you encounter and features that you are missing. The best way of doing this is opening a ticket at https://projects.elego.de/cm3/newticket. Thanks for your support and cooperation, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Sun Aug 23 06:43:44 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 23 Aug 2009 00:43:44 -0400 Subject: [M3devel] A question about the M3 licensing... In-Reply-To: <4A90445A.9070201@cox.net> References: <20090820234825.GB3925@topoi.pooq.com> <20090821102056.nbcql8hsc8ww80cc@mail.elegosoft.com> <4A90445A.9070201@cox.net> Message-ID: <20090823044343.GA9202@topoi.pooq.com> On Sat, Aug 22, 2009 at 02:17:46PM -0500, Rodney M. Bates wrote: > Olaf Wagner wrote: > >Quoting hendrik at topoi.pooq.com: > > > >>I suppose there's another possibility -- writing a new M3 front end with > >>a different licence, and being free of SRC forever. Except that if > >>some of our libraries are compiled from SRC source code, will we have to > >>compile at installation tiem to avould distributing mixed GNU/SRC > >>binaries? > > > >I don't think this is correct. The SRC license allows much more than > >the GNU FSF license. That was exactly the stumbling block when it came > >to integrating the M3 extensions to gcc into the gcc distribution. > >The FSF didn't like the way the backend was used in a different process > >context in order to avoid infecting all compiler code with the FSF > >license. > > > >Of course you can write another compiler front-end under the FSF > >license. I'd assume this will take several man-years though until > >you reach the quality of the current system. And any commercial use > >will then be much more difficult, but this is probably moot > >regarding the current widespread user base :-) > > This could be very hard to pull off, or maybe not so hard, but I think > the best result would be if HP, as SRC's successor, could be persuaded > to assign copyright ownership to FSF, or maybe even some other > entity, such as a nonprofit foundation or something. I can't think how > keeping it themselves would have any business value to HP, and > anything to get it more widely used might have positive value to them. > > Of course, it would be complicated by the fact that there are some > files around with a half-dozen or so other copyright owners and > licenses. But liberating the SRC stuff would handle most of it. And I're recommend a licence that is strictly more liberal than FSF's. Perhaps something like the MIT license, or BSD. They're compatible with GPL, and we may end up having fewer problems in the far future. We might someday, for example, have users needing to link proprietary code with parts of the compiler, and it would be good for that to be possible. - hendrik From jay.krell at cornell.edu Sun Aug 23 07:41:45 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 23 Aug 2009 05:41:45 +0000 Subject: [M3devel] http://www.opencm3.net/ Message-ID: http://www.opencm3.net/ is now remarkably bad. Besides the low contrast high frequency mix of greens and blues, there is also a double nesting of frames by default. - Jay From jay.krell at cornell.edu Sun Aug 23 07:52:36 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 23 Aug 2009 05:52:36 +0000 Subject: [M3devel] more web site problems Message-ID: http://www.opencm3.net/releng/collection-core.html has various README links. I'm certain many are not useful (like under gcc) and I'm not certain if any would be, but asis they all give access denied. "platform-specific library imports for Windows systems" is bogus. They are called "import libraries", not "library imports". The Description is obviously wrong. Maybe that is a placeholder? Or not expanded? The Dependencies look funny but maybe as intended? Or maybe this is a unique output of having no dependencies? Actually they look quite good for other package collections, to provide all that data. I can't tell if only immediately dependent package collections are listed or transitive. The access denied on README isn't unique to core. http://www.opencm3.net/releng/collection-database.html http://www.opencm3.net/releng/collection-cvsup.html contains broken link to "manual page cvpasswd". http://www.opencm3.net/releng/collection-devlib.html README access denied - Jay From jay.krell at cornell.edu Sun Aug 23 08:17:41 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 23 Aug 2009 06:17:41 +0000 Subject: [M3devel] DoRootExport vs. DoRootdExport? Message-ID: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/cm3/src/M3Build.m3?r1=1.28.2.1&r2=1.28.2.2 "d" is or derived, and therefore there is a missing edit after the copy/paste? - Jay From jay.krell at cornell.edu Sun Aug 23 08:26:34 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 23 Aug 2009 06:26:34 +0000 Subject: [M3devel] Posix/Win32 linger options inverted? Message-ID: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-comm/tcp/src/POSIX/TCP.m3?rev=1.7;content-type=text%2Fplain vs. http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-comm/tcp/src/WIN32/TCP.m3?rev=1.3;content-type=text%2Fplain search for linger: PROCEDURE InitFD(fd: CARDINAL) = (* We assume that the runtime ignores SIGPIPE signals *) VAR one: int := 1; linger := Usocket.struct_linger{1, 1}; vs. PROCEDURE InitSock(sock: WinSock.SOCKET) = (* We assume that the runtime ignores SIGPIPE signals *) VAR one : BOOL := 1; linger := WinSock.struct_linger{0, 0}; Surely they can't both be correct. Which is correct? The Posix one? - Jay From jay.krell at cornell.edu Sun Aug 23 09:28:42 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 23 Aug 2009 07:28:42 +0000 Subject: [M3devel] sin_len? Message-ID: I'm looking to - remove the platform dependency defining struct_sockaddr_in - provide a platform independent struct_sockaddr_un What is the deal with the sin_len field? We never fill it in? It is difficult to find documentation as to the meaning of the field. There is this: http://lists.samba.org/archive/rsync/2002-February/001531.html But I believe we have always just left it as zero and I will probably do that. I believe the historical practise here is out of date with IPv6 around, as well. - Jay From jay.krell at cornell.edu Sun Aug 23 10:11:42 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 23 Aug 2009 08:11:42 +0000 Subject: [M3devel] sin_len? In-Reply-To: References: Message-ID: I was going to convert from a portable idealized form of struct_sockaddr_in/un, but I could only support AF_INET and AF_LOCAL/UNIX, and there are many others, so this isn't really viable. Instead I'll strive for the current approach of duplicating the headers reliably, in this small case. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Sun, 23 Aug 2009 07:28:42 +0000 > Subject: [M3devel] sin_len? > > > I'm looking to > - remove the platform dependency defining struct_sockaddr_in > - provide a platform independent struct_sockaddr_un > > What is the deal with the sin_len field? > We never fill it in? > It is difficult to find documentation as to the meaning of the field. > > There is this: > > http://lists.samba.org/archive/rsync/2002-February/001531.html > > But I believe we have always just left it as zero and I will probably do that. > > > I believe the historical practise here is out of date with IPv6 around, as well. > > - Jay From dragisha at m3w.org Sun Aug 23 10:47:57 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 23 Aug 2009 10:47:57 +0200 Subject: [M3devel] New Socket.[im]3? was: Re: sin_len? In-Reply-To: References: Message-ID: <1251017277.30939.31.camel@faramir.m3w.org> There were once (and still is, but not only ones for IPv4) different APIs for TCP and UDP. cmass people unified that in Socket.i3 API, but only for IPv4... What we really need here is even more general Socket.i3, covering AF_UNIX and IPv6... To accomplish this, we have to generalize (OO-ize :) ) Socket.EndPoint to include IPv4/IPv6/AF_UNIX (whatever it's called on Windows, named pipe or...) addresses so Socket(Posix|WIN32).m3 can decide about how to progress through related operations. Good news - Socket interface is unused from current cm3 source tree. Bad news - we don't know about other clients to it. Good news - this is Modula-3 and such changes are easy do detect and easier to change. Thus said... This is probably nothing for 5.8 to care about. If others agreee, and nobody does it, I can find some time in following months to unify work I already have done for AF_UNIX and also to cook what is needed for IPv6 (not much I believe). And of course there's always a "but". What will we do about SCTP? On Sun, 2009-08-23 at 08:11 +0000, Jay K wrote: > I was going to convert from a portable idealized form of struct_sockaddr_in/un, but I could only support AF_INET and AF_LOCAL/UNIX, and there are many others, so this isn't really viable. Instead I'll strive for the current approach of duplicating the headers reliably, in this small case. > > - Jay > > > > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: m3devel at elegosoft.com > > Date: Sun, 23 Aug 2009 07:28:42 +0000 > > Subject: [M3devel] sin_len? > > > > > > I'm looking to > > - remove the platform dependency defining struct_sockaddr_in > > - provide a platform independent struct_sockaddr_un > > > > What is the deal with the sin_len field? > > We never fill it in? > > It is difficult to find documentation as to the meaning of the field. > > > > There is this: > > > > http://lists.samba.org/archive/rsync/2002-February/001531.html > > > > But I believe we have always just left it as zero and I will probably do that. > > > > > > I believe the historical practise here is out of date with IPv6 around, as well. > > > > - Jay -- Dragi?a Duri? From wagner at elegosoft.com Sun Aug 23 12:52:49 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 23 Aug 2009 12:52:49 +0200 Subject: [M3devel] more web site problems In-Reply-To: References: Message-ID: <20090823125249.cc7q0zjwxwcoo84g@mail.elegosoft.com> Quoting Jay K : > http://www.opencm3.net/releng/collection-core.html > > has various README links. > I'm certain many are not useful (like under gcc) and I'm not certain if > any would be, but asis they all give access denied. All README links should now be fixed. I had renamed the workspace and forgot to adapt the link. > "platform-specific library imports for Windows systems" > is bogus. They are called "import libraries", not > "library imports". All package descriptions are in the DESC files. I've fixed this one now. Feel free to improve further. HTML needs to be regenerated now. I'll do that soon. > The Description is obviously wrong. > Maybe that is a placeholder? > Or not expanded? > The Dependencies look funny but maybe as intended? > Or maybe this is a unique output of having no dependencies? > Actually they look quite good for other package collections, > to provide all that data. I can't tell if only > immediately dependent package collections are listed > or transitive. It's just the output of my scripts that compute the dependencies. I haven't had put any efforts into making it beautiful. I thought it would be easily understandable, but that's probably wrong ;-) > The access denied on README isn't unique to core. > http://www.opencm3.net/releng/collection-database.html > > http://www.opencm3.net/releng/collection-cvsup.html > contains broken link to "manual page cvpasswd". That's the result of your putting overrides into the CVSup m3makefiles. Now nothing gets shipped. Probably all the CVSup packages are broken in this respect. Overrides should only be in m3override files and be activated with the -override option. > http://www.opencm3.net/releng/collection-devlib.html > README access denied Thanks for the comments, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Sun Aug 23 13:00:19 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 23 Aug 2009 13:00:19 +0200 Subject: [M3devel] DoRootExport vs. DoRootdExport? In-Reply-To: References: Message-ID: <20090823130019.yucefnpwe8cksgkw@mail.elegosoft.com> Quoting Jay K : > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/cm3/src/M3Build.m3?r1=1.28.2.1&r2=1.28.2.2 > > "d" is or derived, and therefore there is a missing edit after the > copy/paste? Yes, that's wrong. Should be no problem for RC3 though. Fixed in the branch, tag not moved. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Sun Aug 23 13:06:44 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 23 Aug 2009 13:06:44 +0200 Subject: [M3devel] New Socket.[im]3? was: Re: sin_len? In-Reply-To: <1251017277.30939.31.camel@faramir.m3w.org> References: <1251017277.30939.31.camel@faramir.m3w.org> Message-ID: <20090823130644.c3rv6u1dcs0wookk@mail.elegosoft.com> Quoting Dragi?a Duri? : > There were once (and still is, but not only ones for IPv4) different > APIs for TCP and UDP. cmass people unified that in Socket.i3 API, but > only for IPv4... What we really need here is even more general > Socket.i3, covering AF_UNIX and IPv6... > > To accomplish this, we have to generalize (OO-ize :) ) Socket.EndPoint > to include IPv4/IPv6/AF_UNIX (whatever it's called on Windows, named > pipe or...) addresses so Socket(Posix|WIN32).m3 can decide about how to > progress through related operations. > > Good news - Socket interface is unused from current cm3 source tree. Bad > news - we don't know about other clients to it. Good news - this is > Modula-3 and such changes are easy do detect and easier to change. > > Thus said... This is probably nothing for 5.8 to care about. If others > agreee, and nobody does it, I can find some time in following months to > unify work I already have done for AF_UNIX and also to cook what is > needed for IPv6 (not much I believe). > > And of course there's always a "but". What will we do about SCTP? This is definitely nothing for the release. There are still enough problems without refactoring network layers. I'd really appreciate it if you or somebody else takes care of it though. IPv6 has been on my wishlist for M3 for years, too. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Sun Aug 23 18:31:38 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 23 Aug 2009 18:31:38 +0200 Subject: [M3devel] New Socket.[im]3? was: Re: sin_len? In-Reply-To: <20090823130644.c3rv6u1dcs0wookk@mail.elegosoft.com> References: <1251017277.30939.31.camel@faramir.m3w.org> <20090823130644.c3rv6u1dcs0wookk@mail.elegosoft.com> Message-ID: <1251045098.30939.36.camel@faramir.m3w.org> IPv6 is a plaything right now... I've had setup for it on few machines, but it did not last... Though it's not a hassle to make LAN setup... I'll look through this, and esp unifying interface for IPv4/IPv6/(AF_UNIX|named pipes). On Sun, 2009-08-23 at 13:06 +0200, Olaf Wagner wrote: > This is definitely nothing for the release. There are still enough > problems without refactoring network layers. > > I'd really appreciate it if you or somebody else takes care of it > though. > > IPv6 has been on my wishlist for M3 for years, too. -- Dragi?a Duri? From hendrik at topoi.pooq.com Mon Aug 24 02:56:58 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 23 Aug 2009 20:56:58 -0400 Subject: [M3devel] trying RC3 Message-ID: <20090824005658.GA11486@topoi.pooq.com> Well, core and gui installed flaelessly on a Debian lenny system. But cvsup ended with the message: package was built with overrides, not shipping. Now maybe that's correct behaviour, but It doesn't look like it. Here are the details: hendrik at lovesong:~/cm3/ia32/RC3$ mkdir cvsup hendrik at lovesong:~/cm3/ia32/RC3$ cd cvsup hendrik at lovesong:~/cm3/ia32/RC3/cvsup$ tar -zxf ../../../dn/cm3-bin-ws-cvsup-LINUXLIBC6-5.8.3-RC3.tgz hendrik at lovesong:~/cm3/ia32/RC3/cvsup$ ls collection-cvsup.html install.sh m3-tools setup.cmd hendrik at lovesong:~/cm3/ia32/RC3/cvsup$ ./install.sh installing package m3-tools/cvsup/suplib --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/suplib/LINUXLIBC6 .M3EXPORTS . => /usr/local/cm3/lib libsuplib.so.5 . => /usr/local/cm3/pkg/suplib/LINUXLIBC6 libsuplib.a libsuplib.m3x .M3WEB ../LINUXLIBC6 => /usr/local/cm3/pkg/suplib/LINUXLIBC6 ExecRecSeq.i3 ExecRecSeq.m3 DirEntryList.i3 DirEntryList.m3 DirEntryListSort.i3 DirEntryListSort.m3 TextGlobTreeTbl.i3 TextGlobTreeTbl.m3 ExecRecSeqRep.i3 RCSAccessList.i3 RCSAccessList.m3 RCSTagList.i3 RCSTagList.m3 RCSTagListSort.i3 RCSTagListSort.m3 RCSEditTbl.i3 RCSEditTbl.m3 SortedRCSEditTbl.i3 SortedRCSEditTbl.m3 RCSDeltaList.i3 RCSDeltaList.m3 RCSDeltaListSort.i3 RCSDeltaListSort.m3 RCSDeltaTbl.i3 RCSDeltaTbl.m3 SortedRCSDeltaTbl.i3 SortedRCSDeltaTbl.m3 RsyncBlockArraySort.i3 RsyncBlockArraySort.m3 ../src => /usr/local/cm3/pkg/suplib/src RegEx.i3 RegEx.m3 Merger.ig Merger.mg merger.tmpl CText.i3 Uglob.i3 PathComp.i3 PathComp.m3 ChannelMux.m3 ChannelMux.i3 Logger.i3 Logger.m3 LoggerClass.i3 SplitLogger.i3 SplitLogger.m3 SysLogger.i3 SysLogger.m3 TimeStampLogger.i3 TimeStampLogger.m3 WrLogger.i3 WrLogger.m3 ProcTitle.i3 Ugzip.i3 Ugzip.m3 UgzipP.i3 Umd5.i3 MySyslog.i3 WatchDog.i3 WatchDog.m3 IOWatchDog.i3 IOWatchDog.m3 MD5Digest.i3 MD5Digest.m3 MD5.m3 MD5.i3 AuthMD5.m3 AuthMD5.i3 TokScan.m3 TokScan.i3 DevT.i3 FileAttr.i3 FileAttr.m3 FileAttrRep.i3 FileID.m3 FileID.i3 CVProto.m3 CVProto.i3 EscapedRd.i3 EscapedRd.m3 EscapedWr.i3 EscapedWr.m3 MD5Wr.i3 MD5Wr.m3 ErrMsg.i3 ErrMsg.m3 DirEntry.i3 DirEntry.m3 Glob.m3 Glob.i3 GlobTree.i3 GlobTree.m3 LockFile.m3 LockFile.i3 ExecRec.i3 RCSError.i3 RCSString.m3 RCSString.i3 RCSPhrase.i3 RCSPhrase.m3 RCSPhrases.i3 RCSPhrases.m3 RCSDate.m3 RCSDate.i3 RCSRevNum.i3 RCSRevNum.m3 RCSAccess.m3 RCSAccess.i3 RCSTag.i3 RCSTag.m3 RCSEdit.i3 RCSDelta.m3 RCSDelta.i3 RCSDeltaClass.i3 RCSKeyword.m3 RCSKeyword.i3 RCSFile.i3 RCSFile.m3 SupFileRec.i3 SupFileRec.m3 SupMisc.i3 SupMisc.m3 FileStatus.m3 FileStatus.i3 FileStatusRaw.i3 StatusFile.i3 StatusFile.m3 CVTree.m3 CVTree.i3 GzipError.m3 GzipError.i3 GzipRd.i3 GzipRd.m3 GzipWr.i3 GzipWr.m3 RsyncBlock.m3 RsyncBlock.i3 RsyncFile.m3 RsyncFile.i3 Reaper.i3 Reaper.m3 SigHandler.m3 SigHandler.i3 UnixMisc.m3 UnixMisc.i3 UnixMiscC.c Attic.i3 Attic.m3 ../src/POSIX => /usr/local/cm3/pkg/suplib/src/POSIX ProcTitle.m3 FileAttrOS.m3 ../src/libmd => /usr/local/cm3/pkg/suplib/src/libmd md5c.c md5hl.c ../src/libglob => /usr/local/cm3/pkg/suplib/src/libglob fnmatch.c ../src/dev_t_posix => /usr/local/cm3/pkg/suplib/src/dev_t_posix DevT.m3 ../src/text_cm3 => /usr/local/cm3/pkg/suplib/src/text_cm3 CText.m3 SupMiscText.m3 installing package m3-tools/cvsup/client --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/client/LINUXLIBC6 .M3EXPORTS .M3WEB ../LINUXLIBC6 => /usr/local/cm3/pkg/client/LINUXLIBC6 Version.m3 SupGUIBundle.i3 SupGUIBundle.m3 FixupSeq.i3 FixupSeq.m3 FixupSeqRep.i3 SyncFixupQueue.i3 SyncFixupQueue.m3 SupFileRecSeq.m3 SupFileRecSeq.i3 SupFileRecSeqRep.i3 FileAttrSeq.i3 FileAttrSeq.m3 FileAttrSeqRep.i3 ../src => /usr/local/cm3/pkg/client/src Version.i3 SyncQueue.mg SyncQueue.ig syncqueue.tmpl Fixup.i3 Auth.m3 Auth.i3 SupFile.i3 SupFile.m3 Receive.i3 Receive.m3 FileUpdater.i3 FileUpdater.m3 CheckoutCreator.i3 CheckoutCreator.m3 CheckoutUpdater.i3 CheckoutUpdater.m3 RCSUpdater.m3 RCSUpdater.i3 RegularCreator.i3 RegularCreator.m3 RegularUpdater.i3 RegularUpdater.m3 RsyncUpdater.i3 RsyncUpdater.m3 TreeList.i3 TreeList.m3 Detailer.i3 Detailer.m3 Updater.i3 Updater.m3 FSClient.m3 FSClient.i3 SupGUI.i3 SupGUI.m3 EventSync.i3 EventSync.m3 TextPortLogger.m3 TextPortLogger.i3 TextVBTLogger.i3 TextVBTLogger.m3 BackoffTimer.i3 BackoffTimer.m3 Main.m3 . => /usr/local/cm3/bin cvsup . => /usr/local/cm3/man/man1 cvsup.1 installing package m3-tools/cvsup/server --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/server/LINUXLIBC6 .M3EXPORTS .M3WEB ../LINUXLIBC6 => /usr/local/cm3/pkg/server/LINUXLIBC6 Version.m3 FileInfoMerger.i3 FileInfoMerger.m3 LinkTbl.m3 LinkTbl.i3 RCSDeltaMerger.m3 RCSDeltaMerger.i3 RCSTagMerger.i3 RCSTagMerger.m3 SupFileRecSeq.m3 SupFileRecSeq.i3 SupFileRecSeqRep.i3 FileAttrSeq.i3 FileAttrSeq.m3 FileAttrSeqRep.i3 ParsedDeltaList.i3 ParsedDeltaList.m3 ../src => /usr/local/cm3/pkg/server/src Version.i3 FileInfo.m3 FileInfo.i3 ParsedDelta.m3 ParsedDelta.i3 AccessRules.i3 AccessRules.m3 Passwd.i3 Passwd.m3 ClientClass.i3 ClientClass.m3 ClassDB.m3 ClassDB.i3 RCSComp.i3 RCSComp.m3 TreeComp.i3 TreeComp.m3 FSServer.m3 FSServer.i3 FSServerRep.i3 FSServerU.m3 Main.m3 . => /usr/local/cm3/bin cvsupd . => /usr/local/cm3/man/man8 cvsupd.8 . => /usr/local/cm3/man/man5 cvsupd.class.5 installing package m3-tools/cvsup/cvpasswd --- shipping from LINUXLIBC6 --- package was built with overrides, not shipping. hendrik at lovesong:~/cm3/ia32/RC3/cvsup$ ls -- hendrik From jay.krell at cornell.edu Mon Aug 24 03:05:17 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 24 Aug 2009 01:05:17 +0000 Subject: [M3devel] more web site problems In-Reply-To: <20090823125249.cc7q0zjwxwcoo84g@mail.elegosoft.com> References: <20090823125249.cc7q0zjwxwcoo84g@mail.elegosoft.com> Message-ID: > That's the result of your putting overrides into the CVSup I don't think it was me though I should have noticed it in the initial version. - Jay ---------------------------------------- > Date: Sun, 23 Aug 2009 12:52:49 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: more web site problems > > Quoting Jay K : > >> http://www.opencm3.net/releng/collection-core.html >> >> has various README links. >> I'm certain many are not useful (like under gcc) and I'm not certain if >> any would be, but asis they all give access denied. > > All README links should now be fixed. I had renamed the workspace > and forgot to adapt the link. > >> "platform-specific library imports for Windows systems" >> is bogus. They are called "import libraries", not >> "library imports". > > All package descriptions are in the DESC files. I've fixed this one > now. Feel free to improve further. > > HTML needs to be regenerated now. I'll do that soon. > >> The Description is obviously wrong. >> Maybe that is a placeholder? >> Or not expanded? > > >> The Dependencies look funny but maybe as intended? >> Or maybe this is a unique output of having no dependencies? >> Actually they look quite good for other package collections, >> to provide all that data. I can't tell if only >> immediately dependent package collections are listed >> or transitive. > > It's just the output of my scripts that compute the dependencies. > I haven't had put any efforts into making it beautiful. I thought > it would be easily understandable, but that's probably wrong ;-) > >> The access denied on README isn't unique to core. >> http://www.opencm3.net/releng/collection-database.html >> >> http://www.opencm3.net/releng/collection-cvsup.html >> contains broken link to "manual page cvpasswd". > > That's the result of your putting overrides into the CVSup > m3makefiles. Now nothing gets shipped. Probably all the CVSup > packages are broken in this respect. Overrides should only be > in m3override files and be activated with the -override option. > >> http://www.opencm3.net/releng/collection-devlib.html >> README access denied > > Thanks for the comments, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Mon Aug 24 03:07:25 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 24 Aug 2009 01:07:25 +0000 Subject: [M3devel] trying RC3 In-Reply-To: <20090824005658.GA11486@topoi.pooq.com> References: <20090824005658.GA11486@topoi.pooq.com> Message-ID: This is understood and fixed, specific to cvsup. Thanks, - Jay ---------------------------------------- > Date: Sun, 23 Aug 2009 20:56:58 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: [M3devel] trying RC3 > > Well, core and gui installed flaelessly on a Debian lenny system. > > But cvsup ended with the message: > > package was built with overrides, not shipping. > > Now maybe that's correct behaviour, but It doesn't look like it. > > Here are the details: > > hendrik at lovesong:~/cm3/ia32/RC3$ mkdir cvsup > hendrik at lovesong:~/cm3/ia32/RC3$ cd cvsup > hendrik at lovesong:~/cm3/ia32/RC3/cvsup$ tar -zxf > ../../../dn/cm3-bin-ws-cvsup-LINUXLIBC6-5.8.3-RC3.tgz > hendrik at lovesong:~/cm3/ia32/RC3/cvsup$ ls > collection-cvsup.html install.sh m3-tools setup.cmd > hendrik at lovesong:~/cm3/ia32/RC3/cvsup$ ./install.sh > installing package m3-tools/cvsup/suplib > --- shipping from LINUXLIBC6 --- > > . => /usr/local/cm3/pkg/suplib/LINUXLIBC6 > .M3EXPORTS > . => /usr/local/cm3/lib > libsuplib.so.5 > . => /usr/local/cm3/pkg/suplib/LINUXLIBC6 > libsuplib.a libsuplib.m3x .M3WEB > ../LINUXLIBC6 => /usr/local/cm3/pkg/suplib/LINUXLIBC6 > ExecRecSeq.i3 ExecRecSeq.m3 DirEntryList.i3 DirEntryList.m3 > DirEntryListSort.i3 DirEntryListSort.m3 TextGlobTreeTbl.i3 > TextGlobTreeTbl.m3 ExecRecSeqRep.i3 RCSAccessList.i3 > RCSAccessList.m3 > RCSTagList.i3 RCSTagList.m3 RCSTagListSort.i3 > RCSTagListSort.m3 > RCSEditTbl.i3 RCSEditTbl.m3 SortedRCSEditTbl.i3 > SortedRCSEditTbl.m3 RCSDeltaList.i3 RCSDeltaList.m3 > RCSDeltaListSort.i3 RCSDeltaListSort.m3 RCSDeltaTbl.i3 > RCSDeltaTbl.m3 SortedRCSDeltaTbl.i3 SortedRCSDeltaTbl.m3 > RsyncBlockArraySort.i3 RsyncBlockArraySort.m3 > ../src => /usr/local/cm3/pkg/suplib/src > RegEx.i3 RegEx.m3 Merger.ig Merger.mg > merger.tmpl CText.i3 Uglob.i3 PathComp.i3 > PathComp.m3 ChannelMux.m3 ChannelMux.i3 Logger.i3 > Logger.m3 LoggerClass.i3 SplitLogger.i3 SplitLogger.m3 > SysLogger.i3 SysLogger.m3 TimeStampLogger.i3 > TimeStampLogger.m3 WrLogger.i3 WrLogger.m3 ProcTitle.i3 > Ugzip.i3 Ugzip.m3 UgzipP.i3 Umd5.i3 > MySyslog.i3 WatchDog.i3 WatchDog.m3 IOWatchDog.i3 > IOWatchDog.m3 MD5Digest.i3 MD5Digest.m3 MD5.m3 > MD5.i3 AuthMD5.m3 AuthMD5.i3 TokScan.m3 > TokScan.i3 DevT.i3 FileAttr.i3 FileAttr.m3 > FileAttrRep.i3 FileID.m3 FileID.i3 CVProto.m3 > CVProto.i3 EscapedRd.i3 EscapedRd.m3 EscapedWr.i3 > EscapedWr.m3 MD5Wr.i3 MD5Wr.m3 ErrMsg.i3 > ErrMsg.m3 DirEntry.i3 DirEntry.m3 Glob.m3 > Glob.i3 GlobTree.i3 GlobTree.m3 LockFile.m3 > LockFile.i3 ExecRec.i3 RCSError.i3 RCSString.m3 > RCSString.i3 RCSPhrase.i3 RCSPhrase.m3 RCSPhrases.i3 > RCSPhrases.m3 RCSDate.m3 RCSDate.i3 RCSRevNum.i3 > RCSRevNum.m3 RCSAccess.m3 RCSAccess.i3 RCSTag.i3 > RCSTag.m3 RCSEdit.i3 RCSDelta.m3 RCSDelta.i3 > RCSDeltaClass.i3 RCSKeyword.m3 RCSKeyword.i3 RCSFile.i3 > RCSFile.m3 SupFileRec.i3 SupFileRec.m3 SupMisc.i3 > SupMisc.m3 FileStatus.m3 FileStatus.i3 FileStatusRaw.i3 > StatusFile.i3 StatusFile.m3 CVTree.m3 CVTree.i3 > GzipError.m3 GzipError.i3 GzipRd.i3 GzipRd.m3 > GzipWr.i3 GzipWr.m3 RsyncBlock.m3 RsyncBlock.i3 > RsyncFile.m3 RsyncFile.i3 Reaper.i3 Reaper.m3 > SigHandler.m3 SigHandler.i3 UnixMisc.m3 UnixMisc.i3 > UnixMiscC.c Attic.i3 Attic.m3 > ../src/POSIX => /usr/local/cm3/pkg/suplib/src/POSIX > ProcTitle.m3 FileAttrOS.m3 > ../src/libmd => /usr/local/cm3/pkg/suplib/src/libmd > md5c.c md5hl.c > ../src/libglob => /usr/local/cm3/pkg/suplib/src/libglob > fnmatch.c > ../src/dev_t_posix => /usr/local/cm3/pkg/suplib/src/dev_t_posix > DevT.m3 > ../src/text_cm3 => /usr/local/cm3/pkg/suplib/src/text_cm3 > CText.m3 SupMiscText.m3 > installing package m3-tools/cvsup/client > --- shipping from LINUXLIBC6 --- > > . => /usr/local/cm3/pkg/client/LINUXLIBC6 > .M3EXPORTS .M3WEB > ../LINUXLIBC6 => /usr/local/cm3/pkg/client/LINUXLIBC6 > Version.m3 SupGUIBundle.i3 SupGUIBundle.m3 FixupSeq.i3 > FixupSeq.m3 FixupSeqRep.i3 SyncFixupQueue.i3 SyncFixupQueue.m3 > SupFileRecSeq.m3 SupFileRecSeq.i3 SupFileRecSeqRep.i3 FileAttrSeq.i3 > FileAttrSeq.m3 FileAttrSeqRep.i3 > ../src => /usr/local/cm3/pkg/client/src > Version.i3 SyncQueue.mg SyncQueue.ig syncqueue.tmpl > Fixup.i3 Auth.m3 Auth.i3 SupFile.i3 > SupFile.m3 Receive.i3 Receive.m3 FileUpdater.i3 > FileUpdater.m3 CheckoutCreator.i3 CheckoutCreator.m3 > CheckoutUpdater.i3 CheckoutUpdater.m3 RCSUpdater.m3 > RCSUpdater.i3 RegularCreator.i3 RegularCreator.m3 RegularUpdater.i3 > RegularUpdater.m3 RsyncUpdater.i3 RsyncUpdater.m3 TreeList.i3 > TreeList.m3 Detailer.i3 Detailer.m3 Updater.i3 > Updater.m3 FSClient.m3 FSClient.i3 SupGUI.i3 > SupGUI.m3 EventSync.i3 EventSync.m3 TextPortLogger.m3 > TextPortLogger.i3 TextVBTLogger.i3 TextVBTLogger.m3 BackoffTimer.i3 > BackoffTimer.m3 Main.m3 > . => /usr/local/cm3/bin > cvsup > . => /usr/local/cm3/man/man1 > cvsup.1 > installing package m3-tools/cvsup/server > --- shipping from LINUXLIBC6 --- > > . => /usr/local/cm3/pkg/server/LINUXLIBC6 > .M3EXPORTS .M3WEB > ../LINUXLIBC6 => /usr/local/cm3/pkg/server/LINUXLIBC6 > Version.m3 FileInfoMerger.i3 FileInfoMerger.m3 LinkTbl.m3 > LinkTbl.i3 RCSDeltaMerger.m3 RCSDeltaMerger.i3 RCSTagMerger.i3 > RCSTagMerger.m3 SupFileRecSeq.m3 SupFileRecSeq.i3 SupFileRecSeqRep.i3 > FileAttrSeq.i3 FileAttrSeq.m3 FileAttrSeqRep.i3 ParsedDeltaList.i3 > ParsedDeltaList.m3 > ../src => /usr/local/cm3/pkg/server/src > Version.i3 FileInfo.m3 FileInfo.i3 ParsedDelta.m3 > ParsedDelta.i3 AccessRules.i3 AccessRules.m3 Passwd.i3 > Passwd.m3 ClientClass.i3 ClientClass.m3 ClassDB.m3 > ClassDB.i3 RCSComp.i3 RCSComp.m3 TreeComp.i3 > TreeComp.m3 FSServer.m3 FSServer.i3 FSServerRep.i3 > FSServerU.m3 Main.m3 > . => /usr/local/cm3/bin > cvsupd > . => /usr/local/cm3/man/man8 > cvsupd.8 > . => /usr/local/cm3/man/man5 > cvsupd.class.5 > installing package m3-tools/cvsup/cvpasswd > --- shipping from LINUXLIBC6 --- > > package was built with overrides, not shipping. > hendrik at lovesong:~/cm3/ia32/RC3/cvsup$ ls > > > -- hendrik > From hendrik at topoi.pooq.com Mon Aug 24 03:32:45 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 23 Aug 2009 21:32:45 -0400 Subject: [M3devel] trying RC3 In-Reply-To: References: <20090824005658.GA11486@topoi.pooq.com> Message-ID: <20090824013245.GA11619@topoi.pooq.com> On Mon, Aug 24, 2009 at 01:07:25AM +0000, Jay K wrote: > > This is understood and fixed, specific to cvsup. Does 'fixed' mean you've replaced the RC3 archive, in which case I'll try it again soon, or that it'll be OK in RC4? Or just fixed in CVS? > > Thanks, > - Jay You're welcome. Each time a new RC comes out, I shunt aside my existing cm3, and try an install. Then I report on the problems, and move the working cm3 back. I'll spend some time this week testing the other ws-packages. Thanks. -- hendrik From jay.krell at cornell.edu Mon Aug 24 04:43:52 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 24 Aug 2009 02:43:52 +0000 Subject: [M3devel] trying RC3 In-Reply-To: <20090824013245.GA11619@topoi.pooq.com> References: <20090824005658.GA11486@topoi.pooq.com> <20090824013245.GA11619@topoi.pooq.com> Message-ID: In CVS. - Jay ---------------------------------------- > Date: Sun, 23 Aug 2009 21:32:45 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] trying RC3 > > On Mon, Aug 24, 2009 at 01:07:25AM +0000, Jay K wrote: >> >> This is understood and fixed, specific to cvsup. > > Does 'fixed' mean you've replaced the RC3 archive, in which case I'll > try it again soon, or that it'll be OK in RC4? > > Or just fixed in CVS? > >> >> Thanks, >> - Jay > > You're welcome. Each time a new RC comes out, I shunt aside my existing > cm3, and try an install. Then I report on the problems, and move the > working cm3 back. > > I'll spend some time this week testing the other ws-packages. > > Thanks. > > -- hendrik > From wagner at elegosoft.com Mon Aug 24 09:56:39 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 24 Aug 2009 09:56:39 +0200 Subject: [M3devel] more web site problems Message-ID: <20090824095639.smnfmx03w0og8sc8@mail.elegosoft.com> Quoting Jay K : >> That's the result of your putting overrides into the CVSup > > I don't think it was me though I should have noticed it in the > initial version. Sorry, I didn't want to sound accusatory; I just remembered that you imported CVSup into the tree and later changed all the overrides, too. But these oversights happen all the time; you cannot avoid them. So never mind, Olaf > - Jay > > > > ---------------------------------------- >> Date: Sun, 23 Aug 2009 12:52:49 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: more web site problems >> >> Quoting Jay K : >> >>> http://www.opencm3.net/releng/collection-core.html >>> >>> has various README links. >>> I'm certain many are not useful (like under gcc) and I'm not certain if >>> any would be, but asis they all give access denied. >> >> All README links should now be fixed. I had renamed the workspace >> and forgot to adapt the link. >> >>> "platform-specific library imports for Windows systems" >>> is bogus. They are called "import libraries", not >>> "library imports". >> >> All package descriptions are in the DESC files. I've fixed this one >> now. Feel free to improve further. >> >> HTML needs to be regenerated now. I'll do that soon. >> >>> The Description is obviously wrong. >>> Maybe that is a placeholder? >>> Or not expanded? >> >> >>> The Dependencies look funny but maybe as intended? >>> Or maybe this is a unique output of having no dependencies? >>> Actually they look quite good for other package collections, >>> to provide all that data. I can't tell if only >>> immediately dependent package collections are listed >>> or transitive. >> >> It's just the output of my scripts that compute the dependencies. >> I haven't had put any efforts into making it beautiful. I thought >> it would be easily understandable, but that's probably wrong ;-) >> >>> The access denied on README isn't unique to core. >>> http://www.opencm3.net/releng/collection-database.html >>> >>> http://www.opencm3.net/releng/collection-cvsup.html >>> contains broken link to "manual page cvpasswd". >> >> That's the result of your putting overrides into the CVSup >> m3makefiles. Now nothing gets shipped. Probably all the CVSup >> packages are broken in this respect. Overrides should only be >> in m3override files and be activated with the -override option. >> >>> http://www.opencm3.net/releng/collection-devlib.html >>> README access denied >> >> Thanks for the comments, >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From lchretien at mac.com Mon Aug 24 16:08:45 2009 From: lchretien at mac.com (Louis =?ISO-8859-1?B?Q2hy6XRpZW4=?=) Date: Mon, 24 Aug 2009 10:08:45 -0400 Subject: [M3devel] Could you post this for me on m3devel In-Reply-To: <20090822003244.xwf5l3f5icswcgks@mail.elegosoft.com> Message-ID: Hi Olaf, try as I can, i cannot post the message on the list completely. Could you do that for me please? Thanks, ******************* Object: A more precise question about M3 licensing... (Real sorry about this, I don't know why it keeps being truncated...) >From what I gathered so far on this thread, the SRC licence was quite a bit more liberal than the FSF license, which led to this "separate process" business for the code generation phase, which displeased the FSF somewhat. ;-) After having read the licence for the LLVM project (a one pager on their website), i find it quite liberal and you can basically do anything with the code, as long as you give proper credit and keep the license with the files. I'm no lawyer, but it seems that the SRC and LLVM licenses could play along fine, as opposed to the FSF trying to "infect" everything it touches... So, here's the idea I had: Combine the existing CM3 (and/or PM3) front-end, and modify it to emit LLVM bytecodes, so that we could use the LLVM back-end and infrastructure to create a complete compiler/linker. Would such a beast, by combining code from both licenses, be viable? I would like to keep the licensing as liberal as possible. I sure would like your ideas on this subject, P.S.: Olaf, I think your suggestion of documenting the existing intermidiate representation of the CM3 compiler would be an absolute first step... -- Louis Chr?tien lchretien at mac.com From wagner at elegosoft.com Mon Aug 24 17:36:46 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 24 Aug 2009 17:36:46 +0200 Subject: [M3devel] Fwd: Could you post this for me on m3devel Message-ID: <20090824173646.l0yae49dgkwoks8o@mail.elegosoft.com> Trying once again with some periods removed ----- Forwarded message from lchretien at mac.com ----- Date: Mon, 24 Aug 2009 10:08:45 -0400 From: Louis Chr?tien Reply-To: Louis Chr?tien Subject: Could you post this for me on m3devel To: Olaf Wagner Hi Olaf, try as I can, i cannot post the message on the list completely. Could you do that for me please? Thanks, ******************* Object: A more precise question about M3 licensing (Real sorry about this, I don't know why it keeps being truncated) From what I gathered so far on this thread, the SRC licence was quite a bit more liberal than the FSF license, which led to this "separate process" business for the code generation phase, which displeased the FSF somewhat. ;-) After having read the licence for the LLVM project (a one pager on their website), i find it quite liberal and you can basically do anything with the code, as long as you give proper credit and keep the license with the files. I'm no lawyer, but it seems that the SRC and LLVM licenses could play along fine, as opposed to the FSF trying to "infect" everything it touches So, here's the idea I had: Combine the existing CM3 (and/or PM3) front-end, and modify it to emit LLVM bytecodes, so that we could use the LLVM back-end and infrastructure to create a complete compiler/linker. Would such a beast, by combining code from both licenses, be viable? I would like to keep the licensing as liberal as possible. I sure would like your ideas on this subject, P.S.: Olaf, I think your suggestion of documenting the existing intermidiate representation of the CM3 compiler would be an absolute first step -- Louis Chr?tien lchretien at mac.com ----- End forwarded message ----- -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Mon Aug 24 18:47:42 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 24 Aug 2009 12:47:42 -0400 Subject: [M3devel] Fwd: Could you post this for me on m3devel In-Reply-To: <20090824173646.l0yae49dgkwoks8o@mail.elegosoft.com> References: <20090824173646.l0yae49dgkwoks8o@mail.elegosoft.com> Message-ID: <20090824164741.GB13116@topoi.pooq.com> On Mon, Aug 24, 2009 at 05:36:46PM +0200, Olaf Wagner wrote: > > Object: A more precise question about M3 licensing > > From what I gathered so far on this thread, the SRC licence was quite a bit > more liberal than the FSF license, which led to this "separate process" > business for the code generation phase, which displeased the FSF somewhat. > ;-) As far as I know, the problem is that the SRC licence was restrictive at one point that conflicted with the FSF licence. In particular, you had to grant SRC the ability to do anything whatsoever with anything you added or modified in the system. That is a restriction on how you can redistribute -- a restriction more severe than the FSF licence allows.. But there's nothing preventing any of us from releasing your own code under multiple licences, including the FSF one. Even if you link directly to FSF code and distribute binaries, and aggregate your source with FSF code more intimately than "mere aggregation", nothing prevents you from licencing your code under as many different licences as you want in addition to the FSF one. But without SRS's say-so, we can't do it to their code. -- hendrik From hendrik at topoi.pooq.com Mon Aug 24 19:06:24 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 24 Aug 2009 13:06:24 -0400 Subject: [M3devel] platform names again. Message-ID: <20090824170624.GA13190@topoi.pooq.com> I have one home directory, shared via NFS among several machines. Some run Debian lenny, some run Debian squeeze, one is and AMD64. Now I really appreciate the fact that when I run cm3 I get my executables in a system-dependent diractory. But it occurs to me that both Debian lenny and Debian squeeze end you using the directory LINUXLIBC6. Are the files generated there truly Debian-release-independent? Might they depend in some way on the contents of Debian's shared C libraries, for example? And if so, is there a way of overriding the word "LINUXLIBC6" with some other word so that I can distinguish them? By the time I ship them to /usr/local/cm3, the problem is over, of course, since eash system has its own /usr/local. But on the way to there, there could be mishaps in LinuxLIBC6. -- hendrik From jay.krell at cornell.edu Mon Aug 24 20:12:37 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Mon, 24 Aug 2009 14:12:37 -0400 Subject: [M3devel] platform names again. In-Reply-To: <20090824170624.GA13190@topoi.pooq.com> References: <20090824170624.GA13190@topoi.pooq.com> Message-ID: <5E5E68F4-45DF-47A7-A97D-483398DFF529@hotmail.com> We have the same compatibility of any uninteresting multithreaded C code, whatever that is. On reasonable systems that is full compatibility. I don't know if Linux is reasonable. For example 64 bit FreeBSD is not reasonable, struct sockaddr changed from 6.4 to 7.0. - Jay (phone) On Aug 24, 2009, at 1:06 PM, hendrik at topoi.pooq.com wrote: > I have one home directory, shared via NFS among several machines. > Some > run Debian lenny, some run Debian squeeze, one is and AMD64. > > Now I really appreciate the fact that when I run cm3 I get my > executables in a system-dependent diractory. > > But it occurs to me that both Debian lenny and Debian squeeze end you > using the directory LINUXLIBC6. > > Are the files generated there truly Debian-release-independent? Might > they depend in some way on the contents of Debian's shared C > libraries, > for example? And if so, is there a way of overriding the word > "LINUXLIBC6" with some other word so that I can distinguish > them? > > By the time I ship them to /usr/local/cm3, the problem is over, of > course, since eash system has its own /usr/local. But on the way to > there, there could be mishaps in LinuxLIBC6. > > -- hendrik > > From jay.krell at cornell.edu Mon Aug 24 22:58:56 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 24 Aug 2009 20:58:56 +0000 Subject: [M3devel] platform names again. In-Reply-To: <20090824182526.6A6871A209F@newasync.async.caltech.edu> References: <20090824170624.GA13190@topoi.pooq.com> <5E5E68F4-45DF-47A7-A97D-483398DFF529@hotmail.com> <20090824182526.6A6871A209F@newasync.async.caltech.edu> Message-ID: I'm not sure that is true. I know some of the BSDs sometimes carry compatibility libraries -- old versions of libc. I'm not sure the struct sockaddr is a libc change or a kernel change. The mention in the release notes sounds like possibly a kernel change. I find the level of incompatibility knowingly introduced surprising in some of these systems. The commercial systems all seem to try and do achieve much better. As to more of the original questions, no, I don't think there is much you can do about the "LINUXLIBC6" directory name, in the distributed packages. For when you build from source, BUILD_DIR and TARGET are strictly speaking separate values. BUILD_DIR perhaps should be more fine grained and include more of uname. Ultimately we may very well go back to a release form of: assembly code for all the Modula-3 code, that goes into just cm3 uncompiled C code, again just what cm3 uses a makefile source to everything else That will address this issue. And then specific builds for specific systems, like Debian 4.0, Debian 5.0, OpenSUSE 11.0, Fedora 10, etc., the small number we can afford to provide -- possibly in the generic form, possibly in rpm/deb format as the systems "prefer" -- note that this is two separate variables -- the packaging format and the actual ABI. It would be good to nail this all down with more certainty -- what actually has changed in the past and/or is likely to change in the future. I wish the set was empty, but 64bit FreeBSD provides enough of an example to prove it is not. But, I have to ask, how the check do things like Adobe Flash, Acrobat Reader, etc. work? - Jay ---------------------------------------- > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] platform names again. > Date: Mon, 24 Aug 2009 11:25:26 -0700 > From: mika at newasync.async.caltech.edu > > > On FreeBSD, I find that generally you can install the compiler and > libraries and headers from the older version and always have that work. > > You cannot, however, expect to use a compiler, or an object, from a > newer version of the system on an older version and have it work. > > Mika > > jay.krell at cornell.edu writes: >>We have the same compatibility of any uninteresting multithreaded C >>code, whatever that is. >>On reasonable systems that is full compatibility. I don't know if >>Linux is reasonable. For example 64 bit FreeBSD is not reasonable, >>struct sockaddr changed from 6.4 to 7.0. >> >> - Jay (phone) >> >>On Aug 24, 2009, at 1:06 PM, hendrik at topoi.pooq.com wrote: >> >>> I have one home directory, shared via NFS among several machines. >>> Some >>> run Debian lenny, some run Debian squeeze, one is and AMD64. >>> >>> Now I really appreciate the fact that when I run cm3 I get my >>> executables in a system-dependent diractory. >>> >>> But it occurs to me that both Debian lenny and Debian squeeze end you >>> using the directory LINUXLIBC6. >>> >>> Are the files generated there truly Debian-release-independent? Might >>> they depend in some way on the contents of Debian's shared C >>> libraries, >>> for example? And if so, is there a way of overriding the word >>> "LINUXLIBC6" with some other word so that I can distinguish >>> them? >>> >>> By the time I ship them to /usr/local/cm3, the problem is over, of >>> course, since eash system has its own /usr/local. But on the way to >>> there, there could be mishaps in LinuxLIBC6. >>> >>> -- hendrik >>> >>> From jay.krell at cornell.edu Mon Aug 24 23:19:17 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 24 Aug 2009 21:19:17 +0000 Subject: [M3devel] ignored errors Message-ID: http://www.modula3.com:8080/view/SOLgnu/job/cm3-makedist-SOLgnu/11/console === package m3-sys/cminstall === +++ cm3 -build -override $RARGS -DROOT='/home/hudson/workspace/cm3-makedist-SOLgnu/cm3' -DCM3_VERSION_TEXT='5.8.3' -DCM3_VERSION_NUMBER='050803' -DCM3_LAST_CHANGED='2009-08-22' +++ /bin/sh: /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/m3-tools/m3bundle/SOLsun/m3bundle: not found "/home/hudson/workspace/cm3-makedist-SOLgnu/cm3/m3-libs/libm3/src/bundleintf/bundle.tmpl", line 53: quake runtime error: exit 1: /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/m3-tools/m3bundle/SOLsun/m3bundle -name Setup -element config ../src/config/SOLgnu --procedure-- -line- -file--- exec -- bundle 53 /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/m3-libs/libm3/src/bundleintf/bundle.tmpl include_dir 17 /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/m3-sys/cminstall/src/m3makefile 9 /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/m3-sys/cminstall/SOLgnu/m3make.args --- building in SOLgnu --- /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/m3-tools/m3bundle/SOLsun/m3bundle -name Setup -element config ../src/config/SOLgnu Fatal Error: package build failed ==> m3-sys/cminstall done Seems like that should not be ignored. I'll try to fix the actual error -- host vs. target -- SOLsun vs. SOLgnu. stage 2: installing cm3 compiler ---------------------------------------------------------------------------- installing /home/hudson/tmp/cm3/bin/cm3 /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/scripts/make-bin-dist-min.sh: strip: not found installing /home/hudson/tmp/cm3/bin/cm3cg /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/scripts/make-bin-dist-min.sh: strip: not found configuring temporary config file /home/hudson/tmp/cm3/bin/cm3.cfg cp: /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/m3-sys/cminstall/src/config-no-install/CVS: is a directory not sure if that should be ignored. I can fix it too, like: for a in [ /usr/ccs/bin/strip strip ]; then if [ type $a ]; then STRIP=$a fi fi Preferably put the options in the other order, if there is a "break" command in sh for for loops. - Jay From jay.krell at cornell.edu Mon Aug 24 23:22:01 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 24 Aug 2009 21:22:01 +0000 Subject: [M3devel] RC3 tag Message-ID: I don't see commit mails about this, so, fyi: I moved the RC3 tag forward: scripts/sysinfo.sh scripts/regression/defs.sh m3-sys/m3cc/src/m3makefile m3-sys/m3cc/src/gnucc.common (rename it gnucc.quake?) m3-sys/m3cc/src/gnumake.common (rename it gnumake.quake?) TAR was unconditionally being set to tar, which is wrong on Solaris without hacks. No attempt to set TAR or PATH in Hudson could fix that, nor do I think that would be the right fix. I might move m3gdb/src/m3makefile forward too, and something regarding bundle, and maybe more scripts for the strip error. - Jay From hendrik at topoi.pooq.com Tue Aug 25 01:31:18 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 24 Aug 2009 19:31:18 -0400 Subject: [M3devel] platform names again. In-Reply-To: References: <20090824170624.GA13190@topoi.pooq.com> <5E5E68F4-45DF-47A7-A97D-483398DFF529@hotmail.com> <20090824182526.6A6871A209F@newasync.async.caltech.edu> Message-ID: <20090824233118.GB13751@topoi.pooq.com> On Mon, Aug 24, 2009 at 08:58:56PM +0000, Jay K wrote: > > I'm not sure that is true. > I know some of the BSDs sometimes carry compatibility libraries -- old versions of libc. > I'm not sure the struct sockaddr is a libc change or a kernel change. > The mention in the release notes sounds like possibly a kernel change. > > > I find the level of incompatibility knowingly introduced surprising in some of these systems. > The commercial systems all seem to try and do achieve much better. > > > As to more of the original questions, no, I don't think there is much > you can do about the "LINUXLIBC6" directory name, in the distributed > packages. For when you build from source, BUILD_DIR and TARGET are > strictly speaking separate values. BUILD_DIR perhaps should be more > fine grained and include more of uname. So does TARGET identify the target platform and does BUILD_DIR identify the name of the directory (in this case .../LINUXLIBC6/ ) into which all the derived files should go? Could BUILD_DIR be overridden? That would suffice. I'd just pick a different BUILD_DIR when I compile on one of y systems. > > > Ultimately we may very well go back to a release form of: > assembly code for all the Modula-3 code, that goes into just cm3 > uncompiled C code, again just what cm3 uses > a makefile > source to everything else > > > That will address this issue. > > > And then specific builds for specific systems, like Debian 4.0, Debian 5.0, OpenSUSE 11.0, Fedora 10, etc., the small number we can afford to provide -- possibly in the generic form, possibly in rpm/deb format as the systems "prefer" -- note that this is two separate variables -- the packaging format and the actual ABI. > > > It would be good to nail this all down with more certainty -- what actually has changed in the past and/or is likely to change in the future. I wish the set was empty, but 64bit FreeBSD provides enough of an example to prove it is not. > > > But, I have to ask, how the check do things like Adobe Flash, Acrobat > Reader, etc. work? Every now and them Adobe Flash just stops working altogether on my system. -- hendrik From jay.krell at cornell.edu Tue Aug 25 03:08:31 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 25 Aug 2009 01:08:31 +0000 Subject: [M3devel] platform names again. In-Reply-To: <20090824233118.GB13751@topoi.pooq.com> References: <20090824170624.GA13190@topoi.pooq.com> <5E5E68F4-45DF-47A7-A97D-483398DFF529@hotmail.com> <20090824182526.6A6871A209F@newasync.async.caltech.edu> <20090824233118.GB13751@topoi.pooq.com> Message-ID: Yes BUILD_DIR apparently is meant to be overridable/changable. I'm not sure if all the various tools that kinda sorta know what is going on will play along. When I pointed out that TARGET does not necessarily equal BUILD_DIR, Randy said that would break cm3ide. Yet it was apparently always theoretically true, for profiled builds. Not that I have done a profiled build. And it is always true in practise. Since I never do a profiled build and probably nobody else does either. But you can try varying it. Try this: in config file, change BUILD_DIR = whatever to if !defined("BUILD_DIR)" around BUILD_DIR = whatever end and then on the cm3 command line, try cm3 -DBUILD_DIR=foo scripts -realclean will tend to not play along here. - Jay ---------------------------------------- > Date: Mon, 24 Aug 2009 19:31:18 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] platform names again. > > On Mon, Aug 24, 2009 at 08:58:56PM +0000, Jay K wrote: >> >> I'm not sure that is true. >> I know some of the BSDs sometimes carry compatibility libraries -- old versions of libc. >> I'm not sure the struct sockaddr is a libc change or a kernel change. >> The mention in the release notes sounds like possibly a kernel change. >> >> >> I find the level of incompatibility knowingly introduced surprising in some of these systems. >> The commercial systems all seem to try and do achieve much better. >> >> >> As to more of the original questions, no, I don't think there is much >> you can do about the "LINUXLIBC6" directory name, in the distributed >> packages. For when you build from source, BUILD_DIR and TARGET are >> strictly speaking separate values. BUILD_DIR perhaps should be more >> fine grained and include more of uname. > > So does TARGET identify the target platform and does BUILD_DIR identify > the name of the directory (in this case .../LINUXLIBC6/ ) into which all > the derived files should go? Could BUILD_DIR be overridden? That would > suffice. I'd just pick a different BUILD_DIR when I compile on one of y > systems. > >> >> >> Ultimately we may very well go back to a release form of: >> assembly code for all the Modula-3 code, that goes into just cm3 >> uncompiled C code, again just what cm3 uses >> a makefile >> source to everything else >> >> >> That will address this issue. >> >> >> And then specific builds for specific systems, like Debian 4.0, Debian 5.0, OpenSUSE 11.0, Fedora 10, etc., the small number we can afford to provide -- possibly in the generic form, possibly in rpm/deb format as the systems "prefer" -- note that this is two separate variables -- the packaging format and the actual ABI. >> >> >> It would be good to nail this all down with more certainty -- what actually has changed in the past and/or is likely to change in the future. I wish the set was empty, but 64bit FreeBSD provides enough of an example to prove it is not. >> >> >> But, I have to ask, how the check do things like Adobe Flash, Acrobat >> Reader, etc. work? > > Every now and them Adobe Flash just stops working altogether on my > system. > > -- hendrik From hendrik at topoi.pooq.com Tue Aug 25 03:36:10 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 24 Aug 2009 21:36:10 -0400 Subject: [M3devel] How to compile system from (modified) source? Message-ID: <20090825013610.GA13985@topoi.pooq.com> I downloaded the complete source tree via cvs. I downloaded some of the RC3 archives. I start with an empty /usr/local/cm3. I install the core and RC3 gui archives. I make a copy of the source tree so as not to mess with the original. I make small changes to ButtonVBT.i3 and ButtonVBT.m3 I run the script do-cm3-std.sh It fails in odbc. I figure maybe I don;t have the right db stuff on my system and modify do-cm3-std.sh by removing all packages having anything to do with db. Hereby I replace toe command P=`lots of stuff` by P="long list of packages" I obtained the long list by sticking an echo $P into the script, copying the result into the script, and removing odbc postgres95 db smalldb stablegen stable Now I rerun the script. The package I modified appears to compile withoug problems. In fact, the script seems to compile everything but doesn't seem to ship anything. Aha! I forgot to say "ship". Now I rerun again, specifying "ship". Almost all package fails to ship with the message: package was built with overrides, not shipping. How am I supposed to do this. -- hendrik From hendrik at topoi.pooq.com Tue Aug 25 03:53:43 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 24 Aug 2009 21:53:43 -0400 Subject: [M3devel] my small changes to ButtonVBT. In-Reply-To: <20090825013610.GA13985@topoi.pooq.com> References: <20090825013610.GA13985@topoi.pooq.com> Message-ID: <20090825015343.GA14032@topoi.pooq.com> On Mon, Aug 24, 2009 at 09:36:10PM -0400, hendrik at topoi.pooq.com wrote: > > I make small changes to ButtonVBT.i3 and ButtonVBT.m3 By the way, here are the small changes: hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ cvs diff cvs diff: Diffing . Index: ButtonVBT.i3 =================================================================== RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.i3,v retrieving revision 1.2 diff -r1.2 ButtonVBT.i3 39a40 > act(READONLY cd: VBT.MouseRec); Index: ButtonVBT.m3 =================================================================== RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.m3,v retrieving revision 1.2 diff -r1.2 ButtonVBT.m3 28c28,29 < init := Be --- > init := Be; > act := act 46a48,52 > PROCEDURE act(v : T; READONLY cd: VBT.MouseRec) = > BEGIN > v.action(v, cd); > END act; > 59c65 < v.action(v, cd); --- > v.act(cd); hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ -- hendrik From jay.krell at cornell.edu Tue Aug 25 03:56:21 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 25 Aug 2009 01:56:21 +0000 Subject: [M3devel] How to compile system from (modified) source? In-Reply-To: <20090825013610.GA13985@topoi.pooq.com> References: <20090825013610.GA13985@topoi.pooq.com> Message-ID: apt-get install unixodbc etc. ? ./do-cm3-std.sh buildship ./do-pkg.sh buildship list of packages The scripts just cd around and run cm3 -build and/or cm3 -ship and/or other commands. Do ./do-cm3-std.sh realclean to remove the "local" build you did. - Jay ---------------------------------------- > Date: Mon, 24 Aug 2009 21:36:10 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: [M3devel] How to compile system from (modified) source? > > I downloaded the complete source tree via cvs. > > I downloaded some of the RC3 archives. > > I start with an empty /usr/local/cm3. > > I install the core and RC3 gui archives. > > I make a copy of the source tree so as not to mess with the original. > > I make small changes to ButtonVBT.i3 and ButtonVBT.m3 > > I run the script do-cm3-std.sh > > It fails in odbc. > > I figure maybe I don;t have the right db stuff on my system and modify > do-cm3-std.sh by removing all packages having anything to do with db. > Hereby I replace toe command P=`lots of stuff` > by P="long list of packages" > > I obtained the long list by sticking an echo $P into the script, copying > the result into the script, and removing odbc postgres95 db smalldb > stablegen stable > > Now I rerun the script. The package I modified appears to compile > withoug problems. In fact, the script seems to compile everything but > doesn't seem to ship anything. Aha! I forgot to say "ship". > > Now I rerun again, specifying "ship". Almost all package fails to ship > with the message: > package was built with overrides, not shipping. > > How am I supposed to do this. > > -- hendrik > From hendrik at topoi.pooq.com Tue Aug 25 04:45:50 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 24 Aug 2009 22:45:50 -0400 Subject: [M3devel] How to compile system from (modified) source? In-Reply-To: References: <20090825013610.GA13985@topoi.pooq.com> Message-ID: <20090825024550.GA14124@topoi.pooq.com> On Tue, Aug 25, 2009 at 01:56:21AM +0000, Jay K wrote: > > apt-get install unixodbc > etc. > ? > > ./do-cm3-std.sh buildship > > ./do-pkg.sh buildship list of packages > > > The scripts just cd around and run cm3 -build and/or cm3 -ship and/or other commands. > > Do ./do-cm3-std.sh realclean to remove the "local" build you did. Yay! It works! -- hendrik > > > - Jay > > > > > > > ---------------------------------------- > > Date: Mon, 24 Aug 2009 21:36:10 -0400 > > From: hendrik at topoi.pooq.com > > To: m3devel at elegosoft.com > > Subject: [M3devel] How to compile system from (modified) source? > > > > I downloaded the complete source tree via cvs. > > > > I downloaded some of the RC3 archives. > > > > I start with an empty /usr/local/cm3. > > > > I install the core and RC3 gui archives. > > > > I make a copy of the source tree so as not to mess with the original. > > > > I make small changes to ButtonVBT.i3 and ButtonVBT.m3 > > > > I run the script do-cm3-std.sh > > > > It fails in odbc. > > > > I figure maybe I don;t have the right db stuff on my system and modify > > do-cm3-std.sh by removing all packages having anything to do with db. > > Hereby I replace toe command P=`lots of stuff` > > by P="long list of packages" > > > > I obtained the long list by sticking an echo $P into the script, copying > > the result into the script, and removing odbc postgres95 db smalldb > > stablegen stable > > > > Now I rerun the script. The package I modified appears to compile > > withoug problems. In fact, the script seems to compile everything but > > doesn't seem to ship anything. Aha! I forgot to say "ship". > > > > Now I rerun again, specifying "ship". Almost all package fails to ship > > with the message: > > package was built with overrides, not shipping. > > > > How am I supposed to do this. > > > > -- hendrik > > From hendrik at topoi.pooq.com Tue Aug 25 05:01:14 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 24 Aug 2009 23:01:14 -0400 Subject: [M3devel] small design problem in ButtonVBT? In-Reply-To: <20090401120347.x8cneize8oscg44o@mail.elegosoft.com> References: <20090331145127.GB9624@topoi.pooq.com> <20090401120347.x8cneize8oscg44o@mail.elegosoft.com> Message-ID: <20090825030114.GA14152@topoi.pooq.com> On Wed, Apr 01, 2009 at 12:03:47PM +0200, Olaf Wagner wrote: > Quoting hendrik at topoi.pooq.com: > > >The BottonVBT contains an action, which is a procedure rather than a > >method. b This makes it awkward to subclass ButtonVBT becaue the action > >will still expect its first parameter to be a ButtonVBT instead of > >belonging to the subclass, and an explicit downcast of some sort will be > >needed to acess the subclass's members. > > > >The Trestle manual says this was a deliberate decision: > > > >: The action procedure is a field rather than a method in order to allow > >: buttons with different action procedures to share their method suites. > > > >I, however, find it massively inconvenient because it mans I have to > >resort to downcasting or the very kludgey VBT.GetProp to access what > >should be just there. I'd rather the action procedure was a method. > > > >But it should be possible to have the best of both worlds. Have an > >action2 (better name wanted here) method that is available for > >overriding, and by default calls the procedure in the existing action. > >field. That action2 method wounl then be called by Trestle wherever > >action is now called. > > > >Does anyone see problems with this? > > Sounds fine to me offhand. You should test your extensions with > some of the existing larger applications, like mentor and Juno-2, > of course. How should I go about testing my extensions with mentor and Juno-2? I don't know what they do. Is there an automated test? By the way, mentor and Juno (downloaded out of current CVS) do seem to compile and link correctly with this change on a 32-bit Debian squeeze system. I decided to call the new mathid 'act' instead of 'action2', by the way. It's a verb. -- hendrik From wagner at elegosoft.com Tue Aug 25 08:00:01 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 25 Aug 2009 08:00:01 +0200 Subject: [M3devel] ignored errors In-Reply-To: References: Message-ID: <20090825080001.4ptdm2ce8ws4oogk@mail.elegosoft.com> Quoting Jay K : > http://www.modula3.com:8080/view/SOLgnu/job/cm3-makedist-SOLgnu/11/console > === package m3-sys/cminstall === > +++ cm3 -build -override $RARGS > -DROOT='/home/hudson/workspace/cm3-makedist-SOLgnu/cm3' > -DCM3_VERSION_TEXT='5.8.3' -DCM3_VERSION_NUMBER='050803' > -DCM3_LAST_CHANGED='2009-08-22' +++ > /bin/sh: > /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/m3-tools/m3bundle/SOLsun/m3bundle: not > found > "/home/hudson/workspace/cm3-makedist-SOLgnu/cm3/m3-libs/libm3/src/bundleintf/bundle.tmpl", line 53: quake runtime error: exit 1: /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/m3-tools/m3bundle/SOLsun/m3bundle -name Setup -element config > ../src/config/SOLgnu > --procedure-- -line- -file--- > exec -- > bundle 53 > /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/m3-libs/libm3/src/bundleintf/bundle.tmpl > include_dir 17 > /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/m3-sys/cminstall/src/m3makefile > 9 > /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/m3-sys/cminstall/SOLgnu/m3make.args > --- building in SOLgnu --- > /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/m3-tools/m3bundle/SOLsun/m3bundle -name Setup -element config > ../src/config/SOLgnu > Fatal Error: package build failed > ==> m3-sys/cminstall done > > Seems like that should not be ignored. > I'll try to fix the actual error -- host vs. target -- SOLsun vs. SOLgnu. Probably the first stage of upgrade? And calling make-dist without a already-compiled cm3 installation? > stage 2: installing cm3 compiler > ---------------------------------------------------------------------------- > installing /home/hudson/tmp/cm3/bin/cm3 > /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/scripts/make-bin-dist-min.sh: > strip: not found > installing /home/hudson/tmp/cm3/bin/cm3cg > /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/scripts/make-bin-dist-min.sh: > strip: not found > configuring temporary config file /home/hudson/tmp/cm3/bin/cm3.cfg > cp: > /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/m3-sys/cminstall/src/config-no-install/CVS: is a > directory > > not sure if that should be ignored. > I can fix it too, like: > > for a in [ /usr/ccs/bin/strip strip ]; then > if [ type $a ]; then > STRIP=$a > fi > fi We need /usr/ccs/bin in the PATH on Solaris. I just noticed that the PATH was reset to /usr/bin after the latest installation, but forgot about /usr/ccs/bin. > Preferably put the options in the other order, if there is a "break" > command in sh for for loops. We didn't need special handling for strip before AFAIK. It should be there on all POSIX systems. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Aug 25 08:07:01 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 25 Aug 2009 08:07:01 +0200 Subject: [M3devel] RC3 tag In-Reply-To: References: Message-ID: <20090825080701.cfz0fs2wao0880gc@mail.elegosoft.com> Quoting Jay K : > I don't see commit mails about this, so, fyi: > > I moved the RC3 tag forward: > scripts/sysinfo.sh > scripts/regression/defs.sh > m3-sys/m3cc/src/m3makefile > m3-sys/m3cc/src/gnucc.common (rename it gnucc.quake?) > m3-sys/m3cc/src/gnumake.common (rename it gnumake.quake?) > > TAR was unconditionally being set to tar, which is wrong on Solaris > without hacks. > No attempt to set TAR or PATH in Hudson could fix that, nor do I > think that would be the right fix. > > I might move m3gdb/src/m3makefile forward too, and something > regarding bundle, and maybe more scripts for the strip error. Let me know when that's done. I assume you've fixed the build error on Solaris. We should then rebuild all packages. Olaf PS: So far for just pressing a button to build the release packages... :-/ -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Aug 25 09:21:48 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 25 Aug 2009 07:21:48 +0000 Subject: [M3devel] ignored errors In-Reply-To: <20090825080001.4ptdm2ce8ws4oogk@mail.elegosoft.com> References: <20090825080001.4ptdm2ce8ws4oogk@mail.elegosoft.com> Message-ID: > Probably the first stage of upgrade? > And calling make-dist without a already-compiled cm3 installation? Yes, granted, probably unconvential that way. > We need /usr/ccs/bin in the PATH on Solaris. I just noticed that the > PATH was reset to /usr/bin after the latest installation, but forgot > about /usr/ccs/bin. I go back and forth here. I tried out emptying my Solaris .profile file etc. The default path is just /usr/bin. I have made things work with that. gcc, strip, ar, gtar, gmake are not in $PATH but they are present (in a "full" install of what Sun provides0. Usually I check $PATH first, let user override that way, though granted, for strip I was not consistent. - Jay From hendrik at topoi.pooq.com Tue Aug 25 13:29:47 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 25 Aug 2009 07:29:47 -0400 Subject: [M3devel] RC3 tag In-Reply-To: <20090825080701.cfz0fs2wao0880gc@mail.elegosoft.com> References: <20090825080701.cfz0fs2wao0880gc@mail.elegosoft.com> Message-ID: <20090825112947.GB14914@topoi.pooq.com> On Tue, Aug 25, 2009 at 08:07:01AM +0200, Olaf Wagner wrote: > > We should then rebuild all packages. With some distinction in the version numbers so people know which is which. RC3.1? RC4? -- hendrik > > Olaf > > PS: So far for just pressing a button to build the release packages... :-/ That's what's being debugged now. How long has it been since a release? -- hendrik From wagner at elegosoft.com Tue Aug 25 13:45:28 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 25 Aug 2009 13:45:28 +0200 Subject: [M3devel] HEADS UP: Rebuild RC3 or wait for RC4 next week? was Re: RC3 tag In-Reply-To: <20090825112947.GB14914@topoi.pooq.com> References: <20090825080701.cfz0fs2wao0880gc@mail.elegosoft.com> <20090825112947.GB14914@topoi.pooq.com> Message-ID: <20090825134528.ah9lydnwgwgs0skg@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > On Tue, Aug 25, 2009 at 08:07:01AM +0200, Olaf Wagner wrote: >> >> We should then rebuild all packages. > > With some distinction in the version numbers so people know which is > which. RC3.1? RC4? RC3.1 does not make sense. Doing everthing according to plan, we had to abandon RC3 and build RC4 now. The RC3 tag has been moved which shouldn't happen strictly speaking. There's no mechanism in CVS to lock a tag though. There have been only minor corrections, mostly in the build tooling and system dependencies AFAIK. So we could make a concession and rebuild the RC3 packages as they only have been announced on the m3 mailing lists so far. I'd vote for that in this case. Switching to RC4 requires changing several scripts and docs again and applying a new tag. I cannot do that from here, nor will it probably be done until the next weekend. So more delay (until somebody else steps in). NT386 failures are still not resolved, too, AFAIK. Any volunteers? Please note that the built packages now available for RC3 are mostly working, at least better than RC2. But SOLgnu and NT386 couldn't be built with the RC3 tag. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Aug 25 18:28:34 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 25 Aug 2009 16:28:34 +0000 Subject: [M3devel] timeout at the end of makedist? Message-ID: http://www.modula3.com:8080/view/SOLgnu/job/cm3-makedist-SOLgnu/14/console all the way at the bottom: -rw-r--r-- 1 hudson other 2785402 Aug 25 05:56 /home/hudson/tmp/cm3-bin-ws-game-SOLgnu-5.8.3-RC3.tgz Received disconnect from 88.198.39.217: 2: Timeout, your session not responding. lost connection Finished: SUCCESS This is copying the packages to birch? It shouldn't report success? We should do some incremental copy? - Jay From jay.krell at cornell.edu Tue Aug 25 18:31:55 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 25 Aug 2009 16:31:55 +0000 Subject: [M3devel] HEADS UP: Rebuild RC3 or wait for RC4 next week? was Re: RC3 tag In-Reply-To: <20090825134528.ah9lydnwgwgs0skg@mail.elegosoft.com> References: <20090825080701.cfz0fs2wao0880gc@mail.elegosoft.com> <20090825112947.GB14914@topoi.pooq.com> <20090825134528.ah9lydnwgwgs0skg@mail.elegosoft.com> Message-ID: Please let's not create extra process and secretarial work. It's bad enough to have to any branching. I'll move the RC3 tag forward as needed for SOLgnu, SOLsun, NT386. SOLgnu looks good now except for the timeout at the end with scp, and the cvsup problem to fix. - Jay ---------------------------------------- > Date: Tue, 25 Aug 2009 13:45:28 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] HEADS UP: Rebuild RC3 or wait for RC4 next week? was Re: RC3 tag > > Quoting hendrik at topoi.pooq.com: > >> On Tue, Aug 25, 2009 at 08:07:01AM +0200, Olaf Wagner wrote: >>> >>> We should then rebuild all packages. >> >> With some distinction in the version numbers so people know which is >> which. RC3.1? RC4? > > RC3.1 does not make sense. Doing everthing according to plan, we had > to abandon RC3 and build RC4 now. The RC3 tag has been moved which shouldn't > happen strictly speaking. There's no mechanism in CVS to lock a tag though. > > There have been only minor corrections, mostly in the build tooling > and system dependencies AFAIK. So we could make a concession and rebuild > the RC3 packages as they only have been announced on the m3 mailing lists > so far. I'd vote for that in this case. > > Switching to RC4 requires changing several scripts and docs again > and applying a new tag. I cannot do that from here, nor will it probably > be done until the next weekend. So more delay (until somebody else > steps in). NT386 failures are still not resolved, too, AFAIK. > Any volunteers? > > Please note that the built packages now available for RC3 are mostly > working, at least better than RC2. But SOLgnu and NT386 couldn't be > built with the RC3 tag. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Tue Aug 25 18:38:35 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 25 Aug 2009 16:38:35 +0000 Subject: [M3devel] SOLsun and versions Message-ID: Fyi, I'm running a very current Solaris 2.10 2009/05 and its SunStudio 12. http://www.modula3.com:8080/view/SOLsun/job/boot-solsun/9/console "../src/os/POSIX/FilePosixC.c", line 19: warning: typedef redeclared: flock_t cc: Warning: -xarch=v8plus is deprecated, use -m32 -xarch=sparc instead cc: Warning: -xarch=v8plus is deprecated, use -m32 -xarch=sparc instead "/home/hudson/work/solsun/cm3-inst/ssol/rel-d5.8.2/pkg/m3core/src/unix/Common/m3unix.h", line 83: warning: typedef redeclared: timespec_t "../src/os/POSIX/FSPosixC.c", line 12: warning: typedef redeclared: dirent_t cc: Warning: -xarch=v8plus is deprecated, use -m32 -xarch=sparc instead cc: Warning: -xarch=v8plus is deprecated, use -m32 -xarch=sparc instead Undefined first referenced symbol in file __floatdidf FilePosix.mo Could very well be that if/when I fix these or some of them, we'll lose compatibility with older releases. Maybe I'll read the man pages and find out what is compatibile with what. Maybe we can/should do something more "like" autoconf in places. - Jay From jay.krell at cornell.edu Tue Aug 25 19:07:52 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 25 Aug 2009 17:07:52 +0000 Subject: [M3devel] HEADS UP: Rebuild RC3 or wait for RC4 next week? was Re: RC3 tag In-Reply-To: References: <20090825080701.cfz0fs2wao0880gc@mail.elegosoft.com> <20090825112947.GB14914@topoi.pooq.com> <20090825134528.ah9lydnwgwgs0skg@mail.elegosoft.com> Message-ID: The NT386 problems look small btw. "C:\cygwin\home\elego\tmp\cm3\pkg\cit_util\src\generics.tmpl", line 38: quake runtime error: exit 1: C:\cygwin\home\elego\workspace\cm3-makedist-NT386\cm3\caltech-parser\parserlib\klex\NT386\klex ..\src\Calc.l -o CalcLex.i3 -t ..\src\Calc.t -ti3 CalcTok.i3 "C:\cygwin\home\elego\tmp\cm3\pkg\cit_util\src\generics.tmpl", line 38: quake runtime error: exit 1: C:\cygwin\home\elego\workspace\cm3-makedist-NT386\cm3\caltech-parser\parserlib\klex\NT386\klex ..\src\Calc.l -o CalcLex.i3 -t ..\src\Calc.t -ti3 CalcTok.i3 Fatal Error: package build failed errors during build-all; some packages will be missing m3-win/import-libs/NT386/.M3SHIP seems to be broken: make_dir("C:/cygwin/home/elego/tmp/cm3/lib") install_file("wsock32.lib", "C:/cygwin/home/elego/tmp/cm3/lib", "0775") Probably a matter of forward vs. backward slashes on the second set. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Date: Tue, 25 Aug 2009 16:31:55 +0000 > Subject: Re: [M3devel] HEADS UP: Rebuild RC3 or wait for RC4 next week? was Re: RC3 tag > > > Please let's not create extra process and secretarial work. It's bad enough to have to any branching. > I'll move the RC3 tag forward as needed for SOLgnu, SOLsun, NT386. > SOLgnu looks good now except for the timeout at the end with scp, and the cvsup problem to fix. > > - Jay > > ---------------------------------------- >> Date: Tue, 25 Aug 2009 13:45:28 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] HEADS UP: Rebuild RC3 or wait for RC4 next week? was Re: RC3 tag >> >> Quoting hendrik at topoi.pooq.com: >> >>> On Tue, Aug 25, 2009 at 08:07:01AM +0200, Olaf Wagner wrote: >>>> >>>> We should then rebuild all packages. >>> >>> With some distinction in the version numbers so people know which is >>> which. RC3.1? RC4? >> >> RC3.1 does not make sense. Doing everthing according to plan, we had >> to abandon RC3 and build RC4 now. The RC3 tag has been moved which shouldn't >> happen strictly speaking. There's no mechanism in CVS to lock a tag though. >> >> There have been only minor corrections, mostly in the build tooling >> and system dependencies AFAIK. So we could make a concession and rebuild >> the RC3 packages as they only have been announced on the m3 mailing lists >> so far. I'd vote for that in this case. >> >> Switching to RC4 requires changing several scripts and docs again >> and applying a new tag. I cannot do that from here, nor will it probably >> be done until the next weekend. So more delay (until somebody else >> steps in). NT386 failures are still not resolved, too, AFAIK. >> Any volunteers? >> >> Please note that the built packages now available for RC3 are mostly >> working, at least better than RC2. But SOLgnu and NT386 couldn't be >> built with the RC3 tag. >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> From hendrik at topoi.pooq.com Tue Aug 25 20:13:05 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 25 Aug 2009 14:13:05 -0400 Subject: [M3devel] How to compile system from (modified) source? In-Reply-To: References: <20090825013610.GA13985@topoi.pooq.com> Message-ID: <20090825181305.GB15646@topoi.pooq.com> On Tue, Aug 25, 2009 at 01:56:21AM +0000, Jay K wrote: > > apt-get install unixodbc > etc. > ? I already had unixodbc installed on my system. Just in case the installation was affected by the build vd buildship problem, I restored the std script to its original code (uncommenting the fgrep line I had commented out, and commenting out the P= line with the long list I had put in, and reran. Here's what appears to be the relevant part of the log: === package m3-db/odbc === +++ cm3 -build -DROOT='/farhome/hendrik/cm3/love-sq/cm3' -DCM3_VERSION_TEXT='d5.8.2' -DCM3_VERSION_NUMBER='050802' -DCM3_LAST_CHANGED='2009-07-15' $RARGS && cm3 -ship $RARGS -DROOT='/farhome/hendrik/cm3/love-sq/cm3' -DCM3_VERSION_TEXT='d5.8.2' -DCM3_VERSION_NUMBER='050802' -DCM3_LAST_CHANGED='2009-07-15' +++ --- building in LINUXLIBC6 --- ignoring ../src/m3overrides new "/usr/local/cm3/pkg/m3core/LINUXLIBC6/libm3core.a" -> archiving libm3odbc.a /usr/bin/ld: cannot find -lodbc collect2: ld returned 1 exit status make_lib => 1 librarian failed building: m3odbc Fatal Error: package build failed *** execution of cm3 -build -DROOT='/farhome/hendrik/cm3/love-sq/cm3' -DCM3_VERSION_TEXT='d5.8.2' -DCM3_VERSION_NUMBER='050802' -DCM3_LAST_CHANGED='2009-07-15' $RARGS && cm3 -ship $RARGS -DROOT='/farhome/hendrik/cm3/love-sq/cm3' -DCM3_VERSION_TEXT='d5.8.2' -DCM3_VERSION_NUMBER='050802' -DCM3_LAST_CHANGED='2009-07-15' failed *** hendrik at lovesong:~/cm3/love-sq/cm3$ exit Script done, file is log9-with-db-again And here's the list of files for package unixodbc in squeeze, according to the Debian packages website in case it's useful: /usr/bin/isql /usr/bin/iusql /usr/lib/libgtrtst.so.1 /usr/lib/libgtrtst.so.1.0.0 /usr/lib/libodbc.so.1 /usr/lib/libodbc.so.1.0.0 /usr/lib/libodbccr.so.1 /usr/lib/libodbccr.so.1.0.0 /usr/lib/odbc/libnn.so /usr/lib/odbc/libodbctxt.so /usr/share/doc/unixodbc/AUTHORS /usr/share/doc/unixodbc/NEWS.gz /usr/share/doc/unixodbc/README /usr/share/doc/unixodbc/README.GTK /usr/share/doc/unixodbc/README.MySql /usr/share/doc/unixodbc/changelog.Debian.gz /usr/share/doc/unixodbc/changelog.gz /usr/share/doc/unixodbc/copyright /usr/share/lintian/overrides/unixodbc /usr/share/man/man1/isql.1.gz /usr/share/man/man1/iusql.1.gz -- hendrik From jay.krell at cornell.edu Tue Aug 25 21:19:05 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Tue, 25 Aug 2009 15:19:05 -0400 Subject: [M3devel] SOLsun and versions In-Reply-To: References: Message-ID: <55A850EF-4F94-4568-8A00-D4CD5D54F9CD@hotmail.com> (truncated!) - Jay (phone) On Aug 25, 2009, at 12:38 PM, Jay K wrote: > > Fyi, I'm running a very current Solaris 2.10 2009/05 and its > SunStudio 12 From jay.krell at cornell.edu Tue Aug 25 21:22:08 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Tue, 25 Aug 2009 15:22:08 -0400 Subject: [M3devel] How to compile system from (modified) source? In-Reply-To: <20090825181305.GB15646@topoi.pooq.com> References: <20090825013610.GA13985@topoi.pooq.com> <20090825181305.GB15646@topoi.pooq.com> Message-ID: <8A772E75-0495-44E2-9751-3032E9031FD4@hotmail.com> cd m3-db/odbc rm -rf LINUXLIBC6 cm3 -commands or look for odbc in install/bin/config/* - Jay (phone) On Aug 25, 2009, at 2:13 PM, hendrik at topoi.pooq.com wrote: > On Tue, Aug 25, 2009 at 01:56:21AM +0000, Jay K wrote: >> >> apt-get install unixodbc >> etc. >> ? > > I already had unixodbc installed on my system. > > Just in case the installation was affected by the build vd buildship > problem, I restored the std script to its original code (uncommenting > the fgrep line I had commented out, and commenting out the P= line > with > the long list I had put in, and reran. Here's what appears to be the > relevant part of the log: > > === package m3-db/odbc === > +++ cm3 -build -DROOT='/farhome/hendrik/cm3/love-sq/cm3' - > DCM3_VERSION_TEXT='d5.8.2' -DCM3_VERSION_NUMBER='050802' - > DCM3_LAST_CHANGED='2009-07-15' $RARGS && cm3 -ship $RARGS -DROOT='/ > farhome/hendrik/cm3/love-sq/cm3' -DCM3_VERSION_TEXT='d5.8.2' - > DCM3_VERSION_NUMBER='050802' -DCM3_LAST_CHANGED='2009-07-15' +++ > --- building in LINUXLIBC6 --- > > ignoring ../src/m3overrides > > new "/usr/local/cm3/pkg/m3core/LINUXLIBC6/libm3core.a" -> archiving > libm3odbc.a > /usr/bin/ld: cannot find -lodbc > collect2: ld returned 1 exit status > make_lib => 1 > librarian failed building: m3odbc > Fatal Error: package build failed > *** execution of cm3 -build -DROOT='/farhome/hendrik/cm3/love-sq/ > cm3' -DCM3_VERSION_TEXT='d5.8.2' -DCM3_VERSION_NUMBER='050802' - > DCM3_LAST_CHANGED='2009-07-15' $RARGS && cm3 -ship $RARGS -DROOT='/ > farhome/hendrik/cm3/love-sq/cm3' -DCM3_VERSION_TEXT='d5.8.2' - > DCM3_VERSION_NUMBER='050802' -DCM3_LAST_CHANGED='2009-07-15' failed > *** > hendrik at lovesong:~/cm3/love-sq/cm3$ exit > Script done, file is log9-with-db-again > > > And here's the list of files for package unixodbc in squeeze, > according to the Debian packages website in case it's useful: > > /usr/bin/isql > /usr/bin/iusql > /usr/lib/libgtrtst.so.1 > /usr/lib/libgtrtst.so.1.0.0 > /usr/lib/libodbc.so.1 > /usr/lib/libodbc.so.1.0.0 > /usr/lib/libodbccr.so.1 > /usr/lib/libodbccr.so.1.0.0 > /usr/lib/odbc/libnn.so > /usr/lib/odbc/libodbctxt.so > /usr/share/doc/unixodbc/AUTHORS > /usr/share/doc/unixodbc/NEWS.gz > /usr/share/doc/unixodbc/README > /usr/share/doc/unixodbc/README.GTK > /usr/share/doc/unixodbc/README.MySql > /usr/share/doc/unixodbc/changelog.Debian.gz > /usr/share/doc/unixodbc/changelog.gz > /usr/share/doc/unixodbc/copyright > /usr/share/lintian/overrides/unixodbc > /usr/share/man/man1/isql.1.gz > /usr/share/man/man1/iusql.1.gz > > > -- hendrik > From wagner at elegosoft.com Tue Aug 25 22:30:24 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 25 Aug 2009 22:30:24 +0200 Subject: [M3devel] timeout at the end of makedist? In-Reply-To: References: Message-ID: <20090825223024.wye2lz0is44004cs@mail.elegosoft.com> Quoting Jay K : > http://www.modula3.com:8080/view/SOLgnu/job/cm3-makedist-SOLgnu/14/console > > all the way at the bottom: > > -rw-r--r-- 1 hudson other 2785402 Aug 25 05:56 > /home/hudson/tmp/cm3-bin-ws-game-SOLgnu-5.8.3-RC3.tgz > Received disconnect from 88.198.39.217: 2: Timeout, your session not > responding. > lost connection > Finished: SUCCESS > > > > This is copying the packages to birch? > It shouldn't report success? > We should do some incremental copy? scp, like rcp, is inherently unsafe (though more secure) :-/ We should try rsync via ssh instead. Though all ssh-based transfer seems to be a bot unreliable (especially from/to your net). Do we have rsync on all systems? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Aug 25 23:11:33 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 25 Aug 2009 21:11:33 +0000 Subject: [M3devel] timeout at the end of makedist? In-Reply-To: <20090825223024.wye2lz0is44004cs@mail.elegosoft.com> References: <20090825223024.wye2lz0is44004cs@mail.elegosoft.com> Message-ID: > Do we have rsync on all systems? No idea. I've never used it. - Jay From hendrik at topoi.pooq.com Wed Aug 26 02:26:06 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 25 Aug 2009 20:26:06 -0400 Subject: [M3devel] small design problem in ButtonVBT? In-Reply-To: <20090401120347.x8cneize8oscg44o@mail.elegosoft.com> References: <20090331145127.GB9624@topoi.pooq.com> <20090401120347.x8cneize8oscg44o@mail.elegosoft.com> Message-ID: <20090826002606.GB16386@topoi.pooq.com> On Wed, Apr 01, 2009 at 12:03:47PM +0200, Olaf Wagner wrote: > Quoting hendrik at topoi.pooq.com: > > >The BottonVBT contains an action, which is a procedure rather than a > >method. b This makes it awkward to subclass ButtonVBT becaue the action > >will still expect its first parameter to be a ButtonVBT instead of > >belonging to the subclass, and an explicit downcast of some sort will be > >needed to acess the subclass's members. > > > >The Trestle manual says this was a deliberate decision: > > > >: The action procedure is a field rather than a method in order to allow > >: buttons with different action procedures to share their method suites. > > > >I, however, find it massively inconvenient because it mans I have to > >resort to downcasting or the very kludgey VBT.GetProp to access what > >should be just there. I'd rather the action procedure was a method. > > > >But it should be possible to have the best of both worlds. Have an > >action2 (better name wanted here) method that is available for > >overriding, and by default calls the procedure in the existing action. > >field. That action2 method wounl then be called by Trestle wherever > >action is now called. > > > >Does anyone see problems with this? > > Sounds fine to me offhand. You should test your extensions with > some of the existing larger applications, like mentor and Juno-2, > of course. OK. Here's the patch. Would it be possible for someone to check it in for me? mentor runs fine with this change; I watched it animate a heap-sort. I have no idea what Juno is supposed to do, but it did respond to button-pushes. hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ cvs diff cvs diff: Diffing . Index: ButtonVBT.i3 =================================================================== RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.i3,v retrieving revision 1.2 diff -r1.2 ButtonVBT.i3 39a40 > act(READONLY cd: VBT.MouseRec); Index: ButtonVBT.m3 =================================================================== RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.m3,v retrieving revision 1.2 diff -r1.2 ButtonVBT.m3 28c28,29 < init := Be --- > init := Be; > act := act 46a48,52 > PROCEDURE act(v : T; READONLY cd: VBT.MouseRec) = > BEGIN > v.action(v, cd); > END act; > 59c65 < v.action(v, cd); --- > v.act(cd); hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ -- hendrik From jay.krell at cornell.edu Wed Aug 26 09:02:56 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 26 Aug 2009 07:02:56 +0000 Subject: [M3devel] caltech-parser NT386 Hudson problems Message-ID: I think the caltech-parser on NT386 problems are related to line endings. I'm not sure. I see it outputing carriage returns and backslash line continuations -- though Modula-3 has no such line continuations. I haven't been able to find the code in caltech-parser that does that. http://www.modula3.com:8080/computer/elego-win-vm/configure I removed the CYGWIN variable, that previously was nobinmode. The tasks also fiddle around with the mount command. I think all the -o options should be removed. I've left it alone for now. We should try to make it work either way, perhaps. I'm not super keen on changing my local setting, nor debugging it remotely -- it is slow. If pushed I'll try changing my local setting. I set: C:\>set cyg CYGWIN=server but that's probably not needed. and: C:\>mount c:\cygwin\bin on /usr/bin type system (binmode) c:\cygwin\lib on /usr/lib type system (binmode) c:\cygwin on / type system (binmode) c:\obj on /obj type system (binmode) c:\src on /src type system (binmode) c: on /cygdrive/c type user (binmode,noumount) The caltech-parser/parerlib/parerlib/test directory works for me. I get newlines only in the output. Given that the caltech-parser binaries aren't cygwin binaries, I'm actually not sure how any of this could matter. Could be cvs though. Yes, that is a big possibility. For example I only got klex to output files by first running dos2unix on some files, which shouldn't do anything. caltech-parser should imho accept \r and \r\n as line delimiters. I'm not sure if empty lines are significant to it. If not, this is easy. If so, it appears not. It appears to split lines on single characters. - Jay From jay.krell at cornell.edu Wed Aug 26 09:18:03 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 26 Aug 2009 07:18:03 +0000 Subject: [M3devel] caltech-parser NT386 Hudson problems In-Reply-To: References: Message-ID: On second thought, upon further investigation, I changed all the mount commands. We'll see how that does. Probably should also re-checkout all the workspaces. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Date: Wed, 26 Aug 2009 07:02:56 +0000 > Subject: [M3devel] caltech-parser NT386 Hudson problems > > > I think the caltech-parser on NT386 problems are related to line endings. > I'm not sure. > I see it outputing carriage returns and backslash line continuations -- > though Modula-3 has no such line continuations. > I haven't been able to find the code in caltech-parser that does that. > > > http://www.modula3.com:8080/computer/elego-win-vm/configure > > > I removed the CYGWIN variable, that previously was nobinmode. > The tasks also fiddle around with the mount command. > I think all the -o options should be removed. > I've left it alone for now. > > > We should try to make it work either way, perhaps. > > > I'm not super keen on changing my local setting, nor debugging > it remotely -- it is slow. If pushed I'll try changing my local setting. > > > I set: > > > C:\>set cyg > CYGWIN=server > > > but that's probably not needed. > > and: > C:\>mount > c:\cygwin\bin on /usr/bin type system (binmode) > c:\cygwin\lib on /usr/lib type system (binmode) > c:\cygwin on / type system (binmode) > c:\obj on /obj type system (binmode) > c:\src on /src type system (binmode) > c: on /cygdrive/c type user (binmode,noumount) > > > The caltech-parser/parerlib/parerlib/test directory works for me. > I get newlines only in the output. > > > Given that the caltech-parser binaries aren't cygwin binaries, I'm > actually not sure how any of this could matter. > > > Could be cvs though. Yes, that is a big possibility. > For example I only got klex to output files by first running dos2unix on some > files, which shouldn't do anything. > > > caltech-parser should imho accept \r and \r\n as line delimiters. > I'm not sure if empty lines are significant to it. > If not, this is easy. > If so, it appears not. It appears to split lines on single characters. > > > - Jay From wagner at elegosoft.com Wed Aug 26 10:04:41 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 26 Aug 2009 10:04:41 +0200 Subject: [M3devel] small design problem in ButtonVBT? In-Reply-To: <20090826002606.GB16386@topoi.pooq.com> References: <20090331145127.GB9624@topoi.pooq.com> <20090401120347.x8cneize8oscg44o@mail.elegosoft.com> <20090826002606.GB16386@topoi.pooq.com> Message-ID: <20090826100441.ftj2zoekg0kook0w@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > OK. Here's the patch. Would it be possible for someone to check it in > for me? I can do that tonight if nobody is faster. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Aug 26 17:37:16 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 26 Aug 2009 15:37:16 +0000 Subject: [M3devel] running cm3 by relative path Message-ID: Running cm3 by relative path seems to act wierd. $ ./last-ok/bin/cm3 -version Critical Mass Modula-3 version 5.8.3 last updated: 2009-08-22 compiled: 2009-08-25 09:52:28 configuration: ./last-ok/bin/cm3.cfg host: SOLgnu quake runtime error: "./last-ok/bin/cm3.cfg", line 2: quake runtime error: unabl e to open "./last-ok/bin/./last-ok/bin/config/SOLsun" for reading --procedure-- -line- -file--- include -- 2 ./last-ok/bin/cm3.cfg target: $ `pwd`/last-ok/bin/cm3 -version Critical Mass Modula-3 version 5.8.3 last updated: 2009-08-22 compiled: 2009-08-25 09:52:28 configuration: /home/hudson/work/cm3-inst/ssol-sun/last-ok/bin/cm3.cfg host: SOLgnu target: SOLsun I'll have to see if this is related to my recent change or not. I'm also seemingly not able to change host to SOLsun from SOLgnu but that's not likely a bug in cm3. -Jay From hendrik at topoi.pooq.com Wed Aug 26 20:44:17 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 26 Aug 2009 14:44:17 -0400 Subject: [M3devel] trying RC3 In-Reply-To: References: <20090824005658.GA11486@topoi.pooq.com> <20090824013245.GA11619@topoi.pooq.com> Message-ID: <20090826184417.GA18029@topoi.pooq.com> On Mon, Aug 24, 2009 at 02:43:52AM +0000, Jay K wrote: > > In CVS. > > - Jay Now that it seems some RC3 packages are being rebuilt, will this include new builds for LINUXLIBC6? If so, I'll try again with the new RC3. If not, I'll just wait for RC4. By the wat, P.S. I'm not sitting on he edge of my seat, waiting for a usable cvsup release. I have compiled my own. What I'm really doing here is testing the tgz packages. Just let me know when it's useful to test again. -- hendrik > > > ---------------------------------------- > > Date: Sun, 23 Aug 2009 21:32:45 -0400 > > From: hendrik at topoi.pooq.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] trying RC3 > > > > On Mon, Aug 24, 2009 at 01:07:25AM +0000, Jay K wrote: > >> > >> This is understood and fixed, specific to cvsup. > > > > Does 'fixed' mean you've replaced the RC3 archive, in which case I'll > > try it again soon, or that it'll be OK in RC4? > > > > Or just fixed in CVS? > > > >> > >> Thanks, > >> - Jay > > > > You're welcome. Each time a new RC comes out, I shunt aside my existing > > cm3, and try an install. Then I report on the problems, and move the > > working cm3 back. > > > > I'll spend some time this week testing the other ws-packages. > > > > Thanks. > > > > -- hendrik > > From wagner at elegosoft.com Thu Aug 27 08:06:57 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 27 Aug 2009 08:06:57 +0200 Subject: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems In-Reply-To: References: <20090826142644.r6yabwff5wc84cgg@mail.elegosoft.com> Message-ID: <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> Quoting Jay K : > Something or some things very wierd here. I'll keep looking into it. I'm not sure if we should spend/waste(?) more time in trying to make this VM with Windows work. Last night I reactivated my own qemu-based VM and was able to checkout and build some current CM3 stuff. CVS behaves correctly there, and no need to adapt any of the shell scripts at all. It's agonizingly slow though. And it has no remote access. However, building the release archives failed with two errors: vbtkit: new source -> compiling VBTKitResources.m3 "..\src\lego\VBTKitResources.m3", line 10: unable to find interface (VBTKitBundle) 1 error encountered and errors during build-all; some packages will be missing m3-win/import-libs/NT386/.M3SHIP seems to be broken: make_dir("c:/tmp/cm3/lib") install_file("wsock32.lib", "c:/tmp/cm3/lib", "0775") install_file("advapi32.lib", "c:/tmp/cm3/lib", "0775") install_file("opengl32.lib", "c:/tmp/cm3/lib", "0775") install_file("netapi32.lib", "c:/tmp/cm3/lib", "0775") install_file("comctl32.lib", "c:/tmp/cm3/lib", "0775") install_file("user32.lib", "c:/tmp/cm3/lib", "0775") install_file("comdlg32.lib", "c:/tmp/cm3/lib", "0775") install_file("kernel32.lib", "c:/tmp/cm3/lib", "0775") install_file("winspool.lib", "c:/tmp/cm3/lib", "0775") install_file("glu32.lib", "c:/tmp/cm3/lib", "0775") install_file("gdi32.lib", "c:/tmp/cm3/lib", "0775") install_file("odbc32.lib", "c:/tmp/cm3/lib", "0775") (wrong shippind destination, already reported) I suggest we rather concentrate on these and build the Windows packages manually. I'm off to (paid) work again now... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Aug 27 08:09:52 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 27 Aug 2009 06:09:52 +0000 Subject: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems In-Reply-To: <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> References: <20090826142644.r6yabwff5wc84cgg@mail.elegosoft.com> <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> Message-ID: I'm testing a fix for the VM right now actually. Once that works I'll look into the Unresolve problem further. I put in some printing to help diagnose it and possibly a fix. It could be a slash mixup; the printing will tell us. The VBT problem is new seeming. I'll look at that too. Anyone else is welcome to also. - Jay ---------------------------------------- > Date: Thu, 27 Aug 2009 08:06:57 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems > > Quoting Jay K : > >> Something or some things very wierd here. I'll keep looking into it. > I'm not sure if we should spend/waste(?) more time in trying to make > this VM with Windows work. > > Last night I reactivated my own qemu-based VM and was able to checkout > and build some current CM3 stuff. > > CVS behaves correctly there, and no need to adapt any of the shell > scripts at all. It's agonizingly slow though. And it has no remote > access. > > However, building the release archives failed with two errors: > > vbtkit: > new source -> compiling VBTKitResources.m3 > "..\src\lego\VBTKitResources.m3", line 10: unable to find interface > (VBTKitBundle) > 1 error encountered > > and > > errors during build-all; some packages will be missing > m3-win/import-libs/NT386/.M3SHIP seems to be broken: > make_dir("c:/tmp/cm3/lib") > install_file("wsock32.lib", "c:/tmp/cm3/lib", "0775") > install_file("advapi32.lib", "c:/tmp/cm3/lib", "0775") > install_file("opengl32.lib", "c:/tmp/cm3/lib", "0775") > install_file("netapi32.lib", "c:/tmp/cm3/lib", "0775") > install_file("comctl32.lib", "c:/tmp/cm3/lib", "0775") > install_file("user32.lib", "c:/tmp/cm3/lib", "0775") > install_file("comdlg32.lib", "c:/tmp/cm3/lib", "0775") > install_file("kernel32.lib", "c:/tmp/cm3/lib", "0775") > install_file("winspool.lib", "c:/tmp/cm3/lib", "0775") > install_file("glu32.lib", "c:/tmp/cm3/lib", "0775") > install_file("gdi32.lib", "c:/tmp/cm3/lib", "0775") > install_file("odbc32.lib", "c:/tmp/cm3/lib", "0775") > > (wrong shippind destination, already reported) > > I suggest we rather concentrate on these and build the Windows > packages manually. > > I'm off to (paid) work again now... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Thu Aug 27 08:41:46 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 27 Aug 2009 06:41:46 +0000 Subject: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems In-Reply-To: References: <20090826142644.r6yabwff5wc84cgg@mail.elegosoft.com> <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> Message-ID: >> vbtkit: >> new source -> compiling VBTKitResources.m3 >> "..\src\lego\VBTKitResources.m3", line 10: unable to find interface >> (VBTKitBundle) >> 1 error encountered Is m3bundle working for you? In head I have the files: C:\dev2\cm3.2\m3-ui\vbtkit>dir /s/b *kit*bund* C:\dev2\cm3.2\m3-ui\vbtkit\NT386\VBTKitBundle.i3 C:\dev2\cm3.2\m3-ui\vbtkit\NT386\VBTKitBundle.io C:\dev2\cm3.2\m3-ui\vbtkit\NT386\VBTKitBundle.m3 C:\dev2\cm3.2\m3-ui\vbtkit\NT386\VBTKitBundle.mo - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > Date: Thu, 27 Aug 2009 06:09:52 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems > > > I'm testing a fix for the VM right now actually. > Once that works I'll look into the Unresolve problem further. I put in some printing to help diagnose it and possibly a fix. It could be a slash mixup; the printing will tell us. > The VBT problem is new seeming. I'll look at that too. > Anyone else is welcome to also. > > - Jay > > > ---------------------------------------- >> Date: Thu, 27 Aug 2009 08:06:57 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems >> >> Quoting Jay K : >> >>> Something or some things very wierd here. I'll keep looking into it. >> I'm not sure if we should spend/waste(?) more time in trying to make >> this VM with Windows work. >> >> Last night I reactivated my own qemu-based VM and was able to checkout >> and build some current CM3 stuff. >> >> CVS behaves correctly there, and no need to adapt any of the shell >> scripts at all. It's agonizingly slow though. And it has no remote >> access. >> >> However, building the release archives failed with two errors: >> >> vbtkit: >> new source -> compiling VBTKitResources.m3 >> "..\src\lego\VBTKitResources.m3", line 10: unable to find interface >> (VBTKitBundle) >> 1 error encountered >> >> and >> >> errors during build-all; some packages will be missing >> m3-win/import-libs/NT386/.M3SHIP seems to be broken: >> make_dir("c:/tmp/cm3/lib") >> install_file("wsock32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("advapi32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("opengl32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("netapi32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("comctl32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("user32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("comdlg32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("kernel32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("winspool.lib", "c:/tmp/cm3/lib", "0775") >> install_file("glu32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("gdi32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("odbc32.lib", "c:/tmp/cm3/lib", "0775") >> >> (wrong shippind destination, already reported) >> >> I suggest we rather concentrate on these and build the Windows >> packages manually. >> >> I'm off to (paid) work again now... >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> From wagner at elegosoft.com Thu Aug 27 10:02:42 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 27 Aug 2009 10:02:42 +0200 Subject: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems In-Reply-To: References: <20090826142644.r6yabwff5wc84cgg@mail.elegosoft.com> <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> Message-ID: <20090827100242.uyc9fca968s480c4@mail.elegosoft.com> Quoting Jay K : >>> vbtkit: >>> new source -> compiling VBTKitResources.m3 >>> "..\src\lego\VBTKitResources.m3", line 10: unable to find interface >>> (VBTKitBundle) >>> 1 error encountered > > Is m3bundle working for you? > In head I have the files: > > C:\dev2\cm3.2\m3-ui\vbtkit>dir /s/b *kit*bund* > C:\dev2\cm3.2\m3-ui\vbtkit\NT386\VBTKitBundle.i3 > C:\dev2\cm3.2\m3-ui\vbtkit\NT386\VBTKitBundle.io > C:\dev2\cm3.2\m3-ui\vbtkit\NT386\VBTKitBundle.m3 > C:\dev2\cm3.2\m3-ui\vbtkit\NT386\VBTKitBundle.mo Sorry, I cannot check from here. I only remember that the missing interfaces seemed to be the first problem. Maybe I've overseeen failing m3bundle calls though. Strange. Olaf > - Jay > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com >> Date: Thu, 27 Aug 2009 06:09:52 +0000 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] RC3 build problems, was: RE: caltech-parser >> NT386 Hudson problems >> >> >> I'm testing a fix for the VM right now actually. >> Once that works I'll look into the Unresolve problem further. I put >> in some printing to help diagnose it and possibly a fix. It could >> be a slash mixup; the printing will tell us. >> The VBT problem is new seeming. I'll look at that too. >> Anyone else is welcome to also. >> >> - Jay >> >> >> ---------------------------------------- >>> Date: Thu, 27 Aug 2009 08:06:57 +0200 >>> From: wagner at elegosoft.com >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com >>> Subject: [M3devel] RC3 build problems, was: RE: caltech-parser >>> NT386 Hudson problems >>> >>> Quoting Jay K : >>> >>>> Something or some things very wierd here. I'll keep looking into it. >>> I'm not sure if we should spend/waste(?) more time in trying to make >>> this VM with Windows work. >>> >>> Last night I reactivated my own qemu-based VM and was able to checkout >>> and build some current CM3 stuff. >>> >>> CVS behaves correctly there, and no need to adapt any of the shell >>> scripts at all. It's agonizingly slow though. And it has no remote >>> access. >>> >>> However, building the release archives failed with two errors: >>> >>> vbtkit: >>> new source -> compiling VBTKitResources.m3 >>> "..\src\lego\VBTKitResources.m3", line 10: unable to find interface >>> (VBTKitBundle) >>> 1 error encountered >>> >>> and >>> >>> errors during build-all; some packages will be missing >>> m3-win/import-libs/NT386/.M3SHIP seems to be broken: >>> make_dir("c:/tmp/cm3/lib") >>> install_file("wsock32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("advapi32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("opengl32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("netapi32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("comctl32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("user32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("comdlg32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("kernel32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("winspool.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("glu32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("gdi32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("odbc32.lib", "c:/tmp/cm3/lib", "0775") >>> >>> (wrong shippind destination, already reported) >>> >>> I suggest we rather concentrate on these and build the Windows >>> packages manually. >>> >>> I'm off to (paid) work again now... >>> >>> Olaf >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Aug 27 14:14:02 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 27 Aug 2009 12:14:02 +0000 Subject: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems In-Reply-To: <20090827100242.uyc9fca968s480c4@mail.elegosoft.com> References: <20090826142644.r6yabwff5wc84cgg@mail.elegosoft.com> <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> <20090827100242.uyc9fca968s480c4@mail.elegosoft.com> Message-ID: Maybe your initial install lacked it? - Jay ---------------------------------------- > Date: Thu, 27 Aug 2009 10:02:42 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems > > Quoting Jay K : > >>>> vbtkit: >>>> new source -> compiling VBTKitResources.m3 >>>> "..\src\lego\VBTKitResources.m3", line 10: unable to find interface >>>> (VBTKitBundle) >>>> 1 error encountered >> >> Is m3bundle working for you? >> In head I have the files: >> >> C:\dev2\cm3.2\m3-ui\vbtkit>dir /s/b *kit*bund* >> C:\dev2\cm3.2\m3-ui\vbtkit\NT386\VBTKitBundle.i3 >> C:\dev2\cm3.2\m3-ui\vbtkit\NT386\VBTKitBundle.io >> C:\dev2\cm3.2\m3-ui\vbtkit\NT386\VBTKitBundle.m3 >> C:\dev2\cm3.2\m3-ui\vbtkit\NT386\VBTKitBundle.mo > > Sorry, I cannot check from here. I only remember that the > missing interfaces seemed to be the first problem. Maybe I've > overseeen failing m3bundle calls though. Strange. > > Olaf > >> - Jay >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: wagner at elegosoft.com >>> Date: Thu, 27 Aug 2009 06:09:52 +0000 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] RC3 build problems, was: RE: caltech-parser >>> NT386 Hudson problems >>> >>> >>> I'm testing a fix for the VM right now actually. >>> Once that works I'll look into the Unresolve problem further. I put >>> in some printing to help diagnose it and possibly a fix. It could >>> be a slash mixup; the printing will tell us. >>> The VBT problem is new seeming. I'll look at that too. >>> Anyone else is welcome to also. >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> Date: Thu, 27 Aug 2009 08:06:57 +0200 >>>> From: wagner at elegosoft.com >>>> To: jay.krell at cornell.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: [M3devel] RC3 build problems, was: RE: caltech-parser >>>> NT386 Hudson problems >>>> >>>> Quoting Jay K : >>>> >>>>> Something or some things very wierd here. I'll keep looking into it. >>>> I'm not sure if we should spend/waste(?) more time in trying to make >>>> this VM with Windows work. >>>> >>>> Last night I reactivated my own qemu-based VM and was able to checkout >>>> and build some current CM3 stuff. >>>> >>>> CVS behaves correctly there, and no need to adapt any of the shell >>>> scripts at all. It's agonizingly slow though. And it has no remote >>>> access. >>>> >>>> However, building the release archives failed with two errors: >>>> >>>> vbtkit: >>>> new source -> compiling VBTKitResources.m3 >>>> "..\src\lego\VBTKitResources.m3", line 10: unable to find interface >>>> (VBTKitBundle) >>>> 1 error encountered >>>> >>>> and >>>> >>>> errors during build-all; some packages will be missing >>>> m3-win/import-libs/NT386/.M3SHIP seems to be broken: >>>> make_dir("c:/tmp/cm3/lib") >>>> install_file("wsock32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("advapi32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("opengl32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("netapi32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("comctl32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("user32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("comdlg32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("kernel32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("winspool.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("glu32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("gdi32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("odbc32.lib", "c:/tmp/cm3/lib", "0775") >>>> >>>> (wrong shippind destination, already reported) >>>> >>>> I suggest we rather concentrate on these and build the Windows >>>> packages manually. >>>> >>>> I'm off to (paid) work again now... >>>> >>>> Olaf >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>> DE163214194 >>>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Thu Aug 27 14:15:14 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 27 Aug 2009 12:15:14 +0000 Subject: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems In-Reply-To: <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> References: <20090826142644.r6yabwff5wc84cgg@mail.elegosoft.com> <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> Message-ID: My current theory is the unresolve problem is due to that wierd initial build of import-libs in the Hudson task, which was related to the line endings problem, which was related to using CVSNT instead of Cygwin cvs. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems > Date: Thu, 27 Aug 2009 06:09:52 +0000 > > > I'm testing a fix for the VM right now actually. > Once that works I'll look into the Unresolve problem further. I put in some printing to help diagnose it and possibly a fix. It could be a slash mixup; the printing will tell us. > The VBT problem is new seeming. I'll look at that too. > Anyone else is welcome to also. > > - Jay > > > ---------------------------------------- >> Date: Thu, 27 Aug 2009 08:06:57 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems >> >> Quoting Jay K : >> >>> Something or some things very wierd here. I'll keep looking into it. >> I'm not sure if we should spend/waste(?) more time in trying to make >> this VM with Windows work. >> >> Last night I reactivated my own qemu-based VM and was able to checkout >> and build some current CM3 stuff. >> >> CVS behaves correctly there, and no need to adapt any of the shell >> scripts at all. It's agonizingly slow though. And it has no remote >> access. >> >> However, building the release archives failed with two errors: >> >> vbtkit: >> new source -> compiling VBTKitResources.m3 >> "..\src\lego\VBTKitResources.m3", line 10: unable to find interface >> (VBTKitBundle) >> 1 error encountered >> >> and >> >> errors during build-all; some packages will be missing >> m3-win/import-libs/NT386/.M3SHIP seems to be broken: >> make_dir("c:/tmp/cm3/lib") >> install_file("wsock32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("advapi32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("opengl32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("netapi32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("comctl32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("user32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("comdlg32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("kernel32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("winspool.lib", "c:/tmp/cm3/lib", "0775") >> install_file("glu32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("gdi32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("odbc32.lib", "c:/tmp/cm3/lib", "0775") >> >> (wrong shippind destination, already reported) >> >> I suggest we rather concentrate on these and build the Windows >> packages manually. >> >> I'm off to (paid) work again now... >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> From wagner at elegosoft.com Thu Aug 27 14:17:41 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 27 Aug 2009 14:17:41 +0200 Subject: [M3devel] small design problem in ButtonVBT? In-Reply-To: <20090826002606.GB16386@topoi.pooq.com> References: <20090331145127.GB9624@topoi.pooq.com> <20090401120347.x8cneize8oscg44o@mail.elegosoft.com> <20090826002606.GB16386@topoi.pooq.com> Message-ID: <20090827141741.9g1u2vrgfgokkksg@mail.elegosoft.com> Though I promised to do it, I have lost sight of this task while trying to build some RC3 archives on Windows. As I'm not at home this evening, can somebody else please commit Hendrik's extension? Is this something we should should have in the release branch, too? Probably not necessary? Olaf Quoting hendrik at topoi.pooq.com: > On Wed, Apr 01, 2009 at 12:03:47PM +0200, Olaf Wagner wrote: >> Quoting hendrik at topoi.pooq.com: >> >> >The BottonVBT contains an action, which is a procedure rather than a >> >method. b This makes it awkward to subclass ButtonVBT becaue the action >> >will still expect its first parameter to be a ButtonVBT instead of >> >belonging to the subclass, and an explicit downcast of some sort will be >> >needed to acess the subclass's members. >> > >> >The Trestle manual says this was a deliberate decision: >> > >> >: The action procedure is a field rather than a method in order to allow >> >: buttons with different action procedures to share their method suites. >> > >> >I, however, find it massively inconvenient because it mans I have to >> >resort to downcasting or the very kludgey VBT.GetProp to access what >> >should be just there. I'd rather the action procedure was a method. >> > >> >But it should be possible to have the best of both worlds. Have an >> >action2 (better name wanted here) method that is available for >> >overriding, and by default calls the procedure in the existing action. >> >field. That action2 method wounl then be called by Trestle wherever >> >action is now called. >> > >> >Does anyone see problems with this? >> >> Sounds fine to me offhand. You should test your extensions with >> some of the existing larger applications, like mentor and Juno-2, >> of course. > > OK. Here's the patch. Would it be possible for someone to check it in > for me? > > mentor runs fine with this change; I watched it animate a heap-sort. > > I have no idea what Juno is supposed to do, but it did respond to > button-pushes. > > > hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ cvs diff > cvs diff: Diffing . > Index: ButtonVBT.i3 > =================================================================== > RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.i3,v > retrieving revision 1.2 > diff -r1.2 ButtonVBT.i3 > 39a40 >> act(READONLY cd: VBT.MouseRec); > Index: ButtonVBT.m3 > =================================================================== > RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.m3,v > retrieving revision 1.2 > diff -r1.2 ButtonVBT.m3 > 28c28,29 > < init := Be > --- >> init := Be; >> act := act > 46a48,52 >> PROCEDURE act(v : T; READONLY cd: VBT.MouseRec) = >> BEGIN >> v.action(v, cd); >> END act; >> > 59c65 > < v.action(v, cd); > --- >> v.act(cd); > hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ > > -- hendrik > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Thu Aug 27 14:22:01 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 27 Aug 2009 14:22:01 +0200 Subject: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems In-Reply-To: References: <20090826142644.r6yabwff5wc84cgg@mail.elegosoft.com> <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> Message-ID: <20090827142201.qim3orxd4488ssss@mail.elegosoft.com> Quoting Jay K : > My current theory is the unresolve problem is due to that wierd > initial build of import-libs in the Hudson task, which was related > to the line endings problem, which was related to using CVSNT > instead of Cygwin cvs. Hm, I don't think so, as is happend in my Home-VM, too. And there's everything with proper NL endings. As for m3bundle, that should have been built by do-cm3-core.sh long before the build of vbtkit fails. But I cannot really check until tomorrow evening. Olaf > - Jay > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] RC3 build problems, was: RE: caltech-parser >> NT386 Hudson problems >> Date: Thu, 27 Aug 2009 06:09:52 +0000 >> >> >> I'm testing a fix for the VM right now actually. >> Once that works I'll look into the Unresolve problem further. I put >> in some printing to help diagnose it and possibly a fix. It could >> be a slash mixup; the printing will tell us. >> The VBT problem is new seeming. I'll look at that too. >> Anyone else is welcome to also. >> >> - Jay >> >> >> ---------------------------------------- >>> Date: Thu, 27 Aug 2009 08:06:57 +0200 >>> From: wagner at elegosoft.com >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com >>> Subject: [M3devel] RC3 build problems, was: RE: caltech-parser >>> NT386 Hudson problems >>> >>> Quoting Jay K : >>> >>>> Something or some things very wierd here. I'll keep looking into it. >>> I'm not sure if we should spend/waste(?) more time in trying to make >>> this VM with Windows work. >>> >>> Last night I reactivated my own qemu-based VM and was able to checkout >>> and build some current CM3 stuff. >>> >>> CVS behaves correctly there, and no need to adapt any of the shell >>> scripts at all. It's agonizingly slow though. And it has no remote >>> access. >>> >>> However, building the release archives failed with two errors: >>> >>> vbtkit: >>> new source -> compiling VBTKitResources.m3 >>> "..\src\lego\VBTKitResources.m3", line 10: unable to find interface >>> (VBTKitBundle) >>> 1 error encountered >>> >>> and >>> >>> errors during build-all; some packages will be missing >>> m3-win/import-libs/NT386/.M3SHIP seems to be broken: >>> make_dir("c:/tmp/cm3/lib") >>> install_file("wsock32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("advapi32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("opengl32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("netapi32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("comctl32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("user32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("comdlg32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("kernel32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("winspool.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("glu32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("gdi32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("odbc32.lib", "c:/tmp/cm3/lib", "0775") >>> >>> (wrong shippind destination, already reported) >>> >>> I suggest we rather concentrate on these and build the Windows >>> packages manually. >>> >>> I'm off to (paid) work again now... -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Aug 27 14:28:49 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 27 Aug 2009 12:28:49 +0000 Subject: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems In-Reply-To: <20090827142201.qim3orxd4488ssss@mail.elegosoft.com> References: <20090826142644.r6yabwff5wc84cgg@mail.elegosoft.com> <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> <20090827142201.qim3orxd4488ssss@mail.elegosoft.com> Message-ID: The debugprint doesn't show up. http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/cm3/src/M3Build.m3?r1=1.28.2.4&r2=1.28.2.5 could be tools aren't updated yet. But that is also explained by my theory. Are you sure? I've put in realclean for this package in the Hudson task. I'll do another release and lastok build. We'll see. - Jay ---------------------------------------- > Date: Thu, 27 Aug 2009 14:22:01 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems > > Quoting Jay K : > >> My current theory is the unresolve problem is due to that wierd >> initial build of import-libs in the Hudson task, which was related >> to the line endings problem, which was related to using CVSNT >> instead of Cygwin cvs. > > Hm, I don't think so, as is happend in my Home-VM, too. > And there's everything with proper NL endings. > > As for m3bundle, that should have been built by do-cm3-core.sh > long before the build of vbtkit fails. > > But I cannot really check until tomorrow evening. > > Olaf > >> - Jay >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: wagner at elegosoft.com >>> CC: m3devel at elegosoft.com >>> Subject: RE: [M3devel] RC3 build problems, was: RE: caltech-parser >>> NT386 Hudson problems >>> Date: Thu, 27 Aug 2009 06:09:52 +0000 >>> >>> >>> I'm testing a fix for the VM right now actually. >>> Once that works I'll look into the Unresolve problem further. I put >>> in some printing to help diagnose it and possibly a fix. It could >>> be a slash mixup; the printing will tell us. >>> The VBT problem is new seeming. I'll look at that too. >>> Anyone else is welcome to also. >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> Date: Thu, 27 Aug 2009 08:06:57 +0200 >>>> From: wagner at elegosoft.com >>>> To: jay.krell at cornell.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: [M3devel] RC3 build problems, was: RE: caltech-parser >>>> NT386 Hudson problems >>>> >>>> Quoting Jay K : >>>> >>>>> Something or some things very wierd here. I'll keep looking into it. >>>> I'm not sure if we should spend/waste(?) more time in trying to make >>>> this VM with Windows work. >>>> >>>> Last night I reactivated my own qemu-based VM and was able to checkout >>>> and build some current CM3 stuff. >>>> >>>> CVS behaves correctly there, and no need to adapt any of the shell >>>> scripts at all. It's agonizingly slow though. And it has no remote >>>> access. >>>> >>>> However, building the release archives failed with two errors: >>>> >>>> vbtkit: >>>> new source -> compiling VBTKitResources.m3 >>>> "..\src\lego\VBTKitResources.m3", line 10: unable to find interface >>>> (VBTKitBundle) >>>> 1 error encountered >>>> >>>> and >>>> >>>> errors during build-all; some packages will be missing >>>> m3-win/import-libs/NT386/.M3SHIP seems to be broken: >>>> make_dir("c:/tmp/cm3/lib") >>>> install_file("wsock32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("advapi32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("opengl32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("netapi32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("comctl32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("user32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("comdlg32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("kernel32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("winspool.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("glu32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("gdi32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("odbc32.lib", "c:/tmp/cm3/lib", "0775") >>>> >>>> (wrong shippind destination, already reported) >>>> >>>> I suggest we rather concentrate on these and build the Windows >>>> packages manually. >>>> >>>> I'm off to (paid) work again now... > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Thu Aug 27 14:37:21 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 27 Aug 2009 12:37:21 +0000 Subject: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems In-Reply-To: <20090827142201.qim3orxd4488ssss@mail.elegosoft.com> References: <20090826142644.r6yabwff5wc84cgg@mail.elegosoft.com> <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> <20090827142201.qim3orxd4488ssss@mail.elegosoft.com> Message-ID: ps: It doesn't take CVSNT to cause this, but the workaround of building import-libs up front w/o noresolve. I assume you were missing m3bundle, as consistently build ok here in the birch VM and on my machine. - Jay ---------------------------------------- > Date: Thu, 27 Aug 2009 14:22:01 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems > > Quoting Jay K : > >> My current theory is the unresolve problem is due to that wierd >> initial build of import-libs in the Hudson task, which was related >> to the line endings problem, which was related to using CVSNT >> instead of Cygwin cvs. > > Hm, I don't think so, as is happend in my Home-VM, too. > And there's everything with proper NL endings. > > As for m3bundle, that should have been built by do-cm3-core.sh > long before the build of vbtkit fails. > > But I cannot really check until tomorrow evening. > > Olaf > >> - Jay >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: wagner at elegosoft.com >>> CC: m3devel at elegosoft.com >>> Subject: RE: [M3devel] RC3 build problems, was: RE: caltech-parser >>> NT386 Hudson problems >>> Date: Thu, 27 Aug 2009 06:09:52 +0000 >>> >>> >>> I'm testing a fix for the VM right now actually. >>> Once that works I'll look into the Unresolve problem further. I put >>> in some printing to help diagnose it and possibly a fix. It could >>> be a slash mixup; the printing will tell us. >>> The VBT problem is new seeming. I'll look at that too. >>> Anyone else is welcome to also. >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> Date: Thu, 27 Aug 2009 08:06:57 +0200 >>>> From: wagner at elegosoft.com >>>> To: jay.krell at cornell.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: [M3devel] RC3 build problems, was: RE: caltech-parser >>>> NT386 Hudson problems >>>> >>>> Quoting Jay K : >>>> >>>>> Something or some things very wierd here. I'll keep looking into it. >>>> I'm not sure if we should spend/waste(?) more time in trying to make >>>> this VM with Windows work. >>>> >>>> Last night I reactivated my own qemu-based VM and was able to checkout >>>> and build some current CM3 stuff. >>>> >>>> CVS behaves correctly there, and no need to adapt any of the shell >>>> scripts at all. It's agonizingly slow though. And it has no remote >>>> access. >>>> >>>> However, building the release archives failed with two errors: >>>> >>>> vbtkit: >>>> new source -> compiling VBTKitResources.m3 >>>> "..\src\lego\VBTKitResources.m3", line 10: unable to find interface >>>> (VBTKitBundle) >>>> 1 error encountered >>>> >>>> and >>>> >>>> errors during build-all; some packages will be missing >>>> m3-win/import-libs/NT386/.M3SHIP seems to be broken: >>>> make_dir("c:/tmp/cm3/lib") >>>> install_file("wsock32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("advapi32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("opengl32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("netapi32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("comctl32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("user32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("comdlg32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("kernel32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("winspool.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("glu32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("gdi32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("odbc32.lib", "c:/tmp/cm3/lib", "0775") >>>> >>>> (wrong shippind destination, already reported) >>>> >>>> I suggest we rather concentrate on these and build the Windows >>>> packages manually. >>>> >>>> I'm off to (paid) work again now... > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From wagner at elegosoft.com Thu Aug 27 15:50:56 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 27 Aug 2009 15:50:56 +0200 Subject: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems In-Reply-To: References: <20090826142644.r6yabwff5wc84cgg@mail.elegosoft.com> <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> <20090827142201.qim3orxd4488ssss@mail.elegosoft.com> Message-ID: <20090827155056.7tsrrlb0qo8c0sc4@mail.elegosoft.com> Quoting Jay K : > > ps: It doesn't take CVSNT to cause this, but the workaround of > building import-libs up front w/o noresolve. > I assume you were missing m3bundle, as consistently build ok here in > the birch VM and on my machine. Ah, so we should probably use the unresolve switch for all packages in upgrade, too? Olaf > - Jay > > > ---------------------------------------- >> Date: Thu, 27 Aug 2009 14:22:01 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] RC3 build problems, was: RE: caltech-parser >> NT386 Hudson problems >> >> Quoting Jay K : >> >>> My current theory is the unresolve problem is due to that wierd >>> initial build of import-libs in the Hudson task, which was related >>> to the line endings problem, which was related to using CVSNT >>> instead of Cygwin cvs. >> >> Hm, I don't think so, as is happend in my Home-VM, too. >> And there's everything with proper NL endings. >> >> As for m3bundle, that should have been built by do-cm3-core.sh >> long before the build of vbtkit fails. >> >> But I cannot really check until tomorrow evening. >> >> Olaf >> >>> - Jay >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: wagner at elegosoft.com >>>> CC: m3devel at elegosoft.com >>>> Subject: RE: [M3devel] RC3 build problems, was: RE: caltech-parser >>>> NT386 Hudson problems >>>> Date: Thu, 27 Aug 2009 06:09:52 +0000 >>>> >>>> >>>> I'm testing a fix for the VM right now actually. >>>> Once that works I'll look into the Unresolve problem further. I put >>>> in some printing to help diagnose it and possibly a fix. It could >>>> be a slash mixup; the printing will tell us. >>>> The VBT problem is new seeming. I'll look at that too. >>>> Anyone else is welcome to also. >>>> >>>> - Jay >>>> >>>> >>>> ---------------------------------------- >>>>> Date: Thu, 27 Aug 2009 08:06:57 +0200 >>>>> From: wagner at elegosoft.com >>>>> To: jay.krell at cornell.edu >>>>> CC: m3devel at elegosoft.com >>>>> Subject: [M3devel] RC3 build problems, was: RE: caltech-parser >>>>> NT386 Hudson problems >>>>> >>>>> Quoting Jay K : >>>>> >>>>>> Something or some things very wierd here. I'll keep looking into it. >>>>> I'm not sure if we should spend/waste(?) more time in trying to make >>>>> this VM with Windows work. >>>>> >>>>> Last night I reactivated my own qemu-based VM and was able to checkout >>>>> and build some current CM3 stuff. >>>>> >>>>> CVS behaves correctly there, and no need to adapt any of the shell >>>>> scripts at all. It's agonizingly slow though. And it has no remote >>>>> access. >>>>> >>>>> However, building the release archives failed with two errors: >>>>> >>>>> vbtkit: >>>>> new source -> compiling VBTKitResources.m3 >>>>> "..\src\lego\VBTKitResources.m3", line 10: unable to find interface >>>>> (VBTKitBundle) >>>>> 1 error encountered >>>>> >>>>> and >>>>> >>>>> errors during build-all; some packages will be missing >>>>> m3-win/import-libs/NT386/.M3SHIP seems to be broken: >>>>> make_dir("c:/tmp/cm3/lib") >>>>> install_file("wsock32.lib", "c:/tmp/cm3/lib", "0775") >>>>> install_file("advapi32.lib", "c:/tmp/cm3/lib", "0775") >>>>> install_file("opengl32.lib", "c:/tmp/cm3/lib", "0775") >>>>> install_file("netapi32.lib", "c:/tmp/cm3/lib", "0775") >>>>> install_file("comctl32.lib", "c:/tmp/cm3/lib", "0775") >>>>> install_file("user32.lib", "c:/tmp/cm3/lib", "0775") >>>>> install_file("comdlg32.lib", "c:/tmp/cm3/lib", "0775") >>>>> install_file("kernel32.lib", "c:/tmp/cm3/lib", "0775") >>>>> install_file("winspool.lib", "c:/tmp/cm3/lib", "0775") >>>>> install_file("glu32.lib", "c:/tmp/cm3/lib", "0775") >>>>> install_file("gdi32.lib", "c:/tmp/cm3/lib", "0775") >>>>> install_file("odbc32.lib", "c:/tmp/cm3/lib", "0775") >>>>> >>>>> (wrong shippind destination, already reported) >>>>> >>>>> I suggest we rather concentrate on these and build the Windows >>>>> packages manually. >>>>> >>>>> I'm off to (paid) work again now... >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Thu Aug 27 16:17:43 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 27 Aug 2009 16:17:43 +0200 Subject: [M3devel] m3gdb build error in RC3 Message-ID: <20090827161743.mkz8qhp7lco88og8@mail.elegosoft.com> I just found this in Hudson for AMD64_LINUX: http://hudson.modula3.com:8080/view/AMD64_LINUX/job/cm3-test-all-pkgs-AMD64_LINUX/lastBuild/testReport/(root)/CM3%20package%20build%20status/m3_sys_m3gdb/ I've created ticket #1067 for it. Perhaps a wrong/incomplete merge of changes from the main trunk? (I may be the culprit myself, though I'm sure I remember to have compiled m3gdb after merging some changes some days ago.) @Rodney, did you get the account information for trac I sent you? I took the liberty to assign the new ticket to you, too :-) #1058 is not closed yet, too, though you had fixed that. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Thu Aug 27 16:20:11 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 27 Aug 2009 10:20:11 -0400 Subject: [M3devel] small design problem in ButtonVBT? In-Reply-To: <20090827141741.9g1u2vrgfgokkksg@mail.elegosoft.com> References: <20090331145127.GB9624@topoi.pooq.com> <20090401120347.x8cneize8oscg44o@mail.elegosoft.com> <20090826002606.GB16386@topoi.pooq.com> <20090827141741.9g1u2vrgfgokkksg@mail.elegosoft.com> Message-ID: <88690174-5B88-442C-816C-4CACBCB2CDEF@cs.purdue.edu> I'll do it. On 27 Aug 2009, at 08:17, Olaf Wagner wrote: > Though I promised to do it, I have lost sight of this task while > trying to build some RC3 archives on Windows. As I'm not at home this > evening, can somebody else please commit Hendrik's extension? > > Is this something we should should have in the release branch, too? > Probably not necessary? > > Olaf > > Quoting hendrik at topoi.pooq.com: > >> On Wed, Apr 01, 2009 at 12:03:47PM +0200, Olaf Wagner wrote: >>> Quoting hendrik at topoi.pooq.com: >>> >>> >The BottonVBT contains an action, which is a procedure rather >>> than a >>> >method. b This makes it awkward to subclass ButtonVBT becaue the >>> action >>> >will still expect its first parameter to be a ButtonVBT instead of >>> >belonging to the subclass, and an explicit downcast of some sort >>> will be >>> >needed to acess the subclass's members. >>> > >>> >The Trestle manual says this was a deliberate decision: >>> > >>> >: The action procedure is a field rather than a method in order >>> to allow >>> >: buttons with different action procedures to share their method >>> suites. >>> > >>> >I, however, find it massively inconvenient because it mans I have >>> to >>> >resort to downcasting or the very kludgey VBT.GetProp to access >>> what >>> >should be just there. I'd rather the action procedure was a >>> method. >>> > >>> >But it should be possible to have the best of both worlds. Have an >>> >action2 (better name wanted here) method that is available for >>> >overriding, and by default calls the procedure in the existing >>> action. >>> >field. That action2 method wounl then be called by Trestle >>> wherever >>> >action is now called. >>> > >>> >Does anyone see problems with this? >>> >>> Sounds fine to me offhand. You should test your extensions with >>> some of the existing larger applications, like mentor and Juno-2, >>> of course. >> >> OK. Here's the patch. Would it be possible for someone to check it >> in >> for me? >> >> mentor runs fine with this change; I watched it animate a heap-sort. >> >> I have no idea what Juno is supposed to do, but it did respond to >> button-pushes. >> >> >> hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ cvs diff >> cvs diff: Diffing . >> Index: ButtonVBT.i3 >> =================================================================== >> RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.i3,v >> retrieving revision 1.2 >> diff -r1.2 ButtonVBT.i3 >> 39a40 >>> act(READONLY cd: VBT.MouseRec); >> Index: ButtonVBT.m3 >> =================================================================== >> RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.m3,v >> retrieving revision 1.2 >> diff -r1.2 ButtonVBT.m3 >> 28c28,29 >> < init := Be >> --- >>> init := Be; >>> act := act >> 46a48,52 >>> PROCEDURE act(v : T; READONLY cd: VBT.MouseRec) = >>> BEGIN >>> v.action(v, cd); >>> END act; >>> >> 59c65 >> < v.action(v, cd); >> --- >>> v.act(cd); >> hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ >> >> -- hendrik >> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Aug 27 21:15:41 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 27 Aug 2009 15:15:41 -0400 Subject: [M3devel] small design problem in ButtonVBT? In-Reply-To: <20090827141741.9g1u2vrgfgokkksg@mail.elegosoft.com> References: <20090331145127.GB9624@topoi.pooq.com> <20090401120347.x8cneize8oscg44o@mail.elegosoft.com> <20090826002606.GB16386@topoi.pooq.com> <20090827141741.9g1u2vrgfgokkksg@mail.elegosoft.com> Message-ID: I am nervous about having the two alternative entries to the action procedure that other code might not be aware of. Yes, you've modified the default mouse method to call the action method instead of the procedure, but what about other places where the mouse method has been overridden. If you want to be smart about it in your own code you can simply invert your suggestion and do the following: TYPE T = ButtonVBT.T OBJECT METHODS action(cd: VBT.MouseRec) := Action; PROCEDURE Action(v: T; cd: VBT.MouseRec) = ... PROCEDURE ActionProc(v: ButtonVBT.T; cd: VBT.MouseRec) = BEGIN NARROW(v, T).action(cd); END ActionProc; and initialize your T thingy with ButtonVBT.New(..., action := ActionProc; ...) Then in your code you can go ahead and override the action method to your hearts content. Am I just being paranoid? On 27 Aug 2009, at 08:17, Olaf Wagner wrote: > Though I promised to do it, I have lost sight of this task while > trying to build some RC3 archives on Windows. As I'm not at home this > evening, can somebody else please commit Hendrik's extension? > > Is this something we should should have in the release branch, too? > Probably not necessary? > > Olaf > > Quoting hendrik at topoi.pooq.com: > >> On Wed, Apr 01, 2009 at 12:03:47PM +0200, Olaf Wagner wrote: >>> Quoting hendrik at topoi.pooq.com: >>> >>> >The BottonVBT contains an action, which is a procedure rather >>> than a >>> >method. b This makes it awkward to subclass ButtonVBT becaue the >>> action >>> >will still expect its first parameter to be a ButtonVBT instead of >>> >belonging to the subclass, and an explicit downcast of some sort >>> will be >>> >needed to acess the subclass's members. >>> > >>> >The Trestle manual says this was a deliberate decision: >>> > >>> >: The action procedure is a field rather than a method in order >>> to allow >>> >: buttons with different action procedures to share their method >>> suites. >>> > >>> >I, however, find it massively inconvenient because it mans I have >>> to >>> >resort to downcasting or the very kludgey VBT.GetProp to access >>> what >>> >should be just there. I'd rather the action procedure was a >>> method. >>> > >>> >But it should be possible to have the best of both worlds. Have an >>> >action2 (better name wanted here) method that is available for >>> >overriding, and by default calls the procedure in the existing >>> action. >>> >field. That action2 method wounl then be called by Trestle >>> wherever >>> >action is now called. >>> > >>> >Does anyone see problems with this? >>> >>> Sounds fine to me offhand. You should test your extensions with >>> some of the existing larger applications, like mentor and Juno-2, >>> of course. >> >> OK. Here's the patch. Would it be possible for someone to check it >> in >> for me? >> >> mentor runs fine with this change; I watched it animate a heap-sort. >> >> I have no idea what Juno is supposed to do, but it did respond to >> button-pushes. >> >> >> hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ cvs diff >> cvs diff: Diffing . >> Index: ButtonVBT.i3 >> =================================================================== >> RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.i3,v >> retrieving revision 1.2 >> diff -r1.2 ButtonVBT.i3 >> 39a40 >>> act(READONLY cd: VBT.MouseRec); >> Index: ButtonVBT.m3 >> =================================================================== >> RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.m3,v >> retrieving revision 1.2 >> diff -r1.2 ButtonVBT.m3 >> 28c28,29 >> < init := Be >> --- >>> init := Be; >>> act := act >> 46a48,52 >>> PROCEDURE act(v : T; READONLY cd: VBT.MouseRec) = >>> BEGIN >>> v.action(v, cd); >>> END act; >>> >> 59c65 >> < v.action(v, cd); >> --- >>> v.act(cd); >> hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ >> >> -- hendrik >> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From rodney.m.bates at cox.net Thu Aug 27 23:37:12 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Thu, 27 Aug 2009 16:37:12 -0500 Subject: [M3devel] m3gdb build error in RC3 In-Reply-To: <20090827161743.mkz8qhp7lco88og8@mail.elegosoft.com> References: <20090827161743.mkz8qhp7lco88og8@mail.elegosoft.com> Message-ID: <4A96FC88.3030006@cox.net> Olaf Wagner wrote: > I just found this in Hudson for AMD64_LINUX: > > http://hudson.modula3.com:8080/view/AMD64_LINUX/job/cm3-test-all-pkgs-AMD64_LINUX/lastBuild/testReport/(root)/CM3%20package%20build%20status/m3_sys_m3gdb/ > > > I've created ticket #1067 for it. > > Perhaps a wrong/incomplete merge of changes from the main trunk? > (I may be the culprit myself, though I'm sure I remember to have compiled > m3gdb after merging some changes some days ago.) > > @Rodney, did you get the account information for trac I sent you? > I took the liberty to assign the new ticket to you, too :-) > #1058 is not closed yet, too, though you had fixed that. I got the account info and figured out how to close it. My own responsivness is bit erratic these days, as I am often away from internet access for 4 or 5 days at a time. > > Olaf From jay.krell at cornell.edu Fri Aug 28 03:30:47 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 28 Aug 2009 01:30:47 +0000 Subject: [M3devel] m3gdb build error in RC3 In-Reply-To: <4A96FC88.3030006@cox.net> References: <20090827161743.mkz8qhp7lco88og8@mail.elegosoft.com> <4A96FC88.3030006@cox.net> Message-ID: I'll fix this shortly. We can't use stdbool.h. It #errors on Solaris. And we can't use bool either. It conflicts on Linux. I'll change to m3bool, m3true, m3false. - Jay ---------------------------------------- > Date: Thu, 27 Aug 2009 16:37:12 -0500 > From: rodney.m.bates at cox.net > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] m3gdb build error in RC3 > > Olaf Wagner wrote: >> I just found this in Hudson for AMD64_LINUX: >> >> http://hudson.modula3.com:8080/view/AMD64_LINUX/job/cm3-test-all-pkgs-AMD64_LINUX/lastBuild/testReport/(root)/CM3%20package%20build%20status/m3_sys_m3gdb/ >> >> >> I've created ticket #1067 for it. >> >> Perhaps a wrong/incomplete merge of changes from the main trunk? >> (I may be the culprit myself, though I'm sure I remember to have compiled >> m3gdb after merging some changes some days ago.) >> >> @Rodney, did you get the account information for trac I sent you? >> I took the liberty to assign the new ticket to you, too :-) >> #1058 is not closed yet, too, though you had fixed that. > I got the account info and figured out how to close it. My own > responsivness > is bit erratic these days, as I am often away from internet access > for 4 or 5 days at a time. >> >> Olaf > From jay.krell at cornell.edu Fri Aug 28 04:53:47 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 28 Aug 2009 02:53:47 +0000 Subject: [M3devel] CM3 on windows In-Reply-To: <20090828020144.B5E7C1A209A@async.async.caltech.edu> References: <20090828020144.B5E7C1A209A@async.async.caltech.edu> Message-ID: I fixed the access on 5.8.2. Try that? I can poke around.. As I recall 5.8.1 used VC 8.0 and 5.8.2 used 9.0. If that helps. - Jay ---------------------------------------- > To: m3devel at elegosoft.com; jay.krell at cornell.edu > CC: mika at async.caltech.edu > Subject: CM3 on windows > Date: Thu, 27 Aug 2009 19:01:44 -0700 > From: mika at async.async.caltech.edu > > Hi m3devel, > > Not sure if my earlier message today went anywhere. I never saw it on > the list. > > I'd like to try running CM3 on Windows 2000, so I've downloaded > > http://www.opencm3.com/uploaded-archives/cm3-std-NT386-d5.8.1.msi > > (5.8.2 didn't work---no access). > > Having installed it as well as I can figure, following the directions at > > http://www.opencm3.com/installation-windows.html > > I don't really seem to get all the way. Compiling in the CMD window fails > at a link (can't find winspool.lib), and the binaries have problems. > > Funnily enough, WebScape seems to work (as well or poorly as anywhere else), > but mentor and Juno both fail miserably: > > > mika at scruff /cygdrive/c/cm3/bin > $ ./mentor > > > *** > *** runtime error: > *** Attempt to reference an illegal memory location. > *** pc = 0x1061634 = GetAttributes + 0x179 in ..\src\lego\WIN32\ScrollerVBTCl > ass.m3 > *** > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x30af668 0x6a6e4d SystemError + 0x66 in ..\src\runtime\NT386\RTSignal.m3 > 0x30af70c 0x1061634 GetAttributes + 0x179 in ..\src\lego\WIN32\ScrollerVBTClas > s.m3 > 0x30af7e4 0x10993d8 AddView + 0x101e(!) in ..\src\lego\ViewportVBT.m3 > 0x30af830 0x109743e Init + 0x30e in ..\src\lego\ViewportVBT.m3 > 0x30af950 0x1004ee0 pViewport + 0x512 in ..\src\FormsVBT.m3 > 0x30af9b0 0xff33df Item + 0x48b in ..\src\FormsVBT.m3 > 0x30af9dc 0x1010f66 OneChild + 0xf8 in ..\src\FormsVBT.m3 > 0x30afae4 0xff7448 pShape + 0x19c in ..\src\FormsVBT.m3 > 0x30afb44 0xff33df Item + 0x48b in ..\src\FormsVBT.m3 > 0x30afb70 0x1010f66 OneChild + 0xf8 in ..\src\FormsVBT.m3 > ......... ......... ... more frames ... > > mika at scruff /cygdrive/c/cm3/bin > $ ./Juno > > > *** > *** runtime error: > *** failed. > *** file "..\src\winvbt\WinContext.m3", line 165 > *** > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x1b6f854 0xea1e03 PushPixmap + 0x4cb in ..\src\winvbt\WinContext.m3 > 0x1b6f91c 0xeb10c7 PixmapCom + 0x9ed in ..\src\winvbt\WinPaint.m3 > 0x1b6fd78 0xeaedaf PaintBatch + 0x25f in ..\src\winvbt\WinPaint.m3 > 0x1b6fde4 0xea91f3 PaintBatchVBT + 0x13f in ..\src\winvbt\WinTrestle.m3 > 0x1b6fe2c 0xea7919 WindowProc + 0x763 in ..\src\winvbt\WinTrestle.m3 > 0x1b6fe4c 0x77e3a454 > 0x1b6fed8 0x77e14605 > 0x1b6ff30 0x77e15b77 > 0x1b6ff88 0x4fb015 RunThread + 0x234 in ..\src\thread\WIN32\ThreadWin32.m3 > 0x1b6ffb4 0x4fad57 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3 > ......... ......... ... more frames ... > > mika at scruff /cygdrive/c/cm3/bin > $ > > This is running from the cygwin shell but it doesn't do anything different > from CMD... > > Should I not expect to be able to get this to work? > > Mika From hendrik at topoi.pooq.com Fri Aug 28 05:17:23 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 27 Aug 2009 23:17:23 -0400 Subject: [M3devel] small design problem in ButtonVBT? In-Reply-To: References: <20090331145127.GB9624@topoi.pooq.com> <20090401120347.x8cneize8oscg44o@mail.elegosoft.com> <20090826002606.GB16386@topoi.pooq.com> <20090827141741.9g1u2vrgfgokkksg@mail.elegosoft.com> Message-ID: <20090828031722.GB22883@topoi.pooq.com> On Thu, Aug 27, 2009 at 03:15:41PM -0400, Tony Hosking wrote: > I am nervous about having the two alternative entries to the action > procedure that other code might not be aware of. Yes, you've modified > the default mouse method to call the action method instead of the > procedure, but what about other places where the mouse method has been > overridden. > > If you want to be smart about it in your own code you can simply > invert your suggestion and do the following: > > TYPE T = ButtonVBT.T OBJECT > METHODS action(cd: VBT.MouseRec) := Action; > > PROCEDURE Action(v: T; cd: VBT.MouseRec) = ... > > PROCEDURE ActionProc(v: ButtonVBT.T; cd: VBT.MouseRec) = > BEGIN > NARROW(v, T).action(cd); > END ActionProc; > > and initialize your T thingy with ButtonVBT.New(..., action := > ActionProc; ...) > > Then in your code you can go ahead and override the action method to > your hearts content. This kind of thing would work. But, like the existing semantics of ButtonVBT, it seems to be fighting the language instead of working with it. I'd be happiest to get rid of the action variable altogether, but that would be a massively incompatible change, and would require change to a lot of existing code. What I proposed is compatible with existing code, and also has the advantage that someone who subclasses ButtonVBT.T and overrides act can completely ignore the action variable altogether. You say > and initialize your T thingy with ButtonVBT.New(..., action := > ActionProc; ...) But that requires every object I make of type T or any sibclass to be explicitly initialised with ActionProc, certainly a nuisance, and certainly error-prone. The inelegance I see with my approach is that there are two mechanisms for specifying the action to be taken. Either will work without the programmer paying any attention to the other, but if you use both, one will override the other. This is not a problem with legacy software. I'll have to come up with some documentation that makes this clear. It's the inelegance that comes from backward compatibility, and I think my solution is less inelegant, and easier to use, than yours. Yours, however, involves no change in existing code. > > Am I just being paranoid? No. Perhaps just paranoid about different things. I had hoped for someone to come up with a solid technical reason for the action variable. The original designers were clever people, and I'd *still* like to know why they thought it was a good idea. It's awkward and error-prone to use, and they had to use the PutProp/GetProp kludge just to approximate what the language provided for free with inheritance. I'm tempted to go over the entire code-base and change the buttons to use act instead of action, but I have to admit I'm not tempted enough to actually do it... -- hendrik > On 27 Aug 2009, at 08:17, Olaf Wagner wrote: > > >Though I promised to do it, I have lost sight of this task while > >trying to build some RC3 archives on Windows. As I'm not at home this > >evening, can somebody else please commit Hendrik's extension? > > > >Is this something we should should have in the release branch, too? > >Probably not necessary? > > > >Olaf > > > >Quoting hendrik at topoi.pooq.com: > > > >>On Wed, Apr 01, 2009 at 12:03:47PM +0200, Olaf Wagner wrote: > >>>Quoting hendrik at topoi.pooq.com: > >>> > >>>>The BottonVBT contains an action, which is a procedure rather > >>>than a > >>>>method. b This makes it awkward to subclass ButtonVBT becaue the > >>>action > >>>>will still expect its first parameter to be a ButtonVBT instead of > >>>>belonging to the subclass, and an explicit downcast of some sort > >>>will be > >>>>needed to acess the subclass's members. > >>>> > >>>>The Trestle manual says this was a deliberate decision: > >>>> > >>>>: The action procedure is a field rather than a method in order > >>>to allow > >>>>: buttons with different action procedures to share their method > >>>suites. > >>>> > >>>>I, however, find it massively inconvenient because it mans I have > >>>to > >>>>resort to downcasting or the very kludgey VBT.GetProp to access > >>>what > >>>>should be just there. I'd rather the action procedure was a > >>>method. > >>>> > >>>>But it should be possible to have the best of both worlds. Have an > >>>>action2 (better name wanted here) method that is available for > >>>>overriding, and by default calls the procedure in the existing > >>>action. > >>>>field. That action2 method wounl then be called by Trestle > >>>wherever > >>>>action is now called. > >>>> > >>>>Does anyone see problems with this? > >>> > >>>Sounds fine to me offhand. You should test your extensions with > >>>some of the existing larger applications, like mentor and Juno-2, > >>>of course. > >> > >>OK. Here's the patch. Would it be possible for someone to check it > >>in > >>for me? > >> > >>mentor runs fine with this change; I watched it animate a heap-sort. > >> > >>I have no idea what Juno is supposed to do, but it did respond to > >>button-pushes. > >> > >> > >>hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ cvs diff > >>cvs diff: Diffing . > >>Index: ButtonVBT.i3 > >>=================================================================== > >>RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.i3,v > >>retrieving revision 1.2 > >>diff -r1.2 ButtonVBT.i3 > >>39a40 > >>> act(READONLY cd: VBT.MouseRec); > >>Index: ButtonVBT.m3 > >>=================================================================== > >>RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.m3,v > >>retrieving revision 1.2 > >>diff -r1.2 ButtonVBT.m3 > >>28c28,29 > >>< init := Be > >>--- > >>> init := Be; > >>> act := act > >>46a48,52 > >>>PROCEDURE act(v : T; READONLY cd: VBT.MouseRec) = > >>> BEGIN > >>> v.action(v, cd); > >>> END act; > >>> > >>59c65 > >>< v.action(v, cd); > >>--- > >>> v.act(cd); > >>hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ > >> > >>-- hendrik > >> > > > > > > > >-- > >Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > >Germany > >phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > >45 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > >Berlin > >Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > >DE163214194 > > > From jay.krell at cornell.edu Fri Aug 28 05:28:32 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 28 Aug 2009 03:28:32 +0000 Subject: [M3devel] small design problem in ButtonVBT? In-Reply-To: <20090828031722.GB22883@topoi.pooq.com> References: <20090331145127.GB9624@topoi.pooq.com> <20090401120347.x8cneize8oscg44o@mail.elegosoft.com> <20090826002606.GB16386@topoi.pooq.com> <20090827141741.9g1u2vrgfgokkksg@mail.elegosoft.com> <20090828031722.GB22883@topoi.pooq.com> Message-ID: I think I know the reason it is this way. It is very common to override action and nothing else. It is "inconvenient" to derive a new type, just to change one function. - Jay ---------------------------------------- > Date: Thu, 27 Aug 2009 23:17:23 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] small design problem in ButtonVBT? > > On Thu, Aug 27, 2009 at 03:15:41PM -0400, Tony Hosking wrote: >> I am nervous about having the two alternative entries to the action >> procedure that other code might not be aware of. Yes, you've modified >> the default mouse method to call the action method instead of the >> procedure, but what about other places where the mouse method has been >> overridden. >> >> If you want to be smart about it in your own code you can simply >> invert your suggestion and do the following: >> >> TYPE T = ButtonVBT.T OBJECT >> METHODS action(cd: VBT.MouseRec) := Action; >> >> PROCEDURE Action(v: T; cd: VBT.MouseRec) = ... >> >> PROCEDURE ActionProc(v: ButtonVBT.T; cd: VBT.MouseRec) = >> BEGIN >> NARROW(v, T).action(cd); >> END ActionProc; >> >> and initialize your T thingy with ButtonVBT.New(..., action := >> ActionProc; ...) >> >> Then in your code you can go ahead and override the action method to >> your hearts content. > > This kind of thing would work. But, like the existing semantics of > ButtonVBT, it seems to be fighting the language instead of working with > it. I'd be happiest to get rid of the action variable altogether, but > that would be a massively incompatible change, and would require change > to a lot of existing code. What I proposed is compatible with existing > code, and also has the advantage that someone who subclasses ButtonVBT.T > and overrides act can completely ignore the action variable altogether. > > You say > >> and initialize your T thingy with ButtonVBT.New(..., action := >> ActionProc; ...) > > But that requires every object I make of type T or any sibclass to be > explicitly initialised with ActionProc, certainly a nuisance, and > certainly error-prone. > > The inelegance I see with my approach is that there are two mechanisms > for specifying the action to be taken. Either will work without the > programmer paying any attention to the other, but if you use both, one > will override the other. This is not a problem with legacy software. > I'll have to come up with some documentation that makes this clear. > It's the inelegance that comes from backward compatibility, and I think > my solution is less inelegant, and easier to use, than yours. Yours, > however, involves no change in existing code. > >> >> Am I just being paranoid? > > No. Perhaps just paranoid about different things. > > I had hoped for someone to come up with a solid technical reason for the > action variable. The original designers were clever people, and I'd > *still* like to know why they thought it was a good idea. It's awkward > and error-prone to use, and they had to use the PutProp/GetProp kludge > just to approximate what the language provided for free with inheritance. > > I'm tempted to go over the entire code-base and change the buttons to > use act instead of action, but I have to admit I'm not tempted enough to > actually do it... > > -- hendrik > >> On 27 Aug 2009, at 08:17, Olaf Wagner wrote: >> >>>Though I promised to do it, I have lost sight of this task while >>>trying to build some RC3 archives on Windows. As I'm not at home this >>>evening, can somebody else please commit Hendrik's extension? >>> >>>Is this something we should should have in the release branch, too? >>>Probably not necessary? >>> >>>Olaf >>> >>>Quoting hendrik at topoi.pooq.com: >>> >>>>On Wed, Apr 01, 2009 at 12:03:47PM +0200, Olaf Wagner wrote: >>>>>Quoting hendrik at topoi.pooq.com: >>>>> >>>>>>The BottonVBT contains an action, which is a procedure rather >>>>>than a >>>>>>method. b This makes it awkward to subclass ButtonVBT becaue the >>>>>action >>>>>>will still expect its first parameter to be a ButtonVBT instead of >>>>>>belonging to the subclass, and an explicit downcast of some sort >>>>>will be >>>>>>needed to acess the subclass's members. >>>>>> >>>>>>The Trestle manual says this was a deliberate decision: >>>>>> >>>>>>: The action procedure is a field rather than a method in order >>>>>to allow >>>>>>: buttons with different action procedures to share their method >>>>>suites. >>>>>> >>>>>>I, however, find it massively inconvenient because it mans I have >>>>>to >>>>>>resort to downcasting or the very kludgey VBT.GetProp to access >>>>>what >>>>>>should be just there. I'd rather the action procedure was a >>>>>method. >>>>>> >>>>>>But it should be possible to have the best of both worlds. Have an >>>>>>action2 (better name wanted here) method that is available for >>>>>>overriding, and by default calls the procedure in the existing >>>>>action. >>>>>>field. That action2 method wounl then be called by Trestle >>>>>wherever >>>>>>action is now called. >>>>>> >>>>>>Does anyone see problems with this? >>>>> >>>>>Sounds fine to me offhand. You should test your extensions with >>>>>some of the existing larger applications, like mentor and Juno-2, >>>>>of course. >>>> >>>>OK. Here's the patch. Would it be possible for someone to check it >>>>in >>>>for me? >>>> >>>>mentor runs fine with this change; I watched it animate a heap-sort. >>>> >>>>I have no idea what Juno is supposed to do, but it did respond to >>>>button-pushes. >>>> >>>> >>>>hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ cvs diff >>>>cvs diff: Diffing . >>>>Index: ButtonVBT.i3 >>>>=================================================================== >>>>RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.i3,v >>>>retrieving revision 1.2 >>>>diff -r1.2 ButtonVBT.i3 >>>>39a40 >>>>> act(READONLY cd: VBT.MouseRec); >>>>Index: ButtonVBT.m3 >>>>=================================================================== >>>>RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.m3,v >>>>retrieving revision 1.2 >>>>diff -r1.2 ButtonVBT.m3 >>>>28c28,29 >>>>< init := Be >>>>--- >>>>> init := Be; >>>>> act := act >>>>46a48,52 >>>>>PROCEDURE act(v : T; READONLY cd: VBT.MouseRec) = >>>>> BEGIN >>>>> v.action(v, cd); >>>>> END act; >>>>> >>>>59c65 >>>>< v.action(v, cd); >>>>--- >>>>> v.act(cd); >>>>hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ >>>> >>>>-- hendrik >>>> >>> >>> >>> >>>-- >>>Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>>Germany >>>phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>>Berlin >>>Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>DE163214194 >>> >> From hosking at cs.purdue.edu Fri Aug 28 05:26:23 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 27 Aug 2009 23:26:23 -0400 Subject: [M3devel] small design problem in ButtonVBT? In-Reply-To: <20090828031722.GB22883@topoi.pooq.com> References: <20090331145127.GB9624@topoi.pooq.com> <20090401120347.x8cneize8oscg44o@mail.elegosoft.com> <20090826002606.GB16386@topoi.pooq.com> <20090827141741.9g1u2vrgfgokkksg@mail.elegosoft.com> <20090828031722.GB22883@topoi.pooq.com> Message-ID: <433A59EF-4617-424C-8355-893C104F02D4@cs.purdue.edu> I suspect they were concerned about space bloat, if every different kind of button ends up with a separate method suite (because it overrides action). The expectation was that most buttons would inherit the standard behavior, and simply provide a tailored action procedure. It is elegant insofar as it avoids copying the default method suite entries for every different kind of button, but as you say kludgey in practice. If you go ahead and replace the proc with the method everywhere then you will increase the memory footprint. On 27 Aug 2009, at 23:17, hendrik at topoi.pooq.com wrote: > On Thu, Aug 27, 2009 at 03:15:41PM -0400, Tony Hosking wrote: >> I am nervous about having the two alternative entries to the action >> procedure that other code might not be aware of. Yes, you've >> modified >> the default mouse method to call the action method instead of the >> procedure, but what about other places where the mouse method has >> been >> overridden. >> >> If you want to be smart about it in your own code you can simply >> invert your suggestion and do the following: >> >> TYPE T = ButtonVBT.T OBJECT >> METHODS action(cd: VBT.MouseRec) := Action; >> >> PROCEDURE Action(v: T; cd: VBT.MouseRec) = ... >> >> PROCEDURE ActionProc(v: ButtonVBT.T; cd: VBT.MouseRec) = >> BEGIN >> NARROW(v, T).action(cd); >> END ActionProc; >> >> and initialize your T thingy with ButtonVBT.New(..., action := >> ActionProc; ...) >> >> Then in your code you can go ahead and override the action method to >> your hearts content. > > This kind of thing would work. But, like the existing semantics of > ButtonVBT, it seems to be fighting the language instead of working > with > it. I'd be happiest to get rid of the action variable altogether, but > that would be a massively incompatible change, and would require > change > to a lot of existing code. What I proposed is compatible with > existing > code, and also has the advantage that someone who subclasses > ButtonVBT.T > and overrides act can completely ignore the action variable > altogether. > > You say > >> and initialize your T thingy with ButtonVBT.New(..., action := >> ActionProc; ...) > > But that requires every object I make of type T or any sibclass to be > explicitly initialised with ActionProc, certainly a nuisance, and > certainly error-prone. > > The inelegance I see with my approach is that there are two mechanisms > for specifying the action to be taken. Either will work without the > programmer paying any attention to the other, but if you use both, one > will override the other. This is not a problem with legacy software. > I'll have to come up with some documentation that makes this clear. > It's the inelegance that comes from backward compatibility, and I > think > my solution is less inelegant, and easier to use, than yours. Yours, > however, involves no change in existing code. > >> >> Am I just being paranoid? > > No. Perhaps just paranoid about different things. > > I had hoped for someone to come up with a solid technical reason for > the > action variable. The original designers were clever people, and I'd > *still* like to know why they thought it was a good idea. It's > awkward > and error-prone to use, and they had to use the PutProp/GetProp kludge > just to approximate what the language provided for free with > inheritance. > > I'm tempted to go over the entire code-base and change the buttons to > use act instead of action, but I have to admit I'm not tempted > enough to > actually do it... > > -- hendrik > >> On 27 Aug 2009, at 08:17, Olaf Wagner wrote: >> >>> Though I promised to do it, I have lost sight of this task while >>> trying to build some RC3 archives on Windows. As I'm not at home >>> this >>> evening, can somebody else please commit Hendrik's extension? >>> >>> Is this something we should should have in the release branch, too? >>> Probably not necessary? >>> >>> Olaf >>> >>> Quoting hendrik at topoi.pooq.com: >>> >>>> On Wed, Apr 01, 2009 at 12:03:47PM +0200, Olaf Wagner wrote: >>>>> Quoting hendrik at topoi.pooq.com: >>>>> >>>>>> The BottonVBT contains an action, which is a procedure rather >>>>> than a >>>>>> method. b This makes it awkward to subclass ButtonVBT becaue the >>>>> action >>>>>> will still expect its first parameter to be a ButtonVBT instead >>>>>> of >>>>>> belonging to the subclass, and an explicit downcast of some sort >>>>> will be >>>>>> needed to acess the subclass's members. >>>>>> >>>>>> The Trestle manual says this was a deliberate decision: >>>>>> >>>>>> : The action procedure is a field rather than a method in order >>>>> to allow >>>>>> : buttons with different action procedures to share their method >>>>> suites. >>>>>> >>>>>> I, however, find it massively inconvenient because it mans I have >>>>> to >>>>>> resort to downcasting or the very kludgey VBT.GetProp to access >>>>> what >>>>>> should be just there. I'd rather the action procedure was a >>>>> method. >>>>>> >>>>>> But it should be possible to have the best of both worlds. >>>>>> Have an >>>>>> action2 (better name wanted here) method that is available for >>>>>> overriding, and by default calls the procedure in the existing >>>>> action. >>>>>> field. That action2 method wounl then be called by Trestle >>>>> wherever >>>>>> action is now called. >>>>>> >>>>>> Does anyone see problems with this? >>>>> >>>>> Sounds fine to me offhand. You should test your extensions with >>>>> some of the existing larger applications, like mentor and Juno-2, >>>>> of course. >>>> >>>> OK. Here's the patch. Would it be possible for someone to check it >>>> in >>>> for me? >>>> >>>> mentor runs fine with this change; I watched it animate a heap- >>>> sort. >>>> >>>> I have no idea what Juno is supposed to do, but it did respond to >>>> button-pushes. >>>> >>>> >>>> hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ cvs diff >>>> cvs diff: Diffing . >>>> Index: ButtonVBT.i3 >>>> =================================================================== >>>> RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.i3,v >>>> retrieving revision 1.2 >>>> diff -r1.2 ButtonVBT.i3 >>>> 39a40 >>>>> act(READONLY cd: VBT.MouseRec); >>>> Index: ButtonVBT.m3 >>>> =================================================================== >>>> RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.m3,v >>>> retrieving revision 1.2 >>>> diff -r1.2 ButtonVBT.m3 >>>> 28c28,29 >>>> < init := Be >>>> --- >>>>> init := Be; >>>>> act := act >>>> 46a48,52 >>>>> PROCEDURE act(v : T; READONLY cd: VBT.MouseRec) = >>>>> BEGIN >>>>> v.action(v, cd); >>>>> END act; >>>>> >>>> 59c65 >>>> < v.action(v, cd); >>>> --- >>>>> v.act(cd); >>>> hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ >>>> >>>> -- hendrik >>>> >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>> Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>> 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>> Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Aug 28 05:53:27 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 27 Aug 2009 23:53:27 -0400 Subject: [M3devel] small design problem in ButtonVBT? In-Reply-To: References: <20090331145127.GB9624@topoi.pooq.com> <20090401120347.x8cneize8oscg44o@mail.elegosoft.com> <20090826002606.GB16386@topoi.pooq.com> <20090827141741.9g1u2vrgfgokkksg@mail.elegosoft.com> <20090828031722.GB22883@topoi.pooq.com> Message-ID: <36DAB001-70F3-4C96-B1D5-57E8A7322464@cs.purdue.edu> Right. Plus, overriding copies the entire method suite for the new type. On 27 Aug 2009, at 23:28, Jay K wrote: > > I think I know the reason it is this way. > It is very common to override action and nothing else. > It is "inconvenient" to derive a new type, just to change one > function. > > - Jay > > ---------------------------------------- >> Date: Thu, 27 Aug 2009 23:17:23 -0400 >> From: hendrik at topoi.pooq.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] small design problem in ButtonVBT? >> >> On Thu, Aug 27, 2009 at 03:15:41PM -0400, Tony Hosking wrote: >>> I am nervous about having the two alternative entries to the action >>> procedure that other code might not be aware of. Yes, you've >>> modified >>> the default mouse method to call the action method instead of the >>> procedure, but what about other places where the mouse method has >>> been >>> overridden. >>> >>> If you want to be smart about it in your own code you can simply >>> invert your suggestion and do the following: >>> >>> TYPE T = ButtonVBT.T OBJECT >>> METHODS action(cd: VBT.MouseRec) := Action; >>> >>> PROCEDURE Action(v: T; cd: VBT.MouseRec) = ... >>> >>> PROCEDURE ActionProc(v: ButtonVBT.T; cd: VBT.MouseRec) = >>> BEGIN >>> NARROW(v, T).action(cd); >>> END ActionProc; >>> >>> and initialize your T thingy with ButtonVBT.New(..., action := >>> ActionProc; ...) >>> >>> Then in your code you can go ahead and override the action method to >>> your hearts content. >> >> This kind of thing would work. But, like the existing semantics of >> ButtonVBT, it seems to be fighting the language instead of working >> with >> it. I'd be happiest to get rid of the action variable altogether, but >> that would be a massively incompatible change, and would require >> change >> to a lot of existing code. What I proposed is compatible with >> existing >> code, and also has the advantage that someone who subclasses >> ButtonVBT.T >> and overrides act can completely ignore the action variable >> altogether. >> >> You say >> >>> and initialize your T thingy with ButtonVBT.New(..., action := >>> ActionProc; ...) >> >> But that requires every object I make of type T or any sibclass to be >> explicitly initialised with ActionProc, certainly a nuisance, and >> certainly error-prone. >> >> The inelegance I see with my approach is that there are two >> mechanisms >> for specifying the action to be taken. Either will work without the >> programmer paying any attention to the other, but if you use both, >> one >> will override the other. This is not a problem with legacy software. >> I'll have to come up with some documentation that makes this clear. >> It's the inelegance that comes from backward compatibility, and I >> think >> my solution is less inelegant, and easier to use, than yours. Yours, >> however, involves no change in existing code. >> >>> >>> Am I just being paranoid? >> >> No. Perhaps just paranoid about different things. >> >> I had hoped for someone to come up with a solid technical reason >> for the >> action variable. The original designers were clever people, and I'd >> *still* like to know why they thought it was a good idea. It's >> awkward >> and error-prone to use, and they had to use the PutProp/GetProp >> kludge >> just to approximate what the language provided for free with >> inheritance. >> >> I'm tempted to go over the entire code-base and change the buttons to >> use act instead of action, but I have to admit I'm not tempted >> enough to >> actually do it... >> >> -- hendrik >> >>> On 27 Aug 2009, at 08:17, Olaf Wagner wrote: >>> >>>> Though I promised to do it, I have lost sight of this task while >>>> trying to build some RC3 archives on Windows. As I'm not at home >>>> this >>>> evening, can somebody else please commit Hendrik's extension? >>>> >>>> Is this something we should should have in the release branch, too? >>>> Probably not necessary? >>>> >>>> Olaf >>>> >>>> Quoting hendrik at topoi.pooq.com: >>>> >>>>> On Wed, Apr 01, 2009 at 12:03:47PM +0200, Olaf Wagner wrote: >>>>>> Quoting hendrik at topoi.pooq.com: >>>>>> >>>>>>> The BottonVBT contains an action, which is a procedure rather >>>>>> than a >>>>>>> method. b This makes it awkward to subclass ButtonVBT becaue the >>>>>> action >>>>>>> will still expect its first parameter to be a ButtonVBT >>>>>>> instead of >>>>>>> belonging to the subclass, and an explicit downcast of some sort >>>>>> will be >>>>>>> needed to acess the subclass's members. >>>>>>> >>>>>>> The Trestle manual says this was a deliberate decision: >>>>>>> >>>>>>> : The action procedure is a field rather than a method in order >>>>>> to allow >>>>>>> : buttons with different action procedures to share their method >>>>>> suites. >>>>>>> >>>>>>> I, however, find it massively inconvenient because it mans I >>>>>>> have >>>>>> to >>>>>>> resort to downcasting or the very kludgey VBT.GetProp to access >>>>>> what >>>>>>> should be just there. I'd rather the action procedure was a >>>>>> method. >>>>>>> >>>>>>> But it should be possible to have the best of both worlds. >>>>>>> Have an >>>>>>> action2 (better name wanted here) method that is available for >>>>>>> overriding, and by default calls the procedure in the existing >>>>>> action. >>>>>>> field. That action2 method wounl then be called by Trestle >>>>>> wherever >>>>>>> action is now called. >>>>>>> >>>>>>> Does anyone see problems with this? >>>>>> >>>>>> Sounds fine to me offhand. You should test your extensions with >>>>>> some of the existing larger applications, like mentor and Juno-2, >>>>>> of course. >>>>> >>>>> OK. Here's the patch. Would it be possible for someone to check it >>>>> in >>>>> for me? >>>>> >>>>> mentor runs fine with this change; I watched it animate a heap- >>>>> sort. >>>>> >>>>> I have no idea what Juno is supposed to do, but it did respond to >>>>> button-pushes. >>>>> >>>>> >>>>> hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ cvs diff >>>>> cvs diff: Diffing . >>>>> Index: ButtonVBT.i3 >>>>> = >>>>> ================================================================== >>>>> RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.i3,v >>>>> retrieving revision 1.2 >>>>> diff -r1.2 ButtonVBT.i3 >>>>> 39a40 >>>>>> act(READONLY cd: VBT.MouseRec); >>>>> Index: ButtonVBT.m3 >>>>> = >>>>> ================================================================== >>>>> RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.m3,v >>>>> retrieving revision 1.2 >>>>> diff -r1.2 ButtonVBT.m3 >>>>> 28c28,29 >>>>> < init := Be >>>>> --- >>>>>> init := Be; >>>>>> act := act >>>>> 46a48,52 >>>>>> PROCEDURE act(v : T; READONLY cd: VBT.MouseRec) = >>>>>> BEGIN >>>>>> v.action(v, cd); >>>>>> END act; >>>>>> >>>>> 59c65 >>>>> < v.action(v, cd); >>>>> --- >>>>>> v.act(cd); >>>>> hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ >>>>> >>>>> -- hendrik >>>>> >>>> >>>> >>>> >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>>> Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>> 45 86 95 >>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>>> Berlin >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>> DE163214194 >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Aug 28 06:02:38 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 28 Aug 2009 04:02:38 +0000 Subject: [M3devel] CM3 on windows In-Reply-To: <20090828034057.475DD1A209A@async.async.caltech.edu> References: <20090828020144.B5E7C1A209A@async.async.caltech.edu> <20090828034057.475DD1A209A@async.async.caltech.edu> Message-ID: > Compiling in the CMD window fails>> at a link (can't find winspool.lib)=2C and the binaries have problems Where is it getting kernel32.lib? c:\cm3\lib? %LIB%? What is your compiler/linker? What are the "problems"? - Jay ---------------------------------------- > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: CM3 on windows > Date: Thu, 27 Aug 2009 20:40:57 -0700 > From: mika at async.async.caltech.edu > > Jay K writes: >> >>I fixed the access on 5.8.2. >>Try that? >>I can poke around.. >>=20 >>As I recall 5.8.1 used VC 8.0 and 5.8.2 used 9.0. >>If that helps. > > Well I can try but I don't think 9.0 works on Win2k... > >>=20 >> - Jay >> >> >>---------------------------------------- >>> To: m3devel at elegosoft.com=3B jay.krell at cornell.edu >>> CC: mika at async.caltech.edu >>> Subject: CM3 on windows >>> Date: Thu=2C 27 Aug 2009 19:01:44 -0700 >>> From: mika at async.async.caltech.edu >>> >>> Hi m3devel=2C >>> >>> Not sure if my earlier message today went anywhere. I never saw it on >>> the list. >>> >>> I'd like to try running CM3 on Windows 2000=2C so I've downloaded >>> >>> http://www.opencm3.com/uploaded-archives/cm3-std-NT386-d5.8.1.msi >>> >>> (5.8.2 didn't work---no access). >>> >>> Having installed it as well as I can figure=2C following the directions a= >>t >>> >>> http://www.opencm3.com/installation-windows.html >>> >>> I don't really seem to get all the way. Compiling in the CMD window fails >>> at a link (can't find winspool.lib)=2C and the binaries have problems. >>> >>> Funnily enough=2C WebScape seems to work (as well or poorly as anywhere e= >>lse)=2C >>> but mentor and Juno both fail miserably: >>> >>> >>> mika at scruff /cygdrive/c/cm3/bin >>> $ ./mentor >>> >>> >>> *** >>> *** runtime error: >>> *** Attempt to reference an illegal memory location. >>> *** pc =3D 0x1061634 =3D GetAttributes + 0x179 in ..\src\lego\WIN32\Scrol= >>lerVBTCl >>> ass.m3 >>> *** >>> >>> Stack trace: >>> FP PC Procedure >>> --------- --------- ------------------------------- >>> 0x30af668 0x6a6e4d SystemError + 0x66 in ..\src\runtime\NT386\RTSignal.m3 >>> 0x30af70c 0x1061634 GetAttributes + 0x179 in ..\src\lego\WIN32\ScrollerVB= >>TClas >>> s.m3 >>> 0x30af7e4 0x10993d8 AddView + 0x101e(!) in ..\src\lego\ViewportVBT.m3 >>> 0x30af830 0x109743e Init + 0x30e in ..\src\lego\ViewportVBT.m3 >>> 0x30af950 0x1004ee0 pViewport + 0x512 in ..\src\FormsVBT.m3 >>> 0x30af9b0 0xff33df Item + 0x48b in ..\src\FormsVBT.m3 >>> 0x30af9dc 0x1010f66 OneChild + 0xf8 in ..\src\FormsVBT.m3 >>> 0x30afae4 0xff7448 pShape + 0x19c in ..\src\FormsVBT.m3 >>> 0x30afb44 0xff33df Item + 0x48b in ..\src\FormsVBT.m3 >>> 0x30afb70 0x1010f66 OneChild + 0xf8 in ..\src\FormsVBT.m3 >>> ......... ......... ... more frames ... >>> >>> mika at scruff /cygdrive/c/cm3/bin >>> $ ./Juno >>> >>> >>> *** >>> *** runtime error: >>> *** failed. >>> *** file "..\src\winvbt\WinContext.m3"=2C line 165 >>> *** >>> >>> Stack trace: >>> FP PC Procedure >>> --------- --------- ------------------------------- >>> 0x1b6f854 0xea1e03 PushPixmap + 0x4cb in ..\src\winvbt\WinContext.m3 >>> 0x1b6f91c 0xeb10c7 PixmapCom + 0x9ed in ..\src\winvbt\WinPaint.m3 >>> 0x1b6fd78 0xeaedaf PaintBatch + 0x25f in ..\src\winvbt\WinPaint.m3 >>> 0x1b6fde4 0xea91f3 PaintBatchVBT + 0x13f in ..\src\winvbt\WinTrestle.m3 >>> 0x1b6fe2c 0xea7919 WindowProc + 0x763 in ..\src\winvbt\WinTrestle.m3 >>> 0x1b6fe4c 0x77e3a454=20 >>> 0x1b6fed8 0x77e14605=20 >>> 0x1b6ff30 0x77e15b77=20 >>> 0x1b6ff88 0x4fb015 RunThread + 0x234 in ..\src\thread\WIN32\ThreadWin32.m= >>3 >>> 0x1b6ffb4 0x4fad57 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m= >>3 >>> ......... ......... ... more frames ... >>> >>> mika at scruff /cygdrive/c/cm3/bin >>> $ >>> >>> This is running from the cygwin shell but it doesn't do anything differen= >>t >>> from CMD... >>> >>> Should I not expect to be able to get this to work? >>> >>> Mika= From jay.krell at cornell.edu Fri Aug 28 06:32:02 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 28 Aug 2009 04:32:02 +0000 Subject: [M3devel] CM3 on windows In-Reply-To: <20090828042715.B05E51A20A1@async.async.caltech.edu> References: <20090828020144.B5E7C1A209A@async.async.caltech.edu> <20090828034057.475DD1A209A@async.async.caltech.edu> <20090828042715.B05E51A20A1@async.async.caltech.edu> Message-ID: NT386GNU => Do you have an X Windows server? Compiler -- I meant the C compiler. set show: set LIB set PATH set INCLUDE and then among the directories in LIB, and your cm3 install\lib, where is kernel32.lib? Where is winspool.lib? Cm3 has its own, but for /almost/ no good reason. Older cm3 had its own modified ones for reasons related to the VM-sychronized GC. If you were to keep those around, they wouldn't work any longer -- probably fail to link. So current cm3 replaces them. As well, some much less usual toolsets, such as the Visual C++ 2003 Express or somesuch, which isn't available any longer, only included a C runtime and no kernel32.lib, user32.lib, winspool.lib, etc. So we provide them for such users. Perhaps we should 1) assume a new clean install, no old cm3 .libs 2) not support that one odd toolset -- heck, we can keep the import-libs directory, just remove it from any package set, and any such users can build it themselves. Long story short: normally among the directories in %LIB%, you should find kernel32.lib, msvcrt.lib, winspool.lib, user32.lib, gdi32.lib, comctl32.lib, etc. Windows 2000, really? Plan to upgrade to XP or newer any time soon? - Jay ---------------------------------------- > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: CM3 on windows > Date: Thu, 27 Aug 2009 21:27:15 -0700 > From: mika at async.async.caltech.edu > > Jay K writes: >> >>> Compiling in the CMD window fails>> at a link (can't find winspool.lib)= >>=3D2C and the binaries have problems >> >>=20 >>Where is it getting kernel32.lib? >> c:\cm3\lib? >> %LIB%? >>What is your compiler/linker? >>What are the "problems"? > > I installed Visual C++ Express Edition 8.0. > > It appears to use "link.exe" (not the Cygwin one, but a Windows one) as linker. > > Compiler... cm3?? > > The "problems" are mentioned in my email (scroll down a bit... mentor, Juno, ...) > > I tried NT386GNU as well, which does let me do text mode applications but crashes > if I try to open a window. "TrestleComm.Failure" > > I have to warn you I am a *complete* novice when it comes to programming in > Windows... > > Mika > >>=20 >>=20 >> - Jay >> >> >> >>---------------------------------------- >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com >>> Subject: Re: CM3 on windows >>> Date: Thu=2C 27 Aug 2009 20:40:57 -0700 >>> From: mika at async.async.caltech.edu >>> >>> Jay K writes: >>>> >>>>I fixed the access on 5.8.2. >>>>Try that? >>>>I can poke around.. >>>>=3D20 >>>>As I recall 5.8.1 used VC 8.0 and 5.8.2 used 9.0. >>>>If that helps. >>> >>> Well I can try but I don't think 9.0 works on Win2k... >>> >>>>=3D20 >>>> - Jay >>>> >>>> >>>>---------------------------------------- >>>>> To: m3devel at elegosoft.com=3D3B jay.krell at cornell.edu >>>>> CC: mika at async.caltech.edu >>>>> Subject: CM3 on windows >>>>> Date: Thu=3D2C 27 Aug 2009 19:01:44 -0700 >>>>> From: mika at async.async.caltech.edu >>>>> >>>>> Hi m3devel=3D2C >>>>> >>>>> Not sure if my earlier message today went anywhere. I never saw it on >>>>> the list. >>>>> >>>>> I'd like to try running CM3 on Windows 2000=3D2C so I've downloaded >>>>> >>>>> http://www.opencm3.com/uploaded-archives/cm3-std-NT386-d5.8.1.msi >>>>> >>>>> (5.8.2 didn't work---no access). >>>>> >>>>> Having installed it as well as I can figure=3D2C following the directio= >>ns a=3D >>>>t >>>>> >>>>> http://www.opencm3.com/installation-windows.html >>>>> >>>>> I don't really seem to get all the way. Compiling in the CMD window fai= >>ls >>>>> at a link (can't find winspool.lib)=3D2C and the binaries have problems= >>. >>>>> >>>>> Funnily enough=3D2C WebScape seems to work (as well or poorly as anywhe= >>re e=3D >>>>lse)=3D2C >>>>> but mentor and Juno both fail miserably: >>>>> >>>>> >>>>> mika at scruff /cygdrive/c/cm3/bin >>>>> $ ./mentor >>>>> >>>>> >>>>> *** >>>>> *** runtime error: >>>>> *** Attempt to reference an illegal memory location. >>>>> *** pc =3D3D 0x1061634 =3D3D GetAttributes + 0x179 in ..\src\lego\WIN32= >>\Scrol=3D >>>>lerVBTCl >>>>> ass.m3 >>>>> *** >>>>> >>>>> Stack trace: >>>>> FP PC Procedure >>>>> --------- --------- ------------------------------- >>>>> 0x30af668 0x6a6e4d SystemError + 0x66 in ..\src\runtime\NT386\RTSignal.= >>m3 >>>>> 0x30af70c 0x1061634 GetAttributes + 0x179 in ..\src\lego\WIN32\Scroller= >>VB=3D >>>>TClas >>>>> s.m3 >>>>> 0x30af7e4 0x10993d8 AddView + 0x101e(!) in ..\src\lego\ViewportVBT.m3 >>>>> 0x30af830 0x109743e Init + 0x30e in ..\src\lego\ViewportVBT.m3 >>>>> 0x30af950 0x1004ee0 pViewport + 0x512 in ..\src\FormsVBT.m3 >>>>> 0x30af9b0 0xff33df Item + 0x48b in ..\src\FormsVBT.m3 >>>>> 0x30af9dc 0x1010f66 OneChild + 0xf8 in ..\src\FormsVBT.m3 >>>>> 0x30afae4 0xff7448 pShape + 0x19c in ..\src\FormsVBT.m3 >>>>> 0x30afb44 0xff33df Item + 0x48b in ..\src\FormsVBT.m3 >>>>> 0x30afb70 0x1010f66 OneChild + 0xf8 in ..\src\FormsVBT.m3 >>>>> ......... ......... ... more frames ... >>>>> >>>>> mika at scruff /cygdrive/c/cm3/bin >>>>> $ ./Juno >>>>> >>>>> >>>>> *** >>>>> *** runtime error: >>>>> *** failed. >>>>> *** file "..\src\winvbt\WinContext.m3"=3D2C line 165 >>>>> *** >>>>> >>>>> Stack trace: >>>>> FP PC Procedure >>>>> --------- --------- ------------------------------- >>>>> 0x1b6f854 0xea1e03 PushPixmap + 0x4cb in ..\src\winvbt\WinContext.m3 >>>>> 0x1b6f91c 0xeb10c7 PixmapCom + 0x9ed in ..\src\winvbt\WinPaint.m3 >>>>> 0x1b6fd78 0xeaedaf PaintBatch + 0x25f in ..\src\winvbt\WinPaint.m3 >>>>> 0x1b6fde4 0xea91f3 PaintBatchVBT + 0x13f in ..\src\winvbt\WinTrestle.m3 >>>>> 0x1b6fe2c 0xea7919 WindowProc + 0x763 in ..\src\winvbt\WinTrestle.m3 >>>>> 0x1b6fe4c 0x77e3a454=3D20 >>>>> 0x1b6fed8 0x77e14605=3D20 >>>>> 0x1b6ff30 0x77e15b77=3D20 >>>>> 0x1b6ff88 0x4fb015 RunThread + 0x234 in ..\src\thread\WIN32\ThreadWin32= >>.m=3D >>>>3 >>>>> 0x1b6ffb4 0x4fad57 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32= >>.m=3D >>>>3 >>>>> ......... ......... ... more frames ... >>>>> >>>>> mika at scruff /cygdrive/c/cm3/bin >>>>> $ >>>>> >>>>> This is running from the cygwin shell but it doesn't do anything differ= >>en=3D >>>>t >>>>> from CMD... >>>>> >>>>> Should I not expect to be able to get this to work? >>>>> >>>>> Mika=3D= From jay.krell at cornell.edu Fri Aug 28 07:03:58 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 28 Aug 2009 05:03:58 +0000 Subject: [M3devel] CM3 on windows In-Reply-To: <20090828045055.BA3C81A20A1@async.async.caltech.edu> References: <20090828020144.B5E7C1A209A@async.async.caltech.edu> <20090828034057.475DD1A209A@async.async.caltech.edu> <20090828042715.B05E51A20A1@async.async.caltech.edu> <20090828045055.BA3C81A20A1@async.async.caltech.edu> Message-ID: Yes NT386GNU uses X. Olaf expressed an interest in that. Apparently the Windows port of Trestle has never been completed. (I suspect we should punt Trestle and bind to Qt, but that is another matter.) NT386GMINGNU doesn't use X. Though it had problems last I checked. NT386GNU I think also uses pthreads. And NT386MINGNU does not. The names should be I386_CYGWIN and I386_MINGW. There are few variables, and they are largely but not completely independent of each other: Which cm3 backend, integrated or gcc? Which C compiler, Visual C++ or gcc? (or Watcom or Borland, etc.) Which linker, same choices as previous. Win32 or Posix? In terms of path syntax. fork/exec vs. CreateProcess. Which threading library? Which windowing library? NT386GNU aka I386_CYGWIN is "very Posix". NT386MINGNU is totally Win32, except that the compiler backend is gcc. Oh and maybe the compiler/linker are gcc/GNU ld also. In future I expect to rename the platforms to I386_CYGWIN and I386_MINGW, and I386_NT (NT386)). There was good evicence that the gcc backend has never been used to target Win32 GUI. In particular there wasn't support for __stdcall, and the support is still broken in an usual case. I put in a workaround. - Jay ---------------------------------------- > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: CM3 on windows > Date: Thu, 27 Aug 2009 21:50:55 -0700 > From: mika at async.async.caltech.edu > > Jay K writes: >> >>NT386GNU =3D> Do you have an X Windows server? > > Hmm, really, NT386GNU just uses X? I could swear my ancient > Klagenfurt/PM3 uses Windows windows, not X... > >>Compiler -- I meant the C compiler. > > As far as I know the compiler I'm using is "cl" that came with VC++ 8.0 ("2003"?) > >>=20 >>=20 >>set show: >> set LIB >> set PATH >> set INCLUDE >>=20 >>=20 >>and then among the directories in LIB=2C and your cm3 install\lib=2C where = >>is kernel32.lib? Where is winspool.lib? > > kernel32 is in > > ...Visual Studio 8\VC\lib > > aha.. I think the only winspool I have is in C:\cm3, and that directory is > not in LIB. > > That would explain why things aren't compiling, but not why I get the errors > in mentor, Juno, etc. > > >>=20 >>Cm3 has its own=2C but for /almost/ no good reason. >> Older cm3 had its own modified ones for reasons related to the VM-sychroni= >>zed GC. >> If you were to keep those around=2C they wouldn't work any longer -- proba= >>bly fail to link. >> So current cm3 replaces them. >> As well=2C some much less usual toolsets=2C such as the Visual C++ 2003 Ex= >>press or somesuch=2C which isn't available any longer=2C only included a C = >>runtime and no kernel32.lib=2C user32.lib=2C winspool.lib=2C etc. So we pro= >>vide them for such users. Perhaps we should 1) assume a new clean install= >>=2C no old cm3 .libs 2) not support that one odd toolset -- heck=2C we can = >>keep the import-libs directory=2C just remove it from any package set=2C an= >>d any such users can build it themselves. >>=20 >>=20 >>Long story short: normally among the directories in %LIB%=2C you should fin= >>d kernel32.lib=2C msvcrt.lib=2C winspool.lib=2C user32.lib=2C gdi32.lib=2C = >>comctl32.lib=2C etc. >>=20 >>=20 >>Windows 2000=2C really? >>Plan to upgrade to XP or newer any time soon? > > Wasn't planning on it.. I try to use Windows as little as possible.. but if > it's necessary to get CM3 working.. > > I should mention that my goal is actually to build .exes that can be > distributed to people with Vista. Is that possible with my system? > > Mika > >>=20 >>=20 >> - Jay >> >> >>---------------------------------------- >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com >>> Subject: Re: CM3 on windows >>> Date: Thu=2C 27 Aug 2009 21:27:15 -0700 >>> From: mika at async.async.caltech.edu >>> >>> Jay K writes: >>>> >>>>> Compiling in the CMD window fails>> at a link (can't find winspool.lib)= >>=3D >>>>=3D3D2C and the binaries have problems >>>> >>>>=3D20 >>>>Where is it getting kernel32.lib? >>>> c:\cm3\lib? >>>> %LIB%? >>>>What is your compiler/linker? >>>>What are the "problems"? >>> >>> I installed Visual C++ Express Edition 8.0. >>> >>> It appears to use "link.exe" (not the Cygwin one=2C but a Windows one) as= >> linker. >>> >>> Compiler... cm3?? >>> >>> The "problems" are mentioned in my email (scroll down a bit... mentor=2C = >>Juno=2C ...) >>> >>> I tried NT386GNU as well=2C which does let me do text mode applications b= >>ut crashes >>> if I try to open a window. "TrestleComm.Failure" >>> >>> I have to warn you I am a *complete* novice when it comes to programming = >>in >>> Windows... >>> >>> Mika >>> >>>>=3D20 >>>>=3D20 >>>> - Jay >>>> >>>> >>>> >>>>---------------------------------------- >>>>> To: jay.krell at cornell.edu >>>>> CC: m3devel at elegosoft.com >>>>> Subject: Re: CM3 on windows >>>>> Date: Thu=3D2C 27 Aug 2009 20:40:57 -0700 >>>>> From: mika at async.async.caltech.edu >>>>> >>>>> Jay K writes: >>>>>> >>>>>>I fixed the access on 5.8.2. >>>>>>Try that? >>>>>>I can poke around.. >>>>>>=3D3D20 >>>>>>As I recall 5.8.1 used VC 8.0 and 5.8.2 used 9.0. >>>>>>If that helps. >>>>> >>>>> Well I can try but I don't think 9.0 works on Win2k... >>>>> >>>>>>=3D3D20 >>>>>> - Jay >>>>>> >>>>>> >>>>>>---------------------------------------- >>>>>>> To: m3devel at elegosoft.com=3D3D3B jay.krell at cornell.edu >>>>>>> CC: mika at async.caltech.edu >>>>>>> Subject: CM3 on windows >>>>>>> Date: Thu=3D3D2C 27 Aug 2009 19:01:44 -0700 >>>>>>> From: mika at async.async.caltech.edu >>>>>>> >>>>>>> Hi m3devel=3D3D2C >>>>>>> >>>>>>> Not sure if my earlier message today went anywhere. I never saw it on >>>>>>> the list. >>>>>>> >>>>>>> I'd like to try running CM3 on Windows 2000=3D3D2C so I've downloaded >>>>>>> >>>>>>> http://www.opencm3.com/uploaded-archives/cm3-std-NT386-d5.8.1.msi >>>>>>> >>>>>>> (5.8.2 didn't work---no access). >>>>>>> >>>>>>> Having installed it as well as I can figure=3D3D2C following the dire= >>ctio=3D >>>>ns a=3D3D >>>>>>t >>>>>>> >>>>>>> http://www.opencm3.com/installation-windows.html >>>>>>> >>>>>>> I don't really seem to get all the way. Compiling in the CMD window f= >>ai=3D >>>>ls >>>>>>> at a link (can't find winspool.lib)=3D3D2C and the binaries have prob= >>lems=3D >>>>. >>>>>>> >>>>>>> Funnily enough=3D3D2C WebScape seems to work (as well or poorly as an= >>ywhe=3D >>>>re e=3D3D >>>>>>lse)=3D3D2C >>>>>>> but mentor and Juno both fail miserably: >>>>>>> >>>>>>> >>>>>>> mika at scruff /cygdrive/c/cm3/bin >>>>>>> $ ./mentor >>>>>>> >>>>>>> >>>>>>> *** >>>>>>> *** runtime error: >>>>>>> *** Attempt to reference an illegal memory location. >>>>>>> *** pc =3D3D3D 0x1061634 =3D3D3D GetAttributes + 0x179 in ..\src\lego= >>\WIN32=3D >>>>\Scrol=3D3D >>>>>>lerVBTCl >>>>>>> ass.m3 >>>>>>> *** >>>>>>> >>>>>>> Stack trace: >>>>>>> FP PC Procedure >>>>>>> --------- --------- ------------------------------- >>>>>>> 0x30af668 0x6a6e4d SystemError + 0x66 in ..\src\runtime\NT386\RTSigna= >>l.=3D >>>>m3 >>>>>>> 0x30af70c 0x1061634 GetAttributes + 0x179 in ..\src\lego\WIN32\Scroll= >>er=3D >>>>VB=3D3D >>>>>>TClas >>>>>>> s.m3 >>>>>>> 0x30af7e4 0x10993d8 AddView + 0x101e(!) in ..\src\lego\ViewportVBT.m3 >>>>>>> 0x30af830 0x109743e Init + 0x30e in ..\src\lego\ViewportVBT.m3 >>>>>>> 0x30af950 0x1004ee0 pViewport + 0x512 in ..\src\FormsVBT.m3 >>>>>>> 0x30af9b0 0xff33df Item + 0x48b in ..\src\FormsVBT.m3 >>>>>>> 0x30af9dc 0x1010f66 OneChild + 0xf8 in ..\src\FormsVBT.m3 >>>>>>> 0x30afae4 0xff7448 pShape + 0x19c in ..\src\FormsVBT.m3 >>>>>>> 0x30afb44 0xff33df Item + 0x48b in ..\src\FormsVBT.m3 >>>>>>> 0x30afb70 0x1010f66 OneChild + 0xf8 in ..\src\FormsVBT.m3 >>>>>>> ......... ......... ... more frames ... >>>>>>> >>>>>>> mika at scruff /cygdrive/c/cm3/bin >>>>>>> $ ./Juno >>>>>>> >>>>>>> >>>>>>> *** >>>>>>> *** runtime error: >>>>>>> *** failed. >>>>>>> *** file "..\src\winvbt\WinContext.m3"=3D3D2C line 165 >>>>>>> *** >>>>>>> >>>>>>> Stack trace: >>>>>>> FP PC Procedure >>>>>>> --------- --------- ------------------------------- >>>>>>> 0x1b6f854 0xea1e03 PushPixmap + 0x4cb in ..\src\winvbt\WinContext.m3 >>>>>>> 0x1b6f91c 0xeb10c7 PixmapCom + 0x9ed in ..\src\winvbt\WinPaint.m3 >>>>>>> 0x1b6fd78 0xeaedaf PaintBatch + 0x25f in ..\src\winvbt\WinPaint.m3 >>>>>>> 0x1b6fde4 0xea91f3 PaintBatchVBT + 0x13f in ..\src\winvbt\WinTrestle.= >>m3 >>>>>>> 0x1b6fe2c 0xea7919 WindowProc + 0x763 in ..\src\winvbt\WinTrestle.m3 >>>>>>> 0x1b6fe4c 0x77e3a454=3D3D20 >>>>>>> 0x1b6fed8 0x77e14605=3D3D20 >>>>>>> 0x1b6ff30 0x77e15b77=3D3D20 >>>>>>> 0x1b6ff88 0x4fb015 RunThread + 0x234 in ..\src\thread\WIN32\ThreadWin= >>32=3D >>>>.m=3D3D >>>>>>3 >>>>>>> 0x1b6ffb4 0x4fad57 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin= >>32=3D >>>>.m=3D3D >>>>>>3 >>>>>>> ......... ......... ... more frames ... >>>>>>> >>>>>>> mika at scruff /cygdrive/c/cm3/bin >>>>>>> $ >>>>>>> >>>>>>> This is running from the cygwin shell but it doesn't do anything diff= >>er=3D >>>>en=3D3D >>>>>>t >>>>>>> from CMD... >>>>>>> >>>>>>> Should I not expect to be able to get this to work? >>>>>>> >>>>>>> Mika=3D3D=3D= From jay.krell at cornell.edu Fri Aug 28 09:21:19 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 28 Aug 2009 07:21:19 +0000 Subject: [M3devel] strange code in scripts Message-ID: This sequence is odd: [ ${TARGET} != NT386 ] && "${ROOT}/scripts/do-pkg.sh" buildship echo "${ROOT}/scripts/do-cm3-${DIST}.sh" buildlocal "${ROOT}/scripts/do-cm3-${DIST}.sh" buildlocal || exit 1 header "stage 4: installing libraries using new cm3 compiler" echo "${ROOT}/scripts/do-cm3-${DIST}.sh" buildglobal "${ROOT}/scripts/do-cm3-${DIST}.sh" buildglobal || exit 1 The first line doesn't do anything. In the logs you can see it just says "no packages". I don't understand why buildlocal + buildglobal. Is that, um, to delete the .M3OVERRIDES files, so that "On the other side", ship won't refuse? - Jay From jay.krell at cornell.edu Fri Aug 28 09:22:28 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 28 Aug 2009 07:22:28 +0000 Subject: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems In-Reply-To: <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> References: <20090826142644.r6yabwff5wc84cgg@mail.elegosoft.com> <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> Message-ID: It was backslashes vs. forward slashes as I had originally suspected. My debugprinting never hit because I was guessing the elego paths wrong. I finally made it always print and tested it in-situ in the VM. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems > Date: Thu, 27 Aug 2009 12:15:14 +0000 > > > My current theory is the unresolve problem is due to that wierd initial build of import-libs in the Hudson task, which was related to the line endings problem, which was related to using CVSNT instead of Cygwin cvs. > > - Jay > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems >> Date: Thu, 27 Aug 2009 06:09:52 +0000 >> >> >> I'm testing a fix for the VM right now actually. >> Once that works I'll look into the Unresolve problem further. I put in some printing to help diagnose it and possibly a fix. It could be a slash mixup; the printing will tell us. >> The VBT problem is new seeming. I'll look at that too. >> Anyone else is welcome to also. >> >> - Jay >> >> >> ---------------------------------------- >>> Date: Thu, 27 Aug 2009 08:06:57 +0200 >>> From: wagner at elegosoft.com >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com >>> Subject: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems >>> >>> Quoting Jay K : >>> >>>> Something or some things very wierd here. I'll keep looking into it. >>> I'm not sure if we should spend/waste(?) more time in trying to make >>> this VM with Windows work. >>> >>> Last night I reactivated my own qemu-based VM and was able to checkout >>> and build some current CM3 stuff. >>> >>> CVS behaves correctly there, and no need to adapt any of the shell >>> scripts at all. It's agonizingly slow though. And it has no remote >>> access. >>> >>> However, building the release archives failed with two errors: >>> >>> vbtkit: >>> new source -> compiling VBTKitResources.m3 >>> "..\src\lego\VBTKitResources.m3", line 10: unable to find interface >>> (VBTKitBundle) >>> 1 error encountered >>> >>> and >>> >>> errors during build-all; some packages will be missing >>> m3-win/import-libs/NT386/.M3SHIP seems to be broken: >>> make_dir("c:/tmp/cm3/lib") >>> install_file("wsock32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("advapi32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("opengl32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("netapi32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("comctl32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("user32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("comdlg32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("kernel32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("winspool.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("glu32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("gdi32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("odbc32.lib", "c:/tmp/cm3/lib", "0775") >>> >>> (wrong shippind destination, already reported) >>> >>> I suggest we rather concentrate on these and build the Windows >>> packages manually. >>> >>> I'm off to (paid) work again now... >>> >>> Olaf >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >>> From wagner at elegosoft.com Fri Aug 28 09:45:53 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 28 Aug 2009 09:45:53 +0200 Subject: [M3devel] CM3 on windows In-Reply-To: References: <20090828020144.B5E7C1A209A@async.async.caltech.edu> Message-ID: <20090828094553.hbdkyxsi8ss84oos@mail.elegosoft.com> I don't think Juno and mentor ever worked without an X server. The Trestle implementation on Windows was never complete nor stable enough for that AFAIK. Using the X implementation and an X server on Windows should work though (but I haven't tried that for years with M3). Of course it would be great if somebody took care to fix the Trestle ui package for Windows. Others please contradict me if I'm out of date here. Olaf Quoting Jay K : > > I fixed the access on 5.8.2. > Try that? > I can poke around.. > > As I recall 5.8.1 used VC 8.0 and 5.8.2 used 9.0. > If that helps. > > - Jay > > > ---------------------------------------- >> To: m3devel at elegosoft.com; jay.krell at cornell.edu >> CC: mika at async.caltech.edu >> Subject: CM3 on windows >> Date: Thu, 27 Aug 2009 19:01:44 -0700 >> From: mika at async.async.caltech.edu >> >> Hi m3devel, >> >> Not sure if my earlier message today went anywhere. I never saw it on >> the list. >> >> I'd like to try running CM3 on Windows 2000, so I've downloaded >> >> http://www.opencm3.com/uploaded-archives/cm3-std-NT386-d5.8.1.msi >> >> (5.8.2 didn't work---no access). >> >> Having installed it as well as I can figure, following the directions at >> >> http://www.opencm3.com/installation-windows.html >> >> I don't really seem to get all the way. Compiling in the CMD window fails >> at a link (can't find winspool.lib), and the binaries have problems. >> >> Funnily enough, WebScape seems to work (as well or poorly as anywhere else), >> but mentor and Juno both fail miserably: >> >> >> mika at scruff /cygdrive/c/cm3/bin >> $ ./mentor >> >> >> *** >> *** runtime error: >> *** Attempt to reference an illegal memory location. >> *** pc = 0x1061634 = GetAttributes + 0x179 in >> ..\src\lego\WIN32\ScrollerVBTCl >> ass.m3 >> *** >> >> Stack trace: >> FP PC Procedure >> --------- --------- ------------------------------- >> 0x30af668 0x6a6e4d SystemError + 0x66 in ..\src\runtime\NT386\RTSignal.m3 >> 0x30af70c 0x1061634 GetAttributes + 0x179 in >> ..\src\lego\WIN32\ScrollerVBTClas >> s.m3 >> 0x30af7e4 0x10993d8 AddView + 0x101e(!) in ..\src\lego\ViewportVBT.m3 >> 0x30af830 0x109743e Init + 0x30e in ..\src\lego\ViewportVBT.m3 >> 0x30af950 0x1004ee0 pViewport + 0x512 in ..\src\FormsVBT.m3 >> 0x30af9b0 0xff33df Item + 0x48b in ..\src\FormsVBT.m3 >> 0x30af9dc 0x1010f66 OneChild + 0xf8 in ..\src\FormsVBT.m3 >> 0x30afae4 0xff7448 pShape + 0x19c in ..\src\FormsVBT.m3 >> 0x30afb44 0xff33df Item + 0x48b in ..\src\FormsVBT.m3 >> 0x30afb70 0x1010f66 OneChild + 0xf8 in ..\src\FormsVBT.m3 >> ......... ......... ... more frames ... >> >> mika at scruff /cygdrive/c/cm3/bin >> $ ./Juno >> >> >> *** >> *** runtime error: >> *** failed. >> *** file "..\src\winvbt\WinContext.m3", line 165 >> *** >> >> Stack trace: >> FP PC Procedure >> --------- --------- ------------------------------- >> 0x1b6f854 0xea1e03 PushPixmap + 0x4cb in ..\src\winvbt\WinContext.m3 >> 0x1b6f91c 0xeb10c7 PixmapCom + 0x9ed in ..\src\winvbt\WinPaint.m3 >> 0x1b6fd78 0xeaedaf PaintBatch + 0x25f in ..\src\winvbt\WinPaint.m3 >> 0x1b6fde4 0xea91f3 PaintBatchVBT + 0x13f in ..\src\winvbt\WinTrestle.m3 >> 0x1b6fe2c 0xea7919 WindowProc + 0x763 in ..\src\winvbt\WinTrestle.m3 >> 0x1b6fe4c 0x77e3a454 >> 0x1b6fed8 0x77e14605 >> 0x1b6ff30 0x77e15b77 >> 0x1b6ff88 0x4fb015 RunThread + 0x234 in ..\src\thread\WIN32\ThreadWin32.m3 >> 0x1b6ffb4 0x4fad57 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3 >> ......... ......... ... more frames ... >> >> mika at scruff /cygdrive/c/cm3/bin >> $ >> >> This is running from the cygwin shell but it doesn't do anything different >> from CMD... >> >> Should I not expect to be able to get this to work? >> >> Mika -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Fri Aug 28 10:09:03 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 28 Aug 2009 10:09:03 +0200 Subject: [M3devel] strange code in scripts In-Reply-To: References: Message-ID: <20090828100903.7lsknqfqt5w0csk4@mail.elegosoft.com> I assume you're talking about make-bin-dist-min.sh. Quoting Jay K : > This sequence is odd: > > [ ${TARGET} != NT386 ] && "${ROOT}/scripts/do-pkg.sh" buildship > echo "${ROOT}/scripts/do-cm3-${DIST}.sh" buildlocal > "${ROOT}/scripts/do-cm3-${DIST}.sh" buildlocal || exit 1 > > header "stage 4: installing libraries using new cm3 compiler" > echo "${ROOT}/scripts/do-cm3-${DIST}.sh" buildglobal > "${ROOT}/scripts/do-cm3-${DIST}.sh" buildglobal || exit 1 > > The first line doesn't do anything. > In the logs you can see it just says "no packages". Have a look at http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/scripts/make-bin-dist-min.sh?annotate=1.42.2.5 This line is from Tony with the following comment: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/scripts/make-bin-dist-min.sh#rev1.24 It should be completely removed. > I don't understand why buildlocal + buildglobal. This is (a) a reasonable precaution, as building local will test everything before shipping it, and (b) it will show us if both building against the workspace and against the global package pool succeeds. Missing/wrong overrides have often enough broken the released packages. > Is that, um, to delete the .M3OVERRIDES files, so that "On the other side", > ship won't refuse? Of course, if we'd only build with overrides we couldn't ship anything. The second run will mostly just change the .M3SHIP files (and relink some programs, because M3 is usually not smart enough to avoid that -- but the discussion about dynamic linking has shown that that can be viewed as a feature :-). Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Fri Aug 28 10:15:11 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 28 Aug 2009 10:15:11 +0200 Subject: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems In-Reply-To: References: <20090826142644.r6yabwff5wc84cgg@mail.elegosoft.com> <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> Message-ID: <20090828101511.zsm14bsqow0k4w8o@mail.elegosoft.com> Quoting Jay K : > It was backslashes vs. forward slashes as I had originally suspected. > My debugprinting never hit because I was guessing the elego paths wrong. > I finally made it always print and tested it in-situ in the VM. So we now have Windows packages on birch for RC3? No, not yet. But I see that makedist is currently running... I think we should do something about this pathname confusion on Windows. See separate mail. Olaf > > - Jay > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] RC3 build problems, was: RE: caltech-parser >> NT386 Hudson problems >> Date: Thu, 27 Aug 2009 12:15:14 +0000 >> >> >> My current theory is the unresolve problem is due to that wierd >> initial build of import-libs in the Hudson task, which was related >> to the line endings problem, which was related to using CVSNT >> instead of Cygwin cvs. >> >> - Jay >> >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: wagner at elegosoft.com >>> CC: m3devel at elegosoft.com >>> Subject: RE: [M3devel] RC3 build problems, was: RE: caltech-parser >>> NT386 Hudson problems >>> Date: Thu, 27 Aug 2009 06:09:52 +0000 >>> >>> >>> I'm testing a fix for the VM right now actually. >>> Once that works I'll look into the Unresolve problem further. I >>> put in some printing to help diagnose it and possibly a fix. It >>> could be a slash mixup; the printing will tell us. >>> The VBT problem is new seeming. I'll look at that too. >>> Anyone else is welcome to also. >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> Date: Thu, 27 Aug 2009 08:06:57 +0200 >>>> From: wagner at elegosoft.com >>>> To: jay.krell at cornell.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: [M3devel] RC3 build problems, was: RE: caltech-parser >>>> NT386 Hudson problems >>>> >>>> Quoting Jay K : >>>> >>>>> Something or some things very wierd here. I'll keep looking into it. >>>> I'm not sure if we should spend/waste(?) more time in trying to make >>>> this VM with Windows work. >>>> >>>> Last night I reactivated my own qemu-based VM and was able to checkout >>>> and build some current CM3 stuff. >>>> >>>> CVS behaves correctly there, and no need to adapt any of the shell >>>> scripts at all. It's agonizingly slow though. And it has no remote >>>> access. >>>> >>>> However, building the release archives failed with two errors: >>>> >>>> vbtkit: >>>> new source -> compiling VBTKitResources.m3 >>>> "..\src\lego\VBTKitResources.m3", line 10: unable to find interface >>>> (VBTKitBundle) >>>> 1 error encountered >>>> >>>> and >>>> >>>> errors during build-all; some packages will be missing >>>> m3-win/import-libs/NT386/.M3SHIP seems to be broken: >>>> make_dir("c:/tmp/cm3/lib") >>>> install_file("wsock32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("advapi32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("opengl32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("netapi32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("comctl32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("user32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("comdlg32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("kernel32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("winspool.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("glu32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("gdi32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("odbc32.lib", "c:/tmp/cm3/lib", "0775") >>>> >>>> (wrong shippind destination, already reported) >>>> >>>> I suggest we rather concentrate on these and build the Windows >>>> packages manually. >>>> >>>> I'm off to (paid) work again now... >>>> >>>> Olaf >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>> DE163214194 >>>> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Fri Aug 28 10:26:35 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 28 Aug 2009 10:26:35 +0200 Subject: [M3devel] Change Pathname abstraction for Windows? was: RE: RC3 build problems, was: RE: caltech-parser NT386 Hudson problems In-Reply-To: References: <20090826142644.r6yabwff5wc84cgg@mail.elegosoft.com> <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> Message-ID: <20090828102635.0iyxllukro8o44o4@mail.elegosoft.com> Quoting Jay K : > It was backslashes vs. forward slashes as I had originally suspected. > My debugprinting never hit because I was guessing the elego paths wrong. > I finally made it always print and tested it in-situ in the VM. It is amazing how much (pointless) work the difference in pathname denotations on Windows and POSIX systems has caused and still causes. While there are some conceptual differences that cannot easily be generalized (one root <-> many roots, logical <-> physical view of disks etc.), the simple fact that Windows uses \ instead of / makes life needlessly difficult for many programmers. In Modula-3, the Pathname interface is intended to abstract from this, but this works only to a certain degree. It uses \ as the arc separator on Windows, while in fact all modern Windows systems accept both \ and /. I think this should be corrected. Pathnames should be split into elements at both \ and / on Windows, and checks for equality should ignore any differences in separator characters only. Does this sound reasonable? Is there any (non)obvious problem I'm overseeing right now which will make this strategy fail? Olaf PS: I'm not suggesting we do that in this release of course... -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Fri Aug 28 11:11:50 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 28 Aug 2009 05:11:50 -0400 Subject: [M3devel] small design problem in ButtonVBT? In-Reply-To: <36DAB001-70F3-4C96-B1D5-57E8A7322464@cs.purdue.edu> References: <20090331145127.GB9624@topoi.pooq.com> <20090401120347.x8cneize8oscg44o@mail.elegosoft.com> <20090826002606.GB16386@topoi.pooq.com> <20090827141741.9g1u2vrgfgokkksg@mail.elegosoft.com> <20090828031722.GB22883@topoi.pooq.com> <36DAB001-70F3-4C96-B1D5-57E8A7322464@cs.purdue.edu> Message-ID: <20090828091150.GA23396@topoi.pooq.com> On Thu, Aug 27, 2009 at 11:53:27PM -0400, Tony Hosking wrote: > Right. Plus, overriding copies the entire method suite for the new > type. Now that makes sense. I'll re-evaluate my suggestion in this light. > > On 27 Aug 2009, at 23:28, Jay K wrote: > > > > >I think I know the reason it is this way. > >It is very common to override action and nothing else. > >It is "inconvenient" to derive a new type, just to change one > >function. It's more a matter of letting the action procedure or method have clean access to application data in the subclassed function. But your code suggests a simpler way to do this than either your code or mine. It takes a run-time type check, which is conceptually messy. But the code is smaller, and seems to have a smaller memory footprint. See below. > > > >- Jay > > > >---------------------------------------- > >>Date: Thu, 27 Aug 2009 23:17:23 -0400 > >>From: hendrik at topoi.pooq.com > >>To: m3devel at elegosoft.com > >>Subject: Re: [M3devel] small design problem in ButtonVBT? > >> > >>On Thu, Aug 27, 2009 at 03:15:41PM -0400, Tony Hosking wrote: > >>>I am nervous about having the two alternative entries to the action > >>>procedure that other code might not be aware of. Yes, you've > >>>modified > >>>the default mouse method to call the action method instead of the > >>>procedure, but what about other places where the mouse method has > >>>been > >>>overridden. Yes. That could be an issue. But only if act is also overridden, which won't happen in legacy code, since the defauly act behaves identically to the action procedure. > >>> > >>>If you want to be smart about it in your own code you can simply > >>>invert your suggestion and do the following: > >>> > >>>TYPE T = ButtonVBT.T OBJECT > >>>METHODS action(cd: VBT.MouseRec) := Action; > >>> > >>>PROCEDURE Action(v: T; cd: VBT.MouseRec) = ... > >>> > >>>PROCEDURE ActionProc(v: ButtonVBT.T; cd: VBT.MouseRec) = > >>>BEGIN > >>>NARROW(v, T).action(cd); > >>>END ActionProc; > >>> > >>>and initialize your T thingy with ButtonVBT.New(..., action := > >>>ActionProc; ...) > >>> > >>>Then in your code you can go ahead and override the action method to > >>>your hearts content. But I can simplify this further. TYPE T = ButtonVBT.T OBJECT (* as you propose. *) For each action that I had wanted a subclass for, write PROCEDURE Action(vv: T; cd: VBT.MouseRec) = ... VAR v : T; BEGIN v := NARROW(vv, T); ... normal code for performing the action END Action; and initialize my T thingy using this Action. So instead of multiple subclasses to get the various actions, I get two extra lines of code in each action procedure. And I don't have to use GetProp or PutProp (which probably involve some kind of search). The run-time cost is the type-check in the NARROW(vv, T), which is probably cheaper than a method-dispatch on act. Hmmm. I'm starting to think you're right, and my change is unnecessary. I'll have a look in my applicatin code, and see if there are further glitches. I'm not expecting any. -- hendrik > >> > >>This kind of thing would work. But, like the existing semantics of > >>ButtonVBT, it seems to be fighting the language instead of working > >>with > >>it. I'd be happiest to get rid of the action variable altogether, but > >>that would be a massively incompatible change, and would require > >>change > >>to a lot of existing code. What I proposed is compatible with > >>existing > >>code, and also has the advantage that someone who subclasses > >>ButtonVBT.T > >>and overrides act can completely ignore the action variable > >>altogether. > >> > >>You say > >> > >>>and initialize your T thingy with ButtonVBT.New(..., action := > >>>ActionProc; ...) > >> > >>But that requires every object I make of type T or any sibclass to be > >>explicitly initialised with ActionProc, certainly a nuisance, and > >>certainly error-prone. > >> > >>The inelegance I see with my approach is that there are two > >>mechanisms > >>for specifying the action to be taken. Either will work without the > >>programmer paying any attention to the other, but if you use both, > >>one > >>will override the other. This is not a problem with legacy software. > >>I'll have to come up with some documentation that makes this clear. > >>It's the inelegance that comes from backward compatibility, and I > >>think > >>my solution is less inelegant, and easier to use, than yours. Yours, > >>however, involves no change in existing code. > >> > >>> > >>>Am I just being paranoid? > >> > >>No. Perhaps just paranoid about different things. > >> > >>I had hoped for someone to come up with a solid technical reason > >>for the > >>action variable. The original designers were clever people, and I'd > >>*still* like to know why they thought it was a good idea. It's > >>awkward > >>and error-prone to use, and they had to use the PutProp/GetProp > >>kludge > >>just to approximate what the language provided for free with > >>inheritance. > >> > >>I'm tempted to go over the entire code-base and change the buttons to > >>use act instead of action, but I have to admit I'm not tempted > >>enough to > >>actually do it... > >> > >>-- hendrik > >> > >>>On 27 Aug 2009, at 08:17, Olaf Wagner wrote: > >>> > >>>>Though I promised to do it, I have lost sight of this task while > >>>>trying to build some RC3 archives on Windows. As I'm not at home > >>>>this > >>>>evening, can somebody else please commit Hendrik's extension? > >>>> > >>>>Is this something we should should have in the release branch, too? > >>>>Probably not necessary? > >>>> > >>>>Olaf > >>>> > >>>>Quoting hendrik at topoi.pooq.com: > >>>> > >>>>>On Wed, Apr 01, 2009 at 12:03:47PM +0200, Olaf Wagner wrote: > >>>>>>Quoting hendrik at topoi.pooq.com: > >>>>>> > >>>>>>>The BottonVBT contains an action, which is a procedure rather > >>>>>>than a > >>>>>>>method. b This makes it awkward to subclass ButtonVBT becaue the > >>>>>>action > >>>>>>>will still expect its first parameter to be a ButtonVBT > >>>>>>>instead of > >>>>>>>belonging to the subclass, and an explicit downcast of some sort > >>>>>>will be > >>>>>>>needed to acess the subclass's members. > >>>>>>> > >>>>>>>The Trestle manual says this was a deliberate decision: > >>>>>>> > >>>>>>>: The action procedure is a field rather than a method in order > >>>>>>to allow > >>>>>>>: buttons with different action procedures to share their method > >>>>>>suites. > >>>>>>> > >>>>>>>I, however, find it massively inconvenient because it mans I > >>>>>>>have > >>>>>>to > >>>>>>>resort to downcasting or the very kludgey VBT.GetProp to access > >>>>>>what > >>>>>>>should be just there. I'd rather the action procedure was a > >>>>>>method. > >>>>>>> > >>>>>>>But it should be possible to have the best of both worlds. > >>>>>>>Have an > >>>>>>>action2 (better name wanted here) method that is available for > >>>>>>>overriding, and by default calls the procedure in the existing > >>>>>>action. > >>>>>>>field. That action2 method wounl then be called by Trestle > >>>>>>wherever > >>>>>>>action is now called. > >>>>>>> > >>>>>>>Does anyone see problems with this? > >>>>>> > >>>>>>Sounds fine to me offhand. You should test your extensions with > >>>>>>some of the existing larger applications, like mentor and Juno-2, > >>>>>>of course. > >>>>> > >>>>>OK. Here's the patch. Would it be possible for someone to check it > >>>>>in > >>>>>for me? > >>>>> > >>>>>mentor runs fine with this change; I watched it animate a heap- > >>>>>sort. > >>>>> > >>>>>I have no idea what Juno is supposed to do, but it did respond to > >>>>>button-pushes. > >>>>> > >>>>> > >>>>>hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ cvs diff > >>>>>cvs diff: Diffing . > >>>>>Index: ButtonVBT.i3 > >>>>>= > >>>>>================================================================== > >>>>>RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.i3,v > >>>>>retrieving revision 1.2 > >>>>>diff -r1.2 ButtonVBT.i3 > >>>>>39a40 > >>>>>>act(READONLY cd: VBT.MouseRec); > >>>>>Index: ButtonVBT.m3 > >>>>>= > >>>>>================================================================== > >>>>>RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.m3,v > >>>>>retrieving revision 1.2 > >>>>>diff -r1.2 ButtonVBT.m3 > >>>>>28c28,29 > >>>>>< init := Be > >>>>>--- > >>>>>>init := Be; > >>>>>>act := act > >>>>>46a48,52 > >>>>>>PROCEDURE act(v : T; READONLY cd: VBT.MouseRec) = > >>>>>>BEGIN > >>>>>>v.action(v, cd); > >>>>>>END act; > >>>>>> > >>>>>59c65 > >>>>>< v.action(v, cd); > >>>>>--- > >>>>>>v.act(cd); > >>>>>hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ > >>>>> > >>>>>-- hendrik > >>>>> > >>>> > >>>> > >>>> > >>>>-- > >>>>Olaf Wagner -- elego Software Solutions GmbH > >>>>Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > >>>>Germany > >>>>phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > >>>>45 86 95 > >>>>http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > >>>>Berlin > >>>>Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > >>>>DE163214194 > >>>> > >>> > From hendrik at topoi.pooq.com Fri Aug 28 11:21:41 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 28 Aug 2009 05:21:41 -0400 Subject: [M3devel] CM3 on windows In-Reply-To: References: <20090828020144.B5E7C1A209A@async.async.caltech.edu> <20090828034057.475DD1A209A@async.async.caltech.edu> <20090828042715.B05E51A20A1@async.async.caltech.edu> <20090828045055.BA3C81A20A1@async.async.caltech.edu> Message-ID: <20090828092141.GB23396@topoi.pooq.com> On Fri, Aug 28, 2009 at 05:03:58AM +0000, Jay K wrote: > > Yes NT386GNU uses X. > Olaf expressed an interest in that. > Apparently the Windows port of Trestle has never been completed. > (I suspect we should punt Trestle and bind to Qt, but that is another > matter.) I've been wondering about that point with one of my applications -- Does Trestle have access to the underlying OS's fonts, or does it provide its own. I'm specifically thinking of the huge Unicode fonts, and suspect that Trestle doesn't has neither its own nor access to the OS's, on either Unix or WIndows. I happened to be wondering about gtk instead of qt, but that's a detail. Are there reasons I should be aware of for preferring one to the other? Portability or other? -- hendrik From jay.krell at cornell.edu Fri Aug 28 12:32:34 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Fri, 28 Aug 2009 06:32:34 -0400 Subject: [M3devel] CM3 on windows In-Reply-To: <20090828094553.hbdkyxsi8ss84oos@mail.elegosoft.com> References: <20090828020144.B5E7C1A209A@async.async.caltech.edu> <20090828094553.hbdkyxsi8ss84oos@mail.elegosoft.com> Message-ID: I'll have to double check but I thought Juno and mentor both worked a bunch. automation to really put them through their paces welcome. :) - Jay (phone) On Aug 28, 2009, at 3:45 AM, Olaf Wagner wrote: > I don't think Juno and mentor ever worked without an X server. > The Trestle implementation on Windows was never complete nor > stable enough for that AFAIK. > > Using the X implementation and an X server on Windows should work > though (but I haven't tried that for years with M3). > > Of course it would be great if somebody took care to fix the > Trestle ui package for Windows. > > Others please contradict me if I'm out of date here. > > Olaf > > Quoting Jay K : > >> >> I fixed the access on 5.8.2. >> Try that? >> I can poke around.. >> >> As I recall 5.8.1 used VC 8.0 and 5.8.2 used 9.0. >> If that helps. >> >> - Jay >> >> >> ---------------------------------------- >>> To: m3devel at elegosoft.com; jay.krell at cornell.edu >>> CC: mika at async.caltech.edu >>> Subject: CM3 on windows >>> Date: Thu, 27 Aug 2009 19:01:44 -0700 >>> From: mika at async.async.caltech.edu >>> >>> Hi m3devel, >>> >>> Not sure if my earlier message today went anywhere. I never saw it >>> on >>> the list. >>> >>> I'd like to try running CM3 on Windows 2000, so I've downloaded >>> >>> http://www.opencm3.com/uploaded-archives/cm3-std-NT386-d5.8.1.msi >>> >>> (5.8.2 didn't work---no access). >>> >>> Having installed it as well as I can figure, following the >>> directions at >>> >>> http://www.opencm3.com/installation-windows.html >>> >>> I don't really seem to get all the way. Compiling in the CMD >>> window fails >>> at a link (can't find winspool.lib), and the binaries have problems. >>> >>> Funnily enough, WebScape seems to work (as well or poorly as >>> anywhere else), >>> but mentor and Juno both fail miserably: >>> >>> >>> mika at scruff /cygdrive/c/cm3/bin >>> $ ./mentor >>> >>> >>> *** >>> *** runtime error: >>> *** Attempt to reference an illegal memory location. >>> *** pc = 0x1061634 = GetAttributes + 0x179 in ..\src\lego >>> \WIN32\ScrollerVBTCl >>> ass.m3 >>> *** >>> >>> Stack trace: >>> FP PC Procedure >>> --------- --------- ------------------------------- >>> 0x30af668 0x6a6e4d SystemError + 0x66 in ..\src\runtime >>> \NT386\RTSignal.m3 >>> 0x30af70c 0x1061634 GetAttributes + 0x179 in ..\src\lego >>> \WIN32\ScrollerVBTClas >>> s.m3 >>> 0x30af7e4 0x10993d8 AddView + 0x101e(!) in ..\src\lego >>> \ViewportVBT.m3 >>> 0x30af830 0x109743e Init + 0x30e in ..\src\lego\ViewportVBT.m3 >>> 0x30af950 0x1004ee0 pViewport + 0x512 in ..\src\FormsVBT.m3 >>> 0x30af9b0 0xff33df Item + 0x48b in ..\src\FormsVBT.m3 >>> 0x30af9dc 0x1010f66 OneChild + 0xf8 in ..\src\FormsVBT.m3 >>> 0x30afae4 0xff7448 pShape + 0x19c in ..\src\FormsVBT.m3 >>> 0x30afb44 0xff33df Item + 0x48b in ..\src\FormsVBT.m3 >>> 0x30afb70 0x1010f66 OneChild + 0xf8 in ..\src\FormsVBT.m3 >>> ......... ......... ... more frames ... >>> >>> mika at scruff /cygdrive/c/cm3/bin >>> $ ./Juno >>> >>> >>> *** >>> *** runtime error: >>> *** failed. >>> *** file "..\src\winvbt\WinContext.m3", line 165 >>> *** >>> >>> Stack trace: >>> FP PC Procedure >>> --------- --------- ------------------------------- >>> 0x1b6f854 0xea1e03 PushPixmap + 0x4cb in ..\src\winvbt\WinContext.m3 >>> 0x1b6f91c 0xeb10c7 PixmapCom + 0x9ed in ..\src\winvbt\WinPaint.m3 >>> 0x1b6fd78 0xeaedaf PaintBatch + 0x25f in ..\src\winvbt\WinPaint.m3 >>> 0x1b6fde4 0xea91f3 PaintBatchVBT + 0x13f in ..\src\winvbt >>> \WinTrestle.m3 >>> 0x1b6fe2c 0xea7919 WindowProc + 0x763 in ..\src\winvbt\WinTrestle.m3 >>> 0x1b6fe4c 0x77e3a454 >>> 0x1b6fed8 0x77e14605 >>> 0x1b6ff30 0x77e15b77 >>> 0x1b6ff88 0x4fb015 RunThread + 0x234 in ..\src\thread >>> \WIN32\ThreadWin32.m3 >>> 0x1b6ffb4 0x4fad57 ThreadBase + 0x3a in ..\src\thread >>> \WIN32\ThreadWin32.m3 >>> ......... ......... ... more frames ... >>> >>> mika at scruff /cygdrive/c/cm3/bin >>> $ >>> >>> This is running from the cygwin shell but it doesn't do anything >>> different >>> from CMD... >>> >>> Should I not expect to be able to get this to work? >>> >>> Mika > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ > any > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be > rlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > From jay.krell at cornell.edu Fri Aug 28 13:11:07 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Fri, 28 Aug 2009 07:11:07 -0400 Subject: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems In-Reply-To: <20090828101511.zsm14bsqow0k4w8o@mail.elegosoft.com> References: <20090826142644.r6yabwff5wc84cgg@mail.elegosoft.com> <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> <20090828101511.zsm14bsqow0k4w8o@mail.elegosoft.com> Message-ID: Olaf wrote: > > So we now have Windows packages on birch for RC3? No, not yet. > But I see that makedist is currently running... Seems like it got further and then the node disappeared and hasn't reappeared. :( - Jay (phone) From wagner at elegosoft.com Fri Aug 28 13:58:01 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 28 Aug 2009 13:58:01 +0200 Subject: [M3devel] CM3 on windows In-Reply-To: References: <20090828020144.B5E7C1A209A@async.async.caltech.edu> <20090828094553.hbdkyxsi8ss84oos@mail.elegosoft.com> Message-ID: <20090828135801.rja2kahis8wo8ocg@mail.elegosoft.com> Quoting jay.krell at cornell.edu: > I'll have to double check but I thought Juno and mentor both worked a > bunch. automation to really put them through their paces welcome. :) We don't have any support for testing GUI applications currently. I doubt that it will appear soon ;-) Olaf > - Jay (phone) > > On Aug 28, 2009, at 3:45 AM, Olaf Wagner wrote: > >> I don't think Juno and mentor ever worked without an X server. >> The Trestle implementation on Windows was never complete nor >> stable enough for that AFAIK. >> >> Using the X implementation and an X server on Windows should work >> though (but I haven't tried that for years with M3). >> >> Of course it would be great if somebody took care to fix the >> Trestle ui package for Windows. >> >> Others please contradict me if I'm out of date here. >> >> Olaf >> >> Quoting Jay K : >> >>> >>> I fixed the access on 5.8.2. >>> Try that? >>> I can poke around.. >>> >>> As I recall 5.8.1 used VC 8.0 and 5.8.2 used 9.0. >>> If that helps. >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> To: m3devel at elegosoft.com; jay.krell at cornell.edu >>>> CC: mika at async.caltech.edu >>>> Subject: CM3 on windows >>>> Date: Thu, 27 Aug 2009 19:01:44 -0700 >>>> From: mika at async.async.caltech.edu >>>> >>>> Hi m3devel, >>>> >>>> Not sure if my earlier message today went anywhere. I never saw it on >>>> the list. >>>> >>>> I'd like to try running CM3 on Windows 2000, so I've downloaded >>>> >>>> http://www.opencm3.com/uploaded-archives/cm3-std-NT386-d5.8.1.msi >>>> >>>> (5.8.2 didn't work---no access). >>>> >>>> Having installed it as well as I can figure, following the directions at >>>> >>>> http://www.opencm3.com/installation-windows.html >>>> >>>> I don't really seem to get all the way. Compiling in the CMD window fails >>>> at a link (can't find winspool.lib), and the binaries have problems. >>>> >>>> Funnily enough, WebScape seems to work (as well or poorly as >>>> anywhere else), >>>> but mentor and Juno both fail miserably: >>>> >>>> >>>> mika at scruff /cygdrive/c/cm3/bin >>>> $ ./mentor >>>> >>>> >>>> *** >>>> *** runtime error: >>>> *** Attempt to reference an illegal memory location. >>>> *** pc = 0x1061634 = GetAttributes + 0x179 in >>>> ..\src\lego\WIN32\ScrollerVBTCl >>>> ass.m3 >>>> *** >>>> >>>> Stack trace: >>>> FP PC Procedure >>>> --------- --------- ------------------------------- >>>> 0x30af668 0x6a6e4d SystemError + 0x66 in ..\src\runtime\NT386\RTSignal.m3 >>>> 0x30af70c 0x1061634 GetAttributes + 0x179 in >>>> ..\src\lego\WIN32\ScrollerVBTClas >>>> s.m3 >>>> 0x30af7e4 0x10993d8 AddView + 0x101e(!) in ..\src\lego\ViewportVBT.m3 >>>> 0x30af830 0x109743e Init + 0x30e in ..\src\lego\ViewportVBT.m3 >>>> 0x30af950 0x1004ee0 pViewport + 0x512 in ..\src\FormsVBT.m3 >>>> 0x30af9b0 0xff33df Item + 0x48b in ..\src\FormsVBT.m3 >>>> 0x30af9dc 0x1010f66 OneChild + 0xf8 in ..\src\FormsVBT.m3 >>>> 0x30afae4 0xff7448 pShape + 0x19c in ..\src\FormsVBT.m3 >>>> 0x30afb44 0xff33df Item + 0x48b in ..\src\FormsVBT.m3 >>>> 0x30afb70 0x1010f66 OneChild + 0xf8 in ..\src\FormsVBT.m3 >>>> ......... ......... ... more frames ... >>>> >>>> mika at scruff /cygdrive/c/cm3/bin >>>> $ ./Juno >>>> >>>> >>>> *** >>>> *** runtime error: >>>> *** failed. >>>> *** file "..\src\winvbt\WinContext.m3", line 165 >>>> *** >>>> >>>> Stack trace: >>>> FP PC Procedure >>>> --------- --------- ------------------------------- >>>> 0x1b6f854 0xea1e03 PushPixmap + 0x4cb in ..\src\winvbt\WinContext.m3 >>>> 0x1b6f91c 0xeb10c7 PixmapCom + 0x9ed in ..\src\winvbt\WinPaint.m3 >>>> 0x1b6fd78 0xeaedaf PaintBatch + 0x25f in ..\src\winvbt\WinPaint.m3 >>>> 0x1b6fde4 0xea91f3 PaintBatchVBT + 0x13f in ..\src\winvbt\WinTrestle.m3 >>>> 0x1b6fe2c 0xea7919 WindowProc + 0x763 in ..\src\winvbt\WinTrestle.m3 >>>> 0x1b6fe4c 0x77e3a454 >>>> 0x1b6fed8 0x77e14605 >>>> 0x1b6ff30 0x77e15b77 >>>> 0x1b6ff88 0x4fb015 RunThread + 0x234 in ..\src\thread\WIN32\ThreadWin32.m3 >>>> 0x1b6ffb4 0x4fad57 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3 >>>> ......... ......... ... more frames ... >>>> >>>> mika at scruff /cygdrive/c/cm3/bin >>>> $ >>>> >>>> This is running from the cygwin shell but it doesn't do anything different >>>> from CMD... >>>> >>>> Should I not expect to be able to get this to work? >>>> >>>> Mika >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Fri Aug 28 14:06:40 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 28 Aug 2009 14:06:40 +0200 Subject: [M3devel] elego-win-vm unreachable again Message-ID: <20090828140640.krinzx4ls0wco08w@mail.elegosoft.com> Hi Kay, why does the route/tunnel to elego-win-vm keep vanishing? There have been no reboots? [08/28/09 13:46:54] Launching slave agent $ ssh -p 2222 elego at localhost2 "java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=29999 -jar c:\cygwin\home\elego\slave.jar -text" ssh: connect to host localhost2 port 2222: Connection refused Unable to launch the slave agent for elego-win-vm java.io.EOFException: unexpected stream termination at hudson.remoting.Channel.(Channel.java:313) at hudson.remoting.Channel.(Channel.java:252) at hudson.slaves.SlaveComputer.setChannel(SlaveComputer.java:283) at hudson.slaves.CommandLauncher.launch(CommandLauncher.java:111) at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:175) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:619) Please check and install a watch script which rebuilds the tunnel when necessary. TIA, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Aug 28 12:30:20 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Fri, 28 Aug 2009 06:30:20 -0400 Subject: [M3devel] CM3 on windows In-Reply-To: <20090828092141.GB23396@topoi.pooq.com> References: <20090828020144.B5E7C1A209A@async.async.caltech.edu> <20090828034057.475DD1A209A@async.async.caltech.edu> <20090828042715.B05E51A20A1@async.async.caltech.edu> <20090828045055.BA3C81A20A1@async.async.caltech.edu> <20090828092141.GB23396@topoi.pooq.com> Message-ID: <726E21C8-625B-4B2C-8089-2038B9930AB5@hotmail.com> Fonts I don't know. I don't think gtk folks care much about windows. Qt folks do. - Jay (phone) On Aug 28, 2009, at 5:21 AM, hendrik at topoi.pooq.com wrote: > On Fri, Aug 28, 2009 at 05:03:58AM +0000, Jay K wrote: >> >> Yes NT386GNU uses X. >> Olaf expressed an interest in that. >> Apparently the Windows port of Trestle has never been completed. >> (I suspect we should punt Trestle and bind to Qt, but that is another >> matter.) > > I've been wondering about that point with one of my applications -- > Does > Trestle have access to the underlying OS's fonts, or does it provide > its > own. I'm specifically thinking of the huge Unicode fonts, and suspect > that Trestle doesn't has neither its own nor access to the OS's, on > either Unix or WIndows. > > I happened to be wondering about gtk instead of qt, but that's a > detail. > Are there reasons I should be aware of for preferring one to the > other? > Portability or other? > > -- hendrik > > From jay.krell at cornell.edu Fri Aug 28 13:33:45 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Fri, 28 Aug 2009 07:33:45 -0400 Subject: [M3devel] Change Pathname abstraction for Windows? was: RE: RC3 build problems, was: RE: caltech-parser NT386 Hudson problems In-Reply-To: <20090828102635.0iyxllukro8o44o4@mail.elegosoft.com> References: <20090826142644.r6yabwff5wc84cgg@mail.elegosoft.com> <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> <20090828102635.0iyxllukro8o44o4@mail.elegosoft.com> Message-ID: <17E1903E-EA50-4EF3-8273-C55B0FE1952C@hotmail.com> I believe this goes back to CP/M compatibility. I wish the file open dialogs accepted forward slashes. :( I will change cm3 to write back into quake state the canonicalized forms. I believe I already changed Pathname on Windows to accept either slash. I need to check if equality uses decomposed elements. Lots of folks just use strings and skip the abstraction, such as cm3. My personal programming often uses a small library over strings -- GetLastPathElement, RemoveLastElement, JoinPath, EnsureTrailingPathSeparator, ... IMHO you might as well also have posix allow backward slashes as separators, but that was rejected here. To wit I believe cygwin now accepts colons and backward slashes in paths, as non-separators. Interix also one or the other or both. Interix encodes them by oring in 0xFF00 (what happens with Samba to ext3??) There are other issues such as case sensivity not being an OS-wide thing but per volume or directory (NTFS has mount points, directories can lead to volumes, with different filesystems) as well as just what the case mapping tables are (written to NTFS volume at time of format, presumably can vary). The Mac historically used colon as separator and allowed forward slash as non separator. Presumably hidden through some encoding/decoding at the posix layer? - Jay (phone) On Aug 28, 2009, at 4:26 AM, Olaf Wagner wrote: > Quoting Jay K : > >> It was backslashes vs. forward slashes as I had originally suspected. >> My debugprinting never hit because I was guessing the elego paths >> wrong. >> I finally made it always print and tested it in-situ in the VM. > > It is amazing how much (pointless) work the difference in pathname > denotations on Windows and POSIX systems has caused and still causes. > While there are some conceptual differences that cannot easily be > generalized (one root <-> many roots, logical <-> physical view of > disks etc.), the simple fact that Windows uses \ instead of / > makes life needlessly difficult for many programmers. > > In Modula-3, the Pathname interface is intended to abstract from > this, but this works only to a certain degree. It uses \ as the > arc separator on Windows, while in fact all modern Windows systems > accept both \ and /. I think this should be corrected. > > Pathnames should be split into elements at both \ and / on Windows, > and checks for equality should ignore any differences in separator > characters only. Does this sound reasonable? > > Is there any (non)obvious problem I'm overseeing right now which > will make this strategy fail? > > Olaf > > PS: I'm not suggesting we do that in this release of course... > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ > any > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be > rlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > From hosking at cs.purdue.edu Fri Aug 28 15:44:14 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 28 Aug 2009 09:44:14 -0400 Subject: [M3devel] small design problem in ButtonVBT? In-Reply-To: <20090828091150.GA23396@topoi.pooq.com> References: <20090331145127.GB9624@topoi.pooq.com> <20090401120347.x8cneize8oscg44o@mail.elegosoft.com> <20090826002606.GB16386@topoi.pooq.com> <20090827141741.9g1u2vrgfgokkksg@mail.elegosoft.com> <20090828031722.GB22883@topoi.pooq.com> <36DAB001-70F3-4C96-B1D5-57E8A7322464@cs.purdue.edu> <20090828091150.GA23396@topoi.pooq.com> Message-ID: <570C6C84-C41D-446E-A43C-13F85F1C378C@cs.purdue.edu> Yes, exactly! I don't think the change is needed and goes against the grain of a pervasive design principle. We might question that decision, but I hesitate to apply a piecemeal tweak that violates the principle. On 28 Aug 2009, at 05:11, hendrik at topoi.pooq.com wrote: > On Thu, Aug 27, 2009 at 11:53:27PM -0400, Tony Hosking wrote: >> Right. Plus, overriding copies the entire method suite for the new >> type. > > Now that makes sense. I'll re-evaluate my suggestion in this light. > >> >> On 27 Aug 2009, at 23:28, Jay K wrote: >> >>> >>> I think I know the reason it is this way. >>> It is very common to override action and nothing else. >>> It is "inconvenient" to derive a new type, just to change one >>> function. > > It's more a matter of letting the action procedure or method have > clean > access to application data in the subclassed function. But your code > suggests a simpler way to do this than either your code or mine. It > takes a run-time type check, which is conceptually messy. But the > code > is smaller, and seems to have a smaller memory footprint. > > See below. > >>> >>> - Jay >>> >>> ---------------------------------------- >>>> Date: Thu, 27 Aug 2009 23:17:23 -0400 >>>> From: hendrik at topoi.pooq.com >>>> To: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] small design problem in ButtonVBT? >>>> >>>> On Thu, Aug 27, 2009 at 03:15:41PM -0400, Tony Hosking wrote: >>>>> I am nervous about having the two alternative entries to the >>>>> action >>>>> procedure that other code might not be aware of. Yes, you've >>>>> modified >>>>> the default mouse method to call the action method instead of the >>>>> procedure, but what about other places where the mouse method has >>>>> been >>>>> overridden. > > Yes. That could be an issue. But only if act is also overridden, > which > won't happen in legacy code, since the defauly act behaves identically > to the action procedure. > >>>>> >>>>> If you want to be smart about it in your own code you can simply >>>>> invert your suggestion and do the following: >>>>> >>>>> TYPE T = ButtonVBT.T OBJECT >>>>> METHODS action(cd: VBT.MouseRec) := Action; >>>>> >>>>> PROCEDURE Action(v: T; cd: VBT.MouseRec) = ... >>>>> >>>>> PROCEDURE ActionProc(v: ButtonVBT.T; cd: VBT.MouseRec) = >>>>> BEGIN >>>>> NARROW(v, T).action(cd); >>>>> END ActionProc; >>>>> >>>>> and initialize your T thingy with ButtonVBT.New(..., action := >>>>> ActionProc; ...) >>>>> >>>>> Then in your code you can go ahead and override the action >>>>> method to >>>>> your hearts content. > > But I can simplify this further. > > TYPE T = ButtonVBT.T OBJECT (* as you propose. *) > > For each action that I had wanted a subclass for, write > > PROCEDURE Action(vv: T; cd: VBT.MouseRec) = ... > VAR v : T; > BEGIN > v := NARROW(vv, T); > ... normal code for performing the action > END Action; > > and initialize my T thingy using this Action. > > So instead of multiple subclasses to get the various actions, I get > two > extra lines of code in each action procedure. And I don't have to use > GetProp or PutProp (which probably involve some kind of search). The > run-time cost is the type-check in the NARROW(vv, T), which is > probably > cheaper than a method-dispatch on act. > > Hmmm. I'm starting to think you're right, and my change is > unnecessary. > > I'll have a look in my applicatin code, and see if there are further > glitches. I'm not expecting any. > > -- hendrik > >>>> >>>> This kind of thing would work. But, like the existing semantics of >>>> ButtonVBT, it seems to be fighting the language instead of working >>>> with >>>> it. I'd be happiest to get rid of the action variable altogether, >>>> but >>>> that would be a massively incompatible change, and would require >>>> change >>>> to a lot of existing code. What I proposed is compatible with >>>> existing >>>> code, and also has the advantage that someone who subclasses >>>> ButtonVBT.T >>>> and overrides act can completely ignore the action variable >>>> altogether. >>>> >>>> You say >>>> >>>>> and initialize your T thingy with ButtonVBT.New(..., action := >>>>> ActionProc; ...) >>>> >>>> But that requires every object I make of type T or any sibclass >>>> to be >>>> explicitly initialised with ActionProc, certainly a nuisance, and >>>> certainly error-prone. >>>> >>>> The inelegance I see with my approach is that there are two >>>> mechanisms >>>> for specifying the action to be taken. Either will work without the >>>> programmer paying any attention to the other, but if you use both, >>>> one >>>> will override the other. This is not a problem with legacy >>>> software. >>>> I'll have to come up with some documentation that makes this clear. >>>> It's the inelegance that comes from backward compatibility, and I >>>> think >>>> my solution is less inelegant, and easier to use, than yours. >>>> Yours, >>>> however, involves no change in existing code. >>>> >>>>> >>>>> Am I just being paranoid? >>>> >>>> No. Perhaps just paranoid about different things. >>>> >>>> I had hoped for someone to come up with a solid technical reason >>>> for the >>>> action variable. The original designers were clever people, and I'd >>>> *still* like to know why they thought it was a good idea. It's >>>> awkward >>>> and error-prone to use, and they had to use the PutProp/GetProp >>>> kludge >>>> just to approximate what the language provided for free with >>>> inheritance. >>>> >>>> I'm tempted to go over the entire code-base and change the >>>> buttons to >>>> use act instead of action, but I have to admit I'm not tempted >>>> enough to >>>> actually do it... >>>> >>>> -- hendrik >>>> >>>>> On 27 Aug 2009, at 08:17, Olaf Wagner wrote: >>>>> >>>>>> Though I promised to do it, I have lost sight of this task while >>>>>> trying to build some RC3 archives on Windows. As I'm not at home >>>>>> this >>>>>> evening, can somebody else please commit Hendrik's extension? >>>>>> >>>>>> Is this something we should should have in the release branch, >>>>>> too? >>>>>> Probably not necessary? >>>>>> >>>>>> Olaf >>>>>> >>>>>> Quoting hendrik at topoi.pooq.com: >>>>>> >>>>>>> On Wed, Apr 01, 2009 at 12:03:47PM +0200, Olaf Wagner wrote: >>>>>>>> Quoting hendrik at topoi.pooq.com: >>>>>>>> >>>>>>>>> The BottonVBT contains an action, which is a procedure rather >>>>>>>> than a >>>>>>>>> method. b This makes it awkward to subclass ButtonVBT becaue >>>>>>>>> the >>>>>>>> action >>>>>>>>> will still expect its first parameter to be a ButtonVBT >>>>>>>>> instead of >>>>>>>>> belonging to the subclass, and an explicit downcast of some >>>>>>>>> sort >>>>>>>> will be >>>>>>>>> needed to acess the subclass's members. >>>>>>>>> >>>>>>>>> The Trestle manual says this was a deliberate decision: >>>>>>>>> >>>>>>>>> : The action procedure is a field rather than a method in >>>>>>>>> order >>>>>>>> to allow >>>>>>>>> : buttons with different action procedures to share their >>>>>>>>> method >>>>>>>> suites. >>>>>>>>> >>>>>>>>> I, however, find it massively inconvenient because it mans I >>>>>>>>> have >>>>>>>> to >>>>>>>>> resort to downcasting or the very kludgey VBT.GetProp to >>>>>>>>> access >>>>>>>> what >>>>>>>>> should be just there. I'd rather the action procedure was a >>>>>>>> method. >>>>>>>>> >>>>>>>>> But it should be possible to have the best of both worlds. >>>>>>>>> Have an >>>>>>>>> action2 (better name wanted here) method that is available for >>>>>>>>> overriding, and by default calls the procedure in the existing >>>>>>>> action. >>>>>>>>> field. That action2 method wounl then be called by Trestle >>>>>>>> wherever >>>>>>>>> action is now called. >>>>>>>>> >>>>>>>>> Does anyone see problems with this? >>>>>>>> >>>>>>>> Sounds fine to me offhand. You should test your extensions with >>>>>>>> some of the existing larger applications, like mentor and >>>>>>>> Juno-2, >>>>>>>> of course. >>>>>>> >>>>>>> OK. Here's the patch. Would it be possible for someone to >>>>>>> check it >>>>>>> in >>>>>>> for me? >>>>>>> >>>>>>> mentor runs fine with this change; I watched it animate a heap- >>>>>>> sort. >>>>>>> >>>>>>> I have no idea what Juno is supposed to do, but it did respond >>>>>>> to >>>>>>> button-pushes. >>>>>>> >>>>>>> >>>>>>> hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ cvs diff >>>>>>> cvs diff: Diffing . >>>>>>> Index: ButtonVBT.i3 >>>>>>> = >>>>>>> = >>>>>>> = >>>>>>> ================================================================ >>>>>>> RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.i3,v >>>>>>> retrieving revision 1.2 >>>>>>> diff -r1.2 ButtonVBT.i3 >>>>>>> 39a40 >>>>>>>> act(READONLY cd: VBT.MouseRec); >>>>>>> Index: ButtonVBT.m3 >>>>>>> = >>>>>>> = >>>>>>> = >>>>>>> ================================================================ >>>>>>> RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.m3,v >>>>>>> retrieving revision 1.2 >>>>>>> diff -r1.2 ButtonVBT.m3 >>>>>>> 28c28,29 >>>>>>> < init := Be >>>>>>> --- >>>>>>>> init := Be; >>>>>>>> act := act >>>>>>> 46a48,52 >>>>>>>> PROCEDURE act(v : T; READONLY cd: VBT.MouseRec) = >>>>>>>> BEGIN >>>>>>>> v.action(v, cd); >>>>>>>> END act; >>>>>>>> >>>>>>> 59c65 >>>>>>> < v.action(v, cd); >>>>>>> --- >>>>>>>> v.act(cd); >>>>>>> hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ >>>>>>> >>>>>>> -- hendrik >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>>>>> Germany >>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>>>> 45 86 95 >>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>>>>> Berlin >>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>>> DE163214194 >>>>>> >>>>> >> From rodney.m.bates at cox.net Fri Aug 28 15:35:17 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Fri, 28 Aug 2009 08:35:17 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20090828025553.5272F2474002@birch.elegosoft.com> References: <20090828025553.5272F2474002@birch.elegosoft.com> Message-ID: <4A97DD15.1030907@cox.net> Whenever I write/add code, in any language, I am in the habit of always surrounding every identifier with at least one blank, before and after. Otherwise, grepping for all occurrences of an identifier is a nightmare. You usually get overwhelmed with false hits where the identifier you want is a substring of others. This is extremely common. On the other hand, surrounding your search string with the Cartesian product of all the characters that could conceivably surround identifiers in code is a different kind of nightmare, and can fail to find important hits. Combinations of grep piped to grep -v with wild cards, gets closer, but that's a big pain too. (Hmm, maybe sometime I should try to script that.) Starting decades ago, I have wished every string-searching function had some kind of metacharacter to mean "at beginning of identifier" and "at end of identifier". It wouldn't be that hard, and the rules are so very close to language-independent. But, AFAIK, it has never happened. Not that adding the blanks in m3gdb mattered much, since my additions and modifications to it are a tiny subset of what is there. And the surrounding-with-blanks idea only works if you know for certain it has been done everywhere. Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/08/28 04:55:49 > > Modified files: > cm3/m3-sys/m3gdb/gdb/gdb/: Tag: release_branch_cm3_5_8 m3-eval.c > m3-exp.c m3-lang.c m3-threads.c > m3-util.c m3-valprint.c > cm3/m3-sys/m3gdb/gdb/gdb/save/: Tag: release_branch_cm3_5_8 > m3-lang.c m3-lang.h > m3-valprint.c > > Log message: > fix more pointless and inconsistent formating -- spaces before semicolons > > > From wagner at elegosoft.com Fri Aug 28 16:35:32 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 28 Aug 2009 16:35:32 +0200 Subject: [M3devel] Windows packages for RC3 Message-ID: <20090828163532.mtbood3o2ssckogo@mail.elegosoft.com> Now finally the packages have been built, but not copied to birch: /usr/bin/ssh: No such file or directory lost connection This is getting ridiculous. If there wasn't an ssh there would be no connection at all, and it has been explicitly checked before. I'll try to copy the packages manually later when I'm at home. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Fri Aug 28 16:35:39 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 28 Aug 2009 10:35:39 -0400 Subject: [M3devel] small design problem in ButtonVBT? In-Reply-To: <570C6C84-C41D-446E-A43C-13F85F1C378C@cs.purdue.edu> References: <20090331145127.GB9624@topoi.pooq.com> <20090401120347.x8cneize8oscg44o@mail.elegosoft.com> <20090826002606.GB16386@topoi.pooq.com> <20090827141741.9g1u2vrgfgokkksg@mail.elegosoft.com> <20090828031722.GB22883@topoi.pooq.com> <36DAB001-70F3-4C96-B1D5-57E8A7322464@cs.purdue.edu> <20090828091150.GA23396@topoi.pooq.com> <570C6C84-C41D-446E-A43C-13F85F1C378C@cs.purdue.edu> Message-ID: <20090828143539.GA23965@topoi.pooq.com> On Fri, Aug 28, 2009 at 09:44:14AM -0400, Tony Hosking wrote: > Yes, exactly! I don't think the change is needed and goes against the > grain of a pervasive design principle. We might question that > decision, but I hesitate to apply a piecemeal tweak that violates the > principle. Care to state that pervasive design principle? Whatever it is, Modula 3 seems to have done well by it. -- hendrik From jay.krell at cornell.edu Fri Aug 28 16:58:25 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Fri, 28 Aug 2009 10:58:25 -0400 Subject: [M3devel] Change Pathname abstraction for Windows? was: RE: RC3 build problems, was: RE: caltech-parser NT386 Hudson problems In-Reply-To: <20090828102635.0iyxllukro8o44o4@mail.elegosoft.com> References: <20090826142644.r6yabwff5wc84cgg@mail.elegosoft.com> <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> <20090828102635.0iyxllukro8o44o4@mail.elegosoft.com> Message-ID: <5C022EFA-8D3E-49CF-9867-2D39AF515B78@hotmail.com> (including m3devel this time) I believe this goes back to CP/M compatibility. I wish the file open dialogs accepted forward slashes. :( I will change cm3 to write back into quake state the canonicalized forms. I believe I already changed Pathname on Windows to accept either slash. I need to check if equality uses decomposed elements. Lots of folks just use strings and skip the abstraction, such as cm3. My personal programming often uses a small library over strings -- GetLastPathElement, RemoveLastElement, JoinPath, EnsureTrailingPathSeparator, ... IMHO you might as well also have posix allow backward slashes as separators, but that was rejected here. To wit I believe cygwin now accepts colons and backward slashes in paths, as non-separators. Interix also one or the other or both. Interix encodes them by oring in 0xFF00 (what happens with Samba to ext3??) There are other issues such as case sensivity not being an OS-wide thing but per volume or directory (NTFS has mount points, directories can lead to volumes, with different filesystems) as well as just what the case mapping tables are (written to NTFS volume at time of format, presumably can vary). The Mac historically used colon as separator and allowed forward slash as non separator. Presumably hidden through some encoding/decoding at the posix layer? - Jay (phone) On Aug 28, 2009, at 4:26 AM, Olaf Wagner wrote: > Quoting Jay K : > >> It was backslashes vs. forward slashes as I had originally suspected. >> My debugprinting never hit because I was guessing the elego paths >> wrong. >> I finally made it always print and tested it in-situ in the VM. > > It is amazing how much (pointless) work the difference in pathname > denotations on Windows and POSIX systems has caused and still causes. > While there are some conceptual differences that cannot easily be > generalized (one root <-> many roots, logical <-> physical view of > disks etc.), the simple fact that Windows uses \ instead of / > makes life needlessly difficult for many programmers. > > In Modula-3, the Pathname interface is intended to abstract from > this, but this works only to a certain degree. It uses \ as the > arc separator on Windows, while in fact all modern Windows systems > accept both \ and /. I think this should be corrected. > > Pathnames should be split into elements at both \ and / on Windows, > and checks for equality should ignore any differences in separator > characters only. Does this sound reasonable? > > Is there any (non)obvious problem I'm overseeing right now which > will make this strategy fail? > > Olaf > > PS: I'm not suggesting we do that in this release of course... > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ > any > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be > rlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Aug 28 18:44:34 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Fri, 28 Aug 2009 12:44:34 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <4A97DD15.1030907@cox.net> References: <20090828025553.5272F2474002@birch.elegosoft.com> <4A97DD15.1030907@cox.net> Message-ID: <9DA06850-DE99-4D69-A1E2-91DADDF38312@hotmail.com> Perl regexp has word boundary notion. Visual C++ 5.0 find-in-files feature, which overall is an excellent feature, has a "whole word" option. - Jay (phone) On Aug 28, 2009, at 9:35 AM, "Rodney M. Bates" wrote: > Whenever I write/add code, in any language, I am in the habit of > always surrounding > every identifier with at least one blank, before and after. > Otherwise, grepping > for all occurrences of an identifier is a nightmare. You usually > get overwhelmed > with false hits where the identifier you want is a substring of > others. > This is extremely common. > > On the other hand, surrounding your search string with the Cartesian > product of all the characters that could conceivably surround > identifiers > in code is a different kind of nightmare, and can fail to find > important > hits. Combinations of grep piped to grep -v with wild cards, gets > closer, > but that's a big pain too. (Hmm, maybe sometime I should try to > script > that.) > > Starting decades ago, I have wished every string-searching function > had > some kind of metacharacter to mean "at beginning of identifier" and > "at end of identifier". It wouldn't be that hard, and the rules are > so very > close to language-independent. But, AFAIK, it has never happened. > > Not that adding the blanks in m3gdb mattered much, since my additions > and modifications to it are a tiny subset of what is there. And the > surrounding-with-blanks idea only works if you know for certain it has > been done everywhere. > > Jay Krell wrote: >> CVSROOT: /usr/cvs >> Changes by: jkrell at birch. 09/08/28 04:55:49 >> >> Modified files: >> cm3/m3-sys/m3gdb/gdb/gdb/: Tag: release_branch_cm3_5_8 m3- >> eval.c m3-exp.c m3-lang.c m3- >> threads.c m3-util.c m3-valprint.c >> cm3/m3-sys/m3gdb/gdb/gdb/save/: Tag: >> release_branch_cm3_5_8 m3-lang.c >> m3-lang.h m3-valprint.c >> Log message: >> fix more pointless and inconsistent formating -- spaces before >> semicolons >> >> >> > > From hosking at cs.purdue.edu Fri Aug 28 18:44:48 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 28 Aug 2009 12:44:48 -0400 Subject: [M3devel] small design problem in ButtonVBT? In-Reply-To: <20090828143539.GA23965@topoi.pooq.com> References: <20090331145127.GB9624@topoi.pooq.com> <20090401120347.x8cneize8oscg44o@mail.elegosoft.com> <20090826002606.GB16386@topoi.pooq.com> <20090827141741.9g1u2vrgfgokkksg@mail.elegosoft.com> <20090828031722.GB22883@topoi.pooq.com> <36DAB001-70F3-4C96-B1D5-57E8A7322464@cs.purdue.edu> <20090828091150.GA23396@topoi.pooq.com> <570C6C84-C41D-446E-A43C-13F85F1C378C@cs.purdue.edu> <20090828143539.GA23965@topoi.pooq.com> Message-ID: <2B370785-C8C1-4964-87DC-5EF3B839B898@cs.purdue.edu> I meant the principle articulated for use of a procedure instead of a method for ButtonVBT. On 28 Aug 2009, at 10:35, hendrik at topoi.pooq.com wrote: > On Fri, Aug 28, 2009 at 09:44:14AM -0400, Tony Hosking wrote: >> Yes, exactly! I don't think the change is needed and goes against >> the >> grain of a pervasive design principle. We might question that >> decision, but I hesitate to apply a piecemeal tweak that violates the >> principle. > > Care to state that pervasive design principle? Whatever it is, > Modula 3 > seems to have done well by it. > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Aug 29 13:36:37 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 29 Aug 2009 13:36:37 +0200 Subject: [M3devel] RC3 status and open tickets Message-ID: <20090829133637.49ywpog80ggwsogs@mail.elegosoft.com> There have been many problems again building the release archives on some platforms, especially NT386 and Solaris, but there is progress. The SOLgnu packages seem to be OK now, but the SOLsun packages are still all more or less broken. You can find the results of installation tests at http://hudson.modula3.com:8080/view/test-install/ Several build machines we used in RC2 are still not available (traveling on Jay's new computer ;-); those will be added later. Build and other regression test results are in http://hudson.modula3.com:8080/ There are still many open tickets regarding RC3 https://projects.elego.de/cm3/query?status=resolved&status=reopened&status=assigned&status=analyzed&status=new&status=accepted&group=status&milestone=CM3+Release+5.8+RC3 and the final 5.8 release: https://projects.elego.de/cm3/query?status=resolved&status=reopened&status=assigned&status=analyzed&status=new&status=accepted&group=status&milestone=CM3+release+5.8 Help in analyzing and resolving them is very welcome. I'll be on vacation for two weeks to the south of France, and won't be able to do anything for CM3 then (leaving my laptop behind ;-). I think it is unrealistic that the final release is availble until then, but I hope that we at least have a more or less stable RC3. Thanks for your patience and support, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Sat Aug 29 23:51:06 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 29 Aug 2009 23:51:06 +0200 Subject: [M3devel] tinderbox failures: undefined variables in quake Message-ID: <20090829235106.lb9zq4ouo8kcckgs@mail.elegosoft.com> Several release builds fail with undefined variables in quake now (this is probably in the trunk I assume). Who broke this now? Is it just missing backward compatibility or a more serious problem? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sun Aug 30 00:24:53 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Sat, 29 Aug 2009 17:24:53 -0500 Subject: [M3devel] tinderbox failures: undefined variables in quake In-Reply-To: <20090829235106.lb9zq4ouo8kcckgs@mail.elegosoft.com> References: <20090829235106.lb9zq4ouo8kcckgs@mail.elegosoft.com> Message-ID: <4AC5146C-68FE-40F0-828C-462428AF8E6F@hotmail.com> Tinderbox head or Hudson release? Either way probably me I can look tonight. - Jay (phone) On Aug 29, 2009, at 4:51 PM, Olaf Wagner wrote: > Several release builds fail with undefined variables in quake now > (this is probably in the trunk I assume). > > Who broke this now? Is it just missing backward compatibility > or a more serious problem? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ > any > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be > rlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > From jay.krell at cornell.edu Sun Aug 30 11:05:33 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 30 Aug 2009 09:05:33 +0000 Subject: [M3devel] cminstall too many errors if not root, in fact maybe infinite Message-ID: It bugs me how many packages there are -- too much to test. So I'll test just a few. Starting with cm3-bin-min-SOLsun-5.8.3-RC3.tgz: ./cminstall => endless stream of Unable to create directory: /usr/local/cm3 ./cminstall | wc -l => I've been waiting a while and it hasn't terminated. As I've said before, cminstall doesn't do much and doesn't do it well. Granted, claiming that nothing is needed here is a stretch. If I go ahead and in another console as root mkdir /usr/local, no progress. mkdir /usr/local/cm3. Then it stops with: Unexpected problem: Unable to open the log file: /usr/local/cm3/Install.log: errno=13 Please feel free to contact m3-support at elego.de to troubleshoot this problem. Now, I understand that refusing to run as non-root is not the solution. -bash-3.00$ ./cminstall --help Unexpected problem: Unrecognized option: --help Please feel free to contact m3-support at elego.de to troubleshoot this problem. I'll fix that. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Aug 30 11:11:20 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 30 Aug 2009 09:11:20 +0000 Subject: [M3devel] cminstall says too much Message-ID: cminstall is really not so great. Here is one criticism -- it says too much. -bash-3.00$ ./cminstall Thank you for using Critical Mass CM3. This program will configure and install the system. cminstall_root is set to /home/jay/t/min If this is not correct, please restart the installer with -root [Jay Is it ever wrong? Must it always be reported?] If the installer runs interactively, it will ask you some questions about the locations of programs and libraries. Usually it will display a default inside [], which can be accepted with . If the installer has found several choices, you may cycle through them with `+' or `.' for the next and `-' for the previous one. You may of course also enter a completely different value. [I didn't run it interactively. Why tell me all this?] Installing CM3 in: /usr/local/cm3 This may take a few minutes... CM3 is now installed. Before you begin, here's a few reminders: 1) The CM3 compiler executable is in: /usr/local/cm3/bin/cm3 You may need to modify your PATH environment variable to find it. And on Unix, you may need to type "rehash" to your shell. 2) CM3's shared libraries and any you create and ship are in: /usr/local/cm3/lib On some Unix systems you may need to set the LD_LIBRARY_PATH (on Darwin / MacOS X it's called DYLD_LIBRARY_PATH) environment variable before running programs that use these shared libraries (usually not necessary). [This applies to almost no systems, esp. the Mac part.] 3) Your system configuration file is: /usr/local/cm3/bin/cm3.cfg At any point in time, you may edit it to modify or update your installation. 4) A copy of this installation dialogue is in: /usr/local/cm3/Install.log [dialogue for non-interactive installs?] 5) If you had trouble with this installation or need more assistance, please send us a transcript of this installation via e-mail at "m3-support at elego.de". Thank you. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Aug 30 13:00:00 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 30 Aug 2009 11:00:00 +0000 Subject: [M3devel] RandomTest runtime error FileWr.Error not in Raises list Message-ID: I think this is two or three problems. - missing raises - why does it raise - why does it hang Often but not always: jay at xlin2:/dev2/release_branch_cm3_5_8/m3-libs/libm3/tests/random$ pwd /dev2/release_branch_cm3_5_8/m3-libs/libm3/tests/random jay at xlin2:/dev2/release_branch_cm3_5_8/m3-libs/libm3/tests/random$ ./LINUXLIBC6 /RandomTest -perm under gdb: *** *** runtime error: *** Exception "FileWr.Error" not in RAISES list *** file "../src/rw/FileWr.m3", line 81 *** Program received signal SIGABRT, Aborted. [Switching to Thread -1210370368 (LWP 21415)] 0xb7f25410 in ?? () (gdb) bt #0 0xb7f25410 in ?? () #1 0xbfc4f14c in ?? () #2 0x00000006 in ?? () #3 0x000053a7 in ?? () #4 0xb7ddc811 in raise () from /lib/tls/i686/cmov/libc.so.6 #5 0xb7dddfb9 in abort () from /lib/tls/i686/cmov/libc.so.6 #6 0x0808bb12 in RTOS__Crash () at ../src/runtime/POSIX/RTOS.m3:20 #7 0x08085d83 in RTProcess__Crash (M3_Bd56fi_msg=0x0) at ../src/runtime/common/RTProcess.m3:65 #8 0x08083a8e in RTError__EndError (M3_AicXUJ_crash=1 '\001') at ../src/runtime/common/RTError.m3:118 #9 0x08083752 in RTError__MsgS (M3_AJWxb1_file=0x80c437c, M3_AcxOUs_line=81, M3_Bd56fi_msgA=0x80cc350, M3_Bd56fi_msgB=0xb7d7eba0, M3_Bd56fi_msgC=0x80cc378) at ../src/runtime/common/RTError.m3:40 #10 0x08083ef6 in RTException__Crash (M3_Cblw37_a=0xbfc4f460, M3_AicXUJ_raises=1 '\001', M3_AJWxb1_rte=0x80c8400) at ../src/runtime/common/RTException.m3:79 #11 0x08083c5f in RTException__DefaultBackstop (M3_Cblw37_a=0xbfc4f460, M3_AicXUJ_raises=0 '\0') at ../src/runtime/common/RTException.m3:41 #12 0x08083b59 in RTException__InvokeBackstop (M3_Cblw37_a=0xbfc4f460, M3_AicXUJ_raises=0 '\0') at ../src/runtime/common/RTException.m3:25 #13 0x0808c5a8 in RTException__Raise (M3_Cblw37_act=0xbfc4f460) at ../src/runtime/ex_frame/RTExFrame.m3:29 #14 0x08083cb6 in RTException__DefaultBackstop (M3_Cblw37_a=0xbfc4f460, ---Type to continue, or q to quit--- M3_AicXUJ_raises=1 '\001') at ../src/runtime/common/RTException.m3:47 #15 0x08083b59 in RTException__InvokeBackstop (M3_Cblw37_a=0xbfc4f460, M3_AicXUJ_raises=1 '\001') at ../src/runtime/common/RTException.m3:25 #16 0x0808c689 in RTException__Raise (M3_Cblw37_act=0xbfc4f460) at ../src/runtime/ex_frame/RTExFrame.m3:51 #17 0x08073e99 in RTHooks__Raise (M3_AJWxb1_ex=0x80c42a0, M3_AJWxb1_arg=0x0, M3_AJWxb1_module=0x80c43e0, M3_AcxOUs_line=81) at ../src/runtime/common/RTHooks.m3:79 #18 0x0806a9c4 in FileWr__Seek (M3_EJV0jI_wr=0xb7d73234, M3_Cwb5VA_n=4198) at ../src/rw/FileWr.m3:81 #19 0x080559ea in AutoFlushWr__Seek (M3_Aauo9c_wr=0xb7d790a4, M3_Cwb5VA_n=4198) at ../src/rw/AutoFlushWr.m3:106 #20 0x080544bf in WrClass__PutStringDefault (M3_BxxOH1_wr=0xb7d790a4, M3_CKMnXU_a=0xbfc4f7f4) at ../src/rw/Wr.m3:193 #21 0x080539de in UnsafeWr__FastPutText (M3_BxxOH1_wr=0xb7d790a4, M3_Bd56fi_t=0xb7d7eb84) at ../src/rw/Wr.m3:105 #22 0x08053837 in Wr__PutText (M3_BxxOH1_wr=0xb7d790a4, M3_Bd56fi_t=0xb7d7eb84) at ../src/rw/Wr.m3:93 #23 0x0804f561 in RandomTest__TestPerm () at ../src/RandomTest.m3:387 #24 0x0804bedf in RandomTest__Main () at ../src/RandomTest.m3:64 #25 0x08050235 in RandomTest_M3 (M3_AcxOUs_mode=1) at ../src/RandomTest.m3:458 #26 0x08082bf8 in RTLinker__RunMainBody (M3_DjPxE3_m=0x80be120) at ../src/runtime/common/RTLinker.m3:399 #27 0x08081fb2 in RTLinker__AddUnitI (M3_DjPxE3_m=0x80be120) ---Type to continue, or q to quit--- at ../src/runtime/common/RTLinker.m3:113 #28 0x08082040 in RTLinker__AddUnit (M3_DjPxE5_b=0x8050165) at ../src/runtime/common/RTLinker.m3:122 #29 0x0804baee in main (argc=2, argv=0xbfc4fe94, envp=0xbfc4fea0) at _m3main.mc:4 (gdb) This test hangs on OpenBSD/x86. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun Aug 30 22:33:23 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 30 Aug 2009 22:33:23 +0200 Subject: [M3devel] RC3 Message-ID: <20090830223323.qpwzvxkdckw0o480@mail.elegosoft.com> Though there are still several open problem, I suggest that we now stop making changes to the codebase for RC3 and retarget the issues to the final release. This means * We do not move the tag for RC3 any further (except perhaps for some make-dist scripts which need some tweaking but have no direct impact on cm3) * Exception is the addition of the native installation archives for NT386 * We continue adding installation archives for new platforms The installation archives should be much better than RC2. All further improvements and fixes go into the final release (or RC4). We should also announce the availability of RC3 outside of m3devel. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Aug 31 03:10:55 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 31 Aug 2009 01:10:55 +0000 Subject: [M3devel] how to find cm3.cfg Message-ID: how to find cm3.cfg I propose, in this order: - -config or --config switch (actually any number of dashes) - $M3_CONFIG environment variable (however it is already spelled) This is a preferably path to a specific file, not some directory to further probe. I'll have to check the current implementation though. It might be a directory containing cm3.cfg as well. Whatever it currently does is how it should likely stay. - cm3.cfg next to executable, be it cm3.exe, cm3ide.exe, etc. - possibly one other choice, if none of the above exist, and executable is not cm3/cm3.exe, then search $PATH for cm3/cm3.exe and use cm3.cfg next to it This includes NOT looking in: - /etc - current directory - $PATH in general One problem is, you can't really directly/easily even find the current executable in Posix. I'll do more research on this. It is easy in Win32 and I assume Mac. Otherwise will probably fall back to: I believe everyone's best effort here is looking at argv[0] and if that isn't a full or current working directory relative path, search $PATH. Any other search should be layerable upon this. That is, cm3.cfg can include(/etc/cm3.cfg) or such. One thing not accounted for here is a --target command line option. Given the current layout and code, that doesn't work out well. Specifically, using config/target wouldn't set INSTALL_ROOT correctly. --target could set $TARGET and cm3.cfg could include config/target if target is already set. Or cm3 could set INSTALL_ROOT itself. We could look for next-to-executable/target.cfg. I think I'll punt on all this for now -- any accomodation of --target on command line. I think this change should probably go in this release, given that there was another change already that this undoes and given th bug I found regarding running by relative path (granted, I should debug that before replacing the code). Or, I guess, at the very least, remove the new probes and fix the bug I found. I guess. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Aug 31 09:15:49 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 31 Aug 2009 09:15:49 +0200 Subject: [M3devel] how to find cm3.cfg In-Reply-To: References: Message-ID: <20090831091549.ii6ae9sr40cwg804@mail.elegosoft.com> Some quick comments: o It is rather late in the release to change the interfaces, i.e. introduce new command line options like -config or -target. -config is currently the same as -version, so this is incompatible. I'd rather leave changes like this for the trunk. The release branch is _not_ for development. o I do not remember that an agreement was reached concerning the config search discussion. There were some contradictory mails on the matter as far as I remember, but no conclusion, so I didn't change anything again. As long as we haven't really resolved this, we are likely to change again and again. o I'm not against simplifying the initial search in the cm3 executable, but if we agree that customizations for system-specific layouts should be done in the quake code, this should be documented and even prepared in the provided config files. o If anything is changed again, at least not for RC3. The correct way would be to test such changes on the trunk and then merge them for a later RC4. Let's do it this way. It is almost impossible to get the system stable enough for a multi-platform package build. IIRC, we've been trying for more than two weeks now to build RC3. Olaf Quoting Jay K : > how to find cm3.cfg > > I propose, in this order: > > - -config or --config switch (actually any number of dashes) > > - $M3_CONFIG environment variable (however it is already spelled) > > This is a preferably path to a specific file, not some > directory to further probe. > > I'll have to check the current implementation though. It might be > > a directory containing cm3.cfg as well. Whatever it currently > does is how it should likely stay. > > - cm3.cfg next to executable, be it cm3.exe, cm3ide.exe, etc. > > - possibly one other choice, if none of the above exist, and > executable is not cm3/cm3.exe, > > then search $PATH for cm3/cm3.exe and use cm3.cfg next to it > > This includes NOT looking in: > > - /etc > > - current directory > > - $PATH in general > > One problem is, you can't really directly/easily even find the > current executable in Posix. > > I'll do more research on this. > > It is easy in Win32 and I assume Mac. > > Otherwise will probably fall back to: > > I believe everyone's best effort here is looking at argv[0] and if > that isn't a full or > > current working directory relative path, search $PATH. > > Any other search should be layerable upon this. > > That is, cm3.cfg can include(/etc/cm3.cfg) or such. > > One thing not accounted for here is a --target command line option. > > Given the current layout and code, that doesn't work out well. > > Specifically, using config/target wouldn't set INSTALL_ROOT correctly. > > --target could set $TARGET and cm3.cfg could include config/target if > > target is already set. > > Or cm3 could set INSTALL_ROOT itself. > > We could look for next-to-executable/target.cfg. > > I think I'll punt on all this for now -- any accomodation of > --target on command line. > > I think this change should probably go in this release, given that > there was another change > > already that this undoes and given th bug I found regarding running > by relative path (granted, > > I should debug that before replacing the code). > > Or, I guess, at the very least, remove the new probes and fix the > bug I found. > > I guess. -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Aug 31 09:55:00 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 31 Aug 2009 07:55:00 +0000 Subject: [M3devel] RandomTest runtime error FileWr.Error not in Raises list Message-ID: Easy to trigger problems here, also on NT, like with: VAR r: Random.T; stdout := NEW(AutoFlushWr.T).init(Stdio.stdout); PROCEDURE Main () = BEGIN WHILE TRUE DO Wr.PutText(stdout, "foofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoo\n"); END; foofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoo FileWr.Seek:wr.seekable=FALSE,n=53300,wr.hi=57396 *** *** runtime error: *** Exception "FileWr.Error" not in RAISES list *** file "..\src\rw\FileWr.m3", line 85 *** *** *** runtime error: *** Thread client error: Attempt to lock mutex already locked by self *** file "..\src\thread\WIN32\ThreadWin32.m3", line 119 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12fcfc 0x41c2d6 Seek + 0x125 in ..\src\rw\FileWr.m3 0x12fd58 0x40e6b1 Seek + 0x165 in ..\src\rw\AutoFlushWr.m3 0x12fd9c 0x407c9a PutStringDefault + 0x281 in ..\src\rw\Wr.m3 0x12fe50 0x407460 FastPutText + 0x105 in ..\src\rw\Wr.m3 0x12fe78 0x407328 PutText + 0x4e in ..\src\rw\Wr.m3 0x12febc 0x4010c6 Main + 0x76 in ..\src\RandomTest.m3 0x12fee0 0x405795 RandomTest_M3 + 0xb5 in ..\src\RandomTest.m3 Must be some race condition between flushing and other writers? - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: RandomTest runtime error FileWr.Error not in Raises list Date: Sun, 30 Aug 2009 11:00:00 +0000 I think this is two or three problems. - missing raises - why does it raise - why does it hang Often but not always: jay at xlin2:/dev2/release_branch_cm3_5_8/m3-libs/libm3/tests/random$ pwd /dev2/release_branch_cm3_5_8/m3-libs/libm3/tests/random jay at xlin2:/dev2/release_branch_cm3_5_8/m3-libs/libm3/tests/random$ ./LINUXLIBC6 /RandomTest -perm under gdb: *** *** runtime error: *** Exception "FileWr.Error" not in RAISES list *** file "../src/rw/FileWr.m3", line 81 *** Program received signal SIGABRT, Aborted. [Switching to Thread -1210370368 (LWP 21415)] 0xb7f25410 in ?? () (gdb) bt #0 0xb7f25410 in ?? () #1 0xbfc4f14c in ?? () #2 0x00000006 in ?? () #3 0x000053a7 in ?? () #4 0xb7ddc811 in raise () from /lib/tls/i686/cmov/libc.so.6 #5 0xb7dddfb9 in abort () from /lib/tls/i686/cmov/libc.so.6 #6 0x0808bb12 in RTOS__Crash () at ../src/runtime/POSIX/RTOS.m3:20 #7 0x08085d83 in RTProcess__Crash (M3_Bd56fi_msg=0x0) at ../src/runtime/common/RTProcess.m3:65 #8 0x08083a8e in RTError__EndError (M3_AicXUJ_crash=1 '\001') at ../src/runtime/common/RTError.m3:118 #9 0x08083752 in RTError__MsgS (M3_AJWxb1_file=0x80c437c, M3_AcxOUs_line=81, M3_Bd56fi_msgA=0x80cc350, M3_Bd56fi_msgB=0xb7d7eba0, M3_Bd56fi_msgC=0x80cc378) at ../src/runtime/common/RTError.m3:40 #10 0x08083ef6 in RTException__Crash (M3_Cblw37_a=0xbfc4f460, M3_AicXUJ_raises=1 '\001', M3_AJWxb1_rte=0x80c8400) at ../src/runtime/common/RTException.m3:79 #11 0x08083c5f in RTException__DefaultBackstop (M3_Cblw37_a=0xbfc4f460, M3_AicXUJ_raises=0 '\0') at ../src/runtime/common/RTException.m3:41 #12 0x08083b59 in RTException__InvokeBackstop (M3_Cblw37_a=0xbfc4f460, M3_AicXUJ_raises=0 '\0') at ../src/runtime/common/RTException.m3:25 #13 0x0808c5a8 in RTException__Raise (M3_Cblw37_act=0xbfc4f460) at ../src/runtime/ex_frame/RTExFrame.m3:29 #14 0x08083cb6 in RTException__DefaultBackstop (M3_Cblw37_a=0xbfc4f460, ---Type to continue, or q to quit--- M3_AicXUJ_raises=1 '\001') at ../src/runtime/common/RTException.m3:47 #15 0x08083b59 in RTException__InvokeBackstop (M3_Cblw37_a=0xbfc4f460, M3_AicXUJ_raises=1 '\001') at ../src/runtime/common/RTException.m3:25 #16 0x0808c689 in RTException__Raise (M3_Cblw37_act=0xbfc4f460) at ../src/runtime/ex_frame/RTExFrame.m3:51 #17 0x08073e99 in RTHooks__Raise (M3_AJWxb1_ex=0x80c42a0, M3_AJWxb1_arg=0x0, M3_AJWxb1_module=0x80c43e0, M3_AcxOUs_line=81) at ../src/runtime/common/RTHooks.m3:79 #18 0x0806a9c4 in FileWr__Seek (M3_EJV0jI_wr=0xb7d73234, M3_Cwb5VA_n=4198) at ../src/rw/FileWr.m3:81 #19 0x080559ea in AutoFlushWr__Seek (M3_Aauo9c_wr=0xb7d790a4, M3_Cwb5VA_n=4198) at ../src/rw/AutoFlushWr.m3:106 #20 0x080544bf in WrClass__PutStringDefault (M3_BxxOH1_wr=0xb7d790a4, M3_CKMnXU_a=0xbfc4f7f4) at ../src/rw/Wr.m3:193 #21 0x080539de in UnsafeWr__FastPutText (M3_BxxOH1_wr=0xb7d790a4, M3_Bd56fi_t=0xb7d7eb84) at ../src/rw/Wr.m3:105 #22 0x08053837 in Wr__PutText (M3_BxxOH1_wr=0xb7d790a4, M3_Bd56fi_t=0xb7d7eb84) at ../src/rw/Wr.m3:93 #23 0x0804f561 in RandomTest__TestPerm () at ../src/RandomTest.m3:387 #24 0x0804bedf in RandomTest__Main () at ../src/RandomTest.m3:64 #25 0x08050235 in RandomTest_M3 (M3_AcxOUs_mode=1) at ../src/RandomTest.m3:458 #26 0x08082bf8 in RTLinker__RunMainBody (M3_DjPxE3_m=0x80be120) at ../src/runtime/common/RTLinker.m3:399 #27 0x08081fb2 in RTLinker__AddUnitI (M3_DjPxE3_m=0x80be120) ---Type to continue, or q to quit--- at ../src/runtime/common/RTLinker.m3:113 #28 0x08082040 in RTLinker__AddUnit (M3_DjPxE5_b=0x8050165) at ../src/runtime/common/RTLinker.m3:122 #29 0x0804baee in main (argc=2, argv=0xbfc4fe94, envp=0xbfc4fea0) at _m3main.mc:4 (gdb) This test hangs on OpenBSD/x86. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Aug 31 12:02:26 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 31 Aug 2009 10:02:26 +0000 Subject: [M3devel] FW: Wr.Unlock to restore invariants? In-Reply-To: <20090831091151.71CD12474001@birch.elegosoft.com> References: <20090831091151.71CD12474001@birch.elegosoft.com> Message-ID: My later change undoes this, and in general AutoFlushWr wasn't honoring it before -- in particular Flush and Length. Insert the extra unlock/lock to "fix" that? In particular, WrClass.i3: PROCEDURE Unlock(wr: Wr.T); (* The writer wr must be locked and valid; unlock it and restore the private invariant of the writer implementation. *) - Jay > Date: Mon, 31 Aug 2009 11:11:51 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/08/31 11:11:51 > > Modified files: > cm3/m3-libs/libm3/src/rw/: AutoFlushWr.m3 > > Log message: > Since Unlock is also documented as restoring invariants, restore > the early Unlock, and then put in an extra Lock after that. > In reality all the reader/writers implemented here don't do > anything in Unlock except unlock, so it was ok. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Aug 31 12:15:55 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 31 Aug 2009 10:15:55 +0000 Subject: [M3devel] "RandomTest" (that is its name) hangs on I386_OPENBSD Message-ID: "RandomTest" (that is its name) always hangs on I386_OPENBSD. The main thread never finishes StopWorld: (gdb) bt #0 0x00ba08f1 in poll () from /usr/lib/libc.so.50.1 #1 0x04ab5314 in _thread_kern_poll (wait_reqd=1) at /usr/src/lib/libpthread/uthread/uthread_kern.c:760 #2 0x04ab4e53 in _thread_kern_sched (scp=0x0) at /usr/src/lib/libpthread/uthread/uthread_kern.c:382 #3 0x04ab519f in _thread_kern_sched_state (state=615149768, fname=0x24aa70c8 "", lineno=615149768) at /usr/src/lib/libpthread/uthread/uthread_kern.c:550 #4 0x04aaf085 in nanosleep (time_to_sleep=0xcfbcc1a8, time_remaining=0xcfbcc1b0) at /usr/src/lib/libpthread/uthread/uthread_nanosleep.c:84 #5 0x0166eafd in ThreadPThread__Nanosleep (req=0xcfbcc1a8, rem=0xcfbcc1b0) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 #6 0x0166b6f4 in ThreadPThread__CommonSleep () at ../src/thread/PTHREAD/ThreadPThread.m3:651 #7 0x0166d355 in ThreadPThread__StopWorld () at ../src/thread/PTHREAD/ThreadPThread.m3:1142 #8 0x0166c9c3 in ThreadF__SuspendOthers () at ../src/thread/PTHREAD/ThreadPThread.m3:918 #9 0x0164e70b in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:747 #10 0x0164e6ca in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:721 #11 0x0164e161 in RTCollector__CollectEnough (M3_AicXUJ_allocator=1 '\001') ---Type to continue, or q to quit--- at ../src/runtime/common/RTCollector.m3:653 #12 0x01650cb7 in RTCollector__LongAlloc (M3_Cwb5VA_dataSize=92, M3_Cwb5VA_dataAlignment=4, M3_CAzbsM_pool=0x86770ab8) at ../src/runtime/common/RTCollector.m3:1438 #13 0x01650b14 in RTHeapRep__AllocTraced (M3_Cwb5VA_dataSize=92, M3_Cwb5VA_dataAlignment=4, M3_CAzbsM_pool=0x86770ab8) at ../src/runtime/common/RTCollector.m3:1400 #14 0x01645b47 in RTAllocator__GetOpenArray (M3_Eic7CK_def=0x216259d0, M3_ANmeAM_s=0xcfbcc4fc) at ../src/runtime/common/RTAllocator.m3:292 #15 0x01644e3c in RTHooks__AllocateOpenArray (M3_AJWxb1_defn=0x216259d0, M3_ANmeAM_s=0xcfbcc4fc) at ../src/runtime/common/RTAllocator.m3:141 #16 0x0c4b364f in RandomPerm__HQInit (M3_AMLmtL_t=0x7eed1fb0, M3_Cwb5VA_n=21, M3_BUCfej_r=0x7eecb0f4) at ../src/random/Common/RandomPerm.m3:55 #17 0x1c00489e in RandomTest__TestPerm () at ../src/RandomTest.m3:367 #18 0x1c0015f7 in RandomTest__Main () at ../src/RandomTest.m3:64 #19 0x1c00595c in RandomTest_M3 (M3_AcxOUs_mode=1) at ../src/RandomTest.m3:458 #20 0x01658a19 in RTLinker__RunMainBody (M3_DjPxE3_m=0x3c001660) at ../src/runtime/common/RTLinker.m3:400 #21 0x01657dd3 in RTLinker__AddUnitI (M3_DjPxE3_m=0x3c001660) at ../src/runtime/common/RTLinker.m3:114 #22 0x01657e61 in RTLinker__AddUnit (M3_DjPxE5_b=0x1c00588c) at ../src/runtime/common/RTLinker.m3:123 #23 0x1c001206 in main (argc=2, argv=0xcfbccadc, envp=0xcfbccae8) at _m3main.mc:4 While the other thread is in: Thread 2 (process 5611, thread 0x7fc1d400): #0 _thread_kern_sched (scp=0x0) at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 #1 0x04ab5200 in _thread_kern_sched_state_unlock (state=PS_SIGTHREAD, lock=0x7fc1d4b0, fname=0x1
, lineno=1) at /usr/src/lib/libpthread/uthread/uthread_kern.c:581 #2 0x04ab2bc9 in pthread_cond_wait (cond=0x80dda100, mutex=0x80dda1e0) at /usr/src/lib/libpthread/uthread/uthread_cond.c:261 #3 0x01668b89 in ThreadPThread__XWait (M3_BXP32l_self=0x7eeff13c, M3_AYIbX3_m=0x7eecb018, M3_Bl0jv4_c=0x7eecb06c, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x01669235 in Thread__Wait (M3_AYIbX3_m=0x7eecb018, M3_Bl0jv4_c=0x7eecb06c) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x0c4c1de7 in AutoFlushWr__Worker (M3_EMTrVz_cl=0x7eeff134) at ../src/rw/AutoFlushWr.m3:210 #6 0x0166acfb in ThreadPThread__RunThread (M3_BeUkBA_me=0x86770b00) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x0166aa26 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x86770b00) at ../src/thread/PTHREAD/ThreadPThread.m3:523 #8 0x04aac37f in _thread_start () at /usr/src/lib/libpthread/uthread/uthread_create.c:240 #9 0x0000002b in ?? () #10 0x00000000 in ?? () Maybe AutoFlushWr needs more work? (It was crashing on platforms it didn't hang on.) I'll try to dig around more here.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Aug 31 12:16:32 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 31 Aug 2009 10:16:32 +0000 Subject: [M3devel] Posix/Win32 linger options inverted? In-Reply-To: References: Message-ID: ? > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Sun, 23 Aug 2009 06:26:34 +0000 > Subject: [M3devel] Posix/Win32 linger options inverted? > > > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-comm/tcp/src/POSIX/TCP.m3?rev=1.7;content-type=text%2Fplain > > vs. > > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-comm/tcp/src/WIN32/TCP.m3?rev=1.3;content-type=text%2Fplain > > > search for linger: > > PROCEDURE InitFD(fd: CARDINAL) = > (* We assume that the runtime ignores SIGPIPE signals *) > VAR > one: int := 1; > linger := Usocket.struct_linger{1, 1}; > > vs. > > PROCEDURE InitSock(sock: WinSock.SOCKET) = > (* We assume that the runtime ignores SIGPIPE signals *) > VAR > one : BOOL := 1; > linger := WinSock.struct_linger{0, 0}; > > > Surely they can't both be correct. > Which is correct? The Posix one? > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Aug 31 13:20:56 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 31 Aug 2009 13:20:56 +0200 Subject: [M3devel] Posix/Win32 linger options inverted? In-Reply-To: References: Message-ID: <20090831132056.dpkpp6z5pkw4os0c@mail.elegosoft.com> On Solaris I find /* * Structure used for manipulating linger option. */ struct linger { int l_onoff; /* option on/off */ int l_linger; /* linger time */ }; so {1, 1} would make the socket linger for at most 1 second after close, while {0, 0} would close the socket immediately and throw away any data not sent yet. The default linger time on Solaris seems to be 120 seconds btw. I cannot really say why this difference is present, I can only guess that one of them is a workaround for a bug. Perhaps the intention was indeed to allow 1 second until data is sent, but this didn't work on Windows? Does anybody here know more? Olaf Quoting Jay K : > > ? > > > >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Date: Sun, 23 Aug 2009 06:26:34 +0000 >> Subject: [M3devel] Posix/Win32 linger options inverted? >> >> >> http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-comm/tcp/src/POSIX/TCP.m3?rev=1.7;content-type=text%2Fplain >> >> vs. >> >> http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-comm/tcp/src/WIN32/TCP.m3?rev=1.3;content-type=text%2Fplain >> >> >> search for linger: >> >> PROCEDURE InitFD(fd: CARDINAL) = >> (* We assume that the runtime ignores SIGPIPE signals *) >> VAR >> one: int := 1; >> linger := Usocket.struct_linger{1, 1}; >> >> vs. >> >> PROCEDURE InitSock(sock: WinSock.SOCKET) = >> (* We assume that the runtime ignores SIGPIPE signals *) >> VAR >> one : BOOL := 1; >> linger := WinSock.struct_linger{0, 0}; >> >> >> Surely they can't both be correct. >> Which is correct? The Posix one? >> >> >> - Jay > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Aug 31 14:16:21 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 31 Aug 2009 12:16:21 +0000 Subject: [M3devel] tinderbox failures: undefined variables in quake In-Reply-To: <20090829235106.lb9zq4ouo8kcckgs@mail.elegosoft.com> References: <20090829235106.lb9zq4ouo8kcckgs@mail.elegosoft.com> Message-ID: There are definitely some bugs in old cm3 that I don't understand. My use of "local" at global scope may be dubious, granted. I can build cm3cg now from Linux/x86 5.4.0, but I'm not sure about the M3_PROFILING error. We'll see how the next runs go. The Tinderbox build scripts should run cm3 -version so we know what we are dealing with. - Jay > Date: Sat, 29 Aug 2009 23:51:06 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] tinderbox failures: undefined variables in quake > > Several release builds fail with undefined variables in quake now > (this is probably in the trunk I assume). > > Who broke this now? Is it just missing backward compatibility > or a more serious problem? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Aug 31 17:06:44 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 31 Aug 2009 11:06:44 -0400 Subject: [M3devel] "RandomTest" (that is its name) hangs on I386_OPENBSD In-Reply-To: References: Message-ID: <04B5CB8B-5D26-4529-86CA-25B399DE6F0C@cs.purdue.edu> The main thread should never hang here... Looks like thread 2 is not receiving/responding to the signal to stop. Something very wrong... On 31 Aug 2009, at 06:15, Jay K wrote: > "RandomTest" (that is its name) always hangs on I386_OPENBSD. > > > The main thread never finishes StopWorld: > > > (gdb) bt > #0 0x00ba08f1 in poll () from /usr/lib/libc.so.50.1 > #1 0x04ab5314 in _thread_kern_poll (wait_reqd=1) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:760 > #2 0x04ab4e53 in _thread_kern_sched (scp=0x0) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:382 > #3 0x04ab519f in _thread_kern_sched_state (state=615149768, > fname=0x24aa70c8 "", lineno=615149768) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:550 > #4 0x04aaf085 in nanosleep (time_to_sleep=0xcfbcc1a8, > time_remaining=0xcfbcc1b0) > at /usr/src/lib/libpthread/uthread/uthread_nanosleep.c:84 > #5 0x0166eafd in ThreadPThread__Nanosleep (req=0xcfbcc1a8, > rem=0xcfbcc1b0) > at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #6 0x0166b6f4 in ThreadPThread__CommonSleep () > at ../src/thread/PTHREAD/ThreadPThread.m3:651 > #7 0x0166d355 in ThreadPThread__StopWorld () > at ../src/thread/PTHREAD/ThreadPThread.m3:1142 > #8 0x0166c9c3 in ThreadF__SuspendOthers () > at ../src/thread/PTHREAD/ThreadPThread.m3:918 > #9 0x0164e70b in RTCollector__CollectSomeInStateZero () > at ../src/runtime/common/RTCollector.m3:747 > #10 0x0164e6ca in RTCollector__CollectSome () > at ../src/runtime/common/RTCollector.m3:721 > #11 0x0164e161 in RTCollector__CollectEnough (M3_AicXUJ_allocator=1 > '\001') > ---Type to continue, or q to quit--- > at ../src/runtime/common/RTCollector.m3:653 > #12 0x01650cb7 in RTCollector__LongAlloc (M3_Cwb5VA_dataSize=92, > M3_Cwb5VA_dataAlignment=4, M3_CAzbsM_pool=0x86770ab8) > at ../src/runtime/common/RTCollector.m3:1438 > #13 0x01650b14 in RTHeapRep__AllocTraced (M3_Cwb5VA_dataSize=92, > M3_Cwb5VA_dataAlignment=4, M3_CAzbsM_pool=0x86770ab8) > at ../src/runtime/common/RTCollector.m3:1400 > #14 0x01645b47 in RTAllocator__GetOpenArray (M3_Eic7CK_def=0x216259d0, > M3_ANmeAM_s=0xcfbcc4fc) at ../src/runtime/common/ > RTAllocator.m3:292 > #15 0x01644e3c in RTHooks__AllocateOpenArray > (M3_AJWxb1_defn=0x216259d0, > M3_ANmeAM_s=0xcfbcc4fc) at ../src/runtime/common/ > RTAllocator.m3:141 > #16 0x0c4b364f in RandomPerm__HQInit (M3_AMLmtL_t=0x7eed1fb0, > M3_Cwb5VA_n=21, > M3_BUCfej_r=0x7eecb0f4) at ../src/random/Common/RandomPerm.m3:55 > #17 0x1c00489e in RandomTest__TestPerm () at ../src/RandomTest.m3:367 > #18 0x1c0015f7 in RandomTest__Main () at ../src/RandomTest.m3:64 > #19 0x1c00595c in RandomTest_M3 (M3_AcxOUs_mode=1) at ../src/ > RandomTest.m3:458 > #20 0x01658a19 in RTLinker__RunMainBody (M3_DjPxE3_m=0x3c001660) > at ../src/runtime/common/RTLinker.m3:400 > #21 0x01657dd3 in RTLinker__AddUnitI (M3_DjPxE3_m=0x3c001660) > at ../src/runtime/common/RTLinker.m3:114 > #22 0x01657e61 in RTLinker__AddUnit (M3_DjPxE5_b=0x1c00588c) > at ../src/runtime/common/RTLinker.m3:123 > #23 0x1c001206 in main (argc=2, argv=0xcfbccadc, envp=0xcfbccae8) > at _m3main.mc:4 > > > While the other thread is in: > > > Thread 2 (process 5611, thread 0x7fc1d400): > #0 _thread_kern_sched (scp=0x0) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 > #1 0x04ab5200 in _thread_kern_sched_state_unlock (state=PS_SIGTHREAD, > lock=0x7fc1d4b0, fname=0x1
, lineno=1) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:581 > #2 0x04ab2bc9 in pthread_cond_wait (cond=0x80dda100, > mutex=0x80dda1e0) > at /usr/src/lib/libpthread/uthread/uthread_cond.c:261 > #3 0x01668b89 in ThreadPThread__XWait (M3_BXP32l_self=0x7eeff13c, > M3_AYIbX3_m=0x7eecb018, M3_Bl0jv4_c=0x7eecb06c, > M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ > ThreadPThread.m3:227 > #4 0x01669235 in Thread__Wait (M3_AYIbX3_m=0x7eecb018, > M3_Bl0jv4_c=0x7eecb06c) at ../src/thread/PTHREAD/ > ThreadPThread.m3:278 > #5 0x0c4c1de7 in AutoFlushWr__Worker (M3_EMTrVz_cl=0x7eeff134) > at ../src/rw/AutoFlushWr.m3:210 > #6 0x0166acfb in ThreadPThread__RunThread (M3_BeUkBA_me=0x86770b00) > at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #7 0x0166aa26 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x86770b00) > at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #8 0x04aac37f in _thread_start () > at /usr/src/lib/libpthread/uthread/uthread_create.c:240 > #9 0x0000002b in ?? () > #10 0x00000000 in ?? () > > > Maybe AutoFlushWr needs more work? > (It was crashing on platforms it didn't hang on.) > > I'll try to dig around more here.. > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Aug 31 19:16:43 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 31 Aug 2009 19:16:43 +0200 Subject: [M3devel] Pickling problem from 64 to 32 bit platforms Message-ID: <20090831191643.7djdygpgg08wksko@mail.elegosoft.com> I think we've got a problem with pickles from 64 to 32 bit target platforms. Details can be found in https://projects.elego.de/cm3/ticket/1068. Pickle experts should have a look at that. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney.m.bates at cox.net Mon Aug 31 23:37:31 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Mon, 31 Aug 2009 16:37:31 -0500 Subject: [M3devel] Pickling problem from 64 to 32 bit platforms In-Reply-To: <20090831191643.7djdygpgg08wksko@mail.elegosoft.com> References: <20090831191643.7djdygpgg08wksko@mail.elegosoft.com> Message-ID: <4A9C429B.9070308@cox.net> Some initial observations: I don't understand the circumstances where this is happening. "pickles from 64 to 32 bit" sounds to me like the pickle was written on a 64-bit machine and read on a 32-bit machine. But the backtrace seems to be of a run on a 64-bit machine, in part because of the filename in the outermost frame: #38 0x0000000000408409 in _start () at ../sysdeps/x86_64/elf/start.S:113 ^^^^^^ and in part, because all the hexadecimal addresses are 64-bit values. This example seems to be using version 1 of pickles: #5 0x000000000045ac12 in ReadRef (reader=16_00000000025b2018) at ../src/pickle/ver1/Pickle.m3:529 ^^^^ Without some vetting, I can't say for sure, but I'm not sure this version ever did all the cross-target stuff completely. Did this case work earlier under the same circumstances? The len parameter to String8.Hash has surely gone bad. Could there something wrong with operations on CARDINAL on 64-bit machines? What is the symptom of the failure? What needs to be run to reproduce it? Olaf Wagner wrote: > I think we've got a problem with pickles from 64 to 32 bit > target platforms. Details can be found in > https://projects.elego.de/cm3/ticket/1068. > > Pickle experts should have a look at that. > > Olaf From hosking at cs.purdue.edu Sat Aug 1 04:24:49 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 31 Jul 2009 22:24:49 -0400 Subject: [M3devel] package groups question In-Reply-To: References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> <20090731160546.z0n1l2nxa8w008sw@mail.elegosoft.com> <20090731151357.GA18289@topoi.pooq.com> <20090731152047.GC18289@topoi.pooq.com> <20090731182747.5zo12gu1og0os4cg@mail.elegosoft.com> <7E5CE55F-0F6D-48BA-ADEF-35D7C59FB321@cs.purdue.edu> Message-ID: Good to hear that you think the numeric format errors have been stamped out. Not so good to hear that we don't fully support host/ target distinctions in the front-end. Text .mc would need conversion to binary .mc for cm3cg to parse. On 31 Jul 2009, at 12:43, Jay K wrote: > > That reminds me, darn it.. > > Yes I think the INTEGER/FLOAT things are ok now. > I had hit problems in float and/or double bootstrapping where host > and target differed in endian and fixed it. There were also 32bit/ > 64bit problems there maybe, also now believed fixed. > > > And gcc used to be partly to blame for problems here, but has been > fixed. > I even suggested they rev the documented caveats about building for > Alpha and I think they did. > > I do bootstrap from host-generated .s files. > > I understand you could bootstrap from .mc files instead. > Maybe even textual ones? > That you use as a distribution format? > Advantages/disadvantages? > Minor one is that you'd have to build m3cc without the small aid > of cm3..not a big deal, just configure -disable-bootstrap -disable- > multilibs && make and ignore all my little tweaks in the m3makefile. > If not textual, mc files are less readable..but assembly is > unreadable to most people anyway.. > > There are bugs here though. > - I left in the hack you didn't like in order to bootstrap from > 32bit to 64bit, where TEXTs are limited to 4gig, rather than some > much larger value on 64bit systems. The front end should be doing > target math there not host math. > > - You can't bootstrap from 64bit to 32bit due to some similar small > bug in the front end. > Probably also a target math vs. host math thing. > > We already have the code to simulate target math, we just have to > use it a little more. > (This is what gcc now uses gmp/mpfr for presumably, like wrt > constant propagation.) > > > - Jay > > > ________________________________ >> From: hosking at cs.purdue.edu >> To: wagner at elegosoft.com >> Date: Fri, 31 Jul 2009 12:31:49 -0400 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] package groups question >> >> I think cross-compilation should always be the default approach, >> simply because it avoids all the version issues. We should be able >> to bootstrap from any host to any target. I know there have been >> deficiencies in the gcc-based cm3cg backend (for example when host >> and target INTEGER or FLOAT have different formats), but I think we >> are on the way to eliminating those. Bootstrapping from .mc files >> using a native cm3cg probably avoids that though, rather than >> bootstrapping from host-generated .s files. Jay, perhaps you have >> more to add? >> >> On 31 Jul 2009, at 12:27, Olaf Wagner wrote: >> >> I meant getting the first instance of cm3 5.1 run on a certain >> platform. >> And there was of course a first platform. We used the SRC compiler, >> the cm3 4.1 from Critical Mass, and the PM3 compiler on different >> platforms. Later we used cross-compilation almost exclusively. >> >> I assume that cross-compilation support has improved dramatically >> with all your changes. >> >> Olaf >> >> Quoting Jay K>: >> >> >> What does it mean to boot the compiler? >> >> >> I build the compiler from nothing but the compiler itself, >> and config files, and C compiler and linker, cvs >> to get all the source. >> That's not nothing, but it about the smallest start you can have, >> unless you rewrite the compiler in C, then you can start without >> the Modula-3 compiler. But at certain points in time this >> would not work, due to m3core and/or libm3 problems. >> It does work today. >> >> >> Is that booting? >> >> >> In future I'd like to dynamically link cm3, so I'd start with >> cm3, libm3.so, libm3core.so, etc. -- just cm3 and its "static >> dynamic" >> dependencies. Many other systems do dynamically link to this extent >> and we can to. >> >> >> I'm not just being obnoxious. >> Really, what does it mean? >> >> >> Should we just ship std and that's it? >> And even drop the name from it? >> cm3-PPC_LINUX-5.8.2.tar.gz ? >> >> >> (No need to say "POSIX", it is redundant). >> Just one download per platform? >> Not a big matrix of packages to test? >> >> >> Or do we look too fat in that packaging? :) >> >> >> Will too much stuff confuse users? >> >> >> Or mitigate the bulk with a little documentation/tutorial? >> >> >> Something like this: >> >> There are many libraries and packages. >> You do not need to worry about them. >> Here is hello world for a command line program: >> ... >> And for a gui program: >> ... >> And a minimal sample interoperating with C: >> ... >> And a minimal sample using Modula-3's RPC called "network objects": >> ... >> >> CM3 4.1 had some like this that were nice, presumably we have them. >> >> - Jay >> >> >> >> >> ---------------------------------------- >> Date: Fri, 31 Jul 2009 11:20:48 -0400 >> From: hendrik at topoi.pooq.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] package groups question >> >> On Fri, Jul 31, 2009 at 11:13:58AM -0400, hendrik at topoi.pooq.com >> wrote: >> On Fri, Jul 31, 2009 at 04:05:46PM +0200, Olaf Wagner wrote: >> Quoting Tony Hosking : >> >> I don't care if future versions are not compilable with old cm3. But, >> vice versa, old versions should always be compilable with new cm3. >> >> My gut feelings run along the lines of what Randy has said. I do >> think that the average user should accept std as the install, while >> min is for power-users who know what they are doing. Does that jive >> with other people's expectations? >> >> Sorry, I only now caught up with _some_ of the mails on the m3devel >> list. Too much traffic for me to digest. >> >> I gather there's been a long discussion that `min' is not really >> useful as it is not enough to build the system. When we started >> the cm3 5 business many years ago with lots of uncompilable sources >> from Farshad Nayeri, we invented the following sets of packages: >> >> all - obvious meaning. most packages did not compile at all. >> std - the set of packages shipped as compilable and usable with >> every new release >> core - a useful but small set of packages including everything to >> bootstrap the compiler >> boot - the minimal set to bootstrap the compiler >> min - the minimal set useful for anyone (not wanting to compiler cm3) >> >> As of today, std = all, and boot isn't used any more as far as a I >> see. >> >> Is that becaouse no one ever boots the compiler any more? Or because >> there are better ways to do it? >> >> -- hendrik >> >> I guess I should mention that ebian is perfectly happy if one source >> parckage (possibly the entire working cm3 system) generates multiple >> binary packages. >> >> -- hendrik >> >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >> 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >> Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Aug 1 08:51:41 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Fri, 31 Jul 2009 23:51:41 -0700 Subject: [M3devel] package groups question In-Reply-To: <4A72DD14020000D70005DF68@scires.com> References: <4A72DD14020000D70005DF68@scires.com> Message-ID: <27E6BB5F-1852-469E-8CA8-1299389734C7@hotmail.com> | From what I've gleaned in the discussions and the current documentation, I think most everyone has settled on the idea of having 2 "binary" distributions for this release: "min" and "std". > Really? How about just "std" and don't even label it as such? How many expert users are clamoring for "min"? There was actually a push for several non overlaping package sets and Olaf did work for that. But I'm not sure that is worth it. - Jay From wagner at elegosoft.com Sat Aug 1 12:34:09 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 01 Aug 2009 12:34:09 +0200 Subject: [M3devel] CM3 5.8 release engineering status Message-ID: <20090801123409.pgfzat70hco480o4@mail.elegosoft.com> Hi again, I just updated https://projects.elego.de/cm3/roadmap. The current Tinderbox and Hudson status look OK, so I've started to build some installation archives for RC2. Several machines have been integrated into the Hudson regression; there are some connection problems though, which sometimes lead to broken builds. I've been able to create installation archives for AMD64_LINUX, LINUXLIBC6, FreeBSD4 and PPC_DARWIN. SOLgnu and I386_OPENBSD maybe tomorrow, if nobody else is faster. To contribute, check out the release branch and execute make-dist.sh cvs checkout -r release_branch_cm3_5_8 cm3 cd cm3/scripts SHIPRC=yes ./make-dist.sh should do the trick and copy the resulting packages to birch via scp. I'll be away for most of the remaining weekend, but will look into the mail now and then. I've moved the downloads to their own page, but otherwise not changed much in the documentation. There's still a lot to do. I'd appreciate feedback of any installation successes and failures. So long, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Sat Aug 1 23:03:18 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sat, 1 Aug 2009 17:03:18 -0400 Subject: [M3devel] package groups question In-Reply-To: <27E6BB5F-1852-469E-8CA8-1299389734C7@hotmail.com> References: <4A72DD14020000D70005DF68@scires.com> <27E6BB5F-1852-469E-8CA8-1299389734C7@hotmail.com> Message-ID: <20090801210318.GA21289@topoi.pooq.com> On Fri, Jul 31, 2009 at 11:51:41PM -0700, jay.krell at cornell.edu wrote: > | From what I've gleaned in the discussions and the current > documentation, I think most everyone has settled on the idea of having > 2 "binary" distributions for this release: "min" and "std". > > > > Really? How about just "std" and don't even label it as such? How many > expert users are clamoring for "min"? > > There was actually a push for several non overlaping package sets and > Olaf did work for that. But I'm not sure that is worth it. The packages probably shouldn't overlap (at least if we want them to be adopted by Linux distributions, whose installers know about package dependencies) But there are packages that should be optional. There's no way I'm going to be able to install Xorg on a text-only machine just so I can install cm3 because, say, Trestle is part of the standard package and it's compiled for X. -- hendrik From jay.krell at cornell.edu Sat Aug 1 23:16:28 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 1 Aug 2009 21:16:28 +0000 Subject: [M3devel] package groups question In-Reply-To: <20090801210318.GA21289@topoi.pooq.com> References: <4A72DD14020000D70005DF68@scires.com> <27E6BB5F-1852-469E-8CA8-1299389734C7@hotmail.com> <20090801210318.GA21289@topoi.pooq.com> Message-ID: Nobody is going to make you install Xorg. - we only have X clients, no dependencies on an X server - if we just omit any dependencies and leave the obvious errors to occur if you happen to run those binaries (unable to find libX11.so...) that's not terrible imho. Granted that might be a little unfriendly to people who actually want to run..uh..formsedit, and don't yet have X client libraries and are willing to install them if only it is suggested to them.. Keep in mind that Olaf isn't building .debs and .rpms, just these .tar.gz files, that, indeed, have no stated dependencies -- leading to exactly what I said, no suggestion to install anything else, leaving forsmedit et. al. to fail to launch. Are their tools to turn dynamic link dependencies into package dependencies?? - Jay ---------------------------------------- > Date: Sat, 1 Aug 2009 17:03:18 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] package groups question > > On Fri, Jul 31, 2009 at 11:51:41PM -0700, jay.krell at cornell.edu wrote: >> | From what I've gleaned in the discussions and the current >> documentation, I think most everyone has settled on the idea of having >> 2 "binary" distributions for this release: "min" and "std". >>> >> >> Really? How about just "std" and don't even label it as such? How many >> expert users are clamoring for "min"? >> >> There was actually a push for several non overlaping package sets and >> Olaf did work for that. But I'm not sure that is worth it. > > The packages probably shouldn't overlap (at least if we want them to be > adopted by Linux distributions, whose installers know about package > dependencies) > > But there are packages that should be optional. There's no way I'm > going to be able to install Xorg on a text-only machine just so I can > install cm3 because, say, Trestle is part of the standard package and > it's compiled for X. > > -- hendrik From hendrik at topoi.pooq.com Sat Aug 1 23:20:29 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sat, 1 Aug 2009 17:20:29 -0400 Subject: [M3devel] package groups question In-Reply-To: References: <4A72DD14020000D70005DF68@scires.com> <27E6BB5F-1852-469E-8CA8-1299389734C7@hotmail.com> <20090801210318.GA21289@topoi.pooq.com> Message-ID: <20090801212029.GD21289@topoi.pooq.com> On Sat, Aug 01, 2009 at 09:16:28PM +0000, Jay K wrote: > > Nobody is going to make you install Xorg. > > - we only have X clients, no dependencies on an X server > > > - if we just omit any dependencies and leave the obvious errors to > occur if you happen to run those binaries (unable to find > libX11.so...) that's not terrible imho. > Granted that might be a little unfriendly to people who actually want > to run..uh..formsedit, and don't yet have X client libraries and > are willing to install them if only it is suggested to them.. > > > Keep in mind that Olaf isn't building .debs and .rpms, just these .tar.gz files, that, indeed, have no stated dependencies -- leading to exactly what I said, no suggestion to install anything else, leaving forsmedit et. al. to fail to launch. Well, that's OK for now, then. > > > Are their tools to turn dynamic link dependencies into package dependencies?? I don't think Debian does this. I think package dependencies are determined manually, judging form the occasional package I've encountered that lacks a few. -- hendrik > > > - Jay > > > ---------------------------------------- > > Date: Sat, 1 Aug 2009 17:03:18 -0400 > > From: hendrik at topoi.pooq.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] package groups question > > > > On Fri, Jul 31, 2009 at 11:51:41PM -0700, jay.krell at cornell.edu wrote: > >> | From what I've gleaned in the discussions and the current > >> documentation, I think most everyone has settled on the idea of having > >> 2 "binary" distributions for this release: "min" and "std". > >>> > >> > >> Really? How about just "std" and don't even label it as such? How many > >> expert users are clamoring for "min"? > >> > >> There was actually a push for several non overlaping package sets and > >> Olaf did work for that. But I'm not sure that is worth it. > > > > The packages probably shouldn't overlap (at least if we want them to be > > adopted by Linux distributions, whose installers know about package > > dependencies) > > > > But there are packages that should be optional. There's no way I'm > > going to be able to install Xorg on a text-only machine just so I can > > install cm3 because, say, Trestle is part of the standard package and > > it's compiled for X. > > > > -- hendrik From rcolebur at scires.com Sun Aug 2 05:46:38 2009 From: rcolebur at scires.com (Randy Coleburn) Date: Sat, 1 Aug 2009 23:46:38 -0400 Subject: [M3devel] package groups question In-Reply-To: <27E6BB5F-1852-469E-8CA8-1299389734C7@hotmail.com> References: <4A72DD14020000D70005DF68@scires.com> <27E6BB5F-1852-469E-8CA8-1299389734C7@hotmail.com> Message-ID: <4A74D3DB.1E75.00D7.1@scires.com> Jay: That's ok with me if you just want to do "std" and leave out "min". Regards, Randy >>> 8/1/2009 2:51 AM >>> | From what I've gleaned in the discussions and the current documentation, I think most everyone has settled on the idea of having 2 "binary" distributions for this release: "min" and "std". > Really? How about just "std" and don't even label it as such? How many expert users are clamoring for "min"? There was actually a push for several non overlaping package sets and Olaf did work for that. But I'm not sure that is worth it. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4550 bytes Desc: S/MIME Cryptographic Signature URL: From jay.krell at cornell.edu Sun Aug 2 11:18:51 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 2 Aug 2009 09:18:51 +0000 Subject: [M3devel] use of the old config files? Message-ID: I noticed this in the build output: === package m3-sys/cminstall === --- building in SOLgnu --- ignoring ../src/m3overrides /home/hudson/work/cm3-inst/ssol/current--release-build/bin/../bin/m3bundle -name Setup -element config ../src/config/SOLgnu Maybe it is just unused now? - Jay From jay.krell at cornell.edu Sun Aug 2 14:26:21 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 2 Aug 2009 12:26:21 +0000 Subject: [M3devel] some cvs errors? Message-ID: "/tmp/cvsUsaGYO" 61 lines, 1835 characters /usr/cvs/cm3/m3-sys/m3cc/src/m3makefile,v <-- src/m3makefile new revision: 1.111.2.4; previous revision: 1.111.2.3 Cannot Open data file (cwd: /usr/local/tinderbox/bonsai; data/temp.8776): Bad fi ? PKGS /usr/cvs/cm3/scripts/find-packages.sh,v <-- find-packages.sh new revision: 1.9.2.1; previous revision: 1.9 /usr/cvs/cm3/scripts/find-src-dirs.sh,v <-- find-src-dirs.sh new revision: 1.2.2.1; previous revision: 1.2 /usr/cvs/cm3/scripts/list-pkg-dirs.sh,v <-- list-pkg-dirs.sh new revision: 1.2.2.1; previous revision: 1.2 /usr/cvs/cm3/scripts/make-dist.sh,v <-- make-dist.sh new revision: 1.26.2.5; previous revision: 1.26.2.4 cvs [commit aborted]: cannot rename file .new.make-dist.sh to make-dist.sh: Perm ission denied ? I think the commits made it. - Jay From wagner at elegosoft.com Sun Aug 2 14:39:54 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 02 Aug 2009 14:39:54 +0200 Subject: [M3devel] the branch? In-Reply-To: References: Message-ID: <20090802143954.xhdv2b7b8ao40ggw@mail.elegosoft.com> Quoting Jay K : > I checked out/updated in the branch. > Then make-dist did an update and picked up somewhat old stuff, like > the old caltech "term" stuff and the toplevel compat.quake. Jay, make-dist.sh on the release branch is supposed to just build the RC2 tag and nothing else. If we want anything else for that RC, we have to move the tag and rebuild all archives affected by the change. Probably days later then. If SOLgnu is broken and we cannot build anything with the sources, then its broken in RC2. That's life. I thought averything had stabilized. Let's keep it that way on the branch. Feel free to test out different tool setups in the regression or commit changes to the trunk. If we need to merge fixes, let's just merge those absolutely necessary. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Sun Aug 2 14:57:41 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 02 Aug 2009 14:57:41 +0200 Subject: [M3devel] HEADS UP: release engineering procedure clarification Message-ID: <20090802145741.noi5p5y40s4cgg8c@mail.elegosoft.com> Hi all, it seems I may need to explain the current procedure adopted for release engineering in order to avoid some confusion and chaos. (1) All release engineering occurs on the release_branch_cm3_5_8. The trunk is currently unaffected. (2) All RCs will be built from the release branch. (3) Fixes may be merged as necessary to the branch, but not arbitrary changes. Fixes comprise actual source fixes to make the CM3 code work on some platform as well as changes to the scripts to correct building or regression testing. (4) The tag release_CM3_5_8_RC2 defines the release candiate 2. I've made the last adaptions yesterday and started packaging the archives. make-dist.sh is currently supposed to just build this RC. (5) If we move the RC2 tag, we always need to rebuild a number of archives. We cannot do that indefinitely, as it takes a long time. If something is broken in RC2, it can be fixed in RC3. If we don't accept some bugs, we'll never make any release. (6) The Hudson regression and I think most of the tinderbox regression follows the release branch and not the trunk. Please heed these rules and help by building packages, improving the documentation and testing the available installation archives. I'm going to setup some automated tests for installation archives during the next days, but they will only cover some very basic aspects. Thanks for your cooperation, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sun Aug 2 15:06:16 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 2 Aug 2009 13:06:16 +0000 Subject: [M3devel] the branch? In-Reply-To: <20090802143954.xhdv2b7b8ao40ggw@mail.elegosoft.com> References: <20090802143954.xhdv2b7b8ao40ggw@mail.elegosoft.com> Message-ID: I understand, but it's very wierd, I run make-dist and it updates my source. bash-3.2$ rm PKGS rm: cannot remove `PKGS': No such file or directory bash-3.2$ SHIPRC=yes ./make-dist.sh making /cygdrive/c/dev2/cm3.release_branch_cm3_5_8/scripts/PKGS (slow but rare) ? scripts/PKGS U compat.quake U caltech-parser/term/src/cfmakeraw.c U caltech-parser/term/src/termios.h I don't even know why make-dist would be running any cvs upd command at all. I'll have to investigate further. - Jay ---------------------------------------- > Date: Sun, 2 Aug 2009 14:39:54 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: the branch? > > Quoting Jay K : > >> I checked out/updated in the branch. >> Then make-dist did an update and picked up somewhat old stuff, like >> the old caltech "term" stuff and the toplevel compat.quake. > > Jay, > > make-dist.sh on the release branch is supposed to just build the > RC2 tag and nothing else. > > If we want anything else for that RC, we have to move the tag > and rebuild all archives affected by the change. Probably days later then. > > If SOLgnu is broken and we cannot build anything with the sources, > then its broken in RC2. That's life. > > I thought averything had stabilized. Let's keep it that way on the > branch. Feel free to test out different tool setups in the regression > or commit changes to the trunk. > > If we need to merge fixes, let's just merge those absolutely necessary. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Sun Aug 2 15:07:24 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 2 Aug 2009 13:07:24 +0000 Subject: [M3devel] the branch? In-Reply-To: <20090802143954.xhdv2b7b8ao40ggw@mail.elegosoft.com> References: <20090802143954.xhdv2b7b8ao40ggw@mail.elegosoft.com> Message-ID: Oh, it is updating from release_CM3_5_8 to release_CM3_5_8_RC2. I thought we were supposed to checkout release_CM3_5_8. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > CC: m3devel at elegosoft.com > Subject: RE: the branch? > Date: Sun, 2 Aug 2009 13:06:16 +0000 > > > I understand, but it's very wierd, I run make-dist and it updates my source. > > bash-3.2$ rm PKGS > rm: cannot remove `PKGS': No such file or directory > bash-3.2$ SHIPRC=yes ./make-dist.sh > making /cygdrive/c/dev2/cm3.release_branch_cm3_5_8/scripts/PKGS (slow but rare) > ? scripts/PKGS > U compat.quake > U caltech-parser/term/src/cfmakeraw.c > U caltech-parser/term/src/termios.h > > I don't even know why make-dist would be running any cvs upd command at all. > I'll have to investigate further. > > - Jay > > > ---------------------------------------- >> Date: Sun, 2 Aug 2009 14:39:54 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: the branch? >> >> Quoting Jay K : >> >>> I checked out/updated in the branch. >>> Then make-dist did an update and picked up somewhat old stuff, like >>> the old caltech "term" stuff and the toplevel compat.quake. >> >> Jay, >> >> make-dist.sh on the release branch is supposed to just build the >> RC2 tag and nothing else. >> >> If we want anything else for that RC, we have to move the tag >> and rebuild all archives affected by the change. Probably days later then. >> >> If SOLgnu is broken and we cannot build anything with the sources, >> then its broken in RC2. That's life. >> >> I thought averything had stabilized. Let's keep it that way on the >> branch. Feel free to test out different tool setups in the regression >> or commit changes to the trunk. >> >> If we need to merge fixes, let's just merge those absolutely necessary. >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> From wagner at elegosoft.com Sun Aug 2 15:36:29 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 02 Aug 2009 15:36:29 +0200 Subject: [M3devel] HEADS UP: release engineering procedure clarification In-Reply-To: References: <20090802145741.noi5p5y40s4cgg8c@mail.elegosoft.com> Message-ID: <20090802153629.lqe9usnzocs4okwk@mail.elegosoft.com> Quoting Jay K : >> the CM3 code work on some platform as well as changes to the >> scripts to correct building or regression testing. > > That's what I was doing. > > SOLgnu probably shouldn't require a custom gcc, and the changes, > e.g. in m3cc only affect SOLgnu/SOLsun. > You don't really have to rebuild everything due to that change. > That's just an artifact of how CVS triggers Hudson. You can keep > whatever preexisting built packages exist. > > Changes in scripts were so Cygwin sh could build NT386. Likewise. It's all OK until now AFAIK. We can selectively rebuild packages. I've just move the RC2 tag to reflect your changes in scripts and will rebuild the source archive. We haven't got any archives yet for SOLgnu, so we can change anything platform speccific there and move the tag forward, as long as it doesn't affect other targets. Olaf > > - Jay > > > ---------------------------------------- >> Date: Sun, 2 Aug 2009 14:57:41 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] HEADS UP: release engineering procedure clarification >> >> Hi all, >> >> it seems I may need to explain the current procedure adopted for >> release engineering in order to avoid some confusion and chaos. >> >> (1) All release engineering occurs on the release_branch_cm3_5_8. >> The trunk is currently unaffected. >> (2) All RCs will be built from the release branch. >> (3) Fixes may be merged as necessary to the branch, but not >> arbitrary changes. Fixes comprise actual source fixes to make >> the CM3 code work on some platform as well as changes to the >> scripts to correct building or regression testing. >> (4) The tag release_CM3_5_8_RC2 defines the release candiate 2. >> I've made the last adaptions yesterday and started packaging >> the archives. make-dist.sh is currently supposed to just build >> this RC. >> (5) If we move the RC2 tag, we always need to rebuild a number of >> archives. We cannot do that indefinitely, as it takes a long >> time. If something is broken in RC2, it can be fixed in RC3. >> If we don't accept some bugs, we'll never make any release. >> (6) The Hudson regression and I think most of the tinderbox >> regression follows the release branch and not the trunk. >> >> Please heed these rules and help by building packages, improving >> the documentation and testing the available installation archives. >> >> I'm going to setup some automated tests for installation archives >> during the next days, but they will only cover some very basic >> aspects. >> >> Thanks for your cooperation, >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sun Aug 2 15:44:54 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 2 Aug 2009 13:44:54 +0000 Subject: [M3devel] HEADS UP: release engineering procedure clarification In-Reply-To: <20090802153629.lqe9usnzocs4okwk@mail.elegosoft.com> References: <20090802145741.noi5p5y40s4cgg8c@mail.elegosoft.com> <20090802153629.lqe9usnzocs4okwk@mail.elegosoft.com> Message-ID: I'll give up on SOLgnu now building with /usr/sfw/bin/gcc, since it failed again. There is another experiment to try -- -with-as=/usr/sfw/bin/as -with-gnu-as. I've changed hudson's .profile back to have /usr/local/bin in front and trying again. It looks like release and lastok are mixed up, ok. - Jay ---------------------------------------- > Date: Sun, 2 Aug 2009 15:36:29 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] HEADS UP: release engineering procedure clarification > > Quoting Jay K : > >>> the CM3 code work on some platform as well as changes to the >>> scripts to correct building or regression testing. >> >> That's what I was doing. >> >> SOLgnu probably shouldn't require a custom gcc, and the changes, >> e.g. in m3cc only affect SOLgnu/SOLsun. >> You don't really have to rebuild everything due to that change. >> That's just an artifact of how CVS triggers Hudson. You can keep >> whatever preexisting built packages exist. >> >> Changes in scripts were so Cygwin sh could build NT386. Likewise. > > It's all OK until now AFAIK. We can selectively rebuild packages. > I've just move the RC2 tag to reflect your changes in scripts > and will rebuild the source archive. > > We haven't got any archives yet for SOLgnu, so we can change > anything platform speccific there and move the tag forward, as long > as it doesn't affect other targets. > > Olaf > >> >> - Jay >> >> >> ---------------------------------------- >>> Date: Sun, 2 Aug 2009 14:57:41 +0200 >>> From: wagner at elegosoft.com >>> To: m3devel at elegosoft.com >>> Subject: [M3devel] HEADS UP: release engineering procedure clarification >>> >>> Hi all, >>> >>> it seems I may need to explain the current procedure adopted for >>> release engineering in order to avoid some confusion and chaos. >>> >>> (1) All release engineering occurs on the release_branch_cm3_5_8. >>> The trunk is currently unaffected. >>> (2) All RCs will be built from the release branch. >>> (3) Fixes may be merged as necessary to the branch, but not >>> arbitrary changes. Fixes comprise actual source fixes to make >>> the CM3 code work on some platform as well as changes to the >>> scripts to correct building or regression testing. >>> (4) The tag release_CM3_5_8_RC2 defines the release candiate 2. >>> I've made the last adaptions yesterday and started packaging >>> the archives. make-dist.sh is currently supposed to just build >>> this RC. >>> (5) If we move the RC2 tag, we always need to rebuild a number of >>> archives. We cannot do that indefinitely, as it takes a long >>> time. If something is broken in RC2, it can be fixed in RC3. >>> If we don't accept some bugs, we'll never make any release. >>> (6) The Hudson regression and I think most of the tinderbox >>> regression follows the release branch and not the trunk. >>> >>> Please heed these rules and help by building packages, improving >>> the documentation and testing the available installation archives. >>> >>> I'm going to setup some automated tests for installation archives >>> during the next days, but they will only cover some very basic >>> aspects. >>> >>> Thanks for your cooperation, >>> >>> Olaf >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From rcoleburn at scires.com Mon Aug 3 06:52:45 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 03 Aug 2009 00:52:45 -0400 Subject: [M3devel] problems with cm3.cfg and MxConfig Message-ID: <4A763446.1E75.00D7.1@scires.com> I have been working on the problem of cm3ide not getting the BUILD_DIR from cm3.cfg. I've run across some perplexing test results. MxConfig.Get("BUILD_DIR") is returning NIL on Windows XP & Vista. I've tracked it down a bit further. There seem to be two issues that must be fixed to solve this problem: 1. HOST does not seem to be defined. In particular my "C:\cm3\bin\cm3.cfg" file appears as follows (this is the file Jay recommended): INSTALL_ROOT = path() & "/.." include (path() & "/config/" & HOST) Is HOST a variable? Or, was I supposed to replace it by "NT386"? If the latter, my bad on this one--I took Jay's message literally. 2. path() does not appear to always yield the path to the bin folder. In particular, it seems to work fine unless you invoke the program when the current directory is actually set to the bin folder, in which case path() seems to return the empty string. So, if %CD%=C:\, and I run cm3ide, path() returns "C:\cm3\bin" as it should. But, if %CD%=C:\cm3\bin, and I run cm3ide, path() returns "". So in the latter case, the include statement winds up trying to pull a file from the wrong place, e.g. "/config/NT386" rather than "C:\cm3\bin/config/NT386" Regards, Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Aug 3 08:42:17 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Sun, 2 Aug 2009 23:42:17 -0700 Subject: [M3devel] problems with cm3.cfg and MxConfig In-Reply-To: <4A763446.1E75.00D7.1@scires.com> References: <4A763446.1E75.00D7.1@scires.com> Message-ID: Host, hm, I think probably my mistake. It is defined by cm3 but not all m3quake users. Path() should be the directory containing the file with the call. - Jay (phone) On Aug 2, 2009, at 9:52 PM, "Randy Coleburn" wrote: > I have been working on the problem of cm3ide not getting the > BUILD_DIR from cm3.cfg. I've run across some perplexing test results. > > MxConfig.Get("BUILD_DIR") is returning NIL on Windows XP & Vista. > I've tracked it down a bit further. There seem to be two issues > that must be fixed to solve this problem: > > 1. HOST does not seem to be defined. In particular my "C:\cm3\bin > \cm3.cfg" file appears as follows (this is the file Jay recommended): > INSTALL_ROOT = path() & "/.." > include (path() & "/config/" & HOST) > > Is HOST a variable? Or, was I supposed to replace it by "NT386"? > If the latter, my bad on this one--I took Jay's message literally. > > 2. path() does not appear to always yield the path to the bin > folder. In particular, it seems to work fine unless you invoke the > program when the current directory is actually set to the bin > folder, in which case path() seems to return the empty string. > > So, if ?%=C:\, and I run cm3ide, path() returns "C:\cm3\bin" as it s > hould. > But, if ?%=C:\cm3\bin, and I run cm3ide, path() returns "". > > So in the latter case, the include statement winds up trying to pull > a file from the wrong place, e.g. "/config/NT386" rather than "C: > \cm3\bin/config/NT386" > > Regards, > Randy Coleburn From jay.krell at cornell.edu Mon Aug 3 09:37:23 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 07:37:23 +0000 Subject: [M3devel] problems with cm3.cfg and MxConfig In-Reply-To: <4A763446.1E75.00D7.1@scires.com> References: <4A763446.1E75.00D7.1@scires.com> Message-ID: I will address #1 by changing the cm3.cfg files to say the actual target instead of depending on host. I still have to look into #2, that's the first I heard of it, but it could be again some difference between cm3 and all the other m3quake users. - Jay ________________________________ > Date: Mon, 3 Aug 2009 00:52:45 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: [M3devel] problems with cm3.cfg and MxConfig > > > > > > > > I have been working on the problem of cm3ide not getting the BUILD_DIR from cm3.cfg. I've run across some perplexing test results. > > > > MxConfig.Get("BUILD_DIR") is returning NIL on Windows XP & Vista. I've tracked it down a bit further. There seem to be two issues that must be fixed to solve this problem: > > > > 1. HOST does not seem to be defined. In particular my "C:\cm3\bin\cm3.cfg" file appears as follows (this is the file Jay recommended): > > INSTALL_ROOT = path() & "/.." > > include (path() & "/config/" & HOST) > > > > Is HOST a variable? Or, was I supposed to replace it by "NT386"? If the latter, my bad on this one--I took Jay's message literally. > > > > 2. path() does not appear to always yield the path to the bin folder. In particular, it seems to work fine unless you invoke the program when the current directory is actually set to the bin folder, in which case path() seems to return the empty string. > > > > So, if ?%=C:\, and I run cm3ide, path() returns "C:\cm3\bin" as it should. > > But, if ?%=C:\cm3\bin, and I run cm3ide, path() returns "". > > > > So in the latter case, the include statement winds up trying to pull a file from the wrong place, e.g. "/config/NT386" rather than "C:\cm3\bin/config/NT386" > > > > Regards, > > Randy Coleburn From jay.krell at cornell.edu Mon Aug 3 09:38:25 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 07:38:25 +0000 Subject: [M3devel] cm3 vs. m3quake Message-ID: cm3 defines some things, like: C:\dev2\cm3.2\m3-sys\cm3\src\Main.m3(54): Quake.Define(mach, "TARGET", MxConfig.HOST); C:\dev2\cm3.2\m3-sys\cm3\src\Main.m3(55): Quake.Define(mach, "OS_TYPE", MxConfig.HOST_OS_TYPE); C:\dev2\cm3.2\m3-sys\cm3\src\Main.m3(61): Quake.Define(mach, "WORD_SIZE", MxConfig.HOST_WORD_SIZE); C:\dev2\cm3.2\m3-sys\cm3\src\Main.m3(66): Quake.Define(mach, "HOST", MxConfig.HOST); C:\dev2\cm3.2\m3-sys\cm3\src\Main.m3(67): Quake.Define(mach, "HOST_OS_TYPE", MxConfig.HOST_OS_TYPE); C:\dev2\cm3.2\m3-sys\cm3\src\Main.m3(68): Quake.Define(mach, "HOST_GNU_MAKE", Version.GNUMake); all the other m3quake users don't get this. Would it be too polluting to move this to m3quake, thereby making m3quake just not a generic scripting language, but slightly specific to building Modula-3 stuff? I'll hold off for now. - Jay From jay.krell at cornell.edu Mon Aug 3 09:41:26 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 07:41:26 +0000 Subject: [M3devel] assembly goes to C compiler? Message-ID: Does this surprising anyone else: PROCEDURE CompileS (s: State; u: M3Unit.T) = ... ELSIF (u.kind = UK.S) THEN RunCC (s, UnitPath (u), u.object, u.debug, u.optimize); I kept modifying SYSTEM_ASM thinking it would affect how RTMachineASM.s is assembled, but it doesn't. I actually was thinking it might be nice to have two assembly functions, one for the output of m3cg, one for user written code. So, we do in fact have two functions, but one is the function for compiling C!. I'd want a third function, ideally. I'll leave this alone and just special case RTMachineASM.s in the config file, if that works out. That is, I'll try a very targeted slighly inelegant change, goal being to assemble this particular file with /usr/ccs/bin/as instead of the C compiler, on SOLgnu only. - Jay From dragisha at m3w.org Mon Aug 3 10:08:55 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 03 Aug 2009 10:08:55 +0200 Subject: [M3devel] More MxConfig Message-ID: <1249286935.28197.731.camel@faramir.m3w.org> This MxConfig thing looks like a bloody mess. To access former M3Config data I must have cm3.cfg suite present (to date I only had it in -devel packages, but ok...) Except cm3.cfg - ok, it's only set of text files, I must have sysutils, m3middle and m3quake.... A chunk of compiler. All this to read three or five variables from system. Also, this: VAR PKG_INSTALL := MxConfig.Get("PKG_INSTALL"); BUILD_DIR := MxConfig.Get("BUILD_DIR"); PROCEDURE DoImportBase() = BEGIN EVAL DoImportFile(PKG_INSTALL & "/libm3/" & BUILD_DIR & "/.M3WEB", TRUE); Fails on Concat in DoImportFile line - both variables NIL. Do I have some more voodoo to do to initialize MxConfig subsystem? -- Dragi?a Duri? From jay.krell at cornell.edu Mon Aug 3 10:36:24 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 08:36:24 +0000 Subject: [M3devel] the SOLgnu alignment problem finally understood Message-ID: Here finally is a small example of the SOLgnu problem I've been looking at it. It is specific to using /usr/sfw/bin/gcc -g to asssemble. No problem without -g, no problem with /usr/bin/cc, no problem with whatever I built in /usr/local/bin/gcc, no problem if you assemble with anything else and then link with /usr/sfw/bin/gcc -g. -bash-3.00$ cat 4.c asm.s 4.c void Asm(void); #include int main() { Asm(); printf("\n"); return 0; } asm.s .section ".text",#alloc,#execinstr .align 4 .global Asm .type Asm,#function Asm: retl nop .size Asm, (.-Asm) Not all possibilities shown here: -bash-3.00$ /usr/local/bin/gcc -g asm.s 4.c ok -bash-3.00$ /usr/sfw/bin/gcc -g asm.s 4.c ld: fatal: relocation error: R_SPARC_32: file /var/tmp//ccICgvny.o: symbol : offset 0xfeed139e is non-aligned ld: fatal: relocation error: R_SPARC_32: file /var/tmp//ccICgvny.o: symbol : offset 0xfeed14c2 is non-aligned ld: fatal: relocation error: R_SPARC_32: file /var/tmp//ccICgvny.o: symbol : offset 0xfeed15f6 is non-aligned collect2: ld returned 1 exit status -bash-3.00$ /usr/bin/cc -g asm.s 4.c asm.s: 4.c: ok -bash-3.00$ /usr/bin/cc asm.s 4.c asm.s: 4.c: ok -bash-3.00$ /usr/sfw/bin/gcc asm.s 4.c ok -bash-3.00$ /usr/local/bin/gcc asm.s 4.c ok -bash-3.00$ /usr/sfw/bin/gcc -g -c asm.s ok but haven't linked yet, input to later steps -bash-3.00$ /usr/bin/cc asm.o 4.c ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x ff10148e is non-aligned ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x ff1014ca is non-aligned ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x ff1015be is non-aligned -bash-3.00$ /usr/local/bin/gcc asm.o 4.c ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x feee1213 is non-aligned ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x feee122a is non-aligned ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x feee122e is non-aligned ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x feee1232 is non-aligned ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x feee126e is non-aligned collect2: ld returned 1 exit status -bash-3.00$ /usr/local/bin/gcc -g -c asm.s ok, try linking with others -bash-3.00$ /usr/bin/cc asm.o 4.c ok -bash-3.00$ /usr/sfw/bin/gcc asm.o 4.c ok Actually even -gstabs or -gstabs+ instead of -g make it work. -g resolves to -gdwarf2. - Jay From jay.krell at cornell.edu Mon Aug 3 10:42:22 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 08:42:22 +0000 Subject: [M3devel] More MxConfig In-Reply-To: <1249286935.28197.731.camel@faramir.m3w.org> References: <1249286935.28197.731.camel@faramir.m3w.org> Message-ID: Do you want to be able to move your cm3 install around, without editing the config file? You know, "be relocatable without any fixup code"? That is the big question. That is what MxConfig buys. These "variables" are computed, by running quake code. They are in fact known at install time, unless you later move the install around, and require something (cminstall) to modify the config files at install time. If nobody cares about moving installs around without invalidating their config file, we could put it back to a bunch of string constants. And we'd have to put back the markers that trigger cminstall to replace stuff. BUILD_DIR is basically constant either way. But, do you care about profiling? I don't really. Actually probably none of the tools properly support profiling anyway, except cm3. They would have to accept a command line switch. Dragi?a, do you have the symbolic HOST vs. actual string problem in cm3.cfg? A difference biting us is that cm3 does set a few values, such as PROFILING, SL, HOST. I haven't solved the path() problem yet that Randy reported. - Jay ---------------------------------------- > From: dragisha at m3w.org > To: m3devel at elegosoft.com > Date: Mon, 3 Aug 2009 10:08:55 +0200 > Subject: [M3devel] More MxConfig > > This MxConfig thing looks like a bloody mess. > > To access former M3Config data I must have cm3.cfg suite present (to > date I only had it in -devel packages, but ok...) > > Except cm3.cfg - ok, it's only set of text files, I must have sysutils, > m3middle and m3quake.... A chunk of compiler. > > All this to read three or five variables from system. > > Also, this: > > VAR > PKG_INSTALL := MxConfig.Get("PKG_INSTALL"); > BUILD_DIR := MxConfig.Get("BUILD_DIR"); > > PROCEDURE DoImportBase() = > BEGIN > EVAL DoImportFile(PKG_INSTALL & "/libm3/" & BUILD_DIR & > "/.M3WEB", TRUE); > > Fails on Concat in DoImportFile line - both variables NIL. > > Do I have some more voodoo to do to initialize MxConfig subsystem? > > -- > Dragi?a Duri? > From jay.krell at cornell.edu Mon Aug 3 10:51:28 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 08:51:28 +0000 Subject: [M3devel] More MxConfig In-Reply-To: References: <1249286935.28197.731.camel@faramir.m3w.org> Message-ID: ps: I should add that the way it was before was broken from a certain legitimate point of view. The M3Config paths were computed at build time, i.e. on Olaf's machine, i.e. they would point into /tmp or /home/hudson/work/cm3-inst or such. If you built things yourself, then ok, they worked. cminstall did not handle this. They were just constant strings in a generated M3Config.i3. cminstall could only "fix" MxConfig. I still think this is progress, though it would be nice if HOST worked and I have to look into path(). - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: dragisha at m3w.org; m3devel at elegosoft.com > Date: Mon, 3 Aug 2009 08:42:22 +0000 > Subject: Re: [M3devel] More MxConfig > > > Do you want to be able to move your cm3 install around, without editing the config file? > You know, "be relocatable without any fixup code"? > That is the big question. That is what MxConfig buys. > These "variables" are computed, by running quake code. > They are in fact known at install time, unless you later move the install around, > and require something (cminstall) to modify the config files at install time. > If nobody cares about moving installs around without invalidating their config file, > we could put it back to a bunch of string constants. And we'd have to put back > the markers that trigger cminstall to replace stuff. > > > BUILD_DIR is basically constant either way. But, do you care about profiling? I don't really. > Actually probably none of the tools properly support profiling anyway, except cm3. > They would have to accept a command line switch. > > > Dragi?a, do you have the symbolic HOST vs. actual string problem in cm3.cfg? > > > A difference biting us is that cm3 does set a few values, such as PROFILING, SL, HOST. > > > I haven't solved the path() problem yet that Randy reported. > > > - Jay > > > > ---------------------------------------- >> From: dragisha at m3w.org >> To: m3devel at elegosoft.com >> Date: Mon, 3 Aug 2009 10:08:55 +0200 >> Subject: [M3devel] More MxConfig >> >> This MxConfig thing looks like a bloody mess. >> >> To access former M3Config data I must have cm3.cfg suite present (to >> date I only had it in -devel packages, but ok...) >> >> Except cm3.cfg - ok, it's only set of text files, I must have sysutils, >> m3middle and m3quake.... A chunk of compiler. >> >> All this to read three or five variables from system. >> >> Also, this: >> >> VAR >> PKG_INSTALL := MxConfig.Get("PKG_INSTALL"); >> BUILD_DIR := MxConfig.Get("BUILD_DIR"); >> >> PROCEDURE DoImportBase() = >> BEGIN >> EVAL DoImportFile(PKG_INSTALL & "/libm3/" & BUILD_DIR & >> "/.M3WEB", TRUE); >> >> Fails on Concat in DoImportFile line - both variables NIL. >> >> Do I have some more voodoo to do to initialize MxConfig subsystem? >> >> -- >> Dragi?a Duri? >> From dragisha at m3w.org Mon Aug 3 10:55:48 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 03 Aug 2009 10:55:48 +0200 Subject: [M3devel] More MxConfig In-Reply-To: References: <1249286935.28197.731.camel@faramir.m3w.org> Message-ID: <1249289748.28197.740.camel@faramir.m3w.org> New auto-configuring cm3.cfg stuff is all ok. Great! I don't see importance of "moveable around" in that. Only "no need for cminstall and markers". "moveable around" is good when building from source using some kind of cm3-min. While at that, cm3-supermin with only cm3 binary and config files (probably cm3cg) would be supersmart feature. I am curently using cm3-min as a bootstraping device, and first thing I do is making libm3 and m3core over from supplied source. "Moveable around" is probably good, but if a chunk of compiler infrastructure included in any program reading those variables is price - I think it's good point to reconsider goals and ways. On Mon, 2009-08-03 at 08:42 +0000, Jay K wrote: > Do you want to be able to move your cm3 install around, without > editing the config file? > You know, "be relocatable without any fixup code"? > That is the big question. That is what MxConfig buys. > These "variables" are computed, by running quake code. > They are in fact known at install time, unless you later move the > install around, > and require something (cminstall) to modify the config files at > install time. > If nobody cares about moving installs around without invalidating > their config file, > we could put it back to a bunch of string constants. And we'd have > to put back > the markers that trigger cminstall to replace stuff. -- Dragi?a Duri? From jay.krell at cornell.edu Mon Aug 3 11:05:09 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 09:05:09 +0000 Subject: [M3devel] problems with cm3.cfg and MxConfig In-Reply-To: References: <4A763446.1E75.00D7.1@scires.com> Message-ID: Sorry about #1 Randy, my mistake. Sitting in the bin directory...seems a little wierd, eh? What source are you going to build sitting there? I guess um some custom quake code?? Good enough if empty is instead just "."? This falls out of the fact that cm3 actually probes all over the place for the cm3.cfg file and the first place it looks in is the current directory. Another good option I think would be just to remove that probe. It looks in way too many places. Here is the current code. I think it is gross. Too much probing make things quite ambiguous. PROCEDURE FindConfig () = (* LL = mu *) VAR txt: TEXT; BEGIN IF (found) THEN RETURN END; (* try the current directory *) IF TryConfig (Filename) THEN RETURN END; (* try the immediate source directory *) IF TryConfig ("src", Filename) THEN RETURN END; (* try the sibling source directory *) IF TryConfig ("..", "src", Filename) THEN RETURN END; (* try the M3CONFIG environment variable *) txt := QMachine.GetEnv (NIL, "M3CONFIG"); IF (txt # NIL) THEN IF TryConfig (txt) THEN RETURN END; IF TryConfig (txt, Filename) THEN RETURN END; END; (* try the directory containing the current executable *) txt := Pathname.Prefix (Params.Get (0)); IF Text.Length (txt)> 0 THEN IF TryConfig (txt, Filename) THEN RETURN END; END; (* try the directories named by the PATH environment variable. *) txt := Env.Get ("PATH"); FindConfigInPath (txt); IF found THEN RETURN END; (* try the etc directories *) IF TryConfig("/usr/local/cm3/etc", Filename) THEN RETURN END; IF TryConfig("/usr/cm3/etc", Filename) THEN RETURN END; IF TryConfig("/cm3/etc", Filename) THEN RETURN END; IF TryConfig("/usr/contrib/etc", Filename) THEN RETURN END; IF TryConfig("/usr/local/etc", Filename) THEN RETURN END; IF TryConfig("/usr/etc", Filename) THEN RETURN END; IF TryConfig("/opt/etc", Filename) THEN RETURN END; IF TryConfig("/sw/etc", Filename) THEN RETURN END; IF TryConfig("/etc", Filename) THEN RETURN END; (* oh well, make sure we don't try this silly exercise again... *) config := NIL; found := TRUE; END FindConfig; I propose..roughly roughly, we make it like this instead: PROCEDURE FindConfig () = (* LL = mu *) VAR txt: TEXT; BEGIN IF (found) THEN RETURN END; (* try the M3CONFIG environment variable *) txt := QMachine.GetEnv (NIL, "M3CONFIG"); IF (txt # NIL) THEN IF TryConfig (txt) THEN RETURN END; IF TryConfig (txt, Filename) THEN RETURN END; END; (* try the directory containing the current executable *) txt := Pathname.Prefix (Params.Get (0)); IF Text.Length (txt)> 0 THEN IF TryConfig (txt, Filename) THEN RETURN END; END; (* oh well, make sure we don't try this silly exercise again... *) config := NIL; found := TRUE; END FindConfig; or, if people really like it looking all over the place, fixing the case of it being in the current working directory is probably like this: (* try the current directory *) < IF TryConfig (Filename) THEN RETURN END; > IF TryConfig (".", Filename) THEN RETURN END; - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: rcoleburn at scires.com > Date: Sun, 2 Aug 2009 23:42:17 -0700 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] problems with cm3.cfg and MxConfig > > Host, hm, I think probably my mistake. It is defined by cm3 but not > all m3quake users. Path() should be the directory containing the file > with the call. > > - Jay (phone) > > On Aug 2, 2009, at 9:52 PM, "Randy Coleburn" > wrote: > >> I have been working on the problem of cm3ide not getting the >> BUILD_DIR from cm3.cfg. I've run across some perplexing test results. >> >> MxConfig.Get("BUILD_DIR") is returning NIL on Windows XP & Vista. >> I've tracked it down a bit further. There seem to be two issues >> that must be fixed to solve this problem: >> >> 1. HOST does not seem to be defined. In particular my "C:\cm3\bin >> \cm3.cfg" file appears as follows (this is the file Jay recommended): >> INSTALL_ROOT = path() & "/.." >> include (path() & "/config/" & HOST) >> >> Is HOST a variable? Or, was I supposed to replace it by "NT386"? >> If the latter, my bad on this one--I took Jay's message literally. >> >> 2. path() does not appear to always yield the path to the bin >> folder. In particular, it seems to work fine unless you invoke the >> program when the current directory is actually set to the bin >> folder, in which case path() seems to return the empty string. >> >> So, if ?%=C:\, and I run cm3ide, path() returns "C:\cm3\bin" as it s >> hould. >> But, if ?%=C:\cm3\bin, and I run cm3ide, path() returns "". >> >> So in the latter case, the include statement winds up trying to pull >> a file from the wrong place, e.g. "/config/NT386" rather than "C: >> \cm3\bin/config/NT386" >> >> Regards, >> Randy Coleburn From jay.krell at cornell.edu Mon Aug 3 11:13:25 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 09:13:25 +0000 Subject: [M3devel] More MxConfig In-Reply-To: <1249289748.28197.740.camel@faramir.m3w.org> References: <1249286935.28197.731.camel@faramir.m3w.org> <1249289748.28197.740.camel@faramir.m3w.org> Message-ID: Supermin is just cm3 + config files. And the config files we could/should m3bundle into cm3, leaving it to just be cm3. Providing cm3cg is a nice optimization, but then, you know, is the point to: build as much as possible or build as little as possible? build nothing, just get "std" or all of Olaf's packages. I would actually like to make cm3 dynamically linked, so supermin would also include m3core, libm3, sysutils. You could use ldd or whatever to discover. Look at gcc for example -- it doesn't statically link to libc. "Imagine if everyone statically linked the stuff they worked on and wanted to easily backup" -- everything would be statically linked. In terms of distribution purposes, well, I think providing just one large .tar.gz archive per platform is ideal, and one .msi for Windows, and a small number of .deb and .rpm files, like just x86 and AMD64. Arguing about all the subsets has been very wasteful. I don't want to add supermin and supermin+cm3cg to the debate. Meanwhile what we are going to have is probably Olaf's package breakdown. > "Moveable around" is probably good, but if a chunk of compiler > infrastructure included in any program reading those variables is price > - I think it's good point to reconsider goals and ways. Given how broken it was before, I don't see changing it back. I realize I've foisted "the compiler" on you, and there's a larger issue as to the finding of cm3.cfg by the executable. What about something like: cm3 -print-variable INSTALL_ROOT cm3 -print-variable HOST or for that matter: echo print(HOST)> fo o.quake cm3 -eval foo.quake or echo print(HOST) | cm3 -eval foo.quake Better or worse? Heck, you could just: type cm3 and compute the rest yourself. or you know the usual SearchPath function... - Jay ---------------------------------------- > From: dragisha at m3w.org > To: jay.krell at cornell.edu > Date: Mon, 3 Aug 2009 10:55:48 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] More MxConfig > > New auto-configuring cm3.cfg stuff is all ok. Great! > > I don't see importance of "moveable around" in that. Only "no need for > cminstall and markers". "moveable around" is good when building from > source using some kind of cm3-min. > > While at that, cm3-supermin with only cm3 binary and config files > (probably cm3cg) would be supersmart feature. I am curently using > cm3-min as a bootstraping device, and first thing I do is making libm3 > and m3core over from supplied source. > > "Moveable around" is probably good, but if a chunk of compiler > infrastructure included in any program reading those variables is price > - I think it's good point to reconsider goals and ways. > > On Mon, 2009-08-03 at 08:42 +0000, Jay K wrote: >> Do you want to be able to move your cm3 install around, without >> editing the config file? >> You know, "be relocatable without any fixup code"? >> That is the big question. That is what MxConfig buys. >> These "variables" are computed, by running quake code. >> They are in fact known at install time, unless you later move the >> install around, >> and require something (cminstall) to modify the config files at >> install time. >> If nobody cares about moving installs around without invalidating >> their config file, >> we could put it back to a bunch of string constants. And we'd have >> to put back >> the markers that trigger cminstall to replace stuff. > -- > Dragi?a Duri? > From wagner at elegosoft.com Mon Aug 3 12:30:54 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 03 Aug 2009 12:30:54 +0200 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: References: <4A763446.1E75.00D7.1@scires.com> Message-ID: <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> It was a specific request from the people building platform specific installation packages that config files reside and are found in the `usual' locations on their system and not somewhere beneath cm3. Place don't change that unless there is no objection from anyone on m3devel. Olaf Quoting Jay K : > Sorry about #1 Randy, my mistake. > > > Sitting in the bin directory...seems a little wierd, eh? > What source are you going to build sitting there? > I guess um some custom quake code?? > Good enough if empty is instead just "."? > > This falls out of the fact that cm3 actually probes all over the > place for the cm3.cfg file and the first place it looks in is the > current directory. > > > Another good option I think would be just to remove that probe. > It looks in way too many places. > > > Here is the current code. I think it is gross. > Too much probing make things quite ambiguous. > > > PROCEDURE FindConfig () = > (* LL = mu *) > VAR txt: TEXT; > BEGIN > IF (found) THEN RETURN END; > > (* try the current directory *) > IF TryConfig (Filename) THEN RETURN END; > > (* try the immediate source directory *) > IF TryConfig ("src", Filename) THEN RETURN END; > > (* try the sibling source directory *) > IF TryConfig ("..", "src", Filename) THEN RETURN END; > > (* try the M3CONFIG environment variable *) > txt := QMachine.GetEnv (NIL, "M3CONFIG"); > IF (txt # NIL) THEN > IF TryConfig (txt) THEN RETURN END; > IF TryConfig (txt, Filename) THEN RETURN END; > END; > > (* try the directory containing the current executable *) > txt := Pathname.Prefix (Params.Get (0)); > > IF Text.Length (txt)> 0 THEN > IF TryConfig (txt, Filename) THEN RETURN END; > END; > > (* try the directories named by the PATH environment variable. *) > txt := Env.Get ("PATH"); > FindConfigInPath (txt); > > IF found THEN RETURN END; > > (* try the etc directories *) > IF TryConfig("/usr/local/cm3/etc", Filename) THEN RETURN END; > IF TryConfig("/usr/cm3/etc", Filename) THEN RETURN END; > IF TryConfig("/cm3/etc", Filename) THEN RETURN END; > IF TryConfig("/usr/contrib/etc", Filename) THEN RETURN END; > IF TryConfig("/usr/local/etc", Filename) THEN RETURN END; > IF TryConfig("/usr/etc", Filename) THEN RETURN END; > IF TryConfig("/opt/etc", Filename) THEN RETURN END; > IF TryConfig("/sw/etc", Filename) THEN RETURN END; > IF TryConfig("/etc", Filename) THEN RETURN END; > > (* oh well, make sure we don't try this silly exercise again... *) > config := NIL; > found := TRUE; > END FindConfig; > > > I propose..roughly roughly, we make it like this instead: > > > PROCEDURE FindConfig () = > (* LL = mu *) > VAR txt: TEXT; > BEGIN > IF (found) THEN RETURN END; > > (* try the M3CONFIG environment variable *) > txt := QMachine.GetEnv (NIL, "M3CONFIG"); > IF (txt # NIL) THEN > IF TryConfig (txt) THEN RETURN END; > IF TryConfig (txt, Filename) THEN RETURN END; > END; > > (* try the directory containing the current executable *) > txt := Pathname.Prefix (Params.Get (0)); > IF Text.Length (txt)> 0 THEN > IF TryConfig (txt, Filename) THEN RETURN END; > END; > > (* oh well, make sure we don't try this silly exercise again... *) > config := NIL; > found := TRUE; > END FindConfig; > > > or, if people really like it looking all over the place, fixing the > case of it being in the current working directory is probably like > this: > > > (* try the current directory *) > < IF TryConfig (Filename) THEN RETURN END; >> IF TryConfig (".", Filename) THEN RETURN END; > > > - Jay > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: rcoleburn at scires.com >> Date: Sun, 2 Aug 2009 23:42:17 -0700 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] problems with cm3.cfg and MxConfig >> >> Host, hm, I think probably my mistake. It is defined by cm3 but not >> all m3quake users. Path() should be the directory containing the file >> with the call. >> >> - Jay (phone) >> >> On Aug 2, 2009, at 9:52 PM, "Randy Coleburn" >> wrote: >> >>> I have been working on the problem of cm3ide not getting the >>> BUILD_DIR from cm3.cfg. I've run across some perplexing test results. >>> >>> MxConfig.Get("BUILD_DIR") is returning NIL on Windows XP & Vista. >>> I've tracked it down a bit further. There seem to be two issues >>> that must be fixed to solve this problem: >>> >>> 1. HOST does not seem to be defined. In particular my "C:\cm3\bin >>> \cm3.cfg" file appears as follows (this is the file Jay recommended): >>> INSTALL_ROOT = path() & "/.." >>> include (path() & "/config/" & HOST) >>> >>> Is HOST a variable? Or, was I supposed to replace it by "NT386"? >>> If the latter, my bad on this one--I took Jay's message literally. >>> >>> 2. path() does not appear to always yield the path to the bin >>> folder. In particular, it seems to work fine unless you invoke the >>> program when the current directory is actually set to the bin >>> folder, in which case path() seems to return the empty string. >>> >>> So, if ?%=C:\, and I run cm3ide, path() returns "C:\cm3\bin" as it s >>> hould. >>> But, if ?%=C:\cm3\bin, and I run cm3ide, path() returns "". >>> >>> So in the latter case, the include statement winds up trying to pull >>> a file from the wrong place, e.g. "/config/NT386" rather than "C: >>> \cm3\bin/config/NT386" >>> >>> Regards, >>> Randy Coleburn -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Mon Aug 3 13:14:45 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 03 Aug 2009 13:14:45 +0200 Subject: [M3devel] some cvs errors? In-Reply-To: References: Message-ID: <20090803131445.d5u1i1vaf484kg4s@mail.elegosoft.com> Quoting Jay K : > "/tmp/cvsUsaGYO" 61 lines, 1835 characters > /usr/cvs/cm3/m3-sys/m3cc/src/m3makefile,v <-- src/m3makefile > new revision: 1.111.2.4; previous revision: 1.111.2.3 > Cannot Open data file (cwd: /usr/local/tinderbox/bonsai; > data/temp.8776): Bad fi > > ? PKGS > /usr/cvs/cm3/scripts/find-packages.sh,v <-- find-packages.sh > new revision: 1.9.2.1; previous revision: 1.9 > /usr/cvs/cm3/scripts/find-src-dirs.sh,v <-- find-src-dirs.sh > new revision: 1.2.2.1; previous revision: 1.2 > /usr/cvs/cm3/scripts/list-pkg-dirs.sh,v <-- list-pkg-dirs.sh > new revision: 1.2.2.1; previous revision: 1.2 > /usr/cvs/cm3/scripts/make-dist.sh,v <-- make-dist.sh > new revision: 1.26.2.5; previous revision: 1.26.2.4 > cvs [commit aborted]: cannot rename file .new.make-dist.sh to > make-dist.sh: Permission denied > > > ? > > I think the commits made it. What were these? Do we need to investigate them? Or is everything OK now? Still trying to catch up with all my mails, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Mon Aug 3 13:21:58 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 03 Aug 2009 13:21:58 +0200 Subject: [M3devel] assembly goes to C compiler? In-Reply-To: References: Message-ID: <20090803132158.walcuy2s00wck04g@mail.elegosoft.com> Quoting Jay K : > Does this surprising anyone else: > > PROCEDURE CompileS (s: State; u: M3Unit.T) = > ... > ELSIF (u.kind = UK.S) THEN > RunCC (s, UnitPath (u), u.object, u.debug, u.optimize); Indeed! I must say that I was not aware of it. Im not sure if it is an oversight, a hack, or an intended feature. In the last case we should eliminate the assembly methods from the config files. What happens if we run the quake assembly method instead? Does that break lots of systems? > I kept modifying SYSTEM_ASM thinking it would affect how > RTMachineASM.s is assembled, > but it doesn't. I actually was thinking it might be nice to have two > assembly functions, > one for the output of m3cg, one for user written code. So, we do in fact have > two functions, but one is the function for compiling C!. I'd want a > third function, ideally. > > I'll leave this alone and just special case RTMachineASM.s in the > config file, if that works out. > > That is, I'll try a very targeted slighly inelegant change, goal being > to assemble this particular file with /usr/ccs/bin/as instead of the > C compiler, > on SOLgnu only. That doesn't sound very nice. We should really investigate why RunCC is used even for assembly code. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Mon Aug 3 13:26:28 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 03 Aug 2009 13:26:28 +0200 Subject: [M3devel] the SOLgnu alignment problem finally understood In-Reply-To: References: Message-ID: <20090803132628.krcbd41hy8ggs8s8@mail.elegosoft.com> We had similar problems before with -g. CM3 never supported dwarf debugging format, just stabs. I think we changed all -g occurences in the config files to -gstabs some years ago. It sounds like a small fix in the config files after all, correct? At least for this RC? Olaf Quoting Jay K : > > Here finally is a small example of the SOLgnu problem I've been > looking at it. > > > It is specific to using /usr/sfw/bin/gcc -g to asssemble. > No problem without -g, no problem with /usr/bin/cc, no problem with > whatever I built in /usr/local/bin/gcc, no problem if you assemble > with anything else and then link with /usr/sfw/bin/gcc -g. > > > -bash-3.00$ cat 4.c asm.s > > 4.c > void Asm(void); > #include > > int main() > { > Asm(); > printf("\n"); > return 0; > } > > asm.s > > .section ".text",#alloc,#execinstr > .align 4 > .global Asm > .type Asm,#function > Asm: > retl > nop > .size Asm, (.-Asm) > > > Not all possibilities shown here: > > > -bash-3.00$ /usr/local/bin/gcc -g asm.s 4.c > ok > > > -bash-3.00$ /usr/sfw/bin/gcc -g asm.s 4.c > ld: fatal: relocation error: R_SPARC_32: file /var/tmp//ccICgvny.o: > symbol : offset 0xfeed139e is non-aligned > ld: fatal: relocation error: R_SPARC_32: file /var/tmp//ccICgvny.o: > symbol : offset 0xfeed14c2 is non-aligned > ld: fatal: relocation error: R_SPARC_32: file /var/tmp//ccICgvny.o: > symbol : offset 0xfeed15f6 is non-aligned > collect2: ld returned 1 exit status > > > -bash-3.00$ /usr/bin/cc -g asm.s 4.c > asm.s: > 4.c: > ok > > -bash-3.00$ /usr/bin/cc asm.s 4.c > asm.s: > 4.c: > ok > > > -bash-3.00$ /usr/sfw/bin/gcc asm.s 4.c > ok > > > -bash-3.00$ /usr/local/bin/gcc asm.s 4.c > ok > > > -bash-3.00$ /usr/sfw/bin/gcc -g -c asm.s > ok but haven't linked yet, input to later steps > > > -bash-3.00$ /usr/bin/cc asm.o 4.c > ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x > ff10148e is non-aligned > ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x > ff1014ca is non-aligned > ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x > ff1015be is non-aligned > > > -bash-3.00$ /usr/local/bin/gcc asm.o 4.c > ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x > feee1213 is non-aligned > ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x > feee122a is non-aligned > ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x > feee122e is non-aligned > ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x > feee1232 is non-aligned > ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x > feee126e is non-aligned > collect2: ld returned 1 exit status > > > > -bash-3.00$ /usr/local/bin/gcc -g -c asm.s > ok, try linking with others > > > -bash-3.00$ /usr/bin/cc asm.o 4.c > ok > > > > -bash-3.00$ /usr/sfw/bin/gcc asm.o 4.c > ok > > > Actually even -gstabs or -gstabs+ instead of -g make it work. > -g resolves to -gdwarf2. > > > - Jay -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Mon Aug 3 15:10:48 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 3 Aug 2009 09:10:48 -0400 Subject: [M3devel] assembly goes to C compiler? In-Reply-To: <20090803132158.walcuy2s00wck04g@mail.elegosoft.com> References: <20090803132158.walcuy2s00wck04g@mail.elegosoft.com> Message-ID: <20090803131048.GB24864@topoi.pooq.com> On Mon, Aug 03, 2009 at 01:21:58PM +0200, Olaf Wagner wrote: > > That doesn't sound very nice. We should really investigate why > RunCC is used even for assembly code. Just a guess -- could using a C compiler give the assembler code access to the X library? - hendrik From hosking at cs.purdue.edu Mon Aug 3 15:54:19 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 3 Aug 2009 09:54:19 -0400 Subject: [M3devel] cm3 vs. m3quake In-Reply-To: References: Message-ID: Prefer not to pollute. On 3 Aug 2009, at 03:38, Jay K wrote: > > cm3 defines some things, like: > > C:\dev2\cm3.2\m3-sys\cm3\src\Main.m3(54): Quake.Define(mach, > "TARGET", MxConfig.HOST); > C:\dev2\cm3.2\m3-sys\cm3\src\Main.m3(55): Quake.Define(mach, > "OS_TYPE", MxConfig.HOST_OS_TYPE); > C:\dev2\cm3.2\m3-sys\cm3\src\Main.m3(61): Quake.Define(mach, > "WORD_SIZE", MxConfig.HOST_WORD_SIZE); > C:\dev2\cm3.2\m3-sys\cm3\src\Main.m3(66): Quake.Define(mach, > "HOST", MxConfig.HOST); > C:\dev2\cm3.2\m3-sys\cm3\src\Main.m3(67): Quake.Define(mach, > "HOST_OS_TYPE", MxConfig.HOST_OS_TYPE); > C:\dev2\cm3.2\m3-sys\cm3\src\Main.m3(68): Quake.Define(mach, > "HOST_GNU_MAKE", Version.GNUMake); > > > all the other m3quake users don't get this. > > Would it be too polluting to move this to m3quake, thereby making > m3quake just not a generic scripting language, but slightly specific > to building Modula-3 stuff? > > I'll hold off for now. > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Aug 3 15:57:19 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 3 Aug 2009 09:57:19 -0400 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> Message-ID: I don't think we did agree that config files reside other than in the cm3 hierarchy. On 3 Aug 2009, at 06:30, Olaf Wagner wrote: > It was a specific request from the people building platform specific > installation packages that config files reside and are found in the > `usual' locations on their system and not somewhere beneath cm3. > > Place don't change that unless there is no objection from anyone > on m3devel. > > Olaf > > Quoting Jay K : > >> Sorry about #1 Randy, my mistake. >> >> >> Sitting in the bin directory...seems a little wierd, eh? >> What source are you going to build sitting there? >> I guess um some custom quake code?? >> Good enough if empty is instead just "."? >> >> This falls out of the fact that cm3 actually probes all over the >> place for the cm3.cfg file and the first place it looks in is the >> current directory. >> >> >> Another good option I think would be just to remove that probe. >> It looks in way too many places. >> >> >> Here is the current code. I think it is gross. >> Too much probing make things quite ambiguous. >> >> >> PROCEDURE FindConfig () = >> (* LL = mu *) >> VAR txt: TEXT; >> BEGIN >> IF (found) THEN RETURN END; >> >> (* try the current directory *) >> IF TryConfig (Filename) THEN RETURN END; >> >> (* try the immediate source directory *) >> IF TryConfig ("src", Filename) THEN RETURN END; >> >> (* try the sibling source directory *) >> IF TryConfig ("..", "src", Filename) THEN RETURN END; >> >> (* try the M3CONFIG environment variable *) >> txt := QMachine.GetEnv (NIL, "M3CONFIG"); >> IF (txt # NIL) THEN >> IF TryConfig (txt) THEN RETURN END; >> IF TryConfig (txt, Filename) THEN RETURN END; >> END; >> >> (* try the directory containing the current executable *) >> txt := Pathname.Prefix (Params.Get (0)); >> >> IF Text.Length (txt)> 0 THEN >> IF TryConfig (txt, Filename) THEN RETURN END; >> END; >> >> (* try the directories named by the PATH environment variable. *) >> txt := Env.Get ("PATH"); >> FindConfigInPath (txt); >> >> IF found THEN RETURN END; >> >> (* try the etc directories *) >> IF TryConfig("/usr/local/cm3/etc", Filename) THEN RETURN END; >> IF TryConfig("/usr/cm3/etc", Filename) THEN RETURN END; >> IF TryConfig("/cm3/etc", Filename) THEN RETURN END; >> IF TryConfig("/usr/contrib/etc", Filename) THEN RETURN END; >> IF TryConfig("/usr/local/etc", Filename) THEN RETURN END; >> IF TryConfig("/usr/etc", Filename) THEN RETURN END; >> IF TryConfig("/opt/etc", Filename) THEN RETURN END; >> IF TryConfig("/sw/etc", Filename) THEN RETURN END; >> IF TryConfig("/etc", Filename) THEN RETURN END; >> >> (* oh well, make sure we don't try this silly exercise again... *) >> config := NIL; >> found := TRUE; >> END FindConfig; >> >> >> I propose..roughly roughly, we make it like this instead: >> >> >> PROCEDURE FindConfig () = >> (* LL = mu *) >> VAR txt: TEXT; >> BEGIN >> IF (found) THEN RETURN END; >> >> (* try the M3CONFIG environment variable *) >> txt := QMachine.GetEnv (NIL, "M3CONFIG"); >> IF (txt # NIL) THEN >> IF TryConfig (txt) THEN RETURN END; >> IF TryConfig (txt, Filename) THEN RETURN END; >> END; >> >> (* try the directory containing the current executable *) >> txt := Pathname.Prefix (Params.Get (0)); >> IF Text.Length (txt)> 0 THEN >> IF TryConfig (txt, Filename) THEN RETURN END; >> END; >> >> (* oh well, make sure we don't try this silly exercise again... *) >> config := NIL; >> found := TRUE; >> END FindConfig; >> >> >> or, if people really like it looking all over the place, fixing >> the case of it being in the current working directory is probably >> like this: >> >> >> (* try the current directory *) >> < IF TryConfig (Filename) THEN RETURN END; >>> IF TryConfig (".", Filename) THEN RETURN END; >> >> >> - Jay >> >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: rcoleburn at scires.com >>> Date: Sun, 2 Aug 2009 23:42:17 -0700 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] problems with cm3.cfg and MxConfig >>> >>> Host, hm, I think probably my mistake. It is defined by cm3 but not >>> all m3quake users. Path() should be the directory containing the >>> file >>> with the call. >>> >>> - Jay (phone) >>> >>> On Aug 2, 2009, at 9:52 PM, "Randy Coleburn" >>> wrote: >>> >>>> I have been working on the problem of cm3ide not getting the >>>> BUILD_DIR from cm3.cfg. I've run across some perplexing test >>>> results. >>>> >>>> MxConfig.Get("BUILD_DIR") is returning NIL on Windows XP & Vista. >>>> I've tracked it down a bit further. There seem to be two issues >>>> that must be fixed to solve this problem: >>>> >>>> 1. HOST does not seem to be defined. In particular my "C:\cm3\bin >>>> \cm3.cfg" file appears as follows (this is the file Jay >>>> recommended): >>>> INSTALL_ROOT = path() & "/.." >>>> include (path() & "/config/" & HOST) >>>> >>>> Is HOST a variable? Or, was I supposed to replace it by "NT386"? >>>> If the latter, my bad on this one--I took Jay's message literally. >>>> >>>> 2. path() does not appear to always yield the path to the bin >>>> folder. In particular, it seems to work fine unless you invoke the >>>> program when the current directory is actually set to the bin >>>> folder, in which case path() seems to return the empty string. >>>> >>>> So, if ?%=C:\, and I run cm3ide, path() returns "C:\cm3\bin" as >>>> it s >>>> hould. >>>> But, if ?%=C:\cm3\bin, and I run cm3ide, path() returns "". >>>> >>>> So in the latter case, the include statement winds up trying to >>>> pull >>>> a file from the wrong place, e.g. "/config/NT386" rather than "C: >>>> \cm3\bin/config/NT386" >>>> >>>> Regards, >>>> Randy Coleburn > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Aug 3 16:02:12 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 3 Aug 2009 10:02:12 -0400 Subject: [M3devel] assembly goes to C compiler? In-Reply-To: <20090803131048.GB24864@topoi.pooq.com> References: <20090803132158.walcuy2s00wck04g@mail.elegosoft.com> <20090803131048.GB24864@topoi.pooq.com> Message-ID: <4AD30F1F-90E6-48F8-B93C-6889E8D2BAF4@cs.purdue.edu> Using the C compiler allows the assembly to have preprocessor directives. On 3 Aug 2009, at 09:10, hendrik at topoi.pooq.com wrote: > On Mon, Aug 03, 2009 at 01:21:58PM +0200, Olaf Wagner wrote: >> >> That doesn't sound very nice. We should really investigate why >> RunCC is used even for assembly code. > > Just a guess -- could using a C compiler give the assembler code > access > to the X library? > > - hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Aug 3 16:36:25 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 03 Aug 2009 16:36:25 +0200 Subject: [M3devel] assembly goes to C compiler? In-Reply-To: <4AD30F1F-90E6-48F8-B93C-6889E8D2BAF4@cs.purdue.edu> References: <20090803132158.walcuy2s00wck04g@mail.elegosoft.com> <20090803131048.GB24864@topoi.pooq.com> <4AD30F1F-90E6-48F8-B93C-6889E8D2BAF4@cs.purdue.edu> Message-ID: <20090803163625.qm007v2pfog8s8sg@mail.elegosoft.com> Quoting Tony Hosking : > Using the C compiler allows the assembly to have preprocessor directives. So you think it's a feature. Why do we have the assemble methods in the config file then? Or are they just legacy? %---------------------------------------------------------------- assembler --- % "assemble" is called to assemble .s or .asm files. Note that this function % is only called if your program or library explicitly includes assembly source % code, the system distributed by Critical Mass does not. proc assemble(source, object) is if defined("configure_assembler") configure_assembler() end return try_exec("@" & SYSTEM_ASM, source, "-o", object) end Probably a remnant of DEC SRC M3? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Mon Aug 3 16:42:21 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 03 Aug 2009 16:42:21 +0200 Subject: [M3devel] cm3.cfg et all, loc Message-ID: <1249310541.28197.746.camel@faramir.m3w.org> Excuse me for being a Martian here, esp on this topic, but I must agree, and loudly, with few voices on cm3.cfg location. In non-Windows world, /etc/ is natural place for anything config. Would it, or would it not be editable is another concern, mostly not important - if it's so absolutely uneditable then let it be m3bundled. It's up to packager to decide, of course... But I think everything will be much easier (esp this path() bussiness) if we decide to put these files somewhere standard. In Linux case, /etc. And included files in /etc/cm3/. MxConfig will have less problems to work as advertised, if nothing else :). -- Dragi?a Duri? From wagner at elegosoft.com Mon Aug 3 17:25:37 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 03 Aug 2009 17:25:37 +0200 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> Message-ID: <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> Quoting Tony Hosking : > I don't think we did agree that config files reside other than in the > cm3 hierarchy. I may have been too quick to extend the search path some weeks ago. I'm really undecided myself. I guess the score currently is +2 for cm3/ +1 /etc :-) But we should perhaps really come to an agreement that is acceptable for all here. Olaf > On 3 Aug 2009, at 06:30, Olaf Wagner wrote: > >> It was a specific request from the people building platform specific >> installation packages that config files reside and are found in the >> `usual' locations on their system and not somewhere beneath cm3. >> >> Place don't change that unless there is no objection from anyone >> on m3devel. >> >> Olaf >> >> Quoting Jay K : >> >>> Sorry about #1 Randy, my mistake. >>> >>> >>> Sitting in the bin directory...seems a little wierd, eh? >>> What source are you going to build sitting there? >>> I guess um some custom quake code?? >>> Good enough if empty is instead just "."? >>> >>> This falls out of the fact that cm3 actually probes all over the >>> place for the cm3.cfg file and the first place it looks in is the >>> current directory. >>> >>> >>> Another good option I think would be just to remove that probe. >>> It looks in way too many places. >>> >>> >>> Here is the current code. I think it is gross. >>> Too much probing make things quite ambiguous. >>> >>> >>> PROCEDURE FindConfig () = >>> (* LL = mu *) >>> VAR txt: TEXT; >>> BEGIN >>> IF (found) THEN RETURN END; >>> >>> (* try the current directory *) >>> IF TryConfig (Filename) THEN RETURN END; >>> >>> (* try the immediate source directory *) >>> IF TryConfig ("src", Filename) THEN RETURN END; >>> >>> (* try the sibling source directory *) >>> IF TryConfig ("..", "src", Filename) THEN RETURN END; >>> >>> (* try the M3CONFIG environment variable *) >>> txt := QMachine.GetEnv (NIL, "M3CONFIG"); >>> IF (txt # NIL) THEN >>> IF TryConfig (txt) THEN RETURN END; >>> IF TryConfig (txt, Filename) THEN RETURN END; >>> END; >>> >>> (* try the directory containing the current executable *) >>> txt := Pathname.Prefix (Params.Get (0)); >>> >>> IF Text.Length (txt)> 0 THEN >>> IF TryConfig (txt, Filename) THEN RETURN END; >>> END; >>> >>> (* try the directories named by the PATH environment variable. *) >>> txt := Env.Get ("PATH"); >>> FindConfigInPath (txt); >>> >>> IF found THEN RETURN END; >>> >>> (* try the etc directories *) >>> IF TryConfig("/usr/local/cm3/etc", Filename) THEN RETURN END; >>> IF TryConfig("/usr/cm3/etc", Filename) THEN RETURN END; >>> IF TryConfig("/cm3/etc", Filename) THEN RETURN END; >>> IF TryConfig("/usr/contrib/etc", Filename) THEN RETURN END; >>> IF TryConfig("/usr/local/etc", Filename) THEN RETURN END; >>> IF TryConfig("/usr/etc", Filename) THEN RETURN END; >>> IF TryConfig("/opt/etc", Filename) THEN RETURN END; >>> IF TryConfig("/sw/etc", Filename) THEN RETURN END; >>> IF TryConfig("/etc", Filename) THEN RETURN END; >>> >>> (* oh well, make sure we don't try this silly exercise again... *) >>> config := NIL; >>> found := TRUE; >>> END FindConfig; >>> >>> >>> I propose..roughly roughly, we make it like this instead: >>> >>> >>> PROCEDURE FindConfig () = >>> (* LL = mu *) >>> VAR txt: TEXT; >>> BEGIN >>> IF (found) THEN RETURN END; >>> >>> (* try the M3CONFIG environment variable *) >>> txt := QMachine.GetEnv (NIL, "M3CONFIG"); >>> IF (txt # NIL) THEN >>> IF TryConfig (txt) THEN RETURN END; >>> IF TryConfig (txt, Filename) THEN RETURN END; >>> END; >>> >>> (* try the directory containing the current executable *) >>> txt := Pathname.Prefix (Params.Get (0)); >>> IF Text.Length (txt)> 0 THEN >>> IF TryConfig (txt, Filename) THEN RETURN END; >>> END; >>> >>> (* oh well, make sure we don't try this silly exercise again... *) >>> config := NIL; >>> found := TRUE; >>> END FindConfig; >>> >>> >>> or, if people really like it looking all over the place, fixing >>> the case of it being in the current working directory is probably >>> like this: >>> >>> >>> (* try the current directory *) >>> < IF TryConfig (Filename) THEN RETURN END; >>>> IF TryConfig (".", Filename) THEN RETURN END; >>> >>> >>> - Jay >>> >>> >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: rcoleburn at scires.com >>>> Date: Sun, 2 Aug 2009 23:42:17 -0700 >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] problems with cm3.cfg and MxConfig >>>> >>>> Host, hm, I think probably my mistake. It is defined by cm3 but not >>>> all m3quake users. Path() should be the directory containing the file >>>> with the call. >>>> >>>> - Jay (phone) >>>> >>>> On Aug 2, 2009, at 9:52 PM, "Randy Coleburn" >>>> wrote: >>>> >>>>> I have been working on the problem of cm3ide not getting the >>>>> BUILD_DIR from cm3.cfg. I've run across some perplexing test results. >>>>> >>>>> MxConfig.Get("BUILD_DIR") is returning NIL on Windows XP & Vista. >>>>> I've tracked it down a bit further. There seem to be two issues >>>>> that must be fixed to solve this problem: >>>>> >>>>> 1. HOST does not seem to be defined. In particular my "C:\cm3\bin >>>>> \cm3.cfg" file appears as follows (this is the file Jay recommended): >>>>> INSTALL_ROOT = path() & "/.." >>>>> include (path() & "/config/" & HOST) >>>>> >>>>> Is HOST a variable? Or, was I supposed to replace it by "NT386"? >>>>> If the latter, my bad on this one--I took Jay's message literally. >>>>> >>>>> 2. path() does not appear to always yield the path to the bin >>>>> folder. In particular, it seems to work fine unless you invoke the >>>>> program when the current directory is actually set to the bin >>>>> folder, in which case path() seems to return the empty string. >>>>> >>>>> So, if ?%=C:\, and I run cm3ide, path() returns "C:\cm3\bin" as it s >>>>> hould. >>>>> But, if ?%=C:\cm3\bin, and I run cm3ide, path() returns "". >>>>> >>>>> So in the latter case, the include statement winds up trying to pull >>>>> a file from the wrong place, e.g. "/config/NT386" rather than "C: >>>>> \cm3\bin/config/NT386" >>>>> >>>>> Regards, >>>>> Randy Coleburn >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >> 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rcoleburn at scires.com Mon Aug 3 17:27:44 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 03 Aug 2009 11:27:44 -0400 Subject: [M3devel] problems with cm3.cfg and MxConfig In-Reply-To: References: <4A763446.1E75.00D7.1@scires.com> Message-ID: <4A76C915.1E75.00D7.1@scires.com> Jay: No problem. I think you are trying to make it more flexible, and that is good. I just ran into a problem with cm3ide. The shortcut I use to launch cm3ide causes the current dir to be the "bin" folder. So, using your new cm3.cfg, I was always having a problem with (path() & "/config/"), since it would be trying to find "config" at the root of the file system when path() returned the empty string. Since "/config" wasn't found, none of the other parts of your include file were ever processed, hence, BUILD_DIR would never be found. I gather that path() is supposed to return the path to the cm3.cfg file. If this is true, then returning "" is not really a path, so the function seems broken when cm3.cfg is in the current dir. Returning "." makes more sense for this case and would allow the rest of your cm3.cfg file to work I think, provided that HOST is defined or that it is replaced by the actual text. Regards, Randy >>> Jay K 8/3/2009 5:05 AM >>> Sorry about #1 Randy, my mistake. Sitting in the bin directory...seems a little wierd, eh? What source are you going to build sitting there? I guess um some custom quake code?? Good enough if empty is instead just "."? This falls out of the fact that cm3 actually probes all over the place for the cm3.cfg file and the first place it looks in is the current directory. Another good option I think would be just to remove that probe. It looks in way too many places. Here is the current code. I think it is gross. Too much probing make things quite ambiguous. PROCEDURE FindConfig () = (* LL = mu *) VAR txt: TEXT; BEGIN IF (found) THEN RETURN END; (* try the current directory *) IF TryConfig (Filename) THEN RETURN END; (* try the immediate source directory *) IF TryConfig ("src", Filename) THEN RETURN END; (* try the sibling source directory *) IF TryConfig ("..", "src", Filename) THEN RETURN END; (* try the M3CONFIG environment variable *) txt := QMachine.GetEnv (NIL, "M3CONFIG"); IF (txt # NIL) THEN IF TryConfig (txt) THEN RETURN END; IF TryConfig (txt, Filename) THEN RETURN END; END; (* try the directory containing the current executable *) txt := Pathname.Prefix (Params.Get (0)); IF Text.Length (txt)> 0 THEN IF TryConfig (txt, Filename) THEN RETURN END; END; (* try the directories named by the PATH environment variable. *) txt := Env.Get ("PATH"); FindConfigInPath (txt); IF found THEN RETURN END; (* try the etc directories *) IF TryConfig("/usr/local/cm3/etc", Filename) THEN RETURN END; IF TryConfig("/usr/cm3/etc", Filename) THEN RETURN END; IF TryConfig("/cm3/etc", Filename) THEN RETURN END; IF TryConfig("/usr/contrib/etc", Filename) THEN RETURN END; IF TryConfig("/usr/local/etc", Filename) THEN RETURN END; IF TryConfig("/usr/etc", Filename) THEN RETURN END; IF TryConfig("/opt/etc", Filename) THEN RETURN END; IF TryConfig("/sw/etc", Filename) THEN RETURN END; IF TryConfig("/etc", Filename) THEN RETURN END; (* oh well, make sure we don't try this silly exercise again... *) config := NIL; found := TRUE; END FindConfig; I propose..roughly roughly, we make it like this instead: PROCEDURE FindConfig () = (* LL = mu *) VAR txt: TEXT; BEGIN IF (found) THEN RETURN END; (* try the M3CONFIG environment variable *) txt := QMachine.GetEnv (NIL, "M3CONFIG"); IF (txt # NIL) THEN IF TryConfig (txt) THEN RETURN END; IF TryConfig (txt, Filename) THEN RETURN END; END; (* try the directory containing the current executable *) txt := Pathname.Prefix (Params.Get (0)); IF Text.Length (txt)> 0 THEN IF TryConfig (txt, Filename) THEN RETURN END; END; (* oh well, make sure we don't try this silly exercise again... *) config := NIL; found := TRUE; END FindConfig; or, if people really like it looking all over the place, fixing the case of it being in the current working directory is probably like this: (* try the current directory *) < IF TryConfig (Filename) THEN RETURN END; > IF TryConfig (".", Filename) THEN RETURN END; - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: rcoleburn at scires.com > Date: Sun, 2 Aug 2009 23:42:17 -0700 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] problems with cm3.cfg and MxConfig > > Host, hm, I think probably my mistake. It is defined by cm3 but not > all m3quake users. Path() should be the directory containing the file > with the call. > > - Jay (phone) > > On Aug 2, 2009, at 9:52 PM, "Randy Coleburn" > wrote: > >> I have been working on the problem of cm3ide not getting the >> BUILD_DIR from cm3.cfg. I've run across some perplexing test results. >> >> MxConfig.Get("BUILD_DIR") is returning NIL on Windows XP & Vista. >> I've tracked it down a bit further. There seem to be two issues >> that must be fixed to solve this problem: >> >> 1. HOST does not seem to be defined. In particular my "C:\cm3\bin >> \cm3.cfg" file appears as follows (this is the file Jay recommended): >> INSTALL_ROOT = path() & "/.." >> include (path() & "/config/" & HOST) >> >> Is HOST a variable? Or, was I supposed to replace it by "NT386"? >> If the latter, my bad on this one--I took Jay's message literally. >> >> 2. path() does not appear to always yield the path to the bin >> folder. In particular, it seems to work fine unless you invoke the >> program when the current directory is actually set to the bin >> folder, in which case path() seems to return the empty string. >> >> So, if ?%=C:\, and I run cm3ide, path() returns "C:\cm3\bin" as it s >> hould. >> But, if ?%=C:\cm3\bin, and I run cm3ide, path() returns "". >> >> So in the latter case, the include statement winds up trying to pull >> a file from the wrong place, e.g. "/config/NT386" rather than "C: >> \cm3\bin/config/NT386" >> >> Regards, >> Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Mon Aug 3 17:35:18 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 03 Aug 2009 11:35:18 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20090803093135.3F59DCC81B@birch.elegosoft.com> References: <20090803093135.3F59DCC81B@birch.elegosoft.com> Message-ID: <4A76CADA.1E75.00D7.1@scires.com> Jay: I agree that running cm3 from "bin" folder is not going to be productive; however, other programs (such as cm3ide) also use the quake stuff and they don't have this limitation. I think your change is a good one. I'll run some tests and see how cm3ide fares. Thanks. --Randy >>> Jay Krell 8/3/2009 11:31 AM >>> CVSROOT:/usr/cvs Changes by:jkrell at birch.09/08/03 11:31:35 Modified files: cm3/m3-sys/m3quake/src/: MxConfig.m3 Log message: use "." instead of empty string for path() when current working directory is the actual directory of cm3; not sure what good running cm3 here is, and we probe way too many places.. CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at darko.org Mon Aug 3 20:59:26 2009 From: lists at darko.org (Darko Volaric) Date: Mon, 3 Aug 2009 20:59:26 +0200 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> Message-ID: Putting it in /etc would mean that having different active versions of compiler would e a pain, which is useful when developing, debugging or trying out new versions of the compiler and when compilers are not self hosted, which will be the case for ARM_DARWIN. What's the benefit of having it /etc other than being "standard"? On 03/08/2009, at 5:25 PM, Olaf Wagner wrote: > Quoting Tony Hosking : > >> I don't think we did agree that config files reside other than in the >> cm3 hierarchy. > > I may have been too quick to extend the search path some weeks ago. > I'm really undecided myself. I guess the score currently is > +2 for cm3/ +1 /etc :-) > > But we should perhaps really come to an agreement that is acceptable > for all here. > > Olaf > >> On 3 Aug 2009, at 06:30, Olaf Wagner wrote: >> >>> It was a specific request from the people building platform specific >>> installation packages that config files reside and are found in the >>> `usual' locations on their system and not somewhere beneath cm3. >>> >>> Place don't change that unless there is no objection from anyone >>> on m3devel. >>> >>> Olaf >>> >>> Quoting Jay K : >>> >>>> Sorry about #1 Randy, my mistake. >>>> >>>> >>>> Sitting in the bin directory...seems a little wierd, eh? >>>> What source are you going to build sitting there? >>>> I guess um some custom quake code?? >>>> Good enough if empty is instead just "."? >>>> >>>> This falls out of the fact that cm3 actually probes all over >>>> the place for the cm3.cfg file and the first place it looks in >>>> is the current directory. >>>> >>>> >>>> Another good option I think would be just to remove that probe. >>>> It looks in way too many places. >>>> >>>> >>>> Here is the current code. I think it is gross. >>>> Too much probing make things quite ambiguous. >>>> >>>> >>>> PROCEDURE FindConfig () = >>>> (* LL = mu *) >>>> VAR txt: TEXT; >>>> BEGIN >>>> IF (found) THEN RETURN END; >>>> >>>> (* try the current directory *) >>>> IF TryConfig (Filename) THEN RETURN END; >>>> >>>> (* try the immediate source directory *) >>>> IF TryConfig ("src", Filename) THEN RETURN END; >>>> >>>> (* try the sibling source directory *) >>>> IF TryConfig ("..", "src", Filename) THEN RETURN END; >>>> >>>> (* try the M3CONFIG environment variable *) >>>> txt := QMachine.GetEnv (NIL, "M3CONFIG"); >>>> IF (txt # NIL) THEN >>>> IF TryConfig (txt) THEN RETURN END; >>>> IF TryConfig (txt, Filename) THEN RETURN END; >>>> END; >>>> >>>> (* try the directory containing the current executable *) >>>> txt := Pathname.Prefix (Params.Get (0)); >>>> >>>> IF Text.Length (txt)> 0 THEN >>>> IF TryConfig (txt, Filename) THEN RETURN END; >>>> END; >>>> >>>> (* try the directories named by the PATH environment variable. *) >>>> txt := Env.Get ("PATH"); >>>> FindConfigInPath (txt); >>>> >>>> IF found THEN RETURN END; >>>> >>>> (* try the etc directories *) >>>> IF TryConfig("/usr/local/cm3/etc", Filename) THEN RETURN END; >>>> IF TryConfig("/usr/cm3/etc", Filename) THEN RETURN END; >>>> IF TryConfig("/cm3/etc", Filename) THEN RETURN END; >>>> IF TryConfig("/usr/contrib/etc", Filename) THEN RETURN END; >>>> IF TryConfig("/usr/local/etc", Filename) THEN RETURN END; >>>> IF TryConfig("/usr/etc", Filename) THEN RETURN END; >>>> IF TryConfig("/opt/etc", Filename) THEN RETURN END; >>>> IF TryConfig("/sw/etc", Filename) THEN RETURN END; >>>> IF TryConfig("/etc", Filename) THEN RETURN END; >>>> >>>> (* oh well, make sure we don't try this silly exercise again... *) >>>> config := NIL; >>>> found := TRUE; >>>> END FindConfig; >>>> >>>> >>>> I propose..roughly roughly, we make it like this instead: >>>> >>>> >>>> PROCEDURE FindConfig () = >>>> (* LL = mu *) >>>> VAR txt: TEXT; >>>> BEGIN >>>> IF (found) THEN RETURN END; >>>> >>>> (* try the M3CONFIG environment variable *) >>>> txt := QMachine.GetEnv (NIL, "M3CONFIG"); >>>> IF (txt # NIL) THEN >>>> IF TryConfig (txt) THEN RETURN END; >>>> IF TryConfig (txt, Filename) THEN RETURN END; >>>> END; >>>> >>>> (* try the directory containing the current executable *) >>>> txt := Pathname.Prefix (Params.Get (0)); >>>> IF Text.Length (txt)> 0 THEN >>>> IF TryConfig (txt, Filename) THEN RETURN END; >>>> END; >>>> >>>> (* oh well, make sure we don't try this silly exercise again... *) >>>> config := NIL; >>>> found := TRUE; >>>> END FindConfig; >>>> >>>> >>>> or, if people really like it looking all over the place, fixing >>>> the case of it being in the current working directory is >>>> probably like this: >>>> >>>> >>>> (* try the current directory *) >>>> < IF TryConfig (Filename) THEN RETURN END; >>>>> IF TryConfig (".", Filename) THEN RETURN END; >>>> >>>> >>>> - Jay >>>> >>>> >>>> >>>> ---------------------------------------- >>>>> From: jay.krell at cornell.edu >>>>> To: rcoleburn at scires.com >>>>> Date: Sun, 2 Aug 2009 23:42:17 -0700 >>>>> CC: m3devel at elegosoft.com >>>>> Subject: Re: [M3devel] problems with cm3.cfg and MxConfig >>>>> >>>>> Host, hm, I think probably my mistake. It is defined by cm3 but >>>>> not >>>>> all m3quake users. Path() should be the directory containing >>>>> the file >>>>> with the call. >>>>> >>>>> - Jay (phone) >>>>> >>>>> On Aug 2, 2009, at 9:52 PM, "Randy Coleburn" >>>>> wrote: >>>>> >>>>>> I have been working on the problem of cm3ide not getting the >>>>>> BUILD_DIR from cm3.cfg. I've run across some perplexing test >>>>>> results. >>>>>> >>>>>> MxConfig.Get("BUILD_DIR") is returning NIL on Windows XP & Vista. >>>>>> I've tracked it down a bit further. There seem to be two issues >>>>>> that must be fixed to solve this problem: >>>>>> >>>>>> 1. HOST does not seem to be defined. In particular my "C:\cm3\bin >>>>>> \cm3.cfg" file appears as follows (this is the file Jay >>>>>> recommended): >>>>>> INSTALL_ROOT = path() & "/.." >>>>>> include (path() & "/config/" & HOST) >>>>>> >>>>>> Is HOST a variable? Or, was I supposed to replace it by "NT386"? >>>>>> If the latter, my bad on this one--I took Jay's message >>>>>> literally. >>>>>> >>>>>> 2. path() does not appear to always yield the path to the bin >>>>>> folder. In particular, it seems to work fine unless you invoke >>>>>> the >>>>>> program when the current directory is actually set to the bin >>>>>> folder, in which case path() seems to return the empty string. >>>>>> >>>>>> So, if ?%=C:\, and I run cm3ide, path() returns "C:\cm3\bin" >>>>>> as it s >>>>>> hould. >>>>>> But, if ?%=C:\cm3\bin, and I run cm3ide, path() returns "". >>>>>> >>>>>> So in the latter case, the include statement winds up trying >>>>>> to pull >>>>>> a file from the wrong place, e.g. "/config/NT386" rather than "C: >>>>>> \cm3\bin/config/NT386" >>>>>> >>>>>> Regards, >>>>>> Randy Coleburn >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>> Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>> 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>> Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From rcoleburn at scires.com Mon Aug 3 21:17:30 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 03 Aug 2009 15:17:30 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <4A76CADA.1E75.00D7.1@scires.com> References: <20090803093135.3F59DCC81B@birch.elegosoft.com> <4A76CADA.1E75.00D7.1@scires.com> Message-ID: <4A76FEED.1E75.00D7.1@scires.com> Jay: Your change to MxConfig.m3 seems to work fine for cm3ide, provided that I replace HOST by "NT386" in my cm3.cfg is as follows: INSTALL_ROOT = path() & "/.." include (path() & "/config/NT386") Thank you! Can we get your revised MxConfig.m3 put into the RC2 branch? Regards, Randy >>> "Randy Coleburn" 8/3/2009 11:35 AM >>> Jay: I agree that running cm3 from "bin" folder is not going to be productive; however, other programs (such as cm3ide) also use the quake stuff and they don't have this limitation. I think your change is a good one. I'll run some tests and see how cm3ide fares. Thanks. --Randy >>> Jay Krell 8/3/2009 11:31 AM >>> CVSROOT:/usr/cvs Changes by:jkrell at birch.09/08/03 11:31:35 Modified files: cm3/m3-sys/m3quake/src/: MxConfig.m3 Log message: use "." instead of empty string for path() when current working directory is the actual directory of cm3; not sure what good running cm3 here is, and we probe way too many places.. CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Mon Aug 3 22:10:02 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 03 Aug 2009 22:10:02 +0200 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> Message-ID: <1249330202.28197.748.camel@faramir.m3w.org> One day when we start thinking about configurations other than "developing, debugging or trying out new versions of the compiler" we will be ready for people other than m3devel readership. On Mon, 2009-08-03 at 20:59 +0200, Darko Volaric wrote: > Putting it in /etc would mean that having different active versions of > compiler would e a pain, which is useful when developing, debugging or > trying out new versions of the compiler and when compilers are not > self hosted, which will be the case for ARM_DARWIN. > > What's the benefit of having it /etc other than being "standard"? > > > On 03/08/2009, at 5:25 PM, Olaf Wagner wrote: > > > Quoting Tony Hosking : > > > >> I don't think we did agree that config files reside other than in the > >> cm3 hierarchy. > > > > I may have been too quick to extend the search path some weeks ago. > > I'm really undecided myself. I guess the score currently is > > +2 for cm3/ +1 /etc :-) > > > > But we should perhaps really come to an agreement that is acceptable > > for all here. > > > > Olaf > > > >> On 3 Aug 2009, at 06:30, Olaf Wagner wrote: > >> > >>> It was a specific request from the people building platform specific > >>> installation packages that config files reside and are found in the > >>> `usual' locations on their system and not somewhere beneath cm3. > >>> > >>> Place don't change that unless there is no objection from anyone > >>> on m3devel. > >>> > >>> Olaf > >>> > >>> Quoting Jay K : > >>> > >>>> Sorry about #1 Randy, my mistake. > >>>> > >>>> > >>>> Sitting in the bin directory...seems a little wierd, eh? > >>>> What source are you going to build sitting there? > >>>> I guess um some custom quake code?? > >>>> Good enough if empty is instead just "."? > >>>> > >>>> This falls out of the fact that cm3 actually probes all over > >>>> the place for the cm3.cfg file and the first place it looks in > >>>> is the current directory. > >>>> > >>>> > >>>> Another good option I think would be just to remove that probe. > >>>> It looks in way too many places. > >>>> > >>>> > >>>> Here is the current code. I think it is gross. > >>>> Too much probing make things quite ambiguous. > >>>> > >>>> > >>>> PROCEDURE FindConfig () = > >>>> (* LL = mu *) > >>>> VAR txt: TEXT; > >>>> BEGIN > >>>> IF (found) THEN RETURN END; > >>>> > >>>> (* try the current directory *) > >>>> IF TryConfig (Filename) THEN RETURN END; > >>>> > >>>> (* try the immediate source directory *) > >>>> IF TryConfig ("src", Filename) THEN RETURN END; > >>>> > >>>> (* try the sibling source directory *) > >>>> IF TryConfig ("..", "src", Filename) THEN RETURN END; > >>>> > >>>> (* try the M3CONFIG environment variable *) > >>>> txt := QMachine.GetEnv (NIL, "M3CONFIG"); > >>>> IF (txt # NIL) THEN > >>>> IF TryConfig (txt) THEN RETURN END; > >>>> IF TryConfig (txt, Filename) THEN RETURN END; > >>>> END; > >>>> > >>>> (* try the directory containing the current executable *) > >>>> txt := Pathname.Prefix (Params.Get (0)); > >>>> > >>>> IF Text.Length (txt)> 0 THEN > >>>> IF TryConfig (txt, Filename) THEN RETURN END; > >>>> END; > >>>> > >>>> (* try the directories named by the PATH environment variable. *) > >>>> txt := Env.Get ("PATH"); > >>>> FindConfigInPath (txt); > >>>> > >>>> IF found THEN RETURN END; > >>>> > >>>> (* try the etc directories *) > >>>> IF TryConfig("/usr/local/cm3/etc", Filename) THEN RETURN END; > >>>> IF TryConfig("/usr/cm3/etc", Filename) THEN RETURN END; > >>>> IF TryConfig("/cm3/etc", Filename) THEN RETURN END; > >>>> IF TryConfig("/usr/contrib/etc", Filename) THEN RETURN END; > >>>> IF TryConfig("/usr/local/etc", Filename) THEN RETURN END; > >>>> IF TryConfig("/usr/etc", Filename) THEN RETURN END; > >>>> IF TryConfig("/opt/etc", Filename) THEN RETURN END; > >>>> IF TryConfig("/sw/etc", Filename) THEN RETURN END; > >>>> IF TryConfig("/etc", Filename) THEN RETURN END; > >>>> > >>>> (* oh well, make sure we don't try this silly exercise again... *) > >>>> config := NIL; > >>>> found := TRUE; > >>>> END FindConfig; > >>>> > >>>> > >>>> I propose..roughly roughly, we make it like this instead: > >>>> > >>>> > >>>> PROCEDURE FindConfig () = > >>>> (* LL = mu *) > >>>> VAR txt: TEXT; > >>>> BEGIN > >>>> IF (found) THEN RETURN END; > >>>> > >>>> (* try the M3CONFIG environment variable *) > >>>> txt := QMachine.GetEnv (NIL, "M3CONFIG"); > >>>> IF (txt # NIL) THEN > >>>> IF TryConfig (txt) THEN RETURN END; > >>>> IF TryConfig (txt, Filename) THEN RETURN END; > >>>> END; > >>>> > >>>> (* try the directory containing the current executable *) > >>>> txt := Pathname.Prefix (Params.Get (0)); > >>>> IF Text.Length (txt)> 0 THEN > >>>> IF TryConfig (txt, Filename) THEN RETURN END; > >>>> END; > >>>> > >>>> (* oh well, make sure we don't try this silly exercise again... *) > >>>> config := NIL; > >>>> found := TRUE; > >>>> END FindConfig; > >>>> > >>>> > >>>> or, if people really like it looking all over the place, fixing > >>>> the case of it being in the current working directory is > >>>> probably like this: > >>>> > >>>> > >>>> (* try the current directory *) > >>>> < IF TryConfig (Filename) THEN RETURN END; > >>>>> IF TryConfig (".", Filename) THEN RETURN END; > >>>> > >>>> > >>>> - Jay > >>>> > >>>> > >>>> > >>>> ---------------------------------------- > >>>>> From: jay.krell at cornell.edu > >>>>> To: rcoleburn at scires.com > >>>>> Date: Sun, 2 Aug 2009 23:42:17 -0700 > >>>>> CC: m3devel at elegosoft.com > >>>>> Subject: Re: [M3devel] problems with cm3.cfg and MxConfig > >>>>> > >>>>> Host, hm, I think probably my mistake. It is defined by cm3 but > >>>>> not > >>>>> all m3quake users. Path() should be the directory containing > >>>>> the file > >>>>> with the call. > >>>>> > >>>>> - Jay (phone) > >>>>> > >>>>> On Aug 2, 2009, at 9:52 PM, "Randy Coleburn" > >>>>> wrote: > >>>>> > >>>>>> I have been working on the problem of cm3ide not getting the > >>>>>> BUILD_DIR from cm3.cfg. I've run across some perplexing test > >>>>>> results. > >>>>>> > >>>>>> MxConfig.Get("BUILD_DIR") is returning NIL on Windows XP & Vista. > >>>>>> I've tracked it down a bit further. There seem to be two issues > >>>>>> that must be fixed to solve this problem: > >>>>>> > >>>>>> 1. HOST does not seem to be defined. In particular my "C:\cm3\bin > >>>>>> \cm3.cfg" file appears as follows (this is the file Jay > >>>>>> recommended): > >>>>>> INSTALL_ROOT = path() & "/.." > >>>>>> include (path() & "/config/" & HOST) > >>>>>> > >>>>>> Is HOST a variable? Or, was I supposed to replace it by "NT386"? > >>>>>> If the latter, my bad on this one--I took Jay's message > >>>>>> literally. > >>>>>> > >>>>>> 2. path() does not appear to always yield the path to the bin > >>>>>> folder. In particular, it seems to work fine unless you invoke > >>>>>> the > >>>>>> program when the current directory is actually set to the bin > >>>>>> folder, in which case path() seems to return the empty string. > >>>>>> > >>>>>> So, if ?%=C:\, and I run cm3ide, path() returns "C:\cm3\bin" > >>>>>> as it s > >>>>>> hould. > >>>>>> But, if ?%=C:\cm3\bin, and I run cm3ide, path() returns "". > >>>>>> > >>>>>> So in the latter case, the include statement winds up trying > >>>>>> to pull > >>>>>> a file from the wrong place, e.g. "/config/NT386" rather than "C: > >>>>>> \cm3\bin/config/NT386" > >>>>>> > >>>>>> Regards, > >>>>>> Randy Coleburn > >>> > >>> > >>> > >>> -- > >>> Olaf Wagner -- elego Software Solutions GmbH > >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > >>> Germany > >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 > >>> 23 45 86 95 > >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > >>> Berlin > >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > >>> DE163214194 > >>> > > > > > > > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > > Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > > 45 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > > Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > > DE163214194 > > > -- Dragi?a Duri? From wagner at elegosoft.com Mon Aug 3 23:15:45 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 03 Aug 2009 23:15:45 +0200 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> Message-ID: <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> Quoting Darko Volaric : > Putting it in /etc would mean that having different active versions of > compiler would e a pain, which is useful when developing, debugging or > trying out new versions of the compiler and when compilers are not self > hosted, which will be the case for ARM_DARWIN. > > What's the benefit of having it /etc other than being "standard"? The compiler searches in a list of locations and takes the first one found, as is the convention when doing path searches. AFAIK /etc is currently the last option at all. Perhaps we should try to gather the facts and write up a pro/cons list for different options. In all previous releases cm3 used the following strategy to find its configuration: "traditional" (1) ./cm3.cfg (2) src/cm3.cfg (3) ../src/cm3.cfg (4) $M3CONFIG (5) Pathname.Prefix( Params.Get( 0 )) (6) for p in $PATH: try p/cm3.cfg (7) give up... Because people were complaining that it wasn't possible to adhere to common system conventions with CM3 installation packages, I extended this strategy like this: "extended" (1)..(6) same as above (7) /usr/local/cm3/etc/cm3.cfg (8) /usr/cm3/etc/cm3.cfg (9) /cm3/etc/cm3.cfg (10) /usr/contrib/etc/cm3.cfg (11) /usr/local/etc/cm3.cfg (12) /usr/etc/cm3.cfg (13) /opt/etc/cm3.cfg (14) /sw/etc/cm3.cfg (15) /etc/cm3.cfg I do insist neither on this list nor the order or the locations themselves. On the other hand I do not see much harm in an extension like this, allowing a certain degree of freedom for those preparing system dependent installation packages. Recently Jay suggested to radically change the strategy: "reduced" (1) $M3CONFIG (2) Pathname.Prefix( Params.Get( 0 )) (3) give up We should now consider the advantages and disadvantages of each of the proposals. The following lists are not complete; I just make a start and others please extend as they see fit: "traditional" advantages: o seems to have worked OK with cm3, cm3ide etc. until now -- never change a running system (not very convincing ;-) disadvantages: o system dependent non-standard values only possible via environment settings M3CONFIG or PATH o not simple and easy to remember "extended" advantages: o just an extension to existing strategy o allows for several conventional standard locations for config files disadvantages: o not simple and easy to remember, may be confusing "reduced" advantages: o simple and easy to remember disadvantages: o system dependent non-standard values only possible via environment setting of M3CONFIG o may be incompatible with certain use cases of cm3 and cm3ide (to be investigated) There are also the general arguments saying that "no (user) configuration of cm3 is needed at all" (really?) and "that may be said of a lot of tools and services whose config files live in /etc/ and may just be adapted by root" "we should heed the standards and conventions of existing systems in order to be used" That's of course just a start, I'm sure I have forgotten many good arguments. Let's try to keep to the facts as much as possible though. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Mon Aug 3 23:21:41 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 03 Aug 2009 23:21:41 +0200 Subject: [M3devel] /etc/cm3.cfg (was: HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig) In-Reply-To: <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> Message-ID: <1249334501.28197.750.camel@faramir.m3w.org> On Mon, 2009-08-03 at 23:15 +0200, Olaf Wagner wrote: > The compiler searches in a list of locations and takes the first > one found, as is the convention when doing path searches. AFAIK > /etc is currently the last option at all. Tried this today, and what happened was - cm3 set PKG_INSTALL to "/" and I was unable to build anything until I moved cm3.cfg back to where cm3 binary is. -- Dragi?a Duri? From hendrik at topoi.pooq.com Mon Aug 3 23:29:36 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 3 Aug 2009 17:29:36 -0400 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> Message-ID: <20090803212936.GA25621@topoi.pooq.com> On Mon, Aug 03, 2009 at 08:59:26PM +0200, Darko Volaric wrote: > Putting it in /etc would mean that having different active versions of > compiler would e a pain, which is useful when developing, debugging or > trying out new versions of the compiler and when compilers are not > self hosted, which will be the case for ARM_DARWIN. > > What's the benefit of having it /etc other than being "standard"? Things in /etc/ are things that a system administrator might want to tweak. At least that was the idea originally. These options we're talking about seem somewhat different, in that they are tightly bound with the software itself. I say they are more like executable code than like configuration files. If a Debian user were to install cm3.deb, they had damn well point to the place the package put the compiler and friends. I don't see the being usefully modified at all on a user's machine.. So, I'd say, look in /etc if some architecture policeman forces it; otherwise treat the so-called configuration as if it were part of the executable, in .../cm3/... . The environment variables are another good place to look, because that makes it easy to experiment with multiple systems on one machine. -- hendrik From hendrik at topoi.pooq.com Mon Aug 3 23:49:02 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 3 Aug 2009 17:49:02 -0400 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> Message-ID: <20090803214902.GB25621@topoi.pooq.com> One could have the configuration file contain the locations where to find other configuration file(s). The file names in tis file could have explicit notations indicating "where the compiler is", "current directory", "User's home directory", "check the environment variable", and so forth. This would make things somewhat more flexible, It's not clear whether the added complexity would get in our way. -- hendrik From jay.krell at cornell.edu Mon Aug 3 23:53:22 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 21:53:22 +0000 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> Message-ID: > advantages: > o seems to have worked OK with cm3, cm3ide etc. until now -- > never change a running system (not very convincing ;-) This is mixing up ideas. It still works, except that now I have path() instead of an actual path in the config file. That is relocatable, but turns "." into "", and requires an assumption how to navigate from path() to the root of the install. - Jay From jay.krell at cornell.edu Mon Aug 3 23:55:08 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 21:55:08 +0000 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: <20090803214902.GB25621@topoi.pooq.com> References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> <20090803214902.GB25621@topoi.pooq.com> Message-ID: Correct. cm3 could probe for exceedingly few places, and those could then include whatever they want. Like how I moved everything to config, except the initial cm3.cfg (but then ran afoul briefly of my own INSTALL_ROOT = function of path() approach) Of course there is the tension of this being user editable or not, and therefore having to put every probe in on the theory that it isn't user editable. - Jay ---------------------------------------- > Date: Mon, 3 Aug 2009 17:49:02 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig > > One could have the configuration file contain the locations where to > find other configuration file(s). The file names in tis file could have > explicit notations indicating "where the compiler is", "current > directory", "User's home directory", "check the environment variable", > and so forth. > > This would make things somewhat more flexible, It's not clear whether > the added complexity would get in our way. > > -- hendrik From lists at darko.org Mon Aug 3 23:54:44 2009 From: lists at darko.org (Darko Volaric) Date: Mon, 3 Aug 2009 23:54:44 +0200 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> Message-ID: <13F24306-B7AF-4AEE-AC24-748B44FF3D86@darko.org> Besides advantages/disadvantages, can we consider user requirements? People who do native Mac development would need to (regularly) build for 3 targets: I386_DARWIN, AMD64_DARWIN and PPC_DARWIN which requires three different compilers, different libraries and different cfg files. In my mind the simplest solution would be to look next to the binary first as it does now, unless some new arrangement selects cfg files by the compiler target arch. Do we need to break the existing system and compatibility with existing installations and processes and if so, what is the payoff, besides simplification? On 03/08/2009, at 11:15 PM, Olaf Wagner wrote: > Quoting Darko Volaric : > >> Putting it in /etc would mean that having different active versions >> of >> compiler would e a pain, which is useful when developing, debugging >> or >> trying out new versions of the compiler and when compilers are not >> self >> hosted, which will be the case for ARM_DARWIN. >> >> What's the benefit of having it /etc other than being "standard"? > > The compiler searches in a list of locations and takes the first > one found, as is the convention when doing path searches. AFAIK > /etc is currently the last option at all. > > Perhaps we should try to gather the facts and write up a pro/cons > list for different options. > > In all previous releases cm3 used the following strategy to find > its configuration: > > "traditional" > > (1) ./cm3.cfg > (2) src/cm3.cfg > (3) ../src/cm3.cfg > (4) $M3CONFIG > (5) Pathname.Prefix( Params.Get( 0 )) > (6) for p in $PATH: try p/cm3.cfg > (7) give up... > > Because people were complaining that it wasn't possible to adhere > to common system conventions with CM3 installation packages, > I extended this strategy like this: > > "extended" > > (1)..(6) same as above > (7) /usr/local/cm3/etc/cm3.cfg > (8) /usr/cm3/etc/cm3.cfg > (9) /cm3/etc/cm3.cfg > (10) /usr/contrib/etc/cm3.cfg > (11) /usr/local/etc/cm3.cfg > (12) /usr/etc/cm3.cfg > (13) /opt/etc/cm3.cfg > (14) /sw/etc/cm3.cfg > (15) /etc/cm3.cfg > > I do insist neither on this list nor the order or the locations > themselves. On the other hand I do not see much harm in an extension > like this, allowing a certain degree of freedom for those preparing > system dependent installation packages. > > Recently Jay suggested to radically change the strategy: > > "reduced" > > (1) $M3CONFIG > (2) Pathname.Prefix( Params.Get( 0 )) > (3) give up > > We should now consider the advantages and disadvantages of each > of the proposals. The following lists are not complete; I just make > a start and others please extend as they see fit: > > "traditional" > > advantages: > o seems to have worked OK with cm3, cm3ide etc. until now -- > never change a running system (not very convincing ;-) > > disadvantages: > o system dependent non-standard values only possible via environment > settings M3CONFIG or PATH > o not simple and easy to remember > > "extended" > > advantages: > o just an extension to existing strategy > o allows for several conventional standard locations for config files > > disadvantages: > o not simple and easy to remember, may be confusing > > "reduced" > > advantages: > o simple and easy to remember > > disadvantages: > o system dependent non-standard values only possible via environment > setting of M3CONFIG > o may be incompatible with certain use cases of cm3 and cm3ide (to > be investigated) > > There are also the general arguments saying that > > "no (user) configuration of cm3 is needed at all" (really?) > > and > > "that may be said of a lot of tools and services whose config files > live in /etc/ and may just be adapted by root" > > "we should heed the standards and conventions of existing systems > in order to be used" > > That's of course just a start, I'm sure I have forgotten many good > arguments. Let's try to keep to the facts as much as possible though. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From jay.krell at cornell.edu Mon Aug 3 23:56:50 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 21:56:50 +0000 Subject: [M3devel] assembly goes to C compiler? In-Reply-To: <20090803163625.qm007v2pfog8s8sg@mail.elegosoft.com> References: <20090803132158.walcuy2s00wck04g@mail.elegosoft.com> <20090803131048.GB24864@topoi.pooq.com> <4AD30F1F-90E6-48F8-B93C-6889E8D2BAF4@cs.purdue.edu> <20090803163625.qm007v2pfog8s8sg@mail.elegosoft.com> Message-ID: asssemble is used for cm3cg output C is used for user-written assembly - Jay ---------------------------------------- > Date: Mon, 3 Aug 2009 16:36:25 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] assembly goes to C compiler? > > Quoting Tony Hosking : > >> Using the C compiler allows the assembly to have preprocessor directives. > > So you think it's a feature. Why do we have the assemble methods > in the config file then? Or are they just legacy? > > %---------------------------------------------------------------- > assembler --- > % "assemble" is called to assemble .s or .asm files. Note that this function > % is only called if your program or library explicitly includes > assembly source > % code, the system distributed by Critical Mass does not. > > proc assemble(source, object) is > if defined("configure_assembler") > configure_assembler() > end > return try_exec("@" & SYSTEM_ASM, source, "-o", object) > end > > Probably a remnant of DEC SRC M3? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From lists at darko.org Mon Aug 3 23:59:43 2009 From: lists at darko.org (Darko Volaric) Date: Mon, 3 Aug 2009 23:59:43 +0200 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: <20090803212936.GA25621@topoi.pooq.com> References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803212936.GA25621@topoi.pooq.com> Message-ID: The cfg files contain library lists which I change all the time. I understand there is a lot of build scripting in there too, but I ignore that and assume it's correct and see it only as a user config file. Maybe the "executable" bits need to moved elsewhere? Environment variables are pretty loathsome in my opinion. This is a bit of creeping unixism, but not everyone likes unix. On 03/08/2009, at 11:29 PM, hendrik at topoi.pooq.com wrote: > On Mon, Aug 03, 2009 at 08:59:26PM +0200, Darko Volaric wrote: >> Putting it in /etc would mean that having different active versions >> of >> compiler would e a pain, which is useful when developing, debugging >> or >> trying out new versions of the compiler and when compilers are not >> self hosted, which will be the case for ARM_DARWIN. >> >> What's the benefit of having it /etc other than being "standard"? > > Things in /etc/ are things that a system administrator might want to > tweak. At least that was the idea originally. These options we're > talking about seem somewhat different, in that they are tightly bound > with the software itself. I say they are more like executable code > than > like configuration files. If a Debian user were to install cm3.deb, > they had damn well point to the place the package put the compiler and > friends. I don't see the being usefully modified at all on a user's > machine.. > > So, I'd say, look in /etc if some architecture policeman forces it; > otherwise treat the so-called configuration as if it were part of the > executable, in .../cm3/... . > > The environment variables are another good place to look, because that > makes it easy to experiment with multiple systems on one machine. > > -- hendrik From jay.krell at cornell.edu Tue Aug 4 00:00:52 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 22:00:52 +0000 Subject: [M3devel] some cvs errors? In-Reply-To: <20090803131445.d5u1i1vaf484kg4s@mail.elegosoft.com> References: <20090803131445.d5u1i1vaf484kg4s@mail.elegosoft.com> Message-ID: One error, the second one, was maybe local, not on the server. I saw it again later while running make-dist.sh, it tries to update itself. Not clear why it occured here, maybe I had one running and the use of $Id$ caused an attempted and failed write. Or maybe the error was on the server. With CVS, can't be sure of much imho. The other seems ok. +2 for replacing cvs with something better.. after we invent more time... - Jay ---------------------------------------- > Date: Mon, 3 Aug 2009 13:14:45 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; m3-support at elego.de > Subject: Re: some cvs errors? > > Quoting Jay K : > >> "/tmp/cvsUsaGYO" 61 lines, 1835 characters >> /usr/cvs/cm3/m3-sys/m3cc/src/m3makefile,v <-- src/m3makefile >> new revision: 1.111.2.4; previous revision: 1.111.2.3 >> Cannot Open data file (cwd: /usr/local/tinderbox/bonsai; >> data/temp.8776): Bad fi >> >> ? PKGS >> /usr/cvs/cm3/scripts/find-packages.sh,v <-- find-packages.sh >> new revision: 1.9.2.1; previous revision: 1.9 >> /usr/cvs/cm3/scripts/find-src-dirs.sh,v <-- find-src-dirs.sh >> new revision: 1.2.2.1; previous revision: 1.2 >> /usr/cvs/cm3/scripts/list-pkg-dirs.sh,v <-- list-pkg-dirs.sh >> new revision: 1.2.2.1; previous revision: 1.2 >> /usr/cvs/cm3/scripts/make-dist.sh,v <-- make-dist.sh >> new revision: 1.26.2.5; previous revision: 1.26.2.4 >> cvs [commit aborted]: cannot rename file .new.make-dist.sh to >> make-dist.sh: Permission denied >> >> >> ? >> >> I think the commits made it. > > What were these? Do we need to investigate them? > Or is everything OK now? > > Still trying to catch up with all my mails, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Tue Aug 4 00:05:27 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 22:05:27 +0000 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803212936.GA25621@topoi.pooq.com> Message-ID: I have to admit there is a mix of "clearly almost always correct, maybe really always" and "perhaps user editable code" in there. I have hoped for no user editing but can't claim I got there, due to the library issues as you say, and maybe even -gstabs vs. -gstabs+ vs. -g, etc. -- heck maybe user wants slightly smaller binaries and doesn't mind slight loss of debugging, and doesn't want to strip afterward. I did try to find "fairly canonical" places for libraries, such as wherever the platform package system installs things, but ultimately you can build yourself and get /usr/local instead of /usr/pkg, etc. A possible solution is for the cm3.cfg file itself to probe, "at certain well defined points" for "certain well defined data", as well as leaving things not readonly. For example at the very end it might probe for $HOME/etc/cm3.cfg and /etc/cm3.cfg and include them if they exist, or just the first. I also don't want to get into the business of merging these files on user machines, either automatically or making people do it. I guess we are in the second situation now however. A partial approach is to move more of the code into cm3, perhaps merely as Quake snippets, but that is perhaps overkill. - Jay ---------------------------------------- > From: lists at darko.org > To: hendrik at topoi.pooq.com > Date: Mon, 3 Aug 2009 23:59:43 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig > > The cfg files contain library lists which I change all the time. I > understand there is a lot of build scripting in there too, but I > ignore that and assume it's correct and see it only as a user config > file. Maybe the "executable" bits need to moved elsewhere? > > Environment variables are pretty loathsome in my opinion. This is a > bit of creeping unixism, but not everyone likes unix. > > > On 03/08/2009, at 11:29 PM, hendrik at topoi.pooq.com wrote: > >> On Mon, Aug 03, 2009 at 08:59:26PM +0200, Darko Volaric wrote: >>> Putting it in /etc would mean that having different active versions >>> of >>> compiler would e a pain, which is useful when developing, debugging >>> or >>> trying out new versions of the compiler and when compilers are not >>> self hosted, which will be the case for ARM_DARWIN. >>> >>> What's the benefit of having it /etc other than being "standard"? >> >> Things in /etc/ are things that a system administrator might want to >> tweak. At least that was the idea originally. These options we're >> talking about seem somewhat different, in that they are tightly bound >> with the software itself. I say they are more like executable code >> than >> like configuration files. If a Debian user were to install cm3.deb, >> they had damn well point to the place the package put the compiler and >> friends. I don't see the being usefully modified at all on a user's >> machine.. >> >> So, I'd say, look in /etc if some architecture policeman forces it; >> otherwise treat the so-called configuration as if it were part of the >> executable, in .../cm3/... . >> >> The environment variables are another good place to look, because that >> makes it easy to experiment with multiple systems on one machine. >> >> -- hendrik > From jay.krell at cornell.edu Tue Aug 4 00:21:36 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 22:21:36 +0000 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803212936.GA25621@topoi.pooq.com> Message-ID: I'm on the fence wrt environment variables. It is fairly rare for users to run executables by full path. $PATH search and changing $PATH seems to be the way. But what paths code tends to use, not sure. It might also be blurry as "code" that runs stuff is initially users coding up their command lines in sh and then gradually formalizing things, and "formal" might or might not mean using full paths. On Windows, there is no /usr/include. You either set $INCLUDE and $LIB and/or you give paths to the compiler/linker on the command line. Or a mix. Environment variables are The way to set something and have it be inherited by child processes, but not inherited by the rest of the system. They lead to a process tree that works in one setup/configured temporary way. But don't lead to an overall system that works a particular way, unless you set them somewhere with enough impact. There is a larger problem in software wrt how to handle "settings". There are environment variables. There are lots of text files in /etc. There is the Windows registry. They all have pluses and minuses. Really, the Windows registry does have pluses. The problem is related to just how many settings there are. The more you need, the more general a solution is needed, and the less satisfactory it is bound to be. It is far more complicated than most people realize. "settings" are contextual. They can be per user, per machine, per user+machine combination, and more. I'm sure people will claim "but such and such system solves it all", and maybe, but unlikely imho. I mean, heck, per user but I have multiple machines. How do I instantly change all my machines to use an orange desktop? Oh, well, there are "roaming profiles" on Windows and networked $HOME directories on Windows. Maybe. But I've basically never used them, so maybe they do solve it? There are also settings that shouldn't be settings. My terminal emulation usually doesn't quite work. (Amzazing how much does not work..). I find myself messing with $TERM but I should never have to. And still it doesn't work so maybe I don't have to, the problem is elsewhere.. - Jay ---------------------------------------- > From: lists at darko.org > To: hendrik at topoi.pooq.com > Date: Mon, 3 Aug 2009 23:59:43 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig > > The cfg files contain library lists which I change all the time. I > understand there is a lot of build scripting in there too, but I > ignore that and assume it's correct and see it only as a user config > file. Maybe the "executable" bits need to moved elsewhere? > > Environment variables are pretty loathsome in my opinion. This is a > bit of creeping unixism, but not everyone likes unix. > > > On 03/08/2009, at 11:29 PM, hendrik at topoi.pooq.com wrote: > >> On Mon, Aug 03, 2009 at 08:59:26PM +0200, Darko Volaric wrote: >>> Putting it in /etc would mean that having different active versions >>> of >>> compiler would e a pain, which is useful when developing, debugging >>> or >>> trying out new versions of the compiler and when compilers are not >>> self hosted, which will be the case for ARM_DARWIN. >>> >>> What's the benefit of having it /etc other than being "standard"? >> >> Things in /etc/ are things that a system administrator might want to >> tweak. At least that was the idea originally. These options we're >> talking about seem somewhat different, in that they are tightly bound >> with the software itself. I say they are more like executable code >> than >> like configuration files. If a Debian user were to install cm3.deb, >> they had damn well point to the place the package put the compiler and >> friends. I don't see the being usefully modified at all on a user's >> machine.. >> >> So, I'd say, look in /etc if some architecture policeman forces it; >> otherwise treat the so-called configuration as if it were part of the >> executable, in .../cm3/... . >> >> The environment variables are another good place to look, because that >> makes it easy to experiment with multiple systems on one machine. >> >> -- hendrik > From jay.krell at cornell.edu Tue Aug 4 00:23:56 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 22:23:56 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <4A76FEED.1E75.00D7.1@scires.com> References: <20090803093135.3F59DCC81B@birch.elegosoft.com> <4A76CADA.1E75.00D7.1@scires.com> <4A76FEED.1E75.00D7.1@scires.com> Message-ID: I failed to figure how to move anything at all to RC2 (perhaps that is by-design, Olaf escalating and using more and more arcane features of cvs to stay ahead of me), but I moved it to the release branch, which should get it at least into whatever if anything follows RC2. The fix seems fragile though. Converting to a full path would probably be better. (Full paths are still contextual, but most people/code seem ok ignoring that. Could be net used or chroot..) - Jay ________________________________ > Date: Mon, 3 Aug 2009 15:17:30 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > > > > > Jay: > > > > Your change to MxConfig.m3 seems to work fine for cm3ide, provided that I replace HOST by "NT386" in my cm3.cfg is as follows: > > > > INSTALL_ROOT = path() & "/.." > include (path() & "/config/NT386") > > > > Thank you! > > > > Can we get your revised MxConfig.m3 put into the RC2 branch? > > > > Regards, > > Randy > >>>> "Randy Coleburn" 8/3/2009 11:35 AM>>> > > Jay: > > I agree that running cm3 from "bin" folder is not going to be productive; however, other programs (such as cm3ide) also use the quake stuff and they don't have this limitation. I think your change is a good one. I'll run some tests and see how cm3ide fares. Thanks. > > --Randy > >>>> Jay Krell 8/3/2009 11:31 AM>>> > CVSROOT:/usr/cvs > Changes by:jkrell at birch.09/08/03 11:31:35 > > Modified files: > cm3/m3-sys/m3quake/src/: MxConfig.m3 > > Log message: > use "." instead of empty string for path() when current working > directory is the actual directory of cm3; not sure what good > running cm3 here is, and we probe way too many places.. > From jay.krell at cornell.edu Tue Aug 4 00:25:25 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 22:25:25 +0000 Subject: [M3devel] /etc/cm3.cfg (was: HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig) In-Reply-To: <1249334501.28197.750.camel@faramir.m3w.org> References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> <1249334501.28197.750.camel@faramir.m3w.org> Message-ID: If you put your cm3.cfg in /etc, you will have to edit it. INSTALL_ROOT = path() & "/.." won't be correct, and then everything computed from it. - Jay ---------------------------------------- > From: dragisha at m3w.org > To: wagner at elegosoft.com > Date: Mon, 3 Aug 2009 23:21:41 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] /etc/cm3.cfg (was: HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig) > > On Mon, 2009-08-03 at 23:15 +0200, Olaf Wagner wrote: >> The compiler searches in a list of locations and takes the first >> one found, as is the convention when doing path searches. AFAIK >> /etc is currently the last option at all. > > Tried this today, and what happened was - cm3 set PKG_INSTALL to "/" and > I was unable to build anything until I moved cm3.cfg back to where cm3 > binary is. > -- > Dragi?a Duri? > From jay.krell at cornell.edu Tue Aug 4 00:25:42 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 22:25:42 +0000 Subject: [M3devel] /etc/cm3.cfg (was: HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig) In-Reply-To: <1249334501.28197.750.camel@faramir.m3w.org> References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> <1249334501.28197.750.camel@faramir.m3w.org> Message-ID: (unless cm3 is in /etc and / is your install root) ---------------------------------------- > From: jay.krell at cornell.edu > To: dragisha at m3w.org; wagner at elegosoft.com > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] /etc/cm3.cfg (was: HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig) > Date: Mon, 3 Aug 2009 22:25:25 +0000 > > > If you put your cm3.cfg in /etc, you will have to edit it. > INSTALL_ROOT = path() & "/.." won't be correct, and then everything computed from it. > > - Jay > > > ---------------------------------------- >> From: dragisha at m3w.org >> To: wagner at elegosoft.com >> Date: Mon, 3 Aug 2009 23:21:41 +0200 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] /etc/cm3.cfg (was: HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig) >> >> On Mon, 2009-08-03 at 23:15 +0200, Olaf Wagner wrote: >>> The compiler searches in a list of locations and takes the first >>> one found, as is the convention when doing path searches. AFAIK >>> /etc is currently the last option at all. >> >> Tried this today, and what happened was - cm3 set PKG_INSTALL to "/" and >> I was unable to build anything until I moved cm3.cfg back to where cm3 >> binary is. >> -- >> Dragi?a Duri? >> From jay.krell at cornell.edu Tue Aug 4 00:29:48 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 22:29:48 +0000 Subject: [M3devel] the SOLgnu alignment problem finally understood In-Reply-To: <20090803132628.krcbd41hy8ggs8s8@mail.elegosoft.com> References: <20090803132628.krcbd41hy8ggs8s8@mail.elegosoft.com> Message-ID: cm3cg's lack of support for -g or -gdwarf etc. shouldn't mean gcc/gas doesn't support -g. Yes, -g is rare in the config files. This was perhaps an oversight. This seems like a gcc or gas bug, but oh well. My gcc is old 3.x. Note that on some systems -gstabs isn't supported, like PA64_HPUX I think. But using cm3cg -g tends to "internal compiler error" and such. A problem for the potential future, things are adequate for now. - Jay ---------------------------------------- > Date: Mon, 3 Aug 2009 13:26:28 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: the SOLgnu alignment problem finally understood > > We had similar problems before with -g. CM3 never supported dwarf > debugging format, just stabs. I think we changed all -g occurences > in the config files to -gstabs some years ago. > > It sounds like a small fix in the config files after all, correct? > At least for this RC? > > Olaf > > Quoting Jay K : > >> >> Here finally is a small example of the SOLgnu problem I've been >> looking at it. >> >> >> It is specific to using /usr/sfw/bin/gcc -g to asssemble. >> No problem without -g, no problem with /usr/bin/cc, no problem with >> whatever I built in /usr/local/bin/gcc, no problem if you assemble >> with anything else and then link with /usr/sfw/bin/gcc -g. >> >> >> -bash-3.00$ cat 4.c asm.s >> >> 4.c >> void Asm(void); >> #include >> >> int main() >> { >> Asm(); >> printf("\n"); >> return 0; >> } >> >> asm.s >> >> .section ".text",#alloc,#execinstr >> .align 4 >> .global Asm >> .type Asm,#function >> Asm: >> retl >> nop >> .size Asm, (.-Asm) >> >> >> Not all possibilities shown here: >> >> >> -bash-3.00$ /usr/local/bin/gcc -g asm.s 4.c >> ok >> >> >> -bash-3.00$ /usr/sfw/bin/gcc -g asm.s 4.c >> ld: fatal: relocation error: R_SPARC_32: file /var/tmp//ccICgvny.o: >> symbol : offset 0xfeed139e is non-aligned >> ld: fatal: relocation error: R_SPARC_32: file /var/tmp//ccICgvny.o: >> symbol : offset 0xfeed14c2 is non-aligned >> ld: fatal: relocation error: R_SPARC_32: file /var/tmp//ccICgvny.o: >> symbol : offset 0xfeed15f6 is non-aligned >> collect2: ld returned 1 exit status >> >> >> -bash-3.00$ /usr/bin/cc -g asm.s 4.c >> asm.s: >> 4.c: >> ok >> >> -bash-3.00$ /usr/bin/cc asm.s 4.c >> asm.s: >> 4.c: >> ok >> >> >> -bash-3.00$ /usr/sfw/bin/gcc asm.s 4.c >> ok >> >> >> -bash-3.00$ /usr/local/bin/gcc asm.s 4.c >> ok >> >> >> -bash-3.00$ /usr/sfw/bin/gcc -g -c asm.s >> ok but haven't linked yet, input to later steps >> >> >> -bash-3.00$ /usr/bin/cc asm.o 4.c >> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >> ff10148e is non-aligned >> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >> ff1014ca is non-aligned >> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >> ff1015be is non-aligned >> >> >> -bash-3.00$ /usr/local/bin/gcc asm.o 4.c >> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >> feee1213 is non-aligned >> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >> feee122a is non-aligned >> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >> feee122e is non-aligned >> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >> feee1232 is non-aligned >> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >> feee126e is non-aligned >> collect2: ld returned 1 exit status >> >> >> >> -bash-3.00$ /usr/local/bin/gcc -g -c asm.s >> ok, try linking with others >> >> >> -bash-3.00$ /usr/bin/cc asm.o 4.c >> ok >> >> >> >> -bash-3.00$ /usr/sfw/bin/gcc asm.o 4.c >> ok >> >> >> Actually even -gstabs or -gstabs+ instead of -g make it work. >> -g resolves to -gdwarf2. >> >> >> - Jay > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Tue Aug 4 00:31:04 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 22:31:04 +0000 Subject: [M3devel] the SOLgnu alignment problem finally understood In-Reply-To: <20090803132628.krcbd41hy8ggs8s8@mail.elegosoft.com> References: <20090803132628.krcbd41hy8ggs8s8@mail.elegosoft.com> Message-ID: ps: building RC2 with my /usr/local/bin/gcc is also viable That is how things were working. It is confused to use /usr/ccs/bin/as, and the -g doesn't get passed down to it I think it was. I might not get anything else in for ~two days.. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > CC: m3devel at elegosoft.com > Subject: RE: the SOLgnu alignment problem finally understood > Date: Mon, 3 Aug 2009 22:29:48 +0000 > > > cm3cg's lack of support for -g or -gdwarf etc. shouldn't mean gcc/gas doesn't support -g. > Yes, -g is rare in the config files. This was perhaps an oversight. > This seems like a gcc or gas bug, but oh well. > My gcc is old 3.x. > Note that on some systems -gstabs isn't supported, like PA64_HPUX I think. > But using cm3cg -g tends to "internal compiler error" and such. > A problem for the potential future, things are adequate for now. > > - Jay > > > ---------------------------------------- >> Date: Mon, 3 Aug 2009 13:26:28 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: the SOLgnu alignment problem finally understood >> >> We had similar problems before with -g. CM3 never supported dwarf >> debugging format, just stabs. I think we changed all -g occurences >> in the config files to -gstabs some years ago. >> >> It sounds like a small fix in the config files after all, correct? >> At least for this RC? >> >> Olaf >> >> Quoting Jay K : >> >>> >>> Here finally is a small example of the SOLgnu problem I've been >>> looking at it. >>> >>> >>> It is specific to using /usr/sfw/bin/gcc -g to asssemble. >>> No problem without -g, no problem with /usr/bin/cc, no problem with >>> whatever I built in /usr/local/bin/gcc, no problem if you assemble >>> with anything else and then link with /usr/sfw/bin/gcc -g. >>> >>> >>> -bash-3.00$ cat 4.c asm.s >>> >>> 4.c >>> void Asm(void); >>> #include >>> >>> int main() >>> { >>> Asm(); >>> printf("\n"); >>> return 0; >>> } >>> >>> asm.s >>> >>> .section ".text",#alloc,#execinstr >>> .align 4 >>> .global Asm >>> .type Asm,#function >>> Asm: >>> retl >>> nop >>> .size Asm, (.-Asm) >>> >>> >>> Not all possibilities shown here: >>> >>> >>> -bash-3.00$ /usr/local/bin/gcc -g asm.s 4.c >>> ok >>> >>> >>> -bash-3.00$ /usr/sfw/bin/gcc -g asm.s 4.c >>> ld: fatal: relocation error: R_SPARC_32: file /var/tmp//ccICgvny.o: >>> symbol : offset 0xfeed139e is non-aligned >>> ld: fatal: relocation error: R_SPARC_32: file /var/tmp//ccICgvny.o: >>> symbol : offset 0xfeed14c2 is non-aligned >>> ld: fatal: relocation error: R_SPARC_32: file /var/tmp//ccICgvny.o: >>> symbol : offset 0xfeed15f6 is non-aligned >>> collect2: ld returned 1 exit status >>> >>> >>> -bash-3.00$ /usr/bin/cc -g asm.s 4.c >>> asm.s: >>> 4.c: >>> ok >>> >>> -bash-3.00$ /usr/bin/cc asm.s 4.c >>> asm.s: >>> 4.c: >>> ok >>> >>> >>> -bash-3.00$ /usr/sfw/bin/gcc asm.s 4.c >>> ok >>> >>> >>> -bash-3.00$ /usr/local/bin/gcc asm.s 4.c >>> ok >>> >>> >>> -bash-3.00$ /usr/sfw/bin/gcc -g -c asm.s >>> ok but haven't linked yet, input to later steps >>> >>> >>> -bash-3.00$ /usr/bin/cc asm.o 4.c >>> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >>> ff10148e is non-aligned >>> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >>> ff1014ca is non-aligned >>> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >>> ff1015be is non-aligned >>> >>> >>> -bash-3.00$ /usr/local/bin/gcc asm.o 4.c >>> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >>> feee1213 is non-aligned >>> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >>> feee122a is non-aligned >>> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >>> feee122e is non-aligned >>> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >>> feee1232 is non-aligned >>> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >>> feee126e is non-aligned >>> collect2: ld returned 1 exit status >>> >>> >>> >>> -bash-3.00$ /usr/local/bin/gcc -g -c asm.s >>> ok, try linking with others >>> >>> >>> -bash-3.00$ /usr/bin/cc asm.o 4.c >>> ok >>> >>> >>> >>> -bash-3.00$ /usr/sfw/bin/gcc asm.o 4.c >>> ok >>> >>> >>> Actually even -gstabs or -gstabs+ instead of -g make it work. >>> -g resolves to -gdwarf2. >>> >>> >>> - Jay >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> From jay.krell at cornell.edu Tue Aug 4 00:33:40 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 22:33:40 +0000 Subject: [M3devel] the SOLgnu alignment problem finally understood In-Reply-To: References: <20090803132628.krcbd41hy8ggs8s8@mail.elegosoft.com> Message-ID: < confused > configured oops ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > Date: Mon, 3 Aug 2009 22:31:04 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] the SOLgnu alignment problem finally understood > > > ps: building RC2 with my /usr/local/bin/gcc is also viable > That is how things were working. > It is confused to use /usr/ccs/bin/as, and the -g doesn't get passed down to it I think it was. > I might not get anything else in for ~two days.. > > > - Jay > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com >> CC: m3devel at elegosoft.com >> Subject: RE: the SOLgnu alignment problem finally understood >> Date: Mon, 3 Aug 2009 22:29:48 +0000 >> >> >> cm3cg's lack of support for -g or -gdwarf etc. shouldn't mean gcc/gas doesn't support -g. >> Yes, -g is rare in the config files. This was perhaps an oversight. >> This seems like a gcc or gas bug, but oh well. >> My gcc is old 3.x. >> Note that on some systems -gstabs isn't supported, like PA64_HPUX I think. >> But using cm3cg -g tends to "internal compiler error" and such. >> A problem for the potential future, things are adequate for now. >> >> - Jay >> >> >> ---------------------------------------- >>> Date: Mon, 3 Aug 2009 13:26:28 +0200 >>> From: wagner at elegosoft.com >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com >>> Subject: Re: the SOLgnu alignment problem finally understood >>> >>> We had similar problems before with -g. CM3 never supported dwarf >>> debugging format, just stabs. I think we changed all -g occurences >>> in the config files to -gstabs some years ago. >>> >>> It sounds like a small fix in the config files after all, correct? >>> At least for this RC? >>> >>> Olaf >>> >>> Quoting Jay K : >>> >>>> >>>> Here finally is a small example of the SOLgnu problem I've been >>>> looking at it. >>>> >>>> >>>> It is specific to using /usr/sfw/bin/gcc -g to asssemble. >>>> No problem without -g, no problem with /usr/bin/cc, no problem with >>>> whatever I built in /usr/local/bin/gcc, no problem if you assemble >>>> with anything else and then link with /usr/sfw/bin/gcc -g. >>>> >>>> >>>> -bash-3.00$ cat 4.c asm.s >>>> >>>> 4.c >>>> void Asm(void); >>>> #include >>>> >>>> int main() >>>> { >>>> Asm(); >>>> printf("\n"); >>>> return 0; >>>> } >>>> >>>> asm.s >>>> >>>> .section ".text",#alloc,#execinstr >>>> .align 4 >>>> .global Asm >>>> .type Asm,#function >>>> Asm: >>>> retl >>>> nop >>>> .size Asm, (.-Asm) >>>> >>>> >>>> Not all possibilities shown here: >>>> >>>> >>>> -bash-3.00$ /usr/local/bin/gcc -g asm.s 4.c >>>> ok >>>> >>>> >>>> -bash-3.00$ /usr/sfw/bin/gcc -g asm.s 4.c >>>> ld: fatal: relocation error: R_SPARC_32: file /var/tmp//ccICgvny.o: >>>> symbol : offset 0xfeed139e is non-aligned >>>> ld: fatal: relocation error: R_SPARC_32: file /var/tmp//ccICgvny.o: >>>> symbol : offset 0xfeed14c2 is non-aligned >>>> ld: fatal: relocation error: R_SPARC_32: file /var/tmp//ccICgvny.o: >>>> symbol : offset 0xfeed15f6 is non-aligned >>>> collect2: ld returned 1 exit status >>>> >>>> >>>> -bash-3.00$ /usr/bin/cc -g asm.s 4.c >>>> asm.s: >>>> 4.c: >>>> ok >>>> >>>> -bash-3.00$ /usr/bin/cc asm.s 4.c >>>> asm.s: >>>> 4.c: >>>> ok >>>> >>>> >>>> -bash-3.00$ /usr/sfw/bin/gcc asm.s 4.c >>>> ok >>>> >>>> >>>> -bash-3.00$ /usr/local/bin/gcc asm.s 4.c >>>> ok >>>> >>>> >>>> -bash-3.00$ /usr/sfw/bin/gcc -g -c asm.s >>>> ok but haven't linked yet, input to later steps >>>> >>>> >>>> -bash-3.00$ /usr/bin/cc asm.o 4.c >>>> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >>>> ff10148e is non-aligned >>>> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >>>> ff1014ca is non-aligned >>>> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >>>> ff1015be is non-aligned >>>> >>>> >>>> -bash-3.00$ /usr/local/bin/gcc asm.o 4.c >>>> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >>>> feee1213 is non-aligned >>>> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >>>> feee122a is non-aligned >>>> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >>>> feee122e is non-aligned >>>> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >>>> feee1232 is non-aligned >>>> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >>>> feee126e is non-aligned >>>> collect2: ld returned 1 exit status >>>> >>>> >>>> >>>> -bash-3.00$ /usr/local/bin/gcc -g -c asm.s >>>> ok, try linking with others >>>> >>>> >>>> -bash-3.00$ /usr/bin/cc asm.o 4.c >>>> ok >>>> >>>> >>>> >>>> -bash-3.00$ /usr/sfw/bin/gcc asm.o 4.c >>>> ok >>>> >>>> >>>> Actually even -gstabs or -gstabs+ instead of -g make it work. >>>> -g resolves to -gdwarf2. >>>> >>>> >>>> - Jay >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >>> From hendrik at topoi.pooq.com Tue Aug 4 00:37:10 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 3 Aug 2009 18:37:10 -0400 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803212936.GA25621@topoi.pooq.com> Message-ID: <20090803223710.GE25621@topoi.pooq.com> On Mon, Aug 03, 2009 at 10:21:36PM +0000, Jay K wrote: > > I'm on the fence wrt environment variables. > > > It is fairly rare for users to run executables by full path. > $PATH search and changing $PATH seems to be the way. > > > But what paths code tends to use, not sure. > It might also be blurry as "code" that runs stuff is initially users coding up their command lines in sh and then gradually formalizing things, and "formal" might or might not mean using full paths. > > > On Windows, there is no /usr/include. > You either set $INCLUDE and $LIB and/or you give paths to the > compiler/linker on the command line. Or a mix. > > > Environment variables are The way to set something and have it be > inherited by child processes, but not inherited by the rest of the > system. > > > They lead to a process tree that works in one setup/configured temporary way. > But don't lead to an overall system that works a particular way, > unless you set them somewhere with enough impact. > That is exactly the mad scientist whill want when he's tinkering with deviant Modula 3 compilers. But it's not what the average user will want. And it's not what the mad compiler tinkerer will want when he's just compiling ordinary programs. So let an environment variable override whatever else would be used to find the configuration file. And leave it undefined for the average user. > > There is a larger problem in software wrt how to handle "settings". > There are environment variables. There are lots of text files in > /etc. There is the Windows registry. > They all have pluses and minuses. Really, the Windows registry does > have pluses. > The problem is related to just how many settings there are. > The more you need, the more general a solution is needed, and the less > satisfactory it is bound to be. > > > It is far more complicated than most people realize. > "settings" are contextual. They can be per user, per machine, per > user+machine combination, and more. > I'm sure people will claim "but such and such system solves it all", > and maybe, but unlikely imho. > I mean, heck, per user but I have multiple machines. > How do I instantly change all my machines to use an orange desktop? > Oh, well, there are "roaming profiles" on Windows and networked > $HOME directories on Windows. Maybe. But I've basically never used > them, so maybe they do solve it? Let the user provide a program that, when run, will write the configuration file to stdout? Let the user provide a web page with an applet that .... etc. etc. > > There are also settings that shouldn't be settings. > My terminal emulation usually doesn't quite work. (Amzazing how much > does not work..). I find myself messing with $TERM but I should never > have to. And still it doesn't work so maybe I don't have to, the > problem is elsewhere.. My terminal won't come up at all unless I first start iceweasel or gnucash or Pan (maybe some others). But messing with $TERM won't fix this. The problem is elsewhere. :-) > > > > - Jay From jay.krell at cornell.edu Tue Aug 4 01:42:12 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 23:42:12 +0000 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: <20090803223710.GE25621@topoi.pooq.com> References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803212936.GA25621@topoi.pooq.com> <20090803223710.GE25621@topoi.pooq.com> Message-ID: > That is exactly the mad scientist whill want when he's tinkering with > deviant Modula 3 compilers. But it's not what the average user will > want. And it's not what the mad compiler tinkerer will want when he's > just compiling ordinary programs. So let an environment variable > override whatever else would be used to find the configuration file. > And leave it undefined for the average user. I have been a proponent of what you say. And I have tried to achieve it. However it is not clear if I got there. The system-wide library paths, one example, are what the "(mad) Linux tinkerer" might alter, once and be done, not merely the "compiler tinkerer". There may be too many such people. Even for the mad tinkerer to have his own system-wide gcc might be common? Again, more of a "once and be done" mode, not often changing? The config files ultimately don't even that much. The previous authors did factor them fairly well. Just not /quite/ enough to my taste. :) I think primarly it was due to the times. There was more variety back then perhaps, and fewer cases of the same compiler (gcc) being on multiple systems or the same kernels being on multiple processors. For example, Solaris.common would not have made sense, there was just 32bit SPARC. For example, Linux.common would not have made sense, there was just x86. FreeBSD/OpenBSD/NetBSD all fairly young too. Ultimately I gather..and I haven't gotten here yet, but ultimately I think the tinkering escapes to chroot, whereupon from our point of view it ceases being tinkering. The contents of the files might change but the the names are restored to normal. :) As well though, the mad tinkerer is root? And is ok editing text files outside of /etc? - Jay From jay.krell at cornell.edu Tue Aug 4 02:18:06 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 4 Aug 2009 00:18:06 +0000 Subject: [M3devel] FW: HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: <20090803223710.GE25621@topoi.pooq.com> References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803212936.GA25621@topoi.pooq.com> <20090803223710.GE25621@topoi.pooq.com> Message-ID: [was truncated] ---------------------------------------- > From: jay.krell at cornell.edu > To: hendrik at topoi.pooq.com; m3devel at elegosoft.com > Subject: RE: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig > Date: Mon, 3 Aug 2009 23:42:12 +0000 > > >> That is exactly the mad scientist whill want when he's tinkering with >> deviant Modula 3 compilers. But it's not what the average user will >> want. And it's not what the mad compiler tinkerer will want when he's >> just compiling ordinary programs. So let an environment variable >> override whatever else would be used to find the configuration file. >> And leave it undefined for the average user. > > > I have been a proponent of what you say. > And I have tried to achieve it. > > > However it is not clear if I got there. > > > The system-wide library paths, one example, > are what the "(mad) Linux tinkerer" might > alter, once and be done, not merely the > "compiler tinkerer". There may be too many such people. > > > Even for the mad tinkerer to have his own > system-wide gcc might be common? > Again, more of a "once and be done" mode, > not often changing? > > > The config files ultimately don't even that much. > The previous authors did factor them fairly well. > Just not /quite/ enough to my taste. :) > I think primarly it was due to the times. > There was more variety back then perhaps, and fewer > cases of the same compiler (gcc) being on multiple > systems or the same kernels being on multiple processors. > > > For example, Solaris.common would not have made sense, there was just 32bit SPARC. > For example, Linux.common would not have made sense, there was just x86. > FreeBSD/OpenBSD/NetBSD all fairly young too. > > > Ultimately I gather..and I haven't gotten here yet, > but ultimately I think the tinkering escapes to chroot, > whereupon from our point of view it ceases being tinkering. > The contents of the files might change but the the names > are restored to normal. :) > > > As well though, the mad tinkerer is root? > And is ok editing text files outside of /etc? > > > > - Jay From hendrik at topoi.pooq.com Tue Aug 4 02:27:54 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 3 Aug 2009 20:27:54 -0400 Subject: [M3devel] testing RC2. Message-ID: <20090804002754.GF25621@topoi.pooq.com> Now that I've updated the wikipedia entry, it's easier to find the RC2 downloads page. How can I update the other places that are easy to find on the google? Specifically, the Modula 3 resource page, www.modula3.org/ Modula-3 Frequently Asked Questions (FAQ), www.faqs.org/faqs/Modula-3-faq/ I'll soon be trying another installation fromscratch, using RC2, and I'll let you know how it went. -- hendrik From hendrik at topoi.pooq.com Tue Aug 4 02:38:27 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 3 Aug 2009 20:38:27 -0400 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: References: <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803212936.GA25621@topoi.pooq.com> <20090803223710.GE25621@topoi.pooq.com> Message-ID: <20090804003826.GG25621@topoi.pooq.com> On Mon, Aug 03, 2009 at 11:42:12PM +0000, Jay K wrote: > > > That is exactly the mad scientist whill want when he's tinkering with > > deviant Modula 3 compilers. But it's not what the average user will > > want. And it's not what the mad compiler tinkerer will want when he's > > just compiling ordinary programs. So let an environment variable > > override whatever else would be used to find the configuration file. > > And leave it undefined for the average user. > > > I have been a proponent of what you say. > And I have tried to achieve it. > > > However it is not clear if I got there. > > > The system-wide library paths, one example, > are what the "(mad) Linux tinkerer" might > alter, once and be done, not merely the > "compiler tinkerer". There may be too many such people. I was thinking of the mad scientist who writes his own variations into Modula 3, and wants to use his version without it getting mixed up with the standard one available on his system. He'd want his own m3 configuration file for sure. As for the OS's other paths, on Linux the OS provides those, and lets them be overridden by the user as environment variables. He'd just better make sure they point to the ones he needs. That's his job, not ours. I'm not advocating replacing the OS. That's someone else's job, too. oh... wait a moment. Didn't we try something like that with SPIN (for suitable values of "we" that don't include "me")? -- hendrik From jay.krell at cornell.edu Tue Aug 4 02:59:32 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Mon, 3 Aug 2009 17:59:32 -0700 Subject: [M3devel] testing RC2. In-Reply-To: <20090804002754.GF25621@topoi.pooq.com> References: <20090804002754.GF25621@topoi.pooq.com> Message-ID: <1C5F772D-930B-472B-A83B-32DEC364D2FA@hotmail.com> Wikipedia: Aren't you subverting release manager Olaf? Not ready for exposure beyond m3devel? - Jay (phone) On Aug 3, 2009, at 5:27 PM, hendrik at topoi.pooq.com wrote: > Now that I've updated the wikipedia entry, it's easier to find the RC2 > downloads page. > > How can I update the other places that are easy to find on the google? > Specifically, > the Modula 3 resource page, www.modula3.org/ > Modula-3 Frequently Asked Questions (FAQ), > www.faqs.org/faqs/Modula-3-faq/ > > I'll soon be trying another installation fromscratch, using RC2, > and I'll let you know how it went. > > -- hendrik > > From wagner at elegosoft.com Tue Aug 4 08:40:32 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 04 Aug 2009 08:40:32 +0200 Subject: [M3devel] /etc/cm3.cfg (was: HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig) In-Reply-To: <1249334501.28197.750.camel@faramir.m3w.org> References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> <1249334501.28197.750.camel@faramir.m3w.org> Message-ID: <20090804084032.m4ytooeqs04cokcs@mail.elegosoft.com> Quoting Dragi?a Duri? : > On Mon, 2009-08-03 at 23:15 +0200, Olaf Wagner wrote: >> The compiler searches in a list of locations and takes the first >> one found, as is the convention when doing path searches. AFAIK >> /etc is currently the last option at all. > > Tried this today, and what happened was - cm3 set PKG_INSTALL to "/" and > I was unable to build anything until I moved cm3.cfg back to where cm3 > binary is. Well, this is just a matter of the correct contents of the configuration files then. Jay has tailored the suite to be located in .../cm3 currently. Nobody stops you to set PKG_INSTALL and other variables at the top level. If you use a 'non-standard' setup, then the files must be adapted. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Tue Aug 4 09:50:05 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 04 Aug 2009 09:50:05 +0200 Subject: [M3devel] /etc/cm3.cfg (was: HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig) In-Reply-To: <20090804084032.m4ytooeqs04cokcs@mail.elegosoft.com> References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> <1249334501.28197.750.camel@faramir.m3w.org> <20090804084032.m4ytooeqs04cokcs@mail.elegosoft.com> Message-ID: <1249372205.28197.1238.camel@faramir.m3w.org> On Tue, 2009-08-04 at 08:40 +0200, Olaf Wagner wrote: > Well, this is just a matter of the correct contents of the > configuration > files then. Jay has tailored the suite to be located in .../cm3 > currently. Nobody stops you to set PKG_INSTALL and other variables > at the top level. If you use a 'non-standard' setup, then the files > must be adapted. Figured it all out.. As cm3.cfg is twoliner, I've only created it from my RPM recipe with exact PKG_INSTALL location... Another question... While here... is there a separation of runtime and development packages in RELENG process? -- Dragi?a Duri? From wagner at elegosoft.com Tue Aug 4 10:22:54 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 04 Aug 2009 10:22:54 +0200 Subject: [M3devel] some cvs errors? In-Reply-To: References: <20090803131445.d5u1i1vaf484kg4s@mail.elegosoft.com> Message-ID: <20090804102254.yakamff0ysscccs8@mail.elegosoft.com> Quoting Jay K : > > One error, the second one, was maybe local, not on the server. > I saw it again later while running make-dist.sh, it tries to update itself. > Not clear why it occured here, maybe I had one running and the use > of $Id$ caused an attempted and failed write. Or maybe the error was > on the server. With CVS, can't be sure of much imho. > The other seems ok. > +2 for replacing cvs with something better.. after we invent more time... That something better would then be Perforce or AccuRev? Elego has got 3 committers to the Subversion project, and there are lots of problems, too. We've got several customers who are regularly pushing it over the edge of its capabilities... But I'm not against a change, as long as others will do the work ;-) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Aug 4 10:26:27 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 04 Aug 2009 10:26:27 +0200 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: <20090803214902.GB25621@topoi.pooq.com> References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> <20090803214902.GB25621@topoi.pooq.com> Message-ID: <20090804102627.bh1po5bfk0s4ggwo@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > One could have the configuration file contain the locations where to > find other configuration file(s). The file names in tis file could have > explicit notations indicating "where the compiler is", "current > directory", "User's home directory", "check the environment variable", > and so forth. > > This would make things somewhat more flexible, It's not clear whether > the added complexity would get in our way. That's just a matter of adding the appropriate quake code, isn't it? All that flexibility is already there. Getting such things correct in the details is much work though. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Aug 4 10:44:24 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 04 Aug 2009 10:44:24 +0200 Subject: [M3devel] /etc/cm3.cfg (was: HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig) In-Reply-To: <1249372205.28197.1238.camel@faramir.m3w.org> References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> <1249334501.28197.750.camel@faramir.m3w.org> <20090804084032.m4ytooeqs04cokcs@mail.elegosoft.com> <1249372205.28197.1238.camel@faramir.m3w.org> Message-ID: <20090804104424.zh0k8n7nvo8sk80g@mail.elegosoft.com> Quoting Dragi?a Duri? : > On Tue, 2009-08-04 at 08:40 +0200, Olaf Wagner wrote: >> Well, this is just a matter of the correct contents of the >> configuration >> files then. Jay has tailored the suite to be located in .../cm3 >> currently. Nobody stops you to set PKG_INSTALL and other variables >> at the top level. If you use a 'non-standard' setup, then the files >> must be adapted. > > Figured it all out.. As cm3.cfg is twoliner, I've only created it from > my RPM recipe with exact PKG_INSTALL location... > > Another question... While here... is there a separation of runtime and > development packages in RELENG process? Not really. The only real `runtime package' we currently have would be cm3-ws-bin-min..., containing m3core and libm3. But then you'r probably thinking of `binary' packages and `source packages', aren't you? M3 doesn't really do these distinctions... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Aug 4 10:58:35 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 04 Aug 2009 10:58:35 +0200 Subject: [M3devel] testing RC2. In-Reply-To: <1C5F772D-930B-472B-A83B-32DEC364D2FA@hotmail.com> References: <20090804002754.GF25621@topoi.pooq.com> <1C5F772D-930B-472B-A83B-32DEC364D2FA@hotmail.com> Message-ID: <20090804105835.vs1925r2kg480ccg@mail.elegosoft.com> Quoting jay.krell at cornell.edu: > Wikipedia: Aren't you subverting release manager Olaf? Not ready for > exposure beyond m3devel? I just moved the date for RC2 another week :-/ Too many things still to be done. See https://projects.elego.de/cm3/milestone/CM3%20Release%205.8%20RC2 We need o to improve the WWW presentation (there were suggestions from Peter Eiserloh and others but no concrete changes/commits AFAIK) o build some missing installation packages (for I386_DARWIN for example) o automate some installation tests (next thing I'll do) o get some feedback from manual tests If there are no commits to the web pages till Wednesday, I'll make some small adaptions there to be ready for RC2 then. Olaf > - Jay (phone) > > On Aug 3, 2009, at 5:27 PM, hendrik at topoi.pooq.com wrote: > >> Now that I've updated the wikipedia entry, it's easier to find the RC2 >> downloads page. >> >> How can I update the other places that are easy to find on the google? >> Specifically, >> the Modula 3 resource page, www.modula3.org/ >> Modula-3 Frequently Asked Questions (FAQ), >> www.faqs.org/faqs/Modula-3-faq/ >> >> I'll soon be trying another installation fromscratch, using RC2, >> and I'll let you know how it went. >> >> -- hendrik >> >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Tue Aug 4 13:16:47 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 04 Aug 2009 13:16:47 +0200 Subject: [M3devel] runtime/devel separation. was: Re: /etc/cm3.cfg (was: HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig) In-Reply-To: <20090804104424.zh0k8n7nvo8sk80g@mail.elegosoft.com> References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> <1249334501.28197.750.camel@faramir.m3w.org> <20090804084032.m4ytooeqs04cokcs@mail.elegosoft.com> <1249372205.28197.1238.camel@faramir.m3w.org> <20090804104424.zh0k8n7nvo8sk80g@mail.elegosoft.com> Message-ID: <1249384607.28197.1251.camel@faramir.m3w.org> On Tue, 2009-08-04 at 10:44 +0200, Olaf Wagner wrote: > Not really. > > The only real `runtime package' we currently have would be > cm3-ws-bin-min..., containing m3core and libm3. > > But then you'r probably thinking of `binary' packages and > `source packages', aren't you? M3 doesn't really do these > distinctions... No, I am not thinking about source packages. These we have - tar.gz's packed with building recipes. What I did in my RPM packaging is to separate contents (roughly): $BIN_INSTALL except compiler/debugger/related tools, $LIB_INSTALL and $PKG_INSTALL/*/$BUILD_DIR, /etc/cm3.cfg, /etc/cm3/ --> into runtime compiler/debugger, $PKG_INSTALL/*/src --> into development This way I can have my packages installed without library/program source shipped to end user. In case I need them, I just pull -devel package. I am using this scheme for some time now. What I have to work on is man1 vs. man7 and similar. Little bits and pieces. -- Dragi?a Duri? From jay.krell at cornell.edu Tue Aug 4 13:40:53 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 4 Aug 2009 11:40:53 +0000 Subject: [M3devel] some cvs errors? In-Reply-To: <20090804102254.yakamff0ysscccs8@mail.elegosoft.com> References: <20090803131445.d5u1i1vaf484kg4s@mail.elegosoft.com> <20090804102254.yakamff0ysscccs8@mail.elegosoft.com> Message-ID: Perforce is great. I'm already trained. If we can get a good deal (for being opensource) on it and someone provides hosting (with a good deal). I could never find anyone to host it. So I went with Date: Tue, 4 Aug 2009 10:22:54 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; m3-support at elego.de > Subject: Re: [M3devel] some cvs errors? > > Quoting Jay K : > >> >> One error, the second one, was maybe local, not on the server. >> I saw it again later while running make-dist.sh, it tries to update itself. >> Not clear why it occured here, maybe I had one running and the use >> of $Id$ caused an attempted and failed write. Or maybe the error was >> on the server. With CVS, can't be sure of much imho. >> The other seems ok. >> +2 for replacing cvs with something better.. after we invent more time... > > That something better would then be Perforce or AccuRev? > > Elego has got 3 committers to the Subversion project, and there are > lots of problems, too. We've got several customers who are regularly > pushing it over the edge of its capabilities... > > But I'm not against a change, as long as others will do the work ;-) > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Tue Aug 4 13:47:32 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 4 Aug 2009 11:47:32 +0000 Subject: [M3devel] some cvs errors? In-Reply-To: <20090804102254.yakamff0ysscccs8@mail.elegosoft.com> References: <20090803131445.d5u1i1vaf484kg4s@mail.elegosoft.com> <20090804102254.yakamff0ysscccs8@mail.elegosoft.com> Message-ID: Don't know what happened there..lost the content. Just that I use subversion at home, no branching, cheap. Subversion seems to do branching horribly though. Perforce does it maybe perfectly. Mercurial and monotone and git all sound good. If someone else does it, agreed. They pretty much all claim pretty good easy conversion. Not perfect, but ok. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > CC: m3devel at elegosoft.com; m3-support at elego.de > Subject: RE: [M3devel] some cvs errors? > Date: Tue, 4 Aug 2009 11:40:53 +0000 > > > Perforce is great. I'm already trained. > If we can get a good deal (for being opensource) on it and someone provides hosting (with a good deal). > I could never find anyone to host it. > So I went with Date: Tue, 4 Aug 2009 10:22:54 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com; m3-support at elego.de >> Subject: Re: [M3devel] some cvs errors? >> >> Quoting Jay K : >> >>> >>> One error, the second one, was maybe local, not on the server. >>> I saw it again later while running make-dist.sh, it tries to update itself. >>> Not clear why it occured here, maybe I had one running and the use >>> of $Id$ caused an attempted and failed write. Or maybe the error was >>> on the server. With CVS, can't be sure of much imho. >>> The other seems ok. >>> +2 for replacing cvs with something better.. after we invent more time... >> >> That something better would then be Perforce or AccuRev? >> >> Elego has got 3 committers to the Subversion project, and there are >> lots of problems, too. We've got several customers who are regularly >> pushing it over the edge of its capabilities... >> >> But I'm not against a change, as long as others will do the work ;-) >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> From jay.krell at cornell.edu Tue Aug 4 13:49:29 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 4 Aug 2009 11:49:29 +0000 Subject: [M3devel] testing RC2. In-Reply-To: <20090804105835.vs1925r2kg480ccg@mail.elegosoft.com> References: <20090804002754.GF25621@topoi.pooq.com> <1C5F772D-930B-472B-A83B-32DEC364D2FA@hotmail.com> <20090804105835.vs1925r2kg480ccg@mail.elegosoft.com> Message-ID: > build some missing installation packages (for I386_DARWIN for example) I have a new computer arriving roughly Friday on which I can setup near arbitrary x86/AMD64 VMs, as well as doing native I386_DARWIN and AMD64_DARWIN. AMD64_FREEBSD is also missing for example. Tony should also be able to do {I386,AMD64}_DARWIN. - Jay ---------------------------------------- > Date: Tue, 4 Aug 2009 10:58:35 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] testing RC2. > > Quoting jay.krell at cornell.edu: > >> Wikipedia: Aren't you subverting release manager Olaf? Not ready for >> exposure beyond m3devel? > > I just moved the date for RC2 another week :-/ Too many things still > to be done. See > > https://projects.elego.de/cm3/milestone/CM3%20Release%205.8%20RC2 > > We need > > o to improve the WWW presentation (there were suggestions from > Peter Eiserloh and others but no concrete changes/commits AFAIK) > > o build some missing installation packages (for I386_DARWIN for example) > > o automate some installation tests (next thing I'll do) > > o get some feedback from manual tests > > If there are no commits to the web pages till Wednesday, I'll make > some small adaptions there to be ready for RC2 then. > > Olaf > >> - Jay (phone) >> >> On Aug 3, 2009, at 5:27 PM, hendrik at topoi.pooq.com wrote: >> >>> Now that I've updated the wikipedia entry, it's easier to find the RC2 >>> downloads page. >>> >>> How can I update the other places that are easy to find on the google? >>> Specifically, >>> the Modula 3 resource page, www.modula3.org/ >>> Modula-3 Frequently Asked Questions (FAQ), >>> www.faqs.org/faqs/Modula-3-faq/ >>> >>> I'll soon be trying another installation fromscratch, using RC2, >>> and I'll let you know how it went. >>> >>> -- hendrik >>> >>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From rcoleburn at scires.com Tue Aug 4 17:09:32 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 04 Aug 2009 11:09:32 -0400 Subject: [M3devel] some cvs errors? In-Reply-To: <20090804102254.yakamff0ysscccs8@mail.elegosoft.com> References: <20090803131445.d5u1i1vaf484kg4s@mail.elegosoft.com> <20090804102254.yakamff0ysscccs8@mail.elegosoft.com> Message-ID: <4A78164A.1E75.00D7.1@scires.com> As far as replacing CVS with something else, I have "no dog in the race" so to speak, but I will say that CVS has worked fine for my purposes and the TortoiseCVS integration with Windows Explorer makes life easy for me on Windows. I don't have to remember all the CVS command line switches; I just use the TortoiseCVS GUI and it works. If we switch to something else that doesn't have this level of GUI, it will present a learning curve for me. Regards, Randy Coleburn >>> Olaf Wagner 8/4/2009 4:22 AM >>> Quoting Jay K : > > One error, the second one, was maybe local, not on the server. > I saw it again later while running make-dist.sh, it tries to update itself. > Not clear why it occured here, maybe I had one running and the use > of $Id$ caused an attempted and failed write. Or maybe the error was > on the server. With CVS, can't be sure of much imho. > The other seems ok. > +2 for replacing cvs with something better.. after we invent more time... That something better would then be Perforce or AccuRev? Elego has got 3 committers to the Subversion project, and there are lots of problems, too. We've got several customers who are regularly pushing it over the edge of its capabilities... But I'm not against a change, as long as others will do the work ;-) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Tue Aug 4 17:22:56 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 4 Aug 2009 11:22:56 -0400 Subject: [M3devel] /etc/cm3.cfg (was: HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig) In-Reply-To: <20090804104424.zh0k8n7nvo8sk80g@mail.elegosoft.com> References: <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> <1249334501.28197.750.camel@faramir.m3w.org> <20090804084032.m4ytooeqs04cokcs@mail.elegosoft.com> <1249372205.28197.1238.camel@faramir.m3w.org> <20090804104424.zh0k8n7nvo8sk80g@mail.elegosoft.com> Message-ID: <20090804152255.GA27699@topoi.pooq.com> On Tue, Aug 04, 2009 at 10:44:24AM +0200, Olaf Wagner wrote: > Quoting Dragi?a Duri? : > > >On Tue, 2009-08-04 at 08:40 +0200, Olaf Wagner wrote: > >>Well, this is just a matter of the correct contents of the > >>configuration > >>files then. Jay has tailored the suite to be located in .../cm3 > >>currently. Nobody stops you to set PKG_INSTALL and other variables > >>at the top level. If you use a 'non-standard' setup, then the files > >>must be adapted. > > > >Figured it all out.. As cm3.cfg is twoliner, I've only created it from > >my RPM recipe with exact PKG_INSTALL location... > > > >Another question... While here... is there a separation of runtime and > >development packages in RELENG process? > > Not really. > > The only real `runtime package' we currently have would be > cm3-ws-bin-min..., containing m3core and libm3. > > But then you'r probably thinking of `binary' packages and > `source packages', aren't you? M3 doesn't really do these distinctions... The distinction is what you need to run an executable image that uses libraries, versus what you need to compile things using them. M3 may not enable you to compile a library-using application without the library source code, but it should enable you to run the compiled code without it. That said, for the current release, I don't see it to be important to make the distinctio for the current release. It's more important to make available something up-to-date and reliably usable out soon so that people can use it. -- hendrik From hendrik at topoi.pooq.com Tue Aug 4 17:37:21 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 4 Aug 2009 11:37:21 -0400 Subject: [M3devel] testing RC2. In-Reply-To: <1C5F772D-930B-472B-A83B-32DEC364D2FA@hotmail.com> References: <20090804002754.GF25621@topoi.pooq.com> <1C5F772D-930B-472B-A83B-32DEC364D2FA@hotmail.com> Message-ID: <20090804153721.GC27699@topoi.pooq.com> On Mon, Aug 03, 2009 at 05:59:32PM -0700, jay.krell at cornell.edu wrote: > Wikipedia: Aren't you subverting release manager Olaf? Not ready for > exposure beyond m3devel? > > - Jay (phone) I asked in this list shortly before my vacation, and someone gave the go-ahead. If it's a problem, let me know, and I'll gladly revert the change. The entry I provided does say it's the place to go for release candidates, and I intend to replace it with a pinter to the real release when it's ready. Given the difficulty of finding any usable m3 implementation after the great file-system disaster, I thought this was an essential interim measure. > > On Aug 3, 2009, at 5:27 PM, hendrik at topoi.pooq.com wrote: > > >Now that I've updated the wikipedia entry, it's easier to find the RC2 > >downloads page. > > > >How can I update the other places that are easy to find on the google? > >Specifically, > > the Modula 3 resource page, www.modula3.org/ > > Modula-3 Frequently Asked Questions (FAQ), > > www.faqs.org/faqs/Modula-3-faq/ > > > >I'll soon be trying another installation fromscratch, using RC2, > >and I'll let you know how it went. > > > >-- hendrik > > > > From hendrik at topoi.pooq.com Tue Aug 4 17:49:27 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 4 Aug 2009 11:49:27 -0400 Subject: [M3devel] some cvs errors? In-Reply-To: <20090804102254.yakamff0ysscccs8@mail.elegosoft.com> References: <20090803131445.d5u1i1vaf484kg4s@mail.elegosoft.com> <20090804102254.yakamff0ysscccs8@mail.elegosoft.com> Message-ID: <20090804154927.GD27699@topoi.pooq.com> On Tue, Aug 04, 2009 at 10:22:54AM +0200, Olaf Wagner wrote: > Quoting Jay K : > > > > >One error, the second one, was maybe local, not on the server. > > I saw it again later while running make-dist.sh, it tries to update > > itself. > > Not clear why it occured here, maybe I had one running and the use > >of $Id$ caused an attempted and failed write. Or maybe the error was > > on the server. With CVS, can't be sure of much imho. > >The other seems ok. > >+2 for replacing cvs with something better.. after we invent more time... > > That something better would then be Perforce or AccuRev? > > Elego has got 3 committers to the Subversion project, and there are > lots of problems, too. We've got several customers who are regularly > pushing it over the edge of its capabilities... > > But I'm not against a change, as long as others will do the work ;-) > > Olaf I'm being slow on teh cvs->monotone conversion project I was looking into. Once again, sorry. Other things, ostly personal, keep getting in the way. One thing that's delaying it is that I see no point in doing the conversion while we're in the throes of getting a release out. It looks as if the conversion, should we go through with it, will be one-way; that is, monotone will not conveniently pass updates on to cvs. I don't know yet whether it will be possible to regularly pass cvs changes on to monotone, though. It would be a lot easier if it were. -- hendrik From wagner at elegosoft.com Tue Aug 4 17:54:04 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 04 Aug 2009 17:54:04 +0200 Subject: [M3devel] testing RC2. Message-ID: <20090804175404.k6tkhj4i6804ck4c@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > On Mon, Aug 03, 2009 at 05:59:32PM -0700, jay.krell at cornell.edu wrote: >> Wikipedia: Aren't you subverting release manager Olaf? Not ready for >> exposure beyond m3devel? >> >> - Jay (phone) > > I asked in this list shortly before my vacation, and someone gave the > go-ahead. > > If it's a problem, let me know, and I'll gladly revert the change. > > The entry I provided does say it's the place to go for release > candidates, and I intend to replace it with a pinter to the real release > when it's ready. > > Given the difficulty of finding any usable m3 implementation after the > great file-system disaster, I thought this was an essential interim > measure. I think it's OK now; several tests have passed successfully. I'll try to improve the web pages on Wednesday evening, unless someone does that before (hint!). Peter Eiserloh sent several suggestions. Hopefully we'll finally deliver at the next weekend :-) Olaf > > >> >> On Aug 3, 2009, at 5:27 PM, hendrik at topoi.pooq.com wrote: >> >> >Now that I've updated the wikipedia entry, it's easier to find the RC2 >> >downloads page. >> > >> >How can I update the other places that are easy to find on the google? >> >Specifically, >> > the Modula 3 resource page, www.modula3.org/ >> > Modula-3 Frequently Asked Questions (FAQ), >> > www.faqs.org/faqs/Modula-3-faq/ >> > >> >I'll soon be trying another installation fromscratch, using RC2, >> >and I'll let you know how it went. >> > >> >-- hendrik >> > >> > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Aug 4 17:56:26 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 04 Aug 2009 17:56:26 +0200 Subject: [M3devel] automated installation tests on Hudson Message-ID: <20090804175626.xtce1l8jnoc844s8@mail.elegosoft.com> It's not much, but a start: http://hudson.modula3.com:8080/view/test-install/ SOLgnu and SOLsun packages should also be complete tomorrow. Some installation problems found though, but they won't stop the release. That's it for today, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From neels at elego.de Wed Aug 5 00:12:59 2009 From: neels at elego.de (Neels J Hofmeyr) Date: Wed, 05 Aug 2009 00:12:59 +0200 Subject: [M3devel] some cvs errors? In-Reply-To: <4A78164A.1E75.00D7.1@scires.com> References: <20090803131445.d5u1i1vaf484kg4s@mail.elegosoft.com> <20090804102254.yakamff0ysscccs8@mail.elegosoft.com> <4A78164A.1E75.00D7.1@scires.com> Message-ID: <4A78B26B.2010207@elego.de> Randy Coleburn wrote: > > As far as replacing CVS with something else, I have "no dog in the race" > so to speak, but I will say that CVS has worked fine for my purposes and > the TortoiseCVS integration with Windows Explorer makes life easy for me Well, there is TortoiseSVN. I'm not convinced that the branching strategies needed for CM3 dev would indeed push svn over the edge of its capabilities -- not if CVS worked fine all these years. And I would certainly prefer a free SCM to one with a price tag and a restrictive license. You guessed it, one of the Subversion committers speaking ;) ...and this discussion remains empty until anyone wants to actually do the work ;) ~Neels > on Windows. I don't have to remember all the CVS command line switches; > I just use the TortoiseCVS GUI and it works. If we switch to something > else that doesn't have this level of GUI, it will present a learning > curve for me. > Regards, > Randy Coleburn > >>>> Olaf Wagner 8/4/2009 4:22 AM >>> > Quoting Jay K : > >> >> One error, the second one, was maybe local, not on the server. >> I saw it again later while running make-dist.sh, it tries to update > itself. >> Not clear why it occured here, maybe I had one running and the use >> of $Id$ caused an attempted and failed write. Or maybe the error was >> on the server. With CVS, can't be sure of much imho. >> The other seems ok. >> +2 for replacing cvs with something better.. after we invent more time... > > That something better would then be Perforce or AccuRev? > > Elego has got 3 committers to the Subversion project, and there are > lots of problems, too. We've got several customers who are regularly > pushing it over the edge of its capabilities... > > But I'm not against a change, as long as others will do the work ;-) > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From wagner at elegosoft.com Wed Aug 5 13:18:42 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 05 Aug 2009 13:18:42 +0200 Subject: [M3devel] SOLgnu still broken on ssol Message-ID: <20090805131842.5ha3ycwcbkkc448s@mail.elegosoft.com> The SOLgnu builds are still broken, though the makedist job claims to be successful (still need to fix the script): === package m3-libs/m3core === +++ cm3 -build -override $RARGS -DROOT='/home/hudson/workspace/cm3-makedist-SOLgnu/cm3' -DCM3_VERSION_TEXT='d5.8.2' -DCM3_VERSION_NUMBER='050802' -DCM3_LAST_CHANGED='2009-07-15' +++ ld: fatal: relocation error: R_SPARC_32: file RTMachineASM.o: symbol : offset 0xfd951bee is non-aligned ld: fatal: relocation error: R_SPARC_32: file RTMachineASM.o: symbol : offset 0xfd951bf2 is non-aligned ld: fatal: relocation error: R_SPARC_32: file RTMachineASM.o: symbol : offset 0xfd951bf6 is non-aligned ld: fatal: relocation error: R_SPARC_32: file RTMachineASM.o: symbol : offset 0xfd95d2bf is non-aligned ld: fatal: relocation error: R_SPARC_32: file RTMachineASM.o: symbol : offset 0xfd9669ce is non-aligned collect2: ld returned 1 exit status make_lib => 1 librarian failed building: m3core See http://hudson.modula3.com:8080/view/SOLgnu/job/cm3-makedist-SOLgnu/3/consoleFull for more details. Argh... I forgot to include the path preference for /usr/local again to use the pre-built gcc. Now it will run another 4 hours... SOLsun seems to be OK. I'll run the installation tests on it soon. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From lists at darko.org Wed Aug 5 14:06:54 2009 From: lists at darko.org (Darko Volaric) Date: Wed, 5 Aug 2009 14:06:54 +0200 Subject: [M3devel] some cvs errors? In-Reply-To: <4A78B26B.2010207@elego.de> References: <20090803131445.d5u1i1vaf484kg4s@mail.elegosoft.com> <20090804102254.yakamff0ysscccs8@mail.elegosoft.com> <4A78164A.1E75.00D7.1@scires.com> <4A78B26B.2010207@elego.de> Message-ID: <825BD2B1-CCCE-4906-A666-CAA1AE0C3CAB@darko.org> Has anyone considered git? It seems particularly well suited to distributed development, having been essentially designed for open source groups, and seems to be undergoing intensive development. On 05/08/2009, at 12:12 AM, Neels J Hofmeyr wrote: > Randy Coleburn wrote: >> >> As far as replacing CVS with something else, I have "no dog in the >> race" >> so to speak, but I will say that CVS has worked fine for my >> purposes and >> the TortoiseCVS integration with Windows Explorer makes life easy >> for me > > Well, there is TortoiseSVN. > > I'm not convinced that the branching strategies needed for CM3 dev > would > indeed push svn over the edge of its capabilities -- not if CVS > worked fine > all these years. > > And I would certainly prefer a free SCM to one with a price tag and a > restrictive license. You guessed it, one of the Subversion committers > speaking ;) > > ...and this discussion remains empty until anyone wants to actually > do the > work ;) > ~Neels > >> on Windows. I don't have to remember all the CVS command line >> switches; >> I just use the TortoiseCVS GUI and it works. If we switch to >> something >> else that doesn't have this level of GUI, it will present a learning >> curve for me. >> Regards, >> Randy Coleburn >> >>>>> Olaf Wagner 8/4/2009 4:22 AM >>> >> Quoting Jay K : >> >>> >>> One error, the second one, was maybe local, not on the server. >>> I saw it again later while running make-dist.sh, it tries to update >> itself. >>> Not clear why it occured here, maybe I had one running and the use >>> of $Id$ caused an attempted and failed write. Or maybe the error was >>> on the server. With CVS, can't be sure of much imho. >>> The other seems ok. >>> +2 for replacing cvs with something better.. after we invent more >>> time... >> >> That something better would then be Perforce or AccuRev? >> >> Elego has got 3 committers to the Subversion project, and there are >> lots of problems, too. We've got several customers who are regularly >> pushing it over the edge of its capabilities... >> >> But I'm not against a change, as long as others will do the work ;-) >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >> Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >> 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >> Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 >> > From wagner at elegosoft.com Wed Aug 5 15:54:46 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 05 Aug 2009 15:54:46 +0200 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090803093135.3F59DCC81B@birch.elegosoft.com> <4A76CADA.1E75.00D7.1@scires.com> <4A76FEED.1E75.00D7.1@scires.com> Message-ID: <20090805155446.wgsqqqclm8skggkw@mail.elegosoft.com> I just found this mail... too many of them. Quoting Jay K : > I failed to figure how to move anything at all to RC2 (perhaps that > is by-design, Olaf escalating and using more and more arcane > features of cvs to stay ahead of me), but I moved it to the release > branch, which should get it at least into whatever if anything > follows RC2. This is no arcane feature, just the conventional way to pin a bound configuration. We use the release branch to improve the release quality, and certain points on it are marked with RC1, RC2, ... The CVS concept for bound configurations is called a tag (non-branch tag). RC2 is now in the past. We've already built most of the packages. If there is something really important, we can move the tag again, which means that we will probably have to rebuild a number of installation packages. If it's something that severely breaks the system, we may have to do that. What do you say? > The fix seems fragile though. Converting to a full path would > probably be better. > (Full paths are still contextual, but most people/code seem ok > ignoring that. Could be net used or chroot..) RC3 should be faster, as most of the needed infrastructure is now in place. So it may be best to just know that the fix is in there. Olaf > ________________________________ >> Date: Mon, 3 Aug 2009 15:17:30 -0400 >> From: rcoleburn at scires.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] [M3commit] CVS Update: cm3 >> >> Jay: >> >> Your change to MxConfig.m3 seems to work fine for cm3ide, provided >> that I replace HOST by "NT386" in my cm3.cfg is as follows: >> >> INSTALL_ROOT = path() & "/.." >> include (path() & "/config/NT386") >> >> Thank you! >> >> Can we get your revised MxConfig.m3 put into the RC2 branch? >> >> >> Regards, >> >> Randy >> >>>>> "Randy Coleburn" 8/3/2009 11:35 AM>>> >> >> Jay: >> >> I agree that running cm3 from "bin" folder is not going to be >> productive; however, other programs (such as cm3ide) also use the >> quake stuff and they don't have this limitation. I think your >> change is a good one. I'll run some tests and see how cm3ide fares. >> Thanks. >> >> --Randy >> >>>>> Jay Krell 8/3/2009 11:31 AM>>> >> CVSROOT:/usr/cvs >> Changes by:jkrell at birch.09/08/03 11:31:35 >> >> Modified files: >> cm3/m3-sys/m3quake/src/: MxConfig.m3 >> >> Log message: >> use "." instead of empty string for path() when current working >> directory is the actual directory of cm3; not sure what good >> running cm3 here is, and we probe way too many places.. >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Wed Aug 5 20:50:21 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 05 Aug 2009 20:50:21 +0200 Subject: [M3devel] WWW updates for the release Message-ID: <20090805205021.6ag1s0evoc0cggc0@mail.elegosoft.com> I've made some small additions and updates for the pending release, mostly based on https://projects.elego.de/cm3/ticket/1019. Some target platform archives are still missing, but we can add them during the next days. I'd like to have some broader feedback now if possible. The following topics are still unaddressed; perhaps anybody cares to fill them in: (c) The major changes to the compiler should be listed somewhere, since the last release shown on the download page. Right now the last release indicated is 5.4. There are some snapshots of 5.5, but not final release of 5.5. 3 - About-CM3: The "About CM3" page, should have a section listing all the changes / enhancements to the language that it accepts vice that described in the language reference from Nelson's SPWM3. For example, WIDECHAR, LONGINT are two new primitive types. Also list all the pragmas recognized by the compiler as that is a compiler unique issue. http://opencm3.net/about-cm3.html It should also list all the architectures that are supported by the compiler. These should always reflect those of the latest "release" version of the compiler. Please note that the latest changes are only checked-in on the release branch. Everything will be merged back to the main trunk later. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Fri Aug 7 11:56:24 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 07 Aug 2009 11:56:24 +0200 Subject: [M3devel] More Unix constants missing.... Message-ID: <1249638984.2745.11.camel@faramir.m3w.org> Can we have them, in both HEAD ad RC2 branch? TIA, dd === CONST TIOCMGET = 16_5415; TIOCMSET = 16_5418; Bits = ARRAY StatusBits OF CARDINAL { Unix.TIOCM_LE, Unix.TIOCM_DTR, Unix.TIOCM_RTS, Unix.TIOCM_ST, Unix.TIOCM_SR, Unix.TIOCM_CTS, Unix.TIOCM_CAR, Unix.TIOCM_RNG, Unix.TIOCM_DSR }; -- Dragi?a Duri? From wagner at elegosoft.com Fri Aug 7 12:18:07 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 07 Aug 2009 12:18:07 +0200 Subject: [M3devel] More Unix constants missing.... In-Reply-To: <1249638984.2745.11.camel@faramir.m3w.org> References: <1249638984.2745.11.camel@faramir.m3w.org> Message-ID: <20090807121807.ydy78qp4oww0og0c@mail.elegosoft.com> Quoting Dragi?a Duri? : > Can we have them, in both HEAD ad RC2 branch? > > TIA, > dd > > === > CONST > TIOCMGET = 16_5415; > TIOCMSET = 16_5418; > > Bits = ARRAY StatusBits OF CARDINAL { > Unix.TIOCM_LE, > Unix.TIOCM_DTR, > Unix.TIOCM_RTS, > Unix.TIOCM_ST, > Unix.TIOCM_SR, > Unix.TIOCM_CTS, > Unix.TIOCM_CAR, > Unix.TIOCM_RNG, > Unix.TIOCM_DSR > }; > > -- > Dragi?a Duri? If additional constants are missing, just merge them over to the release branch. There is no RC2 branch by the way and will never be. RC2 was just one version several days ago on the 5.8 release branch. If you want me to do it, knowing the file(s) and versions involved would certainly help ;-) As I'm not at home this weekend, it may take some time though. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Fri Aug 7 12:35:38 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 07 Aug 2009 12:35:38 +0200 Subject: [M3devel] More Unix constants missing.... In-Reply-To: <20090807121807.ydy78qp4oww0og0c@mail.elegosoft.com> References: <1249638984.2745.11.camel@faramir.m3w.org> <20090807121807.ydy78qp4oww0og0c@mail.elegosoft.com> Message-ID: <1249641338.2745.13.camel@faramir.m3w.org> I am not at home with CVS, really. It's probably 22 seconds job for Jay-who-cut-them-out-in-the-first-place :). I can make fast fix in my code till I wait proper one, in line with nest style guidelines for UNIX constants. On Fri, 2009-08-07 at 12:18 +0200, Olaf Wagner wrote: > If additional constants are missing, just merge them over to the > release branch. There is no RC2 branch by the way and will never be. > RC2 was just one version several days ago on the 5.8 release branch. > > If you want me to do it, knowing the file(s) and versions involved > would certainly help ;-) As I'm not at home this weekend, it may take > some time though. -- Dragi?a Duri? From hendrik at topoi.pooq.com Sat Aug 8 13:46:19 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sat, 8 Aug 2009 07:46:19 -0400 Subject: [M3devel] trouble with RC2 -- maybe with hudson? Message-ID: <20090808114619.GA3806@topoi.pooq.com> Installing cm3-bin-core-LINUXLIBC6-d5.8.2-RC2.tgz on my 32-bit intel Debian squeeze laptop went fine. But when I tried cm3-bin-core-LINUXLIBC6-d5.8.2-RC2.tgz (downloaded a few days ago) I got: hendrik at notlookedfor:~/cm3$ mkdir gui hendrik at notlookedfor:~/cm3$ cd gui hendrik at notlookedfor:~/cm3/gui$ tar -zxf ../../Desktop/cm3-bin-ws-gui-LINUXLIBC6-d5.8.2-RC2.tgz hendrik at notlookedfor:~/cm3/gui$ ls collection-gui.html install.sh m3-comm m3-tools m3-ui m3-win setup.cmd hendrik at notlookedfor:~/cm3/gui$ ./install.sh --- shipping from LINUXLIBC6 --- --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/tcp/LINUXLIBC6 .M3EXPORTS . => /usr/local/cm3/lib libm3tcp.so.5 "/home/hendrik/cm3/gui/m3-comm/tcp/LINUXLIBC6/.M3SHIP", line 6: quake runtime error: unable to create directory "/home/hudson": errno=13 --procedure-- -line- -file--- make_dir -- 6 /home/hendrik/cm3/gui/m3-comm/tcp/LINUXLIBC6/.M3SHIP Fatal Error: package build failed --- shipping from LINUXLIBC6 --- missing ".M3SHIP" file, build the package first. --- shipping from LINUXLIBC6 --- missing ".M3SHIP" file, build the package first. --- shipping from LINUXLIBC6 --- missing ".M3SHIP" file, build the package first. --- shipping from LINUXLIBC6 --- missing ".M3SHIP" file, build the package first. --- shipping from LINUXLIBC6 --- missing ".M3SHIP" file, build the package first. --- shipping from LINUXLIBC6 --- missing ".M3SHIP" file, build the package first. --- shipping from LINUXLIBC6 --- missing ".M3SHIP" file, build the package first. --- shipping from LINUXLIBC6 --- missing ".M3SHIP" file, build the package first. --- shipping from LINUXLIBC6 --- missing ".M3SHIP" file, build the package first. --- shipping from LINUXLIBC6 --- missing ".M3SHIP" file, build the package first. --- shipping from LINUXLIBC6 --- missing ".M3SHIP" file, build the package first. --- shipping from LINUXLIBC6 --- missing ".M3SHIP" file, build the package first. --- shipping from LINUXLIBC6 --- missing ".M3SHIP" file, build the package first. --- shipping from LINUXLIBC6 --- missing ".M3SHIP" file, build the package first. hendrik at notlookedfor:~/cm3/gui$ exit It looks to me as if hudson has gotten in the way. -- hendrik From wagner at elegosoft.com Sat Aug 8 13:54:30 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 08 Aug 2009 13:54:30 +0200 Subject: [M3devel] trouble with RC2 -- maybe with hudson? In-Reply-To: <20090808114619.GA3806@topoi.pooq.com> References: <20090808114619.GA3806@topoi.pooq.com> Message-ID: <20090808135430.1iy8os9eogwwcss0@mail.elegosoft.com> Please create a ticket for that and attach the contents of file "/home/hendrik/cm3/gui/m3-comm/tcp/LINUXLIBC6/.M3SHIP"/ I'll have a look at it ASAP. Olaf Quoting hendrik at topoi.pooq.com: > Installing cm3-bin-core-LINUXLIBC6-d5.8.2-RC2.tgz on my 32-bit > intel Debian squeeze laptop went fine. > > But when I tried cm3-bin-core-LINUXLIBC6-d5.8.2-RC2.tgz (downloaded a > few days ago) I got: > > hendrik at notlookedfor:~/cm3$ mkdir gui > hendrik at notlookedfor:~/cm3$ cd gui > hendrik at notlookedfor:~/cm3/gui$ tar -zxf > ../../Desktop/cm3-bin-ws-gui-LINUXLIBC6-d5.8.2-RC2.tgz > hendrik at notlookedfor:~/cm3/gui$ ls > collection-gui.html install.sh m3-comm m3-tools m3-ui m3-win > setup.cmd > hendrik at notlookedfor:~/cm3/gui$ ./install.sh > --- shipping from LINUXLIBC6 --- > > --- shipping from LINUXLIBC6 --- > > . => /usr/local/cm3/pkg/tcp/LINUXLIBC6 > .M3EXPORTS > . => /usr/local/cm3/lib > libm3tcp.so.5 > "/home/hendrik/cm3/gui/m3-comm/tcp/LINUXLIBC6/.M3SHIP", line 6: quake > runtime error: unable to create directory "/home/hudson": errno=13 > > --procedure-- -line- -file--- > make_dir -- > 6 > /home/hendrik/cm3/gui/m3-comm/tcp/LINUXLIBC6/.M3SHIP > > Fatal Error: package build failed > --- shipping from LINUXLIBC6 --- > > missing ".M3SHIP" file, build the package first. > --- shipping from LINUXLIBC6 --- > > missing ".M3SHIP" file, build the package first. > --- shipping from LINUXLIBC6 --- > > missing ".M3SHIP" file, build the package first. > --- shipping from LINUXLIBC6 --- > > missing ".M3SHIP" file, build the package first. > --- shipping from LINUXLIBC6 --- > > missing ".M3SHIP" file, build the package first. > --- shipping from LINUXLIBC6 --- > > missing ".M3SHIP" file, build the package first. > --- shipping from LINUXLIBC6 --- > > missing ".M3SHIP" file, build the package first. > --- shipping from LINUXLIBC6 --- > > missing ".M3SHIP" file, build the package first. > --- shipping from LINUXLIBC6 --- > > missing ".M3SHIP" file, build the package first. > --- shipping from LINUXLIBC6 --- > > missing ".M3SHIP" file, build the package first. > --- shipping from LINUXLIBC6 --- > > missing ".M3SHIP" file, build the package first. > --- shipping from LINUXLIBC6 --- > > missing ".M3SHIP" file, build the package first. > --- shipping from LINUXLIBC6 --- > > missing ".M3SHIP" file, build the package first. > --- shipping from LINUXLIBC6 --- > > missing ".M3SHIP" file, build the package first. > hendrik at notlookedfor:~/cm3/gui$ exit > > > > It looks to me as if hudson has gotten in the way. > > -- hendrik > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sat Aug 8 15:03:38 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 8 Aug 2009 13:03:38 +0000 Subject: [M3devel] trouble with RC2 -- maybe with hudson? In-Reply-To: <20090808135430.1iy8os9eogwwcss0@mail.elegosoft.com> References: <20090808114619.GA3806@topoi.pooq.com> <20090808135430.1iy8os9eogwwcss0@mail.elegosoft.com> Message-ID: I rewrote the m3ship-no-resolve stuff some weeks ago. There must be a hole in my rewrite. The feature is very nice, though not well implemented either at first or with my rewrite, maybe no good way to do it. - Jay ---------------------------------------- > Date: Sat, 8 Aug 2009 13:54:30 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] trouble with RC2 -- maybe with hudson? > > Please create a ticket for that and attach the contents of file > "/home/hendrik/cm3/gui/m3-comm/tcp/LINUXLIBC6/.M3SHIP"/ > > I'll have a look at it ASAP. > > Olaf > > Quoting hendrik at topoi.pooq.com: > >> Installing cm3-bin-core-LINUXLIBC6-d5.8.2-RC2.tgz on my 32-bit >> intel Debian squeeze laptop went fine. >> >> But when I tried cm3-bin-core-LINUXLIBC6-d5.8.2-RC2.tgz (downloaded a >> few days ago) I got: >> >> hendrik at notlookedfor:~/cm3$ mkdir gui >> hendrik at notlookedfor:~/cm3$ cd gui >> hendrik at notlookedfor:~/cm3/gui$ tar -zxf >> ../../Desktop/cm3-bin-ws-gui-LINUXLIBC6-d5.8.2-RC2.tgz >> hendrik at notlookedfor:~/cm3/gui$ ls >> collection-gui.html install.sh m3-comm m3-tools m3-ui m3-win >> setup.cmd >> hendrik at notlookedfor:~/cm3/gui$ ./install.sh >> --- shipping from LINUXLIBC6 --- >> >> --- shipping from LINUXLIBC6 --- >> >> . => /usr/local/cm3/pkg/tcp/LINUXLIBC6 >> .M3EXPORTS >> . => /usr/local/cm3/lib >> libm3tcp.so.5 >> "/home/hendrik/cm3/gui/m3-comm/tcp/LINUXLIBC6/.M3SHIP", line 6: quake >> runtime error: unable to create directory "/home/hudson": errno=13 >> >> --procedure-- -line- -file--- >> make_dir -- >> 6 >> /home/hendrik/cm3/gui/m3-comm/tcp/LINUXLIBC6/.M3SHIP >> >> Fatal Error: package build failed >> --- shipping from LINUXLIBC6 --- >> >> missing ".M3SHIP" file, build the package first. >> --- shipping from LINUXLIBC6 --- >> >> missing ".M3SHIP" file, build the package first. >> --- shipping from LINUXLIBC6 --- >> >> missing ".M3SHIP" file, build the package first. >> --- shipping from LINUXLIBC6 --- >> >> missing ".M3SHIP" file, build the package first. >> --- shipping from LINUXLIBC6 --- >> >> missing ".M3SHIP" file, build the package first. >> --- shipping from LINUXLIBC6 --- >> >> missing ".M3SHIP" file, build the package first. >> --- shipping from LINUXLIBC6 --- >> >> missing ".M3SHIP" file, build the package first. >> --- shipping from LINUXLIBC6 --- >> >> missing ".M3SHIP" file, build the package first. >> --- shipping from LINUXLIBC6 --- >> >> missing ".M3SHIP" file, build the package first. >> --- shipping from LINUXLIBC6 --- >> >> missing ".M3SHIP" file, build the package first. >> --- shipping from LINUXLIBC6 --- >> >> missing ".M3SHIP" file, build the package first. >> --- shipping from LINUXLIBC6 --- >> >> missing ".M3SHIP" file, build the package first. >> --- shipping from LINUXLIBC6 --- >> >> missing ".M3SHIP" file, build the package first. >> --- shipping from LINUXLIBC6 --- >> >> missing ".M3SHIP" file, build the package first. >> hendrik at notlookedfor:~/cm3/gui$ exit >> >> >> >> It looks to me as if hudson has gotten in the way. >> >> -- hendrik >> >> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From hendrik at topoi.pooq.com Sat Aug 8 15:15:50 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sat, 8 Aug 2009 09:15:50 -0400 Subject: [M3devel] trouble with RC2 -- maybe with hudson? In-Reply-To: <20090808135430.1iy8os9eogwwcss0@mail.elegosoft.com> References: <20090808114619.GA3806@topoi.pooq.com> <20090808135430.1iy8os9eogwwcss0@mail.elegosoft.com> Message-ID: <20090808131549.GA3891@topoi.pooq.com> On Sat, Aug 08, 2009 at 01:54:30PM +0200, Olaf Wagner wrote: > Please create a ticket for that and attach the contents of file > "/home/hendrik/cm3/gui/m3-comm/tcp/LINUXLIBC6/.M3SHIP"/ Done. Ticket # 1052(new sw-bug) -- hendrik From wagner at elegosoft.com Sat Aug 8 16:38:22 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 08 Aug 2009 16:38:22 +0200 Subject: [M3devel] trouble with RC2 -- maybe with hudson? In-Reply-To: References: <20090808114619.GA3806@topoi.pooq.com> <20090808135430.1iy8os9eogwwcss0@mail.elegosoft.com> Message-ID: <20090808163822.9tr379n4q8skkscw@mail.elegosoft.com> Quoting Jay K : > I rewrote the m3ship-no-resolve stuff some weeks ago. > There must be a hole in my rewrite. > The feature is very nice, though not well implemented > either at first or with my rewrite, maybe no good way > to do it. I assigned that ticket to you. Perhaps it's easy to fix; please have a look. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sat Aug 8 19:00:17 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 8 Aug 2009 17:00:17 +0000 Subject: [M3devel] trouble with RC2 -- maybe with hudson? In-Reply-To: References: <20090808114619.GA3806@topoi.pooq.com> <20090808135430.1iy8os9eogwwcss0@mail.elegosoft.com> Message-ID: Olaf you are missing the flag some places maybe? You can see it working sometimes but not others. Just make it the default and only behavior? It is not specific to m3-comm-tcp. I'll poke around more. udson at xlin2:~$ uname -a Linux xlin2 2.6.18-6-686 #1 SMP Tue May 5 00:40:20 UTC 2009 i686 GNU/Linux hudson at xlin2:~$ pwd /home/hudson hudson at xlin2:~$ grep make_dir `find . | grep m3-comm/tcp/LINUXLIBC6/.M3SHIP` ./workspace/cm3-lastok-build-LINUXLIBC6/cm3/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/work/cm3-inst/xlin2/current--lastok-build//pkg/tcp/LINUXLIBC6") ./workspace/cm3-lastok-build-LINUXLIBC6/cm3/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/work/cm3-inst/xlin2/current--lastok-build//lib") ./workspace/cm3-lastok-build-LINUXLIBC6/cm3/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/work/cm3-inst/xlin2/current--lastok-build//pkg/tcp/src/POSIX") ./workspace/cm3-lastok-build-LINUXLIBC6/cm3/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/work/cm3-inst/xlin2/current--lastok-build//pkg/tcp/src/common") ./workspace/cm3-test-install-LINUXLIBC6/work/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir(PKG_INSTALL & "/tcp/" & TARGET) ./workspace/cm3-test-install-LINUXLIBC6/work/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir(LIB_INSTALL) ./workspace/cm3-test-install-LINUXLIBC6/work/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/tmp/cm3/bin/../lib") ./workspace/cm3-test-install-LINUXLIBC6/work/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir(PKG_INSTALL & "/tcp/src/POSIX") ./workspace/cm3-test-install-LINUXLIBC6/work/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir(PKG_INSTALL & "/tcp/src/common") ./workspace/cm3-test-all-pkgs-LINUXLIBC6/cm3/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/work/cm3-inst/xlin2/last-ok//pkg/tcp/LINUXLIBC6") ./workspace/cm3-test-all-pkgs-LINUXLIBC6/cm3/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/work/cm3-inst/xlin2/last-ok//lib") ./workspace/cm3-test-all-pkgs-LINUXLIBC6/cm3/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/work/cm3-inst/xlin2/last-ok//pkg/tcp/src/POSIX") ./workspace/cm3-test-all-pkgs-LINUXLIBC6/cm3/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/work/cm3-inst/xlin2/last-ok//pkg/tcp/src/common") - Jay > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Date: Sat, 8 Aug 2009 13:03:38 +0000 > Subject: Re: [M3devel] trouble with RC2 -- maybe with hudson? > > > I rewrote the m3ship-no-resolve stuff some weeks ago. > There must be a hole in my rewrite. > The feature is very nice, though not well implemented > either at first or with my rewrite, maybe no good way > to do it. > > > - Jay > > > > ---------------------------------------- > > Date: Sat, 8 Aug 2009 13:54:30 +0200 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] trouble with RC2 -- maybe with hudson? > > > > Please create a ticket for that and attach the contents of file > > "/home/hendrik/cm3/gui/m3-comm/tcp/LINUXLIBC6/.M3SHIP"/ > > > > I'll have a look at it ASAP. > > > > Olaf > > > > Quoting hendrik at topoi.pooq.com: > > > >> Installing cm3-bin-core-LINUXLIBC6-d5.8.2-RC2.tgz on my 32-bit > >> intel Debian squeeze laptop went fine. > >> > >> But when I tried cm3-bin-core-LINUXLIBC6-d5.8.2-RC2.tgz (downloaded a > >> few days ago) I got: > >> > >> hendrik at notlookedfor:~/cm3$ mkdir gui > >> hendrik at notlookedfor:~/cm3$ cd gui > >> hendrik at notlookedfor:~/cm3/gui$ tar -zxf > >> ../../Desktop/cm3-bin-ws-gui-LINUXLIBC6-d5.8.2-RC2.tgz > >> hendrik at notlookedfor:~/cm3/gui$ ls > >> collection-gui.html install.sh m3-comm m3-tools m3-ui m3-win > >> setup.cmd > >> hendrik at notlookedfor:~/cm3/gui$ ./install.sh > >> --- shipping from LINUXLIBC6 --- > >> > >> --- shipping from LINUXLIBC6 --- > >> > >> . => /usr/local/cm3/pkg/tcp/LINUXLIBC6 > >> .M3EXPORTS > >> . => /usr/local/cm3/lib > >> libm3tcp.so.5 > >> "/home/hendrik/cm3/gui/m3-comm/tcp/LINUXLIBC6/.M3SHIP", line 6: quake > >> runtime error: unable to create directory "/home/hudson": errno=13 > >> > >> --procedure-- -line- -file--- > >> make_dir -- > >> 6 > >> /home/hendrik/cm3/gui/m3-comm/tcp/LINUXLIBC6/.M3SHIP > >> > >> Fatal Error: package build failed > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> hendrik at notlookedfor:~/cm3/gui$ exit > >> > >> > >> > >> It looks to me as if hudson has gotten in the way. > >> > >> -- hendrik > >> > >> > > > > > > > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Aug 8 19:33:48 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 8 Aug 2009 17:33:48 +0000 Subject: [M3devel] trouble with RC2 -- maybe with hudson? In-Reply-To: References: <20090808114619.GA3806@topoi.pooq.com> <20090808135430.1iy8os9eogwwcss0@mail.elegosoft.com> Message-ID: The various make-dist console outputs show a literal $RARGS, not the expected switches. -10 for sh? - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Date: Sat, 8 Aug 2009 17:00:17 +0000 Subject: Re: [M3devel] trouble with RC2 -- maybe with hudson? Olaf you are missing the flag some places maybe? You can see it working sometimes but not others. Just make it the default and only behavior? It is not specific to m3-comm-tcp. I'll poke around more. udson at xlin2:~$ uname -a Linux xlin2 2.6.18-6-686 #1 SMP Tue May 5 00:40:20 UTC 2009 i686 GNU/Linux hudson at xlin2:~$ pwd /home/hudson hudson at xlin2:~$ grep make_dir `find . | grep m3-comm/tcp/LINUXLIBC6/.M3SHIP` ./workspace/cm3-lastok-build-LINUXLIBC6/cm3/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/work/cm3-inst/xlin2/current--lastok-build//pkg/tcp/LINUXLIBC6") ./workspace/cm3-lastok-build-LINUXLIBC6/cm3/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/work/cm3-inst/xlin2/current--lastok-build//lib") ./workspace/cm3-lastok-build-LINUXLIBC6/cm3/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/work/cm3-inst/xlin2/current--lastok-build//pkg/tcp/src/POSIX") ./workspace/cm3-lastok-build-LINUXLIBC6/cm3/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/work/cm3-inst/xlin2/current--lastok-build//pkg/tcp/src/common") ./workspace/cm3-test-install-LINUXLIBC6/work/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir(PKG_INSTALL & "/tcp/" & TARGET) ./workspace/cm3-test-install-LINUXLIBC6/work/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir(LIB_INSTALL) ./workspace/cm3-test-install-LINUXLIBC6/work/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/tmp/cm3/bin/../lib") ./workspace/cm3-test-install-LINUXLIBC6/work/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir(PKG_INSTALL & "/tcp/src/POSIX") ./workspace/cm3-test-install-LINUXLIBC6/work/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir(PKG_INSTALL & "/tcp/src/common") ./workspace/cm3-test-all-pkgs-LINUXLIBC6/cm3/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/work/cm3-inst/xlin2/last-ok//pkg/tcp/LINUXLIBC6") ./workspace/cm3-test-all-pkgs-LINUXLIBC6/cm3/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/work/cm3-inst/xlin2/last-ok//lib") ./workspace/cm3-test-all-pkgs-LINUXLIBC6/cm3/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/work/cm3-inst/xlin2/last-ok//pkg/tcp/src/POSIX") ./workspace/cm3-test-all-pkgs-LINUXLIBC6/cm3/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/work/cm3-inst/xlin2/last-ok//pkg/tcp/src/common") - Jay > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Date: Sat, 8 Aug 2009 13:03:38 +0000 > Subject: Re: [M3devel] trouble with RC2 -- maybe with hudson? > > > I rewrote the m3ship-no-resolve stuff some weeks ago. > There must be a hole in my rewrite. > The feature is very nice, though not well implemented > either at first or with my rewrite, maybe no good way > to do it. > > > - Jay > > > > ---------------------------------------- > > Date: Sat, 8 Aug 2009 13:54:30 +0200 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] trouble with RC2 -- maybe with hudson? > > > > Please create a ticket for that and attach the contents of file > > "/home/hendrik/cm3/gui/m3-comm/tcp/LINUXLIBC6/.M3SHIP"/ > > > > I'll have a look at it ASAP. > > > > Olaf > > > > Quoting hendrik at topoi.pooq.com: > > > >> Installing cm3-bin-core-LINUXLIBC6-d5.8.2-RC2.tgz on my 32-bit > >> intel Debian squeeze laptop went fine. > >> > >> But when I tried cm3-bin-core-LINUXLIBC6-d5.8.2-RC2.tgz (downloaded a > >> few days ago) I got: > >> > >> hendrik at notlookedfor:~/cm3$ mkdir gui > >> hendrik at notlookedfor:~/cm3$ cd gui > >> hendrik at notlookedfor:~/cm3/gui$ tar -zxf > >> ../../Desktop/cm3-bin-ws-gui-LINUXLIBC6-d5.8.2-RC2.tgz > >> hendrik at notlookedfor:~/cm3/gui$ ls > >> collection-gui.html install.sh m3-comm m3-tools m3-ui m3-win > >> setup.cmd > >> hendrik at notlookedfor:~/cm3/gui$ ./install.sh > >> --- shipping from LINUXLIBC6 --- > >> > >> --- shipping from LINUXLIBC6 --- > >> > >> . => /usr/local/cm3/pkg/tcp/LINUXLIBC6 > >> .M3EXPORTS > >> . => /usr/local/cm3/lib > >> libm3tcp.so.5 > >> "/home/hendrik/cm3/gui/m3-comm/tcp/LINUXLIBC6/.M3SHIP", line 6: quake > >> runtime error: unable to create directory "/home/hudson": errno=13 > >> > >> --procedure-- -line- -file--- > >> make_dir -- > >> 6 > >> /home/hendrik/cm3/gui/m3-comm/tcp/LINUXLIBC6/.M3SHIP > >> > >> Fatal Error: package build failed > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> hendrik at notlookedfor:~/cm3/gui$ exit > >> > >> > >> > >> It looks to me as if hudson has gotten in the way. > >> > >> -- hendrik > >> > >> > > > > > > > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Aug 8 22:12:20 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 8 Aug 2009 20:12:20 +0000 Subject: [M3devel] lots of problems in gui on AMD64_DARWIN? Message-ID: Not all gui apps fail. Some 32bit-isms in TimeStamp.m3. gdb doesn't seem to be working at all for me, arg. jbook2:bin jay$ ./mentor *** *** runtime error: *** An enumeration or subrange value was out of range. *** file "../src/uid/Common/TimeStamp.m3", line 63 *** Abort trap jbook2:bin jay$ ./formsedit *** *** runtime error: *** An enumeration or subrange value was out of range. *** file "../src/uid/Common/TimeStamp.m3", line 63 *** jbook2:bin jay$ ./BadBricks *** *** runtime error: *** An enumeration or subrange value was out of range. *** file "../src/uid/Common/TimeStamp.m3", line 63 *** Abort trap book2:bin jay$ ./Calculator *** *** runtime error: *** An enumeration or subrange value was out of range. *** file "../src/uid/Common/TimeStamp.m3", line 63 *** -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Aug 8 22:17:09 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 8 Aug 2009 20:17:09 +0000 Subject: [M3devel] make-dist vs. $CM3_TARGET/AMD64_DARWIN Message-ID: I tried to make AMD64_DARWIN distribution with: PATH=/cm3.amd64/bin:$PATH CM3CVSUSER=jkrell SHIPRC=y CM3_TARGET=AMD64_DARWIN ./make-dist.sh I got a bunch of files with I386_DARWIN in their names. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Aug 8 22:44:18 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 08 Aug 2009 22:44:18 +0200 Subject: [M3devel] make-dist vs. $CM3_TARGET/AMD64_DARWIN In-Reply-To: References: Message-ID: <20090808224418.oel9aad5w8w8w0wc@mail.elegosoft.com> Quoting Jay K : > I tried to make AMD64_DARWIN distribution with: > > PATH=/cm3.amd64/bin:$PATH CM3CVSUSER=jkrell SHIPRC=y > CM3_TARGET=AMD64_DARWIN ./make-dist.sh > > I got a bunch of files with I386_DARWIN in their names. Have you added support for all those new AMD64 targets to sysinfo.sh? I assume you expect CM3_TARGET to override everything, but I'm not sure that it will work everywhere. You should trace with set -x. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sat Aug 8 22:48:24 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 8 Aug 2009 20:48:24 +0000 Subject: [M3devel] make-dist vs. $CM3_TARGET/AMD64_DARWIN In-Reply-To: <20090808224418.oel9aad5w8w8w0wc@mail.elegosoft.com> References: <20090808224418.oel9aad5w8w8w0wc@mail.elegosoft.com> Message-ID: I added it to python/pylib.py and I expected CM3_TARGET to override. The code in python/pylib.py: elif UName.startswith("darwin"): # detect the m3 platform (Darwin runs on ppc32, ppc64, x86, amd64) if UNameArchP == "powerpc": Host = "PPC_DARWIN" elif re.match("i[3456]86", UNameArchP): if os.popen("sysctl hw.cpu64bit_capable").read() == "hw.cpu64bit_capable: 1\n": Host = "AMD64_DARWIN" else: Host = "I386_DARWIN" elif UNameArchP == "x86-64": Host = "AMD64_DARWIN" elif UNameArchP == "powerpc64": Host = "PPC64_DARWIN" That was mostly guessing, a few things in sysctl report 64bit stuff, but nothing in uname seems to indicate it. I guess I'll update sysinfo.sh and defs.sh..yuck. I opened tickets. - Jay > Date: Sat, 8 Aug 2009 22:44:18 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] make-dist vs. $CM3_TARGET/AMD64_DARWIN > > Quoting Jay K : > > > I tried to make AMD64_DARWIN distribution with: > > > > PATH=/cm3.amd64/bin:$PATH CM3CVSUSER=jkrell SHIPRC=y > > CM3_TARGET=AMD64_DARWIN ./make-dist.sh > > > > I got a bunch of files with I386_DARWIN in their names. > > Have you added support for all those new AMD64 targets to sysinfo.sh? > I assume you expect CM3_TARGET to override everything, but I'm not sure > that it will work everywhere. > > You should trace with set -x. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Aug 8 22:54:49 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 08 Aug 2009 22:54:49 +0200 Subject: [M3devel] trouble with RC2 -- maybe with hudson? In-Reply-To: References: <20090808114619.GA3806@topoi.pooq.com> <20090808135430.1iy8os9eogwwcss0@mail.elegosoft.com> Message-ID: <20090808225449.q4lgftjzpcsso8os@mail.elegosoft.com> Quoting Jay K : > The various make-dist console outputs show a literal $RARGS, not the > expected switches. > -10 for sh? Jay, the .M3SHIP file mostly looks OK, i.e. the expected variables are found, which would not be the case if the parameters aren't passed correctly. make_dir(PKG_INSTALL & "/tcp/" & TARGET) install_file(".M3EXPORTS", PKG_INSTALL & "/tcp/" & TARGET, "0664") make_dir(LIB_INSTALL) install_file("libm3tcp.so.5", LIB_INSTALL, "0775") symbolic_link_file(PKG_INSTALL & "/tcp/" & TARGET & "/libm3tcp.a", LIB_INSTALL & "/libm3tcp.a") make_dir("/home/hudson/tmp/cm3/bin/../lib") symbolic_link_file("libm3tcp.so.5", "/home/hudson/tmp/cm3/bin/../lib/libm3tcp.so") symbolic_link_file(LIB_INSTALL & "/libm3tcp.so.5", PKG_INSTALL & "/tcp/" & TARGET & "/libm3tcp.so") symbolic_link_file(LIB_INSTALL & "/libm3tcp.so.5", PKG_INSTALL & "/tcp/" & TARGET & "/libm3tcp.so.5") install_file("libm3tcp.a", PKG_INSTALL & "/tcp/" & TARGET, "0664") install_file("libm3tcp.m3x", PKG_INSTALL & "/tcp/" & TARGET, "0664") install_file(".M3WEB", PKG_INSTALL & "/tcp/" & TARGET, "0664") make_dir(PKG_INSTALL & "/tcp/src/POSIX") install_file("../src/POSIX/TCP.m3", PKG_INSTALL & "/tcp/src/POSIX", "0664") install_file("../src/POSIX/TCPPosix.i3", PKG_INSTALL & "/tcp/src/POSIX", "0664") install_file("../src/POSIX/Herrno.i3", PKG_INSTALL & "/tcp/src/POSIX", "0664") install_file("../src/POSIX/HerrnoC.c", PKG_INSTALL & "/tcp/src/POSIX", "0664") install_file("../src/POSIX/IP.m3", PKG_INSTALL & "/tcp/src/POSIX", "0664") install_file("../src/POSIX/IPErrorPosix.m3", PKG_INSTALL & "/tcp/src/POSIX", "0664") install_file("../src/POSIX/TCPExtras.m3", PKG_INSTALL & "/tcp/src/POSIX", "0664") install_file("../src/POSIX/TCPPeer.m3", PKG_INSTALL & "/tcp/src/POSIX", "0664") I had tested that with several different packages some weeks ago. I still think you overlooked some case when applying your changes. Can you please check again? We probably have to rebuild lots of packages... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sat Aug 8 23:15:48 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 8 Aug 2009 21:15:48 +0000 Subject: [M3devel] trouble with RC2 -- maybe with hudson? In-Reply-To: <20090808225449.q4lgftjzpcsso8os@mail.elegosoft.com> References: <20090808114619.GA3806@topoi.pooq.com> <20090808135430.1iy8os9eogwwcss0@mail.elegosoft.com> <20090808225449.q4lgftjzpcsso8os@mail.elegosoft.com> Message-ID: These contain no binaries at all, just source: m3-bin-ws-anim-LINUXLIBC6-d5.8.2-RC2.tgz m3-bin-ws-cvsup-LINUXLIBC6-d5.8.2-RC2.tgz intentional? I see. You are right: cm3-bin-ws-core-LINUXLIBC6-d5.8.2-RC2.tgz jbook2:t jay$ more m3-tools/m3bundle/LINUXLIBC6/.M3SHIP make_dir(PKG_INSTALL & "/m3bundle/" & TARGET) install_file(".M3EXPORTS", PKG_INSTALL & "/m3bundle/" & TARGET, "0664" ) make_dir("/home/hudson/tmp/cm3/bin") install_file("m3bundle", "/home/hudson/tmp/cm3/bin", "0775") install_file(".M3WEB", PKG_INSTALL & "/m3bundle/" & TARGET, "0664") m - Jay > Date: Sat, 8 Aug 2009 22:54:49 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] trouble with RC2 -- maybe with hudson? > > Quoting Jay K : > > > The various make-dist console outputs show a literal $RARGS, not the > > expected switches. > > -10 for sh? > > Jay, the .M3SHIP file mostly looks OK, i.e. the expected variables > are found, which would not be the case if the parameters aren't > passed correctly. > > make_dir(PKG_INSTALL & "/tcp/" & TARGET) > install_file(".M3EXPORTS", PKG_INSTALL & "/tcp/" & TARGET, "0664") > make_dir(LIB_INSTALL) > install_file("libm3tcp.so.5", LIB_INSTALL, "0775") > symbolic_link_file(PKG_INSTALL & "/tcp/" & TARGET & "/libm3tcp.a", > LIB_INSTALL & "/libm3tcp.a") > make_dir("/home/hudson/tmp/cm3/bin/../lib") > symbolic_link_file("libm3tcp.so.5", > "/home/hudson/tmp/cm3/bin/../lib/libm3tcp.so") > symbolic_link_file(LIB_INSTALL & "/libm3tcp.so.5", PKG_INSTALL & > "/tcp/" & TARGET & "/libm3tcp.so") > symbolic_link_file(LIB_INSTALL & "/libm3tcp.so.5", PKG_INSTALL & > "/tcp/" & TARGET & "/libm3tcp.so.5") > install_file("libm3tcp.a", PKG_INSTALL & "/tcp/" & TARGET, "0664") > install_file("libm3tcp.m3x", PKG_INSTALL & "/tcp/" & TARGET, "0664") > install_file(".M3WEB", PKG_INSTALL & "/tcp/" & TARGET, "0664") > make_dir(PKG_INSTALL & "/tcp/src/POSIX") > install_file("../src/POSIX/TCP.m3", PKG_INSTALL & "/tcp/src/POSIX", "0664") > install_file("../src/POSIX/TCPPosix.i3", PKG_INSTALL & > "/tcp/src/POSIX", "0664") > install_file("../src/POSIX/Herrno.i3", PKG_INSTALL & "/tcp/src/POSIX", "0664") > install_file("../src/POSIX/HerrnoC.c", PKG_INSTALL & "/tcp/src/POSIX", "0664") > install_file("../src/POSIX/IP.m3", PKG_INSTALL & "/tcp/src/POSIX", "0664") > install_file("../src/POSIX/IPErrorPosix.m3", PKG_INSTALL & > "/tcp/src/POSIX", "0664") > install_file("../src/POSIX/TCPExtras.m3", PKG_INSTALL & > "/tcp/src/POSIX", "0664") > install_file("../src/POSIX/TCPPeer.m3", PKG_INSTALL & > "/tcp/src/POSIX", "0664") > > I had tested that with several different packages some weeks ago. > > I still think you overlooked some case when applying your changes. > > Can you please check again? We probably have to rebuild lots of > packages... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Aug 8 23:21:34 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 08 Aug 2009 23:21:34 +0200 Subject: [M3devel] trouble with RC2 -- maybe with hudson? In-Reply-To: References: <20090808114619.GA3806@topoi.pooq.com> <20090808135430.1iy8os9eogwwcss0@mail.elegosoft.com> Message-ID: <20090808232134.abs0ft0zgo4ocssk@mail.elegosoft.com> Quoting Jay K : > The various make-dist console outputs show a literal $RARGS, not the > expected switches. > -10 for sh? I've just tested the -no-m3ship-resolution switch on the current cm3 on birch. It mostly works, but some shipping destinations do not use the variable names. So it's nothing to do with shell incompatibilities, but with our programming mistakes. It may be that such paths containing // (perfectly legal in POSIX) and .../bin/../lib/... are the culprit. I should not have relied on the automatic installation testing by hudson; everything worked there, as it is the same user who built the packages. To find such errors, we need to test with different users... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sat Aug 8 23:31:23 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 8 Aug 2009 21:31:23 +0000 Subject: [M3devel] trouble with RC2 -- maybe with hudson? In-Reply-To: <20090808232134.abs0ft0zgo4ocssk@mail.elegosoft.com> References: <20090808114619.GA3806@topoi.pooq.com> <20090808135430.1iy8os9eogwwcss0@mail.elegosoft.com> <20090808232134.abs0ft0zgo4ocssk@mail.elegosoft.com> Message-ID: It's not that. dot and dotdot get smushed out. What does // mean? My code changes any // to just /, except at the start of a path. That is what GetFullPathname on Windows with backward slashes. I was missing BIN_INSTALL and worst case fallback INSTALL_ROOT. - Jay > Date: Sat, 8 Aug 2009 23:21:34 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] trouble with RC2 -- maybe with hudson? > > Quoting Jay K : > > > The various make-dist console outputs show a literal $RARGS, not the > > expected switches. > > -10 for sh? > > I've just tested the -no-m3ship-resolution switch on the current > cm3 on birch. It mostly works, but some shipping destinations do not > use the variable names. So it's nothing to do with shell incompatibilities, > but with our programming mistakes. > > It may be that such paths containing // (perfectly legal in POSIX) > and .../bin/../lib/... are the culprit. > > I should not have relied on the automatic installation testing by hudson; > everything worked there, as it is the same user who built the > packages. To find such errors, we need to test with different > users... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Aug 8 23:40:38 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 08 Aug 2009 23:40:38 +0200 Subject: [M3devel] trouble with RC2 -- maybe with hudson? In-Reply-To: References: <20090808114619.GA3806@topoi.pooq.com> <20090808135430.1iy8os9eogwwcss0@mail.elegosoft.com> <20090808232134.abs0ft0zgo4ocssk@mail.elegosoft.com> Message-ID: <20090808234038.2u68sn81cs04gc40@mail.elegosoft.com> Quoting Jay K : > It's not that. dot and dotdot get smushed out. > What does // mean? > My code changes any // to just /, except at the start of a path. > That is what GetFullPathname on Windows with backward slashes. That's OK. > I was missing BIN_INSTALL and worst case fallback INSTALL_ROOT. So we may have to build RC3 sooner than intended. There's always the workaround to just call cm3 -build before shipping, but many of the install.sh scripts will fail for RC2. Can you check in a fix to the release branch? We may be able to build new packages tomorrow evening or at the start of the week. Olaf > - Jay > >> Date: Sat, 8 Aug 2009 23:21:34 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] trouble with RC2 -- maybe with hudson? >> >> Quoting Jay K : >> >> > The various make-dist console outputs show a literal $RARGS, not the >> > expected switches. >> > -10 for sh? >> >> I've just tested the -no-m3ship-resolution switch on the current >> cm3 on birch. It mostly works, but some shipping destinations do not >> use the variable names. So it's nothing to do with shell incompatibilities, >> but with our programming mistakes. >> >> It may be that such paths containing // (perfectly legal in POSIX) >> and .../bin/../lib/... are the culprit. >> >> I should not have relied on the automatic installation testing by hudson; >> everything worked there, as it is the same user who built the >> packages. To find such errors, we need to test with different >> users... >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sun Aug 9 01:58:25 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Sat, 8 Aug 2009 16:58:25 -0700 Subject: [M3devel] make-dist vs. $CM3_TARGET/AMD64_DARWIN In-Reply-To: <20090808224418.oel9aad5w8w8w0wc@mail.elegosoft.com> References: <20090808224418.oel9aad5w8w8w0wc@mail.elegosoft.com> Message-ID: <25BD6284-E323-4C6D-837C-E853A1B15119@hotmail.com> Ps amd64_Darwin is not new. It was the first Amd64 target. - Jay (phone) On Aug 8, 2009, at 1:44 PM, Olaf Wagner wrote: > Quoting Jay K : > >> I tried to make AMD64_DARWIN distribution with: >> >> PATH=/cm3.amd64/bin:$PATH CM3CVSUSER=jkrell SHIPRC=y >> CM3_TARGET=AMD64_DARWIN ./make-dist.sh >> >> I got a bunch of files with I386_DARWIN in their names. > > Have you added support for all those new AMD64 targets to sysinfo.sh? > I assume you expect CM3_TARGET to override everything, but I'm not > sure > that it will work everywhere. > > You should trace with set -x. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ > any > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be > rlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > From wagner at elegosoft.com Mon Aug 10 00:32:36 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 10 Aug 2009 00:32:36 +0200 Subject: [M3devel] make-dist vs. $CM3_TARGET/AMD64_DARWIN In-Reply-To: <25BD6284-E323-4C6D-837C-E853A1B15119@hotmail.com> References: <20090808224418.oel9aad5w8w8w0wc@mail.elegosoft.com> <25BD6284-E323-4C6D-837C-E853A1B15119@hotmail.com> Message-ID: <20090810003236.8v14j0kpccosscow@mail.elegosoft.com> Quoting jay.krell at cornell.edu: > Ps amd64_Darwin is not new. It was the first Amd64 target. Right, I was confused here. But I guess it was never integrated into the sysinfo.sh script nonetheless. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Aug 10 00:56:32 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 9 Aug 2009 22:56:32 +0000 Subject: [M3devel] caltech-parser m3overrides? Message-ID: Anyone know about all (not all, many) these packages in caltech-parser m3overrides? They no longer exist? We didn't get all the source? override("prsparse",TOP) override("magic",TOP) override("magicextras",TOP) override("cit_common",TOP) override("cit_util",TOP) override("bdd",TOP) override("cptr",TOP) override("bool",TOP) override("boxes",TOP) override("simplegrid",TOP) override("router",TOP) override("term",TOP) override("m3-3",TOP) override("paneman",TOP) override("parserlib",TOP & SL & "parserlib") override("ktoklib",TOP & SL & "parserlib") override("cit_parse",TOP) override("drawcontext",TOP) override("dcpane",TOP & SL & "drawcontext") override("tasks",TOP) override("matrix",TOP) override("layout",TOP) From jay.krell at cornell.edu Mon Aug 10 12:53:43 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 10 Aug 2009 10:53:43 +0000 Subject: [M3devel] proposal for next release: moving some config file content into cm3 Message-ID: Native builds are the usual. Cross builds are rarer. It is dumb for config files to even specify TARGET. As well as thing I recently added: TARGET_OS, TARGET_ENDIAN. It should default to "HOST". Furthermore, a command line option rather than editing/replacing config file should achieve a cross build. One (or more?) of: cm3 I386_LINUX cm3 -target I386_LINUX cm3 -target:I386_LINUX cm3 -target=I386_LINUX cm3 --target I386_LINUX cm3 --target:I386_LINUX cm3 --target=I386_LINUX cm3 -DTARGET=I386_LINUX I like the first, but perhaps it is too implicit/sleazy. User should have to say what the random freestanding platform name means? pylib.py does support this. There is much precedent for the last, as cm3 already supports -D. I have found that -D tends to be processed too late to be as useful as it could/should be. We should probably fix this. Any changes along these lines would "by default" (if not done along with other changes) break other m3quake/m3config users -- m3tohtml, cm3ide, etc. The code in cm3 that "predefines" stuff, such "HOST", such as defaulting TARGET, shall move into the m3quake package, but not be run "automatically". m3quake shall remain by default ignorant of its usual use in support of compiling Modula-3 and remain by default "just a scripting language". Something like m3-sys/m3quake/M3Predefines.i3 m3-sys/m3quake/M3Predefines.Init Should they start with "Q" or M3"? Should cm3 be split up into cm3lib and cm3exe and these would be m3-sys/cm3lib/M3Predefines? m3quake users who are attempting to act "like the compiler" shall call M3Predefines.Init(). Furthermore, the following should all be "correctly default" and therefore moved out of config files: INSTALL_ROOT (based on cm3's location) BIN_INSTALL LIB_INSTALL MAN_INSTALL PKG_INSTALL USE_ROOT LIB_USE PKG_USE etc. (so much for a precise spec. :) ) The config file shall still be able to override this. As well as the command line. I think. There is some order ambiguity. Normally LIB_USE defaults to LIB_INSTALL, etc. If the command line overrides LIB_INSTALL, should that also change LIB_USE? Perhaps these are not changable on the command line. Does anyone really ever vary them? Sure, people install to custom place, but do they all not follow directly from cm3.exe location? Well, I sometimes run unshipped cm3. That is something to consider. cm3 should perhaps even move to an archictecture-specific directory. /cm3/bin/I386_LINUX/cm3 However, aside, I've given up on that idea. While the pkg store has all these nice target-specific directories already, instead of solving the problem for bin and lib, and then having savings due to not duplicating "man", I've just been going with separate entire roots. On a Mac for example, I'd have /cm3.x86 /cm3.amd64 /cm3.ppc /cm3.ppc64 (hypothetical) or on Windows: /cm3 ("native") /cm3.cygwin /cm3.interix The "man" directory would be wastefully duplicated. For the rare user of unshipped cm3 to have to say -DINSTALL_ROOT=/usr/local/bin/cm3 doesn't seem terrible. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Aug 10 14:13:54 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 10 Aug 2009 14:13:54 +0200 Subject: [M3devel] proposal for next release: moving some config file content into cm3 In-Reply-To: References: Message-ID: <20090810141354.9co7e8rxss8g8o48@mail.elegosoft.com> Quoting Jay K : > Furthermore, the following should all be "correctly default" > and therefore moved out of config files: > INSTALL_ROOT (based on cm3's location) > BIN_INSTALL > LIB_INSTALL > MAN_INSTALL > PKG_INSTALL > USE_ROOT > LIB_USE > PKG_USE > > etc. (so much for a precise spec. :) ) > > The config file shall still be able to override this. > As well as the command line. I think. If these cannot be overriden by the config files, system specific installations not adhering to the standard layout won't be possible. > There is some order ambiguity. > Normally LIB_USE defaults to LIB_INSTALL, etc. > If the command line overrides LIB_INSTALL, should > that also change LIB_USE? > > Perhaps these are not changable on the command line. > Does anyone really ever vary them? > Sure, people install to custom place, but > do they all not follow directly from cm3.exe location? > > Well, I sometimes run unshipped cm3. > That is something to consider. > cm3 should perhaps even move to an archictecture-specific directory. > /cm3/bin/I386_LINUX/cm3 > > However, aside, I've given up on that idea. Why? Too complex? Is there some strong argument against it? (I don't remember offhand.) > While the pkg store has all these nice target-specific directories already, > instead of solving the problem for bin and lib, and then having > savings due to not duplicating "man", I've just been > going with separate entire roots. > > On a Mac for example, I'd have > /cm3.x86 > /cm3.amd64 > /cm3.ppc > /cm3.ppc64 (hypothetical) > > or on Windows: > /cm3 ("native") > /cm3.cygwin > /cm3.interix > > The "man" directory would be wastefully duplicated. > > For the rare user of unshipped cm3 to have to say > -DINSTALL_ROOT=/usr/local/bin/cm3 > > doesn't seem terrible. -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Mon Aug 10 14:35:23 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 10 Aug 2009 14:35:23 +0200 Subject: [M3devel] CM3 Hudson Config in CVS Message-ID: <20090810143523.ntayisdvpc4wsgc0@mail.elegosoft.com> I've added a small script that saves all the XML config files of the various Hudson jobs for CM3 into birch's CVS repository below /usr/cvs/hudson-config. It should be accessible for all M3 users, but should be treated as read-only. It is only there to record the history and for backup purposes. It is still very dumb and needs to be improved, so that only actual changes get imported and tagged. The corresponding Hudson job is http://hudson.modula3.com:8080/view/www/job/save-xml-config/ Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Aug 10 19:17:12 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 10 Aug 2009 17:17:12 +0000 Subject: [M3devel] testing RC2. In-Reply-To: <6A0491CD-BC10-49BB-8100-3137A406DBE7@darko.org> References: <20090804002754.GF25621@topoi.pooq.com> <1C5F772D-930B-472B-A83B-32DEC364D2FA@hotmail.com> <20090804105835.vs1925r2kg480ccg@mail.elegosoft.com> <6A0491CD-BC10-49BB-8100-3137A406DBE7@darko.org> Message-ID: My attempt to do an AMD64_DARWIN build messed up the I386_DARWIN files. I386_DARWIN needs to be rebuilt, preferably this time via Hudson. Please give it a day or two at least. - Jay ---------------------------------------- > CC: m3devel at elegosoft.com > From: darko at darko.org > To: jay.krell at cornell.edu > Subject: Re: [M3devel] testing RC2. > Date: Mon, 10 Aug 2009 17:24:53 +0200 > > Just looking into a Mac installer but found the RC2 "optional" > archives seem to have AMD64_DARWIN libraries instead of I386_DARWIN. > I'm looking in http://www.opencm3.net/releng/download.html > > > On 04/08/2009, at 1:49 PM, Jay K wrote: > >> >>> build some missing installation packages (for I386_DARWIN for >>> example) >> >> >> I have a new computer arriving roughly Friday on which I can setup >> near arbitrary x86/AMD64 VMs, as well as doing native I386_DARWIN >> and AMD64_DARWIN. AMD64_FREEBSD is also missing for example. >> Tony should also be able to do {I386,AMD64}_DARWIN. >> >> >> - Jay >> >> >> >> ---------------------------------------- >>> Date: Tue, 4 Aug 2009 10:58:35 +0200 >>> From: wagner at elegosoft.com >>> To: m3devel at elegosoft.com >>> Subject: Re: [M3devel] testing RC2. >>> >>> Quoting jay.krell at cornell.edu: >>> >>>> Wikipedia: Aren't you subverting release manager Olaf? Not ready for >>>> exposure beyond m3devel? >>> >>> I just moved the date for RC2 another week :-/ Too many things still >>> to be done. See >>> >>> https://projects.elego.de/cm3/milestone/CM3%20Release%205.8%20RC2 >>> >>> We need >>> >>> o to improve the WWW presentation (there were suggestions from >>> Peter Eiserloh and others but no concrete changes/commits AFAIK) >>> >>> o build some missing installation packages (for I386_DARWIN for >>> example) >>> >>> o automate some installation tests (next thing I'll do) >>> >>> o get some feedback from manual tests >>> >>> If there are no commits to the web pages till Wednesday, I'll make >>> some small adaptions there to be ready for RC2 then. >>> >>> Olaf >>> >>>> - Jay (phone) >>>> >>>> On Aug 3, 2009, at 5:27 PM, hendrik at topoi.pooq.com wrote: >>>> >>>>> Now that I've updated the wikipedia entry, it's easier to find >>>>> the RC2 >>>>> downloads page. >>>>> >>>>> How can I update the other places that are easy to find on the >>>>> google? >>>>> Specifically, >>>>> the Modula 3 resource page, www.modula3.org/ >>>>> Modula-3 Frequently Asked Questions (FAQ), >>>>> www.faqs.org/faqs/Modula-3-faq/ >>>>> >>>>> I'll soon be trying another installation fromscratch, using RC2, >>>>> and I'll let you know how it went. >>>>> >>>>> -- hendrik >>>>> >>>>> >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>> 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>> Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> > From hosking at cs.purdue.edu Mon Aug 10 20:19:38 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 10 Aug 2009 14:19:38 -0400 Subject: [M3devel] lots of problems in gui on AMD64_DARWIN? In-Reply-To: References: Message-ID: <224E3743-8052-4D90-B49E-BC7CFD01FFF0@cs.purdue.edu> I believe this code used to work on 64-bit ALPHA_OSF, unless something changed since then. Just looking at it, it claims to be 64-bit safe. On 8 Aug 2009, at 16:12, Jay K wrote: > Not all gui apps fail. > Some 32bit-isms in TimeStamp.m3. > gdb doesn't seem to be working at all for me, arg. > > jbook2:bin jay$ ./mentor > > > *** > *** runtime error: > *** An enumeration or subrange value was out of range. > *** file "../src/uid/Common/TimeStamp.m3", line 63 > *** > > Abort trap > > jbook2:bin jay$ ./formsedit > > > *** > *** runtime error: > *** An enumeration or subrange value was out of range. > *** file "../src/uid/Common/TimeStamp.m3", line 63 > *** > > > jbook2:bin jay$ ./BadBricks > > > *** > *** runtime error: > *** An enumeration or subrange value was out of range. > *** file "../src/uid/Common/TimeStamp.m3", line 63 > *** > > Abort trap > > book2:bin jay$ ./Calculator > > > *** > *** runtime error: > *** An enumeration or subrange value was out of range. > *** file "../src/uid/Common/TimeStamp.m3", line 63 > *** > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Aug 10 20:37:26 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 10 Aug 2009 14:37:26 -0400 Subject: [M3devel] lots of problems in gui on AMD64_DARWIN? In-Reply-To: References: Message-ID: <54CE76F0-8422-4124-8981-9B91B08F374D@cs.purdue.edu> I have no problem invoking TimeStamp.New() with my AMD64_DARWIN build. I'm not sure why you are seeing problems with your build. On 8 Aug 2009, at 16:12, Jay K wrote: > Not all gui apps fail. > Some 32bit-isms in TimeStamp.m3. > gdb doesn't seem to be working at all for me, arg. > > jbook2:bin jay$ ./mentor > > > *** > *** runtime error: > *** An enumeration or subrange value was out of range. > *** file "../src/uid/Common/TimeStamp.m3", line 63 > *** > > Abort trap > > jbook2:bin jay$ ./formsedit > > > *** > *** runtime error: > *** An enumeration or subrange value was out of range. > *** file "../src/uid/Common/TimeStamp.m3", line 63 > *** > > > jbook2:bin jay$ ./BadBricks > > > *** > *** runtime error: > *** An enumeration or subrange value was out of range. > *** file "../src/uid/Common/TimeStamp.m3", line 63 > *** > > Abort trap > > book2:bin jay$ ./Calculator > > > *** > *** runtime error: > *** An enumeration or subrange value was out of range. > *** file "../src/uid/Common/TimeStamp.m3", line 63 > *** > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Aug 10 21:17:47 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 10 Aug 2009 19:17:47 +0000 Subject: [M3devel] testing RC2. In-Reply-To: References: <20090804002754.GF25621@topoi.pooq.com> <1C5F772D-930B-472B-A83B-32DEC364D2FA@hotmail.com> <20090804105835.vs1925r2kg480ccg@mail.elegosoft.com> <6A0491CD-BC10-49BB-8100-3137A406DBE7@darko.org> Message-ID: New (untested) I386_DARWIN packages are uploading right now. cm3-bin-core-I386_DARWIN-d5.8.2-RC2.tgz 100% 15MB 65.3KB/s 03:50 cm3-bin-min-I386_DARWIN-d5.8.2-RC2.tgz 100% 7511KB 62.1KB/s 02:01 cm3-bin-ws-anim-I386_DARWIN-d5.8.2-RC2.tgz 100% 5033KB 65.4KB/s 01:17 cm3-bin-ws-caltech-parser-I386_DARWIN-d5.8.2- 100% 4205KB 64.7KB/s 01:05 are done. - Jay > From: jay.krell at cornell.edu > To: darko at darko.org > Date: Mon, 10 Aug 2009 17:17:12 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] testing RC2. > > > My attempt to do an AMD64_DARWIN build messed up the I386_DARWIN files. > I386_DARWIN needs to be rebuilt, preferably this time via Hudson. > Please give it a day or two at least. > > - Jay > > > ---------------------------------------- > > CC: m3devel at elegosoft.com > > From: darko at darko.org > > To: jay.krell at cornell.edu > > Subject: Re: [M3devel] testing RC2. > > Date: Mon, 10 Aug 2009 17:24:53 +0200 > > > > Just looking into a Mac installer but found the RC2 "optional" > > archives seem to have AMD64_DARWIN libraries instead of I386_DARWIN. > > I'm looking in http://www.opencm3.net/releng/download.html > > > > > > On 04/08/2009, at 1:49 PM, Jay K wrote: > > > >> > >>> build some missing installation packages (for I386_DARWIN for > >>> example) > >> > >> > >> I have a new computer arriving roughly Friday on which I can setup > >> near arbitrary x86/AMD64 VMs, as well as doing native I386_DARWIN > >> and AMD64_DARWIN. AMD64_FREEBSD is also missing for example. > >> Tony should also be able to do {I386,AMD64}_DARWIN. > >> > >> > >> - Jay > >> > >> > >> > >> ---------------------------------------- > >>> Date: Tue, 4 Aug 2009 10:58:35 +0200 > >>> From: wagner at elegosoft.com > >>> To: m3devel at elegosoft.com > >>> Subject: Re: [M3devel] testing RC2. > >>> > >>> Quoting jay.krell at cornell.edu: > >>> > >>>> Wikipedia: Aren't you subverting release manager Olaf? Not ready for > >>>> exposure beyond m3devel? > >>> > >>> I just moved the date for RC2 another week :-/ Too many things still > >>> to be done. See > >>> > >>> https://projects.elego.de/cm3/milestone/CM3%20Release%205.8%20RC2 > >>> > >>> We need > >>> > >>> o to improve the WWW presentation (there were suggestions from > >>> Peter Eiserloh and others but no concrete changes/commits AFAIK) > >>> > >>> o build some missing installation packages (for I386_DARWIN for > >>> example) > >>> > >>> o automate some installation tests (next thing I'll do) > >>> > >>> o get some feedback from manual tests > >>> > >>> If there are no commits to the web pages till Wednesday, I'll make > >>> some small adaptions there to be ready for RC2 then. > >>> > >>> Olaf > >>> > >>>> - Jay (phone) > >>>> > >>>> On Aug 3, 2009, at 5:27 PM, hendrik at topoi.pooq.com wrote: > >>>> > >>>>> Now that I've updated the wikipedia entry, it's easier to find > >>>>> the RC2 > >>>>> downloads page. > >>>>> > >>>>> How can I update the other places that are easy to find on the > >>>>> google? > >>>>> Specifically, > >>>>> the Modula 3 resource page, www.modula3.org/ > >>>>> Modula-3 Frequently Asked Questions (FAQ), > >>>>> www.faqs.org/faqs/Modula-3-faq/ > >>>>> > >>>>> I'll soon be trying another installation fromscratch, using RC2, > >>>>> and I'll let you know how it went. > >>>>> > >>>>> -- hendrik > >>>>> > >>>>> > >>> > >>> > >>> > >>> -- > >>> Olaf Wagner -- elego Software Solutions GmbH > >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > >>> 45 86 95 > >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > >>> Berlin > >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > >>> DE163214194 > >>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Aug 10 21:52:16 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 10 Aug 2009 19:52:16 +0000 Subject: [M3devel] proposal for next release: moving some config file content into cm3 In-Reply-To: <20090810141354.9co7e8rxss8g8o48@mail.elegosoft.com> References: <20090810141354.9co7e8rxss8g8o48@mail.elegosoft.com> Message-ID: > If these cannot be overriden by the config files, system specific > installations not adhering to the standard layout won't be possible. They shall be overridable, but perhaps only INSTALL_ROOT? It becomes ambiguous, as to when to resolve INSTALL_ROOT in code like PKG_INSTALL = INSTALL_ROOT & /pkg PKG_USE = INSTALL_ROOT & /pkg or PKG_USE = PKG_INSTALL You have to decide what order things are processed -- builtin defines then command line, or command line then builtin defines, or loop while things change. Could I on the command line say -DPKG_USE="INSTALL_ROOT & '/foo'" ? Does cm3 -DINSTALL_ROOT=/foo imply PKG_USE=/foo/pkg? An easy answer is to only allow overriding USE_ROOT and INSTALL_ROOT. That all the rest follow directly by appending /bin, /pkg, /lib. I guess as well each one is "fully" overridable, but overriding "part of an expression" won't cause that expression to be reevaluated, and all the builtins are evaluated..first? last? Can I say PKG_USE=INSTALL_ROOT & /foo? Is INSTALL_ROOT defined before or after the command line is processed? I don't mean currently, but ideally. > > That is something to consider. > > cm3 should perhaps even move to an archictecture-specific directory. > > /cm3/bin/I386_LINUX/cm3 > > > > However, aside, I've given up on that idea. > > Why? Too complex? Is there some strong argument against it? > (I don't remember offhand.) If I'm going to have /cm3/bin/target, /cm3/lib/target, /cm3/pkg/m3core/target, and it is going to take work to teach things about this, it seems easier and almost equivalent to use /cm3.target/bin, /cm3.target/lib, or /cm3/target/bin, /cm3/target/lib, etc. The downside is some duplication, of the src directories in pkg, the config files (we can fix that, but very minor), doc, man..all fairly small..on Windows at least there is something called the "single instance store" that opportunistically finds identical files and combines their storage but makes them copy-on-write. I know I know -- "make whatever is different, different; leave whatever is the same, the same". But sometimes it is easier to just pretend everything is different, when it is almost true anyway. I wonder how cross builds fit here however. That might be a reason to have /cm3/bin/cm3 /cm3/lib/target /cm3/pkg/m3core/target (already the case) in that, you know, even though "biarch" and "multiarch" are "limited" to a maximum of around 3 (ppc, x86, amd64 darwin; cygwin, interix, native NT), cross combinations occupy the whole matrix, but only lib would get duplicated, not bin. The thing is, I find "full" cross builds to be too much of a pain -- the actual C compilation, assembly, link, so I don't account for them. You need to build or copy the C runtime and headers, build the cross compiler and assembler. The problem imho is that 1) it isn't even always possible, consider the case when the native tools are preferred over GNU and aren't open source (Irix, AIX, HP-UX?) 2) when it is possible, it varies, as the C runtime/headers have to be gotten a different way for each system (*BSD, Solaris, Linux, Windows). It is only "the same everywhere" if you define "everywhere" as one system such as FreeBSD OR Linux OR NetBSD. I have done this, copied /usr, /lib etc. from Solaris to a cross build host..but..as well..you don't even know which files. Perhaps I should use NFS and therefore get all the files more cheaply.. Hm. so /cm3/lib/target. And we use that for native too? Using symlinks for compat? And /cm3/bin/target. And /cm3/bin/cm3 is a .sh file with an except of sysinfo.sh? (and cm3.cmd would exist) And adjust the computation of INSTALL_ROOT? And the location of cm3.cfg? For the sake of "full" cross builds (ie: C compilation, assemble, link)? In either case, these are separate. Except that they relate regarding the computation of INSTALL_ROOT. The code for INSTALL_ROOT computation could be smart. If cm3's directory ends in "bin/host", remove two elements. If it ends in "bin", remove one element. If it ends in "m3-sys/host" error probably, or maybe search $PATH for another cm3 and apply the logic to its location. If anything else, error. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Aug 10 22:04:39 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 10 Aug 2009 20:04:39 +0000 Subject: [M3devel] testing RC2. In-Reply-To: References: <20090804002754.GF25621@topoi.pooq.com> <1C5F772D-930B-472B-A83B-32DEC364D2FA@hotmail.com> <20090804105835.vs1925r2kg480ccg@mail.elegosoft.com> <6A0491CD-BC10-49BB-8100-3137A406DBE7@darko.org> Message-ID: They should all be there now. - Jay From: jay To: darko CC: m3devel Subject: RE: [M3devel] testing RC2. Date: Mon, 10 Aug 2009 19:17:47 +0000 New (untested) I386_DARWIN packages are uploading right now. [snip] -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Aug 10 22:17:35 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 10 Aug 2009 22:17:35 +0200 Subject: [M3devel] testing RC2. In-Reply-To: References: <20090804002754.GF25621@topoi.pooq.com> <1C5F772D-930B-472B-A83B-32DEC364D2FA@hotmail.com> <20090804105835.vs1925r2kg480ccg@mail.elegosoft.com> <6A0491CD-BC10-49BB-8100-3137A406DBE7@darko.org> Message-ID: <20090810221735.covpvzsf4gosogoc@mail.elegosoft.com> Quoting Jay K : > They should all be there now. Great, thanks. Olaf > - Jay > > From: jay > To: darko > CC: m3devel > Subject: RE: [M3devel] testing RC2. > Date: Mon, 10 Aug 2009 19:17:47 +0000 > > > > > > > > > New (untested) I386_DARWIN packages are uploading right now. > > [snip] > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Aug 10 23:10:02 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 10 Aug 2009 21:10:02 +0000 Subject: [M3devel] the beauty of a C backend.. Message-ID: The beauty of a C backend.. We'd just release source and be done. No platform build matrix -- only what we'd test. Leave all the less used architectures to their users. Leave all the packaging to the distribution packaging people. Maybe use autoconf for some of the platform specific stuff, though we have very little anyway. You know, you don't see binary packages for many projects provided by their owners, and then not for many architectures. You know, we'd just do like NT/x86, Linux/x86, maybe Linux/amd64, and that'd be it. Anyone running anything else is an advanced or unusual user. (the x86 packages would generally work on the popular AMD64 machines, anyone wanting native could build from source) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Aug 10 23:19:42 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 10 Aug 2009 17:19:42 -0400 Subject: [M3devel] the beauty of a C backend.. In-Reply-To: References: Message-ID: These are observations, but I don't see how they reach any conclusion, nor whether the conclusion is desirable. I'm not sure exactly what you are trying to say. On 10 Aug 2009, at 17:10, Jay K wrote: > The beauty of a C backend.. > We'd just release source and be done. > No platform build matrix -- only what we'd test. > Leave all the less used architectures to their users. > Leave all the packaging to the distribution packaging people. > Maybe use autoconf for some of the platform specific stuff, though > we have very little anyway. > > > You know, you don't see binary packages for many > projects provided by their owners, and then not for many > architectures. > You know, we'd just do like NT/x86, Linux/x86, maybe Linux/amd64, > and that'd be it. > Anyone running anything else is an advanced or unusual user. > (the x86 packages would generally work on the popular AMD64 > machines, anyone wanting > native could build from source) > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Aug 11 07:24:45 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 11 Aug 2009 05:24:45 +0000 Subject: [M3devel] platform names? Message-ID: Can folks humor me and decide on names for the following: ALPHA_VMS or ALPHA_OPENVMS VMS is shorter IA64_VMS or IA64_OPENVMS VMS is shorter "Open" implies "Posix" as I understand IA64_HPUX -- probably that is it PA32_LINUX or PA or HPPA or HPPA32 PA64_LINUX or HPPA64 gcc uses "hppa" and "hppa64". ALPHA_TRU64 or ALPHA_OSF or ALPHA_OSF1? gcc seems to use "osf1" MIPS32_IRIX probably right, new abi, ignore old abi or MIPSO32_IRIX or MIPSN32_IRIX ? MIPS64_IRIX probably right PPC32_AIX probably right PPC64_AIX probably right ARM_LINUX_UCLIBC? ARM_LINUX24? ARM_LINUX_USERTHREADS? ? Eventually I'd like to get to these, as long gcc supports them, unless I get a C backend working and porting work therefore declines. I have already run some of these OSes recently: AIX, Irix, Linux/hppa. Nothing on Alpha yet, nor VMS. Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Aug 11 07:34:28 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 11 Aug 2009 05:34:28 +0000 Subject: [M3devel] proposal for next release: moving some config file content into cm3 Message-ID: > cm3 should perhaps even move to an archictecture-specific directory. > /cm3/bin/I386_LINUX/cm3 One thing I forgot about here is where to install the likes of: jbook2:m3cc jay$ ls -1 */cm3cg I386_DARWIN-AMD64_FREEBSD/cm3cg I386_DARWIN-AMD64_LINUX/cm3cg I386_DARWIN-AMD64_NETBSD/cm3cg I386_DARWIN-AMD64_OPENBSD/cm3cg I386_DARWIN-FreeBSD4/cm3cg I386_DARWIN-I386_INTERIX/cm3cg I386_DARWIN-I386_OPENBSD/cm3cg Probably /cm3/bin/AMD64_FREEBSD/cm3cg This doesn't necessarily imply "solving" "where to put host specific files". These are target-specific. Eventually it might be nice provide cross compiler packages, for folks that have cross gcc/ld. I just have the config file probe around in the uninstalled tree for backends. If anyone could tackle writing a linker/loader for some systems, I'd be willing to reconsider all the extra C code, for some systems. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Aug 11 07:37:34 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 11 Aug 2009 05:37:34 +0000 Subject: [M3devel] targeting kernel instead of libc/pthreads? Message-ID: Does anyone - like the idea - can work on implementing Modula-3 threads over one/some/all of the kernel interfaces? In particular on Linux pthreads are usermode layer over something else. If we targeted the kernel interface, we could ignore uclibc vc. glibc vc. newlib. On the flip side -- is pthreads viable on non-NPTL kernels? It's not like the C interfaces weren't there. Or is Modula-3 sensitive to the odd semantics? Or is it just slightly or much too slow? Just throwing ideas out.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Aug 11 07:38:05 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 11 Aug 2009 05:38:05 +0000 Subject: [M3devel] proposal for next release: moving some config file content into cm3 Message-ID: [truncated again..] From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: RE: proposal for next release: moving some config file content into cm3 Date: Tue, 11 Aug 2009 05:34:28 +0000 > cm3 should perhaps even move to an archictecture-specific directory. > /cm3/bin/I386_LINUX/cm3 One thing I forgot about here is where to install the likes of: jbook2:m3cc jay$ ls -1 */cm3cg I386_DARWIN-AMD64_FREEBSD/cm3cg I386_DARWIN-AMD64_LINUX/cm3cg I386_DARWIN-AMD64_NETBSD/cm3cg I386_DARWIN-AMD64_OPENBSD/cm3cg I386_DARWIN-FreeBSD4/cm3cg I386_DARWIN-I386_INTERIX/cm3cg I386_DARWIN-I386_OPENBSD/cm3cg Probably /cm3/bin/AMD64_FREEBSD/cm3cg This doesn't necessarily imply "solving" "where to put host specific files". These are target-specific. Eventually it might be nice provide cross compiler packages, for folks that have cross gcc/ld. I just have the config file probe around in the uninstalled tree for backends. If anyone could tackle writing a linker/loader for some systems, I'd be willing to reconsider all the extra C code, for some systems. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Aug 11 08:11:17 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 11 Aug 2009 08:11:17 +0200 Subject: [M3devel] Package build/link errors on Solaris Message-ID: <20090811081117.xdm8121yu8ogw0o4@mail.elegosoft.com> There are lots of strage build/link errors on the two Solaris targets, see http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLsun/ http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/ Does anybody know offhand what's missing there? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Aug 11 08:22:13 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 11 Aug 2009 08:22:13 +0200 Subject: [M3devel] Package build/link errors on Solaris In-Reply-To: <20090811081117.xdm8121yu8ogw0o4@mail.elegosoft.com> References: <20090811081117.xdm8121yu8ogw0o4@mail.elegosoft.com> Message-ID: <20090811082213.o7sxi1znhgkg88gk@mail.elegosoft.com> Quoting Olaf Wagner : > There are lots of strage build/link errors on the two Solaris > targets, see > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLsun/ > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/ > > Does anybody know offhand what's missing there? Bad style to answer my own posts, but I've already found it. The X libraries are missing: -> archiving libm3ui.a ld: fatal: library -lXaw: not found ld: fatal: library -lXmu: not found ld: fatal: library -lXext: not found ld: fatal: library -lXt: not found ld: fatal: library -lX11: not found ld: fatal: File processing errors. No output written to libm3ui.so.5 collect2: ld returned 1 exit status make_lib => 1 Jay, did you remove the X installation? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Aug 11 15:37:30 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 11 Aug 2009 13:37:30 +0000 Subject: [M3devel] More Unix constants missing.... In-Reply-To: <1249638984.2745.11.camel@faramir.m3w.org> References: <1249638984.2745.11.camel@faramir.m3w.org> Message-ID: please review: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/unix/Common/Uconstants.c.diff?r1=1.36;r2=1.37 http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/unix/Common/Unix.i3.diff?r1=1.26;r2=1.27 and for a longer list of potentially removed constants to be restored: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/unix/Common/Unix.txt?rev=1.1;content-type=text%2Fplain - Jay > From: dragisha at m3w.org > To: m3devel at elegosoft.com > Date: Fri, 7 Aug 2009 11:56:24 +0200 > Subject: [M3devel] More Unix constants missing.... > > Can we have them, in both HEAD ad RC2 branch? > > TIA, > dd > > === > CONST > TIOCMGET = 16_5415; > TIOCMSET = 16_5418; > > Bits = ARRAY StatusBits OF CARDINAL { > Unix.TIOCM_LE, > Unix.TIOCM_DTR, > Unix.TIOCM_RTS, > Unix.TIOCM_ST, > Unix.TIOCM_SR, > Unix.TIOCM_CTS, > Unix.TIOCM_CAR, > Unix.TIOCM_RNG, > Unix.TIOCM_DSR > }; > > -- > Dragi?a Duri? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Aug 11 15:41:39 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 11 Aug 2009 13:41:39 +0000 Subject: [M3devel] Package build/link errors on Solaris In-Reply-To: <20090811082213.o7sxi1znhgkg88gk@mail.elegosoft.com> References: <20090811081117.xdm8121yu8ogw0o4@mail.elegosoft.com> <20090811082213.o7sxi1znhgkg88gk@mail.elegosoft.com> Message-ID: I thought I only removed static archives, in a quest for diskspace, arg. Not sure how to fix, might have to reinstall. Sorry. - Jay > Date: Tue, 11 Aug 2009 08:22:13 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Package build/link errors on Solaris > > Quoting Olaf Wagner : > > > There are lots of strage build/link errors on the two Solaris > > targets, see > > > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLsun/ > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/ > > > > Does anybody know offhand what's missing there? > > Bad style to answer my own posts, but I've already found it. The X > libraries are missing: > > -> archiving libm3ui.a > ld: fatal: library -lXaw: not found > ld: fatal: library -lXmu: not found > ld: fatal: library -lXext: not found > ld: fatal: library -lXt: not found > ld: fatal: library -lX11: not found > ld: fatal: File processing errors. No output written to libm3ui.so.5 > collect2: ld returned 1 exit status > make_lib => 1 > > Jay, did you remove the X installation? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Aug 11 15:48:01 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 11 Aug 2009 09:48:01 -0400 Subject: [M3devel] targeting kernel instead of libc/pthreads? In-Reply-To: References: Message-ID: <5E49131B-9F6E-4E8E-AEB3-398B401B38EF@cs.purdue.edu> On 11 Aug 2009, at 01:37, Jay K wrote: > Does anyone > - like the idea Perhaps an interesting "research" idea. Probably not for the mainstream, because it is so platform-specific and puts you at the mercy of changes to kernel interfaces as opposed to more stable POSIX APIs. > - can work on implementing > > Modula-3 threads over one/some/all of the kernel interfaces? > In particular on Linux pthreads are usermode layer over something > else. > > If we targeted the kernel interface, we could ignore uclibc vc. > glibc vc. newlib. > > On the flip side -- is pthreads viable on non-NPTL kernels? > It's not like the C interfaces weren't there. > Or is Modula-3 sensitive to the odd semantics? > Or is it just slightly or much too slow? > > Just throwing ideas out.. > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Aug 11 15:53:23 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 11 Aug 2009 13:53:23 +0000 Subject: [M3devel] Package build/link errors on Solaris In-Reply-To: <20090811082213.o7sxi1znhgkg88gk@mail.elegosoft.com> References: <20090811081117.xdm8121yu8ogw0o4@mail.elegosoft.com> <20090811082213.o7sxi1znhgkg88gk@mail.elegosoft.com> Message-ID: I think I'll attempt a new install this week, sorry. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Subject: RE: [M3devel] Package build/link errors on Solaris Date: Tue, 11 Aug 2009 13:41:39 +0000 I thought I only removed static archives, in a quest for diskspace, arg. Not sure how to fix, might have to reinstall. Sorry. - Jay > Date: Tue, 11 Aug 2009 08:22:13 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Package build/link errors on Solaris > > Quoting Olaf Wagner : > > > There are lots of strage build/link errors on the two Solaris > > targets, see > > > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLsun/ > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/ > > > > Does anybody know offhand what's missing there? > > Bad style to answer my own posts, but I've already found it. The X > libraries are missing: > > -> archiving libm3ui.a > ld: fatal: library -lXaw: not found > ld: fatal: library -lXmu: not found > ld: fatal: library -lXext: not found > ld: fatal: library -lXt: not found > ld: fatal: library -lX11: not found > ld: fatal: File processing errors. No output written to libm3ui.so.5 > collect2: ld returned 1 exit status > make_lib => 1 > > Jay, did you remove the X installation? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Tue Aug 11 16:14:10 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 11 Aug 2009 16:14:10 +0200 Subject: [M3devel] targeting kernel instead of libc/pthreads? In-Reply-To: References: Message-ID: <1250000050.14316.15.camel@faramir.m3w.org> Your data is pretty rusty here :) pthreads as library is of course "usermode layer over something". That something being O(1) kernel space thread implementation. On Tue, 2009-08-11 at 05:37 +0000, Jay K wrote: > > In particular on Linux pthreads are usermode layer over something > else. -- Dragi?a Duri? From jay.krell at cornell.edu Tue Aug 11 16:22:23 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 11 Aug 2009 14:22:23 +0000 Subject: [M3devel] targeting kernel instead of libc/pthreads? In-Reply-To: <1250000050.14316.15.camel@faramir.m3w.org> References: <1250000050.14316.15.camel@faramir.m3w.org> Message-ID: I'm aware of that. But I don't think it matches pthreads closely, but provides sufficient primitives. It is clone and futex. I expect the kernel interfaces to be stable and there are multiple, binary incompatible?, pthreads implementations. - Jay > Subject: Re: [M3devel] targeting kernel instead of libc/pthreads? > From: dragisha at m3w.org > To: jay.krell at cornell.edu > CC: hosking at cs.purdue.edu; m3devel at elegosoft.com > Date: Tue, 11 Aug 2009 16:14:10 +0200 > > Your data is pretty rusty here :) > > pthreads as library is of course "usermode layer over something". That > something being O(1) kernel space thread implementation. > > On Tue, 2009-08-11 at 05:37 +0000, Jay K wrote: > > > > In particular on Linux pthreads are usermode layer over something > > else. > -- > Dragi?a Duri? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Tue Aug 11 16:57:59 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 11 Aug 2009 16:57:59 +0200 Subject: [M3devel] targeting kernel instead of libc/pthreads? In-Reply-To: References: <1250000050.14316.15.camel@faramir.m3w.org> Message-ID: <1250002679.14316.26.camel@faramir.m3w.org> There is exactly one pthreads implementation in use, NPTL. That is really thin layer providing pthreads API. I don't think we can afford anything by reimplementing there, but we can loose pthreads abstraction. I'we not read Anthony's implementation for some time, but I remember he had some state tracking structures resembling earlier behaviour of user-space Modula-3 threads. These are not needed,really, except for some obscure tools and for at-all-prices compatibility. I don't know if it's still there, but if it is, it imposes some non-O(1)-ness, at least in Linux case where we have it. On Tue, 2009-08-11 at 14:22 +0000, Jay K wrote: > I'm aware of that. But I don't think it matches pthreads closely, but > provides sufficient primitives. It is clone and futex. > I expect the kernel interfaces to be stable and there are multiple, > binary incompatible?, pthreads implementations. > > - Jay > > > > Subject: Re: [M3devel] targeting kernel instead of libc/pthreads? > > From: dragisha at m3w.org > > To: jay.krell at cornell.edu > > CC: hosking at cs.purdue.edu; m3devel at elegosoft.com > > Date: Tue, 11 Aug 2009 16:14:10 +0200 > > > > Your data is pretty rusty here :) > > > > pthreads as library is of course "usermode layer over something". > That > > something being O(1) kernel space thread implementation. > > > > On Tue, 2009-08-11 at 05:37 +0000, Jay K wrote: > > > > > > In particular on Linux pthreads are usermode layer over something > > > else. > > -- > > Dragi?a Duri? > > -- Dragi?a Duri? From hosking at cs.purdue.edu Tue Aug 11 17:52:30 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 11 Aug 2009 11:52:30 -0400 Subject: [M3devel] targeting kernel instead of libc/pthreads? In-Reply-To: <1250002679.14316.26.camel@faramir.m3w.org> References: <1250000050.14316.15.camel@faramir.m3w.org> <1250002679.14316.26.camel@faramir.m3w.org> Message-ID: <423DD036-8AA3-4ECE-A364-F90672F35670@cs.purdue.edu> On 11 Aug 2009, at 10:57, Dragi?a Duri? wrote: > There is exactly one pthreads implementation in use, NPTL. > > That is really thin layer providing pthreads API. > > I don't think we can afford anything by reimplementing there, but we > can > loose pthreads abstraction. Agreed, I don't see the win. > I'we not read Anthony's implementation for some time, but I remember > he > had some state tracking structures resembling earlier behaviour of > user-space Modula-3 threads. These are not needed,really, except for > some obscure tools and for at-all-prices compatibility. I don't know > if > it's still there, but if it is, it imposes some non-O(1)-ness, at > least > in Linux case where we have it. My implementation is much lighter now -- thread state information is only ever used for the signal handling needed to suspend/resume thread during GC. Otherwise, no additional accounting in the normal case. LOCK is essentially pthread_mutex_lock/unlock. As far as I recall, for purposes of notification (Alert) we still manage wait queues explicitly, mostly because the semantics of signals and threads in different pthreads implementations varies significantly (I seem to remember Dragi?a's original approach was sufficient for Linux NPTL, but not portable to other platforms). > > On Tue, 2009-08-11 at 14:22 +0000, Jay K wrote: >> I'm aware of that. But I don't think it matches pthreads closely, but >> provides sufficient primitives. It is clone and futex. >> I expect the kernel interfaces to be stable and there are multiple, >> binary incompatible?, pthreads implementations. >> >> - Jay >> >> >>> Subject: Re: [M3devel] targeting kernel instead of libc/pthreads? >>> From: dragisha at m3w.org >>> To: jay.krell at cornell.edu >>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com >>> Date: Tue, 11 Aug 2009 16:14:10 +0200 >>> >>> Your data is pretty rusty here :) >>> >>> pthreads as library is of course "usermode layer over something". >> That >>> something being O(1) kernel space thread implementation. >>> >>> On Tue, 2009-08-11 at 05:37 +0000, Jay K wrote: >>>> >>>> In particular on Linux pthreads are usermode layer over something >>>> else. >>> -- >>> Dragi?a Duri? >>> > -- > Dragi?a Duri? From dragisha at m3w.org Tue Aug 11 21:48:31 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 11 Aug 2009 21:48:31 +0200 Subject: [M3devel] targeting kernel instead of libc/pthreads? In-Reply-To: <423DD036-8AA3-4ECE-A364-F90672F35670@cs.purdue.edu> References: <1250000050.14316.15.camel@faramir.m3w.org> <1250002679.14316.26.camel@faramir.m3w.org> <423DD036-8AA3-4ECE-A364-F90672F35670@cs.purdue.edu> Message-ID: <1250020111.14316.38.camel@faramir.m3w.org> Dragi?a used trusty techniques of reading existing source code, in this case Boehm's GC and testing his approach vs. one similar implementation he was able to find and compare. It checked well, and worked flawlessly for about 4 years in many applications and esp important in one I've designed to stress test it (my DC hub sw). But it was also many yrs ago. December of 2003.... I surely did not execute my code on anything else. And I also stopped using it once you made your code available and supported. It's nice when other fullfill your dreams - mine being first class citizenship of Modula-3 on modern OS's. And that includes relying on established standards like pthreads. On Tue, 2009-08-11 at 11:52 -0400, Tony Hosking wrote: > mostly because the semantics of signals and threads in > different pthreads implementations varies significantly (I seem to > remember Dragi?a's original approach was sufficient for Linux NPTL, > but not portable to other platforms). -- Dragi?a Duri? From wagner at elegosoft.com Wed Aug 12 01:10:38 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 12 Aug 2009 01:10:38 +0200 Subject: [M3devel] CM3 Release Engineering and Feedback Message-ID: <20090812011038.n57fqtq0m8o0s8so@mail.elegosoft.com> Hi again, I can imagine that everybody is a bit tired of all the mails concerning the public release of CM3 5.8 and its problems, but nonetheless I don't want this to become a one or two man show, so I'll summarize the current status again. o RC2 has been released and publicly announced on the m3announce list and in comp.lang.modul3. There are several problems though with the packages, so that we should provide another release candidate, hopefullly at the end of this week. o There hasn't been much feedback, neither from the list of active developers nor from end users for RC2. I'd really appreciate some more reports about installation attempts and the problems encountered. o There's still the open discussion about the location and search strategy for config files where no conclusion or agreement has been reached as far as I know. o There are also still open issues about the integration of system-dependent installation archives, update/improvement/rewrite of the web presentation etc. o There are several open issues concerned with concrete test failures and installation problems that would need to be taken care of. o Documentation for non-POSIX, especially Windows systems is still lacking, too. o The Hudson infrastructure for automatic continuous build and regression testing has grown significantly (mostly due to contributions of Jay Krell) that we will be able to build almost all major target platforms for this and possibly future releases with it. I won't be able to care for all these tasks and issues alone. All help is still appreciated. It shouldn't be difficult, as everything is checked-in (sources, documents) and/or publicly accessible (WWW, Hudson, Trac). As for me, I'm going to build RC3 and the final release, and may then invest some time in reviewing and improving the distributed Hudson setup, which has been created in a rather ad-hoc fashion, because I needed tools to control the release engineering process. There are also still the Elego ComPact and DCVS M3 packages which I started to review for publishing long ago, but have never had the time and energy to finish. I won't promise anything though. I'd really enjoy if the group of active CM3 users and developers would become more engaged and agile in the discussions and open tasks and make active use of the tools and infrastructure provided (Trac, Hudson, WiKi, etc.). And if we could use all the experience and passion assembled here to inspire others and create more interest in this great language. Thanks for your support and patience, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Aug 12 02:05:46 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 12 Aug 2009 00:05:46 +0000 Subject: [M3devel] cd / on Windows Message-ID: Just a note that forward slashes work with cd, but not with pushd. I'll fix "this" "soon". ("this" being setup.cmd and its production, not that pushd doesn't with forward slashes. :) My ideal is that setup.cmd and install.sh are constant, and driven by a text file next to them, setup.txt or install.txt or such. Or possibly appeneded to them if people really like that "static linkage"). - Jay From jay.krell at cornell.edu Wed Aug 12 02:14:35 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 12 Aug 2009 00:14:35 +0000 Subject: [M3devel] targeting kernel instead of libc/pthreads? In-Reply-To: <1250002679.14316.26.camel@faramir.m3w.org> References: <1250000050.14316.15.camel@faramir.m3w.org> <1250002679.14316.26.camel@faramir.m3w.org> Message-ID: > There is exactly one pthreads implementation in use, NPTL. > That is really thin layer providing pthreads API. Is it thin? Is it really the same and binary compatible among the various C libraries -- glibc, uclibc, newlib? Same struct sizes and initializers? (I'd hope the initializers are all NULL and the structs all just the size of a pointer, but that isn't always the case.) - Jay From dragisha at m3w.org Wed Aug 12 11:16:34 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 12 Aug 2009 11:16:34 +0200 Subject: [M3devel] targeting kernel instead of libc/pthreads? In-Reply-To: References: <1250000050.14316.15.camel@faramir.m3w.org> <1250002679.14316.26.camel@faramir.m3w.org> Message-ID: <1250068594.14316.49.camel@faramir.m3w.org> I believe it is as thin as it's realistic. Ulrich Drepper is.... rigorous :) As for various libs, I don't know. I use only glibc. But we speak pthreads here.... glibc has implementation of pthreads over NPTL. pthreads structures are what we look for - Anthony used these, portable parts of glibc pthreads... If structs differ, then differing ones are not pthreads. Period. On Wed, 2009-08-12 at 00:14 +0000, Jay K wrote: > > There is exactly one pthreads implementation in use, NPTL. > > That is really thin layer providing pthreads API. > > Is it thin? > Is it really the same and binary compatible among the various C libraries -- glibc, uclibc, newlib? Same struct sizes and initializers? (I'd hope the initializers are all NULL and the structs all just the size of a pointer, but that isn't always the case.) > > - Jay -- Dragi?a Duri? From wagner at elegosoft.com Wed Aug 12 15:22:10 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 12 Aug 2009 15:22:10 +0200 Subject: [M3devel] cd / on Windows In-Reply-To: References: Message-ID: <20090812152210.fa2rrrpa80go8088@mail.elegosoft.com> Quoting Jay K : > Just a note that forward slashes work with cd, but not with pushd. > I'll fix "this" "soon". > > ("this" being setup.cmd and its production, not that pushd doesn't > with forward slashes. :) My ideal is that setup.cmd and install.sh > are constant, and driven by a text file next to them, setup.txt or > install.txt or such. Or possibly appeneded to them if people really > like that "static linkage"). Please make setup.cmd report shipping failures, too. I don't think I've done that yet. And please include your Windows-specific installation packaging into make-dist.sh if the current platform is NT386. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Wed Aug 12 21:54:10 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 12 Aug 2009 21:54:10 +0200 Subject: [M3devel] A compile-time type is missing Message-ID: <1250106850.3281.20.camel@faramir.m3w.org> Any hint on debugging this? -- Dragi?a Duri? From jay.krell at cornell.edu Wed Aug 12 22:29:15 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 12 Aug 2009 20:29:15 +0000 Subject: [M3devel] A compile-time type is missing In-Reply-To: <1250106850.3281.20.camel@faramir.m3w.org> References: <1250106850.3281.20.camel@faramir.m3w.org> Message-ID: cd scripts OMIT_GCC=yes ./do-cm3-std.sh realclean OMIT_GCC=yes ./do-cm3-std.sh buildship ? - Jay ---------------------------------------- > From: dragisha at m3w.org > To: m3devel at elegosoft.com > Date: Wed, 12 Aug 2009 21:54:10 +0200 > Subject: [M3devel] A compile-time type is missing > > Any hint on debugging this? > > -- > Dragi?a Duri? > From dragisha at m3w.org Thu Aug 13 03:09:06 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 13 Aug 2009 03:09:06 +0200 Subject: [M3devel] A compile-time type is missing In-Reply-To: References: <1250106850.3281.20.camel@faramir.m3w.org> Message-ID: <1250125746.3281.27.camel@faramir.m3w.org> It was my code.. Dynamically loaded shared lib plugins... Don't ask. Works ok now. On Wed, 2009-08-12 at 20:29 +0000, Jay K wrote: > cd scripts > OMIT_GCC=yes ./do-cm3-std.sh realclean > OMIT_GCC=yes ./do-cm3-std.sh buildship > ? > > - Jay > > > > > ---------------------------------------- > > From: dragisha at m3w.org > > To: m3devel at elegosoft.com > > Date: Wed, 12 Aug 2009 21:54:10 +0200 > > Subject: [M3devel] A compile-time type is missing > > > > Any hint on debugging this? > > > > -- > > Dragi?a Duri? > > -- Dragi?a Duri? From vapier at gentoo.org Thu Aug 13 05:29:19 2009 From: vapier at gentoo.org (Mike Frysinger) Date: Wed, 12 Aug 2009 23:29:19 -0400 Subject: [M3devel] targeting kernel instead of libc/pthreads? In-Reply-To: References: <1250002679.14316.26.camel@faramir.m3w.org> Message-ID: <200908122329.23246.vapier@gentoo.org> On Tuesday 11 August 2009 20:14:35 Jay K wrote: > > There is exactly one pthreads implementation in use, NPTL. > > That is really thin layer providing pthreads API. > > Is it thin? > Is it really the same and binary compatible among the various C libraries > -- glibc, uclibc, newlib? Same struct sizes and initializers? (I'd hope the > initializers are all NULL and the structs all just the size of a pointer, > but that isn't always the case.) you can never expect binary compatibility across C libraries. uClibc does use the NPTL source tree from glibc, but that doesnt mean it's binary compatible at either the libc or libpthread level. newlib doesnt do shared libraries, so binary compatibility is irrelevant. but i too think it's absolutely crazy to attempt to write your own threading layer on top of clone(). -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From wagner at elegosoft.com Thu Aug 13 10:51:51 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 13 Aug 2009 10:51:51 +0200 Subject: [M3devel] cm3-tst-all-pkgs failures Message-ID: <20090813105151.dlgyga1y0csgkc4k@mail.elegosoft.com> I've made a mistake this morning adding the example packages to scripts/pkginfo.txt. For reasons still to be investigated it seems that the package examples/istvan is not in the repository (at least on the branch) but the package objects is (which is missing). I just took an ls listing from one of my workspaces. As I haven't got CVS access for some time, can somebody remove the examples/istvan package from scripts/pkginfo.txt on the 5.8 release branch? Thanks in advance, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Thu Aug 13 12:47:47 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 13 Aug 2009 06:47:47 -0400 Subject: [M3devel] CM3 Release Engineering and Feedback In-Reply-To: <20090812011038.n57fqtq0m8o0s8so@mail.elegosoft.com> References: <20090812011038.n57fqtq0m8o0s8so@mail.elegosoft.com> Message-ID: <20090813104747.GA18662@topoi.pooq.com> On Wed, Aug 12, 2009 at 01:10:38AM +0200, Olaf Wagner wrote: > Hi again, > > I can imagine that everybody is a bit tired of all the mails concerning > the public release of CM3 5.8 and its problems, but nonetheless I > don't want this to become a one or two man show, so I'll summarize > the current status again. > > o RC2 has been released and publicly announced on the m3announce list > and in comp.lang.modul3. There are several problems though with the > packages, so that we should provide another release candidate, hopefullly > at the end of this week. > > o There hasn't been much feedback, neither from the list of active > developers nor from end users for RC2. I'd really appreciate some > more reports about installation attempts and the problems encountered. Well, I'll provide more with the next RC. The hudson directpry was pretty much a show-stopper. I'd expect the same problem to be there on the other platforms. -- hendrik > > o There's still the open discussion about the location and search > strategy for config files where no conclusion or agreement has > been reached as far as I know. As long as (1) it is found in a platform-standard place, and (2) there's an easy way for a user to override this via command-line parameter or environment variable, the further details probably don't matter that much. > ... > > There are also still the Elego ComPact and DCVS M3 packages which > I started to review for publishing long ago, but have never had > the time and energy to finish. I won't promise anything though. What are these DCVS packages? > > Thanks for your support and patience, You're welcome. -- hendrik From wagner at elegosoft.com Thu Aug 13 14:38:06 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 13 Aug 2009 14:38:06 +0200 Subject: [M3devel] CM3 Release Engineering and Feedback Message-ID: <20090813143806.udmpiz76ecg0scgs@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > On Wed, Aug 12, 2009 at 01:10:38AM +0200, Olaf Wagner wrote: >> o There hasn't been much feedback, neither from the list of active >> developers nor from end users for RC2. I'd really appreciate some >> more reports about installation attempts and the problems encountered. > > Well, I'll provide more with the next RC. The hudson directory was > pretty much a show-stopper. I'd expect the same problem to be there on > the other platforms. The simple work-around would be to call cm3 -build on the packages again, which should only adapt the broken .M3SHIP files. I've added a check to make-dist.sh which should prevent such accidents in the future. Probably something slightly different will then remain undetected though ;-) But never mind, I'll try to build some RC3 packages for AMD64_LINUX at least at the weekend. >> o There's still the open discussion about the location and search >> strategy for config files where no conclusion or agreement has >> been reached as far as I know. > > As long as > (1) it is found in a platform-standard place, and > (2) there's an easy way for a user to override this via command-line > parameter or environment variable, > the further details probably don't matter that much. I had the impression that there were decidedly different and contradicting opinions on that matter. Maybe I mistook that though. >> There are also still the Elego ComPact and DCVS M3 packages which >> I started to review for publishing long ago, but have never had >> the time and energy to finish. I won't promise anything though. > > What are these DCVS packages? A distributed version of CVS. It's already available, but I'd like to add some or all of the M3 packages to CM3. The distribution part is mainly based on an extended CVSup. There were more interesting features added to CVS like snapshots and changesets, too. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Thu Aug 13 14:49:12 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 13 Aug 2009 08:49:12 -0400 Subject: [M3devel] CM3 Release Engineering and Feedback In-Reply-To: <20090813143806.udmpiz76ecg0scgs@mail.elegosoft.com> References: <20090813143806.udmpiz76ecg0scgs@mail.elegosoft.com> Message-ID: <20090813124912.GA18887@topoi.pooq.com> On Thu, Aug 13, 2009 at 02:38:06PM +0200, Olaf Wagner wrote: > Quoting hendrik at topoi.pooq.com: > > >On Wed, Aug 12, 2009 at 01:10:38AM +0200, Olaf Wagner wrote: > >> o There hasn't been much feedback, neither from the list of active > >> developers nor from end users for RC2. I'd really appreciate some > >> more reports about installation attempts and the problems encountered. > > > >Well, I'll provide more with the next RC. The hudson directory was > >pretty much a show-stopper. I'd expect the same problem to be there on > >the other platforms. > > The simple work-around would be to call cm3 -build on the packages > again, which should only adapt the broken .M3SHIP files. > > I've added a check to make-dist.sh which should prevent such > accidents in the future. Probably something slightly different > will then remain undetected though ;-) > > But never mind, I'll try to build some RC3 packages for AMD64_LINUX > at least at the weekend. > > >> o There's still the open discussion about the location and search > >> strategy for config files where no conclusion or agreement has > >> been reached as far as I know. > > > >As long as > > (1) it is found in a platform-standard place, and > > (2) there's an easy way for a user to override this via command-line > >parameter or environment variable, > >the further details probably don't matter that much. > > I had the impression that there were decidedly different and > contradicting opinions on that matter. Maybe I mistook that though. There may be. But as long as what's implemented meets these criteria, I don't think further details matter as much as havein a release out. The requirement that the standard config file is in a platform-standard place will require platform-dependent code somewhere. But as long as we still put everything in /usr/local/cm3, there's not all that much to be done. Getting Modula 3 into Debian will require us to be fussy, though. But I didn't think that was teh goal for this release. > > >>There are also still the Elego ComPact and DCVS M3 packages which > >>I started to review for publishing long ago, but have never had > >>the time and energy to finish. I won't promise anything though. > > > >What are these DCVS packages? > > A distributed version of CVS. It's already available, but I'd like > to add some or all of the M3 packages to CM3. The distribution part > is mainly based on an extended CVSup. There were more interesting > features added to CVS like snapshots and changesets, too. It seems that migration to DCVS might be easier than migration to monotone or svn or ... -- hendrik From wagner at elegosoft.com Thu Aug 13 17:35:41 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 13 Aug 2009 17:35:41 +0200 Subject: [M3devel] CM3 Release Engineering and Feedback In-Reply-To: <20090813124912.GA18887@topoi.pooq.com> References: <20090813143806.udmpiz76ecg0scgs@mail.elegosoft.com> <20090813124912.GA18887@topoi.pooq.com> Message-ID: <20090813173541.782ks2dyjkg8o84s@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > On Thu, Aug 13, 2009 at 02:38:06PM +0200, Olaf Wagner wrote: >> >What are these DCVS packages? >> >> A distributed version of CVS. It's already available, but I'd like >> to add some or all of the M3 packages to CM3. The distribution part >> is mainly based on an extended CVSup. There were more interesting >> features added to CVS like snapshots and changesets, too. > > It seems that migration to DCVS might be easier than migration to > monotone or svn or ... It wasn't my intention to suggest such a migration, nor would I recommend it. I still think CVS is sufficient for our requirements, but if developers want something newer or better we should try Subversion or Perforce or indeed one of the distributed tools like git or mercurial etc. Though I don't really see the advantages of such a tool for our use. Migration would be easy though, as DCVS is only an extension of CVS, so the actual database does not need to be changed, except for the administrative data. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Fri Aug 14 01:25:42 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 13 Aug 2009 19:25:42 -0400 Subject: [M3devel] CM3 Release Engineering and Feedback In-Reply-To: <20090813173541.782ks2dyjkg8o84s@mail.elegosoft.com> References: <20090813143806.udmpiz76ecg0scgs@mail.elegosoft.com> <20090813124912.GA18887@topoi.pooq.com> <20090813173541.782ks2dyjkg8o84s@mail.elegosoft.com> Message-ID: <20090813232542.GA19898@topoi.pooq.com> On Thu, Aug 13, 2009 at 05:35:41PM +0200, Olaf Wagner wrote: > Quoting hendrik at topoi.pooq.com: > > >On Thu, Aug 13, 2009 at 02:38:06PM +0200, Olaf Wagner wrote: > >>>What are these DCVS packages? > >> > >>A distributed version of CVS. It's already available, but I'd like > >>to add some or all of the M3 packages to CM3. The distribution part > >>is mainly based on an extended CVSup. There were more interesting > >>features added to CVS like snapshots and changesets, too. > > > >It seems that migration to DCVS might be easier than migration to > >monotone or svn or ... > > It wasn't my intention to suggest such a migration, nor would I > recommend it. I still think CVS is sufficient for our requirements, > but if developers want something newer or better we should try Subversion > or Perforce or indeed one of the distributed tools like git or > mercurial etc. Though I don't really see the advantages of such > a tool for our use. If I thought CVS wsa great, I'd be using it for my own stuff. I'm not. I'm using monotone. > > Migration would be easy though, as DCVS is only an extension of CVS, > so the actual database does not need to be changed, except for the > administrative data. That's the one (and prossibly only) advantage of DVCS. -- hendrik From rcoleburn at scires.com Fri Aug 14 17:21:51 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 14 Aug 2009 11:21:51 -0400 Subject: [M3devel] something broken on Windows Message-ID: <4A8547DB.1E75.00D7.1@scires.com> Not sure what is wrong, but something is broken on Windows. I can't get anything to compile anymore after updating. Tried both my scripts and Jay's python. Both fail. Don't have time to debug right now. Here is the failure from using Jay's upgrade.py script: .... no packages left == package C:\cm3\Sandbox\cm3\m3-win\import-libs == +++ C:\cm3\bin\cm3.exe -build -DROOT=C:/cm3/Sandbox/cm3 -DCM3_VERSION_TEXT=d5. 8.2 -DCM3_VERSION_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ C:\cm3\Sandbox\cm3\m3-sys\cminstall\src\config-no-install\NT386, line 115: synta x error: missing: = (found: ) Fatal Error: package build failed *** execution of [, ] failed *** C:\cm3\Sandbox\cm3\scripts\python> Regards, Randy CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Fri Aug 14 17:27:11 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 14 Aug 2009 11:27:11 -0400 Subject: [M3devel] examples should not be in PkgInfo.txt Message-ID: <4A85491C.1E75.00D7.1@scires.com> I see that someone has put some of the examples folder packages into PkgInfo.txt std group. None of these packages in the "examples" folder should go into PkgInfo.txt. Reason is that these are examples meant to be built using CM3IDE. CM3IDE will create a package folder in the user's private repository for the example and build it there locally. We don't want to build and ship these as part of the std distribution. Only the sources are needed. The "examples" folder and its contents need to be copied to the root of your cm3 installation. That's all. Regards, Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Aug 14 18:18:38 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 14 Aug 2009 18:18:38 +0200 Subject: [M3devel] examples should not be in PkgInfo.txt In-Reply-To: <4A85491C.1E75.00D7.1@scires.com> References: <4A85491C.1E75.00D7.1@scires.com> Message-ID: <20090814181838.byoxem2jkkwww8og@mail.elegosoft.com> Quoting Randy Coleburn : > I see that someone has put some of the examples folder packages into > PkgInfo.txt std group. > > None of these packages in the "examples" folder should go into PkgInfo.txt. > > Reason is that these are examples meant to be built using CM3IDE. > CM3IDE will create a package folder in the user's private repository > for the example and build it there locally. We don't want to build > and ship these as part of the std distribution. Only the sources > are needed. The "examples" folder and its contents need to be > copied to the root of your cm3 installation. That's all. I put them there, because they were not packed into the installation archives. They can also not be build with the usual tooling at all. What's the problem with them being included in the package list? If they are only useful for cm3ide, they should probably be part of that package (i.e. moved from cm3/examples to cm3/m3-sys/cm3ide/examples). Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Aug 14 22:55:13 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 14 Aug 2009 20:55:13 +0000 Subject: [M3devel] something broken on Windows In-Reply-To: <4A8547DB.1E75.00D7.1@scires.com> References: <4A8547DB.1E75.00D7.1@scires.com> Message-ID: head or release? It's a simple quake syntax error either way. ________________________________ > Date: Fri, 14 Aug 2009 11:21:51 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: [M3devel] something broken on Windows > > > > > > > > Not sure what is wrong, but something is broken on Windows. I can't get anything to compile anymore after updating. > > > > Tried both my scripts and Jay's python. Both fail. > > > > Don't have time to debug right now. > > > > Here is the failure from using Jay's upgrade.py script: > > > > .... > > no packages left > == package C:\cm3\Sandbox\cm3\m3-win\import-libs == > > > > +++ C:\cm3\bin\cm3.exe -build -DROOT=C:/cm3/Sandbox/cm3 -DCM3_VERSION_TEXT=d5. > 8.2 -DCM3_VERSION_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ > C:\cm3\Sandbox\cm3\m3-sys\cminstall\src\config-no-install\NT386, line 115: synta > x error: missing: = (found: ) > Fatal Error: package build failed > *** execution of [,> pFunction at 0x00B599B0>] failed *** > > > > C:\cm3\Sandbox\cm3\scripts\python> > > > > Regards, > > Randy From rcoleburn at scires.com Sat Aug 15 00:11:41 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 14 Aug 2009 18:11:41 -0400 Subject: [M3devel] something broken on Windows In-Reply-To: References: <4A8547DB.1E75.00D7.1@scires.com> Message-ID: <4A85A7E8.1E75.00D7.1@scires.com> Jay: For the output below, it was taken from an XP machine that gets the HEAD branch. I did find some differences in the way it "works" by getting the release branch on a different machine (Vista). Both of these used to work, so not sure what is wrong now. Regards, Randy >>> Jay K 8/14/2009 4:55 PM >>> head or release? It's a simple quake syntax error either way. ________________________________ > Date: Fri, 14 Aug 2009 11:21:51 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: [M3devel] something broken on Windows > > > > > > > > Not sure what is wrong, but something is broken on Windows. I can't get anything to compile anymore after updating. > > > > Tried both my scripts and Jay's python. Both fail. > > > > Don't have time to debug right now. > > > > Here is the failure from using Jay's upgrade.py script: > > > > .... > > no packages left > == package C:\cm3\Sandbox\cm3\m3-win\import-libs == > > > > +++ C:\cm3\bin\cm3.exe -build -DROOT=C:/cm3/Sandbox/cm3 -DCM3_VERSION_TEXT=d5. > 8.2 -DCM3_VERSION_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ > C:\cm3\Sandbox\cm3\m3-sys\cminstall\src\config-no-install\NT386, line 115: synta > x error: missing: = (found: ) > Fatal Error: package build failed > *** execution of [,> pFunction at 0x00B599B0>] failed *** > > > > C:\cm3\Sandbox\cm3\scripts\python> > > > > Regards, > > Randy CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Aug 15 01:13:50 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 14 Aug 2009 23:13:50 +0000 Subject: [M3devel] something broken on Windows In-Reply-To: <4A85A7E8.1E75.00D7.1@scires.com> References: <4A8547DB.1E75.00D7.1@scires.com> <4A85A7E8.1E75.00D7.1@scires.com> Message-ID: Look at the file/line the error complains about: >> C:\cm3\Sandbox\cm3\m3-sys\cminstall\src\config-no-install\NT386, line 115: synta >> x error: missing: = (found: ) no mystery; fixed. - Jay ________________________________ > Date: Fri, 14 Aug 2009 18:11:41 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] something broken on Windows > > > > > > > > Jay: For the output below, it was taken from an XP machine that gets the HEAD branch. > > I did find some differences in the way it "works" by getting the release branch on a different machine (Vista). > > > > Both of these used to work, so not sure what is wrong now. > > > > Regards, > > Randy > >>>> Jay K 8/14/2009 4:55 PM>>> > > head or release? > It's a simple quake syntax error either way. > > > > > ________________________________ >> Date: Fri, 14 Aug 2009 11:21:51 -0400 >> From: rcoleburn at scires.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] something broken on Windows >> >> >> >> >> >> >> >> Not sure what is wrong, but something is broken on Windows. I can't get anything to compile anymore after updating. >> >> >> >> Tried both my scripts and Jay's python. Both fail. >> >> >> >> Don't have time to debug right now. >> >> >> >> Here is the failure from using Jay's upgrade.py script: >> >> >> >> .... >> >> no packages left >> == package C:\cm3\Sandbox\cm3\m3-win\import-libs == >> >> >> >> +++ C:\cm3\bin\cm3.exe -build -DROOT=C:/cm3/Sandbox/cm3 -DCM3_VERSION_TEXT=d5. >> 8.2 -DCM3_VERSION_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ >> C:\cm3\Sandbox\cm3\m3-sys\cminstall\src\config-no-install\NT386, line 115: synta >> x error: missing: = (found: ) >> Fatal Error: package build failed >> *** execution of [,> pFunction at 0x00B599B0>] failed *** >> >> >> >> C:\cm3\Sandbox\cm3\scripts\python> >> >> >> >> Regards, >> >> Randy From rcoleburn at scires.com Sat Aug 15 01:53:40 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 14 Aug 2009 19:53:40 -0400 Subject: [M3devel] examples should not be in PkgInfo.txt In-Reply-To: <20090814181838.byoxem2jkkwww8og@mail.elegosoft.com> References: <4A85491C.1E75.00D7.1@scires.com> <20090814181838.byoxem2jkkwww8og@mail.elegosoft.com> Message-ID: <4A85BFCE.1E75.00D7.1@scires.com> Agree that they are useful for CM3IDE. Is there a way to have CM3IDE ship this folder to the cm3 root, e.g., C:\cm3\examples, when it is built and shipped? Otherwise, user has to know to copy the folder there. This only has to be done once, so copying the folder at the time CM3IDE is built and installed seems logical. Examples folder is strictly a set of source packages. There should be no derived files there. When user browses to a particular example in CM3IDE and asks to build it, CM3IDE will create a package containing the source of the example and the derived files in the user's private repository. That way each user gets their own private copy to muck around with. Indeed, entire examples folder tree can be marked read-only without any ill-effect because of the way CM3IDE works. Regards, Randy >>> Olaf Wagner 8/14/2009 12:18 PM >>> Quoting Randy Coleburn : > I see that someone has put some of the examples folder packages into > PkgInfo.txt std group. > > None of these packages in the "examples" folder should go into PkgInfo.txt. > > Reason is that these are examples meant to be built using CM3IDE. > CM3IDE will create a package folder in the user's private repository > for the example and build it there locally. We don't want to build > and ship these as part of the std distribution. Only the sources > are needed. The "examples" folder and its contents need to be > copied to the root of your cm3 installation. That's all. I put them there, because they were not packed into the installation archives. They can also not be build with the usual tooling at all. What's the problem with them being included in the package list? If they are only useful for cm3ide, they should probably be part of that package (i.e. moved from cm3/examples to cm3/m3-sys/cm3ide/examples). Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Aug 15 06:14:38 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 15 Aug 2009 04:14:38 +0000 Subject: [M3devel] examples should not be in PkgInfo.txt In-Reply-To: <4A85BFCE.1E75.00D7.1@scires.com> References: <4A85491C.1E75.00D7.1@scires.com> <20090814181838.byoxem2jkkwww8og@mail.elegosoft.com> <4A85BFCE.1E75.00D7.1@scires.com> Message-ID: > when it is built Trivial. > when it is shipped Maybe trivial. An empty directory or with contents? If it has contents, just ship the contents. If it is empty, there may or may not be a way currently. Generally you shouldn't write anything to the installation during build, only ship. And if under the influence of overrides, you shouldn't touch the installation at all -- which falls out of not touching during build and ship isn't allowed. (but maybe for next release this whole override thing goes away -- just clone the existing install and ship to it while building, no need to ever split build from ship) You can in general do pretty arbirary things in build and ship. You are limited by the quake builtins, which are fairly substantial, what you can do by running comamnd lines which is also pretty substantial but a recurring portability hazard (Olaf write some .sh; I write some .cmd or .py; repeat), and what you add to quake, which is basically unlimited, though then a hazard regarding building with old versions, you can probe for what is there with if defined("foo") use foo end. I haven't seen that there is a good clean way to add stuff and make it trivially available either at build or ship. I was accidentally doing ship stuff at build time like with the symlinks and stuff. Some folks resort to writing into .m3ship which seems sleazy. It is the underlying mechanism, but seems maybe worth abstracting. You know -- what if it is open by cm3 and disallowing other writers or has been flushed at other than a line boundary? I think maybe better would be to have .m3ship say if exists(m3user.ship) include(m3user.ship) end or such, and then m3user.ship is where users can write to. or even simply, ship("foo") writes "foo" into .m3ship. There is an ambiguity between declarative and imperative code -- the stuff in .m3ship might be order dependent and you might not know where in the order you are. - Jay ________________________________ > Date: Fri, 14 Aug 2009 19:53:40 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] examples should not be in PkgInfo.txt > > > > > > > > Agree that they are useful for CM3IDE. > > > > Is there a way to have CM3IDE ship this folder to the cm3 root, e.g., C:\cm3\examples, when it is built and shipped? Otherwise, user has to know to copy the folder there. This only has to be done once, so copying the folder at the time CM3IDE is built and installed seems logical. > > > > Examples folder is strictly a set of source packages. There should be no derived files there. When user browses to a particular example in CM3IDE and asks to build it, CM3IDE will create a package containing the source of the example and the derived files in the user's private repository. That way each user gets their own private copy to muck around with. > > > > Indeed, entire examples folder tree can be marked read-only without any ill-effect because of the way CM3IDE works. > > > > Regards, > > Randy > >>>> Olaf Wagner 8/14/2009 12:18 PM>>> > Quoting Randy Coleburn : > >> I see that someone has put some of the examples folder packages into >> PkgInfo.txt std group. >> >> None of these packages in the "examples" folder should go into PkgInfo.txt. >> >> Reason is that these are examples meant to be built using CM3IDE. >> CM3IDE will create a package folder in the user's private repository >> for the example and build it there locally. We don't want to build >> and ship these as part of the std distribution. Only the sources >> are needed. The "examples" folder and its contents need to be >> copied to the root of your cm3 installation. That's all. > > I put them there, because they were not packed into the installation > archives. They can also not be build with the usual tooling at all. > > What's the problem with them being included in the package list? > > If they are only useful for cm3ide, they should probably be part of > that package (i.e. moved from cm3/examples to cm3/m3-sys/cm3ide/examples). > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From rcoleburn at scires.com Sat Aug 15 07:59:10 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Sat, 15 Aug 2009 01:59:10 -0400 Subject: [M3devel] examples should not be in PkgInfo.txt In-Reply-To: References: <4A85491C.1E75.00D7.1@scires.com> <20090814181838.byoxem2jkkwww8og@mail.elegosoft.com> <4A85BFCE.1E75.00D7.1@scires.com> Message-ID: <4A861576.1E75.00D7.1@scires.com> Sorry, I should be more precise. I meant when "shipped", not when "built". The examples folder is just a collection of source packages. Each source package has an HTML file that CM3IDE displays to the user as instructive information about how to use the example. The entire examples folder and its contents need to be at the root of your cm3 install, e.g., C:\cm3\examples, in order for CM3IDE to locate and use it. Of course, if one is not going to use CM3IDE, the folder isn't necessary. Thus, the thought is that when you do "cm3 -ship" on the CM3IDE package it would be good to ensure the example folder is instantiated in the cm3 tree at that time. Thus, if there is a way to do this via some extra code in the m3makefile for CM3IDE that would be fine and we could keep the examples folder as part of the CM3IDE package source tree. Regards, Randy >>> Jay K 8/15/2009 12:14 AM >>> > when it is built Trivial. > when it is shipped Maybe trivial. An empty directory or with contents? If it has contents, just ship the contents. If it is empty, there may or may not be a way currently. Generally you shouldn't write anything to the installation during build, only ship. And if under the influence of overrides, you shouldn't touch the installation at all -- which falls out of not touching during build and ship isn't allowed. (but maybe for next release this whole override thing goes away -- just clone the existing install and ship to it while building, no need to ever split build from ship) You can in general do pretty arbirary things in build and ship. You are limited by the quake builtins, which are fairly substantial, what you can do by running comamnd lines which is also pretty substantial but a recurring portability hazard (Olaf write some .sh; I write some .cmd or .py; repeat), and what you add to quake, which is basically unlimited, though then a hazard regarding building with old versions, you can probe for what is there with if defined("foo") use foo end. I haven't seen that there is a good clean way to add stuff and make it trivially available either at build or ship. I was accidentally doing ship stuff at build time like with the symlinks and stuff. Some folks resort to writing into .m3ship which seems sleazy. It is the underlying mechanism, but seems maybe worth abstracting. You know -- what if it is open by cm3 and disallowing other writers or has been flushed at other than a line boundary? I think maybe better would be to have .m3ship say if exists(m3user.ship) include(m3user.ship) end or such, and then m3user.ship is where users can write to. or even simply, ship("foo") writes "foo" into .m3ship. There is an ambiguity between declarative and imperative code -- the stuff in .m3ship might be order dependent and you might not know where in the order you are. - Jay ________________________________ > Date: Fri, 14 Aug 2009 19:53:40 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] examples should not be in PkgInfo.txt > > > > > > > > Agree that they are useful for CM3IDE. > > > > Is there a way to have CM3IDE ship this folder to the cm3 root, e.g., C:\cm3\examples, when it is built and shipped? Otherwise, user has to know to copy the folder there. This only has to be done once, so copying the folder at the time CM3IDE is built and installed seems logical. > > > > Examples folder is strictly a set of source packages. There should be no derived files there. When user browses to a particular example in CM3IDE and asks to build it, CM3IDE will create a package containing the source of the example and the derived files in the user's private repository. That way each user gets their own private copy to muck around with. > > > > Indeed, entire examples folder tree can be marked read-only without any ill-effect because of the way CM3IDE works. > > > > Regards, > > Randy > >>>> Olaf Wagner 8/14/2009 12:18 PM>>> > Quoting Randy Coleburn : > >> I see that someone has put some of the examples folder packages into >> PkgInfo.txt std group. >> >> None of these packages in the "examples" folder should go into PkgInfo.txt. >> >> Reason is that these are examples meant to be built using CM3IDE. >> CM3IDE will create a package folder in the user's private repository >> for the example and build it there locally. We don't want to build >> and ship these as part of the std distribution. Only the sources >> are needed. The "examples" folder and its contents need to be >> copied to the root of your cm3 installation. That's all. > > I put them there, because they were not packed into the installation > archives. They can also not be build with the usual tooling at all. > > What's the problem with them being included in the package list? > > If they are only useful for cm3ide, they should probably be part of > that package (i.e. moved from cm3/examples to cm3/m3-sys/cm3ide/examples). > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Aug 15 10:37:21 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 15 Aug 2009 10:37:21 +0200 Subject: [M3devel] examples should not be in PkgInfo.txt In-Reply-To: <4A861576.1E75.00D7.1@scires.com> References: <4A85491C.1E75.00D7.1@scires.com> <20090814181838.byoxem2jkkwww8og@mail.elegosoft.com> <4A85BFCE.1E75.00D7.1@scires.com> <4A861576.1E75.00D7.1@scires.com> Message-ID: <20090815103721.a5ded2wusc4ow8wk@mail.elegosoft.com> So the correct way to handle the cm3ide examples would be o mv the sources from the top of cm3 to cm3/m3-sys/cm3ide/examples (or rather cm3ide/src/exmaples?) o remove them from the pkginfo.txt file o ensure that they get shipped to INSTALL_ROOT/examples when cm3ide is installed ? I can take care of that over the weekend, or one of you can do it if you like. Just let me know. Olaf Quoting Randy Coleburn : > Sorry, I should be more precise. I meant when "shipped", not when > "built". > The examples folder is just a collection of source packages. Each > source package has an HTML file that CM3IDE displays to the user as > instructive information about how to use the example. The entire > examples folder and its contents need to be at the root of your cm3 > install, e.g., C:\cm3\examples, in order for CM3IDE to locate and use > it. Of course, if one is not going to use CM3IDE, the folder isn't > necessary. Thus, the thought is that when you do "cm3 -ship" on the > CM3IDE package it would be good to ensure the example folder is > instantiated in the cm3 tree at that time. Thus, if there is a way to > do this via some extra code in the m3makefile for CM3IDE that would be > fine and we could keep the examples folder as part of the CM3IDE package > source tree. > Regards, > Randy > >>>> Jay K 8/15/2009 12:14 AM >>> > >> when it is built > > Trivial. > >> when it is shipped > > Maybe trivial. An empty directory or with contents? > If it has contents, just ship the contents. > If it is empty, there may or may not be a way currently. > > > Generally you shouldn't write anything to the installation during > build, only ship. > And if under the influence of overrides, you shouldn't touch the > installation at all -- which falls out of not touching during build and > ship isn't allowed. > (but maybe for next release this whole override thing goes away -- just > clone the existing install and ship to it while building, no need to > ever split build from ship) > > > You can in general do pretty arbirary things in build and ship. > You are limited by the quake builtins, which are fairly substantial, > what you can do by running comamnd lines which is also pretty > substantial but a recurring portability hazard (Olaf write some .sh; I > write some .cmd or .py; repeat), and what you add to quake, which is > basically unlimited, though then a hazard regarding building with old > versions, you can probe for what is there with if defined("foo") use foo > end. > > > I haven't seen that there is a good clean way to add stuff and make it > trivially available either at build or ship. > > I was accidentally doing ship stuff at build time like with the > symlinks and stuff. > > Some folks resort to writing into .m3ship which seems sleazy. > It is the underlying mechanism, but seems maybe worth abstracting. > You know -- what if it is open by cm3 and disallowing other writers > or has been flushed at other than a line boundary? > > I think maybe better would be to have .m3ship > say if exists(m3user.ship) > include(m3user.ship) > end > > or such, and then m3user.ship is where users can write to. > > or even simply, ship("foo") writes "foo" into .m3ship. > > There is an ambiguity between declarative and imperative code -- the > stuff in .m3ship might be order dependent and you might not know where > in the order you are. > > > - Jay > > > ________________________________ >> Date: Fri, 14 Aug 2009 19:53:40 -0400 >> From: rcoleburn at scires.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] examples should not be in PkgInfo.txt >> >> >> >> >> >> >> >> Agree that they are useful for CM3IDE. >> >> >> >> Is there a way to have CM3IDE ship this folder to the cm3 root, e.g., > C:\cm3\examples, when it is built and shipped? Otherwise, user has to > know to copy the folder there. This only has to be done once, so copying > the folder at the time CM3IDE is built and installed seems logical. >> >> >> >> Examples folder is strictly a set of source packages. There should be > no derived files there. When user browses to a particular example in > CM3IDE and asks to build it, CM3IDE will create a package containing the > source of the example and the derived files in the user's private > repository. That way each user gets their own private copy to muck > around with. >> >> >> >> Indeed, entire examples folder tree can be marked read-only without > any ill-effect because of the way CM3IDE works. >> >> >> >> Regards, >> >> Randy >> >>>>> Olaf Wagner 8/14/2009 12:18 PM>>> >> Quoting Randy Coleburn : >> >>> I see that someone has put some of the examples folder packages > into >>> PkgInfo.txt std group. >>> >>> None of these packages in the "examples" folder should go into > PkgInfo.txt. >>> >>> Reason is that these are examples meant to be built using CM3IDE. >>> CM3IDE will create a package folder in the user's private > repository >>> for the example and build it there locally. We don't want to build >>> and ship these as part of the std distribution. Only the sources >>> are needed. The "examples" folder and its contents need to be >>> copied to the root of your cm3 installation. That's all. >> >> I put them there, because they were not packed into the installation >> archives. They can also not be build with the usual tooling at all. >> >> What's the problem with them being included in the package list? >> >> If they are only useful for cm3ide, they should probably be part of >> that package (i.e. moved from cm3/examples to > cm3/m3-sys/cm3ide/examples). >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 > 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 >> > > CONFIDENTIALITY NOTICE: This email and any attachments are intended > solely for the use of the named recipient(s). This e-mail may contain > confidential and/or proprietary information of Scientific Research > Corporation. If you are not a named recipient, you are prohibited from > making any use of the information in the email and attachments. If you > believe you have received this email in error, please notify the sender > immediately and permanently delete the email, any attachments, and all > copies thereof from any drives or storage media and destroy any > printouts of the email or attachments. > > EXPORT COMPLIANCE NOTICE: This email and any attachments may contain > technical data subject to U.S export restrictions under the > International Traffic in Arms Regulations (ITAR) or the Export > Administration Regulations (EAR). Export or transfer of this technical > data and/or related information to any foreign person(s) or entity(ies), > either within the U.S. or outside of the U.S., may require export > authorization by the appropriate U.S. Government agency prior to export > or transfer. In addition, technical data may not be exported or > transferred to certain countries or specified designated nationals > identified by U.S. embargo controls without prior export authorization. > By accepting this email and any attachments, all recipients confirm that > they understand and will comply with all applicable ITAR, EAR and > embargo compliance requirements. > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Sat Aug 15 12:01:42 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 15 Aug 2009 12:01:42 +0200 Subject: [M3devel] CM3 web presentation Message-ID: <20090815120142.cb14l4zj4k844004@mail.elegosoft.com> I've made some further small improvments (as I think) to the structure and look of the web pages. The green colour scheme was suggested by Peter Eiserloh. It can easily be reverted or changed again in case the majority doesn't like it. As I think it's an improvement and no other suggestions have been made so far, I took the liberty to just try it, because I haven't much time to spare for these topics besides the installation package building and testing. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sat Aug 15 14:14:53 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 15 Aug 2009 12:14:53 +0000 Subject: [M3devel] CM3 web presentation In-Reply-To: <20090815120142.cb14l4zj4k844004@mail.elegosoft.com> References: <20090815120142.cb14l4zj4k844004@mail.elegosoft.com> Message-ID: Please just use white on black or black on white. The old was ugly. Maybe I'm an old curmudgeon before my time, but all this use of color seems gratuitous. Black on white or white on black would be best imho. mostly black and white: http://gcc.gnu.org/ http://www.debian.org/ almost black and white: gray text, some orange text, white background http://www.netbsd.org/ blue text, white background: http://www.redhat.com/ some black on white, some blue on white http://news.cnet.com/ sort of black on white, and some black on gray www.apple.com blue text on white background: blue is links, lots of them, but then articles are black on white www.cnn.com If you want to be unusual I would suggest white or green on black. If you want to be normal I would suggest black on white, except links end up other, I guess blue I was taught that blue is to be avoided in general, because of its longish wave length it focuses poorly. I don't know why purple wasn't indicted the same, maybe it isn't popular? Blue IS my favorite color, but I do avoid it for this very reason. My grandmother didn't like knitting in blue for this reason. I'm amazed at the frequent occurences of blue in large swaths such as Apple and KDE desktop themes. I think PowerShell gets this wrong too. Also while super high contrast can be or seem bright, introduction of colors and shades and grays tends to imho unnecessarily reduce contract. The default Windows cmd scheme is actually gray almost white text on a black background. I change it to white. red (devil/daemon theme) http://www.freebsd.org/ - Jay > Date: Sat, 15 Aug 2009 12:01:42 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] CM3 web presentation > > I've made some further small improvments (as I think) to the > structure and look of the web pages. The green colour scheme was > suggested by Peter Eiserloh. It can easily be reverted or changed > again in case the majority doesn't like it. As I think it's an > improvement and no other suggestions have been made so far, I took > the liberty to just try it, because I haven't much time to spare > for these topics besides the installation package building and testing. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sat Aug 15 15:59:45 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sat, 15 Aug 2009 09:59:45 -0400 Subject: [M3devel] CM3 web presentation In-Reply-To: References: <20090815120142.cb14l4zj4k844004@mail.elegosoft.com> Message-ID: <20090815135945.GA24494@topoi.pooq.com> On Sat, Aug 15, 2009 at 12:14:53PM +0000, Jay K wrote: > > Please just use white on black or black on white. Colour or no colour, prefer light on dark. It's much easier for migraine sufferers. -- hendrik From wagner at elegosoft.com Sat Aug 15 20:24:16 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 15 Aug 2009 20:24:16 +0200 Subject: [M3devel] CM3 web presentation In-Reply-To: References: <20090815120142.cb14l4zj4k844004@mail.elegosoft.com> Message-ID: <20090815202416.mo45s1ftkcsssgo0@mail.elegosoft.com> Well, if someone just wants black on white or vice versa for everything, that should be easy with modern browsers (just don't allow pages to use their own colours). I also don't want to spend time on this now; so a collection of other sites with better layout and design is of no help. There was one concrete suggestion which I think is a improvement, so I tried that while doing some structural changes. I can switch back if needed. Everything else is left for people with more ambition and knowledge in graphical design. To make everyone happy concerning colours, we'll probably have to offer several schemes which can be switched via the GUI. If someone can implement that quickly, I'll happily apply it, too :-) I don't know offhand how to do that with style sheets. I'll now concentrate again on the issues for the next RC. Olaf Quoting Jay K : > Please just use white on black or black on white. > > > > > > The old was ugly. > Maybe I'm an old curmudgeon before my time, but all this use of > color seems gratuitous. > > > > > Black on white or white on black would be best imho. > > > > > mostly black and white: > http://gcc.gnu.org/ > http://www.debian.org/ > > > > > almost black and white: > gray text, some orange text, white background > http://www.netbsd.org/ > > > > > blue text, white background: > http://www.redhat.com/ > > > > > some black on white, some blue on white > http://news.cnet.com/ > > > > sort of black on white, and some black on gray > www.apple.com > > > > blue text on white background: > blue is links, lots of them, but then articles are black on white > www.cnn.com > > > > If you want to be unusual I would suggest > white or green on black. > > > > If you want to be normal I would suggest > black on white, except links end up other, I guess blue > > > > > I was taught that blue is to be avoided in general, > because of its longish wave length it focuses poorly. > I don't know why purple wasn't indicted the same, maybe > it isn't popular? Blue IS my favorite color, but I do > avoid it for this very reason. > My grandmother didn't like knitting in blue for this reason. > > > > > I'm amazed at the frequent occurences of blue in > large swaths such as Apple and KDE desktop themes. > I think PowerShell gets this wrong too. > > > > > Also while super high contrast can be or seem bright, > introduction of colors and shades and grays tends to > imho unnecessarily reduce contract. > > > > > The default Windows cmd scheme is actually gray almost > white text on a black background. I change it to white. > > > > > > red (devil/daemon theme) > http://www.freebsd.org/ > > > > > - Jay > > > >> Date: Sat, 15 Aug 2009 12:01:42 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] CM3 web presentation >> >> I've made some further small improvments (as I think) to the >> structure and look of the web pages. The green colour scheme was >> suggested by Peter Eiserloh. It can easily be reverted or changed >> again in case the majority doesn't like it. As I think it's an >> improvement and no other suggestions have been made so far, I took >> the liberty to just try it, because I haven't much time to spare >> for these topics besides the installation package building and testing. >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sun Aug 16 12:06:15 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 16 Aug 2009 10:06:15 +0000 Subject: [M3devel] more crashers Message-ID: This is head on SOLgnu: I'll try another and debug and see if fix is easy. -bash-3.00$ ./m3browser *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/String16.m3 *** -bash-3.00$ ./visobliq Internal Obliq interpreter installed... Establishing 'templates' (Created frame 'templates') let Templates = {boolean=> ... , browser=> ... , button=> ... , choice=> ... , filebrowser=> ... , form=> ... , frame=> ... , hscroll=> ... , menu=> ... , numeric=> ... , text=> ... , textedit=> ... , typein=> ... , video=> ... , vscroll=> ... } Establishing 'vowidgets' (Created frame 'vowidgets') ok Establishing 'vocheckpt' (Created frame 'vocheckpt') ok Establishing 'volib' (Created frame 'volib') Segmentation Fault (core dumped) -bash-3.00$ From wagner at elegosoft.com Sun Aug 16 14:31:14 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 16 Aug 2009 14:31:14 +0200 Subject: [M3devel] hudson suggestions In-Reply-To: References: <20090816134758.cil4twz0004cwo8g@mail.elegosoft.com> Message-ID: <20090816143114.wijmtla8000gwok8@mail.elegosoft.com> I agree copy & paste and GUI administration isn't great. But as long as I'm doing most of the release engineering from a closed network without ssh access, it's the easiest way. So please let's keep it this way until the release. As I said, I'll write up generic scripts afterwards. I won't be able to change those then during the day. (Cc'ed to m3devel as others may have the same ideas) Olaf Quoting Jay K : > > I think many jobs can be ok, setup as a pipeline, as long the > tedious gui editing is minimized. > Tedious text file editing can be not so bad. > But if they are short and usually succeed and always run in the same > sequence then maybe no point. > I can't stand when things get copied around many times and it > becomes difficult to keep them in sync where they can or should be > the same. For another example some of the m3cc tasks have "clean", > some do not. > > > I don't know if Hudson allows it easily, but e.g. there should be > just one m3cc task, assigned "sticky" to all nodes except NT386 and > then either with "sticky parameters" per-node, or the task uses the > Hudson environment variables to figure stuff out. Large that's not > even needed, due to the uname sniffing, but e.g. if there were > separate SOLsun and SOLgnu nodes or tasks, the Hudson task could set > a parameter. > > > Ok the initial cvs checkout can be non-anonymous. > And right certainly it should be minimal. > Like just get one file or just the scripts directory. > Probably should should be scripts/hudson. > > > scripts/hudson/m3cc > scripts/hudson/release-build > scripts/hudson/last-ok-build > scripts/hudson/test-install > scripts/hudson/makedist > etc. > > > preferably NOT multiplied out per target. > Whenever I see "multiplication" happening I cringe. > Sure, there is some variation but usually stuff is mostly the same > and parameters or #ifdef are imho preferred over copying.. > I understand copy/paste/edit is easier. You don't always know what > all the parameters are or how to even have any. > > Ideally there is: > scripts/hudson/install > > that takes a hostname, port number, node name, maybe CM3_TARGET > value, and sets up a node from scratch. > > Currently I don't know enough to do all this and it's much easier to > sit back and suggest it than do any of it, while I lazily continue > to edit the gui tediously... > > > > - Jay > > > ---------------------------------------- >> Date: Sun, 16 Aug 2009 13:47:58 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> Subject: Re: hudson suggestions >> >> Quoting Jay K : >> >>> two suggestions: >>> >>> 1) all tasks start with: >>> >>> echo hostname >>> hostname >>> uname -a >> >> That should be no problem, but I haven't got the infrastructure set up >> to do multiple XML edits, anyway, I only have HTTP access most of the >> times. So it can just be done incrementally for now. >> >>> or more similar >>> >>> 2) all tasks >>> just do roughly but almost exactly >>> cvs something >>> run something >> >> That's basically what most tasks do. But >> >> o CVS needs to be controlled by Hudson to be able to track the changes >> o we haven't set up generic scripts yet (I'm going to do that ASAP) >> o We don't want all tasks to check out everything, because that takes >> rather long depending on the network connections (yours are the >> best) >> >>> It can actually be anonymous cvs to get the intial code. >> Anonymous CVS asks for a password even if there is none. >> As we need ssh for reporting anyway, there's no reason not to >> use it. >> >>> They would all get the same thing generally. >>> Hudson probably sets enough environment variables -- task name -- for >>> cvs+run to then decide what to do, and what architecture on >>> multiarch systems >>> to use, based on strings in the task name. >>> >>> We can/should also check more stuff up front. >>> Like availability of cc and/or gcc, bc, gnu tar, simple C link tests >>> against -lX11, etc. >>> But first transform the tasks into cvs+run only. >>> >>> I started putting in the hostname/uname -- make sure I put nodes >>> back where you >>> expect them, but it is too tedious to go through the gui. >> >> That's all I have most of the time ;-) >> >> We also need to reduce the number of jobs; I'm thinking of >> combining the builds and the package tests. >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Sun Aug 16 19:00:22 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 16 Aug 2009 13:00:22 -0400 Subject: [M3devel] more crashers In-Reply-To: References: Message-ID: <1409BB96-A7AD-4ED1-8D91-FC3F1991F528@cs.purdue.edu> OK, these are just plain weird given that they ran just fine for me fairly recently. I am very concerned that the churn with all the recent Unix header unification has left us with a much less solid system than we used to have. If we release something that is this broken then we will not win any converts. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 16 Aug 2009, at 06:06, Jay K wrote: > > This is head on SOLgnu: > I'll try another and debug and see if fix is easy. > > -bash-3.00$ ./m3browser > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/String16.m3 > *** > > -bash-3.00$ ./visobliq > Internal Obliq interpreter installed... > Establishing 'templates' > (Created frame 'templates') > let > Templates = > {boolean=> ... , > browser=> ... , > button=> ... , > choice=> ... , > filebrowser=> ... , > form=> ... , > frame=> ... , > hscroll=> ... , > menu=> ... , > numeric=> ... , > text=> ... , > textedit=> ... , > typein=> ... , > video=> ... , > vscroll=> ... } > Establishing 'vowidgets' > (Created frame 'vowidgets') > ok > Establishing 'vocheckpt' > (Created frame 'vocheckpt') > ok > Establishing 'volib' > (Created frame 'volib') > Segmentation Fault (core dumped) > -bash-3.00$ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sun Aug 16 19:10:32 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 16 Aug 2009 13:10:32 -0400 Subject: [M3devel] CM3 Release Engineering and Feedback In-Reply-To: <20090813143806.udmpiz76ecg0scgs@mail.elegosoft.com> References: <20090813143806.udmpiz76ecg0scgs@mail.elegosoft.com> Message-ID: <20090816171032.GA27461@topoi.pooq.com> On Thu, Aug 13, 2009 at 02:38:06PM +0200, Olaf Wagner wrote: > Quoting hendrik at topoi.pooq.com: > > >On Wed, Aug 12, 2009 at 01:10:38AM +0200, Olaf Wagner wrote: > >> o There hasn't been much feedback, neither from the list of active > >> developers nor from end users for RC2. I'd really appreciate some > >> more reports about installation attempts and the problems encountered. > > > >Well, I'll provide more with the next RC. The hudson directory was > >pretty much a show-stopper. I'd expect the same problem to be there on > >the other platforms. > > The simple work-around would be to call cm3 -build on the packages > again, which should only adapt the broken .M3SHIP files. I tried that , but it failed, complaining hendrik at notlookedfor:~/cm3/RC2/gui/m3-ui$ cd cmvbt hendrik at notlookedfor:~/cm3/RC2/gui/m3-ui/cmvbt$ cm3 -build --- building in LINUXLIBC6 --- ignoring ../src/m3overrides "/home/hendrik/cm3/RC2/gui/m3-ui/cmvbt/src/m3makefile", line 3: quake runtime error: unable to open "/usr/local/cm3/pkg/ui/LINUXLIBC6/.M3EXPORTS" for reading --procedure-- -line- -file--- import -- include_dir 3 /home/hendrik/cm3/RC2/gui/m3-ui/cmvbt/src/m3makefile 4 /home/hendrik/cm3/RC2/gui/m3-ui/cmvbt/LINUXLIBC6/m3make.args Fatal Error: package build failed hendrik at notlookedfor:~/cm3/RC2/gui/m3-ui/cmvbt$ I guess I'll wait for RC3 to do further testing. Unless, of course, I've used cm3 -build wrong. In which case the workaround mentinoed on http://www.opencm3.net/releng/known-problems.html needs to be more explicit. In any case, this will be an obsolete by the time RC3 starts to roll out. So focus on that rather than fixing the workaround. -- hendrik From jay.krell at cornell.edu Sun Aug 16 21:21:14 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 16 Aug 2009 19:21:14 +0000 Subject: [M3devel] more crashers Message-ID: I see the assertion failure on PPC_LINUX too. I tried VAR defaultStackSize := 1024 * 1024; (not sure why there was any suspicion of stack size). Debugging doesn't work PPC_LINUX. jay at plin:/cm3/bin$ gdb ./cm3 GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "powerpc-linux-gnu"... break ma(gdb) break main Breakpoint 1 at 0x86fc4: file _m3main.mc, line 2. (gdb) r Starting program: /home/jay/cm3/bin/cm3 Warning: Cannot insert breakpoint 1. Error accessing memory address 0x86fc4: Input/output error. No problem with C: jay at plin:/cm3/bin$ echo "main(){}"> 1.c jay at plin:/cm3/bin$ gcc -g 1.c jay at plin:/cm3/bin$ gdb ./a.out GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "powerpc-linux-gnu"... (gdb) break main Breakpoint 1 at 0x10000448: file 1.c, line 1. (gdb) r Starting program: /home/jay/cm3/bin/a.out Breakpoint 1, main () at 1.c:1 1 main(){} (gdb) jay at plin:/cm3/bin$ gcc -gstabs+ 1.c jay at plin:/cm3/bin$ gdb ./a.out GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "powerpc-linux-gnu"... (gdb) break main Breakpoint 1 at 0x10000448: file 1.c, line 1. (gdb) r Starting program: /home/jay/cm3/bin/a.out Breakpoint 1, main () at 1.c:1 1 main(){} jay at plin:/cm3/bin$ gcc -gstabs 1.c jay at plin:/cm3/bin$ gdb ./a.out GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "powerpc-linux-gnu"... (gdb) break main Breakpoint 1 at 0x10000448: file 1.c, line 1. (gdb) r Starting program: /home/jay/cm3/bin/a.out Breakpoint 1, main () at 1.c:1 1 main(){} (gdb) - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: more crashers > Date: Sun, 16 Aug 2009 10:06:15 +0000 > > > This is head on SOLgnu: > I'll try another and debug and see if fix is easy. > > -bash-3.00$ ./m3browser > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/String16.m3 > *** > > -bash-3.00$ ./visobliq > Internal Obliq interpreter installed... > Establishing 'templates' > (Created frame 'templates') > let > Templates = > {boolean=> ... , > browser=> ... , > button=> ... , > choice=> ... , > filebrowser=> ... , > form=> ... , > frame=> ... , > hscroll=> ... , > menu=> ... , > numeric=> ... , > text=> ... , > textedit=> ... , > typein=> ... , > video=> ... , > vscroll=> ... } > Establishing 'vowidgets' > (Created frame 'vowidgets') > ok > Establishing 'vocheckpt' > (Created frame 'vocheckpt') > ok > Establishing 'volib' > (Created frame 'volib') > Segmentation Fault (core dumped) > -bash-3.00$ > From hosking at cs.purdue.edu Sun Aug 16 21:26:49 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 16 Aug 2009 15:26:49 -0400 Subject: [M3devel] more crashers In-Reply-To: References: Message-ID: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> Could this be endianness-related? On 16 Aug 2009, at 15:21, Jay K wrote: > > I see the assertion failure on PPC_LINUX too. > I tried VAR defaultStackSize := 1024 * 1024; (not sure why there was > any suspicion of stack size). > > > Debugging doesn't work PPC_LINUX. > > > jay at plin:/cm3/bin$ gdb ./cm3 > GNU gdb 6.8-debian > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show > copying" > and "show warranty" for details. > This GDB was configured as "powerpc-linux-gnu"... > break ma(gdb) break main > Breakpoint 1 at 0x86fc4: file _m3main.mc, line 2. > (gdb) r > Starting program: /home/jay/cm3/bin/cm3 > Warning: > Cannot insert breakpoint 1. > Error accessing memory address 0x86fc4: Input/output error. > > > No problem with C: > > > jay at plin:/cm3/bin$ echo "main(){}"> 1.c > jay at plin:/cm3/bin$ gcc -g 1.c > jay at plin:/cm3/bin$ gdb ./a.out > GNU gdb 6.8-debian > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show > copying" > and "show warranty" for details. > This GDB was configured as "powerpc-linux-gnu"... > (gdb) break main > Breakpoint 1 at 0x10000448: file 1.c, line 1. > (gdb) r > Starting program: /home/jay/cm3/bin/a.out > Breakpoint 1, main () at 1.c:1 > 1 main(){} > (gdb) > > > jay at plin:/cm3/bin$ gcc -gstabs+ 1.c > jay at plin:/cm3/bin$ gdb ./a.out > GNU gdb 6.8-debian > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show > copying" > and "show warranty" for details. > This GDB was configured as "powerpc-linux-gnu"... > (gdb) break main > Breakpoint 1 at 0x10000448: file 1.c, line 1. > (gdb) r > Starting program: /home/jay/cm3/bin/a.out > Breakpoint 1, main () at 1.c:1 > 1 main(){} > > > jay at plin:/cm3/bin$ gcc -gstabs 1.c > jay at plin:/cm3/bin$ gdb ./a.out > GNU gdb 6.8-debian > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show > copying" > and "show warranty" for details. > This GDB was configured as "powerpc-linux-gnu"... > (gdb) break main > Breakpoint 1 at 0x10000448: file 1.c, line 1. > (gdb) r > Starting program: /home/jay/cm3/bin/a.out > Breakpoint 1, main () at 1.c:1 > 1 main(){} > (gdb) > > > - Jay > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Subject: more crashers >> Date: Sun, 16 Aug 2009 10:06:15 +0000 >> >> >> This is head on SOLgnu: >> I'll try another and debug and see if fix is easy. >> >> -bash-3.00$ ./m3browser >> >> *** >> *** runtime error: >> *** Segmentation violation - possible attempt to dereference NIL >> *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/String16.m3 >> *** >> >> -bash-3.00$ ./visobliq >> Internal Obliq interpreter installed... >> Establishing 'templates' >> (Created frame 'templates') >> let >> Templates = >> {boolean=> ... , >> browser=> ... , >> button=> ... , >> choice=> ... , >> filebrowser=> ... , >> form=> ... , >> frame=> ... , >> hscroll=> ... , >> menu=> ... , >> numeric=> ... , >> text=> ... , >> textedit=> ... , >> typein=> ... , >> video=> ... , >> vscroll=> ... } >> Establishing 'vowidgets' >> (Created frame 'vowidgets') >> ok >> Establishing 'vocheckpt' >> (Created frame 'vocheckpt') >> ok >> Establishing 'volib' >> (Created frame 'volib') >> Segmentation Fault (core dumped) >> -bash-3.00$ >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Aug 16 21:27:03 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 16 Aug 2009 19:27:03 +0000 Subject: [M3devel] Errors building Juno on PPC_LINUX (Debian 5) Message-ID: Errors building Juno on PPC_LINUX (Debian 5) == package /home/jay/dev2/cm3/m3-ui/juno-2/juno-app == +++ /cm3/bin/cm3 -build -DROOT=/home/jay/dev2/cm3 -DCM3_VERSION_TEXT=d5.8.2 -D CM3_VERSION_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ --- building in PPC_LINUX --- ... new source -> compiling Editor.m3 ../src/Editor.m3: In function 'Editor__Parse2': ../src/Editor.m3:248: fatal error: *** bad opcode: 0x229, at m3cg_lineno 18629 compilation terminated. m3_backend => 1 m3cc (aka cm3cg) failed compiling: Editor.mc new opaque info -> recompiling Drag.m3 Drag.ms: Assembler messages: Drag.ms:3949: Error: unknown pseudo-op: `.s' assemble => 1 assembler failed assembling: Drag.ms *** execution of [, ] failed *** jay at plin:/dev2/cm3/scripts/python$ More details to follow. I'm going to rebuild m3cc clean, make sure it was built native not copied from another machine, but I think it already was native. - Jay From jay.krell at cornell.edu Sun Aug 16 21:33:34 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 16 Aug 2009 19:33:34 +0000 Subject: [M3devel] more crashers In-Reply-To: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> References: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> Message-ID: Could be. I've also seen it on PPC_DARWIN a while ago. I only recall seeing it on sparc and ppc. It doesn't always occur. Here is the m3browser crash on a system that can be debugged. See why I want the full paths in the debug info? C:\Users\jay\Desktop>\cygwin\bin\ssh xobsd. $ cd /cm3 $ cd bin $ export DISPLAY=192.168.1.120:0.0 $ gdb ./m3browser GNU gdb 6.3 This GDB was configured as "i386-unknown-openbsd4.5"... (gdb) r Starting program: /home/jay/cm3/bin/m3browser Program received signal SIGSEGV, Segmentation fault. [Switching to process 31063, thread 0x7eafe800] 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 16 t.get_info (i); (gdb) bt #0 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 #1 0x09fd9464 in ID__Add (M3_Bd56fi_x=0x0) at ../src/ID.m3:48 #2 0x1c01e644 in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:37 #3 0x0156f1bc in RTLinker__RunMainBody (M3_DjPxE3_m=0x3c003ec0) at ../src/runtime/common/RTLinker.m3:399 #4 0x0156e576 in RTLinker__AddUnitI (M3_DjPxE3_m=0x3c003ec0) at ../src/runtime/common/RTLinker.m3:113 #5 0x0156e604 in RTLinker__AddUnit (M3_DjPxE5_b=0x1c01e54d) at ../src/runtime/common/RTLinker.m3:122 #6 0x1c004676 in main (argc=1, argv=0xcfbf6a3c, envp=0xcfbf6a44) at _m3main.mc:4 - Jay ________________________________ > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Sun, 16 Aug 2009 15:26:49 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] more crashers > > Could this be endianness-related? > > On 16 Aug 2009, at 15:21, Jay K wrote: > > > I see the assertion failure on PPC_LINUX too. > I tried VAR defaultStackSize := 1024 * 1024; (not sure why there was any suspicion of stack size). > > > Debugging doesn't work PPC_LINUX. > > > jay at plin:/cm3/bin$ gdb ./cm3 > GNU gdb 6.8-debian > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "powerpc-linux-gnu"... > break ma(gdb) break main > Breakpoint 1 at 0x86fc4: file _m3main.mc, line 2. > (gdb) r > Starting program: /home/jay/cm3/bin/cm3 > Warning: > Cannot insert breakpoint 1. > Error accessing memory address 0x86fc4: Input/output error. > > > No problem with C: > > > jay at plin:/cm3/bin$ echo "main(){}"> 1.c > jay at plin:/cm3/bin$ gcc -g 1.c > jay at plin:/cm3/bin$ gdb ./a.out > GNU gdb 6.8-debian > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "powerpc-linux-gnu"... > (gdb) break main > Breakpoint 1 at 0x10000448: file 1.c, line 1. > (gdb) r > Starting program: /home/jay/cm3/bin/a.out > Breakpoint 1, main () at 1.c:1 > 1 main(){} > (gdb) > > > jay at plin:/cm3/bin$ gcc -gstabs+ 1.c > jay at plin:/cm3/bin$ gdb ./a.out > GNU gdb 6.8-debian > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "powerpc-linux-gnu"... > (gdb) break main > Breakpoint 1 at 0x10000448: file 1.c, line 1. > (gdb) r > Starting program: /home/jay/cm3/bin/a.out > Breakpoint 1, main () at 1.c:1 > 1 main(){} > > > jay at plin:/cm3/bin$ gcc -gstabs 1.c > jay at plin:/cm3/bin$ gdb ./a.out > GNU gdb 6.8-debian > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "powerpc-linux-gnu"... > (gdb) break main > Breakpoint 1 at 0x10000448: file 1.c, line 1. > (gdb) r > Starting program: /home/jay/cm3/bin/a.out > Breakpoint 1, main () at 1.c:1 > 1 main(){} > (gdb) > > > - Jay > > > ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: more crashers > Date: Sun, 16 Aug 2009 10:06:15 +0000 > > > This is head on SOLgnu: > I'll try another and debug and see if fix is easy. > > -bash-3.00$ ./m3browser > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/String16.m3 > *** > > -bash-3.00$ ./visobliq > Internal Obliq interpreter installed... > Establishing 'templates' > (Created frame 'templates') > let > Templates = > {boolean=> ... , > browser=> ... , > button=> ... , > choice=> ... , > filebrowser=> ... , > form=> ... , > frame=> ... , > hscroll=> ... , > menu=> ... , > numeric=> ... , > text=> ... , > textedit=> ... , > typein=> ... , > video=> ... , > vscroll=> ... } > Establishing 'vowidgets' > (Created frame 'vowidgets') > ok > Establishing 'vocheckpt' > (Created frame 'vocheckpt') > ok > Establishing 'volib' > (Created frame 'volib') > Segmentation Fault (core dumped) > -bash-3.00$ > > From jay.krell at cornell.edu Sun Aug 16 21:52:03 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 16 Aug 2009 19:52:03 +0000 Subject: [M3devel] more crashers In-Reply-To: References: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> Message-ID: Here is the relevant code in m3browser ID.m3: C:\dev2\cm3.2\m3-tools\m3markup\src\ID.m3(38): empty_id := Add (""); empty_id := Add (""); (*-------------------------------------------------------------- exported ---*) PROCEDURE Add (x: TEXT): T = VAR t: T; a: REF ARRAY OF CHAR; l: INTEGER; BEGIN l := Text.Length(x); ... END Add; The empty string constant ends up as null. .stabn 68,0,38,.LM115-.LFBB10 .LM115: movl L_1 at GOT(%ebx), %eax leal 24(%eax), %eax movl %eax, (%esp) call ID__Add at PLT movl %eax, -8(%ebp) movl -8(%ebp), %ecx movl MM_ID at GOT(%ebx), %edx movl 248(%edx), %eax andl $0, %eax orl %ecx, %eax movl %eax, 248(%edx) .L136: movl MM_ID at GOT(%ebx), %eax .LBE16: addl $52, %esp popl %ebx popl %ebp ret L_1: 0 .long RTHooks__TextLitInfo 4 .long RTHooks__TextLitGetChar 8 .long RTHooks__TextLitGetWideChar 12 .long RTHooks__TextLitGetChars 16 .long RTHooks__TextLitGetWideChars 20 .long 2 24 .long L_1 .long 0 .zero 4 .ascii "ID_M3" .zero 1 .ascii "ExpandHashTable" .zero 1 .ascii "ExpandIDs" .zero 1 .ascii "ExpandChars" .zero 1 .ascii "Compare" .zero 1 If I change "" to "foo", I get: L_1: 0 .long RTHooks__TextLitInfo 4 .long RTHooks__TextLitGetChar 8 .long RTHooks__TextLitGetWideChar 12 .long RTHooks__TextLitGetChars 16 .long RTHooks__TextLitGetWideChars 20 .long 2 24 .long L_1 .long 3 .ascii "foo" .zero 1 .ascii "ID_M3" and it still crashes. It seems to hit ID__Add twice when only once would be expected. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Sun, 16 Aug 2009 19:33:34 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] more crashers > > > Could be. I've also seen it on PPC_DARWIN a while ago. I only recall seeing it on sparc and ppc. > It doesn't always occur. > > > Here is the m3browser crash on a system that can be debugged. > See why I want the full paths in the debug info? > > > C:\Users\jay\Desktop>\cygwin\bin\ssh xobsd. > $ cd /cm3 > $ cd bin > $ export DISPLAY=192.168.1.120:0.0 > $ gdb ./m3browser > GNU gdb 6.3 > This GDB was configured as "i386-unknown-openbsd4.5"... > (gdb) r > Starting program: /home/jay/cm3/bin/m3browser > Program received signal SIGSEGV, Segmentation fault. > [Switching to process 31063, thread 0x7eafe800] > 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 > 16 t.get_info (i); > (gdb) bt > #0 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 > #1 0x09fd9464 in ID__Add (M3_Bd56fi_x=0x0) at ../src/ID.m3:48 > #2 0x1c01e644 in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:37 > #3 0x0156f1bc in RTLinker__RunMainBody (M3_DjPxE3_m=0x3c003ec0) > at ../src/runtime/common/RTLinker.m3:399 > #4 0x0156e576 in RTLinker__AddUnitI (M3_DjPxE3_m=0x3c003ec0) > at ../src/runtime/common/RTLinker.m3:113 > #5 0x0156e604 in RTLinker__AddUnit (M3_DjPxE5_b=0x1c01e54d) > at ../src/runtime/common/RTLinker.m3:122 > #6 0x1c004676 in main (argc=1, argv=0xcfbf6a3c, envp=0xcfbf6a44) > at _m3main.mc:4 > > > - Jay > > > ________________________________ >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Sun, 16 Aug 2009 15:26:49 -0400 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] more crashers >> >> Could this be endianness-related? >> >> On 16 Aug 2009, at 15:21, Jay K wrote: >> >> >> I see the assertion failure on PPC_LINUX too. >> I tried VAR defaultStackSize := 1024 * 1024; (not sure why there was any suspicion of stack size). >> >> >> Debugging doesn't work PPC_LINUX. >> >> >> jay at plin:/cm3/bin$ gdb ./cm3 >> GNU gdb 6.8-debian >> Copyright (C) 2008 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >> and "show warranty" for details. >> This GDB was configured as "powerpc-linux-gnu"... >> break ma(gdb) break main >> Breakpoint 1 at 0x86fc4: file _m3main.mc, line 2. >> (gdb) r >> Starting program: /home/jay/cm3/bin/cm3 >> Warning: >> Cannot insert breakpoint 1. >> Error accessing memory address 0x86fc4: Input/output error. >> >> >> No problem with C: >> >> >> jay at plin:/cm3/bin$ echo "main(){}"> 1.c >> jay at plin:/cm3/bin$ gcc -g 1.c >> jay at plin:/cm3/bin$ gdb ./a.out >> GNU gdb 6.8-debian >> Copyright (C) 2008 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >> and "show warranty" for details. >> This GDB was configured as "powerpc-linux-gnu"... >> (gdb) break main >> Breakpoint 1 at 0x10000448: file 1.c, line 1. >> (gdb) r >> Starting program: /home/jay/cm3/bin/a.out >> Breakpoint 1, main () at 1.c:1 >> 1 main(){} >> (gdb) >> >> >> jay at plin:/cm3/bin$ gcc -gstabs+ 1.c >> jay at plin:/cm3/bin$ gdb ./a.out >> GNU gdb 6.8-debian >> Copyright (C) 2008 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >> and "show warranty" for details. >> This GDB was configured as "powerpc-linux-gnu"... >> (gdb) break main >> Breakpoint 1 at 0x10000448: file 1.c, line 1. >> (gdb) r >> Starting program: /home/jay/cm3/bin/a.out >> Breakpoint 1, main () at 1.c:1 >> 1 main(){} >> >> >> jay at plin:/cm3/bin$ gcc -gstabs 1.c >> jay at plin:/cm3/bin$ gdb ./a.out >> GNU gdb 6.8-debian >> Copyright (C) 2008 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >> and "show warranty" for details. >> This GDB was configured as "powerpc-linux-gnu"... >> (gdb) break main >> Breakpoint 1 at 0x10000448: file 1.c, line 1. >> (gdb) r >> Starting program: /home/jay/cm3/bin/a.out >> Breakpoint 1, main () at 1.c:1 >> 1 main(){} >> (gdb) >> >> >> - Jay >> >> >> ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Subject: more crashers >> Date: Sun, 16 Aug 2009 10:06:15 +0000 >> >> >> This is head on SOLgnu: >> I'll try another and debug and see if fix is easy. >> >> -bash-3.00$ ./m3browser >> >> *** >> *** runtime error: >> *** Segmentation violation - possible attempt to dereference NIL >> *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/String16.m3 >> *** >> >> -bash-3.00$ ./visobliq >> Internal Obliq interpreter installed... >> Establishing 'templates' >> (Created frame 'templates') >> let >> Templates = >> {boolean=> ... , >> browser=> ... , >> button=> ... , >> choice=> ... , >> filebrowser=> ... , >> form=> ... , >> frame=> ... , >> hscroll=> ... , >> menu=> ... , >> numeric=> ... , >> text=> ... , >> textedit=> ... , >> typein=> ... , >> video=> ... , >> vscroll=> ... } >> Establishing 'vowidgets' >> (Created frame 'vowidgets') >> ok >> Establishing 'vocheckpt' >> (Created frame 'vocheckpt') >> ok >> Establishing 'volib' >> (Created frame 'volib') >> Segmentation Fault (core dumped) >> -bash-3.00$ >> >> From jay.krell at cornell.edu Sun Aug 16 22:22:49 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 16 Aug 2009 20:22:49 +0000 Subject: [M3devel] more crashers In-Reply-To: References: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> Message-ID: sorry, this is simple. derived_dirs := IntList.List1 (ID.Add (MxConfig.Get("BUILD_DIR"))); - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Sun, 16 Aug 2009 19:52:03 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] more crashers > > > Here is the relevant code in m3browser ID.m3: > > > C:\dev2\cm3.2\m3-tools\m3markup\src\ID.m3(38): empty_id := Add (""); > > empty_id := Add (""); > > (*-------------------------------------------------------------- exported ---*) > PROCEDURE Add (x: TEXT): T = > VAR > t: T; > a: REF ARRAY OF CHAR; > l: INTEGER; > BEGIN > l := Text.Length(x); > ... > END Add; > > > The empty string constant ends up as null. > > .stabn 68,0,38,.LM115-.LFBB10 > .LM115: > movl L_1 at GOT(%ebx), %eax > leal 24(%eax), %eax > movl %eax, (%esp) > call ID__Add at PLT > movl %eax, -8(%ebp) > movl -8(%ebp), %ecx > movl MM_ID at GOT(%ebx), %edx > movl 248(%edx), %eax > andl $0, %eax > orl %ecx, %eax > movl %eax, 248(%edx) > .L136: > movl MM_ID at GOT(%ebx), %eax > .LBE16: > addl $52, %esp > popl %ebx > popl %ebp > ret > > L_1: > 0 .long RTHooks__TextLitInfo > 4 .long RTHooks__TextLitGetChar > 8 .long RTHooks__TextLitGetWideChar > 12 .long RTHooks__TextLitGetChars > 16 .long RTHooks__TextLitGetWideChars > 20 .long 2 > 24 .long L_1 > .long 0 > .zero 4 > .ascii "ID_M3" > .zero 1 > .ascii "ExpandHashTable" > .zero 1 > .ascii "ExpandIDs" > .zero 1 > .ascii "ExpandChars" > .zero 1 > .ascii "Compare" > .zero 1 > > If I change "" to "foo", I get: > > L_1: > 0 .long RTHooks__TextLitInfo > 4 .long RTHooks__TextLitGetChar > 8 .long RTHooks__TextLitGetWideChar > 12 .long RTHooks__TextLitGetChars > 16 .long RTHooks__TextLitGetWideChars > 20 .long 2 > 24 .long L_1 > .long 3 > .ascii "foo" > .zero 1 > .ascii "ID_M3" > > and it still crashes. > > > It seems to hit ID__Add twice when only once would be expected. > > > - Jay > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> Date: Sun, 16 Aug 2009 19:33:34 +0000 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] more crashers >> >> >> Could be. I've also seen it on PPC_DARWIN a while ago. I only recall seeing it on sparc and ppc. >> It doesn't always occur. >> >> >> Here is the m3browser crash on a system that can be debugged. >> See why I want the full paths in the debug info? >> >> >> C:\Users\jay\Desktop>\cygwin\bin\ssh xobsd. >> $ cd /cm3 >> $ cd bin >> $ export DISPLAY=192.168.1.120:0.0 >> $ gdb ./m3browser >> GNU gdb 6.3 >> This GDB was configured as "i386-unknown-openbsd4.5"... >> (gdb) r >> Starting program: /home/jay/cm3/bin/m3browser >> Program received signal SIGSEGV, Segmentation fault. >> [Switching to process 31063, thread 0x7eafe800] >> 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 >> 16 t.get_info (i); >> (gdb) bt >> #0 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 >> #1 0x09fd9464 in ID__Add (M3_Bd56fi_x=0x0) at ../src/ID.m3:48 >> #2 0x1c01e644 in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:37 >> #3 0x0156f1bc in RTLinker__RunMainBody (M3_DjPxE3_m=0x3c003ec0) >> at ../src/runtime/common/RTLinker.m3:399 >> #4 0x0156e576 in RTLinker__AddUnitI (M3_DjPxE3_m=0x3c003ec0) >> at ../src/runtime/common/RTLinker.m3:113 >> #5 0x0156e604 in RTLinker__AddUnit (M3_DjPxE5_b=0x1c01e54d) >> at ../src/runtime/common/RTLinker.m3:122 >> #6 0x1c004676 in main (argc=1, argv=0xcfbf6a3c, envp=0xcfbf6a44) >> at _m3main.mc:4 >> >> >> - Jay >> >> >> ________________________________ >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Date: Sun, 16 Aug 2009 15:26:49 -0400 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] more crashers >>> >>> Could this be endianness-related? >>> >>> On 16 Aug 2009, at 15:21, Jay K wrote: >>> >>> >>> I see the assertion failure on PPC_LINUX too. >>> I tried VAR defaultStackSize := 1024 * 1024; (not sure why there was any suspicion of stack size). >>> >>> >>> Debugging doesn't work PPC_LINUX. >>> >>> >>> jay at plin:/cm3/bin$ gdb ./cm3 >>> GNU gdb 6.8-debian >>> Copyright (C) 2008 Free Software Foundation, Inc. >>> License GPLv3+: GNU GPL version 3 or later >>> This is free software: you are free to change and redistribute it. >>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >>> and "show warranty" for details. >>> This GDB was configured as "powerpc-linux-gnu"... >>> break ma(gdb) break main >>> Breakpoint 1 at 0x86fc4: file _m3main.mc, line 2. >>> (gdb) r >>> Starting program: /home/jay/cm3/bin/cm3 >>> Warning: >>> Cannot insert breakpoint 1. >>> Error accessing memory address 0x86fc4: Input/output error. >>> >>> >>> No problem with C: >>> >>> >>> jay at plin:/cm3/bin$ echo "main(){}"> 1.c >>> jay at plin:/cm3/bin$ gcc -g 1.c >>> jay at plin:/cm3/bin$ gdb ./a.out >>> GNU gdb 6.8-debian >>> Copyright (C) 2008 Free Software Foundation, Inc. >>> License GPLv3+: GNU GPL version 3 or later >>> This is free software: you are free to change and redistribute it. >>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >>> and "show warranty" for details. >>> This GDB was configured as "powerpc-linux-gnu"... >>> (gdb) break main >>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>> (gdb) r >>> Starting program: /home/jay/cm3/bin/a.out >>> Breakpoint 1, main () at 1.c:1 >>> 1 main(){} >>> (gdb) >>> >>> >>> jay at plin:/cm3/bin$ gcc -gstabs+ 1.c >>> jay at plin:/cm3/bin$ gdb ./a.out >>> GNU gdb 6.8-debian >>> Copyright (C) 2008 Free Software Foundation, Inc. >>> License GPLv3+: GNU GPL version 3 or later >>> This is free software: you are free to change and redistribute it. >>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >>> and "show warranty" for details. >>> This GDB was configured as "powerpc-linux-gnu"... >>> (gdb) break main >>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>> (gdb) r >>> Starting program: /home/jay/cm3/bin/a.out >>> Breakpoint 1, main () at 1.c:1 >>> 1 main(){} >>> >>> >>> jay at plin:/cm3/bin$ gcc -gstabs 1.c >>> jay at plin:/cm3/bin$ gdb ./a.out >>> GNU gdb 6.8-debian >>> Copyright (C) 2008 Free Software Foundation, Inc. >>> License GPLv3+: GNU GPL version 3 or later >>> This is free software: you are free to change and redistribute it. >>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >>> and "show warranty" for details. >>> This GDB was configured as "powerpc-linux-gnu"... >>> (gdb) break main >>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>> (gdb) r >>> Starting program: /home/jay/cm3/bin/a.out >>> Breakpoint 1, main () at 1.c:1 >>> 1 main(){} >>> (gdb) >>> >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: m3devel at elegosoft.com >>> Subject: more crashers >>> Date: Sun, 16 Aug 2009 10:06:15 +0000 >>> >>> >>> This is head on SOLgnu: >>> I'll try another and debug and see if fix is easy. >>> >>> -bash-3.00$ ./m3browser >>> >>> *** >>> *** runtime error: >>> *** Segmentation violation - possible attempt to dereference NIL >>> *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/String16.m3 >>> *** >>> >>> -bash-3.00$ ./visobliq >>> Internal Obliq interpreter installed... >>> Establishing 'templates' >>> (Created frame 'templates') >>> let >>> Templates = >>> {boolean=> ... , >>> browser=> ... , >>> button=> ... , >>> choice=> ... , >>> filebrowser=> ... , >>> form=> ... , >>> frame=> ... , >>> hscroll=> ... , >>> menu=> ... , >>> numeric=> ... , >>> text=> ... , >>> textedit=> ... , >>> typein=> ... , >>> video=> ... , >>> vscroll=> ... } >>> Establishing 'vowidgets' >>> (Created frame 'vowidgets') >>> ok >>> Establishing 'vocheckpt' >>> (Created frame 'vocheckpt') >>> ok >>> Establishing 'volib' >>> (Created frame 'volib') >>> Segmentation Fault (core dumped) >>> -bash-3.00$ >>> >>> From jay.krell at cornell.edu Sun Aug 16 22:32:31 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 16 Aug 2009 20:32:31 +0000 Subject: [M3devel] more crashers In-Reply-To: References: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> Message-ID: m3browser: It is specific to my config file m3-sys/cminstall/src/config-no-install/cm3.cfg that reachs back into the source tree. It won't happen with what most people do. I have to do that M3Predefines or such work so that all the uses of m3quake besides cm3 are much more like cm3. visobliq: not the same thing Does not occur on Linux/x86 or Linux/sparc. They do print Syntax error just before: -helvetica-bold-\*R-\*240-\*\") (LabelFo ... ill-formed character escape sequence Error detected (file file generated by Visual Obliq) (line 18, char 10) VideoVBT.Start Jv ServerFailure:errno=0 but then gui comes up. I'll have to finish my Solaris reinstall and get dbx. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Sun, 16 Aug 2009 20:22:49 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] more crashers > > > sorry, this is simple. > > derived_dirs := IntList.List1 (ID.Add (MxConfig.Get("BUILD_DIR"))); > > > - Jay > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> Date: Sun, 16 Aug 2009 19:52:03 +0000 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] more crashers >> >> >> Here is the relevant code in m3browser ID.m3: >> >> >> C:\dev2\cm3.2\m3-tools\m3markup\src\ID.m3(38): empty_id := Add (""); >> >> empty_id := Add (""); >> >> (*-------------------------------------------------------------- exported ---*) >> PROCEDURE Add (x: TEXT): T = >> VAR >> t: T; >> a: REF ARRAY OF CHAR; >> l: INTEGER; >> BEGIN >> l := Text.Length(x); >> ... >> END Add; >> >> >> The empty string constant ends up as null. >> >> .stabn 68,0,38,.LM115-.LFBB10 >> .LM115: >> movl L_1 at GOT(%ebx), %eax >> leal 24(%eax), %eax >> movl %eax, (%esp) >> call ID__Add at PLT >> movl %eax, -8(%ebp) >> movl -8(%ebp), %ecx >> movl MM_ID at GOT(%ebx), %edx >> movl 248(%edx), %eax >> andl $0, %eax >> orl %ecx, %eax >> movl %eax, 248(%edx) >> .L136: >> movl MM_ID at GOT(%ebx), %eax >> .LBE16: >> addl $52, %esp >> popl %ebx >> popl %ebp >> ret >> >> L_1: >> 0 .long RTHooks__TextLitInfo >> 4 .long RTHooks__TextLitGetChar >> 8 .long RTHooks__TextLitGetWideChar >> 12 .long RTHooks__TextLitGetChars >> 16 .long RTHooks__TextLitGetWideChars >> 20 .long 2 >> 24 .long L_1 >> .long 0 >> .zero 4 >> .ascii "ID_M3" >> .zero 1 >> .ascii "ExpandHashTable" >> .zero 1 >> .ascii "ExpandIDs" >> .zero 1 >> .ascii "ExpandChars" >> .zero 1 >> .ascii "Compare" >> .zero 1 >> >> If I change "" to "foo", I get: >> >> L_1: >> 0 .long RTHooks__TextLitInfo >> 4 .long RTHooks__TextLitGetChar >> 8 .long RTHooks__TextLitGetWideChar >> 12 .long RTHooks__TextLitGetChars >> 16 .long RTHooks__TextLitGetWideChars >> 20 .long 2 >> 24 .long L_1 >> .long 3 >> .ascii "foo" >> .zero 1 >> .ascii "ID_M3" >> >> and it still crashes. >> >> >> It seems to hit ID__Add twice when only once would be expected. >> >> >> - Jay >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu >>> Date: Sun, 16 Aug 2009 19:33:34 +0000 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] more crashers >>> >>> >>> Could be. I've also seen it on PPC_DARWIN a while ago. I only recall seeing it on sparc and ppc. >>> It doesn't always occur. >>> >>> >>> Here is the m3browser crash on a system that can be debugged. >>> See why I want the full paths in the debug info? >>> >>> >>> C:\Users\jay\Desktop>\cygwin\bin\ssh xobsd. >>> $ cd /cm3 >>> $ cd bin >>> $ export DISPLAY=192.168.1.120:0.0 >>> $ gdb ./m3browser >>> GNU gdb 6.3 >>> This GDB was configured as "i386-unknown-openbsd4.5"... >>> (gdb) r >>> Starting program: /home/jay/cm3/bin/m3browser >>> Program received signal SIGSEGV, Segmentation fault. >>> [Switching to process 31063, thread 0x7eafe800] >>> 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 >>> 16 t.get_info (i); >>> (gdb) bt >>> #0 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 >>> #1 0x09fd9464 in ID__Add (M3_Bd56fi_x=0x0) at ../src/ID.m3:48 >>> #2 0x1c01e644 in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:37 >>> #3 0x0156f1bc in RTLinker__RunMainBody (M3_DjPxE3_m=0x3c003ec0) >>> at ../src/runtime/common/RTLinker.m3:399 >>> #4 0x0156e576 in RTLinker__AddUnitI (M3_DjPxE3_m=0x3c003ec0) >>> at ../src/runtime/common/RTLinker.m3:113 >>> #5 0x0156e604 in RTLinker__AddUnit (M3_DjPxE5_b=0x1c01e54d) >>> at ../src/runtime/common/RTLinker.m3:122 >>> #6 0x1c004676 in main (argc=1, argv=0xcfbf6a3c, envp=0xcfbf6a44) >>> at _m3main.mc:4 >>> >>> >>> - Jay >>> >>> >>> ________________________________ >>>> From: hosking at cs.purdue.edu >>>> To: jay.krell at cornell.edu >>>> Date: Sun, 16 Aug 2009 15:26:49 -0400 >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] more crashers >>>> >>>> Could this be endianness-related? >>>> >>>> On 16 Aug 2009, at 15:21, Jay K wrote: >>>> >>>> >>>> I see the assertion failure on PPC_LINUX too. >>>> I tried VAR defaultStackSize := 1024 * 1024; (not sure why there was any suspicion of stack size). >>>> >>>> >>>> Debugging doesn't work PPC_LINUX. >>>> >>>> >>>> jay at plin:/cm3/bin$ gdb ./cm3 >>>> GNU gdb 6.8-debian >>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>> License GPLv3+: GNU GPL version 3 or later >>>> This is free software: you are free to change and redistribute it. >>>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >>>> and "show warranty" for details. >>>> This GDB was configured as "powerpc-linux-gnu"... >>>> break ma(gdb) break main >>>> Breakpoint 1 at 0x86fc4: file _m3main.mc, line 2. >>>> (gdb) r >>>> Starting program: /home/jay/cm3/bin/cm3 >>>> Warning: >>>> Cannot insert breakpoint 1. >>>> Error accessing memory address 0x86fc4: Input/output error. >>>> >>>> >>>> No problem with C: >>>> >>>> >>>> jay at plin:/cm3/bin$ echo "main(){}"> 1.c >>>> jay at plin:/cm3/bin$ gcc -g 1.c >>>> jay at plin:/cm3/bin$ gdb ./a.out >>>> GNU gdb 6.8-debian >>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>> License GPLv3+: GNU GPL version 3 or later >>>> This is free software: you are free to change and redistribute it. >>>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >>>> and "show warranty" for details. >>>> This GDB was configured as "powerpc-linux-gnu"... >>>> (gdb) break main >>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>> (gdb) r >>>> Starting program: /home/jay/cm3/bin/a.out >>>> Breakpoint 1, main () at 1.c:1 >>>> 1 main(){} >>>> (gdb) >>>> >>>> >>>> jay at plin:/cm3/bin$ gcc -gstabs+ 1.c >>>> jay at plin:/cm3/bin$ gdb ./a.out >>>> GNU gdb 6.8-debian >>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>> License GPLv3+: GNU GPL version 3 or later >>>> This is free software: you are free to change and redistribute it. >>>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >>>> and "show warranty" for details. >>>> This GDB was configured as "powerpc-linux-gnu"... >>>> (gdb) break main >>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>> (gdb) r >>>> Starting program: /home/jay/cm3/bin/a.out >>>> Breakpoint 1, main () at 1.c:1 >>>> 1 main(){} >>>> >>>> >>>> jay at plin:/cm3/bin$ gcc -gstabs 1.c >>>> jay at plin:/cm3/bin$ gdb ./a.out >>>> GNU gdb 6.8-debian >>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>> License GPLv3+: GNU GPL version 3 or later >>>> This is free software: you are free to change and redistribute it. >>>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >>>> and "show warranty" for details. >>>> This GDB was configured as "powerpc-linux-gnu"... >>>> (gdb) break main >>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>> (gdb) r >>>> Starting program: /home/jay/cm3/bin/a.out >>>> Breakpoint 1, main () at 1.c:1 >>>> 1 main(){} >>>> (gdb) >>>> >>>> >>>> - Jay >>>> >>>> >>>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: m3devel at elegosoft.com >>>> Subject: more crashers >>>> Date: Sun, 16 Aug 2009 10:06:15 +0000 >>>> >>>> >>>> This is head on SOLgnu: >>>> I'll try another and debug and see if fix is easy. >>>> >>>> -bash-3.00$ ./m3browser >>>> >>>> *** >>>> *** runtime error: >>>> *** Segmentation violation - possible attempt to dereference NIL >>>> *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/String16.m3 >>>> *** >>>> >>>> -bash-3.00$ ./visobliq >>>> Internal Obliq interpreter installed... >>>> Establishing 'templates' >>>> (Created frame 'templates') >>>> let >>>> Templates = >>>> {boolean=> ... , >>>> browser=> ... , >>>> button=> ... , >>>> choice=> ... , >>>> filebrowser=> ... , >>>> form=> ... , >>>> frame=> ... , >>>> hscroll=> ... , >>>> menu=> ... , >>>> numeric=> ... , >>>> text=> ... , >>>> textedit=> ... , >>>> typein=> ... , >>>> video=> ... , >>>> vscroll=> ... } >>>> Establishing 'vowidgets' >>>> (Created frame 'vowidgets') >>>> ok >>>> Establishing 'vocheckpt' >>>> (Created frame 'vocheckpt') >>>> ok >>>> Establishing 'volib' >>>> (Created frame 'volib') >>>> Segmentation Fault (core dumped) >>>> -bash-3.00$ >>>> >>>> From hosking at cs.purdue.edu Mon Aug 17 01:10:15 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 16 Aug 2009 19:10:15 -0400 Subject: [M3devel] more crashers In-Reply-To: References: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> Message-ID: So now I am worried about the recent changes to Text... On 16 Aug 2009, at 15:33, Jay K wrote: > > Could be. I've also seen it on PPC_DARWIN a while ago. I only recall > seeing it on sparc and ppc. > It doesn't always occur. > > > Here is the m3browser crash on a system that can be debugged. > See why I want the full paths in the debug info? > > > C:\Users\jay\Desktop>\cygwin\bin\ssh xobsd. > $ cd /cm3 > $ cd bin > $ export DISPLAY=192.168.1.120:0.0 > $ gdb ./m3browser > GNU gdb 6.3 > This GDB was configured as "i386-unknown-openbsd4.5"... > (gdb) r > Starting program: /home/jay/cm3/bin/m3browser > Program received signal SIGSEGV, Segmentation fault. > [Switching to process 31063, thread 0x7eafe800] > 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 > 16 t.get_info (i); > (gdb) bt > #0 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/ > Text.m3:16 > #1 0x09fd9464 in ID__Add (M3_Bd56fi_x=0x0) at ../src/ID.m3:48 > #2 0x1c01e644 in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:37 > #3 0x0156f1bc in RTLinker__RunMainBody (M3_DjPxE3_m=0x3c003ec0) > at ../src/runtime/common/RTLinker.m3:399 > #4 0x0156e576 in RTLinker__AddUnitI (M3_DjPxE3_m=0x3c003ec0) > at ../src/runtime/common/RTLinker.m3:113 > #5 0x0156e604 in RTLinker__AddUnit (M3_DjPxE5_b=0x1c01e54d) > at ../src/runtime/common/RTLinker.m3:122 > #6 0x1c004676 in main (argc=1, argv=0xcfbf6a3c, envp=0xcfbf6a44) > at _m3main.mc:4 > > > - Jay > > > ________________________________ >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Sun, 16 Aug 2009 15:26:49 -0400 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] more crashers >> >> Could this be endianness-related? >> >> On 16 Aug 2009, at 15:21, Jay K wrote: >> >> >> I see the assertion failure on PPC_LINUX too. >> I tried VAR defaultStackSize := 1024 * 1024; (not sure why there >> was any suspicion of stack size). >> >> >> Debugging doesn't work PPC_LINUX. >> >> >> jay at plin:/cm3/bin$ gdb ./cm3 >> GNU gdb 6.8-debian >> Copyright (C) 2008 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. Type "show >> copying" >> and "show warranty" for details. >> This GDB was configured as "powerpc-linux-gnu"... >> break ma(gdb) break main >> Breakpoint 1 at 0x86fc4: file _m3main.mc, line 2. >> (gdb) r >> Starting program: /home/jay/cm3/bin/cm3 >> Warning: >> Cannot insert breakpoint 1. >> Error accessing memory address 0x86fc4: Input/output error. >> >> >> No problem with C: >> >> >> jay at plin:/cm3/bin$ echo "main(){}"> 1.c >> jay at plin:/cm3/bin$ gcc -g 1.c >> jay at plin:/cm3/bin$ gdb ./a.out >> GNU gdb 6.8-debian >> Copyright (C) 2008 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. Type "show >> copying" >> and "show warranty" for details. >> This GDB was configured as "powerpc-linux-gnu"... >> (gdb) break main >> Breakpoint 1 at 0x10000448: file 1.c, line 1. >> (gdb) r >> Starting program: /home/jay/cm3/bin/a.out >> Breakpoint 1, main () at 1.c:1 >> 1 main(){} >> (gdb) >> >> >> jay at plin:/cm3/bin$ gcc -gstabs+ 1.c >> jay at plin:/cm3/bin$ gdb ./a.out >> GNU gdb 6.8-debian >> Copyright (C) 2008 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. Type "show >> copying" >> and "show warranty" for details. >> This GDB was configured as "powerpc-linux-gnu"... >> (gdb) break main >> Breakpoint 1 at 0x10000448: file 1.c, line 1. >> (gdb) r >> Starting program: /home/jay/cm3/bin/a.out >> Breakpoint 1, main () at 1.c:1 >> 1 main(){} >> >> >> jay at plin:/cm3/bin$ gcc -gstabs 1.c >> jay at plin:/cm3/bin$ gdb ./a.out >> GNU gdb 6.8-debian >> Copyright (C) 2008 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. Type "show >> copying" >> and "show warranty" for details. >> This GDB was configured as "powerpc-linux-gnu"... >> (gdb) break main >> Breakpoint 1 at 0x10000448: file 1.c, line 1. >> (gdb) r >> Starting program: /home/jay/cm3/bin/a.out >> Breakpoint 1, main () at 1.c:1 >> 1 main(){} >> (gdb) >> >> >> - Jay >> >> >> ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Subject: more crashers >> Date: Sun, 16 Aug 2009 10:06:15 +0000 >> >> >> This is head on SOLgnu: >> I'll try another and debug and see if fix is easy. >> >> -bash-3.00$ ./m3browser >> >> *** >> *** runtime error: >> *** Segmentation violation - possible attempt to dereference NIL >> *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/String16.m3 >> *** >> >> -bash-3.00$ ./visobliq >> Internal Obliq interpreter installed... >> Establishing 'templates' >> (Created frame 'templates') >> let >> Templates = >> {boolean=> ... , >> browser=> ... , >> button=> ... , >> choice=> ... , >> filebrowser=> ... , >> form=> ... , >> frame=> ... , >> hscroll=> ... , >> menu=> ... , >> numeric=> ... , >> text=> ... , >> textedit=> ... , >> typein=> ... , >> video=> ... , >> vscroll=> ... } >> Establishing 'vowidgets' >> (Created frame 'vowidgets') >> ok >> Establishing 'vocheckpt' >> (Created frame 'vocheckpt') >> ok >> Establishing 'volib' >> (Created frame 'volib') >> Segmentation Fault (core dumped) >> -bash-3.00$ >> >> From jay.krell at cornell.edu Mon Aug 17 03:14:02 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 17 Aug 2009 01:14:02 +0000 Subject: [M3devel] more crashers In-Reply-To: References: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> Message-ID: Don't worry because of this. This was changing folks from M3Config to MxConfig plus that my config doesn't go out of its way to be compatible with code that doesn't predefine stuff -- ie: mxconfig clients other than cm3. The "normal" config files have been adapted to be compatible. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Sun, 16 Aug 2009 19:10:15 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] more crashers > > So now I am worried about the recent changes to Text... > > On 16 Aug 2009, at 15:33, Jay K wrote: > >> >> Could be. I've also seen it on PPC_DARWIN a while ago. I only recall >> seeing it on sparc and ppc. >> It doesn't always occur. >> >> >> Here is the m3browser crash on a system that can be debugged. >> See why I want the full paths in the debug info? >> >> >> C:\Users\jay\Desktop>\cygwin\bin\ssh xobsd. >> $ cd /cm3 >> $ cd bin >> $ export DISPLAY=192.168.1.120:0.0 >> $ gdb ./m3browser >> GNU gdb 6.3 >> This GDB was configured as "i386-unknown-openbsd4.5"... >> (gdb) r >> Starting program: /home/jay/cm3/bin/m3browser >> Program received signal SIGSEGV, Segmentation fault. >> [Switching to process 31063, thread 0x7eafe800] >> 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 >> 16 t.get_info (i); >> (gdb) bt >> #0 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/ >> Text.m3:16 >> #1 0x09fd9464 in ID__Add (M3_Bd56fi_x=0x0) at ../src/ID.m3:48 >> #2 0x1c01e644 in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:37 >> #3 0x0156f1bc in RTLinker__RunMainBody (M3_DjPxE3_m=0x3c003ec0) >> at ../src/runtime/common/RTLinker.m3:399 >> #4 0x0156e576 in RTLinker__AddUnitI (M3_DjPxE3_m=0x3c003ec0) >> at ../src/runtime/common/RTLinker.m3:113 >> #5 0x0156e604 in RTLinker__AddUnit (M3_DjPxE5_b=0x1c01e54d) >> at ../src/runtime/common/RTLinker.m3:122 >> #6 0x1c004676 in main (argc=1, argv=0xcfbf6a3c, envp=0xcfbf6a44) >> at _m3main.mc:4 >> >> >> - Jay >> >> >> ________________________________ >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Date: Sun, 16 Aug 2009 15:26:49 -0400 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] more crashers >>> >>> Could this be endianness-related? >>> >>> On 16 Aug 2009, at 15:21, Jay K wrote: >>> >>> >>> I see the assertion failure on PPC_LINUX too. >>> I tried VAR defaultStackSize := 1024 * 1024; (not sure why there >>> was any suspicion of stack size). >>> >>> >>> Debugging doesn't work PPC_LINUX. >>> >>> >>> jay at plin:/cm3/bin$ gdb ./cm3 >>> GNU gdb 6.8-debian >>> Copyright (C) 2008 Free Software Foundation, Inc. >>> License GPLv3+: GNU GPL version 3 or later >>> This is free software: you are free to change and redistribute it. >>> There is NO WARRANTY, to the extent permitted by law. Type "show >>> copying" >>> and "show warranty" for details. >>> This GDB was configured as "powerpc-linux-gnu"... >>> break ma(gdb) break main >>> Breakpoint 1 at 0x86fc4: file _m3main.mc, line 2. >>> (gdb) r >>> Starting program: /home/jay/cm3/bin/cm3 >>> Warning: >>> Cannot insert breakpoint 1. >>> Error accessing memory address 0x86fc4: Input/output error. >>> >>> >>> No problem with C: >>> >>> >>> jay at plin:/cm3/bin$ echo "main(){}"> 1.c >>> jay at plin:/cm3/bin$ gcc -g 1.c >>> jay at plin:/cm3/bin$ gdb ./a.out >>> GNU gdb 6.8-debian >>> Copyright (C) 2008 Free Software Foundation, Inc. >>> License GPLv3+: GNU GPL version 3 or later >>> This is free software: you are free to change and redistribute it. >>> There is NO WARRANTY, to the extent permitted by law. Type "show >>> copying" >>> and "show warranty" for details. >>> This GDB was configured as "powerpc-linux-gnu"... >>> (gdb) break main >>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>> (gdb) r >>> Starting program: /home/jay/cm3/bin/a.out >>> Breakpoint 1, main () at 1.c:1 >>> 1 main(){} >>> (gdb) >>> >>> >>> jay at plin:/cm3/bin$ gcc -gstabs+ 1.c >>> jay at plin:/cm3/bin$ gdb ./a.out >>> GNU gdb 6.8-debian >>> Copyright (C) 2008 Free Software Foundation, Inc. >>> License GPLv3+: GNU GPL version 3 or later >>> This is free software: you are free to change and redistribute it. >>> There is NO WARRANTY, to the extent permitted by law. Type "show >>> copying" >>> and "show warranty" for details. >>> This GDB was configured as "powerpc-linux-gnu"... >>> (gdb) break main >>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>> (gdb) r >>> Starting program: /home/jay/cm3/bin/a.out >>> Breakpoint 1, main () at 1.c:1 >>> 1 main(){} >>> >>> >>> jay at plin:/cm3/bin$ gcc -gstabs 1.c >>> jay at plin:/cm3/bin$ gdb ./a.out >>> GNU gdb 6.8-debian >>> Copyright (C) 2008 Free Software Foundation, Inc. >>> License GPLv3+: GNU GPL version 3 or later >>> This is free software: you are free to change and redistribute it. >>> There is NO WARRANTY, to the extent permitted by law. Type "show >>> copying" >>> and "show warranty" for details. >>> This GDB was configured as "powerpc-linux-gnu"... >>> (gdb) break main >>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>> (gdb) r >>> Starting program: /home/jay/cm3/bin/a.out >>> Breakpoint 1, main () at 1.c:1 >>> 1 main(){} >>> (gdb) >>> >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: m3devel at elegosoft.com >>> Subject: more crashers >>> Date: Sun, 16 Aug 2009 10:06:15 +0000 >>> >>> >>> This is head on SOLgnu: >>> I'll try another and debug and see if fix is easy. >>> >>> -bash-3.00$ ./m3browser >>> >>> *** >>> *** runtime error: >>> *** Segmentation violation - possible attempt to dereference NIL >>> *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/String16.m3 >>> *** >>> >>> -bash-3.00$ ./visobliq >>> Internal Obliq interpreter installed... >>> Establishing 'templates' >>> (Created frame 'templates') >>> let >>> Templates = >>> {boolean=> ... , >>> browser=> ... , >>> button=> ... , >>> choice=> ... , >>> filebrowser=> ... , >>> form=> ... , >>> frame=> ... , >>> hscroll=> ... , >>> menu=> ... , >>> numeric=> ... , >>> text=> ... , >>> textedit=> ... , >>> typein=> ... , >>> video=> ... , >>> vscroll=> ... } >>> Establishing 'vowidgets' >>> (Created frame 'vowidgets') >>> ok >>> Establishing 'vocheckpt' >>> (Created frame 'vocheckpt') >>> ok >>> Establishing 'volib' >>> (Created frame 'volib') >>> Segmentation Fault (core dumped) >>> -bash-3.00$ >>> >>> > From jay.krell at cornell.edu Mon Aug 17 03:33:03 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 17 Aug 2009 01:33:03 +0000 Subject: [M3devel] Errors building Juno on PPC_LINUX (Debian 5) Message-ID: > I'm going to rebuild m3cc clean Did not reoccur after that. Possibly some mismatch with an cm3cg built on Debian 4 vs. Debian 5's binutils. Though that only really makes sense for one of the errors. (Debian 5 has nice property of Sun Java being available for all but hppa, good for Hudson's sake.) - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: Errors building Juno on PPC_LINUX (Debian 5) > Date: Sun, 16 Aug 2009 19:27:03 +0000 > > > Errors building Juno on PPC_LINUX (Debian 5) > > == package /home/jay/dev2/cm3/m3-ui/juno-2/juno-app == > +++ /cm3/bin/cm3 -build -DROOT=/home/jay/dev2/cm3 -DCM3_VERSION_TEXT=d5.8.2 -D > CM3_VERSION_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ > --- building in PPC_LINUX --- > ... > new source -> compiling Editor.m3 > ../src/Editor.m3: In function 'Editor__Parse2': > ../src/Editor.m3:248: fatal error: *** bad opcode: 0x229, at m3cg_lineno 18629 > compilation terminated. > m3_backend => 1 > m3cc (aka cm3cg) failed compiling: Editor.mc > new opaque info -> recompiling Drag.m3 > Drag.ms: Assembler messages: > Drag.ms:3949: Error: unknown pseudo-op: `.s' > assemble => 1 > assembler failed assembling: Drag.ms > *** execution of [, ] failed *** > jay at plin:/dev2/cm3/scripts/python$ > > > More details to follow. > I'm going to rebuild m3cc clean, make sure it was built native not copied from another machine, but I think it already was native. > > > - Jay From jay.krell at cornell.edu Mon Aug 17 06:01:01 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 17 Aug 2009 04:01:01 +0000 Subject: [M3devel] more crashers In-Reply-To: References: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> Message-ID: visobliq was stack overflow. Raising the default from 4K to 16K didn't fix, but 32K did. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] more crashers > Date: Sun, 16 Aug 2009 20:32:31 +0000 > > > m3browser: > > It is specific to my config file m3-sys/cminstall/src/config-no-install/cm3.cfg that reachs back into the source tree. It won't happen with what most people do. I have to do that M3Predefines or such work so that all the uses of m3quake besides cm3 are much more like cm3. > > > visobliq: > not the same thing > Does not occur on Linux/x86 or Linux/sparc. > They do print > Syntax error just before: -helvetica-bold-\*R-\*240-\*\") (LabelFo ... > ill-formed character escape sequence > Error detected (file file generated by Visual Obliq) (line 18, char 10) > VideoVBT.Start Jv ServerFailure:errno=0 > > but then gui comes up. > I'll have to finish my Solaris reinstall and get dbx. > > > - Jay > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> Date: Sun, 16 Aug 2009 20:22:49 +0000 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] more crashers >> >> >> sorry, this is simple. >> >> derived_dirs := IntList.List1 (ID.Add (MxConfig.Get("BUILD_DIR"))); >> >> >> - Jay >> >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu >>> Date: Sun, 16 Aug 2009 19:52:03 +0000 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] more crashers >>> >>> >>> Here is the relevant code in m3browser ID.m3: >>> >>> >>> C:\dev2\cm3.2\m3-tools\m3markup\src\ID.m3(38): empty_id := Add (""); >>> >>> empty_id := Add (""); >>> >>> (*-------------------------------------------------------------- exported ---*) >>> PROCEDURE Add (x: TEXT): T = >>> VAR >>> t: T; >>> a: REF ARRAY OF CHAR; >>> l: INTEGER; >>> BEGIN >>> l := Text.Length(x); >>> ... >>> END Add; >>> >>> >>> The empty string constant ends up as null. >>> >>> .stabn 68,0,38,.LM115-.LFBB10 >>> .LM115: >>> movl L_1 at GOT(%ebx), %eax >>> leal 24(%eax), %eax >>> movl %eax, (%esp) >>> call ID__Add at PLT >>> movl %eax, -8(%ebp) >>> movl -8(%ebp), %ecx >>> movl MM_ID at GOT(%ebx), %edx >>> movl 248(%edx), %eax >>> andl $0, %eax >>> orl %ecx, %eax >>> movl %eax, 248(%edx) >>> .L136: >>> movl MM_ID at GOT(%ebx), %eax >>> .LBE16: >>> addl $52, %esp >>> popl %ebx >>> popl %ebp >>> ret >>> >>> L_1: >>> 0 .long RTHooks__TextLitInfo >>> 4 .long RTHooks__TextLitGetChar >>> 8 .long RTHooks__TextLitGetWideChar >>> 12 .long RTHooks__TextLitGetChars >>> 16 .long RTHooks__TextLitGetWideChars >>> 20 .long 2 >>> 24 .long L_1 >>> .long 0 >>> .zero 4 >>> .ascii "ID_M3" >>> .zero 1 >>> .ascii "ExpandHashTable" >>> .zero 1 >>> .ascii "ExpandIDs" >>> .zero 1 >>> .ascii "ExpandChars" >>> .zero 1 >>> .ascii "Compare" >>> .zero 1 >>> >>> If I change "" to "foo", I get: >>> >>> L_1: >>> 0 .long RTHooks__TextLitInfo >>> 4 .long RTHooks__TextLitGetChar >>> 8 .long RTHooks__TextLitGetWideChar >>> 12 .long RTHooks__TextLitGetChars >>> 16 .long RTHooks__TextLitGetWideChars >>> 20 .long 2 >>> 24 .long L_1 >>> .long 3 >>> .ascii "foo" >>> .zero 1 >>> .ascii "ID_M3" >>> >>> and it still crashes. >>> >>> >>> It seems to hit ID__Add twice when only once would be expected. >>> >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: hosking at cs.purdue.edu >>>> Date: Sun, 16 Aug 2009 19:33:34 +0000 >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] more crashers >>>> >>>> >>>> Could be. I've also seen it on PPC_DARWIN a while ago. I only recall seeing it on sparc and ppc. >>>> It doesn't always occur. >>>> >>>> >>>> Here is the m3browser crash on a system that can be debugged. >>>> See why I want the full paths in the debug info? >>>> >>>> >>>> C:\Users\jay\Desktop>\cygwin\bin\ssh xobsd. >>>> $ cd /cm3 >>>> $ cd bin >>>> $ export DISPLAY=192.168.1.120:0.0 >>>> $ gdb ./m3browser >>>> GNU gdb 6.3 >>>> This GDB was configured as "i386-unknown-openbsd4.5"... >>>> (gdb) r >>>> Starting program: /home/jay/cm3/bin/m3browser >>>> Program received signal SIGSEGV, Segmentation fault. >>>> [Switching to process 31063, thread 0x7eafe800] >>>> 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 >>>> 16 t.get_info (i); >>>> (gdb) bt >>>> #0 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 >>>> #1 0x09fd9464 in ID__Add (M3_Bd56fi_x=0x0) at ../src/ID.m3:48 >>>> #2 0x1c01e644 in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:37 >>>> #3 0x0156f1bc in RTLinker__RunMainBody (M3_DjPxE3_m=0x3c003ec0) >>>> at ../src/runtime/common/RTLinker.m3:399 >>>> #4 0x0156e576 in RTLinker__AddUnitI (M3_DjPxE3_m=0x3c003ec0) >>>> at ../src/runtime/common/RTLinker.m3:113 >>>> #5 0x0156e604 in RTLinker__AddUnit (M3_DjPxE5_b=0x1c01e54d) >>>> at ../src/runtime/common/RTLinker.m3:122 >>>> #6 0x1c004676 in main (argc=1, argv=0xcfbf6a3c, envp=0xcfbf6a44) >>>> at _m3main.mc:4 >>>> >>>> >>>> - Jay >>>> >>>> >>>> ________________________________ >>>>> From: hosking at cs.purdue.edu >>>>> To: jay.krell at cornell.edu >>>>> Date: Sun, 16 Aug 2009 15:26:49 -0400 >>>>> CC: m3devel at elegosoft.com >>>>> Subject: Re: [M3devel] more crashers >>>>> >>>>> Could this be endianness-related? >>>>> >>>>> On 16 Aug 2009, at 15:21, Jay K wrote: >>>>> >>>>> >>>>> I see the assertion failure on PPC_LINUX too. >>>>> I tried VAR defaultStackSize := 1024 * 1024; (not sure why there was any suspicion of stack size). >>>>> >>>>> >>>>> Debugging doesn't work PPC_LINUX. >>>>> >>>>> >>>>> jay at plin:/cm3/bin$ gdb ./cm3 >>>>> GNU gdb 6.8-debian >>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>> License GPLv3+: GNU GPL version 3 or later >>>>> This is free software: you are free to change and redistribute it. >>>>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >>>>> and "show warranty" for details. >>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>> break ma(gdb) break main >>>>> Breakpoint 1 at 0x86fc4: file _m3main.mc, line 2. >>>>> (gdb) r >>>>> Starting program: /home/jay/cm3/bin/cm3 >>>>> Warning: >>>>> Cannot insert breakpoint 1. >>>>> Error accessing memory address 0x86fc4: Input/output error. >>>>> >>>>> >>>>> No problem with C: >>>>> >>>>> >>>>> jay at plin:/cm3/bin$ echo "main(){}"> 1.c >>>>> jay at plin:/cm3/bin$ gcc -g 1.c >>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>> GNU gdb 6.8-debian >>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>> License GPLv3+: GNU GPL version 3 or later >>>>> This is free software: you are free to change and redistribute it. >>>>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >>>>> and "show warranty" for details. >>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>> (gdb) break main >>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>> (gdb) r >>>>> Starting program: /home/jay/cm3/bin/a.out >>>>> Breakpoint 1, main () at 1.c:1 >>>>> 1 main(){} >>>>> (gdb) >>>>> >>>>> >>>>> jay at plin:/cm3/bin$ gcc -gstabs+ 1.c >>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>> GNU gdb 6.8-debian >>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>> License GPLv3+: GNU GPL version 3 or later >>>>> This is free software: you are free to change and redistribute it. >>>>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >>>>> and "show warranty" for details. >>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>> (gdb) break main >>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>> (gdb) r >>>>> Starting program: /home/jay/cm3/bin/a.out >>>>> Breakpoint 1, main () at 1.c:1 >>>>> 1 main(){} >>>>> >>>>> >>>>> jay at plin:/cm3/bin$ gcc -gstabs 1.c >>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>> GNU gdb 6.8-debian >>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>> License GPLv3+: GNU GPL version 3 or later >>>>> This is free software: you are free to change and redistribute it. >>>>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >>>>> and "show warranty" for details. >>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>> (gdb) break main >>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>> (gdb) r >>>>> Starting program: /home/jay/cm3/bin/a.out >>>>> Breakpoint 1, main () at 1.c:1 >>>>> 1 main(){} >>>>> (gdb) >>>>> >>>>> >>>>> - Jay >>>>> >>>>> >>>>> ---------------------------------------- >>>>> From: jay.krell at cornell.edu >>>>> To: m3devel at elegosoft.com >>>>> Subject: more crashers >>>>> Date: Sun, 16 Aug 2009 10:06:15 +0000 >>>>> >>>>> >>>>> This is head on SOLgnu: >>>>> I'll try another and debug and see if fix is easy. >>>>> >>>>> -bash-3.00$ ./m3browser >>>>> >>>>> *** >>>>> *** runtime error: >>>>> *** Segmentation violation - possible attempt to dereference NIL >>>>> *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/String16.m3 >>>>> *** >>>>> >>>>> -bash-3.00$ ./visobliq >>>>> Internal Obliq interpreter installed... >>>>> Establishing 'templates' >>>>> (Created frame 'templates') >>>>> let >>>>> Templates = >>>>> {boolean=> ... , >>>>> browser=> ... , >>>>> button=> ... , >>>>> choice=> ... , >>>>> filebrowser=> ... , >>>>> form=> ... , >>>>> frame=> ... , >>>>> hscroll=> ... , >>>>> menu=> ... , >>>>> numeric=> ... , >>>>> text=> ... , >>>>> textedit=> ... , >>>>> typein=> ... , >>>>> video=> ... , >>>>> vscroll=> ... } >>>>> Establishing 'vowidgets' >>>>> (Created frame 'vowidgets') >>>>> ok >>>>> Establishing 'vocheckpt' >>>>> (Created frame 'vocheckpt') >>>>> ok >>>>> Establishing 'volib' >>>>> (Created frame 'volib') >>>>> Segmentation Fault (core dumped) >>>>> -bash-3.00$ >>>>> >>>>> From jay.krell at cornell.edu Mon Aug 17 06:01:45 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 17 Aug 2009 04:01:45 +0000 Subject: [M3devel] more crashers In-Reply-To: References: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> Message-ID: visobliq was stack overflow. Raising the default from 4K to 16K didn't fix, but 32K did. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] more crashers > Date: Sun, 16 Aug 2009 20:32:31 +0000 > > > m3browser: > > It is specific to my config file m3-sys/cminstall/src/config-no-install/cm3.cfg that reachs back into the source tree. It won't happen with what most people do. I have to do that M3Predefines or such work so that all the uses of m3quake besides cm3 are much more like cm3. > > > visobliq: > not the same thing > Does not occur on Linux/x86 or Linux/sparc. > They do print > Syntax error just before: -helvetica-bold-\*R-\*240-\*\") (LabelFo ... > ill-formed character escape sequence > Error detected (file file generated by Visual Obliq) (line 18, char 10) > VideoVBT.Start Jv ServerFailure:errno=0 > > but then gui comes up. > I'll have to finish my Solaris reinstall and get dbx. > > > - Jay > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> Date: Sun, 16 Aug 2009 20:22:49 +0000 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] more crashers >> >> >> sorry, this is simple. >> >> derived_dirs := IntList.List1 (ID.Add (MxConfig.Get("BUILD_DIR"))); >> >> >> - Jay >> >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu >>> Date: Sun, 16 Aug 2009 19:52:03 +0000 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] more crashers >>> >>> >>> Here is the relevant code in m3browser ID.m3: >>> >>> >>> C:\dev2\cm3.2\m3-tools\m3markup\src\ID.m3(38): empty_id := Add (""); >>> >>> empty_id := Add (""); >>> >>> (*-------------------------------------------------------------- exported ---*) >>> PROCEDURE Add (x: TEXT): T = >>> VAR >>> t: T; >>> a: REF ARRAY OF CHAR; >>> l: INTEGER; >>> BEGIN >>> l := Text.Length(x); >>> ... >>> END Add; >>> >>> >>> The empty string constant ends up as null. >>> >>> .stabn 68,0,38,.LM115-.LFBB10 >>> .LM115: >>> movl L_1 at GOT(%ebx), %eax >>> leal 24(%eax), %eax >>> movl %eax, (%esp) >>> call ID__Add at PLT >>> movl %eax, -8(%ebp) >>> movl -8(%ebp), %ecx >>> movl MM_ID at GOT(%ebx), %edx >>> movl 248(%edx), %eax >>> andl $0, %eax >>> orl %ecx, %eax >>> movl %eax, 248(%edx) >>> .L136: >>> movl MM_ID at GOT(%ebx), %eax >>> .LBE16: >>> addl $52, %esp >>> popl %ebx >>> popl %ebp >>> ret >>> >>> L_1: >>> 0 .long RTHooks__TextLitInfo >>> 4 .long RTHooks__TextLitGetChar >>> 8 .long RTHooks__TextLitGetWideChar >>> 12 .long RTHooks__TextLitGetChars >>> 16 .long RTHooks__TextLitGetWideChars >>> 20 .long 2 >>> 24 .long L_1 >>> .long 0 >>> .zero 4 >>> .ascii "ID_M3" >>> .zero 1 >>> .ascii "ExpandHashTable" >>> .zero 1 >>> .ascii "ExpandIDs" >>> .zero 1 >>> .ascii "ExpandChars" >>> .zero 1 >>> .ascii "Compare" >>> .zero 1 >>> >>> If I change "" to "foo", I get: >>> >>> L_1: >>> 0 .long RTHooks__TextLitInfo >>> 4 .long RTHooks__TextLitGetChar >>> 8 .long RTHooks__TextLitGetWideChar >>> 12 .long RTHooks__TextLitGetChars >>> 16 .long RTHooks__TextLitGetWideChars >>> 20 .long 2 >>> 24 .long L_1 >>> .long 3 >>> .ascii "foo" >>> .zero 1 >>> .ascii "ID_M3" >>> >>> and it still crashes. >>> >>> >>> It seems to hit ID__Add twice when only once would be expected. >>> >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: hosking at cs.purdue.edu >>>> Date: Sun, 16 Aug 2009 19:33:34 +0000 >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] more crashers >>>> >>>> >>>> Could be. I've also seen it on PPC_DARWIN a while ago. I only recall seeing it on sparc and ppc. >>>> It doesn't always occur. >>>> >>>> >>>> Here is the m3browser crash on a system that can be debugged. >>>> See why I want the full paths in the debug info? >>>> >>>> >>>> C:\Users\jay\Desktop>\cygwin\bin\ssh xobsd. >>>> $ cd /cm3 >>>> $ cd bin >>>> $ export DISPLAY=192.168.1.120:0.0 >>>> $ gdb ./m3browser >>>> GNU gdb 6.3 >>>> This GDB was configured as "i386-unknown-openbsd4.5"... >>>> (gdb) r >>>> Starting program: /home/jay/cm3/bin/m3browser >>>> Program received signal SIGSEGV, Segmentation fault. >>>> [Switching to process 31063, thread 0x7eafe800] >>>> 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 >>>> 16 t.get_info (i); >>>> (gdb) bt >>>> #0 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 >>>> #1 0x09fd9464 in ID__Add (M3_Bd56fi_x=0x0) at ../src/ID.m3:48 >>>> #2 0x1c01e644 in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:37 >>>> #3 0x0156f1bc in RTLinker__RunMainBody (M3_DjPxE3_m=0x3c003ec0) >>>> at ../src/runtime/common/RTLinker.m3:399 >>>> #4 0x0156e576 in RTLinker__AddUnitI (M3_DjPxE3_m=0x3c003ec0) >>>> at ../src/runtime/common/RTLinker.m3:113 >>>> #5 0x0156e604 in RTLinker__AddUnit (M3_DjPxE5_b=0x1c01e54d) >>>> at ../src/runtime/common/RTLinker.m3:122 >>>> #6 0x1c004676 in main (argc=1, argv=0xcfbf6a3c, envp=0xcfbf6a44) >>>> at _m3main.mc:4 >>>> >>>> >>>> - Jay >>>> >>>> >>>> ________________________________ >>>>> From: hosking at cs.purdue.edu >>>>> To: jay.krell at cornell.edu >>>>> Date: Sun, 16 Aug 2009 15:26:49 -0400 >>>>> CC: m3devel at elegosoft.com >>>>> Subject: Re: [M3devel] more crashers >>>>> >>>>> Could this be endianness-related? >>>>> >>>>> On 16 Aug 2009, at 15:21, Jay K wrote: >>>>> >>>>> >>>>> I see the assertion failure on PPC_LINUX too. >>>>> I tried VAR defaultStackSize := 1024 * 1024; (not sure why there was any suspicion of stack size). >>>>> >>>>> >>>>> Debugging doesn't work PPC_LINUX. >>>>> >>>>> >>>>> jay at plin:/cm3/bin$ gdb ./cm3 >>>>> GNU gdb 6.8-debian >>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>> License GPLv3+: GNU GPL version 3 or later >>>>> This is free software: you are free to change and redistribute it. >>>>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >>>>> and "show warranty" for details. >>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>> break ma(gdb) break main >>>>> Breakpoint 1 at 0x86fc4: file _m3main.mc, line 2. >>>>> (gdb) r >>>>> Starting program: /home/jay/cm3/bin/cm3 >>>>> Warning: >>>>> Cannot insert breakpoint 1. >>>>> Error accessing memory address 0x86fc4: Input/output error. >>>>> >>>>> >>>>> No problem with C: >>>>> >>>>> >>>>> jay at plin:/cm3/bin$ echo "main(){}"> 1.c >>>>> jay at plin:/cm3/bin$ gcc -g 1.c >>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>> GNU gdb 6.8-debian >>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>> License GPLv3+: GNU GPL version 3 or later >>>>> This is free software: you are free to change and redistribute it. >>>>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >>>>> and "show warranty" for details. >>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>> (gdb) break main >>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>> (gdb) r >>>>> Starting program: /home/jay/cm3/bin/a.out >>>>> Breakpoint 1, main () at 1.c:1 >>>>> 1 main(){} >>>>> (gdb) >>>>> >>>>> >>>>> jay at plin:/cm3/bin$ gcc -gstabs+ 1.c >>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>> GNU gdb 6.8-debian >>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>> License GPLv3+: GNU GPL version 3 or later >>>>> This is free software: you are free to change and redistribute it. >>>>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >>>>> and "show warranty" for details. >>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>> (gdb) break main >>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>> (gdb) r >>>>> Starting program: /home/jay/cm3/bin/a.out >>>>> Breakpoint 1, main () at 1.c:1 >>>>> 1 main(){} >>>>> >>>>> >>>>> jay at plin:/cm3/bin$ gcc -gstabs 1.c >>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>> GNU gdb 6.8-debian >>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>> License GPLv3+: GNU GPL version 3 or later >>>>> This is free software: you are free to change and redistribute it. >>>>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >>>>> and "show warranty" for details. >>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>> (gdb) break main >>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>> (gdb) r >>>>> Starting program: /home/jay/cm3/bin/a.out >>>>> Breakpoint 1, main () at 1.c:1 >>>>> 1 main(){} >>>>> (gdb) >>>>> >>>>> >>>>> - Jay >>>>> >>>>> >>>>> ---------------------------------------- >>>>> From: jay.krell at cornell.edu >>>>> To: m3devel at elegosoft.com >>>>> Subject: more crashers >>>>> Date: Sun, 16 Aug 2009 10:06:15 +0000 >>>>> >>>>> >>>>> This is head on SOLgnu: >>>>> I'll try another and debug and see if fix is easy. >>>>> >>>>> -bash-3.00$ ./m3browser >>>>> >>>>> *** >>>>> *** runtime error: >>>>> *** Segmentation violation - possible attempt to dereference NIL >>>>> *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/String16.m3 >>>>> *** >>>>> >>>>> -bash-3.00$ ./visobliq >>>>> Internal Obliq interpreter installed... >>>>> Establishing 'templates' >>>>> (Created frame 'templates') >>>>> let >>>>> Templates = >>>>> {boolean=> ... , >>>>> browser=> ... , >>>>> button=> ... , >>>>> choice=> ... , >>>>> filebrowser=> ... , >>>>> form=> ... , >>>>> frame=> ... , >>>>> hscroll=> ... , >>>>> menu=> ... , >>>>> numeric=> ... , >>>>> text=> ... , >>>>> textedit=> ... , >>>>> typein=> ... , >>>>> video=> ... , >>>>> vscroll=> ... } >>>>> Establishing 'vowidgets' >>>>> (Created frame 'vowidgets') >>>>> ok >>>>> Establishing 'vocheckpt' >>>>> (Created frame 'vocheckpt') >>>>> ok >>>>> Establishing 'volib' >>>>> (Created frame 'volib') >>>>> Segmentation Fault (core dumped) >>>>> -bash-3.00$ >>>>> >>>>> From jay.krell at cornell.edu Mon Aug 17 10:10:33 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Mon, 17 Aug 2009 01:10:33 -0700 Subject: [M3devel] more crashers In-Reply-To: References: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> Message-ID: Ps a few things We should see about reducing stack usage. We should see about eliminating recursion on the machine stack. Recursion is ok but use a heap allocated data structure. We should experiment to see what some behaviors are specifically default stack sizes, if the stack size is actually changable, and how small it can actually be made on the various platforms. For *hypothetical* example if other than solaris rounds stack size up to 64k boundary then default should be increased to 64k. It depends what behaviors exist. I find the machine stack to the extent that I am familiar with it's implementations, broken. It is fast but it has two severe problems vs heap. 1 you generally have to somehow guess at its maximum size which is approx impossible and approx never done 2 generally no code deals with stack exhaustion, with good reason, it is difficult/impossible/not portable. Compare that to malloc where it is generally limited only by address space, everyone knows what failure looks like, and you can easily detect and react to failure, portably. It would be cool if alloca could return Null for out of stack but that doesn't nearly solve the problem. (yes I understand, alloca is not used for the vast majority of stack allocation, and isn't even portable) - Jay (phone) On Aug 16, 2009, at 9:01 PM, Jay K wrote: > > visobliq was stack overflow. > Raising the default from 4K to 16K didn't fix, but 32K did. > > - Jay > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] more crashers >> Date: Sun, 16 Aug 2009 20:32:31 +0000 >> >> >> m3browser: >> >> It is specific to my config file m3-sys/cminstall/src/config-no- >> install/cm3.cfg that reachs back into the source tree. It won't >> happen with what most people do. I have to do that M3Predefines or >> such work so that all the uses of m3quake besides cm3 are much more >> like cm3. >> >> >> visobliq: >> not the same thing >> Does not occur on Linux/x86 or Linux/sparc. >> They do print >> Syntax error just before: -helvetica-bold-\*R-\*240-\*\") >> (LabelFo ... >> ill-formed character escape sequence >> Error detected (file file generated by Visual Obliq) (line 18, char >> 10) >> VideoVBT.Start Jv ServerFailure:errno=0 >> >> but then gui comes up. >> I'll have to finish my Solaris reinstall and get dbx. >> >> >> - Jay >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu > From wagner at elegosoft.com Mon Aug 17 13:30:26 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 17 Aug 2009 13:30:26 +0200 Subject: [M3devel] more crashers In-Reply-To: References: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> Message-ID: <20090817133026.6v9cm3cu0wwkc08k@mail.elegosoft.com> Quoting Jay K : > visobliq was stack overflow. > Raising the default from 4K to 16K didn't fix, but 32K did. We need to address this somehow. It cannot be correct if the user needs to increase the default stack size on one platform by 8 and not at all on another. Do we have any concept of a 'standard stack size unit' ;-)? Something that can be easily understood and implemented and be used instead of the machine words in the current interfaces? Any ideas? Olaf > - Jay > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] more crashers >> Date: Sun, 16 Aug 2009 20:32:31 +0000 >> >> >> m3browser: >> >> It is specific to my config file >> m3-sys/cminstall/src/config-no-install/cm3.cfg that reachs back >> into the source tree. It won't happen with what most people do. I >> have to do that M3Predefines or such work so that all the uses of >> m3quake besides cm3 are much more like cm3. >> >> >> visobliq: >> not the same thing >> Does not occur on Linux/x86 or Linux/sparc. >> They do print >> Syntax error just before: -helvetica-bold-\*R-\*240-\*\") (LabelFo ... >> ill-formed character escape sequence >> Error detected (file file generated by Visual Obliq) (line 18, char 10) >> VideoVBT.Start Jv ServerFailure:errno=0 >> >> but then gui comes up. >> I'll have to finish my Solaris reinstall and get dbx. >> >> >> - Jay >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu >>> Date: Sun, 16 Aug 2009 20:22:49 +0000 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] more crashers >>> >>> >>> sorry, this is simple. >>> >>> derived_dirs := IntList.List1 (ID.Add (MxConfig.Get("BUILD_DIR"))); >>> >>> >>> - Jay >>> >>> >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: hosking at cs.purdue.edu >>>> Date: Sun, 16 Aug 2009 19:52:03 +0000 >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] more crashers >>>> >>>> >>>> Here is the relevant code in m3browser ID.m3: >>>> >>>> >>>> C:\dev2\cm3.2\m3-tools\m3markup\src\ID.m3(38): empty_id := Add (""); >>>> >>>> empty_id := Add (""); >>>> >>>> (*-------------------------------------------------------------- >>>> exported ---*) >>>> PROCEDURE Add (x: TEXT): T = >>>> VAR >>>> t: T; >>>> a: REF ARRAY OF CHAR; >>>> l: INTEGER; >>>> BEGIN >>>> l := Text.Length(x); >>>> ... >>>> END Add; >>>> >>>> >>>> The empty string constant ends up as null. >>>> >>>> .stabn 68,0,38,.LM115-.LFBB10 >>>> .LM115: >>>> movl L_1 at GOT(%ebx), %eax >>>> leal 24(%eax), %eax >>>> movl %eax, (%esp) >>>> call ID__Add at PLT >>>> movl %eax, -8(%ebp) >>>> movl -8(%ebp), %ecx >>>> movl MM_ID at GOT(%ebx), %edx >>>> movl 248(%edx), %eax >>>> andl $0, %eax >>>> orl %ecx, %eax >>>> movl %eax, 248(%edx) >>>> .L136: >>>> movl MM_ID at GOT(%ebx), %eax >>>> .LBE16: >>>> addl $52, %esp >>>> popl %ebx >>>> popl %ebp >>>> ret >>>> >>>> L_1: >>>> 0 .long RTHooks__TextLitInfo >>>> 4 .long RTHooks__TextLitGetChar >>>> 8 .long RTHooks__TextLitGetWideChar >>>> 12 .long RTHooks__TextLitGetChars >>>> 16 .long RTHooks__TextLitGetWideChars >>>> 20 .long 2 >>>> 24 .long L_1 >>>> .long 0 >>>> .zero 4 >>>> .ascii "ID_M3" >>>> .zero 1 >>>> .ascii "ExpandHashTable" >>>> .zero 1 >>>> .ascii "ExpandIDs" >>>> .zero 1 >>>> .ascii "ExpandChars" >>>> .zero 1 >>>> .ascii "Compare" >>>> .zero 1 >>>> >>>> If I change "" to "foo", I get: >>>> >>>> L_1: >>>> 0 .long RTHooks__TextLitInfo >>>> 4 .long RTHooks__TextLitGetChar >>>> 8 .long RTHooks__TextLitGetWideChar >>>> 12 .long RTHooks__TextLitGetChars >>>> 16 .long RTHooks__TextLitGetWideChars >>>> 20 .long 2 >>>> 24 .long L_1 >>>> .long 3 >>>> .ascii "foo" >>>> .zero 1 >>>> .ascii "ID_M3" >>>> >>>> and it still crashes. >>>> >>>> >>>> It seems to hit ID__Add twice when only once would be expected. >>>> >>>> >>>> - Jay >>>> >>>> >>>> ---------------------------------------- >>>>> From: jay.krell at cornell.edu >>>>> To: hosking at cs.purdue.edu >>>>> Date: Sun, 16 Aug 2009 19:33:34 +0000 >>>>> CC: m3devel at elegosoft.com >>>>> Subject: Re: [M3devel] more crashers >>>>> >>>>> >>>>> Could be. I've also seen it on PPC_DARWIN a while ago. I only >>>>> recall seeing it on sparc and ppc. >>>>> It doesn't always occur. >>>>> >>>>> >>>>> Here is the m3browser crash on a system that can be debugged. >>>>> See why I want the full paths in the debug info? >>>>> >>>>> >>>>> C:\Users\jay\Desktop>\cygwin\bin\ssh xobsd. >>>>> $ cd /cm3 >>>>> $ cd bin >>>>> $ export DISPLAY=192.168.1.120:0.0 >>>>> $ gdb ./m3browser >>>>> GNU gdb 6.3 >>>>> This GDB was configured as "i386-unknown-openbsd4.5"... >>>>> (gdb) r >>>>> Starting program: /home/jay/cm3/bin/m3browser >>>>> Program received signal SIGSEGV, Segmentation fault. >>>>> [Switching to process 31063, thread 0x7eafe800] >>>>> 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 >>>>> 16 t.get_info (i); >>>>> (gdb) bt >>>>> #0 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 >>>>> #1 0x09fd9464 in ID__Add (M3_Bd56fi_x=0x0) at ../src/ID.m3:48 >>>>> #2 0x1c01e644 in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:37 >>>>> #3 0x0156f1bc in RTLinker__RunMainBody (M3_DjPxE3_m=0x3c003ec0) >>>>> at ../src/runtime/common/RTLinker.m3:399 >>>>> #4 0x0156e576 in RTLinker__AddUnitI (M3_DjPxE3_m=0x3c003ec0) >>>>> at ../src/runtime/common/RTLinker.m3:113 >>>>> #5 0x0156e604 in RTLinker__AddUnit (M3_DjPxE5_b=0x1c01e54d) >>>>> at ../src/runtime/common/RTLinker.m3:122 >>>>> #6 0x1c004676 in main (argc=1, argv=0xcfbf6a3c, envp=0xcfbf6a44) >>>>> at _m3main.mc:4 >>>>> >>>>> >>>>> - Jay >>>>> >>>>> >>>>> ________________________________ >>>>>> From: hosking at cs.purdue.edu >>>>>> To: jay.krell at cornell.edu >>>>>> Date: Sun, 16 Aug 2009 15:26:49 -0400 >>>>>> CC: m3devel at elegosoft.com >>>>>> Subject: Re: [M3devel] more crashers >>>>>> >>>>>> Could this be endianness-related? >>>>>> >>>>>> On 16 Aug 2009, at 15:21, Jay K wrote: >>>>>> >>>>>> >>>>>> I see the assertion failure on PPC_LINUX too. >>>>>> I tried VAR defaultStackSize := 1024 * 1024; (not sure why >>>>>> there was any suspicion of stack size). >>>>>> >>>>>> >>>>>> Debugging doesn't work PPC_LINUX. >>>>>> >>>>>> >>>>>> jay at plin:/cm3/bin$ gdb ./cm3 >>>>>> GNU gdb 6.8-debian >>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>> This is free software: you are free to change and redistribute it. >>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>> "show copying" >>>>>> and "show warranty" for details. >>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>> break ma(gdb) break main >>>>>> Breakpoint 1 at 0x86fc4: file _m3main.mc, line 2. >>>>>> (gdb) r >>>>>> Starting program: /home/jay/cm3/bin/cm3 >>>>>> Warning: >>>>>> Cannot insert breakpoint 1. >>>>>> Error accessing memory address 0x86fc4: Input/output error. >>>>>> >>>>>> >>>>>> No problem with C: >>>>>> >>>>>> >>>>>> jay at plin:/cm3/bin$ echo "main(){}"> 1.c >>>>>> jay at plin:/cm3/bin$ gcc -g 1.c >>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>> GNU gdb 6.8-debian >>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>> This is free software: you are free to change and redistribute it. >>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>> "show copying" >>>>>> and "show warranty" for details. >>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>> (gdb) break main >>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>> (gdb) r >>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>> Breakpoint 1, main () at 1.c:1 >>>>>> 1 main(){} >>>>>> (gdb) >>>>>> >>>>>> >>>>>> jay at plin:/cm3/bin$ gcc -gstabs+ 1.c >>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>> GNU gdb 6.8-debian >>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>> This is free software: you are free to change and redistribute it. >>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>> "show copying" >>>>>> and "show warranty" for details. >>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>> (gdb) break main >>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>> (gdb) r >>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>> Breakpoint 1, main () at 1.c:1 >>>>>> 1 main(){} >>>>>> >>>>>> >>>>>> jay at plin:/cm3/bin$ gcc -gstabs 1.c >>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>> GNU gdb 6.8-debian >>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>> This is free software: you are free to change and redistribute it. >>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>> "show copying" >>>>>> and "show warranty" for details. >>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>> (gdb) break main >>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>> (gdb) r >>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>> Breakpoint 1, main () at 1.c:1 >>>>>> 1 main(){} >>>>>> (gdb) >>>>>> >>>>>> >>>>>> - Jay >>>>>> >>>>>> >>>>>> ---------------------------------------- >>>>>> From: jay.krell at cornell.edu >>>>>> To: m3devel at elegosoft.com >>>>>> Subject: more crashers >>>>>> Date: Sun, 16 Aug 2009 10:06:15 +0000 >>>>>> >>>>>> >>>>>> This is head on SOLgnu: >>>>>> I'll try another and debug and see if fix is easy. >>>>>> >>>>>> -bash-3.00$ ./m3browser >>>>>> >>>>>> *** >>>>>> *** runtime error: >>>>>> *** Segmentation violation - possible attempt to dereference NIL >>>>>> *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/String16.m3 >>>>>> *** >>>>>> >>>>>> -bash-3.00$ ./visobliq >>>>>> Internal Obliq interpreter installed... >>>>>> Establishing 'templates' >>>>>> (Created frame 'templates') >>>>>> let >>>>>> Templates = >>>>>> {boolean=> ... , >>>>>> browser=> ... , >>>>>> button=> ... , >>>>>> choice=> ... , >>>>>> filebrowser=> ... , >>>>>> form=> ... , >>>>>> frame=> ... , >>>>>> hscroll=> ... , >>>>>> menu=> ... , >>>>>> numeric=> ... , >>>>>> text=> ... , >>>>>> textedit=> ... , >>>>>> typein=> ... , >>>>>> video=> ... , >>>>>> vscroll=> ... } >>>>>> Establishing 'vowidgets' >>>>>> (Created frame 'vowidgets') >>>>>> ok >>>>>> Establishing 'vocheckpt' >>>>>> (Created frame 'vocheckpt') >>>>>> ok >>>>>> Establishing 'volib' >>>>>> (Created frame 'volib') >>>>>> Segmentation Fault (core dumped) >>>>>> -bash-3.00$ >>>>>> >>>>>> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Mon Aug 17 13:35:25 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 17 Aug 2009 13:35:25 +0200 Subject: [M3devel] CM3 Release Engineering and Feedback In-Reply-To: <20090816171032.GA27461@topoi.pooq.com> References: <20090813143806.udmpiz76ecg0scgs@mail.elegosoft.com> <20090816171032.GA27461@topoi.pooq.com> Message-ID: <20090817133525.c8kdk3g0o4w4g0ok@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > On Thu, Aug 13, 2009 at 02:38:06PM +0200, Olaf Wagner wrote: >> Quoting hendrik at topoi.pooq.com: >> >> >On Wed, Aug 12, 2009 at 01:10:38AM +0200, Olaf Wagner wrote: >> >> o There hasn't been much feedback, neither from the list of active >> >> developers nor from end users for RC2. I'd really appreciate some >> >> more reports about installation attempts and the problems encountered. >> > >> >Well, I'll provide more with the next RC. The hudson directory was >> >pretty much a show-stopper. I'd expect the same problem to be there on >> >the other platforms. >> >> The simple work-around would be to call cm3 -build on the packages >> again, which should only adapt the broken .M3SHIP files. > > I tried that , but it failed, complaining Yes. Sorry. Those were the bogus collection dependencies. They should now be 'fixed', too (at least much easier to understand). I've invested some hours to compute the depdenencies on package and collection level several times and made some changes to the collection classification in pkginfo.txt. [...] > In any case, this will be an obsolete by the time RC3 starts to roll > out. So focus on that rather than fixing the workaround. If there are no more new unexpected crashes, I'll build the RC3 archives soon. It should be much easier this time. We'll see... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Aug 17 13:35:40 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 17 Aug 2009 11:35:40 +0000 Subject: [M3devel] more crashers In-Reply-To: <20090817133026.6v9cm3cu0wwkc08k@mail.elegosoft.com> References: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> <20090817133026.6v9cm3cu0wwkc08k@mail.elegosoft.com> Message-ID: - I think the whole machine stack mechanism is pretty hopelessly broken. Not just in Modula-3. Therefore my enthusiasm to attempt to "fix" it -- which is impossible -- isn't very high. - I'm hoping to find that no platform other than Solaris lets you even use such a small stack. I have to experiment some in a bit. Depending on that experiment, we'll be in a better position, without any further changes, but again, depending on what I find. That is, if every other platform already had a larger stack, then this just brings Solaris inline with the rest. If the other platforms were actually successfully using a 4K stack, then indeed a problem. - It could also be a factor of optimization. Maybe ensuring -O2 or -O3 is used more would cover it up?? - Or some other changes. That is, if we have drastically increased stack usage, we should try to reduce it back down. But given that 4K was the previous value and even 16K doesn't work...I'm not hopeful we could fit it back down in 4K. It is easy enough to see the bug and then look at the various frames and see if they use a lot of stack and can be reduced. - Jay ---------------------------------------- > Date: Mon, 17 Aug 2009 13:30:26 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] more crashers > > Quoting Jay K : > >> visobliq was stack overflow. >> Raising the default from 4K to 16K didn't fix, but 32K did. > > We need to address this somehow. It cannot be correct if the user > needs to increase the default stack size on one platform by 8 > and not at all on another. Do we have any concept of a 'standard > stack size unit' ;-)? Something that can be easily understood and > implemented and be used instead of the machine words in the current > interfaces? Any ideas? > > Olaf > > >> - Jay >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu >>> CC: m3devel at elegosoft.com >>> Subject: RE: [M3devel] more crashers >>> Date: Sun, 16 Aug 2009 20:32:31 +0000 >>> >>> >>> m3browser: >>> >>> It is specific to my config file >>> m3-sys/cminstall/src/config-no-install/cm3.cfg that reachs back >>> into the source tree. It won't happen with what most people do. I >>> have to do that M3Predefines or such work so that all the uses of >>> m3quake besides cm3 are much more like cm3. >>> >>> >>> visobliq: >>> not the same thing >>> Does not occur on Linux/x86 or Linux/sparc. >>> They do print >>> Syntax error just before: -helvetica-bold-\*R-\*240-\*\") (LabelFo ... >>> ill-formed character escape sequence >>> Error detected (file file generated by Visual Obliq) (line 18, char 10) >>> VideoVBT.Start Jv ServerFailure:errno=0 >>> >>> but then gui comes up. >>> I'll have to finish my Solaris reinstall and get dbx. >>> >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: hosking at cs.purdue.edu >>>> Date: Sun, 16 Aug 2009 20:22:49 +0000 >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] more crashers >>>> >>>> >>>> sorry, this is simple. >>>> >>>> derived_dirs := IntList.List1 (ID.Add (MxConfig.Get("BUILD_DIR"))); >>>> >>>> >>>> - Jay >>>> >>>> >>>> >>>> ---------------------------------------- >>>>> From: jay.krell at cornell.edu >>>>> To: hosking at cs.purdue.edu >>>>> Date: Sun, 16 Aug 2009 19:52:03 +0000 >>>>> CC: m3devel at elegosoft.com >>>>> Subject: Re: [M3devel] more crashers >>>>> >>>>> >>>>> Here is the relevant code in m3browser ID.m3: >>>>> >>>>> >>>>> C:\dev2\cm3.2\m3-tools\m3markup\src\ID.m3(38): empty_id := Add (""); >>>>> >>>>> empty_id := Add (""); >>>>> >>>>> (*-------------------------------------------------------------- >>>>> exported ---*) >>>>> PROCEDURE Add (x: TEXT): T = >>>>> VAR >>>>> t: T; >>>>> a: REF ARRAY OF CHAR; >>>>> l: INTEGER; >>>>> BEGIN >>>>> l := Text.Length(x); >>>>> ... >>>>> END Add; >>>>> >>>>> >>>>> The empty string constant ends up as null. >>>>> >>>>> .stabn 68,0,38,.LM115-.LFBB10 >>>>> .LM115: >>>>> movl L_1 at GOT(%ebx), %eax >>>>> leal 24(%eax), %eax >>>>> movl %eax, (%esp) >>>>> call ID__Add at PLT >>>>> movl %eax, -8(%ebp) >>>>> movl -8(%ebp), %ecx >>>>> movl MM_ID at GOT(%ebx), %edx >>>>> movl 248(%edx), %eax >>>>> andl $0, %eax >>>>> orl %ecx, %eax >>>>> movl %eax, 248(%edx) >>>>> .L136: >>>>> movl MM_ID at GOT(%ebx), %eax >>>>> .LBE16: >>>>> addl $52, %esp >>>>> popl %ebx >>>>> popl %ebp >>>>> ret >>>>> >>>>> L_1: >>>>> 0 .long RTHooks__TextLitInfo >>>>> 4 .long RTHooks__TextLitGetChar >>>>> 8 .long RTHooks__TextLitGetWideChar >>>>> 12 .long RTHooks__TextLitGetChars >>>>> 16 .long RTHooks__TextLitGetWideChars >>>>> 20 .long 2 >>>>> 24 .long L_1 >>>>> .long 0 >>>>> .zero 4 >>>>> .ascii "ID_M3" >>>>> .zero 1 >>>>> .ascii "ExpandHashTable" >>>>> .zero 1 >>>>> .ascii "ExpandIDs" >>>>> .zero 1 >>>>> .ascii "ExpandChars" >>>>> .zero 1 >>>>> .ascii "Compare" >>>>> .zero 1 >>>>> >>>>> If I change "" to "foo", I get: >>>>> >>>>> L_1: >>>>> 0 .long RTHooks__TextLitInfo >>>>> 4 .long RTHooks__TextLitGetChar >>>>> 8 .long RTHooks__TextLitGetWideChar >>>>> 12 .long RTHooks__TextLitGetChars >>>>> 16 .long RTHooks__TextLitGetWideChars >>>>> 20 .long 2 >>>>> 24 .long L_1 >>>>> .long 3 >>>>> .ascii "foo" >>>>> .zero 1 >>>>> .ascii "ID_M3" >>>>> >>>>> and it still crashes. >>>>> >>>>> >>>>> It seems to hit ID__Add twice when only once would be expected. >>>>> >>>>> >>>>> - Jay >>>>> >>>>> >>>>> ---------------------------------------- >>>>>> From: jay.krell at cornell.edu >>>>>> To: hosking at cs.purdue.edu >>>>>> Date: Sun, 16 Aug 2009 19:33:34 +0000 >>>>>> CC: m3devel at elegosoft.com >>>>>> Subject: Re: [M3devel] more crashers >>>>>> >>>>>> >>>>>> Could be. I've also seen it on PPC_DARWIN a while ago. I only >>>>>> recall seeing it on sparc and ppc. >>>>>> It doesn't always occur. >>>>>> >>>>>> >>>>>> Here is the m3browser crash on a system that can be debugged. >>>>>> See why I want the full paths in the debug info? >>>>>> >>>>>> >>>>>> C:\Users\jay\Desktop>\cygwin\bin\ssh xobsd. >>>>>> $ cd /cm3 >>>>>> $ cd bin >>>>>> $ export DISPLAY=192.168.1.120:0.0 >>>>>> $ gdb ./m3browser >>>>>> GNU gdb 6.3 >>>>>> This GDB was configured as "i386-unknown-openbsd4.5"... >>>>>> (gdb) r >>>>>> Starting program: /home/jay/cm3/bin/m3browser >>>>>> Program received signal SIGSEGV, Segmentation fault. >>>>>> [Switching to process 31063, thread 0x7eafe800] >>>>>> 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 >>>>>> 16 t.get_info (i); >>>>>> (gdb) bt >>>>>> #0 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 >>>>>> #1 0x09fd9464 in ID__Add (M3_Bd56fi_x=0x0) at ../src/ID.m3:48 >>>>>> #2 0x1c01e644 in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:37 >>>>>> #3 0x0156f1bc in RTLinker__RunMainBody (M3_DjPxE3_m=0x3c003ec0) >>>>>> at ../src/runtime/common/RTLinker.m3:399 >>>>>> #4 0x0156e576 in RTLinker__AddUnitI (M3_DjPxE3_m=0x3c003ec0) >>>>>> at ../src/runtime/common/RTLinker.m3:113 >>>>>> #5 0x0156e604 in RTLinker__AddUnit (M3_DjPxE5_b=0x1c01e54d) >>>>>> at ../src/runtime/common/RTLinker.m3:122 >>>>>> #6 0x1c004676 in main (argc=1, argv=0xcfbf6a3c, envp=0xcfbf6a44) >>>>>> at _m3main.mc:4 >>>>>> >>>>>> >>>>>> - Jay >>>>>> >>>>>> >>>>>> ________________________________ >>>>>>> From: hosking at cs.purdue.edu >>>>>>> To: jay.krell at cornell.edu >>>>>>> Date: Sun, 16 Aug 2009 15:26:49 -0400 >>>>>>> CC: m3devel at elegosoft.com >>>>>>> Subject: Re: [M3devel] more crashers >>>>>>> >>>>>>> Could this be endianness-related? >>>>>>> >>>>>>> On 16 Aug 2009, at 15:21, Jay K wrote: >>>>>>> >>>>>>> >>>>>>> I see the assertion failure on PPC_LINUX too. >>>>>>> I tried VAR defaultStackSize := 1024 * 1024; (not sure why >>>>>>> there was any suspicion of stack size). >>>>>>> >>>>>>> >>>>>>> Debugging doesn't work PPC_LINUX. >>>>>>> >>>>>>> >>>>>>> jay at plin:/cm3/bin$ gdb ./cm3 >>>>>>> GNU gdb 6.8-debian >>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>> This is free software: you are free to change and redistribute it. >>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>> "show copying" >>>>>>> and "show warranty" for details. >>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>> break ma(gdb) break main >>>>>>> Breakpoint 1 at 0x86fc4: file _m3main.mc, line 2. >>>>>>> (gdb) r >>>>>>> Starting program: /home/jay/cm3/bin/cm3 >>>>>>> Warning: >>>>>>> Cannot insert breakpoint 1. >>>>>>> Error accessing memory address 0x86fc4: Input/output error. >>>>>>> >>>>>>> >>>>>>> No problem with C: >>>>>>> >>>>>>> >>>>>>> jay at plin:/cm3/bin$ echo "main(){}"> 1.c >>>>>>> jay at plin:/cm3/bin$ gcc -g 1.c >>>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>>> GNU gdb 6.8-debian >>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>> This is free software: you are free to change and redistribute it. >>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>> "show copying" >>>>>>> and "show warranty" for details. >>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>> (gdb) break main >>>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>>> (gdb) r >>>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>>> Breakpoint 1, main () at 1.c:1 >>>>>>> 1 main(){} >>>>>>> (gdb) >>>>>>> >>>>>>> >>>>>>> jay at plin:/cm3/bin$ gcc -gstabs+ 1.c >>>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>>> GNU gdb 6.8-debian >>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>> This is free software: you are free to change and redistribute it. >>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>> "show copying" >>>>>>> and "show warranty" for details. >>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>> (gdb) break main >>>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>>> (gdb) r >>>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>>> Breakpoint 1, main () at 1.c:1 >>>>>>> 1 main(){} >>>>>>> >>>>>>> >>>>>>> jay at plin:/cm3/bin$ gcc -gstabs 1.c >>>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>>> GNU gdb 6.8-debian >>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>> This is free software: you are free to change and redistribute it. >>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>> "show copying" >>>>>>> and "show warranty" for details. >>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>> (gdb) break main >>>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>>> (gdb) r >>>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>>> Breakpoint 1, main () at 1.c:1 >>>>>>> 1 main(){} >>>>>>> (gdb) >>>>>>> >>>>>>> >>>>>>> - Jay >>>>>>> >>>>>>> >>>>>>> ---------------------------------------- >>>>>>> From: jay.krell at cornell.edu >>>>>>> To: m3devel at elegosoft.com >>>>>>> Subject: more crashers >>>>>>> Date: Sun, 16 Aug 2009 10:06:15 +0000 >>>>>>> >>>>>>> >>>>>>> This is head on SOLgnu: >>>>>>> I'll try another and debug and see if fix is easy. >>>>>>> >>>>>>> -bash-3.00$ ./m3browser >>>>>>> >>>>>>> *** >>>>>>> *** runtime error: >>>>>>> *** Segmentation violation - possible attempt to dereference NIL >>>>>>> *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/String16.m3 >>>>>>> *** >>>>>>> >>>>>>> -bash-3.00$ ./visobliq >>>>>>> Internal Obliq interpreter installed... >>>>>>> Establishing 'templates' >>>>>>> (Created frame 'templates') >>>>>>> let >>>>>>> Templates = >>>>>>> {boolean=> ... , >>>>>>> browser=> ... , >>>>>>> button=> ... , >>>>>>> choice=> ... , >>>>>>> filebrowser=> ... , >>>>>>> form=> ... , >>>>>>> frame=> ... , >>>>>>> hscroll=> ... , >>>>>>> menu=> ... , >>>>>>> numeric=> ... , >>>>>>> text=> ... , >>>>>>> textedit=> ... , >>>>>>> typein=> ... , >>>>>>> video=> ... , >>>>>>> vscroll=> ... } >>>>>>> Establishing 'vowidgets' >>>>>>> (Created frame 'vowidgets') >>>>>>> ok >>>>>>> Establishing 'vocheckpt' >>>>>>> (Created frame 'vocheckpt') >>>>>>> ok >>>>>>> Establishing 'volib' >>>>>>> (Created frame 'volib') >>>>>>> Segmentation Fault (core dumped) >>>>>>> -bash-3.00$ >>>>>>> >>>>>>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Mon Aug 17 13:37:06 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 17 Aug 2009 11:37:06 +0000 Subject: [M3devel] CM3 Release Engineering and Feedback In-Reply-To: <20090817133525.c8kdk3g0o4w4g0ok@mail.elegosoft.com> References: <20090813143806.udmpiz76ecg0scgs@mail.elegosoft.com> <20090816171032.GA27461@topoi.pooq.com> <20090817133525.c8kdk3g0o4w4g0ok@mail.elegosoft.com> Message-ID: > If there are no more new unexpected crashes I cried wolf by accident. Neither the m3browser nor visobliq crashes were particularly interesting, though somewhat. There is still formsedit though. :( - Jay ---------------------------------------- > Date: Mon, 17 Aug 2009 13:35:25 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] CM3 Release Engineering and Feedback > > Quoting hendrik at topoi.pooq.com: > >> On Thu, Aug 13, 2009 at 02:38:06PM +0200, Olaf Wagner wrote: >>> Quoting hendrik at topoi.pooq.com: >>> >>>>On Wed, Aug 12, 2009 at 01:10:38AM +0200, Olaf Wagner wrote: >>>>> o There hasn't been much feedback, neither from the list of active >>>>> developers nor from end users for RC2. I'd really appreciate some >>>>> more reports about installation attempts and the problems encountered. >>>> >>>>Well, I'll provide more with the next RC. The hudson directory was >>>>pretty much a show-stopper. I'd expect the same problem to be there on >>>>the other platforms. >>> >>> The simple work-around would be to call cm3 -build on the packages >>> again, which should only adapt the broken .M3SHIP files. >> >> I tried that , but it failed, complaining > > Yes. Sorry. Those were the bogus collection dependencies. They should > now be 'fixed', too (at least much easier to understand). I've invested > some hours to compute the depdenencies on package and collection level > several times and made some changes to the collection classification > in pkginfo.txt. > > [...] > >> In any case, this will be an obsolete by the time RC3 starts to roll >> out. So focus on that rather than fixing the workaround. > > If there are no more new unexpected crashes, I'll build the RC3 archives > soon. It should be much easier this time. We'll see... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Mon Aug 17 13:48:30 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 17 Aug 2009 11:48:30 +0000 Subject: [M3devel] i386 vs. i486 vs. i586 vs. i686? Message-ID: At some point I'd like to merge m3cc/src/platforms.quake and m3gdb/src/platforms.quake, and put the result in cm3cfg.common, or even cm3. A small sticking point here is which of [3-6]i86 to use in various places. i386 is pretty darn old (1985?), missing some useful instructions, and I believe not particularly well supported by anyone any longer. Beyond that I'm not sure. I don't think i486 has been available for sale in over 10 years, but maybe in embedded systems?? I believe i686 encompasses Pentium Pro, Pentium II, Pentium III, Pentium IV, Core, Core 2, etc. I think I bought a Pentium in 1995. However I have two machines that I'm not sure are i686. Hm, er, I guess just one machine. I thought the "Pentium M" sticker might imply i586, but there is evidence otherwise: The OpenBSD/i386 Hudson machine: $ sysctl | grep hw hw.machine=i386 hw.model=Intel(R) Pentium(R) M processor 1.70GHz ("GenuineIntel" 686-class) hw.ncpu=1 hw.product=HP Compaq nc4010 (PF672AA#ABA) $ a "Fit PC 2.0", doesn't get much use: jay at xlin ~ $ uname -a Linux xlin 2.6.25-gentoo-r7 #5 Sun Oct 5 18:59:56 Local time zone must be set--s ee zic manua i586 Geode(TM) Integrated Processor by AMD PCS AuthenticAMD GNU/Lin ux jay at xlin ~ $ That really might might not be "i686". I guess, er, um, for m3gdb, there's no point in going past i386? The point is the target really, not the host. gdb is not performance sensitive. gcc is probably always going to be slow, but it can produce faster/slower code. This stuff is only used currently for cross builds, though it might be reasonable to use it for native builds too. Like, you know, if I build on a Core 2, you probably don't want the cm3cg producing code that doesn't work on a Pentium IV or somesuch. - Jay From jay.krell at cornell.edu Mon Aug 17 15:18:43 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 17 Aug 2009 13:18:43 +0000 Subject: [M3devel] more crashers In-Reply-To: <20090817133026.6v9cm3cu0wwkc08k@mail.elegosoft.com> References: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> <20090817133026.6v9cm3cu0wwkc08k@mail.elegosoft.com> Message-ID: Not as much luck as I'd like. PTHREAD_STACK_MIN Solaris: 4K Linux/sparc: 24K Linux/x86: 16K Linux/powerpc: 128K The overflowing stack, with 16K: current thread: t at 12 =>[1] Rd__CharsReady(0xfd61a00c, 0xfd617410, 0xfd59fb6c, 0x0, 0xfd59fb84, 0xfd59 fb8c), at 0xfec58578 ---- 1 following frame from gwindows -- possible stack overflow [2] SynScan__LookChar(0xfd883670, 0xfd8aa81c, 0xfd59fb6c, 0x0, 0xfd59fb84, 0xf d59fb8c), at 0xfead71fc [3] SynScan__NextToken(0xfd883670, 0xfd8ab980, 0x9, 0x0, 0xfd59fb84, 0xfd59fb8 c), at 0xfead91c4 [4] SynScan__LookToken(0xfd883670, 0x4ae, 0x9, 0x0, 0xfd59fb84, 0xfd59fb8c), a t 0xfead9628 [5] SynScan__HaveTokenName(0xfd883670, 0xfd5f7768, 0x8, 0x0, 0xfd59fb84, 0xfd5 9fb8c), at 0xfeadd084 [6] SynParse__Read0(0xfd883654, 0xfd6174ac, 0xfd59fb6c, 0x0, 0xfd59fb84, 0xfd5 9fb8c), at 0xfeae4760 [7] SynParse__Read0(0xfd883654, 0xfd617460, 0xfd59fb6c, 0x0, 0xfd59fb84, 0xfd5 9fb8c), at 0xfeae5e8c hundreds of frames of Lots of SynParse__Read0, using about 1K per frame; there is a try in there. d59fb8c), at 0xfeae348c [666] SynParse__Read0(0xfd883654, 0xfd6172d8, 0xfd59fb6c, 0x0, 0xfd59fb84, 0xf d59fb8c), at 0xfeae5e8c [667] SynParse__Read0(0xfd883654, 0xfd8aaa6c, 0xfd59fb6c, 0x0, 0xfd59fb84, 0xf d59fb8c), at 0xfeae3dd4 [668] SynParse__Read0(0xfd883654, 0xfd617288, 0xfd59fb6c, 0x0, 0xfd59fb84, 0xf d59fb8c), at 0xfeae3168 [669] SynParse__Read0(0xfd883654, 0xfd8aacec, 0xfd59fb6c, 0x0, 0xfd59fb84, 0xf d59fb8c), at 0xfeae6230 [670] SynParse__Read1(0xfd883654, 0xfd8aacec, 0x0, 0xfd59fb84, 0xfd59fb8c, 0x0 ), at 0xfeae2674 [671] SynParse__Read(0xfd883654, 0xfd8aacec, 0x0, 0xfd803a00, 0x0, 0xfebee308) , at 0xfeadfb60 [672] SynParse__ReadNonTerminal(0xfd883654, 0xfefed45c, 0xfd61b250, 0xfd61b8cc , 0xfd61b280, 0xfd89a27c), at 0xfeadfae8 [673] ObliqParser__ParsePhrase(0xfd883654, 0x0, 0xfd61b250, 0xfd61b8cc, 0xfd61 b280, 0x0), at 0xfefd5ff0 [674] ObliqOnline__Interact(0xfd89a848, 0xc32a0, 0xfd61a00c, 0x1, 0x1, 0xfebee 308), at 0xff36b80c [675] ObliqRuntime__ForkedDo(0xfd3ddfb8, 0x9658aac0, 0xff000000, 0x0, 0xfd9100 90, 0x0), at 0x80db0 [676] ThreadPThread__RunThread(0xef2b0, 0x0, 0x0, 0x0, 0xfd803a00, 0x1), at 0x fe06bc88 [677] ThreadPThread__ThreadBase(0xef2b0, 0xfd5a0000, 0x0, 0x0, 0xfe06b7c8, 0x1 ), at 0xfe06b818 One of the problems with defining a unit of stack size is the large variety of jmpbuf size. But heck, why 1K per frame here when SOLsun has a stack walker? Hm. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Subject: RE: [M3devel] more crashers > Date: Mon, 17 Aug 2009 11:35:40 +0000 > > > - I think the whole machine stack mechanism is pretty hopelessly broken. > Not just in Modula-3. Therefore my enthusiasm to attempt to "fix" > it -- which is impossible -- isn't very high. > > - I'm hoping to find that no platform other than Solaris lets you > even use such a small stack. I have to experiment some in a bit. > Depending on that experiment, we'll be in a better position, without > any further changes, but again, depending on what I find. > That is, if every other platform already had a larger stack, then this > just brings Solaris inline with the rest. If the other platforms > were actually successfully using a 4K stack, then indeed a problem. > > > - It could also be a factor of optimization. > Maybe ensuring -O2 or -O3 is used more would cover it up?? > > > - Or some other changes. > That is, if we have drastically increased stack usage, we should try > to reduce it back down. But given that 4K was the previous value > and even 16K doesn't work...I'm not hopeful we could fit it back down in 4K. > > It is easy enough to see the bug and then look at the various frames > and see if they use a lot of stack and can be reduced. > > - Jay > > > > ---------------------------------------- >> Date: Mon, 17 Aug 2009 13:30:26 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] more crashers >> >> Quoting Jay K : >> >>> visobliq was stack overflow. >>> Raising the default from 4K to 16K didn't fix, but 32K did. >> >> We need to address this somehow. It cannot be correct if the user >> needs to increase the default stack size on one platform by 8 >> and not at all on another. Do we have any concept of a 'standard >> stack size unit' ;-)? Something that can be easily understood and >> implemented and be used instead of the machine words in the current >> interfaces? Any ideas? >> >> Olaf >> >> >>> - Jay >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: hosking at cs.purdue.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: RE: [M3devel] more crashers >>>> Date: Sun, 16 Aug 2009 20:32:31 +0000 >>>> >>>> >>>> m3browser: >>>> >>>> It is specific to my config file >>>> m3-sys/cminstall/src/config-no-install/cm3.cfg that reachs back >>>> into the source tree. It won't happen with what most people do. I >>>> have to do that M3Predefines or such work so that all the uses of >>>> m3quake besides cm3 are much more like cm3. >>>> >>>> >>>> visobliq: >>>> not the same thing >>>> Does not occur on Linux/x86 or Linux/sparc. >>>> They do print >>>> Syntax error just before: -helvetica-bold-\*R-\*240-\*\") (LabelFo ... >>>> ill-formed character escape sequence >>>> Error detected (file file generated by Visual Obliq) (line 18, char 10) >>>> VideoVBT.Start Jv ServerFailure:errno=0 >>>> >>>> but then gui comes up. >>>> I'll have to finish my Solaris reinstall and get dbx. >>>> >>>> >>>> - Jay >>>> >>>> >>>> ---------------------------------------- >>>>> From: jay.krell at cornell.edu >>>>> To: hosking at cs.purdue.edu >>>>> Date: Sun, 16 Aug 2009 20:22:49 +0000 >>>>> CC: m3devel at elegosoft.com >>>>> Subject: Re: [M3devel] more crashers >>>>> >>>>> >>>>> sorry, this is simple. >>>>> >>>>> derived_dirs := IntList.List1 (ID.Add (MxConfig.Get("BUILD_DIR"))); >>>>> >>>>> >>>>> - Jay >>>>> >>>>> >>>>> >>>>> ---------------------------------------- >>>>>> From: jay.krell at cornell.edu >>>>>> To: hosking at cs.purdue.edu >>>>>> Date: Sun, 16 Aug 2009 19:52:03 +0000 >>>>>> CC: m3devel at elegosoft.com >>>>>> Subject: Re: [M3devel] more crashers >>>>>> >>>>>> >>>>>> Here is the relevant code in m3browser ID.m3: >>>>>> >>>>>> >>>>>> C:\dev2\cm3.2\m3-tools\m3markup\src\ID.m3(38): empty_id := Add (""); >>>>>> >>>>>> empty_id := Add (""); >>>>>> >>>>>> (*-------------------------------------------------------------- >>>>>> exported ---*) >>>>>> PROCEDURE Add (x: TEXT): T = >>>>>> VAR >>>>>> t: T; >>>>>> a: REF ARRAY OF CHAR; >>>>>> l: INTEGER; >>>>>> BEGIN >>>>>> l := Text.Length(x); >>>>>> ... >>>>>> END Add; >>>>>> >>>>>> >>>>>> The empty string constant ends up as null. >>>>>> >>>>>> .stabn 68,0,38,.LM115-.LFBB10 >>>>>> .LM115: >>>>>> movl L_1 at GOT(%ebx), %eax >>>>>> leal 24(%eax), %eax >>>>>> movl %eax, (%esp) >>>>>> call ID__Add at PLT >>>>>> movl %eax, -8(%ebp) >>>>>> movl -8(%ebp), %ecx >>>>>> movl MM_ID at GOT(%ebx), %edx >>>>>> movl 248(%edx), %eax >>>>>> andl $0, %eax >>>>>> orl %ecx, %eax >>>>>> movl %eax, 248(%edx) >>>>>> .L136: >>>>>> movl MM_ID at GOT(%ebx), %eax >>>>>> .LBE16: >>>>>> addl $52, %esp >>>>>> popl %ebx >>>>>> popl %ebp >>>>>> ret >>>>>> >>>>>> L_1: >>>>>> 0 .long RTHooks__TextLitInfo >>>>>> 4 .long RTHooks__TextLitGetChar >>>>>> 8 .long RTHooks__TextLitGetWideChar >>>>>> 12 .long RTHooks__TextLitGetChars >>>>>> 16 .long RTHooks__TextLitGetWideChars >>>>>> 20 .long 2 >>>>>> 24 .long L_1 >>>>>> .long 0 >>>>>> .zero 4 >>>>>> .ascii "ID_M3" >>>>>> .zero 1 >>>>>> .ascii "ExpandHashTable" >>>>>> .zero 1 >>>>>> .ascii "ExpandIDs" >>>>>> .zero 1 >>>>>> .ascii "ExpandChars" >>>>>> .zero 1 >>>>>> .ascii "Compare" >>>>>> .zero 1 >>>>>> >>>>>> If I change "" to "foo", I get: >>>>>> >>>>>> L_1: >>>>>> 0 .long RTHooks__TextLitInfo >>>>>> 4 .long RTHooks__TextLitGetChar >>>>>> 8 .long RTHooks__TextLitGetWideChar >>>>>> 12 .long RTHooks__TextLitGetChars >>>>>> 16 .long RTHooks__TextLitGetWideChars >>>>>> 20 .long 2 >>>>>> 24 .long L_1 >>>>>> .long 3 >>>>>> .ascii "foo" >>>>>> .zero 1 >>>>>> .ascii "ID_M3" >>>>>> >>>>>> and it still crashes. >>>>>> >>>>>> >>>>>> It seems to hit ID__Add twice when only once would be expected. >>>>>> >>>>>> >>>>>> - Jay >>>>>> >>>>>> >>>>>> ---------------------------------------- >>>>>>> From: jay.krell at cornell.edu >>>>>>> To: hosking at cs.purdue.edu >>>>>>> Date: Sun, 16 Aug 2009 19:33:34 +0000 >>>>>>> CC: m3devel at elegosoft.com >>>>>>> Subject: Re: [M3devel] more crashers >>>>>>> >>>>>>> >>>>>>> Could be. I've also seen it on PPC_DARWIN a while ago. I only >>>>>>> recall seeing it on sparc and ppc. >>>>>>> It doesn't always occur. >>>>>>> >>>>>>> >>>>>>> Here is the m3browser crash on a system that can be debugged. >>>>>>> See why I want the full paths in the debug info? >>>>>>> >>>>>>> >>>>>>> C:\Users\jay\Desktop>\cygwin\bin\ssh xobsd. >>>>>>> $ cd /cm3 >>>>>>> $ cd bin >>>>>>> $ export DISPLAY=192.168.1.120:0.0 >>>>>>> $ gdb ./m3browser >>>>>>> GNU gdb 6.3 >>>>>>> This GDB was configured as "i386-unknown-openbsd4.5"... >>>>>>> (gdb) r >>>>>>> Starting program: /home/jay/cm3/bin/m3browser >>>>>>> Program received signal SIGSEGV, Segmentation fault. >>>>>>> [Switching to process 31063, thread 0x7eafe800] >>>>>>> 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 >>>>>>> 16 t.get_info (i); >>>>>>> (gdb) bt >>>>>>> #0 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 >>>>>>> #1 0x09fd9464 in ID__Add (M3_Bd56fi_x=0x0) at ../src/ID.m3:48 >>>>>>> #2 0x1c01e644 in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:37 >>>>>>> #3 0x0156f1bc in RTLinker__RunMainBody (M3_DjPxE3_m=0x3c003ec0) >>>>>>> at ../src/runtime/common/RTLinker.m3:399 >>>>>>> #4 0x0156e576 in RTLinker__AddUnitI (M3_DjPxE3_m=0x3c003ec0) >>>>>>> at ../src/runtime/common/RTLinker.m3:113 >>>>>>> #5 0x0156e604 in RTLinker__AddUnit (M3_DjPxE5_b=0x1c01e54d) >>>>>>> at ../src/runtime/common/RTLinker.m3:122 >>>>>>> #6 0x1c004676 in main (argc=1, argv=0xcfbf6a3c, envp=0xcfbf6a44) >>>>>>> at _m3main.mc:4 >>>>>>> >>>>>>> >>>>>>> - Jay >>>>>>> >>>>>>> >>>>>>> ________________________________ >>>>>>>> From: hosking at cs.purdue.edu >>>>>>>> To: jay.krell at cornell.edu >>>>>>>> Date: Sun, 16 Aug 2009 15:26:49 -0400 >>>>>>>> CC: m3devel at elegosoft.com >>>>>>>> Subject: Re: [M3devel] more crashers >>>>>>>> >>>>>>>> Could this be endianness-related? >>>>>>>> >>>>>>>> On 16 Aug 2009, at 15:21, Jay K wrote: >>>>>>>> >>>>>>>> >>>>>>>> I see the assertion failure on PPC_LINUX too. >>>>>>>> I tried VAR defaultStackSize := 1024 * 1024; (not sure why >>>>>>>> there was any suspicion of stack size). >>>>>>>> >>>>>>>> >>>>>>>> Debugging doesn't work PPC_LINUX. >>>>>>>> >>>>>>>> >>>>>>>> jay at plin:/cm3/bin$ gdb ./cm3 >>>>>>>> GNU gdb 6.8-debian >>>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>> This is free software: you are free to change and redistribute it. >>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>> "show copying" >>>>>>>> and "show warranty" for details. >>>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>>> break ma(gdb) break main >>>>>>>> Breakpoint 1 at 0x86fc4: file _m3main.mc, line 2. >>>>>>>> (gdb) r >>>>>>>> Starting program: /home/jay/cm3/bin/cm3 >>>>>>>> Warning: >>>>>>>> Cannot insert breakpoint 1. >>>>>>>> Error accessing memory address 0x86fc4: Input/output error. >>>>>>>> >>>>>>>> >>>>>>>> No problem with C: >>>>>>>> >>>>>>>> >>>>>>>> jay at plin:/cm3/bin$ echo "main(){}"> 1.c >>>>>>>> jay at plin:/cm3/bin$ gcc -g 1.c >>>>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>>>> GNU gdb 6.8-debian >>>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>> This is free software: you are free to change and redistribute it. >>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>> "show copying" >>>>>>>> and "show warranty" for details. >>>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>>> (gdb) break main >>>>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>>>> (gdb) r >>>>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>>>> Breakpoint 1, main () at 1.c:1 >>>>>>>> 1 main(){} >>>>>>>> (gdb) >>>>>>>> >>>>>>>> >>>>>>>> jay at plin:/cm3/bin$ gcc -gstabs+ 1.c >>>>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>>>> GNU gdb 6.8-debian >>>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>> This is free software: you are free to change and redistribute it. >>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>> "show copying" >>>>>>>> and "show warranty" for details. >>>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>>> (gdb) break main >>>>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>>>> (gdb) r >>>>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>>>> Breakpoint 1, main () at 1.c:1 >>>>>>>> 1 main(){} >>>>>>>> >>>>>>>> >>>>>>>> jay at plin:/cm3/bin$ gcc -gstabs 1.c >>>>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>>>> GNU gdb 6.8-debian >>>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>> This is free software: you are free to change and redistribute it. >>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>> "show copying" >>>>>>>> and "show warranty" for details. >>>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>>> (gdb) break main >>>>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>>>> (gdb) r >>>>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>>>> Breakpoint 1, main () at 1.c:1 >>>>>>>> 1 main(){} >>>>>>>> (gdb) >>>>>>>> >>>>>>>> >>>>>>>> - Jay >>>>>>>> >>>>>>>> >>>>>>>> ---------------------------------------- >>>>>>>> From: jay.krell at cornell.edu >>>>>>>> To: m3devel at elegosoft.com >>>>>>>> Subject: more crashers >>>>>>>> Date: Sun, 16 Aug 2009 10:06:15 +0000 >>>>>>>> >>>>>>>> >>>>>>>> This is head on SOLgnu: >>>>>>>> I'll try another and debug and see if fix is easy. >>>>>>>> >>>>>>>> -bash-3.00$ ./m3browser >>>>>>>> >>>>>>>> *** >>>>>>>> *** runtime error: >>>>>>>> *** Segmentation violation - possible attempt to dereference NIL >>>>>>>> *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/String16.m3 >>>>>>>> *** >>>>>>>> >>>>>>>> -bash-3.00$ ./visobliq >>>>>>>> Internal Obliq interpreter installed... >>>>>>>> Establishing 'templates' >>>>>>>> (Created frame 'templates') >>>>>>>> let >>>>>>>> Templates = >>>>>>>> {boolean=> ... , >>>>>>>> browser=> ... , >>>>>>>> button=> ... , >>>>>>>> choice=> ... , >>>>>>>> filebrowser=> ... , >>>>>>>> form=> ... , >>>>>>>> frame=> ... , >>>>>>>> hscroll=> ... , >>>>>>>> menu=> ... , >>>>>>>> numeric=> ... , >>>>>>>> text=> ... , >>>>>>>> textedit=> ... , >>>>>>>> typein=> ... , >>>>>>>> video=> ... , >>>>>>>> vscroll=> ... } >>>>>>>> Establishing 'vowidgets' >>>>>>>> (Created frame 'vowidgets') >>>>>>>> ok >>>>>>>> Establishing 'vocheckpt' >>>>>>>> (Created frame 'vocheckpt') >>>>>>>> ok >>>>>>>> Establishing 'volib' >>>>>>>> (Created frame 'volib') >>>>>>>> Segmentation Fault (core dumped) >>>>>>>> -bash-3.00$ >>>>>>>> >>>>>>>> >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> From hosking at cs.purdue.edu Mon Aug 17 16:47:46 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 17 Aug 2009 10:47:46 -0400 Subject: [M3devel] more crashers In-Reply-To: References: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> <20090817133026.6v9cm3cu0wwkc08k@mail.elegosoft.com> Message-ID: Indeed, we might be better off investing effort in getting rid of try- blocks implemented using setjmp/longjmp so as to avoid the stack- allocated jmpbuf state. Or perhaps allocate that state in the heap. On 17 Aug 2009, at 09:18, Jay K wrote: > > Not as much luck as I'd like. > > > PTHREAD_STACK_MIN > Solaris: 4K > Linux/sparc: 24K > Linux/x86: 16K > Linux/powerpc: 128K > > > The overflowing stack, with 16K: > > > current thread: t at 12 > =>[1] Rd__CharsReady(0xfd61a00c, 0xfd617410, 0xfd59fb6c, 0x0, > 0xfd59fb84, 0xfd59 > fb8c), at 0xfec58578 > ---- 1 following frame from gwindows -- possible stack overflow > [2] SynScan__LookChar(0xfd883670, 0xfd8aa81c, 0xfd59fb6c, 0x0, > 0xfd59fb84, 0xf > d59fb8c), at 0xfead71fc > [3] SynScan__NextToken(0xfd883670, 0xfd8ab980, 0x9, 0x0, > 0xfd59fb84, 0xfd59fb8 > c), at 0xfead91c4 > [4] SynScan__LookToken(0xfd883670, 0x4ae, 0x9, 0x0, 0xfd59fb84, > 0xfd59fb8c), a > t 0xfead9628 > [5] SynScan__HaveTokenName(0xfd883670, 0xfd5f7768, 0x8, 0x0, > 0xfd59fb84, 0xfd5 > 9fb8c), at 0xfeadd084 > [6] SynParse__Read0(0xfd883654, 0xfd6174ac, 0xfd59fb6c, 0x0, > 0xfd59fb84, 0xfd5 > 9fb8c), at 0xfeae4760 > [7] SynParse__Read0(0xfd883654, 0xfd617460, 0xfd59fb6c, 0x0, > 0xfd59fb84, 0xfd5 > 9fb8c), at 0xfeae5e8c > > > hundreds of frames of Lots of SynParse__Read0, using about 1K per > frame; there is a try in there. > > d59fb8c), at 0xfeae348c > [666] SynParse__Read0(0xfd883654, 0xfd6172d8, 0xfd59fb6c, 0x0, > 0xfd59fb84, 0xf > d59fb8c), at 0xfeae5e8c > [667] SynParse__Read0(0xfd883654, 0xfd8aaa6c, 0xfd59fb6c, 0x0, > 0xfd59fb84, 0xf > d59fb8c), at 0xfeae3dd4 > [668] SynParse__Read0(0xfd883654, 0xfd617288, 0xfd59fb6c, 0x0, > 0xfd59fb84, 0xf > d59fb8c), at 0xfeae3168 > [669] SynParse__Read0(0xfd883654, 0xfd8aacec, 0xfd59fb6c, 0x0, > 0xfd59fb84, 0xf > d59fb8c), at 0xfeae6230 > [670] SynParse__Read1(0xfd883654, 0xfd8aacec, 0x0, 0xfd59fb84, > 0xfd59fb8c, 0x0 > ), at 0xfeae2674 > [671] SynParse__Read(0xfd883654, 0xfd8aacec, 0x0, 0xfd803a00, 0x0, > 0xfebee308) > , at 0xfeadfb60 > [672] SynParse__ReadNonTerminal(0xfd883654, 0xfefed45c, 0xfd61b250, > 0xfd61b8cc > , 0xfd61b280, 0xfd89a27c), at 0xfeadfae8 > [673] ObliqParser__ParsePhrase(0xfd883654, 0x0, 0xfd61b250, > 0xfd61b8cc, 0xfd61 > b280, 0x0), at 0xfefd5ff0 > [674] ObliqOnline__Interact(0xfd89a848, 0xc32a0, 0xfd61a00c, 0x1, > 0x1, 0xfebee > 308), at 0xff36b80c > [675] ObliqRuntime__ForkedDo(0xfd3ddfb8, 0x9658aac0, 0xff000000, > 0x0, 0xfd9100 > 90, 0x0), at 0x80db0 > [676] ThreadPThread__RunThread(0xef2b0, 0x0, 0x0, 0x0, 0xfd803a00, > 0x1), at 0x > fe06bc88 > [677] ThreadPThread__ThreadBase(0xef2b0, 0xfd5a0000, 0x0, 0x0, > 0xfe06b7c8, 0x1 > ), at 0xfe06b818 > > > One of the problems with defining a unit of stack size is the large > variety of jmpbuf size. > But heck, why 1K per frame here when SOLsun has a stack walker? Hm. > > - Jay > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com; m3devel at elegosoft.com >> Subject: RE: [M3devel] more crashers >> Date: Mon, 17 Aug 2009 11:35:40 +0000 >> >> >> - I think the whole machine stack mechanism is pretty hopelessly >> broken. >> Not just in Modula-3. Therefore my enthusiasm to attempt to "fix" >> it -- which is impossible -- isn't very high. >> >> - I'm hoping to find that no platform other than Solaris lets you >> even use such a small stack. I have to experiment some in a bit. >> Depending on that experiment, we'll be in a better position, without >> any further changes, but again, depending on what I find. >> That is, if every other platform already had a larger stack, then >> this >> just brings Solaris inline with the rest. If the other platforms >> were actually successfully using a 4K stack, then indeed a problem. >> >> >> - It could also be a factor of optimization. >> Maybe ensuring -O2 or -O3 is used more would cover it up?? >> >> >> - Or some other changes. >> That is, if we have drastically increased stack usage, we should try >> to reduce it back down. But given that 4K was the previous value >> and even 16K doesn't work...I'm not hopeful we could fit it back >> down in 4K. >> >> It is easy enough to see the bug and then look at the various frames >> and see if they use a lot of stack and can be reduced. >> >> - Jay >> >> >> >> ---------------------------------------- >>> Date: Mon, 17 Aug 2009 13:30:26 +0200 >>> From: wagner at elegosoft.com >>> To: m3devel at elegosoft.com >>> Subject: Re: [M3devel] more crashers >>> >>> Quoting Jay K : >>> >>>> visobliq was stack overflow. >>>> Raising the default from 4K to 16K didn't fix, but 32K did. >>> >>> We need to address this somehow. It cannot be correct if the user >>> needs to increase the default stack size on one platform by 8 >>> and not at all on another. Do we have any concept of a 'standard >>> stack size unit' ;-)? Something that can be easily understood and >>> implemented and be used instead of the machine words in the current >>> interfaces? Any ideas? >>> >>> Olaf >>> >>> >>>> - Jay >>>> >>>> ---------------------------------------- >>>>> From: jay.krell at cornell.edu >>>>> To: hosking at cs.purdue.edu >>>>> CC: m3devel at elegosoft.com >>>>> Subject: RE: [M3devel] more crashers >>>>> Date: Sun, 16 Aug 2009 20:32:31 +0000 >>>>> >>>>> >>>>> m3browser: >>>>> >>>>> It is specific to my config file >>>>> m3-sys/cminstall/src/config-no-install/cm3.cfg that reachs back >>>>> into the source tree. It won't happen with what most people do. I >>>>> have to do that M3Predefines or such work so that all the uses of >>>>> m3quake besides cm3 are much more like cm3. >>>>> >>>>> >>>>> visobliq: >>>>> not the same thing >>>>> Does not occur on Linux/x86 or Linux/sparc. >>>>> They do print >>>>> Syntax error just before: -helvetica-bold-\*R-\*240-\*\") >>>>> (LabelFo ... >>>>> ill-formed character escape sequence >>>>> Error detected (file file generated by Visual Obliq) (line 18, >>>>> char 10) >>>>> VideoVBT.Start Jv ServerFailure:errno=0 >>>>> >>>>> but then gui comes up. >>>>> I'll have to finish my Solaris reinstall and get dbx. >>>>> >>>>> >>>>> - Jay >>>>> >>>>> >>>>> ---------------------------------------- >>>>>> From: jay.krell at cornell.edu >>>>>> To: hosking at cs.purdue.edu >>>>>> Date: Sun, 16 Aug 2009 20:22:49 +0000 >>>>>> CC: m3devel at elegosoft.com >>>>>> Subject: Re: [M3devel] more crashers >>>>>> >>>>>> >>>>>> sorry, this is simple. >>>>>> >>>>>> derived_dirs := IntList.List1 (ID.Add >>>>>> (MxConfig.Get("BUILD_DIR"))); >>>>>> >>>>>> >>>>>> - Jay >>>>>> >>>>>> >>>>>> >>>>>> ---------------------------------------- >>>>>>> From: jay.krell at cornell.edu >>>>>>> To: hosking at cs.purdue.edu >>>>>>> Date: Sun, 16 Aug 2009 19:52:03 +0000 >>>>>>> CC: m3devel at elegosoft.com >>>>>>> Subject: Re: [M3devel] more crashers >>>>>>> >>>>>>> >>>>>>> Here is the relevant code in m3browser ID.m3: >>>>>>> >>>>>>> >>>>>>> C:\dev2\cm3.2\m3-tools\m3markup\src\ID.m3(38): empty_id := Add >>>>>>> (""); >>>>>>> >>>>>>> empty_id := Add (""); >>>>>>> >>>>>>> (*-------------------------------------------------------------- >>>>>>> exported ---*) >>>>>>> PROCEDURE Add (x: TEXT): T = >>>>>>> VAR >>>>>>> t: T; >>>>>>> a: REF ARRAY OF CHAR; >>>>>>> l: INTEGER; >>>>>>> BEGIN >>>>>>> l := Text.Length(x); >>>>>>> ... >>>>>>> END Add; >>>>>>> >>>>>>> >>>>>>> The empty string constant ends up as null. >>>>>>> >>>>>>> .stabn 68,0,38,.LM115-.LFBB10 >>>>>>> .LM115: >>>>>>> movl L_1 at GOT(%ebx), %eax >>>>>>> leal 24(%eax), %eax >>>>>>> movl %eax, (%esp) >>>>>>> call ID__Add at PLT >>>>>>> movl %eax, -8(%ebp) >>>>>>> movl -8(%ebp), %ecx >>>>>>> movl MM_ID at GOT(%ebx), %edx >>>>>>> movl 248(%edx), %eax >>>>>>> andl $0, %eax >>>>>>> orl %ecx, %eax >>>>>>> movl %eax, 248(%edx) >>>>>>> .L136: >>>>>>> movl MM_ID at GOT(%ebx), %eax >>>>>>> .LBE16: >>>>>>> addl $52, %esp >>>>>>> popl %ebx >>>>>>> popl %ebp >>>>>>> ret >>>>>>> >>>>>>> L_1: >>>>>>> 0 .long RTHooks__TextLitInfo >>>>>>> 4 .long RTHooks__TextLitGetChar >>>>>>> 8 .long RTHooks__TextLitGetWideChar >>>>>>> 12 .long RTHooks__TextLitGetChars >>>>>>> 16 .long RTHooks__TextLitGetWideChars >>>>>>> 20 .long 2 >>>>>>> 24 .long L_1 >>>>>>> .long 0 >>>>>>> .zero 4 >>>>>>> .ascii "ID_M3" >>>>>>> .zero 1 >>>>>>> .ascii "ExpandHashTable" >>>>>>> .zero 1 >>>>>>> .ascii "ExpandIDs" >>>>>>> .zero 1 >>>>>>> .ascii "ExpandChars" >>>>>>> .zero 1 >>>>>>> .ascii "Compare" >>>>>>> .zero 1 >>>>>>> >>>>>>> If I change "" to "foo", I get: >>>>>>> >>>>>>> L_1: >>>>>>> 0 .long RTHooks__TextLitInfo >>>>>>> 4 .long RTHooks__TextLitGetChar >>>>>>> 8 .long RTHooks__TextLitGetWideChar >>>>>>> 12 .long RTHooks__TextLitGetChars >>>>>>> 16 .long RTHooks__TextLitGetWideChars >>>>>>> 20 .long 2 >>>>>>> 24 .long L_1 >>>>>>> .long 3 >>>>>>> .ascii "foo" >>>>>>> .zero 1 >>>>>>> .ascii "ID_M3" >>>>>>> >>>>>>> and it still crashes. >>>>>>> >>>>>>> >>>>>>> It seems to hit ID__Add twice when only once would be expected. >>>>>>> >>>>>>> >>>>>>> - Jay >>>>>>> >>>>>>> >>>>>>> ---------------------------------------- >>>>>>>> From: jay.krell at cornell.edu >>>>>>>> To: hosking at cs.purdue.edu >>>>>>>> Date: Sun, 16 Aug 2009 19:33:34 +0000 >>>>>>>> CC: m3devel at elegosoft.com >>>>>>>> Subject: Re: [M3devel] more crashers >>>>>>>> >>>>>>>> >>>>>>>> Could be. I've also seen it on PPC_DARWIN a while ago. I only >>>>>>>> recall seeing it on sparc and ppc. >>>>>>>> It doesn't always occur. >>>>>>>> >>>>>>>> >>>>>>>> Here is the m3browser crash on a system that can be debugged. >>>>>>>> See why I want the full paths in the debug info? >>>>>>>> >>>>>>>> >>>>>>>> C:\Users\jay\Desktop>\cygwin\bin\ssh xobsd. >>>>>>>> $ cd /cm3 >>>>>>>> $ cd bin >>>>>>>> $ export DISPLAY=192.168.1.120:0.0 >>>>>>>> $ gdb ./m3browser >>>>>>>> GNU gdb 6.3 >>>>>>>> This GDB was configured as "i386-unknown-openbsd4.5"... >>>>>>>> (gdb) r >>>>>>>> Starting program: /home/jay/cm3/bin/m3browser >>>>>>>> Program received signal SIGSEGV, Segmentation fault. >>>>>>>> [Switching to process 31063, thread 0x7eafe800] >>>>>>>> 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/ >>>>>>>> Text.m3:16 >>>>>>>> 16 t.get_info (i); >>>>>>>> (gdb) bt >>>>>>>> #0 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/ >>>>>>>> text/Text.m3:16 >>>>>>>> #1 0x09fd9464 in ID__Add (M3_Bd56fi_x=0x0) at ../src/ID.m3:48 >>>>>>>> #2 0x1c01e644 in Main_M3 (M3_AcxOUs_mode=1) at ../src/ >>>>>>>> Main.m3:37 >>>>>>>> #3 0x0156f1bc in RTLinker__RunMainBody (M3_DjPxE3_m=0x3c003ec0) >>>>>>>> at ../src/runtime/common/RTLinker.m3:399 >>>>>>>> #4 0x0156e576 in RTLinker__AddUnitI (M3_DjPxE3_m=0x3c003ec0) >>>>>>>> at ../src/runtime/common/RTLinker.m3:113 >>>>>>>> #5 0x0156e604 in RTLinker__AddUnit (M3_DjPxE5_b=0x1c01e54d) >>>>>>>> at ../src/runtime/common/RTLinker.m3:122 >>>>>>>> #6 0x1c004676 in main (argc=1, argv=0xcfbf6a3c, >>>>>>>> envp=0xcfbf6a44) >>>>>>>> at _m3main.mc:4 >>>>>>>> >>>>>>>> >>>>>>>> - Jay >>>>>>>> >>>>>>>> >>>>>>>> ________________________________ >>>>>>>>> From: hosking at cs.purdue.edu >>>>>>>>> To: jay.krell at cornell.edu >>>>>>>>> Date: Sun, 16 Aug 2009 15:26:49 -0400 >>>>>>>>> CC: m3devel at elegosoft.com >>>>>>>>> Subject: Re: [M3devel] more crashers >>>>>>>>> >>>>>>>>> Could this be endianness-related? >>>>>>>>> >>>>>>>>> On 16 Aug 2009, at 15:21, Jay K wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> I see the assertion failure on PPC_LINUX too. >>>>>>>>> I tried VAR defaultStackSize := 1024 * 1024; (not sure why >>>>>>>>> there was any suspicion of stack size). >>>>>>>>> >>>>>>>>> >>>>>>>>> Debugging doesn't work PPC_LINUX. >>>>>>>>> >>>>>>>>> >>>>>>>>> jay at plin:/cm3/bin$ gdb ./cm3 >>>>>>>>> GNU gdb 6.8-debian >>>>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>>> This is free software: you are free to change and >>>>>>>>> redistribute it. >>>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>>> "show copying" >>>>>>>>> and "show warranty" for details. >>>>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>>>> break ma(gdb) break main >>>>>>>>> Breakpoint 1 at 0x86fc4: file _m3main.mc, line 2. >>>>>>>>> (gdb) r >>>>>>>>> Starting program: /home/jay/cm3/bin/cm3 >>>>>>>>> Warning: >>>>>>>>> Cannot insert breakpoint 1. >>>>>>>>> Error accessing memory address 0x86fc4: Input/output error. >>>>>>>>> >>>>>>>>> >>>>>>>>> No problem with C: >>>>>>>>> >>>>>>>>> >>>>>>>>> jay at plin:/cm3/bin$ echo "main(){}"> 1.c >>>>>>>>> jay at plin:/cm3/bin$ gcc -g 1.c >>>>>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>>>>> GNU gdb 6.8-debian >>>>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>>> This is free software: you are free to change and >>>>>>>>> redistribute it. >>>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>>> "show copying" >>>>>>>>> and "show warranty" for details. >>>>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>>>> (gdb) break main >>>>>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>>>>> (gdb) r >>>>>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>>>>> Breakpoint 1, main () at 1.c:1 >>>>>>>>> 1 main(){} >>>>>>>>> (gdb) >>>>>>>>> >>>>>>>>> >>>>>>>>> jay at plin:/cm3/bin$ gcc -gstabs+ 1.c >>>>>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>>>>> GNU gdb 6.8-debian >>>>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>>> This is free software: you are free to change and >>>>>>>>> redistribute it. >>>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>>> "show copying" >>>>>>>>> and "show warranty" for details. >>>>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>>>> (gdb) break main >>>>>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>>>>> (gdb) r >>>>>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>>>>> Breakpoint 1, main () at 1.c:1 >>>>>>>>> 1 main(){} >>>>>>>>> >>>>>>>>> >>>>>>>>> jay at plin:/cm3/bin$ gcc -gstabs 1.c >>>>>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>>>>> GNU gdb 6.8-debian >>>>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>>> This is free software: you are free to change and >>>>>>>>> redistribute it. >>>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>>> "show copying" >>>>>>>>> and "show warranty" for details. >>>>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>>>> (gdb) break main >>>>>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>>>>> (gdb) r >>>>>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>>>>> Breakpoint 1, main () at 1.c:1 >>>>>>>>> 1 main(){} >>>>>>>>> (gdb) >>>>>>>>> >>>>>>>>> >>>>>>>>> - Jay >>>>>>>>> >>>>>>>>> >>>>>>>>> ---------------------------------------- >>>>>>>>> From: jay.krell at cornell.edu >>>>>>>>> To: m3devel at elegosoft.com >>>>>>>>> Subject: more crashers >>>>>>>>> Date: Sun, 16 Aug 2009 10:06:15 +0000 >>>>>>>>> >>>>>>>>> >>>>>>>>> This is head on SOLgnu: >>>>>>>>> I'll try another and debug and see if fix is easy. >>>>>>>>> >>>>>>>>> -bash-3.00$ ./m3browser >>>>>>>>> >>>>>>>>> *** >>>>>>>>> *** runtime error: >>>>>>>>> *** Segmentation violation - possible attempt to dereference >>>>>>>>> NIL >>>>>>>>> *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/ >>>>>>>>> String16.m3 >>>>>>>>> *** >>>>>>>>> >>>>>>>>> -bash-3.00$ ./visobliq >>>>>>>>> Internal Obliq interpreter installed... >>>>>>>>> Establishing 'templates' >>>>>>>>> (Created frame 'templates') >>>>>>>>> let >>>>>>>>> Templates = >>>>>>>>> {boolean=> ... , >>>>>>>>> browser=> ... , >>>>>>>>> button=> ... , >>>>>>>>> choice=> ... , >>>>>>>>> filebrowser=> ... , >>>>>>>>> form=> ... , >>>>>>>>> frame=> ... , >>>>>>>>> hscroll=> ... , >>>>>>>>> menu=> ... , >>>>>>>>> numeric=> ... , >>>>>>>>> text=> ... , >>>>>>>>> textedit=> ... , >>>>>>>>> typein=> ... , >>>>>>>>> video=> ... , >>>>>>>>> vscroll=> ... } >>>>>>>>> Establishing 'vowidgets' >>>>>>>>> (Created frame 'vowidgets') >>>>>>>>> ok >>>>>>>>> Establishing 'vocheckpt' >>>>>>>>> (Created frame 'vocheckpt') >>>>>>>>> ok >>>>>>>>> Establishing 'volib' >>>>>>>>> (Created frame 'volib') >>>>>>>>> Segmentation Fault (core dumped) >>>>>>>>> -bash-3.00$ >>>>>>>>> >>>>>>>>> >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>> 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>> Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Aug 17 17:13:29 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 17 Aug 2009 17:13:29 +0200 Subject: [M3devel] more crashers In-Reply-To: References: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> <20090817133026.6v9cm3cu0wwkc08k@mail.elegosoft.com> Message-ID: <20090817171329.dsbfoh9s04k0o84w@mail.elegosoft.com> Quoting Tony Hosking : > Indeed, we might be better off investing effort in getting rid of try- > blocks implemented using setjmp/longjmp so as to avoid the stack- > allocated jmpbuf state. Or perhaps allocate that state in the heap. Is this a feature for 5.9 then? ;-) Olaf > On 17 Aug 2009, at 09:18, Jay K wrote: > >> >> Not as much luck as I'd like. >> >> >> PTHREAD_STACK_MIN >> Solaris: 4K >> Linux/sparc: 24K >> Linux/x86: 16K >> Linux/powerpc: 128K >> >> >> The overflowing stack, with 16K: >> >> >> current thread: t at 12 >> =>[1] Rd__CharsReady(0xfd61a00c, 0xfd617410, 0xfd59fb6c, 0x0, >> 0xfd59fb84, 0xfd59 >> fb8c), at 0xfec58578 >> ---- 1 following frame from gwindows -- possible stack overflow >> [2] SynScan__LookChar(0xfd883670, 0xfd8aa81c, 0xfd59fb6c, 0x0, >> 0xfd59fb84, 0xf >> d59fb8c), at 0xfead71fc >> [3] SynScan__NextToken(0xfd883670, 0xfd8ab980, 0x9, 0x0, >> 0xfd59fb84, 0xfd59fb8 >> c), at 0xfead91c4 >> [4] SynScan__LookToken(0xfd883670, 0x4ae, 0x9, 0x0, 0xfd59fb84, >> 0xfd59fb8c), a >> t 0xfead9628 >> [5] SynScan__HaveTokenName(0xfd883670, 0xfd5f7768, 0x8, 0x0, >> 0xfd59fb84, 0xfd5 >> 9fb8c), at 0xfeadd084 >> [6] SynParse__Read0(0xfd883654, 0xfd6174ac, 0xfd59fb6c, 0x0, >> 0xfd59fb84, 0xfd5 >> 9fb8c), at 0xfeae4760 >> [7] SynParse__Read0(0xfd883654, 0xfd617460, 0xfd59fb6c, 0x0, >> 0xfd59fb84, 0xfd5 >> 9fb8c), at 0xfeae5e8c >> >> >> hundreds of frames of Lots of SynParse__Read0, using about 1K per >> frame; there is a try in there. >> >> d59fb8c), at 0xfeae348c >> [666] SynParse__Read0(0xfd883654, 0xfd6172d8, 0xfd59fb6c, 0x0, >> 0xfd59fb84, 0xf >> d59fb8c), at 0xfeae5e8c >> [667] SynParse__Read0(0xfd883654, 0xfd8aaa6c, 0xfd59fb6c, 0x0, >> 0xfd59fb84, 0xf >> d59fb8c), at 0xfeae3dd4 >> [668] SynParse__Read0(0xfd883654, 0xfd617288, 0xfd59fb6c, 0x0, >> 0xfd59fb84, 0xf >> d59fb8c), at 0xfeae3168 >> [669] SynParse__Read0(0xfd883654, 0xfd8aacec, 0xfd59fb6c, 0x0, >> 0xfd59fb84, 0xf >> d59fb8c), at 0xfeae6230 >> [670] SynParse__Read1(0xfd883654, 0xfd8aacec, 0x0, 0xfd59fb84, >> 0xfd59fb8c, 0x0 >> ), at 0xfeae2674 >> [671] SynParse__Read(0xfd883654, 0xfd8aacec, 0x0, 0xfd803a00, 0x0, >> 0xfebee308) >> , at 0xfeadfb60 >> [672] SynParse__ReadNonTerminal(0xfd883654, 0xfefed45c, 0xfd61b250, >> 0xfd61b8cc >> , 0xfd61b280, 0xfd89a27c), at 0xfeadfae8 >> [673] ObliqParser__ParsePhrase(0xfd883654, 0x0, 0xfd61b250, >> 0xfd61b8cc, 0xfd61 >> b280, 0x0), at 0xfefd5ff0 >> [674] ObliqOnline__Interact(0xfd89a848, 0xc32a0, 0xfd61a00c, 0x1, >> 0x1, 0xfebee >> 308), at 0xff36b80c >> [675] ObliqRuntime__ForkedDo(0xfd3ddfb8, 0x9658aac0, 0xff000000, >> 0x0, 0xfd9100 >> 90, 0x0), at 0x80db0 >> [676] ThreadPThread__RunThread(0xef2b0, 0x0, 0x0, 0x0, 0xfd803a00, >> 0x1), at 0x >> fe06bc88 >> [677] ThreadPThread__ThreadBase(0xef2b0, 0xfd5a0000, 0x0, 0x0, >> 0xfe06b7c8, 0x1 >> ), at 0xfe06b818 >> >> >> One of the problems with defining a unit of stack size is the large >> variety of jmpbuf size. >> But heck, why 1K per frame here when SOLsun has a stack walker? Hm. >> >> - Jay >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: wagner at elegosoft.com; m3devel at elegosoft.com >>> Subject: RE: [M3devel] more crashers >>> Date: Mon, 17 Aug 2009 11:35:40 +0000 >>> >>> >>> - I think the whole machine stack mechanism is pretty hopelessly broken. >>> Not just in Modula-3. Therefore my enthusiasm to attempt to "fix" >>> it -- which is impossible -- isn't very high. >>> >>> - I'm hoping to find that no platform other than Solaris lets you >>> even use such a small stack. I have to experiment some in a bit. >>> Depending on that experiment, we'll be in a better position, without >>> any further changes, but again, depending on what I find. >>> That is, if every other platform already had a larger stack, then this >>> just brings Solaris inline with the rest. If the other platforms >>> were actually successfully using a 4K stack, then indeed a problem. >>> >>> >>> - It could also be a factor of optimization. >>> Maybe ensuring -O2 or -O3 is used more would cover it up?? >>> >>> >>> - Or some other changes. >>> That is, if we have drastically increased stack usage, we should try >>> to reduce it back down. But given that 4K was the previous value >>> and even 16K doesn't work...I'm not hopeful we could fit it back >>> down in 4K. >>> >>> It is easy enough to see the bug and then look at the various frames >>> and see if they use a lot of stack and can be reduced. >>> >>> - Jay >>> >>> >>> >>> ---------------------------------------- >>>> Date: Mon, 17 Aug 2009 13:30:26 +0200 >>>> From: wagner at elegosoft.com >>>> To: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] more crashers >>>> >>>> Quoting Jay K : >>>> >>>>> visobliq was stack overflow. >>>>> Raising the default from 4K to 16K didn't fix, but 32K did. >>>> >>>> We need to address this somehow. It cannot be correct if the user >>>> needs to increase the default stack size on one platform by 8 >>>> and not at all on another. Do we have any concept of a 'standard >>>> stack size unit' ;-)? Something that can be easily understood and >>>> implemented and be used instead of the machine words in the current >>>> interfaces? Any ideas? >>>> >>>> Olaf >>>> >>>> >>>>> - Jay >>>>> >>>>> ---------------------------------------- >>>>>> From: jay.krell at cornell.edu >>>>>> To: hosking at cs.purdue.edu >>>>>> CC: m3devel at elegosoft.com >>>>>> Subject: RE: [M3devel] more crashers >>>>>> Date: Sun, 16 Aug 2009 20:32:31 +0000 >>>>>> >>>>>> >>>>>> m3browser: >>>>>> >>>>>> It is specific to my config file >>>>>> m3-sys/cminstall/src/config-no-install/cm3.cfg that reachs back >>>>>> into the source tree. It won't happen with what most people do. I >>>>>> have to do that M3Predefines or such work so that all the uses of >>>>>> m3quake besides cm3 are much more like cm3. >>>>>> >>>>>> >>>>>> visobliq: >>>>>> not the same thing >>>>>> Does not occur on Linux/x86 or Linux/sparc. >>>>>> They do print >>>>>> Syntax error just before: -helvetica-bold-\*R-\*240-\*\") (LabelFo ... >>>>>> ill-formed character escape sequence >>>>>> Error detected (file file generated by Visual Obliq) (line 18, char 10) >>>>>> VideoVBT.Start Jv ServerFailure:errno=0 >>>>>> >>>>>> but then gui comes up. >>>>>> I'll have to finish my Solaris reinstall and get dbx. >>>>>> >>>>>> >>>>>> - Jay >>>>>> >>>>>> >>>>>> ---------------------------------------- >>>>>>> From: jay.krell at cornell.edu >>>>>>> To: hosking at cs.purdue.edu >>>>>>> Date: Sun, 16 Aug 2009 20:22:49 +0000 >>>>>>> CC: m3devel at elegosoft.com >>>>>>> Subject: Re: [M3devel] more crashers >>>>>>> >>>>>>> >>>>>>> sorry, this is simple. >>>>>>> >>>>>>> derived_dirs := IntList.List1 (ID.Add (MxConfig.Get("BUILD_DIR"))); >>>>>>> >>>>>>> >>>>>>> - Jay >>>>>>> >>>>>>> >>>>>>> >>>>>>> ---------------------------------------- >>>>>>>> From: jay.krell at cornell.edu >>>>>>>> To: hosking at cs.purdue.edu >>>>>>>> Date: Sun, 16 Aug 2009 19:52:03 +0000 >>>>>>>> CC: m3devel at elegosoft.com >>>>>>>> Subject: Re: [M3devel] more crashers >>>>>>>> >>>>>>>> >>>>>>>> Here is the relevant code in m3browser ID.m3: >>>>>>>> >>>>>>>> >>>>>>>> C:\dev2\cm3.2\m3-tools\m3markup\src\ID.m3(38): empty_id := Add (""); >>>>>>>> >>>>>>>> empty_id := Add (""); >>>>>>>> >>>>>>>> (*-------------------------------------------------------------- >>>>>>>> exported ---*) >>>>>>>> PROCEDURE Add (x: TEXT): T = >>>>>>>> VAR >>>>>>>> t: T; >>>>>>>> a: REF ARRAY OF CHAR; >>>>>>>> l: INTEGER; >>>>>>>> BEGIN >>>>>>>> l := Text.Length(x); >>>>>>>> ... >>>>>>>> END Add; >>>>>>>> >>>>>>>> >>>>>>>> The empty string constant ends up as null. >>>>>>>> >>>>>>>> .stabn 68,0,38,.LM115-.LFBB10 >>>>>>>> .LM115: >>>>>>>> movl L_1 at GOT(%ebx), %eax >>>>>>>> leal 24(%eax), %eax >>>>>>>> movl %eax, (%esp) >>>>>>>> call ID__Add at PLT >>>>>>>> movl %eax, -8(%ebp) >>>>>>>> movl -8(%ebp), %ecx >>>>>>>> movl MM_ID at GOT(%ebx), %edx >>>>>>>> movl 248(%edx), %eax >>>>>>>> andl $0, %eax >>>>>>>> orl %ecx, %eax >>>>>>>> movl %eax, 248(%edx) >>>>>>>> .L136: >>>>>>>> movl MM_ID at GOT(%ebx), %eax >>>>>>>> .LBE16: >>>>>>>> addl $52, %esp >>>>>>>> popl %ebx >>>>>>>> popl %ebp >>>>>>>> ret >>>>>>>> >>>>>>>> L_1: >>>>>>>> 0 .long RTHooks__TextLitInfo >>>>>>>> 4 .long RTHooks__TextLitGetChar >>>>>>>> 8 .long RTHooks__TextLitGetWideChar >>>>>>>> 12 .long RTHooks__TextLitGetChars >>>>>>>> 16 .long RTHooks__TextLitGetWideChars >>>>>>>> 20 .long 2 >>>>>>>> 24 .long L_1 >>>>>>>> .long 0 >>>>>>>> .zero 4 >>>>>>>> .ascii "ID_M3" >>>>>>>> .zero 1 >>>>>>>> .ascii "ExpandHashTable" >>>>>>>> .zero 1 >>>>>>>> .ascii "ExpandIDs" >>>>>>>> .zero 1 >>>>>>>> .ascii "ExpandChars" >>>>>>>> .zero 1 >>>>>>>> .ascii "Compare" >>>>>>>> .zero 1 >>>>>>>> >>>>>>>> If I change "" to "foo", I get: >>>>>>>> >>>>>>>> L_1: >>>>>>>> 0 .long RTHooks__TextLitInfo >>>>>>>> 4 .long RTHooks__TextLitGetChar >>>>>>>> 8 .long RTHooks__TextLitGetWideChar >>>>>>>> 12 .long RTHooks__TextLitGetChars >>>>>>>> 16 .long RTHooks__TextLitGetWideChars >>>>>>>> 20 .long 2 >>>>>>>> 24 .long L_1 >>>>>>>> .long 3 >>>>>>>> .ascii "foo" >>>>>>>> .zero 1 >>>>>>>> .ascii "ID_M3" >>>>>>>> >>>>>>>> and it still crashes. >>>>>>>> >>>>>>>> >>>>>>>> It seems to hit ID__Add twice when only once would be expected. >>>>>>>> >>>>>>>> >>>>>>>> - Jay >>>>>>>> >>>>>>>> >>>>>>>> ---------------------------------------- >>>>>>>>> From: jay.krell at cornell.edu >>>>>>>>> To: hosking at cs.purdue.edu >>>>>>>>> Date: Sun, 16 Aug 2009 19:33:34 +0000 >>>>>>>>> CC: m3devel at elegosoft.com >>>>>>>>> Subject: Re: [M3devel] more crashers >>>>>>>>> >>>>>>>>> >>>>>>>>> Could be. I've also seen it on PPC_DARWIN a while ago. I only >>>>>>>>> recall seeing it on sparc and ppc. >>>>>>>>> It doesn't always occur. >>>>>>>>> >>>>>>>>> >>>>>>>>> Here is the m3browser crash on a system that can be debugged. >>>>>>>>> See why I want the full paths in the debug info? >>>>>>>>> >>>>>>>>> >>>>>>>>> C:\Users\jay\Desktop>\cygwin\bin\ssh xobsd. >>>>>>>>> $ cd /cm3 >>>>>>>>> $ cd bin >>>>>>>>> $ export DISPLAY=192.168.1.120:0.0 >>>>>>>>> $ gdb ./m3browser >>>>>>>>> GNU gdb 6.3 >>>>>>>>> This GDB was configured as "i386-unknown-openbsd4.5"... >>>>>>>>> (gdb) r >>>>>>>>> Starting program: /home/jay/cm3/bin/m3browser >>>>>>>>> Program received signal SIGSEGV, Segmentation fault. >>>>>>>>> [Switching to process 31063, thread 0x7eafe800] >>>>>>>>> 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/ >>>>>>>>> Text.m3:16 >>>>>>>>> 16 t.get_info (i); >>>>>>>>> (gdb) bt >>>>>>>>> #0 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/ >>>>>>>>> text/Text.m3:16 >>>>>>>>> #1 0x09fd9464 in ID__Add (M3_Bd56fi_x=0x0) at ../src/ID.m3:48 >>>>>>>>> #2 0x1c01e644 in Main_M3 (M3_AcxOUs_mode=1) at ../src/ Main.m3:37 >>>>>>>>> #3 0x0156f1bc in RTLinker__RunMainBody (M3_DjPxE3_m=0x3c003ec0) >>>>>>>>> at ../src/runtime/common/RTLinker.m3:399 >>>>>>>>> #4 0x0156e576 in RTLinker__AddUnitI (M3_DjPxE3_m=0x3c003ec0) >>>>>>>>> at ../src/runtime/common/RTLinker.m3:113 >>>>>>>>> #5 0x0156e604 in RTLinker__AddUnit (M3_DjPxE5_b=0x1c01e54d) >>>>>>>>> at ../src/runtime/common/RTLinker.m3:122 >>>>>>>>> #6 0x1c004676 in main (argc=1, argv=0xcfbf6a3c, envp=0xcfbf6a44) >>>>>>>>> at _m3main.mc:4 >>>>>>>>> >>>>>>>>> >>>>>>>>> - Jay >>>>>>>>> >>>>>>>>> >>>>>>>>> ________________________________ >>>>>>>>>> From: hosking at cs.purdue.edu >>>>>>>>>> To: jay.krell at cornell.edu >>>>>>>>>> Date: Sun, 16 Aug 2009 15:26:49 -0400 >>>>>>>>>> CC: m3devel at elegosoft.com >>>>>>>>>> Subject: Re: [M3devel] more crashers >>>>>>>>>> >>>>>>>>>> Could this be endianness-related? >>>>>>>>>> >>>>>>>>>> On 16 Aug 2009, at 15:21, Jay K wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I see the assertion failure on PPC_LINUX too. >>>>>>>>>> I tried VAR defaultStackSize := 1024 * 1024; (not sure why >>>>>>>>>> there was any suspicion of stack size). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Debugging doesn't work PPC_LINUX. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> jay at plin:/cm3/bin$ gdb ./cm3 >>>>>>>>>> GNU gdb 6.8-debian >>>>>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>>>> This is free software: you are free to change and redistribute it. >>>>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>>>> "show copying" >>>>>>>>>> and "show warranty" for details. >>>>>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>>>>> break ma(gdb) break main >>>>>>>>>> Breakpoint 1 at 0x86fc4: file _m3main.mc, line 2. >>>>>>>>>> (gdb) r >>>>>>>>>> Starting program: /home/jay/cm3/bin/cm3 >>>>>>>>>> Warning: >>>>>>>>>> Cannot insert breakpoint 1. >>>>>>>>>> Error accessing memory address 0x86fc4: Input/output error. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> No problem with C: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> jay at plin:/cm3/bin$ echo "main(){}"> 1.c >>>>>>>>>> jay at plin:/cm3/bin$ gcc -g 1.c >>>>>>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>>>>>> GNU gdb 6.8-debian >>>>>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>>>> This is free software: you are free to change and redistribute it. >>>>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>>>> "show copying" >>>>>>>>>> and "show warranty" for details. >>>>>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>>>>> (gdb) break main >>>>>>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>>>>>> (gdb) r >>>>>>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>>>>>> Breakpoint 1, main () at 1.c:1 >>>>>>>>>> 1 main(){} >>>>>>>>>> (gdb) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> jay at plin:/cm3/bin$ gcc -gstabs+ 1.c >>>>>>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>>>>>> GNU gdb 6.8-debian >>>>>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>>>> This is free software: you are free to change and redistribute it. >>>>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>>>> "show copying" >>>>>>>>>> and "show warranty" for details. >>>>>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>>>>> (gdb) break main >>>>>>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>>>>>> (gdb) r >>>>>>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>>>>>> Breakpoint 1, main () at 1.c:1 >>>>>>>>>> 1 main(){} >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> jay at plin:/cm3/bin$ gcc -gstabs 1.c >>>>>>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>>>>>> GNU gdb 6.8-debian >>>>>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>>>> This is free software: you are free to change and redistribute it. >>>>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>>>> "show copying" >>>>>>>>>> and "show warranty" for details. >>>>>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>>>>> (gdb) break main >>>>>>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>>>>>> (gdb) r >>>>>>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>>>>>> Breakpoint 1, main () at 1.c:1 >>>>>>>>>> 1 main(){} >>>>>>>>>> (gdb) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> - Jay >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ---------------------------------------- >>>>>>>>>> From: jay.krell at cornell.edu >>>>>>>>>> To: m3devel at elegosoft.com >>>>>>>>>> Subject: more crashers >>>>>>>>>> Date: Sun, 16 Aug 2009 10:06:15 +0000 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> This is head on SOLgnu: >>>>>>>>>> I'll try another and debug and see if fix is easy. >>>>>>>>>> >>>>>>>>>> -bash-3.00$ ./m3browser >>>>>>>>>> >>>>>>>>>> *** >>>>>>>>>> *** runtime error: >>>>>>>>>> *** Segmentation violation - possible attempt to dereference NIL >>>>>>>>>> *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/ String16.m3 >>>>>>>>>> *** >>>>>>>>>> >>>>>>>>>> -bash-3.00$ ./visobliq >>>>>>>>>> Internal Obliq interpreter installed... >>>>>>>>>> Establishing 'templates' >>>>>>>>>> (Created frame 'templates') >>>>>>>>>> let >>>>>>>>>> Templates = >>>>>>>>>> {boolean=> ... , >>>>>>>>>> browser=> ... , >>>>>>>>>> button=> ... , >>>>>>>>>> choice=> ... , >>>>>>>>>> filebrowser=> ... , >>>>>>>>>> form=> ... , >>>>>>>>>> frame=> ... , >>>>>>>>>> hscroll=> ... , >>>>>>>>>> menu=> ... , >>>>>>>>>> numeric=> ... , >>>>>>>>>> text=> ... , >>>>>>>>>> textedit=> ... , >>>>>>>>>> typein=> ... , >>>>>>>>>> video=> ... , >>>>>>>>>> vscroll=> ... } >>>>>>>>>> Establishing 'vowidgets' >>>>>>>>>> (Created frame 'vowidgets') >>>>>>>>>> ok >>>>>>>>>> Establishing 'vocheckpt' >>>>>>>>>> (Created frame 'vocheckpt') >>>>>>>>>> ok >>>>>>>>>> Establishing 'volib' >>>>>>>>>> (Created frame 'volib') >>>>>>>>>> Segmentation Fault (core dumped) >>>>>>>>>> -bash-3.00$ >>>>>>>>>> >>>>>>>>>> >>>> >>>> >>>> >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>> 45 86 95 >>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>> DE163214194 >>>> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Aug 17 17:14:44 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 17 Aug 2009 15:14:44 +0000 Subject: [M3devel] more crashers In-Reply-To: <20090817171329.dsbfoh9s04k0o84w@mail.elegosoft.com> References: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> <20090817133026.6v9cm3cu0wwkc08k@mail.elegosoft.com> <20090817171329.dsbfoh9s04k0o84w@mail.elegosoft.com> Message-ID: For 5.9 we should look into the libunwind/libgcc stuff. - Jay ---------------------------------------- > Date: Mon, 17 Aug 2009 17:13:29 +0200 > From: wagner at elegosoft.com > To: hosking at cs.purdue.edu > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > Subject: Re: [M3devel] more crashers > > Quoting Tony Hosking : > >> Indeed, we might be better off investing effort in getting rid of try- >> blocks implemented using setjmp/longjmp so as to avoid the stack- >> allocated jmpbuf state. Or perhaps allocate that state in the heap. > > Is this a feature for 5.9 then? ;-) > > Olaf > >> On 17 Aug 2009, at 09:18, Jay K wrote: >> >>> >>> Not as much luck as I'd like. >>> >>> >>> PTHREAD_STACK_MIN >>> Solaris: 4K >>> Linux/sparc: 24K >>> Linux/x86: 16K >>> Linux/powerpc: 128K >>> >>> >>> The overflowing stack, with 16K: >>> >>> >>> current thread: t at 12 >>> =>[1] Rd__CharsReady(0xfd61a00c, 0xfd617410, 0xfd59fb6c, 0x0, >>> 0xfd59fb84, 0xfd59 >>> fb8c), at 0xfec58578 >>> ---- 1 following frame from gwindows -- possible stack overflow >>> [2] SynScan__LookChar(0xfd883670, 0xfd8aa81c, 0xfd59fb6c, 0x0, >>> 0xfd59fb84, 0xf >>> d59fb8c), at 0xfead71fc >>> [3] SynScan__NextToken(0xfd883670, 0xfd8ab980, 0x9, 0x0, >>> 0xfd59fb84, 0xfd59fb8 >>> c), at 0xfead91c4 >>> [4] SynScan__LookToken(0xfd883670, 0x4ae, 0x9, 0x0, 0xfd59fb84, >>> 0xfd59fb8c), a >>> t 0xfead9628 >>> [5] SynScan__HaveTokenName(0xfd883670, 0xfd5f7768, 0x8, 0x0, >>> 0xfd59fb84, 0xfd5 >>> 9fb8c), at 0xfeadd084 >>> [6] SynParse__Read0(0xfd883654, 0xfd6174ac, 0xfd59fb6c, 0x0, >>> 0xfd59fb84, 0xfd5 >>> 9fb8c), at 0xfeae4760 >>> [7] SynParse__Read0(0xfd883654, 0xfd617460, 0xfd59fb6c, 0x0, >>> 0xfd59fb84, 0xfd5 >>> 9fb8c), at 0xfeae5e8c >>> >>> >>> hundreds of frames of Lots of SynParse__Read0, using about 1K per >>> frame; there is a try in there. >>> >>> d59fb8c), at 0xfeae348c >>> [666] SynParse__Read0(0xfd883654, 0xfd6172d8, 0xfd59fb6c, 0x0, >>> 0xfd59fb84, 0xf >>> d59fb8c), at 0xfeae5e8c >>> [667] SynParse__Read0(0xfd883654, 0xfd8aaa6c, 0xfd59fb6c, 0x0, >>> 0xfd59fb84, 0xf >>> d59fb8c), at 0xfeae3dd4 >>> [668] SynParse__Read0(0xfd883654, 0xfd617288, 0xfd59fb6c, 0x0, >>> 0xfd59fb84, 0xf >>> d59fb8c), at 0xfeae3168 >>> [669] SynParse__Read0(0xfd883654, 0xfd8aacec, 0xfd59fb6c, 0x0, >>> 0xfd59fb84, 0xf >>> d59fb8c), at 0xfeae6230 >>> [670] SynParse__Read1(0xfd883654, 0xfd8aacec, 0x0, 0xfd59fb84, >>> 0xfd59fb8c, 0x0 >>> ), at 0xfeae2674 >>> [671] SynParse__Read(0xfd883654, 0xfd8aacec, 0x0, 0xfd803a00, 0x0, >>> 0xfebee308) >>> , at 0xfeadfb60 >>> [672] SynParse__ReadNonTerminal(0xfd883654, 0xfefed45c, 0xfd61b250, >>> 0xfd61b8cc >>> , 0xfd61b280, 0xfd89a27c), at 0xfeadfae8 >>> [673] ObliqParser__ParsePhrase(0xfd883654, 0x0, 0xfd61b250, >>> 0xfd61b8cc, 0xfd61 >>> b280, 0x0), at 0xfefd5ff0 >>> [674] ObliqOnline__Interact(0xfd89a848, 0xc32a0, 0xfd61a00c, 0x1, >>> 0x1, 0xfebee >>> 308), at 0xff36b80c >>> [675] ObliqRuntime__ForkedDo(0xfd3ddfb8, 0x9658aac0, 0xff000000, >>> 0x0, 0xfd9100 >>> 90, 0x0), at 0x80db0 >>> [676] ThreadPThread__RunThread(0xef2b0, 0x0, 0x0, 0x0, 0xfd803a00, >>> 0x1), at 0x >>> fe06bc88 >>> [677] ThreadPThread__ThreadBase(0xef2b0, 0xfd5a0000, 0x0, 0x0, >>> 0xfe06b7c8, 0x1 >>> ), at 0xfe06b818 >>> >>> >>> One of the problems with defining a unit of stack size is the large >>> variety of jmpbuf size. >>> But heck, why 1K per frame here when SOLsun has a stack walker? Hm. >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: wagner at elegosoft.com; m3devel at elegosoft.com >>>> Subject: RE: [M3devel] more crashers >>>> Date: Mon, 17 Aug 2009 11:35:40 +0000 >>>> >>>> >>>> - I think the whole machine stack mechanism is pretty hopelessly broken. >>>> Not just in Modula-3. Therefore my enthusiasm to attempt to "fix" >>>> it -- which is impossible -- isn't very high. >>>> >>>> - I'm hoping to find that no platform other than Solaris lets you >>>> even use such a small stack. I have to experiment some in a bit. >>>> Depending on that experiment, we'll be in a better position, without >>>> any further changes, but again, depending on what I find. >>>> That is, if every other platform already had a larger stack, then this >>>> just brings Solaris inline with the rest. If the other platforms >>>> were actually successfully using a 4K stack, then indeed a problem. >>>> >>>> >>>> - It could also be a factor of optimization. >>>> Maybe ensuring -O2 or -O3 is used more would cover it up?? >>>> >>>> >>>> - Or some other changes. >>>> That is, if we have drastically increased stack usage, we should try >>>> to reduce it back down. But given that 4K was the previous value >>>> and even 16K doesn't work...I'm not hopeful we could fit it back >>>> down in 4K. >>>> >>>> It is easy enough to see the bug and then look at the various frames >>>> and see if they use a lot of stack and can be reduced. >>>> >>>> - Jay >>>> >>>> >>>> >>>> ---------------------------------------- >>>>> Date: Mon, 17 Aug 2009 13:30:26 +0200 >>>>> From: wagner at elegosoft.com >>>>> To: m3devel at elegosoft.com >>>>> Subject: Re: [M3devel] more crashers >>>>> >>>>> Quoting Jay K : >>>>> >>>>>> visobliq was stack overflow. >>>>>> Raising the default from 4K to 16K didn't fix, but 32K did. >>>>> >>>>> We need to address this somehow. It cannot be correct if the user >>>>> needs to increase the default stack size on one platform by 8 >>>>> and not at all on another. Do we have any concept of a 'standard >>>>> stack size unit' ;-)? Something that can be easily understood and >>>>> implemented and be used instead of the machine words in the current >>>>> interfaces? Any ideas? >>>>> >>>>> Olaf >>>>> >>>>> >>>>>> - Jay >>>>>> >>>>>> ---------------------------------------- >>>>>>> From: jay.krell at cornell.edu >>>>>>> To: hosking at cs.purdue.edu >>>>>>> CC: m3devel at elegosoft.com >>>>>>> Subject: RE: [M3devel] more crashers >>>>>>> Date: Sun, 16 Aug 2009 20:32:31 +0000 >>>>>>> >>>>>>> >>>>>>> m3browser: >>>>>>> >>>>>>> It is specific to my config file >>>>>>> m3-sys/cminstall/src/config-no-install/cm3.cfg that reachs back >>>>>>> into the source tree. It won't happen with what most people do. I >>>>>>> have to do that M3Predefines or such work so that all the uses of >>>>>>> m3quake besides cm3 are much more like cm3. >>>>>>> >>>>>>> >>>>>>> visobliq: >>>>>>> not the same thing >>>>>>> Does not occur on Linux/x86 or Linux/sparc. >>>>>>> They do print >>>>>>> Syntax error just before: -helvetica-bold-\*R-\*240-\*\") (LabelFo ... >>>>>>> ill-formed character escape sequence >>>>>>> Error detected (file file generated by Visual Obliq) (line 18, char 10) >>>>>>> VideoVBT.Start Jv ServerFailure:errno=0 >>>>>>> >>>>>>> but then gui comes up. >>>>>>> I'll have to finish my Solaris reinstall and get dbx. >>>>>>> >>>>>>> >>>>>>> - Jay >>>>>>> >>>>>>> >>>>>>> ---------------------------------------- >>>>>>>> From: jay.krell at cornell.edu >>>>>>>> To: hosking at cs.purdue.edu >>>>>>>> Date: Sun, 16 Aug 2009 20:22:49 +0000 >>>>>>>> CC: m3devel at elegosoft.com >>>>>>>> Subject: Re: [M3devel] more crashers >>>>>>>> >>>>>>>> >>>>>>>> sorry, this is simple. >>>>>>>> >>>>>>>> derived_dirs := IntList.List1 (ID.Add (MxConfig.Get("BUILD_DIR"))); >>>>>>>> >>>>>>>> >>>>>>>> - Jay >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ---------------------------------------- >>>>>>>>> From: jay.krell at cornell.edu >>>>>>>>> To: hosking at cs.purdue.edu >>>>>>>>> Date: Sun, 16 Aug 2009 19:52:03 +0000 >>>>>>>>> CC: m3devel at elegosoft.com >>>>>>>>> Subject: Re: [M3devel] more crashers >>>>>>>>> >>>>>>>>> >>>>>>>>> Here is the relevant code in m3browser ID.m3: >>>>>>>>> >>>>>>>>> >>>>>>>>> C:\dev2\cm3.2\m3-tools\m3markup\src\ID.m3(38): empty_id := Add (""); >>>>>>>>> >>>>>>>>> empty_id := Add (""); >>>>>>>>> >>>>>>>>> (*-------------------------------------------------------------- >>>>>>>>> exported ---*) >>>>>>>>> PROCEDURE Add (x: TEXT): T = >>>>>>>>> VAR >>>>>>>>> t: T; >>>>>>>>> a: REF ARRAY OF CHAR; >>>>>>>>> l: INTEGER; >>>>>>>>> BEGIN >>>>>>>>> l := Text.Length(x); >>>>>>>>> ... >>>>>>>>> END Add; >>>>>>>>> >>>>>>>>> >>>>>>>>> The empty string constant ends up as null. >>>>>>>>> >>>>>>>>> .stabn 68,0,38,.LM115-.LFBB10 >>>>>>>>> .LM115: >>>>>>>>> movl L_1 at GOT(%ebx), %eax >>>>>>>>> leal 24(%eax), %eax >>>>>>>>> movl %eax, (%esp) >>>>>>>>> call ID__Add at PLT >>>>>>>>> movl %eax, -8(%ebp) >>>>>>>>> movl -8(%ebp), %ecx >>>>>>>>> movl MM_ID at GOT(%ebx), %edx >>>>>>>>> movl 248(%edx), %eax >>>>>>>>> andl $0, %eax >>>>>>>>> orl %ecx, %eax >>>>>>>>> movl %eax, 248(%edx) >>>>>>>>> .L136: >>>>>>>>> movl MM_ID at GOT(%ebx), %eax >>>>>>>>> .LBE16: >>>>>>>>> addl $52, %esp >>>>>>>>> popl %ebx >>>>>>>>> popl %ebp >>>>>>>>> ret >>>>>>>>> >>>>>>>>> L_1: >>>>>>>>> 0 .long RTHooks__TextLitInfo >>>>>>>>> 4 .long RTHooks__TextLitGetChar >>>>>>>>> 8 .long RTHooks__TextLitGetWideChar >>>>>>>>> 12 .long RTHooks__TextLitGetChars >>>>>>>>> 16 .long RTHooks__TextLitGetWideChars >>>>>>>>> 20 .long 2 >>>>>>>>> 24 .long L_1 >>>>>>>>> .long 0 >>>>>>>>> .zero 4 >>>>>>>>> .ascii "ID_M3" >>>>>>>>> .zero 1 >>>>>>>>> .ascii "ExpandHashTable" >>>>>>>>> .zero 1 >>>>>>>>> .ascii "ExpandIDs" >>>>>>>>> .zero 1 >>>>>>>>> .ascii "ExpandChars" >>>>>>>>> .zero 1 >>>>>>>>> .ascii "Compare" >>>>>>>>> .zero 1 >>>>>>>>> >>>>>>>>> If I change "" to "foo", I get: >>>>>>>>> >>>>>>>>> L_1: >>>>>>>>> 0 .long RTHooks__TextLitInfo >>>>>>>>> 4 .long RTHooks__TextLitGetChar >>>>>>>>> 8 .long RTHooks__TextLitGetWideChar >>>>>>>>> 12 .long RTHooks__TextLitGetChars >>>>>>>>> 16 .long RTHooks__TextLitGetWideChars >>>>>>>>> 20 .long 2 >>>>>>>>> 24 .long L_1 >>>>>>>>> .long 3 >>>>>>>>> .ascii "foo" >>>>>>>>> .zero 1 >>>>>>>>> .ascii "ID_M3" >>>>>>>>> >>>>>>>>> and it still crashes. >>>>>>>>> >>>>>>>>> >>>>>>>>> It seems to hit ID__Add twice when only once would be expected. >>>>>>>>> >>>>>>>>> >>>>>>>>> - Jay >>>>>>>>> >>>>>>>>> >>>>>>>>> ---------------------------------------- >>>>>>>>>> From: jay.krell at cornell.edu >>>>>>>>>> To: hosking at cs.purdue.edu >>>>>>>>>> Date: Sun, 16 Aug 2009 19:33:34 +0000 >>>>>>>>>> CC: m3devel at elegosoft.com >>>>>>>>>> Subject: Re: [M3devel] more crashers >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Could be. I've also seen it on PPC_DARWIN a while ago. I only >>>>>>>>>> recall seeing it on sparc and ppc. >>>>>>>>>> It doesn't always occur. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Here is the m3browser crash on a system that can be debugged. >>>>>>>>>> See why I want the full paths in the debug info? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> C:\Users\jay\Desktop>\cygwin\bin\ssh xobsd. >>>>>>>>>> $ cd /cm3 >>>>>>>>>> $ cd bin >>>>>>>>>> $ export DISPLAY=192.168.1.120:0.0 >>>>>>>>>> $ gdb ./m3browser >>>>>>>>>> GNU gdb 6.3 >>>>>>>>>> This GDB was configured as "i386-unknown-openbsd4.5"... >>>>>>>>>> (gdb) r >>>>>>>>>> Starting program: /home/jay/cm3/bin/m3browser >>>>>>>>>> Program received signal SIGSEGV, Segmentation fault. >>>>>>>>>> [Switching to process 31063, thread 0x7eafe800] >>>>>>>>>> 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/ >>>>>>>>>> Text.m3:16 >>>>>>>>>> 16 t.get_info (i); >>>>>>>>>> (gdb) bt >>>>>>>>>> #0 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/ >>>>>>>>>> text/Text.m3:16 >>>>>>>>>> #1 0x09fd9464 in ID__Add (M3_Bd56fi_x=0x0) at ../src/ID.m3:48 >>>>>>>>>> #2 0x1c01e644 in Main_M3 (M3_AcxOUs_mode=1) at ../src/ Main.m3:37 >>>>>>>>>> #3 0x0156f1bc in RTLinker__RunMainBody (M3_DjPxE3_m=0x3c003ec0) >>>>>>>>>> at ../src/runtime/common/RTLinker.m3:399 >>>>>>>>>> #4 0x0156e576 in RTLinker__AddUnitI (M3_DjPxE3_m=0x3c003ec0) >>>>>>>>>> at ../src/runtime/common/RTLinker.m3:113 >>>>>>>>>> #5 0x0156e604 in RTLinker__AddUnit (M3_DjPxE5_b=0x1c01e54d) >>>>>>>>>> at ../src/runtime/common/RTLinker.m3:122 >>>>>>>>>> #6 0x1c004676 in main (argc=1, argv=0xcfbf6a3c, envp=0xcfbf6a44) >>>>>>>>>> at _m3main.mc:4 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> - Jay >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ________________________________ >>>>>>>>>>> From: hosking at cs.purdue.edu >>>>>>>>>>> To: jay.krell at cornell.edu >>>>>>>>>>> Date: Sun, 16 Aug 2009 15:26:49 -0400 >>>>>>>>>>> CC: m3devel at elegosoft.com >>>>>>>>>>> Subject: Re: [M3devel] more crashers >>>>>>>>>>> >>>>>>>>>>> Could this be endianness-related? >>>>>>>>>>> >>>>>>>>>>> On 16 Aug 2009, at 15:21, Jay K wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I see the assertion failure on PPC_LINUX too. >>>>>>>>>>> I tried VAR defaultStackSize := 1024 * 1024; (not sure why >>>>>>>>>>> there was any suspicion of stack size). >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Debugging doesn't work PPC_LINUX. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> jay at plin:/cm3/bin$ gdb ./cm3 >>>>>>>>>>> GNU gdb 6.8-debian >>>>>>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>>>>> This is free software: you are free to change and redistribute it. >>>>>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>>>>> "show copying" >>>>>>>>>>> and "show warranty" for details. >>>>>>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>>>>>> break ma(gdb) break main >>>>>>>>>>> Breakpoint 1 at 0x86fc4: file _m3main.mc, line 2. >>>>>>>>>>> (gdb) r >>>>>>>>>>> Starting program: /home/jay/cm3/bin/cm3 >>>>>>>>>>> Warning: >>>>>>>>>>> Cannot insert breakpoint 1. >>>>>>>>>>> Error accessing memory address 0x86fc4: Input/output error. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> No problem with C: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> jay at plin:/cm3/bin$ echo "main(){}"> 1.c >>>>>>>>>>> jay at plin:/cm3/bin$ gcc -g 1.c >>>>>>>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>>>>>>> GNU gdb 6.8-debian >>>>>>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>>>>> This is free software: you are free to change and redistribute it. >>>>>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>>>>> "show copying" >>>>>>>>>>> and "show warranty" for details. >>>>>>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>>>>>> (gdb) break main >>>>>>>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>>>>>>> (gdb) r >>>>>>>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>>>>>>> Breakpoint 1, main () at 1.c:1 >>>>>>>>>>> 1 main(){} >>>>>>>>>>> (gdb) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> jay at plin:/cm3/bin$ gcc -gstabs+ 1.c >>>>>>>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>>>>>>> GNU gdb 6.8-debian >>>>>>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>>>>> This is free software: you are free to change and redistribute it. >>>>>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>>>>> "show copying" >>>>>>>>>>> and "show warranty" for details. >>>>>>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>>>>>> (gdb) break main >>>>>>>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>>>>>>> (gdb) r >>>>>>>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>>>>>>> Breakpoint 1, main () at 1.c:1 >>>>>>>>>>> 1 main(){} >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> jay at plin:/cm3/bin$ gcc -gstabs 1.c >>>>>>>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>>>>>>> GNU gdb 6.8-debian >>>>>>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>>>>> This is free software: you are free to change and redistribute it. >>>>>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>>>>> "show copying" >>>>>>>>>>> and "show warranty" for details. >>>>>>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>>>>>> (gdb) break main >>>>>>>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>>>>>>> (gdb) r >>>>>>>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>>>>>>> Breakpoint 1, main () at 1.c:1 >>>>>>>>>>> 1 main(){} >>>>>>>>>>> (gdb) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> - Jay >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ---------------------------------------- >>>>>>>>>>> From: jay.krell at cornell.edu >>>>>>>>>>> To: m3devel at elegosoft.com >>>>>>>>>>> Subject: more crashers >>>>>>>>>>> Date: Sun, 16 Aug 2009 10:06:15 +0000 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> This is head on SOLgnu: >>>>>>>>>>> I'll try another and debug and see if fix is easy. >>>>>>>>>>> >>>>>>>>>>> -bash-3.00$ ./m3browser >>>>>>>>>>> >>>>>>>>>>> *** >>>>>>>>>>> *** runtime error: >>>>>>>>>>> *** Segmentation violation - possible attempt to dereference NIL >>>>>>>>>>> *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/ String16.m3 >>>>>>>>>>> *** >>>>>>>>>>> >>>>>>>>>>> -bash-3.00$ ./visobliq >>>>>>>>>>> Internal Obliq interpreter installed... >>>>>>>>>>> Establishing 'templates' >>>>>>>>>>> (Created frame 'templates') >>>>>>>>>>> let >>>>>>>>>>> Templates = >>>>>>>>>>> {boolean=> ... , >>>>>>>>>>> browser=> ... , >>>>>>>>>>> button=> ... , >>>>>>>>>>> choice=> ... , >>>>>>>>>>> filebrowser=> ... , >>>>>>>>>>> form=> ... , >>>>>>>>>>> frame=> ... , >>>>>>>>>>> hscroll=> ... , >>>>>>>>>>> menu=> ... , >>>>>>>>>>> numeric=> ... , >>>>>>>>>>> text=> ... , >>>>>>>>>>> textedit=> ... , >>>>>>>>>>> typein=> ... , >>>>>>>>>>> video=> ... , >>>>>>>>>>> vscroll=> ... } >>>>>>>>>>> Establishing 'vowidgets' >>>>>>>>>>> (Created frame 'vowidgets') >>>>>>>>>>> ok >>>>>>>>>>> Establishing 'vocheckpt' >>>>>>>>>>> (Created frame 'vocheckpt') >>>>>>>>>>> ok >>>>>>>>>>> Establishing 'volib' >>>>>>>>>>> (Created frame 'volib') >>>>>>>>>>> Segmentation Fault (core dumped) >>>>>>>>>>> -bash-3.00$ >>>>>>>>>>> >>>>>>>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>>> 45 86 95 >>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>> DE163214194 >>>>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From dragisha at m3w.org Mon Aug 17 16:59:23 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 17 Aug 2009 16:59:23 +0200 Subject: [M3devel] more crashers In-Reply-To: References: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> <20090817133026.6v9cm3cu0wwkc08k@mail.elegosoft.com> Message-ID: <1250521163.11420.12.camel@faramir.m3w.org> Isn't that setjmp/longjmp bussiness direct intruction set dependant? Some pushall or something like that? On Mon, 2009-08-17 at 10:47 -0400, Tony Hosking wrote: > Indeed, we might be better off investing effort in getting rid of > try-blocks implemented using setjmp/longjmp so as to avoid the > stack-allocated jmpbuf state. Or perhaps allocate that state in the > heap. -- Dragi?a Duri? From jay.krell at cornell.edu Tue Aug 18 03:23:00 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 18 Aug 2009 01:23:00 +0000 Subject: [M3devel] more crashers In-Reply-To: <1250521163.11420.12.camel@faramir.m3w.org> References: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> <20090817133026.6v9cm3cu0wwkc08k@mail.elegosoft.com> <1250521163.11420.12.camel@faramir.m3w.org> Message-ID: Yes, something like that. I was likely mistaken -- no try/except/finally here. Still need to look into a bit more, make sure the resulting stack is now very small as I removed all the locals and put them in nested functions -- the function is a big switch and most arms of the switch have their own locals, and some are recursive, every recursion paid for every arm's locals, I assume. 900+ bytes of locals, in a recursive function! That recurses hundreds of times! Blech. The front-end IMHO should "stack pack" "parallel scopes" as a matter of course, not just depend on the optimizer. That wouldn't reduce it as much as my transform though. My transform can sometimes increase stack usage, but not typically. Also of course my transform slows it down in multiple ways, more function calls, slower access to parameters. But preserving stack is important imho. Interesting little area.. - Jay > From: dragisha at m3w.org > To: hosking at cs.purdue.edu > Date: Mon, 17 Aug 2009 16:59:23 +0200 > CC: m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3devel] more crashers > > Isn't that setjmp/longjmp bussiness direct intruction set dependant? > Some pushall or something like that? > > On Mon, 2009-08-17 at 10:47 -0400, Tony Hosking wrote: > > Indeed, we might be better off investing effort in getting rid of > > try-blocks implemented using setjmp/longjmp so as to avoid the > > stack-allocated jmpbuf state. Or perhaps allocate that state in the > > heap. > -- > Dragi?a Duri? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.m.bates at cox.net Tue Aug 18 03:57:54 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Mon, 17 Aug 2009 20:57:54 -0500 Subject: [M3devel] Some big-endian info needed Message-ID: <4A8A0AA2.7080008@cox.net> I need a favor. I need some info from the following program, compiled on a 32-bit big endian and a 64-bit big-endian machine. Would someone who has such machines with working cm3 installed please send it to me? In particular, I need it compiled with -O0 -gstabs+, then the output of: objdump -dG BitNos.mo Alternatively, if you don't have a working objdump, compiling with cm3 -keep and sending me BitNos.ms would probably give me what I need. Thanks. Rodney Bates ------------------------------------------------------------- MODULE BitNos EXPORTS Main ; TYPE Packed = RECORD F0 : BITS 2 FOR [ 0 .. 3 ] := 3 ; F1 : BITS 3 FOR [ 0 .. 7 ] := 7 ; F2 : BITS 10 FOR [ 0 .. 1023 ] := 9 ; F3 : BITS 17 FOR [ 0 .. 131071 ] := 11 ; F4 : BITS 4 FOR [ 0 .. 15 ] := 15 ; F5 : BITS 5 FOR [ 0 .. 31 ] := 17 ; F6 : BITS 12 FOR [ 0 .. 4095] := 19 ; F7 : BITS 11 FOR [ 0 .. 2047 ] := 21 ; F8 : BITS 8 FOR [ 0 .. 255 ] := 23 END ; PROCEDURE P ( ) = VAR Local : Packed ; BEGIN EVAL Local . F3 END P ; PROCEDURE Q ( ) = BEGIN END Q ; BEGIN P ( ) ; Q ( ) END BitNos . --------------------------------------------------------------------- From rodney.m.bates at cox.net Tue Aug 18 04:01:20 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Mon, 17 Aug 2009 21:01:20 -0500 Subject: [M3devel] CM3 web presentation In-Reply-To: <20090815135945.GA24494@topoi.pooq.com> References: <20090815120142.cb14l4zj4k844004@mail.elegosoft.com> <20090815135945.GA24494@topoi.pooq.com> Message-ID: <4A8A0B70.9010601@cox.net> hendrik at topoi.pooq.com wrote: > On Sat, Aug 15, 2009 at 12:14:53PM +0000, Jay K wrote: > >> Please just use white on black or black on white. >> > > Colour or no colour, prefer light on dark. It's much easier for > migraine sufferers. > Interesting. I had severe migraines for years and greatly preferred dark letters on light background. But it's now moot, as the headaches have almost entirely gone in my old age. > -- hendrik > > From jay.krell at cornell.edu Tue Aug 18 04:24:49 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 18 Aug 2009 02:24:49 +0000 Subject: [M3devel] Some big-endian info needed In-Reply-To: <4A8A0AA2.7080008@cox.net> References: <4A8A0AA2.7080008@cox.net> Message-ID: You don't need the target machine to get the .ms file. You can cross build. # build some cross compilers cd $CM3_ROOT/m3-sys/m3cc cm3 -DM3CC_TARGET=PPC_LINUX cm3 -DM3CC_TARGET=SOLgnu cm3 -DM3CC_TARGET=PPC_DARWIN cm3 -DM3CC_TARGET=PA32_HPUX cm3 -DM3CC_TARGET=PA64_HPUX cm3 -DM3CC_TARGET=SPARC64_OPENBSD cm3 -DM3CC_TARGET=MIPS64_OPENBSD cm3 -DM3CC_TARGET=SPARC64_SOLARIS # use cm3.cfg that honors CM3_TARGET environment variable cp m3-sys/cminstall/src/config-no-install/* /cm3/bin cd to where your code is CM3_TARGET=PPC_LINUX cm3 -boot CM3_TARGET=PPC_DARWIN cm3 -boot CM3_TARGET=MIPS64_OPENBSD cm3 -boot CM3_TARGET=SPARC64_OPENBSD cm3 -boot CM3_TARGET=SPARC64_SOLARIS cm3 -boot CM3_TARGET=PA32_HPUX cm3 -boot CM3_TARGET=PA64_HPUX cm3 -boot I don't think we have any actually working big endian 64bit targets, but the ones above almost work. - Jay > Date: Mon, 17 Aug 2009 20:57:54 -0500 > From: rodney.m.bates at cox.net > To: m3devel at elegosoft.com > Subject: [M3devel] Some big-endian info needed > > I need a favor. I need some info from the following program, > compiled on a 32-bit big endian and a 64-bit big-endian machine. > Would someone who has such machines with working cm3 installed > please send it to me? > > In particular, I need it compiled with -O0 -gstabs+, then the > output of: > > objdump -dG BitNos.mo > > Alternatively, if you don't have a working objdump, compiling > with cm3 -keep and sending me BitNos.ms would probably give me > what I need. > > Thanks. > > Rodney Bates > > ------------------------------------------------------------- > > MODULE BitNos EXPORTS Main > > ; TYPE Packed = RECORD > F0 : BITS 2 FOR [ 0 .. 3 ] := 3 > ; F1 : BITS 3 FOR [ 0 .. 7 ] := 7 > ; F2 : BITS 10 FOR [ 0 .. 1023 ] := 9 > ; F3 : BITS 17 FOR [ 0 .. 131071 ] := 11 > ; F4 : BITS 4 FOR [ 0 .. 15 ] := 15 > ; F5 : BITS 5 FOR [ 0 .. 31 ] := 17 > ; F6 : BITS 12 FOR [ 0 .. 4095] := 19 > ; F7 : BITS 11 FOR [ 0 .. 2047 ] := 21 > ; F8 : BITS 8 FOR [ 0 .. 255 ] := 23 > END > > ; PROCEDURE P ( ) > > = VAR Local : Packed > > ; BEGIN > EVAL Local . F3 > END P > > ; PROCEDURE Q ( ) > > = BEGIN > END Q > > ; BEGIN > P ( ) > ; Q ( ) > END BitNos -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Aug 18 15:34:08 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 18 Aug 2009 13:34:08 +0000 Subject: [M3devel] missing error checks in makedist? Message-ID: http://www.modula3.com:8080/view/I386_OPENBSD/job/cm3-makedist-I386_OPENBSD/1/console === package m3-db/odbc === +++ cm3 -build -DROOT='/home/hudson/workspace/cm3-makedist-I386_OPENBSD/cm3' -DCM3_VERSION_TEXT='d5.8.2' -DCM3_VERSION_NUMBER='050802' -DCM3_LAST_CHANGED='2009-07-15' $RARGS && cm3 -ship $RARGS -DROOT='/home/hudson/workspace/cm3-makedist-I386_OPENBSD/cm3' -DCM3_VERSION_TEXT='d5.8.2' -DCM3_VERSION_NUMBER='050802' -DCM3_LAST_CHANGED='2009-07-15' +++ /usr/bin/ld: cannot find -lodbc collect2: ld returned 1 exit status make_lib => 1 librarian failed building: m3odbc From hendrik at topoi.pooq.com Tue Aug 18 16:17:09 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 18 Aug 2009 10:17:09 -0400 Subject: [M3devel] CM3 web presentation In-Reply-To: <4A8A0B70.9010601@cox.net> References: <20090815120142.cb14l4zj4k844004@mail.elegosoft.com> <20090815135945.GA24494@topoi.pooq.com> <4A8A0B70.9010601@cox.net> Message-ID: <20090818141709.GB31203@topoi.pooq.com> On Mon, Aug 17, 2009 at 09:01:20PM -0500, Rodney M. Bates wrote: > hendrik at topoi.pooq.com wrote: > >On Sat, Aug 15, 2009 at 12:14:53PM +0000, Jay K wrote: > > > >>Please just use white on black or black on white. > >> > > > >Colour or no colour, prefer light on dark. It's much easier for > >migraine sufferers. > > > > Interesting. I had severe migraines for years and greatly > preferred dark letters on light background. But it's now > moot, as the headaches have almost entirely gone in my > old age. Evidently all the evidence isn't in yet. It seems to be the amount of subliminal or perceived flicker that aggaravates a migraine. Having a *really* good monitor will likely make a difference. Did the migraines make you fotofugic? -- hendrik From wagner at elegosoft.com Tue Aug 18 16:46:40 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 18 Aug 2009 16:46:40 +0200 Subject: [M3devel] missing error checks in makedist? In-Reply-To: References: Message-ID: <20090818164640.7qet0p9uogsgwks4@mail.elegosoft.com> Quoting Jay K : > > http://www.modula3.com:8080/view/I386_OPENBSD/job/cm3-makedist-I386_OPENBSD/1/console > === package m3-db/odbc === > +++ cm3 -build > -DROOT='/home/hudson/workspace/cm3-makedist-I386_OPENBSD/cm3' > -DCM3_VERSION_TEXT='d5.8.2' -DCM3_VERSION_NUMBER='050802' > -DCM3_LAST_CHANGED='2009-07-15' $RARGS && cm3 -ship $RARGS > -DROOT='/home/hudson/workspace/cm3-makedist-I386_OPENBSD/cm3' > -DCM3_VERSION_TEXT='d5.8.2' -DCM3_VERSION_NUMBER='050802' > -DCM3_LAST_CHANGED='2009-07-15' +++ > /usr/bin/ld: cannot find -lodbc > collect2: ld returned 1 exit status > make_lib => 1 > librarian failed building: m3odbc I reopened ticket 1047. It would help if such failures were immediately fed into trac to be tracked ;-) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Aug 18 17:25:56 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 18 Aug 2009 17:25:56 +0200 Subject: [M3devel] m3gdb build errors Message-ID: <20090818172556.ktlh757rc4gg440o@mail.elegosoft.com> Why does building m3gdb now even fail on FreeBSD for some time? http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-FreeBSD4/107/testReport/ Olaf From wagner at elegosoft.com Wed Aug 19 00:22:53 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 19 Aug 2009 00:22:53 +0200 Subject: [M3devel] m3gdb build errors In-Reply-To: <20090818172556.ktlh757rc4gg440o@mail.elegosoft.com> References: <20090818172556.ktlh757rc4gg440o@mail.elegosoft.com> Message-ID: <20090819002253.esfhmrovogc44gcg@mail.elegosoft.com> Quoting Olaf Wagner : > Why does building m3gdb now even fail on FreeBSD for some time? > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-FreeBSD4/107/testReport/ Something surprising every day: checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... configure: error: ls -t appears to fail. Make sure there is not a broken alias in your environment configure: error: newly created file is older than distributed files! Check your system clock gmake[1]: *** [configure-bfd] Error 1 gmake[1]: Leaving directory `/ad0e/home/hudson/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb/FreeBSD4' gmake: *** [all] Error 2 "/ad0e/home/hudson/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb/src/m3makefile", line 84: quake runtime error: exit 2: gmake CFLAGS="-g" MAKEINFO=echo --procedure-- -line- -file--- exec -- m3gdb_Run 84 /ad0e/home/hudson/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb/src/m3makefile include_dir 123 /ad0e/home/hudson/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb/src/m3makefile 4 /ad0e/home/hudson/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb/FreeBSD4/m3make.args Fatal Error: package build failed ls is aliased to `ls -F' luthien [~/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb] hudson % ls -t "-F" is not a file or directory. "-t" is not a file or directory. luthien [~/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb] hudson % unalias ls luthien [~/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb] hudson % ls -t "-t" is not a file or directory. luthien [~/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb] hudson % ls . ----------- CVS directory gdb directory src directory .cvsignore file (length =516) DESC file (length =56) PkgTags file (length =76) FreeBSD4 directory luthien [~/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb] hudson % type ls ls is hashed (/ad0e/home/hudson/work/cm3-inst/luthien/last-ok/bin/ls) Since when do we provide our own ls? Oh, I see, it's probably one of the examples that should never have been shipped... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Wed Aug 19 00:32:50 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 19 Aug 2009 00:32:50 +0200 Subject: [M3devel] m3gdb build errors In-Reply-To: <20090819002253.esfhmrovogc44gcg@mail.elegosoft.com> References: <20090818172556.ktlh757rc4gg440o@mail.elegosoft.com> <20090819002253.esfhmrovogc44gcg@mail.elegosoft.com> Message-ID: <20090819003250.go8ismls04kogg44@mail.elegosoft.com> Hm, my mails seem to get truncated too, now. Quoting Olaf Wagner : > Quoting Olaf Wagner : > "-t" is not a file or directory. > luthien [~/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb] hudson > % ls Why has this ls been shipped to bin though? The makefile says ./m3-sys/cm3ide/src/examples/files/src/m3makefile:program ("ls") Has anybody changed the shipping semantics? If yes, it is an incompatible change which should be reverted. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Aug 19 01:27:03 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Tue, 18 Aug 2009 16:27:03 -0700 Subject: [M3devel] m3gdb build errors In-Reply-To: <20090819003250.go8ismls04kogg44@mail.elegosoft.com> References: <20090818172556.ktlh757rc4gg440o@mail.elegosoft.com> <20090819002253.esfhmrovogc44gcg@mail.elegosoft.com> <20090819003250.go8ismls04kogg44@mail.elegosoft.com> Message-ID: <4CA7696C-C79F-4E9F-BC0D-5F68566679BC@hotmail.com> I agree that would be wrong. The no-resolution changes? (case sensitivity is too subtle I think but I've known about it) - Jay (phone) On Aug 18, 2009, at 3:32 PM, Olaf Wagner wrote: > Hm, my mails seem to get truncated too, now. > > Quoting Olaf Wagner : > >> Quoting Olaf Wagner : >> "-t" is not a file or directory. >> luthien [~/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb] >> hudson >> % ls > > Why has this ls been shipped to bin though? The makefile says > > ./m3-sys/cm3ide/src/examples/files/src/m3makefile:program ("ls") > > Has anybody changed the shipping semantics? If yes, it is an > incompatible change which should be reverted. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ > any > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be > rlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > From jay.krell at cornell.edu Wed Aug 19 05:46:36 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 19 Aug 2009 03:46:36 +0000 Subject: [M3devel] m3gdb build errors In-Reply-To: <20090819003250.go8ismls04kogg44@mail.elegosoft.com> References: <20090818172556.ktlh757rc4gg440o@mail.elegosoft.com> <20090819002253.esfhmrovogc44gcg@mail.elegosoft.com> <20090819003250.go8ismls04kogg44@mail.elegosoft.com> Message-ID: > Hm, my mails seem to get truncated too, now. I think this is a matter of playing the odds. The more mail you send, the more frequently you send, the longer the mails, the more likely they are to be truncated. - Jay ---------------------------------------- > Date: Wed, 19 Aug 2009 00:32:50 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] m3gdb build errors > > Hm, my mails seem to get truncated too, now. > > Quoting Olaf Wagner : > >> Quoting Olaf Wagner : >> "-t" is not a file or directory. >> luthien [~/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb] hudson >> % ls > > Why has this ls been shipped to bin though? The makefile says > > ./m3-sys/cm3ide/src/examples/files/src/m3makefile:program ("ls") > > Has anybody changed the shipping semantics? If yes, it is an > incompatible change which should be reverted. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From wagner at elegosoft.com Wed Aug 19 08:47:12 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 19 Aug 2009 08:47:12 +0200 Subject: [M3devel] Wrong shipping needs investigation, was: Re: m3gdb build errors In-Reply-To: <4CA7696C-C79F-4E9F-BC0D-5F68566679BC@hotmail.com> References: <20090818172556.ktlh757rc4gg440o@mail.elegosoft.com> <20090819002253.esfhmrovogc44gcg@mail.elegosoft.com> <20090819003250.go8ismls04kogg44@mail.elegosoft.com> <4CA7696C-C79F-4E9F-BC0D-5F68566679BC@hotmail.com> Message-ID: <20090819084712.deqwnkyk0s488go8@mail.elegosoft.com> Quoting jay.krell at cornell.edu: > I agree that would be wrong. The no-resolution changes? (case > sensitivity is too subtle I think but I've known about it) I thought so, too. but it is at least not obvious. The implementation of program and Program looks innocent enough, and the diffs to 2009-07-15 don't bring up anything related. At least in m3-sys/cm3. Perhaps it's a side-effect of another package? But how could this be? Can anybody investigate this further? If we don't fix it soon, RC3 won't be ready at the weekend, as building packages for all platforms takes rather long. We also need to add some tests for the correct contents of shipping files to m3-sys/m3tests. Any volunteers there? Olaf PS: I'm off to work now and not home again until tomorrow evening. Connectivity will be infrequent and slow. PPS: I've opened ticket #1060 for this. > - Jay (phone) >> Quoting Olaf Wagner : >> >>> Quoting Olaf Wagner : >>> "-t" is not a file or directory. >>> luthien [~/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb] hudson >>> % ls >> >> Why has this ls been shipped to bin though? The makefile says >> >> ./m3-sys/cm3ide/src/examples/files/src/m3makefile:program ("ls") >> >> Has anybody changed the shipping semantics? If yes, it is an >> incompatible change which should be reverted. -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Wed Aug 19 21:22:47 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 19 Aug 2009 21:22:47 +0200 Subject: [M3devel] m3gdb build errors In-Reply-To: <20090819003250.go8ismls04kogg44@mail.elegosoft.com> References: <20090818172556.ktlh757rc4gg440o@mail.elegosoft.com> <20090819002253.esfhmrovogc44gcg@mail.elegosoft.com> <20090819003250.go8ismls04kogg44@mail.elegosoft.com> Message-ID: <20090819212247.xlgbut6jtcccs0sw@mail.elegosoft.com> Quoting Olaf Wagner : > Hm, my mails seem to get truncated too, now. > > Quoting Olaf Wagner : > >> Quoting Olaf Wagner : >> "-t" is not a file or directory. >> luthien [~/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb] hudson >> % ls > > Why has this ls been shipped to bin though? The makefile says > > ./m3-sys/cm3ide/src/examples/files/src/m3makefile:program ("ls") > > Has anybody changed the shipping semantics? If yes, it is an > incompatible change which should be reverted. This is a strange day. I don't seem to be able to reproduce this any more. If I hadn't saved the .M3SHIP file in the ticket I'd say I was still dreaming this morning. Has anybody fixed it already? Ah, browsing the changelog I find this: 2009-08-19 13:06 jkrell * m3-sys/cminstall/src/config-no-install/: NT386.common, cm3cfg.common: manual merge from release_branch_cm3_5_8 to head: let cm3 decide where to ship stuff -- not everything goes to BinInstall So it was only in the config files? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Aug 19 21:56:10 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 19 Aug 2009 19:56:10 +0000 Subject: [M3devel] m3gdb build errors In-Reply-To: <20090819212247.xlgbut6jtcccs0sw@mail.elegosoft.com> References: <20090818172556.ktlh757rc4gg440o@mail.elegosoft.com> <20090819002253.esfhmrovogc44gcg@mail.elegosoft.com> <20090819003250.go8ismls04kogg44@mail.elegosoft.com> <20090819212247.xlgbut6jtcccs0sw@mail.elegosoft.com> Message-ID: Yes it was in the config files. Only if skip_ was called -- you have to run cm3 twice or such. - Jay ---------------------------------------- > Date: Wed, 19 Aug 2009 21:22:47 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] m3gdb build errors > > Quoting Olaf Wagner : > >> Hm, my mails seem to get truncated too, now. >> >> Quoting Olaf Wagner : >> >>> Quoting Olaf Wagner : >>> "-t" is not a file or directory. >>> luthien [~/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb] hudson >>> % ls >> >> Why has this ls been shipped to bin though? The makefile says >> >> ./m3-sys/cm3ide/src/examples/files/src/m3makefile:program ("ls") >> >> Has anybody changed the shipping semantics? If yes, it is an >> incompatible change which should be reverted. > > This is a strange day. I don't seem to be able to reproduce this > any more. If I hadn't saved the .M3SHIP file in the ticket I'd > say I was still dreaming this morning. > > Has anybody fixed it already? > > Ah, browsing the changelog I find this: > > 2009-08-19 13:06 jkrell > > * m3-sys/cminstall/src/config-no-install/: NT386.common, cm3cfg.common: > > manual merge from release_branch_cm3_5_8 to head: let cm3 decide > where to ship stuff -- not everything goes to BinInstall > > So it was only in the config files? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Wed Aug 19 22:44:26 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 19 Aug 2009 20:44:26 +0000 Subject: [M3devel] m3gdb build errors In-Reply-To: <20090819212247.xlgbut6jtcccs0sw@mail.elegosoft.com> References: <20090818172556.ktlh757rc4gg440o@mail.elegosoft.com> <20090819002253.esfhmrovogc44gcg@mail.elegosoft.com> <20090819003250.go8ismls04kogg44@mail.elegosoft.com> <20090819212247.xlgbut6jtcccs0sw@mail.elegosoft.com> Message-ID: ps: There's a related small NT specific problem where the symbols -- the .pdb file -- always gets shipped to the bin directory, whereas the intent was to ship next to the binary. I believe the fix is to move the code, very few lines, into cm3. The catch I couldn't solve right away is that the file isn't always present, even on NT, depending on config file details, so it's probably best done "only if exists", ignoring the corner case where it existed in an earlier run, config file changed, doesn't exist in later run -- though that can be dealt with too by deleting the destination if the source doesn't exist. I don't think we have a CopyIfExists primitive though. I can add one. The name should probaby be different to reflect...you know..like... CopyIfExistsElseDeleteDestination?? - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Subject: RE: [M3devel] m3gdb build errors > Date: Wed, 19 Aug 2009 19:56:10 +0000 > > > Yes it was in the config files. > Only if skip_ was called -- you have to run cm3 twice or such. > > - Jay > > > ---------------------------------------- >> Date: Wed, 19 Aug 2009 21:22:47 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] m3gdb build errors >> >> Quoting Olaf Wagner : >> >>> Hm, my mails seem to get truncated too, now. >>> >>> Quoting Olaf Wagner : >>> >>>> Quoting Olaf Wagner : >>>> "-t" is not a file or directory. >>>> luthien [~/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb] hudson >>>> % ls >>> >>> Why has this ls been shipped to bin though? The makefile says >>> >>> ./m3-sys/cm3ide/src/examples/files/src/m3makefile:program ("ls") >>> >>> Has anybody changed the shipping semantics? If yes, it is an >>> incompatible change which should be reverted. >> >> This is a strange day. I don't seem to be able to reproduce this >> any more. If I hadn't saved the .M3SHIP file in the ticket I'd >> say I was still dreaming this morning. >> >> Has anybody fixed it already? >> >> Ah, browsing the changelog I find this: >> >> 2009-08-19 13:06 jkrell >> >> * m3-sys/cminstall/src/config-no-install/: NT386.common, cm3cfg.common: >> >> manual merge from release_branch_cm3_5_8 to head: let cm3 decide >> where to ship stuff -- not everything goes to BinInstall >> >> So it was only in the config files? >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> From wagner at elegosoft.com Thu Aug 20 08:58:07 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 20 Aug 2009 08:58:07 +0200 Subject: [M3devel] m3gdb build errors In-Reply-To: References: <20090818172556.ktlh757rc4gg440o@mail.elegosoft.com> <20090819002253.esfhmrovogc44gcg@mail.elegosoft.com> <20090819003250.go8ismls04kogg44@mail.elegosoft.com> <20090819212247.xlgbut6jtcccs0sw@mail.elegosoft.com> Message-ID: <20090820085807.qxd84gjkcg40g4cg@mail.elegosoft.com> Quoting Jay K : > ps: There's a related small NT specific problem where the symbols -- > the .pdb file -- always gets shipped to the bin directory, whereas > the intent was to ship next to the binary. I believe the fix is to > move the code, very few lines, into cm3. The catch I couldn't solve > right away is that the file isn't always present, even on NT, > depending on config file details, so it's probably best done "only > if exists", ignoring the corner case where it existed in an earlier > run, config file changed, doesn't exist in later run -- though that > can be dealt with too by deleting the destination if the source > doesn't exist. I don't think we have a CopyIfExists primitive > though. I can add one. The name should probaby be different to > reflect...you know..like... CopyIfExistsElseDeleteDestination?? Can you please add a reference to the fix to the ticket, and the above information, too? If we need a complex installation function, we can add it, but perhaps somebody can suggest a better name? Olaf > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com; m3devel at elegosoft.com >> Subject: RE: [M3devel] m3gdb build errors >> Date: Wed, 19 Aug 2009 19:56:10 +0000 >> >> >> Yes it was in the config files. >> Only if skip_ was called -- you have to run cm3 twice or such. >> >> - Jay >> >> ---------------------------------------- >>> Date: Wed, 19 Aug 2009 21:22:47 +0200 >>> From: wagner at elegosoft.com >>> To: m3devel at elegosoft.com >>> Subject: Re: [M3devel] m3gdb build errors >>> >>> Quoting Olaf Wagner : >>> >>>> Hm, my mails seem to get truncated too, now. >>>> >>>> Quoting Olaf Wagner : >>>> >>>>> Quoting Olaf Wagner : >>>>> "-t" is not a file or directory. >>>>> luthien [~/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb] hudson >>>>> % ls >>>> >>>> Why has this ls been shipped to bin though? The makefile says >>>> >>>> ./m3-sys/cm3ide/src/examples/files/src/m3makefile:program ("ls") >>>> >>>> Has anybody changed the shipping semantics? If yes, it is an >>>> incompatible change which should be reverted. >>> >>> This is a strange day. I don't seem to be able to reproduce this >>> any more. If I hadn't saved the .M3SHIP file in the ticket I'd >>> say I was still dreaming this morning. >>> >>> Has anybody fixed it already? >>> >>> Ah, browsing the changelog I find this: >>> >>> 2009-08-19 13:06 jkrell >>> >>> * m3-sys/cminstall/src/config-no-install/: NT386.common, cm3cfg.common: >>> >>> manual merge from release_branch_cm3_5_8 to head: let cm3 decide >>> where to ship stuff -- not everything goes to BinInstall >>> >>> So it was only in the config files? -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Thu Aug 20 09:03:54 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 20 Aug 2009 09:03:54 +0200 Subject: [M3devel] Trac/CVS/Hudson integration Message-ID: <20090820090354.pki6jxajokgsgwo0@mail.elegosoft.com> If you commit a fix for a change related to a ticket in trac, you should add the ticket number in the form # to the commit message. Then Hudson (and other tools) will be able to cross-reference tickets and version changes. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Aug 20 11:45:21 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 20 Aug 2009 09:45:21 +0000 Subject: [M3devel] formedit crash Message-ID: Just a note that I have 5.4.0 running on Solaris. I've run its formsedit many times, never a crash. It crashes at least 10% of the time in the current tree. I tried copying all the "nearby" code, that merely turned my assertion back into SIGSEGV. Indeed the nearby diffs are not significant. - Jay From jay.krell at cornell.edu Thu Aug 20 11:55:07 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 20 Aug 2009 09:55:07 +0000 Subject: [M3devel] @M3paranoidgc always crashes Message-ID: Verified on SOLgnu and AMD64_LINUX. Probably related to initialization order changes that let user threads work again. Probably should just use untraced? % gdb --args ./cm3 @M3paranoidgc GNU gdb 6.4.90-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run Starting program: /home/jkrell/cm3/bin/cm3 @M3paranoidgc [Thread debugging using libthread_db enabled] [New Thread 47899659458256 (LWP 29607)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 47899659458256 (LWP 29607)] 0x00000000006934c5 in RTAllocator__GetTracedObj (M3_Eic7CK_def=Cannot access mem ory at address 0x800028d97718 ) at ../src/runtime/common/RTAllocator.m3:221 221 INC(thread.inCritical); (gdb) bt #0 0x00000000006934c5 in RTAllocator__GetTracedObj (M3_Eic7CK_def=Cannot access memory at address 0x800028d97718 ) at ../src/runtime/common/RTAllocator.m3:221 #1 0x0000000000692e1f in RTHooks__AllocateTracedObj (M3_AJWxb1_defn=Cannot acce ss memory at address 0x800028d97788 ) at ../src/runtime/common/RTAllocator.m3:120 #2 0x000000000069b3ae in RTCollector__InstallSanityCheck () at ../src/runtime/common/RTCollector.m3:1637 #3 0x00000000006a1747 in RTHeapRep__Init () at ../src/runtime/common/RTCollector.m3:2769 #4 0x00000000006a2a1d in RTLinker__InitRuntime (M3_AcxOUs_p_argc=Cannot access memory at address 0x800028d97858 ) at ../src/runtime/common/RTLinker.m3:58 #5 0x00000000004160bc in main (argc=Cannot access memory at address 0x800028d97 8a8 ) at _m3main.mc:3 (gdb) From hosking at cs.purdue.edu Thu Aug 20 16:03:19 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 20 Aug 2009 10:03:19 -0400 Subject: [M3devel] @M3paranoidgc always crashes In-Reply-To: References: Message-ID: Indeed, the use of paranoidgc itself now seems to be broken (independently of any other bug you might be trying to track down by invoking paranoidgc). This is a serious bug, that should be rectified *before* any release. Without it, we cannot easily diagnose GC bugs in the field. I have little to no time to devote to this right now, but it does look like the recent changes to threading initialisation has broken things. I remember being very careful about initialization of threads and heap components of the run-time when working on the original native threads. In particular, the ability to invoke ThreadF.GetActivation was allowed before ThreadF.Init had been called, because ThreadF.InitActivations was able to be invoked on-demand independently of ThreadF.Init. This independence now seems to have been eliminated so as to eliminate a run-time check in GetActivation. On 20 Aug 2009, at 05:55, Jay K wrote: > > Verified on SOLgnu and AMD64_LINUX. > Probably related to initialization order changes that let user > threads work again. > Probably should just use untraced? > > > > % gdb --args ./cm3 @M3paranoidgc > GNU gdb 6.4.90-debian > Copyright (C) 2006 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and > you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "x86_64-linux-gnu"...Using host > libthread_db library > "/lib/libthread_db.so.1". > (gdb) run > Starting program: /home/jkrell/cm3/bin/cm3 @M3paranoidgc > [Thread debugging using libthread_db enabled] > [New Thread 47899659458256 (LWP 29607)] > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 47899659458256 (LWP 29607)] > 0x00000000006934c5 in RTAllocator__GetTracedObj > (M3_Eic7CK_def=Cannot access mem > ory at address 0x800028d97718 > ) > at ../src/runtime/common/RTAllocator.m3:221 > 221 INC(thread.inCritical); > (gdb) bt > #0 0x00000000006934c5 in RTAllocator__GetTracedObj > (M3_Eic7CK_def=Cannot access > memory at address 0x800028d97718 > ) > at ../src/runtime/common/RTAllocator.m3:221 > #1 0x0000000000692e1f in RTHooks__AllocateTracedObj > (M3_AJWxb1_defn=Cannot acce > ss memory at address 0x800028d97788 > ) > at ../src/runtime/common/RTAllocator.m3:120 > #2 0x000000000069b3ae in RTCollector__InstallSanityCheck () > at ../src/runtime/common/RTCollector.m3:1637 > #3 0x00000000006a1747 in RTHeapRep__Init () > at ../src/runtime/common/RTCollector.m3:2769 > #4 0x00000000006a2a1d in RTLinker__InitRuntime > (M3_AcxOUs_p_argc=Cannot access > memory at address 0x800028d97858 > ) > at ../src/runtime/common/RTLinker.m3:58 > #5 0x00000000004160bc in main (argc=Cannot access memory at address > 0x800028d97 > 8a8 > ) at _m3main.mc:3 > (gdb) > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Thu Aug 20 16:37:31 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 20 Aug 2009 16:37:31 +0200 Subject: [M3devel] SYSTEM_LIBS, quake, ./configure Message-ID: <1250779051.3002.6.camel@faramir.m3w.org> In this ticket, https://projects.elego.de/cm3/ticket/1048, cvsup problem with libz on some systems is described. But, that problem is bigger than this - whole C portability issue. We need quake standardized way for locating (or not allocating:) system libraries. That way, it'll be possible to have Modula-3 programs and libraries which depend on C libraries like.... expat, tidy, mysqlclient, sqlite... distributed as wide as cm3 is. This is solvable with some quake magic? -- Dragi?a Duri? From wagner at elegosoft.com Thu Aug 20 17:07:37 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 20 Aug 2009 17:07:37 +0200 Subject: [M3devel] SYSTEM_LIBS, quake, ./configure In-Reply-To: <1250779051.3002.6.camel@faramir.m3w.org> References: <1250779051.3002.6.camel@faramir.m3w.org> Message-ID: <20090820170737.xlylo4e268oo480o@mail.elegosoft.com> Quoting Dragi?a Duri? : > In this ticket, https://projects.elego.de/cm3/ticket/1048, cvsup problem > with libz on some systems is described. But, that problem is bigger than > this - whole C portability issue. > > We need quake standardized way for locating (or not allocating:) system > libraries. That way, it'll be possible to have Modula-3 programs and > libraries which depend on C libraries like.... expat, tidy, mysqlclient, > sqlite... distributed as wide as cm3 is. > > This is solvable with some quake magic? This kind of configure-function was part of the old CM3 installer, but has become unused now, because Jay insists that it is unnecessary. I don't think this should be a quake function executed at compile time. Interfaces to a well-known set of system libraries are contained in the config files. A quake definition of such a function would necessarily be system- dependent, as it would need to know about all standard locations to search on a certain platform. Or search all known locations, but then the problem of resolving multiple hits comes up... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Thu Aug 20 17:10:58 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 20 Aug 2009 17:10:58 +0200 Subject: [M3devel] @M3paranoidgc always crashes In-Reply-To: References: Message-ID: <20090820171058.0stkh5eu68cw0ksk@mail.elegosoft.com> Quoting Tony Hosking : > Indeed, the use of paranoidgc itself now seems to be broken > (independently of any other bug you might be trying to track down by > invoking paranoidgc). > This is a serious bug, that should be rectified *before* any release. > Without it, we cannot easily diagnose GC bugs in the field. I have > little to no time to devote to this right now, but it does look like > the recent changes to threading initialisation has broken things. I > remember being very careful about initialization of threads and heap > components of the run-time when working on the original native > threads. In particular, the ability to invoke ThreadF.GetActivation > was allowed before ThreadF.Init had been called, because > ThreadF.InitActivations was able to be invoked on-demand independently > of ThreadF.Init. This independence now seems to have been eliminated > so as to eliminate a run-time check in GetActivation. Jay, could you open a ticket for that, too? And we also need to add tests for running with various @M3 options... Olaf > > On 20 Aug 2009, at 05:55, Jay K wrote: > >> >> Verified on SOLgnu and AMD64_LINUX. >> Probably related to initialization order changes that let user >> threads work again. >> Probably should just use untraced? >> >> >> >> % gdb --args ./cm3 @M3paranoidgc >> GNU gdb 6.4.90-debian >> Copyright (C) 2006 Free Software Foundation, Inc. >> GDB is free software, covered by the GNU General Public License, >> and you are >> welcome to change it and/or distribute copies of it under certain >> conditions. >> Type "show copying" to see the conditions. >> There is absolutely no warranty for GDB. Type "show warranty" for details. >> This GDB was configured as "x86_64-linux-gnu"...Using host >> libthread_db library >> "/lib/libthread_db.so.1". >> (gdb) run >> Starting program: /home/jkrell/cm3/bin/cm3 @M3paranoidgc >> [Thread debugging using libthread_db enabled] >> [New Thread 47899659458256 (LWP 29607)] >> Program received signal SIGSEGV, Segmentation fault. >> [Switching to Thread 47899659458256 (LWP 29607)] >> 0x00000000006934c5 in RTAllocator__GetTracedObj >> (M3_Eic7CK_def=Cannot access mem >> ory at address 0x800028d97718 >> ) >> at ../src/runtime/common/RTAllocator.m3:221 >> 221 INC(thread.inCritical); >> (gdb) bt >> #0 0x00000000006934c5 in RTAllocator__GetTracedObj >> (M3_Eic7CK_def=Cannot access >> memory at address 0x800028d97718 >> ) >> at ../src/runtime/common/RTAllocator.m3:221 >> #1 0x0000000000692e1f in RTHooks__AllocateTracedObj >> (M3_AJWxb1_defn=Cannot acce >> ss memory at address 0x800028d97788 >> ) >> at ../src/runtime/common/RTAllocator.m3:120 >> #2 0x000000000069b3ae in RTCollector__InstallSanityCheck () >> at ../src/runtime/common/RTCollector.m3:1637 >> #3 0x00000000006a1747 in RTHeapRep__Init () >> at ../src/runtime/common/RTCollector.m3:2769 >> #4 0x00000000006a2a1d in RTLinker__InitRuntime >> (M3_AcxOUs_p_argc=Cannot access >> memory at address 0x800028d97858 >> ) >> at ../src/runtime/common/RTLinker.m3:58 >> #5 0x00000000004160bc in main (argc=Cannot access memory at >> address 0x800028d97 >> 8a8 >> ) at _m3main.mc:3 >> (gdb) >> >> >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Thu Aug 20 17:26:52 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 20 Aug 2009 11:26:52 -0400 Subject: [M3devel] @M3paranoidgc always crashes In-Reply-To: <20090820171058.0stkh5eu68cw0ksk@mail.elegosoft.com> References: <20090820171058.0stkh5eu68cw0ksk@mail.elegosoft.com> Message-ID: <007DD8EA-4A1C-447A-B8FB-56396A8F6560@cs.purdue.edu> Jay may have fixed this for now. On 20 Aug 2009, at 11:10, Olaf Wagner wrote: > Quoting Tony Hosking : > >> Indeed, the use of paranoidgc itself now seems to be broken >> (independently of any other bug you might be trying to track down by >> invoking paranoidgc). >> This is a serious bug, that should be rectified *before* any release. >> Without it, we cannot easily diagnose GC bugs in the field. I have >> little to no time to devote to this right now, but it does look like >> the recent changes to threading initialisation has broken things. I >> remember being very careful about initialization of threads and heap >> components of the run-time when working on the original native >> threads. In particular, the ability to invoke ThreadF.GetActivation >> was allowed before ThreadF.Init had been called, because >> ThreadF.InitActivations was able to be invoked on-demand >> independently >> of ThreadF.Init. This independence now seems to have been eliminated >> so as to eliminate a run-time check in GetActivation. > > Jay, could you open a ticket for that, too? > > And we also need to add tests for running with various @M3 options... > > Olaf > >> >> On 20 Aug 2009, at 05:55, Jay K wrote: >> >>> >>> Verified on SOLgnu and AMD64_LINUX. >>> Probably related to initialization order changes that let user >>> threads work again. >>> Probably should just use untraced? >>> >>> >>> >>> % gdb --args ./cm3 @M3paranoidgc >>> GNU gdb 6.4.90-debian >>> Copyright (C) 2006 Free Software Foundation, Inc. >>> GDB is free software, covered by the GNU General Public License, >>> and you are >>> welcome to change it and/or distribute copies of it under >>> certain conditions. >>> Type "show copying" to see the conditions. >>> There is absolutely no warranty for GDB. Type "show warranty" >>> for details. >>> This GDB was configured as "x86_64-linux-gnu"...Using host >>> libthread_db library >>> "/lib/libthread_db.so.1". >>> (gdb) run >>> Starting program: /home/jkrell/cm3/bin/cm3 @M3paranoidgc >>> [Thread debugging using libthread_db enabled] >>> [New Thread 47899659458256 (LWP 29607)] >>> Program received signal SIGSEGV, Segmentation fault. >>> [Switching to Thread 47899659458256 (LWP 29607)] >>> 0x00000000006934c5 in RTAllocator__GetTracedObj >>> (M3_Eic7CK_def=Cannot access mem >>> ory at address 0x800028d97718 >>> ) >>> at ../src/runtime/common/RTAllocator.m3:221 >>> 221 INC(thread.inCritical); >>> (gdb) bt >>> #0 0x00000000006934c5 in RTAllocator__GetTracedObj >>> (M3_Eic7CK_def=Cannot access >>> memory at address 0x800028d97718 >>> ) >>> at ../src/runtime/common/RTAllocator.m3:221 >>> #1 0x0000000000692e1f in RTHooks__AllocateTracedObj >>> (M3_AJWxb1_defn=Cannot acce >>> ss memory at address 0x800028d97788 >>> ) >>> at ../src/runtime/common/RTAllocator.m3:120 >>> #2 0x000000000069b3ae in RTCollector__InstallSanityCheck () >>> at ../src/runtime/common/RTCollector.m3:1637 >>> #3 0x00000000006a1747 in RTHeapRep__Init () >>> at ../src/runtime/common/RTCollector.m3:2769 >>> #4 0x00000000006a2a1d in RTLinker__InitRuntime >>> (M3_AcxOUs_p_argc=Cannot access >>> memory at address 0x800028d97858 >>> ) >>> at ../src/runtime/common/RTLinker.m3:58 >>> #5 0x00000000004160bc in main (argc=Cannot access memory at >>> address 0x800028d97 >>> 8a8 >>> ) at _m3main.mc:3 >>> (gdb) >>> >>> >>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lchretien at mac.com Thu Aug 20 20:57:36 2009 From: lchretien at mac.com (Louis =?ISO-8859-1?B?Q2hy6XRpZW4=?=) Date: Thu, 20 Aug 2009 14:57:36 -0400 Subject: [M3devel] A question about the M3 licensing... Message-ID: I remember reading on this list (or was it the website...) that the way the licensing of Modula-3 is written, it would make it incompatible/impossible to merge this project with the GCC front-end from the GCC foundation, the way that GNU Ada was incorporated into that project. Because M3 uses a modified GCC code generator, it would have a made sense to go that way. But another, intriguing possibility exists: the LLVM project (http://www.llvm.org). It looks like a very high-performance, optimizing, multiple target infrastructure, that would make Modula-3 highly portable. I'm sure i'm not the first to think of this, but what are the obstacle to porting M3 to that environment (apart from the obvious effort in programming required... ;-))) -- Louis Chr?tien lchretien at mac.com From mbishop at esoteriq.org Thu Aug 20 22:30:06 2009 From: mbishop at esoteriq.org (Martin Bishop) Date: Thu, 20 Aug 2009 15:30:06 -0500 Subject: [M3devel] A question about the M3 licensing... In-Reply-To: References: Message-ID: <4A8DB24E.7010807@esoteriq.org> I definitely wondered about getting CM3 to use LLVM as well. I have none of the skills required to make it happen, but just wondered about doing so. LLVM is the "hot thing" now (deservedly so) and it would be nice if Modula-3 could get a little bit of life in it by association. Louis Chr?tien wrote: > I remember reading on this list (or was it the website...) that the way the > licensing of Modula-3 is written, it would make it incompatible/impossible > to merge this project with the GCC front-end from the GCC foundation, the > way that GNU Ada was incorporated into that project. > > Because M3 uses a modified GCC code generator, it would have a made sense to > go that way. > > But another, intriguing possibility exists: the LLVM project > (http://www.llvm.org). It looks like a very high-performance, optimizing, > multiple target infrastructure, that would make Modula-3 highly portable. > > I'm sure i'm not the first to think of this, but what are the obstacle to > porting M3 to that environment (apart from the obvious effort in programming > required... ;-))) > > -- > Louis Chr?tien > lchretien at mac.com > > > > From hosking at cs.purdue.edu Thu Aug 20 23:50:16 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 20 Aug 2009 17:50:16 -0400 Subject: [M3devel] A question about the M3 licensing... In-Reply-To: References: Message-ID: <1F753DA1-D9A2-46C5-B490-8F4D08A4392F@cs.purdue.edu> Yes, I have thought that this would be a great idea for some time now. Similarly for .NET. The only obstacle of course is time... :-) On 20 Aug 2009, at 14:57, Louis Chr?tien wrote: > I remember reading on this list (or was it the website...) that the > way the > licensing of Modula-3 is written, it would make it incompatible/ > impossible > to merge this project with the GCC front-end from the GCC > foundation, the > way that GNU Ada was incorporated into that project. > > Because M3 uses a modified GCC code generator, it would have a made > sense to > go that way. > > But another, intriguing possibility exists: the LLVM project > (http://www.llvm.org). It looks like a very high-performance, > optimizing, > multiple target infrastructure, that would make Modula-3 highly > portable. > > I'm sure i'm not the first to think of this, but what are the > obstacle to > porting M3 to that environment (apart from the obvious effort in > programming > required... ;-))) > > -- > Louis Chr?tien > lchretien at mac.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.m.bates at cox.net Thu Aug 20 22:37:21 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Thu, 20 Aug 2009 15:37:21 -0500 Subject: [M3devel] How to update tickets myself Message-ID: <4A8DB401.2020209@cox.net> I just checked in fixed to ticket #1058. How can I access the ticket system and update it myself? Sorry, I forgot the # before the ticket number in the commit message. Rodney Bates From hendrik at topoi.pooq.com Fri Aug 21 01:48:26 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 20 Aug 2009 19:48:26 -0400 Subject: [M3devel] A question about the M3 licensing... In-Reply-To: References: Message-ID: <20090820234825.GB3925@topoi.pooq.com> On Thu, Aug 20, 2009 at 02:57:36PM -0400, Louis Chr?tien wrote: > I remember reading on this list (or was it the website...) that the way the > licensing of Modula-3 is written, it would make it incompatible/impossible > to merge this project with the GCC front-end from the GCC foundation, the > way that GNU Ada was incorporated into that project. > > Because M3 uses a modified GCC code generator, it would have a made sense to > go that way. > > But another, intriguing possibility exists: the LLVM project > (http://www.llvm.org). It looks like a very high-performance, optimizing, > multiple target infrastructure, that would make Modula-3 highly portable. I looked into LLVM for another language, with the idea of using its in-memory interface and constructing the parse tree directly. It turns out that it does type calculation during parse tree construction. THe result is that any type I want to use has to be completely defined before I can use it anywhere in the parse tree I'm trying to build. For compiler-synthesized records whose fields are invented while generating the intermediate code that uses them, this turned out to be an unacceptable ordering constraint. There are ways around this by storing the entire intermediate code in RAM as a kind of insertable-text data structure, and then writing it all to a disk file, and then having the LLVM back end read that file .... but it got messy. > > I'm sure i'm not the first to think of this, but what are the obstacle to > porting M3 to that environment (apart from the obvious effort in programming > required... ;-))) I suppose there's another possibility -- writing a new M3 front end with a different licence, and being free of SRC forever. Except that if some of our libraries are compiled from SRC source code, will we have to compile at installation tiem to avould distributing mixed GNU/SRC binaries? -- hendrik From hendrik at topoi.pooq.com Fri Aug 21 02:04:29 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 20 Aug 2009 20:04:29 -0400 Subject: [M3devel] Using LLVM (WAS; A question about the M3 licensing...) In-Reply-To: <20090820234825.GB3925@topoi.pooq.com> References: <20090820234825.GB3925@topoi.pooq.com> Message-ID: <20090821000429.GC3925@topoi.pooq.com> On Thu, Aug 20, 2009 at 07:48:26PM -0400, hendrik at topoi.pooq.com wrote: > > I looked into LLVM for another language, with the idea of using its > in-memory interface and constructing the parse tree directly. It turns > out that it does type calculation during parse tree construction. THe > result is that any type I want to use has to be completely defined > before I can use it anywhere in the parse tree I'm trying to build. For > compiler-synthesized records whose fields are invented while generating > the intermediate code that uses them, this turned out to be an > unacceptable ordering constraint. > > There are ways around this by storing the entire intermediate code in > RAM as a kind of insertable-text data structure, and then writing it all > to a disk file, and then having the LLVM back end read that file .... > but it got messy. By the way, I ended up using C-- for the project, which looks like a better-designed langauge, but with less of an organisation backing it for when things go wrong. I ended uo using the insertable-text data structure to generate the C-- code, too. But at least C-- was designed to have the text file be the primary form of inout; LLVM was designed to have parse trees built in RAM by the front end. -- hendrik. From jay.krell at cornell.edu Fri Aug 21 10:03:11 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 21 Aug 2009 08:03:11 +0000 Subject: [M3devel] SYSTEM_LIBS, quake, ./configure In-Reply-To: <20090820170737.xlylo4e268oo480o@mail.elegosoft.com> References: <1250779051.3002.6.camel@faramir.m3w.org> <20090820170737.xlylo4e268oo480o@mail.elegosoft.com> Message-ID: I know I'm guilty, and I'm a little on the fence. I think /maybe/ we should have m3-sys/cminstall/src/config-no-install/Solaris.libraries m3-sys/cminstall/src/config-no-install/Linux.libraries m3-sys/cminstall/src/config-no-install/NetBSD.libraries m3-sys/cminstall/src/config-no-install/OpenBSD.libraries m3-sys/cminstall/src/config-no-install/FreeBSD.libraries m3-sys/cminstall/src/config-no-install/IRIX.libraries m3-sys/cminstall/src/config-no-install/HPUX.libraries etc. and in packages we'd copy one of these to /usr/local/cm3/bin/config/cm3cfg.libraries so that we'd maintain the "codify the 'standard' locations" while also easing custom editing. More generally there's probably install/cm3/bin/config/libraries/*.quake. X11.quake c.quake ODBC.quake z.quake possibly install/cm3/bin/config/libraries/TARGET/*.quake. possibly probe between them. Each one or two lines. m3makefile dependent on ODBC would read: UseLibrary("X11") and/or UseLibraries(["X11", "ODBC"]) proc UseLibraries(a) is foreach b in a local c = CONFIG_ROOT & "/" & a & ".quake" if exists(c) include(c) else print("WARNING: not building package " & package_name & " because library " & a " is missing)" inform_cm3_to_skip_current_directory() end end proc UseLibrary(a) is UseLibraries([a]) end cm3 and scripts would have switches like: -error-for-missing-libraries -error-for-missing-library:X11 -ignore-missing-libraries -ignore-missing-libraries:X11,ODBC -ignore-missing-library:X11 and where I have print above, well, more like: inform_cm3_of_missing_library(a) but for that matter, move all the logic to cm3 probably. Probably should be using Modula-3 more and Quake less. But it's just so adequate and reasonably pleasant.. As well, need to consider what the "two level" aspect of the current design allows for and how to preserve that. I think it is "how to link library FOO" and "what global order to link libraries in". What I find ambiguous is code that checks for presence in SYSTEM_LIBORDER or SYSTEM_LIBRARIES. Seems to me like, probably, their members should always be the same? (The keys in one should be the members in the other and vice versa). ?? There are like three main scenarios I think. - It is a "package" available on the system, and therefore in a known platform specific location on the vast majority of systems. e.g. /usr on Debian, /usr/pkg on NetBSD, /usr/local on FreeBSD, /usr/sfw or /opt on Solaris. - It may or may not be an available package and user builds it from source and it goes to the library owner's default, usually /usr/local - Sometimes this is the same as the first. - User builds it from source and it goes to the system owner's preference. I have really only catered to the first. And since I emphasize folding common code, the other two have suffered. There is also the possibility of knowing about "pkgconfig". Which only solves the problem for packages that use it. Similarly I'm on the fence regarding autoconf and/or its approach. Autoconf seems quite messy and slow, but doing similar sorts of things in Quake hasn't seemed so bad. - Jay > Date: Thu, 20 Aug 2009 17:07:37 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] SYSTEM_LIBS, quake, ./configure > > Quoting Dragi?a Duri? : > > > In this ticket, https://projects.elego.de/cm3/ticket/1048, cvsup problem > > with libz on some systems is described. But, that problem is bigger than > > this - whole C portability issue. > > > > We need quake standardized way for locating (or not allocating:) system > > libraries. That way, it'll be possible to have Modula-3 programs and > > libraries which depend on C libraries like.... expat, tidy, mysqlclient, > > sqlite... distributed as wide as cm3 is. > > > > This is solvable with some quake magic? > > This kind of configure-function was part of the old CM3 installer, > but has become unused now, because Jay insists that it is unnecessary. > I don't think this should be a quake function executed at compile time. > Interfaces to a well-known set of system libraries are contained in > the config files. > > A quake definition of such a function would necessarily be system- > dependent, as it would need to know about all standard locations to > search on a certain platform. Or search all known locations, but then > the problem of resolving multiple hits comes up... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Aug 21 10:06:14 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 21 Aug 2009 10:06:14 +0200 Subject: [M3devel] How to update tickets myself In-Reply-To: <4A8DB401.2020209@cox.net> References: <4A8DB401.2020209@cox.net> Message-ID: <20090821100614.1hrjhbdou80ggowg@mail.elegosoft.com> Quoting "Rodney M. Bates" : > I just checked in fixed to ticket #1058. How can I > access the ticket system and update it myself? You need to login to trac to view further menu options, but you don't have an account yet as far as I can see. I'll create one for you this evening. Unfortunately the HTTP administration is broken in our trac setup (will be fixed and upgraded when our sysadmin stuff is complete again). > Sorry, I forgot the # > before the ticket number in > the commit message. You can correct/change CVS commit messages with the `cvs admin' command. Use something like cvs admin '-m:message text' Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Fri Aug 21 10:20:56 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 21 Aug 2009 10:20:56 +0200 Subject: [M3devel] A question about the M3 licensing... In-Reply-To: <20090820234825.GB3925@topoi.pooq.com> References: <20090820234825.GB3925@topoi.pooq.com> Message-ID: <20090821102056.nbcql8hsc8ww80cc@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > I suppose there's another possibility -- writing a new M3 front end with > a different licence, and being free of SRC forever. Except that if > some of our libraries are compiled from SRC source code, will we have to > compile at installation tiem to avould distributing mixed GNU/SRC > binaries? I don't think this is correct. The SRC license allows much more than the GNU FSF license. That was exactly the stumbling block when it came to integrating the M3 extensions to gcc into the gcc distribution. The FSF didn't like the way the backend was used in a different process context in order to avoid infecting all compiler code with the FSF license. Of course you can write another compiler front-end under the FSF license. I'd assume this will take several man-years though until you reach the quality of the current system. And any commercial use will then be much more difficult, but this is probably moot regarding the current widespread user base :-) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Aug 21 11:32:31 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 21 Aug 2009 09:32:31 +0000 Subject: [M3devel] A question about the M3 licensing... In-Reply-To: <20090821102056.nbcql8hsc8ww80cc@mail.elegosoft.com> References: <20090820234825.GB3925@topoi.pooq.com> <20090821102056.nbcql8hsc8ww80cc@mail.elegosoft.com> Message-ID: > Of course you can write another compiler front-end under the FSF It's surprising how similar Ada looks to Modula-3.. I've looked into llvm but haven't really got my head around it and/or the cm3 intermediate representation. If I could get my head around the latter I'd really like to try to translate that into C, for better and worse. Gcc relatively recently grew a plugin interface. That might be useful to us. Might -- you know, like, we'd say gcc -plugin-something-somesuch *.mc and gcc would load cm3cg.so or somesuch. Potentially m3-sys/m3cc would drop in size dramatically. - Jay > Date: Fri, 21 Aug 2009 10:20:56 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] A question about the M3 licensing... > > Quoting hendrik at topoi.pooq.com: > > > I suppose there's another possibility -- writing a new M3 front end with > > a different licence, and being free of SRC forever. Except that if > > some of our libraries are compiled from SRC source code, will we have to > > compile at installation tiem to avould distributing mixed GNU/SRC > > binaries? > > I don't think this is correct. The SRC license allows much more than > the GNU FSF license. That was exactly the stumbling block when it came > to integrating the M3 extensions to gcc into the gcc distribution. > The FSF didn't like the way the backend was used in a different process > context in order to avoid infecting all compiler code with the FSF > license. > > Of course you can write another compiler front-end under the FSF > license. I'd assume this will take several man-years though until > you reach the quality of the current system. And any commercial use > will then be much more difficult, but this is probably moot > regarding the current widespread user base :-) > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Fri Aug 21 11:47:16 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 21 Aug 2009 05:47:16 -0400 Subject: [M3devel] A question about the M3 licensing... In-Reply-To: References: <20090820234825.GB3925@topoi.pooq.com> <20090821102056.nbcql8hsc8ww80cc@mail.elegosoft.com> Message-ID: <20090821094716.GA5222@topoi.pooq.com> On Fri, Aug 21, 2009 at 09:32:31AM +0000, Jay K wrote: > > It's surprising how similar Ada looks to Modula-3.. I think they both dated from the same era, and both are ultimately based on Pascal syntax. > I've looked into llvm but haven't really got my head around it and/or > the cm3 intermediate representation. Do you mean the internal parse tree? > If I could get my head around the > latter I'd really like to try to translate that into C, for better and > worse. Didn't there use to be a translator from Modula 3 to C before people gave up on C as not being a good object code language? Wouldn't it still be lurking in anckent CVS branches somewhere? -- hendrik From wagner at elegosoft.com Fri Aug 21 12:18:25 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 21 Aug 2009 12:18:25 +0200 Subject: [M3devel] A question about the M3 licensing... In-Reply-To: References: <20090820234825.GB3925@topoi.pooq.com> <20090821102056.nbcql8hsc8ww80cc@mail.elegosoft.com> Message-ID: <20090821121825.pk6wsoyrb4w4gkgo@mail.elegosoft.com> Quoting Jay K : > > Of course you can write another compiler front-end under the FSF > > It's surprising how similar Ada looks to Modula-3.. > > I've looked into llvm but haven't really got my head around it > and/or the cm3 intermediate representation. If I could get my head > around the latter I'd really like to try to translate that into C, > for better and worse. Perhaps it would be best if we start to document the intermediate code representation. I.e. write a short but useful interface spec? Who would be able and willing to do that? > Gcc relatively recently grew a plugin interface. > > That might be useful to us. Might -- you know, like, we'd say gcc > -plugin-something-somesuch *.mc and gcc would load cm3cg.so or > somesuch. Potentially m3-sys/m3cc would drop in size dramatically. This sounds interesting, too. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Fri Aug 21 12:31:39 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 21 Aug 2009 12:31:39 +0200 Subject: [M3devel] A question about the M3 licensing... In-Reply-To: <20090821094716.GA5222@topoi.pooq.com> References: <20090820234825.GB3925@topoi.pooq.com> <20090821102056.nbcql8hsc8ww80cc@mail.elegosoft.com> <20090821094716.GA5222@topoi.pooq.com> Message-ID: <20090821123139.wy7bo0jhmgwg8s8c@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > On Fri, Aug 21, 2009 at 09:32:31AM +0000, Jay K wrote: >> >> It's surprising how similar Ada looks to Modula-3.. > > I think they both dated from the same era, and both are ultimately based > on Pascal syntax. > >> I've looked into llvm but haven't really got my head around it and/or >> the cm3 intermediate representation. > > Do you mean the internal parse tree? > >> If I could get my head around the >> latter I'd really like to try to translate that into C, for better and >> worse. > > Didn't there use to be a translator from Modula 3 to C before people > gave up on C as not being a good object code language? Wouldn't it > still be lurking in anckent CVS branches somewhere? AFAIK only the first release of M3 used C as intermediate code. Later SRC releases used gcc as backend. I don't know if any of the old archives are still accessible somewhere. SRC never used/provided a public version control system (though they internally had bindings for Vesta AFAIK). (For Vesta, see http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-168.pdf.) So there will be no public record of the old compiler sources in any repository. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dmuysers at hotmail.com Fri Aug 21 13:25:36 2009 From: dmuysers at hotmail.com (Dirk Muysers) Date: Fri, 21 Aug 2009 13:25:36 +0200 Subject: [M3devel] A question about the M3 licensing... In-Reply-To: <20090820234825.GB3925@topoi.pooq.com><20090821102056.nbcql8hsc8ww80cc@mail.elegosoft.com><20090821094716.GA5222@topoi.pooq.com> <20090821123139.wy7bo0jhmgwg8s8c@mail.elegosoft.com> References: <20090820234825.GB3925@topoi.pooq.com><20090821102056.nbcql8hsc8ww80cc@mail.elegosoft.com><20090821094716.GA5222@topoi.pooq.com> <20090821123139.wy7bo0jhmgwg8s8c@mail.elegosoft.com> Message-ID: Have a look at the Klagenfurt site (http://www.cs.tut.fi/lintula/manual/modula3/modula-3/html/m3pc.html) Maybe it still hangs around. If not, I have the source on my hard disk. -------------------------------------------------- From: "Olaf Wagner" Sent: Friday, August 21, 2009 12:31 PM To: Subject: Re: [M3devel] A question about the M3 licensing... > Quoting hendrik at topoi.pooq.com: > >> On Fri, Aug 21, 2009 at 09:32:31AM +0000, Jay K wrote: >>> >>> It's surprising how similar Ada looks to Modula-3.. >> >> I think they both dated from the same era, and both are ultimately based >> on Pascal syntax. >> >>> I've looked into llvm but haven't really got my head around it and/or >>> the cm3 intermediate representation. >> >> Do you mean the internal parse tree? >> >>> If I could get my head around the >>> latter I'd really like to try to translate that into C, for better and >>> worse. >> >> Didn't there use to be a translator from Modula 3 to C before people >> gave up on C as not being a good object code language? Wouldn't it >> still be lurking in anckent CVS branches somewhere? > > AFAIK only the first release of M3 used C as intermediate code. > Later SRC releases used gcc as backend. I don't know if any of > the old archives are still accessible somewhere. > > SRC never used/provided a public version control system (though they > internally had bindings for Vesta AFAIK). > (For Vesta, see > http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-168.pdf.) > > So there will be no public record of the old compiler sources in any > repository. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 > 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > From jay.krell at cornell.edu Fri Aug 21 16:19:18 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 21 Aug 2009 14:19:18 +0000 Subject: [M3devel] lock before or after try? Message-ID: lock try stuff finally unlock end or try lock stuff finally unlock end Lock can't fail so no difference? - Jay From lchretien at mac.com Fri Aug 21 20:35:03 2009 From: lchretien at mac.com (Louis =?ISO-8859-1?B?Q2hy6XRpZW4=?=) Date: Fri, 21 Aug 2009 14:35:03 -0400 Subject: [M3devel] A more precise question about M3 licensing... Message-ID: >From what I gathered so far on this thread, the SRC licence was quite a bit more liberal than the FSF license, which led to this "separate process" business for the code generation phase, which displeased the FSF somewhat... After having read the licence for the LLVM project (a one pager on their website), i find it quite liberal and you can basically do anything with the code, as long as you give proper credit and keep the license with the files. I'm no lawyer, but it seems that the SRC and LLVM licenses could play along fine, as opposed to the FSF trying to "infect" everything it touches... So, here's the idea I had: Combine the existing CM3 (and/or PM3) front-end, and modify it to emit LLVM bytecodes, so that we could use the LLVM back-end and infrastructure to create a complete compiler/linker. Would such a beast, by combining code from both licenses, be viable? I would like to keep the licensing as liberal as possible. I sure would like your ideas on this subject, P.S.: Olaf, I think your suggestion of documenting the existing intermidiate representation of the CM3 compiler would be an absolute first step... -- Louis Chr?tien lchretien at mac.com From wagner at elegosoft.com Fri Aug 21 21:36:52 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 21 Aug 2009 21:36:52 +0200 Subject: [M3devel] @M3paranoidgc always crashes In-Reply-To: <007DD8EA-4A1C-447A-B8FB-56396A8F6560@cs.purdue.edu> References: <20090820171058.0stkh5eu68cw0ksk@mail.elegosoft.com> <007DD8EA-4A1C-447A-B8FB-56396A8F6560@cs.purdue.edu> Message-ID: <20090821213652.nd7w7ddirkwookgk@mail.elegosoft.com> Quoting Tony Hosking : > Jay may have fixed this for now. It seems to be still broken, at least in the release branch. I'm currently adding some tests. Running a simple test program with @M3paranoidgc does not terminate: % ../src/p2/p213/FreeBSD4/pgm `Hello world' and `Hello world' are equal. The length of the first is 11 Extracting four chars from position 3 yields --lo w-- Salut = Hello done. luthien [~/work/cm3/m3-sys/m3tests/src] wagner % ../src/p2/p213/FreeBSD4/pgm @M3paranoidgc *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL^C It only prints half of the message and eats lots of CPU afterwards. I'll open a ticket for it and won't build release packages until it is fixed. Ticket is #1063. Olaf > > On 20 Aug 2009, at 11:10, Olaf Wagner wrote: > >> Quoting Tony Hosking : >> >>> Indeed, the use of paranoidgc itself now seems to be broken >>> (independently of any other bug you might be trying to track down by >>> invoking paranoidgc). >>> This is a serious bug, that should be rectified *before* any release. >>> Without it, we cannot easily diagnose GC bugs in the field. I have >>> little to no time to devote to this right now, but it does look like >>> the recent changes to threading initialisation has broken things. I >>> remember being very careful about initialization of threads and heap >>> components of the run-time when working on the original native >>> threads. In particular, the ability to invoke ThreadF.GetActivation >>> was allowed before ThreadF.Init had been called, because >>> ThreadF.InitActivations was able to be invoked on-demand independently >>> of ThreadF.Init. This independence now seems to have been eliminated >>> so as to eliminate a run-time check in GetActivation. >> >> Jay, could you open a ticket for that, too? >> >> And we also need to add tests for running with various @M3 options... >> >> Olaf >> >>> >>> On 20 Aug 2009, at 05:55, Jay K wrote: >>> >>>> >>>> Verified on SOLgnu and AMD64_LINUX. >>>> Probably related to initialization order changes that let user >>>> threads work again. >>>> Probably should just use untraced? >>>> >>>> >>>> >>>> % gdb --args ./cm3 @M3paranoidgc >>>> GNU gdb 6.4.90-debian >>>> Copyright (C) 2006 Free Software Foundation, Inc. >>>> GDB is free software, covered by the GNU General Public License, >>>> and you are >>>> welcome to change it and/or distribute copies of it under >>>> certain conditions. >>>> Type "show copying" to see the conditions. >>>> There is absolutely no warranty for GDB. Type "show warranty" >>>> for details. >>>> This GDB was configured as "x86_64-linux-gnu"...Using host >>>> libthread_db library >>>> "/lib/libthread_db.so.1". >>>> (gdb) run >>>> Starting program: /home/jkrell/cm3/bin/cm3 @M3paranoidgc >>>> [Thread debugging using libthread_db enabled] >>>> [New Thread 47899659458256 (LWP 29607)] >>>> Program received signal SIGSEGV, Segmentation fault. >>>> [Switching to Thread 47899659458256 (LWP 29607)] >>>> 0x00000000006934c5 in RTAllocator__GetTracedObj >>>> (M3_Eic7CK_def=Cannot access mem >>>> ory at address 0x800028d97718 >>>> ) >>>> at ../src/runtime/common/RTAllocator.m3:221 >>>> 221 INC(thread.inCritical); >>>> (gdb) bt >>>> #0 0x00000000006934c5 in RTAllocator__GetTracedObj >>>> (M3_Eic7CK_def=Cannot access >>>> memory at address 0x800028d97718 >>>> ) >>>> at ../src/runtime/common/RTAllocator.m3:221 >>>> #1 0x0000000000692e1f in RTHooks__AllocateTracedObj >>>> (M3_AJWxb1_defn=Cannot acce >>>> ss memory at address 0x800028d97788 >>>> ) >>>> at ../src/runtime/common/RTAllocator.m3:120 >>>> #2 0x000000000069b3ae in RTCollector__InstallSanityCheck () >>>> at ../src/runtime/common/RTCollector.m3:1637 >>>> #3 0x00000000006a1747 in RTHeapRep__Init () >>>> at ../src/runtime/common/RTCollector.m3:2769 >>>> #4 0x00000000006a2a1d in RTLinker__InitRuntime >>>> (M3_AcxOUs_p_argc=Cannot access >>>> memory at address 0x800028d97858 >>>> ) >>>> at ../src/runtime/common/RTLinker.m3:58 >>>> #5 0x00000000004160bc in main (argc=Cannot access memory at >>>> address 0x800028d97 >>>> 8a8 >>>> ) at _m3main.mc:3 >>>> (gdb) -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From roland.illig at gmx.de Fri Aug 21 21:44:50 2009 From: roland.illig at gmx.de (Roland Illig) Date: Fri, 21 Aug 2009 21:44:50 +0200 Subject: [M3devel] lock before or after try? In-Reply-To: References: Message-ID: <4A8EF932.2020804@gmx.de> Jay K schrieb: > lock > try > stuff > finally > unlock > end > > or > try > lock > stuff > finally > unlock > end > > Lock can't fail so no difference? I would always choose the first variant, because if locking fails for some reason (although it cannot, I know), unlock will not be called without a corresponding lock. At least in Java, it may happen that another thread interrupts this one just in the very nanosecond between the try and lock, throwing an exception, and then you would unlock something that hasn't been locked before. Roland From lchretien at mac.com Fri Aug 21 21:57:48 2009 From: lchretien at mac.com (Louis =?ISO-8859-1?B?Q2hy6XRpZW4=?=) Date: Fri, 21 Aug 2009 15:57:48 -0400 Subject: [M3devel] A more precise question about M3 licensing... Message-ID: (I don't know why it was truncated the first time...) >From what I gathered so far on this thread, the SRC licence was quite a bit more liberal than the FSF license, which led to this "separate process" business for the code generation phase, which displeased the FSF somewhat... After having read the licence for the LLVM project (a one pager on their website), i find it quite liberal and you can basically do anything with the code, as long as you give proper credit and keep the license with the files. I'm no lawyer, but it seems that the SRC and LLVM licenses could play along fine, as opposed to the FSF trying to "infect" everything it touches... So, here's the idea I had: Combine the existing CM3 (and/or PM3) front-end, and modify it to emit LLVM bytecodes, so that we could use the LLVM back-end and infrastructure to create a complete compiler/linker. Would such a beast, by combining code from both licenses, be viable? I would like to keep the licensing as liberal as possible. I sure would like your ideas on this subject, P.S.: Olaf, I think your suggestion of documenting the existing intermidiate representation of the CM3 compiler would be an absolute first step... -- Louis Chr?tien lchretien at mac.com From jay.krell at cornell.edu Fri Aug 21 23:47:35 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 21 Aug 2009 21:47:35 +0000 Subject: [M3devel] @M3paranoidgc always crashes In-Reply-To: <20090821213652.nd7w7ddirkwookgk@mail.elegosoft.com> References: <20090820171058.0stkh5eu68cw0ksk@mail.elegosoft.com> <007DD8EA-4A1C-447A-B8FB-56396A8F6560@cs.purdue.edu> <20090821213652.nd7w7ddirkwookgk@mail.elegosoft.com> Message-ID: Fix is in head. - Jay > Date: Fri, 21 Aug 2009 21:36:52 +0200 > From: wagner at elegosoft.com > To: hosking at cs.purdue.edu; jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] @M3paranoidgc always crashes > > Quoting Tony Hosking : > > > Jay may have fixed this for now. > > It seems to be still broken, at least in the release branch. I'm currently > adding some tests. Running a simple test program with @M3paranoidgc > does not terminate: > > % ../src/p2/p213/FreeBSD4/pgm > `Hello world' and `Hello world' are equal. > The length of the first is 11 > Extracting four chars from position 3 yields --lo w-- > Salut = Hello > > done. > luthien [~/work/cm3/m3-sys/m3tests/src] wagner > % ../src/p2/p213/FreeBSD4/pgm @M3paranoidgc > > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL^C > > It only prints half of the message and eats lots of CPU afterwards. > > I'll open a ticket for it and won't build release packages until it is > fixed. > > Ticket is #1063. > > Olaf > > > > > On 20 Aug 2009, at 11:10, Olaf Wagner wrote: > > > >> Quoting Tony Hosking : > >> > >>> Indeed, the use of paranoidgc itself now seems to be broken > >>> (independently of any other bug you might be trying to track down by > >>> invoking paranoidgc). > >>> This is a serious bug, that should be rectified *before* any release. > >>> Without it, we cannot easily diagnose GC bugs in the field. I have > >>> little to no time to devote to this right now, but it does look like > >>> the recent changes to threading initialisation has broken things. I > >>> remember being very careful about initialization of threads and heap > >>> components of the run-time when working on the original native > >>> threads. In particular, the ability to invoke ThreadF.GetActivation > >>> was allowed before ThreadF.Init had been called, because > >>> ThreadF.InitActivations was able to be invoked on-demand independently > >>> of ThreadF.Init. This independence now seems to have been eliminated > >>> so as to eliminate a run-time check in GetActivation. > >> > >> Jay, could you open a ticket for that, too? > >> > >> And we also need to add tests for running with various @M3 options... > >> > >> Olaf > >> > >>> > >>> On 20 Aug 2009, at 05:55, Jay K wrote: > >>> > >>>> > >>>> Verified on SOLgnu and AMD64_LINUX. > >>>> Probably related to initialization order changes that let user > >>>> threads work again. > >>>> Probably should just use untraced? > >>>> > >>>> > >>>> > >>>> % gdb --args ./cm3 @M3paranoidgc > >>>> GNU gdb 6.4.90-debian > >>>> Copyright (C) 2006 Free Software Foundation, Inc. > >>>> GDB is free software, covered by the GNU General Public License, > >>>> and you are > >>>> welcome to change it and/or distribute copies of it under > >>>> certain conditions. > >>>> Type "show copying" to see the conditions. > >>>> There is absolutely no warranty for GDB. Type "show warranty" > >>>> for details. > >>>> This GDB was configured as "x86_64-linux-gnu"...Using host > >>>> libthread_db library > >>>> "/lib/libthread_db.so.1". > >>>> (gdb) run > >>>> Starting program: /home/jkrell/cm3/bin/cm3 @M3paranoidgc > >>>> [Thread debugging using libthread_db enabled] > >>>> [New Thread 47899659458256 (LWP 29607)] > >>>> Program received signal SIGSEGV, Segmentation fault. > >>>> [Switching to Thread 47899659458256 (LWP 29607)] > >>>> 0x00000000006934c5 in RTAllocator__GetTracedObj > >>>> (M3_Eic7CK_def=Cannot access mem > >>>> ory at address 0x800028d97718 > >>>> ) > >>>> at ../src/runtime/common/RTAllocator.m3:221 > >>>> 221 INC(thread.inCritical); > >>>> (gdb) bt > >>>> #0 0x00000000006934c5 in RTAllocator__GetTracedObj > >>>> (M3_Eic7CK_def=Cannot access > >>>> memory at address 0x800028d97718 > >>>> ) > >>>> at ../src/runtime/common/RTAllocator.m3:221 > >>>> #1 0x0000000000692e1f in RTHooks__AllocateTracedObj > >>>> (M3_AJWxb1_defn=Cannot acce > >>>> ss memory at address 0x800028d97788 > >>>> ) > >>>> at ../src/runtime/common/RTAllocator.m3:120 > >>>> #2 0x000000000069b3ae in RTCollector__InstallSanityCheck () > >>>> at ../src/runtime/common/RTCollector.m3:1637 > >>>> #3 0x00000000006a1747 in RTHeapRep__Init () > >>>> at ../src/runtime/common/RTCollector.m3:2769 > >>>> #4 0x00000000006a2a1d in RTLinker__InitRuntime > >>>> (M3_AcxOUs_p_argc=Cannot access > >>>> memory at address 0x800028d97858 > >>>> ) > >>>> at ../src/runtime/common/RTLinker.m3:58 > >>>> #5 0x00000000004160bc in main (argc=Cannot access memory at > >>>> address 0x800028d97 > >>>> 8a8 > >>>> ) at _m3main.mc:3 > >>>> (gdb) > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Aug 22 00:32:44 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 22 Aug 2009 00:32:44 +0200 Subject: [M3devel] A more precise question about M3 licensing... In-Reply-To: References: Message-ID: <20090822003244.xwf5l3f5icswcgks@mail.elegosoft.com> Quoting Louis Chr?tien : > (I don't know why it was truncated the first time...) I've got a theory now regarding mail truncation. > From what I gathered so far on this thread, the SRC licence was quite a bit > more liberal than the FSF license, which led to this "separate process" > business for the code generation phase, which displeased the FSF somewhat.. It happens when a period gets wrapped to the start of a line. A line starting with a period is the ancient way to end a message or a file. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Sat Aug 22 00:36:24 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 22 Aug 2009 00:36:24 +0200 Subject: [M3devel] @M3paranoidgc always crashes In-Reply-To: References: <20090820171058.0stkh5eu68cw0ksk@mail.elegosoft.com> <007DD8EA-4A1C-447A-B8FB-56396A8F6560@cs.purdue.edu> <20090821213652.nd7w7ddirkwookgk@mail.elegosoft.com> Message-ID: <20090822003624.i5xcphcf4gsgo44o@mail.elegosoft.com> Quoting Jay K : > Fix is in head. OK. I merged runtime and thread from the trunk head. I couldn't compile it though. Some imports were missing. Strange. With the added imports, the tests seem to run fine. Thanks, Olaf > - Jay > >> Date: Fri, 21 Aug 2009 21:36:52 +0200 >> From: wagner at elegosoft.com >> To: hosking at cs.purdue.edu; jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] @M3paranoidgc always crashes >> >> Quoting Tony Hosking : >> >> > Jay may have fixed this for now. >> >> It seems to be still broken, at least in the release branch. I'm currently >> adding some tests. Running a simple test program with @M3paranoidgc >> does not terminate: >> >> % ../src/p2/p213/FreeBSD4/pgm >> `Hello world' and `Hello world' are equal. >> The length of the first is 11 >> Extracting four chars from position 3 yields --lo w-- >> Salut = Hello >> >> done. >> luthien [~/work/cm3/m3-sys/m3tests/src] wagner >> % ../src/p2/p213/FreeBSD4/pgm @M3paranoidgc >> >> >> *** >> *** runtime error: >> *** Segmentation violation - possible attempt to dereference NIL^C >> >> It only prints half of the message and eats lots of CPU afterwards. >> >> I'll open a ticket for it and won't build release packages until it is >> fixed. >> >> Ticket is #1063. >> >> Olaf >> >> > >> > On 20 Aug 2009, at 11:10, Olaf Wagner wrote: >> > >> >> Quoting Tony Hosking : >> >> >> >>> Indeed, the use of paranoidgc itself now seems to be broken >> >>> (independently of any other bug you might be trying to track down by >> >>> invoking paranoidgc). >> >>> This is a serious bug, that should be rectified *before* any release. >> >>> Without it, we cannot easily diagnose GC bugs in the field. I have >> >>> little to no time to devote to this right now, but it does look like >> >>> the recent changes to threading initialisation has broken things. I >> >>> remember being very careful about initialization of threads and heap >> >>> components of the run-time when working on the original native >> >>> threads. In particular, the ability to invoke ThreadF.GetActivation >> >>> was allowed before ThreadF.Init had been called, because >> >>> ThreadF.InitActivations was able to be invoked on-demand independently >> >>> of ThreadF.Init. This independence now seems to have been eliminated >> >>> so as to eliminate a run-time check in GetActivation. >> >> >> >> Jay, could you open a ticket for that, too? >> >> >> >> And we also need to add tests for running with various @M3 options... >> >> >> >> Olaf >> >> >> >>> >> >>> On 20 Aug 2009, at 05:55, Jay K wrote: >> >>> >> >>>> >> >>>> Verified on SOLgnu and AMD64_LINUX. >> >>>> Probably related to initialization order changes that let user >> >>>> threads work again. >> >>>> Probably should just use untraced? >> >>>> >> >>>> >> >>>> >> >>>> % gdb --args ./cm3 @M3paranoidgc >> >>>> GNU gdb 6.4.90-debian >> >>>> Copyright (C) 2006 Free Software Foundation, Inc. >> >>>> GDB is free software, covered by the GNU General Public License, >> >>>> and you are >> >>>> welcome to change it and/or distribute copies of it under >> >>>> certain conditions. >> >>>> Type "show copying" to see the conditions. >> >>>> There is absolutely no warranty for GDB. Type "show warranty" >> >>>> for details. >> >>>> This GDB was configured as "x86_64-linux-gnu"...Using host >> >>>> libthread_db library >> >>>> "/lib/libthread_db.so.1". >> >>>> (gdb) run >> >>>> Starting program: /home/jkrell/cm3/bin/cm3 @M3paranoidgc >> >>>> [Thread debugging using libthread_db enabled] >> >>>> [New Thread 47899659458256 (LWP 29607)] >> >>>> Program received signal SIGSEGV, Segmentation fault. >> >>>> [Switching to Thread 47899659458256 (LWP 29607)] >> >>>> 0x00000000006934c5 in RTAllocator__GetTracedObj >> >>>> (M3_Eic7CK_def=Cannot access mem >> >>>> ory at address 0x800028d97718 >> >>>> ) >> >>>> at ../src/runtime/common/RTAllocator.m3:221 >> >>>> 221 INC(thread.inCritical); >> >>>> (gdb) bt >> >>>> #0 0x00000000006934c5 in RTAllocator__GetTracedObj >> >>>> (M3_Eic7CK_def=Cannot access >> >>>> memory at address 0x800028d97718 >> >>>> ) >> >>>> at ../src/runtime/common/RTAllocator.m3:221 >> >>>> #1 0x0000000000692e1f in RTHooks__AllocateTracedObj >> >>>> (M3_AJWxb1_defn=Cannot acce >> >>>> ss memory at address 0x800028d97788 >> >>>> ) >> >>>> at ../src/runtime/common/RTAllocator.m3:120 >> >>>> #2 0x000000000069b3ae in RTCollector__InstallSanityCheck () >> >>>> at ../src/runtime/common/RTCollector.m3:1637 >> >>>> #3 0x00000000006a1747 in RTHeapRep__Init () >> >>>> at ../src/runtime/common/RTCollector.m3:2769 >> >>>> #4 0x00000000006a2a1d in RTLinker__InitRuntime >> >>>> (M3_AcxOUs_p_argc=Cannot access >> >>>> memory at address 0x800028d97858 >> >>>> ) >> >>>> at ../src/runtime/common/RTLinker.m3:58 >> >>>> #5 0x00000000004160bc in main (argc=Cannot access memory at >> >>>> address 0x800028d97 >> >>>> 8a8 >> >>>> ) at _m3main.mc:3 >> >>>> (gdb) >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From lchretien at mac.com Fri Aug 21 23:40:27 2009 From: lchretien at mac.com (Louis =?ISO-8859-1?B?Q2hy6XRpZW4=?=) Date: Fri, 21 Aug 2009 17:40:27 -0400 Subject: [M3devel] A more precise question about M3 licensing... Message-ID: (Real sorry about this, I don't know why it keeps being truncated...) >From what I gathered so far on this thread, the SRC licence was quite a bit more liberal than the FSF license, which led to this "separate process" business for the code generation phase, which displeased the FSF somewhat. ;-) After having read the licence for the LLVM project (a one pager on their website), i find it quite liberal and you can basically do anything with the code, as long as you give proper credit and keep the license with the files. I'm no lawyer, but it seems that the SRC and LLVM licenses could play along fine, as opposed to the FSF trying to "infect" everything it touches... So, here's the idea I had: Combine the existing CM3 (and/or PM3) front-end, and modify it to emit LLVM bytecodes, so that we could use the LLVM back-end and infrastructure to create a complete compiler/linker. Would such a beast, by combining code from both licenses, be viable? I would like to keep the licensing as liberal as possible. I sure would like your ideas on this subject, P.S.: Olaf, I think your suggestion of documenting the existing intermidiate representation of the CM3 compiler would be an absolute first step... -- Louis Chr?tien lchretien at mac.com From wagner at elegosoft.com Sat Aug 22 01:16:49 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 22 Aug 2009 01:16:49 +0200 Subject: [M3devel] config init problem Message-ID: <20090822011649.81l7rnebgg8884k4@mail.elegosoft.com> In MxConfig.m3 quake runtime exception were ignored and thrown away in EvalConfig. Writing them to stderr, we get the following output for a simple cm3.cfg file: % cat ~/cm3-rc3/bin/cm3.cfg %INSTALL_ROOT = "/ad0e/home/wagner/cm3-rc3" INSTALL_ROOT = path() & SL & ".." include(path() & "/config/FreeBSD4") luthien [~/work/cm3] wagner % cm3 -trace -version Critical Mass Modula-3 version p5.8.3 last updated: 2009-08-10 compiled: 2009-08-21 22:59:34 configuration: /ad0e/home/wagner/cm3-rc3/bin/cm3.cfg host: FreeBSD4 ****** /ad0e/home/wagner/cm3-rc3/bin/cm3.cfg ****** .0 SetLine 1 .1 SetLine 3 .2 LoadVar (193) "path" .3 StartCall .4 CallFunc 0 .5 LoadVar (373) "SL" quake runtime error: "/ad0e/home/wagner/cm3-rc3/bin/cm3.cfg", line 3: quake runtime error: undefined variable: SL --procedure-- -line- -file--- 3 /ad0e/home/wagner/cm3-rc3/bin/cm3.cfg target: SL gets defined in M3Build.m3 in cm3, along with all the other builtins that the compiler may use (and the config file author). Of course MxConfig in package m3quake does not know about these, as it creates its own quake machine on the fly. So configuration evaluation won't work in general currently, unless only standard quake functions and definitions are used. Any ideas? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sat Aug 22 04:13:59 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 22 Aug 2009 02:13:59 +0000 Subject: [M3devel] config init problem In-Reply-To: <20090822011649.81l7rnebgg8884k4@mail.elegosoft.com> References: <20090822011649.81l7rnebgg8884k4@mail.elegosoft.com> Message-ID: In the top of cm3.cfg put if not defined("SL") SL = "/" and/or just hardcode forward slash -- it works on Windows. There is already similar in a few places. Look at cminstall/src/config-no-install/cm3.cfg. This is why m3tohtml and such were crashing, but I dealt with them. I thought. Again, see the cm3.cfg and cm3cfg.common, etc. I have a proposal for next release that the predefines that cm3 does be made available to all quake clients via some new function. - Jay > Date: Sat, 22 Aug 2009 01:16:49 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] config init problem > > In MxConfig.m3 quake runtime exception were ignored and thrown away > in EvalConfig. Writing them to stderr, we get the following output > for a simple cm3.cfg file: > > % cat ~/cm3-rc3/bin/cm3.cfg > > %INSTALL_ROOT = "/ad0e/home/wagner/cm3-rc3" > INSTALL_ROOT = path() & SL & ".." > > include(path() & "/config/FreeBSD4") > > luthien [~/work/cm3] wagner > % cm3 -trace -version > Critical Mass Modula-3 version p5.8.3 > last updated: 2009-08-10 > compiled: 2009-08-21 22:59:34 > configuration: /ad0e/home/wagner/cm3-rc3/bin/cm3.cfg > host: FreeBSD4 > ****** /ad0e/home/wagner/cm3-rc3/bin/cm3.cfg ****** > .0 SetLine 1 > .1 SetLine 3 > .2 LoadVar (193) "path" > .3 StartCall > .4 CallFunc 0 > .5 LoadVar (373) "SL" > quake runtime error: "/ad0e/home/wagner/cm3-rc3/bin/cm3.cfg", line 3: > quake runtime error: undefined variable: SL > > --procedure-- -line- -file--- > 3 /ad0e/home/wagner/cm3-rc3/bin/cm3.cfg > target: > > SL gets defined in M3Build.m3 in cm3, along with all the other > builtins that the compiler may use (and the config file author). > Of course MxConfig in package m3quake does not know about these, > as it creates its own quake machine on the fly. > > So configuration evaluation won't work in general currently, > unless only standard quake functions and definitions are used. > > Any ideas? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Aug 22 11:07:41 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 22 Aug 2009 11:07:41 +0200 Subject: [M3devel] A more precise question about M3 licensing... In-Reply-To: <20090822003244.xwf5l3f5icswcgks@mail.elegosoft.com> References: <20090822003244.xwf5l3f5icswcgks@mail.elegosoft.com> Message-ID: <20090822110741.s6vo69beo000k8c8@mail.elegosoft.com> Quoting Olaf Wagner : > Quoting Louis Chr?tien : > >> (I don't know why it was truncated the first time...) > > I've got a theory now regarding mail truncation. > >> From what I gathered so far on this thread, the SRC licence was quite a bit >> more liberal than the FSF license, which led to this "separate process" >> business for the code generation phase, which displeased the FSF somewhat > > It happens when a period gets wrapped to the start of a line. A line > starting with a period is the ancient way to end a message or a > file. This got truncated, too. Another attempt with some periods removed. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Sat Aug 22 11:45:44 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 22 Aug 2009 11:45:44 +0200 Subject: [M3devel] config init problem In-Reply-To: References: <20090822011649.81l7rnebgg8884k4@mail.elegosoft.com> Message-ID: <20090822114544.i2wwhjp1wsgwws0c@mail.elegosoft.com> Quoting Jay K : > In the top of cm3.cfg put > if not defined("SL") SL = "/" > and/or just hardcode forward slash -- it works on Windows. > > There is already similar in a few places. > Look at cminstall/src/config-no-install/cm3.cfg. I'm not really comfortable with this solution. And I don't think you are ;-) It's just a workaround for SL, but doesn't deal with the other several dozens of definitions whiche _might_ be used in the config scripts. > This is why m3tohtml and such were crashing, but I dealt with them. > I thought. Again, see the cm3.cfg and cm3cfg.common, etc. If the exception wouldn't have been silently ignored in MxConfig.m3, that should have been easy to diagnose. We probably need to build some kind of quality-check tool for M3, which warns about such coding, or should review our changes more often and better. Alas, I'm afraid that won't happen because nobody has enougth time :-( Or perhpas just add a warning to the compiler if a caught exception is just thrown away? > I have a proposal for next release that the predefines that cm3 does > be made available to all quake clients via some new function. We could of course pass down the correctly initialized QM in cm3 (M3Build -> Makefile -> MxConfig). That would fix the problem for cm3, but not for other clients, unless we make them depend on most of the build functions. The latter seems rather unnecessary and inconvenient if only some simple definitions like TARGET are needed. Perhaps we need to distinguish between two kinds of config files: one level for simple clients which may only contain assignments and basic quake functions from m3quake, and more complex initialization for cm3. I agree we should probably not make such changes in the release branch now and postpone them. Olaf >> Date: Sat, 22 Aug 2009 01:16:49 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] config init problem >> >> In MxConfig.m3 quake runtime exception were ignored and thrown away >> in EvalConfig. Writing them to stderr, we get the following output >> for a simple cm3.cfg file: >> >> % cat ~/cm3-rc3/bin/cm3.cfg >> >> %INSTALL_ROOT = "/ad0e/home/wagner/cm3-rc3" >> INSTALL_ROOT = path() & SL & ".." >> >> include(path() & "/config/FreeBSD4") >> >> luthien [~/work/cm3] wagner >> % cm3 -trace -version >> Critical Mass Modula-3 version p5.8.3 >> last updated: 2009-08-10 >> compiled: 2009-08-21 22:59:34 >> configuration: /ad0e/home/wagner/cm3-rc3/bin/cm3.cfg >> host: FreeBSD4 >> ****** /ad0e/home/wagner/cm3-rc3/bin/cm3.cfg ****** >> .0 SetLine 1 >> .1 SetLine 3 >> .2 LoadVar (193) "path" >> .3 StartCall >> .4 CallFunc 0 >> .5 LoadVar (373) "SL" >> quake runtime error: "/ad0e/home/wagner/cm3-rc3/bin/cm3.cfg", line 3: >> quake runtime error: undefined variable: SL >> >> --procedure-- -line- -file--- >> 3 /ad0e/home/wagner/cm3-rc3/bin/cm3.cfg >> target: >> >> SL gets defined in M3Build.m3 in cm3, along with all the other >> builtins that the compiler may use (and the config file author). >> Of course MxConfig in package m3quake does not know about these, >> as it creates its own quake machine on the fly. >> >> So configuration evaluation won't work in general currently, >> unless only standard quake functions and definitions are used. >> >> Any ideas? -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From lchretien at mac.com Sat Aug 22 13:19:09 2009 From: lchretien at mac.com (Louis =?ISO-8859-1?B?Q2hy6XRpZW4=?=) Date: Sat, 22 Aug 2009 07:19:09 -0400 Subject: [M3devel] A more precise question about M3 licensing Message-ID: (Real sorry about this, I don't know why it keeps being truncated...) >From what I gathered so far on this thread, the SRC licence was quite a bit more liberal than the FSF license, which led to this "separate process" business for the code generation phase, which displeased the FSF somewhat. ;-) After having read the licence for the LLVM project (a one pager on their website), i find it quite liberal and you can basically do anything with the code, as long as you give proper credit and keep the license with the files. I'm no lawyer, but it seems that the SRC and LLVM licenses could play along fine, as opposed to the FSF trying to "infect" everything it touches. So, here's the idea I had: Combine the existing CM3 (and/or PM3) front-end, and modify it to emit LLVM bytecodes, so that we could use the LLVM back-end and infrastructure to create a complete compiler/linker. Would such a beast, by combining code from both licenses, be viable? I would like to keep the licensing as liberal as possible. I sure would like your ideas on this subject, P.S.: Olaf, I think your suggestion of documenting the existing intermidiate representation of the CM3 compiler would be an absolute first step. -- Louis Chr?tien lchretien at mac.com From jay.krell at cornell.edu Sat Aug 22 12:34:29 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Sat, 22 Aug 2009 05:34:29 -0500 Subject: [M3devel] config init problem In-Reply-To: <20090822011649.81l7rnebgg8884k4@mail.elegosoft.com> References: <20090822011649.81l7rnebgg8884k4@mail.elegosoft.com> Message-ID: Ignoring errors is very common and usually wrong. Better to have a system terminate than keep running in an unknown state.. "exceptions are better than error return codes" because they have the proper default -- to propagate -- but 1 they still lead to many bugs because lazy programmers still do play along in the escalating game and put in extra code to do the wrong thing and eat exceptions 2 disciplined C programmers know that almost anything can fail and can spot missing error checks at a glance. To wit even simple integer arithmetic can overflow. Look at the intsafe.h header on windows for what to do about that. - Jay (phone) On Aug 21, 2009, at 6:16 PM, Olaf Wagner wrote: > In MxConfig.m3 quake runtime exception were ignored and thrown away > in EvalConfig. Writing them to stderr, we get the following output > for a simple cm3.cfg file: > > % cat ~/cm3-rc3/bin/cm3.cfg > > %INSTALL_ROOT = "/ad0e/home/wagner/cm3-rc3" > INSTALL_ROOT = path() & SL & ".." > > include(path() & "/config/FreeBSD4") > > luthien [~/work/cm3] wagner > % cm3 -trace -version > Critical Mass Modula-3 version p5.8.3 > last updated: 2009-08-10 > compiled: 2009-08-21 22:59:34 > configuration: /ad0e/home/wagner/cm3-rc3/bin/cm3.cfg > host: FreeBSD4 > ****** /ad0e/home/wagner/cm3-rc3/bin/cm3.cfg ****** > .0 SetLine 1 > .1 SetLine 3 > .2 LoadVar (193) "path" > .3 StartCall > .4 CallFunc 0 > .5 LoadVar (373) "SL" > quake runtime error: "/ad0e/home/wagner/cm3-rc3/bin/cm3.cfg", line > 3: quake runtime error: undefined variable: SL > > --procedure-- -line- -file--- > 3 /ad0e/home/wagner/cm3-rc3/bin/cm3.cfg > target: > > SL gets defined in M3Build.m3 in cm3, along with all the other > builtins that the compiler may use (and the config file author). > Of course MxConfig in package m3quake does not know about these, > as it creates its own quake machine on the fly. > > So configuration evaluation won't work in general currently, > unless only standard quake functions and definitions are used. > > Any ideas? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ > any > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be > rlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > From hendrik at topoi.pooq.com Sat Aug 22 13:38:26 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sat, 22 Aug 2009 07:38:26 -0400 Subject: [M3devel] A more precise question about M3 licensing... In-Reply-To: References: Message-ID: <20090822113826.GC7643@topoi.pooq.com> On Fri, Aug 21, 2009 at 02:35:03PM -0400, Louis Chr?tien wrote: > >From what I gathered so far on this thread, the SRC licence was quite a bit > more liberal than the FSF license, which led to this "separate process" > business for the code generation phase, which displeased the FSF somewhat.. The SRC licence specified that if any of this code, whether the original SRC code or other peoples' modifications or additions, ever got back to SRC, they could do anything they wanted with it. This means that if you add code to the M3 system, you have to allow SRC to do anything they want to it. This clause is incompatible with the GPL, which restricts the freedom to distribute binary code without source. Existing GPL'd code can therefore not be incorporated into the Modula 3 system because SRC would not have the freedom to do anything they want with it. -- hendrik From hendrik at topoi.pooq.com Sat Aug 22 13:40:55 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sat, 22 Aug 2009 07:40:55 -0400 Subject: [M3devel] A more precise question about M3 licensing... In-Reply-To: References: Message-ID: <20090822114055.GD7643@topoi.pooq.com> On Fri, Aug 21, 2009 at 05:40:27PM -0400, Louis Chr?tien wrote: > (Real sorry about this, I don't know why it keeps being truncated...) > > >From what I gathered so far on this thread, the SRC licence was quite a bit > more liberal than the FSF license, which led to this "separate process" > business for the code generation phase, which displeased the FSF somewhat. > ;-) > > After having read the licence for the LLVM project (a one pager on their > website), i find it quite liberal and you can basically do anything with the > code, as long as you give proper credit and keep the license with the files So is the licence for C--, which I believe says simply "This software can be used by anyone for any purpose". -- hendrik From jay.krell at cornell.edu Sat Aug 22 13:41:31 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Sat, 22 Aug 2009 06:41:31 -0500 Subject: [M3devel] config init problem In-Reply-To: <20090822114544.i2wwhjp1wsgwws0c@mail.elegosoft.com> References: <20090822011649.81l7rnebgg8884k4@mail.elegosoft.com> <20090822114544.i2wwhjp1wsgwws0c@mail.elegosoft.com> Message-ID: <2190F957-A6DE-426A-9159-8E498373F140@hotmail.com> Most config file readers need very little -- the paths and target. I think we can probably get by with very little change. I don't think we need worry much about all the functions in cm3 but not m3quake. I dare suggest a small library instead if quake that parses command line for target, defaults it to host, maybe checks $cm3_path, searches $path to decide the paths. A wrinkle is like profiling twiddling build_dir. Has that ever worked in reactor?? - Jay (phone) On Aug 22, 2009, at 4:45 AM, Olaf Wagner wrote: > Quoting Jay K : > >> In the top of cm3.cfg put >> if not defined("SL") SL = "/" >> and/or just hardcode forward slash -- it works on Windows. >> >> There is already similar in a few places. >> Look at cminstall/src/config-no-install/cm3.cfg. > > I'm not really comfortable with this solution. And I don't think > you are ;-) It's just a workaround for SL, but doesn't deal with the > other several dozens of definitions whiche _might_ be used in the > config scripts. > >> This is why m3tohtml and such were crashing, but I dealt with them. >> I thought. Again, see the cm3.cfg and cm3cfg.common, etc. > > If the exception wouldn't have been silently ignored in MxConfig.m3, > that should have been easy to diagnose. We probably need to build > some kind of quality-check tool for M3, which warns about such > coding, or should review our changes more often and better. Alas, > I'm afraid that won't happen because nobody has enougth time :-( > > Or perhpas just add a warning to the compiler if a caught exception > is just thrown away? > >> I have a proposal for next release that the predefines that cm3 does >> be made available to all quake clients via some new function. > > We could of course pass down the correctly initialized QM in cm3 > (M3Build -> Makefile -> MxConfig). That would fix the problem for > cm3, but not for other clients, unless we make them depend on most > of the build functions. The latter seems rather unnecessary and > inconvenient if only some simple definitions like TARGET are needed. > Perhaps we need to distinguish between two kinds of config files: > one level for simple clients which may only contain assignments > and basic quake functions from m3quake, and more complex > initialization > for cm3. > > I agree we should probably not make such changes in the release branch > now and postpone them. > > Olaf > >>> Date: Sat, 22 Aug 2009 01:16:49 +0200 >>> From: wagner at elegosoft.com >>> To: m3devel at elegosoft.com >>> Subject: [M3devel] config init problem >>> >>> In MxConfig.m3 quake runtime exception were ignored and thrown away >>> in EvalConfig. Writing them to stderr, we get the following output >>> for a simple cm3.cfg file: >>> >>> % cat ~/cm3-rc3/bin/cm3.cfg >>> >>> %INSTALL_ROOT = "/ad0e/home/wagner/cm3-rc3" >>> INSTALL_ROOT = path() & SL & ".." >>> >>> include(path() & "/config/FreeBSD4") >>> >>> luthien [~/work/cm3] wagner >>> % cm3 -trace -version >>> Critical Mass Modula-3 version p5.8.3 >>> last updated: 2009-08-10 >>> compiled: 2009-08-21 22:59:34 >>> configuration: /ad0e/home/wagner/cm3-rc3/bin/cm3.cfg >>> host: FreeBSD4 >>> ****** /ad0e/home/wagner/cm3-rc3/bin/cm3.cfg ****** >>> .0 SetLine 1 >>> .1 SetLine 3 >>> .2 LoadVar (193) "path" >>> .3 StartCall >>> .4 CallFunc 0 >>> .5 LoadVar (373) "SL" >>> quake runtime error: "/ad0e/home/wagner/cm3-rc3/bin/cm3.cfg", line >>> 3: >>> quake runtime error: undefined variable: SL >>> >>> --procedure-- -line- -file--- >>> 3 /ad0e/home/wagner/cm3-rc3/bin/cm3.cfg >>> target: >>> >>> SL gets defined in M3Build.m3 in cm3, along with all the other >>> builtins that the compiler may use (and the config file author). >>> Of course MxConfig in package m3quake does not know about these, >>> as it creates its own quake machine on the fly. >>> >>> So configuration evaluation won't work in general currently, >>> unless only standard quake functions and definitions are used. >>> >>> Any ideas? > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ > any > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be > rlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > From rodney.m.bates at cox.net Sat Aug 22 21:17:46 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Sat, 22 Aug 2009 14:17:46 -0500 Subject: [M3devel] A question about the M3 licensing... In-Reply-To: <20090821102056.nbcql8hsc8ww80cc@mail.elegosoft.com> References: <20090820234825.GB3925@topoi.pooq.com> <20090821102056.nbcql8hsc8ww80cc@mail.elegosoft.com> Message-ID: <4A90445A.9070201@cox.net> Olaf Wagner wrote: > Quoting hendrik at topoi.pooq.com: > >> I suppose there's another possibility -- writing a new M3 front end with >> a different licence, and being free of SRC forever. Except that if >> some of our libraries are compiled from SRC source code, will we have to >> compile at installation tiem to avould distributing mixed GNU/SRC >> binaries? > > I don't think this is correct. The SRC license allows much more than > the GNU FSF license. That was exactly the stumbling block when it came > to integrating the M3 extensions to gcc into the gcc distribution. > The FSF didn't like the way the backend was used in a different process > context in order to avoid infecting all compiler code with the FSF > license. > > Of course you can write another compiler front-end under the FSF > license. I'd assume this will take several man-years though until > you reach the quality of the current system. And any commercial use > will then be much more difficult, but this is probably moot > regarding the current widespread user base :-) This could be very hard to pull off, or maybe not so hard, but I think the best result would be if HP, as SRC's successor, could be persuaded to assign copyright ownership to FSF, or maybe even some other entity, such as a nonprofit foundation or something. I can't think how keeping it themselves would have any business value to HP, and anything to get it more widely used might have positive value to them. Of course, it would be complicated by the fact that there are some files around with a half-dozen or so other copyright owners and licenses. > > Olaf From wagner at elegosoft.com Sun Aug 23 01:51:25 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 23 Aug 2009 01:51:25 +0200 Subject: [M3devel] CM3 Release 5.8 RC3 Message-ID: <20090823015125.e1mq5xiogc4gkkw8@mail.elegosoft.com> The first packages of CM3 release 5.8 RC3 are now available on www.opencm3.net. More packages will be built during the next days. As there are still 11 open tickets for 5.8 and more are to be expected when RC3 is tested by more users, I've also retargeted the date for the final release to the end of September. Please let me know of any problems you encounter and features that you are missing. The best way of doing this is opening a ticket at https://projects.elego.de/cm3/newticket. Thanks for your support and cooperation, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Sun Aug 23 06:43:44 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 23 Aug 2009 00:43:44 -0400 Subject: [M3devel] A question about the M3 licensing... In-Reply-To: <4A90445A.9070201@cox.net> References: <20090820234825.GB3925@topoi.pooq.com> <20090821102056.nbcql8hsc8ww80cc@mail.elegosoft.com> <4A90445A.9070201@cox.net> Message-ID: <20090823044343.GA9202@topoi.pooq.com> On Sat, Aug 22, 2009 at 02:17:46PM -0500, Rodney M. Bates wrote: > Olaf Wagner wrote: > >Quoting hendrik at topoi.pooq.com: > > > >>I suppose there's another possibility -- writing a new M3 front end with > >>a different licence, and being free of SRC forever. Except that if > >>some of our libraries are compiled from SRC source code, will we have to > >>compile at installation tiem to avould distributing mixed GNU/SRC > >>binaries? > > > >I don't think this is correct. The SRC license allows much more than > >the GNU FSF license. That was exactly the stumbling block when it came > >to integrating the M3 extensions to gcc into the gcc distribution. > >The FSF didn't like the way the backend was used in a different process > >context in order to avoid infecting all compiler code with the FSF > >license. > > > >Of course you can write another compiler front-end under the FSF > >license. I'd assume this will take several man-years though until > >you reach the quality of the current system. And any commercial use > >will then be much more difficult, but this is probably moot > >regarding the current widespread user base :-) > > This could be very hard to pull off, or maybe not so hard, but I think > the best result would be if HP, as SRC's successor, could be persuaded > to assign copyright ownership to FSF, or maybe even some other > entity, such as a nonprofit foundation or something. I can't think how > keeping it themselves would have any business value to HP, and > anything to get it more widely used might have positive value to them. > > Of course, it would be complicated by the fact that there are some > files around with a half-dozen or so other copyright owners and > licenses. But liberating the SRC stuff would handle most of it. And I're recommend a licence that is strictly more liberal than FSF's. Perhaps something like the MIT license, or BSD. They're compatible with GPL, and we may end up having fewer problems in the far future. We might someday, for example, have users needing to link proprietary code with parts of the compiler, and it would be good for that to be possible. - hendrik From jay.krell at cornell.edu Sun Aug 23 07:41:45 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 23 Aug 2009 05:41:45 +0000 Subject: [M3devel] http://www.opencm3.net/ Message-ID: http://www.opencm3.net/ is now remarkably bad. Besides the low contrast high frequency mix of greens and blues, there is also a double nesting of frames by default. - Jay From jay.krell at cornell.edu Sun Aug 23 07:52:36 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 23 Aug 2009 05:52:36 +0000 Subject: [M3devel] more web site problems Message-ID: http://www.opencm3.net/releng/collection-core.html has various README links. I'm certain many are not useful (like under gcc) and I'm not certain if any would be, but asis they all give access denied. "platform-specific library imports for Windows systems" is bogus. They are called "import libraries", not "library imports". The Description is obviously wrong. Maybe that is a placeholder? Or not expanded? The Dependencies look funny but maybe as intended? Or maybe this is a unique output of having no dependencies? Actually they look quite good for other package collections, to provide all that data. I can't tell if only immediately dependent package collections are listed or transitive. The access denied on README isn't unique to core. http://www.opencm3.net/releng/collection-database.html http://www.opencm3.net/releng/collection-cvsup.html contains broken link to "manual page cvpasswd". http://www.opencm3.net/releng/collection-devlib.html README access denied - Jay From jay.krell at cornell.edu Sun Aug 23 08:17:41 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 23 Aug 2009 06:17:41 +0000 Subject: [M3devel] DoRootExport vs. DoRootdExport? Message-ID: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/cm3/src/M3Build.m3?r1=1.28.2.1&r2=1.28.2.2 "d" is or derived, and therefore there is a missing edit after the copy/paste? - Jay From jay.krell at cornell.edu Sun Aug 23 08:26:34 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 23 Aug 2009 06:26:34 +0000 Subject: [M3devel] Posix/Win32 linger options inverted? Message-ID: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-comm/tcp/src/POSIX/TCP.m3?rev=1.7;content-type=text%2Fplain vs. http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-comm/tcp/src/WIN32/TCP.m3?rev=1.3;content-type=text%2Fplain search for linger: PROCEDURE InitFD(fd: CARDINAL) = (* We assume that the runtime ignores SIGPIPE signals *) VAR one: int := 1; linger := Usocket.struct_linger{1, 1}; vs. PROCEDURE InitSock(sock: WinSock.SOCKET) = (* We assume that the runtime ignores SIGPIPE signals *) VAR one : BOOL := 1; linger := WinSock.struct_linger{0, 0}; Surely they can't both be correct. Which is correct? The Posix one? - Jay From jay.krell at cornell.edu Sun Aug 23 09:28:42 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 23 Aug 2009 07:28:42 +0000 Subject: [M3devel] sin_len? Message-ID: I'm looking to - remove the platform dependency defining struct_sockaddr_in - provide a platform independent struct_sockaddr_un What is the deal with the sin_len field? We never fill it in? It is difficult to find documentation as to the meaning of the field. There is this: http://lists.samba.org/archive/rsync/2002-February/001531.html But I believe we have always just left it as zero and I will probably do that. I believe the historical practise here is out of date with IPv6 around, as well. - Jay From jay.krell at cornell.edu Sun Aug 23 10:11:42 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 23 Aug 2009 08:11:42 +0000 Subject: [M3devel] sin_len? In-Reply-To: References: Message-ID: I was going to convert from a portable idealized form of struct_sockaddr_in/un, but I could only support AF_INET and AF_LOCAL/UNIX, and there are many others, so this isn't really viable. Instead I'll strive for the current approach of duplicating the headers reliably, in this small case. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Sun, 23 Aug 2009 07:28:42 +0000 > Subject: [M3devel] sin_len? > > > I'm looking to > - remove the platform dependency defining struct_sockaddr_in > - provide a platform independent struct_sockaddr_un > > What is the deal with the sin_len field? > We never fill it in? > It is difficult to find documentation as to the meaning of the field. > > There is this: > > http://lists.samba.org/archive/rsync/2002-February/001531.html > > But I believe we have always just left it as zero and I will probably do that. > > > I believe the historical practise here is out of date with IPv6 around, as well. > > - Jay From dragisha at m3w.org Sun Aug 23 10:47:57 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 23 Aug 2009 10:47:57 +0200 Subject: [M3devel] New Socket.[im]3? was: Re: sin_len? In-Reply-To: References: Message-ID: <1251017277.30939.31.camel@faramir.m3w.org> There were once (and still is, but not only ones for IPv4) different APIs for TCP and UDP. cmass people unified that in Socket.i3 API, but only for IPv4... What we really need here is even more general Socket.i3, covering AF_UNIX and IPv6... To accomplish this, we have to generalize (OO-ize :) ) Socket.EndPoint to include IPv4/IPv6/AF_UNIX (whatever it's called on Windows, named pipe or...) addresses so Socket(Posix|WIN32).m3 can decide about how to progress through related operations. Good news - Socket interface is unused from current cm3 source tree. Bad news - we don't know about other clients to it. Good news - this is Modula-3 and such changes are easy do detect and easier to change. Thus said... This is probably nothing for 5.8 to care about. If others agreee, and nobody does it, I can find some time in following months to unify work I already have done for AF_UNIX and also to cook what is needed for IPv6 (not much I believe). And of course there's always a "but". What will we do about SCTP? On Sun, 2009-08-23 at 08:11 +0000, Jay K wrote: > I was going to convert from a portable idealized form of struct_sockaddr_in/un, but I could only support AF_INET and AF_LOCAL/UNIX, and there are many others, so this isn't really viable. Instead I'll strive for the current approach of duplicating the headers reliably, in this small case. > > - Jay > > > > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: m3devel at elegosoft.com > > Date: Sun, 23 Aug 2009 07:28:42 +0000 > > Subject: [M3devel] sin_len? > > > > > > I'm looking to > > - remove the platform dependency defining struct_sockaddr_in > > - provide a platform independent struct_sockaddr_un > > > > What is the deal with the sin_len field? > > We never fill it in? > > It is difficult to find documentation as to the meaning of the field. > > > > There is this: > > > > http://lists.samba.org/archive/rsync/2002-February/001531.html > > > > But I believe we have always just left it as zero and I will probably do that. > > > > > > I believe the historical practise here is out of date with IPv6 around, as well. > > > > - Jay -- Dragi?a Duri? From wagner at elegosoft.com Sun Aug 23 12:52:49 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 23 Aug 2009 12:52:49 +0200 Subject: [M3devel] more web site problems In-Reply-To: References: Message-ID: <20090823125249.cc7q0zjwxwcoo84g@mail.elegosoft.com> Quoting Jay K : > http://www.opencm3.net/releng/collection-core.html > > has various README links. > I'm certain many are not useful (like under gcc) and I'm not certain if > any would be, but asis they all give access denied. All README links should now be fixed. I had renamed the workspace and forgot to adapt the link. > "platform-specific library imports for Windows systems" > is bogus. They are called "import libraries", not > "library imports". All package descriptions are in the DESC files. I've fixed this one now. Feel free to improve further. HTML needs to be regenerated now. I'll do that soon. > The Description is obviously wrong. > Maybe that is a placeholder? > Or not expanded? > The Dependencies look funny but maybe as intended? > Or maybe this is a unique output of having no dependencies? > Actually they look quite good for other package collections, > to provide all that data. I can't tell if only > immediately dependent package collections are listed > or transitive. It's just the output of my scripts that compute the dependencies. I haven't had put any efforts into making it beautiful. I thought it would be easily understandable, but that's probably wrong ;-) > The access denied on README isn't unique to core. > http://www.opencm3.net/releng/collection-database.html > > http://www.opencm3.net/releng/collection-cvsup.html > contains broken link to "manual page cvpasswd". That's the result of your putting overrides into the CVSup m3makefiles. Now nothing gets shipped. Probably all the CVSup packages are broken in this respect. Overrides should only be in m3override files and be activated with the -override option. > http://www.opencm3.net/releng/collection-devlib.html > README access denied Thanks for the comments, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Sun Aug 23 13:00:19 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 23 Aug 2009 13:00:19 +0200 Subject: [M3devel] DoRootExport vs. DoRootdExport? In-Reply-To: References: Message-ID: <20090823130019.yucefnpwe8cksgkw@mail.elegosoft.com> Quoting Jay K : > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/cm3/src/M3Build.m3?r1=1.28.2.1&r2=1.28.2.2 > > "d" is or derived, and therefore there is a missing edit after the > copy/paste? Yes, that's wrong. Should be no problem for RC3 though. Fixed in the branch, tag not moved. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Sun Aug 23 13:06:44 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 23 Aug 2009 13:06:44 +0200 Subject: [M3devel] New Socket.[im]3? was: Re: sin_len? In-Reply-To: <1251017277.30939.31.camel@faramir.m3w.org> References: <1251017277.30939.31.camel@faramir.m3w.org> Message-ID: <20090823130644.c3rv6u1dcs0wookk@mail.elegosoft.com> Quoting Dragi?a Duri? : > There were once (and still is, but not only ones for IPv4) different > APIs for TCP and UDP. cmass people unified that in Socket.i3 API, but > only for IPv4... What we really need here is even more general > Socket.i3, covering AF_UNIX and IPv6... > > To accomplish this, we have to generalize (OO-ize :) ) Socket.EndPoint > to include IPv4/IPv6/AF_UNIX (whatever it's called on Windows, named > pipe or...) addresses so Socket(Posix|WIN32).m3 can decide about how to > progress through related operations. > > Good news - Socket interface is unused from current cm3 source tree. Bad > news - we don't know about other clients to it. Good news - this is > Modula-3 and such changes are easy do detect and easier to change. > > Thus said... This is probably nothing for 5.8 to care about. If others > agreee, and nobody does it, I can find some time in following months to > unify work I already have done for AF_UNIX and also to cook what is > needed for IPv6 (not much I believe). > > And of course there's always a "but". What will we do about SCTP? This is definitely nothing for the release. There are still enough problems without refactoring network layers. I'd really appreciate it if you or somebody else takes care of it though. IPv6 has been on my wishlist for M3 for years, too. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Sun Aug 23 18:31:38 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 23 Aug 2009 18:31:38 +0200 Subject: [M3devel] New Socket.[im]3? was: Re: sin_len? In-Reply-To: <20090823130644.c3rv6u1dcs0wookk@mail.elegosoft.com> References: <1251017277.30939.31.camel@faramir.m3w.org> <20090823130644.c3rv6u1dcs0wookk@mail.elegosoft.com> Message-ID: <1251045098.30939.36.camel@faramir.m3w.org> IPv6 is a plaything right now... I've had setup for it on few machines, but it did not last... Though it's not a hassle to make LAN setup... I'll look through this, and esp unifying interface for IPv4/IPv6/(AF_UNIX|named pipes). On Sun, 2009-08-23 at 13:06 +0200, Olaf Wagner wrote: > This is definitely nothing for the release. There are still enough > problems without refactoring network layers. > > I'd really appreciate it if you or somebody else takes care of it > though. > > IPv6 has been on my wishlist for M3 for years, too. -- Dragi?a Duri? From hendrik at topoi.pooq.com Mon Aug 24 02:56:58 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 23 Aug 2009 20:56:58 -0400 Subject: [M3devel] trying RC3 Message-ID: <20090824005658.GA11486@topoi.pooq.com> Well, core and gui installed flaelessly on a Debian lenny system. But cvsup ended with the message: package was built with overrides, not shipping. Now maybe that's correct behaviour, but It doesn't look like it. Here are the details: hendrik at lovesong:~/cm3/ia32/RC3$ mkdir cvsup hendrik at lovesong:~/cm3/ia32/RC3$ cd cvsup hendrik at lovesong:~/cm3/ia32/RC3/cvsup$ tar -zxf ../../../dn/cm3-bin-ws-cvsup-LINUXLIBC6-5.8.3-RC3.tgz hendrik at lovesong:~/cm3/ia32/RC3/cvsup$ ls collection-cvsup.html install.sh m3-tools setup.cmd hendrik at lovesong:~/cm3/ia32/RC3/cvsup$ ./install.sh installing package m3-tools/cvsup/suplib --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/suplib/LINUXLIBC6 .M3EXPORTS . => /usr/local/cm3/lib libsuplib.so.5 . => /usr/local/cm3/pkg/suplib/LINUXLIBC6 libsuplib.a libsuplib.m3x .M3WEB ../LINUXLIBC6 => /usr/local/cm3/pkg/suplib/LINUXLIBC6 ExecRecSeq.i3 ExecRecSeq.m3 DirEntryList.i3 DirEntryList.m3 DirEntryListSort.i3 DirEntryListSort.m3 TextGlobTreeTbl.i3 TextGlobTreeTbl.m3 ExecRecSeqRep.i3 RCSAccessList.i3 RCSAccessList.m3 RCSTagList.i3 RCSTagList.m3 RCSTagListSort.i3 RCSTagListSort.m3 RCSEditTbl.i3 RCSEditTbl.m3 SortedRCSEditTbl.i3 SortedRCSEditTbl.m3 RCSDeltaList.i3 RCSDeltaList.m3 RCSDeltaListSort.i3 RCSDeltaListSort.m3 RCSDeltaTbl.i3 RCSDeltaTbl.m3 SortedRCSDeltaTbl.i3 SortedRCSDeltaTbl.m3 RsyncBlockArraySort.i3 RsyncBlockArraySort.m3 ../src => /usr/local/cm3/pkg/suplib/src RegEx.i3 RegEx.m3 Merger.ig Merger.mg merger.tmpl CText.i3 Uglob.i3 PathComp.i3 PathComp.m3 ChannelMux.m3 ChannelMux.i3 Logger.i3 Logger.m3 LoggerClass.i3 SplitLogger.i3 SplitLogger.m3 SysLogger.i3 SysLogger.m3 TimeStampLogger.i3 TimeStampLogger.m3 WrLogger.i3 WrLogger.m3 ProcTitle.i3 Ugzip.i3 Ugzip.m3 UgzipP.i3 Umd5.i3 MySyslog.i3 WatchDog.i3 WatchDog.m3 IOWatchDog.i3 IOWatchDog.m3 MD5Digest.i3 MD5Digest.m3 MD5.m3 MD5.i3 AuthMD5.m3 AuthMD5.i3 TokScan.m3 TokScan.i3 DevT.i3 FileAttr.i3 FileAttr.m3 FileAttrRep.i3 FileID.m3 FileID.i3 CVProto.m3 CVProto.i3 EscapedRd.i3 EscapedRd.m3 EscapedWr.i3 EscapedWr.m3 MD5Wr.i3 MD5Wr.m3 ErrMsg.i3 ErrMsg.m3 DirEntry.i3 DirEntry.m3 Glob.m3 Glob.i3 GlobTree.i3 GlobTree.m3 LockFile.m3 LockFile.i3 ExecRec.i3 RCSError.i3 RCSString.m3 RCSString.i3 RCSPhrase.i3 RCSPhrase.m3 RCSPhrases.i3 RCSPhrases.m3 RCSDate.m3 RCSDate.i3 RCSRevNum.i3 RCSRevNum.m3 RCSAccess.m3 RCSAccess.i3 RCSTag.i3 RCSTag.m3 RCSEdit.i3 RCSDelta.m3 RCSDelta.i3 RCSDeltaClass.i3 RCSKeyword.m3 RCSKeyword.i3 RCSFile.i3 RCSFile.m3 SupFileRec.i3 SupFileRec.m3 SupMisc.i3 SupMisc.m3 FileStatus.m3 FileStatus.i3 FileStatusRaw.i3 StatusFile.i3 StatusFile.m3 CVTree.m3 CVTree.i3 GzipError.m3 GzipError.i3 GzipRd.i3 GzipRd.m3 GzipWr.i3 GzipWr.m3 RsyncBlock.m3 RsyncBlock.i3 RsyncFile.m3 RsyncFile.i3 Reaper.i3 Reaper.m3 SigHandler.m3 SigHandler.i3 UnixMisc.m3 UnixMisc.i3 UnixMiscC.c Attic.i3 Attic.m3 ../src/POSIX => /usr/local/cm3/pkg/suplib/src/POSIX ProcTitle.m3 FileAttrOS.m3 ../src/libmd => /usr/local/cm3/pkg/suplib/src/libmd md5c.c md5hl.c ../src/libglob => /usr/local/cm3/pkg/suplib/src/libglob fnmatch.c ../src/dev_t_posix => /usr/local/cm3/pkg/suplib/src/dev_t_posix DevT.m3 ../src/text_cm3 => /usr/local/cm3/pkg/suplib/src/text_cm3 CText.m3 SupMiscText.m3 installing package m3-tools/cvsup/client --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/client/LINUXLIBC6 .M3EXPORTS .M3WEB ../LINUXLIBC6 => /usr/local/cm3/pkg/client/LINUXLIBC6 Version.m3 SupGUIBundle.i3 SupGUIBundle.m3 FixupSeq.i3 FixupSeq.m3 FixupSeqRep.i3 SyncFixupQueue.i3 SyncFixupQueue.m3 SupFileRecSeq.m3 SupFileRecSeq.i3 SupFileRecSeqRep.i3 FileAttrSeq.i3 FileAttrSeq.m3 FileAttrSeqRep.i3 ../src => /usr/local/cm3/pkg/client/src Version.i3 SyncQueue.mg SyncQueue.ig syncqueue.tmpl Fixup.i3 Auth.m3 Auth.i3 SupFile.i3 SupFile.m3 Receive.i3 Receive.m3 FileUpdater.i3 FileUpdater.m3 CheckoutCreator.i3 CheckoutCreator.m3 CheckoutUpdater.i3 CheckoutUpdater.m3 RCSUpdater.m3 RCSUpdater.i3 RegularCreator.i3 RegularCreator.m3 RegularUpdater.i3 RegularUpdater.m3 RsyncUpdater.i3 RsyncUpdater.m3 TreeList.i3 TreeList.m3 Detailer.i3 Detailer.m3 Updater.i3 Updater.m3 FSClient.m3 FSClient.i3 SupGUI.i3 SupGUI.m3 EventSync.i3 EventSync.m3 TextPortLogger.m3 TextPortLogger.i3 TextVBTLogger.i3 TextVBTLogger.m3 BackoffTimer.i3 BackoffTimer.m3 Main.m3 . => /usr/local/cm3/bin cvsup . => /usr/local/cm3/man/man1 cvsup.1 installing package m3-tools/cvsup/server --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/server/LINUXLIBC6 .M3EXPORTS .M3WEB ../LINUXLIBC6 => /usr/local/cm3/pkg/server/LINUXLIBC6 Version.m3 FileInfoMerger.i3 FileInfoMerger.m3 LinkTbl.m3 LinkTbl.i3 RCSDeltaMerger.m3 RCSDeltaMerger.i3 RCSTagMerger.i3 RCSTagMerger.m3 SupFileRecSeq.m3 SupFileRecSeq.i3 SupFileRecSeqRep.i3 FileAttrSeq.i3 FileAttrSeq.m3 FileAttrSeqRep.i3 ParsedDeltaList.i3 ParsedDeltaList.m3 ../src => /usr/local/cm3/pkg/server/src Version.i3 FileInfo.m3 FileInfo.i3 ParsedDelta.m3 ParsedDelta.i3 AccessRules.i3 AccessRules.m3 Passwd.i3 Passwd.m3 ClientClass.i3 ClientClass.m3 ClassDB.m3 ClassDB.i3 RCSComp.i3 RCSComp.m3 TreeComp.i3 TreeComp.m3 FSServer.m3 FSServer.i3 FSServerRep.i3 FSServerU.m3 Main.m3 . => /usr/local/cm3/bin cvsupd . => /usr/local/cm3/man/man8 cvsupd.8 . => /usr/local/cm3/man/man5 cvsupd.class.5 installing package m3-tools/cvsup/cvpasswd --- shipping from LINUXLIBC6 --- package was built with overrides, not shipping. hendrik at lovesong:~/cm3/ia32/RC3/cvsup$ ls -- hendrik From jay.krell at cornell.edu Mon Aug 24 03:05:17 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 24 Aug 2009 01:05:17 +0000 Subject: [M3devel] more web site problems In-Reply-To: <20090823125249.cc7q0zjwxwcoo84g@mail.elegosoft.com> References: <20090823125249.cc7q0zjwxwcoo84g@mail.elegosoft.com> Message-ID: > That's the result of your putting overrides into the CVSup I don't think it was me though I should have noticed it in the initial version. - Jay ---------------------------------------- > Date: Sun, 23 Aug 2009 12:52:49 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: more web site problems > > Quoting Jay K : > >> http://www.opencm3.net/releng/collection-core.html >> >> has various README links. >> I'm certain many are not useful (like under gcc) and I'm not certain if >> any would be, but asis they all give access denied. > > All README links should now be fixed. I had renamed the workspace > and forgot to adapt the link. > >> "platform-specific library imports for Windows systems" >> is bogus. They are called "import libraries", not >> "library imports". > > All package descriptions are in the DESC files. I've fixed this one > now. Feel free to improve further. > > HTML needs to be regenerated now. I'll do that soon. > >> The Description is obviously wrong. >> Maybe that is a placeholder? >> Or not expanded? > > >> The Dependencies look funny but maybe as intended? >> Or maybe this is a unique output of having no dependencies? >> Actually they look quite good for other package collections, >> to provide all that data. I can't tell if only >> immediately dependent package collections are listed >> or transitive. > > It's just the output of my scripts that compute the dependencies. > I haven't had put any efforts into making it beautiful. I thought > it would be easily understandable, but that's probably wrong ;-) > >> The access denied on README isn't unique to core. >> http://www.opencm3.net/releng/collection-database.html >> >> http://www.opencm3.net/releng/collection-cvsup.html >> contains broken link to "manual page cvpasswd". > > That's the result of your putting overrides into the CVSup > m3makefiles. Now nothing gets shipped. Probably all the CVSup > packages are broken in this respect. Overrides should only be > in m3override files and be activated with the -override option. > >> http://www.opencm3.net/releng/collection-devlib.html >> README access denied > > Thanks for the comments, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Mon Aug 24 03:07:25 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 24 Aug 2009 01:07:25 +0000 Subject: [M3devel] trying RC3 In-Reply-To: <20090824005658.GA11486@topoi.pooq.com> References: <20090824005658.GA11486@topoi.pooq.com> Message-ID: This is understood and fixed, specific to cvsup. Thanks, - Jay ---------------------------------------- > Date: Sun, 23 Aug 2009 20:56:58 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: [M3devel] trying RC3 > > Well, core and gui installed flaelessly on a Debian lenny system. > > But cvsup ended with the message: > > package was built with overrides, not shipping. > > Now maybe that's correct behaviour, but It doesn't look like it. > > Here are the details: > > hendrik at lovesong:~/cm3/ia32/RC3$ mkdir cvsup > hendrik at lovesong:~/cm3/ia32/RC3$ cd cvsup > hendrik at lovesong:~/cm3/ia32/RC3/cvsup$ tar -zxf > ../../../dn/cm3-bin-ws-cvsup-LINUXLIBC6-5.8.3-RC3.tgz > hendrik at lovesong:~/cm3/ia32/RC3/cvsup$ ls > collection-cvsup.html install.sh m3-tools setup.cmd > hendrik at lovesong:~/cm3/ia32/RC3/cvsup$ ./install.sh > installing package m3-tools/cvsup/suplib > --- shipping from LINUXLIBC6 --- > > . => /usr/local/cm3/pkg/suplib/LINUXLIBC6 > .M3EXPORTS > . => /usr/local/cm3/lib > libsuplib.so.5 > . => /usr/local/cm3/pkg/suplib/LINUXLIBC6 > libsuplib.a libsuplib.m3x .M3WEB > ../LINUXLIBC6 => /usr/local/cm3/pkg/suplib/LINUXLIBC6 > ExecRecSeq.i3 ExecRecSeq.m3 DirEntryList.i3 DirEntryList.m3 > DirEntryListSort.i3 DirEntryListSort.m3 TextGlobTreeTbl.i3 > TextGlobTreeTbl.m3 ExecRecSeqRep.i3 RCSAccessList.i3 > RCSAccessList.m3 > RCSTagList.i3 RCSTagList.m3 RCSTagListSort.i3 > RCSTagListSort.m3 > RCSEditTbl.i3 RCSEditTbl.m3 SortedRCSEditTbl.i3 > SortedRCSEditTbl.m3 RCSDeltaList.i3 RCSDeltaList.m3 > RCSDeltaListSort.i3 RCSDeltaListSort.m3 RCSDeltaTbl.i3 > RCSDeltaTbl.m3 SortedRCSDeltaTbl.i3 SortedRCSDeltaTbl.m3 > RsyncBlockArraySort.i3 RsyncBlockArraySort.m3 > ../src => /usr/local/cm3/pkg/suplib/src > RegEx.i3 RegEx.m3 Merger.ig Merger.mg > merger.tmpl CText.i3 Uglob.i3 PathComp.i3 > PathComp.m3 ChannelMux.m3 ChannelMux.i3 Logger.i3 > Logger.m3 LoggerClass.i3 SplitLogger.i3 SplitLogger.m3 > SysLogger.i3 SysLogger.m3 TimeStampLogger.i3 > TimeStampLogger.m3 WrLogger.i3 WrLogger.m3 ProcTitle.i3 > Ugzip.i3 Ugzip.m3 UgzipP.i3 Umd5.i3 > MySyslog.i3 WatchDog.i3 WatchDog.m3 IOWatchDog.i3 > IOWatchDog.m3 MD5Digest.i3 MD5Digest.m3 MD5.m3 > MD5.i3 AuthMD5.m3 AuthMD5.i3 TokScan.m3 > TokScan.i3 DevT.i3 FileAttr.i3 FileAttr.m3 > FileAttrRep.i3 FileID.m3 FileID.i3 CVProto.m3 > CVProto.i3 EscapedRd.i3 EscapedRd.m3 EscapedWr.i3 > EscapedWr.m3 MD5Wr.i3 MD5Wr.m3 ErrMsg.i3 > ErrMsg.m3 DirEntry.i3 DirEntry.m3 Glob.m3 > Glob.i3 GlobTree.i3 GlobTree.m3 LockFile.m3 > LockFile.i3 ExecRec.i3 RCSError.i3 RCSString.m3 > RCSString.i3 RCSPhrase.i3 RCSPhrase.m3 RCSPhrases.i3 > RCSPhrases.m3 RCSDate.m3 RCSDate.i3 RCSRevNum.i3 > RCSRevNum.m3 RCSAccess.m3 RCSAccess.i3 RCSTag.i3 > RCSTag.m3 RCSEdit.i3 RCSDelta.m3 RCSDelta.i3 > RCSDeltaClass.i3 RCSKeyword.m3 RCSKeyword.i3 RCSFile.i3 > RCSFile.m3 SupFileRec.i3 SupFileRec.m3 SupMisc.i3 > SupMisc.m3 FileStatus.m3 FileStatus.i3 FileStatusRaw.i3 > StatusFile.i3 StatusFile.m3 CVTree.m3 CVTree.i3 > GzipError.m3 GzipError.i3 GzipRd.i3 GzipRd.m3 > GzipWr.i3 GzipWr.m3 RsyncBlock.m3 RsyncBlock.i3 > RsyncFile.m3 RsyncFile.i3 Reaper.i3 Reaper.m3 > SigHandler.m3 SigHandler.i3 UnixMisc.m3 UnixMisc.i3 > UnixMiscC.c Attic.i3 Attic.m3 > ../src/POSIX => /usr/local/cm3/pkg/suplib/src/POSIX > ProcTitle.m3 FileAttrOS.m3 > ../src/libmd => /usr/local/cm3/pkg/suplib/src/libmd > md5c.c md5hl.c > ../src/libglob => /usr/local/cm3/pkg/suplib/src/libglob > fnmatch.c > ../src/dev_t_posix => /usr/local/cm3/pkg/suplib/src/dev_t_posix > DevT.m3 > ../src/text_cm3 => /usr/local/cm3/pkg/suplib/src/text_cm3 > CText.m3 SupMiscText.m3 > installing package m3-tools/cvsup/client > --- shipping from LINUXLIBC6 --- > > . => /usr/local/cm3/pkg/client/LINUXLIBC6 > .M3EXPORTS .M3WEB > ../LINUXLIBC6 => /usr/local/cm3/pkg/client/LINUXLIBC6 > Version.m3 SupGUIBundle.i3 SupGUIBundle.m3 FixupSeq.i3 > FixupSeq.m3 FixupSeqRep.i3 SyncFixupQueue.i3 SyncFixupQueue.m3 > SupFileRecSeq.m3 SupFileRecSeq.i3 SupFileRecSeqRep.i3 FileAttrSeq.i3 > FileAttrSeq.m3 FileAttrSeqRep.i3 > ../src => /usr/local/cm3/pkg/client/src > Version.i3 SyncQueue.mg SyncQueue.ig syncqueue.tmpl > Fixup.i3 Auth.m3 Auth.i3 SupFile.i3 > SupFile.m3 Receive.i3 Receive.m3 FileUpdater.i3 > FileUpdater.m3 CheckoutCreator.i3 CheckoutCreator.m3 > CheckoutUpdater.i3 CheckoutUpdater.m3 RCSUpdater.m3 > RCSUpdater.i3 RegularCreator.i3 RegularCreator.m3 RegularUpdater.i3 > RegularUpdater.m3 RsyncUpdater.i3 RsyncUpdater.m3 TreeList.i3 > TreeList.m3 Detailer.i3 Detailer.m3 Updater.i3 > Updater.m3 FSClient.m3 FSClient.i3 SupGUI.i3 > SupGUI.m3 EventSync.i3 EventSync.m3 TextPortLogger.m3 > TextPortLogger.i3 TextVBTLogger.i3 TextVBTLogger.m3 BackoffTimer.i3 > BackoffTimer.m3 Main.m3 > . => /usr/local/cm3/bin > cvsup > . => /usr/local/cm3/man/man1 > cvsup.1 > installing package m3-tools/cvsup/server > --- shipping from LINUXLIBC6 --- > > . => /usr/local/cm3/pkg/server/LINUXLIBC6 > .M3EXPORTS .M3WEB > ../LINUXLIBC6 => /usr/local/cm3/pkg/server/LINUXLIBC6 > Version.m3 FileInfoMerger.i3 FileInfoMerger.m3 LinkTbl.m3 > LinkTbl.i3 RCSDeltaMerger.m3 RCSDeltaMerger.i3 RCSTagMerger.i3 > RCSTagMerger.m3 SupFileRecSeq.m3 SupFileRecSeq.i3 SupFileRecSeqRep.i3 > FileAttrSeq.i3 FileAttrSeq.m3 FileAttrSeqRep.i3 ParsedDeltaList.i3 > ParsedDeltaList.m3 > ../src => /usr/local/cm3/pkg/server/src > Version.i3 FileInfo.m3 FileInfo.i3 ParsedDelta.m3 > ParsedDelta.i3 AccessRules.i3 AccessRules.m3 Passwd.i3 > Passwd.m3 ClientClass.i3 ClientClass.m3 ClassDB.m3 > ClassDB.i3 RCSComp.i3 RCSComp.m3 TreeComp.i3 > TreeComp.m3 FSServer.m3 FSServer.i3 FSServerRep.i3 > FSServerU.m3 Main.m3 > . => /usr/local/cm3/bin > cvsupd > . => /usr/local/cm3/man/man8 > cvsupd.8 > . => /usr/local/cm3/man/man5 > cvsupd.class.5 > installing package m3-tools/cvsup/cvpasswd > --- shipping from LINUXLIBC6 --- > > package was built with overrides, not shipping. > hendrik at lovesong:~/cm3/ia32/RC3/cvsup$ ls > > > -- hendrik > From hendrik at topoi.pooq.com Mon Aug 24 03:32:45 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 23 Aug 2009 21:32:45 -0400 Subject: [M3devel] trying RC3 In-Reply-To: References: <20090824005658.GA11486@topoi.pooq.com> Message-ID: <20090824013245.GA11619@topoi.pooq.com> On Mon, Aug 24, 2009 at 01:07:25AM +0000, Jay K wrote: > > This is understood and fixed, specific to cvsup. Does 'fixed' mean you've replaced the RC3 archive, in which case I'll try it again soon, or that it'll be OK in RC4? Or just fixed in CVS? > > Thanks, > - Jay You're welcome. Each time a new RC comes out, I shunt aside my existing cm3, and try an install. Then I report on the problems, and move the working cm3 back. I'll spend some time this week testing the other ws-packages. Thanks. -- hendrik From jay.krell at cornell.edu Mon Aug 24 04:43:52 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 24 Aug 2009 02:43:52 +0000 Subject: [M3devel] trying RC3 In-Reply-To: <20090824013245.GA11619@topoi.pooq.com> References: <20090824005658.GA11486@topoi.pooq.com> <20090824013245.GA11619@topoi.pooq.com> Message-ID: In CVS. - Jay ---------------------------------------- > Date: Sun, 23 Aug 2009 21:32:45 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] trying RC3 > > On Mon, Aug 24, 2009 at 01:07:25AM +0000, Jay K wrote: >> >> This is understood and fixed, specific to cvsup. > > Does 'fixed' mean you've replaced the RC3 archive, in which case I'll > try it again soon, or that it'll be OK in RC4? > > Or just fixed in CVS? > >> >> Thanks, >> - Jay > > You're welcome. Each time a new RC comes out, I shunt aside my existing > cm3, and try an install. Then I report on the problems, and move the > working cm3 back. > > I'll spend some time this week testing the other ws-packages. > > Thanks. > > -- hendrik > From wagner at elegosoft.com Mon Aug 24 09:56:39 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 24 Aug 2009 09:56:39 +0200 Subject: [M3devel] more web site problems Message-ID: <20090824095639.smnfmx03w0og8sc8@mail.elegosoft.com> Quoting Jay K : >> That's the result of your putting overrides into the CVSup > > I don't think it was me though I should have noticed it in the > initial version. Sorry, I didn't want to sound accusatory; I just remembered that you imported CVSup into the tree and later changed all the overrides, too. But these oversights happen all the time; you cannot avoid them. So never mind, Olaf > - Jay > > > > ---------------------------------------- >> Date: Sun, 23 Aug 2009 12:52:49 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: more web site problems >> >> Quoting Jay K : >> >>> http://www.opencm3.net/releng/collection-core.html >>> >>> has various README links. >>> I'm certain many are not useful (like under gcc) and I'm not certain if >>> any would be, but asis they all give access denied. >> >> All README links should now be fixed. I had renamed the workspace >> and forgot to adapt the link. >> >>> "platform-specific library imports for Windows systems" >>> is bogus. They are called "import libraries", not >>> "library imports". >> >> All package descriptions are in the DESC files. I've fixed this one >> now. Feel free to improve further. >> >> HTML needs to be regenerated now. I'll do that soon. >> >>> The Description is obviously wrong. >>> Maybe that is a placeholder? >>> Or not expanded? >> >> >>> The Dependencies look funny but maybe as intended? >>> Or maybe this is a unique output of having no dependencies? >>> Actually they look quite good for other package collections, >>> to provide all that data. I can't tell if only >>> immediately dependent package collections are listed >>> or transitive. >> >> It's just the output of my scripts that compute the dependencies. >> I haven't had put any efforts into making it beautiful. I thought >> it would be easily understandable, but that's probably wrong ;-) >> >>> The access denied on README isn't unique to core. >>> http://www.opencm3.net/releng/collection-database.html >>> >>> http://www.opencm3.net/releng/collection-cvsup.html >>> contains broken link to "manual page cvpasswd". >> >> That's the result of your putting overrides into the CVSup >> m3makefiles. Now nothing gets shipped. Probably all the CVSup >> packages are broken in this respect. Overrides should only be >> in m3override files and be activated with the -override option. >> >>> http://www.opencm3.net/releng/collection-devlib.html >>> README access denied >> >> Thanks for the comments, >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From lchretien at mac.com Mon Aug 24 16:08:45 2009 From: lchretien at mac.com (Louis =?ISO-8859-1?B?Q2hy6XRpZW4=?=) Date: Mon, 24 Aug 2009 10:08:45 -0400 Subject: [M3devel] Could you post this for me on m3devel In-Reply-To: <20090822003244.xwf5l3f5icswcgks@mail.elegosoft.com> Message-ID: Hi Olaf, try as I can, i cannot post the message on the list completely. Could you do that for me please? Thanks, ******************* Object: A more precise question about M3 licensing... (Real sorry about this, I don't know why it keeps being truncated...) >From what I gathered so far on this thread, the SRC licence was quite a bit more liberal than the FSF license, which led to this "separate process" business for the code generation phase, which displeased the FSF somewhat. ;-) After having read the licence for the LLVM project (a one pager on their website), i find it quite liberal and you can basically do anything with the code, as long as you give proper credit and keep the license with the files. I'm no lawyer, but it seems that the SRC and LLVM licenses could play along fine, as opposed to the FSF trying to "infect" everything it touches... So, here's the idea I had: Combine the existing CM3 (and/or PM3) front-end, and modify it to emit LLVM bytecodes, so that we could use the LLVM back-end and infrastructure to create a complete compiler/linker. Would such a beast, by combining code from both licenses, be viable? I would like to keep the licensing as liberal as possible. I sure would like your ideas on this subject, P.S.: Olaf, I think your suggestion of documenting the existing intermidiate representation of the CM3 compiler would be an absolute first step... -- Louis Chr?tien lchretien at mac.com From wagner at elegosoft.com Mon Aug 24 17:36:46 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 24 Aug 2009 17:36:46 +0200 Subject: [M3devel] Fwd: Could you post this for me on m3devel Message-ID: <20090824173646.l0yae49dgkwoks8o@mail.elegosoft.com> Trying once again with some periods removed ----- Forwarded message from lchretien at mac.com ----- Date: Mon, 24 Aug 2009 10:08:45 -0400 From: Louis Chr?tien Reply-To: Louis Chr?tien Subject: Could you post this for me on m3devel To: Olaf Wagner Hi Olaf, try as I can, i cannot post the message on the list completely. Could you do that for me please? Thanks, ******************* Object: A more precise question about M3 licensing (Real sorry about this, I don't know why it keeps being truncated) From what I gathered so far on this thread, the SRC licence was quite a bit more liberal than the FSF license, which led to this "separate process" business for the code generation phase, which displeased the FSF somewhat. ;-) After having read the licence for the LLVM project (a one pager on their website), i find it quite liberal and you can basically do anything with the code, as long as you give proper credit and keep the license with the files. I'm no lawyer, but it seems that the SRC and LLVM licenses could play along fine, as opposed to the FSF trying to "infect" everything it touches So, here's the idea I had: Combine the existing CM3 (and/or PM3) front-end, and modify it to emit LLVM bytecodes, so that we could use the LLVM back-end and infrastructure to create a complete compiler/linker. Would such a beast, by combining code from both licenses, be viable? I would like to keep the licensing as liberal as possible. I sure would like your ideas on this subject, P.S.: Olaf, I think your suggestion of documenting the existing intermidiate representation of the CM3 compiler would be an absolute first step -- Louis Chr?tien lchretien at mac.com ----- End forwarded message ----- -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Mon Aug 24 18:47:42 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 24 Aug 2009 12:47:42 -0400 Subject: [M3devel] Fwd: Could you post this for me on m3devel In-Reply-To: <20090824173646.l0yae49dgkwoks8o@mail.elegosoft.com> References: <20090824173646.l0yae49dgkwoks8o@mail.elegosoft.com> Message-ID: <20090824164741.GB13116@topoi.pooq.com> On Mon, Aug 24, 2009 at 05:36:46PM +0200, Olaf Wagner wrote: > > Object: A more precise question about M3 licensing > > From what I gathered so far on this thread, the SRC licence was quite a bit > more liberal than the FSF license, which led to this "separate process" > business for the code generation phase, which displeased the FSF somewhat. > ;-) As far as I know, the problem is that the SRC licence was restrictive at one point that conflicted with the FSF licence. In particular, you had to grant SRC the ability to do anything whatsoever with anything you added or modified in the system. That is a restriction on how you can redistribute -- a restriction more severe than the FSF licence allows.. But there's nothing preventing any of us from releasing your own code under multiple licences, including the FSF one. Even if you link directly to FSF code and distribute binaries, and aggregate your source with FSF code more intimately than "mere aggregation", nothing prevents you from licencing your code under as many different licences as you want in addition to the FSF one. But without SRS's say-so, we can't do it to their code. -- hendrik From hendrik at topoi.pooq.com Mon Aug 24 19:06:24 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 24 Aug 2009 13:06:24 -0400 Subject: [M3devel] platform names again. Message-ID: <20090824170624.GA13190@topoi.pooq.com> I have one home directory, shared via NFS among several machines. Some run Debian lenny, some run Debian squeeze, one is and AMD64. Now I really appreciate the fact that when I run cm3 I get my executables in a system-dependent diractory. But it occurs to me that both Debian lenny and Debian squeeze end you using the directory LINUXLIBC6. Are the files generated there truly Debian-release-independent? Might they depend in some way on the contents of Debian's shared C libraries, for example? And if so, is there a way of overriding the word "LINUXLIBC6" with some other word so that I can distinguish them? By the time I ship them to /usr/local/cm3, the problem is over, of course, since eash system has its own /usr/local. But on the way to there, there could be mishaps in LinuxLIBC6. -- hendrik From jay.krell at cornell.edu Mon Aug 24 20:12:37 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Mon, 24 Aug 2009 14:12:37 -0400 Subject: [M3devel] platform names again. In-Reply-To: <20090824170624.GA13190@topoi.pooq.com> References: <20090824170624.GA13190@topoi.pooq.com> Message-ID: <5E5E68F4-45DF-47A7-A97D-483398DFF529@hotmail.com> We have the same compatibility of any uninteresting multithreaded C code, whatever that is. On reasonable systems that is full compatibility. I don't know if Linux is reasonable. For example 64 bit FreeBSD is not reasonable, struct sockaddr changed from 6.4 to 7.0. - Jay (phone) On Aug 24, 2009, at 1:06 PM, hendrik at topoi.pooq.com wrote: > I have one home directory, shared via NFS among several machines. > Some > run Debian lenny, some run Debian squeeze, one is and AMD64. > > Now I really appreciate the fact that when I run cm3 I get my > executables in a system-dependent diractory. > > But it occurs to me that both Debian lenny and Debian squeeze end you > using the directory LINUXLIBC6. > > Are the files generated there truly Debian-release-independent? Might > they depend in some way on the contents of Debian's shared C > libraries, > for example? And if so, is there a way of overriding the word > "LINUXLIBC6" with some other word so that I can distinguish > them? > > By the time I ship them to /usr/local/cm3, the problem is over, of > course, since eash system has its own /usr/local. But on the way to > there, there could be mishaps in LinuxLIBC6. > > -- hendrik > > From jay.krell at cornell.edu Mon Aug 24 22:58:56 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 24 Aug 2009 20:58:56 +0000 Subject: [M3devel] platform names again. In-Reply-To: <20090824182526.6A6871A209F@newasync.async.caltech.edu> References: <20090824170624.GA13190@topoi.pooq.com> <5E5E68F4-45DF-47A7-A97D-483398DFF529@hotmail.com> <20090824182526.6A6871A209F@newasync.async.caltech.edu> Message-ID: I'm not sure that is true. I know some of the BSDs sometimes carry compatibility libraries -- old versions of libc. I'm not sure the struct sockaddr is a libc change or a kernel change. The mention in the release notes sounds like possibly a kernel change. I find the level of incompatibility knowingly introduced surprising in some of these systems. The commercial systems all seem to try and do achieve much better. As to more of the original questions, no, I don't think there is much you can do about the "LINUXLIBC6" directory name, in the distributed packages. For when you build from source, BUILD_DIR and TARGET are strictly speaking separate values. BUILD_DIR perhaps should be more fine grained and include more of uname. Ultimately we may very well go back to a release form of: assembly code for all the Modula-3 code, that goes into just cm3 uncompiled C code, again just what cm3 uses a makefile source to everything else That will address this issue. And then specific builds for specific systems, like Debian 4.0, Debian 5.0, OpenSUSE 11.0, Fedora 10, etc., the small number we can afford to provide -- possibly in the generic form, possibly in rpm/deb format as the systems "prefer" -- note that this is two separate variables -- the packaging format and the actual ABI. It would be good to nail this all down with more certainty -- what actually has changed in the past and/or is likely to change in the future. I wish the set was empty, but 64bit FreeBSD provides enough of an example to prove it is not. But, I have to ask, how the check do things like Adobe Flash, Acrobat Reader, etc. work? - Jay ---------------------------------------- > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] platform names again. > Date: Mon, 24 Aug 2009 11:25:26 -0700 > From: mika at newasync.async.caltech.edu > > > On FreeBSD, I find that generally you can install the compiler and > libraries and headers from the older version and always have that work. > > You cannot, however, expect to use a compiler, or an object, from a > newer version of the system on an older version and have it work. > > Mika > > jay.krell at cornell.edu writes: >>We have the same compatibility of any uninteresting multithreaded C >>code, whatever that is. >>On reasonable systems that is full compatibility. I don't know if >>Linux is reasonable. For example 64 bit FreeBSD is not reasonable, >>struct sockaddr changed from 6.4 to 7.0. >> >> - Jay (phone) >> >>On Aug 24, 2009, at 1:06 PM, hendrik at topoi.pooq.com wrote: >> >>> I have one home directory, shared via NFS among several machines. >>> Some >>> run Debian lenny, some run Debian squeeze, one is and AMD64. >>> >>> Now I really appreciate the fact that when I run cm3 I get my >>> executables in a system-dependent diractory. >>> >>> But it occurs to me that both Debian lenny and Debian squeeze end you >>> using the directory LINUXLIBC6. >>> >>> Are the files generated there truly Debian-release-independent? Might >>> they depend in some way on the contents of Debian's shared C >>> libraries, >>> for example? And if so, is there a way of overriding the word >>> "LINUXLIBC6" with some other word so that I can distinguish >>> them? >>> >>> By the time I ship them to /usr/local/cm3, the problem is over, of >>> course, since eash system has its own /usr/local. But on the way to >>> there, there could be mishaps in LinuxLIBC6. >>> >>> -- hendrik >>> >>> From jay.krell at cornell.edu Mon Aug 24 23:19:17 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 24 Aug 2009 21:19:17 +0000 Subject: [M3devel] ignored errors Message-ID: http://www.modula3.com:8080/view/SOLgnu/job/cm3-makedist-SOLgnu/11/console === package m3-sys/cminstall === +++ cm3 -build -override $RARGS -DROOT='/home/hudson/workspace/cm3-makedist-SOLgnu/cm3' -DCM3_VERSION_TEXT='5.8.3' -DCM3_VERSION_NUMBER='050803' -DCM3_LAST_CHANGED='2009-08-22' +++ /bin/sh: /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/m3-tools/m3bundle/SOLsun/m3bundle: not found "/home/hudson/workspace/cm3-makedist-SOLgnu/cm3/m3-libs/libm3/src/bundleintf/bundle.tmpl", line 53: quake runtime error: exit 1: /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/m3-tools/m3bundle/SOLsun/m3bundle -name Setup -element config ../src/config/SOLgnu --procedure-- -line- -file--- exec -- bundle 53 /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/m3-libs/libm3/src/bundleintf/bundle.tmpl include_dir 17 /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/m3-sys/cminstall/src/m3makefile 9 /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/m3-sys/cminstall/SOLgnu/m3make.args --- building in SOLgnu --- /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/m3-tools/m3bundle/SOLsun/m3bundle -name Setup -element config ../src/config/SOLgnu Fatal Error: package build failed ==> m3-sys/cminstall done Seems like that should not be ignored. I'll try to fix the actual error -- host vs. target -- SOLsun vs. SOLgnu. stage 2: installing cm3 compiler ---------------------------------------------------------------------------- installing /home/hudson/tmp/cm3/bin/cm3 /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/scripts/make-bin-dist-min.sh: strip: not found installing /home/hudson/tmp/cm3/bin/cm3cg /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/scripts/make-bin-dist-min.sh: strip: not found configuring temporary config file /home/hudson/tmp/cm3/bin/cm3.cfg cp: /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/m3-sys/cminstall/src/config-no-install/CVS: is a directory not sure if that should be ignored. I can fix it too, like: for a in [ /usr/ccs/bin/strip strip ]; then if [ type $a ]; then STRIP=$a fi fi Preferably put the options in the other order, if there is a "break" command in sh for for loops. - Jay From jay.krell at cornell.edu Mon Aug 24 23:22:01 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 24 Aug 2009 21:22:01 +0000 Subject: [M3devel] RC3 tag Message-ID: I don't see commit mails about this, so, fyi: I moved the RC3 tag forward: scripts/sysinfo.sh scripts/regression/defs.sh m3-sys/m3cc/src/m3makefile m3-sys/m3cc/src/gnucc.common (rename it gnucc.quake?) m3-sys/m3cc/src/gnumake.common (rename it gnumake.quake?) TAR was unconditionally being set to tar, which is wrong on Solaris without hacks. No attempt to set TAR or PATH in Hudson could fix that, nor do I think that would be the right fix. I might move m3gdb/src/m3makefile forward too, and something regarding bundle, and maybe more scripts for the strip error. - Jay From hendrik at topoi.pooq.com Tue Aug 25 01:31:18 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 24 Aug 2009 19:31:18 -0400 Subject: [M3devel] platform names again. In-Reply-To: References: <20090824170624.GA13190@topoi.pooq.com> <5E5E68F4-45DF-47A7-A97D-483398DFF529@hotmail.com> <20090824182526.6A6871A209F@newasync.async.caltech.edu> Message-ID: <20090824233118.GB13751@topoi.pooq.com> On Mon, Aug 24, 2009 at 08:58:56PM +0000, Jay K wrote: > > I'm not sure that is true. > I know some of the BSDs sometimes carry compatibility libraries -- old versions of libc. > I'm not sure the struct sockaddr is a libc change or a kernel change. > The mention in the release notes sounds like possibly a kernel change. > > > I find the level of incompatibility knowingly introduced surprising in some of these systems. > The commercial systems all seem to try and do achieve much better. > > > As to more of the original questions, no, I don't think there is much > you can do about the "LINUXLIBC6" directory name, in the distributed > packages. For when you build from source, BUILD_DIR and TARGET are > strictly speaking separate values. BUILD_DIR perhaps should be more > fine grained and include more of uname. So does TARGET identify the target platform and does BUILD_DIR identify the name of the directory (in this case .../LINUXLIBC6/ ) into which all the derived files should go? Could BUILD_DIR be overridden? That would suffice. I'd just pick a different BUILD_DIR when I compile on one of y systems. > > > Ultimately we may very well go back to a release form of: > assembly code for all the Modula-3 code, that goes into just cm3 > uncompiled C code, again just what cm3 uses > a makefile > source to everything else > > > That will address this issue. > > > And then specific builds for specific systems, like Debian 4.0, Debian 5.0, OpenSUSE 11.0, Fedora 10, etc., the small number we can afford to provide -- possibly in the generic form, possibly in rpm/deb format as the systems "prefer" -- note that this is two separate variables -- the packaging format and the actual ABI. > > > It would be good to nail this all down with more certainty -- what actually has changed in the past and/or is likely to change in the future. I wish the set was empty, but 64bit FreeBSD provides enough of an example to prove it is not. > > > But, I have to ask, how the check do things like Adobe Flash, Acrobat > Reader, etc. work? Every now and them Adobe Flash just stops working altogether on my system. -- hendrik From jay.krell at cornell.edu Tue Aug 25 03:08:31 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 25 Aug 2009 01:08:31 +0000 Subject: [M3devel] platform names again. In-Reply-To: <20090824233118.GB13751@topoi.pooq.com> References: <20090824170624.GA13190@topoi.pooq.com> <5E5E68F4-45DF-47A7-A97D-483398DFF529@hotmail.com> <20090824182526.6A6871A209F@newasync.async.caltech.edu> <20090824233118.GB13751@topoi.pooq.com> Message-ID: Yes BUILD_DIR apparently is meant to be overridable/changable. I'm not sure if all the various tools that kinda sorta know what is going on will play along. When I pointed out that TARGET does not necessarily equal BUILD_DIR, Randy said that would break cm3ide. Yet it was apparently always theoretically true, for profiled builds. Not that I have done a profiled build. And it is always true in practise. Since I never do a profiled build and probably nobody else does either. But you can try varying it. Try this: in config file, change BUILD_DIR = whatever to if !defined("BUILD_DIR)" around BUILD_DIR = whatever end and then on the cm3 command line, try cm3 -DBUILD_DIR=foo scripts -realclean will tend to not play along here. - Jay ---------------------------------------- > Date: Mon, 24 Aug 2009 19:31:18 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] platform names again. > > On Mon, Aug 24, 2009 at 08:58:56PM +0000, Jay K wrote: >> >> I'm not sure that is true. >> I know some of the BSDs sometimes carry compatibility libraries -- old versions of libc. >> I'm not sure the struct sockaddr is a libc change or a kernel change. >> The mention in the release notes sounds like possibly a kernel change. >> >> >> I find the level of incompatibility knowingly introduced surprising in some of these systems. >> The commercial systems all seem to try and do achieve much better. >> >> >> As to more of the original questions, no, I don't think there is much >> you can do about the "LINUXLIBC6" directory name, in the distributed >> packages. For when you build from source, BUILD_DIR and TARGET are >> strictly speaking separate values. BUILD_DIR perhaps should be more >> fine grained and include more of uname. > > So does TARGET identify the target platform and does BUILD_DIR identify > the name of the directory (in this case .../LINUXLIBC6/ ) into which all > the derived files should go? Could BUILD_DIR be overridden? That would > suffice. I'd just pick a different BUILD_DIR when I compile on one of y > systems. > >> >> >> Ultimately we may very well go back to a release form of: >> assembly code for all the Modula-3 code, that goes into just cm3 >> uncompiled C code, again just what cm3 uses >> a makefile >> source to everything else >> >> >> That will address this issue. >> >> >> And then specific builds for specific systems, like Debian 4.0, Debian 5.0, OpenSUSE 11.0, Fedora 10, etc., the small number we can afford to provide -- possibly in the generic form, possibly in rpm/deb format as the systems "prefer" -- note that this is two separate variables -- the packaging format and the actual ABI. >> >> >> It would be good to nail this all down with more certainty -- what actually has changed in the past and/or is likely to change in the future. I wish the set was empty, but 64bit FreeBSD provides enough of an example to prove it is not. >> >> >> But, I have to ask, how the check do things like Adobe Flash, Acrobat >> Reader, etc. work? > > Every now and them Adobe Flash just stops working altogether on my > system. > > -- hendrik From hendrik at topoi.pooq.com Tue Aug 25 03:36:10 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 24 Aug 2009 21:36:10 -0400 Subject: [M3devel] How to compile system from (modified) source? Message-ID: <20090825013610.GA13985@topoi.pooq.com> I downloaded the complete source tree via cvs. I downloaded some of the RC3 archives. I start with an empty /usr/local/cm3. I install the core and RC3 gui archives. I make a copy of the source tree so as not to mess with the original. I make small changes to ButtonVBT.i3 and ButtonVBT.m3 I run the script do-cm3-std.sh It fails in odbc. I figure maybe I don;t have the right db stuff on my system and modify do-cm3-std.sh by removing all packages having anything to do with db. Hereby I replace toe command P=`lots of stuff` by P="long list of packages" I obtained the long list by sticking an echo $P into the script, copying the result into the script, and removing odbc postgres95 db smalldb stablegen stable Now I rerun the script. The package I modified appears to compile withoug problems. In fact, the script seems to compile everything but doesn't seem to ship anything. Aha! I forgot to say "ship". Now I rerun again, specifying "ship". Almost all package fails to ship with the message: package was built with overrides, not shipping. How am I supposed to do this. -- hendrik From hendrik at topoi.pooq.com Tue Aug 25 03:53:43 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 24 Aug 2009 21:53:43 -0400 Subject: [M3devel] my small changes to ButtonVBT. In-Reply-To: <20090825013610.GA13985@topoi.pooq.com> References: <20090825013610.GA13985@topoi.pooq.com> Message-ID: <20090825015343.GA14032@topoi.pooq.com> On Mon, Aug 24, 2009 at 09:36:10PM -0400, hendrik at topoi.pooq.com wrote: > > I make small changes to ButtonVBT.i3 and ButtonVBT.m3 By the way, here are the small changes: hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ cvs diff cvs diff: Diffing . Index: ButtonVBT.i3 =================================================================== RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.i3,v retrieving revision 1.2 diff -r1.2 ButtonVBT.i3 39a40 > act(READONLY cd: VBT.MouseRec); Index: ButtonVBT.m3 =================================================================== RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.m3,v retrieving revision 1.2 diff -r1.2 ButtonVBT.m3 28c28,29 < init := Be --- > init := Be; > act := act 46a48,52 > PROCEDURE act(v : T; READONLY cd: VBT.MouseRec) = > BEGIN > v.action(v, cd); > END act; > 59c65 < v.action(v, cd); --- > v.act(cd); hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ -- hendrik From jay.krell at cornell.edu Tue Aug 25 03:56:21 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 25 Aug 2009 01:56:21 +0000 Subject: [M3devel] How to compile system from (modified) source? In-Reply-To: <20090825013610.GA13985@topoi.pooq.com> References: <20090825013610.GA13985@topoi.pooq.com> Message-ID: apt-get install unixodbc etc. ? ./do-cm3-std.sh buildship ./do-pkg.sh buildship list of packages The scripts just cd around and run cm3 -build and/or cm3 -ship and/or other commands. Do ./do-cm3-std.sh realclean to remove the "local" build you did. - Jay ---------------------------------------- > Date: Mon, 24 Aug 2009 21:36:10 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: [M3devel] How to compile system from (modified) source? > > I downloaded the complete source tree via cvs. > > I downloaded some of the RC3 archives. > > I start with an empty /usr/local/cm3. > > I install the core and RC3 gui archives. > > I make a copy of the source tree so as not to mess with the original. > > I make small changes to ButtonVBT.i3 and ButtonVBT.m3 > > I run the script do-cm3-std.sh > > It fails in odbc. > > I figure maybe I don;t have the right db stuff on my system and modify > do-cm3-std.sh by removing all packages having anything to do with db. > Hereby I replace toe command P=`lots of stuff` > by P="long list of packages" > > I obtained the long list by sticking an echo $P into the script, copying > the result into the script, and removing odbc postgres95 db smalldb > stablegen stable > > Now I rerun the script. The package I modified appears to compile > withoug problems. In fact, the script seems to compile everything but > doesn't seem to ship anything. Aha! I forgot to say "ship". > > Now I rerun again, specifying "ship". Almost all package fails to ship > with the message: > package was built with overrides, not shipping. > > How am I supposed to do this. > > -- hendrik > From hendrik at topoi.pooq.com Tue Aug 25 04:45:50 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 24 Aug 2009 22:45:50 -0400 Subject: [M3devel] How to compile system from (modified) source? In-Reply-To: References: <20090825013610.GA13985@topoi.pooq.com> Message-ID: <20090825024550.GA14124@topoi.pooq.com> On Tue, Aug 25, 2009 at 01:56:21AM +0000, Jay K wrote: > > apt-get install unixodbc > etc. > ? > > ./do-cm3-std.sh buildship > > ./do-pkg.sh buildship list of packages > > > The scripts just cd around and run cm3 -build and/or cm3 -ship and/or other commands. > > Do ./do-cm3-std.sh realclean to remove the "local" build you did. Yay! It works! -- hendrik > > > - Jay > > > > > > > ---------------------------------------- > > Date: Mon, 24 Aug 2009 21:36:10 -0400 > > From: hendrik at topoi.pooq.com > > To: m3devel at elegosoft.com > > Subject: [M3devel] How to compile system from (modified) source? > > > > I downloaded the complete source tree via cvs. > > > > I downloaded some of the RC3 archives. > > > > I start with an empty /usr/local/cm3. > > > > I install the core and RC3 gui archives. > > > > I make a copy of the source tree so as not to mess with the original. > > > > I make small changes to ButtonVBT.i3 and ButtonVBT.m3 > > > > I run the script do-cm3-std.sh > > > > It fails in odbc. > > > > I figure maybe I don;t have the right db stuff on my system and modify > > do-cm3-std.sh by removing all packages having anything to do with db. > > Hereby I replace toe command P=`lots of stuff` > > by P="long list of packages" > > > > I obtained the long list by sticking an echo $P into the script, copying > > the result into the script, and removing odbc postgres95 db smalldb > > stablegen stable > > > > Now I rerun the script. The package I modified appears to compile > > withoug problems. In fact, the script seems to compile everything but > > doesn't seem to ship anything. Aha! I forgot to say "ship". > > > > Now I rerun again, specifying "ship". Almost all package fails to ship > > with the message: > > package was built with overrides, not shipping. > > > > How am I supposed to do this. > > > > -- hendrik > > From hendrik at topoi.pooq.com Tue Aug 25 05:01:14 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 24 Aug 2009 23:01:14 -0400 Subject: [M3devel] small design problem in ButtonVBT? In-Reply-To: <20090401120347.x8cneize8oscg44o@mail.elegosoft.com> References: <20090331145127.GB9624@topoi.pooq.com> <20090401120347.x8cneize8oscg44o@mail.elegosoft.com> Message-ID: <20090825030114.GA14152@topoi.pooq.com> On Wed, Apr 01, 2009 at 12:03:47PM +0200, Olaf Wagner wrote: > Quoting hendrik at topoi.pooq.com: > > >The BottonVBT contains an action, which is a procedure rather than a > >method. b This makes it awkward to subclass ButtonVBT becaue the action > >will still expect its first parameter to be a ButtonVBT instead of > >belonging to the subclass, and an explicit downcast of some sort will be > >needed to acess the subclass's members. > > > >The Trestle manual says this was a deliberate decision: > > > >: The action procedure is a field rather than a method in order to allow > >: buttons with different action procedures to share their method suites. > > > >I, however, find it massively inconvenient because it mans I have to > >resort to downcasting or the very kludgey VBT.GetProp to access what > >should be just there. I'd rather the action procedure was a method. > > > >But it should be possible to have the best of both worlds. Have an > >action2 (better name wanted here) method that is available for > >overriding, and by default calls the procedure in the existing action. > >field. That action2 method wounl then be called by Trestle wherever > >action is now called. > > > >Does anyone see problems with this? > > Sounds fine to me offhand. You should test your extensions with > some of the existing larger applications, like mentor and Juno-2, > of course. How should I go about testing my extensions with mentor and Juno-2? I don't know what they do. Is there an automated test? By the way, mentor and Juno (downloaded out of current CVS) do seem to compile and link correctly with this change on a 32-bit Debian squeeze system. I decided to call the new mathid 'act' instead of 'action2', by the way. It's a verb. -- hendrik From wagner at elegosoft.com Tue Aug 25 08:00:01 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 25 Aug 2009 08:00:01 +0200 Subject: [M3devel] ignored errors In-Reply-To: References: Message-ID: <20090825080001.4ptdm2ce8ws4oogk@mail.elegosoft.com> Quoting Jay K : > http://www.modula3.com:8080/view/SOLgnu/job/cm3-makedist-SOLgnu/11/console > === package m3-sys/cminstall === > +++ cm3 -build -override $RARGS > -DROOT='/home/hudson/workspace/cm3-makedist-SOLgnu/cm3' > -DCM3_VERSION_TEXT='5.8.3' -DCM3_VERSION_NUMBER='050803' > -DCM3_LAST_CHANGED='2009-08-22' +++ > /bin/sh: > /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/m3-tools/m3bundle/SOLsun/m3bundle: not > found > "/home/hudson/workspace/cm3-makedist-SOLgnu/cm3/m3-libs/libm3/src/bundleintf/bundle.tmpl", line 53: quake runtime error: exit 1: /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/m3-tools/m3bundle/SOLsun/m3bundle -name Setup -element config > ../src/config/SOLgnu > --procedure-- -line- -file--- > exec -- > bundle 53 > /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/m3-libs/libm3/src/bundleintf/bundle.tmpl > include_dir 17 > /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/m3-sys/cminstall/src/m3makefile > 9 > /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/m3-sys/cminstall/SOLgnu/m3make.args > --- building in SOLgnu --- > /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/m3-tools/m3bundle/SOLsun/m3bundle -name Setup -element config > ../src/config/SOLgnu > Fatal Error: package build failed > ==> m3-sys/cminstall done > > Seems like that should not be ignored. > I'll try to fix the actual error -- host vs. target -- SOLsun vs. SOLgnu. Probably the first stage of upgrade? And calling make-dist without a already-compiled cm3 installation? > stage 2: installing cm3 compiler > ---------------------------------------------------------------------------- > installing /home/hudson/tmp/cm3/bin/cm3 > /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/scripts/make-bin-dist-min.sh: > strip: not found > installing /home/hudson/tmp/cm3/bin/cm3cg > /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/scripts/make-bin-dist-min.sh: > strip: not found > configuring temporary config file /home/hudson/tmp/cm3/bin/cm3.cfg > cp: > /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/m3-sys/cminstall/src/config-no-install/CVS: is a > directory > > not sure if that should be ignored. > I can fix it too, like: > > for a in [ /usr/ccs/bin/strip strip ]; then > if [ type $a ]; then > STRIP=$a > fi > fi We need /usr/ccs/bin in the PATH on Solaris. I just noticed that the PATH was reset to /usr/bin after the latest installation, but forgot about /usr/ccs/bin. > Preferably put the options in the other order, if there is a "break" > command in sh for for loops. We didn't need special handling for strip before AFAIK. It should be there on all POSIX systems. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Aug 25 08:07:01 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 25 Aug 2009 08:07:01 +0200 Subject: [M3devel] RC3 tag In-Reply-To: References: Message-ID: <20090825080701.cfz0fs2wao0880gc@mail.elegosoft.com> Quoting Jay K : > I don't see commit mails about this, so, fyi: > > I moved the RC3 tag forward: > scripts/sysinfo.sh > scripts/regression/defs.sh > m3-sys/m3cc/src/m3makefile > m3-sys/m3cc/src/gnucc.common (rename it gnucc.quake?) > m3-sys/m3cc/src/gnumake.common (rename it gnumake.quake?) > > TAR was unconditionally being set to tar, which is wrong on Solaris > without hacks. > No attempt to set TAR or PATH in Hudson could fix that, nor do I > think that would be the right fix. > > I might move m3gdb/src/m3makefile forward too, and something > regarding bundle, and maybe more scripts for the strip error. Let me know when that's done. I assume you've fixed the build error on Solaris. We should then rebuild all packages. Olaf PS: So far for just pressing a button to build the release packages... :-/ -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Aug 25 09:21:48 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 25 Aug 2009 07:21:48 +0000 Subject: [M3devel] ignored errors In-Reply-To: <20090825080001.4ptdm2ce8ws4oogk@mail.elegosoft.com> References: <20090825080001.4ptdm2ce8ws4oogk@mail.elegosoft.com> Message-ID: > Probably the first stage of upgrade? > And calling make-dist without a already-compiled cm3 installation? Yes, granted, probably unconvential that way. > We need /usr/ccs/bin in the PATH on Solaris. I just noticed that the > PATH was reset to /usr/bin after the latest installation, but forgot > about /usr/ccs/bin. I go back and forth here. I tried out emptying my Solaris .profile file etc. The default path is just /usr/bin. I have made things work with that. gcc, strip, ar, gtar, gmake are not in $PATH but they are present (in a "full" install of what Sun provides0. Usually I check $PATH first, let user override that way, though granted, for strip I was not consistent. - Jay From hendrik at topoi.pooq.com Tue Aug 25 13:29:47 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 25 Aug 2009 07:29:47 -0400 Subject: [M3devel] RC3 tag In-Reply-To: <20090825080701.cfz0fs2wao0880gc@mail.elegosoft.com> References: <20090825080701.cfz0fs2wao0880gc@mail.elegosoft.com> Message-ID: <20090825112947.GB14914@topoi.pooq.com> On Tue, Aug 25, 2009 at 08:07:01AM +0200, Olaf Wagner wrote: > > We should then rebuild all packages. With some distinction in the version numbers so people know which is which. RC3.1? RC4? -- hendrik > > Olaf > > PS: So far for just pressing a button to build the release packages... :-/ That's what's being debugged now. How long has it been since a release? -- hendrik From wagner at elegosoft.com Tue Aug 25 13:45:28 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 25 Aug 2009 13:45:28 +0200 Subject: [M3devel] HEADS UP: Rebuild RC3 or wait for RC4 next week? was Re: RC3 tag In-Reply-To: <20090825112947.GB14914@topoi.pooq.com> References: <20090825080701.cfz0fs2wao0880gc@mail.elegosoft.com> <20090825112947.GB14914@topoi.pooq.com> Message-ID: <20090825134528.ah9lydnwgwgs0skg@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > On Tue, Aug 25, 2009 at 08:07:01AM +0200, Olaf Wagner wrote: >> >> We should then rebuild all packages. > > With some distinction in the version numbers so people know which is > which. RC3.1? RC4? RC3.1 does not make sense. Doing everthing according to plan, we had to abandon RC3 and build RC4 now. The RC3 tag has been moved which shouldn't happen strictly speaking. There's no mechanism in CVS to lock a tag though. There have been only minor corrections, mostly in the build tooling and system dependencies AFAIK. So we could make a concession and rebuild the RC3 packages as they only have been announced on the m3 mailing lists so far. I'd vote for that in this case. Switching to RC4 requires changing several scripts and docs again and applying a new tag. I cannot do that from here, nor will it probably be done until the next weekend. So more delay (until somebody else steps in). NT386 failures are still not resolved, too, AFAIK. Any volunteers? Please note that the built packages now available for RC3 are mostly working, at least better than RC2. But SOLgnu and NT386 couldn't be built with the RC3 tag. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Aug 25 18:28:34 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 25 Aug 2009 16:28:34 +0000 Subject: [M3devel] timeout at the end of makedist? Message-ID: http://www.modula3.com:8080/view/SOLgnu/job/cm3-makedist-SOLgnu/14/console all the way at the bottom: -rw-r--r-- 1 hudson other 2785402 Aug 25 05:56 /home/hudson/tmp/cm3-bin-ws-game-SOLgnu-5.8.3-RC3.tgz Received disconnect from 88.198.39.217: 2: Timeout, your session not responding. lost connection Finished: SUCCESS This is copying the packages to birch? It shouldn't report success? We should do some incremental copy? - Jay From jay.krell at cornell.edu Tue Aug 25 18:31:55 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 25 Aug 2009 16:31:55 +0000 Subject: [M3devel] HEADS UP: Rebuild RC3 or wait for RC4 next week? was Re: RC3 tag In-Reply-To: <20090825134528.ah9lydnwgwgs0skg@mail.elegosoft.com> References: <20090825080701.cfz0fs2wao0880gc@mail.elegosoft.com> <20090825112947.GB14914@topoi.pooq.com> <20090825134528.ah9lydnwgwgs0skg@mail.elegosoft.com> Message-ID: Please let's not create extra process and secretarial work. It's bad enough to have to any branching. I'll move the RC3 tag forward as needed for SOLgnu, SOLsun, NT386. SOLgnu looks good now except for the timeout at the end with scp, and the cvsup problem to fix. - Jay ---------------------------------------- > Date: Tue, 25 Aug 2009 13:45:28 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] HEADS UP: Rebuild RC3 or wait for RC4 next week? was Re: RC3 tag > > Quoting hendrik at topoi.pooq.com: > >> On Tue, Aug 25, 2009 at 08:07:01AM +0200, Olaf Wagner wrote: >>> >>> We should then rebuild all packages. >> >> With some distinction in the version numbers so people know which is >> which. RC3.1? RC4? > > RC3.1 does not make sense. Doing everthing according to plan, we had > to abandon RC3 and build RC4 now. The RC3 tag has been moved which shouldn't > happen strictly speaking. There's no mechanism in CVS to lock a tag though. > > There have been only minor corrections, mostly in the build tooling > and system dependencies AFAIK. So we could make a concession and rebuild > the RC3 packages as they only have been announced on the m3 mailing lists > so far. I'd vote for that in this case. > > Switching to RC4 requires changing several scripts and docs again > and applying a new tag. I cannot do that from here, nor will it probably > be done until the next weekend. So more delay (until somebody else > steps in). NT386 failures are still not resolved, too, AFAIK. > Any volunteers? > > Please note that the built packages now available for RC3 are mostly > working, at least better than RC2. But SOLgnu and NT386 couldn't be > built with the RC3 tag. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Tue Aug 25 18:38:35 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 25 Aug 2009 16:38:35 +0000 Subject: [M3devel] SOLsun and versions Message-ID: Fyi, I'm running a very current Solaris 2.10 2009/05 and its SunStudio 12. http://www.modula3.com:8080/view/SOLsun/job/boot-solsun/9/console "../src/os/POSIX/FilePosixC.c", line 19: warning: typedef redeclared: flock_t cc: Warning: -xarch=v8plus is deprecated, use -m32 -xarch=sparc instead cc: Warning: -xarch=v8plus is deprecated, use -m32 -xarch=sparc instead "/home/hudson/work/solsun/cm3-inst/ssol/rel-d5.8.2/pkg/m3core/src/unix/Common/m3unix.h", line 83: warning: typedef redeclared: timespec_t "../src/os/POSIX/FSPosixC.c", line 12: warning: typedef redeclared: dirent_t cc: Warning: -xarch=v8plus is deprecated, use -m32 -xarch=sparc instead cc: Warning: -xarch=v8plus is deprecated, use -m32 -xarch=sparc instead Undefined first referenced symbol in file __floatdidf FilePosix.mo Could very well be that if/when I fix these or some of them, we'll lose compatibility with older releases. Maybe I'll read the man pages and find out what is compatibile with what. Maybe we can/should do something more "like" autoconf in places. - Jay From jay.krell at cornell.edu Tue Aug 25 19:07:52 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 25 Aug 2009 17:07:52 +0000 Subject: [M3devel] HEADS UP: Rebuild RC3 or wait for RC4 next week? was Re: RC3 tag In-Reply-To: References: <20090825080701.cfz0fs2wao0880gc@mail.elegosoft.com> <20090825112947.GB14914@topoi.pooq.com> <20090825134528.ah9lydnwgwgs0skg@mail.elegosoft.com> Message-ID: The NT386 problems look small btw. "C:\cygwin\home\elego\tmp\cm3\pkg\cit_util\src\generics.tmpl", line 38: quake runtime error: exit 1: C:\cygwin\home\elego\workspace\cm3-makedist-NT386\cm3\caltech-parser\parserlib\klex\NT386\klex ..\src\Calc.l -o CalcLex.i3 -t ..\src\Calc.t -ti3 CalcTok.i3 "C:\cygwin\home\elego\tmp\cm3\pkg\cit_util\src\generics.tmpl", line 38: quake runtime error: exit 1: C:\cygwin\home\elego\workspace\cm3-makedist-NT386\cm3\caltech-parser\parserlib\klex\NT386\klex ..\src\Calc.l -o CalcLex.i3 -t ..\src\Calc.t -ti3 CalcTok.i3 Fatal Error: package build failed errors during build-all; some packages will be missing m3-win/import-libs/NT386/.M3SHIP seems to be broken: make_dir("C:/cygwin/home/elego/tmp/cm3/lib") install_file("wsock32.lib", "C:/cygwin/home/elego/tmp/cm3/lib", "0775") Probably a matter of forward vs. backward slashes on the second set. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Date: Tue, 25 Aug 2009 16:31:55 +0000 > Subject: Re: [M3devel] HEADS UP: Rebuild RC3 or wait for RC4 next week? was Re: RC3 tag > > > Please let's not create extra process and secretarial work. It's bad enough to have to any branching. > I'll move the RC3 tag forward as needed for SOLgnu, SOLsun, NT386. > SOLgnu looks good now except for the timeout at the end with scp, and the cvsup problem to fix. > > - Jay > > ---------------------------------------- >> Date: Tue, 25 Aug 2009 13:45:28 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] HEADS UP: Rebuild RC3 or wait for RC4 next week? was Re: RC3 tag >> >> Quoting hendrik at topoi.pooq.com: >> >>> On Tue, Aug 25, 2009 at 08:07:01AM +0200, Olaf Wagner wrote: >>>> >>>> We should then rebuild all packages. >>> >>> With some distinction in the version numbers so people know which is >>> which. RC3.1? RC4? >> >> RC3.1 does not make sense. Doing everthing according to plan, we had >> to abandon RC3 and build RC4 now. The RC3 tag has been moved which shouldn't >> happen strictly speaking. There's no mechanism in CVS to lock a tag though. >> >> There have been only minor corrections, mostly in the build tooling >> and system dependencies AFAIK. So we could make a concession and rebuild >> the RC3 packages as they only have been announced on the m3 mailing lists >> so far. I'd vote for that in this case. >> >> Switching to RC4 requires changing several scripts and docs again >> and applying a new tag. I cannot do that from here, nor will it probably >> be done until the next weekend. So more delay (until somebody else >> steps in). NT386 failures are still not resolved, too, AFAIK. >> Any volunteers? >> >> Please note that the built packages now available for RC3 are mostly >> working, at least better than RC2. But SOLgnu and NT386 couldn't be >> built with the RC3 tag. >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> From hendrik at topoi.pooq.com Tue Aug 25 20:13:05 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 25 Aug 2009 14:13:05 -0400 Subject: [M3devel] How to compile system from (modified) source? In-Reply-To: References: <20090825013610.GA13985@topoi.pooq.com> Message-ID: <20090825181305.GB15646@topoi.pooq.com> On Tue, Aug 25, 2009 at 01:56:21AM +0000, Jay K wrote: > > apt-get install unixodbc > etc. > ? I already had unixodbc installed on my system. Just in case the installation was affected by the build vd buildship problem, I restored the std script to its original code (uncommenting the fgrep line I had commented out, and commenting out the P= line with the long list I had put in, and reran. Here's what appears to be the relevant part of the log: === package m3-db/odbc === +++ cm3 -build -DROOT='/farhome/hendrik/cm3/love-sq/cm3' -DCM3_VERSION_TEXT='d5.8.2' -DCM3_VERSION_NUMBER='050802' -DCM3_LAST_CHANGED='2009-07-15' $RARGS && cm3 -ship $RARGS -DROOT='/farhome/hendrik/cm3/love-sq/cm3' -DCM3_VERSION_TEXT='d5.8.2' -DCM3_VERSION_NUMBER='050802' -DCM3_LAST_CHANGED='2009-07-15' +++ --- building in LINUXLIBC6 --- ignoring ../src/m3overrides new "/usr/local/cm3/pkg/m3core/LINUXLIBC6/libm3core.a" -> archiving libm3odbc.a /usr/bin/ld: cannot find -lodbc collect2: ld returned 1 exit status make_lib => 1 librarian failed building: m3odbc Fatal Error: package build failed *** execution of cm3 -build -DROOT='/farhome/hendrik/cm3/love-sq/cm3' -DCM3_VERSION_TEXT='d5.8.2' -DCM3_VERSION_NUMBER='050802' -DCM3_LAST_CHANGED='2009-07-15' $RARGS && cm3 -ship $RARGS -DROOT='/farhome/hendrik/cm3/love-sq/cm3' -DCM3_VERSION_TEXT='d5.8.2' -DCM3_VERSION_NUMBER='050802' -DCM3_LAST_CHANGED='2009-07-15' failed *** hendrik at lovesong:~/cm3/love-sq/cm3$ exit Script done, file is log9-with-db-again And here's the list of files for package unixodbc in squeeze, according to the Debian packages website in case it's useful: /usr/bin/isql /usr/bin/iusql /usr/lib/libgtrtst.so.1 /usr/lib/libgtrtst.so.1.0.0 /usr/lib/libodbc.so.1 /usr/lib/libodbc.so.1.0.0 /usr/lib/libodbccr.so.1 /usr/lib/libodbccr.so.1.0.0 /usr/lib/odbc/libnn.so /usr/lib/odbc/libodbctxt.so /usr/share/doc/unixodbc/AUTHORS /usr/share/doc/unixodbc/NEWS.gz /usr/share/doc/unixodbc/README /usr/share/doc/unixodbc/README.GTK /usr/share/doc/unixodbc/README.MySql /usr/share/doc/unixodbc/changelog.Debian.gz /usr/share/doc/unixodbc/changelog.gz /usr/share/doc/unixodbc/copyright /usr/share/lintian/overrides/unixodbc /usr/share/man/man1/isql.1.gz /usr/share/man/man1/iusql.1.gz -- hendrik From jay.krell at cornell.edu Tue Aug 25 21:19:05 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Tue, 25 Aug 2009 15:19:05 -0400 Subject: [M3devel] SOLsun and versions In-Reply-To: References: Message-ID: <55A850EF-4F94-4568-8A00-D4CD5D54F9CD@hotmail.com> (truncated!) - Jay (phone) On Aug 25, 2009, at 12:38 PM, Jay K wrote: > > Fyi, I'm running a very current Solaris 2.10 2009/05 and its > SunStudio 12 From jay.krell at cornell.edu Tue Aug 25 21:22:08 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Tue, 25 Aug 2009 15:22:08 -0400 Subject: [M3devel] How to compile system from (modified) source? In-Reply-To: <20090825181305.GB15646@topoi.pooq.com> References: <20090825013610.GA13985@topoi.pooq.com> <20090825181305.GB15646@topoi.pooq.com> Message-ID: <8A772E75-0495-44E2-9751-3032E9031FD4@hotmail.com> cd m3-db/odbc rm -rf LINUXLIBC6 cm3 -commands or look for odbc in install/bin/config/* - Jay (phone) On Aug 25, 2009, at 2:13 PM, hendrik at topoi.pooq.com wrote: > On Tue, Aug 25, 2009 at 01:56:21AM +0000, Jay K wrote: >> >> apt-get install unixodbc >> etc. >> ? > > I already had unixodbc installed on my system. > > Just in case the installation was affected by the build vd buildship > problem, I restored the std script to its original code (uncommenting > the fgrep line I had commented out, and commenting out the P= line > with > the long list I had put in, and reran. Here's what appears to be the > relevant part of the log: > > === package m3-db/odbc === > +++ cm3 -build -DROOT='/farhome/hendrik/cm3/love-sq/cm3' - > DCM3_VERSION_TEXT='d5.8.2' -DCM3_VERSION_NUMBER='050802' - > DCM3_LAST_CHANGED='2009-07-15' $RARGS && cm3 -ship $RARGS -DROOT='/ > farhome/hendrik/cm3/love-sq/cm3' -DCM3_VERSION_TEXT='d5.8.2' - > DCM3_VERSION_NUMBER='050802' -DCM3_LAST_CHANGED='2009-07-15' +++ > --- building in LINUXLIBC6 --- > > ignoring ../src/m3overrides > > new "/usr/local/cm3/pkg/m3core/LINUXLIBC6/libm3core.a" -> archiving > libm3odbc.a > /usr/bin/ld: cannot find -lodbc > collect2: ld returned 1 exit status > make_lib => 1 > librarian failed building: m3odbc > Fatal Error: package build failed > *** execution of cm3 -build -DROOT='/farhome/hendrik/cm3/love-sq/ > cm3' -DCM3_VERSION_TEXT='d5.8.2' -DCM3_VERSION_NUMBER='050802' - > DCM3_LAST_CHANGED='2009-07-15' $RARGS && cm3 -ship $RARGS -DROOT='/ > farhome/hendrik/cm3/love-sq/cm3' -DCM3_VERSION_TEXT='d5.8.2' - > DCM3_VERSION_NUMBER='050802' -DCM3_LAST_CHANGED='2009-07-15' failed > *** > hendrik at lovesong:~/cm3/love-sq/cm3$ exit > Script done, file is log9-with-db-again > > > And here's the list of files for package unixodbc in squeeze, > according to the Debian packages website in case it's useful: > > /usr/bin/isql > /usr/bin/iusql > /usr/lib/libgtrtst.so.1 > /usr/lib/libgtrtst.so.1.0.0 > /usr/lib/libodbc.so.1 > /usr/lib/libodbc.so.1.0.0 > /usr/lib/libodbccr.so.1 > /usr/lib/libodbccr.so.1.0.0 > /usr/lib/odbc/libnn.so > /usr/lib/odbc/libodbctxt.so > /usr/share/doc/unixodbc/AUTHORS > /usr/share/doc/unixodbc/NEWS.gz > /usr/share/doc/unixodbc/README > /usr/share/doc/unixodbc/README.GTK > /usr/share/doc/unixodbc/README.MySql > /usr/share/doc/unixodbc/changelog.Debian.gz > /usr/share/doc/unixodbc/changelog.gz > /usr/share/doc/unixodbc/copyright > /usr/share/lintian/overrides/unixodbc > /usr/share/man/man1/isql.1.gz > /usr/share/man/man1/iusql.1.gz > > > -- hendrik > From wagner at elegosoft.com Tue Aug 25 22:30:24 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 25 Aug 2009 22:30:24 +0200 Subject: [M3devel] timeout at the end of makedist? In-Reply-To: References: Message-ID: <20090825223024.wye2lz0is44004cs@mail.elegosoft.com> Quoting Jay K : > http://www.modula3.com:8080/view/SOLgnu/job/cm3-makedist-SOLgnu/14/console > > all the way at the bottom: > > -rw-r--r-- 1 hudson other 2785402 Aug 25 05:56 > /home/hudson/tmp/cm3-bin-ws-game-SOLgnu-5.8.3-RC3.tgz > Received disconnect from 88.198.39.217: 2: Timeout, your session not > responding. > lost connection > Finished: SUCCESS > > > > This is copying the packages to birch? > It shouldn't report success? > We should do some incremental copy? scp, like rcp, is inherently unsafe (though more secure) :-/ We should try rsync via ssh instead. Though all ssh-based transfer seems to be a bot unreliable (especially from/to your net). Do we have rsync on all systems? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Aug 25 23:11:33 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 25 Aug 2009 21:11:33 +0000 Subject: [M3devel] timeout at the end of makedist? In-Reply-To: <20090825223024.wye2lz0is44004cs@mail.elegosoft.com> References: <20090825223024.wye2lz0is44004cs@mail.elegosoft.com> Message-ID: > Do we have rsync on all systems? No idea. I've never used it. - Jay From hendrik at topoi.pooq.com Wed Aug 26 02:26:06 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 25 Aug 2009 20:26:06 -0400 Subject: [M3devel] small design problem in ButtonVBT? In-Reply-To: <20090401120347.x8cneize8oscg44o@mail.elegosoft.com> References: <20090331145127.GB9624@topoi.pooq.com> <20090401120347.x8cneize8oscg44o@mail.elegosoft.com> Message-ID: <20090826002606.GB16386@topoi.pooq.com> On Wed, Apr 01, 2009 at 12:03:47PM +0200, Olaf Wagner wrote: > Quoting hendrik at topoi.pooq.com: > > >The BottonVBT contains an action, which is a procedure rather than a > >method. b This makes it awkward to subclass ButtonVBT becaue the action > >will still expect its first parameter to be a ButtonVBT instead of > >belonging to the subclass, and an explicit downcast of some sort will be > >needed to acess the subclass's members. > > > >The Trestle manual says this was a deliberate decision: > > > >: The action procedure is a field rather than a method in order to allow > >: buttons with different action procedures to share their method suites. > > > >I, however, find it massively inconvenient because it mans I have to > >resort to downcasting or the very kludgey VBT.GetProp to access what > >should be just there. I'd rather the action procedure was a method. > > > >But it should be possible to have the best of both worlds. Have an > >action2 (better name wanted here) method that is available for > >overriding, and by default calls the procedure in the existing action. > >field. That action2 method wounl then be called by Trestle wherever > >action is now called. > > > >Does anyone see problems with this? > > Sounds fine to me offhand. You should test your extensions with > some of the existing larger applications, like mentor and Juno-2, > of course. OK. Here's the patch. Would it be possible for someone to check it in for me? mentor runs fine with this change; I watched it animate a heap-sort. I have no idea what Juno is supposed to do, but it did respond to button-pushes. hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ cvs diff cvs diff: Diffing . Index: ButtonVBT.i3 =================================================================== RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.i3,v retrieving revision 1.2 diff -r1.2 ButtonVBT.i3 39a40 > act(READONLY cd: VBT.MouseRec); Index: ButtonVBT.m3 =================================================================== RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.m3,v retrieving revision 1.2 diff -r1.2 ButtonVBT.m3 28c28,29 < init := Be --- > init := Be; > act := act 46a48,52 > PROCEDURE act(v : T; READONLY cd: VBT.MouseRec) = > BEGIN > v.action(v, cd); > END act; > 59c65 < v.action(v, cd); --- > v.act(cd); hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ -- hendrik From jay.krell at cornell.edu Wed Aug 26 09:02:56 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 26 Aug 2009 07:02:56 +0000 Subject: [M3devel] caltech-parser NT386 Hudson problems Message-ID: I think the caltech-parser on NT386 problems are related to line endings. I'm not sure. I see it outputing carriage returns and backslash line continuations -- though Modula-3 has no such line continuations. I haven't been able to find the code in caltech-parser that does that. http://www.modula3.com:8080/computer/elego-win-vm/configure I removed the CYGWIN variable, that previously was nobinmode. The tasks also fiddle around with the mount command. I think all the -o options should be removed. I've left it alone for now. We should try to make it work either way, perhaps. I'm not super keen on changing my local setting, nor debugging it remotely -- it is slow. If pushed I'll try changing my local setting. I set: C:\>set cyg CYGWIN=server but that's probably not needed. and: C:\>mount c:\cygwin\bin on /usr/bin type system (binmode) c:\cygwin\lib on /usr/lib type system (binmode) c:\cygwin on / type system (binmode) c:\obj on /obj type system (binmode) c:\src on /src type system (binmode) c: on /cygdrive/c type user (binmode,noumount) The caltech-parser/parerlib/parerlib/test directory works for me. I get newlines only in the output. Given that the caltech-parser binaries aren't cygwin binaries, I'm actually not sure how any of this could matter. Could be cvs though. Yes, that is a big possibility. For example I only got klex to output files by first running dos2unix on some files, which shouldn't do anything. caltech-parser should imho accept \r and \r\n as line delimiters. I'm not sure if empty lines are significant to it. If not, this is easy. If so, it appears not. It appears to split lines on single characters. - Jay From jay.krell at cornell.edu Wed Aug 26 09:18:03 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 26 Aug 2009 07:18:03 +0000 Subject: [M3devel] caltech-parser NT386 Hudson problems In-Reply-To: References: Message-ID: On second thought, upon further investigation, I changed all the mount commands. We'll see how that does. Probably should also re-checkout all the workspaces. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Date: Wed, 26 Aug 2009 07:02:56 +0000 > Subject: [M3devel] caltech-parser NT386 Hudson problems > > > I think the caltech-parser on NT386 problems are related to line endings. > I'm not sure. > I see it outputing carriage returns and backslash line continuations -- > though Modula-3 has no such line continuations. > I haven't been able to find the code in caltech-parser that does that. > > > http://www.modula3.com:8080/computer/elego-win-vm/configure > > > I removed the CYGWIN variable, that previously was nobinmode. > The tasks also fiddle around with the mount command. > I think all the -o options should be removed. > I've left it alone for now. > > > We should try to make it work either way, perhaps. > > > I'm not super keen on changing my local setting, nor debugging > it remotely -- it is slow. If pushed I'll try changing my local setting. > > > I set: > > > C:\>set cyg > CYGWIN=server > > > but that's probably not needed. > > and: > C:\>mount > c:\cygwin\bin on /usr/bin type system (binmode) > c:\cygwin\lib on /usr/lib type system (binmode) > c:\cygwin on / type system (binmode) > c:\obj on /obj type system (binmode) > c:\src on /src type system (binmode) > c: on /cygdrive/c type user (binmode,noumount) > > > The caltech-parser/parerlib/parerlib/test directory works for me. > I get newlines only in the output. > > > Given that the caltech-parser binaries aren't cygwin binaries, I'm > actually not sure how any of this could matter. > > > Could be cvs though. Yes, that is a big possibility. > For example I only got klex to output files by first running dos2unix on some > files, which shouldn't do anything. > > > caltech-parser should imho accept \r and \r\n as line delimiters. > I'm not sure if empty lines are significant to it. > If not, this is easy. > If so, it appears not. It appears to split lines on single characters. > > > - Jay From wagner at elegosoft.com Wed Aug 26 10:04:41 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 26 Aug 2009 10:04:41 +0200 Subject: [M3devel] small design problem in ButtonVBT? In-Reply-To: <20090826002606.GB16386@topoi.pooq.com> References: <20090331145127.GB9624@topoi.pooq.com> <20090401120347.x8cneize8oscg44o@mail.elegosoft.com> <20090826002606.GB16386@topoi.pooq.com> Message-ID: <20090826100441.ftj2zoekg0kook0w@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > OK. Here's the patch. Would it be possible for someone to check it in > for me? I can do that tonight if nobody is faster. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Aug 26 17:37:16 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 26 Aug 2009 15:37:16 +0000 Subject: [M3devel] running cm3 by relative path Message-ID: Running cm3 by relative path seems to act wierd. $ ./last-ok/bin/cm3 -version Critical Mass Modula-3 version 5.8.3 last updated: 2009-08-22 compiled: 2009-08-25 09:52:28 configuration: ./last-ok/bin/cm3.cfg host: SOLgnu quake runtime error: "./last-ok/bin/cm3.cfg", line 2: quake runtime error: unabl e to open "./last-ok/bin/./last-ok/bin/config/SOLsun" for reading --procedure-- -line- -file--- include -- 2 ./last-ok/bin/cm3.cfg target: $ `pwd`/last-ok/bin/cm3 -version Critical Mass Modula-3 version 5.8.3 last updated: 2009-08-22 compiled: 2009-08-25 09:52:28 configuration: /home/hudson/work/cm3-inst/ssol-sun/last-ok/bin/cm3.cfg host: SOLgnu target: SOLsun I'll have to see if this is related to my recent change or not. I'm also seemingly not able to change host to SOLsun from SOLgnu but that's not likely a bug in cm3. -Jay From hendrik at topoi.pooq.com Wed Aug 26 20:44:17 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 26 Aug 2009 14:44:17 -0400 Subject: [M3devel] trying RC3 In-Reply-To: References: <20090824005658.GA11486@topoi.pooq.com> <20090824013245.GA11619@topoi.pooq.com> Message-ID: <20090826184417.GA18029@topoi.pooq.com> On Mon, Aug 24, 2009 at 02:43:52AM +0000, Jay K wrote: > > In CVS. > > - Jay Now that it seems some RC3 packages are being rebuilt, will this include new builds for LINUXLIBC6? If so, I'll try again with the new RC3. If not, I'll just wait for RC4. By the wat, P.S. I'm not sitting on he edge of my seat, waiting for a usable cvsup release. I have compiled my own. What I'm really doing here is testing the tgz packages. Just let me know when it's useful to test again. -- hendrik > > > ---------------------------------------- > > Date: Sun, 23 Aug 2009 21:32:45 -0400 > > From: hendrik at topoi.pooq.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] trying RC3 > > > > On Mon, Aug 24, 2009 at 01:07:25AM +0000, Jay K wrote: > >> > >> This is understood and fixed, specific to cvsup. > > > > Does 'fixed' mean you've replaced the RC3 archive, in which case I'll > > try it again soon, or that it'll be OK in RC4? > > > > Or just fixed in CVS? > > > >> > >> Thanks, > >> - Jay > > > > You're welcome. Each time a new RC comes out, I shunt aside my existing > > cm3, and try an install. Then I report on the problems, and move the > > working cm3 back. > > > > I'll spend some time this week testing the other ws-packages. > > > > Thanks. > > > > -- hendrik > > From wagner at elegosoft.com Thu Aug 27 08:06:57 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 27 Aug 2009 08:06:57 +0200 Subject: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems In-Reply-To: References: <20090826142644.r6yabwff5wc84cgg@mail.elegosoft.com> Message-ID: <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> Quoting Jay K : > Something or some things very wierd here. I'll keep looking into it. I'm not sure if we should spend/waste(?) more time in trying to make this VM with Windows work. Last night I reactivated my own qemu-based VM and was able to checkout and build some current CM3 stuff. CVS behaves correctly there, and no need to adapt any of the shell scripts at all. It's agonizingly slow though. And it has no remote access. However, building the release archives failed with two errors: vbtkit: new source -> compiling VBTKitResources.m3 "..\src\lego\VBTKitResources.m3", line 10: unable to find interface (VBTKitBundle) 1 error encountered and errors during build-all; some packages will be missing m3-win/import-libs/NT386/.M3SHIP seems to be broken: make_dir("c:/tmp/cm3/lib") install_file("wsock32.lib", "c:/tmp/cm3/lib", "0775") install_file("advapi32.lib", "c:/tmp/cm3/lib", "0775") install_file("opengl32.lib", "c:/tmp/cm3/lib", "0775") install_file("netapi32.lib", "c:/tmp/cm3/lib", "0775") install_file("comctl32.lib", "c:/tmp/cm3/lib", "0775") install_file("user32.lib", "c:/tmp/cm3/lib", "0775") install_file("comdlg32.lib", "c:/tmp/cm3/lib", "0775") install_file("kernel32.lib", "c:/tmp/cm3/lib", "0775") install_file("winspool.lib", "c:/tmp/cm3/lib", "0775") install_file("glu32.lib", "c:/tmp/cm3/lib", "0775") install_file("gdi32.lib", "c:/tmp/cm3/lib", "0775") install_file("odbc32.lib", "c:/tmp/cm3/lib", "0775") (wrong shippind destination, already reported) I suggest we rather concentrate on these and build the Windows packages manually. I'm off to (paid) work again now... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Aug 27 08:09:52 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 27 Aug 2009 06:09:52 +0000 Subject: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems In-Reply-To: <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> References: <20090826142644.r6yabwff5wc84cgg@mail.elegosoft.com> <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> Message-ID: I'm testing a fix for the VM right now actually. Once that works I'll look into the Unresolve problem further. I put in some printing to help diagnose it and possibly a fix. It could be a slash mixup; the printing will tell us. The VBT problem is new seeming. I'll look at that too. Anyone else is welcome to also. - Jay ---------------------------------------- > Date: Thu, 27 Aug 2009 08:06:57 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems > > Quoting Jay K : > >> Something or some things very wierd here. I'll keep looking into it. > I'm not sure if we should spend/waste(?) more time in trying to make > this VM with Windows work. > > Last night I reactivated my own qemu-based VM and was able to checkout > and build some current CM3 stuff. > > CVS behaves correctly there, and no need to adapt any of the shell > scripts at all. It's agonizingly slow though. And it has no remote > access. > > However, building the release archives failed with two errors: > > vbtkit: > new source -> compiling VBTKitResources.m3 > "..\src\lego\VBTKitResources.m3", line 10: unable to find interface > (VBTKitBundle) > 1 error encountered > > and > > errors during build-all; some packages will be missing > m3-win/import-libs/NT386/.M3SHIP seems to be broken: > make_dir("c:/tmp/cm3/lib") > install_file("wsock32.lib", "c:/tmp/cm3/lib", "0775") > install_file("advapi32.lib", "c:/tmp/cm3/lib", "0775") > install_file("opengl32.lib", "c:/tmp/cm3/lib", "0775") > install_file("netapi32.lib", "c:/tmp/cm3/lib", "0775") > install_file("comctl32.lib", "c:/tmp/cm3/lib", "0775") > install_file("user32.lib", "c:/tmp/cm3/lib", "0775") > install_file("comdlg32.lib", "c:/tmp/cm3/lib", "0775") > install_file("kernel32.lib", "c:/tmp/cm3/lib", "0775") > install_file("winspool.lib", "c:/tmp/cm3/lib", "0775") > install_file("glu32.lib", "c:/tmp/cm3/lib", "0775") > install_file("gdi32.lib", "c:/tmp/cm3/lib", "0775") > install_file("odbc32.lib", "c:/tmp/cm3/lib", "0775") > > (wrong shippind destination, already reported) > > I suggest we rather concentrate on these and build the Windows > packages manually. > > I'm off to (paid) work again now... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Thu Aug 27 08:41:46 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 27 Aug 2009 06:41:46 +0000 Subject: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems In-Reply-To: References: <20090826142644.r6yabwff5wc84cgg@mail.elegosoft.com> <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> Message-ID: >> vbtkit: >> new source -> compiling VBTKitResources.m3 >> "..\src\lego\VBTKitResources.m3", line 10: unable to find interface >> (VBTKitBundle) >> 1 error encountered Is m3bundle working for you? In head I have the files: C:\dev2\cm3.2\m3-ui\vbtkit>dir /s/b *kit*bund* C:\dev2\cm3.2\m3-ui\vbtkit\NT386\VBTKitBundle.i3 C:\dev2\cm3.2\m3-ui\vbtkit\NT386\VBTKitBundle.io C:\dev2\cm3.2\m3-ui\vbtkit\NT386\VBTKitBundle.m3 C:\dev2\cm3.2\m3-ui\vbtkit\NT386\VBTKitBundle.mo - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > Date: Thu, 27 Aug 2009 06:09:52 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems > > > I'm testing a fix for the VM right now actually. > Once that works I'll look into the Unresolve problem further. I put in some printing to help diagnose it and possibly a fix. It could be a slash mixup; the printing will tell us. > The VBT problem is new seeming. I'll look at that too. > Anyone else is welcome to also. > > - Jay > > > ---------------------------------------- >> Date: Thu, 27 Aug 2009 08:06:57 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems >> >> Quoting Jay K : >> >>> Something or some things very wierd here. I'll keep looking into it. >> I'm not sure if we should spend/waste(?) more time in trying to make >> this VM with Windows work. >> >> Last night I reactivated my own qemu-based VM and was able to checkout >> and build some current CM3 stuff. >> >> CVS behaves correctly there, and no need to adapt any of the shell >> scripts at all. It's agonizingly slow though. And it has no remote >> access. >> >> However, building the release archives failed with two errors: >> >> vbtkit: >> new source -> compiling VBTKitResources.m3 >> "..\src\lego\VBTKitResources.m3", line 10: unable to find interface >> (VBTKitBundle) >> 1 error encountered >> >> and >> >> errors during build-all; some packages will be missing >> m3-win/import-libs/NT386/.M3SHIP seems to be broken: >> make_dir("c:/tmp/cm3/lib") >> install_file("wsock32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("advapi32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("opengl32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("netapi32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("comctl32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("user32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("comdlg32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("kernel32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("winspool.lib", "c:/tmp/cm3/lib", "0775") >> install_file("glu32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("gdi32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("odbc32.lib", "c:/tmp/cm3/lib", "0775") >> >> (wrong shippind destination, already reported) >> >> I suggest we rather concentrate on these and build the Windows >> packages manually. >> >> I'm off to (paid) work again now... >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> From wagner at elegosoft.com Thu Aug 27 10:02:42 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 27 Aug 2009 10:02:42 +0200 Subject: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems In-Reply-To: References: <20090826142644.r6yabwff5wc84cgg@mail.elegosoft.com> <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> Message-ID: <20090827100242.uyc9fca968s480c4@mail.elegosoft.com> Quoting Jay K : >>> vbtkit: >>> new source -> compiling VBTKitResources.m3 >>> "..\src\lego\VBTKitResources.m3", line 10: unable to find interface >>> (VBTKitBundle) >>> 1 error encountered > > Is m3bundle working for you? > In head I have the files: > > C:\dev2\cm3.2\m3-ui\vbtkit>dir /s/b *kit*bund* > C:\dev2\cm3.2\m3-ui\vbtkit\NT386\VBTKitBundle.i3 > C:\dev2\cm3.2\m3-ui\vbtkit\NT386\VBTKitBundle.io > C:\dev2\cm3.2\m3-ui\vbtkit\NT386\VBTKitBundle.m3 > C:\dev2\cm3.2\m3-ui\vbtkit\NT386\VBTKitBundle.mo Sorry, I cannot check from here. I only remember that the missing interfaces seemed to be the first problem. Maybe I've overseeen failing m3bundle calls though. Strange. Olaf > - Jay > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com >> Date: Thu, 27 Aug 2009 06:09:52 +0000 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] RC3 build problems, was: RE: caltech-parser >> NT386 Hudson problems >> >> >> I'm testing a fix for the VM right now actually. >> Once that works I'll look into the Unresolve problem further. I put >> in some printing to help diagnose it and possibly a fix. It could >> be a slash mixup; the printing will tell us. >> The VBT problem is new seeming. I'll look at that too. >> Anyone else is welcome to also. >> >> - Jay >> >> >> ---------------------------------------- >>> Date: Thu, 27 Aug 2009 08:06:57 +0200 >>> From: wagner at elegosoft.com >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com >>> Subject: [M3devel] RC3 build problems, was: RE: caltech-parser >>> NT386 Hudson problems >>> >>> Quoting Jay K : >>> >>>> Something or some things very wierd here. I'll keep looking into it. >>> I'm not sure if we should spend/waste(?) more time in trying to make >>> this VM with Windows work. >>> >>> Last night I reactivated my own qemu-based VM and was able to checkout >>> and build some current CM3 stuff. >>> >>> CVS behaves correctly there, and no need to adapt any of the shell >>> scripts at all. It's agonizingly slow though. And it has no remote >>> access. >>> >>> However, building the release archives failed with two errors: >>> >>> vbtkit: >>> new source -> compiling VBTKitResources.m3 >>> "..\src\lego\VBTKitResources.m3", line 10: unable to find interface >>> (VBTKitBundle) >>> 1 error encountered >>> >>> and >>> >>> errors during build-all; some packages will be missing >>> m3-win/import-libs/NT386/.M3SHIP seems to be broken: >>> make_dir("c:/tmp/cm3/lib") >>> install_file("wsock32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("advapi32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("opengl32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("netapi32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("comctl32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("user32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("comdlg32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("kernel32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("winspool.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("glu32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("gdi32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("odbc32.lib", "c:/tmp/cm3/lib", "0775") >>> >>> (wrong shippind destination, already reported) >>> >>> I suggest we rather concentrate on these and build the Windows >>> packages manually. >>> >>> I'm off to (paid) work again now... >>> >>> Olaf >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Aug 27 14:14:02 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 27 Aug 2009 12:14:02 +0000 Subject: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems In-Reply-To: <20090827100242.uyc9fca968s480c4@mail.elegosoft.com> References: <20090826142644.r6yabwff5wc84cgg@mail.elegosoft.com> <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> <20090827100242.uyc9fca968s480c4@mail.elegosoft.com> Message-ID: Maybe your initial install lacked it? - Jay ---------------------------------------- > Date: Thu, 27 Aug 2009 10:02:42 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems > > Quoting Jay K : > >>>> vbtkit: >>>> new source -> compiling VBTKitResources.m3 >>>> "..\src\lego\VBTKitResources.m3", line 10: unable to find interface >>>> (VBTKitBundle) >>>> 1 error encountered >> >> Is m3bundle working for you? >> In head I have the files: >> >> C:\dev2\cm3.2\m3-ui\vbtkit>dir /s/b *kit*bund* >> C:\dev2\cm3.2\m3-ui\vbtkit\NT386\VBTKitBundle.i3 >> C:\dev2\cm3.2\m3-ui\vbtkit\NT386\VBTKitBundle.io >> C:\dev2\cm3.2\m3-ui\vbtkit\NT386\VBTKitBundle.m3 >> C:\dev2\cm3.2\m3-ui\vbtkit\NT386\VBTKitBundle.mo > > Sorry, I cannot check from here. I only remember that the > missing interfaces seemed to be the first problem. Maybe I've > overseeen failing m3bundle calls though. Strange. > > Olaf > >> - Jay >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: wagner at elegosoft.com >>> Date: Thu, 27 Aug 2009 06:09:52 +0000 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] RC3 build problems, was: RE: caltech-parser >>> NT386 Hudson problems >>> >>> >>> I'm testing a fix for the VM right now actually. >>> Once that works I'll look into the Unresolve problem further. I put >>> in some printing to help diagnose it and possibly a fix. It could >>> be a slash mixup; the printing will tell us. >>> The VBT problem is new seeming. I'll look at that too. >>> Anyone else is welcome to also. >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> Date: Thu, 27 Aug 2009 08:06:57 +0200 >>>> From: wagner at elegosoft.com >>>> To: jay.krell at cornell.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: [M3devel] RC3 build problems, was: RE: caltech-parser >>>> NT386 Hudson problems >>>> >>>> Quoting Jay K : >>>> >>>>> Something or some things very wierd here. I'll keep looking into it. >>>> I'm not sure if we should spend/waste(?) more time in trying to make >>>> this VM with Windows work. >>>> >>>> Last night I reactivated my own qemu-based VM and was able to checkout >>>> and build some current CM3 stuff. >>>> >>>> CVS behaves correctly there, and no need to adapt any of the shell >>>> scripts at all. It's agonizingly slow though. And it has no remote >>>> access. >>>> >>>> However, building the release archives failed with two errors: >>>> >>>> vbtkit: >>>> new source -> compiling VBTKitResources.m3 >>>> "..\src\lego\VBTKitResources.m3", line 10: unable to find interface >>>> (VBTKitBundle) >>>> 1 error encountered >>>> >>>> and >>>> >>>> errors during build-all; some packages will be missing >>>> m3-win/import-libs/NT386/.M3SHIP seems to be broken: >>>> make_dir("c:/tmp/cm3/lib") >>>> install_file("wsock32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("advapi32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("opengl32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("netapi32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("comctl32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("user32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("comdlg32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("kernel32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("winspool.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("glu32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("gdi32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("odbc32.lib", "c:/tmp/cm3/lib", "0775") >>>> >>>> (wrong shippind destination, already reported) >>>> >>>> I suggest we rather concentrate on these and build the Windows >>>> packages manually. >>>> >>>> I'm off to (paid) work again now... >>>> >>>> Olaf >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>> DE163214194 >>>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Thu Aug 27 14:15:14 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 27 Aug 2009 12:15:14 +0000 Subject: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems In-Reply-To: <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> References: <20090826142644.r6yabwff5wc84cgg@mail.elegosoft.com> <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> Message-ID: My current theory is the unresolve problem is due to that wierd initial build of import-libs in the Hudson task, which was related to the line endings problem, which was related to using CVSNT instead of Cygwin cvs. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems > Date: Thu, 27 Aug 2009 06:09:52 +0000 > > > I'm testing a fix for the VM right now actually. > Once that works I'll look into the Unresolve problem further. I put in some printing to help diagnose it and possibly a fix. It could be a slash mixup; the printing will tell us. > The VBT problem is new seeming. I'll look at that too. > Anyone else is welcome to also. > > - Jay > > > ---------------------------------------- >> Date: Thu, 27 Aug 2009 08:06:57 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems >> >> Quoting Jay K : >> >>> Something or some things very wierd here. I'll keep looking into it. >> I'm not sure if we should spend/waste(?) more time in trying to make >> this VM with Windows work. >> >> Last night I reactivated my own qemu-based VM and was able to checkout >> and build some current CM3 stuff. >> >> CVS behaves correctly there, and no need to adapt any of the shell >> scripts at all. It's agonizingly slow though. And it has no remote >> access. >> >> However, building the release archives failed with two errors: >> >> vbtkit: >> new source -> compiling VBTKitResources.m3 >> "..\src\lego\VBTKitResources.m3", line 10: unable to find interface >> (VBTKitBundle) >> 1 error encountered >> >> and >> >> errors during build-all; some packages will be missing >> m3-win/import-libs/NT386/.M3SHIP seems to be broken: >> make_dir("c:/tmp/cm3/lib") >> install_file("wsock32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("advapi32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("opengl32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("netapi32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("comctl32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("user32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("comdlg32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("kernel32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("winspool.lib", "c:/tmp/cm3/lib", "0775") >> install_file("glu32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("gdi32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("odbc32.lib", "c:/tmp/cm3/lib", "0775") >> >> (wrong shippind destination, already reported) >> >> I suggest we rather concentrate on these and build the Windows >> packages manually. >> >> I'm off to (paid) work again now... >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> From wagner at elegosoft.com Thu Aug 27 14:17:41 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 27 Aug 2009 14:17:41 +0200 Subject: [M3devel] small design problem in ButtonVBT? In-Reply-To: <20090826002606.GB16386@topoi.pooq.com> References: <20090331145127.GB9624@topoi.pooq.com> <20090401120347.x8cneize8oscg44o@mail.elegosoft.com> <20090826002606.GB16386@topoi.pooq.com> Message-ID: <20090827141741.9g1u2vrgfgokkksg@mail.elegosoft.com> Though I promised to do it, I have lost sight of this task while trying to build some RC3 archives on Windows. As I'm not at home this evening, can somebody else please commit Hendrik's extension? Is this something we should should have in the release branch, too? Probably not necessary? Olaf Quoting hendrik at topoi.pooq.com: > On Wed, Apr 01, 2009 at 12:03:47PM +0200, Olaf Wagner wrote: >> Quoting hendrik at topoi.pooq.com: >> >> >The BottonVBT contains an action, which is a procedure rather than a >> >method. b This makes it awkward to subclass ButtonVBT becaue the action >> >will still expect its first parameter to be a ButtonVBT instead of >> >belonging to the subclass, and an explicit downcast of some sort will be >> >needed to acess the subclass's members. >> > >> >The Trestle manual says this was a deliberate decision: >> > >> >: The action procedure is a field rather than a method in order to allow >> >: buttons with different action procedures to share their method suites. >> > >> >I, however, find it massively inconvenient because it mans I have to >> >resort to downcasting or the very kludgey VBT.GetProp to access what >> >should be just there. I'd rather the action procedure was a method. >> > >> >But it should be possible to have the best of both worlds. Have an >> >action2 (better name wanted here) method that is available for >> >overriding, and by default calls the procedure in the existing action. >> >field. That action2 method wounl then be called by Trestle wherever >> >action is now called. >> > >> >Does anyone see problems with this? >> >> Sounds fine to me offhand. You should test your extensions with >> some of the existing larger applications, like mentor and Juno-2, >> of course. > > OK. Here's the patch. Would it be possible for someone to check it in > for me? > > mentor runs fine with this change; I watched it animate a heap-sort. > > I have no idea what Juno is supposed to do, but it did respond to > button-pushes. > > > hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ cvs diff > cvs diff: Diffing . > Index: ButtonVBT.i3 > =================================================================== > RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.i3,v > retrieving revision 1.2 > diff -r1.2 ButtonVBT.i3 > 39a40 >> act(READONLY cd: VBT.MouseRec); > Index: ButtonVBT.m3 > =================================================================== > RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.m3,v > retrieving revision 1.2 > diff -r1.2 ButtonVBT.m3 > 28c28,29 > < init := Be > --- >> init := Be; >> act := act > 46a48,52 >> PROCEDURE act(v : T; READONLY cd: VBT.MouseRec) = >> BEGIN >> v.action(v, cd); >> END act; >> > 59c65 > < v.action(v, cd); > --- >> v.act(cd); > hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ > > -- hendrik > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Thu Aug 27 14:22:01 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 27 Aug 2009 14:22:01 +0200 Subject: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems In-Reply-To: References: <20090826142644.r6yabwff5wc84cgg@mail.elegosoft.com> <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> Message-ID: <20090827142201.qim3orxd4488ssss@mail.elegosoft.com> Quoting Jay K : > My current theory is the unresolve problem is due to that wierd > initial build of import-libs in the Hudson task, which was related > to the line endings problem, which was related to using CVSNT > instead of Cygwin cvs. Hm, I don't think so, as is happend in my Home-VM, too. And there's everything with proper NL endings. As for m3bundle, that should have been built by do-cm3-core.sh long before the build of vbtkit fails. But I cannot really check until tomorrow evening. Olaf > - Jay > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] RC3 build problems, was: RE: caltech-parser >> NT386 Hudson problems >> Date: Thu, 27 Aug 2009 06:09:52 +0000 >> >> >> I'm testing a fix for the VM right now actually. >> Once that works I'll look into the Unresolve problem further. I put >> in some printing to help diagnose it and possibly a fix. It could >> be a slash mixup; the printing will tell us. >> The VBT problem is new seeming. I'll look at that too. >> Anyone else is welcome to also. >> >> - Jay >> >> >> ---------------------------------------- >>> Date: Thu, 27 Aug 2009 08:06:57 +0200 >>> From: wagner at elegosoft.com >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com >>> Subject: [M3devel] RC3 build problems, was: RE: caltech-parser >>> NT386 Hudson problems >>> >>> Quoting Jay K : >>> >>>> Something or some things very wierd here. I'll keep looking into it. >>> I'm not sure if we should spend/waste(?) more time in trying to make >>> this VM with Windows work. >>> >>> Last night I reactivated my own qemu-based VM and was able to checkout >>> and build some current CM3 stuff. >>> >>> CVS behaves correctly there, and no need to adapt any of the shell >>> scripts at all. It's agonizingly slow though. And it has no remote >>> access. >>> >>> However, building the release archives failed with two errors: >>> >>> vbtkit: >>> new source -> compiling VBTKitResources.m3 >>> "..\src\lego\VBTKitResources.m3", line 10: unable to find interface >>> (VBTKitBundle) >>> 1 error encountered >>> >>> and >>> >>> errors during build-all; some packages will be missing >>> m3-win/import-libs/NT386/.M3SHIP seems to be broken: >>> make_dir("c:/tmp/cm3/lib") >>> install_file("wsock32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("advapi32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("opengl32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("netapi32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("comctl32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("user32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("comdlg32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("kernel32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("winspool.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("glu32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("gdi32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("odbc32.lib", "c:/tmp/cm3/lib", "0775") >>> >>> (wrong shippind destination, already reported) >>> >>> I suggest we rather concentrate on these and build the Windows >>> packages manually. >>> >>> I'm off to (paid) work again now... -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Aug 27 14:28:49 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 27 Aug 2009 12:28:49 +0000 Subject: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems In-Reply-To: <20090827142201.qim3orxd4488ssss@mail.elegosoft.com> References: <20090826142644.r6yabwff5wc84cgg@mail.elegosoft.com> <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> <20090827142201.qim3orxd4488ssss@mail.elegosoft.com> Message-ID: The debugprint doesn't show up. http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/cm3/src/M3Build.m3?r1=1.28.2.4&r2=1.28.2.5 could be tools aren't updated yet. But that is also explained by my theory. Are you sure? I've put in realclean for this package in the Hudson task. I'll do another release and lastok build. We'll see. - Jay ---------------------------------------- > Date: Thu, 27 Aug 2009 14:22:01 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems > > Quoting Jay K : > >> My current theory is the unresolve problem is due to that wierd >> initial build of import-libs in the Hudson task, which was related >> to the line endings problem, which was related to using CVSNT >> instead of Cygwin cvs. > > Hm, I don't think so, as is happend in my Home-VM, too. > And there's everything with proper NL endings. > > As for m3bundle, that should have been built by do-cm3-core.sh > long before the build of vbtkit fails. > > But I cannot really check until tomorrow evening. > > Olaf > >> - Jay >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: wagner at elegosoft.com >>> CC: m3devel at elegosoft.com >>> Subject: RE: [M3devel] RC3 build problems, was: RE: caltech-parser >>> NT386 Hudson problems >>> Date: Thu, 27 Aug 2009 06:09:52 +0000 >>> >>> >>> I'm testing a fix for the VM right now actually. >>> Once that works I'll look into the Unresolve problem further. I put >>> in some printing to help diagnose it and possibly a fix. It could >>> be a slash mixup; the printing will tell us. >>> The VBT problem is new seeming. I'll look at that too. >>> Anyone else is welcome to also. >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> Date: Thu, 27 Aug 2009 08:06:57 +0200 >>>> From: wagner at elegosoft.com >>>> To: jay.krell at cornell.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: [M3devel] RC3 build problems, was: RE: caltech-parser >>>> NT386 Hudson problems >>>> >>>> Quoting Jay K : >>>> >>>>> Something or some things very wierd here. I'll keep looking into it. >>>> I'm not sure if we should spend/waste(?) more time in trying to make >>>> this VM with Windows work. >>>> >>>> Last night I reactivated my own qemu-based VM and was able to checkout >>>> and build some current CM3 stuff. >>>> >>>> CVS behaves correctly there, and no need to adapt any of the shell >>>> scripts at all. It's agonizingly slow though. And it has no remote >>>> access. >>>> >>>> However, building the release archives failed with two errors: >>>> >>>> vbtkit: >>>> new source -> compiling VBTKitResources.m3 >>>> "..\src\lego\VBTKitResources.m3", line 10: unable to find interface >>>> (VBTKitBundle) >>>> 1 error encountered >>>> >>>> and >>>> >>>> errors during build-all; some packages will be missing >>>> m3-win/import-libs/NT386/.M3SHIP seems to be broken: >>>> make_dir("c:/tmp/cm3/lib") >>>> install_file("wsock32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("advapi32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("opengl32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("netapi32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("comctl32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("user32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("comdlg32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("kernel32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("winspool.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("glu32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("gdi32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("odbc32.lib", "c:/tmp/cm3/lib", "0775") >>>> >>>> (wrong shippind destination, already reported) >>>> >>>> I suggest we rather concentrate on these and build the Windows >>>> packages manually. >>>> >>>> I'm off to (paid) work again now... > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Thu Aug 27 14:37:21 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 27 Aug 2009 12:37:21 +0000 Subject: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems In-Reply-To: <20090827142201.qim3orxd4488ssss@mail.elegosoft.com> References: <20090826142644.r6yabwff5wc84cgg@mail.elegosoft.com> <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> <20090827142201.qim3orxd4488ssss@mail.elegosoft.com> Message-ID: ps: It doesn't take CVSNT to cause this, but the workaround of building import-libs up front w/o noresolve. I assume you were missing m3bundle, as consistently build ok here in the birch VM and on my machine. - Jay ---------------------------------------- > Date: Thu, 27 Aug 2009 14:22:01 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems > > Quoting Jay K : > >> My current theory is the unresolve problem is due to that wierd >> initial build of import-libs in the Hudson task, which was related >> to the line endings problem, which was related to using CVSNT >> instead of Cygwin cvs. > > Hm, I don't think so, as is happend in my Home-VM, too. > And there's everything with proper NL endings. > > As for m3bundle, that should have been built by do-cm3-core.sh > long before the build of vbtkit fails. > > But I cannot really check until tomorrow evening. > > Olaf > >> - Jay >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: wagner at elegosoft.com >>> CC: m3devel at elegosoft.com >>> Subject: RE: [M3devel] RC3 build problems, was: RE: caltech-parser >>> NT386 Hudson problems >>> Date: Thu, 27 Aug 2009 06:09:52 +0000 >>> >>> >>> I'm testing a fix for the VM right now actually. >>> Once that works I'll look into the Unresolve problem further. I put >>> in some printing to help diagnose it and possibly a fix. It could >>> be a slash mixup; the printing will tell us. >>> The VBT problem is new seeming. I'll look at that too. >>> Anyone else is welcome to also. >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> Date: Thu, 27 Aug 2009 08:06:57 +0200 >>>> From: wagner at elegosoft.com >>>> To: jay.krell at cornell.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: [M3devel] RC3 build problems, was: RE: caltech-parser >>>> NT386 Hudson problems >>>> >>>> Quoting Jay K : >>>> >>>>> Something or some things very wierd here. I'll keep looking into it. >>>> I'm not sure if we should spend/waste(?) more time in trying to make >>>> this VM with Windows work. >>>> >>>> Last night I reactivated my own qemu-based VM and was able to checkout >>>> and build some current CM3 stuff. >>>> >>>> CVS behaves correctly there, and no need to adapt any of the shell >>>> scripts at all. It's agonizingly slow though. And it has no remote >>>> access. >>>> >>>> However, building the release archives failed with two errors: >>>> >>>> vbtkit: >>>> new source -> compiling VBTKitResources.m3 >>>> "..\src\lego\VBTKitResources.m3", line 10: unable to find interface >>>> (VBTKitBundle) >>>> 1 error encountered >>>> >>>> and >>>> >>>> errors during build-all; some packages will be missing >>>> m3-win/import-libs/NT386/.M3SHIP seems to be broken: >>>> make_dir("c:/tmp/cm3/lib") >>>> install_file("wsock32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("advapi32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("opengl32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("netapi32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("comctl32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("user32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("comdlg32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("kernel32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("winspool.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("glu32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("gdi32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("odbc32.lib", "c:/tmp/cm3/lib", "0775") >>>> >>>> (wrong shippind destination, already reported) >>>> >>>> I suggest we rather concentrate on these and build the Windows >>>> packages manually. >>>> >>>> I'm off to (paid) work again now... > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From wagner at elegosoft.com Thu Aug 27 15:50:56 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 27 Aug 2009 15:50:56 +0200 Subject: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems In-Reply-To: References: <20090826142644.r6yabwff5wc84cgg@mail.elegosoft.com> <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> <20090827142201.qim3orxd4488ssss@mail.elegosoft.com> Message-ID: <20090827155056.7tsrrlb0qo8c0sc4@mail.elegosoft.com> Quoting Jay K : > > ps: It doesn't take CVSNT to cause this, but the workaround of > building import-libs up front w/o noresolve. > I assume you were missing m3bundle, as consistently build ok here in > the birch VM and on my machine. Ah, so we should probably use the unresolve switch for all packages in upgrade, too? Olaf > - Jay > > > ---------------------------------------- >> Date: Thu, 27 Aug 2009 14:22:01 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] RC3 build problems, was: RE: caltech-parser >> NT386 Hudson problems >> >> Quoting Jay K : >> >>> My current theory is the unresolve problem is due to that wierd >>> initial build of import-libs in the Hudson task, which was related >>> to the line endings problem, which was related to using CVSNT >>> instead of Cygwin cvs. >> >> Hm, I don't think so, as is happend in my Home-VM, too. >> And there's everything with proper NL endings. >> >> As for m3bundle, that should have been built by do-cm3-core.sh >> long before the build of vbtkit fails. >> >> But I cannot really check until tomorrow evening. >> >> Olaf >> >>> - Jay >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: wagner at elegosoft.com >>>> CC: m3devel at elegosoft.com >>>> Subject: RE: [M3devel] RC3 build problems, was: RE: caltech-parser >>>> NT386 Hudson problems >>>> Date: Thu, 27 Aug 2009 06:09:52 +0000 >>>> >>>> >>>> I'm testing a fix for the VM right now actually. >>>> Once that works I'll look into the Unresolve problem further. I put >>>> in some printing to help diagnose it and possibly a fix. It could >>>> be a slash mixup; the printing will tell us. >>>> The VBT problem is new seeming. I'll look at that too. >>>> Anyone else is welcome to also. >>>> >>>> - Jay >>>> >>>> >>>> ---------------------------------------- >>>>> Date: Thu, 27 Aug 2009 08:06:57 +0200 >>>>> From: wagner at elegosoft.com >>>>> To: jay.krell at cornell.edu >>>>> CC: m3devel at elegosoft.com >>>>> Subject: [M3devel] RC3 build problems, was: RE: caltech-parser >>>>> NT386 Hudson problems >>>>> >>>>> Quoting Jay K : >>>>> >>>>>> Something or some things very wierd here. I'll keep looking into it. >>>>> I'm not sure if we should spend/waste(?) more time in trying to make >>>>> this VM with Windows work. >>>>> >>>>> Last night I reactivated my own qemu-based VM and was able to checkout >>>>> and build some current CM3 stuff. >>>>> >>>>> CVS behaves correctly there, and no need to adapt any of the shell >>>>> scripts at all. It's agonizingly slow though. And it has no remote >>>>> access. >>>>> >>>>> However, building the release archives failed with two errors: >>>>> >>>>> vbtkit: >>>>> new source -> compiling VBTKitResources.m3 >>>>> "..\src\lego\VBTKitResources.m3", line 10: unable to find interface >>>>> (VBTKitBundle) >>>>> 1 error encountered >>>>> >>>>> and >>>>> >>>>> errors during build-all; some packages will be missing >>>>> m3-win/import-libs/NT386/.M3SHIP seems to be broken: >>>>> make_dir("c:/tmp/cm3/lib") >>>>> install_file("wsock32.lib", "c:/tmp/cm3/lib", "0775") >>>>> install_file("advapi32.lib", "c:/tmp/cm3/lib", "0775") >>>>> install_file("opengl32.lib", "c:/tmp/cm3/lib", "0775") >>>>> install_file("netapi32.lib", "c:/tmp/cm3/lib", "0775") >>>>> install_file("comctl32.lib", "c:/tmp/cm3/lib", "0775") >>>>> install_file("user32.lib", "c:/tmp/cm3/lib", "0775") >>>>> install_file("comdlg32.lib", "c:/tmp/cm3/lib", "0775") >>>>> install_file("kernel32.lib", "c:/tmp/cm3/lib", "0775") >>>>> install_file("winspool.lib", "c:/tmp/cm3/lib", "0775") >>>>> install_file("glu32.lib", "c:/tmp/cm3/lib", "0775") >>>>> install_file("gdi32.lib", "c:/tmp/cm3/lib", "0775") >>>>> install_file("odbc32.lib", "c:/tmp/cm3/lib", "0775") >>>>> >>>>> (wrong shippind destination, already reported) >>>>> >>>>> I suggest we rather concentrate on these and build the Windows >>>>> packages manually. >>>>> >>>>> I'm off to (paid) work again now... >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Thu Aug 27 16:17:43 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 27 Aug 2009 16:17:43 +0200 Subject: [M3devel] m3gdb build error in RC3 Message-ID: <20090827161743.mkz8qhp7lco88og8@mail.elegosoft.com> I just found this in Hudson for AMD64_LINUX: http://hudson.modula3.com:8080/view/AMD64_LINUX/job/cm3-test-all-pkgs-AMD64_LINUX/lastBuild/testReport/(root)/CM3%20package%20build%20status/m3_sys_m3gdb/ I've created ticket #1067 for it. Perhaps a wrong/incomplete merge of changes from the main trunk? (I may be the culprit myself, though I'm sure I remember to have compiled m3gdb after merging some changes some days ago.) @Rodney, did you get the account information for trac I sent you? I took the liberty to assign the new ticket to you, too :-) #1058 is not closed yet, too, though you had fixed that. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Thu Aug 27 16:20:11 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 27 Aug 2009 10:20:11 -0400 Subject: [M3devel] small design problem in ButtonVBT? In-Reply-To: <20090827141741.9g1u2vrgfgokkksg@mail.elegosoft.com> References: <20090331145127.GB9624@topoi.pooq.com> <20090401120347.x8cneize8oscg44o@mail.elegosoft.com> <20090826002606.GB16386@topoi.pooq.com> <20090827141741.9g1u2vrgfgokkksg@mail.elegosoft.com> Message-ID: <88690174-5B88-442C-816C-4CACBCB2CDEF@cs.purdue.edu> I'll do it. On 27 Aug 2009, at 08:17, Olaf Wagner wrote: > Though I promised to do it, I have lost sight of this task while > trying to build some RC3 archives on Windows. As I'm not at home this > evening, can somebody else please commit Hendrik's extension? > > Is this something we should should have in the release branch, too? > Probably not necessary? > > Olaf > > Quoting hendrik at topoi.pooq.com: > >> On Wed, Apr 01, 2009 at 12:03:47PM +0200, Olaf Wagner wrote: >>> Quoting hendrik at topoi.pooq.com: >>> >>> >The BottonVBT contains an action, which is a procedure rather >>> than a >>> >method. b This makes it awkward to subclass ButtonVBT becaue the >>> action >>> >will still expect its first parameter to be a ButtonVBT instead of >>> >belonging to the subclass, and an explicit downcast of some sort >>> will be >>> >needed to acess the subclass's members. >>> > >>> >The Trestle manual says this was a deliberate decision: >>> > >>> >: The action procedure is a field rather than a method in order >>> to allow >>> >: buttons with different action procedures to share their method >>> suites. >>> > >>> >I, however, find it massively inconvenient because it mans I have >>> to >>> >resort to downcasting or the very kludgey VBT.GetProp to access >>> what >>> >should be just there. I'd rather the action procedure was a >>> method. >>> > >>> >But it should be possible to have the best of both worlds. Have an >>> >action2 (better name wanted here) method that is available for >>> >overriding, and by default calls the procedure in the existing >>> action. >>> >field. That action2 method wounl then be called by Trestle >>> wherever >>> >action is now called. >>> > >>> >Does anyone see problems with this? >>> >>> Sounds fine to me offhand. You should test your extensions with >>> some of the existing larger applications, like mentor and Juno-2, >>> of course. >> >> OK. Here's the patch. Would it be possible for someone to check it >> in >> for me? >> >> mentor runs fine with this change; I watched it animate a heap-sort. >> >> I have no idea what Juno is supposed to do, but it did respond to >> button-pushes. >> >> >> hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ cvs diff >> cvs diff: Diffing . >> Index: ButtonVBT.i3 >> =================================================================== >> RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.i3,v >> retrieving revision 1.2 >> diff -r1.2 ButtonVBT.i3 >> 39a40 >>> act(READONLY cd: VBT.MouseRec); >> Index: ButtonVBT.m3 >> =================================================================== >> RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.m3,v >> retrieving revision 1.2 >> diff -r1.2 ButtonVBT.m3 >> 28c28,29 >> < init := Be >> --- >>> init := Be; >>> act := act >> 46a48,52 >>> PROCEDURE act(v : T; READONLY cd: VBT.MouseRec) = >>> BEGIN >>> v.action(v, cd); >>> END act; >>> >> 59c65 >> < v.action(v, cd); >> --- >>> v.act(cd); >> hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ >> >> -- hendrik >> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Aug 27 21:15:41 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 27 Aug 2009 15:15:41 -0400 Subject: [M3devel] small design problem in ButtonVBT? In-Reply-To: <20090827141741.9g1u2vrgfgokkksg@mail.elegosoft.com> References: <20090331145127.GB9624@topoi.pooq.com> <20090401120347.x8cneize8oscg44o@mail.elegosoft.com> <20090826002606.GB16386@topoi.pooq.com> <20090827141741.9g1u2vrgfgokkksg@mail.elegosoft.com> Message-ID: I am nervous about having the two alternative entries to the action procedure that other code might not be aware of. Yes, you've modified the default mouse method to call the action method instead of the procedure, but what about other places where the mouse method has been overridden. If you want to be smart about it in your own code you can simply invert your suggestion and do the following: TYPE T = ButtonVBT.T OBJECT METHODS action(cd: VBT.MouseRec) := Action; PROCEDURE Action(v: T; cd: VBT.MouseRec) = ... PROCEDURE ActionProc(v: ButtonVBT.T; cd: VBT.MouseRec) = BEGIN NARROW(v, T).action(cd); END ActionProc; and initialize your T thingy with ButtonVBT.New(..., action := ActionProc; ...) Then in your code you can go ahead and override the action method to your hearts content. Am I just being paranoid? On 27 Aug 2009, at 08:17, Olaf Wagner wrote: > Though I promised to do it, I have lost sight of this task while > trying to build some RC3 archives on Windows. As I'm not at home this > evening, can somebody else please commit Hendrik's extension? > > Is this something we should should have in the release branch, too? > Probably not necessary? > > Olaf > > Quoting hendrik at topoi.pooq.com: > >> On Wed, Apr 01, 2009 at 12:03:47PM +0200, Olaf Wagner wrote: >>> Quoting hendrik at topoi.pooq.com: >>> >>> >The BottonVBT contains an action, which is a procedure rather >>> than a >>> >method. b This makes it awkward to subclass ButtonVBT becaue the >>> action >>> >will still expect its first parameter to be a ButtonVBT instead of >>> >belonging to the subclass, and an explicit downcast of some sort >>> will be >>> >needed to acess the subclass's members. >>> > >>> >The Trestle manual says this was a deliberate decision: >>> > >>> >: The action procedure is a field rather than a method in order >>> to allow >>> >: buttons with different action procedures to share their method >>> suites. >>> > >>> >I, however, find it massively inconvenient because it mans I have >>> to >>> >resort to downcasting or the very kludgey VBT.GetProp to access >>> what >>> >should be just there. I'd rather the action procedure was a >>> method. >>> > >>> >But it should be possible to have the best of both worlds. Have an >>> >action2 (better name wanted here) method that is available for >>> >overriding, and by default calls the procedure in the existing >>> action. >>> >field. That action2 method wounl then be called by Trestle >>> wherever >>> >action is now called. >>> > >>> >Does anyone see problems with this? >>> >>> Sounds fine to me offhand. You should test your extensions with >>> some of the existing larger applications, like mentor and Juno-2, >>> of course. >> >> OK. Here's the patch. Would it be possible for someone to check it >> in >> for me? >> >> mentor runs fine with this change; I watched it animate a heap-sort. >> >> I have no idea what Juno is supposed to do, but it did respond to >> button-pushes. >> >> >> hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ cvs diff >> cvs diff: Diffing . >> Index: ButtonVBT.i3 >> =================================================================== >> RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.i3,v >> retrieving revision 1.2 >> diff -r1.2 ButtonVBT.i3 >> 39a40 >>> act(READONLY cd: VBT.MouseRec); >> Index: ButtonVBT.m3 >> =================================================================== >> RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.m3,v >> retrieving revision 1.2 >> diff -r1.2 ButtonVBT.m3 >> 28c28,29 >> < init := Be >> --- >>> init := Be; >>> act := act >> 46a48,52 >>> PROCEDURE act(v : T; READONLY cd: VBT.MouseRec) = >>> BEGIN >>> v.action(v, cd); >>> END act; >>> >> 59c65 >> < v.action(v, cd); >> --- >>> v.act(cd); >> hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ >> >> -- hendrik >> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From rodney.m.bates at cox.net Thu Aug 27 23:37:12 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Thu, 27 Aug 2009 16:37:12 -0500 Subject: [M3devel] m3gdb build error in RC3 In-Reply-To: <20090827161743.mkz8qhp7lco88og8@mail.elegosoft.com> References: <20090827161743.mkz8qhp7lco88og8@mail.elegosoft.com> Message-ID: <4A96FC88.3030006@cox.net> Olaf Wagner wrote: > I just found this in Hudson for AMD64_LINUX: > > http://hudson.modula3.com:8080/view/AMD64_LINUX/job/cm3-test-all-pkgs-AMD64_LINUX/lastBuild/testReport/(root)/CM3%20package%20build%20status/m3_sys_m3gdb/ > > > I've created ticket #1067 for it. > > Perhaps a wrong/incomplete merge of changes from the main trunk? > (I may be the culprit myself, though I'm sure I remember to have compiled > m3gdb after merging some changes some days ago.) > > @Rodney, did you get the account information for trac I sent you? > I took the liberty to assign the new ticket to you, too :-) > #1058 is not closed yet, too, though you had fixed that. I got the account info and figured out how to close it. My own responsivness is bit erratic these days, as I am often away from internet access for 4 or 5 days at a time. > > Olaf From jay.krell at cornell.edu Fri Aug 28 03:30:47 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 28 Aug 2009 01:30:47 +0000 Subject: [M3devel] m3gdb build error in RC3 In-Reply-To: <4A96FC88.3030006@cox.net> References: <20090827161743.mkz8qhp7lco88og8@mail.elegosoft.com> <4A96FC88.3030006@cox.net> Message-ID: I'll fix this shortly. We can't use stdbool.h. It #errors on Solaris. And we can't use bool either. It conflicts on Linux. I'll change to m3bool, m3true, m3false. - Jay ---------------------------------------- > Date: Thu, 27 Aug 2009 16:37:12 -0500 > From: rodney.m.bates at cox.net > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] m3gdb build error in RC3 > > Olaf Wagner wrote: >> I just found this in Hudson for AMD64_LINUX: >> >> http://hudson.modula3.com:8080/view/AMD64_LINUX/job/cm3-test-all-pkgs-AMD64_LINUX/lastBuild/testReport/(root)/CM3%20package%20build%20status/m3_sys_m3gdb/ >> >> >> I've created ticket #1067 for it. >> >> Perhaps a wrong/incomplete merge of changes from the main trunk? >> (I may be the culprit myself, though I'm sure I remember to have compiled >> m3gdb after merging some changes some days ago.) >> >> @Rodney, did you get the account information for trac I sent you? >> I took the liberty to assign the new ticket to you, too :-) >> #1058 is not closed yet, too, though you had fixed that. > I got the account info and figured out how to close it. My own > responsivness > is bit erratic these days, as I am often away from internet access > for 4 or 5 days at a time. >> >> Olaf > From jay.krell at cornell.edu Fri Aug 28 04:53:47 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 28 Aug 2009 02:53:47 +0000 Subject: [M3devel] CM3 on windows In-Reply-To: <20090828020144.B5E7C1A209A@async.async.caltech.edu> References: <20090828020144.B5E7C1A209A@async.async.caltech.edu> Message-ID: I fixed the access on 5.8.2. Try that? I can poke around.. As I recall 5.8.1 used VC 8.0 and 5.8.2 used 9.0. If that helps. - Jay ---------------------------------------- > To: m3devel at elegosoft.com; jay.krell at cornell.edu > CC: mika at async.caltech.edu > Subject: CM3 on windows > Date: Thu, 27 Aug 2009 19:01:44 -0700 > From: mika at async.async.caltech.edu > > Hi m3devel, > > Not sure if my earlier message today went anywhere. I never saw it on > the list. > > I'd like to try running CM3 on Windows 2000, so I've downloaded > > http://www.opencm3.com/uploaded-archives/cm3-std-NT386-d5.8.1.msi > > (5.8.2 didn't work---no access). > > Having installed it as well as I can figure, following the directions at > > http://www.opencm3.com/installation-windows.html > > I don't really seem to get all the way. Compiling in the CMD window fails > at a link (can't find winspool.lib), and the binaries have problems. > > Funnily enough, WebScape seems to work (as well or poorly as anywhere else), > but mentor and Juno both fail miserably: > > > mika at scruff /cygdrive/c/cm3/bin > $ ./mentor > > > *** > *** runtime error: > *** Attempt to reference an illegal memory location. > *** pc = 0x1061634 = GetAttributes + 0x179 in ..\src\lego\WIN32\ScrollerVBTCl > ass.m3 > *** > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x30af668 0x6a6e4d SystemError + 0x66 in ..\src\runtime\NT386\RTSignal.m3 > 0x30af70c 0x1061634 GetAttributes + 0x179 in ..\src\lego\WIN32\ScrollerVBTClas > s.m3 > 0x30af7e4 0x10993d8 AddView + 0x101e(!) in ..\src\lego\ViewportVBT.m3 > 0x30af830 0x109743e Init + 0x30e in ..\src\lego\ViewportVBT.m3 > 0x30af950 0x1004ee0 pViewport + 0x512 in ..\src\FormsVBT.m3 > 0x30af9b0 0xff33df Item + 0x48b in ..\src\FormsVBT.m3 > 0x30af9dc 0x1010f66 OneChild + 0xf8 in ..\src\FormsVBT.m3 > 0x30afae4 0xff7448 pShape + 0x19c in ..\src\FormsVBT.m3 > 0x30afb44 0xff33df Item + 0x48b in ..\src\FormsVBT.m3 > 0x30afb70 0x1010f66 OneChild + 0xf8 in ..\src\FormsVBT.m3 > ......... ......... ... more frames ... > > mika at scruff /cygdrive/c/cm3/bin > $ ./Juno > > > *** > *** runtime error: > *** failed. > *** file "..\src\winvbt\WinContext.m3", line 165 > *** > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x1b6f854 0xea1e03 PushPixmap + 0x4cb in ..\src\winvbt\WinContext.m3 > 0x1b6f91c 0xeb10c7 PixmapCom + 0x9ed in ..\src\winvbt\WinPaint.m3 > 0x1b6fd78 0xeaedaf PaintBatch + 0x25f in ..\src\winvbt\WinPaint.m3 > 0x1b6fde4 0xea91f3 PaintBatchVBT + 0x13f in ..\src\winvbt\WinTrestle.m3 > 0x1b6fe2c 0xea7919 WindowProc + 0x763 in ..\src\winvbt\WinTrestle.m3 > 0x1b6fe4c 0x77e3a454 > 0x1b6fed8 0x77e14605 > 0x1b6ff30 0x77e15b77 > 0x1b6ff88 0x4fb015 RunThread + 0x234 in ..\src\thread\WIN32\ThreadWin32.m3 > 0x1b6ffb4 0x4fad57 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3 > ......... ......... ... more frames ... > > mika at scruff /cygdrive/c/cm3/bin > $ > > This is running from the cygwin shell but it doesn't do anything different > from CMD... > > Should I not expect to be able to get this to work? > > Mika From hendrik at topoi.pooq.com Fri Aug 28 05:17:23 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 27 Aug 2009 23:17:23 -0400 Subject: [M3devel] small design problem in ButtonVBT? In-Reply-To: References: <20090331145127.GB9624@topoi.pooq.com> <20090401120347.x8cneize8oscg44o@mail.elegosoft.com> <20090826002606.GB16386@topoi.pooq.com> <20090827141741.9g1u2vrgfgokkksg@mail.elegosoft.com> Message-ID: <20090828031722.GB22883@topoi.pooq.com> On Thu, Aug 27, 2009 at 03:15:41PM -0400, Tony Hosking wrote: > I am nervous about having the two alternative entries to the action > procedure that other code might not be aware of. Yes, you've modified > the default mouse method to call the action method instead of the > procedure, but what about other places where the mouse method has been > overridden. > > If you want to be smart about it in your own code you can simply > invert your suggestion and do the following: > > TYPE T = ButtonVBT.T OBJECT > METHODS action(cd: VBT.MouseRec) := Action; > > PROCEDURE Action(v: T; cd: VBT.MouseRec) = ... > > PROCEDURE ActionProc(v: ButtonVBT.T; cd: VBT.MouseRec) = > BEGIN > NARROW(v, T).action(cd); > END ActionProc; > > and initialize your T thingy with ButtonVBT.New(..., action := > ActionProc; ...) > > Then in your code you can go ahead and override the action method to > your hearts content. This kind of thing would work. But, like the existing semantics of ButtonVBT, it seems to be fighting the language instead of working with it. I'd be happiest to get rid of the action variable altogether, but that would be a massively incompatible change, and would require change to a lot of existing code. What I proposed is compatible with existing code, and also has the advantage that someone who subclasses ButtonVBT.T and overrides act can completely ignore the action variable altogether. You say > and initialize your T thingy with ButtonVBT.New(..., action := > ActionProc; ...) But that requires every object I make of type T or any sibclass to be explicitly initialised with ActionProc, certainly a nuisance, and certainly error-prone. The inelegance I see with my approach is that there are two mechanisms for specifying the action to be taken. Either will work without the programmer paying any attention to the other, but if you use both, one will override the other. This is not a problem with legacy software. I'll have to come up with some documentation that makes this clear. It's the inelegance that comes from backward compatibility, and I think my solution is less inelegant, and easier to use, than yours. Yours, however, involves no change in existing code. > > Am I just being paranoid? No. Perhaps just paranoid about different things. I had hoped for someone to come up with a solid technical reason for the action variable. The original designers were clever people, and I'd *still* like to know why they thought it was a good idea. It's awkward and error-prone to use, and they had to use the PutProp/GetProp kludge just to approximate what the language provided for free with inheritance. I'm tempted to go over the entire code-base and change the buttons to use act instead of action, but I have to admit I'm not tempted enough to actually do it... -- hendrik > On 27 Aug 2009, at 08:17, Olaf Wagner wrote: > > >Though I promised to do it, I have lost sight of this task while > >trying to build some RC3 archives on Windows. As I'm not at home this > >evening, can somebody else please commit Hendrik's extension? > > > >Is this something we should should have in the release branch, too? > >Probably not necessary? > > > >Olaf > > > >Quoting hendrik at topoi.pooq.com: > > > >>On Wed, Apr 01, 2009 at 12:03:47PM +0200, Olaf Wagner wrote: > >>>Quoting hendrik at topoi.pooq.com: > >>> > >>>>The BottonVBT contains an action, which is a procedure rather > >>>than a > >>>>method. b This makes it awkward to subclass ButtonVBT becaue the > >>>action > >>>>will still expect its first parameter to be a ButtonVBT instead of > >>>>belonging to the subclass, and an explicit downcast of some sort > >>>will be > >>>>needed to acess the subclass's members. > >>>> > >>>>The Trestle manual says this was a deliberate decision: > >>>> > >>>>: The action procedure is a field rather than a method in order > >>>to allow > >>>>: buttons with different action procedures to share their method > >>>suites. > >>>> > >>>>I, however, find it massively inconvenient because it mans I have > >>>to > >>>>resort to downcasting or the very kludgey VBT.GetProp to access > >>>what > >>>>should be just there. I'd rather the action procedure was a > >>>method. > >>>> > >>>>But it should be possible to have the best of both worlds. Have an > >>>>action2 (better name wanted here) method that is available for > >>>>overriding, and by default calls the procedure in the existing > >>>action. > >>>>field. That action2 method wounl then be called by Trestle > >>>wherever > >>>>action is now called. > >>>> > >>>>Does anyone see problems with this? > >>> > >>>Sounds fine to me offhand. You should test your extensions with > >>>some of the existing larger applications, like mentor and Juno-2, > >>>of course. > >> > >>OK. Here's the patch. Would it be possible for someone to check it > >>in > >>for me? > >> > >>mentor runs fine with this change; I watched it animate a heap-sort. > >> > >>I have no idea what Juno is supposed to do, but it did respond to > >>button-pushes. > >> > >> > >>hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ cvs diff > >>cvs diff: Diffing . > >>Index: ButtonVBT.i3 > >>=================================================================== > >>RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.i3,v > >>retrieving revision 1.2 > >>diff -r1.2 ButtonVBT.i3 > >>39a40 > >>> act(READONLY cd: VBT.MouseRec); > >>Index: ButtonVBT.m3 > >>=================================================================== > >>RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.m3,v > >>retrieving revision 1.2 > >>diff -r1.2 ButtonVBT.m3 > >>28c28,29 > >>< init := Be > >>--- > >>> init := Be; > >>> act := act > >>46a48,52 > >>>PROCEDURE act(v : T; READONLY cd: VBT.MouseRec) = > >>> BEGIN > >>> v.action(v, cd); > >>> END act; > >>> > >>59c65 > >>< v.action(v, cd); > >>--- > >>> v.act(cd); > >>hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ > >> > >>-- hendrik > >> > > > > > > > >-- > >Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > >Germany > >phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > >45 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > >Berlin > >Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > >DE163214194 > > > From jay.krell at cornell.edu Fri Aug 28 05:28:32 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 28 Aug 2009 03:28:32 +0000 Subject: [M3devel] small design problem in ButtonVBT? In-Reply-To: <20090828031722.GB22883@topoi.pooq.com> References: <20090331145127.GB9624@topoi.pooq.com> <20090401120347.x8cneize8oscg44o@mail.elegosoft.com> <20090826002606.GB16386@topoi.pooq.com> <20090827141741.9g1u2vrgfgokkksg@mail.elegosoft.com> <20090828031722.GB22883@topoi.pooq.com> Message-ID: I think I know the reason it is this way. It is very common to override action and nothing else. It is "inconvenient" to derive a new type, just to change one function. - Jay ---------------------------------------- > Date: Thu, 27 Aug 2009 23:17:23 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] small design problem in ButtonVBT? > > On Thu, Aug 27, 2009 at 03:15:41PM -0400, Tony Hosking wrote: >> I am nervous about having the two alternative entries to the action >> procedure that other code might not be aware of. Yes, you've modified >> the default mouse method to call the action method instead of the >> procedure, but what about other places where the mouse method has been >> overridden. >> >> If you want to be smart about it in your own code you can simply >> invert your suggestion and do the following: >> >> TYPE T = ButtonVBT.T OBJECT >> METHODS action(cd: VBT.MouseRec) := Action; >> >> PROCEDURE Action(v: T; cd: VBT.MouseRec) = ... >> >> PROCEDURE ActionProc(v: ButtonVBT.T; cd: VBT.MouseRec) = >> BEGIN >> NARROW(v, T).action(cd); >> END ActionProc; >> >> and initialize your T thingy with ButtonVBT.New(..., action := >> ActionProc; ...) >> >> Then in your code you can go ahead and override the action method to >> your hearts content. > > This kind of thing would work. But, like the existing semantics of > ButtonVBT, it seems to be fighting the language instead of working with > it. I'd be happiest to get rid of the action variable altogether, but > that would be a massively incompatible change, and would require change > to a lot of existing code. What I proposed is compatible with existing > code, and also has the advantage that someone who subclasses ButtonVBT.T > and overrides act can completely ignore the action variable altogether. > > You say > >> and initialize your T thingy with ButtonVBT.New(..., action := >> ActionProc; ...) > > But that requires every object I make of type T or any sibclass to be > explicitly initialised with ActionProc, certainly a nuisance, and > certainly error-prone. > > The inelegance I see with my approach is that there are two mechanisms > for specifying the action to be taken. Either will work without the > programmer paying any attention to the other, but if you use both, one > will override the other. This is not a problem with legacy software. > I'll have to come up with some documentation that makes this clear. > It's the inelegance that comes from backward compatibility, and I think > my solution is less inelegant, and easier to use, than yours. Yours, > however, involves no change in existing code. > >> >> Am I just being paranoid? > > No. Perhaps just paranoid about different things. > > I had hoped for someone to come up with a solid technical reason for the > action variable. The original designers were clever people, and I'd > *still* like to know why they thought it was a good idea. It's awkward > and error-prone to use, and they had to use the PutProp/GetProp kludge > just to approximate what the language provided for free with inheritance. > > I'm tempted to go over the entire code-base and change the buttons to > use act instead of action, but I have to admit I'm not tempted enough to > actually do it... > > -- hendrik > >> On 27 Aug 2009, at 08:17, Olaf Wagner wrote: >> >>>Though I promised to do it, I have lost sight of this task while >>>trying to build some RC3 archives on Windows. As I'm not at home this >>>evening, can somebody else please commit Hendrik's extension? >>> >>>Is this something we should should have in the release branch, too? >>>Probably not necessary? >>> >>>Olaf >>> >>>Quoting hendrik at topoi.pooq.com: >>> >>>>On Wed, Apr 01, 2009 at 12:03:47PM +0200, Olaf Wagner wrote: >>>>>Quoting hendrik at topoi.pooq.com: >>>>> >>>>>>The BottonVBT contains an action, which is a procedure rather >>>>>than a >>>>>>method. b This makes it awkward to subclass ButtonVBT becaue the >>>>>action >>>>>>will still expect its first parameter to be a ButtonVBT instead of >>>>>>belonging to the subclass, and an explicit downcast of some sort >>>>>will be >>>>>>needed to acess the subclass's members. >>>>>> >>>>>>The Trestle manual says this was a deliberate decision: >>>>>> >>>>>>: The action procedure is a field rather than a method in order >>>>>to allow >>>>>>: buttons with different action procedures to share their method >>>>>suites. >>>>>> >>>>>>I, however, find it massively inconvenient because it mans I have >>>>>to >>>>>>resort to downcasting or the very kludgey VBT.GetProp to access >>>>>what >>>>>>should be just there. I'd rather the action procedure was a >>>>>method. >>>>>> >>>>>>But it should be possible to have the best of both worlds. Have an >>>>>>action2 (better name wanted here) method that is available for >>>>>>overriding, and by default calls the procedure in the existing >>>>>action. >>>>>>field. That action2 method wounl then be called by Trestle >>>>>wherever >>>>>>action is now called. >>>>>> >>>>>>Does anyone see problems with this? >>>>> >>>>>Sounds fine to me offhand. You should test your extensions with >>>>>some of the existing larger applications, like mentor and Juno-2, >>>>>of course. >>>> >>>>OK. Here's the patch. Would it be possible for someone to check it >>>>in >>>>for me? >>>> >>>>mentor runs fine with this change; I watched it animate a heap-sort. >>>> >>>>I have no idea what Juno is supposed to do, but it did respond to >>>>button-pushes. >>>> >>>> >>>>hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ cvs diff >>>>cvs diff: Diffing . >>>>Index: ButtonVBT.i3 >>>>=================================================================== >>>>RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.i3,v >>>>retrieving revision 1.2 >>>>diff -r1.2 ButtonVBT.i3 >>>>39a40 >>>>> act(READONLY cd: VBT.MouseRec); >>>>Index: ButtonVBT.m3 >>>>=================================================================== >>>>RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.m3,v >>>>retrieving revision 1.2 >>>>diff -r1.2 ButtonVBT.m3 >>>>28c28,29 >>>>< init := Be >>>>--- >>>>> init := Be; >>>>> act := act >>>>46a48,52 >>>>>PROCEDURE act(v : T; READONLY cd: VBT.MouseRec) = >>>>> BEGIN >>>>> v.action(v, cd); >>>>> END act; >>>>> >>>>59c65 >>>>< v.action(v, cd); >>>>--- >>>>> v.act(cd); >>>>hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ >>>> >>>>-- hendrik >>>> >>> >>> >>> >>>-- >>>Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>>Germany >>>phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>>Berlin >>>Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>DE163214194 >>> >> From hosking at cs.purdue.edu Fri Aug 28 05:26:23 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 27 Aug 2009 23:26:23 -0400 Subject: [M3devel] small design problem in ButtonVBT? In-Reply-To: <20090828031722.GB22883@topoi.pooq.com> References: <20090331145127.GB9624@topoi.pooq.com> <20090401120347.x8cneize8oscg44o@mail.elegosoft.com> <20090826002606.GB16386@topoi.pooq.com> <20090827141741.9g1u2vrgfgokkksg@mail.elegosoft.com> <20090828031722.GB22883@topoi.pooq.com> Message-ID: <433A59EF-4617-424C-8355-893C104F02D4@cs.purdue.edu> I suspect they were concerned about space bloat, if every different kind of button ends up with a separate method suite (because it overrides action). The expectation was that most buttons would inherit the standard behavior, and simply provide a tailored action procedure. It is elegant insofar as it avoids copying the default method suite entries for every different kind of button, but as you say kludgey in practice. If you go ahead and replace the proc with the method everywhere then you will increase the memory footprint. On 27 Aug 2009, at 23:17, hendrik at topoi.pooq.com wrote: > On Thu, Aug 27, 2009 at 03:15:41PM -0400, Tony Hosking wrote: >> I am nervous about having the two alternative entries to the action >> procedure that other code might not be aware of. Yes, you've >> modified >> the default mouse method to call the action method instead of the >> procedure, but what about other places where the mouse method has >> been >> overridden. >> >> If you want to be smart about it in your own code you can simply >> invert your suggestion and do the following: >> >> TYPE T = ButtonVBT.T OBJECT >> METHODS action(cd: VBT.MouseRec) := Action; >> >> PROCEDURE Action(v: T; cd: VBT.MouseRec) = ... >> >> PROCEDURE ActionProc(v: ButtonVBT.T; cd: VBT.MouseRec) = >> BEGIN >> NARROW(v, T).action(cd); >> END ActionProc; >> >> and initialize your T thingy with ButtonVBT.New(..., action := >> ActionProc; ...) >> >> Then in your code you can go ahead and override the action method to >> your hearts content. > > This kind of thing would work. But, like the existing semantics of > ButtonVBT, it seems to be fighting the language instead of working > with > it. I'd be happiest to get rid of the action variable altogether, but > that would be a massively incompatible change, and would require > change > to a lot of existing code. What I proposed is compatible with > existing > code, and also has the advantage that someone who subclasses > ButtonVBT.T > and overrides act can completely ignore the action variable > altogether. > > You say > >> and initialize your T thingy with ButtonVBT.New(..., action := >> ActionProc; ...) > > But that requires every object I make of type T or any sibclass to be > explicitly initialised with ActionProc, certainly a nuisance, and > certainly error-prone. > > The inelegance I see with my approach is that there are two mechanisms > for specifying the action to be taken. Either will work without the > programmer paying any attention to the other, but if you use both, one > will override the other. This is not a problem with legacy software. > I'll have to come up with some documentation that makes this clear. > It's the inelegance that comes from backward compatibility, and I > think > my solution is less inelegant, and easier to use, than yours. Yours, > however, involves no change in existing code. > >> >> Am I just being paranoid? > > No. Perhaps just paranoid about different things. > > I had hoped for someone to come up with a solid technical reason for > the > action variable. The original designers were clever people, and I'd > *still* like to know why they thought it was a good idea. It's > awkward > and error-prone to use, and they had to use the PutProp/GetProp kludge > just to approximate what the language provided for free with > inheritance. > > I'm tempted to go over the entire code-base and change the buttons to > use act instead of action, but I have to admit I'm not tempted > enough to > actually do it... > > -- hendrik > >> On 27 Aug 2009, at 08:17, Olaf Wagner wrote: >> >>> Though I promised to do it, I have lost sight of this task while >>> trying to build some RC3 archives on Windows. As I'm not at home >>> this >>> evening, can somebody else please commit Hendrik's extension? >>> >>> Is this something we should should have in the release branch, too? >>> Probably not necessary? >>> >>> Olaf >>> >>> Quoting hendrik at topoi.pooq.com: >>> >>>> On Wed, Apr 01, 2009 at 12:03:47PM +0200, Olaf Wagner wrote: >>>>> Quoting hendrik at topoi.pooq.com: >>>>> >>>>>> The BottonVBT contains an action, which is a procedure rather >>>>> than a >>>>>> method. b This makes it awkward to subclass ButtonVBT becaue the >>>>> action >>>>>> will still expect its first parameter to be a ButtonVBT instead >>>>>> of >>>>>> belonging to the subclass, and an explicit downcast of some sort >>>>> will be >>>>>> needed to acess the subclass's members. >>>>>> >>>>>> The Trestle manual says this was a deliberate decision: >>>>>> >>>>>> : The action procedure is a field rather than a method in order >>>>> to allow >>>>>> : buttons with different action procedures to share their method >>>>> suites. >>>>>> >>>>>> I, however, find it massively inconvenient because it mans I have >>>>> to >>>>>> resort to downcasting or the very kludgey VBT.GetProp to access >>>>> what >>>>>> should be just there. I'd rather the action procedure was a >>>>> method. >>>>>> >>>>>> But it should be possible to have the best of both worlds. >>>>>> Have an >>>>>> action2 (better name wanted here) method that is available for >>>>>> overriding, and by default calls the procedure in the existing >>>>> action. >>>>>> field. That action2 method wounl then be called by Trestle >>>>> wherever >>>>>> action is now called. >>>>>> >>>>>> Does anyone see problems with this? >>>>> >>>>> Sounds fine to me offhand. You should test your extensions with >>>>> some of the existing larger applications, like mentor and Juno-2, >>>>> of course. >>>> >>>> OK. Here's the patch. Would it be possible for someone to check it >>>> in >>>> for me? >>>> >>>> mentor runs fine with this change; I watched it animate a heap- >>>> sort. >>>> >>>> I have no idea what Juno is supposed to do, but it did respond to >>>> button-pushes. >>>> >>>> >>>> hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ cvs diff >>>> cvs diff: Diffing . >>>> Index: ButtonVBT.i3 >>>> =================================================================== >>>> RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.i3,v >>>> retrieving revision 1.2 >>>> diff -r1.2 ButtonVBT.i3 >>>> 39a40 >>>>> act(READONLY cd: VBT.MouseRec); >>>> Index: ButtonVBT.m3 >>>> =================================================================== >>>> RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.m3,v >>>> retrieving revision 1.2 >>>> diff -r1.2 ButtonVBT.m3 >>>> 28c28,29 >>>> < init := Be >>>> --- >>>>> init := Be; >>>>> act := act >>>> 46a48,52 >>>>> PROCEDURE act(v : T; READONLY cd: VBT.MouseRec) = >>>>> BEGIN >>>>> v.action(v, cd); >>>>> END act; >>>>> >>>> 59c65 >>>> < v.action(v, cd); >>>> --- >>>>> v.act(cd); >>>> hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ >>>> >>>> -- hendrik >>>> >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>> Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>> 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>> Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Aug 28 05:53:27 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 27 Aug 2009 23:53:27 -0400 Subject: [M3devel] small design problem in ButtonVBT? In-Reply-To: References: <20090331145127.GB9624@topoi.pooq.com> <20090401120347.x8cneize8oscg44o@mail.elegosoft.com> <20090826002606.GB16386@topoi.pooq.com> <20090827141741.9g1u2vrgfgokkksg@mail.elegosoft.com> <20090828031722.GB22883@topoi.pooq.com> Message-ID: <36DAB001-70F3-4C96-B1D5-57E8A7322464@cs.purdue.edu> Right. Plus, overriding copies the entire method suite for the new type. On 27 Aug 2009, at 23:28, Jay K wrote: > > I think I know the reason it is this way. > It is very common to override action and nothing else. > It is "inconvenient" to derive a new type, just to change one > function. > > - Jay > > ---------------------------------------- >> Date: Thu, 27 Aug 2009 23:17:23 -0400 >> From: hendrik at topoi.pooq.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] small design problem in ButtonVBT? >> >> On Thu, Aug 27, 2009 at 03:15:41PM -0400, Tony Hosking wrote: >>> I am nervous about having the two alternative entries to the action >>> procedure that other code might not be aware of. Yes, you've >>> modified >>> the default mouse method to call the action method instead of the >>> procedure, but what about other places where the mouse method has >>> been >>> overridden. >>> >>> If you want to be smart about it in your own code you can simply >>> invert your suggestion and do the following: >>> >>> TYPE T = ButtonVBT.T OBJECT >>> METHODS action(cd: VBT.MouseRec) := Action; >>> >>> PROCEDURE Action(v: T; cd: VBT.MouseRec) = ... >>> >>> PROCEDURE ActionProc(v: ButtonVBT.T; cd: VBT.MouseRec) = >>> BEGIN >>> NARROW(v, T).action(cd); >>> END ActionProc; >>> >>> and initialize your T thingy with ButtonVBT.New(..., action := >>> ActionProc; ...) >>> >>> Then in your code you can go ahead and override the action method to >>> your hearts content. >> >> This kind of thing would work. But, like the existing semantics of >> ButtonVBT, it seems to be fighting the language instead of working >> with >> it. I'd be happiest to get rid of the action variable altogether, but >> that would be a massively incompatible change, and would require >> change >> to a lot of existing code. What I proposed is compatible with >> existing >> code, and also has the advantage that someone who subclasses >> ButtonVBT.T >> and overrides act can completely ignore the action variable >> altogether. >> >> You say >> >>> and initialize your T thingy with ButtonVBT.New(..., action := >>> ActionProc; ...) >> >> But that requires every object I make of type T or any sibclass to be >> explicitly initialised with ActionProc, certainly a nuisance, and >> certainly error-prone. >> >> The inelegance I see with my approach is that there are two >> mechanisms >> for specifying the action to be taken. Either will work without the >> programmer paying any attention to the other, but if you use both, >> one >> will override the other. This is not a problem with legacy software. >> I'll have to come up with some documentation that makes this clear. >> It's the inelegance that comes from backward compatibility, and I >> think >> my solution is less inelegant, and easier to use, than yours. Yours, >> however, involves no change in existing code. >> >>> >>> Am I just being paranoid? >> >> No. Perhaps just paranoid about different things. >> >> I had hoped for someone to come up with a solid technical reason >> for the >> action variable. The original designers were clever people, and I'd >> *still* like to know why they thought it was a good idea. It's >> awkward >> and error-prone to use, and they had to use the PutProp/GetProp >> kludge >> just to approximate what the language provided for free with >> inheritance. >> >> I'm tempted to go over the entire code-base and change the buttons to >> use act instead of action, but I have to admit I'm not tempted >> enough to >> actually do it... >> >> -- hendrik >> >>> On 27 Aug 2009, at 08:17, Olaf Wagner wrote: >>> >>>> Though I promised to do it, I have lost sight of this task while >>>> trying to build some RC3 archives on Windows. As I'm not at home >>>> this >>>> evening, can somebody else please commit Hendrik's extension? >>>> >>>> Is this something we should should have in the release branch, too? >>>> Probably not necessary? >>>> >>>> Olaf >>>> >>>> Quoting hendrik at topoi.pooq.com: >>>> >>>>> On Wed, Apr 01, 2009 at 12:03:47PM +0200, Olaf Wagner wrote: >>>>>> Quoting hendrik at topoi.pooq.com: >>>>>> >>>>>>> The BottonVBT contains an action, which is a procedure rather >>>>>> than a >>>>>>> method. b This makes it awkward to subclass ButtonVBT becaue the >>>>>> action >>>>>>> will still expect its first parameter to be a ButtonVBT >>>>>>> instead of >>>>>>> belonging to the subclass, and an explicit downcast of some sort >>>>>> will be >>>>>>> needed to acess the subclass's members. >>>>>>> >>>>>>> The Trestle manual says this was a deliberate decision: >>>>>>> >>>>>>> : The action procedure is a field rather than a method in order >>>>>> to allow >>>>>>> : buttons with different action procedures to share their method >>>>>> suites. >>>>>>> >>>>>>> I, however, find it massively inconvenient because it mans I >>>>>>> have >>>>>> to >>>>>>> resort to downcasting or the very kludgey VBT.GetProp to access >>>>>> what >>>>>>> should be just there. I'd rather the action procedure was a >>>>>> method. >>>>>>> >>>>>>> But it should be possible to have the best of both worlds. >>>>>>> Have an >>>>>>> action2 (better name wanted here) method that is available for >>>>>>> overriding, and by default calls the procedure in the existing >>>>>> action. >>>>>>> field. That action2 method wounl then be called by Trestle >>>>>> wherever >>>>>>> action is now called. >>>>>>> >>>>>>> Does anyone see problems with this? >>>>>> >>>>>> Sounds fine to me offhand. You should test your extensions with >>>>>> some of the existing larger applications, like mentor and Juno-2, >>>>>> of course. >>>>> >>>>> OK. Here's the patch. Would it be possible for someone to check it >>>>> in >>>>> for me? >>>>> >>>>> mentor runs fine with this change; I watched it animate a heap- >>>>> sort. >>>>> >>>>> I have no idea what Juno is supposed to do, but it did respond to >>>>> button-pushes. >>>>> >>>>> >>>>> hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ cvs diff >>>>> cvs diff: Diffing . >>>>> Index: ButtonVBT.i3 >>>>> = >>>>> ================================================================== >>>>> RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.i3,v >>>>> retrieving revision 1.2 >>>>> diff -r1.2 ButtonVBT.i3 >>>>> 39a40 >>>>>> act(READONLY cd: VBT.MouseRec); >>>>> Index: ButtonVBT.m3 >>>>> = >>>>> ================================================================== >>>>> RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.m3,v >>>>> retrieving revision 1.2 >>>>> diff -r1.2 ButtonVBT.m3 >>>>> 28c28,29 >>>>> < init := Be >>>>> --- >>>>>> init := Be; >>>>>> act := act >>>>> 46a48,52 >>>>>> PROCEDURE act(v : T; READONLY cd: VBT.MouseRec) = >>>>>> BEGIN >>>>>> v.action(v, cd); >>>>>> END act; >>>>>> >>>>> 59c65 >>>>> < v.action(v, cd); >>>>> --- >>>>>> v.act(cd); >>>>> hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ >>>>> >>>>> -- hendrik >>>>> >>>> >>>> >>>> >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>>> Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>> 45 86 95 >>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>>> Berlin >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>> DE163214194 >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Aug 28 06:02:38 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 28 Aug 2009 04:02:38 +0000 Subject: [M3devel] CM3 on windows In-Reply-To: <20090828034057.475DD1A209A@async.async.caltech.edu> References: <20090828020144.B5E7C1A209A@async.async.caltech.edu> <20090828034057.475DD1A209A@async.async.caltech.edu> Message-ID: > Compiling in the CMD window fails>> at a link (can't find winspool.lib)=2C and the binaries have problems Where is it getting kernel32.lib? c:\cm3\lib? %LIB%? What is your compiler/linker? What are the "problems"? - Jay ---------------------------------------- > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: CM3 on windows > Date: Thu, 27 Aug 2009 20:40:57 -0700 > From: mika at async.async.caltech.edu > > Jay K writes: >> >>I fixed the access on 5.8.2. >>Try that? >>I can poke around.. >>=20 >>As I recall 5.8.1 used VC 8.0 and 5.8.2 used 9.0. >>If that helps. > > Well I can try but I don't think 9.0 works on Win2k... > >>=20 >> - Jay >> >> >>---------------------------------------- >>> To: m3devel at elegosoft.com=3B jay.krell at cornell.edu >>> CC: mika at async.caltech.edu >>> Subject: CM3 on windows >>> Date: Thu=2C 27 Aug 2009 19:01:44 -0700 >>> From: mika at async.async.caltech.edu >>> >>> Hi m3devel=2C >>> >>> Not sure if my earlier message today went anywhere. I never saw it on >>> the list. >>> >>> I'd like to try running CM3 on Windows 2000=2C so I've downloaded >>> >>> http://www.opencm3.com/uploaded-archives/cm3-std-NT386-d5.8.1.msi >>> >>> (5.8.2 didn't work---no access). >>> >>> Having installed it as well as I can figure=2C following the directions a= >>t >>> >>> http://www.opencm3.com/installation-windows.html >>> >>> I don't really seem to get all the way. Compiling in the CMD window fails >>> at a link (can't find winspool.lib)=2C and the binaries have problems. >>> >>> Funnily enough=2C WebScape seems to work (as well or poorly as anywhere e= >>lse)=2C >>> but mentor and Juno both fail miserably: >>> >>> >>> mika at scruff /cygdrive/c/cm3/bin >>> $ ./mentor >>> >>> >>> *** >>> *** runtime error: >>> *** Attempt to reference an illegal memory location. >>> *** pc =3D 0x1061634 =3D GetAttributes + 0x179 in ..\src\lego\WIN32\Scrol= >>lerVBTCl >>> ass.m3 >>> *** >>> >>> Stack trace: >>> FP PC Procedure >>> --------- --------- ------------------------------- >>> 0x30af668 0x6a6e4d SystemError + 0x66 in ..\src\runtime\NT386\RTSignal.m3 >>> 0x30af70c 0x1061634 GetAttributes + 0x179 in ..\src\lego\WIN32\ScrollerVB= >>TClas >>> s.m3 >>> 0x30af7e4 0x10993d8 AddView + 0x101e(!) in ..\src\lego\ViewportVBT.m3 >>> 0x30af830 0x109743e Init + 0x30e in ..\src\lego\ViewportVBT.m3 >>> 0x30af950 0x1004ee0 pViewport + 0x512 in ..\src\FormsVBT.m3 >>> 0x30af9b0 0xff33df Item + 0x48b in ..\src\FormsVBT.m3 >>> 0x30af9dc 0x1010f66 OneChild + 0xf8 in ..\src\FormsVBT.m3 >>> 0x30afae4 0xff7448 pShape + 0x19c in ..\src\FormsVBT.m3 >>> 0x30afb44 0xff33df Item + 0x48b in ..\src\FormsVBT.m3 >>> 0x30afb70 0x1010f66 OneChild + 0xf8 in ..\src\FormsVBT.m3 >>> ......... ......... ... more frames ... >>> >>> mika at scruff /cygdrive/c/cm3/bin >>> $ ./Juno >>> >>> >>> *** >>> *** runtime error: >>> *** failed. >>> *** file "..\src\winvbt\WinContext.m3"=2C line 165 >>> *** >>> >>> Stack trace: >>> FP PC Procedure >>> --------- --------- ------------------------------- >>> 0x1b6f854 0xea1e03 PushPixmap + 0x4cb in ..\src\winvbt\WinContext.m3 >>> 0x1b6f91c 0xeb10c7 PixmapCom + 0x9ed in ..\src\winvbt\WinPaint.m3 >>> 0x1b6fd78 0xeaedaf PaintBatch + 0x25f in ..\src\winvbt\WinPaint.m3 >>> 0x1b6fde4 0xea91f3 PaintBatchVBT + 0x13f in ..\src\winvbt\WinTrestle.m3 >>> 0x1b6fe2c 0xea7919 WindowProc + 0x763 in ..\src\winvbt\WinTrestle.m3 >>> 0x1b6fe4c 0x77e3a454=20 >>> 0x1b6fed8 0x77e14605=20 >>> 0x1b6ff30 0x77e15b77=20 >>> 0x1b6ff88 0x4fb015 RunThread + 0x234 in ..\src\thread\WIN32\ThreadWin32.m= >>3 >>> 0x1b6ffb4 0x4fad57 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m= >>3 >>> ......... ......... ... more frames ... >>> >>> mika at scruff /cygdrive/c/cm3/bin >>> $ >>> >>> This is running from the cygwin shell but it doesn't do anything differen= >>t >>> from CMD... >>> >>> Should I not expect to be able to get this to work? >>> >>> Mika= From jay.krell at cornell.edu Fri Aug 28 06:32:02 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 28 Aug 2009 04:32:02 +0000 Subject: [M3devel] CM3 on windows In-Reply-To: <20090828042715.B05E51A20A1@async.async.caltech.edu> References: <20090828020144.B5E7C1A209A@async.async.caltech.edu> <20090828034057.475DD1A209A@async.async.caltech.edu> <20090828042715.B05E51A20A1@async.async.caltech.edu> Message-ID: NT386GNU => Do you have an X Windows server? Compiler -- I meant the C compiler. set show: set LIB set PATH set INCLUDE and then among the directories in LIB, and your cm3 install\lib, where is kernel32.lib? Where is winspool.lib? Cm3 has its own, but for /almost/ no good reason. Older cm3 had its own modified ones for reasons related to the VM-sychronized GC. If you were to keep those around, they wouldn't work any longer -- probably fail to link. So current cm3 replaces them. As well, some much less usual toolsets, such as the Visual C++ 2003 Express or somesuch, which isn't available any longer, only included a C runtime and no kernel32.lib, user32.lib, winspool.lib, etc. So we provide them for such users. Perhaps we should 1) assume a new clean install, no old cm3 .libs 2) not support that one odd toolset -- heck, we can keep the import-libs directory, just remove it from any package set, and any such users can build it themselves. Long story short: normally among the directories in %LIB%, you should find kernel32.lib, msvcrt.lib, winspool.lib, user32.lib, gdi32.lib, comctl32.lib, etc. Windows 2000, really? Plan to upgrade to XP or newer any time soon? - Jay ---------------------------------------- > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: CM3 on windows > Date: Thu, 27 Aug 2009 21:27:15 -0700 > From: mika at async.async.caltech.edu > > Jay K writes: >> >>> Compiling in the CMD window fails>> at a link (can't find winspool.lib)= >>=3D2C and the binaries have problems >> >>=20 >>Where is it getting kernel32.lib? >> c:\cm3\lib? >> %LIB%? >>What is your compiler/linker? >>What are the "problems"? > > I installed Visual C++ Express Edition 8.0. > > It appears to use "link.exe" (not the Cygwin one, but a Windows one) as linker. > > Compiler... cm3?? > > The "problems" are mentioned in my email (scroll down a bit... mentor, Juno, ...) > > I tried NT386GNU as well, which does let me do text mode applications but crashes > if I try to open a window. "TrestleComm.Failure" > > I have to warn you I am a *complete* novice when it comes to programming in > Windows... > > Mika > >>=20 >>=20 >> - Jay >> >> >> >>---------------------------------------- >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com >>> Subject: Re: CM3 on windows >>> Date: Thu=2C 27 Aug 2009 20:40:57 -0700 >>> From: mika at async.async.caltech.edu >>> >>> Jay K writes: >>>> >>>>I fixed the access on 5.8.2. >>>>Try that? >>>>I can poke around.. >>>>=3D20 >>>>As I recall 5.8.1 used VC 8.0 and 5.8.2 used 9.0. >>>>If that helps. >>> >>> Well I can try but I don't think 9.0 works on Win2k... >>> >>>>=3D20 >>>> - Jay >>>> >>>> >>>>---------------------------------------- >>>>> To: m3devel at elegosoft.com=3D3B jay.krell at cornell.edu >>>>> CC: mika at async.caltech.edu >>>>> Subject: CM3 on windows >>>>> Date: Thu=3D2C 27 Aug 2009 19:01:44 -0700 >>>>> From: mika at async.async.caltech.edu >>>>> >>>>> Hi m3devel=3D2C >>>>> >>>>> Not sure if my earlier message today went anywhere. I never saw it on >>>>> the list. >>>>> >>>>> I'd like to try running CM3 on Windows 2000=3D2C so I've downloaded >>>>> >>>>> http://www.opencm3.com/uploaded-archives/cm3-std-NT386-d5.8.1.msi >>>>> >>>>> (5.8.2 didn't work---no access). >>>>> >>>>> Having installed it as well as I can figure=3D2C following the directio= >>ns a=3D >>>>t >>>>> >>>>> http://www.opencm3.com/installation-windows.html >>>>> >>>>> I don't really seem to get all the way. Compiling in the CMD window fai= >>ls >>>>> at a link (can't find winspool.lib)=3D2C and the binaries have problems= >>. >>>>> >>>>> Funnily enough=3D2C WebScape seems to work (as well or poorly as anywhe= >>re e=3D >>>>lse)=3D2C >>>>> but mentor and Juno both fail miserably: >>>>> >>>>> >>>>> mika at scruff /cygdrive/c/cm3/bin >>>>> $ ./mentor >>>>> >>>>> >>>>> *** >>>>> *** runtime error: >>>>> *** Attempt to reference an illegal memory location. >>>>> *** pc =3D3D 0x1061634 =3D3D GetAttributes + 0x179 in ..\src\lego\WIN32= >>\Scrol=3D >>>>lerVBTCl >>>>> ass.m3 >>>>> *** >>>>> >>>>> Stack trace: >>>>> FP PC Procedure >>>>> --------- --------- ------------------------------- >>>>> 0x30af668 0x6a6e4d SystemError + 0x66 in ..\src\runtime\NT386\RTSignal.= >>m3 >>>>> 0x30af70c 0x1061634 GetAttributes + 0x179 in ..\src\lego\WIN32\Scroller= >>VB=3D >>>>TClas >>>>> s.m3 >>>>> 0x30af7e4 0x10993d8 AddView + 0x101e(!) in ..\src\lego\ViewportVBT.m3 >>>>> 0x30af830 0x109743e Init + 0x30e in ..\src\lego\ViewportVBT.m3 >>>>> 0x30af950 0x1004ee0 pViewport + 0x512 in ..\src\FormsVBT.m3 >>>>> 0x30af9b0 0xff33df Item + 0x48b in ..\src\FormsVBT.m3 >>>>> 0x30af9dc 0x1010f66 OneChild + 0xf8 in ..\src\FormsVBT.m3 >>>>> 0x30afae4 0xff7448 pShape + 0x19c in ..\src\FormsVBT.m3 >>>>> 0x30afb44 0xff33df Item + 0x48b in ..\src\FormsVBT.m3 >>>>> 0x30afb70 0x1010f66 OneChild + 0xf8 in ..\src\FormsVBT.m3 >>>>> ......... ......... ... more frames ... >>>>> >>>>> mika at scruff /cygdrive/c/cm3/bin >>>>> $ ./Juno >>>>> >>>>> >>>>> *** >>>>> *** runtime error: >>>>> *** failed. >>>>> *** file "..\src\winvbt\WinContext.m3"=3D2C line 165 >>>>> *** >>>>> >>>>> Stack trace: >>>>> FP PC Procedure >>>>> --------- --------- ------------------------------- >>>>> 0x1b6f854 0xea1e03 PushPixmap + 0x4cb in ..\src\winvbt\WinContext.m3 >>>>> 0x1b6f91c 0xeb10c7 PixmapCom + 0x9ed in ..\src\winvbt\WinPaint.m3 >>>>> 0x1b6fd78 0xeaedaf PaintBatch + 0x25f in ..\src\winvbt\WinPaint.m3 >>>>> 0x1b6fde4 0xea91f3 PaintBatchVBT + 0x13f in ..\src\winvbt\WinTrestle.m3 >>>>> 0x1b6fe2c 0xea7919 WindowProc + 0x763 in ..\src\winvbt\WinTrestle.m3 >>>>> 0x1b6fe4c 0x77e3a454=3D20 >>>>> 0x1b6fed8 0x77e14605=3D20 >>>>> 0x1b6ff30 0x77e15b77=3D20 >>>>> 0x1b6ff88 0x4fb015 RunThread + 0x234 in ..\src\thread\WIN32\ThreadWin32= >>.m=3D >>>>3 >>>>> 0x1b6ffb4 0x4fad57 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32= >>.m=3D >>>>3 >>>>> ......... ......... ... more frames ... >>>>> >>>>> mika at scruff /cygdrive/c/cm3/bin >>>>> $ >>>>> >>>>> This is running from the cygwin shell but it doesn't do anything differ= >>en=3D >>>>t >>>>> from CMD... >>>>> >>>>> Should I not expect to be able to get this to work? >>>>> >>>>> Mika=3D= From jay.krell at cornell.edu Fri Aug 28 07:03:58 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 28 Aug 2009 05:03:58 +0000 Subject: [M3devel] CM3 on windows In-Reply-To: <20090828045055.BA3C81A20A1@async.async.caltech.edu> References: <20090828020144.B5E7C1A209A@async.async.caltech.edu> <20090828034057.475DD1A209A@async.async.caltech.edu> <20090828042715.B05E51A20A1@async.async.caltech.edu> <20090828045055.BA3C81A20A1@async.async.caltech.edu> Message-ID: Yes NT386GNU uses X. Olaf expressed an interest in that. Apparently the Windows port of Trestle has never been completed. (I suspect we should punt Trestle and bind to Qt, but that is another matter.) NT386GMINGNU doesn't use X. Though it had problems last I checked. NT386GNU I think also uses pthreads. And NT386MINGNU does not. The names should be I386_CYGWIN and I386_MINGW. There are few variables, and they are largely but not completely independent of each other: Which cm3 backend, integrated or gcc? Which C compiler, Visual C++ or gcc? (or Watcom or Borland, etc.) Which linker, same choices as previous. Win32 or Posix? In terms of path syntax. fork/exec vs. CreateProcess. Which threading library? Which windowing library? NT386GNU aka I386_CYGWIN is "very Posix". NT386MINGNU is totally Win32, except that the compiler backend is gcc. Oh and maybe the compiler/linker are gcc/GNU ld also. In future I expect to rename the platforms to I386_CYGWIN and I386_MINGW, and I386_NT (NT386)). There was good evicence that the gcc backend has never been used to target Win32 GUI. In particular there wasn't support for __stdcall, and the support is still broken in an usual case. I put in a workaround. - Jay ---------------------------------------- > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: CM3 on windows > Date: Thu, 27 Aug 2009 21:50:55 -0700 > From: mika at async.async.caltech.edu > > Jay K writes: >> >>NT386GNU =3D> Do you have an X Windows server? > > Hmm, really, NT386GNU just uses X? I could swear my ancient > Klagenfurt/PM3 uses Windows windows, not X... > >>Compiler -- I meant the C compiler. > > As far as I know the compiler I'm using is "cl" that came with VC++ 8.0 ("2003"?) > >>=20 >>=20 >>set show: >> set LIB >> set PATH >> set INCLUDE >>=20 >>=20 >>and then among the directories in LIB=2C and your cm3 install\lib=2C where = >>is kernel32.lib? Where is winspool.lib? > > kernel32 is in > > ...Visual Studio 8\VC\lib > > aha.. I think the only winspool I have is in C:\cm3, and that directory is > not in LIB. > > That would explain why things aren't compiling, but not why I get the errors > in mentor, Juno, etc. > > >>=20 >>Cm3 has its own=2C but for /almost/ no good reason. >> Older cm3 had its own modified ones for reasons related to the VM-sychroni= >>zed GC. >> If you were to keep those around=2C they wouldn't work any longer -- proba= >>bly fail to link. >> So current cm3 replaces them. >> As well=2C some much less usual toolsets=2C such as the Visual C++ 2003 Ex= >>press or somesuch=2C which isn't available any longer=2C only included a C = >>runtime and no kernel32.lib=2C user32.lib=2C winspool.lib=2C etc. So we pro= >>vide them for such users. Perhaps we should 1) assume a new clean install= >>=2C no old cm3 .libs 2) not support that one odd toolset -- heck=2C we can = >>keep the import-libs directory=2C just remove it from any package set=2C an= >>d any such users can build it themselves. >>=20 >>=20 >>Long story short: normally among the directories in %LIB%=2C you should fin= >>d kernel32.lib=2C msvcrt.lib=2C winspool.lib=2C user32.lib=2C gdi32.lib=2C = >>comctl32.lib=2C etc. >>=20 >>=20 >>Windows 2000=2C really? >>Plan to upgrade to XP or newer any time soon? > > Wasn't planning on it.. I try to use Windows as little as possible.. but if > it's necessary to get CM3 working.. > > I should mention that my goal is actually to build .exes that can be > distributed to people with Vista. Is that possible with my system? > > Mika > >>=20 >>=20 >> - Jay >> >> >>---------------------------------------- >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com >>> Subject: Re: CM3 on windows >>> Date: Thu=2C 27 Aug 2009 21:27:15 -0700 >>> From: mika at async.async.caltech.edu >>> >>> Jay K writes: >>>> >>>>> Compiling in the CMD window fails>> at a link (can't find winspool.lib)= >>=3D >>>>=3D3D2C and the binaries have problems >>>> >>>>=3D20 >>>>Where is it getting kernel32.lib? >>>> c:\cm3\lib? >>>> %LIB%? >>>>What is your compiler/linker? >>>>What are the "problems"? >>> >>> I installed Visual C++ Express Edition 8.0. >>> >>> It appears to use "link.exe" (not the Cygwin one=2C but a Windows one) as= >> linker. >>> >>> Compiler... cm3?? >>> >>> The "problems" are mentioned in my email (scroll down a bit... mentor=2C = >>Juno=2C ...) >>> >>> I tried NT386GNU as well=2C which does let me do text mode applications b= >>ut crashes >>> if I try to open a window. "TrestleComm.Failure" >>> >>> I have to warn you I am a *complete* novice when it comes to programming = >>in >>> Windows... >>> >>> Mika >>> >>>>=3D20 >>>>=3D20 >>>> - Jay >>>> >>>> >>>> >>>>---------------------------------------- >>>>> To: jay.krell at cornell.edu >>>>> CC: m3devel at elegosoft.com >>>>> Subject: Re: CM3 on windows >>>>> Date: Thu=3D2C 27 Aug 2009 20:40:57 -0700 >>>>> From: mika at async.async.caltech.edu >>>>> >>>>> Jay K writes: >>>>>> >>>>>>I fixed the access on 5.8.2. >>>>>>Try that? >>>>>>I can poke around.. >>>>>>=3D3D20 >>>>>>As I recall 5.8.1 used VC 8.0 and 5.8.2 used 9.0. >>>>>>If that helps. >>>>> >>>>> Well I can try but I don't think 9.0 works on Win2k... >>>>> >>>>>>=3D3D20 >>>>>> - Jay >>>>>> >>>>>> >>>>>>---------------------------------------- >>>>>>> To: m3devel at elegosoft.com=3D3D3B jay.krell at cornell.edu >>>>>>> CC: mika at async.caltech.edu >>>>>>> Subject: CM3 on windows >>>>>>> Date: Thu=3D3D2C 27 Aug 2009 19:01:44 -0700 >>>>>>> From: mika at async.async.caltech.edu >>>>>>> >>>>>>> Hi m3devel=3D3D2C >>>>>>> >>>>>>> Not sure if my earlier message today went anywhere. I never saw it on >>>>>>> the list. >>>>>>> >>>>>>> I'd like to try running CM3 on Windows 2000=3D3D2C so I've downloaded >>>>>>> >>>>>>> http://www.opencm3.com/uploaded-archives/cm3-std-NT386-d5.8.1.msi >>>>>>> >>>>>>> (5.8.2 didn't work---no access). >>>>>>> >>>>>>> Having installed it as well as I can figure=3D3D2C following the dire= >>ctio=3D >>>>ns a=3D3D >>>>>>t >>>>>>> >>>>>>> http://www.opencm3.com/installation-windows.html >>>>>>> >>>>>>> I don't really seem to get all the way. Compiling in the CMD window f= >>ai=3D >>>>ls >>>>>>> at a link (can't find winspool.lib)=3D3D2C and the binaries have prob= >>lems=3D >>>>. >>>>>>> >>>>>>> Funnily enough=3D3D2C WebScape seems to work (as well or poorly as an= >>ywhe=3D >>>>re e=3D3D >>>>>>lse)=3D3D2C >>>>>>> but mentor and Juno both fail miserably: >>>>>>> >>>>>>> >>>>>>> mika at scruff /cygdrive/c/cm3/bin >>>>>>> $ ./mentor >>>>>>> >>>>>>> >>>>>>> *** >>>>>>> *** runtime error: >>>>>>> *** Attempt to reference an illegal memory location. >>>>>>> *** pc =3D3D3D 0x1061634 =3D3D3D GetAttributes + 0x179 in ..\src\lego= >>\WIN32=3D >>>>\Scrol=3D3D >>>>>>lerVBTCl >>>>>>> ass.m3 >>>>>>> *** >>>>>>> >>>>>>> Stack trace: >>>>>>> FP PC Procedure >>>>>>> --------- --------- ------------------------------- >>>>>>> 0x30af668 0x6a6e4d SystemError + 0x66 in ..\src\runtime\NT386\RTSigna= >>l.=3D >>>>m3 >>>>>>> 0x30af70c 0x1061634 GetAttributes + 0x179 in ..\src\lego\WIN32\Scroll= >>er=3D >>>>VB=3D3D >>>>>>TClas >>>>>>> s.m3 >>>>>>> 0x30af7e4 0x10993d8 AddView + 0x101e(!) in ..\src\lego\ViewportVBT.m3 >>>>>>> 0x30af830 0x109743e Init + 0x30e in ..\src\lego\ViewportVBT.m3 >>>>>>> 0x30af950 0x1004ee0 pViewport + 0x512 in ..\src\FormsVBT.m3 >>>>>>> 0x30af9b0 0xff33df Item + 0x48b in ..\src\FormsVBT.m3 >>>>>>> 0x30af9dc 0x1010f66 OneChild + 0xf8 in ..\src\FormsVBT.m3 >>>>>>> 0x30afae4 0xff7448 pShape + 0x19c in ..\src\FormsVBT.m3 >>>>>>> 0x30afb44 0xff33df Item + 0x48b in ..\src\FormsVBT.m3 >>>>>>> 0x30afb70 0x1010f66 OneChild + 0xf8 in ..\src\FormsVBT.m3 >>>>>>> ......... ......... ... more frames ... >>>>>>> >>>>>>> mika at scruff /cygdrive/c/cm3/bin >>>>>>> $ ./Juno >>>>>>> >>>>>>> >>>>>>> *** >>>>>>> *** runtime error: >>>>>>> *** failed. >>>>>>> *** file "..\src\winvbt\WinContext.m3"=3D3D2C line 165 >>>>>>> *** >>>>>>> >>>>>>> Stack trace: >>>>>>> FP PC Procedure >>>>>>> --------- --------- ------------------------------- >>>>>>> 0x1b6f854 0xea1e03 PushPixmap + 0x4cb in ..\src\winvbt\WinContext.m3 >>>>>>> 0x1b6f91c 0xeb10c7 PixmapCom + 0x9ed in ..\src\winvbt\WinPaint.m3 >>>>>>> 0x1b6fd78 0xeaedaf PaintBatch + 0x25f in ..\src\winvbt\WinPaint.m3 >>>>>>> 0x1b6fde4 0xea91f3 PaintBatchVBT + 0x13f in ..\src\winvbt\WinTrestle.= >>m3 >>>>>>> 0x1b6fe2c 0xea7919 WindowProc + 0x763 in ..\src\winvbt\WinTrestle.m3 >>>>>>> 0x1b6fe4c 0x77e3a454=3D3D20 >>>>>>> 0x1b6fed8 0x77e14605=3D3D20 >>>>>>> 0x1b6ff30 0x77e15b77=3D3D20 >>>>>>> 0x1b6ff88 0x4fb015 RunThread + 0x234 in ..\src\thread\WIN32\ThreadWin= >>32=3D >>>>.m=3D3D >>>>>>3 >>>>>>> 0x1b6ffb4 0x4fad57 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin= >>32=3D >>>>.m=3D3D >>>>>>3 >>>>>>> ......... ......... ... more frames ... >>>>>>> >>>>>>> mika at scruff /cygdrive/c/cm3/bin >>>>>>> $ >>>>>>> >>>>>>> This is running from the cygwin shell but it doesn't do anything diff= >>er=3D >>>>en=3D3D >>>>>>t >>>>>>> from CMD... >>>>>>> >>>>>>> Should I not expect to be able to get this to work? >>>>>>> >>>>>>> Mika=3D3D=3D= From jay.krell at cornell.edu Fri Aug 28 09:21:19 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 28 Aug 2009 07:21:19 +0000 Subject: [M3devel] strange code in scripts Message-ID: This sequence is odd: [ ${TARGET} != NT386 ] && "${ROOT}/scripts/do-pkg.sh" buildship echo "${ROOT}/scripts/do-cm3-${DIST}.sh" buildlocal "${ROOT}/scripts/do-cm3-${DIST}.sh" buildlocal || exit 1 header "stage 4: installing libraries using new cm3 compiler" echo "${ROOT}/scripts/do-cm3-${DIST}.sh" buildglobal "${ROOT}/scripts/do-cm3-${DIST}.sh" buildglobal || exit 1 The first line doesn't do anything. In the logs you can see it just says "no packages". I don't understand why buildlocal + buildglobal. Is that, um, to delete the .M3OVERRIDES files, so that "On the other side", ship won't refuse? - Jay From jay.krell at cornell.edu Fri Aug 28 09:22:28 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 28 Aug 2009 07:22:28 +0000 Subject: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems In-Reply-To: <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> References: <20090826142644.r6yabwff5wc84cgg@mail.elegosoft.com> <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> Message-ID: It was backslashes vs. forward slashes as I had originally suspected. My debugprinting never hit because I was guessing the elego paths wrong. I finally made it always print and tested it in-situ in the VM. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems > Date: Thu, 27 Aug 2009 12:15:14 +0000 > > > My current theory is the unresolve problem is due to that wierd initial build of import-libs in the Hudson task, which was related to the line endings problem, which was related to using CVSNT instead of Cygwin cvs. > > - Jay > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems >> Date: Thu, 27 Aug 2009 06:09:52 +0000 >> >> >> I'm testing a fix for the VM right now actually. >> Once that works I'll look into the Unresolve problem further. I put in some printing to help diagnose it and possibly a fix. It could be a slash mixup; the printing will tell us. >> The VBT problem is new seeming. I'll look at that too. >> Anyone else is welcome to also. >> >> - Jay >> >> >> ---------------------------------------- >>> Date: Thu, 27 Aug 2009 08:06:57 +0200 >>> From: wagner at elegosoft.com >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com >>> Subject: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems >>> >>> Quoting Jay K : >>> >>>> Something or some things very wierd here. I'll keep looking into it. >>> I'm not sure if we should spend/waste(?) more time in trying to make >>> this VM with Windows work. >>> >>> Last night I reactivated my own qemu-based VM and was able to checkout >>> and build some current CM3 stuff. >>> >>> CVS behaves correctly there, and no need to adapt any of the shell >>> scripts at all. It's agonizingly slow though. And it has no remote >>> access. >>> >>> However, building the release archives failed with two errors: >>> >>> vbtkit: >>> new source -> compiling VBTKitResources.m3 >>> "..\src\lego\VBTKitResources.m3", line 10: unable to find interface >>> (VBTKitBundle) >>> 1 error encountered >>> >>> and >>> >>> errors during build-all; some packages will be missing >>> m3-win/import-libs/NT386/.M3SHIP seems to be broken: >>> make_dir("c:/tmp/cm3/lib") >>> install_file("wsock32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("advapi32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("opengl32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("netapi32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("comctl32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("user32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("comdlg32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("kernel32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("winspool.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("glu32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("gdi32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("odbc32.lib", "c:/tmp/cm3/lib", "0775") >>> >>> (wrong shippind destination, already reported) >>> >>> I suggest we rather concentrate on these and build the Windows >>> packages manually. >>> >>> I'm off to (paid) work again now... >>> >>> Olaf >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >>> From wagner at elegosoft.com Fri Aug 28 09:45:53 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 28 Aug 2009 09:45:53 +0200 Subject: [M3devel] CM3 on windows In-Reply-To: References: <20090828020144.B5E7C1A209A@async.async.caltech.edu> Message-ID: <20090828094553.hbdkyxsi8ss84oos@mail.elegosoft.com> I don't think Juno and mentor ever worked without an X server. The Trestle implementation on Windows was never complete nor stable enough for that AFAIK. Using the X implementation and an X server on Windows should work though (but I haven't tried that for years with M3). Of course it would be great if somebody took care to fix the Trestle ui package for Windows. Others please contradict me if I'm out of date here. Olaf Quoting Jay K : > > I fixed the access on 5.8.2. > Try that? > I can poke around.. > > As I recall 5.8.1 used VC 8.0 and 5.8.2 used 9.0. > If that helps. > > - Jay > > > ---------------------------------------- >> To: m3devel at elegosoft.com; jay.krell at cornell.edu >> CC: mika at async.caltech.edu >> Subject: CM3 on windows >> Date: Thu, 27 Aug 2009 19:01:44 -0700 >> From: mika at async.async.caltech.edu >> >> Hi m3devel, >> >> Not sure if my earlier message today went anywhere. I never saw it on >> the list. >> >> I'd like to try running CM3 on Windows 2000, so I've downloaded >> >> http://www.opencm3.com/uploaded-archives/cm3-std-NT386-d5.8.1.msi >> >> (5.8.2 didn't work---no access). >> >> Having installed it as well as I can figure, following the directions at >> >> http://www.opencm3.com/installation-windows.html >> >> I don't really seem to get all the way. Compiling in the CMD window fails >> at a link (can't find winspool.lib), and the binaries have problems. >> >> Funnily enough, WebScape seems to work (as well or poorly as anywhere else), >> but mentor and Juno both fail miserably: >> >> >> mika at scruff /cygdrive/c/cm3/bin >> $ ./mentor >> >> >> *** >> *** runtime error: >> *** Attempt to reference an illegal memory location. >> *** pc = 0x1061634 = GetAttributes + 0x179 in >> ..\src\lego\WIN32\ScrollerVBTCl >> ass.m3 >> *** >> >> Stack trace: >> FP PC Procedure >> --------- --------- ------------------------------- >> 0x30af668 0x6a6e4d SystemError + 0x66 in ..\src\runtime\NT386\RTSignal.m3 >> 0x30af70c 0x1061634 GetAttributes + 0x179 in >> ..\src\lego\WIN32\ScrollerVBTClas >> s.m3 >> 0x30af7e4 0x10993d8 AddView + 0x101e(!) in ..\src\lego\ViewportVBT.m3 >> 0x30af830 0x109743e Init + 0x30e in ..\src\lego\ViewportVBT.m3 >> 0x30af950 0x1004ee0 pViewport + 0x512 in ..\src\FormsVBT.m3 >> 0x30af9b0 0xff33df Item + 0x48b in ..\src\FormsVBT.m3 >> 0x30af9dc 0x1010f66 OneChild + 0xf8 in ..\src\FormsVBT.m3 >> 0x30afae4 0xff7448 pShape + 0x19c in ..\src\FormsVBT.m3 >> 0x30afb44 0xff33df Item + 0x48b in ..\src\FormsVBT.m3 >> 0x30afb70 0x1010f66 OneChild + 0xf8 in ..\src\FormsVBT.m3 >> ......... ......... ... more frames ... >> >> mika at scruff /cygdrive/c/cm3/bin >> $ ./Juno >> >> >> *** >> *** runtime error: >> *** failed. >> *** file "..\src\winvbt\WinContext.m3", line 165 >> *** >> >> Stack trace: >> FP PC Procedure >> --------- --------- ------------------------------- >> 0x1b6f854 0xea1e03 PushPixmap + 0x4cb in ..\src\winvbt\WinContext.m3 >> 0x1b6f91c 0xeb10c7 PixmapCom + 0x9ed in ..\src\winvbt\WinPaint.m3 >> 0x1b6fd78 0xeaedaf PaintBatch + 0x25f in ..\src\winvbt\WinPaint.m3 >> 0x1b6fde4 0xea91f3 PaintBatchVBT + 0x13f in ..\src\winvbt\WinTrestle.m3 >> 0x1b6fe2c 0xea7919 WindowProc + 0x763 in ..\src\winvbt\WinTrestle.m3 >> 0x1b6fe4c 0x77e3a454 >> 0x1b6fed8 0x77e14605 >> 0x1b6ff30 0x77e15b77 >> 0x1b6ff88 0x4fb015 RunThread + 0x234 in ..\src\thread\WIN32\ThreadWin32.m3 >> 0x1b6ffb4 0x4fad57 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3 >> ......... ......... ... more frames ... >> >> mika at scruff /cygdrive/c/cm3/bin >> $ >> >> This is running from the cygwin shell but it doesn't do anything different >> from CMD... >> >> Should I not expect to be able to get this to work? >> >> Mika -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Fri Aug 28 10:09:03 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 28 Aug 2009 10:09:03 +0200 Subject: [M3devel] strange code in scripts In-Reply-To: References: Message-ID: <20090828100903.7lsknqfqt5w0csk4@mail.elegosoft.com> I assume you're talking about make-bin-dist-min.sh. Quoting Jay K : > This sequence is odd: > > [ ${TARGET} != NT386 ] && "${ROOT}/scripts/do-pkg.sh" buildship > echo "${ROOT}/scripts/do-cm3-${DIST}.sh" buildlocal > "${ROOT}/scripts/do-cm3-${DIST}.sh" buildlocal || exit 1 > > header "stage 4: installing libraries using new cm3 compiler" > echo "${ROOT}/scripts/do-cm3-${DIST}.sh" buildglobal > "${ROOT}/scripts/do-cm3-${DIST}.sh" buildglobal || exit 1 > > The first line doesn't do anything. > In the logs you can see it just says "no packages". Have a look at http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/scripts/make-bin-dist-min.sh?annotate=1.42.2.5 This line is from Tony with the following comment: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/scripts/make-bin-dist-min.sh#rev1.24 It should be completely removed. > I don't understand why buildlocal + buildglobal. This is (a) a reasonable precaution, as building local will test everything before shipping it, and (b) it will show us if both building against the workspace and against the global package pool succeeds. Missing/wrong overrides have often enough broken the released packages. > Is that, um, to delete the .M3OVERRIDES files, so that "On the other side", > ship won't refuse? Of course, if we'd only build with overrides we couldn't ship anything. The second run will mostly just change the .M3SHIP files (and relink some programs, because M3 is usually not smart enough to avoid that -- but the discussion about dynamic linking has shown that that can be viewed as a feature :-). Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Fri Aug 28 10:15:11 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 28 Aug 2009 10:15:11 +0200 Subject: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems In-Reply-To: References: <20090826142644.r6yabwff5wc84cgg@mail.elegosoft.com> <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> Message-ID: <20090828101511.zsm14bsqow0k4w8o@mail.elegosoft.com> Quoting Jay K : > It was backslashes vs. forward slashes as I had originally suspected. > My debugprinting never hit because I was guessing the elego paths wrong. > I finally made it always print and tested it in-situ in the VM. So we now have Windows packages on birch for RC3? No, not yet. But I see that makedist is currently running... I think we should do something about this pathname confusion on Windows. See separate mail. Olaf > > - Jay > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] RC3 build problems, was: RE: caltech-parser >> NT386 Hudson problems >> Date: Thu, 27 Aug 2009 12:15:14 +0000 >> >> >> My current theory is the unresolve problem is due to that wierd >> initial build of import-libs in the Hudson task, which was related >> to the line endings problem, which was related to using CVSNT >> instead of Cygwin cvs. >> >> - Jay >> >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: wagner at elegosoft.com >>> CC: m3devel at elegosoft.com >>> Subject: RE: [M3devel] RC3 build problems, was: RE: caltech-parser >>> NT386 Hudson problems >>> Date: Thu, 27 Aug 2009 06:09:52 +0000 >>> >>> >>> I'm testing a fix for the VM right now actually. >>> Once that works I'll look into the Unresolve problem further. I >>> put in some printing to help diagnose it and possibly a fix. It >>> could be a slash mixup; the printing will tell us. >>> The VBT problem is new seeming. I'll look at that too. >>> Anyone else is welcome to also. >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> Date: Thu, 27 Aug 2009 08:06:57 +0200 >>>> From: wagner at elegosoft.com >>>> To: jay.krell at cornell.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: [M3devel] RC3 build problems, was: RE: caltech-parser >>>> NT386 Hudson problems >>>> >>>> Quoting Jay K : >>>> >>>>> Something or some things very wierd here. I'll keep looking into it. >>>> I'm not sure if we should spend/waste(?) more time in trying to make >>>> this VM with Windows work. >>>> >>>> Last night I reactivated my own qemu-based VM and was able to checkout >>>> and build some current CM3 stuff. >>>> >>>> CVS behaves correctly there, and no need to adapt any of the shell >>>> scripts at all. It's agonizingly slow though. And it has no remote >>>> access. >>>> >>>> However, building the release archives failed with two errors: >>>> >>>> vbtkit: >>>> new source -> compiling VBTKitResources.m3 >>>> "..\src\lego\VBTKitResources.m3", line 10: unable to find interface >>>> (VBTKitBundle) >>>> 1 error encountered >>>> >>>> and >>>> >>>> errors during build-all; some packages will be missing >>>> m3-win/import-libs/NT386/.M3SHIP seems to be broken: >>>> make_dir("c:/tmp/cm3/lib") >>>> install_file("wsock32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("advapi32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("opengl32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("netapi32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("comctl32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("user32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("comdlg32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("kernel32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("winspool.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("glu32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("gdi32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("odbc32.lib", "c:/tmp/cm3/lib", "0775") >>>> >>>> (wrong shippind destination, already reported) >>>> >>>> I suggest we rather concentrate on these and build the Windows >>>> packages manually. >>>> >>>> I'm off to (paid) work again now... >>>> >>>> Olaf >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>> DE163214194 >>>> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Fri Aug 28 10:26:35 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 28 Aug 2009 10:26:35 +0200 Subject: [M3devel] Change Pathname abstraction for Windows? was: RE: RC3 build problems, was: RE: caltech-parser NT386 Hudson problems In-Reply-To: References: <20090826142644.r6yabwff5wc84cgg@mail.elegosoft.com> <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> Message-ID: <20090828102635.0iyxllukro8o44o4@mail.elegosoft.com> Quoting Jay K : > It was backslashes vs. forward slashes as I had originally suspected. > My debugprinting never hit because I was guessing the elego paths wrong. > I finally made it always print and tested it in-situ in the VM. It is amazing how much (pointless) work the difference in pathname denotations on Windows and POSIX systems has caused and still causes. While there are some conceptual differences that cannot easily be generalized (one root <-> many roots, logical <-> physical view of disks etc.), the simple fact that Windows uses \ instead of / makes life needlessly difficult for many programmers. In Modula-3, the Pathname interface is intended to abstract from this, but this works only to a certain degree. It uses \ as the arc separator on Windows, while in fact all modern Windows systems accept both \ and /. I think this should be corrected. Pathnames should be split into elements at both \ and / on Windows, and checks for equality should ignore any differences in separator characters only. Does this sound reasonable? Is there any (non)obvious problem I'm overseeing right now which will make this strategy fail? Olaf PS: I'm not suggesting we do that in this release of course... -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Fri Aug 28 11:11:50 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 28 Aug 2009 05:11:50 -0400 Subject: [M3devel] small design problem in ButtonVBT? In-Reply-To: <36DAB001-70F3-4C96-B1D5-57E8A7322464@cs.purdue.edu> References: <20090331145127.GB9624@topoi.pooq.com> <20090401120347.x8cneize8oscg44o@mail.elegosoft.com> <20090826002606.GB16386@topoi.pooq.com> <20090827141741.9g1u2vrgfgokkksg@mail.elegosoft.com> <20090828031722.GB22883@topoi.pooq.com> <36DAB001-70F3-4C96-B1D5-57E8A7322464@cs.purdue.edu> Message-ID: <20090828091150.GA23396@topoi.pooq.com> On Thu, Aug 27, 2009 at 11:53:27PM -0400, Tony Hosking wrote: > Right. Plus, overriding copies the entire method suite for the new > type. Now that makes sense. I'll re-evaluate my suggestion in this light. > > On 27 Aug 2009, at 23:28, Jay K wrote: > > > > >I think I know the reason it is this way. > >It is very common to override action and nothing else. > >It is "inconvenient" to derive a new type, just to change one > >function. It's more a matter of letting the action procedure or method have clean access to application data in the subclassed function. But your code suggests a simpler way to do this than either your code or mine. It takes a run-time type check, which is conceptually messy. But the code is smaller, and seems to have a smaller memory footprint. See below. > > > >- Jay > > > >---------------------------------------- > >>Date: Thu, 27 Aug 2009 23:17:23 -0400 > >>From: hendrik at topoi.pooq.com > >>To: m3devel at elegosoft.com > >>Subject: Re: [M3devel] small design problem in ButtonVBT? > >> > >>On Thu, Aug 27, 2009 at 03:15:41PM -0400, Tony Hosking wrote: > >>>I am nervous about having the two alternative entries to the action > >>>procedure that other code might not be aware of. Yes, you've > >>>modified > >>>the default mouse method to call the action method instead of the > >>>procedure, but what about other places where the mouse method has > >>>been > >>>overridden. Yes. That could be an issue. But only if act is also overridden, which won't happen in legacy code, since the defauly act behaves identically to the action procedure. > >>> > >>>If you want to be smart about it in your own code you can simply > >>>invert your suggestion and do the following: > >>> > >>>TYPE T = ButtonVBT.T OBJECT > >>>METHODS action(cd: VBT.MouseRec) := Action; > >>> > >>>PROCEDURE Action(v: T; cd: VBT.MouseRec) = ... > >>> > >>>PROCEDURE ActionProc(v: ButtonVBT.T; cd: VBT.MouseRec) = > >>>BEGIN > >>>NARROW(v, T).action(cd); > >>>END ActionProc; > >>> > >>>and initialize your T thingy with ButtonVBT.New(..., action := > >>>ActionProc; ...) > >>> > >>>Then in your code you can go ahead and override the action method to > >>>your hearts content. But I can simplify this further. TYPE T = ButtonVBT.T OBJECT (* as you propose. *) For each action that I had wanted a subclass for, write PROCEDURE Action(vv: T; cd: VBT.MouseRec) = ... VAR v : T; BEGIN v := NARROW(vv, T); ... normal code for performing the action END Action; and initialize my T thingy using this Action. So instead of multiple subclasses to get the various actions, I get two extra lines of code in each action procedure. And I don't have to use GetProp or PutProp (which probably involve some kind of search). The run-time cost is the type-check in the NARROW(vv, T), which is probably cheaper than a method-dispatch on act. Hmmm. I'm starting to think you're right, and my change is unnecessary. I'll have a look in my applicatin code, and see if there are further glitches. I'm not expecting any. -- hendrik > >> > >>This kind of thing would work. But, like the existing semantics of > >>ButtonVBT, it seems to be fighting the language instead of working > >>with > >>it. I'd be happiest to get rid of the action variable altogether, but > >>that would be a massively incompatible change, and would require > >>change > >>to a lot of existing code. What I proposed is compatible with > >>existing > >>code, and also has the advantage that someone who subclasses > >>ButtonVBT.T > >>and overrides act can completely ignore the action variable > >>altogether. > >> > >>You say > >> > >>>and initialize your T thingy with ButtonVBT.New(..., action := > >>>ActionProc; ...) > >> > >>But that requires every object I make of type T or any sibclass to be > >>explicitly initialised with ActionProc, certainly a nuisance, and > >>certainly error-prone. > >> > >>The inelegance I see with my approach is that there are two > >>mechanisms > >>for specifying the action to be taken. Either will work without the > >>programmer paying any attention to the other, but if you use both, > >>one > >>will override the other. This is not a problem with legacy software. > >>I'll have to come up with some documentation that makes this clear. > >>It's the inelegance that comes from backward compatibility, and I > >>think > >>my solution is less inelegant, and easier to use, than yours. Yours, > >>however, involves no change in existing code. > >> > >>> > >>>Am I just being paranoid? > >> > >>No. Perhaps just paranoid about different things. > >> > >>I had hoped for someone to come up with a solid technical reason > >>for the > >>action variable. The original designers were clever people, and I'd > >>*still* like to know why they thought it was a good idea. It's > >>awkward > >>and error-prone to use, and they had to use the PutProp/GetProp > >>kludge > >>just to approximate what the language provided for free with > >>inheritance. > >> > >>I'm tempted to go over the entire code-base and change the buttons to > >>use act instead of action, but I have to admit I'm not tempted > >>enough to > >>actually do it... > >> > >>-- hendrik > >> > >>>On 27 Aug 2009, at 08:17, Olaf Wagner wrote: > >>> > >>>>Though I promised to do it, I have lost sight of this task while > >>>>trying to build some RC3 archives on Windows. As I'm not at home > >>>>this > >>>>evening, can somebody else please commit Hendrik's extension? > >>>> > >>>>Is this something we should should have in the release branch, too? > >>>>Probably not necessary? > >>>> > >>>>Olaf > >>>> > >>>>Quoting hendrik at topoi.pooq.com: > >>>> > >>>>>On Wed, Apr 01, 2009 at 12:03:47PM +0200, Olaf Wagner wrote: > >>>>>>Quoting hendrik at topoi.pooq.com: > >>>>>> > >>>>>>>The BottonVBT contains an action, which is a procedure rather > >>>>>>than a > >>>>>>>method. b This makes it awkward to subclass ButtonVBT becaue the > >>>>>>action > >>>>>>>will still expect its first parameter to be a ButtonVBT > >>>>>>>instead of > >>>>>>>belonging to the subclass, and an explicit downcast of some sort > >>>>>>will be > >>>>>>>needed to acess the subclass's members. > >>>>>>> > >>>>>>>The Trestle manual says this was a deliberate decision: > >>>>>>> > >>>>>>>: The action procedure is a field rather than a method in order > >>>>>>to allow > >>>>>>>: buttons with different action procedures to share their method > >>>>>>suites. > >>>>>>> > >>>>>>>I, however, find it massively inconvenient because it mans I > >>>>>>>have > >>>>>>to > >>>>>>>resort to downcasting or the very kludgey VBT.GetProp to access > >>>>>>what > >>>>>>>should be just there. I'd rather the action procedure was a > >>>>>>method. > >>>>>>> > >>>>>>>But it should be possible to have the best of both worlds. > >>>>>>>Have an > >>>>>>>action2 (better name wanted here) method that is available for > >>>>>>>overriding, and by default calls the procedure in the existing > >>>>>>action. > >>>>>>>field. That action2 method wounl then be called by Trestle > >>>>>>wherever > >>>>>>>action is now called. > >>>>>>> > >>>>>>>Does anyone see problems with this? > >>>>>> > >>>>>>Sounds fine to me offhand. You should test your extensions with > >>>>>>some of the existing larger applications, like mentor and Juno-2, > >>>>>>of course. > >>>>> > >>>>>OK. Here's the patch. Would it be possible for someone to check it > >>>>>in > >>>>>for me? > >>>>> > >>>>>mentor runs fine with this change; I watched it animate a heap- > >>>>>sort. > >>>>> > >>>>>I have no idea what Juno is supposed to do, but it did respond to > >>>>>button-pushes. > >>>>> > >>>>> > >>>>>hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ cvs diff > >>>>>cvs diff: Diffing . > >>>>>Index: ButtonVBT.i3 > >>>>>= > >>>>>================================================================== > >>>>>RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.i3,v > >>>>>retrieving revision 1.2 > >>>>>diff -r1.2 ButtonVBT.i3 > >>>>>39a40 > >>>>>>act(READONLY cd: VBT.MouseRec); > >>>>>Index: ButtonVBT.m3 > >>>>>= > >>>>>================================================================== > >>>>>RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.m3,v > >>>>>retrieving revision 1.2 > >>>>>diff -r1.2 ButtonVBT.m3 > >>>>>28c28,29 > >>>>>< init := Be > >>>>>--- > >>>>>>init := Be; > >>>>>>act := act > >>>>>46a48,52 > >>>>>>PROCEDURE act(v : T; READONLY cd: VBT.MouseRec) = > >>>>>>BEGIN > >>>>>>v.action(v, cd); > >>>>>>END act; > >>>>>> > >>>>>59c65 > >>>>>< v.action(v, cd); > >>>>>--- > >>>>>>v.act(cd); > >>>>>hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ > >>>>> > >>>>>-- hendrik > >>>>> > >>>> > >>>> > >>>> > >>>>-- > >>>>Olaf Wagner -- elego Software Solutions GmbH > >>>>Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > >>>>Germany > >>>>phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > >>>>45 86 95 > >>>>http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > >>>>Berlin > >>>>Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > >>>>DE163214194 > >>>> > >>> > From hendrik at topoi.pooq.com Fri Aug 28 11:21:41 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 28 Aug 2009 05:21:41 -0400 Subject: [M3devel] CM3 on windows In-Reply-To: References: <20090828020144.B5E7C1A209A@async.async.caltech.edu> <20090828034057.475DD1A209A@async.async.caltech.edu> <20090828042715.B05E51A20A1@async.async.caltech.edu> <20090828045055.BA3C81A20A1@async.async.caltech.edu> Message-ID: <20090828092141.GB23396@topoi.pooq.com> On Fri, Aug 28, 2009 at 05:03:58AM +0000, Jay K wrote: > > Yes NT386GNU uses X. > Olaf expressed an interest in that. > Apparently the Windows port of Trestle has never been completed. > (I suspect we should punt Trestle and bind to Qt, but that is another > matter.) I've been wondering about that point with one of my applications -- Does Trestle have access to the underlying OS's fonts, or does it provide its own. I'm specifically thinking of the huge Unicode fonts, and suspect that Trestle doesn't has neither its own nor access to the OS's, on either Unix or WIndows. I happened to be wondering about gtk instead of qt, but that's a detail. Are there reasons I should be aware of for preferring one to the other? Portability or other? -- hendrik From jay.krell at cornell.edu Fri Aug 28 12:32:34 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Fri, 28 Aug 2009 06:32:34 -0400 Subject: [M3devel] CM3 on windows In-Reply-To: <20090828094553.hbdkyxsi8ss84oos@mail.elegosoft.com> References: <20090828020144.B5E7C1A209A@async.async.caltech.edu> <20090828094553.hbdkyxsi8ss84oos@mail.elegosoft.com> Message-ID: I'll have to double check but I thought Juno and mentor both worked a bunch. automation to really put them through their paces welcome. :) - Jay (phone) On Aug 28, 2009, at 3:45 AM, Olaf Wagner wrote: > I don't think Juno and mentor ever worked without an X server. > The Trestle implementation on Windows was never complete nor > stable enough for that AFAIK. > > Using the X implementation and an X server on Windows should work > though (but I haven't tried that for years with M3). > > Of course it would be great if somebody took care to fix the > Trestle ui package for Windows. > > Others please contradict me if I'm out of date here. > > Olaf > > Quoting Jay K : > >> >> I fixed the access on 5.8.2. >> Try that? >> I can poke around.. >> >> As I recall 5.8.1 used VC 8.0 and 5.8.2 used 9.0. >> If that helps. >> >> - Jay >> >> >> ---------------------------------------- >>> To: m3devel at elegosoft.com; jay.krell at cornell.edu >>> CC: mika at async.caltech.edu >>> Subject: CM3 on windows >>> Date: Thu, 27 Aug 2009 19:01:44 -0700 >>> From: mika at async.async.caltech.edu >>> >>> Hi m3devel, >>> >>> Not sure if my earlier message today went anywhere. I never saw it >>> on >>> the list. >>> >>> I'd like to try running CM3 on Windows 2000, so I've downloaded >>> >>> http://www.opencm3.com/uploaded-archives/cm3-std-NT386-d5.8.1.msi >>> >>> (5.8.2 didn't work---no access). >>> >>> Having installed it as well as I can figure, following the >>> directions at >>> >>> http://www.opencm3.com/installation-windows.html >>> >>> I don't really seem to get all the way. Compiling in the CMD >>> window fails >>> at a link (can't find winspool.lib), and the binaries have problems. >>> >>> Funnily enough, WebScape seems to work (as well or poorly as >>> anywhere else), >>> but mentor and Juno both fail miserably: >>> >>> >>> mika at scruff /cygdrive/c/cm3/bin >>> $ ./mentor >>> >>> >>> *** >>> *** runtime error: >>> *** Attempt to reference an illegal memory location. >>> *** pc = 0x1061634 = GetAttributes + 0x179 in ..\src\lego >>> \WIN32\ScrollerVBTCl >>> ass.m3 >>> *** >>> >>> Stack trace: >>> FP PC Procedure >>> --------- --------- ------------------------------- >>> 0x30af668 0x6a6e4d SystemError + 0x66 in ..\src\runtime >>> \NT386\RTSignal.m3 >>> 0x30af70c 0x1061634 GetAttributes + 0x179 in ..\src\lego >>> \WIN32\ScrollerVBTClas >>> s.m3 >>> 0x30af7e4 0x10993d8 AddView + 0x101e(!) in ..\src\lego >>> \ViewportVBT.m3 >>> 0x30af830 0x109743e Init + 0x30e in ..\src\lego\ViewportVBT.m3 >>> 0x30af950 0x1004ee0 pViewport + 0x512 in ..\src\FormsVBT.m3 >>> 0x30af9b0 0xff33df Item + 0x48b in ..\src\FormsVBT.m3 >>> 0x30af9dc 0x1010f66 OneChild + 0xf8 in ..\src\FormsVBT.m3 >>> 0x30afae4 0xff7448 pShape + 0x19c in ..\src\FormsVBT.m3 >>> 0x30afb44 0xff33df Item + 0x48b in ..\src\FormsVBT.m3 >>> 0x30afb70 0x1010f66 OneChild + 0xf8 in ..\src\FormsVBT.m3 >>> ......... ......... ... more frames ... >>> >>> mika at scruff /cygdrive/c/cm3/bin >>> $ ./Juno >>> >>> >>> *** >>> *** runtime error: >>> *** failed. >>> *** file "..\src\winvbt\WinContext.m3", line 165 >>> *** >>> >>> Stack trace: >>> FP PC Procedure >>> --------- --------- ------------------------------- >>> 0x1b6f854 0xea1e03 PushPixmap + 0x4cb in ..\src\winvbt\WinContext.m3 >>> 0x1b6f91c 0xeb10c7 PixmapCom + 0x9ed in ..\src\winvbt\WinPaint.m3 >>> 0x1b6fd78 0xeaedaf PaintBatch + 0x25f in ..\src\winvbt\WinPaint.m3 >>> 0x1b6fde4 0xea91f3 PaintBatchVBT + 0x13f in ..\src\winvbt >>> \WinTrestle.m3 >>> 0x1b6fe2c 0xea7919 WindowProc + 0x763 in ..\src\winvbt\WinTrestle.m3 >>> 0x1b6fe4c 0x77e3a454 >>> 0x1b6fed8 0x77e14605 >>> 0x1b6ff30 0x77e15b77 >>> 0x1b6ff88 0x4fb015 RunThread + 0x234 in ..\src\thread >>> \WIN32\ThreadWin32.m3 >>> 0x1b6ffb4 0x4fad57 ThreadBase + 0x3a in ..\src\thread >>> \WIN32\ThreadWin32.m3 >>> ......... ......... ... more frames ... >>> >>> mika at scruff /cygdrive/c/cm3/bin >>> $ >>> >>> This is running from the cygwin shell but it doesn't do anything >>> different >>> from CMD... >>> >>> Should I not expect to be able to get this to work? >>> >>> Mika > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ > any > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be > rlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > From jay.krell at cornell.edu Fri Aug 28 13:11:07 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Fri, 28 Aug 2009 07:11:07 -0400 Subject: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems In-Reply-To: <20090828101511.zsm14bsqow0k4w8o@mail.elegosoft.com> References: <20090826142644.r6yabwff5wc84cgg@mail.elegosoft.com> <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> <20090828101511.zsm14bsqow0k4w8o@mail.elegosoft.com> Message-ID: Olaf wrote: > > So we now have Windows packages on birch for RC3? No, not yet. > But I see that makedist is currently running... Seems like it got further and then the node disappeared and hasn't reappeared. :( - Jay (phone) From wagner at elegosoft.com Fri Aug 28 13:58:01 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 28 Aug 2009 13:58:01 +0200 Subject: [M3devel] CM3 on windows In-Reply-To: References: <20090828020144.B5E7C1A209A@async.async.caltech.edu> <20090828094553.hbdkyxsi8ss84oos@mail.elegosoft.com> Message-ID: <20090828135801.rja2kahis8wo8ocg@mail.elegosoft.com> Quoting jay.krell at cornell.edu: > I'll have to double check but I thought Juno and mentor both worked a > bunch. automation to really put them through their paces welcome. :) We don't have any support for testing GUI applications currently. I doubt that it will appear soon ;-) Olaf > - Jay (phone) > > On Aug 28, 2009, at 3:45 AM, Olaf Wagner wrote: > >> I don't think Juno and mentor ever worked without an X server. >> The Trestle implementation on Windows was never complete nor >> stable enough for that AFAIK. >> >> Using the X implementation and an X server on Windows should work >> though (but I haven't tried that for years with M3). >> >> Of course it would be great if somebody took care to fix the >> Trestle ui package for Windows. >> >> Others please contradict me if I'm out of date here. >> >> Olaf >> >> Quoting Jay K : >> >>> >>> I fixed the access on 5.8.2. >>> Try that? >>> I can poke around.. >>> >>> As I recall 5.8.1 used VC 8.0 and 5.8.2 used 9.0. >>> If that helps. >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> To: m3devel at elegosoft.com; jay.krell at cornell.edu >>>> CC: mika at async.caltech.edu >>>> Subject: CM3 on windows >>>> Date: Thu, 27 Aug 2009 19:01:44 -0700 >>>> From: mika at async.async.caltech.edu >>>> >>>> Hi m3devel, >>>> >>>> Not sure if my earlier message today went anywhere. I never saw it on >>>> the list. >>>> >>>> I'd like to try running CM3 on Windows 2000, so I've downloaded >>>> >>>> http://www.opencm3.com/uploaded-archives/cm3-std-NT386-d5.8.1.msi >>>> >>>> (5.8.2 didn't work---no access). >>>> >>>> Having installed it as well as I can figure, following the directions at >>>> >>>> http://www.opencm3.com/installation-windows.html >>>> >>>> I don't really seem to get all the way. Compiling in the CMD window fails >>>> at a link (can't find winspool.lib), and the binaries have problems. >>>> >>>> Funnily enough, WebScape seems to work (as well or poorly as >>>> anywhere else), >>>> but mentor and Juno both fail miserably: >>>> >>>> >>>> mika at scruff /cygdrive/c/cm3/bin >>>> $ ./mentor >>>> >>>> >>>> *** >>>> *** runtime error: >>>> *** Attempt to reference an illegal memory location. >>>> *** pc = 0x1061634 = GetAttributes + 0x179 in >>>> ..\src\lego\WIN32\ScrollerVBTCl >>>> ass.m3 >>>> *** >>>> >>>> Stack trace: >>>> FP PC Procedure >>>> --------- --------- ------------------------------- >>>> 0x30af668 0x6a6e4d SystemError + 0x66 in ..\src\runtime\NT386\RTSignal.m3 >>>> 0x30af70c 0x1061634 GetAttributes + 0x179 in >>>> ..\src\lego\WIN32\ScrollerVBTClas >>>> s.m3 >>>> 0x30af7e4 0x10993d8 AddView + 0x101e(!) in ..\src\lego\ViewportVBT.m3 >>>> 0x30af830 0x109743e Init + 0x30e in ..\src\lego\ViewportVBT.m3 >>>> 0x30af950 0x1004ee0 pViewport + 0x512 in ..\src\FormsVBT.m3 >>>> 0x30af9b0 0xff33df Item + 0x48b in ..\src\FormsVBT.m3 >>>> 0x30af9dc 0x1010f66 OneChild + 0xf8 in ..\src\FormsVBT.m3 >>>> 0x30afae4 0xff7448 pShape + 0x19c in ..\src\FormsVBT.m3 >>>> 0x30afb44 0xff33df Item + 0x48b in ..\src\FormsVBT.m3 >>>> 0x30afb70 0x1010f66 OneChild + 0xf8 in ..\src\FormsVBT.m3 >>>> ......... ......... ... more frames ... >>>> >>>> mika at scruff /cygdrive/c/cm3/bin >>>> $ ./Juno >>>> >>>> >>>> *** >>>> *** runtime error: >>>> *** failed. >>>> *** file "..\src\winvbt\WinContext.m3", line 165 >>>> *** >>>> >>>> Stack trace: >>>> FP PC Procedure >>>> --------- --------- ------------------------------- >>>> 0x1b6f854 0xea1e03 PushPixmap + 0x4cb in ..\src\winvbt\WinContext.m3 >>>> 0x1b6f91c 0xeb10c7 PixmapCom + 0x9ed in ..\src\winvbt\WinPaint.m3 >>>> 0x1b6fd78 0xeaedaf PaintBatch + 0x25f in ..\src\winvbt\WinPaint.m3 >>>> 0x1b6fde4 0xea91f3 PaintBatchVBT + 0x13f in ..\src\winvbt\WinTrestle.m3 >>>> 0x1b6fe2c 0xea7919 WindowProc + 0x763 in ..\src\winvbt\WinTrestle.m3 >>>> 0x1b6fe4c 0x77e3a454 >>>> 0x1b6fed8 0x77e14605 >>>> 0x1b6ff30 0x77e15b77 >>>> 0x1b6ff88 0x4fb015 RunThread + 0x234 in ..\src\thread\WIN32\ThreadWin32.m3 >>>> 0x1b6ffb4 0x4fad57 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3 >>>> ......... ......... ... more frames ... >>>> >>>> mika at scruff /cygdrive/c/cm3/bin >>>> $ >>>> >>>> This is running from the cygwin shell but it doesn't do anything different >>>> from CMD... >>>> >>>> Should I not expect to be able to get this to work? >>>> >>>> Mika >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Fri Aug 28 14:06:40 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 28 Aug 2009 14:06:40 +0200 Subject: [M3devel] elego-win-vm unreachable again Message-ID: <20090828140640.krinzx4ls0wco08w@mail.elegosoft.com> Hi Kay, why does the route/tunnel to elego-win-vm keep vanishing? There have been no reboots? [08/28/09 13:46:54] Launching slave agent $ ssh -p 2222 elego at localhost2 "java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=29999 -jar c:\cygwin\home\elego\slave.jar -text" ssh: connect to host localhost2 port 2222: Connection refused Unable to launch the slave agent for elego-win-vm java.io.EOFException: unexpected stream termination at hudson.remoting.Channel.(Channel.java:313) at hudson.remoting.Channel.(Channel.java:252) at hudson.slaves.SlaveComputer.setChannel(SlaveComputer.java:283) at hudson.slaves.CommandLauncher.launch(CommandLauncher.java:111) at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:175) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:619) Please check and install a watch script which rebuilds the tunnel when necessary. TIA, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Aug 28 12:30:20 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Fri, 28 Aug 2009 06:30:20 -0400 Subject: [M3devel] CM3 on windows In-Reply-To: <20090828092141.GB23396@topoi.pooq.com> References: <20090828020144.B5E7C1A209A@async.async.caltech.edu> <20090828034057.475DD1A209A@async.async.caltech.edu> <20090828042715.B05E51A20A1@async.async.caltech.edu> <20090828045055.BA3C81A20A1@async.async.caltech.edu> <20090828092141.GB23396@topoi.pooq.com> Message-ID: <726E21C8-625B-4B2C-8089-2038B9930AB5@hotmail.com> Fonts I don't know. I don't think gtk folks care much about windows. Qt folks do. - Jay (phone) On Aug 28, 2009, at 5:21 AM, hendrik at topoi.pooq.com wrote: > On Fri, Aug 28, 2009 at 05:03:58AM +0000, Jay K wrote: >> >> Yes NT386GNU uses X. >> Olaf expressed an interest in that. >> Apparently the Windows port of Trestle has never been completed. >> (I suspect we should punt Trestle and bind to Qt, but that is another >> matter.) > > I've been wondering about that point with one of my applications -- > Does > Trestle have access to the underlying OS's fonts, or does it provide > its > own. I'm specifically thinking of the huge Unicode fonts, and suspect > that Trestle doesn't has neither its own nor access to the OS's, on > either Unix or WIndows. > > I happened to be wondering about gtk instead of qt, but that's a > detail. > Are there reasons I should be aware of for preferring one to the > other? > Portability or other? > > -- hendrik > > From jay.krell at cornell.edu Fri Aug 28 13:33:45 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Fri, 28 Aug 2009 07:33:45 -0400 Subject: [M3devel] Change Pathname abstraction for Windows? was: RE: RC3 build problems, was: RE: caltech-parser NT386 Hudson problems In-Reply-To: <20090828102635.0iyxllukro8o44o4@mail.elegosoft.com> References: <20090826142644.r6yabwff5wc84cgg@mail.elegosoft.com> <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> <20090828102635.0iyxllukro8o44o4@mail.elegosoft.com> Message-ID: <17E1903E-EA50-4EF3-8273-C55B0FE1952C@hotmail.com> I believe this goes back to CP/M compatibility. I wish the file open dialogs accepted forward slashes. :( I will change cm3 to write back into quake state the canonicalized forms. I believe I already changed Pathname on Windows to accept either slash. I need to check if equality uses decomposed elements. Lots of folks just use strings and skip the abstraction, such as cm3. My personal programming often uses a small library over strings -- GetLastPathElement, RemoveLastElement, JoinPath, EnsureTrailingPathSeparator, ... IMHO you might as well also have posix allow backward slashes as separators, but that was rejected here. To wit I believe cygwin now accepts colons and backward slashes in paths, as non-separators. Interix also one or the other or both. Interix encodes them by oring in 0xFF00 (what happens with Samba to ext3??) There are other issues such as case sensivity not being an OS-wide thing but per volume or directory (NTFS has mount points, directories can lead to volumes, with different filesystems) as well as just what the case mapping tables are (written to NTFS volume at time of format, presumably can vary). The Mac historically used colon as separator and allowed forward slash as non separator. Presumably hidden through some encoding/decoding at the posix layer? - Jay (phone) On Aug 28, 2009, at 4:26 AM, Olaf Wagner wrote: > Quoting Jay K : > >> It was backslashes vs. forward slashes as I had originally suspected. >> My debugprinting never hit because I was guessing the elego paths >> wrong. >> I finally made it always print and tested it in-situ in the VM. > > It is amazing how much (pointless) work the difference in pathname > denotations on Windows and POSIX systems has caused and still causes. > While there are some conceptual differences that cannot easily be > generalized (one root <-> many roots, logical <-> physical view of > disks etc.), the simple fact that Windows uses \ instead of / > makes life needlessly difficult for many programmers. > > In Modula-3, the Pathname interface is intended to abstract from > this, but this works only to a certain degree. It uses \ as the > arc separator on Windows, while in fact all modern Windows systems > accept both \ and /. I think this should be corrected. > > Pathnames should be split into elements at both \ and / on Windows, > and checks for equality should ignore any differences in separator > characters only. Does this sound reasonable? > > Is there any (non)obvious problem I'm overseeing right now which > will make this strategy fail? > > Olaf > > PS: I'm not suggesting we do that in this release of course... > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ > any > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be > rlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > From hosking at cs.purdue.edu Fri Aug 28 15:44:14 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 28 Aug 2009 09:44:14 -0400 Subject: [M3devel] small design problem in ButtonVBT? In-Reply-To: <20090828091150.GA23396@topoi.pooq.com> References: <20090331145127.GB9624@topoi.pooq.com> <20090401120347.x8cneize8oscg44o@mail.elegosoft.com> <20090826002606.GB16386@topoi.pooq.com> <20090827141741.9g1u2vrgfgokkksg@mail.elegosoft.com> <20090828031722.GB22883@topoi.pooq.com> <36DAB001-70F3-4C96-B1D5-57E8A7322464@cs.purdue.edu> <20090828091150.GA23396@topoi.pooq.com> Message-ID: <570C6C84-C41D-446E-A43C-13F85F1C378C@cs.purdue.edu> Yes, exactly! I don't think the change is needed and goes against the grain of a pervasive design principle. We might question that decision, but I hesitate to apply a piecemeal tweak that violates the principle. On 28 Aug 2009, at 05:11, hendrik at topoi.pooq.com wrote: > On Thu, Aug 27, 2009 at 11:53:27PM -0400, Tony Hosking wrote: >> Right. Plus, overriding copies the entire method suite for the new >> type. > > Now that makes sense. I'll re-evaluate my suggestion in this light. > >> >> On 27 Aug 2009, at 23:28, Jay K wrote: >> >>> >>> I think I know the reason it is this way. >>> It is very common to override action and nothing else. >>> It is "inconvenient" to derive a new type, just to change one >>> function. > > It's more a matter of letting the action procedure or method have > clean > access to application data in the subclassed function. But your code > suggests a simpler way to do this than either your code or mine. It > takes a run-time type check, which is conceptually messy. But the > code > is smaller, and seems to have a smaller memory footprint. > > See below. > >>> >>> - Jay >>> >>> ---------------------------------------- >>>> Date: Thu, 27 Aug 2009 23:17:23 -0400 >>>> From: hendrik at topoi.pooq.com >>>> To: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] small design problem in ButtonVBT? >>>> >>>> On Thu, Aug 27, 2009 at 03:15:41PM -0400, Tony Hosking wrote: >>>>> I am nervous about having the two alternative entries to the >>>>> action >>>>> procedure that other code might not be aware of. Yes, you've >>>>> modified >>>>> the default mouse method to call the action method instead of the >>>>> procedure, but what about other places where the mouse method has >>>>> been >>>>> overridden. > > Yes. That could be an issue. But only if act is also overridden, > which > won't happen in legacy code, since the defauly act behaves identically > to the action procedure. > >>>>> >>>>> If you want to be smart about it in your own code you can simply >>>>> invert your suggestion and do the following: >>>>> >>>>> TYPE T = ButtonVBT.T OBJECT >>>>> METHODS action(cd: VBT.MouseRec) := Action; >>>>> >>>>> PROCEDURE Action(v: T; cd: VBT.MouseRec) = ... >>>>> >>>>> PROCEDURE ActionProc(v: ButtonVBT.T; cd: VBT.MouseRec) = >>>>> BEGIN >>>>> NARROW(v, T).action(cd); >>>>> END ActionProc; >>>>> >>>>> and initialize your T thingy with ButtonVBT.New(..., action := >>>>> ActionProc; ...) >>>>> >>>>> Then in your code you can go ahead and override the action >>>>> method to >>>>> your hearts content. > > But I can simplify this further. > > TYPE T = ButtonVBT.T OBJECT (* as you propose. *) > > For each action that I had wanted a subclass for, write > > PROCEDURE Action(vv: T; cd: VBT.MouseRec) = ... > VAR v : T; > BEGIN > v := NARROW(vv, T); > ... normal code for performing the action > END Action; > > and initialize my T thingy using this Action. > > So instead of multiple subclasses to get the various actions, I get > two > extra lines of code in each action procedure. And I don't have to use > GetProp or PutProp (which probably involve some kind of search). The > run-time cost is the type-check in the NARROW(vv, T), which is > probably > cheaper than a method-dispatch on act. > > Hmmm. I'm starting to think you're right, and my change is > unnecessary. > > I'll have a look in my applicatin code, and see if there are further > glitches. I'm not expecting any. > > -- hendrik > >>>> >>>> This kind of thing would work. But, like the existing semantics of >>>> ButtonVBT, it seems to be fighting the language instead of working >>>> with >>>> it. I'd be happiest to get rid of the action variable altogether, >>>> but >>>> that would be a massively incompatible change, and would require >>>> change >>>> to a lot of existing code. What I proposed is compatible with >>>> existing >>>> code, and also has the advantage that someone who subclasses >>>> ButtonVBT.T >>>> and overrides act can completely ignore the action variable >>>> altogether. >>>> >>>> You say >>>> >>>>> and initialize your T thingy with ButtonVBT.New(..., action := >>>>> ActionProc; ...) >>>> >>>> But that requires every object I make of type T or any sibclass >>>> to be >>>> explicitly initialised with ActionProc, certainly a nuisance, and >>>> certainly error-prone. >>>> >>>> The inelegance I see with my approach is that there are two >>>> mechanisms >>>> for specifying the action to be taken. Either will work without the >>>> programmer paying any attention to the other, but if you use both, >>>> one >>>> will override the other. This is not a problem with legacy >>>> software. >>>> I'll have to come up with some documentation that makes this clear. >>>> It's the inelegance that comes from backward compatibility, and I >>>> think >>>> my solution is less inelegant, and easier to use, than yours. >>>> Yours, >>>> however, involves no change in existing code. >>>> >>>>> >>>>> Am I just being paranoid? >>>> >>>> No. Perhaps just paranoid about different things. >>>> >>>> I had hoped for someone to come up with a solid technical reason >>>> for the >>>> action variable. The original designers were clever people, and I'd >>>> *still* like to know why they thought it was a good idea. It's >>>> awkward >>>> and error-prone to use, and they had to use the PutProp/GetProp >>>> kludge >>>> just to approximate what the language provided for free with >>>> inheritance. >>>> >>>> I'm tempted to go over the entire code-base and change the >>>> buttons to >>>> use act instead of action, but I have to admit I'm not tempted >>>> enough to >>>> actually do it... >>>> >>>> -- hendrik >>>> >>>>> On 27 Aug 2009, at 08:17, Olaf Wagner wrote: >>>>> >>>>>> Though I promised to do it, I have lost sight of this task while >>>>>> trying to build some RC3 archives on Windows. As I'm not at home >>>>>> this >>>>>> evening, can somebody else please commit Hendrik's extension? >>>>>> >>>>>> Is this something we should should have in the release branch, >>>>>> too? >>>>>> Probably not necessary? >>>>>> >>>>>> Olaf >>>>>> >>>>>> Quoting hendrik at topoi.pooq.com: >>>>>> >>>>>>> On Wed, Apr 01, 2009 at 12:03:47PM +0200, Olaf Wagner wrote: >>>>>>>> Quoting hendrik at topoi.pooq.com: >>>>>>>> >>>>>>>>> The BottonVBT contains an action, which is a procedure rather >>>>>>>> than a >>>>>>>>> method. b This makes it awkward to subclass ButtonVBT becaue >>>>>>>>> the >>>>>>>> action >>>>>>>>> will still expect its first parameter to be a ButtonVBT >>>>>>>>> instead of >>>>>>>>> belonging to the subclass, and an explicit downcast of some >>>>>>>>> sort >>>>>>>> will be >>>>>>>>> needed to acess the subclass's members. >>>>>>>>> >>>>>>>>> The Trestle manual says this was a deliberate decision: >>>>>>>>> >>>>>>>>> : The action procedure is a field rather than a method in >>>>>>>>> order >>>>>>>> to allow >>>>>>>>> : buttons with different action procedures to share their >>>>>>>>> method >>>>>>>> suites. >>>>>>>>> >>>>>>>>> I, however, find it massively inconvenient because it mans I >>>>>>>>> have >>>>>>>> to >>>>>>>>> resort to downcasting or the very kludgey VBT.GetProp to >>>>>>>>> access >>>>>>>> what >>>>>>>>> should be just there. I'd rather the action procedure was a >>>>>>>> method. >>>>>>>>> >>>>>>>>> But it should be possible to have the best of both worlds. >>>>>>>>> Have an >>>>>>>>> action2 (better name wanted here) method that is available for >>>>>>>>> overriding, and by default calls the procedure in the existing >>>>>>>> action. >>>>>>>>> field. That action2 method wounl then be called by Trestle >>>>>>>> wherever >>>>>>>>> action is now called. >>>>>>>>> >>>>>>>>> Does anyone see problems with this? >>>>>>>> >>>>>>>> Sounds fine to me offhand. You should test your extensions with >>>>>>>> some of the existing larger applications, like mentor and >>>>>>>> Juno-2, >>>>>>>> of course. >>>>>>> >>>>>>> OK. Here's the patch. Would it be possible for someone to >>>>>>> check it >>>>>>> in >>>>>>> for me? >>>>>>> >>>>>>> mentor runs fine with this change; I watched it animate a heap- >>>>>>> sort. >>>>>>> >>>>>>> I have no idea what Juno is supposed to do, but it did respond >>>>>>> to >>>>>>> button-pushes. >>>>>>> >>>>>>> >>>>>>> hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ cvs diff >>>>>>> cvs diff: Diffing . >>>>>>> Index: ButtonVBT.i3 >>>>>>> = >>>>>>> = >>>>>>> = >>>>>>> ================================================================ >>>>>>> RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.i3,v >>>>>>> retrieving revision 1.2 >>>>>>> diff -r1.2 ButtonVBT.i3 >>>>>>> 39a40 >>>>>>>> act(READONLY cd: VBT.MouseRec); >>>>>>> Index: ButtonVBT.m3 >>>>>>> = >>>>>>> = >>>>>>> = >>>>>>> ================================================================ >>>>>>> RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.m3,v >>>>>>> retrieving revision 1.2 >>>>>>> diff -r1.2 ButtonVBT.m3 >>>>>>> 28c28,29 >>>>>>> < init := Be >>>>>>> --- >>>>>>>> init := Be; >>>>>>>> act := act >>>>>>> 46a48,52 >>>>>>>> PROCEDURE act(v : T; READONLY cd: VBT.MouseRec) = >>>>>>>> BEGIN >>>>>>>> v.action(v, cd); >>>>>>>> END act; >>>>>>>> >>>>>>> 59c65 >>>>>>> < v.action(v, cd); >>>>>>> --- >>>>>>>> v.act(cd); >>>>>>> hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ >>>>>>> >>>>>>> -- hendrik >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>>>>> Germany >>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>>>> 45 86 95 >>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>>>>> Berlin >>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>>> DE163214194 >>>>>> >>>>> >> From rodney.m.bates at cox.net Fri Aug 28 15:35:17 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Fri, 28 Aug 2009 08:35:17 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20090828025553.5272F2474002@birch.elegosoft.com> References: <20090828025553.5272F2474002@birch.elegosoft.com> Message-ID: <4A97DD15.1030907@cox.net> Whenever I write/add code, in any language, I am in the habit of always surrounding every identifier with at least one blank, before and after. Otherwise, grepping for all occurrences of an identifier is a nightmare. You usually get overwhelmed with false hits where the identifier you want is a substring of others. This is extremely common. On the other hand, surrounding your search string with the Cartesian product of all the characters that could conceivably surround identifiers in code is a different kind of nightmare, and can fail to find important hits. Combinations of grep piped to grep -v with wild cards, gets closer, but that's a big pain too. (Hmm, maybe sometime I should try to script that.) Starting decades ago, I have wished every string-searching function had some kind of metacharacter to mean "at beginning of identifier" and "at end of identifier". It wouldn't be that hard, and the rules are so very close to language-independent. But, AFAIK, it has never happened. Not that adding the blanks in m3gdb mattered much, since my additions and modifications to it are a tiny subset of what is there. And the surrounding-with-blanks idea only works if you know for certain it has been done everywhere. Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/08/28 04:55:49 > > Modified files: > cm3/m3-sys/m3gdb/gdb/gdb/: Tag: release_branch_cm3_5_8 m3-eval.c > m3-exp.c m3-lang.c m3-threads.c > m3-util.c m3-valprint.c > cm3/m3-sys/m3gdb/gdb/gdb/save/: Tag: release_branch_cm3_5_8 > m3-lang.c m3-lang.h > m3-valprint.c > > Log message: > fix more pointless and inconsistent formating -- spaces before semicolons > > > From wagner at elegosoft.com Fri Aug 28 16:35:32 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 28 Aug 2009 16:35:32 +0200 Subject: [M3devel] Windows packages for RC3 Message-ID: <20090828163532.mtbood3o2ssckogo@mail.elegosoft.com> Now finally the packages have been built, but not copied to birch: /usr/bin/ssh: No such file or directory lost connection This is getting ridiculous. If there wasn't an ssh there would be no connection at all, and it has been explicitly checked before. I'll try to copy the packages manually later when I'm at home. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Fri Aug 28 16:35:39 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 28 Aug 2009 10:35:39 -0400 Subject: [M3devel] small design problem in ButtonVBT? In-Reply-To: <570C6C84-C41D-446E-A43C-13F85F1C378C@cs.purdue.edu> References: <20090331145127.GB9624@topoi.pooq.com> <20090401120347.x8cneize8oscg44o@mail.elegosoft.com> <20090826002606.GB16386@topoi.pooq.com> <20090827141741.9g1u2vrgfgokkksg@mail.elegosoft.com> <20090828031722.GB22883@topoi.pooq.com> <36DAB001-70F3-4C96-B1D5-57E8A7322464@cs.purdue.edu> <20090828091150.GA23396@topoi.pooq.com> <570C6C84-C41D-446E-A43C-13F85F1C378C@cs.purdue.edu> Message-ID: <20090828143539.GA23965@topoi.pooq.com> On Fri, Aug 28, 2009 at 09:44:14AM -0400, Tony Hosking wrote: > Yes, exactly! I don't think the change is needed and goes against the > grain of a pervasive design principle. We might question that > decision, but I hesitate to apply a piecemeal tweak that violates the > principle. Care to state that pervasive design principle? Whatever it is, Modula 3 seems to have done well by it. -- hendrik From jay.krell at cornell.edu Fri Aug 28 16:58:25 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Fri, 28 Aug 2009 10:58:25 -0400 Subject: [M3devel] Change Pathname abstraction for Windows? was: RE: RC3 build problems, was: RE: caltech-parser NT386 Hudson problems In-Reply-To: <20090828102635.0iyxllukro8o44o4@mail.elegosoft.com> References: <20090826142644.r6yabwff5wc84cgg@mail.elegosoft.com> <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> <20090828102635.0iyxllukro8o44o4@mail.elegosoft.com> Message-ID: <5C022EFA-8D3E-49CF-9867-2D39AF515B78@hotmail.com> (including m3devel this time) I believe this goes back to CP/M compatibility. I wish the file open dialogs accepted forward slashes. :( I will change cm3 to write back into quake state the canonicalized forms. I believe I already changed Pathname on Windows to accept either slash. I need to check if equality uses decomposed elements. Lots of folks just use strings and skip the abstraction, such as cm3. My personal programming often uses a small library over strings -- GetLastPathElement, RemoveLastElement, JoinPath, EnsureTrailingPathSeparator, ... IMHO you might as well also have posix allow backward slashes as separators, but that was rejected here. To wit I believe cygwin now accepts colons and backward slashes in paths, as non-separators. Interix also one or the other or both. Interix encodes them by oring in 0xFF00 (what happens with Samba to ext3??) There are other issues such as case sensivity not being an OS-wide thing but per volume or directory (NTFS has mount points, directories can lead to volumes, with different filesystems) as well as just what the case mapping tables are (written to NTFS volume at time of format, presumably can vary). The Mac historically used colon as separator and allowed forward slash as non separator. Presumably hidden through some encoding/decoding at the posix layer? - Jay (phone) On Aug 28, 2009, at 4:26 AM, Olaf Wagner wrote: > Quoting Jay K : > >> It was backslashes vs. forward slashes as I had originally suspected. >> My debugprinting never hit because I was guessing the elego paths >> wrong. >> I finally made it always print and tested it in-situ in the VM. > > It is amazing how much (pointless) work the difference in pathname > denotations on Windows and POSIX systems has caused and still causes. > While there are some conceptual differences that cannot easily be > generalized (one root <-> many roots, logical <-> physical view of > disks etc.), the simple fact that Windows uses \ instead of / > makes life needlessly difficult for many programmers. > > In Modula-3, the Pathname interface is intended to abstract from > this, but this works only to a certain degree. It uses \ as the > arc separator on Windows, while in fact all modern Windows systems > accept both \ and /. I think this should be corrected. > > Pathnames should be split into elements at both \ and / on Windows, > and checks for equality should ignore any differences in separator > characters only. Does this sound reasonable? > > Is there any (non)obvious problem I'm overseeing right now which > will make this strategy fail? > > Olaf > > PS: I'm not suggesting we do that in this release of course... > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ > any > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be > rlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Aug 28 18:44:34 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Fri, 28 Aug 2009 12:44:34 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <4A97DD15.1030907@cox.net> References: <20090828025553.5272F2474002@birch.elegosoft.com> <4A97DD15.1030907@cox.net> Message-ID: <9DA06850-DE99-4D69-A1E2-91DADDF38312@hotmail.com> Perl regexp has word boundary notion. Visual C++ 5.0 find-in-files feature, which overall is an excellent feature, has a "whole word" option. - Jay (phone) On Aug 28, 2009, at 9:35 AM, "Rodney M. Bates" wrote: > Whenever I write/add code, in any language, I am in the habit of > always surrounding > every identifier with at least one blank, before and after. > Otherwise, grepping > for all occurrences of an identifier is a nightmare. You usually > get overwhelmed > with false hits where the identifier you want is a substring of > others. > This is extremely common. > > On the other hand, surrounding your search string with the Cartesian > product of all the characters that could conceivably surround > identifiers > in code is a different kind of nightmare, and can fail to find > important > hits. Combinations of grep piped to grep -v with wild cards, gets > closer, > but that's a big pain too. (Hmm, maybe sometime I should try to > script > that.) > > Starting decades ago, I have wished every string-searching function > had > some kind of metacharacter to mean "at beginning of identifier" and > "at end of identifier". It wouldn't be that hard, and the rules are > so very > close to language-independent. But, AFAIK, it has never happened. > > Not that adding the blanks in m3gdb mattered much, since my additions > and modifications to it are a tiny subset of what is there. And the > surrounding-with-blanks idea only works if you know for certain it has > been done everywhere. > > Jay Krell wrote: >> CVSROOT: /usr/cvs >> Changes by: jkrell at birch. 09/08/28 04:55:49 >> >> Modified files: >> cm3/m3-sys/m3gdb/gdb/gdb/: Tag: release_branch_cm3_5_8 m3- >> eval.c m3-exp.c m3-lang.c m3- >> threads.c m3-util.c m3-valprint.c >> cm3/m3-sys/m3gdb/gdb/gdb/save/: Tag: >> release_branch_cm3_5_8 m3-lang.c >> m3-lang.h m3-valprint.c >> Log message: >> fix more pointless and inconsistent formating -- spaces before >> semicolons >> >> >> > > From hosking at cs.purdue.edu Fri Aug 28 18:44:48 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 28 Aug 2009 12:44:48 -0400 Subject: [M3devel] small design problem in ButtonVBT? In-Reply-To: <20090828143539.GA23965@topoi.pooq.com> References: <20090331145127.GB9624@topoi.pooq.com> <20090401120347.x8cneize8oscg44o@mail.elegosoft.com> <20090826002606.GB16386@topoi.pooq.com> <20090827141741.9g1u2vrgfgokkksg@mail.elegosoft.com> <20090828031722.GB22883@topoi.pooq.com> <36DAB001-70F3-4C96-B1D5-57E8A7322464@cs.purdue.edu> <20090828091150.GA23396@topoi.pooq.com> <570C6C84-C41D-446E-A43C-13F85F1C378C@cs.purdue.edu> <20090828143539.GA23965@topoi.pooq.com> Message-ID: <2B370785-C8C1-4964-87DC-5EF3B839B898@cs.purdue.edu> I meant the principle articulated for use of a procedure instead of a method for ButtonVBT. On 28 Aug 2009, at 10:35, hendrik at topoi.pooq.com wrote: > On Fri, Aug 28, 2009 at 09:44:14AM -0400, Tony Hosking wrote: >> Yes, exactly! I don't think the change is needed and goes against >> the >> grain of a pervasive design principle. We might question that >> decision, but I hesitate to apply a piecemeal tweak that violates the >> principle. > > Care to state that pervasive design principle? Whatever it is, > Modula 3 > seems to have done well by it. > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Aug 29 13:36:37 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 29 Aug 2009 13:36:37 +0200 Subject: [M3devel] RC3 status and open tickets Message-ID: <20090829133637.49ywpog80ggwsogs@mail.elegosoft.com> There have been many problems again building the release archives on some platforms, especially NT386 and Solaris, but there is progress. The SOLgnu packages seem to be OK now, but the SOLsun packages are still all more or less broken. You can find the results of installation tests at http://hudson.modula3.com:8080/view/test-install/ Several build machines we used in RC2 are still not available (traveling on Jay's new computer ;-); those will be added later. Build and other regression test results are in http://hudson.modula3.com:8080/ There are still many open tickets regarding RC3 https://projects.elego.de/cm3/query?status=resolved&status=reopened&status=assigned&status=analyzed&status=new&status=accepted&group=status&milestone=CM3+Release+5.8+RC3 and the final 5.8 release: https://projects.elego.de/cm3/query?status=resolved&status=reopened&status=assigned&status=analyzed&status=new&status=accepted&group=status&milestone=CM3+release+5.8 Help in analyzing and resolving them is very welcome. I'll be on vacation for two weeks to the south of France, and won't be able to do anything for CM3 then (leaving my laptop behind ;-). I think it is unrealistic that the final release is availble until then, but I hope that we at least have a more or less stable RC3. Thanks for your patience and support, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Sat Aug 29 23:51:06 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 29 Aug 2009 23:51:06 +0200 Subject: [M3devel] tinderbox failures: undefined variables in quake Message-ID: <20090829235106.lb9zq4ouo8kcckgs@mail.elegosoft.com> Several release builds fail with undefined variables in quake now (this is probably in the trunk I assume). Who broke this now? Is it just missing backward compatibility or a more serious problem? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sun Aug 30 00:24:53 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Sat, 29 Aug 2009 17:24:53 -0500 Subject: [M3devel] tinderbox failures: undefined variables in quake In-Reply-To: <20090829235106.lb9zq4ouo8kcckgs@mail.elegosoft.com> References: <20090829235106.lb9zq4ouo8kcckgs@mail.elegosoft.com> Message-ID: <4AC5146C-68FE-40F0-828C-462428AF8E6F@hotmail.com> Tinderbox head or Hudson release? Either way probably me I can look tonight. - Jay (phone) On Aug 29, 2009, at 4:51 PM, Olaf Wagner wrote: > Several release builds fail with undefined variables in quake now > (this is probably in the trunk I assume). > > Who broke this now? Is it just missing backward compatibility > or a more serious problem? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ > any > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be > rlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > From jay.krell at cornell.edu Sun Aug 30 11:05:33 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 30 Aug 2009 09:05:33 +0000 Subject: [M3devel] cminstall too many errors if not root, in fact maybe infinite Message-ID: It bugs me how many packages there are -- too much to test. So I'll test just a few. Starting with cm3-bin-min-SOLsun-5.8.3-RC3.tgz: ./cminstall => endless stream of Unable to create directory: /usr/local/cm3 ./cminstall | wc -l => I've been waiting a while and it hasn't terminated. As I've said before, cminstall doesn't do much and doesn't do it well. Granted, claiming that nothing is needed here is a stretch. If I go ahead and in another console as root mkdir /usr/local, no progress. mkdir /usr/local/cm3. Then it stops with: Unexpected problem: Unable to open the log file: /usr/local/cm3/Install.log: errno=13 Please feel free to contact m3-support at elego.de to troubleshoot this problem. Now, I understand that refusing to run as non-root is not the solution. -bash-3.00$ ./cminstall --help Unexpected problem: Unrecognized option: --help Please feel free to contact m3-support at elego.de to troubleshoot this problem. I'll fix that. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Aug 30 11:11:20 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 30 Aug 2009 09:11:20 +0000 Subject: [M3devel] cminstall says too much Message-ID: cminstall is really not so great. Here is one criticism -- it says too much. -bash-3.00$ ./cminstall Thank you for using Critical Mass CM3. This program will configure and install the system. cminstall_root is set to /home/jay/t/min If this is not correct, please restart the installer with -root [Jay Is it ever wrong? Must it always be reported?] If the installer runs interactively, it will ask you some questions about the locations of programs and libraries. Usually it will display a default inside [], which can be accepted with . If the installer has found several choices, you may cycle through them with `+' or `.' for the next and `-' for the previous one. You may of course also enter a completely different value. [I didn't run it interactively. Why tell me all this?] Installing CM3 in: /usr/local/cm3 This may take a few minutes... CM3 is now installed. Before you begin, here's a few reminders: 1) The CM3 compiler executable is in: /usr/local/cm3/bin/cm3 You may need to modify your PATH environment variable to find it. And on Unix, you may need to type "rehash" to your shell. 2) CM3's shared libraries and any you create and ship are in: /usr/local/cm3/lib On some Unix systems you may need to set the LD_LIBRARY_PATH (on Darwin / MacOS X it's called DYLD_LIBRARY_PATH) environment variable before running programs that use these shared libraries (usually not necessary). [This applies to almost no systems, esp. the Mac part.] 3) Your system configuration file is: /usr/local/cm3/bin/cm3.cfg At any point in time, you may edit it to modify or update your installation. 4) A copy of this installation dialogue is in: /usr/local/cm3/Install.log [dialogue for non-interactive installs?] 5) If you had trouble with this installation or need more assistance, please send us a transcript of this installation via e-mail at "m3-support at elego.de". Thank you. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Aug 30 13:00:00 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 30 Aug 2009 11:00:00 +0000 Subject: [M3devel] RandomTest runtime error FileWr.Error not in Raises list Message-ID: I think this is two or three problems. - missing raises - why does it raise - why does it hang Often but not always: jay at xlin2:/dev2/release_branch_cm3_5_8/m3-libs/libm3/tests/random$ pwd /dev2/release_branch_cm3_5_8/m3-libs/libm3/tests/random jay at xlin2:/dev2/release_branch_cm3_5_8/m3-libs/libm3/tests/random$ ./LINUXLIBC6 /RandomTest -perm under gdb: *** *** runtime error: *** Exception "FileWr.Error" not in RAISES list *** file "../src/rw/FileWr.m3", line 81 *** Program received signal SIGABRT, Aborted. [Switching to Thread -1210370368 (LWP 21415)] 0xb7f25410 in ?? () (gdb) bt #0 0xb7f25410 in ?? () #1 0xbfc4f14c in ?? () #2 0x00000006 in ?? () #3 0x000053a7 in ?? () #4 0xb7ddc811 in raise () from /lib/tls/i686/cmov/libc.so.6 #5 0xb7dddfb9 in abort () from /lib/tls/i686/cmov/libc.so.6 #6 0x0808bb12 in RTOS__Crash () at ../src/runtime/POSIX/RTOS.m3:20 #7 0x08085d83 in RTProcess__Crash (M3_Bd56fi_msg=0x0) at ../src/runtime/common/RTProcess.m3:65 #8 0x08083a8e in RTError__EndError (M3_AicXUJ_crash=1 '\001') at ../src/runtime/common/RTError.m3:118 #9 0x08083752 in RTError__MsgS (M3_AJWxb1_file=0x80c437c, M3_AcxOUs_line=81, M3_Bd56fi_msgA=0x80cc350, M3_Bd56fi_msgB=0xb7d7eba0, M3_Bd56fi_msgC=0x80cc378) at ../src/runtime/common/RTError.m3:40 #10 0x08083ef6 in RTException__Crash (M3_Cblw37_a=0xbfc4f460, M3_AicXUJ_raises=1 '\001', M3_AJWxb1_rte=0x80c8400) at ../src/runtime/common/RTException.m3:79 #11 0x08083c5f in RTException__DefaultBackstop (M3_Cblw37_a=0xbfc4f460, M3_AicXUJ_raises=0 '\0') at ../src/runtime/common/RTException.m3:41 #12 0x08083b59 in RTException__InvokeBackstop (M3_Cblw37_a=0xbfc4f460, M3_AicXUJ_raises=0 '\0') at ../src/runtime/common/RTException.m3:25 #13 0x0808c5a8 in RTException__Raise (M3_Cblw37_act=0xbfc4f460) at ../src/runtime/ex_frame/RTExFrame.m3:29 #14 0x08083cb6 in RTException__DefaultBackstop (M3_Cblw37_a=0xbfc4f460, ---Type to continue, or q to quit--- M3_AicXUJ_raises=1 '\001') at ../src/runtime/common/RTException.m3:47 #15 0x08083b59 in RTException__InvokeBackstop (M3_Cblw37_a=0xbfc4f460, M3_AicXUJ_raises=1 '\001') at ../src/runtime/common/RTException.m3:25 #16 0x0808c689 in RTException__Raise (M3_Cblw37_act=0xbfc4f460) at ../src/runtime/ex_frame/RTExFrame.m3:51 #17 0x08073e99 in RTHooks__Raise (M3_AJWxb1_ex=0x80c42a0, M3_AJWxb1_arg=0x0, M3_AJWxb1_module=0x80c43e0, M3_AcxOUs_line=81) at ../src/runtime/common/RTHooks.m3:79 #18 0x0806a9c4 in FileWr__Seek (M3_EJV0jI_wr=0xb7d73234, M3_Cwb5VA_n=4198) at ../src/rw/FileWr.m3:81 #19 0x080559ea in AutoFlushWr__Seek (M3_Aauo9c_wr=0xb7d790a4, M3_Cwb5VA_n=4198) at ../src/rw/AutoFlushWr.m3:106 #20 0x080544bf in WrClass__PutStringDefault (M3_BxxOH1_wr=0xb7d790a4, M3_CKMnXU_a=0xbfc4f7f4) at ../src/rw/Wr.m3:193 #21 0x080539de in UnsafeWr__FastPutText (M3_BxxOH1_wr=0xb7d790a4, M3_Bd56fi_t=0xb7d7eb84) at ../src/rw/Wr.m3:105 #22 0x08053837 in Wr__PutText (M3_BxxOH1_wr=0xb7d790a4, M3_Bd56fi_t=0xb7d7eb84) at ../src/rw/Wr.m3:93 #23 0x0804f561 in RandomTest__TestPerm () at ../src/RandomTest.m3:387 #24 0x0804bedf in RandomTest__Main () at ../src/RandomTest.m3:64 #25 0x08050235 in RandomTest_M3 (M3_AcxOUs_mode=1) at ../src/RandomTest.m3:458 #26 0x08082bf8 in RTLinker__RunMainBody (M3_DjPxE3_m=0x80be120) at ../src/runtime/common/RTLinker.m3:399 #27 0x08081fb2 in RTLinker__AddUnitI (M3_DjPxE3_m=0x80be120) ---Type to continue, or q to quit--- at ../src/runtime/common/RTLinker.m3:113 #28 0x08082040 in RTLinker__AddUnit (M3_DjPxE5_b=0x8050165) at ../src/runtime/common/RTLinker.m3:122 #29 0x0804baee in main (argc=2, argv=0xbfc4fe94, envp=0xbfc4fea0) at _m3main.mc:4 (gdb) This test hangs on OpenBSD/x86. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun Aug 30 22:33:23 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 30 Aug 2009 22:33:23 +0200 Subject: [M3devel] RC3 Message-ID: <20090830223323.qpwzvxkdckw0o480@mail.elegosoft.com> Though there are still several open problem, I suggest that we now stop making changes to the codebase for RC3 and retarget the issues to the final release. This means * We do not move the tag for RC3 any further (except perhaps for some make-dist scripts which need some tweaking but have no direct impact on cm3) * Exception is the addition of the native installation archives for NT386 * We continue adding installation archives for new platforms The installation archives should be much better than RC2. All further improvements and fixes go into the final release (or RC4). We should also announce the availability of RC3 outside of m3devel. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Aug 31 03:10:55 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 31 Aug 2009 01:10:55 +0000 Subject: [M3devel] how to find cm3.cfg Message-ID: how to find cm3.cfg I propose, in this order: - -config or --config switch (actually any number of dashes) - $M3_CONFIG environment variable (however it is already spelled) This is a preferably path to a specific file, not some directory to further probe. I'll have to check the current implementation though. It might be a directory containing cm3.cfg as well. Whatever it currently does is how it should likely stay. - cm3.cfg next to executable, be it cm3.exe, cm3ide.exe, etc. - possibly one other choice, if none of the above exist, and executable is not cm3/cm3.exe, then search $PATH for cm3/cm3.exe and use cm3.cfg next to it This includes NOT looking in: - /etc - current directory - $PATH in general One problem is, you can't really directly/easily even find the current executable in Posix. I'll do more research on this. It is easy in Win32 and I assume Mac. Otherwise will probably fall back to: I believe everyone's best effort here is looking at argv[0] and if that isn't a full or current working directory relative path, search $PATH. Any other search should be layerable upon this. That is, cm3.cfg can include(/etc/cm3.cfg) or such. One thing not accounted for here is a --target command line option. Given the current layout and code, that doesn't work out well. Specifically, using config/target wouldn't set INSTALL_ROOT correctly. --target could set $TARGET and cm3.cfg could include config/target if target is already set. Or cm3 could set INSTALL_ROOT itself. We could look for next-to-executable/target.cfg. I think I'll punt on all this for now -- any accomodation of --target on command line. I think this change should probably go in this release, given that there was another change already that this undoes and given th bug I found regarding running by relative path (granted, I should debug that before replacing the code). Or, I guess, at the very least, remove the new probes and fix the bug I found. I guess. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Aug 31 09:15:49 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 31 Aug 2009 09:15:49 +0200 Subject: [M3devel] how to find cm3.cfg In-Reply-To: References: Message-ID: <20090831091549.ii6ae9sr40cwg804@mail.elegosoft.com> Some quick comments: o It is rather late in the release to change the interfaces, i.e. introduce new command line options like -config or -target. -config is currently the same as -version, so this is incompatible. I'd rather leave changes like this for the trunk. The release branch is _not_ for development. o I do not remember that an agreement was reached concerning the config search discussion. There were some contradictory mails on the matter as far as I remember, but no conclusion, so I didn't change anything again. As long as we haven't really resolved this, we are likely to change again and again. o I'm not against simplifying the initial search in the cm3 executable, but if we agree that customizations for system-specific layouts should be done in the quake code, this should be documented and even prepared in the provided config files. o If anything is changed again, at least not for RC3. The correct way would be to test such changes on the trunk and then merge them for a later RC4. Let's do it this way. It is almost impossible to get the system stable enough for a multi-platform package build. IIRC, we've been trying for more than two weeks now to build RC3. Olaf Quoting Jay K : > how to find cm3.cfg > > I propose, in this order: > > - -config or --config switch (actually any number of dashes) > > - $M3_CONFIG environment variable (however it is already spelled) > > This is a preferably path to a specific file, not some > directory to further probe. > > I'll have to check the current implementation though. It might be > > a directory containing cm3.cfg as well. Whatever it currently > does is how it should likely stay. > > - cm3.cfg next to executable, be it cm3.exe, cm3ide.exe, etc. > > - possibly one other choice, if none of the above exist, and > executable is not cm3/cm3.exe, > > then search $PATH for cm3/cm3.exe and use cm3.cfg next to it > > This includes NOT looking in: > > - /etc > > - current directory > > - $PATH in general > > One problem is, you can't really directly/easily even find the > current executable in Posix. > > I'll do more research on this. > > It is easy in Win32 and I assume Mac. > > Otherwise will probably fall back to: > > I believe everyone's best effort here is looking at argv[0] and if > that isn't a full or > > current working directory relative path, search $PATH. > > Any other search should be layerable upon this. > > That is, cm3.cfg can include(/etc/cm3.cfg) or such. > > One thing not accounted for here is a --target command line option. > > Given the current layout and code, that doesn't work out well. > > Specifically, using config/target wouldn't set INSTALL_ROOT correctly. > > --target could set $TARGET and cm3.cfg could include config/target if > > target is already set. > > Or cm3 could set INSTALL_ROOT itself. > > We could look for next-to-executable/target.cfg. > > I think I'll punt on all this for now -- any accomodation of > --target on command line. > > I think this change should probably go in this release, given that > there was another change > > already that this undoes and given th bug I found regarding running > by relative path (granted, > > I should debug that before replacing the code). > > Or, I guess, at the very least, remove the new probes and fix the > bug I found. > > I guess. -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Aug 31 09:55:00 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 31 Aug 2009 07:55:00 +0000 Subject: [M3devel] RandomTest runtime error FileWr.Error not in Raises list Message-ID: Easy to trigger problems here, also on NT, like with: VAR r: Random.T; stdout := NEW(AutoFlushWr.T).init(Stdio.stdout); PROCEDURE Main () = BEGIN WHILE TRUE DO Wr.PutText(stdout, "foofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoo\n"); END; foofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoo FileWr.Seek:wr.seekable=FALSE,n=53300,wr.hi=57396 *** *** runtime error: *** Exception "FileWr.Error" not in RAISES list *** file "..\src\rw\FileWr.m3", line 85 *** *** *** runtime error: *** Thread client error: Attempt to lock mutex already locked by self *** file "..\src\thread\WIN32\ThreadWin32.m3", line 119 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12fcfc 0x41c2d6 Seek + 0x125 in ..\src\rw\FileWr.m3 0x12fd58 0x40e6b1 Seek + 0x165 in ..\src\rw\AutoFlushWr.m3 0x12fd9c 0x407c9a PutStringDefault + 0x281 in ..\src\rw\Wr.m3 0x12fe50 0x407460 FastPutText + 0x105 in ..\src\rw\Wr.m3 0x12fe78 0x407328 PutText + 0x4e in ..\src\rw\Wr.m3 0x12febc 0x4010c6 Main + 0x76 in ..\src\RandomTest.m3 0x12fee0 0x405795 RandomTest_M3 + 0xb5 in ..\src\RandomTest.m3 Must be some race condition between flushing and other writers? - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: RandomTest runtime error FileWr.Error not in Raises list Date: Sun, 30 Aug 2009 11:00:00 +0000 I think this is two or three problems. - missing raises - why does it raise - why does it hang Often but not always: jay at xlin2:/dev2/release_branch_cm3_5_8/m3-libs/libm3/tests/random$ pwd /dev2/release_branch_cm3_5_8/m3-libs/libm3/tests/random jay at xlin2:/dev2/release_branch_cm3_5_8/m3-libs/libm3/tests/random$ ./LINUXLIBC6 /RandomTest -perm under gdb: *** *** runtime error: *** Exception "FileWr.Error" not in RAISES list *** file "../src/rw/FileWr.m3", line 81 *** Program received signal SIGABRT, Aborted. [Switching to Thread -1210370368 (LWP 21415)] 0xb7f25410 in ?? () (gdb) bt #0 0xb7f25410 in ?? () #1 0xbfc4f14c in ?? () #2 0x00000006 in ?? () #3 0x000053a7 in ?? () #4 0xb7ddc811 in raise () from /lib/tls/i686/cmov/libc.so.6 #5 0xb7dddfb9 in abort () from /lib/tls/i686/cmov/libc.so.6 #6 0x0808bb12 in RTOS__Crash () at ../src/runtime/POSIX/RTOS.m3:20 #7 0x08085d83 in RTProcess__Crash (M3_Bd56fi_msg=0x0) at ../src/runtime/common/RTProcess.m3:65 #8 0x08083a8e in RTError__EndError (M3_AicXUJ_crash=1 '\001') at ../src/runtime/common/RTError.m3:118 #9 0x08083752 in RTError__MsgS (M3_AJWxb1_file=0x80c437c, M3_AcxOUs_line=81, M3_Bd56fi_msgA=0x80cc350, M3_Bd56fi_msgB=0xb7d7eba0, M3_Bd56fi_msgC=0x80cc378) at ../src/runtime/common/RTError.m3:40 #10 0x08083ef6 in RTException__Crash (M3_Cblw37_a=0xbfc4f460, M3_AicXUJ_raises=1 '\001', M3_AJWxb1_rte=0x80c8400) at ../src/runtime/common/RTException.m3:79 #11 0x08083c5f in RTException__DefaultBackstop (M3_Cblw37_a=0xbfc4f460, M3_AicXUJ_raises=0 '\0') at ../src/runtime/common/RTException.m3:41 #12 0x08083b59 in RTException__InvokeBackstop (M3_Cblw37_a=0xbfc4f460, M3_AicXUJ_raises=0 '\0') at ../src/runtime/common/RTException.m3:25 #13 0x0808c5a8 in RTException__Raise (M3_Cblw37_act=0xbfc4f460) at ../src/runtime/ex_frame/RTExFrame.m3:29 #14 0x08083cb6 in RTException__DefaultBackstop (M3_Cblw37_a=0xbfc4f460, ---Type to continue, or q to quit--- M3_AicXUJ_raises=1 '\001') at ../src/runtime/common/RTException.m3:47 #15 0x08083b59 in RTException__InvokeBackstop (M3_Cblw37_a=0xbfc4f460, M3_AicXUJ_raises=1 '\001') at ../src/runtime/common/RTException.m3:25 #16 0x0808c689 in RTException__Raise (M3_Cblw37_act=0xbfc4f460) at ../src/runtime/ex_frame/RTExFrame.m3:51 #17 0x08073e99 in RTHooks__Raise (M3_AJWxb1_ex=0x80c42a0, M3_AJWxb1_arg=0x0, M3_AJWxb1_module=0x80c43e0, M3_AcxOUs_line=81) at ../src/runtime/common/RTHooks.m3:79 #18 0x0806a9c4 in FileWr__Seek (M3_EJV0jI_wr=0xb7d73234, M3_Cwb5VA_n=4198) at ../src/rw/FileWr.m3:81 #19 0x080559ea in AutoFlushWr__Seek (M3_Aauo9c_wr=0xb7d790a4, M3_Cwb5VA_n=4198) at ../src/rw/AutoFlushWr.m3:106 #20 0x080544bf in WrClass__PutStringDefault (M3_BxxOH1_wr=0xb7d790a4, M3_CKMnXU_a=0xbfc4f7f4) at ../src/rw/Wr.m3:193 #21 0x080539de in UnsafeWr__FastPutText (M3_BxxOH1_wr=0xb7d790a4, M3_Bd56fi_t=0xb7d7eb84) at ../src/rw/Wr.m3:105 #22 0x08053837 in Wr__PutText (M3_BxxOH1_wr=0xb7d790a4, M3_Bd56fi_t=0xb7d7eb84) at ../src/rw/Wr.m3:93 #23 0x0804f561 in RandomTest__TestPerm () at ../src/RandomTest.m3:387 #24 0x0804bedf in RandomTest__Main () at ../src/RandomTest.m3:64 #25 0x08050235 in RandomTest_M3 (M3_AcxOUs_mode=1) at ../src/RandomTest.m3:458 #26 0x08082bf8 in RTLinker__RunMainBody (M3_DjPxE3_m=0x80be120) at ../src/runtime/common/RTLinker.m3:399 #27 0x08081fb2 in RTLinker__AddUnitI (M3_DjPxE3_m=0x80be120) ---Type to continue, or q to quit--- at ../src/runtime/common/RTLinker.m3:113 #28 0x08082040 in RTLinker__AddUnit (M3_DjPxE5_b=0x8050165) at ../src/runtime/common/RTLinker.m3:122 #29 0x0804baee in main (argc=2, argv=0xbfc4fe94, envp=0xbfc4fea0) at _m3main.mc:4 (gdb) This test hangs on OpenBSD/x86. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Aug 31 12:02:26 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 31 Aug 2009 10:02:26 +0000 Subject: [M3devel] FW: Wr.Unlock to restore invariants? In-Reply-To: <20090831091151.71CD12474001@birch.elegosoft.com> References: <20090831091151.71CD12474001@birch.elegosoft.com> Message-ID: My later change undoes this, and in general AutoFlushWr wasn't honoring it before -- in particular Flush and Length. Insert the extra unlock/lock to "fix" that? In particular, WrClass.i3: PROCEDURE Unlock(wr: Wr.T); (* The writer wr must be locked and valid; unlock it and restore the private invariant of the writer implementation. *) - Jay > Date: Mon, 31 Aug 2009 11:11:51 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/08/31 11:11:51 > > Modified files: > cm3/m3-libs/libm3/src/rw/: AutoFlushWr.m3 > > Log message: > Since Unlock is also documented as restoring invariants, restore > the early Unlock, and then put in an extra Lock after that. > In reality all the reader/writers implemented here don't do > anything in Unlock except unlock, so it was ok. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Aug 31 12:15:55 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 31 Aug 2009 10:15:55 +0000 Subject: [M3devel] "RandomTest" (that is its name) hangs on I386_OPENBSD Message-ID: "RandomTest" (that is its name) always hangs on I386_OPENBSD. The main thread never finishes StopWorld: (gdb) bt #0 0x00ba08f1 in poll () from /usr/lib/libc.so.50.1 #1 0x04ab5314 in _thread_kern_poll (wait_reqd=1) at /usr/src/lib/libpthread/uthread/uthread_kern.c:760 #2 0x04ab4e53 in _thread_kern_sched (scp=0x0) at /usr/src/lib/libpthread/uthread/uthread_kern.c:382 #3 0x04ab519f in _thread_kern_sched_state (state=615149768, fname=0x24aa70c8 "", lineno=615149768) at /usr/src/lib/libpthread/uthread/uthread_kern.c:550 #4 0x04aaf085 in nanosleep (time_to_sleep=0xcfbcc1a8, time_remaining=0xcfbcc1b0) at /usr/src/lib/libpthread/uthread/uthread_nanosleep.c:84 #5 0x0166eafd in ThreadPThread__Nanosleep (req=0xcfbcc1a8, rem=0xcfbcc1b0) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 #6 0x0166b6f4 in ThreadPThread__CommonSleep () at ../src/thread/PTHREAD/ThreadPThread.m3:651 #7 0x0166d355 in ThreadPThread__StopWorld () at ../src/thread/PTHREAD/ThreadPThread.m3:1142 #8 0x0166c9c3 in ThreadF__SuspendOthers () at ../src/thread/PTHREAD/ThreadPThread.m3:918 #9 0x0164e70b in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:747 #10 0x0164e6ca in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:721 #11 0x0164e161 in RTCollector__CollectEnough (M3_AicXUJ_allocator=1 '\001') ---Type to continue, or q to quit--- at ../src/runtime/common/RTCollector.m3:653 #12 0x01650cb7 in RTCollector__LongAlloc (M3_Cwb5VA_dataSize=92, M3_Cwb5VA_dataAlignment=4, M3_CAzbsM_pool=0x86770ab8) at ../src/runtime/common/RTCollector.m3:1438 #13 0x01650b14 in RTHeapRep__AllocTraced (M3_Cwb5VA_dataSize=92, M3_Cwb5VA_dataAlignment=4, M3_CAzbsM_pool=0x86770ab8) at ../src/runtime/common/RTCollector.m3:1400 #14 0x01645b47 in RTAllocator__GetOpenArray (M3_Eic7CK_def=0x216259d0, M3_ANmeAM_s=0xcfbcc4fc) at ../src/runtime/common/RTAllocator.m3:292 #15 0x01644e3c in RTHooks__AllocateOpenArray (M3_AJWxb1_defn=0x216259d0, M3_ANmeAM_s=0xcfbcc4fc) at ../src/runtime/common/RTAllocator.m3:141 #16 0x0c4b364f in RandomPerm__HQInit (M3_AMLmtL_t=0x7eed1fb0, M3_Cwb5VA_n=21, M3_BUCfej_r=0x7eecb0f4) at ../src/random/Common/RandomPerm.m3:55 #17 0x1c00489e in RandomTest__TestPerm () at ../src/RandomTest.m3:367 #18 0x1c0015f7 in RandomTest__Main () at ../src/RandomTest.m3:64 #19 0x1c00595c in RandomTest_M3 (M3_AcxOUs_mode=1) at ../src/RandomTest.m3:458 #20 0x01658a19 in RTLinker__RunMainBody (M3_DjPxE3_m=0x3c001660) at ../src/runtime/common/RTLinker.m3:400 #21 0x01657dd3 in RTLinker__AddUnitI (M3_DjPxE3_m=0x3c001660) at ../src/runtime/common/RTLinker.m3:114 #22 0x01657e61 in RTLinker__AddUnit (M3_DjPxE5_b=0x1c00588c) at ../src/runtime/common/RTLinker.m3:123 #23 0x1c001206 in main (argc=2, argv=0xcfbccadc, envp=0xcfbccae8) at _m3main.mc:4 While the other thread is in: Thread 2 (process 5611, thread 0x7fc1d400): #0 _thread_kern_sched (scp=0x0) at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 #1 0x04ab5200 in _thread_kern_sched_state_unlock (state=PS_SIGTHREAD, lock=0x7fc1d4b0, fname=0x1
, lineno=1) at /usr/src/lib/libpthread/uthread/uthread_kern.c:581 #2 0x04ab2bc9 in pthread_cond_wait (cond=0x80dda100, mutex=0x80dda1e0) at /usr/src/lib/libpthread/uthread/uthread_cond.c:261 #3 0x01668b89 in ThreadPThread__XWait (M3_BXP32l_self=0x7eeff13c, M3_AYIbX3_m=0x7eecb018, M3_Bl0jv4_c=0x7eecb06c, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x01669235 in Thread__Wait (M3_AYIbX3_m=0x7eecb018, M3_Bl0jv4_c=0x7eecb06c) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x0c4c1de7 in AutoFlushWr__Worker (M3_EMTrVz_cl=0x7eeff134) at ../src/rw/AutoFlushWr.m3:210 #6 0x0166acfb in ThreadPThread__RunThread (M3_BeUkBA_me=0x86770b00) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x0166aa26 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x86770b00) at ../src/thread/PTHREAD/ThreadPThread.m3:523 #8 0x04aac37f in _thread_start () at /usr/src/lib/libpthread/uthread/uthread_create.c:240 #9 0x0000002b in ?? () #10 0x00000000 in ?? () Maybe AutoFlushWr needs more work? (It was crashing on platforms it didn't hang on.) I'll try to dig around more here.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Aug 31 12:16:32 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 31 Aug 2009 10:16:32 +0000 Subject: [M3devel] Posix/Win32 linger options inverted? In-Reply-To: References: Message-ID: ? > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Sun, 23 Aug 2009 06:26:34 +0000 > Subject: [M3devel] Posix/Win32 linger options inverted? > > > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-comm/tcp/src/POSIX/TCP.m3?rev=1.7;content-type=text%2Fplain > > vs. > > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-comm/tcp/src/WIN32/TCP.m3?rev=1.3;content-type=text%2Fplain > > > search for linger: > > PROCEDURE InitFD(fd: CARDINAL) = > (* We assume that the runtime ignores SIGPIPE signals *) > VAR > one: int := 1; > linger := Usocket.struct_linger{1, 1}; > > vs. > > PROCEDURE InitSock(sock: WinSock.SOCKET) = > (* We assume that the runtime ignores SIGPIPE signals *) > VAR > one : BOOL := 1; > linger := WinSock.struct_linger{0, 0}; > > > Surely they can't both be correct. > Which is correct? The Posix one? > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Aug 31 13:20:56 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 31 Aug 2009 13:20:56 +0200 Subject: [M3devel] Posix/Win32 linger options inverted? In-Reply-To: References: Message-ID: <20090831132056.dpkpp6z5pkw4os0c@mail.elegosoft.com> On Solaris I find /* * Structure used for manipulating linger option. */ struct linger { int l_onoff; /* option on/off */ int l_linger; /* linger time */ }; so {1, 1} would make the socket linger for at most 1 second after close, while {0, 0} would close the socket immediately and throw away any data not sent yet. The default linger time on Solaris seems to be 120 seconds btw. I cannot really say why this difference is present, I can only guess that one of them is a workaround for a bug. Perhaps the intention was indeed to allow 1 second until data is sent, but this didn't work on Windows? Does anybody here know more? Olaf Quoting Jay K : > > ? > > > >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Date: Sun, 23 Aug 2009 06:26:34 +0000 >> Subject: [M3devel] Posix/Win32 linger options inverted? >> >> >> http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-comm/tcp/src/POSIX/TCP.m3?rev=1.7;content-type=text%2Fplain >> >> vs. >> >> http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-comm/tcp/src/WIN32/TCP.m3?rev=1.3;content-type=text%2Fplain >> >> >> search for linger: >> >> PROCEDURE InitFD(fd: CARDINAL) = >> (* We assume that the runtime ignores SIGPIPE signals *) >> VAR >> one: int := 1; >> linger := Usocket.struct_linger{1, 1}; >> >> vs. >> >> PROCEDURE InitSock(sock: WinSock.SOCKET) = >> (* We assume that the runtime ignores SIGPIPE signals *) >> VAR >> one : BOOL := 1; >> linger := WinSock.struct_linger{0, 0}; >> >> >> Surely they can't both be correct. >> Which is correct? The Posix one? >> >> >> - Jay > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Aug 31 14:16:21 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 31 Aug 2009 12:16:21 +0000 Subject: [M3devel] tinderbox failures: undefined variables in quake In-Reply-To: <20090829235106.lb9zq4ouo8kcckgs@mail.elegosoft.com> References: <20090829235106.lb9zq4ouo8kcckgs@mail.elegosoft.com> Message-ID: There are definitely some bugs in old cm3 that I don't understand. My use of "local" at global scope may be dubious, granted. I can build cm3cg now from Linux/x86 5.4.0, but I'm not sure about the M3_PROFILING error. We'll see how the next runs go. The Tinderbox build scripts should run cm3 -version so we know what we are dealing with. - Jay > Date: Sat, 29 Aug 2009 23:51:06 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] tinderbox failures: undefined variables in quake > > Several release builds fail with undefined variables in quake now > (this is probably in the trunk I assume). > > Who broke this now? Is it just missing backward compatibility > or a more serious problem? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Aug 31 17:06:44 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 31 Aug 2009 11:06:44 -0400 Subject: [M3devel] "RandomTest" (that is its name) hangs on I386_OPENBSD In-Reply-To: References: Message-ID: <04B5CB8B-5D26-4529-86CA-25B399DE6F0C@cs.purdue.edu> The main thread should never hang here... Looks like thread 2 is not receiving/responding to the signal to stop. Something very wrong... On 31 Aug 2009, at 06:15, Jay K wrote: > "RandomTest" (that is its name) always hangs on I386_OPENBSD. > > > The main thread never finishes StopWorld: > > > (gdb) bt > #0 0x00ba08f1 in poll () from /usr/lib/libc.so.50.1 > #1 0x04ab5314 in _thread_kern_poll (wait_reqd=1) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:760 > #2 0x04ab4e53 in _thread_kern_sched (scp=0x0) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:382 > #3 0x04ab519f in _thread_kern_sched_state (state=615149768, > fname=0x24aa70c8 "", lineno=615149768) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:550 > #4 0x04aaf085 in nanosleep (time_to_sleep=0xcfbcc1a8, > time_remaining=0xcfbcc1b0) > at /usr/src/lib/libpthread/uthread/uthread_nanosleep.c:84 > #5 0x0166eafd in ThreadPThread__Nanosleep (req=0xcfbcc1a8, > rem=0xcfbcc1b0) > at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #6 0x0166b6f4 in ThreadPThread__CommonSleep () > at ../src/thread/PTHREAD/ThreadPThread.m3:651 > #7 0x0166d355 in ThreadPThread__StopWorld () > at ../src/thread/PTHREAD/ThreadPThread.m3:1142 > #8 0x0166c9c3 in ThreadF__SuspendOthers () > at ../src/thread/PTHREAD/ThreadPThread.m3:918 > #9 0x0164e70b in RTCollector__CollectSomeInStateZero () > at ../src/runtime/common/RTCollector.m3:747 > #10 0x0164e6ca in RTCollector__CollectSome () > at ../src/runtime/common/RTCollector.m3:721 > #11 0x0164e161 in RTCollector__CollectEnough (M3_AicXUJ_allocator=1 > '\001') > ---Type to continue, or q to quit--- > at ../src/runtime/common/RTCollector.m3:653 > #12 0x01650cb7 in RTCollector__LongAlloc (M3_Cwb5VA_dataSize=92, > M3_Cwb5VA_dataAlignment=4, M3_CAzbsM_pool=0x86770ab8) > at ../src/runtime/common/RTCollector.m3:1438 > #13 0x01650b14 in RTHeapRep__AllocTraced (M3_Cwb5VA_dataSize=92, > M3_Cwb5VA_dataAlignment=4, M3_CAzbsM_pool=0x86770ab8) > at ../src/runtime/common/RTCollector.m3:1400 > #14 0x01645b47 in RTAllocator__GetOpenArray (M3_Eic7CK_def=0x216259d0, > M3_ANmeAM_s=0xcfbcc4fc) at ../src/runtime/common/ > RTAllocator.m3:292 > #15 0x01644e3c in RTHooks__AllocateOpenArray > (M3_AJWxb1_defn=0x216259d0, > M3_ANmeAM_s=0xcfbcc4fc) at ../src/runtime/common/ > RTAllocator.m3:141 > #16 0x0c4b364f in RandomPerm__HQInit (M3_AMLmtL_t=0x7eed1fb0, > M3_Cwb5VA_n=21, > M3_BUCfej_r=0x7eecb0f4) at ../src/random/Common/RandomPerm.m3:55 > #17 0x1c00489e in RandomTest__TestPerm () at ../src/RandomTest.m3:367 > #18 0x1c0015f7 in RandomTest__Main () at ../src/RandomTest.m3:64 > #19 0x1c00595c in RandomTest_M3 (M3_AcxOUs_mode=1) at ../src/ > RandomTest.m3:458 > #20 0x01658a19 in RTLinker__RunMainBody (M3_DjPxE3_m=0x3c001660) > at ../src/runtime/common/RTLinker.m3:400 > #21 0x01657dd3 in RTLinker__AddUnitI (M3_DjPxE3_m=0x3c001660) > at ../src/runtime/common/RTLinker.m3:114 > #22 0x01657e61 in RTLinker__AddUnit (M3_DjPxE5_b=0x1c00588c) > at ../src/runtime/common/RTLinker.m3:123 > #23 0x1c001206 in main (argc=2, argv=0xcfbccadc, envp=0xcfbccae8) > at _m3main.mc:4 > > > While the other thread is in: > > > Thread 2 (process 5611, thread 0x7fc1d400): > #0 _thread_kern_sched (scp=0x0) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 > #1 0x04ab5200 in _thread_kern_sched_state_unlock (state=PS_SIGTHREAD, > lock=0x7fc1d4b0, fname=0x1
, lineno=1) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:581 > #2 0x04ab2bc9 in pthread_cond_wait (cond=0x80dda100, > mutex=0x80dda1e0) > at /usr/src/lib/libpthread/uthread/uthread_cond.c:261 > #3 0x01668b89 in ThreadPThread__XWait (M3_BXP32l_self=0x7eeff13c, > M3_AYIbX3_m=0x7eecb018, M3_Bl0jv4_c=0x7eecb06c, > M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ > ThreadPThread.m3:227 > #4 0x01669235 in Thread__Wait (M3_AYIbX3_m=0x7eecb018, > M3_Bl0jv4_c=0x7eecb06c) at ../src/thread/PTHREAD/ > ThreadPThread.m3:278 > #5 0x0c4c1de7 in AutoFlushWr__Worker (M3_EMTrVz_cl=0x7eeff134) > at ../src/rw/AutoFlushWr.m3:210 > #6 0x0166acfb in ThreadPThread__RunThread (M3_BeUkBA_me=0x86770b00) > at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #7 0x0166aa26 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x86770b00) > at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #8 0x04aac37f in _thread_start () > at /usr/src/lib/libpthread/uthread/uthread_create.c:240 > #9 0x0000002b in ?? () > #10 0x00000000 in ?? () > > > Maybe AutoFlushWr needs more work? > (It was crashing on platforms it didn't hang on.) > > I'll try to dig around more here.. > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Aug 31 19:16:43 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 31 Aug 2009 19:16:43 +0200 Subject: [M3devel] Pickling problem from 64 to 32 bit platforms Message-ID: <20090831191643.7djdygpgg08wksko@mail.elegosoft.com> I think we've got a problem with pickles from 64 to 32 bit target platforms. Details can be found in https://projects.elego.de/cm3/ticket/1068. Pickle experts should have a look at that. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney.m.bates at cox.net Mon Aug 31 23:37:31 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Mon, 31 Aug 2009 16:37:31 -0500 Subject: [M3devel] Pickling problem from 64 to 32 bit platforms In-Reply-To: <20090831191643.7djdygpgg08wksko@mail.elegosoft.com> References: <20090831191643.7djdygpgg08wksko@mail.elegosoft.com> Message-ID: <4A9C429B.9070308@cox.net> Some initial observations: I don't understand the circumstances where this is happening. "pickles from 64 to 32 bit" sounds to me like the pickle was written on a 64-bit machine and read on a 32-bit machine. But the backtrace seems to be of a run on a 64-bit machine, in part because of the filename in the outermost frame: #38 0x0000000000408409 in _start () at ../sysdeps/x86_64/elf/start.S:113 ^^^^^^ and in part, because all the hexadecimal addresses are 64-bit values. This example seems to be using version 1 of pickles: #5 0x000000000045ac12 in ReadRef (reader=16_00000000025b2018) at ../src/pickle/ver1/Pickle.m3:529 ^^^^ Without some vetting, I can't say for sure, but I'm not sure this version ever did all the cross-target stuff completely. Did this case work earlier under the same circumstances? The len parameter to String8.Hash has surely gone bad. Could there something wrong with operations on CARDINAL on 64-bit machines? What is the symptom of the failure? What needs to be run to reproduce it? Olaf Wagner wrote: > I think we've got a problem with pickles from 64 to 32 bit > target platforms. Details can be found in > https://projects.elego.de/cm3/ticket/1068. > > Pickle experts should have a look at that. > > Olaf From hosking at cs.purdue.edu Sat Aug 1 04:24:49 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 31 Jul 2009 22:24:49 -0400 Subject: [M3devel] package groups question In-Reply-To: References: <4A70A456.1E75.00D7.1@scires.com> <4A71A555.1E75.00D7.1@scires.com> <4A7236FD.1E75.00D7.1@scires.com> <20090731160546.z0n1l2nxa8w008sw@mail.elegosoft.com> <20090731151357.GA18289@topoi.pooq.com> <20090731152047.GC18289@topoi.pooq.com> <20090731182747.5zo12gu1og0os4cg@mail.elegosoft.com> <7E5CE55F-0F6D-48BA-ADEF-35D7C59FB321@cs.purdue.edu> Message-ID: Good to hear that you think the numeric format errors have been stamped out. Not so good to hear that we don't fully support host/ target distinctions in the front-end. Text .mc would need conversion to binary .mc for cm3cg to parse. On 31 Jul 2009, at 12:43, Jay K wrote: > > That reminds me, darn it.. > > Yes I think the INTEGER/FLOAT things are ok now. > I had hit problems in float and/or double bootstrapping where host > and target differed in endian and fixed it. There were also 32bit/ > 64bit problems there maybe, also now believed fixed. > > > And gcc used to be partly to blame for problems here, but has been > fixed. > I even suggested they rev the documented caveats about building for > Alpha and I think they did. > > I do bootstrap from host-generated .s files. > > I understand you could bootstrap from .mc files instead. > Maybe even textual ones? > That you use as a distribution format? > Advantages/disadvantages? > Minor one is that you'd have to build m3cc without the small aid > of cm3..not a big deal, just configure -disable-bootstrap -disable- > multilibs && make and ignore all my little tweaks in the m3makefile. > If not textual, mc files are less readable..but assembly is > unreadable to most people anyway.. > > There are bugs here though. > - I left in the hack you didn't like in order to bootstrap from > 32bit to 64bit, where TEXTs are limited to 4gig, rather than some > much larger value on 64bit systems. The front end should be doing > target math there not host math. > > - You can't bootstrap from 64bit to 32bit due to some similar small > bug in the front end. > Probably also a target math vs. host math thing. > > We already have the code to simulate target math, we just have to > use it a little more. > (This is what gcc now uses gmp/mpfr for presumably, like wrt > constant propagation.) > > > - Jay > > > ________________________________ >> From: hosking at cs.purdue.edu >> To: wagner at elegosoft.com >> Date: Fri, 31 Jul 2009 12:31:49 -0400 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] package groups question >> >> I think cross-compilation should always be the default approach, >> simply because it avoids all the version issues. We should be able >> to bootstrap from any host to any target. I know there have been >> deficiencies in the gcc-based cm3cg backend (for example when host >> and target INTEGER or FLOAT have different formats), but I think we >> are on the way to eliminating those. Bootstrapping from .mc files >> using a native cm3cg probably avoids that though, rather than >> bootstrapping from host-generated .s files. Jay, perhaps you have >> more to add? >> >> On 31 Jul 2009, at 12:27, Olaf Wagner wrote: >> >> I meant getting the first instance of cm3 5.1 run on a certain >> platform. >> And there was of course a first platform. We used the SRC compiler, >> the cm3 4.1 from Critical Mass, and the PM3 compiler on different >> platforms. Later we used cross-compilation almost exclusively. >> >> I assume that cross-compilation support has improved dramatically >> with all your changes. >> >> Olaf >> >> Quoting Jay K>: >> >> >> What does it mean to boot the compiler? >> >> >> I build the compiler from nothing but the compiler itself, >> and config files, and C compiler and linker, cvs >> to get all the source. >> That's not nothing, but it about the smallest start you can have, >> unless you rewrite the compiler in C, then you can start without >> the Modula-3 compiler. But at certain points in time this >> would not work, due to m3core and/or libm3 problems. >> It does work today. >> >> >> Is that booting? >> >> >> In future I'd like to dynamically link cm3, so I'd start with >> cm3, libm3.so, libm3core.so, etc. -- just cm3 and its "static >> dynamic" >> dependencies. Many other systems do dynamically link to this extent >> and we can to. >> >> >> I'm not just being obnoxious. >> Really, what does it mean? >> >> >> Should we just ship std and that's it? >> And even drop the name from it? >> cm3-PPC_LINUX-5.8.2.tar.gz ? >> >> >> (No need to say "POSIX", it is redundant). >> Just one download per platform? >> Not a big matrix of packages to test? >> >> >> Or do we look too fat in that packaging? :) >> >> >> Will too much stuff confuse users? >> >> >> Or mitigate the bulk with a little documentation/tutorial? >> >> >> Something like this: >> >> There are many libraries and packages. >> You do not need to worry about them. >> Here is hello world for a command line program: >> ... >> And for a gui program: >> ... >> And a minimal sample interoperating with C: >> ... >> And a minimal sample using Modula-3's RPC called "network objects": >> ... >> >> CM3 4.1 had some like this that were nice, presumably we have them. >> >> - Jay >> >> >> >> >> ---------------------------------------- >> Date: Fri, 31 Jul 2009 11:20:48 -0400 >> From: hendrik at topoi.pooq.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] package groups question >> >> On Fri, Jul 31, 2009 at 11:13:58AM -0400, hendrik at topoi.pooq.com >> wrote: >> On Fri, Jul 31, 2009 at 04:05:46PM +0200, Olaf Wagner wrote: >> Quoting Tony Hosking : >> >> I don't care if future versions are not compilable with old cm3. But, >> vice versa, old versions should always be compilable with new cm3. >> >> My gut feelings run along the lines of what Randy has said. I do >> think that the average user should accept std as the install, while >> min is for power-users who know what they are doing. Does that jive >> with other people's expectations? >> >> Sorry, I only now caught up with _some_ of the mails on the m3devel >> list. Too much traffic for me to digest. >> >> I gather there's been a long discussion that `min' is not really >> useful as it is not enough to build the system. When we started >> the cm3 5 business many years ago with lots of uncompilable sources >> from Farshad Nayeri, we invented the following sets of packages: >> >> all - obvious meaning. most packages did not compile at all. >> std - the set of packages shipped as compilable and usable with >> every new release >> core - a useful but small set of packages including everything to >> bootstrap the compiler >> boot - the minimal set to bootstrap the compiler >> min - the minimal set useful for anyone (not wanting to compiler cm3) >> >> As of today, std = all, and boot isn't used any more as far as a I >> see. >> >> Is that becaouse no one ever boots the compiler any more? Or because >> there are better ways to do it? >> >> -- hendrik >> >> I guess I should mention that ebian is perfectly happy if one source >> parckage (possibly the entire working cm3 system) generates multiple >> binary packages. >> >> -- hendrik >> >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >> 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >> Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Aug 1 08:51:41 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Fri, 31 Jul 2009 23:51:41 -0700 Subject: [M3devel] package groups question In-Reply-To: <4A72DD14020000D70005DF68@scires.com> References: <4A72DD14020000D70005DF68@scires.com> Message-ID: <27E6BB5F-1852-469E-8CA8-1299389734C7@hotmail.com> | From what I've gleaned in the discussions and the current documentation, I think most everyone has settled on the idea of having 2 "binary" distributions for this release: "min" and "std". > Really? How about just "std" and don't even label it as such? How many expert users are clamoring for "min"? There was actually a push for several non overlaping package sets and Olaf did work for that. But I'm not sure that is worth it. - Jay From wagner at elegosoft.com Sat Aug 1 12:34:09 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 01 Aug 2009 12:34:09 +0200 Subject: [M3devel] CM3 5.8 release engineering status Message-ID: <20090801123409.pgfzat70hco480o4@mail.elegosoft.com> Hi again, I just updated https://projects.elego.de/cm3/roadmap. The current Tinderbox and Hudson status look OK, so I've started to build some installation archives for RC2. Several machines have been integrated into the Hudson regression; there are some connection problems though, which sometimes lead to broken builds. I've been able to create installation archives for AMD64_LINUX, LINUXLIBC6, FreeBSD4 and PPC_DARWIN. SOLgnu and I386_OPENBSD maybe tomorrow, if nobody else is faster. To contribute, check out the release branch and execute make-dist.sh cvs checkout -r release_branch_cm3_5_8 cm3 cd cm3/scripts SHIPRC=yes ./make-dist.sh should do the trick and copy the resulting packages to birch via scp. I'll be away for most of the remaining weekend, but will look into the mail now and then. I've moved the downloads to their own page, but otherwise not changed much in the documentation. There's still a lot to do. I'd appreciate feedback of any installation successes and failures. So long, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Sat Aug 1 23:03:18 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sat, 1 Aug 2009 17:03:18 -0400 Subject: [M3devel] package groups question In-Reply-To: <27E6BB5F-1852-469E-8CA8-1299389734C7@hotmail.com> References: <4A72DD14020000D70005DF68@scires.com> <27E6BB5F-1852-469E-8CA8-1299389734C7@hotmail.com> Message-ID: <20090801210318.GA21289@topoi.pooq.com> On Fri, Jul 31, 2009 at 11:51:41PM -0700, jay.krell at cornell.edu wrote: > | From what I've gleaned in the discussions and the current > documentation, I think most everyone has settled on the idea of having > 2 "binary" distributions for this release: "min" and "std". > > > > Really? How about just "std" and don't even label it as such? How many > expert users are clamoring for "min"? > > There was actually a push for several non overlaping package sets and > Olaf did work for that. But I'm not sure that is worth it. The packages probably shouldn't overlap (at least if we want them to be adopted by Linux distributions, whose installers know about package dependencies) But there are packages that should be optional. There's no way I'm going to be able to install Xorg on a text-only machine just so I can install cm3 because, say, Trestle is part of the standard package and it's compiled for X. -- hendrik From jay.krell at cornell.edu Sat Aug 1 23:16:28 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 1 Aug 2009 21:16:28 +0000 Subject: [M3devel] package groups question In-Reply-To: <20090801210318.GA21289@topoi.pooq.com> References: <4A72DD14020000D70005DF68@scires.com> <27E6BB5F-1852-469E-8CA8-1299389734C7@hotmail.com> <20090801210318.GA21289@topoi.pooq.com> Message-ID: Nobody is going to make you install Xorg. - we only have X clients, no dependencies on an X server - if we just omit any dependencies and leave the obvious errors to occur if you happen to run those binaries (unable to find libX11.so...) that's not terrible imho. Granted that might be a little unfriendly to people who actually want to run..uh..formsedit, and don't yet have X client libraries and are willing to install them if only it is suggested to them.. Keep in mind that Olaf isn't building .debs and .rpms, just these .tar.gz files, that, indeed, have no stated dependencies -- leading to exactly what I said, no suggestion to install anything else, leaving forsmedit et. al. to fail to launch. Are their tools to turn dynamic link dependencies into package dependencies?? - Jay ---------------------------------------- > Date: Sat, 1 Aug 2009 17:03:18 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] package groups question > > On Fri, Jul 31, 2009 at 11:51:41PM -0700, jay.krell at cornell.edu wrote: >> | From what I've gleaned in the discussions and the current >> documentation, I think most everyone has settled on the idea of having >> 2 "binary" distributions for this release: "min" and "std". >>> >> >> Really? How about just "std" and don't even label it as such? How many >> expert users are clamoring for "min"? >> >> There was actually a push for several non overlaping package sets and >> Olaf did work for that. But I'm not sure that is worth it. > > The packages probably shouldn't overlap (at least if we want them to be > adopted by Linux distributions, whose installers know about package > dependencies) > > But there are packages that should be optional. There's no way I'm > going to be able to install Xorg on a text-only machine just so I can > install cm3 because, say, Trestle is part of the standard package and > it's compiled for X. > > -- hendrik From hendrik at topoi.pooq.com Sat Aug 1 23:20:29 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sat, 1 Aug 2009 17:20:29 -0400 Subject: [M3devel] package groups question In-Reply-To: References: <4A72DD14020000D70005DF68@scires.com> <27E6BB5F-1852-469E-8CA8-1299389734C7@hotmail.com> <20090801210318.GA21289@topoi.pooq.com> Message-ID: <20090801212029.GD21289@topoi.pooq.com> On Sat, Aug 01, 2009 at 09:16:28PM +0000, Jay K wrote: > > Nobody is going to make you install Xorg. > > - we only have X clients, no dependencies on an X server > > > - if we just omit any dependencies and leave the obvious errors to > occur if you happen to run those binaries (unable to find > libX11.so...) that's not terrible imho. > Granted that might be a little unfriendly to people who actually want > to run..uh..formsedit, and don't yet have X client libraries and > are willing to install them if only it is suggested to them.. > > > Keep in mind that Olaf isn't building .debs and .rpms, just these .tar.gz files, that, indeed, have no stated dependencies -- leading to exactly what I said, no suggestion to install anything else, leaving forsmedit et. al. to fail to launch. Well, that's OK for now, then. > > > Are their tools to turn dynamic link dependencies into package dependencies?? I don't think Debian does this. I think package dependencies are determined manually, judging form the occasional package I've encountered that lacks a few. -- hendrik > > > - Jay > > > ---------------------------------------- > > Date: Sat, 1 Aug 2009 17:03:18 -0400 > > From: hendrik at topoi.pooq.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] package groups question > > > > On Fri, Jul 31, 2009 at 11:51:41PM -0700, jay.krell at cornell.edu wrote: > >> | From what I've gleaned in the discussions and the current > >> documentation, I think most everyone has settled on the idea of having > >> 2 "binary" distributions for this release: "min" and "std". > >>> > >> > >> Really? How about just "std" and don't even label it as such? How many > >> expert users are clamoring for "min"? > >> > >> There was actually a push for several non overlaping package sets and > >> Olaf did work for that. But I'm not sure that is worth it. > > > > The packages probably shouldn't overlap (at least if we want them to be > > adopted by Linux distributions, whose installers know about package > > dependencies) > > > > But there are packages that should be optional. There's no way I'm > > going to be able to install Xorg on a text-only machine just so I can > > install cm3 because, say, Trestle is part of the standard package and > > it's compiled for X. > > > > -- hendrik From rcolebur at scires.com Sun Aug 2 05:46:38 2009 From: rcolebur at scires.com (Randy Coleburn) Date: Sat, 1 Aug 2009 23:46:38 -0400 Subject: [M3devel] package groups question In-Reply-To: <27E6BB5F-1852-469E-8CA8-1299389734C7@hotmail.com> References: <4A72DD14020000D70005DF68@scires.com> <27E6BB5F-1852-469E-8CA8-1299389734C7@hotmail.com> Message-ID: <4A74D3DB.1E75.00D7.1@scires.com> Jay: That's ok with me if you just want to do "std" and leave out "min". Regards, Randy >>> 8/1/2009 2:51 AM >>> | From what I've gleaned in the discussions and the current documentation, I think most everyone has settled on the idea of having 2 "binary" distributions for this release: "min" and "std". > Really? How about just "std" and don't even label it as such? How many expert users are clamoring for "min"? There was actually a push for several non overlaping package sets and Olaf did work for that. But I'm not sure that is worth it. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4550 bytes Desc: S/MIME Cryptographic Signature URL: From jay.krell at cornell.edu Sun Aug 2 11:18:51 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 2 Aug 2009 09:18:51 +0000 Subject: [M3devel] use of the old config files? Message-ID: I noticed this in the build output: === package m3-sys/cminstall === --- building in SOLgnu --- ignoring ../src/m3overrides /home/hudson/work/cm3-inst/ssol/current--release-build/bin/../bin/m3bundle -name Setup -element config ../src/config/SOLgnu Maybe it is just unused now? - Jay From jay.krell at cornell.edu Sun Aug 2 14:26:21 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 2 Aug 2009 12:26:21 +0000 Subject: [M3devel] some cvs errors? Message-ID: "/tmp/cvsUsaGYO" 61 lines, 1835 characters /usr/cvs/cm3/m3-sys/m3cc/src/m3makefile,v <-- src/m3makefile new revision: 1.111.2.4; previous revision: 1.111.2.3 Cannot Open data file (cwd: /usr/local/tinderbox/bonsai; data/temp.8776): Bad fi ? PKGS /usr/cvs/cm3/scripts/find-packages.sh,v <-- find-packages.sh new revision: 1.9.2.1; previous revision: 1.9 /usr/cvs/cm3/scripts/find-src-dirs.sh,v <-- find-src-dirs.sh new revision: 1.2.2.1; previous revision: 1.2 /usr/cvs/cm3/scripts/list-pkg-dirs.sh,v <-- list-pkg-dirs.sh new revision: 1.2.2.1; previous revision: 1.2 /usr/cvs/cm3/scripts/make-dist.sh,v <-- make-dist.sh new revision: 1.26.2.5; previous revision: 1.26.2.4 cvs [commit aborted]: cannot rename file .new.make-dist.sh to make-dist.sh: Perm ission denied ? I think the commits made it. - Jay From wagner at elegosoft.com Sun Aug 2 14:39:54 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 02 Aug 2009 14:39:54 +0200 Subject: [M3devel] the branch? In-Reply-To: References: Message-ID: <20090802143954.xhdv2b7b8ao40ggw@mail.elegosoft.com> Quoting Jay K : > I checked out/updated in the branch. > Then make-dist did an update and picked up somewhat old stuff, like > the old caltech "term" stuff and the toplevel compat.quake. Jay, make-dist.sh on the release branch is supposed to just build the RC2 tag and nothing else. If we want anything else for that RC, we have to move the tag and rebuild all archives affected by the change. Probably days later then. If SOLgnu is broken and we cannot build anything with the sources, then its broken in RC2. That's life. I thought averything had stabilized. Let's keep it that way on the branch. Feel free to test out different tool setups in the regression or commit changes to the trunk. If we need to merge fixes, let's just merge those absolutely necessary. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Sun Aug 2 14:57:41 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 02 Aug 2009 14:57:41 +0200 Subject: [M3devel] HEADS UP: release engineering procedure clarification Message-ID: <20090802145741.noi5p5y40s4cgg8c@mail.elegosoft.com> Hi all, it seems I may need to explain the current procedure adopted for release engineering in order to avoid some confusion and chaos. (1) All release engineering occurs on the release_branch_cm3_5_8. The trunk is currently unaffected. (2) All RCs will be built from the release branch. (3) Fixes may be merged as necessary to the branch, but not arbitrary changes. Fixes comprise actual source fixes to make the CM3 code work on some platform as well as changes to the scripts to correct building or regression testing. (4) The tag release_CM3_5_8_RC2 defines the release candiate 2. I've made the last adaptions yesterday and started packaging the archives. make-dist.sh is currently supposed to just build this RC. (5) If we move the RC2 tag, we always need to rebuild a number of archives. We cannot do that indefinitely, as it takes a long time. If something is broken in RC2, it can be fixed in RC3. If we don't accept some bugs, we'll never make any release. (6) The Hudson regression and I think most of the tinderbox regression follows the release branch and not the trunk. Please heed these rules and help by building packages, improving the documentation and testing the available installation archives. I'm going to setup some automated tests for installation archives during the next days, but they will only cover some very basic aspects. Thanks for your cooperation, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sun Aug 2 15:06:16 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 2 Aug 2009 13:06:16 +0000 Subject: [M3devel] the branch? In-Reply-To: <20090802143954.xhdv2b7b8ao40ggw@mail.elegosoft.com> References: <20090802143954.xhdv2b7b8ao40ggw@mail.elegosoft.com> Message-ID: I understand, but it's very wierd, I run make-dist and it updates my source. bash-3.2$ rm PKGS rm: cannot remove `PKGS': No such file or directory bash-3.2$ SHIPRC=yes ./make-dist.sh making /cygdrive/c/dev2/cm3.release_branch_cm3_5_8/scripts/PKGS (slow but rare) ? scripts/PKGS U compat.quake U caltech-parser/term/src/cfmakeraw.c U caltech-parser/term/src/termios.h I don't even know why make-dist would be running any cvs upd command at all. I'll have to investigate further. - Jay ---------------------------------------- > Date: Sun, 2 Aug 2009 14:39:54 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: the branch? > > Quoting Jay K : > >> I checked out/updated in the branch. >> Then make-dist did an update and picked up somewhat old stuff, like >> the old caltech "term" stuff and the toplevel compat.quake. > > Jay, > > make-dist.sh on the release branch is supposed to just build the > RC2 tag and nothing else. > > If we want anything else for that RC, we have to move the tag > and rebuild all archives affected by the change. Probably days later then. > > If SOLgnu is broken and we cannot build anything with the sources, > then its broken in RC2. That's life. > > I thought averything had stabilized. Let's keep it that way on the > branch. Feel free to test out different tool setups in the regression > or commit changes to the trunk. > > If we need to merge fixes, let's just merge those absolutely necessary. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Sun Aug 2 15:07:24 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 2 Aug 2009 13:07:24 +0000 Subject: [M3devel] the branch? In-Reply-To: <20090802143954.xhdv2b7b8ao40ggw@mail.elegosoft.com> References: <20090802143954.xhdv2b7b8ao40ggw@mail.elegosoft.com> Message-ID: Oh, it is updating from release_CM3_5_8 to release_CM3_5_8_RC2. I thought we were supposed to checkout release_CM3_5_8. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > CC: m3devel at elegosoft.com > Subject: RE: the branch? > Date: Sun, 2 Aug 2009 13:06:16 +0000 > > > I understand, but it's very wierd, I run make-dist and it updates my source. > > bash-3.2$ rm PKGS > rm: cannot remove `PKGS': No such file or directory > bash-3.2$ SHIPRC=yes ./make-dist.sh > making /cygdrive/c/dev2/cm3.release_branch_cm3_5_8/scripts/PKGS (slow but rare) > ? scripts/PKGS > U compat.quake > U caltech-parser/term/src/cfmakeraw.c > U caltech-parser/term/src/termios.h > > I don't even know why make-dist would be running any cvs upd command at all. > I'll have to investigate further. > > - Jay > > > ---------------------------------------- >> Date: Sun, 2 Aug 2009 14:39:54 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: the branch? >> >> Quoting Jay K : >> >>> I checked out/updated in the branch. >>> Then make-dist did an update and picked up somewhat old stuff, like >>> the old caltech "term" stuff and the toplevel compat.quake. >> >> Jay, >> >> make-dist.sh on the release branch is supposed to just build the >> RC2 tag and nothing else. >> >> If we want anything else for that RC, we have to move the tag >> and rebuild all archives affected by the change. Probably days later then. >> >> If SOLgnu is broken and we cannot build anything with the sources, >> then its broken in RC2. That's life. >> >> I thought averything had stabilized. Let's keep it that way on the >> branch. Feel free to test out different tool setups in the regression >> or commit changes to the trunk. >> >> If we need to merge fixes, let's just merge those absolutely necessary. >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> From wagner at elegosoft.com Sun Aug 2 15:36:29 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 02 Aug 2009 15:36:29 +0200 Subject: [M3devel] HEADS UP: release engineering procedure clarification In-Reply-To: References: <20090802145741.noi5p5y40s4cgg8c@mail.elegosoft.com> Message-ID: <20090802153629.lqe9usnzocs4okwk@mail.elegosoft.com> Quoting Jay K : >> the CM3 code work on some platform as well as changes to the >> scripts to correct building or regression testing. > > That's what I was doing. > > SOLgnu probably shouldn't require a custom gcc, and the changes, > e.g. in m3cc only affect SOLgnu/SOLsun. > You don't really have to rebuild everything due to that change. > That's just an artifact of how CVS triggers Hudson. You can keep > whatever preexisting built packages exist. > > Changes in scripts were so Cygwin sh could build NT386. Likewise. It's all OK until now AFAIK. We can selectively rebuild packages. I've just move the RC2 tag to reflect your changes in scripts and will rebuild the source archive. We haven't got any archives yet for SOLgnu, so we can change anything platform speccific there and move the tag forward, as long as it doesn't affect other targets. Olaf > > - Jay > > > ---------------------------------------- >> Date: Sun, 2 Aug 2009 14:57:41 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] HEADS UP: release engineering procedure clarification >> >> Hi all, >> >> it seems I may need to explain the current procedure adopted for >> release engineering in order to avoid some confusion and chaos. >> >> (1) All release engineering occurs on the release_branch_cm3_5_8. >> The trunk is currently unaffected. >> (2) All RCs will be built from the release branch. >> (3) Fixes may be merged as necessary to the branch, but not >> arbitrary changes. Fixes comprise actual source fixes to make >> the CM3 code work on some platform as well as changes to the >> scripts to correct building or regression testing. >> (4) The tag release_CM3_5_8_RC2 defines the release candiate 2. >> I've made the last adaptions yesterday and started packaging >> the archives. make-dist.sh is currently supposed to just build >> this RC. >> (5) If we move the RC2 tag, we always need to rebuild a number of >> archives. We cannot do that indefinitely, as it takes a long >> time. If something is broken in RC2, it can be fixed in RC3. >> If we don't accept some bugs, we'll never make any release. >> (6) The Hudson regression and I think most of the tinderbox >> regression follows the release branch and not the trunk. >> >> Please heed these rules and help by building packages, improving >> the documentation and testing the available installation archives. >> >> I'm going to setup some automated tests for installation archives >> during the next days, but they will only cover some very basic >> aspects. >> >> Thanks for your cooperation, >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sun Aug 2 15:44:54 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 2 Aug 2009 13:44:54 +0000 Subject: [M3devel] HEADS UP: release engineering procedure clarification In-Reply-To: <20090802153629.lqe9usnzocs4okwk@mail.elegosoft.com> References: <20090802145741.noi5p5y40s4cgg8c@mail.elegosoft.com> <20090802153629.lqe9usnzocs4okwk@mail.elegosoft.com> Message-ID: I'll give up on SOLgnu now building with /usr/sfw/bin/gcc, since it failed again. There is another experiment to try -- -with-as=/usr/sfw/bin/as -with-gnu-as. I've changed hudson's .profile back to have /usr/local/bin in front and trying again. It looks like release and lastok are mixed up, ok. - Jay ---------------------------------------- > Date: Sun, 2 Aug 2009 15:36:29 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] HEADS UP: release engineering procedure clarification > > Quoting Jay K : > >>> the CM3 code work on some platform as well as changes to the >>> scripts to correct building or regression testing. >> >> That's what I was doing. >> >> SOLgnu probably shouldn't require a custom gcc, and the changes, >> e.g. in m3cc only affect SOLgnu/SOLsun. >> You don't really have to rebuild everything due to that change. >> That's just an artifact of how CVS triggers Hudson. You can keep >> whatever preexisting built packages exist. >> >> Changes in scripts were so Cygwin sh could build NT386. Likewise. > > It's all OK until now AFAIK. We can selectively rebuild packages. > I've just move the RC2 tag to reflect your changes in scripts > and will rebuild the source archive. > > We haven't got any archives yet for SOLgnu, so we can change > anything platform speccific there and move the tag forward, as long > as it doesn't affect other targets. > > Olaf > >> >> - Jay >> >> >> ---------------------------------------- >>> Date: Sun, 2 Aug 2009 14:57:41 +0200 >>> From: wagner at elegosoft.com >>> To: m3devel at elegosoft.com >>> Subject: [M3devel] HEADS UP: release engineering procedure clarification >>> >>> Hi all, >>> >>> it seems I may need to explain the current procedure adopted for >>> release engineering in order to avoid some confusion and chaos. >>> >>> (1) All release engineering occurs on the release_branch_cm3_5_8. >>> The trunk is currently unaffected. >>> (2) All RCs will be built from the release branch. >>> (3) Fixes may be merged as necessary to the branch, but not >>> arbitrary changes. Fixes comprise actual source fixes to make >>> the CM3 code work on some platform as well as changes to the >>> scripts to correct building or regression testing. >>> (4) The tag release_CM3_5_8_RC2 defines the release candiate 2. >>> I've made the last adaptions yesterday and started packaging >>> the archives. make-dist.sh is currently supposed to just build >>> this RC. >>> (5) If we move the RC2 tag, we always need to rebuild a number of >>> archives. We cannot do that indefinitely, as it takes a long >>> time. If something is broken in RC2, it can be fixed in RC3. >>> If we don't accept some bugs, we'll never make any release. >>> (6) The Hudson regression and I think most of the tinderbox >>> regression follows the release branch and not the trunk. >>> >>> Please heed these rules and help by building packages, improving >>> the documentation and testing the available installation archives. >>> >>> I'm going to setup some automated tests for installation archives >>> during the next days, but they will only cover some very basic >>> aspects. >>> >>> Thanks for your cooperation, >>> >>> Olaf >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From rcoleburn at scires.com Mon Aug 3 06:52:45 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 03 Aug 2009 00:52:45 -0400 Subject: [M3devel] problems with cm3.cfg and MxConfig Message-ID: <4A763446.1E75.00D7.1@scires.com> I have been working on the problem of cm3ide not getting the BUILD_DIR from cm3.cfg. I've run across some perplexing test results. MxConfig.Get("BUILD_DIR") is returning NIL on Windows XP & Vista. I've tracked it down a bit further. There seem to be two issues that must be fixed to solve this problem: 1. HOST does not seem to be defined. In particular my "C:\cm3\bin\cm3.cfg" file appears as follows (this is the file Jay recommended): INSTALL_ROOT = path() & "/.." include (path() & "/config/" & HOST) Is HOST a variable? Or, was I supposed to replace it by "NT386"? If the latter, my bad on this one--I took Jay's message literally. 2. path() does not appear to always yield the path to the bin folder. In particular, it seems to work fine unless you invoke the program when the current directory is actually set to the bin folder, in which case path() seems to return the empty string. So, if %CD%=C:\, and I run cm3ide, path() returns "C:\cm3\bin" as it should. But, if %CD%=C:\cm3\bin, and I run cm3ide, path() returns "". So in the latter case, the include statement winds up trying to pull a file from the wrong place, e.g. "/config/NT386" rather than "C:\cm3\bin/config/NT386" Regards, Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Aug 3 08:42:17 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Sun, 2 Aug 2009 23:42:17 -0700 Subject: [M3devel] problems with cm3.cfg and MxConfig In-Reply-To: <4A763446.1E75.00D7.1@scires.com> References: <4A763446.1E75.00D7.1@scires.com> Message-ID: Host, hm, I think probably my mistake. It is defined by cm3 but not all m3quake users. Path() should be the directory containing the file with the call. - Jay (phone) On Aug 2, 2009, at 9:52 PM, "Randy Coleburn" wrote: > I have been working on the problem of cm3ide not getting the > BUILD_DIR from cm3.cfg. I've run across some perplexing test results. > > MxConfig.Get("BUILD_DIR") is returning NIL on Windows XP & Vista. > I've tracked it down a bit further. There seem to be two issues > that must be fixed to solve this problem: > > 1. HOST does not seem to be defined. In particular my "C:\cm3\bin > \cm3.cfg" file appears as follows (this is the file Jay recommended): > INSTALL_ROOT = path() & "/.." > include (path() & "/config/" & HOST) > > Is HOST a variable? Or, was I supposed to replace it by "NT386"? > If the latter, my bad on this one--I took Jay's message literally. > > 2. path() does not appear to always yield the path to the bin > folder. In particular, it seems to work fine unless you invoke the > program when the current directory is actually set to the bin > folder, in which case path() seems to return the empty string. > > So, if ?%=C:\, and I run cm3ide, path() returns "C:\cm3\bin" as it s > hould. > But, if ?%=C:\cm3\bin, and I run cm3ide, path() returns "". > > So in the latter case, the include statement winds up trying to pull > a file from the wrong place, e.g. "/config/NT386" rather than "C: > \cm3\bin/config/NT386" > > Regards, > Randy Coleburn From jay.krell at cornell.edu Mon Aug 3 09:37:23 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 07:37:23 +0000 Subject: [M3devel] problems with cm3.cfg and MxConfig In-Reply-To: <4A763446.1E75.00D7.1@scires.com> References: <4A763446.1E75.00D7.1@scires.com> Message-ID: I will address #1 by changing the cm3.cfg files to say the actual target instead of depending on host. I still have to look into #2, that's the first I heard of it, but it could be again some difference between cm3 and all the other m3quake users. - Jay ________________________________ > Date: Mon, 3 Aug 2009 00:52:45 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: [M3devel] problems with cm3.cfg and MxConfig > > > > > > > > I have been working on the problem of cm3ide not getting the BUILD_DIR from cm3.cfg. I've run across some perplexing test results. > > > > MxConfig.Get("BUILD_DIR") is returning NIL on Windows XP & Vista. I've tracked it down a bit further. There seem to be two issues that must be fixed to solve this problem: > > > > 1. HOST does not seem to be defined. In particular my "C:\cm3\bin\cm3.cfg" file appears as follows (this is the file Jay recommended): > > INSTALL_ROOT = path() & "/.." > > include (path() & "/config/" & HOST) > > > > Is HOST a variable? Or, was I supposed to replace it by "NT386"? If the latter, my bad on this one--I took Jay's message literally. > > > > 2. path() does not appear to always yield the path to the bin folder. In particular, it seems to work fine unless you invoke the program when the current directory is actually set to the bin folder, in which case path() seems to return the empty string. > > > > So, if ?%=C:\, and I run cm3ide, path() returns "C:\cm3\bin" as it should. > > But, if ?%=C:\cm3\bin, and I run cm3ide, path() returns "". > > > > So in the latter case, the include statement winds up trying to pull a file from the wrong place, e.g. "/config/NT386" rather than "C:\cm3\bin/config/NT386" > > > > Regards, > > Randy Coleburn From jay.krell at cornell.edu Mon Aug 3 09:38:25 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 07:38:25 +0000 Subject: [M3devel] cm3 vs. m3quake Message-ID: cm3 defines some things, like: C:\dev2\cm3.2\m3-sys\cm3\src\Main.m3(54): Quake.Define(mach, "TARGET", MxConfig.HOST); C:\dev2\cm3.2\m3-sys\cm3\src\Main.m3(55): Quake.Define(mach, "OS_TYPE", MxConfig.HOST_OS_TYPE); C:\dev2\cm3.2\m3-sys\cm3\src\Main.m3(61): Quake.Define(mach, "WORD_SIZE", MxConfig.HOST_WORD_SIZE); C:\dev2\cm3.2\m3-sys\cm3\src\Main.m3(66): Quake.Define(mach, "HOST", MxConfig.HOST); C:\dev2\cm3.2\m3-sys\cm3\src\Main.m3(67): Quake.Define(mach, "HOST_OS_TYPE", MxConfig.HOST_OS_TYPE); C:\dev2\cm3.2\m3-sys\cm3\src\Main.m3(68): Quake.Define(mach, "HOST_GNU_MAKE", Version.GNUMake); all the other m3quake users don't get this. Would it be too polluting to move this to m3quake, thereby making m3quake just not a generic scripting language, but slightly specific to building Modula-3 stuff? I'll hold off for now. - Jay From jay.krell at cornell.edu Mon Aug 3 09:41:26 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 07:41:26 +0000 Subject: [M3devel] assembly goes to C compiler? Message-ID: Does this surprising anyone else: PROCEDURE CompileS (s: State; u: M3Unit.T) = ... ELSIF (u.kind = UK.S) THEN RunCC (s, UnitPath (u), u.object, u.debug, u.optimize); I kept modifying SYSTEM_ASM thinking it would affect how RTMachineASM.s is assembled, but it doesn't. I actually was thinking it might be nice to have two assembly functions, one for the output of m3cg, one for user written code. So, we do in fact have two functions, but one is the function for compiling C!. I'd want a third function, ideally. I'll leave this alone and just special case RTMachineASM.s in the config file, if that works out. That is, I'll try a very targeted slighly inelegant change, goal being to assemble this particular file with /usr/ccs/bin/as instead of the C compiler, on SOLgnu only. - Jay From dragisha at m3w.org Mon Aug 3 10:08:55 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 03 Aug 2009 10:08:55 +0200 Subject: [M3devel] More MxConfig Message-ID: <1249286935.28197.731.camel@faramir.m3w.org> This MxConfig thing looks like a bloody mess. To access former M3Config data I must have cm3.cfg suite present (to date I only had it in -devel packages, but ok...) Except cm3.cfg - ok, it's only set of text files, I must have sysutils, m3middle and m3quake.... A chunk of compiler. All this to read three or five variables from system. Also, this: VAR PKG_INSTALL := MxConfig.Get("PKG_INSTALL"); BUILD_DIR := MxConfig.Get("BUILD_DIR"); PROCEDURE DoImportBase() = BEGIN EVAL DoImportFile(PKG_INSTALL & "/libm3/" & BUILD_DIR & "/.M3WEB", TRUE); Fails on Concat in DoImportFile line - both variables NIL. Do I have some more voodoo to do to initialize MxConfig subsystem? -- Dragi?a Duri? From jay.krell at cornell.edu Mon Aug 3 10:36:24 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 08:36:24 +0000 Subject: [M3devel] the SOLgnu alignment problem finally understood Message-ID: Here finally is a small example of the SOLgnu problem I've been looking at it. It is specific to using /usr/sfw/bin/gcc -g to asssemble. No problem without -g, no problem with /usr/bin/cc, no problem with whatever I built in /usr/local/bin/gcc, no problem if you assemble with anything else and then link with /usr/sfw/bin/gcc -g. -bash-3.00$ cat 4.c asm.s 4.c void Asm(void); #include int main() { Asm(); printf("\n"); return 0; } asm.s .section ".text",#alloc,#execinstr .align 4 .global Asm .type Asm,#function Asm: retl nop .size Asm, (.-Asm) Not all possibilities shown here: -bash-3.00$ /usr/local/bin/gcc -g asm.s 4.c ok -bash-3.00$ /usr/sfw/bin/gcc -g asm.s 4.c ld: fatal: relocation error: R_SPARC_32: file /var/tmp//ccICgvny.o: symbol : offset 0xfeed139e is non-aligned ld: fatal: relocation error: R_SPARC_32: file /var/tmp//ccICgvny.o: symbol : offset 0xfeed14c2 is non-aligned ld: fatal: relocation error: R_SPARC_32: file /var/tmp//ccICgvny.o: symbol : offset 0xfeed15f6 is non-aligned collect2: ld returned 1 exit status -bash-3.00$ /usr/bin/cc -g asm.s 4.c asm.s: 4.c: ok -bash-3.00$ /usr/bin/cc asm.s 4.c asm.s: 4.c: ok -bash-3.00$ /usr/sfw/bin/gcc asm.s 4.c ok -bash-3.00$ /usr/local/bin/gcc asm.s 4.c ok -bash-3.00$ /usr/sfw/bin/gcc -g -c asm.s ok but haven't linked yet, input to later steps -bash-3.00$ /usr/bin/cc asm.o 4.c ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x ff10148e is non-aligned ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x ff1014ca is non-aligned ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x ff1015be is non-aligned -bash-3.00$ /usr/local/bin/gcc asm.o 4.c ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x feee1213 is non-aligned ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x feee122a is non-aligned ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x feee122e is non-aligned ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x feee1232 is non-aligned ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x feee126e is non-aligned collect2: ld returned 1 exit status -bash-3.00$ /usr/local/bin/gcc -g -c asm.s ok, try linking with others -bash-3.00$ /usr/bin/cc asm.o 4.c ok -bash-3.00$ /usr/sfw/bin/gcc asm.o 4.c ok Actually even -gstabs or -gstabs+ instead of -g make it work. -g resolves to -gdwarf2. - Jay From jay.krell at cornell.edu Mon Aug 3 10:42:22 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 08:42:22 +0000 Subject: [M3devel] More MxConfig In-Reply-To: <1249286935.28197.731.camel@faramir.m3w.org> References: <1249286935.28197.731.camel@faramir.m3w.org> Message-ID: Do you want to be able to move your cm3 install around, without editing the config file? You know, "be relocatable without any fixup code"? That is the big question. That is what MxConfig buys. These "variables" are computed, by running quake code. They are in fact known at install time, unless you later move the install around, and require something (cminstall) to modify the config files at install time. If nobody cares about moving installs around without invalidating their config file, we could put it back to a bunch of string constants. And we'd have to put back the markers that trigger cminstall to replace stuff. BUILD_DIR is basically constant either way. But, do you care about profiling? I don't really. Actually probably none of the tools properly support profiling anyway, except cm3. They would have to accept a command line switch. Dragi?a, do you have the symbolic HOST vs. actual string problem in cm3.cfg? A difference biting us is that cm3 does set a few values, such as PROFILING, SL, HOST. I haven't solved the path() problem yet that Randy reported. - Jay ---------------------------------------- > From: dragisha at m3w.org > To: m3devel at elegosoft.com > Date: Mon, 3 Aug 2009 10:08:55 +0200 > Subject: [M3devel] More MxConfig > > This MxConfig thing looks like a bloody mess. > > To access former M3Config data I must have cm3.cfg suite present (to > date I only had it in -devel packages, but ok...) > > Except cm3.cfg - ok, it's only set of text files, I must have sysutils, > m3middle and m3quake.... A chunk of compiler. > > All this to read three or five variables from system. > > Also, this: > > VAR > PKG_INSTALL := MxConfig.Get("PKG_INSTALL"); > BUILD_DIR := MxConfig.Get("BUILD_DIR"); > > PROCEDURE DoImportBase() = > BEGIN > EVAL DoImportFile(PKG_INSTALL & "/libm3/" & BUILD_DIR & > "/.M3WEB", TRUE); > > Fails on Concat in DoImportFile line - both variables NIL. > > Do I have some more voodoo to do to initialize MxConfig subsystem? > > -- > Dragi?a Duri? > From jay.krell at cornell.edu Mon Aug 3 10:51:28 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 08:51:28 +0000 Subject: [M3devel] More MxConfig In-Reply-To: References: <1249286935.28197.731.camel@faramir.m3w.org> Message-ID: ps: I should add that the way it was before was broken from a certain legitimate point of view. The M3Config paths were computed at build time, i.e. on Olaf's machine, i.e. they would point into /tmp or /home/hudson/work/cm3-inst or such. If you built things yourself, then ok, they worked. cminstall did not handle this. They were just constant strings in a generated M3Config.i3. cminstall could only "fix" MxConfig. I still think this is progress, though it would be nice if HOST worked and I have to look into path(). - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: dragisha at m3w.org; m3devel at elegosoft.com > Date: Mon, 3 Aug 2009 08:42:22 +0000 > Subject: Re: [M3devel] More MxConfig > > > Do you want to be able to move your cm3 install around, without editing the config file? > You know, "be relocatable without any fixup code"? > That is the big question. That is what MxConfig buys. > These "variables" are computed, by running quake code. > They are in fact known at install time, unless you later move the install around, > and require something (cminstall) to modify the config files at install time. > If nobody cares about moving installs around without invalidating their config file, > we could put it back to a bunch of string constants. And we'd have to put back > the markers that trigger cminstall to replace stuff. > > > BUILD_DIR is basically constant either way. But, do you care about profiling? I don't really. > Actually probably none of the tools properly support profiling anyway, except cm3. > They would have to accept a command line switch. > > > Dragi?a, do you have the symbolic HOST vs. actual string problem in cm3.cfg? > > > A difference biting us is that cm3 does set a few values, such as PROFILING, SL, HOST. > > > I haven't solved the path() problem yet that Randy reported. > > > - Jay > > > > ---------------------------------------- >> From: dragisha at m3w.org >> To: m3devel at elegosoft.com >> Date: Mon, 3 Aug 2009 10:08:55 +0200 >> Subject: [M3devel] More MxConfig >> >> This MxConfig thing looks like a bloody mess. >> >> To access former M3Config data I must have cm3.cfg suite present (to >> date I only had it in -devel packages, but ok...) >> >> Except cm3.cfg - ok, it's only set of text files, I must have sysutils, >> m3middle and m3quake.... A chunk of compiler. >> >> All this to read three or five variables from system. >> >> Also, this: >> >> VAR >> PKG_INSTALL := MxConfig.Get("PKG_INSTALL"); >> BUILD_DIR := MxConfig.Get("BUILD_DIR"); >> >> PROCEDURE DoImportBase() = >> BEGIN >> EVAL DoImportFile(PKG_INSTALL & "/libm3/" & BUILD_DIR & >> "/.M3WEB", TRUE); >> >> Fails on Concat in DoImportFile line - both variables NIL. >> >> Do I have some more voodoo to do to initialize MxConfig subsystem? >> >> -- >> Dragi?a Duri? >> From dragisha at m3w.org Mon Aug 3 10:55:48 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 03 Aug 2009 10:55:48 +0200 Subject: [M3devel] More MxConfig In-Reply-To: References: <1249286935.28197.731.camel@faramir.m3w.org> Message-ID: <1249289748.28197.740.camel@faramir.m3w.org> New auto-configuring cm3.cfg stuff is all ok. Great! I don't see importance of "moveable around" in that. Only "no need for cminstall and markers". "moveable around" is good when building from source using some kind of cm3-min. While at that, cm3-supermin with only cm3 binary and config files (probably cm3cg) would be supersmart feature. I am curently using cm3-min as a bootstraping device, and first thing I do is making libm3 and m3core over from supplied source. "Moveable around" is probably good, but if a chunk of compiler infrastructure included in any program reading those variables is price - I think it's good point to reconsider goals and ways. On Mon, 2009-08-03 at 08:42 +0000, Jay K wrote: > Do you want to be able to move your cm3 install around, without > editing the config file? > You know, "be relocatable without any fixup code"? > That is the big question. That is what MxConfig buys. > These "variables" are computed, by running quake code. > They are in fact known at install time, unless you later move the > install around, > and require something (cminstall) to modify the config files at > install time. > If nobody cares about moving installs around without invalidating > their config file, > we could put it back to a bunch of string constants. And we'd have > to put back > the markers that trigger cminstall to replace stuff. -- Dragi?a Duri? From jay.krell at cornell.edu Mon Aug 3 11:05:09 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 09:05:09 +0000 Subject: [M3devel] problems with cm3.cfg and MxConfig In-Reply-To: References: <4A763446.1E75.00D7.1@scires.com> Message-ID: Sorry about #1 Randy, my mistake. Sitting in the bin directory...seems a little wierd, eh? What source are you going to build sitting there? I guess um some custom quake code?? Good enough if empty is instead just "."? This falls out of the fact that cm3 actually probes all over the place for the cm3.cfg file and the first place it looks in is the current directory. Another good option I think would be just to remove that probe. It looks in way too many places. Here is the current code. I think it is gross. Too much probing make things quite ambiguous. PROCEDURE FindConfig () = (* LL = mu *) VAR txt: TEXT; BEGIN IF (found) THEN RETURN END; (* try the current directory *) IF TryConfig (Filename) THEN RETURN END; (* try the immediate source directory *) IF TryConfig ("src", Filename) THEN RETURN END; (* try the sibling source directory *) IF TryConfig ("..", "src", Filename) THEN RETURN END; (* try the M3CONFIG environment variable *) txt := QMachine.GetEnv (NIL, "M3CONFIG"); IF (txt # NIL) THEN IF TryConfig (txt) THEN RETURN END; IF TryConfig (txt, Filename) THEN RETURN END; END; (* try the directory containing the current executable *) txt := Pathname.Prefix (Params.Get (0)); IF Text.Length (txt)> 0 THEN IF TryConfig (txt, Filename) THEN RETURN END; END; (* try the directories named by the PATH environment variable. *) txt := Env.Get ("PATH"); FindConfigInPath (txt); IF found THEN RETURN END; (* try the etc directories *) IF TryConfig("/usr/local/cm3/etc", Filename) THEN RETURN END; IF TryConfig("/usr/cm3/etc", Filename) THEN RETURN END; IF TryConfig("/cm3/etc", Filename) THEN RETURN END; IF TryConfig("/usr/contrib/etc", Filename) THEN RETURN END; IF TryConfig("/usr/local/etc", Filename) THEN RETURN END; IF TryConfig("/usr/etc", Filename) THEN RETURN END; IF TryConfig("/opt/etc", Filename) THEN RETURN END; IF TryConfig("/sw/etc", Filename) THEN RETURN END; IF TryConfig("/etc", Filename) THEN RETURN END; (* oh well, make sure we don't try this silly exercise again... *) config := NIL; found := TRUE; END FindConfig; I propose..roughly roughly, we make it like this instead: PROCEDURE FindConfig () = (* LL = mu *) VAR txt: TEXT; BEGIN IF (found) THEN RETURN END; (* try the M3CONFIG environment variable *) txt := QMachine.GetEnv (NIL, "M3CONFIG"); IF (txt # NIL) THEN IF TryConfig (txt) THEN RETURN END; IF TryConfig (txt, Filename) THEN RETURN END; END; (* try the directory containing the current executable *) txt := Pathname.Prefix (Params.Get (0)); IF Text.Length (txt)> 0 THEN IF TryConfig (txt, Filename) THEN RETURN END; END; (* oh well, make sure we don't try this silly exercise again... *) config := NIL; found := TRUE; END FindConfig; or, if people really like it looking all over the place, fixing the case of it being in the current working directory is probably like this: (* try the current directory *) < IF TryConfig (Filename) THEN RETURN END; > IF TryConfig (".", Filename) THEN RETURN END; - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: rcoleburn at scires.com > Date: Sun, 2 Aug 2009 23:42:17 -0700 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] problems with cm3.cfg and MxConfig > > Host, hm, I think probably my mistake. It is defined by cm3 but not > all m3quake users. Path() should be the directory containing the file > with the call. > > - Jay (phone) > > On Aug 2, 2009, at 9:52 PM, "Randy Coleburn" > wrote: > >> I have been working on the problem of cm3ide not getting the >> BUILD_DIR from cm3.cfg. I've run across some perplexing test results. >> >> MxConfig.Get("BUILD_DIR") is returning NIL on Windows XP & Vista. >> I've tracked it down a bit further. There seem to be two issues >> that must be fixed to solve this problem: >> >> 1. HOST does not seem to be defined. In particular my "C:\cm3\bin >> \cm3.cfg" file appears as follows (this is the file Jay recommended): >> INSTALL_ROOT = path() & "/.." >> include (path() & "/config/" & HOST) >> >> Is HOST a variable? Or, was I supposed to replace it by "NT386"? >> If the latter, my bad on this one--I took Jay's message literally. >> >> 2. path() does not appear to always yield the path to the bin >> folder. In particular, it seems to work fine unless you invoke the >> program when the current directory is actually set to the bin >> folder, in which case path() seems to return the empty string. >> >> So, if ?%=C:\, and I run cm3ide, path() returns "C:\cm3\bin" as it s >> hould. >> But, if ?%=C:\cm3\bin, and I run cm3ide, path() returns "". >> >> So in the latter case, the include statement winds up trying to pull >> a file from the wrong place, e.g. "/config/NT386" rather than "C: >> \cm3\bin/config/NT386" >> >> Regards, >> Randy Coleburn From jay.krell at cornell.edu Mon Aug 3 11:13:25 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 09:13:25 +0000 Subject: [M3devel] More MxConfig In-Reply-To: <1249289748.28197.740.camel@faramir.m3w.org> References: <1249286935.28197.731.camel@faramir.m3w.org> <1249289748.28197.740.camel@faramir.m3w.org> Message-ID: Supermin is just cm3 + config files. And the config files we could/should m3bundle into cm3, leaving it to just be cm3. Providing cm3cg is a nice optimization, but then, you know, is the point to: build as much as possible or build as little as possible? build nothing, just get "std" or all of Olaf's packages. I would actually like to make cm3 dynamically linked, so supermin would also include m3core, libm3, sysutils. You could use ldd or whatever to discover. Look at gcc for example -- it doesn't statically link to libc. "Imagine if everyone statically linked the stuff they worked on and wanted to easily backup" -- everything would be statically linked. In terms of distribution purposes, well, I think providing just one large .tar.gz archive per platform is ideal, and one .msi for Windows, and a small number of .deb and .rpm files, like just x86 and AMD64. Arguing about all the subsets has been very wasteful. I don't want to add supermin and supermin+cm3cg to the debate. Meanwhile what we are going to have is probably Olaf's package breakdown. > "Moveable around" is probably good, but if a chunk of compiler > infrastructure included in any program reading those variables is price > - I think it's good point to reconsider goals and ways. Given how broken it was before, I don't see changing it back. I realize I've foisted "the compiler" on you, and there's a larger issue as to the finding of cm3.cfg by the executable. What about something like: cm3 -print-variable INSTALL_ROOT cm3 -print-variable HOST or for that matter: echo print(HOST)> fo o.quake cm3 -eval foo.quake or echo print(HOST) | cm3 -eval foo.quake Better or worse? Heck, you could just: type cm3 and compute the rest yourself. or you know the usual SearchPath function... - Jay ---------------------------------------- > From: dragisha at m3w.org > To: jay.krell at cornell.edu > Date: Mon, 3 Aug 2009 10:55:48 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] More MxConfig > > New auto-configuring cm3.cfg stuff is all ok. Great! > > I don't see importance of "moveable around" in that. Only "no need for > cminstall and markers". "moveable around" is good when building from > source using some kind of cm3-min. > > While at that, cm3-supermin with only cm3 binary and config files > (probably cm3cg) would be supersmart feature. I am curently using > cm3-min as a bootstraping device, and first thing I do is making libm3 > and m3core over from supplied source. > > "Moveable around" is probably good, but if a chunk of compiler > infrastructure included in any program reading those variables is price > - I think it's good point to reconsider goals and ways. > > On Mon, 2009-08-03 at 08:42 +0000, Jay K wrote: >> Do you want to be able to move your cm3 install around, without >> editing the config file? >> You know, "be relocatable without any fixup code"? >> That is the big question. That is what MxConfig buys. >> These "variables" are computed, by running quake code. >> They are in fact known at install time, unless you later move the >> install around, >> and require something (cminstall) to modify the config files at >> install time. >> If nobody cares about moving installs around without invalidating >> their config file, >> we could put it back to a bunch of string constants. And we'd have >> to put back >> the markers that trigger cminstall to replace stuff. > -- > Dragi?a Duri? > From wagner at elegosoft.com Mon Aug 3 12:30:54 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 03 Aug 2009 12:30:54 +0200 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: References: <4A763446.1E75.00D7.1@scires.com> Message-ID: <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> It was a specific request from the people building platform specific installation packages that config files reside and are found in the `usual' locations on their system and not somewhere beneath cm3. Place don't change that unless there is no objection from anyone on m3devel. Olaf Quoting Jay K : > Sorry about #1 Randy, my mistake. > > > Sitting in the bin directory...seems a little wierd, eh? > What source are you going to build sitting there? > I guess um some custom quake code?? > Good enough if empty is instead just "."? > > This falls out of the fact that cm3 actually probes all over the > place for the cm3.cfg file and the first place it looks in is the > current directory. > > > Another good option I think would be just to remove that probe. > It looks in way too many places. > > > Here is the current code. I think it is gross. > Too much probing make things quite ambiguous. > > > PROCEDURE FindConfig () = > (* LL = mu *) > VAR txt: TEXT; > BEGIN > IF (found) THEN RETURN END; > > (* try the current directory *) > IF TryConfig (Filename) THEN RETURN END; > > (* try the immediate source directory *) > IF TryConfig ("src", Filename) THEN RETURN END; > > (* try the sibling source directory *) > IF TryConfig ("..", "src", Filename) THEN RETURN END; > > (* try the M3CONFIG environment variable *) > txt := QMachine.GetEnv (NIL, "M3CONFIG"); > IF (txt # NIL) THEN > IF TryConfig (txt) THEN RETURN END; > IF TryConfig (txt, Filename) THEN RETURN END; > END; > > (* try the directory containing the current executable *) > txt := Pathname.Prefix (Params.Get (0)); > > IF Text.Length (txt)> 0 THEN > IF TryConfig (txt, Filename) THEN RETURN END; > END; > > (* try the directories named by the PATH environment variable. *) > txt := Env.Get ("PATH"); > FindConfigInPath (txt); > > IF found THEN RETURN END; > > (* try the etc directories *) > IF TryConfig("/usr/local/cm3/etc", Filename) THEN RETURN END; > IF TryConfig("/usr/cm3/etc", Filename) THEN RETURN END; > IF TryConfig("/cm3/etc", Filename) THEN RETURN END; > IF TryConfig("/usr/contrib/etc", Filename) THEN RETURN END; > IF TryConfig("/usr/local/etc", Filename) THEN RETURN END; > IF TryConfig("/usr/etc", Filename) THEN RETURN END; > IF TryConfig("/opt/etc", Filename) THEN RETURN END; > IF TryConfig("/sw/etc", Filename) THEN RETURN END; > IF TryConfig("/etc", Filename) THEN RETURN END; > > (* oh well, make sure we don't try this silly exercise again... *) > config := NIL; > found := TRUE; > END FindConfig; > > > I propose..roughly roughly, we make it like this instead: > > > PROCEDURE FindConfig () = > (* LL = mu *) > VAR txt: TEXT; > BEGIN > IF (found) THEN RETURN END; > > (* try the M3CONFIG environment variable *) > txt := QMachine.GetEnv (NIL, "M3CONFIG"); > IF (txt # NIL) THEN > IF TryConfig (txt) THEN RETURN END; > IF TryConfig (txt, Filename) THEN RETURN END; > END; > > (* try the directory containing the current executable *) > txt := Pathname.Prefix (Params.Get (0)); > IF Text.Length (txt)> 0 THEN > IF TryConfig (txt, Filename) THEN RETURN END; > END; > > (* oh well, make sure we don't try this silly exercise again... *) > config := NIL; > found := TRUE; > END FindConfig; > > > or, if people really like it looking all over the place, fixing the > case of it being in the current working directory is probably like > this: > > > (* try the current directory *) > < IF TryConfig (Filename) THEN RETURN END; >> IF TryConfig (".", Filename) THEN RETURN END; > > > - Jay > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: rcoleburn at scires.com >> Date: Sun, 2 Aug 2009 23:42:17 -0700 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] problems with cm3.cfg and MxConfig >> >> Host, hm, I think probably my mistake. It is defined by cm3 but not >> all m3quake users. Path() should be the directory containing the file >> with the call. >> >> - Jay (phone) >> >> On Aug 2, 2009, at 9:52 PM, "Randy Coleburn" >> wrote: >> >>> I have been working on the problem of cm3ide not getting the >>> BUILD_DIR from cm3.cfg. I've run across some perplexing test results. >>> >>> MxConfig.Get("BUILD_DIR") is returning NIL on Windows XP & Vista. >>> I've tracked it down a bit further. There seem to be two issues >>> that must be fixed to solve this problem: >>> >>> 1. HOST does not seem to be defined. In particular my "C:\cm3\bin >>> \cm3.cfg" file appears as follows (this is the file Jay recommended): >>> INSTALL_ROOT = path() & "/.." >>> include (path() & "/config/" & HOST) >>> >>> Is HOST a variable? Or, was I supposed to replace it by "NT386"? >>> If the latter, my bad on this one--I took Jay's message literally. >>> >>> 2. path() does not appear to always yield the path to the bin >>> folder. In particular, it seems to work fine unless you invoke the >>> program when the current directory is actually set to the bin >>> folder, in which case path() seems to return the empty string. >>> >>> So, if ?%=C:\, and I run cm3ide, path() returns "C:\cm3\bin" as it s >>> hould. >>> But, if ?%=C:\cm3\bin, and I run cm3ide, path() returns "". >>> >>> So in the latter case, the include statement winds up trying to pull >>> a file from the wrong place, e.g. "/config/NT386" rather than "C: >>> \cm3\bin/config/NT386" >>> >>> Regards, >>> Randy Coleburn -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Mon Aug 3 13:14:45 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 03 Aug 2009 13:14:45 +0200 Subject: [M3devel] some cvs errors? In-Reply-To: References: Message-ID: <20090803131445.d5u1i1vaf484kg4s@mail.elegosoft.com> Quoting Jay K : > "/tmp/cvsUsaGYO" 61 lines, 1835 characters > /usr/cvs/cm3/m3-sys/m3cc/src/m3makefile,v <-- src/m3makefile > new revision: 1.111.2.4; previous revision: 1.111.2.3 > Cannot Open data file (cwd: /usr/local/tinderbox/bonsai; > data/temp.8776): Bad fi > > ? PKGS > /usr/cvs/cm3/scripts/find-packages.sh,v <-- find-packages.sh > new revision: 1.9.2.1; previous revision: 1.9 > /usr/cvs/cm3/scripts/find-src-dirs.sh,v <-- find-src-dirs.sh > new revision: 1.2.2.1; previous revision: 1.2 > /usr/cvs/cm3/scripts/list-pkg-dirs.sh,v <-- list-pkg-dirs.sh > new revision: 1.2.2.1; previous revision: 1.2 > /usr/cvs/cm3/scripts/make-dist.sh,v <-- make-dist.sh > new revision: 1.26.2.5; previous revision: 1.26.2.4 > cvs [commit aborted]: cannot rename file .new.make-dist.sh to > make-dist.sh: Permission denied > > > ? > > I think the commits made it. What were these? Do we need to investigate them? Or is everything OK now? Still trying to catch up with all my mails, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Mon Aug 3 13:21:58 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 03 Aug 2009 13:21:58 +0200 Subject: [M3devel] assembly goes to C compiler? In-Reply-To: References: Message-ID: <20090803132158.walcuy2s00wck04g@mail.elegosoft.com> Quoting Jay K : > Does this surprising anyone else: > > PROCEDURE CompileS (s: State; u: M3Unit.T) = > ... > ELSIF (u.kind = UK.S) THEN > RunCC (s, UnitPath (u), u.object, u.debug, u.optimize); Indeed! I must say that I was not aware of it. Im not sure if it is an oversight, a hack, or an intended feature. In the last case we should eliminate the assembly methods from the config files. What happens if we run the quake assembly method instead? Does that break lots of systems? > I kept modifying SYSTEM_ASM thinking it would affect how > RTMachineASM.s is assembled, > but it doesn't. I actually was thinking it might be nice to have two > assembly functions, > one for the output of m3cg, one for user written code. So, we do in fact have > two functions, but one is the function for compiling C!. I'd want a > third function, ideally. > > I'll leave this alone and just special case RTMachineASM.s in the > config file, if that works out. > > That is, I'll try a very targeted slighly inelegant change, goal being > to assemble this particular file with /usr/ccs/bin/as instead of the > C compiler, > on SOLgnu only. That doesn't sound very nice. We should really investigate why RunCC is used even for assembly code. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Mon Aug 3 13:26:28 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 03 Aug 2009 13:26:28 +0200 Subject: [M3devel] the SOLgnu alignment problem finally understood In-Reply-To: References: Message-ID: <20090803132628.krcbd41hy8ggs8s8@mail.elegosoft.com> We had similar problems before with -g. CM3 never supported dwarf debugging format, just stabs. I think we changed all -g occurences in the config files to -gstabs some years ago. It sounds like a small fix in the config files after all, correct? At least for this RC? Olaf Quoting Jay K : > > Here finally is a small example of the SOLgnu problem I've been > looking at it. > > > It is specific to using /usr/sfw/bin/gcc -g to asssemble. > No problem without -g, no problem with /usr/bin/cc, no problem with > whatever I built in /usr/local/bin/gcc, no problem if you assemble > with anything else and then link with /usr/sfw/bin/gcc -g. > > > -bash-3.00$ cat 4.c asm.s > > 4.c > void Asm(void); > #include > > int main() > { > Asm(); > printf("\n"); > return 0; > } > > asm.s > > .section ".text",#alloc,#execinstr > .align 4 > .global Asm > .type Asm,#function > Asm: > retl > nop > .size Asm, (.-Asm) > > > Not all possibilities shown here: > > > -bash-3.00$ /usr/local/bin/gcc -g asm.s 4.c > ok > > > -bash-3.00$ /usr/sfw/bin/gcc -g asm.s 4.c > ld: fatal: relocation error: R_SPARC_32: file /var/tmp//ccICgvny.o: > symbol : offset 0xfeed139e is non-aligned > ld: fatal: relocation error: R_SPARC_32: file /var/tmp//ccICgvny.o: > symbol : offset 0xfeed14c2 is non-aligned > ld: fatal: relocation error: R_SPARC_32: file /var/tmp//ccICgvny.o: > symbol : offset 0xfeed15f6 is non-aligned > collect2: ld returned 1 exit status > > > -bash-3.00$ /usr/bin/cc -g asm.s 4.c > asm.s: > 4.c: > ok > > -bash-3.00$ /usr/bin/cc asm.s 4.c > asm.s: > 4.c: > ok > > > -bash-3.00$ /usr/sfw/bin/gcc asm.s 4.c > ok > > > -bash-3.00$ /usr/local/bin/gcc asm.s 4.c > ok > > > -bash-3.00$ /usr/sfw/bin/gcc -g -c asm.s > ok but haven't linked yet, input to later steps > > > -bash-3.00$ /usr/bin/cc asm.o 4.c > ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x > ff10148e is non-aligned > ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x > ff1014ca is non-aligned > ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x > ff1015be is non-aligned > > > -bash-3.00$ /usr/local/bin/gcc asm.o 4.c > ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x > feee1213 is non-aligned > ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x > feee122a is non-aligned > ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x > feee122e is non-aligned > ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x > feee1232 is non-aligned > ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x > feee126e is non-aligned > collect2: ld returned 1 exit status > > > > -bash-3.00$ /usr/local/bin/gcc -g -c asm.s > ok, try linking with others > > > -bash-3.00$ /usr/bin/cc asm.o 4.c > ok > > > > -bash-3.00$ /usr/sfw/bin/gcc asm.o 4.c > ok > > > Actually even -gstabs or -gstabs+ instead of -g make it work. > -g resolves to -gdwarf2. > > > - Jay -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Mon Aug 3 15:10:48 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 3 Aug 2009 09:10:48 -0400 Subject: [M3devel] assembly goes to C compiler? In-Reply-To: <20090803132158.walcuy2s00wck04g@mail.elegosoft.com> References: <20090803132158.walcuy2s00wck04g@mail.elegosoft.com> Message-ID: <20090803131048.GB24864@topoi.pooq.com> On Mon, Aug 03, 2009 at 01:21:58PM +0200, Olaf Wagner wrote: > > That doesn't sound very nice. We should really investigate why > RunCC is used even for assembly code. Just a guess -- could using a C compiler give the assembler code access to the X library? - hendrik From hosking at cs.purdue.edu Mon Aug 3 15:54:19 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 3 Aug 2009 09:54:19 -0400 Subject: [M3devel] cm3 vs. m3quake In-Reply-To: References: Message-ID: Prefer not to pollute. On 3 Aug 2009, at 03:38, Jay K wrote: > > cm3 defines some things, like: > > C:\dev2\cm3.2\m3-sys\cm3\src\Main.m3(54): Quake.Define(mach, > "TARGET", MxConfig.HOST); > C:\dev2\cm3.2\m3-sys\cm3\src\Main.m3(55): Quake.Define(mach, > "OS_TYPE", MxConfig.HOST_OS_TYPE); > C:\dev2\cm3.2\m3-sys\cm3\src\Main.m3(61): Quake.Define(mach, > "WORD_SIZE", MxConfig.HOST_WORD_SIZE); > C:\dev2\cm3.2\m3-sys\cm3\src\Main.m3(66): Quake.Define(mach, > "HOST", MxConfig.HOST); > C:\dev2\cm3.2\m3-sys\cm3\src\Main.m3(67): Quake.Define(mach, > "HOST_OS_TYPE", MxConfig.HOST_OS_TYPE); > C:\dev2\cm3.2\m3-sys\cm3\src\Main.m3(68): Quake.Define(mach, > "HOST_GNU_MAKE", Version.GNUMake); > > > all the other m3quake users don't get this. > > Would it be too polluting to move this to m3quake, thereby making > m3quake just not a generic scripting language, but slightly specific > to building Modula-3 stuff? > > I'll hold off for now. > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Aug 3 15:57:19 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 3 Aug 2009 09:57:19 -0400 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> Message-ID: I don't think we did agree that config files reside other than in the cm3 hierarchy. On 3 Aug 2009, at 06:30, Olaf Wagner wrote: > It was a specific request from the people building platform specific > installation packages that config files reside and are found in the > `usual' locations on their system and not somewhere beneath cm3. > > Place don't change that unless there is no objection from anyone > on m3devel. > > Olaf > > Quoting Jay K : > >> Sorry about #1 Randy, my mistake. >> >> >> Sitting in the bin directory...seems a little wierd, eh? >> What source are you going to build sitting there? >> I guess um some custom quake code?? >> Good enough if empty is instead just "."? >> >> This falls out of the fact that cm3 actually probes all over the >> place for the cm3.cfg file and the first place it looks in is the >> current directory. >> >> >> Another good option I think would be just to remove that probe. >> It looks in way too many places. >> >> >> Here is the current code. I think it is gross. >> Too much probing make things quite ambiguous. >> >> >> PROCEDURE FindConfig () = >> (* LL = mu *) >> VAR txt: TEXT; >> BEGIN >> IF (found) THEN RETURN END; >> >> (* try the current directory *) >> IF TryConfig (Filename) THEN RETURN END; >> >> (* try the immediate source directory *) >> IF TryConfig ("src", Filename) THEN RETURN END; >> >> (* try the sibling source directory *) >> IF TryConfig ("..", "src", Filename) THEN RETURN END; >> >> (* try the M3CONFIG environment variable *) >> txt := QMachine.GetEnv (NIL, "M3CONFIG"); >> IF (txt # NIL) THEN >> IF TryConfig (txt) THEN RETURN END; >> IF TryConfig (txt, Filename) THEN RETURN END; >> END; >> >> (* try the directory containing the current executable *) >> txt := Pathname.Prefix (Params.Get (0)); >> >> IF Text.Length (txt)> 0 THEN >> IF TryConfig (txt, Filename) THEN RETURN END; >> END; >> >> (* try the directories named by the PATH environment variable. *) >> txt := Env.Get ("PATH"); >> FindConfigInPath (txt); >> >> IF found THEN RETURN END; >> >> (* try the etc directories *) >> IF TryConfig("/usr/local/cm3/etc", Filename) THEN RETURN END; >> IF TryConfig("/usr/cm3/etc", Filename) THEN RETURN END; >> IF TryConfig("/cm3/etc", Filename) THEN RETURN END; >> IF TryConfig("/usr/contrib/etc", Filename) THEN RETURN END; >> IF TryConfig("/usr/local/etc", Filename) THEN RETURN END; >> IF TryConfig("/usr/etc", Filename) THEN RETURN END; >> IF TryConfig("/opt/etc", Filename) THEN RETURN END; >> IF TryConfig("/sw/etc", Filename) THEN RETURN END; >> IF TryConfig("/etc", Filename) THEN RETURN END; >> >> (* oh well, make sure we don't try this silly exercise again... *) >> config := NIL; >> found := TRUE; >> END FindConfig; >> >> >> I propose..roughly roughly, we make it like this instead: >> >> >> PROCEDURE FindConfig () = >> (* LL = mu *) >> VAR txt: TEXT; >> BEGIN >> IF (found) THEN RETURN END; >> >> (* try the M3CONFIG environment variable *) >> txt := QMachine.GetEnv (NIL, "M3CONFIG"); >> IF (txt # NIL) THEN >> IF TryConfig (txt) THEN RETURN END; >> IF TryConfig (txt, Filename) THEN RETURN END; >> END; >> >> (* try the directory containing the current executable *) >> txt := Pathname.Prefix (Params.Get (0)); >> IF Text.Length (txt)> 0 THEN >> IF TryConfig (txt, Filename) THEN RETURN END; >> END; >> >> (* oh well, make sure we don't try this silly exercise again... *) >> config := NIL; >> found := TRUE; >> END FindConfig; >> >> >> or, if people really like it looking all over the place, fixing >> the case of it being in the current working directory is probably >> like this: >> >> >> (* try the current directory *) >> < IF TryConfig (Filename) THEN RETURN END; >>> IF TryConfig (".", Filename) THEN RETURN END; >> >> >> - Jay >> >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: rcoleburn at scires.com >>> Date: Sun, 2 Aug 2009 23:42:17 -0700 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] problems with cm3.cfg and MxConfig >>> >>> Host, hm, I think probably my mistake. It is defined by cm3 but not >>> all m3quake users. Path() should be the directory containing the >>> file >>> with the call. >>> >>> - Jay (phone) >>> >>> On Aug 2, 2009, at 9:52 PM, "Randy Coleburn" >>> wrote: >>> >>>> I have been working on the problem of cm3ide not getting the >>>> BUILD_DIR from cm3.cfg. I've run across some perplexing test >>>> results. >>>> >>>> MxConfig.Get("BUILD_DIR") is returning NIL on Windows XP & Vista. >>>> I've tracked it down a bit further. There seem to be two issues >>>> that must be fixed to solve this problem: >>>> >>>> 1. HOST does not seem to be defined. In particular my "C:\cm3\bin >>>> \cm3.cfg" file appears as follows (this is the file Jay >>>> recommended): >>>> INSTALL_ROOT = path() & "/.." >>>> include (path() & "/config/" & HOST) >>>> >>>> Is HOST a variable? Or, was I supposed to replace it by "NT386"? >>>> If the latter, my bad on this one--I took Jay's message literally. >>>> >>>> 2. path() does not appear to always yield the path to the bin >>>> folder. In particular, it seems to work fine unless you invoke the >>>> program when the current directory is actually set to the bin >>>> folder, in which case path() seems to return the empty string. >>>> >>>> So, if ?%=C:\, and I run cm3ide, path() returns "C:\cm3\bin" as >>>> it s >>>> hould. >>>> But, if ?%=C:\cm3\bin, and I run cm3ide, path() returns "". >>>> >>>> So in the latter case, the include statement winds up trying to >>>> pull >>>> a file from the wrong place, e.g. "/config/NT386" rather than "C: >>>> \cm3\bin/config/NT386" >>>> >>>> Regards, >>>> Randy Coleburn > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Aug 3 16:02:12 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 3 Aug 2009 10:02:12 -0400 Subject: [M3devel] assembly goes to C compiler? In-Reply-To: <20090803131048.GB24864@topoi.pooq.com> References: <20090803132158.walcuy2s00wck04g@mail.elegosoft.com> <20090803131048.GB24864@topoi.pooq.com> Message-ID: <4AD30F1F-90E6-48F8-B93C-6889E8D2BAF4@cs.purdue.edu> Using the C compiler allows the assembly to have preprocessor directives. On 3 Aug 2009, at 09:10, hendrik at topoi.pooq.com wrote: > On Mon, Aug 03, 2009 at 01:21:58PM +0200, Olaf Wagner wrote: >> >> That doesn't sound very nice. We should really investigate why >> RunCC is used even for assembly code. > > Just a guess -- could using a C compiler give the assembler code > access > to the X library? > > - hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Aug 3 16:36:25 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 03 Aug 2009 16:36:25 +0200 Subject: [M3devel] assembly goes to C compiler? In-Reply-To: <4AD30F1F-90E6-48F8-B93C-6889E8D2BAF4@cs.purdue.edu> References: <20090803132158.walcuy2s00wck04g@mail.elegosoft.com> <20090803131048.GB24864@topoi.pooq.com> <4AD30F1F-90E6-48F8-B93C-6889E8D2BAF4@cs.purdue.edu> Message-ID: <20090803163625.qm007v2pfog8s8sg@mail.elegosoft.com> Quoting Tony Hosking : > Using the C compiler allows the assembly to have preprocessor directives. So you think it's a feature. Why do we have the assemble methods in the config file then? Or are they just legacy? %---------------------------------------------------------------- assembler --- % "assemble" is called to assemble .s or .asm files. Note that this function % is only called if your program or library explicitly includes assembly source % code, the system distributed by Critical Mass does not. proc assemble(source, object) is if defined("configure_assembler") configure_assembler() end return try_exec("@" & SYSTEM_ASM, source, "-o", object) end Probably a remnant of DEC SRC M3? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Mon Aug 3 16:42:21 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 03 Aug 2009 16:42:21 +0200 Subject: [M3devel] cm3.cfg et all, loc Message-ID: <1249310541.28197.746.camel@faramir.m3w.org> Excuse me for being a Martian here, esp on this topic, but I must agree, and loudly, with few voices on cm3.cfg location. In non-Windows world, /etc/ is natural place for anything config. Would it, or would it not be editable is another concern, mostly not important - if it's so absolutely uneditable then let it be m3bundled. It's up to packager to decide, of course... But I think everything will be much easier (esp this path() bussiness) if we decide to put these files somewhere standard. In Linux case, /etc. And included files in /etc/cm3/. MxConfig will have less problems to work as advertised, if nothing else :). -- Dragi?a Duri? From wagner at elegosoft.com Mon Aug 3 17:25:37 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 03 Aug 2009 17:25:37 +0200 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> Message-ID: <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> Quoting Tony Hosking : > I don't think we did agree that config files reside other than in the > cm3 hierarchy. I may have been too quick to extend the search path some weeks ago. I'm really undecided myself. I guess the score currently is +2 for cm3/ +1 /etc :-) But we should perhaps really come to an agreement that is acceptable for all here. Olaf > On 3 Aug 2009, at 06:30, Olaf Wagner wrote: > >> It was a specific request from the people building platform specific >> installation packages that config files reside and are found in the >> `usual' locations on their system and not somewhere beneath cm3. >> >> Place don't change that unless there is no objection from anyone >> on m3devel. >> >> Olaf >> >> Quoting Jay K : >> >>> Sorry about #1 Randy, my mistake. >>> >>> >>> Sitting in the bin directory...seems a little wierd, eh? >>> What source are you going to build sitting there? >>> I guess um some custom quake code?? >>> Good enough if empty is instead just "."? >>> >>> This falls out of the fact that cm3 actually probes all over the >>> place for the cm3.cfg file and the first place it looks in is the >>> current directory. >>> >>> >>> Another good option I think would be just to remove that probe. >>> It looks in way too many places. >>> >>> >>> Here is the current code. I think it is gross. >>> Too much probing make things quite ambiguous. >>> >>> >>> PROCEDURE FindConfig () = >>> (* LL = mu *) >>> VAR txt: TEXT; >>> BEGIN >>> IF (found) THEN RETURN END; >>> >>> (* try the current directory *) >>> IF TryConfig (Filename) THEN RETURN END; >>> >>> (* try the immediate source directory *) >>> IF TryConfig ("src", Filename) THEN RETURN END; >>> >>> (* try the sibling source directory *) >>> IF TryConfig ("..", "src", Filename) THEN RETURN END; >>> >>> (* try the M3CONFIG environment variable *) >>> txt := QMachine.GetEnv (NIL, "M3CONFIG"); >>> IF (txt # NIL) THEN >>> IF TryConfig (txt) THEN RETURN END; >>> IF TryConfig (txt, Filename) THEN RETURN END; >>> END; >>> >>> (* try the directory containing the current executable *) >>> txt := Pathname.Prefix (Params.Get (0)); >>> >>> IF Text.Length (txt)> 0 THEN >>> IF TryConfig (txt, Filename) THEN RETURN END; >>> END; >>> >>> (* try the directories named by the PATH environment variable. *) >>> txt := Env.Get ("PATH"); >>> FindConfigInPath (txt); >>> >>> IF found THEN RETURN END; >>> >>> (* try the etc directories *) >>> IF TryConfig("/usr/local/cm3/etc", Filename) THEN RETURN END; >>> IF TryConfig("/usr/cm3/etc", Filename) THEN RETURN END; >>> IF TryConfig("/cm3/etc", Filename) THEN RETURN END; >>> IF TryConfig("/usr/contrib/etc", Filename) THEN RETURN END; >>> IF TryConfig("/usr/local/etc", Filename) THEN RETURN END; >>> IF TryConfig("/usr/etc", Filename) THEN RETURN END; >>> IF TryConfig("/opt/etc", Filename) THEN RETURN END; >>> IF TryConfig("/sw/etc", Filename) THEN RETURN END; >>> IF TryConfig("/etc", Filename) THEN RETURN END; >>> >>> (* oh well, make sure we don't try this silly exercise again... *) >>> config := NIL; >>> found := TRUE; >>> END FindConfig; >>> >>> >>> I propose..roughly roughly, we make it like this instead: >>> >>> >>> PROCEDURE FindConfig () = >>> (* LL = mu *) >>> VAR txt: TEXT; >>> BEGIN >>> IF (found) THEN RETURN END; >>> >>> (* try the M3CONFIG environment variable *) >>> txt := QMachine.GetEnv (NIL, "M3CONFIG"); >>> IF (txt # NIL) THEN >>> IF TryConfig (txt) THEN RETURN END; >>> IF TryConfig (txt, Filename) THEN RETURN END; >>> END; >>> >>> (* try the directory containing the current executable *) >>> txt := Pathname.Prefix (Params.Get (0)); >>> IF Text.Length (txt)> 0 THEN >>> IF TryConfig (txt, Filename) THEN RETURN END; >>> END; >>> >>> (* oh well, make sure we don't try this silly exercise again... *) >>> config := NIL; >>> found := TRUE; >>> END FindConfig; >>> >>> >>> or, if people really like it looking all over the place, fixing >>> the case of it being in the current working directory is probably >>> like this: >>> >>> >>> (* try the current directory *) >>> < IF TryConfig (Filename) THEN RETURN END; >>>> IF TryConfig (".", Filename) THEN RETURN END; >>> >>> >>> - Jay >>> >>> >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: rcoleburn at scires.com >>>> Date: Sun, 2 Aug 2009 23:42:17 -0700 >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] problems with cm3.cfg and MxConfig >>>> >>>> Host, hm, I think probably my mistake. It is defined by cm3 but not >>>> all m3quake users. Path() should be the directory containing the file >>>> with the call. >>>> >>>> - Jay (phone) >>>> >>>> On Aug 2, 2009, at 9:52 PM, "Randy Coleburn" >>>> wrote: >>>> >>>>> I have been working on the problem of cm3ide not getting the >>>>> BUILD_DIR from cm3.cfg. I've run across some perplexing test results. >>>>> >>>>> MxConfig.Get("BUILD_DIR") is returning NIL on Windows XP & Vista. >>>>> I've tracked it down a bit further. There seem to be two issues >>>>> that must be fixed to solve this problem: >>>>> >>>>> 1. HOST does not seem to be defined. In particular my "C:\cm3\bin >>>>> \cm3.cfg" file appears as follows (this is the file Jay recommended): >>>>> INSTALL_ROOT = path() & "/.." >>>>> include (path() & "/config/" & HOST) >>>>> >>>>> Is HOST a variable? Or, was I supposed to replace it by "NT386"? >>>>> If the latter, my bad on this one--I took Jay's message literally. >>>>> >>>>> 2. path() does not appear to always yield the path to the bin >>>>> folder. In particular, it seems to work fine unless you invoke the >>>>> program when the current directory is actually set to the bin >>>>> folder, in which case path() seems to return the empty string. >>>>> >>>>> So, if ?%=C:\, and I run cm3ide, path() returns "C:\cm3\bin" as it s >>>>> hould. >>>>> But, if ?%=C:\cm3\bin, and I run cm3ide, path() returns "". >>>>> >>>>> So in the latter case, the include statement winds up trying to pull >>>>> a file from the wrong place, e.g. "/config/NT386" rather than "C: >>>>> \cm3\bin/config/NT386" >>>>> >>>>> Regards, >>>>> Randy Coleburn >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >> 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rcoleburn at scires.com Mon Aug 3 17:27:44 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 03 Aug 2009 11:27:44 -0400 Subject: [M3devel] problems with cm3.cfg and MxConfig In-Reply-To: References: <4A763446.1E75.00D7.1@scires.com> Message-ID: <4A76C915.1E75.00D7.1@scires.com> Jay: No problem. I think you are trying to make it more flexible, and that is good. I just ran into a problem with cm3ide. The shortcut I use to launch cm3ide causes the current dir to be the "bin" folder. So, using your new cm3.cfg, I was always having a problem with (path() & "/config/"), since it would be trying to find "config" at the root of the file system when path() returned the empty string. Since "/config" wasn't found, none of the other parts of your include file were ever processed, hence, BUILD_DIR would never be found. I gather that path() is supposed to return the path to the cm3.cfg file. If this is true, then returning "" is not really a path, so the function seems broken when cm3.cfg is in the current dir. Returning "." makes more sense for this case and would allow the rest of your cm3.cfg file to work I think, provided that HOST is defined or that it is replaced by the actual text. Regards, Randy >>> Jay K 8/3/2009 5:05 AM >>> Sorry about #1 Randy, my mistake. Sitting in the bin directory...seems a little wierd, eh? What source are you going to build sitting there? I guess um some custom quake code?? Good enough if empty is instead just "."? This falls out of the fact that cm3 actually probes all over the place for the cm3.cfg file and the first place it looks in is the current directory. Another good option I think would be just to remove that probe. It looks in way too many places. Here is the current code. I think it is gross. Too much probing make things quite ambiguous. PROCEDURE FindConfig () = (* LL = mu *) VAR txt: TEXT; BEGIN IF (found) THEN RETURN END; (* try the current directory *) IF TryConfig (Filename) THEN RETURN END; (* try the immediate source directory *) IF TryConfig ("src", Filename) THEN RETURN END; (* try the sibling source directory *) IF TryConfig ("..", "src", Filename) THEN RETURN END; (* try the M3CONFIG environment variable *) txt := QMachine.GetEnv (NIL, "M3CONFIG"); IF (txt # NIL) THEN IF TryConfig (txt) THEN RETURN END; IF TryConfig (txt, Filename) THEN RETURN END; END; (* try the directory containing the current executable *) txt := Pathname.Prefix (Params.Get (0)); IF Text.Length (txt)> 0 THEN IF TryConfig (txt, Filename) THEN RETURN END; END; (* try the directories named by the PATH environment variable. *) txt := Env.Get ("PATH"); FindConfigInPath (txt); IF found THEN RETURN END; (* try the etc directories *) IF TryConfig("/usr/local/cm3/etc", Filename) THEN RETURN END; IF TryConfig("/usr/cm3/etc", Filename) THEN RETURN END; IF TryConfig("/cm3/etc", Filename) THEN RETURN END; IF TryConfig("/usr/contrib/etc", Filename) THEN RETURN END; IF TryConfig("/usr/local/etc", Filename) THEN RETURN END; IF TryConfig("/usr/etc", Filename) THEN RETURN END; IF TryConfig("/opt/etc", Filename) THEN RETURN END; IF TryConfig("/sw/etc", Filename) THEN RETURN END; IF TryConfig("/etc", Filename) THEN RETURN END; (* oh well, make sure we don't try this silly exercise again... *) config := NIL; found := TRUE; END FindConfig; I propose..roughly roughly, we make it like this instead: PROCEDURE FindConfig () = (* LL = mu *) VAR txt: TEXT; BEGIN IF (found) THEN RETURN END; (* try the M3CONFIG environment variable *) txt := QMachine.GetEnv (NIL, "M3CONFIG"); IF (txt # NIL) THEN IF TryConfig (txt) THEN RETURN END; IF TryConfig (txt, Filename) THEN RETURN END; END; (* try the directory containing the current executable *) txt := Pathname.Prefix (Params.Get (0)); IF Text.Length (txt)> 0 THEN IF TryConfig (txt, Filename) THEN RETURN END; END; (* oh well, make sure we don't try this silly exercise again... *) config := NIL; found := TRUE; END FindConfig; or, if people really like it looking all over the place, fixing the case of it being in the current working directory is probably like this: (* try the current directory *) < IF TryConfig (Filename) THEN RETURN END; > IF TryConfig (".", Filename) THEN RETURN END; - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: rcoleburn at scires.com > Date: Sun, 2 Aug 2009 23:42:17 -0700 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] problems with cm3.cfg and MxConfig > > Host, hm, I think probably my mistake. It is defined by cm3 but not > all m3quake users. Path() should be the directory containing the file > with the call. > > - Jay (phone) > > On Aug 2, 2009, at 9:52 PM, "Randy Coleburn" > wrote: > >> I have been working on the problem of cm3ide not getting the >> BUILD_DIR from cm3.cfg. I've run across some perplexing test results. >> >> MxConfig.Get("BUILD_DIR") is returning NIL on Windows XP & Vista. >> I've tracked it down a bit further. There seem to be two issues >> that must be fixed to solve this problem: >> >> 1. HOST does not seem to be defined. In particular my "C:\cm3\bin >> \cm3.cfg" file appears as follows (this is the file Jay recommended): >> INSTALL_ROOT = path() & "/.." >> include (path() & "/config/" & HOST) >> >> Is HOST a variable? Or, was I supposed to replace it by "NT386"? >> If the latter, my bad on this one--I took Jay's message literally. >> >> 2. path() does not appear to always yield the path to the bin >> folder. In particular, it seems to work fine unless you invoke the >> program when the current directory is actually set to the bin >> folder, in which case path() seems to return the empty string. >> >> So, if ?%=C:\, and I run cm3ide, path() returns "C:\cm3\bin" as it s >> hould. >> But, if ?%=C:\cm3\bin, and I run cm3ide, path() returns "". >> >> So in the latter case, the include statement winds up trying to pull >> a file from the wrong place, e.g. "/config/NT386" rather than "C: >> \cm3\bin/config/NT386" >> >> Regards, >> Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Mon Aug 3 17:35:18 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 03 Aug 2009 11:35:18 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20090803093135.3F59DCC81B@birch.elegosoft.com> References: <20090803093135.3F59DCC81B@birch.elegosoft.com> Message-ID: <4A76CADA.1E75.00D7.1@scires.com> Jay: I agree that running cm3 from "bin" folder is not going to be productive; however, other programs (such as cm3ide) also use the quake stuff and they don't have this limitation. I think your change is a good one. I'll run some tests and see how cm3ide fares. Thanks. --Randy >>> Jay Krell 8/3/2009 11:31 AM >>> CVSROOT:/usr/cvs Changes by:jkrell at birch.09/08/03 11:31:35 Modified files: cm3/m3-sys/m3quake/src/: MxConfig.m3 Log message: use "." instead of empty string for path() when current working directory is the actual directory of cm3; not sure what good running cm3 here is, and we probe way too many places.. CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at darko.org Mon Aug 3 20:59:26 2009 From: lists at darko.org (Darko Volaric) Date: Mon, 3 Aug 2009 20:59:26 +0200 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> Message-ID: Putting it in /etc would mean that having different active versions of compiler would e a pain, which is useful when developing, debugging or trying out new versions of the compiler and when compilers are not self hosted, which will be the case for ARM_DARWIN. What's the benefit of having it /etc other than being "standard"? On 03/08/2009, at 5:25 PM, Olaf Wagner wrote: > Quoting Tony Hosking : > >> I don't think we did agree that config files reside other than in the >> cm3 hierarchy. > > I may have been too quick to extend the search path some weeks ago. > I'm really undecided myself. I guess the score currently is > +2 for cm3/ +1 /etc :-) > > But we should perhaps really come to an agreement that is acceptable > for all here. > > Olaf > >> On 3 Aug 2009, at 06:30, Olaf Wagner wrote: >> >>> It was a specific request from the people building platform specific >>> installation packages that config files reside and are found in the >>> `usual' locations on their system and not somewhere beneath cm3. >>> >>> Place don't change that unless there is no objection from anyone >>> on m3devel. >>> >>> Olaf >>> >>> Quoting Jay K : >>> >>>> Sorry about #1 Randy, my mistake. >>>> >>>> >>>> Sitting in the bin directory...seems a little wierd, eh? >>>> What source are you going to build sitting there? >>>> I guess um some custom quake code?? >>>> Good enough if empty is instead just "."? >>>> >>>> This falls out of the fact that cm3 actually probes all over >>>> the place for the cm3.cfg file and the first place it looks in >>>> is the current directory. >>>> >>>> >>>> Another good option I think would be just to remove that probe. >>>> It looks in way too many places. >>>> >>>> >>>> Here is the current code. I think it is gross. >>>> Too much probing make things quite ambiguous. >>>> >>>> >>>> PROCEDURE FindConfig () = >>>> (* LL = mu *) >>>> VAR txt: TEXT; >>>> BEGIN >>>> IF (found) THEN RETURN END; >>>> >>>> (* try the current directory *) >>>> IF TryConfig (Filename) THEN RETURN END; >>>> >>>> (* try the immediate source directory *) >>>> IF TryConfig ("src", Filename) THEN RETURN END; >>>> >>>> (* try the sibling source directory *) >>>> IF TryConfig ("..", "src", Filename) THEN RETURN END; >>>> >>>> (* try the M3CONFIG environment variable *) >>>> txt := QMachine.GetEnv (NIL, "M3CONFIG"); >>>> IF (txt # NIL) THEN >>>> IF TryConfig (txt) THEN RETURN END; >>>> IF TryConfig (txt, Filename) THEN RETURN END; >>>> END; >>>> >>>> (* try the directory containing the current executable *) >>>> txt := Pathname.Prefix (Params.Get (0)); >>>> >>>> IF Text.Length (txt)> 0 THEN >>>> IF TryConfig (txt, Filename) THEN RETURN END; >>>> END; >>>> >>>> (* try the directories named by the PATH environment variable. *) >>>> txt := Env.Get ("PATH"); >>>> FindConfigInPath (txt); >>>> >>>> IF found THEN RETURN END; >>>> >>>> (* try the etc directories *) >>>> IF TryConfig("/usr/local/cm3/etc", Filename) THEN RETURN END; >>>> IF TryConfig("/usr/cm3/etc", Filename) THEN RETURN END; >>>> IF TryConfig("/cm3/etc", Filename) THEN RETURN END; >>>> IF TryConfig("/usr/contrib/etc", Filename) THEN RETURN END; >>>> IF TryConfig("/usr/local/etc", Filename) THEN RETURN END; >>>> IF TryConfig("/usr/etc", Filename) THEN RETURN END; >>>> IF TryConfig("/opt/etc", Filename) THEN RETURN END; >>>> IF TryConfig("/sw/etc", Filename) THEN RETURN END; >>>> IF TryConfig("/etc", Filename) THEN RETURN END; >>>> >>>> (* oh well, make sure we don't try this silly exercise again... *) >>>> config := NIL; >>>> found := TRUE; >>>> END FindConfig; >>>> >>>> >>>> I propose..roughly roughly, we make it like this instead: >>>> >>>> >>>> PROCEDURE FindConfig () = >>>> (* LL = mu *) >>>> VAR txt: TEXT; >>>> BEGIN >>>> IF (found) THEN RETURN END; >>>> >>>> (* try the M3CONFIG environment variable *) >>>> txt := QMachine.GetEnv (NIL, "M3CONFIG"); >>>> IF (txt # NIL) THEN >>>> IF TryConfig (txt) THEN RETURN END; >>>> IF TryConfig (txt, Filename) THEN RETURN END; >>>> END; >>>> >>>> (* try the directory containing the current executable *) >>>> txt := Pathname.Prefix (Params.Get (0)); >>>> IF Text.Length (txt)> 0 THEN >>>> IF TryConfig (txt, Filename) THEN RETURN END; >>>> END; >>>> >>>> (* oh well, make sure we don't try this silly exercise again... *) >>>> config := NIL; >>>> found := TRUE; >>>> END FindConfig; >>>> >>>> >>>> or, if people really like it looking all over the place, fixing >>>> the case of it being in the current working directory is >>>> probably like this: >>>> >>>> >>>> (* try the current directory *) >>>> < IF TryConfig (Filename) THEN RETURN END; >>>>> IF TryConfig (".", Filename) THEN RETURN END; >>>> >>>> >>>> - Jay >>>> >>>> >>>> >>>> ---------------------------------------- >>>>> From: jay.krell at cornell.edu >>>>> To: rcoleburn at scires.com >>>>> Date: Sun, 2 Aug 2009 23:42:17 -0700 >>>>> CC: m3devel at elegosoft.com >>>>> Subject: Re: [M3devel] problems with cm3.cfg and MxConfig >>>>> >>>>> Host, hm, I think probably my mistake. It is defined by cm3 but >>>>> not >>>>> all m3quake users. Path() should be the directory containing >>>>> the file >>>>> with the call. >>>>> >>>>> - Jay (phone) >>>>> >>>>> On Aug 2, 2009, at 9:52 PM, "Randy Coleburn" >>>>> wrote: >>>>> >>>>>> I have been working on the problem of cm3ide not getting the >>>>>> BUILD_DIR from cm3.cfg. I've run across some perplexing test >>>>>> results. >>>>>> >>>>>> MxConfig.Get("BUILD_DIR") is returning NIL on Windows XP & Vista. >>>>>> I've tracked it down a bit further. There seem to be two issues >>>>>> that must be fixed to solve this problem: >>>>>> >>>>>> 1. HOST does not seem to be defined. In particular my "C:\cm3\bin >>>>>> \cm3.cfg" file appears as follows (this is the file Jay >>>>>> recommended): >>>>>> INSTALL_ROOT = path() & "/.." >>>>>> include (path() & "/config/" & HOST) >>>>>> >>>>>> Is HOST a variable? Or, was I supposed to replace it by "NT386"? >>>>>> If the latter, my bad on this one--I took Jay's message >>>>>> literally. >>>>>> >>>>>> 2. path() does not appear to always yield the path to the bin >>>>>> folder. In particular, it seems to work fine unless you invoke >>>>>> the >>>>>> program when the current directory is actually set to the bin >>>>>> folder, in which case path() seems to return the empty string. >>>>>> >>>>>> So, if ?%=C:\, and I run cm3ide, path() returns "C:\cm3\bin" >>>>>> as it s >>>>>> hould. >>>>>> But, if ?%=C:\cm3\bin, and I run cm3ide, path() returns "". >>>>>> >>>>>> So in the latter case, the include statement winds up trying >>>>>> to pull >>>>>> a file from the wrong place, e.g. "/config/NT386" rather than "C: >>>>>> \cm3\bin/config/NT386" >>>>>> >>>>>> Regards, >>>>>> Randy Coleburn >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>> Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>> 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>> Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From rcoleburn at scires.com Mon Aug 3 21:17:30 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 03 Aug 2009 15:17:30 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <4A76CADA.1E75.00D7.1@scires.com> References: <20090803093135.3F59DCC81B@birch.elegosoft.com> <4A76CADA.1E75.00D7.1@scires.com> Message-ID: <4A76FEED.1E75.00D7.1@scires.com> Jay: Your change to MxConfig.m3 seems to work fine for cm3ide, provided that I replace HOST by "NT386" in my cm3.cfg is as follows: INSTALL_ROOT = path() & "/.." include (path() & "/config/NT386") Thank you! Can we get your revised MxConfig.m3 put into the RC2 branch? Regards, Randy >>> "Randy Coleburn" 8/3/2009 11:35 AM >>> Jay: I agree that running cm3 from "bin" folder is not going to be productive; however, other programs (such as cm3ide) also use the quake stuff and they don't have this limitation. I think your change is a good one. I'll run some tests and see how cm3ide fares. Thanks. --Randy >>> Jay Krell 8/3/2009 11:31 AM >>> CVSROOT:/usr/cvs Changes by:jkrell at birch.09/08/03 11:31:35 Modified files: cm3/m3-sys/m3quake/src/: MxConfig.m3 Log message: use "." instead of empty string for path() when current working directory is the actual directory of cm3; not sure what good running cm3 here is, and we probe way too many places.. CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Mon Aug 3 22:10:02 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 03 Aug 2009 22:10:02 +0200 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> Message-ID: <1249330202.28197.748.camel@faramir.m3w.org> One day when we start thinking about configurations other than "developing, debugging or trying out new versions of the compiler" we will be ready for people other than m3devel readership. On Mon, 2009-08-03 at 20:59 +0200, Darko Volaric wrote: > Putting it in /etc would mean that having different active versions of > compiler would e a pain, which is useful when developing, debugging or > trying out new versions of the compiler and when compilers are not > self hosted, which will be the case for ARM_DARWIN. > > What's the benefit of having it /etc other than being "standard"? > > > On 03/08/2009, at 5:25 PM, Olaf Wagner wrote: > > > Quoting Tony Hosking : > > > >> I don't think we did agree that config files reside other than in the > >> cm3 hierarchy. > > > > I may have been too quick to extend the search path some weeks ago. > > I'm really undecided myself. I guess the score currently is > > +2 for cm3/ +1 /etc :-) > > > > But we should perhaps really come to an agreement that is acceptable > > for all here. > > > > Olaf > > > >> On 3 Aug 2009, at 06:30, Olaf Wagner wrote: > >> > >>> It was a specific request from the people building platform specific > >>> installation packages that config files reside and are found in the > >>> `usual' locations on their system and not somewhere beneath cm3. > >>> > >>> Place don't change that unless there is no objection from anyone > >>> on m3devel. > >>> > >>> Olaf > >>> > >>> Quoting Jay K : > >>> > >>>> Sorry about #1 Randy, my mistake. > >>>> > >>>> > >>>> Sitting in the bin directory...seems a little wierd, eh? > >>>> What source are you going to build sitting there? > >>>> I guess um some custom quake code?? > >>>> Good enough if empty is instead just "."? > >>>> > >>>> This falls out of the fact that cm3 actually probes all over > >>>> the place for the cm3.cfg file and the first place it looks in > >>>> is the current directory. > >>>> > >>>> > >>>> Another good option I think would be just to remove that probe. > >>>> It looks in way too many places. > >>>> > >>>> > >>>> Here is the current code. I think it is gross. > >>>> Too much probing make things quite ambiguous. > >>>> > >>>> > >>>> PROCEDURE FindConfig () = > >>>> (* LL = mu *) > >>>> VAR txt: TEXT; > >>>> BEGIN > >>>> IF (found) THEN RETURN END; > >>>> > >>>> (* try the current directory *) > >>>> IF TryConfig (Filename) THEN RETURN END; > >>>> > >>>> (* try the immediate source directory *) > >>>> IF TryConfig ("src", Filename) THEN RETURN END; > >>>> > >>>> (* try the sibling source directory *) > >>>> IF TryConfig ("..", "src", Filename) THEN RETURN END; > >>>> > >>>> (* try the M3CONFIG environment variable *) > >>>> txt := QMachine.GetEnv (NIL, "M3CONFIG"); > >>>> IF (txt # NIL) THEN > >>>> IF TryConfig (txt) THEN RETURN END; > >>>> IF TryConfig (txt, Filename) THEN RETURN END; > >>>> END; > >>>> > >>>> (* try the directory containing the current executable *) > >>>> txt := Pathname.Prefix (Params.Get (0)); > >>>> > >>>> IF Text.Length (txt)> 0 THEN > >>>> IF TryConfig (txt, Filename) THEN RETURN END; > >>>> END; > >>>> > >>>> (* try the directories named by the PATH environment variable. *) > >>>> txt := Env.Get ("PATH"); > >>>> FindConfigInPath (txt); > >>>> > >>>> IF found THEN RETURN END; > >>>> > >>>> (* try the etc directories *) > >>>> IF TryConfig("/usr/local/cm3/etc", Filename) THEN RETURN END; > >>>> IF TryConfig("/usr/cm3/etc", Filename) THEN RETURN END; > >>>> IF TryConfig("/cm3/etc", Filename) THEN RETURN END; > >>>> IF TryConfig("/usr/contrib/etc", Filename) THEN RETURN END; > >>>> IF TryConfig("/usr/local/etc", Filename) THEN RETURN END; > >>>> IF TryConfig("/usr/etc", Filename) THEN RETURN END; > >>>> IF TryConfig("/opt/etc", Filename) THEN RETURN END; > >>>> IF TryConfig("/sw/etc", Filename) THEN RETURN END; > >>>> IF TryConfig("/etc", Filename) THEN RETURN END; > >>>> > >>>> (* oh well, make sure we don't try this silly exercise again... *) > >>>> config := NIL; > >>>> found := TRUE; > >>>> END FindConfig; > >>>> > >>>> > >>>> I propose..roughly roughly, we make it like this instead: > >>>> > >>>> > >>>> PROCEDURE FindConfig () = > >>>> (* LL = mu *) > >>>> VAR txt: TEXT; > >>>> BEGIN > >>>> IF (found) THEN RETURN END; > >>>> > >>>> (* try the M3CONFIG environment variable *) > >>>> txt := QMachine.GetEnv (NIL, "M3CONFIG"); > >>>> IF (txt # NIL) THEN > >>>> IF TryConfig (txt) THEN RETURN END; > >>>> IF TryConfig (txt, Filename) THEN RETURN END; > >>>> END; > >>>> > >>>> (* try the directory containing the current executable *) > >>>> txt := Pathname.Prefix (Params.Get (0)); > >>>> IF Text.Length (txt)> 0 THEN > >>>> IF TryConfig (txt, Filename) THEN RETURN END; > >>>> END; > >>>> > >>>> (* oh well, make sure we don't try this silly exercise again... *) > >>>> config := NIL; > >>>> found := TRUE; > >>>> END FindConfig; > >>>> > >>>> > >>>> or, if people really like it looking all over the place, fixing > >>>> the case of it being in the current working directory is > >>>> probably like this: > >>>> > >>>> > >>>> (* try the current directory *) > >>>> < IF TryConfig (Filename) THEN RETURN END; > >>>>> IF TryConfig (".", Filename) THEN RETURN END; > >>>> > >>>> > >>>> - Jay > >>>> > >>>> > >>>> > >>>> ---------------------------------------- > >>>>> From: jay.krell at cornell.edu > >>>>> To: rcoleburn at scires.com > >>>>> Date: Sun, 2 Aug 2009 23:42:17 -0700 > >>>>> CC: m3devel at elegosoft.com > >>>>> Subject: Re: [M3devel] problems with cm3.cfg and MxConfig > >>>>> > >>>>> Host, hm, I think probably my mistake. It is defined by cm3 but > >>>>> not > >>>>> all m3quake users. Path() should be the directory containing > >>>>> the file > >>>>> with the call. > >>>>> > >>>>> - Jay (phone) > >>>>> > >>>>> On Aug 2, 2009, at 9:52 PM, "Randy Coleburn" > >>>>> wrote: > >>>>> > >>>>>> I have been working on the problem of cm3ide not getting the > >>>>>> BUILD_DIR from cm3.cfg. I've run across some perplexing test > >>>>>> results. > >>>>>> > >>>>>> MxConfig.Get("BUILD_DIR") is returning NIL on Windows XP & Vista. > >>>>>> I've tracked it down a bit further. There seem to be two issues > >>>>>> that must be fixed to solve this problem: > >>>>>> > >>>>>> 1. HOST does not seem to be defined. In particular my "C:\cm3\bin > >>>>>> \cm3.cfg" file appears as follows (this is the file Jay > >>>>>> recommended): > >>>>>> INSTALL_ROOT = path() & "/.." > >>>>>> include (path() & "/config/" & HOST) > >>>>>> > >>>>>> Is HOST a variable? Or, was I supposed to replace it by "NT386"? > >>>>>> If the latter, my bad on this one--I took Jay's message > >>>>>> literally. > >>>>>> > >>>>>> 2. path() does not appear to always yield the path to the bin > >>>>>> folder. In particular, it seems to work fine unless you invoke > >>>>>> the > >>>>>> program when the current directory is actually set to the bin > >>>>>> folder, in which case path() seems to return the empty string. > >>>>>> > >>>>>> So, if ?%=C:\, and I run cm3ide, path() returns "C:\cm3\bin" > >>>>>> as it s > >>>>>> hould. > >>>>>> But, if ?%=C:\cm3\bin, and I run cm3ide, path() returns "". > >>>>>> > >>>>>> So in the latter case, the include statement winds up trying > >>>>>> to pull > >>>>>> a file from the wrong place, e.g. "/config/NT386" rather than "C: > >>>>>> \cm3\bin/config/NT386" > >>>>>> > >>>>>> Regards, > >>>>>> Randy Coleburn > >>> > >>> > >>> > >>> -- > >>> Olaf Wagner -- elego Software Solutions GmbH > >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > >>> Germany > >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 > >>> 23 45 86 95 > >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > >>> Berlin > >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > >>> DE163214194 > >>> > > > > > > > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > > Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > > 45 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > > Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > > DE163214194 > > > -- Dragi?a Duri? From wagner at elegosoft.com Mon Aug 3 23:15:45 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 03 Aug 2009 23:15:45 +0200 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> Message-ID: <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> Quoting Darko Volaric : > Putting it in /etc would mean that having different active versions of > compiler would e a pain, which is useful when developing, debugging or > trying out new versions of the compiler and when compilers are not self > hosted, which will be the case for ARM_DARWIN. > > What's the benefit of having it /etc other than being "standard"? The compiler searches in a list of locations and takes the first one found, as is the convention when doing path searches. AFAIK /etc is currently the last option at all. Perhaps we should try to gather the facts and write up a pro/cons list for different options. In all previous releases cm3 used the following strategy to find its configuration: "traditional" (1) ./cm3.cfg (2) src/cm3.cfg (3) ../src/cm3.cfg (4) $M3CONFIG (5) Pathname.Prefix( Params.Get( 0 )) (6) for p in $PATH: try p/cm3.cfg (7) give up... Because people were complaining that it wasn't possible to adhere to common system conventions with CM3 installation packages, I extended this strategy like this: "extended" (1)..(6) same as above (7) /usr/local/cm3/etc/cm3.cfg (8) /usr/cm3/etc/cm3.cfg (9) /cm3/etc/cm3.cfg (10) /usr/contrib/etc/cm3.cfg (11) /usr/local/etc/cm3.cfg (12) /usr/etc/cm3.cfg (13) /opt/etc/cm3.cfg (14) /sw/etc/cm3.cfg (15) /etc/cm3.cfg I do insist neither on this list nor the order or the locations themselves. On the other hand I do not see much harm in an extension like this, allowing a certain degree of freedom for those preparing system dependent installation packages. Recently Jay suggested to radically change the strategy: "reduced" (1) $M3CONFIG (2) Pathname.Prefix( Params.Get( 0 )) (3) give up We should now consider the advantages and disadvantages of each of the proposals. The following lists are not complete; I just make a start and others please extend as they see fit: "traditional" advantages: o seems to have worked OK with cm3, cm3ide etc. until now -- never change a running system (not very convincing ;-) disadvantages: o system dependent non-standard values only possible via environment settings M3CONFIG or PATH o not simple and easy to remember "extended" advantages: o just an extension to existing strategy o allows for several conventional standard locations for config files disadvantages: o not simple and easy to remember, may be confusing "reduced" advantages: o simple and easy to remember disadvantages: o system dependent non-standard values only possible via environment setting of M3CONFIG o may be incompatible with certain use cases of cm3 and cm3ide (to be investigated) There are also the general arguments saying that "no (user) configuration of cm3 is needed at all" (really?) and "that may be said of a lot of tools and services whose config files live in /etc/ and may just be adapted by root" "we should heed the standards and conventions of existing systems in order to be used" That's of course just a start, I'm sure I have forgotten many good arguments. Let's try to keep to the facts as much as possible though. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Mon Aug 3 23:21:41 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 03 Aug 2009 23:21:41 +0200 Subject: [M3devel] /etc/cm3.cfg (was: HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig) In-Reply-To: <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> Message-ID: <1249334501.28197.750.camel@faramir.m3w.org> On Mon, 2009-08-03 at 23:15 +0200, Olaf Wagner wrote: > The compiler searches in a list of locations and takes the first > one found, as is the convention when doing path searches. AFAIK > /etc is currently the last option at all. Tried this today, and what happened was - cm3 set PKG_INSTALL to "/" and I was unable to build anything until I moved cm3.cfg back to where cm3 binary is. -- Dragi?a Duri? From hendrik at topoi.pooq.com Mon Aug 3 23:29:36 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 3 Aug 2009 17:29:36 -0400 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> Message-ID: <20090803212936.GA25621@topoi.pooq.com> On Mon, Aug 03, 2009 at 08:59:26PM +0200, Darko Volaric wrote: > Putting it in /etc would mean that having different active versions of > compiler would e a pain, which is useful when developing, debugging or > trying out new versions of the compiler and when compilers are not > self hosted, which will be the case for ARM_DARWIN. > > What's the benefit of having it /etc other than being "standard"? Things in /etc/ are things that a system administrator might want to tweak. At least that was the idea originally. These options we're talking about seem somewhat different, in that they are tightly bound with the software itself. I say they are more like executable code than like configuration files. If a Debian user were to install cm3.deb, they had damn well point to the place the package put the compiler and friends. I don't see the being usefully modified at all on a user's machine.. So, I'd say, look in /etc if some architecture policeman forces it; otherwise treat the so-called configuration as if it were part of the executable, in .../cm3/... . The environment variables are another good place to look, because that makes it easy to experiment with multiple systems on one machine. -- hendrik From hendrik at topoi.pooq.com Mon Aug 3 23:49:02 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 3 Aug 2009 17:49:02 -0400 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> Message-ID: <20090803214902.GB25621@topoi.pooq.com> One could have the configuration file contain the locations where to find other configuration file(s). The file names in tis file could have explicit notations indicating "where the compiler is", "current directory", "User's home directory", "check the environment variable", and so forth. This would make things somewhat more flexible, It's not clear whether the added complexity would get in our way. -- hendrik From jay.krell at cornell.edu Mon Aug 3 23:53:22 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 21:53:22 +0000 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> Message-ID: > advantages: > o seems to have worked OK with cm3, cm3ide etc. until now -- > never change a running system (not very convincing ;-) This is mixing up ideas. It still works, except that now I have path() instead of an actual path in the config file. That is relocatable, but turns "." into "", and requires an assumption how to navigate from path() to the root of the install. - Jay From jay.krell at cornell.edu Mon Aug 3 23:55:08 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 21:55:08 +0000 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: <20090803214902.GB25621@topoi.pooq.com> References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> <20090803214902.GB25621@topoi.pooq.com> Message-ID: Correct. cm3 could probe for exceedingly few places, and those could then include whatever they want. Like how I moved everything to config, except the initial cm3.cfg (but then ran afoul briefly of my own INSTALL_ROOT = function of path() approach) Of course there is the tension of this being user editable or not, and therefore having to put every probe in on the theory that it isn't user editable. - Jay ---------------------------------------- > Date: Mon, 3 Aug 2009 17:49:02 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig > > One could have the configuration file contain the locations where to > find other configuration file(s). The file names in tis file could have > explicit notations indicating "where the compiler is", "current > directory", "User's home directory", "check the environment variable", > and so forth. > > This would make things somewhat more flexible, It's not clear whether > the added complexity would get in our way. > > -- hendrik From lists at darko.org Mon Aug 3 23:54:44 2009 From: lists at darko.org (Darko Volaric) Date: Mon, 3 Aug 2009 23:54:44 +0200 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> Message-ID: <13F24306-B7AF-4AEE-AC24-748B44FF3D86@darko.org> Besides advantages/disadvantages, can we consider user requirements? People who do native Mac development would need to (regularly) build for 3 targets: I386_DARWIN, AMD64_DARWIN and PPC_DARWIN which requires three different compilers, different libraries and different cfg files. In my mind the simplest solution would be to look next to the binary first as it does now, unless some new arrangement selects cfg files by the compiler target arch. Do we need to break the existing system and compatibility with existing installations and processes and if so, what is the payoff, besides simplification? On 03/08/2009, at 11:15 PM, Olaf Wagner wrote: > Quoting Darko Volaric : > >> Putting it in /etc would mean that having different active versions >> of >> compiler would e a pain, which is useful when developing, debugging >> or >> trying out new versions of the compiler and when compilers are not >> self >> hosted, which will be the case for ARM_DARWIN. >> >> What's the benefit of having it /etc other than being "standard"? > > The compiler searches in a list of locations and takes the first > one found, as is the convention when doing path searches. AFAIK > /etc is currently the last option at all. > > Perhaps we should try to gather the facts and write up a pro/cons > list for different options. > > In all previous releases cm3 used the following strategy to find > its configuration: > > "traditional" > > (1) ./cm3.cfg > (2) src/cm3.cfg > (3) ../src/cm3.cfg > (4) $M3CONFIG > (5) Pathname.Prefix( Params.Get( 0 )) > (6) for p in $PATH: try p/cm3.cfg > (7) give up... > > Because people were complaining that it wasn't possible to adhere > to common system conventions with CM3 installation packages, > I extended this strategy like this: > > "extended" > > (1)..(6) same as above > (7) /usr/local/cm3/etc/cm3.cfg > (8) /usr/cm3/etc/cm3.cfg > (9) /cm3/etc/cm3.cfg > (10) /usr/contrib/etc/cm3.cfg > (11) /usr/local/etc/cm3.cfg > (12) /usr/etc/cm3.cfg > (13) /opt/etc/cm3.cfg > (14) /sw/etc/cm3.cfg > (15) /etc/cm3.cfg > > I do insist neither on this list nor the order or the locations > themselves. On the other hand I do not see much harm in an extension > like this, allowing a certain degree of freedom for those preparing > system dependent installation packages. > > Recently Jay suggested to radically change the strategy: > > "reduced" > > (1) $M3CONFIG > (2) Pathname.Prefix( Params.Get( 0 )) > (3) give up > > We should now consider the advantages and disadvantages of each > of the proposals. The following lists are not complete; I just make > a start and others please extend as they see fit: > > "traditional" > > advantages: > o seems to have worked OK with cm3, cm3ide etc. until now -- > never change a running system (not very convincing ;-) > > disadvantages: > o system dependent non-standard values only possible via environment > settings M3CONFIG or PATH > o not simple and easy to remember > > "extended" > > advantages: > o just an extension to existing strategy > o allows for several conventional standard locations for config files > > disadvantages: > o not simple and easy to remember, may be confusing > > "reduced" > > advantages: > o simple and easy to remember > > disadvantages: > o system dependent non-standard values only possible via environment > setting of M3CONFIG > o may be incompatible with certain use cases of cm3 and cm3ide (to > be investigated) > > There are also the general arguments saying that > > "no (user) configuration of cm3 is needed at all" (really?) > > and > > "that may be said of a lot of tools and services whose config files > live in /etc/ and may just be adapted by root" > > "we should heed the standards and conventions of existing systems > in order to be used" > > That's of course just a start, I'm sure I have forgotten many good > arguments. Let's try to keep to the facts as much as possible though. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From jay.krell at cornell.edu Mon Aug 3 23:56:50 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 21:56:50 +0000 Subject: [M3devel] assembly goes to C compiler? In-Reply-To: <20090803163625.qm007v2pfog8s8sg@mail.elegosoft.com> References: <20090803132158.walcuy2s00wck04g@mail.elegosoft.com> <20090803131048.GB24864@topoi.pooq.com> <4AD30F1F-90E6-48F8-B93C-6889E8D2BAF4@cs.purdue.edu> <20090803163625.qm007v2pfog8s8sg@mail.elegosoft.com> Message-ID: asssemble is used for cm3cg output C is used for user-written assembly - Jay ---------------------------------------- > Date: Mon, 3 Aug 2009 16:36:25 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] assembly goes to C compiler? > > Quoting Tony Hosking : > >> Using the C compiler allows the assembly to have preprocessor directives. > > So you think it's a feature. Why do we have the assemble methods > in the config file then? Or are they just legacy? > > %---------------------------------------------------------------- > assembler --- > % "assemble" is called to assemble .s or .asm files. Note that this function > % is only called if your program or library explicitly includes > assembly source > % code, the system distributed by Critical Mass does not. > > proc assemble(source, object) is > if defined("configure_assembler") > configure_assembler() > end > return try_exec("@" & SYSTEM_ASM, source, "-o", object) > end > > Probably a remnant of DEC SRC M3? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From lists at darko.org Mon Aug 3 23:59:43 2009 From: lists at darko.org (Darko Volaric) Date: Mon, 3 Aug 2009 23:59:43 +0200 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: <20090803212936.GA25621@topoi.pooq.com> References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803212936.GA25621@topoi.pooq.com> Message-ID: The cfg files contain library lists which I change all the time. I understand there is a lot of build scripting in there too, but I ignore that and assume it's correct and see it only as a user config file. Maybe the "executable" bits need to moved elsewhere? Environment variables are pretty loathsome in my opinion. This is a bit of creeping unixism, but not everyone likes unix. On 03/08/2009, at 11:29 PM, hendrik at topoi.pooq.com wrote: > On Mon, Aug 03, 2009 at 08:59:26PM +0200, Darko Volaric wrote: >> Putting it in /etc would mean that having different active versions >> of >> compiler would e a pain, which is useful when developing, debugging >> or >> trying out new versions of the compiler and when compilers are not >> self hosted, which will be the case for ARM_DARWIN. >> >> What's the benefit of having it /etc other than being "standard"? > > Things in /etc/ are things that a system administrator might want to > tweak. At least that was the idea originally. These options we're > talking about seem somewhat different, in that they are tightly bound > with the software itself. I say they are more like executable code > than > like configuration files. If a Debian user were to install cm3.deb, > they had damn well point to the place the package put the compiler and > friends. I don't see the being usefully modified at all on a user's > machine.. > > So, I'd say, look in /etc if some architecture policeman forces it; > otherwise treat the so-called configuration as if it were part of the > executable, in .../cm3/... . > > The environment variables are another good place to look, because that > makes it easy to experiment with multiple systems on one machine. > > -- hendrik From jay.krell at cornell.edu Tue Aug 4 00:00:52 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 22:00:52 +0000 Subject: [M3devel] some cvs errors? In-Reply-To: <20090803131445.d5u1i1vaf484kg4s@mail.elegosoft.com> References: <20090803131445.d5u1i1vaf484kg4s@mail.elegosoft.com> Message-ID: One error, the second one, was maybe local, not on the server. I saw it again later while running make-dist.sh, it tries to update itself. Not clear why it occured here, maybe I had one running and the use of $Id$ caused an attempted and failed write. Or maybe the error was on the server. With CVS, can't be sure of much imho. The other seems ok. +2 for replacing cvs with something better.. after we invent more time... - Jay ---------------------------------------- > Date: Mon, 3 Aug 2009 13:14:45 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; m3-support at elego.de > Subject: Re: some cvs errors? > > Quoting Jay K : > >> "/tmp/cvsUsaGYO" 61 lines, 1835 characters >> /usr/cvs/cm3/m3-sys/m3cc/src/m3makefile,v <-- src/m3makefile >> new revision: 1.111.2.4; previous revision: 1.111.2.3 >> Cannot Open data file (cwd: /usr/local/tinderbox/bonsai; >> data/temp.8776): Bad fi >> >> ? PKGS >> /usr/cvs/cm3/scripts/find-packages.sh,v <-- find-packages.sh >> new revision: 1.9.2.1; previous revision: 1.9 >> /usr/cvs/cm3/scripts/find-src-dirs.sh,v <-- find-src-dirs.sh >> new revision: 1.2.2.1; previous revision: 1.2 >> /usr/cvs/cm3/scripts/list-pkg-dirs.sh,v <-- list-pkg-dirs.sh >> new revision: 1.2.2.1; previous revision: 1.2 >> /usr/cvs/cm3/scripts/make-dist.sh,v <-- make-dist.sh >> new revision: 1.26.2.5; previous revision: 1.26.2.4 >> cvs [commit aborted]: cannot rename file .new.make-dist.sh to >> make-dist.sh: Permission denied >> >> >> ? >> >> I think the commits made it. > > What were these? Do we need to investigate them? > Or is everything OK now? > > Still trying to catch up with all my mails, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Tue Aug 4 00:05:27 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 22:05:27 +0000 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803212936.GA25621@topoi.pooq.com> Message-ID: I have to admit there is a mix of "clearly almost always correct, maybe really always" and "perhaps user editable code" in there. I have hoped for no user editing but can't claim I got there, due to the library issues as you say, and maybe even -gstabs vs. -gstabs+ vs. -g, etc. -- heck maybe user wants slightly smaller binaries and doesn't mind slight loss of debugging, and doesn't want to strip afterward. I did try to find "fairly canonical" places for libraries, such as wherever the platform package system installs things, but ultimately you can build yourself and get /usr/local instead of /usr/pkg, etc. A possible solution is for the cm3.cfg file itself to probe, "at certain well defined points" for "certain well defined data", as well as leaving things not readonly. For example at the very end it might probe for $HOME/etc/cm3.cfg and /etc/cm3.cfg and include them if they exist, or just the first. I also don't want to get into the business of merging these files on user machines, either automatically or making people do it. I guess we are in the second situation now however. A partial approach is to move more of the code into cm3, perhaps merely as Quake snippets, but that is perhaps overkill. - Jay ---------------------------------------- > From: lists at darko.org > To: hendrik at topoi.pooq.com > Date: Mon, 3 Aug 2009 23:59:43 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig > > The cfg files contain library lists which I change all the time. I > understand there is a lot of build scripting in there too, but I > ignore that and assume it's correct and see it only as a user config > file. Maybe the "executable" bits need to moved elsewhere? > > Environment variables are pretty loathsome in my opinion. This is a > bit of creeping unixism, but not everyone likes unix. > > > On 03/08/2009, at 11:29 PM, hendrik at topoi.pooq.com wrote: > >> On Mon, Aug 03, 2009 at 08:59:26PM +0200, Darko Volaric wrote: >>> Putting it in /etc would mean that having different active versions >>> of >>> compiler would e a pain, which is useful when developing, debugging >>> or >>> trying out new versions of the compiler and when compilers are not >>> self hosted, which will be the case for ARM_DARWIN. >>> >>> What's the benefit of having it /etc other than being "standard"? >> >> Things in /etc/ are things that a system administrator might want to >> tweak. At least that was the idea originally. These options we're >> talking about seem somewhat different, in that they are tightly bound >> with the software itself. I say they are more like executable code >> than >> like configuration files. If a Debian user were to install cm3.deb, >> they had damn well point to the place the package put the compiler and >> friends. I don't see the being usefully modified at all on a user's >> machine.. >> >> So, I'd say, look in /etc if some architecture policeman forces it; >> otherwise treat the so-called configuration as if it were part of the >> executable, in .../cm3/... . >> >> The environment variables are another good place to look, because that >> makes it easy to experiment with multiple systems on one machine. >> >> -- hendrik > From jay.krell at cornell.edu Tue Aug 4 00:21:36 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 22:21:36 +0000 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803212936.GA25621@topoi.pooq.com> Message-ID: I'm on the fence wrt environment variables. It is fairly rare for users to run executables by full path. $PATH search and changing $PATH seems to be the way. But what paths code tends to use, not sure. It might also be blurry as "code" that runs stuff is initially users coding up their command lines in sh and then gradually formalizing things, and "formal" might or might not mean using full paths. On Windows, there is no /usr/include. You either set $INCLUDE and $LIB and/or you give paths to the compiler/linker on the command line. Or a mix. Environment variables are The way to set something and have it be inherited by child processes, but not inherited by the rest of the system. They lead to a process tree that works in one setup/configured temporary way. But don't lead to an overall system that works a particular way, unless you set them somewhere with enough impact. There is a larger problem in software wrt how to handle "settings". There are environment variables. There are lots of text files in /etc. There is the Windows registry. They all have pluses and minuses. Really, the Windows registry does have pluses. The problem is related to just how many settings there are. The more you need, the more general a solution is needed, and the less satisfactory it is bound to be. It is far more complicated than most people realize. "settings" are contextual. They can be per user, per machine, per user+machine combination, and more. I'm sure people will claim "but such and such system solves it all", and maybe, but unlikely imho. I mean, heck, per user but I have multiple machines. How do I instantly change all my machines to use an orange desktop? Oh, well, there are "roaming profiles" on Windows and networked $HOME directories on Windows. Maybe. But I've basically never used them, so maybe they do solve it? There are also settings that shouldn't be settings. My terminal emulation usually doesn't quite work. (Amzazing how much does not work..). I find myself messing with $TERM but I should never have to. And still it doesn't work so maybe I don't have to, the problem is elsewhere.. - Jay ---------------------------------------- > From: lists at darko.org > To: hendrik at topoi.pooq.com > Date: Mon, 3 Aug 2009 23:59:43 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig > > The cfg files contain library lists which I change all the time. I > understand there is a lot of build scripting in there too, but I > ignore that and assume it's correct and see it only as a user config > file. Maybe the "executable" bits need to moved elsewhere? > > Environment variables are pretty loathsome in my opinion. This is a > bit of creeping unixism, but not everyone likes unix. > > > On 03/08/2009, at 11:29 PM, hendrik at topoi.pooq.com wrote: > >> On Mon, Aug 03, 2009 at 08:59:26PM +0200, Darko Volaric wrote: >>> Putting it in /etc would mean that having different active versions >>> of >>> compiler would e a pain, which is useful when developing, debugging >>> or >>> trying out new versions of the compiler and when compilers are not >>> self hosted, which will be the case for ARM_DARWIN. >>> >>> What's the benefit of having it /etc other than being "standard"? >> >> Things in /etc/ are things that a system administrator might want to >> tweak. At least that was the idea originally. These options we're >> talking about seem somewhat different, in that they are tightly bound >> with the software itself. I say they are more like executable code >> than >> like configuration files. If a Debian user were to install cm3.deb, >> they had damn well point to the place the package put the compiler and >> friends. I don't see the being usefully modified at all on a user's >> machine.. >> >> So, I'd say, look in /etc if some architecture policeman forces it; >> otherwise treat the so-called configuration as if it were part of the >> executable, in .../cm3/... . >> >> The environment variables are another good place to look, because that >> makes it easy to experiment with multiple systems on one machine. >> >> -- hendrik > From jay.krell at cornell.edu Tue Aug 4 00:23:56 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 22:23:56 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <4A76FEED.1E75.00D7.1@scires.com> References: <20090803093135.3F59DCC81B@birch.elegosoft.com> <4A76CADA.1E75.00D7.1@scires.com> <4A76FEED.1E75.00D7.1@scires.com> Message-ID: I failed to figure how to move anything at all to RC2 (perhaps that is by-design, Olaf escalating and using more and more arcane features of cvs to stay ahead of me), but I moved it to the release branch, which should get it at least into whatever if anything follows RC2. The fix seems fragile though. Converting to a full path would probably be better. (Full paths are still contextual, but most people/code seem ok ignoring that. Could be net used or chroot..) - Jay ________________________________ > Date: Mon, 3 Aug 2009 15:17:30 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > > > > > Jay: > > > > Your change to MxConfig.m3 seems to work fine for cm3ide, provided that I replace HOST by "NT386" in my cm3.cfg is as follows: > > > > INSTALL_ROOT = path() & "/.." > include (path() & "/config/NT386") > > > > Thank you! > > > > Can we get your revised MxConfig.m3 put into the RC2 branch? > > > > Regards, > > Randy > >>>> "Randy Coleburn" 8/3/2009 11:35 AM>>> > > Jay: > > I agree that running cm3 from "bin" folder is not going to be productive; however, other programs (such as cm3ide) also use the quake stuff and they don't have this limitation. I think your change is a good one. I'll run some tests and see how cm3ide fares. Thanks. > > --Randy > >>>> Jay Krell 8/3/2009 11:31 AM>>> > CVSROOT:/usr/cvs > Changes by:jkrell at birch.09/08/03 11:31:35 > > Modified files: > cm3/m3-sys/m3quake/src/: MxConfig.m3 > > Log message: > use "." instead of empty string for path() when current working > directory is the actual directory of cm3; not sure what good > running cm3 here is, and we probe way too many places.. > From jay.krell at cornell.edu Tue Aug 4 00:25:25 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 22:25:25 +0000 Subject: [M3devel] /etc/cm3.cfg (was: HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig) In-Reply-To: <1249334501.28197.750.camel@faramir.m3w.org> References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> <1249334501.28197.750.camel@faramir.m3w.org> Message-ID: If you put your cm3.cfg in /etc, you will have to edit it. INSTALL_ROOT = path() & "/.." won't be correct, and then everything computed from it. - Jay ---------------------------------------- > From: dragisha at m3w.org > To: wagner at elegosoft.com > Date: Mon, 3 Aug 2009 23:21:41 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] /etc/cm3.cfg (was: HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig) > > On Mon, 2009-08-03 at 23:15 +0200, Olaf Wagner wrote: >> The compiler searches in a list of locations and takes the first >> one found, as is the convention when doing path searches. AFAIK >> /etc is currently the last option at all. > > Tried this today, and what happened was - cm3 set PKG_INSTALL to "/" and > I was unable to build anything until I moved cm3.cfg back to where cm3 > binary is. > -- > Dragi?a Duri? > From jay.krell at cornell.edu Tue Aug 4 00:25:42 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 22:25:42 +0000 Subject: [M3devel] /etc/cm3.cfg (was: HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig) In-Reply-To: <1249334501.28197.750.camel@faramir.m3w.org> References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> <1249334501.28197.750.camel@faramir.m3w.org> Message-ID: (unless cm3 is in /etc and / is your install root) ---------------------------------------- > From: jay.krell at cornell.edu > To: dragisha at m3w.org; wagner at elegosoft.com > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] /etc/cm3.cfg (was: HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig) > Date: Mon, 3 Aug 2009 22:25:25 +0000 > > > If you put your cm3.cfg in /etc, you will have to edit it. > INSTALL_ROOT = path() & "/.." won't be correct, and then everything computed from it. > > - Jay > > > ---------------------------------------- >> From: dragisha at m3w.org >> To: wagner at elegosoft.com >> Date: Mon, 3 Aug 2009 23:21:41 +0200 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] /etc/cm3.cfg (was: HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig) >> >> On Mon, 2009-08-03 at 23:15 +0200, Olaf Wagner wrote: >>> The compiler searches in a list of locations and takes the first >>> one found, as is the convention when doing path searches. AFAIK >>> /etc is currently the last option at all. >> >> Tried this today, and what happened was - cm3 set PKG_INSTALL to "/" and >> I was unable to build anything until I moved cm3.cfg back to where cm3 >> binary is. >> -- >> Dragi?a Duri? >> From jay.krell at cornell.edu Tue Aug 4 00:29:48 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 22:29:48 +0000 Subject: [M3devel] the SOLgnu alignment problem finally understood In-Reply-To: <20090803132628.krcbd41hy8ggs8s8@mail.elegosoft.com> References: <20090803132628.krcbd41hy8ggs8s8@mail.elegosoft.com> Message-ID: cm3cg's lack of support for -g or -gdwarf etc. shouldn't mean gcc/gas doesn't support -g. Yes, -g is rare in the config files. This was perhaps an oversight. This seems like a gcc or gas bug, but oh well. My gcc is old 3.x. Note that on some systems -gstabs isn't supported, like PA64_HPUX I think. But using cm3cg -g tends to "internal compiler error" and such. A problem for the potential future, things are adequate for now. - Jay ---------------------------------------- > Date: Mon, 3 Aug 2009 13:26:28 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: the SOLgnu alignment problem finally understood > > We had similar problems before with -g. CM3 never supported dwarf > debugging format, just stabs. I think we changed all -g occurences > in the config files to -gstabs some years ago. > > It sounds like a small fix in the config files after all, correct? > At least for this RC? > > Olaf > > Quoting Jay K : > >> >> Here finally is a small example of the SOLgnu problem I've been >> looking at it. >> >> >> It is specific to using /usr/sfw/bin/gcc -g to asssemble. >> No problem without -g, no problem with /usr/bin/cc, no problem with >> whatever I built in /usr/local/bin/gcc, no problem if you assemble >> with anything else and then link with /usr/sfw/bin/gcc -g. >> >> >> -bash-3.00$ cat 4.c asm.s >> >> 4.c >> void Asm(void); >> #include >> >> int main() >> { >> Asm(); >> printf("\n"); >> return 0; >> } >> >> asm.s >> >> .section ".text",#alloc,#execinstr >> .align 4 >> .global Asm >> .type Asm,#function >> Asm: >> retl >> nop >> .size Asm, (.-Asm) >> >> >> Not all possibilities shown here: >> >> >> -bash-3.00$ /usr/local/bin/gcc -g asm.s 4.c >> ok >> >> >> -bash-3.00$ /usr/sfw/bin/gcc -g asm.s 4.c >> ld: fatal: relocation error: R_SPARC_32: file /var/tmp//ccICgvny.o: >> symbol : offset 0xfeed139e is non-aligned >> ld: fatal: relocation error: R_SPARC_32: file /var/tmp//ccICgvny.o: >> symbol : offset 0xfeed14c2 is non-aligned >> ld: fatal: relocation error: R_SPARC_32: file /var/tmp//ccICgvny.o: >> symbol : offset 0xfeed15f6 is non-aligned >> collect2: ld returned 1 exit status >> >> >> -bash-3.00$ /usr/bin/cc -g asm.s 4.c >> asm.s: >> 4.c: >> ok >> >> -bash-3.00$ /usr/bin/cc asm.s 4.c >> asm.s: >> 4.c: >> ok >> >> >> -bash-3.00$ /usr/sfw/bin/gcc asm.s 4.c >> ok >> >> >> -bash-3.00$ /usr/local/bin/gcc asm.s 4.c >> ok >> >> >> -bash-3.00$ /usr/sfw/bin/gcc -g -c asm.s >> ok but haven't linked yet, input to later steps >> >> >> -bash-3.00$ /usr/bin/cc asm.o 4.c >> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >> ff10148e is non-aligned >> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >> ff1014ca is non-aligned >> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >> ff1015be is non-aligned >> >> >> -bash-3.00$ /usr/local/bin/gcc asm.o 4.c >> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >> feee1213 is non-aligned >> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >> feee122a is non-aligned >> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >> feee122e is non-aligned >> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >> feee1232 is non-aligned >> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >> feee126e is non-aligned >> collect2: ld returned 1 exit status >> >> >> >> -bash-3.00$ /usr/local/bin/gcc -g -c asm.s >> ok, try linking with others >> >> >> -bash-3.00$ /usr/bin/cc asm.o 4.c >> ok >> >> >> >> -bash-3.00$ /usr/sfw/bin/gcc asm.o 4.c >> ok >> >> >> Actually even -gstabs or -gstabs+ instead of -g make it work. >> -g resolves to -gdwarf2. >> >> >> - Jay > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Tue Aug 4 00:31:04 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 22:31:04 +0000 Subject: [M3devel] the SOLgnu alignment problem finally understood In-Reply-To: <20090803132628.krcbd41hy8ggs8s8@mail.elegosoft.com> References: <20090803132628.krcbd41hy8ggs8s8@mail.elegosoft.com> Message-ID: ps: building RC2 with my /usr/local/bin/gcc is also viable That is how things were working. It is confused to use /usr/ccs/bin/as, and the -g doesn't get passed down to it I think it was. I might not get anything else in for ~two days.. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > CC: m3devel at elegosoft.com > Subject: RE: the SOLgnu alignment problem finally understood > Date: Mon, 3 Aug 2009 22:29:48 +0000 > > > cm3cg's lack of support for -g or -gdwarf etc. shouldn't mean gcc/gas doesn't support -g. > Yes, -g is rare in the config files. This was perhaps an oversight. > This seems like a gcc or gas bug, but oh well. > My gcc is old 3.x. > Note that on some systems -gstabs isn't supported, like PA64_HPUX I think. > But using cm3cg -g tends to "internal compiler error" and such. > A problem for the potential future, things are adequate for now. > > - Jay > > > ---------------------------------------- >> Date: Mon, 3 Aug 2009 13:26:28 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: the SOLgnu alignment problem finally understood >> >> We had similar problems before with -g. CM3 never supported dwarf >> debugging format, just stabs. I think we changed all -g occurences >> in the config files to -gstabs some years ago. >> >> It sounds like a small fix in the config files after all, correct? >> At least for this RC? >> >> Olaf >> >> Quoting Jay K : >> >>> >>> Here finally is a small example of the SOLgnu problem I've been >>> looking at it. >>> >>> >>> It is specific to using /usr/sfw/bin/gcc -g to asssemble. >>> No problem without -g, no problem with /usr/bin/cc, no problem with >>> whatever I built in /usr/local/bin/gcc, no problem if you assemble >>> with anything else and then link with /usr/sfw/bin/gcc -g. >>> >>> >>> -bash-3.00$ cat 4.c asm.s >>> >>> 4.c >>> void Asm(void); >>> #include >>> >>> int main() >>> { >>> Asm(); >>> printf("\n"); >>> return 0; >>> } >>> >>> asm.s >>> >>> .section ".text",#alloc,#execinstr >>> .align 4 >>> .global Asm >>> .type Asm,#function >>> Asm: >>> retl >>> nop >>> .size Asm, (.-Asm) >>> >>> >>> Not all possibilities shown here: >>> >>> >>> -bash-3.00$ /usr/local/bin/gcc -g asm.s 4.c >>> ok >>> >>> >>> -bash-3.00$ /usr/sfw/bin/gcc -g asm.s 4.c >>> ld: fatal: relocation error: R_SPARC_32: file /var/tmp//ccICgvny.o: >>> symbol : offset 0xfeed139e is non-aligned >>> ld: fatal: relocation error: R_SPARC_32: file /var/tmp//ccICgvny.o: >>> symbol : offset 0xfeed14c2 is non-aligned >>> ld: fatal: relocation error: R_SPARC_32: file /var/tmp//ccICgvny.o: >>> symbol : offset 0xfeed15f6 is non-aligned >>> collect2: ld returned 1 exit status >>> >>> >>> -bash-3.00$ /usr/bin/cc -g asm.s 4.c >>> asm.s: >>> 4.c: >>> ok >>> >>> -bash-3.00$ /usr/bin/cc asm.s 4.c >>> asm.s: >>> 4.c: >>> ok >>> >>> >>> -bash-3.00$ /usr/sfw/bin/gcc asm.s 4.c >>> ok >>> >>> >>> -bash-3.00$ /usr/local/bin/gcc asm.s 4.c >>> ok >>> >>> >>> -bash-3.00$ /usr/sfw/bin/gcc -g -c asm.s >>> ok but haven't linked yet, input to later steps >>> >>> >>> -bash-3.00$ /usr/bin/cc asm.o 4.c >>> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >>> ff10148e is non-aligned >>> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >>> ff1014ca is non-aligned >>> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >>> ff1015be is non-aligned >>> >>> >>> -bash-3.00$ /usr/local/bin/gcc asm.o 4.c >>> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >>> feee1213 is non-aligned >>> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >>> feee122a is non-aligned >>> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >>> feee122e is non-aligned >>> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >>> feee1232 is non-aligned >>> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >>> feee126e is non-aligned >>> collect2: ld returned 1 exit status >>> >>> >>> >>> -bash-3.00$ /usr/local/bin/gcc -g -c asm.s >>> ok, try linking with others >>> >>> >>> -bash-3.00$ /usr/bin/cc asm.o 4.c >>> ok >>> >>> >>> >>> -bash-3.00$ /usr/sfw/bin/gcc asm.o 4.c >>> ok >>> >>> >>> Actually even -gstabs or -gstabs+ instead of -g make it work. >>> -g resolves to -gdwarf2. >>> >>> >>> - Jay >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> From jay.krell at cornell.edu Tue Aug 4 00:33:40 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 22:33:40 +0000 Subject: [M3devel] the SOLgnu alignment problem finally understood In-Reply-To: References: <20090803132628.krcbd41hy8ggs8s8@mail.elegosoft.com> Message-ID: < confused > configured oops ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > Date: Mon, 3 Aug 2009 22:31:04 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] the SOLgnu alignment problem finally understood > > > ps: building RC2 with my /usr/local/bin/gcc is also viable > That is how things were working. > It is confused to use /usr/ccs/bin/as, and the -g doesn't get passed down to it I think it was. > I might not get anything else in for ~two days.. > > > - Jay > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com >> CC: m3devel at elegosoft.com >> Subject: RE: the SOLgnu alignment problem finally understood >> Date: Mon, 3 Aug 2009 22:29:48 +0000 >> >> >> cm3cg's lack of support for -g or -gdwarf etc. shouldn't mean gcc/gas doesn't support -g. >> Yes, -g is rare in the config files. This was perhaps an oversight. >> This seems like a gcc or gas bug, but oh well. >> My gcc is old 3.x. >> Note that on some systems -gstabs isn't supported, like PA64_HPUX I think. >> But using cm3cg -g tends to "internal compiler error" and such. >> A problem for the potential future, things are adequate for now. >> >> - Jay >> >> >> ---------------------------------------- >>> Date: Mon, 3 Aug 2009 13:26:28 +0200 >>> From: wagner at elegosoft.com >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com >>> Subject: Re: the SOLgnu alignment problem finally understood >>> >>> We had similar problems before with -g. CM3 never supported dwarf >>> debugging format, just stabs. I think we changed all -g occurences >>> in the config files to -gstabs some years ago. >>> >>> It sounds like a small fix in the config files after all, correct? >>> At least for this RC? >>> >>> Olaf >>> >>> Quoting Jay K : >>> >>>> >>>> Here finally is a small example of the SOLgnu problem I've been >>>> looking at it. >>>> >>>> >>>> It is specific to using /usr/sfw/bin/gcc -g to asssemble. >>>> No problem without -g, no problem with /usr/bin/cc, no problem with >>>> whatever I built in /usr/local/bin/gcc, no problem if you assemble >>>> with anything else and then link with /usr/sfw/bin/gcc -g. >>>> >>>> >>>> -bash-3.00$ cat 4.c asm.s >>>> >>>> 4.c >>>> void Asm(void); >>>> #include >>>> >>>> int main() >>>> { >>>> Asm(); >>>> printf("\n"); >>>> return 0; >>>> } >>>> >>>> asm.s >>>> >>>> .section ".text",#alloc,#execinstr >>>> .align 4 >>>> .global Asm >>>> .type Asm,#function >>>> Asm: >>>> retl >>>> nop >>>> .size Asm, (.-Asm) >>>> >>>> >>>> Not all possibilities shown here: >>>> >>>> >>>> -bash-3.00$ /usr/local/bin/gcc -g asm.s 4.c >>>> ok >>>> >>>> >>>> -bash-3.00$ /usr/sfw/bin/gcc -g asm.s 4.c >>>> ld: fatal: relocation error: R_SPARC_32: file /var/tmp//ccICgvny.o: >>>> symbol : offset 0xfeed139e is non-aligned >>>> ld: fatal: relocation error: R_SPARC_32: file /var/tmp//ccICgvny.o: >>>> symbol : offset 0xfeed14c2 is non-aligned >>>> ld: fatal: relocation error: R_SPARC_32: file /var/tmp//ccICgvny.o: >>>> symbol : offset 0xfeed15f6 is non-aligned >>>> collect2: ld returned 1 exit status >>>> >>>> >>>> -bash-3.00$ /usr/bin/cc -g asm.s 4.c >>>> asm.s: >>>> 4.c: >>>> ok >>>> >>>> -bash-3.00$ /usr/bin/cc asm.s 4.c >>>> asm.s: >>>> 4.c: >>>> ok >>>> >>>> >>>> -bash-3.00$ /usr/sfw/bin/gcc asm.s 4.c >>>> ok >>>> >>>> >>>> -bash-3.00$ /usr/local/bin/gcc asm.s 4.c >>>> ok >>>> >>>> >>>> -bash-3.00$ /usr/sfw/bin/gcc -g -c asm.s >>>> ok but haven't linked yet, input to later steps >>>> >>>> >>>> -bash-3.00$ /usr/bin/cc asm.o 4.c >>>> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >>>> ff10148e is non-aligned >>>> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >>>> ff1014ca is non-aligned >>>> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >>>> ff1015be is non-aligned >>>> >>>> >>>> -bash-3.00$ /usr/local/bin/gcc asm.o 4.c >>>> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >>>> feee1213 is non-aligned >>>> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >>>> feee122a is non-aligned >>>> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >>>> feee122e is non-aligned >>>> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >>>> feee1232 is non-aligned >>>> ld: fatal: relocation error: R_SPARC_32: file asm.o: symbol : offset 0x >>>> feee126e is non-aligned >>>> collect2: ld returned 1 exit status >>>> >>>> >>>> >>>> -bash-3.00$ /usr/local/bin/gcc -g -c asm.s >>>> ok, try linking with others >>>> >>>> >>>> -bash-3.00$ /usr/bin/cc asm.o 4.c >>>> ok >>>> >>>> >>>> >>>> -bash-3.00$ /usr/sfw/bin/gcc asm.o 4.c >>>> ok >>>> >>>> >>>> Actually even -gstabs or -gstabs+ instead of -g make it work. >>>> -g resolves to -gdwarf2. >>>> >>>> >>>> - Jay >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >>> From hendrik at topoi.pooq.com Tue Aug 4 00:37:10 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 3 Aug 2009 18:37:10 -0400 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803212936.GA25621@topoi.pooq.com> Message-ID: <20090803223710.GE25621@topoi.pooq.com> On Mon, Aug 03, 2009 at 10:21:36PM +0000, Jay K wrote: > > I'm on the fence wrt environment variables. > > > It is fairly rare for users to run executables by full path. > $PATH search and changing $PATH seems to be the way. > > > But what paths code tends to use, not sure. > It might also be blurry as "code" that runs stuff is initially users coding up their command lines in sh and then gradually formalizing things, and "formal" might or might not mean using full paths. > > > On Windows, there is no /usr/include. > You either set $INCLUDE and $LIB and/or you give paths to the > compiler/linker on the command line. Or a mix. > > > Environment variables are The way to set something and have it be > inherited by child processes, but not inherited by the rest of the > system. > > > They lead to a process tree that works in one setup/configured temporary way. > But don't lead to an overall system that works a particular way, > unless you set them somewhere with enough impact. > That is exactly the mad scientist whill want when he's tinkering with deviant Modula 3 compilers. But it's not what the average user will want. And it's not what the mad compiler tinkerer will want when he's just compiling ordinary programs. So let an environment variable override whatever else would be used to find the configuration file. And leave it undefined for the average user. > > There is a larger problem in software wrt how to handle "settings". > There are environment variables. There are lots of text files in > /etc. There is the Windows registry. > They all have pluses and minuses. Really, the Windows registry does > have pluses. > The problem is related to just how many settings there are. > The more you need, the more general a solution is needed, and the less > satisfactory it is bound to be. > > > It is far more complicated than most people realize. > "settings" are contextual. They can be per user, per machine, per > user+machine combination, and more. > I'm sure people will claim "but such and such system solves it all", > and maybe, but unlikely imho. > I mean, heck, per user but I have multiple machines. > How do I instantly change all my machines to use an orange desktop? > Oh, well, there are "roaming profiles" on Windows and networked > $HOME directories on Windows. Maybe. But I've basically never used > them, so maybe they do solve it? Let the user provide a program that, when run, will write the configuration file to stdout? Let the user provide a web page with an applet that .... etc. etc. > > There are also settings that shouldn't be settings. > My terminal emulation usually doesn't quite work. (Amzazing how much > does not work..). I find myself messing with $TERM but I should never > have to. And still it doesn't work so maybe I don't have to, the > problem is elsewhere.. My terminal won't come up at all unless I first start iceweasel or gnucash or Pan (maybe some others). But messing with $TERM won't fix this. The problem is elsewhere. :-) > > > > - Jay From jay.krell at cornell.edu Tue Aug 4 01:42:12 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 3 Aug 2009 23:42:12 +0000 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: <20090803223710.GE25621@topoi.pooq.com> References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803212936.GA25621@topoi.pooq.com> <20090803223710.GE25621@topoi.pooq.com> Message-ID: > That is exactly the mad scientist whill want when he's tinkering with > deviant Modula 3 compilers. But it's not what the average user will > want. And it's not what the mad compiler tinkerer will want when he's > just compiling ordinary programs. So let an environment variable > override whatever else would be used to find the configuration file. > And leave it undefined for the average user. I have been a proponent of what you say. And I have tried to achieve it. However it is not clear if I got there. The system-wide library paths, one example, are what the "(mad) Linux tinkerer" might alter, once and be done, not merely the "compiler tinkerer". There may be too many such people. Even for the mad tinkerer to have his own system-wide gcc might be common? Again, more of a "once and be done" mode, not often changing? The config files ultimately don't even that much. The previous authors did factor them fairly well. Just not /quite/ enough to my taste. :) I think primarly it was due to the times. There was more variety back then perhaps, and fewer cases of the same compiler (gcc) being on multiple systems or the same kernels being on multiple processors. For example, Solaris.common would not have made sense, there was just 32bit SPARC. For example, Linux.common would not have made sense, there was just x86. FreeBSD/OpenBSD/NetBSD all fairly young too. Ultimately I gather..and I haven't gotten here yet, but ultimately I think the tinkering escapes to chroot, whereupon from our point of view it ceases being tinkering. The contents of the files might change but the the names are restored to normal. :) As well though, the mad tinkerer is root? And is ok editing text files outside of /etc? - Jay From jay.krell at cornell.edu Tue Aug 4 02:18:06 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 4 Aug 2009 00:18:06 +0000 Subject: [M3devel] FW: HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: <20090803223710.GE25621@topoi.pooq.com> References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803212936.GA25621@topoi.pooq.com> <20090803223710.GE25621@topoi.pooq.com> Message-ID: [was truncated] ---------------------------------------- > From: jay.krell at cornell.edu > To: hendrik at topoi.pooq.com; m3devel at elegosoft.com > Subject: RE: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig > Date: Mon, 3 Aug 2009 23:42:12 +0000 > > >> That is exactly the mad scientist whill want when he's tinkering with >> deviant Modula 3 compilers. But it's not what the average user will >> want. And it's not what the mad compiler tinkerer will want when he's >> just compiling ordinary programs. So let an environment variable >> override whatever else would be used to find the configuration file. >> And leave it undefined for the average user. > > > I have been a proponent of what you say. > And I have tried to achieve it. > > > However it is not clear if I got there. > > > The system-wide library paths, one example, > are what the "(mad) Linux tinkerer" might > alter, once and be done, not merely the > "compiler tinkerer". There may be too many such people. > > > Even for the mad tinkerer to have his own > system-wide gcc might be common? > Again, more of a "once and be done" mode, > not often changing? > > > The config files ultimately don't even that much. > The previous authors did factor them fairly well. > Just not /quite/ enough to my taste. :) > I think primarly it was due to the times. > There was more variety back then perhaps, and fewer > cases of the same compiler (gcc) being on multiple > systems or the same kernels being on multiple processors. > > > For example, Solaris.common would not have made sense, there was just 32bit SPARC. > For example, Linux.common would not have made sense, there was just x86. > FreeBSD/OpenBSD/NetBSD all fairly young too. > > > Ultimately I gather..and I haven't gotten here yet, > but ultimately I think the tinkering escapes to chroot, > whereupon from our point of view it ceases being tinkering. > The contents of the files might change but the the names > are restored to normal. :) > > > As well though, the mad tinkerer is root? > And is ok editing text files outside of /etc? > > > > - Jay From hendrik at topoi.pooq.com Tue Aug 4 02:27:54 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 3 Aug 2009 20:27:54 -0400 Subject: [M3devel] testing RC2. Message-ID: <20090804002754.GF25621@topoi.pooq.com> Now that I've updated the wikipedia entry, it's easier to find the RC2 downloads page. How can I update the other places that are easy to find on the google? Specifically, the Modula 3 resource page, www.modula3.org/ Modula-3 Frequently Asked Questions (FAQ), www.faqs.org/faqs/Modula-3-faq/ I'll soon be trying another installation fromscratch, using RC2, and I'll let you know how it went. -- hendrik From hendrik at topoi.pooq.com Tue Aug 4 02:38:27 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 3 Aug 2009 20:38:27 -0400 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: References: <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803212936.GA25621@topoi.pooq.com> <20090803223710.GE25621@topoi.pooq.com> Message-ID: <20090804003826.GG25621@topoi.pooq.com> On Mon, Aug 03, 2009 at 11:42:12PM +0000, Jay K wrote: > > > That is exactly the mad scientist whill want when he's tinkering with > > deviant Modula 3 compilers. But it's not what the average user will > > want. And it's not what the mad compiler tinkerer will want when he's > > just compiling ordinary programs. So let an environment variable > > override whatever else would be used to find the configuration file. > > And leave it undefined for the average user. > > > I have been a proponent of what you say. > And I have tried to achieve it. > > > However it is not clear if I got there. > > > The system-wide library paths, one example, > are what the "(mad) Linux tinkerer" might > alter, once and be done, not merely the > "compiler tinkerer". There may be too many such people. I was thinking of the mad scientist who writes his own variations into Modula 3, and wants to use his version without it getting mixed up with the standard one available on his system. He'd want his own m3 configuration file for sure. As for the OS's other paths, on Linux the OS provides those, and lets them be overridden by the user as environment variables. He'd just better make sure they point to the ones he needs. That's his job, not ours. I'm not advocating replacing the OS. That's someone else's job, too. oh... wait a moment. Didn't we try something like that with SPIN (for suitable values of "we" that don't include "me")? -- hendrik From jay.krell at cornell.edu Tue Aug 4 02:59:32 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Mon, 3 Aug 2009 17:59:32 -0700 Subject: [M3devel] testing RC2. In-Reply-To: <20090804002754.GF25621@topoi.pooq.com> References: <20090804002754.GF25621@topoi.pooq.com> Message-ID: <1C5F772D-930B-472B-A83B-32DEC364D2FA@hotmail.com> Wikipedia: Aren't you subverting release manager Olaf? Not ready for exposure beyond m3devel? - Jay (phone) On Aug 3, 2009, at 5:27 PM, hendrik at topoi.pooq.com wrote: > Now that I've updated the wikipedia entry, it's easier to find the RC2 > downloads page. > > How can I update the other places that are easy to find on the google? > Specifically, > the Modula 3 resource page, www.modula3.org/ > Modula-3 Frequently Asked Questions (FAQ), > www.faqs.org/faqs/Modula-3-faq/ > > I'll soon be trying another installation fromscratch, using RC2, > and I'll let you know how it went. > > -- hendrik > > From wagner at elegosoft.com Tue Aug 4 08:40:32 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 04 Aug 2009 08:40:32 +0200 Subject: [M3devel] /etc/cm3.cfg (was: HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig) In-Reply-To: <1249334501.28197.750.camel@faramir.m3w.org> References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> <1249334501.28197.750.camel@faramir.m3w.org> Message-ID: <20090804084032.m4ytooeqs04cokcs@mail.elegosoft.com> Quoting Dragi?a Duri? : > On Mon, 2009-08-03 at 23:15 +0200, Olaf Wagner wrote: >> The compiler searches in a list of locations and takes the first >> one found, as is the convention when doing path searches. AFAIK >> /etc is currently the last option at all. > > Tried this today, and what happened was - cm3 set PKG_INSTALL to "/" and > I was unable to build anything until I moved cm3.cfg back to where cm3 > binary is. Well, this is just a matter of the correct contents of the configuration files then. Jay has tailored the suite to be located in .../cm3 currently. Nobody stops you to set PKG_INSTALL and other variables at the top level. If you use a 'non-standard' setup, then the files must be adapted. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Tue Aug 4 09:50:05 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 04 Aug 2009 09:50:05 +0200 Subject: [M3devel] /etc/cm3.cfg (was: HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig) In-Reply-To: <20090804084032.m4ytooeqs04cokcs@mail.elegosoft.com> References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> <1249334501.28197.750.camel@faramir.m3w.org> <20090804084032.m4ytooeqs04cokcs@mail.elegosoft.com> Message-ID: <1249372205.28197.1238.camel@faramir.m3w.org> On Tue, 2009-08-04 at 08:40 +0200, Olaf Wagner wrote: > Well, this is just a matter of the correct contents of the > configuration > files then. Jay has tailored the suite to be located in .../cm3 > currently. Nobody stops you to set PKG_INSTALL and other variables > at the top level. If you use a 'non-standard' setup, then the files > must be adapted. Figured it all out.. As cm3.cfg is twoliner, I've only created it from my RPM recipe with exact PKG_INSTALL location... Another question... While here... is there a separation of runtime and development packages in RELENG process? -- Dragi?a Duri? From wagner at elegosoft.com Tue Aug 4 10:22:54 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 04 Aug 2009 10:22:54 +0200 Subject: [M3devel] some cvs errors? In-Reply-To: References: <20090803131445.d5u1i1vaf484kg4s@mail.elegosoft.com> Message-ID: <20090804102254.yakamff0ysscccs8@mail.elegosoft.com> Quoting Jay K : > > One error, the second one, was maybe local, not on the server. > I saw it again later while running make-dist.sh, it tries to update itself. > Not clear why it occured here, maybe I had one running and the use > of $Id$ caused an attempted and failed write. Or maybe the error was > on the server. With CVS, can't be sure of much imho. > The other seems ok. > +2 for replacing cvs with something better.. after we invent more time... That something better would then be Perforce or AccuRev? Elego has got 3 committers to the Subversion project, and there are lots of problems, too. We've got several customers who are regularly pushing it over the edge of its capabilities... But I'm not against a change, as long as others will do the work ;-) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Aug 4 10:26:27 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 04 Aug 2009 10:26:27 +0200 Subject: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig In-Reply-To: <20090803214902.GB25621@topoi.pooq.com> References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> <20090803214902.GB25621@topoi.pooq.com> Message-ID: <20090804102627.bh1po5bfk0s4ggwo@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > One could have the configuration file contain the locations where to > find other configuration file(s). The file names in tis file could have > explicit notations indicating "where the compiler is", "current > directory", "User's home directory", "check the environment variable", > and so forth. > > This would make things somewhat more flexible, It's not clear whether > the added complexity would get in our way. That's just a matter of adding the appropriate quake code, isn't it? All that flexibility is already there. Getting such things correct in the details is much work though. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Aug 4 10:44:24 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 04 Aug 2009 10:44:24 +0200 Subject: [M3devel] /etc/cm3.cfg (was: HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig) In-Reply-To: <1249372205.28197.1238.camel@faramir.m3w.org> References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> <1249334501.28197.750.camel@faramir.m3w.org> <20090804084032.m4ytooeqs04cokcs@mail.elegosoft.com> <1249372205.28197.1238.camel@faramir.m3w.org> Message-ID: <20090804104424.zh0k8n7nvo8sk80g@mail.elegosoft.com> Quoting Dragi?a Duri? : > On Tue, 2009-08-04 at 08:40 +0200, Olaf Wagner wrote: >> Well, this is just a matter of the correct contents of the >> configuration >> files then. Jay has tailored the suite to be located in .../cm3 >> currently. Nobody stops you to set PKG_INSTALL and other variables >> at the top level. If you use a 'non-standard' setup, then the files >> must be adapted. > > Figured it all out.. As cm3.cfg is twoliner, I've only created it from > my RPM recipe with exact PKG_INSTALL location... > > Another question... While here... is there a separation of runtime and > development packages in RELENG process? Not really. The only real `runtime package' we currently have would be cm3-ws-bin-min..., containing m3core and libm3. But then you'r probably thinking of `binary' packages and `source packages', aren't you? M3 doesn't really do these distinctions... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Aug 4 10:58:35 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 04 Aug 2009 10:58:35 +0200 Subject: [M3devel] testing RC2. In-Reply-To: <1C5F772D-930B-472B-A83B-32DEC364D2FA@hotmail.com> References: <20090804002754.GF25621@topoi.pooq.com> <1C5F772D-930B-472B-A83B-32DEC364D2FA@hotmail.com> Message-ID: <20090804105835.vs1925r2kg480ccg@mail.elegosoft.com> Quoting jay.krell at cornell.edu: > Wikipedia: Aren't you subverting release manager Olaf? Not ready for > exposure beyond m3devel? I just moved the date for RC2 another week :-/ Too many things still to be done. See https://projects.elego.de/cm3/milestone/CM3%20Release%205.8%20RC2 We need o to improve the WWW presentation (there were suggestions from Peter Eiserloh and others but no concrete changes/commits AFAIK) o build some missing installation packages (for I386_DARWIN for example) o automate some installation tests (next thing I'll do) o get some feedback from manual tests If there are no commits to the web pages till Wednesday, I'll make some small adaptions there to be ready for RC2 then. Olaf > - Jay (phone) > > On Aug 3, 2009, at 5:27 PM, hendrik at topoi.pooq.com wrote: > >> Now that I've updated the wikipedia entry, it's easier to find the RC2 >> downloads page. >> >> How can I update the other places that are easy to find on the google? >> Specifically, >> the Modula 3 resource page, www.modula3.org/ >> Modula-3 Frequently Asked Questions (FAQ), >> www.faqs.org/faqs/Modula-3-faq/ >> >> I'll soon be trying another installation fromscratch, using RC2, >> and I'll let you know how it went. >> >> -- hendrik >> >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Tue Aug 4 13:16:47 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 04 Aug 2009 13:16:47 +0200 Subject: [M3devel] runtime/devel separation. was: Re: /etc/cm3.cfg (was: HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig) In-Reply-To: <20090804104424.zh0k8n7nvo8sk80g@mail.elegosoft.com> References: <4A763446.1E75.00D7.1@scires.com> <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> <1249334501.28197.750.camel@faramir.m3w.org> <20090804084032.m4ytooeqs04cokcs@mail.elegosoft.com> <1249372205.28197.1238.camel@faramir.m3w.org> <20090804104424.zh0k8n7nvo8sk80g@mail.elegosoft.com> Message-ID: <1249384607.28197.1251.camel@faramir.m3w.org> On Tue, 2009-08-04 at 10:44 +0200, Olaf Wagner wrote: > Not really. > > The only real `runtime package' we currently have would be > cm3-ws-bin-min..., containing m3core and libm3. > > But then you'r probably thinking of `binary' packages and > `source packages', aren't you? M3 doesn't really do these > distinctions... No, I am not thinking about source packages. These we have - tar.gz's packed with building recipes. What I did in my RPM packaging is to separate contents (roughly): $BIN_INSTALL except compiler/debugger/related tools, $LIB_INSTALL and $PKG_INSTALL/*/$BUILD_DIR, /etc/cm3.cfg, /etc/cm3/ --> into runtime compiler/debugger, $PKG_INSTALL/*/src --> into development This way I can have my packages installed without library/program source shipped to end user. In case I need them, I just pull -devel package. I am using this scheme for some time now. What I have to work on is man1 vs. man7 and similar. Little bits and pieces. -- Dragi?a Duri? From jay.krell at cornell.edu Tue Aug 4 13:40:53 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 4 Aug 2009 11:40:53 +0000 Subject: [M3devel] some cvs errors? In-Reply-To: <20090804102254.yakamff0ysscccs8@mail.elegosoft.com> References: <20090803131445.d5u1i1vaf484kg4s@mail.elegosoft.com> <20090804102254.yakamff0ysscccs8@mail.elegosoft.com> Message-ID: Perforce is great. I'm already trained. If we can get a good deal (for being opensource) on it and someone provides hosting (with a good deal). I could never find anyone to host it. So I went with Date: Tue, 4 Aug 2009 10:22:54 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; m3-support at elego.de > Subject: Re: [M3devel] some cvs errors? > > Quoting Jay K : > >> >> One error, the second one, was maybe local, not on the server. >> I saw it again later while running make-dist.sh, it tries to update itself. >> Not clear why it occured here, maybe I had one running and the use >> of $Id$ caused an attempted and failed write. Or maybe the error was >> on the server. With CVS, can't be sure of much imho. >> The other seems ok. >> +2 for replacing cvs with something better.. after we invent more time... > > That something better would then be Perforce or AccuRev? > > Elego has got 3 committers to the Subversion project, and there are > lots of problems, too. We've got several customers who are regularly > pushing it over the edge of its capabilities... > > But I'm not against a change, as long as others will do the work ;-) > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Tue Aug 4 13:47:32 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 4 Aug 2009 11:47:32 +0000 Subject: [M3devel] some cvs errors? In-Reply-To: <20090804102254.yakamff0ysscccs8@mail.elegosoft.com> References: <20090803131445.d5u1i1vaf484kg4s@mail.elegosoft.com> <20090804102254.yakamff0ysscccs8@mail.elegosoft.com> Message-ID: Don't know what happened there..lost the content. Just that I use subversion at home, no branching, cheap. Subversion seems to do branching horribly though. Perforce does it maybe perfectly. Mercurial and monotone and git all sound good. If someone else does it, agreed. They pretty much all claim pretty good easy conversion. Not perfect, but ok. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > CC: m3devel at elegosoft.com; m3-support at elego.de > Subject: RE: [M3devel] some cvs errors? > Date: Tue, 4 Aug 2009 11:40:53 +0000 > > > Perforce is great. I'm already trained. > If we can get a good deal (for being opensource) on it and someone provides hosting (with a good deal). > I could never find anyone to host it. > So I went with Date: Tue, 4 Aug 2009 10:22:54 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com; m3-support at elego.de >> Subject: Re: [M3devel] some cvs errors? >> >> Quoting Jay K : >> >>> >>> One error, the second one, was maybe local, not on the server. >>> I saw it again later while running make-dist.sh, it tries to update itself. >>> Not clear why it occured here, maybe I had one running and the use >>> of $Id$ caused an attempted and failed write. Or maybe the error was >>> on the server. With CVS, can't be sure of much imho. >>> The other seems ok. >>> +2 for replacing cvs with something better.. after we invent more time... >> >> That something better would then be Perforce or AccuRev? >> >> Elego has got 3 committers to the Subversion project, and there are >> lots of problems, too. We've got several customers who are regularly >> pushing it over the edge of its capabilities... >> >> But I'm not against a change, as long as others will do the work ;-) >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> From jay.krell at cornell.edu Tue Aug 4 13:49:29 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 4 Aug 2009 11:49:29 +0000 Subject: [M3devel] testing RC2. In-Reply-To: <20090804105835.vs1925r2kg480ccg@mail.elegosoft.com> References: <20090804002754.GF25621@topoi.pooq.com> <1C5F772D-930B-472B-A83B-32DEC364D2FA@hotmail.com> <20090804105835.vs1925r2kg480ccg@mail.elegosoft.com> Message-ID: > build some missing installation packages (for I386_DARWIN for example) I have a new computer arriving roughly Friday on which I can setup near arbitrary x86/AMD64 VMs, as well as doing native I386_DARWIN and AMD64_DARWIN. AMD64_FREEBSD is also missing for example. Tony should also be able to do {I386,AMD64}_DARWIN. - Jay ---------------------------------------- > Date: Tue, 4 Aug 2009 10:58:35 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] testing RC2. > > Quoting jay.krell at cornell.edu: > >> Wikipedia: Aren't you subverting release manager Olaf? Not ready for >> exposure beyond m3devel? > > I just moved the date for RC2 another week :-/ Too many things still > to be done. See > > https://projects.elego.de/cm3/milestone/CM3%20Release%205.8%20RC2 > > We need > > o to improve the WWW presentation (there were suggestions from > Peter Eiserloh and others but no concrete changes/commits AFAIK) > > o build some missing installation packages (for I386_DARWIN for example) > > o automate some installation tests (next thing I'll do) > > o get some feedback from manual tests > > If there are no commits to the web pages till Wednesday, I'll make > some small adaptions there to be ready for RC2 then. > > Olaf > >> - Jay (phone) >> >> On Aug 3, 2009, at 5:27 PM, hendrik at topoi.pooq.com wrote: >> >>> Now that I've updated the wikipedia entry, it's easier to find the RC2 >>> downloads page. >>> >>> How can I update the other places that are easy to find on the google? >>> Specifically, >>> the Modula 3 resource page, www.modula3.org/ >>> Modula-3 Frequently Asked Questions (FAQ), >>> www.faqs.org/faqs/Modula-3-faq/ >>> >>> I'll soon be trying another installation fromscratch, using RC2, >>> and I'll let you know how it went. >>> >>> -- hendrik >>> >>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From rcoleburn at scires.com Tue Aug 4 17:09:32 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 04 Aug 2009 11:09:32 -0400 Subject: [M3devel] some cvs errors? In-Reply-To: <20090804102254.yakamff0ysscccs8@mail.elegosoft.com> References: <20090803131445.d5u1i1vaf484kg4s@mail.elegosoft.com> <20090804102254.yakamff0ysscccs8@mail.elegosoft.com> Message-ID: <4A78164A.1E75.00D7.1@scires.com> As far as replacing CVS with something else, I have "no dog in the race" so to speak, but I will say that CVS has worked fine for my purposes and the TortoiseCVS integration with Windows Explorer makes life easy for me on Windows. I don't have to remember all the CVS command line switches; I just use the TortoiseCVS GUI and it works. If we switch to something else that doesn't have this level of GUI, it will present a learning curve for me. Regards, Randy Coleburn >>> Olaf Wagner 8/4/2009 4:22 AM >>> Quoting Jay K : > > One error, the second one, was maybe local, not on the server. > I saw it again later while running make-dist.sh, it tries to update itself. > Not clear why it occured here, maybe I had one running and the use > of $Id$ caused an attempted and failed write. Or maybe the error was > on the server. With CVS, can't be sure of much imho. > The other seems ok. > +2 for replacing cvs with something better.. after we invent more time... That something better would then be Perforce or AccuRev? Elego has got 3 committers to the Subversion project, and there are lots of problems, too. We've got several customers who are regularly pushing it over the edge of its capabilities... But I'm not against a change, as long as others will do the work ;-) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Tue Aug 4 17:22:56 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 4 Aug 2009 11:22:56 -0400 Subject: [M3devel] /etc/cm3.cfg (was: HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig) In-Reply-To: <20090804104424.zh0k8n7nvo8sk80g@mail.elegosoft.com> References: <20090803123054.5ypqf469q8o48k04@mail.elegosoft.com> <20090803172537.m3ei7prs5cwks8ks@mail.elegosoft.com> <20090803231545.vwg4g6tk8o4wgsgc@mail.elegosoft.com> <1249334501.28197.750.camel@faramir.m3w.org> <20090804084032.m4ytooeqs04cokcs@mail.elegosoft.com> <1249372205.28197.1238.camel@faramir.m3w.org> <20090804104424.zh0k8n7nvo8sk80g@mail.elegosoft.com> Message-ID: <20090804152255.GA27699@topoi.pooq.com> On Tue, Aug 04, 2009 at 10:44:24AM +0200, Olaf Wagner wrote: > Quoting Dragi?a Duri? : > > >On Tue, 2009-08-04 at 08:40 +0200, Olaf Wagner wrote: > >>Well, this is just a matter of the correct contents of the > >>configuration > >>files then. Jay has tailored the suite to be located in .../cm3 > >>currently. Nobody stops you to set PKG_INSTALL and other variables > >>at the top level. If you use a 'non-standard' setup, then the files > >>must be adapted. > > > >Figured it all out.. As cm3.cfg is twoliner, I've only created it from > >my RPM recipe with exact PKG_INSTALL location... > > > >Another question... While here... is there a separation of runtime and > >development packages in RELENG process? > > Not really. > > The only real `runtime package' we currently have would be > cm3-ws-bin-min..., containing m3core and libm3. > > But then you'r probably thinking of `binary' packages and > `source packages', aren't you? M3 doesn't really do these distinctions... The distinction is what you need to run an executable image that uses libraries, versus what you need to compile things using them. M3 may not enable you to compile a library-using application without the library source code, but it should enable you to run the compiled code without it. That said, for the current release, I don't see it to be important to make the distinctio for the current release. It's more important to make available something up-to-date and reliably usable out soon so that people can use it. -- hendrik From hendrik at topoi.pooq.com Tue Aug 4 17:37:21 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 4 Aug 2009 11:37:21 -0400 Subject: [M3devel] testing RC2. In-Reply-To: <1C5F772D-930B-472B-A83B-32DEC364D2FA@hotmail.com> References: <20090804002754.GF25621@topoi.pooq.com> <1C5F772D-930B-472B-A83B-32DEC364D2FA@hotmail.com> Message-ID: <20090804153721.GC27699@topoi.pooq.com> On Mon, Aug 03, 2009 at 05:59:32PM -0700, jay.krell at cornell.edu wrote: > Wikipedia: Aren't you subverting release manager Olaf? Not ready for > exposure beyond m3devel? > > - Jay (phone) I asked in this list shortly before my vacation, and someone gave the go-ahead. If it's a problem, let me know, and I'll gladly revert the change. The entry I provided does say it's the place to go for release candidates, and I intend to replace it with a pinter to the real release when it's ready. Given the difficulty of finding any usable m3 implementation after the great file-system disaster, I thought this was an essential interim measure. > > On Aug 3, 2009, at 5:27 PM, hendrik at topoi.pooq.com wrote: > > >Now that I've updated the wikipedia entry, it's easier to find the RC2 > >downloads page. > > > >How can I update the other places that are easy to find on the google? > >Specifically, > > the Modula 3 resource page, www.modula3.org/ > > Modula-3 Frequently Asked Questions (FAQ), > > www.faqs.org/faqs/Modula-3-faq/ > > > >I'll soon be trying another installation fromscratch, using RC2, > >and I'll let you know how it went. > > > >-- hendrik > > > > From hendrik at topoi.pooq.com Tue Aug 4 17:49:27 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 4 Aug 2009 11:49:27 -0400 Subject: [M3devel] some cvs errors? In-Reply-To: <20090804102254.yakamff0ysscccs8@mail.elegosoft.com> References: <20090803131445.d5u1i1vaf484kg4s@mail.elegosoft.com> <20090804102254.yakamff0ysscccs8@mail.elegosoft.com> Message-ID: <20090804154927.GD27699@topoi.pooq.com> On Tue, Aug 04, 2009 at 10:22:54AM +0200, Olaf Wagner wrote: > Quoting Jay K : > > > > >One error, the second one, was maybe local, not on the server. > > I saw it again later while running make-dist.sh, it tries to update > > itself. > > Not clear why it occured here, maybe I had one running and the use > >of $Id$ caused an attempted and failed write. Or maybe the error was > > on the server. With CVS, can't be sure of much imho. > >The other seems ok. > >+2 for replacing cvs with something better.. after we invent more time... > > That something better would then be Perforce or AccuRev? > > Elego has got 3 committers to the Subversion project, and there are > lots of problems, too. We've got several customers who are regularly > pushing it over the edge of its capabilities... > > But I'm not against a change, as long as others will do the work ;-) > > Olaf I'm being slow on teh cvs->monotone conversion project I was looking into. Once again, sorry. Other things, ostly personal, keep getting in the way. One thing that's delaying it is that I see no point in doing the conversion while we're in the throes of getting a release out. It looks as if the conversion, should we go through with it, will be one-way; that is, monotone will not conveniently pass updates on to cvs. I don't know yet whether it will be possible to regularly pass cvs changes on to monotone, though. It would be a lot easier if it were. -- hendrik From wagner at elegosoft.com Tue Aug 4 17:54:04 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 04 Aug 2009 17:54:04 +0200 Subject: [M3devel] testing RC2. Message-ID: <20090804175404.k6tkhj4i6804ck4c@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > On Mon, Aug 03, 2009 at 05:59:32PM -0700, jay.krell at cornell.edu wrote: >> Wikipedia: Aren't you subverting release manager Olaf? Not ready for >> exposure beyond m3devel? >> >> - Jay (phone) > > I asked in this list shortly before my vacation, and someone gave the > go-ahead. > > If it's a problem, let me know, and I'll gladly revert the change. > > The entry I provided does say it's the place to go for release > candidates, and I intend to replace it with a pinter to the real release > when it's ready. > > Given the difficulty of finding any usable m3 implementation after the > great file-system disaster, I thought this was an essential interim > measure. I think it's OK now; several tests have passed successfully. I'll try to improve the web pages on Wednesday evening, unless someone does that before (hint!). Peter Eiserloh sent several suggestions. Hopefully we'll finally deliver at the next weekend :-) Olaf > > >> >> On Aug 3, 2009, at 5:27 PM, hendrik at topoi.pooq.com wrote: >> >> >Now that I've updated the wikipedia entry, it's easier to find the RC2 >> >downloads page. >> > >> >How can I update the other places that are easy to find on the google? >> >Specifically, >> > the Modula 3 resource page, www.modula3.org/ >> > Modula-3 Frequently Asked Questions (FAQ), >> > www.faqs.org/faqs/Modula-3-faq/ >> > >> >I'll soon be trying another installation fromscratch, using RC2, >> >and I'll let you know how it went. >> > >> >-- hendrik >> > >> > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Aug 4 17:56:26 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 04 Aug 2009 17:56:26 +0200 Subject: [M3devel] automated installation tests on Hudson Message-ID: <20090804175626.xtce1l8jnoc844s8@mail.elegosoft.com> It's not much, but a start: http://hudson.modula3.com:8080/view/test-install/ SOLgnu and SOLsun packages should also be complete tomorrow. Some installation problems found though, but they won't stop the release. That's it for today, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From neels at elego.de Wed Aug 5 00:12:59 2009 From: neels at elego.de (Neels J Hofmeyr) Date: Wed, 05 Aug 2009 00:12:59 +0200 Subject: [M3devel] some cvs errors? In-Reply-To: <4A78164A.1E75.00D7.1@scires.com> References: <20090803131445.d5u1i1vaf484kg4s@mail.elegosoft.com> <20090804102254.yakamff0ysscccs8@mail.elegosoft.com> <4A78164A.1E75.00D7.1@scires.com> Message-ID: <4A78B26B.2010207@elego.de> Randy Coleburn wrote: > > As far as replacing CVS with something else, I have "no dog in the race" > so to speak, but I will say that CVS has worked fine for my purposes and > the TortoiseCVS integration with Windows Explorer makes life easy for me Well, there is TortoiseSVN. I'm not convinced that the branching strategies needed for CM3 dev would indeed push svn over the edge of its capabilities -- not if CVS worked fine all these years. And I would certainly prefer a free SCM to one with a price tag and a restrictive license. You guessed it, one of the Subversion committers speaking ;) ...and this discussion remains empty until anyone wants to actually do the work ;) ~Neels > on Windows. I don't have to remember all the CVS command line switches; > I just use the TortoiseCVS GUI and it works. If we switch to something > else that doesn't have this level of GUI, it will present a learning > curve for me. > Regards, > Randy Coleburn > >>>> Olaf Wagner 8/4/2009 4:22 AM >>> > Quoting Jay K : > >> >> One error, the second one, was maybe local, not on the server. >> I saw it again later while running make-dist.sh, it tries to update > itself. >> Not clear why it occured here, maybe I had one running and the use >> of $Id$ caused an attempted and failed write. Or maybe the error was >> on the server. With CVS, can't be sure of much imho. >> The other seems ok. >> +2 for replacing cvs with something better.. after we invent more time... > > That something better would then be Perforce or AccuRev? > > Elego has got 3 committers to the Subversion project, and there are > lots of problems, too. We've got several customers who are regularly > pushing it over the edge of its capabilities... > > But I'm not against a change, as long as others will do the work ;-) > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From wagner at elegosoft.com Wed Aug 5 13:18:42 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 05 Aug 2009 13:18:42 +0200 Subject: [M3devel] SOLgnu still broken on ssol Message-ID: <20090805131842.5ha3ycwcbkkc448s@mail.elegosoft.com> The SOLgnu builds are still broken, though the makedist job claims to be successful (still need to fix the script): === package m3-libs/m3core === +++ cm3 -build -override $RARGS -DROOT='/home/hudson/workspace/cm3-makedist-SOLgnu/cm3' -DCM3_VERSION_TEXT='d5.8.2' -DCM3_VERSION_NUMBER='050802' -DCM3_LAST_CHANGED='2009-07-15' +++ ld: fatal: relocation error: R_SPARC_32: file RTMachineASM.o: symbol : offset 0xfd951bee is non-aligned ld: fatal: relocation error: R_SPARC_32: file RTMachineASM.o: symbol : offset 0xfd951bf2 is non-aligned ld: fatal: relocation error: R_SPARC_32: file RTMachineASM.o: symbol : offset 0xfd951bf6 is non-aligned ld: fatal: relocation error: R_SPARC_32: file RTMachineASM.o: symbol : offset 0xfd95d2bf is non-aligned ld: fatal: relocation error: R_SPARC_32: file RTMachineASM.o: symbol : offset 0xfd9669ce is non-aligned collect2: ld returned 1 exit status make_lib => 1 librarian failed building: m3core See http://hudson.modula3.com:8080/view/SOLgnu/job/cm3-makedist-SOLgnu/3/consoleFull for more details. Argh... I forgot to include the path preference for /usr/local again to use the pre-built gcc. Now it will run another 4 hours... SOLsun seems to be OK. I'll run the installation tests on it soon. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From lists at darko.org Wed Aug 5 14:06:54 2009 From: lists at darko.org (Darko Volaric) Date: Wed, 5 Aug 2009 14:06:54 +0200 Subject: [M3devel] some cvs errors? In-Reply-To: <4A78B26B.2010207@elego.de> References: <20090803131445.d5u1i1vaf484kg4s@mail.elegosoft.com> <20090804102254.yakamff0ysscccs8@mail.elegosoft.com> <4A78164A.1E75.00D7.1@scires.com> <4A78B26B.2010207@elego.de> Message-ID: <825BD2B1-CCCE-4906-A666-CAA1AE0C3CAB@darko.org> Has anyone considered git? It seems particularly well suited to distributed development, having been essentially designed for open source groups, and seems to be undergoing intensive development. On 05/08/2009, at 12:12 AM, Neels J Hofmeyr wrote: > Randy Coleburn wrote: >> >> As far as replacing CVS with something else, I have "no dog in the >> race" >> so to speak, but I will say that CVS has worked fine for my >> purposes and >> the TortoiseCVS integration with Windows Explorer makes life easy >> for me > > Well, there is TortoiseSVN. > > I'm not convinced that the branching strategies needed for CM3 dev > would > indeed push svn over the edge of its capabilities -- not if CVS > worked fine > all these years. > > And I would certainly prefer a free SCM to one with a price tag and a > restrictive license. You guessed it, one of the Subversion committers > speaking ;) > > ...and this discussion remains empty until anyone wants to actually > do the > work ;) > ~Neels > >> on Windows. I don't have to remember all the CVS command line >> switches; >> I just use the TortoiseCVS GUI and it works. If we switch to >> something >> else that doesn't have this level of GUI, it will present a learning >> curve for me. >> Regards, >> Randy Coleburn >> >>>>> Olaf Wagner 8/4/2009 4:22 AM >>> >> Quoting Jay K : >> >>> >>> One error, the second one, was maybe local, not on the server. >>> I saw it again later while running make-dist.sh, it tries to update >> itself. >>> Not clear why it occured here, maybe I had one running and the use >>> of $Id$ caused an attempted and failed write. Or maybe the error was >>> on the server. With CVS, can't be sure of much imho. >>> The other seems ok. >>> +2 for replacing cvs with something better.. after we invent more >>> time... >> >> That something better would then be Perforce or AccuRev? >> >> Elego has got 3 committers to the Subversion project, and there are >> lots of problems, too. We've got several customers who are regularly >> pushing it over the edge of its capabilities... >> >> But I'm not against a change, as long as others will do the work ;-) >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >> Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >> 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >> Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 >> > From wagner at elegosoft.com Wed Aug 5 15:54:46 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 05 Aug 2009 15:54:46 +0200 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090803093135.3F59DCC81B@birch.elegosoft.com> <4A76CADA.1E75.00D7.1@scires.com> <4A76FEED.1E75.00D7.1@scires.com> Message-ID: <20090805155446.wgsqqqclm8skggkw@mail.elegosoft.com> I just found this mail... too many of them. Quoting Jay K : > I failed to figure how to move anything at all to RC2 (perhaps that > is by-design, Olaf escalating and using more and more arcane > features of cvs to stay ahead of me), but I moved it to the release > branch, which should get it at least into whatever if anything > follows RC2. This is no arcane feature, just the conventional way to pin a bound configuration. We use the release branch to improve the release quality, and certain points on it are marked with RC1, RC2, ... The CVS concept for bound configurations is called a tag (non-branch tag). RC2 is now in the past. We've already built most of the packages. If there is something really important, we can move the tag again, which means that we will probably have to rebuild a number of installation packages. If it's something that severely breaks the system, we may have to do that. What do you say? > The fix seems fragile though. Converting to a full path would > probably be better. > (Full paths are still contextual, but most people/code seem ok > ignoring that. Could be net used or chroot..) RC3 should be faster, as most of the needed infrastructure is now in place. So it may be best to just know that the fix is in there. Olaf > ________________________________ >> Date: Mon, 3 Aug 2009 15:17:30 -0400 >> From: rcoleburn at scires.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] [M3commit] CVS Update: cm3 >> >> Jay: >> >> Your change to MxConfig.m3 seems to work fine for cm3ide, provided >> that I replace HOST by "NT386" in my cm3.cfg is as follows: >> >> INSTALL_ROOT = path() & "/.." >> include (path() & "/config/NT386") >> >> Thank you! >> >> Can we get your revised MxConfig.m3 put into the RC2 branch? >> >> >> Regards, >> >> Randy >> >>>>> "Randy Coleburn" 8/3/2009 11:35 AM>>> >> >> Jay: >> >> I agree that running cm3 from "bin" folder is not going to be >> productive; however, other programs (such as cm3ide) also use the >> quake stuff and they don't have this limitation. I think your >> change is a good one. I'll run some tests and see how cm3ide fares. >> Thanks. >> >> --Randy >> >>>>> Jay Krell 8/3/2009 11:31 AM>>> >> CVSROOT:/usr/cvs >> Changes by:jkrell at birch.09/08/03 11:31:35 >> >> Modified files: >> cm3/m3-sys/m3quake/src/: MxConfig.m3 >> >> Log message: >> use "." instead of empty string for path() when current working >> directory is the actual directory of cm3; not sure what good >> running cm3 here is, and we probe way too many places.. >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Wed Aug 5 20:50:21 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 05 Aug 2009 20:50:21 +0200 Subject: [M3devel] WWW updates for the release Message-ID: <20090805205021.6ag1s0evoc0cggc0@mail.elegosoft.com> I've made some small additions and updates for the pending release, mostly based on https://projects.elego.de/cm3/ticket/1019. Some target platform archives are still missing, but we can add them during the next days. I'd like to have some broader feedback now if possible. The following topics are still unaddressed; perhaps anybody cares to fill them in: (c) The major changes to the compiler should be listed somewhere, since the last release shown on the download page. Right now the last release indicated is 5.4. There are some snapshots of 5.5, but not final release of 5.5. 3 - About-CM3: The "About CM3" page, should have a section listing all the changes / enhancements to the language that it accepts vice that described in the language reference from Nelson's SPWM3. For example, WIDECHAR, LONGINT are two new primitive types. Also list all the pragmas recognized by the compiler as that is a compiler unique issue. http://opencm3.net/about-cm3.html It should also list all the architectures that are supported by the compiler. These should always reflect those of the latest "release" version of the compiler. Please note that the latest changes are only checked-in on the release branch. Everything will be merged back to the main trunk later. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Fri Aug 7 11:56:24 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 07 Aug 2009 11:56:24 +0200 Subject: [M3devel] More Unix constants missing.... Message-ID: <1249638984.2745.11.camel@faramir.m3w.org> Can we have them, in both HEAD ad RC2 branch? TIA, dd === CONST TIOCMGET = 16_5415; TIOCMSET = 16_5418; Bits = ARRAY StatusBits OF CARDINAL { Unix.TIOCM_LE, Unix.TIOCM_DTR, Unix.TIOCM_RTS, Unix.TIOCM_ST, Unix.TIOCM_SR, Unix.TIOCM_CTS, Unix.TIOCM_CAR, Unix.TIOCM_RNG, Unix.TIOCM_DSR }; -- Dragi?a Duri? From wagner at elegosoft.com Fri Aug 7 12:18:07 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 07 Aug 2009 12:18:07 +0200 Subject: [M3devel] More Unix constants missing.... In-Reply-To: <1249638984.2745.11.camel@faramir.m3w.org> References: <1249638984.2745.11.camel@faramir.m3w.org> Message-ID: <20090807121807.ydy78qp4oww0og0c@mail.elegosoft.com> Quoting Dragi?a Duri? : > Can we have them, in both HEAD ad RC2 branch? > > TIA, > dd > > === > CONST > TIOCMGET = 16_5415; > TIOCMSET = 16_5418; > > Bits = ARRAY StatusBits OF CARDINAL { > Unix.TIOCM_LE, > Unix.TIOCM_DTR, > Unix.TIOCM_RTS, > Unix.TIOCM_ST, > Unix.TIOCM_SR, > Unix.TIOCM_CTS, > Unix.TIOCM_CAR, > Unix.TIOCM_RNG, > Unix.TIOCM_DSR > }; > > -- > Dragi?a Duri? If additional constants are missing, just merge them over to the release branch. There is no RC2 branch by the way and will never be. RC2 was just one version several days ago on the 5.8 release branch. If you want me to do it, knowing the file(s) and versions involved would certainly help ;-) As I'm not at home this weekend, it may take some time though. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Fri Aug 7 12:35:38 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 07 Aug 2009 12:35:38 +0200 Subject: [M3devel] More Unix constants missing.... In-Reply-To: <20090807121807.ydy78qp4oww0og0c@mail.elegosoft.com> References: <1249638984.2745.11.camel@faramir.m3w.org> <20090807121807.ydy78qp4oww0og0c@mail.elegosoft.com> Message-ID: <1249641338.2745.13.camel@faramir.m3w.org> I am not at home with CVS, really. It's probably 22 seconds job for Jay-who-cut-them-out-in-the-first-place :). I can make fast fix in my code till I wait proper one, in line with nest style guidelines for UNIX constants. On Fri, 2009-08-07 at 12:18 +0200, Olaf Wagner wrote: > If additional constants are missing, just merge them over to the > release branch. There is no RC2 branch by the way and will never be. > RC2 was just one version several days ago on the 5.8 release branch. > > If you want me to do it, knowing the file(s) and versions involved > would certainly help ;-) As I'm not at home this weekend, it may take > some time though. -- Dragi?a Duri? From hendrik at topoi.pooq.com Sat Aug 8 13:46:19 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sat, 8 Aug 2009 07:46:19 -0400 Subject: [M3devel] trouble with RC2 -- maybe with hudson? Message-ID: <20090808114619.GA3806@topoi.pooq.com> Installing cm3-bin-core-LINUXLIBC6-d5.8.2-RC2.tgz on my 32-bit intel Debian squeeze laptop went fine. But when I tried cm3-bin-core-LINUXLIBC6-d5.8.2-RC2.tgz (downloaded a few days ago) I got: hendrik at notlookedfor:~/cm3$ mkdir gui hendrik at notlookedfor:~/cm3$ cd gui hendrik at notlookedfor:~/cm3/gui$ tar -zxf ../../Desktop/cm3-bin-ws-gui-LINUXLIBC6-d5.8.2-RC2.tgz hendrik at notlookedfor:~/cm3/gui$ ls collection-gui.html install.sh m3-comm m3-tools m3-ui m3-win setup.cmd hendrik at notlookedfor:~/cm3/gui$ ./install.sh --- shipping from LINUXLIBC6 --- --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/tcp/LINUXLIBC6 .M3EXPORTS . => /usr/local/cm3/lib libm3tcp.so.5 "/home/hendrik/cm3/gui/m3-comm/tcp/LINUXLIBC6/.M3SHIP", line 6: quake runtime error: unable to create directory "/home/hudson": errno=13 --procedure-- -line- -file--- make_dir -- 6 /home/hendrik/cm3/gui/m3-comm/tcp/LINUXLIBC6/.M3SHIP Fatal Error: package build failed --- shipping from LINUXLIBC6 --- missing ".M3SHIP" file, build the package first. --- shipping from LINUXLIBC6 --- missing ".M3SHIP" file, build the package first. --- shipping from LINUXLIBC6 --- missing ".M3SHIP" file, build the package first. --- shipping from LINUXLIBC6 --- missing ".M3SHIP" file, build the package first. --- shipping from LINUXLIBC6 --- missing ".M3SHIP" file, build the package first. --- shipping from LINUXLIBC6 --- missing ".M3SHIP" file, build the package first. --- shipping from LINUXLIBC6 --- missing ".M3SHIP" file, build the package first. --- shipping from LINUXLIBC6 --- missing ".M3SHIP" file, build the package first. --- shipping from LINUXLIBC6 --- missing ".M3SHIP" file, build the package first. --- shipping from LINUXLIBC6 --- missing ".M3SHIP" file, build the package first. --- shipping from LINUXLIBC6 --- missing ".M3SHIP" file, build the package first. --- shipping from LINUXLIBC6 --- missing ".M3SHIP" file, build the package first. --- shipping from LINUXLIBC6 --- missing ".M3SHIP" file, build the package first. --- shipping from LINUXLIBC6 --- missing ".M3SHIP" file, build the package first. hendrik at notlookedfor:~/cm3/gui$ exit It looks to me as if hudson has gotten in the way. -- hendrik From wagner at elegosoft.com Sat Aug 8 13:54:30 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 08 Aug 2009 13:54:30 +0200 Subject: [M3devel] trouble with RC2 -- maybe with hudson? In-Reply-To: <20090808114619.GA3806@topoi.pooq.com> References: <20090808114619.GA3806@topoi.pooq.com> Message-ID: <20090808135430.1iy8os9eogwwcss0@mail.elegosoft.com> Please create a ticket for that and attach the contents of file "/home/hendrik/cm3/gui/m3-comm/tcp/LINUXLIBC6/.M3SHIP"/ I'll have a look at it ASAP. Olaf Quoting hendrik at topoi.pooq.com: > Installing cm3-bin-core-LINUXLIBC6-d5.8.2-RC2.tgz on my 32-bit > intel Debian squeeze laptop went fine. > > But when I tried cm3-bin-core-LINUXLIBC6-d5.8.2-RC2.tgz (downloaded a > few days ago) I got: > > hendrik at notlookedfor:~/cm3$ mkdir gui > hendrik at notlookedfor:~/cm3$ cd gui > hendrik at notlookedfor:~/cm3/gui$ tar -zxf > ../../Desktop/cm3-bin-ws-gui-LINUXLIBC6-d5.8.2-RC2.tgz > hendrik at notlookedfor:~/cm3/gui$ ls > collection-gui.html install.sh m3-comm m3-tools m3-ui m3-win > setup.cmd > hendrik at notlookedfor:~/cm3/gui$ ./install.sh > --- shipping from LINUXLIBC6 --- > > --- shipping from LINUXLIBC6 --- > > . => /usr/local/cm3/pkg/tcp/LINUXLIBC6 > .M3EXPORTS > . => /usr/local/cm3/lib > libm3tcp.so.5 > "/home/hendrik/cm3/gui/m3-comm/tcp/LINUXLIBC6/.M3SHIP", line 6: quake > runtime error: unable to create directory "/home/hudson": errno=13 > > --procedure-- -line- -file--- > make_dir -- > 6 > /home/hendrik/cm3/gui/m3-comm/tcp/LINUXLIBC6/.M3SHIP > > Fatal Error: package build failed > --- shipping from LINUXLIBC6 --- > > missing ".M3SHIP" file, build the package first. > --- shipping from LINUXLIBC6 --- > > missing ".M3SHIP" file, build the package first. > --- shipping from LINUXLIBC6 --- > > missing ".M3SHIP" file, build the package first. > --- shipping from LINUXLIBC6 --- > > missing ".M3SHIP" file, build the package first. > --- shipping from LINUXLIBC6 --- > > missing ".M3SHIP" file, build the package first. > --- shipping from LINUXLIBC6 --- > > missing ".M3SHIP" file, build the package first. > --- shipping from LINUXLIBC6 --- > > missing ".M3SHIP" file, build the package first. > --- shipping from LINUXLIBC6 --- > > missing ".M3SHIP" file, build the package first. > --- shipping from LINUXLIBC6 --- > > missing ".M3SHIP" file, build the package first. > --- shipping from LINUXLIBC6 --- > > missing ".M3SHIP" file, build the package first. > --- shipping from LINUXLIBC6 --- > > missing ".M3SHIP" file, build the package first. > --- shipping from LINUXLIBC6 --- > > missing ".M3SHIP" file, build the package first. > --- shipping from LINUXLIBC6 --- > > missing ".M3SHIP" file, build the package first. > --- shipping from LINUXLIBC6 --- > > missing ".M3SHIP" file, build the package first. > hendrik at notlookedfor:~/cm3/gui$ exit > > > > It looks to me as if hudson has gotten in the way. > > -- hendrik > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sat Aug 8 15:03:38 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 8 Aug 2009 13:03:38 +0000 Subject: [M3devel] trouble with RC2 -- maybe with hudson? In-Reply-To: <20090808135430.1iy8os9eogwwcss0@mail.elegosoft.com> References: <20090808114619.GA3806@topoi.pooq.com> <20090808135430.1iy8os9eogwwcss0@mail.elegosoft.com> Message-ID: I rewrote the m3ship-no-resolve stuff some weeks ago. There must be a hole in my rewrite. The feature is very nice, though not well implemented either at first or with my rewrite, maybe no good way to do it. - Jay ---------------------------------------- > Date: Sat, 8 Aug 2009 13:54:30 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] trouble with RC2 -- maybe with hudson? > > Please create a ticket for that and attach the contents of file > "/home/hendrik/cm3/gui/m3-comm/tcp/LINUXLIBC6/.M3SHIP"/ > > I'll have a look at it ASAP. > > Olaf > > Quoting hendrik at topoi.pooq.com: > >> Installing cm3-bin-core-LINUXLIBC6-d5.8.2-RC2.tgz on my 32-bit >> intel Debian squeeze laptop went fine. >> >> But when I tried cm3-bin-core-LINUXLIBC6-d5.8.2-RC2.tgz (downloaded a >> few days ago) I got: >> >> hendrik at notlookedfor:~/cm3$ mkdir gui >> hendrik at notlookedfor:~/cm3$ cd gui >> hendrik at notlookedfor:~/cm3/gui$ tar -zxf >> ../../Desktop/cm3-bin-ws-gui-LINUXLIBC6-d5.8.2-RC2.tgz >> hendrik at notlookedfor:~/cm3/gui$ ls >> collection-gui.html install.sh m3-comm m3-tools m3-ui m3-win >> setup.cmd >> hendrik at notlookedfor:~/cm3/gui$ ./install.sh >> --- shipping from LINUXLIBC6 --- >> >> --- shipping from LINUXLIBC6 --- >> >> . => /usr/local/cm3/pkg/tcp/LINUXLIBC6 >> .M3EXPORTS >> . => /usr/local/cm3/lib >> libm3tcp.so.5 >> "/home/hendrik/cm3/gui/m3-comm/tcp/LINUXLIBC6/.M3SHIP", line 6: quake >> runtime error: unable to create directory "/home/hudson": errno=13 >> >> --procedure-- -line- -file--- >> make_dir -- >> 6 >> /home/hendrik/cm3/gui/m3-comm/tcp/LINUXLIBC6/.M3SHIP >> >> Fatal Error: package build failed >> --- shipping from LINUXLIBC6 --- >> >> missing ".M3SHIP" file, build the package first. >> --- shipping from LINUXLIBC6 --- >> >> missing ".M3SHIP" file, build the package first. >> --- shipping from LINUXLIBC6 --- >> >> missing ".M3SHIP" file, build the package first. >> --- shipping from LINUXLIBC6 --- >> >> missing ".M3SHIP" file, build the package first. >> --- shipping from LINUXLIBC6 --- >> >> missing ".M3SHIP" file, build the package first. >> --- shipping from LINUXLIBC6 --- >> >> missing ".M3SHIP" file, build the package first. >> --- shipping from LINUXLIBC6 --- >> >> missing ".M3SHIP" file, build the package first. >> --- shipping from LINUXLIBC6 --- >> >> missing ".M3SHIP" file, build the package first. >> --- shipping from LINUXLIBC6 --- >> >> missing ".M3SHIP" file, build the package first. >> --- shipping from LINUXLIBC6 --- >> >> missing ".M3SHIP" file, build the package first. >> --- shipping from LINUXLIBC6 --- >> >> missing ".M3SHIP" file, build the package first. >> --- shipping from LINUXLIBC6 --- >> >> missing ".M3SHIP" file, build the package first. >> --- shipping from LINUXLIBC6 --- >> >> missing ".M3SHIP" file, build the package first. >> --- shipping from LINUXLIBC6 --- >> >> missing ".M3SHIP" file, build the package first. >> hendrik at notlookedfor:~/cm3/gui$ exit >> >> >> >> It looks to me as if hudson has gotten in the way. >> >> -- hendrik >> >> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From hendrik at topoi.pooq.com Sat Aug 8 15:15:50 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sat, 8 Aug 2009 09:15:50 -0400 Subject: [M3devel] trouble with RC2 -- maybe with hudson? In-Reply-To: <20090808135430.1iy8os9eogwwcss0@mail.elegosoft.com> References: <20090808114619.GA3806@topoi.pooq.com> <20090808135430.1iy8os9eogwwcss0@mail.elegosoft.com> Message-ID: <20090808131549.GA3891@topoi.pooq.com> On Sat, Aug 08, 2009 at 01:54:30PM +0200, Olaf Wagner wrote: > Please create a ticket for that and attach the contents of file > "/home/hendrik/cm3/gui/m3-comm/tcp/LINUXLIBC6/.M3SHIP"/ Done. Ticket # 1052(new sw-bug) -- hendrik From wagner at elegosoft.com Sat Aug 8 16:38:22 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 08 Aug 2009 16:38:22 +0200 Subject: [M3devel] trouble with RC2 -- maybe with hudson? In-Reply-To: References: <20090808114619.GA3806@topoi.pooq.com> <20090808135430.1iy8os9eogwwcss0@mail.elegosoft.com> Message-ID: <20090808163822.9tr379n4q8skkscw@mail.elegosoft.com> Quoting Jay K : > I rewrote the m3ship-no-resolve stuff some weeks ago. > There must be a hole in my rewrite. > The feature is very nice, though not well implemented > either at first or with my rewrite, maybe no good way > to do it. I assigned that ticket to you. Perhaps it's easy to fix; please have a look. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sat Aug 8 19:00:17 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 8 Aug 2009 17:00:17 +0000 Subject: [M3devel] trouble with RC2 -- maybe with hudson? In-Reply-To: References: <20090808114619.GA3806@topoi.pooq.com> <20090808135430.1iy8os9eogwwcss0@mail.elegosoft.com> Message-ID: Olaf you are missing the flag some places maybe? You can see it working sometimes but not others. Just make it the default and only behavior? It is not specific to m3-comm-tcp. I'll poke around more. udson at xlin2:~$ uname -a Linux xlin2 2.6.18-6-686 #1 SMP Tue May 5 00:40:20 UTC 2009 i686 GNU/Linux hudson at xlin2:~$ pwd /home/hudson hudson at xlin2:~$ grep make_dir `find . | grep m3-comm/tcp/LINUXLIBC6/.M3SHIP` ./workspace/cm3-lastok-build-LINUXLIBC6/cm3/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/work/cm3-inst/xlin2/current--lastok-build//pkg/tcp/LINUXLIBC6") ./workspace/cm3-lastok-build-LINUXLIBC6/cm3/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/work/cm3-inst/xlin2/current--lastok-build//lib") ./workspace/cm3-lastok-build-LINUXLIBC6/cm3/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/work/cm3-inst/xlin2/current--lastok-build//pkg/tcp/src/POSIX") ./workspace/cm3-lastok-build-LINUXLIBC6/cm3/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/work/cm3-inst/xlin2/current--lastok-build//pkg/tcp/src/common") ./workspace/cm3-test-install-LINUXLIBC6/work/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir(PKG_INSTALL & "/tcp/" & TARGET) ./workspace/cm3-test-install-LINUXLIBC6/work/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir(LIB_INSTALL) ./workspace/cm3-test-install-LINUXLIBC6/work/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/tmp/cm3/bin/../lib") ./workspace/cm3-test-install-LINUXLIBC6/work/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir(PKG_INSTALL & "/tcp/src/POSIX") ./workspace/cm3-test-install-LINUXLIBC6/work/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir(PKG_INSTALL & "/tcp/src/common") ./workspace/cm3-test-all-pkgs-LINUXLIBC6/cm3/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/work/cm3-inst/xlin2/last-ok//pkg/tcp/LINUXLIBC6") ./workspace/cm3-test-all-pkgs-LINUXLIBC6/cm3/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/work/cm3-inst/xlin2/last-ok//lib") ./workspace/cm3-test-all-pkgs-LINUXLIBC6/cm3/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/work/cm3-inst/xlin2/last-ok//pkg/tcp/src/POSIX") ./workspace/cm3-test-all-pkgs-LINUXLIBC6/cm3/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/work/cm3-inst/xlin2/last-ok//pkg/tcp/src/common") - Jay > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Date: Sat, 8 Aug 2009 13:03:38 +0000 > Subject: Re: [M3devel] trouble with RC2 -- maybe with hudson? > > > I rewrote the m3ship-no-resolve stuff some weeks ago. > There must be a hole in my rewrite. > The feature is very nice, though not well implemented > either at first or with my rewrite, maybe no good way > to do it. > > > - Jay > > > > ---------------------------------------- > > Date: Sat, 8 Aug 2009 13:54:30 +0200 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] trouble with RC2 -- maybe with hudson? > > > > Please create a ticket for that and attach the contents of file > > "/home/hendrik/cm3/gui/m3-comm/tcp/LINUXLIBC6/.M3SHIP"/ > > > > I'll have a look at it ASAP. > > > > Olaf > > > > Quoting hendrik at topoi.pooq.com: > > > >> Installing cm3-bin-core-LINUXLIBC6-d5.8.2-RC2.tgz on my 32-bit > >> intel Debian squeeze laptop went fine. > >> > >> But when I tried cm3-bin-core-LINUXLIBC6-d5.8.2-RC2.tgz (downloaded a > >> few days ago) I got: > >> > >> hendrik at notlookedfor:~/cm3$ mkdir gui > >> hendrik at notlookedfor:~/cm3$ cd gui > >> hendrik at notlookedfor:~/cm3/gui$ tar -zxf > >> ../../Desktop/cm3-bin-ws-gui-LINUXLIBC6-d5.8.2-RC2.tgz > >> hendrik at notlookedfor:~/cm3/gui$ ls > >> collection-gui.html install.sh m3-comm m3-tools m3-ui m3-win > >> setup.cmd > >> hendrik at notlookedfor:~/cm3/gui$ ./install.sh > >> --- shipping from LINUXLIBC6 --- > >> > >> --- shipping from LINUXLIBC6 --- > >> > >> . => /usr/local/cm3/pkg/tcp/LINUXLIBC6 > >> .M3EXPORTS > >> . => /usr/local/cm3/lib > >> libm3tcp.so.5 > >> "/home/hendrik/cm3/gui/m3-comm/tcp/LINUXLIBC6/.M3SHIP", line 6: quake > >> runtime error: unable to create directory "/home/hudson": errno=13 > >> > >> --procedure-- -line- -file--- > >> make_dir -- > >> 6 > >> /home/hendrik/cm3/gui/m3-comm/tcp/LINUXLIBC6/.M3SHIP > >> > >> Fatal Error: package build failed > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> hendrik at notlookedfor:~/cm3/gui$ exit > >> > >> > >> > >> It looks to me as if hudson has gotten in the way. > >> > >> -- hendrik > >> > >> > > > > > > > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Aug 8 19:33:48 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 8 Aug 2009 17:33:48 +0000 Subject: [M3devel] trouble with RC2 -- maybe with hudson? In-Reply-To: References: <20090808114619.GA3806@topoi.pooq.com> <20090808135430.1iy8os9eogwwcss0@mail.elegosoft.com> Message-ID: The various make-dist console outputs show a literal $RARGS, not the expected switches. -10 for sh? - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Date: Sat, 8 Aug 2009 17:00:17 +0000 Subject: Re: [M3devel] trouble with RC2 -- maybe with hudson? Olaf you are missing the flag some places maybe? You can see it working sometimes but not others. Just make it the default and only behavior? It is not specific to m3-comm-tcp. I'll poke around more. udson at xlin2:~$ uname -a Linux xlin2 2.6.18-6-686 #1 SMP Tue May 5 00:40:20 UTC 2009 i686 GNU/Linux hudson at xlin2:~$ pwd /home/hudson hudson at xlin2:~$ grep make_dir `find . | grep m3-comm/tcp/LINUXLIBC6/.M3SHIP` ./workspace/cm3-lastok-build-LINUXLIBC6/cm3/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/work/cm3-inst/xlin2/current--lastok-build//pkg/tcp/LINUXLIBC6") ./workspace/cm3-lastok-build-LINUXLIBC6/cm3/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/work/cm3-inst/xlin2/current--lastok-build//lib") ./workspace/cm3-lastok-build-LINUXLIBC6/cm3/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/work/cm3-inst/xlin2/current--lastok-build//pkg/tcp/src/POSIX") ./workspace/cm3-lastok-build-LINUXLIBC6/cm3/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/work/cm3-inst/xlin2/current--lastok-build//pkg/tcp/src/common") ./workspace/cm3-test-install-LINUXLIBC6/work/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir(PKG_INSTALL & "/tcp/" & TARGET) ./workspace/cm3-test-install-LINUXLIBC6/work/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir(LIB_INSTALL) ./workspace/cm3-test-install-LINUXLIBC6/work/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/tmp/cm3/bin/../lib") ./workspace/cm3-test-install-LINUXLIBC6/work/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir(PKG_INSTALL & "/tcp/src/POSIX") ./workspace/cm3-test-install-LINUXLIBC6/work/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir(PKG_INSTALL & "/tcp/src/common") ./workspace/cm3-test-all-pkgs-LINUXLIBC6/cm3/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/work/cm3-inst/xlin2/last-ok//pkg/tcp/LINUXLIBC6") ./workspace/cm3-test-all-pkgs-LINUXLIBC6/cm3/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/work/cm3-inst/xlin2/last-ok//lib") ./workspace/cm3-test-all-pkgs-LINUXLIBC6/cm3/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/work/cm3-inst/xlin2/last-ok//pkg/tcp/src/POSIX") ./workspace/cm3-test-all-pkgs-LINUXLIBC6/cm3/m3-comm/tcp/LINUXLIBC6/.M3SHIP:make_dir("/home/hudson/work/cm3-inst/xlin2/last-ok//pkg/tcp/src/common") - Jay > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Date: Sat, 8 Aug 2009 13:03:38 +0000 > Subject: Re: [M3devel] trouble with RC2 -- maybe with hudson? > > > I rewrote the m3ship-no-resolve stuff some weeks ago. > There must be a hole in my rewrite. > The feature is very nice, though not well implemented > either at first or with my rewrite, maybe no good way > to do it. > > > - Jay > > > > ---------------------------------------- > > Date: Sat, 8 Aug 2009 13:54:30 +0200 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] trouble with RC2 -- maybe with hudson? > > > > Please create a ticket for that and attach the contents of file > > "/home/hendrik/cm3/gui/m3-comm/tcp/LINUXLIBC6/.M3SHIP"/ > > > > I'll have a look at it ASAP. > > > > Olaf > > > > Quoting hendrik at topoi.pooq.com: > > > >> Installing cm3-bin-core-LINUXLIBC6-d5.8.2-RC2.tgz on my 32-bit > >> intel Debian squeeze laptop went fine. > >> > >> But when I tried cm3-bin-core-LINUXLIBC6-d5.8.2-RC2.tgz (downloaded a > >> few days ago) I got: > >> > >> hendrik at notlookedfor:~/cm3$ mkdir gui > >> hendrik at notlookedfor:~/cm3$ cd gui > >> hendrik at notlookedfor:~/cm3/gui$ tar -zxf > >> ../../Desktop/cm3-bin-ws-gui-LINUXLIBC6-d5.8.2-RC2.tgz > >> hendrik at notlookedfor:~/cm3/gui$ ls > >> collection-gui.html install.sh m3-comm m3-tools m3-ui m3-win > >> setup.cmd > >> hendrik at notlookedfor:~/cm3/gui$ ./install.sh > >> --- shipping from LINUXLIBC6 --- > >> > >> --- shipping from LINUXLIBC6 --- > >> > >> . => /usr/local/cm3/pkg/tcp/LINUXLIBC6 > >> .M3EXPORTS > >> . => /usr/local/cm3/lib > >> libm3tcp.so.5 > >> "/home/hendrik/cm3/gui/m3-comm/tcp/LINUXLIBC6/.M3SHIP", line 6: quake > >> runtime error: unable to create directory "/home/hudson": errno=13 > >> > >> --procedure-- -line- -file--- > >> make_dir -- > >> 6 > >> /home/hendrik/cm3/gui/m3-comm/tcp/LINUXLIBC6/.M3SHIP > >> > >> Fatal Error: package build failed > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> --- shipping from LINUXLIBC6 --- > >> > >> missing ".M3SHIP" file, build the package first. > >> hendrik at notlookedfor:~/cm3/gui$ exit > >> > >> > >> > >> It looks to me as if hudson has gotten in the way. > >> > >> -- hendrik > >> > >> > > > > > > > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Aug 8 22:12:20 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 8 Aug 2009 20:12:20 +0000 Subject: [M3devel] lots of problems in gui on AMD64_DARWIN? Message-ID: Not all gui apps fail. Some 32bit-isms in TimeStamp.m3. gdb doesn't seem to be working at all for me, arg. jbook2:bin jay$ ./mentor *** *** runtime error: *** An enumeration or subrange value was out of range. *** file "../src/uid/Common/TimeStamp.m3", line 63 *** Abort trap jbook2:bin jay$ ./formsedit *** *** runtime error: *** An enumeration or subrange value was out of range. *** file "../src/uid/Common/TimeStamp.m3", line 63 *** jbook2:bin jay$ ./BadBricks *** *** runtime error: *** An enumeration or subrange value was out of range. *** file "../src/uid/Common/TimeStamp.m3", line 63 *** Abort trap book2:bin jay$ ./Calculator *** *** runtime error: *** An enumeration or subrange value was out of range. *** file "../src/uid/Common/TimeStamp.m3", line 63 *** -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Aug 8 22:17:09 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 8 Aug 2009 20:17:09 +0000 Subject: [M3devel] make-dist vs. $CM3_TARGET/AMD64_DARWIN Message-ID: I tried to make AMD64_DARWIN distribution with: PATH=/cm3.amd64/bin:$PATH CM3CVSUSER=jkrell SHIPRC=y CM3_TARGET=AMD64_DARWIN ./make-dist.sh I got a bunch of files with I386_DARWIN in their names. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Aug 8 22:44:18 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 08 Aug 2009 22:44:18 +0200 Subject: [M3devel] make-dist vs. $CM3_TARGET/AMD64_DARWIN In-Reply-To: References: Message-ID: <20090808224418.oel9aad5w8w8w0wc@mail.elegosoft.com> Quoting Jay K : > I tried to make AMD64_DARWIN distribution with: > > PATH=/cm3.amd64/bin:$PATH CM3CVSUSER=jkrell SHIPRC=y > CM3_TARGET=AMD64_DARWIN ./make-dist.sh > > I got a bunch of files with I386_DARWIN in their names. Have you added support for all those new AMD64 targets to sysinfo.sh? I assume you expect CM3_TARGET to override everything, but I'm not sure that it will work everywhere. You should trace with set -x. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sat Aug 8 22:48:24 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 8 Aug 2009 20:48:24 +0000 Subject: [M3devel] make-dist vs. $CM3_TARGET/AMD64_DARWIN In-Reply-To: <20090808224418.oel9aad5w8w8w0wc@mail.elegosoft.com> References: <20090808224418.oel9aad5w8w8w0wc@mail.elegosoft.com> Message-ID: I added it to python/pylib.py and I expected CM3_TARGET to override. The code in python/pylib.py: elif UName.startswith("darwin"): # detect the m3 platform (Darwin runs on ppc32, ppc64, x86, amd64) if UNameArchP == "powerpc": Host = "PPC_DARWIN" elif re.match("i[3456]86", UNameArchP): if os.popen("sysctl hw.cpu64bit_capable").read() == "hw.cpu64bit_capable: 1\n": Host = "AMD64_DARWIN" else: Host = "I386_DARWIN" elif UNameArchP == "x86-64": Host = "AMD64_DARWIN" elif UNameArchP == "powerpc64": Host = "PPC64_DARWIN" That was mostly guessing, a few things in sysctl report 64bit stuff, but nothing in uname seems to indicate it. I guess I'll update sysinfo.sh and defs.sh..yuck. I opened tickets. - Jay > Date: Sat, 8 Aug 2009 22:44:18 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] make-dist vs. $CM3_TARGET/AMD64_DARWIN > > Quoting Jay K : > > > I tried to make AMD64_DARWIN distribution with: > > > > PATH=/cm3.amd64/bin:$PATH CM3CVSUSER=jkrell SHIPRC=y > > CM3_TARGET=AMD64_DARWIN ./make-dist.sh > > > > I got a bunch of files with I386_DARWIN in their names. > > Have you added support for all those new AMD64 targets to sysinfo.sh? > I assume you expect CM3_TARGET to override everything, but I'm not sure > that it will work everywhere. > > You should trace with set -x. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Aug 8 22:54:49 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 08 Aug 2009 22:54:49 +0200 Subject: [M3devel] trouble with RC2 -- maybe with hudson? In-Reply-To: References: <20090808114619.GA3806@topoi.pooq.com> <20090808135430.1iy8os9eogwwcss0@mail.elegosoft.com> Message-ID: <20090808225449.q4lgftjzpcsso8os@mail.elegosoft.com> Quoting Jay K : > The various make-dist console outputs show a literal $RARGS, not the > expected switches. > -10 for sh? Jay, the .M3SHIP file mostly looks OK, i.e. the expected variables are found, which would not be the case if the parameters aren't passed correctly. make_dir(PKG_INSTALL & "/tcp/" & TARGET) install_file(".M3EXPORTS", PKG_INSTALL & "/tcp/" & TARGET, "0664") make_dir(LIB_INSTALL) install_file("libm3tcp.so.5", LIB_INSTALL, "0775") symbolic_link_file(PKG_INSTALL & "/tcp/" & TARGET & "/libm3tcp.a", LIB_INSTALL & "/libm3tcp.a") make_dir("/home/hudson/tmp/cm3/bin/../lib") symbolic_link_file("libm3tcp.so.5", "/home/hudson/tmp/cm3/bin/../lib/libm3tcp.so") symbolic_link_file(LIB_INSTALL & "/libm3tcp.so.5", PKG_INSTALL & "/tcp/" & TARGET & "/libm3tcp.so") symbolic_link_file(LIB_INSTALL & "/libm3tcp.so.5", PKG_INSTALL & "/tcp/" & TARGET & "/libm3tcp.so.5") install_file("libm3tcp.a", PKG_INSTALL & "/tcp/" & TARGET, "0664") install_file("libm3tcp.m3x", PKG_INSTALL & "/tcp/" & TARGET, "0664") install_file(".M3WEB", PKG_INSTALL & "/tcp/" & TARGET, "0664") make_dir(PKG_INSTALL & "/tcp/src/POSIX") install_file("../src/POSIX/TCP.m3", PKG_INSTALL & "/tcp/src/POSIX", "0664") install_file("../src/POSIX/TCPPosix.i3", PKG_INSTALL & "/tcp/src/POSIX", "0664") install_file("../src/POSIX/Herrno.i3", PKG_INSTALL & "/tcp/src/POSIX", "0664") install_file("../src/POSIX/HerrnoC.c", PKG_INSTALL & "/tcp/src/POSIX", "0664") install_file("../src/POSIX/IP.m3", PKG_INSTALL & "/tcp/src/POSIX", "0664") install_file("../src/POSIX/IPErrorPosix.m3", PKG_INSTALL & "/tcp/src/POSIX", "0664") install_file("../src/POSIX/TCPExtras.m3", PKG_INSTALL & "/tcp/src/POSIX", "0664") install_file("../src/POSIX/TCPPeer.m3", PKG_INSTALL & "/tcp/src/POSIX", "0664") I had tested that with several different packages some weeks ago. I still think you overlooked some case when applying your changes. Can you please check again? We probably have to rebuild lots of packages... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sat Aug 8 23:15:48 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 8 Aug 2009 21:15:48 +0000 Subject: [M3devel] trouble with RC2 -- maybe with hudson? In-Reply-To: <20090808225449.q4lgftjzpcsso8os@mail.elegosoft.com> References: <20090808114619.GA3806@topoi.pooq.com> <20090808135430.1iy8os9eogwwcss0@mail.elegosoft.com> <20090808225449.q4lgftjzpcsso8os@mail.elegosoft.com> Message-ID: These contain no binaries at all, just source: m3-bin-ws-anim-LINUXLIBC6-d5.8.2-RC2.tgz m3-bin-ws-cvsup-LINUXLIBC6-d5.8.2-RC2.tgz intentional? I see. You are right: cm3-bin-ws-core-LINUXLIBC6-d5.8.2-RC2.tgz jbook2:t jay$ more m3-tools/m3bundle/LINUXLIBC6/.M3SHIP make_dir(PKG_INSTALL & "/m3bundle/" & TARGET) install_file(".M3EXPORTS", PKG_INSTALL & "/m3bundle/" & TARGET, "0664" ) make_dir("/home/hudson/tmp/cm3/bin") install_file("m3bundle", "/home/hudson/tmp/cm3/bin", "0775") install_file(".M3WEB", PKG_INSTALL & "/m3bundle/" & TARGET, "0664") m - Jay > Date: Sat, 8 Aug 2009 22:54:49 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] trouble with RC2 -- maybe with hudson? > > Quoting Jay K : > > > The various make-dist console outputs show a literal $RARGS, not the > > expected switches. > > -10 for sh? > > Jay, the .M3SHIP file mostly looks OK, i.e. the expected variables > are found, which would not be the case if the parameters aren't > passed correctly. > > make_dir(PKG_INSTALL & "/tcp/" & TARGET) > install_file(".M3EXPORTS", PKG_INSTALL & "/tcp/" & TARGET, "0664") > make_dir(LIB_INSTALL) > install_file("libm3tcp.so.5", LIB_INSTALL, "0775") > symbolic_link_file(PKG_INSTALL & "/tcp/" & TARGET & "/libm3tcp.a", > LIB_INSTALL & "/libm3tcp.a") > make_dir("/home/hudson/tmp/cm3/bin/../lib") > symbolic_link_file("libm3tcp.so.5", > "/home/hudson/tmp/cm3/bin/../lib/libm3tcp.so") > symbolic_link_file(LIB_INSTALL & "/libm3tcp.so.5", PKG_INSTALL & > "/tcp/" & TARGET & "/libm3tcp.so") > symbolic_link_file(LIB_INSTALL & "/libm3tcp.so.5", PKG_INSTALL & > "/tcp/" & TARGET & "/libm3tcp.so.5") > install_file("libm3tcp.a", PKG_INSTALL & "/tcp/" & TARGET, "0664") > install_file("libm3tcp.m3x", PKG_INSTALL & "/tcp/" & TARGET, "0664") > install_file(".M3WEB", PKG_INSTALL & "/tcp/" & TARGET, "0664") > make_dir(PKG_INSTALL & "/tcp/src/POSIX") > install_file("../src/POSIX/TCP.m3", PKG_INSTALL & "/tcp/src/POSIX", "0664") > install_file("../src/POSIX/TCPPosix.i3", PKG_INSTALL & > "/tcp/src/POSIX", "0664") > install_file("../src/POSIX/Herrno.i3", PKG_INSTALL & "/tcp/src/POSIX", "0664") > install_file("../src/POSIX/HerrnoC.c", PKG_INSTALL & "/tcp/src/POSIX", "0664") > install_file("../src/POSIX/IP.m3", PKG_INSTALL & "/tcp/src/POSIX", "0664") > install_file("../src/POSIX/IPErrorPosix.m3", PKG_INSTALL & > "/tcp/src/POSIX", "0664") > install_file("../src/POSIX/TCPExtras.m3", PKG_INSTALL & > "/tcp/src/POSIX", "0664") > install_file("../src/POSIX/TCPPeer.m3", PKG_INSTALL & > "/tcp/src/POSIX", "0664") > > I had tested that with several different packages some weeks ago. > > I still think you overlooked some case when applying your changes. > > Can you please check again? We probably have to rebuild lots of > packages... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Aug 8 23:21:34 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 08 Aug 2009 23:21:34 +0200 Subject: [M3devel] trouble with RC2 -- maybe with hudson? In-Reply-To: References: <20090808114619.GA3806@topoi.pooq.com> <20090808135430.1iy8os9eogwwcss0@mail.elegosoft.com> Message-ID: <20090808232134.abs0ft0zgo4ocssk@mail.elegosoft.com> Quoting Jay K : > The various make-dist console outputs show a literal $RARGS, not the > expected switches. > -10 for sh? I've just tested the -no-m3ship-resolution switch on the current cm3 on birch. It mostly works, but some shipping destinations do not use the variable names. So it's nothing to do with shell incompatibilities, but with our programming mistakes. It may be that such paths containing // (perfectly legal in POSIX) and .../bin/../lib/... are the culprit. I should not have relied on the automatic installation testing by hudson; everything worked there, as it is the same user who built the packages. To find such errors, we need to test with different users... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sat Aug 8 23:31:23 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 8 Aug 2009 21:31:23 +0000 Subject: [M3devel] trouble with RC2 -- maybe with hudson? In-Reply-To: <20090808232134.abs0ft0zgo4ocssk@mail.elegosoft.com> References: <20090808114619.GA3806@topoi.pooq.com> <20090808135430.1iy8os9eogwwcss0@mail.elegosoft.com> <20090808232134.abs0ft0zgo4ocssk@mail.elegosoft.com> Message-ID: It's not that. dot and dotdot get smushed out. What does // mean? My code changes any // to just /, except at the start of a path. That is what GetFullPathname on Windows with backward slashes. I was missing BIN_INSTALL and worst case fallback INSTALL_ROOT. - Jay > Date: Sat, 8 Aug 2009 23:21:34 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] trouble with RC2 -- maybe with hudson? > > Quoting Jay K : > > > The various make-dist console outputs show a literal $RARGS, not the > > expected switches. > > -10 for sh? > > I've just tested the -no-m3ship-resolution switch on the current > cm3 on birch. It mostly works, but some shipping destinations do not > use the variable names. So it's nothing to do with shell incompatibilities, > but with our programming mistakes. > > It may be that such paths containing // (perfectly legal in POSIX) > and .../bin/../lib/... are the culprit. > > I should not have relied on the automatic installation testing by hudson; > everything worked there, as it is the same user who built the > packages. To find such errors, we need to test with different > users... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Aug 8 23:40:38 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 08 Aug 2009 23:40:38 +0200 Subject: [M3devel] trouble with RC2 -- maybe with hudson? In-Reply-To: References: <20090808114619.GA3806@topoi.pooq.com> <20090808135430.1iy8os9eogwwcss0@mail.elegosoft.com> <20090808232134.abs0ft0zgo4ocssk@mail.elegosoft.com> Message-ID: <20090808234038.2u68sn81cs04gc40@mail.elegosoft.com> Quoting Jay K : > It's not that. dot and dotdot get smushed out. > What does // mean? > My code changes any // to just /, except at the start of a path. > That is what GetFullPathname on Windows with backward slashes. That's OK. > I was missing BIN_INSTALL and worst case fallback INSTALL_ROOT. So we may have to build RC3 sooner than intended. There's always the workaround to just call cm3 -build before shipping, but many of the install.sh scripts will fail for RC2. Can you check in a fix to the release branch? We may be able to build new packages tomorrow evening or at the start of the week. Olaf > - Jay > >> Date: Sat, 8 Aug 2009 23:21:34 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] trouble with RC2 -- maybe with hudson? >> >> Quoting Jay K : >> >> > The various make-dist console outputs show a literal $RARGS, not the >> > expected switches. >> > -10 for sh? >> >> I've just tested the -no-m3ship-resolution switch on the current >> cm3 on birch. It mostly works, but some shipping destinations do not >> use the variable names. So it's nothing to do with shell incompatibilities, >> but with our programming mistakes. >> >> It may be that such paths containing // (perfectly legal in POSIX) >> and .../bin/../lib/... are the culprit. >> >> I should not have relied on the automatic installation testing by hudson; >> everything worked there, as it is the same user who built the >> packages. To find such errors, we need to test with different >> users... >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sun Aug 9 01:58:25 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Sat, 8 Aug 2009 16:58:25 -0700 Subject: [M3devel] make-dist vs. $CM3_TARGET/AMD64_DARWIN In-Reply-To: <20090808224418.oel9aad5w8w8w0wc@mail.elegosoft.com> References: <20090808224418.oel9aad5w8w8w0wc@mail.elegosoft.com> Message-ID: <25BD6284-E323-4C6D-837C-E853A1B15119@hotmail.com> Ps amd64_Darwin is not new. It was the first Amd64 target. - Jay (phone) On Aug 8, 2009, at 1:44 PM, Olaf Wagner wrote: > Quoting Jay K : > >> I tried to make AMD64_DARWIN distribution with: >> >> PATH=/cm3.amd64/bin:$PATH CM3CVSUSER=jkrell SHIPRC=y >> CM3_TARGET=AMD64_DARWIN ./make-dist.sh >> >> I got a bunch of files with I386_DARWIN in their names. > > Have you added support for all those new AMD64 targets to sysinfo.sh? > I assume you expect CM3_TARGET to override everything, but I'm not > sure > that it will work everywhere. > > You should trace with set -x. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ > any > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be > rlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > From wagner at elegosoft.com Mon Aug 10 00:32:36 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 10 Aug 2009 00:32:36 +0200 Subject: [M3devel] make-dist vs. $CM3_TARGET/AMD64_DARWIN In-Reply-To: <25BD6284-E323-4C6D-837C-E853A1B15119@hotmail.com> References: <20090808224418.oel9aad5w8w8w0wc@mail.elegosoft.com> <25BD6284-E323-4C6D-837C-E853A1B15119@hotmail.com> Message-ID: <20090810003236.8v14j0kpccosscow@mail.elegosoft.com> Quoting jay.krell at cornell.edu: > Ps amd64_Darwin is not new. It was the first Amd64 target. Right, I was confused here. But I guess it was never integrated into the sysinfo.sh script nonetheless. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Aug 10 00:56:32 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 9 Aug 2009 22:56:32 +0000 Subject: [M3devel] caltech-parser m3overrides? Message-ID: Anyone know about all (not all, many) these packages in caltech-parser m3overrides? They no longer exist? We didn't get all the source? override("prsparse",TOP) override("magic",TOP) override("magicextras",TOP) override("cit_common",TOP) override("cit_util",TOP) override("bdd",TOP) override("cptr",TOP) override("bool",TOP) override("boxes",TOP) override("simplegrid",TOP) override("router",TOP) override("term",TOP) override("m3-3",TOP) override("paneman",TOP) override("parserlib",TOP & SL & "parserlib") override("ktoklib",TOP & SL & "parserlib") override("cit_parse",TOP) override("drawcontext",TOP) override("dcpane",TOP & SL & "drawcontext") override("tasks",TOP) override("matrix",TOP) override("layout",TOP) From jay.krell at cornell.edu Mon Aug 10 12:53:43 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 10 Aug 2009 10:53:43 +0000 Subject: [M3devel] proposal for next release: moving some config file content into cm3 Message-ID: Native builds are the usual. Cross builds are rarer. It is dumb for config files to even specify TARGET. As well as thing I recently added: TARGET_OS, TARGET_ENDIAN. It should default to "HOST". Furthermore, a command line option rather than editing/replacing config file should achieve a cross build. One (or more?) of: cm3 I386_LINUX cm3 -target I386_LINUX cm3 -target:I386_LINUX cm3 -target=I386_LINUX cm3 --target I386_LINUX cm3 --target:I386_LINUX cm3 --target=I386_LINUX cm3 -DTARGET=I386_LINUX I like the first, but perhaps it is too implicit/sleazy. User should have to say what the random freestanding platform name means? pylib.py does support this. There is much precedent for the last, as cm3 already supports -D. I have found that -D tends to be processed too late to be as useful as it could/should be. We should probably fix this. Any changes along these lines would "by default" (if not done along with other changes) break other m3quake/m3config users -- m3tohtml, cm3ide, etc. The code in cm3 that "predefines" stuff, such "HOST", such as defaulting TARGET, shall move into the m3quake package, but not be run "automatically". m3quake shall remain by default ignorant of its usual use in support of compiling Modula-3 and remain by default "just a scripting language". Something like m3-sys/m3quake/M3Predefines.i3 m3-sys/m3quake/M3Predefines.Init Should they start with "Q" or M3"? Should cm3 be split up into cm3lib and cm3exe and these would be m3-sys/cm3lib/M3Predefines? m3quake users who are attempting to act "like the compiler" shall call M3Predefines.Init(). Furthermore, the following should all be "correctly default" and therefore moved out of config files: INSTALL_ROOT (based on cm3's location) BIN_INSTALL LIB_INSTALL MAN_INSTALL PKG_INSTALL USE_ROOT LIB_USE PKG_USE etc. (so much for a precise spec. :) ) The config file shall still be able to override this. As well as the command line. I think. There is some order ambiguity. Normally LIB_USE defaults to LIB_INSTALL, etc. If the command line overrides LIB_INSTALL, should that also change LIB_USE? Perhaps these are not changable on the command line. Does anyone really ever vary them? Sure, people install to custom place, but do they all not follow directly from cm3.exe location? Well, I sometimes run unshipped cm3. That is something to consider. cm3 should perhaps even move to an archictecture-specific directory. /cm3/bin/I386_LINUX/cm3 However, aside, I've given up on that idea. While the pkg store has all these nice target-specific directories already, instead of solving the problem for bin and lib, and then having savings due to not duplicating "man", I've just been going with separate entire roots. On a Mac for example, I'd have /cm3.x86 /cm3.amd64 /cm3.ppc /cm3.ppc64 (hypothetical) or on Windows: /cm3 ("native") /cm3.cygwin /cm3.interix The "man" directory would be wastefully duplicated. For the rare user of unshipped cm3 to have to say -DINSTALL_ROOT=/usr/local/bin/cm3 doesn't seem terrible. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Aug 10 14:13:54 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 10 Aug 2009 14:13:54 +0200 Subject: [M3devel] proposal for next release: moving some config file content into cm3 In-Reply-To: References: Message-ID: <20090810141354.9co7e8rxss8g8o48@mail.elegosoft.com> Quoting Jay K : > Furthermore, the following should all be "correctly default" > and therefore moved out of config files: > INSTALL_ROOT (based on cm3's location) > BIN_INSTALL > LIB_INSTALL > MAN_INSTALL > PKG_INSTALL > USE_ROOT > LIB_USE > PKG_USE > > etc. (so much for a precise spec. :) ) > > The config file shall still be able to override this. > As well as the command line. I think. If these cannot be overriden by the config files, system specific installations not adhering to the standard layout won't be possible. > There is some order ambiguity. > Normally LIB_USE defaults to LIB_INSTALL, etc. > If the command line overrides LIB_INSTALL, should > that also change LIB_USE? > > Perhaps these are not changable on the command line. > Does anyone really ever vary them? > Sure, people install to custom place, but > do they all not follow directly from cm3.exe location? > > Well, I sometimes run unshipped cm3. > That is something to consider. > cm3 should perhaps even move to an archictecture-specific directory. > /cm3/bin/I386_LINUX/cm3 > > However, aside, I've given up on that idea. Why? Too complex? Is there some strong argument against it? (I don't remember offhand.) > While the pkg store has all these nice target-specific directories already, > instead of solving the problem for bin and lib, and then having > savings due to not duplicating "man", I've just been > going with separate entire roots. > > On a Mac for example, I'd have > /cm3.x86 > /cm3.amd64 > /cm3.ppc > /cm3.ppc64 (hypothetical) > > or on Windows: > /cm3 ("native") > /cm3.cygwin > /cm3.interix > > The "man" directory would be wastefully duplicated. > > For the rare user of unshipped cm3 to have to say > -DINSTALL_ROOT=/usr/local/bin/cm3 > > doesn't seem terrible. -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Mon Aug 10 14:35:23 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 10 Aug 2009 14:35:23 +0200 Subject: [M3devel] CM3 Hudson Config in CVS Message-ID: <20090810143523.ntayisdvpc4wsgc0@mail.elegosoft.com> I've added a small script that saves all the XML config files of the various Hudson jobs for CM3 into birch's CVS repository below /usr/cvs/hudson-config. It should be accessible for all M3 users, but should be treated as read-only. It is only there to record the history and for backup purposes. It is still very dumb and needs to be improved, so that only actual changes get imported and tagged. The corresponding Hudson job is http://hudson.modula3.com:8080/view/www/job/save-xml-config/ Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Aug 10 19:17:12 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 10 Aug 2009 17:17:12 +0000 Subject: [M3devel] testing RC2. In-Reply-To: <6A0491CD-BC10-49BB-8100-3137A406DBE7@darko.org> References: <20090804002754.GF25621@topoi.pooq.com> <1C5F772D-930B-472B-A83B-32DEC364D2FA@hotmail.com> <20090804105835.vs1925r2kg480ccg@mail.elegosoft.com> <6A0491CD-BC10-49BB-8100-3137A406DBE7@darko.org> Message-ID: My attempt to do an AMD64_DARWIN build messed up the I386_DARWIN files. I386_DARWIN needs to be rebuilt, preferably this time via Hudson. Please give it a day or two at least. - Jay ---------------------------------------- > CC: m3devel at elegosoft.com > From: darko at darko.org > To: jay.krell at cornell.edu > Subject: Re: [M3devel] testing RC2. > Date: Mon, 10 Aug 2009 17:24:53 +0200 > > Just looking into a Mac installer but found the RC2 "optional" > archives seem to have AMD64_DARWIN libraries instead of I386_DARWIN. > I'm looking in http://www.opencm3.net/releng/download.html > > > On 04/08/2009, at 1:49 PM, Jay K wrote: > >> >>> build some missing installation packages (for I386_DARWIN for >>> example) >> >> >> I have a new computer arriving roughly Friday on which I can setup >> near arbitrary x86/AMD64 VMs, as well as doing native I386_DARWIN >> and AMD64_DARWIN. AMD64_FREEBSD is also missing for example. >> Tony should also be able to do {I386,AMD64}_DARWIN. >> >> >> - Jay >> >> >> >> ---------------------------------------- >>> Date: Tue, 4 Aug 2009 10:58:35 +0200 >>> From: wagner at elegosoft.com >>> To: m3devel at elegosoft.com >>> Subject: Re: [M3devel] testing RC2. >>> >>> Quoting jay.krell at cornell.edu: >>> >>>> Wikipedia: Aren't you subverting release manager Olaf? Not ready for >>>> exposure beyond m3devel? >>> >>> I just moved the date for RC2 another week :-/ Too many things still >>> to be done. See >>> >>> https://projects.elego.de/cm3/milestone/CM3%20Release%205.8%20RC2 >>> >>> We need >>> >>> o to improve the WWW presentation (there were suggestions from >>> Peter Eiserloh and others but no concrete changes/commits AFAIK) >>> >>> o build some missing installation packages (for I386_DARWIN for >>> example) >>> >>> o automate some installation tests (next thing I'll do) >>> >>> o get some feedback from manual tests >>> >>> If there are no commits to the web pages till Wednesday, I'll make >>> some small adaptions there to be ready for RC2 then. >>> >>> Olaf >>> >>>> - Jay (phone) >>>> >>>> On Aug 3, 2009, at 5:27 PM, hendrik at topoi.pooq.com wrote: >>>> >>>>> Now that I've updated the wikipedia entry, it's easier to find >>>>> the RC2 >>>>> downloads page. >>>>> >>>>> How can I update the other places that are easy to find on the >>>>> google? >>>>> Specifically, >>>>> the Modula 3 resource page, www.modula3.org/ >>>>> Modula-3 Frequently Asked Questions (FAQ), >>>>> www.faqs.org/faqs/Modula-3-faq/ >>>>> >>>>> I'll soon be trying another installation fromscratch, using RC2, >>>>> and I'll let you know how it went. >>>>> >>>>> -- hendrik >>>>> >>>>> >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>> 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>> Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> > From hosking at cs.purdue.edu Mon Aug 10 20:19:38 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 10 Aug 2009 14:19:38 -0400 Subject: [M3devel] lots of problems in gui on AMD64_DARWIN? In-Reply-To: References: Message-ID: <224E3743-8052-4D90-B49E-BC7CFD01FFF0@cs.purdue.edu> I believe this code used to work on 64-bit ALPHA_OSF, unless something changed since then. Just looking at it, it claims to be 64-bit safe. On 8 Aug 2009, at 16:12, Jay K wrote: > Not all gui apps fail. > Some 32bit-isms in TimeStamp.m3. > gdb doesn't seem to be working at all for me, arg. > > jbook2:bin jay$ ./mentor > > > *** > *** runtime error: > *** An enumeration or subrange value was out of range. > *** file "../src/uid/Common/TimeStamp.m3", line 63 > *** > > Abort trap > > jbook2:bin jay$ ./formsedit > > > *** > *** runtime error: > *** An enumeration or subrange value was out of range. > *** file "../src/uid/Common/TimeStamp.m3", line 63 > *** > > > jbook2:bin jay$ ./BadBricks > > > *** > *** runtime error: > *** An enumeration or subrange value was out of range. > *** file "../src/uid/Common/TimeStamp.m3", line 63 > *** > > Abort trap > > book2:bin jay$ ./Calculator > > > *** > *** runtime error: > *** An enumeration or subrange value was out of range. > *** file "../src/uid/Common/TimeStamp.m3", line 63 > *** > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Aug 10 20:37:26 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 10 Aug 2009 14:37:26 -0400 Subject: [M3devel] lots of problems in gui on AMD64_DARWIN? In-Reply-To: References: Message-ID: <54CE76F0-8422-4124-8981-9B91B08F374D@cs.purdue.edu> I have no problem invoking TimeStamp.New() with my AMD64_DARWIN build. I'm not sure why you are seeing problems with your build. On 8 Aug 2009, at 16:12, Jay K wrote: > Not all gui apps fail. > Some 32bit-isms in TimeStamp.m3. > gdb doesn't seem to be working at all for me, arg. > > jbook2:bin jay$ ./mentor > > > *** > *** runtime error: > *** An enumeration or subrange value was out of range. > *** file "../src/uid/Common/TimeStamp.m3", line 63 > *** > > Abort trap > > jbook2:bin jay$ ./formsedit > > > *** > *** runtime error: > *** An enumeration or subrange value was out of range. > *** file "../src/uid/Common/TimeStamp.m3", line 63 > *** > > > jbook2:bin jay$ ./BadBricks > > > *** > *** runtime error: > *** An enumeration or subrange value was out of range. > *** file "../src/uid/Common/TimeStamp.m3", line 63 > *** > > Abort trap > > book2:bin jay$ ./Calculator > > > *** > *** runtime error: > *** An enumeration or subrange value was out of range. > *** file "../src/uid/Common/TimeStamp.m3", line 63 > *** > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Aug 10 21:17:47 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 10 Aug 2009 19:17:47 +0000 Subject: [M3devel] testing RC2. In-Reply-To: References: <20090804002754.GF25621@topoi.pooq.com> <1C5F772D-930B-472B-A83B-32DEC364D2FA@hotmail.com> <20090804105835.vs1925r2kg480ccg@mail.elegosoft.com> <6A0491CD-BC10-49BB-8100-3137A406DBE7@darko.org> Message-ID: New (untested) I386_DARWIN packages are uploading right now. cm3-bin-core-I386_DARWIN-d5.8.2-RC2.tgz 100% 15MB 65.3KB/s 03:50 cm3-bin-min-I386_DARWIN-d5.8.2-RC2.tgz 100% 7511KB 62.1KB/s 02:01 cm3-bin-ws-anim-I386_DARWIN-d5.8.2-RC2.tgz 100% 5033KB 65.4KB/s 01:17 cm3-bin-ws-caltech-parser-I386_DARWIN-d5.8.2- 100% 4205KB 64.7KB/s 01:05 are done. - Jay > From: jay.krell at cornell.edu > To: darko at darko.org > Date: Mon, 10 Aug 2009 17:17:12 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] testing RC2. > > > My attempt to do an AMD64_DARWIN build messed up the I386_DARWIN files. > I386_DARWIN needs to be rebuilt, preferably this time via Hudson. > Please give it a day or two at least. > > - Jay > > > ---------------------------------------- > > CC: m3devel at elegosoft.com > > From: darko at darko.org > > To: jay.krell at cornell.edu > > Subject: Re: [M3devel] testing RC2. > > Date: Mon, 10 Aug 2009 17:24:53 +0200 > > > > Just looking into a Mac installer but found the RC2 "optional" > > archives seem to have AMD64_DARWIN libraries instead of I386_DARWIN. > > I'm looking in http://www.opencm3.net/releng/download.html > > > > > > On 04/08/2009, at 1:49 PM, Jay K wrote: > > > >> > >>> build some missing installation packages (for I386_DARWIN for > >>> example) > >> > >> > >> I have a new computer arriving roughly Friday on which I can setup > >> near arbitrary x86/AMD64 VMs, as well as doing native I386_DARWIN > >> and AMD64_DARWIN. AMD64_FREEBSD is also missing for example. > >> Tony should also be able to do {I386,AMD64}_DARWIN. > >> > >> > >> - Jay > >> > >> > >> > >> ---------------------------------------- > >>> Date: Tue, 4 Aug 2009 10:58:35 +0200 > >>> From: wagner at elegosoft.com > >>> To: m3devel at elegosoft.com > >>> Subject: Re: [M3devel] testing RC2. > >>> > >>> Quoting jay.krell at cornell.edu: > >>> > >>>> Wikipedia: Aren't you subverting release manager Olaf? Not ready for > >>>> exposure beyond m3devel? > >>> > >>> I just moved the date for RC2 another week :-/ Too many things still > >>> to be done. See > >>> > >>> https://projects.elego.de/cm3/milestone/CM3%20Release%205.8%20RC2 > >>> > >>> We need > >>> > >>> o to improve the WWW presentation (there were suggestions from > >>> Peter Eiserloh and others but no concrete changes/commits AFAIK) > >>> > >>> o build some missing installation packages (for I386_DARWIN for > >>> example) > >>> > >>> o automate some installation tests (next thing I'll do) > >>> > >>> o get some feedback from manual tests > >>> > >>> If there are no commits to the web pages till Wednesday, I'll make > >>> some small adaptions there to be ready for RC2 then. > >>> > >>> Olaf > >>> > >>>> - Jay (phone) > >>>> > >>>> On Aug 3, 2009, at 5:27 PM, hendrik at topoi.pooq.com wrote: > >>>> > >>>>> Now that I've updated the wikipedia entry, it's easier to find > >>>>> the RC2 > >>>>> downloads page. > >>>>> > >>>>> How can I update the other places that are easy to find on the > >>>>> google? > >>>>> Specifically, > >>>>> the Modula 3 resource page, www.modula3.org/ > >>>>> Modula-3 Frequently Asked Questions (FAQ), > >>>>> www.faqs.org/faqs/Modula-3-faq/ > >>>>> > >>>>> I'll soon be trying another installation fromscratch, using RC2, > >>>>> and I'll let you know how it went. > >>>>> > >>>>> -- hendrik > >>>>> > >>>>> > >>> > >>> > >>> > >>> -- > >>> Olaf Wagner -- elego Software Solutions GmbH > >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > >>> 45 86 95 > >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > >>> Berlin > >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > >>> DE163214194 > >>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Aug 10 21:52:16 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 10 Aug 2009 19:52:16 +0000 Subject: [M3devel] proposal for next release: moving some config file content into cm3 In-Reply-To: <20090810141354.9co7e8rxss8g8o48@mail.elegosoft.com> References: <20090810141354.9co7e8rxss8g8o48@mail.elegosoft.com> Message-ID: > If these cannot be overriden by the config files, system specific > installations not adhering to the standard layout won't be possible. They shall be overridable, but perhaps only INSTALL_ROOT? It becomes ambiguous, as to when to resolve INSTALL_ROOT in code like PKG_INSTALL = INSTALL_ROOT & /pkg PKG_USE = INSTALL_ROOT & /pkg or PKG_USE = PKG_INSTALL You have to decide what order things are processed -- builtin defines then command line, or command line then builtin defines, or loop while things change. Could I on the command line say -DPKG_USE="INSTALL_ROOT & '/foo'" ? Does cm3 -DINSTALL_ROOT=/foo imply PKG_USE=/foo/pkg? An easy answer is to only allow overriding USE_ROOT and INSTALL_ROOT. That all the rest follow directly by appending /bin, /pkg, /lib. I guess as well each one is "fully" overridable, but overriding "part of an expression" won't cause that expression to be reevaluated, and all the builtins are evaluated..first? last? Can I say PKG_USE=INSTALL_ROOT & /foo? Is INSTALL_ROOT defined before or after the command line is processed? I don't mean currently, but ideally. > > That is something to consider. > > cm3 should perhaps even move to an archictecture-specific directory. > > /cm3/bin/I386_LINUX/cm3 > > > > However, aside, I've given up on that idea. > > Why? Too complex? Is there some strong argument against it? > (I don't remember offhand.) If I'm going to have /cm3/bin/target, /cm3/lib/target, /cm3/pkg/m3core/target, and it is going to take work to teach things about this, it seems easier and almost equivalent to use /cm3.target/bin, /cm3.target/lib, or /cm3/target/bin, /cm3/target/lib, etc. The downside is some duplication, of the src directories in pkg, the config files (we can fix that, but very minor), doc, man..all fairly small..on Windows at least there is something called the "single instance store" that opportunistically finds identical files and combines their storage but makes them copy-on-write. I know I know -- "make whatever is different, different; leave whatever is the same, the same". But sometimes it is easier to just pretend everything is different, when it is almost true anyway. I wonder how cross builds fit here however. That might be a reason to have /cm3/bin/cm3 /cm3/lib/target /cm3/pkg/m3core/target (already the case) in that, you know, even though "biarch" and "multiarch" are "limited" to a maximum of around 3 (ppc, x86, amd64 darwin; cygwin, interix, native NT), cross combinations occupy the whole matrix, but only lib would get duplicated, not bin. The thing is, I find "full" cross builds to be too much of a pain -- the actual C compilation, assembly, link, so I don't account for them. You need to build or copy the C runtime and headers, build the cross compiler and assembler. The problem imho is that 1) it isn't even always possible, consider the case when the native tools are preferred over GNU and aren't open source (Irix, AIX, HP-UX?) 2) when it is possible, it varies, as the C runtime/headers have to be gotten a different way for each system (*BSD, Solaris, Linux, Windows). It is only "the same everywhere" if you define "everywhere" as one system such as FreeBSD OR Linux OR NetBSD. I have done this, copied /usr, /lib etc. from Solaris to a cross build host..but..as well..you don't even know which files. Perhaps I should use NFS and therefore get all the files more cheaply.. Hm. so /cm3/lib/target. And we use that for native too? Using symlinks for compat? And /cm3/bin/target. And /cm3/bin/cm3 is a .sh file with an except of sysinfo.sh? (and cm3.cmd would exist) And adjust the computation of INSTALL_ROOT? And the location of cm3.cfg? For the sake of "full" cross builds (ie: C compilation, assemble, link)? In either case, these are separate. Except that they relate regarding the computation of INSTALL_ROOT. The code for INSTALL_ROOT computation could be smart. If cm3's directory ends in "bin/host", remove two elements. If it ends in "bin", remove one element. If it ends in "m3-sys/host" error probably, or maybe search $PATH for another cm3 and apply the logic to its location. If anything else, error. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Aug 10 22:04:39 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 10 Aug 2009 20:04:39 +0000 Subject: [M3devel] testing RC2. In-Reply-To: References: <20090804002754.GF25621@topoi.pooq.com> <1C5F772D-930B-472B-A83B-32DEC364D2FA@hotmail.com> <20090804105835.vs1925r2kg480ccg@mail.elegosoft.com> <6A0491CD-BC10-49BB-8100-3137A406DBE7@darko.org> Message-ID: They should all be there now. - Jay From: jay To: darko CC: m3devel Subject: RE: [M3devel] testing RC2. Date: Mon, 10 Aug 2009 19:17:47 +0000 New (untested) I386_DARWIN packages are uploading right now. [snip] -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Aug 10 22:17:35 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 10 Aug 2009 22:17:35 +0200 Subject: [M3devel] testing RC2. In-Reply-To: References: <20090804002754.GF25621@topoi.pooq.com> <1C5F772D-930B-472B-A83B-32DEC364D2FA@hotmail.com> <20090804105835.vs1925r2kg480ccg@mail.elegosoft.com> <6A0491CD-BC10-49BB-8100-3137A406DBE7@darko.org> Message-ID: <20090810221735.covpvzsf4gosogoc@mail.elegosoft.com> Quoting Jay K : > They should all be there now. Great, thanks. Olaf > - Jay > > From: jay > To: darko > CC: m3devel > Subject: RE: [M3devel] testing RC2. > Date: Mon, 10 Aug 2009 19:17:47 +0000 > > > > > > > > > New (untested) I386_DARWIN packages are uploading right now. > > [snip] > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Aug 10 23:10:02 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 10 Aug 2009 21:10:02 +0000 Subject: [M3devel] the beauty of a C backend.. Message-ID: The beauty of a C backend.. We'd just release source and be done. No platform build matrix -- only what we'd test. Leave all the less used architectures to their users. Leave all the packaging to the distribution packaging people. Maybe use autoconf for some of the platform specific stuff, though we have very little anyway. You know, you don't see binary packages for many projects provided by their owners, and then not for many architectures. You know, we'd just do like NT/x86, Linux/x86, maybe Linux/amd64, and that'd be it. Anyone running anything else is an advanced or unusual user. (the x86 packages would generally work on the popular AMD64 machines, anyone wanting native could build from source) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Aug 10 23:19:42 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 10 Aug 2009 17:19:42 -0400 Subject: [M3devel] the beauty of a C backend.. In-Reply-To: References: Message-ID: These are observations, but I don't see how they reach any conclusion, nor whether the conclusion is desirable. I'm not sure exactly what you are trying to say. On 10 Aug 2009, at 17:10, Jay K wrote: > The beauty of a C backend.. > We'd just release source and be done. > No platform build matrix -- only what we'd test. > Leave all the less used architectures to their users. > Leave all the packaging to the distribution packaging people. > Maybe use autoconf for some of the platform specific stuff, though > we have very little anyway. > > > You know, you don't see binary packages for many > projects provided by their owners, and then not for many > architectures. > You know, we'd just do like NT/x86, Linux/x86, maybe Linux/amd64, > and that'd be it. > Anyone running anything else is an advanced or unusual user. > (the x86 packages would generally work on the popular AMD64 > machines, anyone wanting > native could build from source) > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Aug 11 07:24:45 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 11 Aug 2009 05:24:45 +0000 Subject: [M3devel] platform names? Message-ID: Can folks humor me and decide on names for the following: ALPHA_VMS or ALPHA_OPENVMS VMS is shorter IA64_VMS or IA64_OPENVMS VMS is shorter "Open" implies "Posix" as I understand IA64_HPUX -- probably that is it PA32_LINUX or PA or HPPA or HPPA32 PA64_LINUX or HPPA64 gcc uses "hppa" and "hppa64". ALPHA_TRU64 or ALPHA_OSF or ALPHA_OSF1? gcc seems to use "osf1" MIPS32_IRIX probably right, new abi, ignore old abi or MIPSO32_IRIX or MIPSN32_IRIX ? MIPS64_IRIX probably right PPC32_AIX probably right PPC64_AIX probably right ARM_LINUX_UCLIBC? ARM_LINUX24? ARM_LINUX_USERTHREADS? ? Eventually I'd like to get to these, as long gcc supports them, unless I get a C backend working and porting work therefore declines. I have already run some of these OSes recently: AIX, Irix, Linux/hppa. Nothing on Alpha yet, nor VMS. Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Aug 11 07:34:28 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 11 Aug 2009 05:34:28 +0000 Subject: [M3devel] proposal for next release: moving some config file content into cm3 Message-ID: > cm3 should perhaps even move to an archictecture-specific directory. > /cm3/bin/I386_LINUX/cm3 One thing I forgot about here is where to install the likes of: jbook2:m3cc jay$ ls -1 */cm3cg I386_DARWIN-AMD64_FREEBSD/cm3cg I386_DARWIN-AMD64_LINUX/cm3cg I386_DARWIN-AMD64_NETBSD/cm3cg I386_DARWIN-AMD64_OPENBSD/cm3cg I386_DARWIN-FreeBSD4/cm3cg I386_DARWIN-I386_INTERIX/cm3cg I386_DARWIN-I386_OPENBSD/cm3cg Probably /cm3/bin/AMD64_FREEBSD/cm3cg This doesn't necessarily imply "solving" "where to put host specific files". These are target-specific. Eventually it might be nice provide cross compiler packages, for folks that have cross gcc/ld. I just have the config file probe around in the uninstalled tree for backends. If anyone could tackle writing a linker/loader for some systems, I'd be willing to reconsider all the extra C code, for some systems. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Aug 11 07:37:34 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 11 Aug 2009 05:37:34 +0000 Subject: [M3devel] targeting kernel instead of libc/pthreads? Message-ID: Does anyone - like the idea - can work on implementing Modula-3 threads over one/some/all of the kernel interfaces? In particular on Linux pthreads are usermode layer over something else. If we targeted the kernel interface, we could ignore uclibc vc. glibc vc. newlib. On the flip side -- is pthreads viable on non-NPTL kernels? It's not like the C interfaces weren't there. Or is Modula-3 sensitive to the odd semantics? Or is it just slightly or much too slow? Just throwing ideas out.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Aug 11 07:38:05 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 11 Aug 2009 05:38:05 +0000 Subject: [M3devel] proposal for next release: moving some config file content into cm3 Message-ID: [truncated again..] From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: RE: proposal for next release: moving some config file content into cm3 Date: Tue, 11 Aug 2009 05:34:28 +0000 > cm3 should perhaps even move to an archictecture-specific directory. > /cm3/bin/I386_LINUX/cm3 One thing I forgot about here is where to install the likes of: jbook2:m3cc jay$ ls -1 */cm3cg I386_DARWIN-AMD64_FREEBSD/cm3cg I386_DARWIN-AMD64_LINUX/cm3cg I386_DARWIN-AMD64_NETBSD/cm3cg I386_DARWIN-AMD64_OPENBSD/cm3cg I386_DARWIN-FreeBSD4/cm3cg I386_DARWIN-I386_INTERIX/cm3cg I386_DARWIN-I386_OPENBSD/cm3cg Probably /cm3/bin/AMD64_FREEBSD/cm3cg This doesn't necessarily imply "solving" "where to put host specific files". These are target-specific. Eventually it might be nice provide cross compiler packages, for folks that have cross gcc/ld. I just have the config file probe around in the uninstalled tree for backends. If anyone could tackle writing a linker/loader for some systems, I'd be willing to reconsider all the extra C code, for some systems. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Aug 11 08:11:17 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 11 Aug 2009 08:11:17 +0200 Subject: [M3devel] Package build/link errors on Solaris Message-ID: <20090811081117.xdm8121yu8ogw0o4@mail.elegosoft.com> There are lots of strage build/link errors on the two Solaris targets, see http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLsun/ http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/ Does anybody know offhand what's missing there? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Aug 11 08:22:13 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 11 Aug 2009 08:22:13 +0200 Subject: [M3devel] Package build/link errors on Solaris In-Reply-To: <20090811081117.xdm8121yu8ogw0o4@mail.elegosoft.com> References: <20090811081117.xdm8121yu8ogw0o4@mail.elegosoft.com> Message-ID: <20090811082213.o7sxi1znhgkg88gk@mail.elegosoft.com> Quoting Olaf Wagner : > There are lots of strage build/link errors on the two Solaris > targets, see > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLsun/ > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/ > > Does anybody know offhand what's missing there? Bad style to answer my own posts, but I've already found it. The X libraries are missing: -> archiving libm3ui.a ld: fatal: library -lXaw: not found ld: fatal: library -lXmu: not found ld: fatal: library -lXext: not found ld: fatal: library -lXt: not found ld: fatal: library -lX11: not found ld: fatal: File processing errors. No output written to libm3ui.so.5 collect2: ld returned 1 exit status make_lib => 1 Jay, did you remove the X installation? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Aug 11 15:37:30 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 11 Aug 2009 13:37:30 +0000 Subject: [M3devel] More Unix constants missing.... In-Reply-To: <1249638984.2745.11.camel@faramir.m3w.org> References: <1249638984.2745.11.camel@faramir.m3w.org> Message-ID: please review: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/unix/Common/Uconstants.c.diff?r1=1.36;r2=1.37 http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/unix/Common/Unix.i3.diff?r1=1.26;r2=1.27 and for a longer list of potentially removed constants to be restored: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/unix/Common/Unix.txt?rev=1.1;content-type=text%2Fplain - Jay > From: dragisha at m3w.org > To: m3devel at elegosoft.com > Date: Fri, 7 Aug 2009 11:56:24 +0200 > Subject: [M3devel] More Unix constants missing.... > > Can we have them, in both HEAD ad RC2 branch? > > TIA, > dd > > === > CONST > TIOCMGET = 16_5415; > TIOCMSET = 16_5418; > > Bits = ARRAY StatusBits OF CARDINAL { > Unix.TIOCM_LE, > Unix.TIOCM_DTR, > Unix.TIOCM_RTS, > Unix.TIOCM_ST, > Unix.TIOCM_SR, > Unix.TIOCM_CTS, > Unix.TIOCM_CAR, > Unix.TIOCM_RNG, > Unix.TIOCM_DSR > }; > > -- > Dragi?a Duri? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Aug 11 15:41:39 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 11 Aug 2009 13:41:39 +0000 Subject: [M3devel] Package build/link errors on Solaris In-Reply-To: <20090811082213.o7sxi1znhgkg88gk@mail.elegosoft.com> References: <20090811081117.xdm8121yu8ogw0o4@mail.elegosoft.com> <20090811082213.o7sxi1znhgkg88gk@mail.elegosoft.com> Message-ID: I thought I only removed static archives, in a quest for diskspace, arg. Not sure how to fix, might have to reinstall. Sorry. - Jay > Date: Tue, 11 Aug 2009 08:22:13 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Package build/link errors on Solaris > > Quoting Olaf Wagner : > > > There are lots of strage build/link errors on the two Solaris > > targets, see > > > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLsun/ > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/ > > > > Does anybody know offhand what's missing there? > > Bad style to answer my own posts, but I've already found it. The X > libraries are missing: > > -> archiving libm3ui.a > ld: fatal: library -lXaw: not found > ld: fatal: library -lXmu: not found > ld: fatal: library -lXext: not found > ld: fatal: library -lXt: not found > ld: fatal: library -lX11: not found > ld: fatal: File processing errors. No output written to libm3ui.so.5 > collect2: ld returned 1 exit status > make_lib => 1 > > Jay, did you remove the X installation? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Aug 11 15:48:01 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 11 Aug 2009 09:48:01 -0400 Subject: [M3devel] targeting kernel instead of libc/pthreads? In-Reply-To: References: Message-ID: <5E49131B-9F6E-4E8E-AEB3-398B401B38EF@cs.purdue.edu> On 11 Aug 2009, at 01:37, Jay K wrote: > Does anyone > - like the idea Perhaps an interesting "research" idea. Probably not for the mainstream, because it is so platform-specific and puts you at the mercy of changes to kernel interfaces as opposed to more stable POSIX APIs. > - can work on implementing > > Modula-3 threads over one/some/all of the kernel interfaces? > In particular on Linux pthreads are usermode layer over something > else. > > If we targeted the kernel interface, we could ignore uclibc vc. > glibc vc. newlib. > > On the flip side -- is pthreads viable on non-NPTL kernels? > It's not like the C interfaces weren't there. > Or is Modula-3 sensitive to the odd semantics? > Or is it just slightly or much too slow? > > Just throwing ideas out.. > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Aug 11 15:53:23 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 11 Aug 2009 13:53:23 +0000 Subject: [M3devel] Package build/link errors on Solaris In-Reply-To: <20090811082213.o7sxi1znhgkg88gk@mail.elegosoft.com> References: <20090811081117.xdm8121yu8ogw0o4@mail.elegosoft.com> <20090811082213.o7sxi1znhgkg88gk@mail.elegosoft.com> Message-ID: I think I'll attempt a new install this week, sorry. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Subject: RE: [M3devel] Package build/link errors on Solaris Date: Tue, 11 Aug 2009 13:41:39 +0000 I thought I only removed static archives, in a quest for diskspace, arg. Not sure how to fix, might have to reinstall. Sorry. - Jay > Date: Tue, 11 Aug 2009 08:22:13 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Package build/link errors on Solaris > > Quoting Olaf Wagner : > > > There are lots of strage build/link errors on the two Solaris > > targets, see > > > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLsun/ > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/ > > > > Does anybody know offhand what's missing there? > > Bad style to answer my own posts, but I've already found it. The X > libraries are missing: > > -> archiving libm3ui.a > ld: fatal: library -lXaw: not found > ld: fatal: library -lXmu: not found > ld: fatal: library -lXext: not found > ld: fatal: library -lXt: not found > ld: fatal: library -lX11: not found > ld: fatal: File processing errors. No output written to libm3ui.so.5 > collect2: ld returned 1 exit status > make_lib => 1 > > Jay, did you remove the X installation? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Tue Aug 11 16:14:10 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 11 Aug 2009 16:14:10 +0200 Subject: [M3devel] targeting kernel instead of libc/pthreads? In-Reply-To: References: Message-ID: <1250000050.14316.15.camel@faramir.m3w.org> Your data is pretty rusty here :) pthreads as library is of course "usermode layer over something". That something being O(1) kernel space thread implementation. On Tue, 2009-08-11 at 05:37 +0000, Jay K wrote: > > In particular on Linux pthreads are usermode layer over something > else. -- Dragi?a Duri? From jay.krell at cornell.edu Tue Aug 11 16:22:23 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 11 Aug 2009 14:22:23 +0000 Subject: [M3devel] targeting kernel instead of libc/pthreads? In-Reply-To: <1250000050.14316.15.camel@faramir.m3w.org> References: <1250000050.14316.15.camel@faramir.m3w.org> Message-ID: I'm aware of that. But I don't think it matches pthreads closely, but provides sufficient primitives. It is clone and futex. I expect the kernel interfaces to be stable and there are multiple, binary incompatible?, pthreads implementations. - Jay > Subject: Re: [M3devel] targeting kernel instead of libc/pthreads? > From: dragisha at m3w.org > To: jay.krell at cornell.edu > CC: hosking at cs.purdue.edu; m3devel at elegosoft.com > Date: Tue, 11 Aug 2009 16:14:10 +0200 > > Your data is pretty rusty here :) > > pthreads as library is of course "usermode layer over something". That > something being O(1) kernel space thread implementation. > > On Tue, 2009-08-11 at 05:37 +0000, Jay K wrote: > > > > In particular on Linux pthreads are usermode layer over something > > else. > -- > Dragi?a Duri? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Tue Aug 11 16:57:59 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 11 Aug 2009 16:57:59 +0200 Subject: [M3devel] targeting kernel instead of libc/pthreads? In-Reply-To: References: <1250000050.14316.15.camel@faramir.m3w.org> Message-ID: <1250002679.14316.26.camel@faramir.m3w.org> There is exactly one pthreads implementation in use, NPTL. That is really thin layer providing pthreads API. I don't think we can afford anything by reimplementing there, but we can loose pthreads abstraction. I'we not read Anthony's implementation for some time, but I remember he had some state tracking structures resembling earlier behaviour of user-space Modula-3 threads. These are not needed,really, except for some obscure tools and for at-all-prices compatibility. I don't know if it's still there, but if it is, it imposes some non-O(1)-ness, at least in Linux case where we have it. On Tue, 2009-08-11 at 14:22 +0000, Jay K wrote: > I'm aware of that. But I don't think it matches pthreads closely, but > provides sufficient primitives. It is clone and futex. > I expect the kernel interfaces to be stable and there are multiple, > binary incompatible?, pthreads implementations. > > - Jay > > > > Subject: Re: [M3devel] targeting kernel instead of libc/pthreads? > > From: dragisha at m3w.org > > To: jay.krell at cornell.edu > > CC: hosking at cs.purdue.edu; m3devel at elegosoft.com > > Date: Tue, 11 Aug 2009 16:14:10 +0200 > > > > Your data is pretty rusty here :) > > > > pthreads as library is of course "usermode layer over something". > That > > something being O(1) kernel space thread implementation. > > > > On Tue, 2009-08-11 at 05:37 +0000, Jay K wrote: > > > > > > In particular on Linux pthreads are usermode layer over something > > > else. > > -- > > Dragi?a Duri? > > -- Dragi?a Duri? From hosking at cs.purdue.edu Tue Aug 11 17:52:30 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 11 Aug 2009 11:52:30 -0400 Subject: [M3devel] targeting kernel instead of libc/pthreads? In-Reply-To: <1250002679.14316.26.camel@faramir.m3w.org> References: <1250000050.14316.15.camel@faramir.m3w.org> <1250002679.14316.26.camel@faramir.m3w.org> Message-ID: <423DD036-8AA3-4ECE-A364-F90672F35670@cs.purdue.edu> On 11 Aug 2009, at 10:57, Dragi?a Duri? wrote: > There is exactly one pthreads implementation in use, NPTL. > > That is really thin layer providing pthreads API. > > I don't think we can afford anything by reimplementing there, but we > can > loose pthreads abstraction. Agreed, I don't see the win. > I'we not read Anthony's implementation for some time, but I remember > he > had some state tracking structures resembling earlier behaviour of > user-space Modula-3 threads. These are not needed,really, except for > some obscure tools and for at-all-prices compatibility. I don't know > if > it's still there, but if it is, it imposes some non-O(1)-ness, at > least > in Linux case where we have it. My implementation is much lighter now -- thread state information is only ever used for the signal handling needed to suspend/resume thread during GC. Otherwise, no additional accounting in the normal case. LOCK is essentially pthread_mutex_lock/unlock. As far as I recall, for purposes of notification (Alert) we still manage wait queues explicitly, mostly because the semantics of signals and threads in different pthreads implementations varies significantly (I seem to remember Dragi?a's original approach was sufficient for Linux NPTL, but not portable to other platforms). > > On Tue, 2009-08-11 at 14:22 +0000, Jay K wrote: >> I'm aware of that. But I don't think it matches pthreads closely, but >> provides sufficient primitives. It is clone and futex. >> I expect the kernel interfaces to be stable and there are multiple, >> binary incompatible?, pthreads implementations. >> >> - Jay >> >> >>> Subject: Re: [M3devel] targeting kernel instead of libc/pthreads? >>> From: dragisha at m3w.org >>> To: jay.krell at cornell.edu >>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com >>> Date: Tue, 11 Aug 2009 16:14:10 +0200 >>> >>> Your data is pretty rusty here :) >>> >>> pthreads as library is of course "usermode layer over something". >> That >>> something being O(1) kernel space thread implementation. >>> >>> On Tue, 2009-08-11 at 05:37 +0000, Jay K wrote: >>>> >>>> In particular on Linux pthreads are usermode layer over something >>>> else. >>> -- >>> Dragi?a Duri? >>> > -- > Dragi?a Duri? From dragisha at m3w.org Tue Aug 11 21:48:31 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 11 Aug 2009 21:48:31 +0200 Subject: [M3devel] targeting kernel instead of libc/pthreads? In-Reply-To: <423DD036-8AA3-4ECE-A364-F90672F35670@cs.purdue.edu> References: <1250000050.14316.15.camel@faramir.m3w.org> <1250002679.14316.26.camel@faramir.m3w.org> <423DD036-8AA3-4ECE-A364-F90672F35670@cs.purdue.edu> Message-ID: <1250020111.14316.38.camel@faramir.m3w.org> Dragi?a used trusty techniques of reading existing source code, in this case Boehm's GC and testing his approach vs. one similar implementation he was able to find and compare. It checked well, and worked flawlessly for about 4 years in many applications and esp important in one I've designed to stress test it (my DC hub sw). But it was also many yrs ago. December of 2003.... I surely did not execute my code on anything else. And I also stopped using it once you made your code available and supported. It's nice when other fullfill your dreams - mine being first class citizenship of Modula-3 on modern OS's. And that includes relying on established standards like pthreads. On Tue, 2009-08-11 at 11:52 -0400, Tony Hosking wrote: > mostly because the semantics of signals and threads in > different pthreads implementations varies significantly (I seem to > remember Dragi?a's original approach was sufficient for Linux NPTL, > but not portable to other platforms). -- Dragi?a Duri? From wagner at elegosoft.com Wed Aug 12 01:10:38 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 12 Aug 2009 01:10:38 +0200 Subject: [M3devel] CM3 Release Engineering and Feedback Message-ID: <20090812011038.n57fqtq0m8o0s8so@mail.elegosoft.com> Hi again, I can imagine that everybody is a bit tired of all the mails concerning the public release of CM3 5.8 and its problems, but nonetheless I don't want this to become a one or two man show, so I'll summarize the current status again. o RC2 has been released and publicly announced on the m3announce list and in comp.lang.modul3. There are several problems though with the packages, so that we should provide another release candidate, hopefullly at the end of this week. o There hasn't been much feedback, neither from the list of active developers nor from end users for RC2. I'd really appreciate some more reports about installation attempts and the problems encountered. o There's still the open discussion about the location and search strategy for config files where no conclusion or agreement has been reached as far as I know. o There are also still open issues about the integration of system-dependent installation archives, update/improvement/rewrite of the web presentation etc. o There are several open issues concerned with concrete test failures and installation problems that would need to be taken care of. o Documentation for non-POSIX, especially Windows systems is still lacking, too. o The Hudson infrastructure for automatic continuous build and regression testing has grown significantly (mostly due to contributions of Jay Krell) that we will be able to build almost all major target platforms for this and possibly future releases with it. I won't be able to care for all these tasks and issues alone. All help is still appreciated. It shouldn't be difficult, as everything is checked-in (sources, documents) and/or publicly accessible (WWW, Hudson, Trac). As for me, I'm going to build RC3 and the final release, and may then invest some time in reviewing and improving the distributed Hudson setup, which has been created in a rather ad-hoc fashion, because I needed tools to control the release engineering process. There are also still the Elego ComPact and DCVS M3 packages which I started to review for publishing long ago, but have never had the time and energy to finish. I won't promise anything though. I'd really enjoy if the group of active CM3 users and developers would become more engaged and agile in the discussions and open tasks and make active use of the tools and infrastructure provided (Trac, Hudson, WiKi, etc.). And if we could use all the experience and passion assembled here to inspire others and create more interest in this great language. Thanks for your support and patience, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Aug 12 02:05:46 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 12 Aug 2009 00:05:46 +0000 Subject: [M3devel] cd / on Windows Message-ID: Just a note that forward slashes work with cd, but not with pushd. I'll fix "this" "soon". ("this" being setup.cmd and its production, not that pushd doesn't with forward slashes. :) My ideal is that setup.cmd and install.sh are constant, and driven by a text file next to them, setup.txt or install.txt or such. Or possibly appeneded to them if people really like that "static linkage"). - Jay From jay.krell at cornell.edu Wed Aug 12 02:14:35 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 12 Aug 2009 00:14:35 +0000 Subject: [M3devel] targeting kernel instead of libc/pthreads? In-Reply-To: <1250002679.14316.26.camel@faramir.m3w.org> References: <1250000050.14316.15.camel@faramir.m3w.org> <1250002679.14316.26.camel@faramir.m3w.org> Message-ID: > There is exactly one pthreads implementation in use, NPTL. > That is really thin layer providing pthreads API. Is it thin? Is it really the same and binary compatible among the various C libraries -- glibc, uclibc, newlib? Same struct sizes and initializers? (I'd hope the initializers are all NULL and the structs all just the size of a pointer, but that isn't always the case.) - Jay From dragisha at m3w.org Wed Aug 12 11:16:34 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 12 Aug 2009 11:16:34 +0200 Subject: [M3devel] targeting kernel instead of libc/pthreads? In-Reply-To: References: <1250000050.14316.15.camel@faramir.m3w.org> <1250002679.14316.26.camel@faramir.m3w.org> Message-ID: <1250068594.14316.49.camel@faramir.m3w.org> I believe it is as thin as it's realistic. Ulrich Drepper is.... rigorous :) As for various libs, I don't know. I use only glibc. But we speak pthreads here.... glibc has implementation of pthreads over NPTL. pthreads structures are what we look for - Anthony used these, portable parts of glibc pthreads... If structs differ, then differing ones are not pthreads. Period. On Wed, 2009-08-12 at 00:14 +0000, Jay K wrote: > > There is exactly one pthreads implementation in use, NPTL. > > That is really thin layer providing pthreads API. > > Is it thin? > Is it really the same and binary compatible among the various C libraries -- glibc, uclibc, newlib? Same struct sizes and initializers? (I'd hope the initializers are all NULL and the structs all just the size of a pointer, but that isn't always the case.) > > - Jay -- Dragi?a Duri? From wagner at elegosoft.com Wed Aug 12 15:22:10 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 12 Aug 2009 15:22:10 +0200 Subject: [M3devel] cd / on Windows In-Reply-To: References: Message-ID: <20090812152210.fa2rrrpa80go8088@mail.elegosoft.com> Quoting Jay K : > Just a note that forward slashes work with cd, but not with pushd. > I'll fix "this" "soon". > > ("this" being setup.cmd and its production, not that pushd doesn't > with forward slashes. :) My ideal is that setup.cmd and install.sh > are constant, and driven by a text file next to them, setup.txt or > install.txt or such. Or possibly appeneded to them if people really > like that "static linkage"). Please make setup.cmd report shipping failures, too. I don't think I've done that yet. And please include your Windows-specific installation packaging into make-dist.sh if the current platform is NT386. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Wed Aug 12 21:54:10 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 12 Aug 2009 21:54:10 +0200 Subject: [M3devel] A compile-time type is missing Message-ID: <1250106850.3281.20.camel@faramir.m3w.org> Any hint on debugging this? -- Dragi?a Duri? From jay.krell at cornell.edu Wed Aug 12 22:29:15 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 12 Aug 2009 20:29:15 +0000 Subject: [M3devel] A compile-time type is missing In-Reply-To: <1250106850.3281.20.camel@faramir.m3w.org> References: <1250106850.3281.20.camel@faramir.m3w.org> Message-ID: cd scripts OMIT_GCC=yes ./do-cm3-std.sh realclean OMIT_GCC=yes ./do-cm3-std.sh buildship ? - Jay ---------------------------------------- > From: dragisha at m3w.org > To: m3devel at elegosoft.com > Date: Wed, 12 Aug 2009 21:54:10 +0200 > Subject: [M3devel] A compile-time type is missing > > Any hint on debugging this? > > -- > Dragi?a Duri? > From dragisha at m3w.org Thu Aug 13 03:09:06 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 13 Aug 2009 03:09:06 +0200 Subject: [M3devel] A compile-time type is missing In-Reply-To: References: <1250106850.3281.20.camel@faramir.m3w.org> Message-ID: <1250125746.3281.27.camel@faramir.m3w.org> It was my code.. Dynamically loaded shared lib plugins... Don't ask. Works ok now. On Wed, 2009-08-12 at 20:29 +0000, Jay K wrote: > cd scripts > OMIT_GCC=yes ./do-cm3-std.sh realclean > OMIT_GCC=yes ./do-cm3-std.sh buildship > ? > > - Jay > > > > > ---------------------------------------- > > From: dragisha at m3w.org > > To: m3devel at elegosoft.com > > Date: Wed, 12 Aug 2009 21:54:10 +0200 > > Subject: [M3devel] A compile-time type is missing > > > > Any hint on debugging this? > > > > -- > > Dragi?a Duri? > > -- Dragi?a Duri? From vapier at gentoo.org Thu Aug 13 05:29:19 2009 From: vapier at gentoo.org (Mike Frysinger) Date: Wed, 12 Aug 2009 23:29:19 -0400 Subject: [M3devel] targeting kernel instead of libc/pthreads? In-Reply-To: References: <1250002679.14316.26.camel@faramir.m3w.org> Message-ID: <200908122329.23246.vapier@gentoo.org> On Tuesday 11 August 2009 20:14:35 Jay K wrote: > > There is exactly one pthreads implementation in use, NPTL. > > That is really thin layer providing pthreads API. > > Is it thin? > Is it really the same and binary compatible among the various C libraries > -- glibc, uclibc, newlib? Same struct sizes and initializers? (I'd hope the > initializers are all NULL and the structs all just the size of a pointer, > but that isn't always the case.) you can never expect binary compatibility across C libraries. uClibc does use the NPTL source tree from glibc, but that doesnt mean it's binary compatible at either the libc or libpthread level. newlib doesnt do shared libraries, so binary compatibility is irrelevant. but i too think it's absolutely crazy to attempt to write your own threading layer on top of clone(). -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From wagner at elegosoft.com Thu Aug 13 10:51:51 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 13 Aug 2009 10:51:51 +0200 Subject: [M3devel] cm3-tst-all-pkgs failures Message-ID: <20090813105151.dlgyga1y0csgkc4k@mail.elegosoft.com> I've made a mistake this morning adding the example packages to scripts/pkginfo.txt. For reasons still to be investigated it seems that the package examples/istvan is not in the repository (at least on the branch) but the package objects is (which is missing). I just took an ls listing from one of my workspaces. As I haven't got CVS access for some time, can somebody remove the examples/istvan package from scripts/pkginfo.txt on the 5.8 release branch? Thanks in advance, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Thu Aug 13 12:47:47 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 13 Aug 2009 06:47:47 -0400 Subject: [M3devel] CM3 Release Engineering and Feedback In-Reply-To: <20090812011038.n57fqtq0m8o0s8so@mail.elegosoft.com> References: <20090812011038.n57fqtq0m8o0s8so@mail.elegosoft.com> Message-ID: <20090813104747.GA18662@topoi.pooq.com> On Wed, Aug 12, 2009 at 01:10:38AM +0200, Olaf Wagner wrote: > Hi again, > > I can imagine that everybody is a bit tired of all the mails concerning > the public release of CM3 5.8 and its problems, but nonetheless I > don't want this to become a one or two man show, so I'll summarize > the current status again. > > o RC2 has been released and publicly announced on the m3announce list > and in comp.lang.modul3. There are several problems though with the > packages, so that we should provide another release candidate, hopefullly > at the end of this week. > > o There hasn't been much feedback, neither from the list of active > developers nor from end users for RC2. I'd really appreciate some > more reports about installation attempts and the problems encountered. Well, I'll provide more with the next RC. The hudson directpry was pretty much a show-stopper. I'd expect the same problem to be there on the other platforms. -- hendrik > > o There's still the open discussion about the location and search > strategy for config files where no conclusion or agreement has > been reached as far as I know. As long as (1) it is found in a platform-standard place, and (2) there's an easy way for a user to override this via command-line parameter or environment variable, the further details probably don't matter that much. > ... > > There are also still the Elego ComPact and DCVS M3 packages which > I started to review for publishing long ago, but have never had > the time and energy to finish. I won't promise anything though. What are these DCVS packages? > > Thanks for your support and patience, You're welcome. -- hendrik From wagner at elegosoft.com Thu Aug 13 14:38:06 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 13 Aug 2009 14:38:06 +0200 Subject: [M3devel] CM3 Release Engineering and Feedback Message-ID: <20090813143806.udmpiz76ecg0scgs@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > On Wed, Aug 12, 2009 at 01:10:38AM +0200, Olaf Wagner wrote: >> o There hasn't been much feedback, neither from the list of active >> developers nor from end users for RC2. I'd really appreciate some >> more reports about installation attempts and the problems encountered. > > Well, I'll provide more with the next RC. The hudson directory was > pretty much a show-stopper. I'd expect the same problem to be there on > the other platforms. The simple work-around would be to call cm3 -build on the packages again, which should only adapt the broken .M3SHIP files. I've added a check to make-dist.sh which should prevent such accidents in the future. Probably something slightly different will then remain undetected though ;-) But never mind, I'll try to build some RC3 packages for AMD64_LINUX at least at the weekend. >> o There's still the open discussion about the location and search >> strategy for config files where no conclusion or agreement has >> been reached as far as I know. > > As long as > (1) it is found in a platform-standard place, and > (2) there's an easy way for a user to override this via command-line > parameter or environment variable, > the further details probably don't matter that much. I had the impression that there were decidedly different and contradicting opinions on that matter. Maybe I mistook that though. >> There are also still the Elego ComPact and DCVS M3 packages which >> I started to review for publishing long ago, but have never had >> the time and energy to finish. I won't promise anything though. > > What are these DCVS packages? A distributed version of CVS. It's already available, but I'd like to add some or all of the M3 packages to CM3. The distribution part is mainly based on an extended CVSup. There were more interesting features added to CVS like snapshots and changesets, too. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Thu Aug 13 14:49:12 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 13 Aug 2009 08:49:12 -0400 Subject: [M3devel] CM3 Release Engineering and Feedback In-Reply-To: <20090813143806.udmpiz76ecg0scgs@mail.elegosoft.com> References: <20090813143806.udmpiz76ecg0scgs@mail.elegosoft.com> Message-ID: <20090813124912.GA18887@topoi.pooq.com> On Thu, Aug 13, 2009 at 02:38:06PM +0200, Olaf Wagner wrote: > Quoting hendrik at topoi.pooq.com: > > >On Wed, Aug 12, 2009 at 01:10:38AM +0200, Olaf Wagner wrote: > >> o There hasn't been much feedback, neither from the list of active > >> developers nor from end users for RC2. I'd really appreciate some > >> more reports about installation attempts and the problems encountered. > > > >Well, I'll provide more with the next RC. The hudson directory was > >pretty much a show-stopper. I'd expect the same problem to be there on > >the other platforms. > > The simple work-around would be to call cm3 -build on the packages > again, which should only adapt the broken .M3SHIP files. > > I've added a check to make-dist.sh which should prevent such > accidents in the future. Probably something slightly different > will then remain undetected though ;-) > > But never mind, I'll try to build some RC3 packages for AMD64_LINUX > at least at the weekend. > > >> o There's still the open discussion about the location and search > >> strategy for config files where no conclusion or agreement has > >> been reached as far as I know. > > > >As long as > > (1) it is found in a platform-standard place, and > > (2) there's an easy way for a user to override this via command-line > >parameter or environment variable, > >the further details probably don't matter that much. > > I had the impression that there were decidedly different and > contradicting opinions on that matter. Maybe I mistook that though. There may be. But as long as what's implemented meets these criteria, I don't think further details matter as much as havein a release out. The requirement that the standard config file is in a platform-standard place will require platform-dependent code somewhere. But as long as we still put everything in /usr/local/cm3, there's not all that much to be done. Getting Modula 3 into Debian will require us to be fussy, though. But I didn't think that was teh goal for this release. > > >>There are also still the Elego ComPact and DCVS M3 packages which > >>I started to review for publishing long ago, but have never had > >>the time and energy to finish. I won't promise anything though. > > > >What are these DCVS packages? > > A distributed version of CVS. It's already available, but I'd like > to add some or all of the M3 packages to CM3. The distribution part > is mainly based on an extended CVSup. There were more interesting > features added to CVS like snapshots and changesets, too. It seems that migration to DCVS might be easier than migration to monotone or svn or ... -- hendrik From wagner at elegosoft.com Thu Aug 13 17:35:41 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 13 Aug 2009 17:35:41 +0200 Subject: [M3devel] CM3 Release Engineering and Feedback In-Reply-To: <20090813124912.GA18887@topoi.pooq.com> References: <20090813143806.udmpiz76ecg0scgs@mail.elegosoft.com> <20090813124912.GA18887@topoi.pooq.com> Message-ID: <20090813173541.782ks2dyjkg8o84s@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > On Thu, Aug 13, 2009 at 02:38:06PM +0200, Olaf Wagner wrote: >> >What are these DCVS packages? >> >> A distributed version of CVS. It's already available, but I'd like >> to add some or all of the M3 packages to CM3. The distribution part >> is mainly based on an extended CVSup. There were more interesting >> features added to CVS like snapshots and changesets, too. > > It seems that migration to DCVS might be easier than migration to > monotone or svn or ... It wasn't my intention to suggest such a migration, nor would I recommend it. I still think CVS is sufficient for our requirements, but if developers want something newer or better we should try Subversion or Perforce or indeed one of the distributed tools like git or mercurial etc. Though I don't really see the advantages of such a tool for our use. Migration would be easy though, as DCVS is only an extension of CVS, so the actual database does not need to be changed, except for the administrative data. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Fri Aug 14 01:25:42 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 13 Aug 2009 19:25:42 -0400 Subject: [M3devel] CM3 Release Engineering and Feedback In-Reply-To: <20090813173541.782ks2dyjkg8o84s@mail.elegosoft.com> References: <20090813143806.udmpiz76ecg0scgs@mail.elegosoft.com> <20090813124912.GA18887@topoi.pooq.com> <20090813173541.782ks2dyjkg8o84s@mail.elegosoft.com> Message-ID: <20090813232542.GA19898@topoi.pooq.com> On Thu, Aug 13, 2009 at 05:35:41PM +0200, Olaf Wagner wrote: > Quoting hendrik at topoi.pooq.com: > > >On Thu, Aug 13, 2009 at 02:38:06PM +0200, Olaf Wagner wrote: > >>>What are these DCVS packages? > >> > >>A distributed version of CVS. It's already available, but I'd like > >>to add some or all of the M3 packages to CM3. The distribution part > >>is mainly based on an extended CVSup. There were more interesting > >>features added to CVS like snapshots and changesets, too. > > > >It seems that migration to DCVS might be easier than migration to > >monotone or svn or ... > > It wasn't my intention to suggest such a migration, nor would I > recommend it. I still think CVS is sufficient for our requirements, > but if developers want something newer or better we should try Subversion > or Perforce or indeed one of the distributed tools like git or > mercurial etc. Though I don't really see the advantages of such > a tool for our use. If I thought CVS wsa great, I'd be using it for my own stuff. I'm not. I'm using monotone. > > Migration would be easy though, as DCVS is only an extension of CVS, > so the actual database does not need to be changed, except for the > administrative data. That's the one (and prossibly only) advantage of DVCS. -- hendrik From rcoleburn at scires.com Fri Aug 14 17:21:51 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 14 Aug 2009 11:21:51 -0400 Subject: [M3devel] something broken on Windows Message-ID: <4A8547DB.1E75.00D7.1@scires.com> Not sure what is wrong, but something is broken on Windows. I can't get anything to compile anymore after updating. Tried both my scripts and Jay's python. Both fail. Don't have time to debug right now. Here is the failure from using Jay's upgrade.py script: .... no packages left == package C:\cm3\Sandbox\cm3\m3-win\import-libs == +++ C:\cm3\bin\cm3.exe -build -DROOT=C:/cm3/Sandbox/cm3 -DCM3_VERSION_TEXT=d5. 8.2 -DCM3_VERSION_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ C:\cm3\Sandbox\cm3\m3-sys\cminstall\src\config-no-install\NT386, line 115: synta x error: missing: = (found: ) Fatal Error: package build failed *** execution of [, ] failed *** C:\cm3\Sandbox\cm3\scripts\python> Regards, Randy CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Fri Aug 14 17:27:11 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 14 Aug 2009 11:27:11 -0400 Subject: [M3devel] examples should not be in PkgInfo.txt Message-ID: <4A85491C.1E75.00D7.1@scires.com> I see that someone has put some of the examples folder packages into PkgInfo.txt std group. None of these packages in the "examples" folder should go into PkgInfo.txt. Reason is that these are examples meant to be built using CM3IDE. CM3IDE will create a package folder in the user's private repository for the example and build it there locally. We don't want to build and ship these as part of the std distribution. Only the sources are needed. The "examples" folder and its contents need to be copied to the root of your cm3 installation. That's all. Regards, Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Aug 14 18:18:38 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 14 Aug 2009 18:18:38 +0200 Subject: [M3devel] examples should not be in PkgInfo.txt In-Reply-To: <4A85491C.1E75.00D7.1@scires.com> References: <4A85491C.1E75.00D7.1@scires.com> Message-ID: <20090814181838.byoxem2jkkwww8og@mail.elegosoft.com> Quoting Randy Coleburn : > I see that someone has put some of the examples folder packages into > PkgInfo.txt std group. > > None of these packages in the "examples" folder should go into PkgInfo.txt. > > Reason is that these are examples meant to be built using CM3IDE. > CM3IDE will create a package folder in the user's private repository > for the example and build it there locally. We don't want to build > and ship these as part of the std distribution. Only the sources > are needed. The "examples" folder and its contents need to be > copied to the root of your cm3 installation. That's all. I put them there, because they were not packed into the installation archives. They can also not be build with the usual tooling at all. What's the problem with them being included in the package list? If they are only useful for cm3ide, they should probably be part of that package (i.e. moved from cm3/examples to cm3/m3-sys/cm3ide/examples). Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Aug 14 22:55:13 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 14 Aug 2009 20:55:13 +0000 Subject: [M3devel] something broken on Windows In-Reply-To: <4A8547DB.1E75.00D7.1@scires.com> References: <4A8547DB.1E75.00D7.1@scires.com> Message-ID: head or release? It's a simple quake syntax error either way. ________________________________ > Date: Fri, 14 Aug 2009 11:21:51 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: [M3devel] something broken on Windows > > > > > > > > Not sure what is wrong, but something is broken on Windows. I can't get anything to compile anymore after updating. > > > > Tried both my scripts and Jay's python. Both fail. > > > > Don't have time to debug right now. > > > > Here is the failure from using Jay's upgrade.py script: > > > > .... > > no packages left > == package C:\cm3\Sandbox\cm3\m3-win\import-libs == > > > > +++ C:\cm3\bin\cm3.exe -build -DROOT=C:/cm3/Sandbox/cm3 -DCM3_VERSION_TEXT=d5. > 8.2 -DCM3_VERSION_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ > C:\cm3\Sandbox\cm3\m3-sys\cminstall\src\config-no-install\NT386, line 115: synta > x error: missing: = (found: ) > Fatal Error: package build failed > *** execution of [,> pFunction at 0x00B599B0>] failed *** > > > > C:\cm3\Sandbox\cm3\scripts\python> > > > > Regards, > > Randy From rcoleburn at scires.com Sat Aug 15 00:11:41 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 14 Aug 2009 18:11:41 -0400 Subject: [M3devel] something broken on Windows In-Reply-To: References: <4A8547DB.1E75.00D7.1@scires.com> Message-ID: <4A85A7E8.1E75.00D7.1@scires.com> Jay: For the output below, it was taken from an XP machine that gets the HEAD branch. I did find some differences in the way it "works" by getting the release branch on a different machine (Vista). Both of these used to work, so not sure what is wrong now. Regards, Randy >>> Jay K 8/14/2009 4:55 PM >>> head or release? It's a simple quake syntax error either way. ________________________________ > Date: Fri, 14 Aug 2009 11:21:51 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: [M3devel] something broken on Windows > > > > > > > > Not sure what is wrong, but something is broken on Windows. I can't get anything to compile anymore after updating. > > > > Tried both my scripts and Jay's python. Both fail. > > > > Don't have time to debug right now. > > > > Here is the failure from using Jay's upgrade.py script: > > > > .... > > no packages left > == package C:\cm3\Sandbox\cm3\m3-win\import-libs == > > > > +++ C:\cm3\bin\cm3.exe -build -DROOT=C:/cm3/Sandbox/cm3 -DCM3_VERSION_TEXT=d5. > 8.2 -DCM3_VERSION_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ > C:\cm3\Sandbox\cm3\m3-sys\cminstall\src\config-no-install\NT386, line 115: synta > x error: missing: = (found: ) > Fatal Error: package build failed > *** execution of [,> pFunction at 0x00B599B0>] failed *** > > > > C:\cm3\Sandbox\cm3\scripts\python> > > > > Regards, > > Randy CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Aug 15 01:13:50 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 14 Aug 2009 23:13:50 +0000 Subject: [M3devel] something broken on Windows In-Reply-To: <4A85A7E8.1E75.00D7.1@scires.com> References: <4A8547DB.1E75.00D7.1@scires.com> <4A85A7E8.1E75.00D7.1@scires.com> Message-ID: Look at the file/line the error complains about: >> C:\cm3\Sandbox\cm3\m3-sys\cminstall\src\config-no-install\NT386, line 115: synta >> x error: missing: = (found: ) no mystery; fixed. - Jay ________________________________ > Date: Fri, 14 Aug 2009 18:11:41 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] something broken on Windows > > > > > > > > Jay: For the output below, it was taken from an XP machine that gets the HEAD branch. > > I did find some differences in the way it "works" by getting the release branch on a different machine (Vista). > > > > Both of these used to work, so not sure what is wrong now. > > > > Regards, > > Randy > >>>> Jay K 8/14/2009 4:55 PM>>> > > head or release? > It's a simple quake syntax error either way. > > > > > ________________________________ >> Date: Fri, 14 Aug 2009 11:21:51 -0400 >> From: rcoleburn at scires.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] something broken on Windows >> >> >> >> >> >> >> >> Not sure what is wrong, but something is broken on Windows. I can't get anything to compile anymore after updating. >> >> >> >> Tried both my scripts and Jay's python. Both fail. >> >> >> >> Don't have time to debug right now. >> >> >> >> Here is the failure from using Jay's upgrade.py script: >> >> >> >> .... >> >> no packages left >> == package C:\cm3\Sandbox\cm3\m3-win\import-libs == >> >> >> >> +++ C:\cm3\bin\cm3.exe -build -DROOT=C:/cm3/Sandbox/cm3 -DCM3_VERSION_TEXT=d5. >> 8.2 -DCM3_VERSION_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ >> C:\cm3\Sandbox\cm3\m3-sys\cminstall\src\config-no-install\NT386, line 115: synta >> x error: missing: = (found: ) >> Fatal Error: package build failed >> *** execution of [,> pFunction at 0x00B599B0>] failed *** >> >> >> >> C:\cm3\Sandbox\cm3\scripts\python> >> >> >> >> Regards, >> >> Randy From rcoleburn at scires.com Sat Aug 15 01:53:40 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 14 Aug 2009 19:53:40 -0400 Subject: [M3devel] examples should not be in PkgInfo.txt In-Reply-To: <20090814181838.byoxem2jkkwww8og@mail.elegosoft.com> References: <4A85491C.1E75.00D7.1@scires.com> <20090814181838.byoxem2jkkwww8og@mail.elegosoft.com> Message-ID: <4A85BFCE.1E75.00D7.1@scires.com> Agree that they are useful for CM3IDE. Is there a way to have CM3IDE ship this folder to the cm3 root, e.g., C:\cm3\examples, when it is built and shipped? Otherwise, user has to know to copy the folder there. This only has to be done once, so copying the folder at the time CM3IDE is built and installed seems logical. Examples folder is strictly a set of source packages. There should be no derived files there. When user browses to a particular example in CM3IDE and asks to build it, CM3IDE will create a package containing the source of the example and the derived files in the user's private repository. That way each user gets their own private copy to muck around with. Indeed, entire examples folder tree can be marked read-only without any ill-effect because of the way CM3IDE works. Regards, Randy >>> Olaf Wagner 8/14/2009 12:18 PM >>> Quoting Randy Coleburn : > I see that someone has put some of the examples folder packages into > PkgInfo.txt std group. > > None of these packages in the "examples" folder should go into PkgInfo.txt. > > Reason is that these are examples meant to be built using CM3IDE. > CM3IDE will create a package folder in the user's private repository > for the example and build it there locally. We don't want to build > and ship these as part of the std distribution. Only the sources > are needed. The "examples" folder and its contents need to be > copied to the root of your cm3 installation. That's all. I put them there, because they were not packed into the installation archives. They can also not be build with the usual tooling at all. What's the problem with them being included in the package list? If they are only useful for cm3ide, they should probably be part of that package (i.e. moved from cm3/examples to cm3/m3-sys/cm3ide/examples). Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Aug 15 06:14:38 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 15 Aug 2009 04:14:38 +0000 Subject: [M3devel] examples should not be in PkgInfo.txt In-Reply-To: <4A85BFCE.1E75.00D7.1@scires.com> References: <4A85491C.1E75.00D7.1@scires.com> <20090814181838.byoxem2jkkwww8og@mail.elegosoft.com> <4A85BFCE.1E75.00D7.1@scires.com> Message-ID: > when it is built Trivial. > when it is shipped Maybe trivial. An empty directory or with contents? If it has contents, just ship the contents. If it is empty, there may or may not be a way currently. Generally you shouldn't write anything to the installation during build, only ship. And if under the influence of overrides, you shouldn't touch the installation at all -- which falls out of not touching during build and ship isn't allowed. (but maybe for next release this whole override thing goes away -- just clone the existing install and ship to it while building, no need to ever split build from ship) You can in general do pretty arbirary things in build and ship. You are limited by the quake builtins, which are fairly substantial, what you can do by running comamnd lines which is also pretty substantial but a recurring portability hazard (Olaf write some .sh; I write some .cmd or .py; repeat), and what you add to quake, which is basically unlimited, though then a hazard regarding building with old versions, you can probe for what is there with if defined("foo") use foo end. I haven't seen that there is a good clean way to add stuff and make it trivially available either at build or ship. I was accidentally doing ship stuff at build time like with the symlinks and stuff. Some folks resort to writing into .m3ship which seems sleazy. It is the underlying mechanism, but seems maybe worth abstracting. You know -- what if it is open by cm3 and disallowing other writers or has been flushed at other than a line boundary? I think maybe better would be to have .m3ship say if exists(m3user.ship) include(m3user.ship) end or such, and then m3user.ship is where users can write to. or even simply, ship("foo") writes "foo" into .m3ship. There is an ambiguity between declarative and imperative code -- the stuff in .m3ship might be order dependent and you might not know where in the order you are. - Jay ________________________________ > Date: Fri, 14 Aug 2009 19:53:40 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] examples should not be in PkgInfo.txt > > > > > > > > Agree that they are useful for CM3IDE. > > > > Is there a way to have CM3IDE ship this folder to the cm3 root, e.g., C:\cm3\examples, when it is built and shipped? Otherwise, user has to know to copy the folder there. This only has to be done once, so copying the folder at the time CM3IDE is built and installed seems logical. > > > > Examples folder is strictly a set of source packages. There should be no derived files there. When user browses to a particular example in CM3IDE and asks to build it, CM3IDE will create a package containing the source of the example and the derived files in the user's private repository. That way each user gets their own private copy to muck around with. > > > > Indeed, entire examples folder tree can be marked read-only without any ill-effect because of the way CM3IDE works. > > > > Regards, > > Randy > >>>> Olaf Wagner 8/14/2009 12:18 PM>>> > Quoting Randy Coleburn : > >> I see that someone has put some of the examples folder packages into >> PkgInfo.txt std group. >> >> None of these packages in the "examples" folder should go into PkgInfo.txt. >> >> Reason is that these are examples meant to be built using CM3IDE. >> CM3IDE will create a package folder in the user's private repository >> for the example and build it there locally. We don't want to build >> and ship these as part of the std distribution. Only the sources >> are needed. The "examples" folder and its contents need to be >> copied to the root of your cm3 installation. That's all. > > I put them there, because they were not packed into the installation > archives. They can also not be build with the usual tooling at all. > > What's the problem with them being included in the package list? > > If they are only useful for cm3ide, they should probably be part of > that package (i.e. moved from cm3/examples to cm3/m3-sys/cm3ide/examples). > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From rcoleburn at scires.com Sat Aug 15 07:59:10 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Sat, 15 Aug 2009 01:59:10 -0400 Subject: [M3devel] examples should not be in PkgInfo.txt In-Reply-To: References: <4A85491C.1E75.00D7.1@scires.com> <20090814181838.byoxem2jkkwww8og@mail.elegosoft.com> <4A85BFCE.1E75.00D7.1@scires.com> Message-ID: <4A861576.1E75.00D7.1@scires.com> Sorry, I should be more precise. I meant when "shipped", not when "built". The examples folder is just a collection of source packages. Each source package has an HTML file that CM3IDE displays to the user as instructive information about how to use the example. The entire examples folder and its contents need to be at the root of your cm3 install, e.g., C:\cm3\examples, in order for CM3IDE to locate and use it. Of course, if one is not going to use CM3IDE, the folder isn't necessary. Thus, the thought is that when you do "cm3 -ship" on the CM3IDE package it would be good to ensure the example folder is instantiated in the cm3 tree at that time. Thus, if there is a way to do this via some extra code in the m3makefile for CM3IDE that would be fine and we could keep the examples folder as part of the CM3IDE package source tree. Regards, Randy >>> Jay K 8/15/2009 12:14 AM >>> > when it is built Trivial. > when it is shipped Maybe trivial. An empty directory or with contents? If it has contents, just ship the contents. If it is empty, there may or may not be a way currently. Generally you shouldn't write anything to the installation during build, only ship. And if under the influence of overrides, you shouldn't touch the installation at all -- which falls out of not touching during build and ship isn't allowed. (but maybe for next release this whole override thing goes away -- just clone the existing install and ship to it while building, no need to ever split build from ship) You can in general do pretty arbirary things in build and ship. You are limited by the quake builtins, which are fairly substantial, what you can do by running comamnd lines which is also pretty substantial but a recurring portability hazard (Olaf write some .sh; I write some .cmd or .py; repeat), and what you add to quake, which is basically unlimited, though then a hazard regarding building with old versions, you can probe for what is there with if defined("foo") use foo end. I haven't seen that there is a good clean way to add stuff and make it trivially available either at build or ship. I was accidentally doing ship stuff at build time like with the symlinks and stuff. Some folks resort to writing into .m3ship which seems sleazy. It is the underlying mechanism, but seems maybe worth abstracting. You know -- what if it is open by cm3 and disallowing other writers or has been flushed at other than a line boundary? I think maybe better would be to have .m3ship say if exists(m3user.ship) include(m3user.ship) end or such, and then m3user.ship is where users can write to. or even simply, ship("foo") writes "foo" into .m3ship. There is an ambiguity between declarative and imperative code -- the stuff in .m3ship might be order dependent and you might not know where in the order you are. - Jay ________________________________ > Date: Fri, 14 Aug 2009 19:53:40 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] examples should not be in PkgInfo.txt > > > > > > > > Agree that they are useful for CM3IDE. > > > > Is there a way to have CM3IDE ship this folder to the cm3 root, e.g., C:\cm3\examples, when it is built and shipped? Otherwise, user has to know to copy the folder there. This only has to be done once, so copying the folder at the time CM3IDE is built and installed seems logical. > > > > Examples folder is strictly a set of source packages. There should be no derived files there. When user browses to a particular example in CM3IDE and asks to build it, CM3IDE will create a package containing the source of the example and the derived files in the user's private repository. That way each user gets their own private copy to muck around with. > > > > Indeed, entire examples folder tree can be marked read-only without any ill-effect because of the way CM3IDE works. > > > > Regards, > > Randy > >>>> Olaf Wagner 8/14/2009 12:18 PM>>> > Quoting Randy Coleburn : > >> I see that someone has put some of the examples folder packages into >> PkgInfo.txt std group. >> >> None of these packages in the "examples" folder should go into PkgInfo.txt. >> >> Reason is that these are examples meant to be built using CM3IDE. >> CM3IDE will create a package folder in the user's private repository >> for the example and build it there locally. We don't want to build >> and ship these as part of the std distribution. Only the sources >> are needed. The "examples" folder and its contents need to be >> copied to the root of your cm3 installation. That's all. > > I put them there, because they were not packed into the installation > archives. They can also not be build with the usual tooling at all. > > What's the problem with them being included in the package list? > > If they are only useful for cm3ide, they should probably be part of > that package (i.e. moved from cm3/examples to cm3/m3-sys/cm3ide/examples). > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Aug 15 10:37:21 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 15 Aug 2009 10:37:21 +0200 Subject: [M3devel] examples should not be in PkgInfo.txt In-Reply-To: <4A861576.1E75.00D7.1@scires.com> References: <4A85491C.1E75.00D7.1@scires.com> <20090814181838.byoxem2jkkwww8og@mail.elegosoft.com> <4A85BFCE.1E75.00D7.1@scires.com> <4A861576.1E75.00D7.1@scires.com> Message-ID: <20090815103721.a5ded2wusc4ow8wk@mail.elegosoft.com> So the correct way to handle the cm3ide examples would be o mv the sources from the top of cm3 to cm3/m3-sys/cm3ide/examples (or rather cm3ide/src/exmaples?) o remove them from the pkginfo.txt file o ensure that they get shipped to INSTALL_ROOT/examples when cm3ide is installed ? I can take care of that over the weekend, or one of you can do it if you like. Just let me know. Olaf Quoting Randy Coleburn : > Sorry, I should be more precise. I meant when "shipped", not when > "built". > The examples folder is just a collection of source packages. Each > source package has an HTML file that CM3IDE displays to the user as > instructive information about how to use the example. The entire > examples folder and its contents need to be at the root of your cm3 > install, e.g., C:\cm3\examples, in order for CM3IDE to locate and use > it. Of course, if one is not going to use CM3IDE, the folder isn't > necessary. Thus, the thought is that when you do "cm3 -ship" on the > CM3IDE package it would be good to ensure the example folder is > instantiated in the cm3 tree at that time. Thus, if there is a way to > do this via some extra code in the m3makefile for CM3IDE that would be > fine and we could keep the examples folder as part of the CM3IDE package > source tree. > Regards, > Randy > >>>> Jay K 8/15/2009 12:14 AM >>> > >> when it is built > > Trivial. > >> when it is shipped > > Maybe trivial. An empty directory or with contents? > If it has contents, just ship the contents. > If it is empty, there may or may not be a way currently. > > > Generally you shouldn't write anything to the installation during > build, only ship. > And if under the influence of overrides, you shouldn't touch the > installation at all -- which falls out of not touching during build and > ship isn't allowed. > (but maybe for next release this whole override thing goes away -- just > clone the existing install and ship to it while building, no need to > ever split build from ship) > > > You can in general do pretty arbirary things in build and ship. > You are limited by the quake builtins, which are fairly substantial, > what you can do by running comamnd lines which is also pretty > substantial but a recurring portability hazard (Olaf write some .sh; I > write some .cmd or .py; repeat), and what you add to quake, which is > basically unlimited, though then a hazard regarding building with old > versions, you can probe for what is there with if defined("foo") use foo > end. > > > I haven't seen that there is a good clean way to add stuff and make it > trivially available either at build or ship. > > I was accidentally doing ship stuff at build time like with the > symlinks and stuff. > > Some folks resort to writing into .m3ship which seems sleazy. > It is the underlying mechanism, but seems maybe worth abstracting. > You know -- what if it is open by cm3 and disallowing other writers > or has been flushed at other than a line boundary? > > I think maybe better would be to have .m3ship > say if exists(m3user.ship) > include(m3user.ship) > end > > or such, and then m3user.ship is where users can write to. > > or even simply, ship("foo") writes "foo" into .m3ship. > > There is an ambiguity between declarative and imperative code -- the > stuff in .m3ship might be order dependent and you might not know where > in the order you are. > > > - Jay > > > ________________________________ >> Date: Fri, 14 Aug 2009 19:53:40 -0400 >> From: rcoleburn at scires.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] examples should not be in PkgInfo.txt >> >> >> >> >> >> >> >> Agree that they are useful for CM3IDE. >> >> >> >> Is there a way to have CM3IDE ship this folder to the cm3 root, e.g., > C:\cm3\examples, when it is built and shipped? Otherwise, user has to > know to copy the folder there. This only has to be done once, so copying > the folder at the time CM3IDE is built and installed seems logical. >> >> >> >> Examples folder is strictly a set of source packages. There should be > no derived files there. When user browses to a particular example in > CM3IDE and asks to build it, CM3IDE will create a package containing the > source of the example and the derived files in the user's private > repository. That way each user gets their own private copy to muck > around with. >> >> >> >> Indeed, entire examples folder tree can be marked read-only without > any ill-effect because of the way CM3IDE works. >> >> >> >> Regards, >> >> Randy >> >>>>> Olaf Wagner 8/14/2009 12:18 PM>>> >> Quoting Randy Coleburn : >> >>> I see that someone has put some of the examples folder packages > into >>> PkgInfo.txt std group. >>> >>> None of these packages in the "examples" folder should go into > PkgInfo.txt. >>> >>> Reason is that these are examples meant to be built using CM3IDE. >>> CM3IDE will create a package folder in the user's private > repository >>> for the example and build it there locally. We don't want to build >>> and ship these as part of the std distribution. Only the sources >>> are needed. The "examples" folder and its contents need to be >>> copied to the root of your cm3 installation. That's all. >> >> I put them there, because they were not packed into the installation >> archives. They can also not be build with the usual tooling at all. >> >> What's the problem with them being included in the package list? >> >> If they are only useful for cm3ide, they should probably be part of >> that package (i.e. moved from cm3/examples to > cm3/m3-sys/cm3ide/examples). >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 > 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 >> > > CONFIDENTIALITY NOTICE: This email and any attachments are intended > solely for the use of the named recipient(s). This e-mail may contain > confidential and/or proprietary information of Scientific Research > Corporation. If you are not a named recipient, you are prohibited from > making any use of the information in the email and attachments. If you > believe you have received this email in error, please notify the sender > immediately and permanently delete the email, any attachments, and all > copies thereof from any drives or storage media and destroy any > printouts of the email or attachments. > > EXPORT COMPLIANCE NOTICE: This email and any attachments may contain > technical data subject to U.S export restrictions under the > International Traffic in Arms Regulations (ITAR) or the Export > Administration Regulations (EAR). Export or transfer of this technical > data and/or related information to any foreign person(s) or entity(ies), > either within the U.S. or outside of the U.S., may require export > authorization by the appropriate U.S. Government agency prior to export > or transfer. In addition, technical data may not be exported or > transferred to certain countries or specified designated nationals > identified by U.S. embargo controls without prior export authorization. > By accepting this email and any attachments, all recipients confirm that > they understand and will comply with all applicable ITAR, EAR and > embargo compliance requirements. > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Sat Aug 15 12:01:42 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 15 Aug 2009 12:01:42 +0200 Subject: [M3devel] CM3 web presentation Message-ID: <20090815120142.cb14l4zj4k844004@mail.elegosoft.com> I've made some further small improvments (as I think) to the structure and look of the web pages. The green colour scheme was suggested by Peter Eiserloh. It can easily be reverted or changed again in case the majority doesn't like it. As I think it's an improvement and no other suggestions have been made so far, I took the liberty to just try it, because I haven't much time to spare for these topics besides the installation package building and testing. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sat Aug 15 14:14:53 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 15 Aug 2009 12:14:53 +0000 Subject: [M3devel] CM3 web presentation In-Reply-To: <20090815120142.cb14l4zj4k844004@mail.elegosoft.com> References: <20090815120142.cb14l4zj4k844004@mail.elegosoft.com> Message-ID: Please just use white on black or black on white. The old was ugly. Maybe I'm an old curmudgeon before my time, but all this use of color seems gratuitous. Black on white or white on black would be best imho. mostly black and white: http://gcc.gnu.org/ http://www.debian.org/ almost black and white: gray text, some orange text, white background http://www.netbsd.org/ blue text, white background: http://www.redhat.com/ some black on white, some blue on white http://news.cnet.com/ sort of black on white, and some black on gray www.apple.com blue text on white background: blue is links, lots of them, but then articles are black on white www.cnn.com If you want to be unusual I would suggest white or green on black. If you want to be normal I would suggest black on white, except links end up other, I guess blue I was taught that blue is to be avoided in general, because of its longish wave length it focuses poorly. I don't know why purple wasn't indicted the same, maybe it isn't popular? Blue IS my favorite color, but I do avoid it for this very reason. My grandmother didn't like knitting in blue for this reason. I'm amazed at the frequent occurences of blue in large swaths such as Apple and KDE desktop themes. I think PowerShell gets this wrong too. Also while super high contrast can be or seem bright, introduction of colors and shades and grays tends to imho unnecessarily reduce contract. The default Windows cmd scheme is actually gray almost white text on a black background. I change it to white. red (devil/daemon theme) http://www.freebsd.org/ - Jay > Date: Sat, 15 Aug 2009 12:01:42 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] CM3 web presentation > > I've made some further small improvments (as I think) to the > structure and look of the web pages. The green colour scheme was > suggested by Peter Eiserloh. It can easily be reverted or changed > again in case the majority doesn't like it. As I think it's an > improvement and no other suggestions have been made so far, I took > the liberty to just try it, because I haven't much time to spare > for these topics besides the installation package building and testing. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sat Aug 15 15:59:45 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sat, 15 Aug 2009 09:59:45 -0400 Subject: [M3devel] CM3 web presentation In-Reply-To: References: <20090815120142.cb14l4zj4k844004@mail.elegosoft.com> Message-ID: <20090815135945.GA24494@topoi.pooq.com> On Sat, Aug 15, 2009 at 12:14:53PM +0000, Jay K wrote: > > Please just use white on black or black on white. Colour or no colour, prefer light on dark. It's much easier for migraine sufferers. -- hendrik From wagner at elegosoft.com Sat Aug 15 20:24:16 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 15 Aug 2009 20:24:16 +0200 Subject: [M3devel] CM3 web presentation In-Reply-To: References: <20090815120142.cb14l4zj4k844004@mail.elegosoft.com> Message-ID: <20090815202416.mo45s1ftkcsssgo0@mail.elegosoft.com> Well, if someone just wants black on white or vice versa for everything, that should be easy with modern browsers (just don't allow pages to use their own colours). I also don't want to spend time on this now; so a collection of other sites with better layout and design is of no help. There was one concrete suggestion which I think is a improvement, so I tried that while doing some structural changes. I can switch back if needed. Everything else is left for people with more ambition and knowledge in graphical design. To make everyone happy concerning colours, we'll probably have to offer several schemes which can be switched via the GUI. If someone can implement that quickly, I'll happily apply it, too :-) I don't know offhand how to do that with style sheets. I'll now concentrate again on the issues for the next RC. Olaf Quoting Jay K : > Please just use white on black or black on white. > > > > > > The old was ugly. > Maybe I'm an old curmudgeon before my time, but all this use of > color seems gratuitous. > > > > > Black on white or white on black would be best imho. > > > > > mostly black and white: > http://gcc.gnu.org/ > http://www.debian.org/ > > > > > almost black and white: > gray text, some orange text, white background > http://www.netbsd.org/ > > > > > blue text, white background: > http://www.redhat.com/ > > > > > some black on white, some blue on white > http://news.cnet.com/ > > > > sort of black on white, and some black on gray > www.apple.com > > > > blue text on white background: > blue is links, lots of them, but then articles are black on white > www.cnn.com > > > > If you want to be unusual I would suggest > white or green on black. > > > > If you want to be normal I would suggest > black on white, except links end up other, I guess blue > > > > > I was taught that blue is to be avoided in general, > because of its longish wave length it focuses poorly. > I don't know why purple wasn't indicted the same, maybe > it isn't popular? Blue IS my favorite color, but I do > avoid it for this very reason. > My grandmother didn't like knitting in blue for this reason. > > > > > I'm amazed at the frequent occurences of blue in > large swaths such as Apple and KDE desktop themes. > I think PowerShell gets this wrong too. > > > > > Also while super high contrast can be or seem bright, > introduction of colors and shades and grays tends to > imho unnecessarily reduce contract. > > > > > The default Windows cmd scheme is actually gray almost > white text on a black background. I change it to white. > > > > > > red (devil/daemon theme) > http://www.freebsd.org/ > > > > > - Jay > > > >> Date: Sat, 15 Aug 2009 12:01:42 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] CM3 web presentation >> >> I've made some further small improvments (as I think) to the >> structure and look of the web pages. The green colour scheme was >> suggested by Peter Eiserloh. It can easily be reverted or changed >> again in case the majority doesn't like it. As I think it's an >> improvement and no other suggestions have been made so far, I took >> the liberty to just try it, because I haven't much time to spare >> for these topics besides the installation package building and testing. >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sun Aug 16 12:06:15 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 16 Aug 2009 10:06:15 +0000 Subject: [M3devel] more crashers Message-ID: This is head on SOLgnu: I'll try another and debug and see if fix is easy. -bash-3.00$ ./m3browser *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/String16.m3 *** -bash-3.00$ ./visobliq Internal Obliq interpreter installed... Establishing 'templates' (Created frame 'templates') let Templates = {boolean=> ... , browser=> ... , button=> ... , choice=> ... , filebrowser=> ... , form=> ... , frame=> ... , hscroll=> ... , menu=> ... , numeric=> ... , text=> ... , textedit=> ... , typein=> ... , video=> ... , vscroll=> ... } Establishing 'vowidgets' (Created frame 'vowidgets') ok Establishing 'vocheckpt' (Created frame 'vocheckpt') ok Establishing 'volib' (Created frame 'volib') Segmentation Fault (core dumped) -bash-3.00$ From wagner at elegosoft.com Sun Aug 16 14:31:14 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 16 Aug 2009 14:31:14 +0200 Subject: [M3devel] hudson suggestions In-Reply-To: References: <20090816134758.cil4twz0004cwo8g@mail.elegosoft.com> Message-ID: <20090816143114.wijmtla8000gwok8@mail.elegosoft.com> I agree copy & paste and GUI administration isn't great. But as long as I'm doing most of the release engineering from a closed network without ssh access, it's the easiest way. So please let's keep it this way until the release. As I said, I'll write up generic scripts afterwards. I won't be able to change those then during the day. (Cc'ed to m3devel as others may have the same ideas) Olaf Quoting Jay K : > > I think many jobs can be ok, setup as a pipeline, as long the > tedious gui editing is minimized. > Tedious text file editing can be not so bad. > But if they are short and usually succeed and always run in the same > sequence then maybe no point. > I can't stand when things get copied around many times and it > becomes difficult to keep them in sync where they can or should be > the same. For another example some of the m3cc tasks have "clean", > some do not. > > > I don't know if Hudson allows it easily, but e.g. there should be > just one m3cc task, assigned "sticky" to all nodes except NT386 and > then either with "sticky parameters" per-node, or the task uses the > Hudson environment variables to figure stuff out. Large that's not > even needed, due to the uname sniffing, but e.g. if there were > separate SOLsun and SOLgnu nodes or tasks, the Hudson task could set > a parameter. > > > Ok the initial cvs checkout can be non-anonymous. > And right certainly it should be minimal. > Like just get one file or just the scripts directory. > Probably should should be scripts/hudson. > > > scripts/hudson/m3cc > scripts/hudson/release-build > scripts/hudson/last-ok-build > scripts/hudson/test-install > scripts/hudson/makedist > etc. > > > preferably NOT multiplied out per target. > Whenever I see "multiplication" happening I cringe. > Sure, there is some variation but usually stuff is mostly the same > and parameters or #ifdef are imho preferred over copying.. > I understand copy/paste/edit is easier. You don't always know what > all the parameters are or how to even have any. > > Ideally there is: > scripts/hudson/install > > that takes a hostname, port number, node name, maybe CM3_TARGET > value, and sets up a node from scratch. > > Currently I don't know enough to do all this and it's much easier to > sit back and suggest it than do any of it, while I lazily continue > to edit the gui tediously... > > > > - Jay > > > ---------------------------------------- >> Date: Sun, 16 Aug 2009 13:47:58 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> Subject: Re: hudson suggestions >> >> Quoting Jay K : >> >>> two suggestions: >>> >>> 1) all tasks start with: >>> >>> echo hostname >>> hostname >>> uname -a >> >> That should be no problem, but I haven't got the infrastructure set up >> to do multiple XML edits, anyway, I only have HTTP access most of the >> times. So it can just be done incrementally for now. >> >>> or more similar >>> >>> 2) all tasks >>> just do roughly but almost exactly >>> cvs something >>> run something >> >> That's basically what most tasks do. But >> >> o CVS needs to be controlled by Hudson to be able to track the changes >> o we haven't set up generic scripts yet (I'm going to do that ASAP) >> o We don't want all tasks to check out everything, because that takes >> rather long depending on the network connections (yours are the >> best) >> >>> It can actually be anonymous cvs to get the intial code. >> Anonymous CVS asks for a password even if there is none. >> As we need ssh for reporting anyway, there's no reason not to >> use it. >> >>> They would all get the same thing generally. >>> Hudson probably sets enough environment variables -- task name -- for >>> cvs+run to then decide what to do, and what architecture on >>> multiarch systems >>> to use, based on strings in the task name. >>> >>> We can/should also check more stuff up front. >>> Like availability of cc and/or gcc, bc, gnu tar, simple C link tests >>> against -lX11, etc. >>> But first transform the tasks into cvs+run only. >>> >>> I started putting in the hostname/uname -- make sure I put nodes >>> back where you >>> expect them, but it is too tedious to go through the gui. >> >> That's all I have most of the time ;-) >> >> We also need to reduce the number of jobs; I'm thinking of >> combining the builds and the package tests. >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Sun Aug 16 19:00:22 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 16 Aug 2009 13:00:22 -0400 Subject: [M3devel] more crashers In-Reply-To: References: Message-ID: <1409BB96-A7AD-4ED1-8D91-FC3F1991F528@cs.purdue.edu> OK, these are just plain weird given that they ran just fine for me fairly recently. I am very concerned that the churn with all the recent Unix header unification has left us with a much less solid system than we used to have. If we release something that is this broken then we will not win any converts. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 16 Aug 2009, at 06:06, Jay K wrote: > > This is head on SOLgnu: > I'll try another and debug and see if fix is easy. > > -bash-3.00$ ./m3browser > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/String16.m3 > *** > > -bash-3.00$ ./visobliq > Internal Obliq interpreter installed... > Establishing 'templates' > (Created frame 'templates') > let > Templates = > {boolean=> ... , > browser=> ... , > button=> ... , > choice=> ... , > filebrowser=> ... , > form=> ... , > frame=> ... , > hscroll=> ... , > menu=> ... , > numeric=> ... , > text=> ... , > textedit=> ... , > typein=> ... , > video=> ... , > vscroll=> ... } > Establishing 'vowidgets' > (Created frame 'vowidgets') > ok > Establishing 'vocheckpt' > (Created frame 'vocheckpt') > ok > Establishing 'volib' > (Created frame 'volib') > Segmentation Fault (core dumped) > -bash-3.00$ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sun Aug 16 19:10:32 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 16 Aug 2009 13:10:32 -0400 Subject: [M3devel] CM3 Release Engineering and Feedback In-Reply-To: <20090813143806.udmpiz76ecg0scgs@mail.elegosoft.com> References: <20090813143806.udmpiz76ecg0scgs@mail.elegosoft.com> Message-ID: <20090816171032.GA27461@topoi.pooq.com> On Thu, Aug 13, 2009 at 02:38:06PM +0200, Olaf Wagner wrote: > Quoting hendrik at topoi.pooq.com: > > >On Wed, Aug 12, 2009 at 01:10:38AM +0200, Olaf Wagner wrote: > >> o There hasn't been much feedback, neither from the list of active > >> developers nor from end users for RC2. I'd really appreciate some > >> more reports about installation attempts and the problems encountered. > > > >Well, I'll provide more with the next RC. The hudson directory was > >pretty much a show-stopper. I'd expect the same problem to be there on > >the other platforms. > > The simple work-around would be to call cm3 -build on the packages > again, which should only adapt the broken .M3SHIP files. I tried that , but it failed, complaining hendrik at notlookedfor:~/cm3/RC2/gui/m3-ui$ cd cmvbt hendrik at notlookedfor:~/cm3/RC2/gui/m3-ui/cmvbt$ cm3 -build --- building in LINUXLIBC6 --- ignoring ../src/m3overrides "/home/hendrik/cm3/RC2/gui/m3-ui/cmvbt/src/m3makefile", line 3: quake runtime error: unable to open "/usr/local/cm3/pkg/ui/LINUXLIBC6/.M3EXPORTS" for reading --procedure-- -line- -file--- import -- include_dir 3 /home/hendrik/cm3/RC2/gui/m3-ui/cmvbt/src/m3makefile 4 /home/hendrik/cm3/RC2/gui/m3-ui/cmvbt/LINUXLIBC6/m3make.args Fatal Error: package build failed hendrik at notlookedfor:~/cm3/RC2/gui/m3-ui/cmvbt$ I guess I'll wait for RC3 to do further testing. Unless, of course, I've used cm3 -build wrong. In which case the workaround mentinoed on http://www.opencm3.net/releng/known-problems.html needs to be more explicit. In any case, this will be an obsolete by the time RC3 starts to roll out. So focus on that rather than fixing the workaround. -- hendrik From jay.krell at cornell.edu Sun Aug 16 21:21:14 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 16 Aug 2009 19:21:14 +0000 Subject: [M3devel] more crashers Message-ID: I see the assertion failure on PPC_LINUX too. I tried VAR defaultStackSize := 1024 * 1024; (not sure why there was any suspicion of stack size). Debugging doesn't work PPC_LINUX. jay at plin:/cm3/bin$ gdb ./cm3 GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "powerpc-linux-gnu"... break ma(gdb) break main Breakpoint 1 at 0x86fc4: file _m3main.mc, line 2. (gdb) r Starting program: /home/jay/cm3/bin/cm3 Warning: Cannot insert breakpoint 1. Error accessing memory address 0x86fc4: Input/output error. No problem with C: jay at plin:/cm3/bin$ echo "main(){}"> 1.c jay at plin:/cm3/bin$ gcc -g 1.c jay at plin:/cm3/bin$ gdb ./a.out GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "powerpc-linux-gnu"... (gdb) break main Breakpoint 1 at 0x10000448: file 1.c, line 1. (gdb) r Starting program: /home/jay/cm3/bin/a.out Breakpoint 1, main () at 1.c:1 1 main(){} (gdb) jay at plin:/cm3/bin$ gcc -gstabs+ 1.c jay at plin:/cm3/bin$ gdb ./a.out GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "powerpc-linux-gnu"... (gdb) break main Breakpoint 1 at 0x10000448: file 1.c, line 1. (gdb) r Starting program: /home/jay/cm3/bin/a.out Breakpoint 1, main () at 1.c:1 1 main(){} jay at plin:/cm3/bin$ gcc -gstabs 1.c jay at plin:/cm3/bin$ gdb ./a.out GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "powerpc-linux-gnu"... (gdb) break main Breakpoint 1 at 0x10000448: file 1.c, line 1. (gdb) r Starting program: /home/jay/cm3/bin/a.out Breakpoint 1, main () at 1.c:1 1 main(){} (gdb) - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: more crashers > Date: Sun, 16 Aug 2009 10:06:15 +0000 > > > This is head on SOLgnu: > I'll try another and debug and see if fix is easy. > > -bash-3.00$ ./m3browser > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/String16.m3 > *** > > -bash-3.00$ ./visobliq > Internal Obliq interpreter installed... > Establishing 'templates' > (Created frame 'templates') > let > Templates = > {boolean=> ... , > browser=> ... , > button=> ... , > choice=> ... , > filebrowser=> ... , > form=> ... , > frame=> ... , > hscroll=> ... , > menu=> ... , > numeric=> ... , > text=> ... , > textedit=> ... , > typein=> ... , > video=> ... , > vscroll=> ... } > Establishing 'vowidgets' > (Created frame 'vowidgets') > ok > Establishing 'vocheckpt' > (Created frame 'vocheckpt') > ok > Establishing 'volib' > (Created frame 'volib') > Segmentation Fault (core dumped) > -bash-3.00$ > From hosking at cs.purdue.edu Sun Aug 16 21:26:49 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 16 Aug 2009 15:26:49 -0400 Subject: [M3devel] more crashers In-Reply-To: References: Message-ID: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> Could this be endianness-related? On 16 Aug 2009, at 15:21, Jay K wrote: > > I see the assertion failure on PPC_LINUX too. > I tried VAR defaultStackSize := 1024 * 1024; (not sure why there was > any suspicion of stack size). > > > Debugging doesn't work PPC_LINUX. > > > jay at plin:/cm3/bin$ gdb ./cm3 > GNU gdb 6.8-debian > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show > copying" > and "show warranty" for details. > This GDB was configured as "powerpc-linux-gnu"... > break ma(gdb) break main > Breakpoint 1 at 0x86fc4: file _m3main.mc, line 2. > (gdb) r > Starting program: /home/jay/cm3/bin/cm3 > Warning: > Cannot insert breakpoint 1. > Error accessing memory address 0x86fc4: Input/output error. > > > No problem with C: > > > jay at plin:/cm3/bin$ echo "main(){}"> 1.c > jay at plin:/cm3/bin$ gcc -g 1.c > jay at plin:/cm3/bin$ gdb ./a.out > GNU gdb 6.8-debian > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show > copying" > and "show warranty" for details. > This GDB was configured as "powerpc-linux-gnu"... > (gdb) break main > Breakpoint 1 at 0x10000448: file 1.c, line 1. > (gdb) r > Starting program: /home/jay/cm3/bin/a.out > Breakpoint 1, main () at 1.c:1 > 1 main(){} > (gdb) > > > jay at plin:/cm3/bin$ gcc -gstabs+ 1.c > jay at plin:/cm3/bin$ gdb ./a.out > GNU gdb 6.8-debian > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show > copying" > and "show warranty" for details. > This GDB was configured as "powerpc-linux-gnu"... > (gdb) break main > Breakpoint 1 at 0x10000448: file 1.c, line 1. > (gdb) r > Starting program: /home/jay/cm3/bin/a.out > Breakpoint 1, main () at 1.c:1 > 1 main(){} > > > jay at plin:/cm3/bin$ gcc -gstabs 1.c > jay at plin:/cm3/bin$ gdb ./a.out > GNU gdb 6.8-debian > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show > copying" > and "show warranty" for details. > This GDB was configured as "powerpc-linux-gnu"... > (gdb) break main > Breakpoint 1 at 0x10000448: file 1.c, line 1. > (gdb) r > Starting program: /home/jay/cm3/bin/a.out > Breakpoint 1, main () at 1.c:1 > 1 main(){} > (gdb) > > > - Jay > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Subject: more crashers >> Date: Sun, 16 Aug 2009 10:06:15 +0000 >> >> >> This is head on SOLgnu: >> I'll try another and debug and see if fix is easy. >> >> -bash-3.00$ ./m3browser >> >> *** >> *** runtime error: >> *** Segmentation violation - possible attempt to dereference NIL >> *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/String16.m3 >> *** >> >> -bash-3.00$ ./visobliq >> Internal Obliq interpreter installed... >> Establishing 'templates' >> (Created frame 'templates') >> let >> Templates = >> {boolean=> ... , >> browser=> ... , >> button=> ... , >> choice=> ... , >> filebrowser=> ... , >> form=> ... , >> frame=> ... , >> hscroll=> ... , >> menu=> ... , >> numeric=> ... , >> text=> ... , >> textedit=> ... , >> typein=> ... , >> video=> ... , >> vscroll=> ... } >> Establishing 'vowidgets' >> (Created frame 'vowidgets') >> ok >> Establishing 'vocheckpt' >> (Created frame 'vocheckpt') >> ok >> Establishing 'volib' >> (Created frame 'volib') >> Segmentation Fault (core dumped) >> -bash-3.00$ >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Aug 16 21:27:03 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 16 Aug 2009 19:27:03 +0000 Subject: [M3devel] Errors building Juno on PPC_LINUX (Debian 5) Message-ID: Errors building Juno on PPC_LINUX (Debian 5) == package /home/jay/dev2/cm3/m3-ui/juno-2/juno-app == +++ /cm3/bin/cm3 -build -DROOT=/home/jay/dev2/cm3 -DCM3_VERSION_TEXT=d5.8.2 -D CM3_VERSION_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ --- building in PPC_LINUX --- ... new source -> compiling Editor.m3 ../src/Editor.m3: In function 'Editor__Parse2': ../src/Editor.m3:248: fatal error: *** bad opcode: 0x229, at m3cg_lineno 18629 compilation terminated. m3_backend => 1 m3cc (aka cm3cg) failed compiling: Editor.mc new opaque info -> recompiling Drag.m3 Drag.ms: Assembler messages: Drag.ms:3949: Error: unknown pseudo-op: `.s' assemble => 1 assembler failed assembling: Drag.ms *** execution of [, ] failed *** jay at plin:/dev2/cm3/scripts/python$ More details to follow. I'm going to rebuild m3cc clean, make sure it was built native not copied from another machine, but I think it already was native. - Jay From jay.krell at cornell.edu Sun Aug 16 21:33:34 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 16 Aug 2009 19:33:34 +0000 Subject: [M3devel] more crashers In-Reply-To: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> References: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> Message-ID: Could be. I've also seen it on PPC_DARWIN a while ago. I only recall seeing it on sparc and ppc. It doesn't always occur. Here is the m3browser crash on a system that can be debugged. See why I want the full paths in the debug info? C:\Users\jay\Desktop>\cygwin\bin\ssh xobsd. $ cd /cm3 $ cd bin $ export DISPLAY=192.168.1.120:0.0 $ gdb ./m3browser GNU gdb 6.3 This GDB was configured as "i386-unknown-openbsd4.5"... (gdb) r Starting program: /home/jay/cm3/bin/m3browser Program received signal SIGSEGV, Segmentation fault. [Switching to process 31063, thread 0x7eafe800] 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 16 t.get_info (i); (gdb) bt #0 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 #1 0x09fd9464 in ID__Add (M3_Bd56fi_x=0x0) at ../src/ID.m3:48 #2 0x1c01e644 in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:37 #3 0x0156f1bc in RTLinker__RunMainBody (M3_DjPxE3_m=0x3c003ec0) at ../src/runtime/common/RTLinker.m3:399 #4 0x0156e576 in RTLinker__AddUnitI (M3_DjPxE3_m=0x3c003ec0) at ../src/runtime/common/RTLinker.m3:113 #5 0x0156e604 in RTLinker__AddUnit (M3_DjPxE5_b=0x1c01e54d) at ../src/runtime/common/RTLinker.m3:122 #6 0x1c004676 in main (argc=1, argv=0xcfbf6a3c, envp=0xcfbf6a44) at _m3main.mc:4 - Jay ________________________________ > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Sun, 16 Aug 2009 15:26:49 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] more crashers > > Could this be endianness-related? > > On 16 Aug 2009, at 15:21, Jay K wrote: > > > I see the assertion failure on PPC_LINUX too. > I tried VAR defaultStackSize := 1024 * 1024; (not sure why there was any suspicion of stack size). > > > Debugging doesn't work PPC_LINUX. > > > jay at plin:/cm3/bin$ gdb ./cm3 > GNU gdb 6.8-debian > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "powerpc-linux-gnu"... > break ma(gdb) break main > Breakpoint 1 at 0x86fc4: file _m3main.mc, line 2. > (gdb) r > Starting program: /home/jay/cm3/bin/cm3 > Warning: > Cannot insert breakpoint 1. > Error accessing memory address 0x86fc4: Input/output error. > > > No problem with C: > > > jay at plin:/cm3/bin$ echo "main(){}"> 1.c > jay at plin:/cm3/bin$ gcc -g 1.c > jay at plin:/cm3/bin$ gdb ./a.out > GNU gdb 6.8-debian > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "powerpc-linux-gnu"... > (gdb) break main > Breakpoint 1 at 0x10000448: file 1.c, line 1. > (gdb) r > Starting program: /home/jay/cm3/bin/a.out > Breakpoint 1, main () at 1.c:1 > 1 main(){} > (gdb) > > > jay at plin:/cm3/bin$ gcc -gstabs+ 1.c > jay at plin:/cm3/bin$ gdb ./a.out > GNU gdb 6.8-debian > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "powerpc-linux-gnu"... > (gdb) break main > Breakpoint 1 at 0x10000448: file 1.c, line 1. > (gdb) r > Starting program: /home/jay/cm3/bin/a.out > Breakpoint 1, main () at 1.c:1 > 1 main(){} > > > jay at plin:/cm3/bin$ gcc -gstabs 1.c > jay at plin:/cm3/bin$ gdb ./a.out > GNU gdb 6.8-debian > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "powerpc-linux-gnu"... > (gdb) break main > Breakpoint 1 at 0x10000448: file 1.c, line 1. > (gdb) r > Starting program: /home/jay/cm3/bin/a.out > Breakpoint 1, main () at 1.c:1 > 1 main(){} > (gdb) > > > - Jay > > > ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: more crashers > Date: Sun, 16 Aug 2009 10:06:15 +0000 > > > This is head on SOLgnu: > I'll try another and debug and see if fix is easy. > > -bash-3.00$ ./m3browser > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/String16.m3 > *** > > -bash-3.00$ ./visobliq > Internal Obliq interpreter installed... > Establishing 'templates' > (Created frame 'templates') > let > Templates = > {boolean=> ... , > browser=> ... , > button=> ... , > choice=> ... , > filebrowser=> ... , > form=> ... , > frame=> ... , > hscroll=> ... , > menu=> ... , > numeric=> ... , > text=> ... , > textedit=> ... , > typein=> ... , > video=> ... , > vscroll=> ... } > Establishing 'vowidgets' > (Created frame 'vowidgets') > ok > Establishing 'vocheckpt' > (Created frame 'vocheckpt') > ok > Establishing 'volib' > (Created frame 'volib') > Segmentation Fault (core dumped) > -bash-3.00$ > > From jay.krell at cornell.edu Sun Aug 16 21:52:03 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 16 Aug 2009 19:52:03 +0000 Subject: [M3devel] more crashers In-Reply-To: References: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> Message-ID: Here is the relevant code in m3browser ID.m3: C:\dev2\cm3.2\m3-tools\m3markup\src\ID.m3(38): empty_id := Add (""); empty_id := Add (""); (*-------------------------------------------------------------- exported ---*) PROCEDURE Add (x: TEXT): T = VAR t: T; a: REF ARRAY OF CHAR; l: INTEGER; BEGIN l := Text.Length(x); ... END Add; The empty string constant ends up as null. .stabn 68,0,38,.LM115-.LFBB10 .LM115: movl L_1 at GOT(%ebx), %eax leal 24(%eax), %eax movl %eax, (%esp) call ID__Add at PLT movl %eax, -8(%ebp) movl -8(%ebp), %ecx movl MM_ID at GOT(%ebx), %edx movl 248(%edx), %eax andl $0, %eax orl %ecx, %eax movl %eax, 248(%edx) .L136: movl MM_ID at GOT(%ebx), %eax .LBE16: addl $52, %esp popl %ebx popl %ebp ret L_1: 0 .long RTHooks__TextLitInfo 4 .long RTHooks__TextLitGetChar 8 .long RTHooks__TextLitGetWideChar 12 .long RTHooks__TextLitGetChars 16 .long RTHooks__TextLitGetWideChars 20 .long 2 24 .long L_1 .long 0 .zero 4 .ascii "ID_M3" .zero 1 .ascii "ExpandHashTable" .zero 1 .ascii "ExpandIDs" .zero 1 .ascii "ExpandChars" .zero 1 .ascii "Compare" .zero 1 If I change "" to "foo", I get: L_1: 0 .long RTHooks__TextLitInfo 4 .long RTHooks__TextLitGetChar 8 .long RTHooks__TextLitGetWideChar 12 .long RTHooks__TextLitGetChars 16 .long RTHooks__TextLitGetWideChars 20 .long 2 24 .long L_1 .long 3 .ascii "foo" .zero 1 .ascii "ID_M3" and it still crashes. It seems to hit ID__Add twice when only once would be expected. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Sun, 16 Aug 2009 19:33:34 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] more crashers > > > Could be. I've also seen it on PPC_DARWIN a while ago. I only recall seeing it on sparc and ppc. > It doesn't always occur. > > > Here is the m3browser crash on a system that can be debugged. > See why I want the full paths in the debug info? > > > C:\Users\jay\Desktop>\cygwin\bin\ssh xobsd. > $ cd /cm3 > $ cd bin > $ export DISPLAY=192.168.1.120:0.0 > $ gdb ./m3browser > GNU gdb 6.3 > This GDB was configured as "i386-unknown-openbsd4.5"... > (gdb) r > Starting program: /home/jay/cm3/bin/m3browser > Program received signal SIGSEGV, Segmentation fault. > [Switching to process 31063, thread 0x7eafe800] > 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 > 16 t.get_info (i); > (gdb) bt > #0 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 > #1 0x09fd9464 in ID__Add (M3_Bd56fi_x=0x0) at ../src/ID.m3:48 > #2 0x1c01e644 in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:37 > #3 0x0156f1bc in RTLinker__RunMainBody (M3_DjPxE3_m=0x3c003ec0) > at ../src/runtime/common/RTLinker.m3:399 > #4 0x0156e576 in RTLinker__AddUnitI (M3_DjPxE3_m=0x3c003ec0) > at ../src/runtime/common/RTLinker.m3:113 > #5 0x0156e604 in RTLinker__AddUnit (M3_DjPxE5_b=0x1c01e54d) > at ../src/runtime/common/RTLinker.m3:122 > #6 0x1c004676 in main (argc=1, argv=0xcfbf6a3c, envp=0xcfbf6a44) > at _m3main.mc:4 > > > - Jay > > > ________________________________ >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Sun, 16 Aug 2009 15:26:49 -0400 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] more crashers >> >> Could this be endianness-related? >> >> On 16 Aug 2009, at 15:21, Jay K wrote: >> >> >> I see the assertion failure on PPC_LINUX too. >> I tried VAR defaultStackSize := 1024 * 1024; (not sure why there was any suspicion of stack size). >> >> >> Debugging doesn't work PPC_LINUX. >> >> >> jay at plin:/cm3/bin$ gdb ./cm3 >> GNU gdb 6.8-debian >> Copyright (C) 2008 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >> and "show warranty" for details. >> This GDB was configured as "powerpc-linux-gnu"... >> break ma(gdb) break main >> Breakpoint 1 at 0x86fc4: file _m3main.mc, line 2. >> (gdb) r >> Starting program: /home/jay/cm3/bin/cm3 >> Warning: >> Cannot insert breakpoint 1. >> Error accessing memory address 0x86fc4: Input/output error. >> >> >> No problem with C: >> >> >> jay at plin:/cm3/bin$ echo "main(){}"> 1.c >> jay at plin:/cm3/bin$ gcc -g 1.c >> jay at plin:/cm3/bin$ gdb ./a.out >> GNU gdb 6.8-debian >> Copyright (C) 2008 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >> and "show warranty" for details. >> This GDB was configured as "powerpc-linux-gnu"... >> (gdb) break main >> Breakpoint 1 at 0x10000448: file 1.c, line 1. >> (gdb) r >> Starting program: /home/jay/cm3/bin/a.out >> Breakpoint 1, main () at 1.c:1 >> 1 main(){} >> (gdb) >> >> >> jay at plin:/cm3/bin$ gcc -gstabs+ 1.c >> jay at plin:/cm3/bin$ gdb ./a.out >> GNU gdb 6.8-debian >> Copyright (C) 2008 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >> and "show warranty" for details. >> This GDB was configured as "powerpc-linux-gnu"... >> (gdb) break main >> Breakpoint 1 at 0x10000448: file 1.c, line 1. >> (gdb) r >> Starting program: /home/jay/cm3/bin/a.out >> Breakpoint 1, main () at 1.c:1 >> 1 main(){} >> >> >> jay at plin:/cm3/bin$ gcc -gstabs 1.c >> jay at plin:/cm3/bin$ gdb ./a.out >> GNU gdb 6.8-debian >> Copyright (C) 2008 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >> and "show warranty" for details. >> This GDB was configured as "powerpc-linux-gnu"... >> (gdb) break main >> Breakpoint 1 at 0x10000448: file 1.c, line 1. >> (gdb) r >> Starting program: /home/jay/cm3/bin/a.out >> Breakpoint 1, main () at 1.c:1 >> 1 main(){} >> (gdb) >> >> >> - Jay >> >> >> ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Subject: more crashers >> Date: Sun, 16 Aug 2009 10:06:15 +0000 >> >> >> This is head on SOLgnu: >> I'll try another and debug and see if fix is easy. >> >> -bash-3.00$ ./m3browser >> >> *** >> *** runtime error: >> *** Segmentation violation - possible attempt to dereference NIL >> *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/String16.m3 >> *** >> >> -bash-3.00$ ./visobliq >> Internal Obliq interpreter installed... >> Establishing 'templates' >> (Created frame 'templates') >> let >> Templates = >> {boolean=> ... , >> browser=> ... , >> button=> ... , >> choice=> ... , >> filebrowser=> ... , >> form=> ... , >> frame=> ... , >> hscroll=> ... , >> menu=> ... , >> numeric=> ... , >> text=> ... , >> textedit=> ... , >> typein=> ... , >> video=> ... , >> vscroll=> ... } >> Establishing 'vowidgets' >> (Created frame 'vowidgets') >> ok >> Establishing 'vocheckpt' >> (Created frame 'vocheckpt') >> ok >> Establishing 'volib' >> (Created frame 'volib') >> Segmentation Fault (core dumped) >> -bash-3.00$ >> >> From jay.krell at cornell.edu Sun Aug 16 22:22:49 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 16 Aug 2009 20:22:49 +0000 Subject: [M3devel] more crashers In-Reply-To: References: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> Message-ID: sorry, this is simple. derived_dirs := IntList.List1 (ID.Add (MxConfig.Get("BUILD_DIR"))); - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Sun, 16 Aug 2009 19:52:03 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] more crashers > > > Here is the relevant code in m3browser ID.m3: > > > C:\dev2\cm3.2\m3-tools\m3markup\src\ID.m3(38): empty_id := Add (""); > > empty_id := Add (""); > > (*-------------------------------------------------------------- exported ---*) > PROCEDURE Add (x: TEXT): T = > VAR > t: T; > a: REF ARRAY OF CHAR; > l: INTEGER; > BEGIN > l := Text.Length(x); > ... > END Add; > > > The empty string constant ends up as null. > > .stabn 68,0,38,.LM115-.LFBB10 > .LM115: > movl L_1 at GOT(%ebx), %eax > leal 24(%eax), %eax > movl %eax, (%esp) > call ID__Add at PLT > movl %eax, -8(%ebp) > movl -8(%ebp), %ecx > movl MM_ID at GOT(%ebx), %edx > movl 248(%edx), %eax > andl $0, %eax > orl %ecx, %eax > movl %eax, 248(%edx) > .L136: > movl MM_ID at GOT(%ebx), %eax > .LBE16: > addl $52, %esp > popl %ebx > popl %ebp > ret > > L_1: > 0 .long RTHooks__TextLitInfo > 4 .long RTHooks__TextLitGetChar > 8 .long RTHooks__TextLitGetWideChar > 12 .long RTHooks__TextLitGetChars > 16 .long RTHooks__TextLitGetWideChars > 20 .long 2 > 24 .long L_1 > .long 0 > .zero 4 > .ascii "ID_M3" > .zero 1 > .ascii "ExpandHashTable" > .zero 1 > .ascii "ExpandIDs" > .zero 1 > .ascii "ExpandChars" > .zero 1 > .ascii "Compare" > .zero 1 > > If I change "" to "foo", I get: > > L_1: > 0 .long RTHooks__TextLitInfo > 4 .long RTHooks__TextLitGetChar > 8 .long RTHooks__TextLitGetWideChar > 12 .long RTHooks__TextLitGetChars > 16 .long RTHooks__TextLitGetWideChars > 20 .long 2 > 24 .long L_1 > .long 3 > .ascii "foo" > .zero 1 > .ascii "ID_M3" > > and it still crashes. > > > It seems to hit ID__Add twice when only once would be expected. > > > - Jay > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> Date: Sun, 16 Aug 2009 19:33:34 +0000 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] more crashers >> >> >> Could be. I've also seen it on PPC_DARWIN a while ago. I only recall seeing it on sparc and ppc. >> It doesn't always occur. >> >> >> Here is the m3browser crash on a system that can be debugged. >> See why I want the full paths in the debug info? >> >> >> C:\Users\jay\Desktop>\cygwin\bin\ssh xobsd. >> $ cd /cm3 >> $ cd bin >> $ export DISPLAY=192.168.1.120:0.0 >> $ gdb ./m3browser >> GNU gdb 6.3 >> This GDB was configured as "i386-unknown-openbsd4.5"... >> (gdb) r >> Starting program: /home/jay/cm3/bin/m3browser >> Program received signal SIGSEGV, Segmentation fault. >> [Switching to process 31063, thread 0x7eafe800] >> 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 >> 16 t.get_info (i); >> (gdb) bt >> #0 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 >> #1 0x09fd9464 in ID__Add (M3_Bd56fi_x=0x0) at ../src/ID.m3:48 >> #2 0x1c01e644 in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:37 >> #3 0x0156f1bc in RTLinker__RunMainBody (M3_DjPxE3_m=0x3c003ec0) >> at ../src/runtime/common/RTLinker.m3:399 >> #4 0x0156e576 in RTLinker__AddUnitI (M3_DjPxE3_m=0x3c003ec0) >> at ../src/runtime/common/RTLinker.m3:113 >> #5 0x0156e604 in RTLinker__AddUnit (M3_DjPxE5_b=0x1c01e54d) >> at ../src/runtime/common/RTLinker.m3:122 >> #6 0x1c004676 in main (argc=1, argv=0xcfbf6a3c, envp=0xcfbf6a44) >> at _m3main.mc:4 >> >> >> - Jay >> >> >> ________________________________ >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Date: Sun, 16 Aug 2009 15:26:49 -0400 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] more crashers >>> >>> Could this be endianness-related? >>> >>> On 16 Aug 2009, at 15:21, Jay K wrote: >>> >>> >>> I see the assertion failure on PPC_LINUX too. >>> I tried VAR defaultStackSize := 1024 * 1024; (not sure why there was any suspicion of stack size). >>> >>> >>> Debugging doesn't work PPC_LINUX. >>> >>> >>> jay at plin:/cm3/bin$ gdb ./cm3 >>> GNU gdb 6.8-debian >>> Copyright (C) 2008 Free Software Foundation, Inc. >>> License GPLv3+: GNU GPL version 3 or later >>> This is free software: you are free to change and redistribute it. >>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >>> and "show warranty" for details. >>> This GDB was configured as "powerpc-linux-gnu"... >>> break ma(gdb) break main >>> Breakpoint 1 at 0x86fc4: file _m3main.mc, line 2. >>> (gdb) r >>> Starting program: /home/jay/cm3/bin/cm3 >>> Warning: >>> Cannot insert breakpoint 1. >>> Error accessing memory address 0x86fc4: Input/output error. >>> >>> >>> No problem with C: >>> >>> >>> jay at plin:/cm3/bin$ echo "main(){}"> 1.c >>> jay at plin:/cm3/bin$ gcc -g 1.c >>> jay at plin:/cm3/bin$ gdb ./a.out >>> GNU gdb 6.8-debian >>> Copyright (C) 2008 Free Software Foundation, Inc. >>> License GPLv3+: GNU GPL version 3 or later >>> This is free software: you are free to change and redistribute it. >>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >>> and "show warranty" for details. >>> This GDB was configured as "powerpc-linux-gnu"... >>> (gdb) break main >>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>> (gdb) r >>> Starting program: /home/jay/cm3/bin/a.out >>> Breakpoint 1, main () at 1.c:1 >>> 1 main(){} >>> (gdb) >>> >>> >>> jay at plin:/cm3/bin$ gcc -gstabs+ 1.c >>> jay at plin:/cm3/bin$ gdb ./a.out >>> GNU gdb 6.8-debian >>> Copyright (C) 2008 Free Software Foundation, Inc. >>> License GPLv3+: GNU GPL version 3 or later >>> This is free software: you are free to change and redistribute it. >>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >>> and "show warranty" for details. >>> This GDB was configured as "powerpc-linux-gnu"... >>> (gdb) break main >>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>> (gdb) r >>> Starting program: /home/jay/cm3/bin/a.out >>> Breakpoint 1, main () at 1.c:1 >>> 1 main(){} >>> >>> >>> jay at plin:/cm3/bin$ gcc -gstabs 1.c >>> jay at plin:/cm3/bin$ gdb ./a.out >>> GNU gdb 6.8-debian >>> Copyright (C) 2008 Free Software Foundation, Inc. >>> License GPLv3+: GNU GPL version 3 or later >>> This is free software: you are free to change and redistribute it. >>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >>> and "show warranty" for details. >>> This GDB was configured as "powerpc-linux-gnu"... >>> (gdb) break main >>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>> (gdb) r >>> Starting program: /home/jay/cm3/bin/a.out >>> Breakpoint 1, main () at 1.c:1 >>> 1 main(){} >>> (gdb) >>> >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: m3devel at elegosoft.com >>> Subject: more crashers >>> Date: Sun, 16 Aug 2009 10:06:15 +0000 >>> >>> >>> This is head on SOLgnu: >>> I'll try another and debug and see if fix is easy. >>> >>> -bash-3.00$ ./m3browser >>> >>> *** >>> *** runtime error: >>> *** Segmentation violation - possible attempt to dereference NIL >>> *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/String16.m3 >>> *** >>> >>> -bash-3.00$ ./visobliq >>> Internal Obliq interpreter installed... >>> Establishing 'templates' >>> (Created frame 'templates') >>> let >>> Templates = >>> {boolean=> ... , >>> browser=> ... , >>> button=> ... , >>> choice=> ... , >>> filebrowser=> ... , >>> form=> ... , >>> frame=> ... , >>> hscroll=> ... , >>> menu=> ... , >>> numeric=> ... , >>> text=> ... , >>> textedit=> ... , >>> typein=> ... , >>> video=> ... , >>> vscroll=> ... } >>> Establishing 'vowidgets' >>> (Created frame 'vowidgets') >>> ok >>> Establishing 'vocheckpt' >>> (Created frame 'vocheckpt') >>> ok >>> Establishing 'volib' >>> (Created frame 'volib') >>> Segmentation Fault (core dumped) >>> -bash-3.00$ >>> >>> From jay.krell at cornell.edu Sun Aug 16 22:32:31 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 16 Aug 2009 20:32:31 +0000 Subject: [M3devel] more crashers In-Reply-To: References: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> Message-ID: m3browser: It is specific to my config file m3-sys/cminstall/src/config-no-install/cm3.cfg that reachs back into the source tree. It won't happen with what most people do. I have to do that M3Predefines or such work so that all the uses of m3quake besides cm3 are much more like cm3. visobliq: not the same thing Does not occur on Linux/x86 or Linux/sparc. They do print Syntax error just before: -helvetica-bold-\*R-\*240-\*\") (LabelFo ... ill-formed character escape sequence Error detected (file file generated by Visual Obliq) (line 18, char 10) VideoVBT.Start Jv ServerFailure:errno=0 but then gui comes up. I'll have to finish my Solaris reinstall and get dbx. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Sun, 16 Aug 2009 20:22:49 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] more crashers > > > sorry, this is simple. > > derived_dirs := IntList.List1 (ID.Add (MxConfig.Get("BUILD_DIR"))); > > > - Jay > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> Date: Sun, 16 Aug 2009 19:52:03 +0000 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] more crashers >> >> >> Here is the relevant code in m3browser ID.m3: >> >> >> C:\dev2\cm3.2\m3-tools\m3markup\src\ID.m3(38): empty_id := Add (""); >> >> empty_id := Add (""); >> >> (*-------------------------------------------------------------- exported ---*) >> PROCEDURE Add (x: TEXT): T = >> VAR >> t: T; >> a: REF ARRAY OF CHAR; >> l: INTEGER; >> BEGIN >> l := Text.Length(x); >> ... >> END Add; >> >> >> The empty string constant ends up as null. >> >> .stabn 68,0,38,.LM115-.LFBB10 >> .LM115: >> movl L_1 at GOT(%ebx), %eax >> leal 24(%eax), %eax >> movl %eax, (%esp) >> call ID__Add at PLT >> movl %eax, -8(%ebp) >> movl -8(%ebp), %ecx >> movl MM_ID at GOT(%ebx), %edx >> movl 248(%edx), %eax >> andl $0, %eax >> orl %ecx, %eax >> movl %eax, 248(%edx) >> .L136: >> movl MM_ID at GOT(%ebx), %eax >> .LBE16: >> addl $52, %esp >> popl %ebx >> popl %ebp >> ret >> >> L_1: >> 0 .long RTHooks__TextLitInfo >> 4 .long RTHooks__TextLitGetChar >> 8 .long RTHooks__TextLitGetWideChar >> 12 .long RTHooks__TextLitGetChars >> 16 .long RTHooks__TextLitGetWideChars >> 20 .long 2 >> 24 .long L_1 >> .long 0 >> .zero 4 >> .ascii "ID_M3" >> .zero 1 >> .ascii "ExpandHashTable" >> .zero 1 >> .ascii "ExpandIDs" >> .zero 1 >> .ascii "ExpandChars" >> .zero 1 >> .ascii "Compare" >> .zero 1 >> >> If I change "" to "foo", I get: >> >> L_1: >> 0 .long RTHooks__TextLitInfo >> 4 .long RTHooks__TextLitGetChar >> 8 .long RTHooks__TextLitGetWideChar >> 12 .long RTHooks__TextLitGetChars >> 16 .long RTHooks__TextLitGetWideChars >> 20 .long 2 >> 24 .long L_1 >> .long 3 >> .ascii "foo" >> .zero 1 >> .ascii "ID_M3" >> >> and it still crashes. >> >> >> It seems to hit ID__Add twice when only once would be expected. >> >> >> - Jay >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu >>> Date: Sun, 16 Aug 2009 19:33:34 +0000 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] more crashers >>> >>> >>> Could be. I've also seen it on PPC_DARWIN a while ago. I only recall seeing it on sparc and ppc. >>> It doesn't always occur. >>> >>> >>> Here is the m3browser crash on a system that can be debugged. >>> See why I want the full paths in the debug info? >>> >>> >>> C:\Users\jay\Desktop>\cygwin\bin\ssh xobsd. >>> $ cd /cm3 >>> $ cd bin >>> $ export DISPLAY=192.168.1.120:0.0 >>> $ gdb ./m3browser >>> GNU gdb 6.3 >>> This GDB was configured as "i386-unknown-openbsd4.5"... >>> (gdb) r >>> Starting program: /home/jay/cm3/bin/m3browser >>> Program received signal SIGSEGV, Segmentation fault. >>> [Switching to process 31063, thread 0x7eafe800] >>> 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 >>> 16 t.get_info (i); >>> (gdb) bt >>> #0 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 >>> #1 0x09fd9464 in ID__Add (M3_Bd56fi_x=0x0) at ../src/ID.m3:48 >>> #2 0x1c01e644 in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:37 >>> #3 0x0156f1bc in RTLinker__RunMainBody (M3_DjPxE3_m=0x3c003ec0) >>> at ../src/runtime/common/RTLinker.m3:399 >>> #4 0x0156e576 in RTLinker__AddUnitI (M3_DjPxE3_m=0x3c003ec0) >>> at ../src/runtime/common/RTLinker.m3:113 >>> #5 0x0156e604 in RTLinker__AddUnit (M3_DjPxE5_b=0x1c01e54d) >>> at ../src/runtime/common/RTLinker.m3:122 >>> #6 0x1c004676 in main (argc=1, argv=0xcfbf6a3c, envp=0xcfbf6a44) >>> at _m3main.mc:4 >>> >>> >>> - Jay >>> >>> >>> ________________________________ >>>> From: hosking at cs.purdue.edu >>>> To: jay.krell at cornell.edu >>>> Date: Sun, 16 Aug 2009 15:26:49 -0400 >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] more crashers >>>> >>>> Could this be endianness-related? >>>> >>>> On 16 Aug 2009, at 15:21, Jay K wrote: >>>> >>>> >>>> I see the assertion failure on PPC_LINUX too. >>>> I tried VAR defaultStackSize := 1024 * 1024; (not sure why there was any suspicion of stack size). >>>> >>>> >>>> Debugging doesn't work PPC_LINUX. >>>> >>>> >>>> jay at plin:/cm3/bin$ gdb ./cm3 >>>> GNU gdb 6.8-debian >>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>> License GPLv3+: GNU GPL version 3 or later >>>> This is free software: you are free to change and redistribute it. >>>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >>>> and "show warranty" for details. >>>> This GDB was configured as "powerpc-linux-gnu"... >>>> break ma(gdb) break main >>>> Breakpoint 1 at 0x86fc4: file _m3main.mc, line 2. >>>> (gdb) r >>>> Starting program: /home/jay/cm3/bin/cm3 >>>> Warning: >>>> Cannot insert breakpoint 1. >>>> Error accessing memory address 0x86fc4: Input/output error. >>>> >>>> >>>> No problem with C: >>>> >>>> >>>> jay at plin:/cm3/bin$ echo "main(){}"> 1.c >>>> jay at plin:/cm3/bin$ gcc -g 1.c >>>> jay at plin:/cm3/bin$ gdb ./a.out >>>> GNU gdb 6.8-debian >>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>> License GPLv3+: GNU GPL version 3 or later >>>> This is free software: you are free to change and redistribute it. >>>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >>>> and "show warranty" for details. >>>> This GDB was configured as "powerpc-linux-gnu"... >>>> (gdb) break main >>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>> (gdb) r >>>> Starting program: /home/jay/cm3/bin/a.out >>>> Breakpoint 1, main () at 1.c:1 >>>> 1 main(){} >>>> (gdb) >>>> >>>> >>>> jay at plin:/cm3/bin$ gcc -gstabs+ 1.c >>>> jay at plin:/cm3/bin$ gdb ./a.out >>>> GNU gdb 6.8-debian >>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>> License GPLv3+: GNU GPL version 3 or later >>>> This is free software: you are free to change and redistribute it. >>>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >>>> and "show warranty" for details. >>>> This GDB was configured as "powerpc-linux-gnu"... >>>> (gdb) break main >>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>> (gdb) r >>>> Starting program: /home/jay/cm3/bin/a.out >>>> Breakpoint 1, main () at 1.c:1 >>>> 1 main(){} >>>> >>>> >>>> jay at plin:/cm3/bin$ gcc -gstabs 1.c >>>> jay at plin:/cm3/bin$ gdb ./a.out >>>> GNU gdb 6.8-debian >>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>> License GPLv3+: GNU GPL version 3 or later >>>> This is free software: you are free to change and redistribute it. >>>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >>>> and "show warranty" for details. >>>> This GDB was configured as "powerpc-linux-gnu"... >>>> (gdb) break main >>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>> (gdb) r >>>> Starting program: /home/jay/cm3/bin/a.out >>>> Breakpoint 1, main () at 1.c:1 >>>> 1 main(){} >>>> (gdb) >>>> >>>> >>>> - Jay >>>> >>>> >>>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: m3devel at elegosoft.com >>>> Subject: more crashers >>>> Date: Sun, 16 Aug 2009 10:06:15 +0000 >>>> >>>> >>>> This is head on SOLgnu: >>>> I'll try another and debug and see if fix is easy. >>>> >>>> -bash-3.00$ ./m3browser >>>> >>>> *** >>>> *** runtime error: >>>> *** Segmentation violation - possible attempt to dereference NIL >>>> *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/String16.m3 >>>> *** >>>> >>>> -bash-3.00$ ./visobliq >>>> Internal Obliq interpreter installed... >>>> Establishing 'templates' >>>> (Created frame 'templates') >>>> let >>>> Templates = >>>> {boolean=> ... , >>>> browser=> ... , >>>> button=> ... , >>>> choice=> ... , >>>> filebrowser=> ... , >>>> form=> ... , >>>> frame=> ... , >>>> hscroll=> ... , >>>> menu=> ... , >>>> numeric=> ... , >>>> text=> ... , >>>> textedit=> ... , >>>> typein=> ... , >>>> video=> ... , >>>> vscroll=> ... } >>>> Establishing 'vowidgets' >>>> (Created frame 'vowidgets') >>>> ok >>>> Establishing 'vocheckpt' >>>> (Created frame 'vocheckpt') >>>> ok >>>> Establishing 'volib' >>>> (Created frame 'volib') >>>> Segmentation Fault (core dumped) >>>> -bash-3.00$ >>>> >>>> From hosking at cs.purdue.edu Mon Aug 17 01:10:15 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 16 Aug 2009 19:10:15 -0400 Subject: [M3devel] more crashers In-Reply-To: References: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> Message-ID: So now I am worried about the recent changes to Text... On 16 Aug 2009, at 15:33, Jay K wrote: > > Could be. I've also seen it on PPC_DARWIN a while ago. I only recall > seeing it on sparc and ppc. > It doesn't always occur. > > > Here is the m3browser crash on a system that can be debugged. > See why I want the full paths in the debug info? > > > C:\Users\jay\Desktop>\cygwin\bin\ssh xobsd. > $ cd /cm3 > $ cd bin > $ export DISPLAY=192.168.1.120:0.0 > $ gdb ./m3browser > GNU gdb 6.3 > This GDB was configured as "i386-unknown-openbsd4.5"... > (gdb) r > Starting program: /home/jay/cm3/bin/m3browser > Program received signal SIGSEGV, Segmentation fault. > [Switching to process 31063, thread 0x7eafe800] > 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 > 16 t.get_info (i); > (gdb) bt > #0 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/ > Text.m3:16 > #1 0x09fd9464 in ID__Add (M3_Bd56fi_x=0x0) at ../src/ID.m3:48 > #2 0x1c01e644 in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:37 > #3 0x0156f1bc in RTLinker__RunMainBody (M3_DjPxE3_m=0x3c003ec0) > at ../src/runtime/common/RTLinker.m3:399 > #4 0x0156e576 in RTLinker__AddUnitI (M3_DjPxE3_m=0x3c003ec0) > at ../src/runtime/common/RTLinker.m3:113 > #5 0x0156e604 in RTLinker__AddUnit (M3_DjPxE5_b=0x1c01e54d) > at ../src/runtime/common/RTLinker.m3:122 > #6 0x1c004676 in main (argc=1, argv=0xcfbf6a3c, envp=0xcfbf6a44) > at _m3main.mc:4 > > > - Jay > > > ________________________________ >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Sun, 16 Aug 2009 15:26:49 -0400 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] more crashers >> >> Could this be endianness-related? >> >> On 16 Aug 2009, at 15:21, Jay K wrote: >> >> >> I see the assertion failure on PPC_LINUX too. >> I tried VAR defaultStackSize := 1024 * 1024; (not sure why there >> was any suspicion of stack size). >> >> >> Debugging doesn't work PPC_LINUX. >> >> >> jay at plin:/cm3/bin$ gdb ./cm3 >> GNU gdb 6.8-debian >> Copyright (C) 2008 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. Type "show >> copying" >> and "show warranty" for details. >> This GDB was configured as "powerpc-linux-gnu"... >> break ma(gdb) break main >> Breakpoint 1 at 0x86fc4: file _m3main.mc, line 2. >> (gdb) r >> Starting program: /home/jay/cm3/bin/cm3 >> Warning: >> Cannot insert breakpoint 1. >> Error accessing memory address 0x86fc4: Input/output error. >> >> >> No problem with C: >> >> >> jay at plin:/cm3/bin$ echo "main(){}"> 1.c >> jay at plin:/cm3/bin$ gcc -g 1.c >> jay at plin:/cm3/bin$ gdb ./a.out >> GNU gdb 6.8-debian >> Copyright (C) 2008 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. Type "show >> copying" >> and "show warranty" for details. >> This GDB was configured as "powerpc-linux-gnu"... >> (gdb) break main >> Breakpoint 1 at 0x10000448: file 1.c, line 1. >> (gdb) r >> Starting program: /home/jay/cm3/bin/a.out >> Breakpoint 1, main () at 1.c:1 >> 1 main(){} >> (gdb) >> >> >> jay at plin:/cm3/bin$ gcc -gstabs+ 1.c >> jay at plin:/cm3/bin$ gdb ./a.out >> GNU gdb 6.8-debian >> Copyright (C) 2008 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. Type "show >> copying" >> and "show warranty" for details. >> This GDB was configured as "powerpc-linux-gnu"... >> (gdb) break main >> Breakpoint 1 at 0x10000448: file 1.c, line 1. >> (gdb) r >> Starting program: /home/jay/cm3/bin/a.out >> Breakpoint 1, main () at 1.c:1 >> 1 main(){} >> >> >> jay at plin:/cm3/bin$ gcc -gstabs 1.c >> jay at plin:/cm3/bin$ gdb ./a.out >> GNU gdb 6.8-debian >> Copyright (C) 2008 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. Type "show >> copying" >> and "show warranty" for details. >> This GDB was configured as "powerpc-linux-gnu"... >> (gdb) break main >> Breakpoint 1 at 0x10000448: file 1.c, line 1. >> (gdb) r >> Starting program: /home/jay/cm3/bin/a.out >> Breakpoint 1, main () at 1.c:1 >> 1 main(){} >> (gdb) >> >> >> - Jay >> >> >> ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Subject: more crashers >> Date: Sun, 16 Aug 2009 10:06:15 +0000 >> >> >> This is head on SOLgnu: >> I'll try another and debug and see if fix is easy. >> >> -bash-3.00$ ./m3browser >> >> *** >> *** runtime error: >> *** Segmentation violation - possible attempt to dereference NIL >> *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/String16.m3 >> *** >> >> -bash-3.00$ ./visobliq >> Internal Obliq interpreter installed... >> Establishing 'templates' >> (Created frame 'templates') >> let >> Templates = >> {boolean=> ... , >> browser=> ... , >> button=> ... , >> choice=> ... , >> filebrowser=> ... , >> form=> ... , >> frame=> ... , >> hscroll=> ... , >> menu=> ... , >> numeric=> ... , >> text=> ... , >> textedit=> ... , >> typein=> ... , >> video=> ... , >> vscroll=> ... } >> Establishing 'vowidgets' >> (Created frame 'vowidgets') >> ok >> Establishing 'vocheckpt' >> (Created frame 'vocheckpt') >> ok >> Establishing 'volib' >> (Created frame 'volib') >> Segmentation Fault (core dumped) >> -bash-3.00$ >> >> From jay.krell at cornell.edu Mon Aug 17 03:14:02 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 17 Aug 2009 01:14:02 +0000 Subject: [M3devel] more crashers In-Reply-To: References: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> Message-ID: Don't worry because of this. This was changing folks from M3Config to MxConfig plus that my config doesn't go out of its way to be compatible with code that doesn't predefine stuff -- ie: mxconfig clients other than cm3. The "normal" config files have been adapted to be compatible. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Sun, 16 Aug 2009 19:10:15 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] more crashers > > So now I am worried about the recent changes to Text... > > On 16 Aug 2009, at 15:33, Jay K wrote: > >> >> Could be. I've also seen it on PPC_DARWIN a while ago. I only recall >> seeing it on sparc and ppc. >> It doesn't always occur. >> >> >> Here is the m3browser crash on a system that can be debugged. >> See why I want the full paths in the debug info? >> >> >> C:\Users\jay\Desktop>\cygwin\bin\ssh xobsd. >> $ cd /cm3 >> $ cd bin >> $ export DISPLAY=192.168.1.120:0.0 >> $ gdb ./m3browser >> GNU gdb 6.3 >> This GDB was configured as "i386-unknown-openbsd4.5"... >> (gdb) r >> Starting program: /home/jay/cm3/bin/m3browser >> Program received signal SIGSEGV, Segmentation fault. >> [Switching to process 31063, thread 0x7eafe800] >> 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 >> 16 t.get_info (i); >> (gdb) bt >> #0 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/ >> Text.m3:16 >> #1 0x09fd9464 in ID__Add (M3_Bd56fi_x=0x0) at ../src/ID.m3:48 >> #2 0x1c01e644 in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:37 >> #3 0x0156f1bc in RTLinker__RunMainBody (M3_DjPxE3_m=0x3c003ec0) >> at ../src/runtime/common/RTLinker.m3:399 >> #4 0x0156e576 in RTLinker__AddUnitI (M3_DjPxE3_m=0x3c003ec0) >> at ../src/runtime/common/RTLinker.m3:113 >> #5 0x0156e604 in RTLinker__AddUnit (M3_DjPxE5_b=0x1c01e54d) >> at ../src/runtime/common/RTLinker.m3:122 >> #6 0x1c004676 in main (argc=1, argv=0xcfbf6a3c, envp=0xcfbf6a44) >> at _m3main.mc:4 >> >> >> - Jay >> >> >> ________________________________ >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Date: Sun, 16 Aug 2009 15:26:49 -0400 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] more crashers >>> >>> Could this be endianness-related? >>> >>> On 16 Aug 2009, at 15:21, Jay K wrote: >>> >>> >>> I see the assertion failure on PPC_LINUX too. >>> I tried VAR defaultStackSize := 1024 * 1024; (not sure why there >>> was any suspicion of stack size). >>> >>> >>> Debugging doesn't work PPC_LINUX. >>> >>> >>> jay at plin:/cm3/bin$ gdb ./cm3 >>> GNU gdb 6.8-debian >>> Copyright (C) 2008 Free Software Foundation, Inc. >>> License GPLv3+: GNU GPL version 3 or later >>> This is free software: you are free to change and redistribute it. >>> There is NO WARRANTY, to the extent permitted by law. Type "show >>> copying" >>> and "show warranty" for details. >>> This GDB was configured as "powerpc-linux-gnu"... >>> break ma(gdb) break main >>> Breakpoint 1 at 0x86fc4: file _m3main.mc, line 2. >>> (gdb) r >>> Starting program: /home/jay/cm3/bin/cm3 >>> Warning: >>> Cannot insert breakpoint 1. >>> Error accessing memory address 0x86fc4: Input/output error. >>> >>> >>> No problem with C: >>> >>> >>> jay at plin:/cm3/bin$ echo "main(){}"> 1.c >>> jay at plin:/cm3/bin$ gcc -g 1.c >>> jay at plin:/cm3/bin$ gdb ./a.out >>> GNU gdb 6.8-debian >>> Copyright (C) 2008 Free Software Foundation, Inc. >>> License GPLv3+: GNU GPL version 3 or later >>> This is free software: you are free to change and redistribute it. >>> There is NO WARRANTY, to the extent permitted by law. Type "show >>> copying" >>> and "show warranty" for details. >>> This GDB was configured as "powerpc-linux-gnu"... >>> (gdb) break main >>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>> (gdb) r >>> Starting program: /home/jay/cm3/bin/a.out >>> Breakpoint 1, main () at 1.c:1 >>> 1 main(){} >>> (gdb) >>> >>> >>> jay at plin:/cm3/bin$ gcc -gstabs+ 1.c >>> jay at plin:/cm3/bin$ gdb ./a.out >>> GNU gdb 6.8-debian >>> Copyright (C) 2008 Free Software Foundation, Inc. >>> License GPLv3+: GNU GPL version 3 or later >>> This is free software: you are free to change and redistribute it. >>> There is NO WARRANTY, to the extent permitted by law. Type "show >>> copying" >>> and "show warranty" for details. >>> This GDB was configured as "powerpc-linux-gnu"... >>> (gdb) break main >>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>> (gdb) r >>> Starting program: /home/jay/cm3/bin/a.out >>> Breakpoint 1, main () at 1.c:1 >>> 1 main(){} >>> >>> >>> jay at plin:/cm3/bin$ gcc -gstabs 1.c >>> jay at plin:/cm3/bin$ gdb ./a.out >>> GNU gdb 6.8-debian >>> Copyright (C) 2008 Free Software Foundation, Inc. >>> License GPLv3+: GNU GPL version 3 or later >>> This is free software: you are free to change and redistribute it. >>> There is NO WARRANTY, to the extent permitted by law. Type "show >>> copying" >>> and "show warranty" for details. >>> This GDB was configured as "powerpc-linux-gnu"... >>> (gdb) break main >>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>> (gdb) r >>> Starting program: /home/jay/cm3/bin/a.out >>> Breakpoint 1, main () at 1.c:1 >>> 1 main(){} >>> (gdb) >>> >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: m3devel at elegosoft.com >>> Subject: more crashers >>> Date: Sun, 16 Aug 2009 10:06:15 +0000 >>> >>> >>> This is head on SOLgnu: >>> I'll try another and debug and see if fix is easy. >>> >>> -bash-3.00$ ./m3browser >>> >>> *** >>> *** runtime error: >>> *** Segmentation violation - possible attempt to dereference NIL >>> *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/String16.m3 >>> *** >>> >>> -bash-3.00$ ./visobliq >>> Internal Obliq interpreter installed... >>> Establishing 'templates' >>> (Created frame 'templates') >>> let >>> Templates = >>> {boolean=> ... , >>> browser=> ... , >>> button=> ... , >>> choice=> ... , >>> filebrowser=> ... , >>> form=> ... , >>> frame=> ... , >>> hscroll=> ... , >>> menu=> ... , >>> numeric=> ... , >>> text=> ... , >>> textedit=> ... , >>> typein=> ... , >>> video=> ... , >>> vscroll=> ... } >>> Establishing 'vowidgets' >>> (Created frame 'vowidgets') >>> ok >>> Establishing 'vocheckpt' >>> (Created frame 'vocheckpt') >>> ok >>> Establishing 'volib' >>> (Created frame 'volib') >>> Segmentation Fault (core dumped) >>> -bash-3.00$ >>> >>> > From jay.krell at cornell.edu Mon Aug 17 03:33:03 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 17 Aug 2009 01:33:03 +0000 Subject: [M3devel] Errors building Juno on PPC_LINUX (Debian 5) Message-ID: > I'm going to rebuild m3cc clean Did not reoccur after that. Possibly some mismatch with an cm3cg built on Debian 4 vs. Debian 5's binutils. Though that only really makes sense for one of the errors. (Debian 5 has nice property of Sun Java being available for all but hppa, good for Hudson's sake.) - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: Errors building Juno on PPC_LINUX (Debian 5) > Date: Sun, 16 Aug 2009 19:27:03 +0000 > > > Errors building Juno on PPC_LINUX (Debian 5) > > == package /home/jay/dev2/cm3/m3-ui/juno-2/juno-app == > +++ /cm3/bin/cm3 -build -DROOT=/home/jay/dev2/cm3 -DCM3_VERSION_TEXT=d5.8.2 -D > CM3_VERSION_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ > --- building in PPC_LINUX --- > ... > new source -> compiling Editor.m3 > ../src/Editor.m3: In function 'Editor__Parse2': > ../src/Editor.m3:248: fatal error: *** bad opcode: 0x229, at m3cg_lineno 18629 > compilation terminated. > m3_backend => 1 > m3cc (aka cm3cg) failed compiling: Editor.mc > new opaque info -> recompiling Drag.m3 > Drag.ms: Assembler messages: > Drag.ms:3949: Error: unknown pseudo-op: `.s' > assemble => 1 > assembler failed assembling: Drag.ms > *** execution of [, ] failed *** > jay at plin:/dev2/cm3/scripts/python$ > > > More details to follow. > I'm going to rebuild m3cc clean, make sure it was built native not copied from another machine, but I think it already was native. > > > - Jay From jay.krell at cornell.edu Mon Aug 17 06:01:01 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 17 Aug 2009 04:01:01 +0000 Subject: [M3devel] more crashers In-Reply-To: References: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> Message-ID: visobliq was stack overflow. Raising the default from 4K to 16K didn't fix, but 32K did. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] more crashers > Date: Sun, 16 Aug 2009 20:32:31 +0000 > > > m3browser: > > It is specific to my config file m3-sys/cminstall/src/config-no-install/cm3.cfg that reachs back into the source tree. It won't happen with what most people do. I have to do that M3Predefines or such work so that all the uses of m3quake besides cm3 are much more like cm3. > > > visobliq: > not the same thing > Does not occur on Linux/x86 or Linux/sparc. > They do print > Syntax error just before: -helvetica-bold-\*R-\*240-\*\") (LabelFo ... > ill-formed character escape sequence > Error detected (file file generated by Visual Obliq) (line 18, char 10) > VideoVBT.Start Jv ServerFailure:errno=0 > > but then gui comes up. > I'll have to finish my Solaris reinstall and get dbx. > > > - Jay > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> Date: Sun, 16 Aug 2009 20:22:49 +0000 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] more crashers >> >> >> sorry, this is simple. >> >> derived_dirs := IntList.List1 (ID.Add (MxConfig.Get("BUILD_DIR"))); >> >> >> - Jay >> >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu >>> Date: Sun, 16 Aug 2009 19:52:03 +0000 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] more crashers >>> >>> >>> Here is the relevant code in m3browser ID.m3: >>> >>> >>> C:\dev2\cm3.2\m3-tools\m3markup\src\ID.m3(38): empty_id := Add (""); >>> >>> empty_id := Add (""); >>> >>> (*-------------------------------------------------------------- exported ---*) >>> PROCEDURE Add (x: TEXT): T = >>> VAR >>> t: T; >>> a: REF ARRAY OF CHAR; >>> l: INTEGER; >>> BEGIN >>> l := Text.Length(x); >>> ... >>> END Add; >>> >>> >>> The empty string constant ends up as null. >>> >>> .stabn 68,0,38,.LM115-.LFBB10 >>> .LM115: >>> movl L_1 at GOT(%ebx), %eax >>> leal 24(%eax), %eax >>> movl %eax, (%esp) >>> call ID__Add at PLT >>> movl %eax, -8(%ebp) >>> movl -8(%ebp), %ecx >>> movl MM_ID at GOT(%ebx), %edx >>> movl 248(%edx), %eax >>> andl $0, %eax >>> orl %ecx, %eax >>> movl %eax, 248(%edx) >>> .L136: >>> movl MM_ID at GOT(%ebx), %eax >>> .LBE16: >>> addl $52, %esp >>> popl %ebx >>> popl %ebp >>> ret >>> >>> L_1: >>> 0 .long RTHooks__TextLitInfo >>> 4 .long RTHooks__TextLitGetChar >>> 8 .long RTHooks__TextLitGetWideChar >>> 12 .long RTHooks__TextLitGetChars >>> 16 .long RTHooks__TextLitGetWideChars >>> 20 .long 2 >>> 24 .long L_1 >>> .long 0 >>> .zero 4 >>> .ascii "ID_M3" >>> .zero 1 >>> .ascii "ExpandHashTable" >>> .zero 1 >>> .ascii "ExpandIDs" >>> .zero 1 >>> .ascii "ExpandChars" >>> .zero 1 >>> .ascii "Compare" >>> .zero 1 >>> >>> If I change "" to "foo", I get: >>> >>> L_1: >>> 0 .long RTHooks__TextLitInfo >>> 4 .long RTHooks__TextLitGetChar >>> 8 .long RTHooks__TextLitGetWideChar >>> 12 .long RTHooks__TextLitGetChars >>> 16 .long RTHooks__TextLitGetWideChars >>> 20 .long 2 >>> 24 .long L_1 >>> .long 3 >>> .ascii "foo" >>> .zero 1 >>> .ascii "ID_M3" >>> >>> and it still crashes. >>> >>> >>> It seems to hit ID__Add twice when only once would be expected. >>> >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: hosking at cs.purdue.edu >>>> Date: Sun, 16 Aug 2009 19:33:34 +0000 >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] more crashers >>>> >>>> >>>> Could be. I've also seen it on PPC_DARWIN a while ago. I only recall seeing it on sparc and ppc. >>>> It doesn't always occur. >>>> >>>> >>>> Here is the m3browser crash on a system that can be debugged. >>>> See why I want the full paths in the debug info? >>>> >>>> >>>> C:\Users\jay\Desktop>\cygwin\bin\ssh xobsd. >>>> $ cd /cm3 >>>> $ cd bin >>>> $ export DISPLAY=192.168.1.120:0.0 >>>> $ gdb ./m3browser >>>> GNU gdb 6.3 >>>> This GDB was configured as "i386-unknown-openbsd4.5"... >>>> (gdb) r >>>> Starting program: /home/jay/cm3/bin/m3browser >>>> Program received signal SIGSEGV, Segmentation fault. >>>> [Switching to process 31063, thread 0x7eafe800] >>>> 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 >>>> 16 t.get_info (i); >>>> (gdb) bt >>>> #0 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 >>>> #1 0x09fd9464 in ID__Add (M3_Bd56fi_x=0x0) at ../src/ID.m3:48 >>>> #2 0x1c01e644 in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:37 >>>> #3 0x0156f1bc in RTLinker__RunMainBody (M3_DjPxE3_m=0x3c003ec0) >>>> at ../src/runtime/common/RTLinker.m3:399 >>>> #4 0x0156e576 in RTLinker__AddUnitI (M3_DjPxE3_m=0x3c003ec0) >>>> at ../src/runtime/common/RTLinker.m3:113 >>>> #5 0x0156e604 in RTLinker__AddUnit (M3_DjPxE5_b=0x1c01e54d) >>>> at ../src/runtime/common/RTLinker.m3:122 >>>> #6 0x1c004676 in main (argc=1, argv=0xcfbf6a3c, envp=0xcfbf6a44) >>>> at _m3main.mc:4 >>>> >>>> >>>> - Jay >>>> >>>> >>>> ________________________________ >>>>> From: hosking at cs.purdue.edu >>>>> To: jay.krell at cornell.edu >>>>> Date: Sun, 16 Aug 2009 15:26:49 -0400 >>>>> CC: m3devel at elegosoft.com >>>>> Subject: Re: [M3devel] more crashers >>>>> >>>>> Could this be endianness-related? >>>>> >>>>> On 16 Aug 2009, at 15:21, Jay K wrote: >>>>> >>>>> >>>>> I see the assertion failure on PPC_LINUX too. >>>>> I tried VAR defaultStackSize := 1024 * 1024; (not sure why there was any suspicion of stack size). >>>>> >>>>> >>>>> Debugging doesn't work PPC_LINUX. >>>>> >>>>> >>>>> jay at plin:/cm3/bin$ gdb ./cm3 >>>>> GNU gdb 6.8-debian >>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>> License GPLv3+: GNU GPL version 3 or later >>>>> This is free software: you are free to change and redistribute it. >>>>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >>>>> and "show warranty" for details. >>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>> break ma(gdb) break main >>>>> Breakpoint 1 at 0x86fc4: file _m3main.mc, line 2. >>>>> (gdb) r >>>>> Starting program: /home/jay/cm3/bin/cm3 >>>>> Warning: >>>>> Cannot insert breakpoint 1. >>>>> Error accessing memory address 0x86fc4: Input/output error. >>>>> >>>>> >>>>> No problem with C: >>>>> >>>>> >>>>> jay at plin:/cm3/bin$ echo "main(){}"> 1.c >>>>> jay at plin:/cm3/bin$ gcc -g 1.c >>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>> GNU gdb 6.8-debian >>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>> License GPLv3+: GNU GPL version 3 or later >>>>> This is free software: you are free to change and redistribute it. >>>>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >>>>> and "show warranty" for details. >>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>> (gdb) break main >>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>> (gdb) r >>>>> Starting program: /home/jay/cm3/bin/a.out >>>>> Breakpoint 1, main () at 1.c:1 >>>>> 1 main(){} >>>>> (gdb) >>>>> >>>>> >>>>> jay at plin:/cm3/bin$ gcc -gstabs+ 1.c >>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>> GNU gdb 6.8-debian >>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>> License GPLv3+: GNU GPL version 3 or later >>>>> This is free software: you are free to change and redistribute it. >>>>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >>>>> and "show warranty" for details. >>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>> (gdb) break main >>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>> (gdb) r >>>>> Starting program: /home/jay/cm3/bin/a.out >>>>> Breakpoint 1, main () at 1.c:1 >>>>> 1 main(){} >>>>> >>>>> >>>>> jay at plin:/cm3/bin$ gcc -gstabs 1.c >>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>> GNU gdb 6.8-debian >>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>> License GPLv3+: GNU GPL version 3 or later >>>>> This is free software: you are free to change and redistribute it. >>>>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >>>>> and "show warranty" for details. >>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>> (gdb) break main >>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>> (gdb) r >>>>> Starting program: /home/jay/cm3/bin/a.out >>>>> Breakpoint 1, main () at 1.c:1 >>>>> 1 main(){} >>>>> (gdb) >>>>> >>>>> >>>>> - Jay >>>>> >>>>> >>>>> ---------------------------------------- >>>>> From: jay.krell at cornell.edu >>>>> To: m3devel at elegosoft.com >>>>> Subject: more crashers >>>>> Date: Sun, 16 Aug 2009 10:06:15 +0000 >>>>> >>>>> >>>>> This is head on SOLgnu: >>>>> I'll try another and debug and see if fix is easy. >>>>> >>>>> -bash-3.00$ ./m3browser >>>>> >>>>> *** >>>>> *** runtime error: >>>>> *** Segmentation violation - possible attempt to dereference NIL >>>>> *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/String16.m3 >>>>> *** >>>>> >>>>> -bash-3.00$ ./visobliq >>>>> Internal Obliq interpreter installed... >>>>> Establishing 'templates' >>>>> (Created frame 'templates') >>>>> let >>>>> Templates = >>>>> {boolean=> ... , >>>>> browser=> ... , >>>>> button=> ... , >>>>> choice=> ... , >>>>> filebrowser=> ... , >>>>> form=> ... , >>>>> frame=> ... , >>>>> hscroll=> ... , >>>>> menu=> ... , >>>>> numeric=> ... , >>>>> text=> ... , >>>>> textedit=> ... , >>>>> typein=> ... , >>>>> video=> ... , >>>>> vscroll=> ... } >>>>> Establishing 'vowidgets' >>>>> (Created frame 'vowidgets') >>>>> ok >>>>> Establishing 'vocheckpt' >>>>> (Created frame 'vocheckpt') >>>>> ok >>>>> Establishing 'volib' >>>>> (Created frame 'volib') >>>>> Segmentation Fault (core dumped) >>>>> -bash-3.00$ >>>>> >>>>> From jay.krell at cornell.edu Mon Aug 17 06:01:45 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 17 Aug 2009 04:01:45 +0000 Subject: [M3devel] more crashers In-Reply-To: References: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> Message-ID: visobliq was stack overflow. Raising the default from 4K to 16K didn't fix, but 32K did. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] more crashers > Date: Sun, 16 Aug 2009 20:32:31 +0000 > > > m3browser: > > It is specific to my config file m3-sys/cminstall/src/config-no-install/cm3.cfg that reachs back into the source tree. It won't happen with what most people do. I have to do that M3Predefines or such work so that all the uses of m3quake besides cm3 are much more like cm3. > > > visobliq: > not the same thing > Does not occur on Linux/x86 or Linux/sparc. > They do print > Syntax error just before: -helvetica-bold-\*R-\*240-\*\") (LabelFo ... > ill-formed character escape sequence > Error detected (file file generated by Visual Obliq) (line 18, char 10) > VideoVBT.Start Jv ServerFailure:errno=0 > > but then gui comes up. > I'll have to finish my Solaris reinstall and get dbx. > > > - Jay > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> Date: Sun, 16 Aug 2009 20:22:49 +0000 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] more crashers >> >> >> sorry, this is simple. >> >> derived_dirs := IntList.List1 (ID.Add (MxConfig.Get("BUILD_DIR"))); >> >> >> - Jay >> >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu >>> Date: Sun, 16 Aug 2009 19:52:03 +0000 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] more crashers >>> >>> >>> Here is the relevant code in m3browser ID.m3: >>> >>> >>> C:\dev2\cm3.2\m3-tools\m3markup\src\ID.m3(38): empty_id := Add (""); >>> >>> empty_id := Add (""); >>> >>> (*-------------------------------------------------------------- exported ---*) >>> PROCEDURE Add (x: TEXT): T = >>> VAR >>> t: T; >>> a: REF ARRAY OF CHAR; >>> l: INTEGER; >>> BEGIN >>> l := Text.Length(x); >>> ... >>> END Add; >>> >>> >>> The empty string constant ends up as null. >>> >>> .stabn 68,0,38,.LM115-.LFBB10 >>> .LM115: >>> movl L_1 at GOT(%ebx), %eax >>> leal 24(%eax), %eax >>> movl %eax, (%esp) >>> call ID__Add at PLT >>> movl %eax, -8(%ebp) >>> movl -8(%ebp), %ecx >>> movl MM_ID at GOT(%ebx), %edx >>> movl 248(%edx), %eax >>> andl $0, %eax >>> orl %ecx, %eax >>> movl %eax, 248(%edx) >>> .L136: >>> movl MM_ID at GOT(%ebx), %eax >>> .LBE16: >>> addl $52, %esp >>> popl %ebx >>> popl %ebp >>> ret >>> >>> L_1: >>> 0 .long RTHooks__TextLitInfo >>> 4 .long RTHooks__TextLitGetChar >>> 8 .long RTHooks__TextLitGetWideChar >>> 12 .long RTHooks__TextLitGetChars >>> 16 .long RTHooks__TextLitGetWideChars >>> 20 .long 2 >>> 24 .long L_1 >>> .long 0 >>> .zero 4 >>> .ascii "ID_M3" >>> .zero 1 >>> .ascii "ExpandHashTable" >>> .zero 1 >>> .ascii "ExpandIDs" >>> .zero 1 >>> .ascii "ExpandChars" >>> .zero 1 >>> .ascii "Compare" >>> .zero 1 >>> >>> If I change "" to "foo", I get: >>> >>> L_1: >>> 0 .long RTHooks__TextLitInfo >>> 4 .long RTHooks__TextLitGetChar >>> 8 .long RTHooks__TextLitGetWideChar >>> 12 .long RTHooks__TextLitGetChars >>> 16 .long RTHooks__TextLitGetWideChars >>> 20 .long 2 >>> 24 .long L_1 >>> .long 3 >>> .ascii "foo" >>> .zero 1 >>> .ascii "ID_M3" >>> >>> and it still crashes. >>> >>> >>> It seems to hit ID__Add twice when only once would be expected. >>> >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: hosking at cs.purdue.edu >>>> Date: Sun, 16 Aug 2009 19:33:34 +0000 >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] more crashers >>>> >>>> >>>> Could be. I've also seen it on PPC_DARWIN a while ago. I only recall seeing it on sparc and ppc. >>>> It doesn't always occur. >>>> >>>> >>>> Here is the m3browser crash on a system that can be debugged. >>>> See why I want the full paths in the debug info? >>>> >>>> >>>> C:\Users\jay\Desktop>\cygwin\bin\ssh xobsd. >>>> $ cd /cm3 >>>> $ cd bin >>>> $ export DISPLAY=192.168.1.120:0.0 >>>> $ gdb ./m3browser >>>> GNU gdb 6.3 >>>> This GDB was configured as "i386-unknown-openbsd4.5"... >>>> (gdb) r >>>> Starting program: /home/jay/cm3/bin/m3browser >>>> Program received signal SIGSEGV, Segmentation fault. >>>> [Switching to process 31063, thread 0x7eafe800] >>>> 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 >>>> 16 t.get_info (i); >>>> (gdb) bt >>>> #0 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 >>>> #1 0x09fd9464 in ID__Add (M3_Bd56fi_x=0x0) at ../src/ID.m3:48 >>>> #2 0x1c01e644 in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:37 >>>> #3 0x0156f1bc in RTLinker__RunMainBody (M3_DjPxE3_m=0x3c003ec0) >>>> at ../src/runtime/common/RTLinker.m3:399 >>>> #4 0x0156e576 in RTLinker__AddUnitI (M3_DjPxE3_m=0x3c003ec0) >>>> at ../src/runtime/common/RTLinker.m3:113 >>>> #5 0x0156e604 in RTLinker__AddUnit (M3_DjPxE5_b=0x1c01e54d) >>>> at ../src/runtime/common/RTLinker.m3:122 >>>> #6 0x1c004676 in main (argc=1, argv=0xcfbf6a3c, envp=0xcfbf6a44) >>>> at _m3main.mc:4 >>>> >>>> >>>> - Jay >>>> >>>> >>>> ________________________________ >>>>> From: hosking at cs.purdue.edu >>>>> To: jay.krell at cornell.edu >>>>> Date: Sun, 16 Aug 2009 15:26:49 -0400 >>>>> CC: m3devel at elegosoft.com >>>>> Subject: Re: [M3devel] more crashers >>>>> >>>>> Could this be endianness-related? >>>>> >>>>> On 16 Aug 2009, at 15:21, Jay K wrote: >>>>> >>>>> >>>>> I see the assertion failure on PPC_LINUX too. >>>>> I tried VAR defaultStackSize := 1024 * 1024; (not sure why there was any suspicion of stack size). >>>>> >>>>> >>>>> Debugging doesn't work PPC_LINUX. >>>>> >>>>> >>>>> jay at plin:/cm3/bin$ gdb ./cm3 >>>>> GNU gdb 6.8-debian >>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>> License GPLv3+: GNU GPL version 3 or later >>>>> This is free software: you are free to change and redistribute it. >>>>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >>>>> and "show warranty" for details. >>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>> break ma(gdb) break main >>>>> Breakpoint 1 at 0x86fc4: file _m3main.mc, line 2. >>>>> (gdb) r >>>>> Starting program: /home/jay/cm3/bin/cm3 >>>>> Warning: >>>>> Cannot insert breakpoint 1. >>>>> Error accessing memory address 0x86fc4: Input/output error. >>>>> >>>>> >>>>> No problem with C: >>>>> >>>>> >>>>> jay at plin:/cm3/bin$ echo "main(){}"> 1.c >>>>> jay at plin:/cm3/bin$ gcc -g 1.c >>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>> GNU gdb 6.8-debian >>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>> License GPLv3+: GNU GPL version 3 or later >>>>> This is free software: you are free to change and redistribute it. >>>>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >>>>> and "show warranty" for details. >>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>> (gdb) break main >>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>> (gdb) r >>>>> Starting program: /home/jay/cm3/bin/a.out >>>>> Breakpoint 1, main () at 1.c:1 >>>>> 1 main(){} >>>>> (gdb) >>>>> >>>>> >>>>> jay at plin:/cm3/bin$ gcc -gstabs+ 1.c >>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>> GNU gdb 6.8-debian >>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>> License GPLv3+: GNU GPL version 3 or later >>>>> This is free software: you are free to change and redistribute it. >>>>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >>>>> and "show warranty" for details. >>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>> (gdb) break main >>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>> (gdb) r >>>>> Starting program: /home/jay/cm3/bin/a.out >>>>> Breakpoint 1, main () at 1.c:1 >>>>> 1 main(){} >>>>> >>>>> >>>>> jay at plin:/cm3/bin$ gcc -gstabs 1.c >>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>> GNU gdb 6.8-debian >>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>> License GPLv3+: GNU GPL version 3 or later >>>>> This is free software: you are free to change and redistribute it. >>>>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >>>>> and "show warranty" for details. >>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>> (gdb) break main >>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>> (gdb) r >>>>> Starting program: /home/jay/cm3/bin/a.out >>>>> Breakpoint 1, main () at 1.c:1 >>>>> 1 main(){} >>>>> (gdb) >>>>> >>>>> >>>>> - Jay >>>>> >>>>> >>>>> ---------------------------------------- >>>>> From: jay.krell at cornell.edu >>>>> To: m3devel at elegosoft.com >>>>> Subject: more crashers >>>>> Date: Sun, 16 Aug 2009 10:06:15 +0000 >>>>> >>>>> >>>>> This is head on SOLgnu: >>>>> I'll try another and debug and see if fix is easy. >>>>> >>>>> -bash-3.00$ ./m3browser >>>>> >>>>> *** >>>>> *** runtime error: >>>>> *** Segmentation violation - possible attempt to dereference NIL >>>>> *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/String16.m3 >>>>> *** >>>>> >>>>> -bash-3.00$ ./visobliq >>>>> Internal Obliq interpreter installed... >>>>> Establishing 'templates' >>>>> (Created frame 'templates') >>>>> let >>>>> Templates = >>>>> {boolean=> ... , >>>>> browser=> ... , >>>>> button=> ... , >>>>> choice=> ... , >>>>> filebrowser=> ... , >>>>> form=> ... , >>>>> frame=> ... , >>>>> hscroll=> ... , >>>>> menu=> ... , >>>>> numeric=> ... , >>>>> text=> ... , >>>>> textedit=> ... , >>>>> typein=> ... , >>>>> video=> ... , >>>>> vscroll=> ... } >>>>> Establishing 'vowidgets' >>>>> (Created frame 'vowidgets') >>>>> ok >>>>> Establishing 'vocheckpt' >>>>> (Created frame 'vocheckpt') >>>>> ok >>>>> Establishing 'volib' >>>>> (Created frame 'volib') >>>>> Segmentation Fault (core dumped) >>>>> -bash-3.00$ >>>>> >>>>> From jay.krell at cornell.edu Mon Aug 17 10:10:33 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Mon, 17 Aug 2009 01:10:33 -0700 Subject: [M3devel] more crashers In-Reply-To: References: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> Message-ID: Ps a few things We should see about reducing stack usage. We should see about eliminating recursion on the machine stack. Recursion is ok but use a heap allocated data structure. We should experiment to see what some behaviors are specifically default stack sizes, if the stack size is actually changable, and how small it can actually be made on the various platforms. For *hypothetical* example if other than solaris rounds stack size up to 64k boundary then default should be increased to 64k. It depends what behaviors exist. I find the machine stack to the extent that I am familiar with it's implementations, broken. It is fast but it has two severe problems vs heap. 1 you generally have to somehow guess at its maximum size which is approx impossible and approx never done 2 generally no code deals with stack exhaustion, with good reason, it is difficult/impossible/not portable. Compare that to malloc where it is generally limited only by address space, everyone knows what failure looks like, and you can easily detect and react to failure, portably. It would be cool if alloca could return Null for out of stack but that doesn't nearly solve the problem. (yes I understand, alloca is not used for the vast majority of stack allocation, and isn't even portable) - Jay (phone) On Aug 16, 2009, at 9:01 PM, Jay K wrote: > > visobliq was stack overflow. > Raising the default from 4K to 16K didn't fix, but 32K did. > > - Jay > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] more crashers >> Date: Sun, 16 Aug 2009 20:32:31 +0000 >> >> >> m3browser: >> >> It is specific to my config file m3-sys/cminstall/src/config-no- >> install/cm3.cfg that reachs back into the source tree. It won't >> happen with what most people do. I have to do that M3Predefines or >> such work so that all the uses of m3quake besides cm3 are much more >> like cm3. >> >> >> visobliq: >> not the same thing >> Does not occur on Linux/x86 or Linux/sparc. >> They do print >> Syntax error just before: -helvetica-bold-\*R-\*240-\*\") >> (LabelFo ... >> ill-formed character escape sequence >> Error detected (file file generated by Visual Obliq) (line 18, char >> 10) >> VideoVBT.Start Jv ServerFailure:errno=0 >> >> but then gui comes up. >> I'll have to finish my Solaris reinstall and get dbx. >> >> >> - Jay >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu > From wagner at elegosoft.com Mon Aug 17 13:30:26 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 17 Aug 2009 13:30:26 +0200 Subject: [M3devel] more crashers In-Reply-To: References: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> Message-ID: <20090817133026.6v9cm3cu0wwkc08k@mail.elegosoft.com> Quoting Jay K : > visobliq was stack overflow. > Raising the default from 4K to 16K didn't fix, but 32K did. We need to address this somehow. It cannot be correct if the user needs to increase the default stack size on one platform by 8 and not at all on another. Do we have any concept of a 'standard stack size unit' ;-)? Something that can be easily understood and implemented and be used instead of the machine words in the current interfaces? Any ideas? Olaf > - Jay > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] more crashers >> Date: Sun, 16 Aug 2009 20:32:31 +0000 >> >> >> m3browser: >> >> It is specific to my config file >> m3-sys/cminstall/src/config-no-install/cm3.cfg that reachs back >> into the source tree. It won't happen with what most people do. I >> have to do that M3Predefines or such work so that all the uses of >> m3quake besides cm3 are much more like cm3. >> >> >> visobliq: >> not the same thing >> Does not occur on Linux/x86 or Linux/sparc. >> They do print >> Syntax error just before: -helvetica-bold-\*R-\*240-\*\") (LabelFo ... >> ill-formed character escape sequence >> Error detected (file file generated by Visual Obliq) (line 18, char 10) >> VideoVBT.Start Jv ServerFailure:errno=0 >> >> but then gui comes up. >> I'll have to finish my Solaris reinstall and get dbx. >> >> >> - Jay >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu >>> Date: Sun, 16 Aug 2009 20:22:49 +0000 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] more crashers >>> >>> >>> sorry, this is simple. >>> >>> derived_dirs := IntList.List1 (ID.Add (MxConfig.Get("BUILD_DIR"))); >>> >>> >>> - Jay >>> >>> >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: hosking at cs.purdue.edu >>>> Date: Sun, 16 Aug 2009 19:52:03 +0000 >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] more crashers >>>> >>>> >>>> Here is the relevant code in m3browser ID.m3: >>>> >>>> >>>> C:\dev2\cm3.2\m3-tools\m3markup\src\ID.m3(38): empty_id := Add (""); >>>> >>>> empty_id := Add (""); >>>> >>>> (*-------------------------------------------------------------- >>>> exported ---*) >>>> PROCEDURE Add (x: TEXT): T = >>>> VAR >>>> t: T; >>>> a: REF ARRAY OF CHAR; >>>> l: INTEGER; >>>> BEGIN >>>> l := Text.Length(x); >>>> ... >>>> END Add; >>>> >>>> >>>> The empty string constant ends up as null. >>>> >>>> .stabn 68,0,38,.LM115-.LFBB10 >>>> .LM115: >>>> movl L_1 at GOT(%ebx), %eax >>>> leal 24(%eax), %eax >>>> movl %eax, (%esp) >>>> call ID__Add at PLT >>>> movl %eax, -8(%ebp) >>>> movl -8(%ebp), %ecx >>>> movl MM_ID at GOT(%ebx), %edx >>>> movl 248(%edx), %eax >>>> andl $0, %eax >>>> orl %ecx, %eax >>>> movl %eax, 248(%edx) >>>> .L136: >>>> movl MM_ID at GOT(%ebx), %eax >>>> .LBE16: >>>> addl $52, %esp >>>> popl %ebx >>>> popl %ebp >>>> ret >>>> >>>> L_1: >>>> 0 .long RTHooks__TextLitInfo >>>> 4 .long RTHooks__TextLitGetChar >>>> 8 .long RTHooks__TextLitGetWideChar >>>> 12 .long RTHooks__TextLitGetChars >>>> 16 .long RTHooks__TextLitGetWideChars >>>> 20 .long 2 >>>> 24 .long L_1 >>>> .long 0 >>>> .zero 4 >>>> .ascii "ID_M3" >>>> .zero 1 >>>> .ascii "ExpandHashTable" >>>> .zero 1 >>>> .ascii "ExpandIDs" >>>> .zero 1 >>>> .ascii "ExpandChars" >>>> .zero 1 >>>> .ascii "Compare" >>>> .zero 1 >>>> >>>> If I change "" to "foo", I get: >>>> >>>> L_1: >>>> 0 .long RTHooks__TextLitInfo >>>> 4 .long RTHooks__TextLitGetChar >>>> 8 .long RTHooks__TextLitGetWideChar >>>> 12 .long RTHooks__TextLitGetChars >>>> 16 .long RTHooks__TextLitGetWideChars >>>> 20 .long 2 >>>> 24 .long L_1 >>>> .long 3 >>>> .ascii "foo" >>>> .zero 1 >>>> .ascii "ID_M3" >>>> >>>> and it still crashes. >>>> >>>> >>>> It seems to hit ID__Add twice when only once would be expected. >>>> >>>> >>>> - Jay >>>> >>>> >>>> ---------------------------------------- >>>>> From: jay.krell at cornell.edu >>>>> To: hosking at cs.purdue.edu >>>>> Date: Sun, 16 Aug 2009 19:33:34 +0000 >>>>> CC: m3devel at elegosoft.com >>>>> Subject: Re: [M3devel] more crashers >>>>> >>>>> >>>>> Could be. I've also seen it on PPC_DARWIN a while ago. I only >>>>> recall seeing it on sparc and ppc. >>>>> It doesn't always occur. >>>>> >>>>> >>>>> Here is the m3browser crash on a system that can be debugged. >>>>> See why I want the full paths in the debug info? >>>>> >>>>> >>>>> C:\Users\jay\Desktop>\cygwin\bin\ssh xobsd. >>>>> $ cd /cm3 >>>>> $ cd bin >>>>> $ export DISPLAY=192.168.1.120:0.0 >>>>> $ gdb ./m3browser >>>>> GNU gdb 6.3 >>>>> This GDB was configured as "i386-unknown-openbsd4.5"... >>>>> (gdb) r >>>>> Starting program: /home/jay/cm3/bin/m3browser >>>>> Program received signal SIGSEGV, Segmentation fault. >>>>> [Switching to process 31063, thread 0x7eafe800] >>>>> 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 >>>>> 16 t.get_info (i); >>>>> (gdb) bt >>>>> #0 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 >>>>> #1 0x09fd9464 in ID__Add (M3_Bd56fi_x=0x0) at ../src/ID.m3:48 >>>>> #2 0x1c01e644 in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:37 >>>>> #3 0x0156f1bc in RTLinker__RunMainBody (M3_DjPxE3_m=0x3c003ec0) >>>>> at ../src/runtime/common/RTLinker.m3:399 >>>>> #4 0x0156e576 in RTLinker__AddUnitI (M3_DjPxE3_m=0x3c003ec0) >>>>> at ../src/runtime/common/RTLinker.m3:113 >>>>> #5 0x0156e604 in RTLinker__AddUnit (M3_DjPxE5_b=0x1c01e54d) >>>>> at ../src/runtime/common/RTLinker.m3:122 >>>>> #6 0x1c004676 in main (argc=1, argv=0xcfbf6a3c, envp=0xcfbf6a44) >>>>> at _m3main.mc:4 >>>>> >>>>> >>>>> - Jay >>>>> >>>>> >>>>> ________________________________ >>>>>> From: hosking at cs.purdue.edu >>>>>> To: jay.krell at cornell.edu >>>>>> Date: Sun, 16 Aug 2009 15:26:49 -0400 >>>>>> CC: m3devel at elegosoft.com >>>>>> Subject: Re: [M3devel] more crashers >>>>>> >>>>>> Could this be endianness-related? >>>>>> >>>>>> On 16 Aug 2009, at 15:21, Jay K wrote: >>>>>> >>>>>> >>>>>> I see the assertion failure on PPC_LINUX too. >>>>>> I tried VAR defaultStackSize := 1024 * 1024; (not sure why >>>>>> there was any suspicion of stack size). >>>>>> >>>>>> >>>>>> Debugging doesn't work PPC_LINUX. >>>>>> >>>>>> >>>>>> jay at plin:/cm3/bin$ gdb ./cm3 >>>>>> GNU gdb 6.8-debian >>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>> This is free software: you are free to change and redistribute it. >>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>> "show copying" >>>>>> and "show warranty" for details. >>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>> break ma(gdb) break main >>>>>> Breakpoint 1 at 0x86fc4: file _m3main.mc, line 2. >>>>>> (gdb) r >>>>>> Starting program: /home/jay/cm3/bin/cm3 >>>>>> Warning: >>>>>> Cannot insert breakpoint 1. >>>>>> Error accessing memory address 0x86fc4: Input/output error. >>>>>> >>>>>> >>>>>> No problem with C: >>>>>> >>>>>> >>>>>> jay at plin:/cm3/bin$ echo "main(){}"> 1.c >>>>>> jay at plin:/cm3/bin$ gcc -g 1.c >>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>> GNU gdb 6.8-debian >>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>> This is free software: you are free to change and redistribute it. >>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>> "show copying" >>>>>> and "show warranty" for details. >>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>> (gdb) break main >>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>> (gdb) r >>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>> Breakpoint 1, main () at 1.c:1 >>>>>> 1 main(){} >>>>>> (gdb) >>>>>> >>>>>> >>>>>> jay at plin:/cm3/bin$ gcc -gstabs+ 1.c >>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>> GNU gdb 6.8-debian >>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>> This is free software: you are free to change and redistribute it. >>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>> "show copying" >>>>>> and "show warranty" for details. >>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>> (gdb) break main >>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>> (gdb) r >>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>> Breakpoint 1, main () at 1.c:1 >>>>>> 1 main(){} >>>>>> >>>>>> >>>>>> jay at plin:/cm3/bin$ gcc -gstabs 1.c >>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>> GNU gdb 6.8-debian >>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>> This is free software: you are free to change and redistribute it. >>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>> "show copying" >>>>>> and "show warranty" for details. >>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>> (gdb) break main >>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>> (gdb) r >>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>> Breakpoint 1, main () at 1.c:1 >>>>>> 1 main(){} >>>>>> (gdb) >>>>>> >>>>>> >>>>>> - Jay >>>>>> >>>>>> >>>>>> ---------------------------------------- >>>>>> From: jay.krell at cornell.edu >>>>>> To: m3devel at elegosoft.com >>>>>> Subject: more crashers >>>>>> Date: Sun, 16 Aug 2009 10:06:15 +0000 >>>>>> >>>>>> >>>>>> This is head on SOLgnu: >>>>>> I'll try another and debug and see if fix is easy. >>>>>> >>>>>> -bash-3.00$ ./m3browser >>>>>> >>>>>> *** >>>>>> *** runtime error: >>>>>> *** Segmentation violation - possible attempt to dereference NIL >>>>>> *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/String16.m3 >>>>>> *** >>>>>> >>>>>> -bash-3.00$ ./visobliq >>>>>> Internal Obliq interpreter installed... >>>>>> Establishing 'templates' >>>>>> (Created frame 'templates') >>>>>> let >>>>>> Templates = >>>>>> {boolean=> ... , >>>>>> browser=> ... , >>>>>> button=> ... , >>>>>> choice=> ... , >>>>>> filebrowser=> ... , >>>>>> form=> ... , >>>>>> frame=> ... , >>>>>> hscroll=> ... , >>>>>> menu=> ... , >>>>>> numeric=> ... , >>>>>> text=> ... , >>>>>> textedit=> ... , >>>>>> typein=> ... , >>>>>> video=> ... , >>>>>> vscroll=> ... } >>>>>> Establishing 'vowidgets' >>>>>> (Created frame 'vowidgets') >>>>>> ok >>>>>> Establishing 'vocheckpt' >>>>>> (Created frame 'vocheckpt') >>>>>> ok >>>>>> Establishing 'volib' >>>>>> (Created frame 'volib') >>>>>> Segmentation Fault (core dumped) >>>>>> -bash-3.00$ >>>>>> >>>>>> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Mon Aug 17 13:35:25 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 17 Aug 2009 13:35:25 +0200 Subject: [M3devel] CM3 Release Engineering and Feedback In-Reply-To: <20090816171032.GA27461@topoi.pooq.com> References: <20090813143806.udmpiz76ecg0scgs@mail.elegosoft.com> <20090816171032.GA27461@topoi.pooq.com> Message-ID: <20090817133525.c8kdk3g0o4w4g0ok@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > On Thu, Aug 13, 2009 at 02:38:06PM +0200, Olaf Wagner wrote: >> Quoting hendrik at topoi.pooq.com: >> >> >On Wed, Aug 12, 2009 at 01:10:38AM +0200, Olaf Wagner wrote: >> >> o There hasn't been much feedback, neither from the list of active >> >> developers nor from end users for RC2. I'd really appreciate some >> >> more reports about installation attempts and the problems encountered. >> > >> >Well, I'll provide more with the next RC. The hudson directory was >> >pretty much a show-stopper. I'd expect the same problem to be there on >> >the other platforms. >> >> The simple work-around would be to call cm3 -build on the packages >> again, which should only adapt the broken .M3SHIP files. > > I tried that , but it failed, complaining Yes. Sorry. Those were the bogus collection dependencies. They should now be 'fixed', too (at least much easier to understand). I've invested some hours to compute the depdenencies on package and collection level several times and made some changes to the collection classification in pkginfo.txt. [...] > In any case, this will be an obsolete by the time RC3 starts to roll > out. So focus on that rather than fixing the workaround. If there are no more new unexpected crashes, I'll build the RC3 archives soon. It should be much easier this time. We'll see... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Aug 17 13:35:40 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 17 Aug 2009 11:35:40 +0000 Subject: [M3devel] more crashers In-Reply-To: <20090817133026.6v9cm3cu0wwkc08k@mail.elegosoft.com> References: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> <20090817133026.6v9cm3cu0wwkc08k@mail.elegosoft.com> Message-ID: - I think the whole machine stack mechanism is pretty hopelessly broken. Not just in Modula-3. Therefore my enthusiasm to attempt to "fix" it -- which is impossible -- isn't very high. - I'm hoping to find that no platform other than Solaris lets you even use such a small stack. I have to experiment some in a bit. Depending on that experiment, we'll be in a better position, without any further changes, but again, depending on what I find. That is, if every other platform already had a larger stack, then this just brings Solaris inline with the rest. If the other platforms were actually successfully using a 4K stack, then indeed a problem. - It could also be a factor of optimization. Maybe ensuring -O2 or -O3 is used more would cover it up?? - Or some other changes. That is, if we have drastically increased stack usage, we should try to reduce it back down. But given that 4K was the previous value and even 16K doesn't work...I'm not hopeful we could fit it back down in 4K. It is easy enough to see the bug and then look at the various frames and see if they use a lot of stack and can be reduced. - Jay ---------------------------------------- > Date: Mon, 17 Aug 2009 13:30:26 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] more crashers > > Quoting Jay K : > >> visobliq was stack overflow. >> Raising the default from 4K to 16K didn't fix, but 32K did. > > We need to address this somehow. It cannot be correct if the user > needs to increase the default stack size on one platform by 8 > and not at all on another. Do we have any concept of a 'standard > stack size unit' ;-)? Something that can be easily understood and > implemented and be used instead of the machine words in the current > interfaces? Any ideas? > > Olaf > > >> - Jay >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu >>> CC: m3devel at elegosoft.com >>> Subject: RE: [M3devel] more crashers >>> Date: Sun, 16 Aug 2009 20:32:31 +0000 >>> >>> >>> m3browser: >>> >>> It is specific to my config file >>> m3-sys/cminstall/src/config-no-install/cm3.cfg that reachs back >>> into the source tree. It won't happen with what most people do. I >>> have to do that M3Predefines or such work so that all the uses of >>> m3quake besides cm3 are much more like cm3. >>> >>> >>> visobliq: >>> not the same thing >>> Does not occur on Linux/x86 or Linux/sparc. >>> They do print >>> Syntax error just before: -helvetica-bold-\*R-\*240-\*\") (LabelFo ... >>> ill-formed character escape sequence >>> Error detected (file file generated by Visual Obliq) (line 18, char 10) >>> VideoVBT.Start Jv ServerFailure:errno=0 >>> >>> but then gui comes up. >>> I'll have to finish my Solaris reinstall and get dbx. >>> >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: hosking at cs.purdue.edu >>>> Date: Sun, 16 Aug 2009 20:22:49 +0000 >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] more crashers >>>> >>>> >>>> sorry, this is simple. >>>> >>>> derived_dirs := IntList.List1 (ID.Add (MxConfig.Get("BUILD_DIR"))); >>>> >>>> >>>> - Jay >>>> >>>> >>>> >>>> ---------------------------------------- >>>>> From: jay.krell at cornell.edu >>>>> To: hosking at cs.purdue.edu >>>>> Date: Sun, 16 Aug 2009 19:52:03 +0000 >>>>> CC: m3devel at elegosoft.com >>>>> Subject: Re: [M3devel] more crashers >>>>> >>>>> >>>>> Here is the relevant code in m3browser ID.m3: >>>>> >>>>> >>>>> C:\dev2\cm3.2\m3-tools\m3markup\src\ID.m3(38): empty_id := Add (""); >>>>> >>>>> empty_id := Add (""); >>>>> >>>>> (*-------------------------------------------------------------- >>>>> exported ---*) >>>>> PROCEDURE Add (x: TEXT): T = >>>>> VAR >>>>> t: T; >>>>> a: REF ARRAY OF CHAR; >>>>> l: INTEGER; >>>>> BEGIN >>>>> l := Text.Length(x); >>>>> ... >>>>> END Add; >>>>> >>>>> >>>>> The empty string constant ends up as null. >>>>> >>>>> .stabn 68,0,38,.LM115-.LFBB10 >>>>> .LM115: >>>>> movl L_1 at GOT(%ebx), %eax >>>>> leal 24(%eax), %eax >>>>> movl %eax, (%esp) >>>>> call ID__Add at PLT >>>>> movl %eax, -8(%ebp) >>>>> movl -8(%ebp), %ecx >>>>> movl MM_ID at GOT(%ebx), %edx >>>>> movl 248(%edx), %eax >>>>> andl $0, %eax >>>>> orl %ecx, %eax >>>>> movl %eax, 248(%edx) >>>>> .L136: >>>>> movl MM_ID at GOT(%ebx), %eax >>>>> .LBE16: >>>>> addl $52, %esp >>>>> popl %ebx >>>>> popl %ebp >>>>> ret >>>>> >>>>> L_1: >>>>> 0 .long RTHooks__TextLitInfo >>>>> 4 .long RTHooks__TextLitGetChar >>>>> 8 .long RTHooks__TextLitGetWideChar >>>>> 12 .long RTHooks__TextLitGetChars >>>>> 16 .long RTHooks__TextLitGetWideChars >>>>> 20 .long 2 >>>>> 24 .long L_1 >>>>> .long 0 >>>>> .zero 4 >>>>> .ascii "ID_M3" >>>>> .zero 1 >>>>> .ascii "ExpandHashTable" >>>>> .zero 1 >>>>> .ascii "ExpandIDs" >>>>> .zero 1 >>>>> .ascii "ExpandChars" >>>>> .zero 1 >>>>> .ascii "Compare" >>>>> .zero 1 >>>>> >>>>> If I change "" to "foo", I get: >>>>> >>>>> L_1: >>>>> 0 .long RTHooks__TextLitInfo >>>>> 4 .long RTHooks__TextLitGetChar >>>>> 8 .long RTHooks__TextLitGetWideChar >>>>> 12 .long RTHooks__TextLitGetChars >>>>> 16 .long RTHooks__TextLitGetWideChars >>>>> 20 .long 2 >>>>> 24 .long L_1 >>>>> .long 3 >>>>> .ascii "foo" >>>>> .zero 1 >>>>> .ascii "ID_M3" >>>>> >>>>> and it still crashes. >>>>> >>>>> >>>>> It seems to hit ID__Add twice when only once would be expected. >>>>> >>>>> >>>>> - Jay >>>>> >>>>> >>>>> ---------------------------------------- >>>>>> From: jay.krell at cornell.edu >>>>>> To: hosking at cs.purdue.edu >>>>>> Date: Sun, 16 Aug 2009 19:33:34 +0000 >>>>>> CC: m3devel at elegosoft.com >>>>>> Subject: Re: [M3devel] more crashers >>>>>> >>>>>> >>>>>> Could be. I've also seen it on PPC_DARWIN a while ago. I only >>>>>> recall seeing it on sparc and ppc. >>>>>> It doesn't always occur. >>>>>> >>>>>> >>>>>> Here is the m3browser crash on a system that can be debugged. >>>>>> See why I want the full paths in the debug info? >>>>>> >>>>>> >>>>>> C:\Users\jay\Desktop>\cygwin\bin\ssh xobsd. >>>>>> $ cd /cm3 >>>>>> $ cd bin >>>>>> $ export DISPLAY=192.168.1.120:0.0 >>>>>> $ gdb ./m3browser >>>>>> GNU gdb 6.3 >>>>>> This GDB was configured as "i386-unknown-openbsd4.5"... >>>>>> (gdb) r >>>>>> Starting program: /home/jay/cm3/bin/m3browser >>>>>> Program received signal SIGSEGV, Segmentation fault. >>>>>> [Switching to process 31063, thread 0x7eafe800] >>>>>> 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 >>>>>> 16 t.get_info (i); >>>>>> (gdb) bt >>>>>> #0 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 >>>>>> #1 0x09fd9464 in ID__Add (M3_Bd56fi_x=0x0) at ../src/ID.m3:48 >>>>>> #2 0x1c01e644 in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:37 >>>>>> #3 0x0156f1bc in RTLinker__RunMainBody (M3_DjPxE3_m=0x3c003ec0) >>>>>> at ../src/runtime/common/RTLinker.m3:399 >>>>>> #4 0x0156e576 in RTLinker__AddUnitI (M3_DjPxE3_m=0x3c003ec0) >>>>>> at ../src/runtime/common/RTLinker.m3:113 >>>>>> #5 0x0156e604 in RTLinker__AddUnit (M3_DjPxE5_b=0x1c01e54d) >>>>>> at ../src/runtime/common/RTLinker.m3:122 >>>>>> #6 0x1c004676 in main (argc=1, argv=0xcfbf6a3c, envp=0xcfbf6a44) >>>>>> at _m3main.mc:4 >>>>>> >>>>>> >>>>>> - Jay >>>>>> >>>>>> >>>>>> ________________________________ >>>>>>> From: hosking at cs.purdue.edu >>>>>>> To: jay.krell at cornell.edu >>>>>>> Date: Sun, 16 Aug 2009 15:26:49 -0400 >>>>>>> CC: m3devel at elegosoft.com >>>>>>> Subject: Re: [M3devel] more crashers >>>>>>> >>>>>>> Could this be endianness-related? >>>>>>> >>>>>>> On 16 Aug 2009, at 15:21, Jay K wrote: >>>>>>> >>>>>>> >>>>>>> I see the assertion failure on PPC_LINUX too. >>>>>>> I tried VAR defaultStackSize := 1024 * 1024; (not sure why >>>>>>> there was any suspicion of stack size). >>>>>>> >>>>>>> >>>>>>> Debugging doesn't work PPC_LINUX. >>>>>>> >>>>>>> >>>>>>> jay at plin:/cm3/bin$ gdb ./cm3 >>>>>>> GNU gdb 6.8-debian >>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>> This is free software: you are free to change and redistribute it. >>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>> "show copying" >>>>>>> and "show warranty" for details. >>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>> break ma(gdb) break main >>>>>>> Breakpoint 1 at 0x86fc4: file _m3main.mc, line 2. >>>>>>> (gdb) r >>>>>>> Starting program: /home/jay/cm3/bin/cm3 >>>>>>> Warning: >>>>>>> Cannot insert breakpoint 1. >>>>>>> Error accessing memory address 0x86fc4: Input/output error. >>>>>>> >>>>>>> >>>>>>> No problem with C: >>>>>>> >>>>>>> >>>>>>> jay at plin:/cm3/bin$ echo "main(){}"> 1.c >>>>>>> jay at plin:/cm3/bin$ gcc -g 1.c >>>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>>> GNU gdb 6.8-debian >>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>> This is free software: you are free to change and redistribute it. >>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>> "show copying" >>>>>>> and "show warranty" for details. >>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>> (gdb) break main >>>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>>> (gdb) r >>>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>>> Breakpoint 1, main () at 1.c:1 >>>>>>> 1 main(){} >>>>>>> (gdb) >>>>>>> >>>>>>> >>>>>>> jay at plin:/cm3/bin$ gcc -gstabs+ 1.c >>>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>>> GNU gdb 6.8-debian >>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>> This is free software: you are free to change and redistribute it. >>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>> "show copying" >>>>>>> and "show warranty" for details. >>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>> (gdb) break main >>>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>>> (gdb) r >>>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>>> Breakpoint 1, main () at 1.c:1 >>>>>>> 1 main(){} >>>>>>> >>>>>>> >>>>>>> jay at plin:/cm3/bin$ gcc -gstabs 1.c >>>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>>> GNU gdb 6.8-debian >>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>> This is free software: you are free to change and redistribute it. >>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>> "show copying" >>>>>>> and "show warranty" for details. >>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>> (gdb) break main >>>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>>> (gdb) r >>>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>>> Breakpoint 1, main () at 1.c:1 >>>>>>> 1 main(){} >>>>>>> (gdb) >>>>>>> >>>>>>> >>>>>>> - Jay >>>>>>> >>>>>>> >>>>>>> ---------------------------------------- >>>>>>> From: jay.krell at cornell.edu >>>>>>> To: m3devel at elegosoft.com >>>>>>> Subject: more crashers >>>>>>> Date: Sun, 16 Aug 2009 10:06:15 +0000 >>>>>>> >>>>>>> >>>>>>> This is head on SOLgnu: >>>>>>> I'll try another and debug and see if fix is easy. >>>>>>> >>>>>>> -bash-3.00$ ./m3browser >>>>>>> >>>>>>> *** >>>>>>> *** runtime error: >>>>>>> *** Segmentation violation - possible attempt to dereference NIL >>>>>>> *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/String16.m3 >>>>>>> *** >>>>>>> >>>>>>> -bash-3.00$ ./visobliq >>>>>>> Internal Obliq interpreter installed... >>>>>>> Establishing 'templates' >>>>>>> (Created frame 'templates') >>>>>>> let >>>>>>> Templates = >>>>>>> {boolean=> ... , >>>>>>> browser=> ... , >>>>>>> button=> ... , >>>>>>> choice=> ... , >>>>>>> filebrowser=> ... , >>>>>>> form=> ... , >>>>>>> frame=> ... , >>>>>>> hscroll=> ... , >>>>>>> menu=> ... , >>>>>>> numeric=> ... , >>>>>>> text=> ... , >>>>>>> textedit=> ... , >>>>>>> typein=> ... , >>>>>>> video=> ... , >>>>>>> vscroll=> ... } >>>>>>> Establishing 'vowidgets' >>>>>>> (Created frame 'vowidgets') >>>>>>> ok >>>>>>> Establishing 'vocheckpt' >>>>>>> (Created frame 'vocheckpt') >>>>>>> ok >>>>>>> Establishing 'volib' >>>>>>> (Created frame 'volib') >>>>>>> Segmentation Fault (core dumped) >>>>>>> -bash-3.00$ >>>>>>> >>>>>>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Mon Aug 17 13:37:06 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 17 Aug 2009 11:37:06 +0000 Subject: [M3devel] CM3 Release Engineering and Feedback In-Reply-To: <20090817133525.c8kdk3g0o4w4g0ok@mail.elegosoft.com> References: <20090813143806.udmpiz76ecg0scgs@mail.elegosoft.com> <20090816171032.GA27461@topoi.pooq.com> <20090817133525.c8kdk3g0o4w4g0ok@mail.elegosoft.com> Message-ID: > If there are no more new unexpected crashes I cried wolf by accident. Neither the m3browser nor visobliq crashes were particularly interesting, though somewhat. There is still formsedit though. :( - Jay ---------------------------------------- > Date: Mon, 17 Aug 2009 13:35:25 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] CM3 Release Engineering and Feedback > > Quoting hendrik at topoi.pooq.com: > >> On Thu, Aug 13, 2009 at 02:38:06PM +0200, Olaf Wagner wrote: >>> Quoting hendrik at topoi.pooq.com: >>> >>>>On Wed, Aug 12, 2009 at 01:10:38AM +0200, Olaf Wagner wrote: >>>>> o There hasn't been much feedback, neither from the list of active >>>>> developers nor from end users for RC2. I'd really appreciate some >>>>> more reports about installation attempts and the problems encountered. >>>> >>>>Well, I'll provide more with the next RC. The hudson directory was >>>>pretty much a show-stopper. I'd expect the same problem to be there on >>>>the other platforms. >>> >>> The simple work-around would be to call cm3 -build on the packages >>> again, which should only adapt the broken .M3SHIP files. >> >> I tried that , but it failed, complaining > > Yes. Sorry. Those were the bogus collection dependencies. They should > now be 'fixed', too (at least much easier to understand). I've invested > some hours to compute the depdenencies on package and collection level > several times and made some changes to the collection classification > in pkginfo.txt. > > [...] > >> In any case, this will be an obsolete by the time RC3 starts to roll >> out. So focus on that rather than fixing the workaround. > > If there are no more new unexpected crashes, I'll build the RC3 archives > soon. It should be much easier this time. We'll see... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Mon Aug 17 13:48:30 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 17 Aug 2009 11:48:30 +0000 Subject: [M3devel] i386 vs. i486 vs. i586 vs. i686? Message-ID: At some point I'd like to merge m3cc/src/platforms.quake and m3gdb/src/platforms.quake, and put the result in cm3cfg.common, or even cm3. A small sticking point here is which of [3-6]i86 to use in various places. i386 is pretty darn old (1985?), missing some useful instructions, and I believe not particularly well supported by anyone any longer. Beyond that I'm not sure. I don't think i486 has been available for sale in over 10 years, but maybe in embedded systems?? I believe i686 encompasses Pentium Pro, Pentium II, Pentium III, Pentium IV, Core, Core 2, etc. I think I bought a Pentium in 1995. However I have two machines that I'm not sure are i686. Hm, er, I guess just one machine. I thought the "Pentium M" sticker might imply i586, but there is evidence otherwise: The OpenBSD/i386 Hudson machine: $ sysctl | grep hw hw.machine=i386 hw.model=Intel(R) Pentium(R) M processor 1.70GHz ("GenuineIntel" 686-class) hw.ncpu=1 hw.product=HP Compaq nc4010 (PF672AA#ABA) $ a "Fit PC 2.0", doesn't get much use: jay at xlin ~ $ uname -a Linux xlin 2.6.25-gentoo-r7 #5 Sun Oct 5 18:59:56 Local time zone must be set--s ee zic manua i586 Geode(TM) Integrated Processor by AMD PCS AuthenticAMD GNU/Lin ux jay at xlin ~ $ That really might might not be "i686". I guess, er, um, for m3gdb, there's no point in going past i386? The point is the target really, not the host. gdb is not performance sensitive. gcc is probably always going to be slow, but it can produce faster/slower code. This stuff is only used currently for cross builds, though it might be reasonable to use it for native builds too. Like, you know, if I build on a Core 2, you probably don't want the cm3cg producing code that doesn't work on a Pentium IV or somesuch. - Jay From jay.krell at cornell.edu Mon Aug 17 15:18:43 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 17 Aug 2009 13:18:43 +0000 Subject: [M3devel] more crashers In-Reply-To: <20090817133026.6v9cm3cu0wwkc08k@mail.elegosoft.com> References: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> <20090817133026.6v9cm3cu0wwkc08k@mail.elegosoft.com> Message-ID: Not as much luck as I'd like. PTHREAD_STACK_MIN Solaris: 4K Linux/sparc: 24K Linux/x86: 16K Linux/powerpc: 128K The overflowing stack, with 16K: current thread: t at 12 =>[1] Rd__CharsReady(0xfd61a00c, 0xfd617410, 0xfd59fb6c, 0x0, 0xfd59fb84, 0xfd59 fb8c), at 0xfec58578 ---- 1 following frame from gwindows -- possible stack overflow [2] SynScan__LookChar(0xfd883670, 0xfd8aa81c, 0xfd59fb6c, 0x0, 0xfd59fb84, 0xf d59fb8c), at 0xfead71fc [3] SynScan__NextToken(0xfd883670, 0xfd8ab980, 0x9, 0x0, 0xfd59fb84, 0xfd59fb8 c), at 0xfead91c4 [4] SynScan__LookToken(0xfd883670, 0x4ae, 0x9, 0x0, 0xfd59fb84, 0xfd59fb8c), a t 0xfead9628 [5] SynScan__HaveTokenName(0xfd883670, 0xfd5f7768, 0x8, 0x0, 0xfd59fb84, 0xfd5 9fb8c), at 0xfeadd084 [6] SynParse__Read0(0xfd883654, 0xfd6174ac, 0xfd59fb6c, 0x0, 0xfd59fb84, 0xfd5 9fb8c), at 0xfeae4760 [7] SynParse__Read0(0xfd883654, 0xfd617460, 0xfd59fb6c, 0x0, 0xfd59fb84, 0xfd5 9fb8c), at 0xfeae5e8c hundreds of frames of Lots of SynParse__Read0, using about 1K per frame; there is a try in there. d59fb8c), at 0xfeae348c [666] SynParse__Read0(0xfd883654, 0xfd6172d8, 0xfd59fb6c, 0x0, 0xfd59fb84, 0xf d59fb8c), at 0xfeae5e8c [667] SynParse__Read0(0xfd883654, 0xfd8aaa6c, 0xfd59fb6c, 0x0, 0xfd59fb84, 0xf d59fb8c), at 0xfeae3dd4 [668] SynParse__Read0(0xfd883654, 0xfd617288, 0xfd59fb6c, 0x0, 0xfd59fb84, 0xf d59fb8c), at 0xfeae3168 [669] SynParse__Read0(0xfd883654, 0xfd8aacec, 0xfd59fb6c, 0x0, 0xfd59fb84, 0xf d59fb8c), at 0xfeae6230 [670] SynParse__Read1(0xfd883654, 0xfd8aacec, 0x0, 0xfd59fb84, 0xfd59fb8c, 0x0 ), at 0xfeae2674 [671] SynParse__Read(0xfd883654, 0xfd8aacec, 0x0, 0xfd803a00, 0x0, 0xfebee308) , at 0xfeadfb60 [672] SynParse__ReadNonTerminal(0xfd883654, 0xfefed45c, 0xfd61b250, 0xfd61b8cc , 0xfd61b280, 0xfd89a27c), at 0xfeadfae8 [673] ObliqParser__ParsePhrase(0xfd883654, 0x0, 0xfd61b250, 0xfd61b8cc, 0xfd61 b280, 0x0), at 0xfefd5ff0 [674] ObliqOnline__Interact(0xfd89a848, 0xc32a0, 0xfd61a00c, 0x1, 0x1, 0xfebee 308), at 0xff36b80c [675] ObliqRuntime__ForkedDo(0xfd3ddfb8, 0x9658aac0, 0xff000000, 0x0, 0xfd9100 90, 0x0), at 0x80db0 [676] ThreadPThread__RunThread(0xef2b0, 0x0, 0x0, 0x0, 0xfd803a00, 0x1), at 0x fe06bc88 [677] ThreadPThread__ThreadBase(0xef2b0, 0xfd5a0000, 0x0, 0x0, 0xfe06b7c8, 0x1 ), at 0xfe06b818 One of the problems with defining a unit of stack size is the large variety of jmpbuf size. But heck, why 1K per frame here when SOLsun has a stack walker? Hm. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Subject: RE: [M3devel] more crashers > Date: Mon, 17 Aug 2009 11:35:40 +0000 > > > - I think the whole machine stack mechanism is pretty hopelessly broken. > Not just in Modula-3. Therefore my enthusiasm to attempt to "fix" > it -- which is impossible -- isn't very high. > > - I'm hoping to find that no platform other than Solaris lets you > even use such a small stack. I have to experiment some in a bit. > Depending on that experiment, we'll be in a better position, without > any further changes, but again, depending on what I find. > That is, if every other platform already had a larger stack, then this > just brings Solaris inline with the rest. If the other platforms > were actually successfully using a 4K stack, then indeed a problem. > > > - It could also be a factor of optimization. > Maybe ensuring -O2 or -O3 is used more would cover it up?? > > > - Or some other changes. > That is, if we have drastically increased stack usage, we should try > to reduce it back down. But given that 4K was the previous value > and even 16K doesn't work...I'm not hopeful we could fit it back down in 4K. > > It is easy enough to see the bug and then look at the various frames > and see if they use a lot of stack and can be reduced. > > - Jay > > > > ---------------------------------------- >> Date: Mon, 17 Aug 2009 13:30:26 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] more crashers >> >> Quoting Jay K : >> >>> visobliq was stack overflow. >>> Raising the default from 4K to 16K didn't fix, but 32K did. >> >> We need to address this somehow. It cannot be correct if the user >> needs to increase the default stack size on one platform by 8 >> and not at all on another. Do we have any concept of a 'standard >> stack size unit' ;-)? Something that can be easily understood and >> implemented and be used instead of the machine words in the current >> interfaces? Any ideas? >> >> Olaf >> >> >>> - Jay >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: hosking at cs.purdue.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: RE: [M3devel] more crashers >>>> Date: Sun, 16 Aug 2009 20:32:31 +0000 >>>> >>>> >>>> m3browser: >>>> >>>> It is specific to my config file >>>> m3-sys/cminstall/src/config-no-install/cm3.cfg that reachs back >>>> into the source tree. It won't happen with what most people do. I >>>> have to do that M3Predefines or such work so that all the uses of >>>> m3quake besides cm3 are much more like cm3. >>>> >>>> >>>> visobliq: >>>> not the same thing >>>> Does not occur on Linux/x86 or Linux/sparc. >>>> They do print >>>> Syntax error just before: -helvetica-bold-\*R-\*240-\*\") (LabelFo ... >>>> ill-formed character escape sequence >>>> Error detected (file file generated by Visual Obliq) (line 18, char 10) >>>> VideoVBT.Start Jv ServerFailure:errno=0 >>>> >>>> but then gui comes up. >>>> I'll have to finish my Solaris reinstall and get dbx. >>>> >>>> >>>> - Jay >>>> >>>> >>>> ---------------------------------------- >>>>> From: jay.krell at cornell.edu >>>>> To: hosking at cs.purdue.edu >>>>> Date: Sun, 16 Aug 2009 20:22:49 +0000 >>>>> CC: m3devel at elegosoft.com >>>>> Subject: Re: [M3devel] more crashers >>>>> >>>>> >>>>> sorry, this is simple. >>>>> >>>>> derived_dirs := IntList.List1 (ID.Add (MxConfig.Get("BUILD_DIR"))); >>>>> >>>>> >>>>> - Jay >>>>> >>>>> >>>>> >>>>> ---------------------------------------- >>>>>> From: jay.krell at cornell.edu >>>>>> To: hosking at cs.purdue.edu >>>>>> Date: Sun, 16 Aug 2009 19:52:03 +0000 >>>>>> CC: m3devel at elegosoft.com >>>>>> Subject: Re: [M3devel] more crashers >>>>>> >>>>>> >>>>>> Here is the relevant code in m3browser ID.m3: >>>>>> >>>>>> >>>>>> C:\dev2\cm3.2\m3-tools\m3markup\src\ID.m3(38): empty_id := Add (""); >>>>>> >>>>>> empty_id := Add (""); >>>>>> >>>>>> (*-------------------------------------------------------------- >>>>>> exported ---*) >>>>>> PROCEDURE Add (x: TEXT): T = >>>>>> VAR >>>>>> t: T; >>>>>> a: REF ARRAY OF CHAR; >>>>>> l: INTEGER; >>>>>> BEGIN >>>>>> l := Text.Length(x); >>>>>> ... >>>>>> END Add; >>>>>> >>>>>> >>>>>> The empty string constant ends up as null. >>>>>> >>>>>> .stabn 68,0,38,.LM115-.LFBB10 >>>>>> .LM115: >>>>>> movl L_1 at GOT(%ebx), %eax >>>>>> leal 24(%eax), %eax >>>>>> movl %eax, (%esp) >>>>>> call ID__Add at PLT >>>>>> movl %eax, -8(%ebp) >>>>>> movl -8(%ebp), %ecx >>>>>> movl MM_ID at GOT(%ebx), %edx >>>>>> movl 248(%edx), %eax >>>>>> andl $0, %eax >>>>>> orl %ecx, %eax >>>>>> movl %eax, 248(%edx) >>>>>> .L136: >>>>>> movl MM_ID at GOT(%ebx), %eax >>>>>> .LBE16: >>>>>> addl $52, %esp >>>>>> popl %ebx >>>>>> popl %ebp >>>>>> ret >>>>>> >>>>>> L_1: >>>>>> 0 .long RTHooks__TextLitInfo >>>>>> 4 .long RTHooks__TextLitGetChar >>>>>> 8 .long RTHooks__TextLitGetWideChar >>>>>> 12 .long RTHooks__TextLitGetChars >>>>>> 16 .long RTHooks__TextLitGetWideChars >>>>>> 20 .long 2 >>>>>> 24 .long L_1 >>>>>> .long 0 >>>>>> .zero 4 >>>>>> .ascii "ID_M3" >>>>>> .zero 1 >>>>>> .ascii "ExpandHashTable" >>>>>> .zero 1 >>>>>> .ascii "ExpandIDs" >>>>>> .zero 1 >>>>>> .ascii "ExpandChars" >>>>>> .zero 1 >>>>>> .ascii "Compare" >>>>>> .zero 1 >>>>>> >>>>>> If I change "" to "foo", I get: >>>>>> >>>>>> L_1: >>>>>> 0 .long RTHooks__TextLitInfo >>>>>> 4 .long RTHooks__TextLitGetChar >>>>>> 8 .long RTHooks__TextLitGetWideChar >>>>>> 12 .long RTHooks__TextLitGetChars >>>>>> 16 .long RTHooks__TextLitGetWideChars >>>>>> 20 .long 2 >>>>>> 24 .long L_1 >>>>>> .long 3 >>>>>> .ascii "foo" >>>>>> .zero 1 >>>>>> .ascii "ID_M3" >>>>>> >>>>>> and it still crashes. >>>>>> >>>>>> >>>>>> It seems to hit ID__Add twice when only once would be expected. >>>>>> >>>>>> >>>>>> - Jay >>>>>> >>>>>> >>>>>> ---------------------------------------- >>>>>>> From: jay.krell at cornell.edu >>>>>>> To: hosking at cs.purdue.edu >>>>>>> Date: Sun, 16 Aug 2009 19:33:34 +0000 >>>>>>> CC: m3devel at elegosoft.com >>>>>>> Subject: Re: [M3devel] more crashers >>>>>>> >>>>>>> >>>>>>> Could be. I've also seen it on PPC_DARWIN a while ago. I only >>>>>>> recall seeing it on sparc and ppc. >>>>>>> It doesn't always occur. >>>>>>> >>>>>>> >>>>>>> Here is the m3browser crash on a system that can be debugged. >>>>>>> See why I want the full paths in the debug info? >>>>>>> >>>>>>> >>>>>>> C:\Users\jay\Desktop>\cygwin\bin\ssh xobsd. >>>>>>> $ cd /cm3 >>>>>>> $ cd bin >>>>>>> $ export DISPLAY=192.168.1.120:0.0 >>>>>>> $ gdb ./m3browser >>>>>>> GNU gdb 6.3 >>>>>>> This GDB was configured as "i386-unknown-openbsd4.5"... >>>>>>> (gdb) r >>>>>>> Starting program: /home/jay/cm3/bin/m3browser >>>>>>> Program received signal SIGSEGV, Segmentation fault. >>>>>>> [Switching to process 31063, thread 0x7eafe800] >>>>>>> 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 >>>>>>> 16 t.get_info (i); >>>>>>> (gdb) bt >>>>>>> #0 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/Text.m3:16 >>>>>>> #1 0x09fd9464 in ID__Add (M3_Bd56fi_x=0x0) at ../src/ID.m3:48 >>>>>>> #2 0x1c01e644 in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:37 >>>>>>> #3 0x0156f1bc in RTLinker__RunMainBody (M3_DjPxE3_m=0x3c003ec0) >>>>>>> at ../src/runtime/common/RTLinker.m3:399 >>>>>>> #4 0x0156e576 in RTLinker__AddUnitI (M3_DjPxE3_m=0x3c003ec0) >>>>>>> at ../src/runtime/common/RTLinker.m3:113 >>>>>>> #5 0x0156e604 in RTLinker__AddUnit (M3_DjPxE5_b=0x1c01e54d) >>>>>>> at ../src/runtime/common/RTLinker.m3:122 >>>>>>> #6 0x1c004676 in main (argc=1, argv=0xcfbf6a3c, envp=0xcfbf6a44) >>>>>>> at _m3main.mc:4 >>>>>>> >>>>>>> >>>>>>> - Jay >>>>>>> >>>>>>> >>>>>>> ________________________________ >>>>>>>> From: hosking at cs.purdue.edu >>>>>>>> To: jay.krell at cornell.edu >>>>>>>> Date: Sun, 16 Aug 2009 15:26:49 -0400 >>>>>>>> CC: m3devel at elegosoft.com >>>>>>>> Subject: Re: [M3devel] more crashers >>>>>>>> >>>>>>>> Could this be endianness-related? >>>>>>>> >>>>>>>> On 16 Aug 2009, at 15:21, Jay K wrote: >>>>>>>> >>>>>>>> >>>>>>>> I see the assertion failure on PPC_LINUX too. >>>>>>>> I tried VAR defaultStackSize := 1024 * 1024; (not sure why >>>>>>>> there was any suspicion of stack size). >>>>>>>> >>>>>>>> >>>>>>>> Debugging doesn't work PPC_LINUX. >>>>>>>> >>>>>>>> >>>>>>>> jay at plin:/cm3/bin$ gdb ./cm3 >>>>>>>> GNU gdb 6.8-debian >>>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>> This is free software: you are free to change and redistribute it. >>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>> "show copying" >>>>>>>> and "show warranty" for details. >>>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>>> break ma(gdb) break main >>>>>>>> Breakpoint 1 at 0x86fc4: file _m3main.mc, line 2. >>>>>>>> (gdb) r >>>>>>>> Starting program: /home/jay/cm3/bin/cm3 >>>>>>>> Warning: >>>>>>>> Cannot insert breakpoint 1. >>>>>>>> Error accessing memory address 0x86fc4: Input/output error. >>>>>>>> >>>>>>>> >>>>>>>> No problem with C: >>>>>>>> >>>>>>>> >>>>>>>> jay at plin:/cm3/bin$ echo "main(){}"> 1.c >>>>>>>> jay at plin:/cm3/bin$ gcc -g 1.c >>>>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>>>> GNU gdb 6.8-debian >>>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>> This is free software: you are free to change and redistribute it. >>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>> "show copying" >>>>>>>> and "show warranty" for details. >>>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>>> (gdb) break main >>>>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>>>> (gdb) r >>>>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>>>> Breakpoint 1, main () at 1.c:1 >>>>>>>> 1 main(){} >>>>>>>> (gdb) >>>>>>>> >>>>>>>> >>>>>>>> jay at plin:/cm3/bin$ gcc -gstabs+ 1.c >>>>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>>>> GNU gdb 6.8-debian >>>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>> This is free software: you are free to change and redistribute it. >>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>> "show copying" >>>>>>>> and "show warranty" for details. >>>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>>> (gdb) break main >>>>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>>>> (gdb) r >>>>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>>>> Breakpoint 1, main () at 1.c:1 >>>>>>>> 1 main(){} >>>>>>>> >>>>>>>> >>>>>>>> jay at plin:/cm3/bin$ gcc -gstabs 1.c >>>>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>>>> GNU gdb 6.8-debian >>>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>> This is free software: you are free to change and redistribute it. >>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>> "show copying" >>>>>>>> and "show warranty" for details. >>>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>>> (gdb) break main >>>>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>>>> (gdb) r >>>>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>>>> Breakpoint 1, main () at 1.c:1 >>>>>>>> 1 main(){} >>>>>>>> (gdb) >>>>>>>> >>>>>>>> >>>>>>>> - Jay >>>>>>>> >>>>>>>> >>>>>>>> ---------------------------------------- >>>>>>>> From: jay.krell at cornell.edu >>>>>>>> To: m3devel at elegosoft.com >>>>>>>> Subject: more crashers >>>>>>>> Date: Sun, 16 Aug 2009 10:06:15 +0000 >>>>>>>> >>>>>>>> >>>>>>>> This is head on SOLgnu: >>>>>>>> I'll try another and debug and see if fix is easy. >>>>>>>> >>>>>>>> -bash-3.00$ ./m3browser >>>>>>>> >>>>>>>> *** >>>>>>>> *** runtime error: >>>>>>>> *** Segmentation violation - possible attempt to dereference NIL >>>>>>>> *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/String16.m3 >>>>>>>> *** >>>>>>>> >>>>>>>> -bash-3.00$ ./visobliq >>>>>>>> Internal Obliq interpreter installed... >>>>>>>> Establishing 'templates' >>>>>>>> (Created frame 'templates') >>>>>>>> let >>>>>>>> Templates = >>>>>>>> {boolean=> ... , >>>>>>>> browser=> ... , >>>>>>>> button=> ... , >>>>>>>> choice=> ... , >>>>>>>> filebrowser=> ... , >>>>>>>> form=> ... , >>>>>>>> frame=> ... , >>>>>>>> hscroll=> ... , >>>>>>>> menu=> ... , >>>>>>>> numeric=> ... , >>>>>>>> text=> ... , >>>>>>>> textedit=> ... , >>>>>>>> typein=> ... , >>>>>>>> video=> ... , >>>>>>>> vscroll=> ... } >>>>>>>> Establishing 'vowidgets' >>>>>>>> (Created frame 'vowidgets') >>>>>>>> ok >>>>>>>> Establishing 'vocheckpt' >>>>>>>> (Created frame 'vocheckpt') >>>>>>>> ok >>>>>>>> Establishing 'volib' >>>>>>>> (Created frame 'volib') >>>>>>>> Segmentation Fault (core dumped) >>>>>>>> -bash-3.00$ >>>>>>>> >>>>>>>> >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> From hosking at cs.purdue.edu Mon Aug 17 16:47:46 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 17 Aug 2009 10:47:46 -0400 Subject: [M3devel] more crashers In-Reply-To: References: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> <20090817133026.6v9cm3cu0wwkc08k@mail.elegosoft.com> Message-ID: Indeed, we might be better off investing effort in getting rid of try- blocks implemented using setjmp/longjmp so as to avoid the stack- allocated jmpbuf state. Or perhaps allocate that state in the heap. On 17 Aug 2009, at 09:18, Jay K wrote: > > Not as much luck as I'd like. > > > PTHREAD_STACK_MIN > Solaris: 4K > Linux/sparc: 24K > Linux/x86: 16K > Linux/powerpc: 128K > > > The overflowing stack, with 16K: > > > current thread: t at 12 > =>[1] Rd__CharsReady(0xfd61a00c, 0xfd617410, 0xfd59fb6c, 0x0, > 0xfd59fb84, 0xfd59 > fb8c), at 0xfec58578 > ---- 1 following frame from gwindows -- possible stack overflow > [2] SynScan__LookChar(0xfd883670, 0xfd8aa81c, 0xfd59fb6c, 0x0, > 0xfd59fb84, 0xf > d59fb8c), at 0xfead71fc > [3] SynScan__NextToken(0xfd883670, 0xfd8ab980, 0x9, 0x0, > 0xfd59fb84, 0xfd59fb8 > c), at 0xfead91c4 > [4] SynScan__LookToken(0xfd883670, 0x4ae, 0x9, 0x0, 0xfd59fb84, > 0xfd59fb8c), a > t 0xfead9628 > [5] SynScan__HaveTokenName(0xfd883670, 0xfd5f7768, 0x8, 0x0, > 0xfd59fb84, 0xfd5 > 9fb8c), at 0xfeadd084 > [6] SynParse__Read0(0xfd883654, 0xfd6174ac, 0xfd59fb6c, 0x0, > 0xfd59fb84, 0xfd5 > 9fb8c), at 0xfeae4760 > [7] SynParse__Read0(0xfd883654, 0xfd617460, 0xfd59fb6c, 0x0, > 0xfd59fb84, 0xfd5 > 9fb8c), at 0xfeae5e8c > > > hundreds of frames of Lots of SynParse__Read0, using about 1K per > frame; there is a try in there. > > d59fb8c), at 0xfeae348c > [666] SynParse__Read0(0xfd883654, 0xfd6172d8, 0xfd59fb6c, 0x0, > 0xfd59fb84, 0xf > d59fb8c), at 0xfeae5e8c > [667] SynParse__Read0(0xfd883654, 0xfd8aaa6c, 0xfd59fb6c, 0x0, > 0xfd59fb84, 0xf > d59fb8c), at 0xfeae3dd4 > [668] SynParse__Read0(0xfd883654, 0xfd617288, 0xfd59fb6c, 0x0, > 0xfd59fb84, 0xf > d59fb8c), at 0xfeae3168 > [669] SynParse__Read0(0xfd883654, 0xfd8aacec, 0xfd59fb6c, 0x0, > 0xfd59fb84, 0xf > d59fb8c), at 0xfeae6230 > [670] SynParse__Read1(0xfd883654, 0xfd8aacec, 0x0, 0xfd59fb84, > 0xfd59fb8c, 0x0 > ), at 0xfeae2674 > [671] SynParse__Read(0xfd883654, 0xfd8aacec, 0x0, 0xfd803a00, 0x0, > 0xfebee308) > , at 0xfeadfb60 > [672] SynParse__ReadNonTerminal(0xfd883654, 0xfefed45c, 0xfd61b250, > 0xfd61b8cc > , 0xfd61b280, 0xfd89a27c), at 0xfeadfae8 > [673] ObliqParser__ParsePhrase(0xfd883654, 0x0, 0xfd61b250, > 0xfd61b8cc, 0xfd61 > b280, 0x0), at 0xfefd5ff0 > [674] ObliqOnline__Interact(0xfd89a848, 0xc32a0, 0xfd61a00c, 0x1, > 0x1, 0xfebee > 308), at 0xff36b80c > [675] ObliqRuntime__ForkedDo(0xfd3ddfb8, 0x9658aac0, 0xff000000, > 0x0, 0xfd9100 > 90, 0x0), at 0x80db0 > [676] ThreadPThread__RunThread(0xef2b0, 0x0, 0x0, 0x0, 0xfd803a00, > 0x1), at 0x > fe06bc88 > [677] ThreadPThread__ThreadBase(0xef2b0, 0xfd5a0000, 0x0, 0x0, > 0xfe06b7c8, 0x1 > ), at 0xfe06b818 > > > One of the problems with defining a unit of stack size is the large > variety of jmpbuf size. > But heck, why 1K per frame here when SOLsun has a stack walker? Hm. > > - Jay > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com; m3devel at elegosoft.com >> Subject: RE: [M3devel] more crashers >> Date: Mon, 17 Aug 2009 11:35:40 +0000 >> >> >> - I think the whole machine stack mechanism is pretty hopelessly >> broken. >> Not just in Modula-3. Therefore my enthusiasm to attempt to "fix" >> it -- which is impossible -- isn't very high. >> >> - I'm hoping to find that no platform other than Solaris lets you >> even use such a small stack. I have to experiment some in a bit. >> Depending on that experiment, we'll be in a better position, without >> any further changes, but again, depending on what I find. >> That is, if every other platform already had a larger stack, then >> this >> just brings Solaris inline with the rest. If the other platforms >> were actually successfully using a 4K stack, then indeed a problem. >> >> >> - It could also be a factor of optimization. >> Maybe ensuring -O2 or -O3 is used more would cover it up?? >> >> >> - Or some other changes. >> That is, if we have drastically increased stack usage, we should try >> to reduce it back down. But given that 4K was the previous value >> and even 16K doesn't work...I'm not hopeful we could fit it back >> down in 4K. >> >> It is easy enough to see the bug and then look at the various frames >> and see if they use a lot of stack and can be reduced. >> >> - Jay >> >> >> >> ---------------------------------------- >>> Date: Mon, 17 Aug 2009 13:30:26 +0200 >>> From: wagner at elegosoft.com >>> To: m3devel at elegosoft.com >>> Subject: Re: [M3devel] more crashers >>> >>> Quoting Jay K : >>> >>>> visobliq was stack overflow. >>>> Raising the default from 4K to 16K didn't fix, but 32K did. >>> >>> We need to address this somehow. It cannot be correct if the user >>> needs to increase the default stack size on one platform by 8 >>> and not at all on another. Do we have any concept of a 'standard >>> stack size unit' ;-)? Something that can be easily understood and >>> implemented and be used instead of the machine words in the current >>> interfaces? Any ideas? >>> >>> Olaf >>> >>> >>>> - Jay >>>> >>>> ---------------------------------------- >>>>> From: jay.krell at cornell.edu >>>>> To: hosking at cs.purdue.edu >>>>> CC: m3devel at elegosoft.com >>>>> Subject: RE: [M3devel] more crashers >>>>> Date: Sun, 16 Aug 2009 20:32:31 +0000 >>>>> >>>>> >>>>> m3browser: >>>>> >>>>> It is specific to my config file >>>>> m3-sys/cminstall/src/config-no-install/cm3.cfg that reachs back >>>>> into the source tree. It won't happen with what most people do. I >>>>> have to do that M3Predefines or such work so that all the uses of >>>>> m3quake besides cm3 are much more like cm3. >>>>> >>>>> >>>>> visobliq: >>>>> not the same thing >>>>> Does not occur on Linux/x86 or Linux/sparc. >>>>> They do print >>>>> Syntax error just before: -helvetica-bold-\*R-\*240-\*\") >>>>> (LabelFo ... >>>>> ill-formed character escape sequence >>>>> Error detected (file file generated by Visual Obliq) (line 18, >>>>> char 10) >>>>> VideoVBT.Start Jv ServerFailure:errno=0 >>>>> >>>>> but then gui comes up. >>>>> I'll have to finish my Solaris reinstall and get dbx. >>>>> >>>>> >>>>> - Jay >>>>> >>>>> >>>>> ---------------------------------------- >>>>>> From: jay.krell at cornell.edu >>>>>> To: hosking at cs.purdue.edu >>>>>> Date: Sun, 16 Aug 2009 20:22:49 +0000 >>>>>> CC: m3devel at elegosoft.com >>>>>> Subject: Re: [M3devel] more crashers >>>>>> >>>>>> >>>>>> sorry, this is simple. >>>>>> >>>>>> derived_dirs := IntList.List1 (ID.Add >>>>>> (MxConfig.Get("BUILD_DIR"))); >>>>>> >>>>>> >>>>>> - Jay >>>>>> >>>>>> >>>>>> >>>>>> ---------------------------------------- >>>>>>> From: jay.krell at cornell.edu >>>>>>> To: hosking at cs.purdue.edu >>>>>>> Date: Sun, 16 Aug 2009 19:52:03 +0000 >>>>>>> CC: m3devel at elegosoft.com >>>>>>> Subject: Re: [M3devel] more crashers >>>>>>> >>>>>>> >>>>>>> Here is the relevant code in m3browser ID.m3: >>>>>>> >>>>>>> >>>>>>> C:\dev2\cm3.2\m3-tools\m3markup\src\ID.m3(38): empty_id := Add >>>>>>> (""); >>>>>>> >>>>>>> empty_id := Add (""); >>>>>>> >>>>>>> (*-------------------------------------------------------------- >>>>>>> exported ---*) >>>>>>> PROCEDURE Add (x: TEXT): T = >>>>>>> VAR >>>>>>> t: T; >>>>>>> a: REF ARRAY OF CHAR; >>>>>>> l: INTEGER; >>>>>>> BEGIN >>>>>>> l := Text.Length(x); >>>>>>> ... >>>>>>> END Add; >>>>>>> >>>>>>> >>>>>>> The empty string constant ends up as null. >>>>>>> >>>>>>> .stabn 68,0,38,.LM115-.LFBB10 >>>>>>> .LM115: >>>>>>> movl L_1 at GOT(%ebx), %eax >>>>>>> leal 24(%eax), %eax >>>>>>> movl %eax, (%esp) >>>>>>> call ID__Add at PLT >>>>>>> movl %eax, -8(%ebp) >>>>>>> movl -8(%ebp), %ecx >>>>>>> movl MM_ID at GOT(%ebx), %edx >>>>>>> movl 248(%edx), %eax >>>>>>> andl $0, %eax >>>>>>> orl %ecx, %eax >>>>>>> movl %eax, 248(%edx) >>>>>>> .L136: >>>>>>> movl MM_ID at GOT(%ebx), %eax >>>>>>> .LBE16: >>>>>>> addl $52, %esp >>>>>>> popl %ebx >>>>>>> popl %ebp >>>>>>> ret >>>>>>> >>>>>>> L_1: >>>>>>> 0 .long RTHooks__TextLitInfo >>>>>>> 4 .long RTHooks__TextLitGetChar >>>>>>> 8 .long RTHooks__TextLitGetWideChar >>>>>>> 12 .long RTHooks__TextLitGetChars >>>>>>> 16 .long RTHooks__TextLitGetWideChars >>>>>>> 20 .long 2 >>>>>>> 24 .long L_1 >>>>>>> .long 0 >>>>>>> .zero 4 >>>>>>> .ascii "ID_M3" >>>>>>> .zero 1 >>>>>>> .ascii "ExpandHashTable" >>>>>>> .zero 1 >>>>>>> .ascii "ExpandIDs" >>>>>>> .zero 1 >>>>>>> .ascii "ExpandChars" >>>>>>> .zero 1 >>>>>>> .ascii "Compare" >>>>>>> .zero 1 >>>>>>> >>>>>>> If I change "" to "foo", I get: >>>>>>> >>>>>>> L_1: >>>>>>> 0 .long RTHooks__TextLitInfo >>>>>>> 4 .long RTHooks__TextLitGetChar >>>>>>> 8 .long RTHooks__TextLitGetWideChar >>>>>>> 12 .long RTHooks__TextLitGetChars >>>>>>> 16 .long RTHooks__TextLitGetWideChars >>>>>>> 20 .long 2 >>>>>>> 24 .long L_1 >>>>>>> .long 3 >>>>>>> .ascii "foo" >>>>>>> .zero 1 >>>>>>> .ascii "ID_M3" >>>>>>> >>>>>>> and it still crashes. >>>>>>> >>>>>>> >>>>>>> It seems to hit ID__Add twice when only once would be expected. >>>>>>> >>>>>>> >>>>>>> - Jay >>>>>>> >>>>>>> >>>>>>> ---------------------------------------- >>>>>>>> From: jay.krell at cornell.edu >>>>>>>> To: hosking at cs.purdue.edu >>>>>>>> Date: Sun, 16 Aug 2009 19:33:34 +0000 >>>>>>>> CC: m3devel at elegosoft.com >>>>>>>> Subject: Re: [M3devel] more crashers >>>>>>>> >>>>>>>> >>>>>>>> Could be. I've also seen it on PPC_DARWIN a while ago. I only >>>>>>>> recall seeing it on sparc and ppc. >>>>>>>> It doesn't always occur. >>>>>>>> >>>>>>>> >>>>>>>> Here is the m3browser crash on a system that can be debugged. >>>>>>>> See why I want the full paths in the debug info? >>>>>>>> >>>>>>>> >>>>>>>> C:\Users\jay\Desktop>\cygwin\bin\ssh xobsd. >>>>>>>> $ cd /cm3 >>>>>>>> $ cd bin >>>>>>>> $ export DISPLAY=192.168.1.120:0.0 >>>>>>>> $ gdb ./m3browser >>>>>>>> GNU gdb 6.3 >>>>>>>> This GDB was configured as "i386-unknown-openbsd4.5"... >>>>>>>> (gdb) r >>>>>>>> Starting program: /home/jay/cm3/bin/m3browser >>>>>>>> Program received signal SIGSEGV, Segmentation fault. >>>>>>>> [Switching to process 31063, thread 0x7eafe800] >>>>>>>> 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/ >>>>>>>> Text.m3:16 >>>>>>>> 16 t.get_info (i); >>>>>>>> (gdb) bt >>>>>>>> #0 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/ >>>>>>>> text/Text.m3:16 >>>>>>>> #1 0x09fd9464 in ID__Add (M3_Bd56fi_x=0x0) at ../src/ID.m3:48 >>>>>>>> #2 0x1c01e644 in Main_M3 (M3_AcxOUs_mode=1) at ../src/ >>>>>>>> Main.m3:37 >>>>>>>> #3 0x0156f1bc in RTLinker__RunMainBody (M3_DjPxE3_m=0x3c003ec0) >>>>>>>> at ../src/runtime/common/RTLinker.m3:399 >>>>>>>> #4 0x0156e576 in RTLinker__AddUnitI (M3_DjPxE3_m=0x3c003ec0) >>>>>>>> at ../src/runtime/common/RTLinker.m3:113 >>>>>>>> #5 0x0156e604 in RTLinker__AddUnit (M3_DjPxE5_b=0x1c01e54d) >>>>>>>> at ../src/runtime/common/RTLinker.m3:122 >>>>>>>> #6 0x1c004676 in main (argc=1, argv=0xcfbf6a3c, >>>>>>>> envp=0xcfbf6a44) >>>>>>>> at _m3main.mc:4 >>>>>>>> >>>>>>>> >>>>>>>> - Jay >>>>>>>> >>>>>>>> >>>>>>>> ________________________________ >>>>>>>>> From: hosking at cs.purdue.edu >>>>>>>>> To: jay.krell at cornell.edu >>>>>>>>> Date: Sun, 16 Aug 2009 15:26:49 -0400 >>>>>>>>> CC: m3devel at elegosoft.com >>>>>>>>> Subject: Re: [M3devel] more crashers >>>>>>>>> >>>>>>>>> Could this be endianness-related? >>>>>>>>> >>>>>>>>> On 16 Aug 2009, at 15:21, Jay K wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> I see the assertion failure on PPC_LINUX too. >>>>>>>>> I tried VAR defaultStackSize := 1024 * 1024; (not sure why >>>>>>>>> there was any suspicion of stack size). >>>>>>>>> >>>>>>>>> >>>>>>>>> Debugging doesn't work PPC_LINUX. >>>>>>>>> >>>>>>>>> >>>>>>>>> jay at plin:/cm3/bin$ gdb ./cm3 >>>>>>>>> GNU gdb 6.8-debian >>>>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>>> This is free software: you are free to change and >>>>>>>>> redistribute it. >>>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>>> "show copying" >>>>>>>>> and "show warranty" for details. >>>>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>>>> break ma(gdb) break main >>>>>>>>> Breakpoint 1 at 0x86fc4: file _m3main.mc, line 2. >>>>>>>>> (gdb) r >>>>>>>>> Starting program: /home/jay/cm3/bin/cm3 >>>>>>>>> Warning: >>>>>>>>> Cannot insert breakpoint 1. >>>>>>>>> Error accessing memory address 0x86fc4: Input/output error. >>>>>>>>> >>>>>>>>> >>>>>>>>> No problem with C: >>>>>>>>> >>>>>>>>> >>>>>>>>> jay at plin:/cm3/bin$ echo "main(){}"> 1.c >>>>>>>>> jay at plin:/cm3/bin$ gcc -g 1.c >>>>>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>>>>> GNU gdb 6.8-debian >>>>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>>> This is free software: you are free to change and >>>>>>>>> redistribute it. >>>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>>> "show copying" >>>>>>>>> and "show warranty" for details. >>>>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>>>> (gdb) break main >>>>>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>>>>> (gdb) r >>>>>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>>>>> Breakpoint 1, main () at 1.c:1 >>>>>>>>> 1 main(){} >>>>>>>>> (gdb) >>>>>>>>> >>>>>>>>> >>>>>>>>> jay at plin:/cm3/bin$ gcc -gstabs+ 1.c >>>>>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>>>>> GNU gdb 6.8-debian >>>>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>>> This is free software: you are free to change and >>>>>>>>> redistribute it. >>>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>>> "show copying" >>>>>>>>> and "show warranty" for details. >>>>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>>>> (gdb) break main >>>>>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>>>>> (gdb) r >>>>>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>>>>> Breakpoint 1, main () at 1.c:1 >>>>>>>>> 1 main(){} >>>>>>>>> >>>>>>>>> >>>>>>>>> jay at plin:/cm3/bin$ gcc -gstabs 1.c >>>>>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>>>>> GNU gdb 6.8-debian >>>>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>>> This is free software: you are free to change and >>>>>>>>> redistribute it. >>>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>>> "show copying" >>>>>>>>> and "show warranty" for details. >>>>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>>>> (gdb) break main >>>>>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>>>>> (gdb) r >>>>>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>>>>> Breakpoint 1, main () at 1.c:1 >>>>>>>>> 1 main(){} >>>>>>>>> (gdb) >>>>>>>>> >>>>>>>>> >>>>>>>>> - Jay >>>>>>>>> >>>>>>>>> >>>>>>>>> ---------------------------------------- >>>>>>>>> From: jay.krell at cornell.edu >>>>>>>>> To: m3devel at elegosoft.com >>>>>>>>> Subject: more crashers >>>>>>>>> Date: Sun, 16 Aug 2009 10:06:15 +0000 >>>>>>>>> >>>>>>>>> >>>>>>>>> This is head on SOLgnu: >>>>>>>>> I'll try another and debug and see if fix is easy. >>>>>>>>> >>>>>>>>> -bash-3.00$ ./m3browser >>>>>>>>> >>>>>>>>> *** >>>>>>>>> *** runtime error: >>>>>>>>> *** Segmentation violation - possible attempt to dereference >>>>>>>>> NIL >>>>>>>>> *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/ >>>>>>>>> String16.m3 >>>>>>>>> *** >>>>>>>>> >>>>>>>>> -bash-3.00$ ./visobliq >>>>>>>>> Internal Obliq interpreter installed... >>>>>>>>> Establishing 'templates' >>>>>>>>> (Created frame 'templates') >>>>>>>>> let >>>>>>>>> Templates = >>>>>>>>> {boolean=> ... , >>>>>>>>> browser=> ... , >>>>>>>>> button=> ... , >>>>>>>>> choice=> ... , >>>>>>>>> filebrowser=> ... , >>>>>>>>> form=> ... , >>>>>>>>> frame=> ... , >>>>>>>>> hscroll=> ... , >>>>>>>>> menu=> ... , >>>>>>>>> numeric=> ... , >>>>>>>>> text=> ... , >>>>>>>>> textedit=> ... , >>>>>>>>> typein=> ... , >>>>>>>>> video=> ... , >>>>>>>>> vscroll=> ... } >>>>>>>>> Establishing 'vowidgets' >>>>>>>>> (Created frame 'vowidgets') >>>>>>>>> ok >>>>>>>>> Establishing 'vocheckpt' >>>>>>>>> (Created frame 'vocheckpt') >>>>>>>>> ok >>>>>>>>> Establishing 'volib' >>>>>>>>> (Created frame 'volib') >>>>>>>>> Segmentation Fault (core dumped) >>>>>>>>> -bash-3.00$ >>>>>>>>> >>>>>>>>> >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>> 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>> Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Aug 17 17:13:29 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 17 Aug 2009 17:13:29 +0200 Subject: [M3devel] more crashers In-Reply-To: References: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> <20090817133026.6v9cm3cu0wwkc08k@mail.elegosoft.com> Message-ID: <20090817171329.dsbfoh9s04k0o84w@mail.elegosoft.com> Quoting Tony Hosking : > Indeed, we might be better off investing effort in getting rid of try- > blocks implemented using setjmp/longjmp so as to avoid the stack- > allocated jmpbuf state. Or perhaps allocate that state in the heap. Is this a feature for 5.9 then? ;-) Olaf > On 17 Aug 2009, at 09:18, Jay K wrote: > >> >> Not as much luck as I'd like. >> >> >> PTHREAD_STACK_MIN >> Solaris: 4K >> Linux/sparc: 24K >> Linux/x86: 16K >> Linux/powerpc: 128K >> >> >> The overflowing stack, with 16K: >> >> >> current thread: t at 12 >> =>[1] Rd__CharsReady(0xfd61a00c, 0xfd617410, 0xfd59fb6c, 0x0, >> 0xfd59fb84, 0xfd59 >> fb8c), at 0xfec58578 >> ---- 1 following frame from gwindows -- possible stack overflow >> [2] SynScan__LookChar(0xfd883670, 0xfd8aa81c, 0xfd59fb6c, 0x0, >> 0xfd59fb84, 0xf >> d59fb8c), at 0xfead71fc >> [3] SynScan__NextToken(0xfd883670, 0xfd8ab980, 0x9, 0x0, >> 0xfd59fb84, 0xfd59fb8 >> c), at 0xfead91c4 >> [4] SynScan__LookToken(0xfd883670, 0x4ae, 0x9, 0x0, 0xfd59fb84, >> 0xfd59fb8c), a >> t 0xfead9628 >> [5] SynScan__HaveTokenName(0xfd883670, 0xfd5f7768, 0x8, 0x0, >> 0xfd59fb84, 0xfd5 >> 9fb8c), at 0xfeadd084 >> [6] SynParse__Read0(0xfd883654, 0xfd6174ac, 0xfd59fb6c, 0x0, >> 0xfd59fb84, 0xfd5 >> 9fb8c), at 0xfeae4760 >> [7] SynParse__Read0(0xfd883654, 0xfd617460, 0xfd59fb6c, 0x0, >> 0xfd59fb84, 0xfd5 >> 9fb8c), at 0xfeae5e8c >> >> >> hundreds of frames of Lots of SynParse__Read0, using about 1K per >> frame; there is a try in there. >> >> d59fb8c), at 0xfeae348c >> [666] SynParse__Read0(0xfd883654, 0xfd6172d8, 0xfd59fb6c, 0x0, >> 0xfd59fb84, 0xf >> d59fb8c), at 0xfeae5e8c >> [667] SynParse__Read0(0xfd883654, 0xfd8aaa6c, 0xfd59fb6c, 0x0, >> 0xfd59fb84, 0xf >> d59fb8c), at 0xfeae3dd4 >> [668] SynParse__Read0(0xfd883654, 0xfd617288, 0xfd59fb6c, 0x0, >> 0xfd59fb84, 0xf >> d59fb8c), at 0xfeae3168 >> [669] SynParse__Read0(0xfd883654, 0xfd8aacec, 0xfd59fb6c, 0x0, >> 0xfd59fb84, 0xf >> d59fb8c), at 0xfeae6230 >> [670] SynParse__Read1(0xfd883654, 0xfd8aacec, 0x0, 0xfd59fb84, >> 0xfd59fb8c, 0x0 >> ), at 0xfeae2674 >> [671] SynParse__Read(0xfd883654, 0xfd8aacec, 0x0, 0xfd803a00, 0x0, >> 0xfebee308) >> , at 0xfeadfb60 >> [672] SynParse__ReadNonTerminal(0xfd883654, 0xfefed45c, 0xfd61b250, >> 0xfd61b8cc >> , 0xfd61b280, 0xfd89a27c), at 0xfeadfae8 >> [673] ObliqParser__ParsePhrase(0xfd883654, 0x0, 0xfd61b250, >> 0xfd61b8cc, 0xfd61 >> b280, 0x0), at 0xfefd5ff0 >> [674] ObliqOnline__Interact(0xfd89a848, 0xc32a0, 0xfd61a00c, 0x1, >> 0x1, 0xfebee >> 308), at 0xff36b80c >> [675] ObliqRuntime__ForkedDo(0xfd3ddfb8, 0x9658aac0, 0xff000000, >> 0x0, 0xfd9100 >> 90, 0x0), at 0x80db0 >> [676] ThreadPThread__RunThread(0xef2b0, 0x0, 0x0, 0x0, 0xfd803a00, >> 0x1), at 0x >> fe06bc88 >> [677] ThreadPThread__ThreadBase(0xef2b0, 0xfd5a0000, 0x0, 0x0, >> 0xfe06b7c8, 0x1 >> ), at 0xfe06b818 >> >> >> One of the problems with defining a unit of stack size is the large >> variety of jmpbuf size. >> But heck, why 1K per frame here when SOLsun has a stack walker? Hm. >> >> - Jay >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: wagner at elegosoft.com; m3devel at elegosoft.com >>> Subject: RE: [M3devel] more crashers >>> Date: Mon, 17 Aug 2009 11:35:40 +0000 >>> >>> >>> - I think the whole machine stack mechanism is pretty hopelessly broken. >>> Not just in Modula-3. Therefore my enthusiasm to attempt to "fix" >>> it -- which is impossible -- isn't very high. >>> >>> - I'm hoping to find that no platform other than Solaris lets you >>> even use such a small stack. I have to experiment some in a bit. >>> Depending on that experiment, we'll be in a better position, without >>> any further changes, but again, depending on what I find. >>> That is, if every other platform already had a larger stack, then this >>> just brings Solaris inline with the rest. If the other platforms >>> were actually successfully using a 4K stack, then indeed a problem. >>> >>> >>> - It could also be a factor of optimization. >>> Maybe ensuring -O2 or -O3 is used more would cover it up?? >>> >>> >>> - Or some other changes. >>> That is, if we have drastically increased stack usage, we should try >>> to reduce it back down. But given that 4K was the previous value >>> and even 16K doesn't work...I'm not hopeful we could fit it back >>> down in 4K. >>> >>> It is easy enough to see the bug and then look at the various frames >>> and see if they use a lot of stack and can be reduced. >>> >>> - Jay >>> >>> >>> >>> ---------------------------------------- >>>> Date: Mon, 17 Aug 2009 13:30:26 +0200 >>>> From: wagner at elegosoft.com >>>> To: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] more crashers >>>> >>>> Quoting Jay K : >>>> >>>>> visobliq was stack overflow. >>>>> Raising the default from 4K to 16K didn't fix, but 32K did. >>>> >>>> We need to address this somehow. It cannot be correct if the user >>>> needs to increase the default stack size on one platform by 8 >>>> and not at all on another. Do we have any concept of a 'standard >>>> stack size unit' ;-)? Something that can be easily understood and >>>> implemented and be used instead of the machine words in the current >>>> interfaces? Any ideas? >>>> >>>> Olaf >>>> >>>> >>>>> - Jay >>>>> >>>>> ---------------------------------------- >>>>>> From: jay.krell at cornell.edu >>>>>> To: hosking at cs.purdue.edu >>>>>> CC: m3devel at elegosoft.com >>>>>> Subject: RE: [M3devel] more crashers >>>>>> Date: Sun, 16 Aug 2009 20:32:31 +0000 >>>>>> >>>>>> >>>>>> m3browser: >>>>>> >>>>>> It is specific to my config file >>>>>> m3-sys/cminstall/src/config-no-install/cm3.cfg that reachs back >>>>>> into the source tree. It won't happen with what most people do. I >>>>>> have to do that M3Predefines or such work so that all the uses of >>>>>> m3quake besides cm3 are much more like cm3. >>>>>> >>>>>> >>>>>> visobliq: >>>>>> not the same thing >>>>>> Does not occur on Linux/x86 or Linux/sparc. >>>>>> They do print >>>>>> Syntax error just before: -helvetica-bold-\*R-\*240-\*\") (LabelFo ... >>>>>> ill-formed character escape sequence >>>>>> Error detected (file file generated by Visual Obliq) (line 18, char 10) >>>>>> VideoVBT.Start Jv ServerFailure:errno=0 >>>>>> >>>>>> but then gui comes up. >>>>>> I'll have to finish my Solaris reinstall and get dbx. >>>>>> >>>>>> >>>>>> - Jay >>>>>> >>>>>> >>>>>> ---------------------------------------- >>>>>>> From: jay.krell at cornell.edu >>>>>>> To: hosking at cs.purdue.edu >>>>>>> Date: Sun, 16 Aug 2009 20:22:49 +0000 >>>>>>> CC: m3devel at elegosoft.com >>>>>>> Subject: Re: [M3devel] more crashers >>>>>>> >>>>>>> >>>>>>> sorry, this is simple. >>>>>>> >>>>>>> derived_dirs := IntList.List1 (ID.Add (MxConfig.Get("BUILD_DIR"))); >>>>>>> >>>>>>> >>>>>>> - Jay >>>>>>> >>>>>>> >>>>>>> >>>>>>> ---------------------------------------- >>>>>>>> From: jay.krell at cornell.edu >>>>>>>> To: hosking at cs.purdue.edu >>>>>>>> Date: Sun, 16 Aug 2009 19:52:03 +0000 >>>>>>>> CC: m3devel at elegosoft.com >>>>>>>> Subject: Re: [M3devel] more crashers >>>>>>>> >>>>>>>> >>>>>>>> Here is the relevant code in m3browser ID.m3: >>>>>>>> >>>>>>>> >>>>>>>> C:\dev2\cm3.2\m3-tools\m3markup\src\ID.m3(38): empty_id := Add (""); >>>>>>>> >>>>>>>> empty_id := Add (""); >>>>>>>> >>>>>>>> (*-------------------------------------------------------------- >>>>>>>> exported ---*) >>>>>>>> PROCEDURE Add (x: TEXT): T = >>>>>>>> VAR >>>>>>>> t: T; >>>>>>>> a: REF ARRAY OF CHAR; >>>>>>>> l: INTEGER; >>>>>>>> BEGIN >>>>>>>> l := Text.Length(x); >>>>>>>> ... >>>>>>>> END Add; >>>>>>>> >>>>>>>> >>>>>>>> The empty string constant ends up as null. >>>>>>>> >>>>>>>> .stabn 68,0,38,.LM115-.LFBB10 >>>>>>>> .LM115: >>>>>>>> movl L_1 at GOT(%ebx), %eax >>>>>>>> leal 24(%eax), %eax >>>>>>>> movl %eax, (%esp) >>>>>>>> call ID__Add at PLT >>>>>>>> movl %eax, -8(%ebp) >>>>>>>> movl -8(%ebp), %ecx >>>>>>>> movl MM_ID at GOT(%ebx), %edx >>>>>>>> movl 248(%edx), %eax >>>>>>>> andl $0, %eax >>>>>>>> orl %ecx, %eax >>>>>>>> movl %eax, 248(%edx) >>>>>>>> .L136: >>>>>>>> movl MM_ID at GOT(%ebx), %eax >>>>>>>> .LBE16: >>>>>>>> addl $52, %esp >>>>>>>> popl %ebx >>>>>>>> popl %ebp >>>>>>>> ret >>>>>>>> >>>>>>>> L_1: >>>>>>>> 0 .long RTHooks__TextLitInfo >>>>>>>> 4 .long RTHooks__TextLitGetChar >>>>>>>> 8 .long RTHooks__TextLitGetWideChar >>>>>>>> 12 .long RTHooks__TextLitGetChars >>>>>>>> 16 .long RTHooks__TextLitGetWideChars >>>>>>>> 20 .long 2 >>>>>>>> 24 .long L_1 >>>>>>>> .long 0 >>>>>>>> .zero 4 >>>>>>>> .ascii "ID_M3" >>>>>>>> .zero 1 >>>>>>>> .ascii "ExpandHashTable" >>>>>>>> .zero 1 >>>>>>>> .ascii "ExpandIDs" >>>>>>>> .zero 1 >>>>>>>> .ascii "ExpandChars" >>>>>>>> .zero 1 >>>>>>>> .ascii "Compare" >>>>>>>> .zero 1 >>>>>>>> >>>>>>>> If I change "" to "foo", I get: >>>>>>>> >>>>>>>> L_1: >>>>>>>> 0 .long RTHooks__TextLitInfo >>>>>>>> 4 .long RTHooks__TextLitGetChar >>>>>>>> 8 .long RTHooks__TextLitGetWideChar >>>>>>>> 12 .long RTHooks__TextLitGetChars >>>>>>>> 16 .long RTHooks__TextLitGetWideChars >>>>>>>> 20 .long 2 >>>>>>>> 24 .long L_1 >>>>>>>> .long 3 >>>>>>>> .ascii "foo" >>>>>>>> .zero 1 >>>>>>>> .ascii "ID_M3" >>>>>>>> >>>>>>>> and it still crashes. >>>>>>>> >>>>>>>> >>>>>>>> It seems to hit ID__Add twice when only once would be expected. >>>>>>>> >>>>>>>> >>>>>>>> - Jay >>>>>>>> >>>>>>>> >>>>>>>> ---------------------------------------- >>>>>>>>> From: jay.krell at cornell.edu >>>>>>>>> To: hosking at cs.purdue.edu >>>>>>>>> Date: Sun, 16 Aug 2009 19:33:34 +0000 >>>>>>>>> CC: m3devel at elegosoft.com >>>>>>>>> Subject: Re: [M3devel] more crashers >>>>>>>>> >>>>>>>>> >>>>>>>>> Could be. I've also seen it on PPC_DARWIN a while ago. I only >>>>>>>>> recall seeing it on sparc and ppc. >>>>>>>>> It doesn't always occur. >>>>>>>>> >>>>>>>>> >>>>>>>>> Here is the m3browser crash on a system that can be debugged. >>>>>>>>> See why I want the full paths in the debug info? >>>>>>>>> >>>>>>>>> >>>>>>>>> C:\Users\jay\Desktop>\cygwin\bin\ssh xobsd. >>>>>>>>> $ cd /cm3 >>>>>>>>> $ cd bin >>>>>>>>> $ export DISPLAY=192.168.1.120:0.0 >>>>>>>>> $ gdb ./m3browser >>>>>>>>> GNU gdb 6.3 >>>>>>>>> This GDB was configured as "i386-unknown-openbsd4.5"... >>>>>>>>> (gdb) r >>>>>>>>> Starting program: /home/jay/cm3/bin/m3browser >>>>>>>>> Program received signal SIGSEGV, Segmentation fault. >>>>>>>>> [Switching to process 31063, thread 0x7eafe800] >>>>>>>>> 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/ >>>>>>>>> Text.m3:16 >>>>>>>>> 16 t.get_info (i); >>>>>>>>> (gdb) bt >>>>>>>>> #0 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/ >>>>>>>>> text/Text.m3:16 >>>>>>>>> #1 0x09fd9464 in ID__Add (M3_Bd56fi_x=0x0) at ../src/ID.m3:48 >>>>>>>>> #2 0x1c01e644 in Main_M3 (M3_AcxOUs_mode=1) at ../src/ Main.m3:37 >>>>>>>>> #3 0x0156f1bc in RTLinker__RunMainBody (M3_DjPxE3_m=0x3c003ec0) >>>>>>>>> at ../src/runtime/common/RTLinker.m3:399 >>>>>>>>> #4 0x0156e576 in RTLinker__AddUnitI (M3_DjPxE3_m=0x3c003ec0) >>>>>>>>> at ../src/runtime/common/RTLinker.m3:113 >>>>>>>>> #5 0x0156e604 in RTLinker__AddUnit (M3_DjPxE5_b=0x1c01e54d) >>>>>>>>> at ../src/runtime/common/RTLinker.m3:122 >>>>>>>>> #6 0x1c004676 in main (argc=1, argv=0xcfbf6a3c, envp=0xcfbf6a44) >>>>>>>>> at _m3main.mc:4 >>>>>>>>> >>>>>>>>> >>>>>>>>> - Jay >>>>>>>>> >>>>>>>>> >>>>>>>>> ________________________________ >>>>>>>>>> From: hosking at cs.purdue.edu >>>>>>>>>> To: jay.krell at cornell.edu >>>>>>>>>> Date: Sun, 16 Aug 2009 15:26:49 -0400 >>>>>>>>>> CC: m3devel at elegosoft.com >>>>>>>>>> Subject: Re: [M3devel] more crashers >>>>>>>>>> >>>>>>>>>> Could this be endianness-related? >>>>>>>>>> >>>>>>>>>> On 16 Aug 2009, at 15:21, Jay K wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I see the assertion failure on PPC_LINUX too. >>>>>>>>>> I tried VAR defaultStackSize := 1024 * 1024; (not sure why >>>>>>>>>> there was any suspicion of stack size). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Debugging doesn't work PPC_LINUX. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> jay at plin:/cm3/bin$ gdb ./cm3 >>>>>>>>>> GNU gdb 6.8-debian >>>>>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>>>> This is free software: you are free to change and redistribute it. >>>>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>>>> "show copying" >>>>>>>>>> and "show warranty" for details. >>>>>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>>>>> break ma(gdb) break main >>>>>>>>>> Breakpoint 1 at 0x86fc4: file _m3main.mc, line 2. >>>>>>>>>> (gdb) r >>>>>>>>>> Starting program: /home/jay/cm3/bin/cm3 >>>>>>>>>> Warning: >>>>>>>>>> Cannot insert breakpoint 1. >>>>>>>>>> Error accessing memory address 0x86fc4: Input/output error. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> No problem with C: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> jay at plin:/cm3/bin$ echo "main(){}"> 1.c >>>>>>>>>> jay at plin:/cm3/bin$ gcc -g 1.c >>>>>>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>>>>>> GNU gdb 6.8-debian >>>>>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>>>> This is free software: you are free to change and redistribute it. >>>>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>>>> "show copying" >>>>>>>>>> and "show warranty" for details. >>>>>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>>>>> (gdb) break main >>>>>>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>>>>>> (gdb) r >>>>>>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>>>>>> Breakpoint 1, main () at 1.c:1 >>>>>>>>>> 1 main(){} >>>>>>>>>> (gdb) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> jay at plin:/cm3/bin$ gcc -gstabs+ 1.c >>>>>>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>>>>>> GNU gdb 6.8-debian >>>>>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>>>> This is free software: you are free to change and redistribute it. >>>>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>>>> "show copying" >>>>>>>>>> and "show warranty" for details. >>>>>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>>>>> (gdb) break main >>>>>>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>>>>>> (gdb) r >>>>>>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>>>>>> Breakpoint 1, main () at 1.c:1 >>>>>>>>>> 1 main(){} >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> jay at plin:/cm3/bin$ gcc -gstabs 1.c >>>>>>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>>>>>> GNU gdb 6.8-debian >>>>>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>>>> This is free software: you are free to change and redistribute it. >>>>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>>>> "show copying" >>>>>>>>>> and "show warranty" for details. >>>>>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>>>>> (gdb) break main >>>>>>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>>>>>> (gdb) r >>>>>>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>>>>>> Breakpoint 1, main () at 1.c:1 >>>>>>>>>> 1 main(){} >>>>>>>>>> (gdb) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> - Jay >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ---------------------------------------- >>>>>>>>>> From: jay.krell at cornell.edu >>>>>>>>>> To: m3devel at elegosoft.com >>>>>>>>>> Subject: more crashers >>>>>>>>>> Date: Sun, 16 Aug 2009 10:06:15 +0000 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> This is head on SOLgnu: >>>>>>>>>> I'll try another and debug and see if fix is easy. >>>>>>>>>> >>>>>>>>>> -bash-3.00$ ./m3browser >>>>>>>>>> >>>>>>>>>> *** >>>>>>>>>> *** runtime error: >>>>>>>>>> *** Segmentation violation - possible attempt to dereference NIL >>>>>>>>>> *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/ String16.m3 >>>>>>>>>> *** >>>>>>>>>> >>>>>>>>>> -bash-3.00$ ./visobliq >>>>>>>>>> Internal Obliq interpreter installed... >>>>>>>>>> Establishing 'templates' >>>>>>>>>> (Created frame 'templates') >>>>>>>>>> let >>>>>>>>>> Templates = >>>>>>>>>> {boolean=> ... , >>>>>>>>>> browser=> ... , >>>>>>>>>> button=> ... , >>>>>>>>>> choice=> ... , >>>>>>>>>> filebrowser=> ... , >>>>>>>>>> form=> ... , >>>>>>>>>> frame=> ... , >>>>>>>>>> hscroll=> ... , >>>>>>>>>> menu=> ... , >>>>>>>>>> numeric=> ... , >>>>>>>>>> text=> ... , >>>>>>>>>> textedit=> ... , >>>>>>>>>> typein=> ... , >>>>>>>>>> video=> ... , >>>>>>>>>> vscroll=> ... } >>>>>>>>>> Establishing 'vowidgets' >>>>>>>>>> (Created frame 'vowidgets') >>>>>>>>>> ok >>>>>>>>>> Establishing 'vocheckpt' >>>>>>>>>> (Created frame 'vocheckpt') >>>>>>>>>> ok >>>>>>>>>> Establishing 'volib' >>>>>>>>>> (Created frame 'volib') >>>>>>>>>> Segmentation Fault (core dumped) >>>>>>>>>> -bash-3.00$ >>>>>>>>>> >>>>>>>>>> >>>> >>>> >>>> >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>> 45 86 95 >>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>> DE163214194 >>>> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Aug 17 17:14:44 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 17 Aug 2009 15:14:44 +0000 Subject: [M3devel] more crashers In-Reply-To: <20090817171329.dsbfoh9s04k0o84w@mail.elegosoft.com> References: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> <20090817133026.6v9cm3cu0wwkc08k@mail.elegosoft.com> <20090817171329.dsbfoh9s04k0o84w@mail.elegosoft.com> Message-ID: For 5.9 we should look into the libunwind/libgcc stuff. - Jay ---------------------------------------- > Date: Mon, 17 Aug 2009 17:13:29 +0200 > From: wagner at elegosoft.com > To: hosking at cs.purdue.edu > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > Subject: Re: [M3devel] more crashers > > Quoting Tony Hosking : > >> Indeed, we might be better off investing effort in getting rid of try- >> blocks implemented using setjmp/longjmp so as to avoid the stack- >> allocated jmpbuf state. Or perhaps allocate that state in the heap. > > Is this a feature for 5.9 then? ;-) > > Olaf > >> On 17 Aug 2009, at 09:18, Jay K wrote: >> >>> >>> Not as much luck as I'd like. >>> >>> >>> PTHREAD_STACK_MIN >>> Solaris: 4K >>> Linux/sparc: 24K >>> Linux/x86: 16K >>> Linux/powerpc: 128K >>> >>> >>> The overflowing stack, with 16K: >>> >>> >>> current thread: t at 12 >>> =>[1] Rd__CharsReady(0xfd61a00c, 0xfd617410, 0xfd59fb6c, 0x0, >>> 0xfd59fb84, 0xfd59 >>> fb8c), at 0xfec58578 >>> ---- 1 following frame from gwindows -- possible stack overflow >>> [2] SynScan__LookChar(0xfd883670, 0xfd8aa81c, 0xfd59fb6c, 0x0, >>> 0xfd59fb84, 0xf >>> d59fb8c), at 0xfead71fc >>> [3] SynScan__NextToken(0xfd883670, 0xfd8ab980, 0x9, 0x0, >>> 0xfd59fb84, 0xfd59fb8 >>> c), at 0xfead91c4 >>> [4] SynScan__LookToken(0xfd883670, 0x4ae, 0x9, 0x0, 0xfd59fb84, >>> 0xfd59fb8c), a >>> t 0xfead9628 >>> [5] SynScan__HaveTokenName(0xfd883670, 0xfd5f7768, 0x8, 0x0, >>> 0xfd59fb84, 0xfd5 >>> 9fb8c), at 0xfeadd084 >>> [6] SynParse__Read0(0xfd883654, 0xfd6174ac, 0xfd59fb6c, 0x0, >>> 0xfd59fb84, 0xfd5 >>> 9fb8c), at 0xfeae4760 >>> [7] SynParse__Read0(0xfd883654, 0xfd617460, 0xfd59fb6c, 0x0, >>> 0xfd59fb84, 0xfd5 >>> 9fb8c), at 0xfeae5e8c >>> >>> >>> hundreds of frames of Lots of SynParse__Read0, using about 1K per >>> frame; there is a try in there. >>> >>> d59fb8c), at 0xfeae348c >>> [666] SynParse__Read0(0xfd883654, 0xfd6172d8, 0xfd59fb6c, 0x0, >>> 0xfd59fb84, 0xf >>> d59fb8c), at 0xfeae5e8c >>> [667] SynParse__Read0(0xfd883654, 0xfd8aaa6c, 0xfd59fb6c, 0x0, >>> 0xfd59fb84, 0xf >>> d59fb8c), at 0xfeae3dd4 >>> [668] SynParse__Read0(0xfd883654, 0xfd617288, 0xfd59fb6c, 0x0, >>> 0xfd59fb84, 0xf >>> d59fb8c), at 0xfeae3168 >>> [669] SynParse__Read0(0xfd883654, 0xfd8aacec, 0xfd59fb6c, 0x0, >>> 0xfd59fb84, 0xf >>> d59fb8c), at 0xfeae6230 >>> [670] SynParse__Read1(0xfd883654, 0xfd8aacec, 0x0, 0xfd59fb84, >>> 0xfd59fb8c, 0x0 >>> ), at 0xfeae2674 >>> [671] SynParse__Read(0xfd883654, 0xfd8aacec, 0x0, 0xfd803a00, 0x0, >>> 0xfebee308) >>> , at 0xfeadfb60 >>> [672] SynParse__ReadNonTerminal(0xfd883654, 0xfefed45c, 0xfd61b250, >>> 0xfd61b8cc >>> , 0xfd61b280, 0xfd89a27c), at 0xfeadfae8 >>> [673] ObliqParser__ParsePhrase(0xfd883654, 0x0, 0xfd61b250, >>> 0xfd61b8cc, 0xfd61 >>> b280, 0x0), at 0xfefd5ff0 >>> [674] ObliqOnline__Interact(0xfd89a848, 0xc32a0, 0xfd61a00c, 0x1, >>> 0x1, 0xfebee >>> 308), at 0xff36b80c >>> [675] ObliqRuntime__ForkedDo(0xfd3ddfb8, 0x9658aac0, 0xff000000, >>> 0x0, 0xfd9100 >>> 90, 0x0), at 0x80db0 >>> [676] ThreadPThread__RunThread(0xef2b0, 0x0, 0x0, 0x0, 0xfd803a00, >>> 0x1), at 0x >>> fe06bc88 >>> [677] ThreadPThread__ThreadBase(0xef2b0, 0xfd5a0000, 0x0, 0x0, >>> 0xfe06b7c8, 0x1 >>> ), at 0xfe06b818 >>> >>> >>> One of the problems with defining a unit of stack size is the large >>> variety of jmpbuf size. >>> But heck, why 1K per frame here when SOLsun has a stack walker? Hm. >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: wagner at elegosoft.com; m3devel at elegosoft.com >>>> Subject: RE: [M3devel] more crashers >>>> Date: Mon, 17 Aug 2009 11:35:40 +0000 >>>> >>>> >>>> - I think the whole machine stack mechanism is pretty hopelessly broken. >>>> Not just in Modula-3. Therefore my enthusiasm to attempt to "fix" >>>> it -- which is impossible -- isn't very high. >>>> >>>> - I'm hoping to find that no platform other than Solaris lets you >>>> even use such a small stack. I have to experiment some in a bit. >>>> Depending on that experiment, we'll be in a better position, without >>>> any further changes, but again, depending on what I find. >>>> That is, if every other platform already had a larger stack, then this >>>> just brings Solaris inline with the rest. If the other platforms >>>> were actually successfully using a 4K stack, then indeed a problem. >>>> >>>> >>>> - It could also be a factor of optimization. >>>> Maybe ensuring -O2 or -O3 is used more would cover it up?? >>>> >>>> >>>> - Or some other changes. >>>> That is, if we have drastically increased stack usage, we should try >>>> to reduce it back down. But given that 4K was the previous value >>>> and even 16K doesn't work...I'm not hopeful we could fit it back >>>> down in 4K. >>>> >>>> It is easy enough to see the bug and then look at the various frames >>>> and see if they use a lot of stack and can be reduced. >>>> >>>> - Jay >>>> >>>> >>>> >>>> ---------------------------------------- >>>>> Date: Mon, 17 Aug 2009 13:30:26 +0200 >>>>> From: wagner at elegosoft.com >>>>> To: m3devel at elegosoft.com >>>>> Subject: Re: [M3devel] more crashers >>>>> >>>>> Quoting Jay K : >>>>> >>>>>> visobliq was stack overflow. >>>>>> Raising the default from 4K to 16K didn't fix, but 32K did. >>>>> >>>>> We need to address this somehow. It cannot be correct if the user >>>>> needs to increase the default stack size on one platform by 8 >>>>> and not at all on another. Do we have any concept of a 'standard >>>>> stack size unit' ;-)? Something that can be easily understood and >>>>> implemented and be used instead of the machine words in the current >>>>> interfaces? Any ideas? >>>>> >>>>> Olaf >>>>> >>>>> >>>>>> - Jay >>>>>> >>>>>> ---------------------------------------- >>>>>>> From: jay.krell at cornell.edu >>>>>>> To: hosking at cs.purdue.edu >>>>>>> CC: m3devel at elegosoft.com >>>>>>> Subject: RE: [M3devel] more crashers >>>>>>> Date: Sun, 16 Aug 2009 20:32:31 +0000 >>>>>>> >>>>>>> >>>>>>> m3browser: >>>>>>> >>>>>>> It is specific to my config file >>>>>>> m3-sys/cminstall/src/config-no-install/cm3.cfg that reachs back >>>>>>> into the source tree. It won't happen with what most people do. I >>>>>>> have to do that M3Predefines or such work so that all the uses of >>>>>>> m3quake besides cm3 are much more like cm3. >>>>>>> >>>>>>> >>>>>>> visobliq: >>>>>>> not the same thing >>>>>>> Does not occur on Linux/x86 or Linux/sparc. >>>>>>> They do print >>>>>>> Syntax error just before: -helvetica-bold-\*R-\*240-\*\") (LabelFo ... >>>>>>> ill-formed character escape sequence >>>>>>> Error detected (file file generated by Visual Obliq) (line 18, char 10) >>>>>>> VideoVBT.Start Jv ServerFailure:errno=0 >>>>>>> >>>>>>> but then gui comes up. >>>>>>> I'll have to finish my Solaris reinstall and get dbx. >>>>>>> >>>>>>> >>>>>>> - Jay >>>>>>> >>>>>>> >>>>>>> ---------------------------------------- >>>>>>>> From: jay.krell at cornell.edu >>>>>>>> To: hosking at cs.purdue.edu >>>>>>>> Date: Sun, 16 Aug 2009 20:22:49 +0000 >>>>>>>> CC: m3devel at elegosoft.com >>>>>>>> Subject: Re: [M3devel] more crashers >>>>>>>> >>>>>>>> >>>>>>>> sorry, this is simple. >>>>>>>> >>>>>>>> derived_dirs := IntList.List1 (ID.Add (MxConfig.Get("BUILD_DIR"))); >>>>>>>> >>>>>>>> >>>>>>>> - Jay >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ---------------------------------------- >>>>>>>>> From: jay.krell at cornell.edu >>>>>>>>> To: hosking at cs.purdue.edu >>>>>>>>> Date: Sun, 16 Aug 2009 19:52:03 +0000 >>>>>>>>> CC: m3devel at elegosoft.com >>>>>>>>> Subject: Re: [M3devel] more crashers >>>>>>>>> >>>>>>>>> >>>>>>>>> Here is the relevant code in m3browser ID.m3: >>>>>>>>> >>>>>>>>> >>>>>>>>> C:\dev2\cm3.2\m3-tools\m3markup\src\ID.m3(38): empty_id := Add (""); >>>>>>>>> >>>>>>>>> empty_id := Add (""); >>>>>>>>> >>>>>>>>> (*-------------------------------------------------------------- >>>>>>>>> exported ---*) >>>>>>>>> PROCEDURE Add (x: TEXT): T = >>>>>>>>> VAR >>>>>>>>> t: T; >>>>>>>>> a: REF ARRAY OF CHAR; >>>>>>>>> l: INTEGER; >>>>>>>>> BEGIN >>>>>>>>> l := Text.Length(x); >>>>>>>>> ... >>>>>>>>> END Add; >>>>>>>>> >>>>>>>>> >>>>>>>>> The empty string constant ends up as null. >>>>>>>>> >>>>>>>>> .stabn 68,0,38,.LM115-.LFBB10 >>>>>>>>> .LM115: >>>>>>>>> movl L_1 at GOT(%ebx), %eax >>>>>>>>> leal 24(%eax), %eax >>>>>>>>> movl %eax, (%esp) >>>>>>>>> call ID__Add at PLT >>>>>>>>> movl %eax, -8(%ebp) >>>>>>>>> movl -8(%ebp), %ecx >>>>>>>>> movl MM_ID at GOT(%ebx), %edx >>>>>>>>> movl 248(%edx), %eax >>>>>>>>> andl $0, %eax >>>>>>>>> orl %ecx, %eax >>>>>>>>> movl %eax, 248(%edx) >>>>>>>>> .L136: >>>>>>>>> movl MM_ID at GOT(%ebx), %eax >>>>>>>>> .LBE16: >>>>>>>>> addl $52, %esp >>>>>>>>> popl %ebx >>>>>>>>> popl %ebp >>>>>>>>> ret >>>>>>>>> >>>>>>>>> L_1: >>>>>>>>> 0 .long RTHooks__TextLitInfo >>>>>>>>> 4 .long RTHooks__TextLitGetChar >>>>>>>>> 8 .long RTHooks__TextLitGetWideChar >>>>>>>>> 12 .long RTHooks__TextLitGetChars >>>>>>>>> 16 .long RTHooks__TextLitGetWideChars >>>>>>>>> 20 .long 2 >>>>>>>>> 24 .long L_1 >>>>>>>>> .long 0 >>>>>>>>> .zero 4 >>>>>>>>> .ascii "ID_M3" >>>>>>>>> .zero 1 >>>>>>>>> .ascii "ExpandHashTable" >>>>>>>>> .zero 1 >>>>>>>>> .ascii "ExpandIDs" >>>>>>>>> .zero 1 >>>>>>>>> .ascii "ExpandChars" >>>>>>>>> .zero 1 >>>>>>>>> .ascii "Compare" >>>>>>>>> .zero 1 >>>>>>>>> >>>>>>>>> If I change "" to "foo", I get: >>>>>>>>> >>>>>>>>> L_1: >>>>>>>>> 0 .long RTHooks__TextLitInfo >>>>>>>>> 4 .long RTHooks__TextLitGetChar >>>>>>>>> 8 .long RTHooks__TextLitGetWideChar >>>>>>>>> 12 .long RTHooks__TextLitGetChars >>>>>>>>> 16 .long RTHooks__TextLitGetWideChars >>>>>>>>> 20 .long 2 >>>>>>>>> 24 .long L_1 >>>>>>>>> .long 3 >>>>>>>>> .ascii "foo" >>>>>>>>> .zero 1 >>>>>>>>> .ascii "ID_M3" >>>>>>>>> >>>>>>>>> and it still crashes. >>>>>>>>> >>>>>>>>> >>>>>>>>> It seems to hit ID__Add twice when only once would be expected. >>>>>>>>> >>>>>>>>> >>>>>>>>> - Jay >>>>>>>>> >>>>>>>>> >>>>>>>>> ---------------------------------------- >>>>>>>>>> From: jay.krell at cornell.edu >>>>>>>>>> To: hosking at cs.purdue.edu >>>>>>>>>> Date: Sun, 16 Aug 2009 19:33:34 +0000 >>>>>>>>>> CC: m3devel at elegosoft.com >>>>>>>>>> Subject: Re: [M3devel] more crashers >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Could be. I've also seen it on PPC_DARWIN a while ago. I only >>>>>>>>>> recall seeing it on sparc and ppc. >>>>>>>>>> It doesn't always occur. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Here is the m3browser crash on a system that can be debugged. >>>>>>>>>> See why I want the full paths in the debug info? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> C:\Users\jay\Desktop>\cygwin\bin\ssh xobsd. >>>>>>>>>> $ cd /cm3 >>>>>>>>>> $ cd bin >>>>>>>>>> $ export DISPLAY=192.168.1.120:0.0 >>>>>>>>>> $ gdb ./m3browser >>>>>>>>>> GNU gdb 6.3 >>>>>>>>>> This GDB was configured as "i386-unknown-openbsd4.5"... >>>>>>>>>> (gdb) r >>>>>>>>>> Starting program: /home/jay/cm3/bin/m3browser >>>>>>>>>> Program received signal SIGSEGV, Segmentation fault. >>>>>>>>>> [Switching to process 31063, thread 0x7eafe800] >>>>>>>>>> 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/ >>>>>>>>>> Text.m3:16 >>>>>>>>>> 16 t.get_info (i); >>>>>>>>>> (gdb) bt >>>>>>>>>> #0 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/ >>>>>>>>>> text/Text.m3:16 >>>>>>>>>> #1 0x09fd9464 in ID__Add (M3_Bd56fi_x=0x0) at ../src/ID.m3:48 >>>>>>>>>> #2 0x1c01e644 in Main_M3 (M3_AcxOUs_mode=1) at ../src/ Main.m3:37 >>>>>>>>>> #3 0x0156f1bc in RTLinker__RunMainBody (M3_DjPxE3_m=0x3c003ec0) >>>>>>>>>> at ../src/runtime/common/RTLinker.m3:399 >>>>>>>>>> #4 0x0156e576 in RTLinker__AddUnitI (M3_DjPxE3_m=0x3c003ec0) >>>>>>>>>> at ../src/runtime/common/RTLinker.m3:113 >>>>>>>>>> #5 0x0156e604 in RTLinker__AddUnit (M3_DjPxE5_b=0x1c01e54d) >>>>>>>>>> at ../src/runtime/common/RTLinker.m3:122 >>>>>>>>>> #6 0x1c004676 in main (argc=1, argv=0xcfbf6a3c, envp=0xcfbf6a44) >>>>>>>>>> at _m3main.mc:4 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> - Jay >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ________________________________ >>>>>>>>>>> From: hosking at cs.purdue.edu >>>>>>>>>>> To: jay.krell at cornell.edu >>>>>>>>>>> Date: Sun, 16 Aug 2009 15:26:49 -0400 >>>>>>>>>>> CC: m3devel at elegosoft.com >>>>>>>>>>> Subject: Re: [M3devel] more crashers >>>>>>>>>>> >>>>>>>>>>> Could this be endianness-related? >>>>>>>>>>> >>>>>>>>>>> On 16 Aug 2009, at 15:21, Jay K wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I see the assertion failure on PPC_LINUX too. >>>>>>>>>>> I tried VAR defaultStackSize := 1024 * 1024; (not sure why >>>>>>>>>>> there was any suspicion of stack size). >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Debugging doesn't work PPC_LINUX. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> jay at plin:/cm3/bin$ gdb ./cm3 >>>>>>>>>>> GNU gdb 6.8-debian >>>>>>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>>>>> This is free software: you are free to change and redistribute it. >>>>>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>>>>> "show copying" >>>>>>>>>>> and "show warranty" for details. >>>>>>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>>>>>> break ma(gdb) break main >>>>>>>>>>> Breakpoint 1 at 0x86fc4: file _m3main.mc, line 2. >>>>>>>>>>> (gdb) r >>>>>>>>>>> Starting program: /home/jay/cm3/bin/cm3 >>>>>>>>>>> Warning: >>>>>>>>>>> Cannot insert breakpoint 1. >>>>>>>>>>> Error accessing memory address 0x86fc4: Input/output error. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> No problem with C: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> jay at plin:/cm3/bin$ echo "main(){}"> 1.c >>>>>>>>>>> jay at plin:/cm3/bin$ gcc -g 1.c >>>>>>>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>>>>>>> GNU gdb 6.8-debian >>>>>>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>>>>> This is free software: you are free to change and redistribute it. >>>>>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>>>>> "show copying" >>>>>>>>>>> and "show warranty" for details. >>>>>>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>>>>>> (gdb) break main >>>>>>>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>>>>>>> (gdb) r >>>>>>>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>>>>>>> Breakpoint 1, main () at 1.c:1 >>>>>>>>>>> 1 main(){} >>>>>>>>>>> (gdb) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> jay at plin:/cm3/bin$ gcc -gstabs+ 1.c >>>>>>>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>>>>>>> GNU gdb 6.8-debian >>>>>>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>>>>> This is free software: you are free to change and redistribute it. >>>>>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>>>>> "show copying" >>>>>>>>>>> and "show warranty" for details. >>>>>>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>>>>>> (gdb) break main >>>>>>>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>>>>>>> (gdb) r >>>>>>>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>>>>>>> Breakpoint 1, main () at 1.c:1 >>>>>>>>>>> 1 main(){} >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> jay at plin:/cm3/bin$ gcc -gstabs 1.c >>>>>>>>>>> jay at plin:/cm3/bin$ gdb ./a.out >>>>>>>>>>> GNU gdb 6.8-debian >>>>>>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>>>>> This is free software: you are free to change and redistribute it. >>>>>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>>>>> "show copying" >>>>>>>>>>> and "show warranty" for details. >>>>>>>>>>> This GDB was configured as "powerpc-linux-gnu"... >>>>>>>>>>> (gdb) break main >>>>>>>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1. >>>>>>>>>>> (gdb) r >>>>>>>>>>> Starting program: /home/jay/cm3/bin/a.out >>>>>>>>>>> Breakpoint 1, main () at 1.c:1 >>>>>>>>>>> 1 main(){} >>>>>>>>>>> (gdb) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> - Jay >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ---------------------------------------- >>>>>>>>>>> From: jay.krell at cornell.edu >>>>>>>>>>> To: m3devel at elegosoft.com >>>>>>>>>>> Subject: more crashers >>>>>>>>>>> Date: Sun, 16 Aug 2009 10:06:15 +0000 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> This is head on SOLgnu: >>>>>>>>>>> I'll try another and debug and see if fix is easy. >>>>>>>>>>> >>>>>>>>>>> -bash-3.00$ ./m3browser >>>>>>>>>>> >>>>>>>>>>> *** >>>>>>>>>>> *** runtime error: >>>>>>>>>>> *** Segmentation violation - possible attempt to dereference NIL >>>>>>>>>>> *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/ String16.m3 >>>>>>>>>>> *** >>>>>>>>>>> >>>>>>>>>>> -bash-3.00$ ./visobliq >>>>>>>>>>> Internal Obliq interpreter installed... >>>>>>>>>>> Establishing 'templates' >>>>>>>>>>> (Created frame 'templates') >>>>>>>>>>> let >>>>>>>>>>> Templates = >>>>>>>>>>> {boolean=> ... , >>>>>>>>>>> browser=> ... , >>>>>>>>>>> button=> ... , >>>>>>>>>>> choice=> ... , >>>>>>>>>>> filebrowser=> ... , >>>>>>>>>>> form=> ... , >>>>>>>>>>> frame=> ... , >>>>>>>>>>> hscroll=> ... , >>>>>>>>>>> menu=> ... , >>>>>>>>>>> numeric=> ... , >>>>>>>>>>> text=> ... , >>>>>>>>>>> textedit=> ... , >>>>>>>>>>> typein=> ... , >>>>>>>>>>> video=> ... , >>>>>>>>>>> vscroll=> ... } >>>>>>>>>>> Establishing 'vowidgets' >>>>>>>>>>> (Created frame 'vowidgets') >>>>>>>>>>> ok >>>>>>>>>>> Establishing 'vocheckpt' >>>>>>>>>>> (Created frame 'vocheckpt') >>>>>>>>>>> ok >>>>>>>>>>> Establishing 'volib' >>>>>>>>>>> (Created frame 'volib') >>>>>>>>>>> Segmentation Fault (core dumped) >>>>>>>>>>> -bash-3.00$ >>>>>>>>>>> >>>>>>>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>>> 45 86 95 >>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>> DE163214194 >>>>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From dragisha at m3w.org Mon Aug 17 16:59:23 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 17 Aug 2009 16:59:23 +0200 Subject: [M3devel] more crashers In-Reply-To: References: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> <20090817133026.6v9cm3cu0wwkc08k@mail.elegosoft.com> Message-ID: <1250521163.11420.12.camel@faramir.m3w.org> Isn't that setjmp/longjmp bussiness direct intruction set dependant? Some pushall or something like that? On Mon, 2009-08-17 at 10:47 -0400, Tony Hosking wrote: > Indeed, we might be better off investing effort in getting rid of > try-blocks implemented using setjmp/longjmp so as to avoid the > stack-allocated jmpbuf state. Or perhaps allocate that state in the > heap. -- Dragi?a Duri? From jay.krell at cornell.edu Tue Aug 18 03:23:00 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 18 Aug 2009 01:23:00 +0000 Subject: [M3devel] more crashers In-Reply-To: <1250521163.11420.12.camel@faramir.m3w.org> References: <0C700661-EF07-40D4-B317-BA6B3F24C05A@cs.purdue.edu> <20090817133026.6v9cm3cu0wwkc08k@mail.elegosoft.com> <1250521163.11420.12.camel@faramir.m3w.org> Message-ID: Yes, something like that. I was likely mistaken -- no try/except/finally here. Still need to look into a bit more, make sure the resulting stack is now very small as I removed all the locals and put them in nested functions -- the function is a big switch and most arms of the switch have their own locals, and some are recursive, every recursion paid for every arm's locals, I assume. 900+ bytes of locals, in a recursive function! That recurses hundreds of times! Blech. The front-end IMHO should "stack pack" "parallel scopes" as a matter of course, not just depend on the optimizer. That wouldn't reduce it as much as my transform though. My transform can sometimes increase stack usage, but not typically. Also of course my transform slows it down in multiple ways, more function calls, slower access to parameters. But preserving stack is important imho. Interesting little area.. - Jay > From: dragisha at m3w.org > To: hosking at cs.purdue.edu > Date: Mon, 17 Aug 2009 16:59:23 +0200 > CC: m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3devel] more crashers > > Isn't that setjmp/longjmp bussiness direct intruction set dependant? > Some pushall or something like that? > > On Mon, 2009-08-17 at 10:47 -0400, Tony Hosking wrote: > > Indeed, we might be better off investing effort in getting rid of > > try-blocks implemented using setjmp/longjmp so as to avoid the > > stack-allocated jmpbuf state. Or perhaps allocate that state in the > > heap. > -- > Dragi?a Duri? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.m.bates at cox.net Tue Aug 18 03:57:54 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Mon, 17 Aug 2009 20:57:54 -0500 Subject: [M3devel] Some big-endian info needed Message-ID: <4A8A0AA2.7080008@cox.net> I need a favor. I need some info from the following program, compiled on a 32-bit big endian and a 64-bit big-endian machine. Would someone who has such machines with working cm3 installed please send it to me? In particular, I need it compiled with -O0 -gstabs+, then the output of: objdump -dG BitNos.mo Alternatively, if you don't have a working objdump, compiling with cm3 -keep and sending me BitNos.ms would probably give me what I need. Thanks. Rodney Bates ------------------------------------------------------------- MODULE BitNos EXPORTS Main ; TYPE Packed = RECORD F0 : BITS 2 FOR [ 0 .. 3 ] := 3 ; F1 : BITS 3 FOR [ 0 .. 7 ] := 7 ; F2 : BITS 10 FOR [ 0 .. 1023 ] := 9 ; F3 : BITS 17 FOR [ 0 .. 131071 ] := 11 ; F4 : BITS 4 FOR [ 0 .. 15 ] := 15 ; F5 : BITS 5 FOR [ 0 .. 31 ] := 17 ; F6 : BITS 12 FOR [ 0 .. 4095] := 19 ; F7 : BITS 11 FOR [ 0 .. 2047 ] := 21 ; F8 : BITS 8 FOR [ 0 .. 255 ] := 23 END ; PROCEDURE P ( ) = VAR Local : Packed ; BEGIN EVAL Local . F3 END P ; PROCEDURE Q ( ) = BEGIN END Q ; BEGIN P ( ) ; Q ( ) END BitNos . --------------------------------------------------------------------- From rodney.m.bates at cox.net Tue Aug 18 04:01:20 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Mon, 17 Aug 2009 21:01:20 -0500 Subject: [M3devel] CM3 web presentation In-Reply-To: <20090815135945.GA24494@topoi.pooq.com> References: <20090815120142.cb14l4zj4k844004@mail.elegosoft.com> <20090815135945.GA24494@topoi.pooq.com> Message-ID: <4A8A0B70.9010601@cox.net> hendrik at topoi.pooq.com wrote: > On Sat, Aug 15, 2009 at 12:14:53PM +0000, Jay K wrote: > >> Please just use white on black or black on white. >> > > Colour or no colour, prefer light on dark. It's much easier for > migraine sufferers. > Interesting. I had severe migraines for years and greatly preferred dark letters on light background. But it's now moot, as the headaches have almost entirely gone in my old age. > -- hendrik > > From jay.krell at cornell.edu Tue Aug 18 04:24:49 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 18 Aug 2009 02:24:49 +0000 Subject: [M3devel] Some big-endian info needed In-Reply-To: <4A8A0AA2.7080008@cox.net> References: <4A8A0AA2.7080008@cox.net> Message-ID: You don't need the target machine to get the .ms file. You can cross build. # build some cross compilers cd $CM3_ROOT/m3-sys/m3cc cm3 -DM3CC_TARGET=PPC_LINUX cm3 -DM3CC_TARGET=SOLgnu cm3 -DM3CC_TARGET=PPC_DARWIN cm3 -DM3CC_TARGET=PA32_HPUX cm3 -DM3CC_TARGET=PA64_HPUX cm3 -DM3CC_TARGET=SPARC64_OPENBSD cm3 -DM3CC_TARGET=MIPS64_OPENBSD cm3 -DM3CC_TARGET=SPARC64_SOLARIS # use cm3.cfg that honors CM3_TARGET environment variable cp m3-sys/cminstall/src/config-no-install/* /cm3/bin cd to where your code is CM3_TARGET=PPC_LINUX cm3 -boot CM3_TARGET=PPC_DARWIN cm3 -boot CM3_TARGET=MIPS64_OPENBSD cm3 -boot CM3_TARGET=SPARC64_OPENBSD cm3 -boot CM3_TARGET=SPARC64_SOLARIS cm3 -boot CM3_TARGET=PA32_HPUX cm3 -boot CM3_TARGET=PA64_HPUX cm3 -boot I don't think we have any actually working big endian 64bit targets, but the ones above almost work. - Jay > Date: Mon, 17 Aug 2009 20:57:54 -0500 > From: rodney.m.bates at cox.net > To: m3devel at elegosoft.com > Subject: [M3devel] Some big-endian info needed > > I need a favor. I need some info from the following program, > compiled on a 32-bit big endian and a 64-bit big-endian machine. > Would someone who has such machines with working cm3 installed > please send it to me? > > In particular, I need it compiled with -O0 -gstabs+, then the > output of: > > objdump -dG BitNos.mo > > Alternatively, if you don't have a working objdump, compiling > with cm3 -keep and sending me BitNos.ms would probably give me > what I need. > > Thanks. > > Rodney Bates > > ------------------------------------------------------------- > > MODULE BitNos EXPORTS Main > > ; TYPE Packed = RECORD > F0 : BITS 2 FOR [ 0 .. 3 ] := 3 > ; F1 : BITS 3 FOR [ 0 .. 7 ] := 7 > ; F2 : BITS 10 FOR [ 0 .. 1023 ] := 9 > ; F3 : BITS 17 FOR [ 0 .. 131071 ] := 11 > ; F4 : BITS 4 FOR [ 0 .. 15 ] := 15 > ; F5 : BITS 5 FOR [ 0 .. 31 ] := 17 > ; F6 : BITS 12 FOR [ 0 .. 4095] := 19 > ; F7 : BITS 11 FOR [ 0 .. 2047 ] := 21 > ; F8 : BITS 8 FOR [ 0 .. 255 ] := 23 > END > > ; PROCEDURE P ( ) > > = VAR Local : Packed > > ; BEGIN > EVAL Local . F3 > END P > > ; PROCEDURE Q ( ) > > = BEGIN > END Q > > ; BEGIN > P ( ) > ; Q ( ) > END BitNos -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Aug 18 15:34:08 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 18 Aug 2009 13:34:08 +0000 Subject: [M3devel] missing error checks in makedist? Message-ID: http://www.modula3.com:8080/view/I386_OPENBSD/job/cm3-makedist-I386_OPENBSD/1/console === package m3-db/odbc === +++ cm3 -build -DROOT='/home/hudson/workspace/cm3-makedist-I386_OPENBSD/cm3' -DCM3_VERSION_TEXT='d5.8.2' -DCM3_VERSION_NUMBER='050802' -DCM3_LAST_CHANGED='2009-07-15' $RARGS && cm3 -ship $RARGS -DROOT='/home/hudson/workspace/cm3-makedist-I386_OPENBSD/cm3' -DCM3_VERSION_TEXT='d5.8.2' -DCM3_VERSION_NUMBER='050802' -DCM3_LAST_CHANGED='2009-07-15' +++ /usr/bin/ld: cannot find -lodbc collect2: ld returned 1 exit status make_lib => 1 librarian failed building: m3odbc From hendrik at topoi.pooq.com Tue Aug 18 16:17:09 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 18 Aug 2009 10:17:09 -0400 Subject: [M3devel] CM3 web presentation In-Reply-To: <4A8A0B70.9010601@cox.net> References: <20090815120142.cb14l4zj4k844004@mail.elegosoft.com> <20090815135945.GA24494@topoi.pooq.com> <4A8A0B70.9010601@cox.net> Message-ID: <20090818141709.GB31203@topoi.pooq.com> On Mon, Aug 17, 2009 at 09:01:20PM -0500, Rodney M. Bates wrote: > hendrik at topoi.pooq.com wrote: > >On Sat, Aug 15, 2009 at 12:14:53PM +0000, Jay K wrote: > > > >>Please just use white on black or black on white. > >> > > > >Colour or no colour, prefer light on dark. It's much easier for > >migraine sufferers. > > > > Interesting. I had severe migraines for years and greatly > preferred dark letters on light background. But it's now > moot, as the headaches have almost entirely gone in my > old age. Evidently all the evidence isn't in yet. It seems to be the amount of subliminal or perceived flicker that aggaravates a migraine. Having a *really* good monitor will likely make a difference. Did the migraines make you fotofugic? -- hendrik From wagner at elegosoft.com Tue Aug 18 16:46:40 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 18 Aug 2009 16:46:40 +0200 Subject: [M3devel] missing error checks in makedist? In-Reply-To: References: Message-ID: <20090818164640.7qet0p9uogsgwks4@mail.elegosoft.com> Quoting Jay K : > > http://www.modula3.com:8080/view/I386_OPENBSD/job/cm3-makedist-I386_OPENBSD/1/console > === package m3-db/odbc === > +++ cm3 -build > -DROOT='/home/hudson/workspace/cm3-makedist-I386_OPENBSD/cm3' > -DCM3_VERSION_TEXT='d5.8.2' -DCM3_VERSION_NUMBER='050802' > -DCM3_LAST_CHANGED='2009-07-15' $RARGS && cm3 -ship $RARGS > -DROOT='/home/hudson/workspace/cm3-makedist-I386_OPENBSD/cm3' > -DCM3_VERSION_TEXT='d5.8.2' -DCM3_VERSION_NUMBER='050802' > -DCM3_LAST_CHANGED='2009-07-15' +++ > /usr/bin/ld: cannot find -lodbc > collect2: ld returned 1 exit status > make_lib => 1 > librarian failed building: m3odbc I reopened ticket 1047. It would help if such failures were immediately fed into trac to be tracked ;-) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Aug 18 17:25:56 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 18 Aug 2009 17:25:56 +0200 Subject: [M3devel] m3gdb build errors Message-ID: <20090818172556.ktlh757rc4gg440o@mail.elegosoft.com> Why does building m3gdb now even fail on FreeBSD for some time? http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-FreeBSD4/107/testReport/ Olaf From wagner at elegosoft.com Wed Aug 19 00:22:53 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 19 Aug 2009 00:22:53 +0200 Subject: [M3devel] m3gdb build errors In-Reply-To: <20090818172556.ktlh757rc4gg440o@mail.elegosoft.com> References: <20090818172556.ktlh757rc4gg440o@mail.elegosoft.com> Message-ID: <20090819002253.esfhmrovogc44gcg@mail.elegosoft.com> Quoting Olaf Wagner : > Why does building m3gdb now even fail on FreeBSD for some time? > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-FreeBSD4/107/testReport/ Something surprising every day: checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... configure: error: ls -t appears to fail. Make sure there is not a broken alias in your environment configure: error: newly created file is older than distributed files! Check your system clock gmake[1]: *** [configure-bfd] Error 1 gmake[1]: Leaving directory `/ad0e/home/hudson/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb/FreeBSD4' gmake: *** [all] Error 2 "/ad0e/home/hudson/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb/src/m3makefile", line 84: quake runtime error: exit 2: gmake CFLAGS="-g" MAKEINFO=echo --procedure-- -line- -file--- exec -- m3gdb_Run 84 /ad0e/home/hudson/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb/src/m3makefile include_dir 123 /ad0e/home/hudson/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb/src/m3makefile 4 /ad0e/home/hudson/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb/FreeBSD4/m3make.args Fatal Error: package build failed ls is aliased to `ls -F' luthien [~/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb] hudson % ls -t "-F" is not a file or directory. "-t" is not a file or directory. luthien [~/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb] hudson % unalias ls luthien [~/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb] hudson % ls -t "-t" is not a file or directory. luthien [~/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb] hudson % ls . ----------- CVS directory gdb directory src directory .cvsignore file (length =516) DESC file (length =56) PkgTags file (length =76) FreeBSD4 directory luthien [~/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb] hudson % type ls ls is hashed (/ad0e/home/hudson/work/cm3-inst/luthien/last-ok/bin/ls) Since when do we provide our own ls? Oh, I see, it's probably one of the examples that should never have been shipped... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Wed Aug 19 00:32:50 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 19 Aug 2009 00:32:50 +0200 Subject: [M3devel] m3gdb build errors In-Reply-To: <20090819002253.esfhmrovogc44gcg@mail.elegosoft.com> References: <20090818172556.ktlh757rc4gg440o@mail.elegosoft.com> <20090819002253.esfhmrovogc44gcg@mail.elegosoft.com> Message-ID: <20090819003250.go8ismls04kogg44@mail.elegosoft.com> Hm, my mails seem to get truncated too, now. Quoting Olaf Wagner : > Quoting Olaf Wagner : > "-t" is not a file or directory. > luthien [~/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb] hudson > % ls Why has this ls been shipped to bin though? The makefile says ./m3-sys/cm3ide/src/examples/files/src/m3makefile:program ("ls") Has anybody changed the shipping semantics? If yes, it is an incompatible change which should be reverted. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Aug 19 01:27:03 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Tue, 18 Aug 2009 16:27:03 -0700 Subject: [M3devel] m3gdb build errors In-Reply-To: <20090819003250.go8ismls04kogg44@mail.elegosoft.com> References: <20090818172556.ktlh757rc4gg440o@mail.elegosoft.com> <20090819002253.esfhmrovogc44gcg@mail.elegosoft.com> <20090819003250.go8ismls04kogg44@mail.elegosoft.com> Message-ID: <4CA7696C-C79F-4E9F-BC0D-5F68566679BC@hotmail.com> I agree that would be wrong. The no-resolution changes? (case sensitivity is too subtle I think but I've known about it) - Jay (phone) On Aug 18, 2009, at 3:32 PM, Olaf Wagner wrote: > Hm, my mails seem to get truncated too, now. > > Quoting Olaf Wagner : > >> Quoting Olaf Wagner : >> "-t" is not a file or directory. >> luthien [~/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb] >> hudson >> % ls > > Why has this ls been shipped to bin though? The makefile says > > ./m3-sys/cm3ide/src/examples/files/src/m3makefile:program ("ls") > > Has anybody changed the shipping semantics? If yes, it is an > incompatible change which should be reverted. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ > any > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be > rlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > From jay.krell at cornell.edu Wed Aug 19 05:46:36 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 19 Aug 2009 03:46:36 +0000 Subject: [M3devel] m3gdb build errors In-Reply-To: <20090819003250.go8ismls04kogg44@mail.elegosoft.com> References: <20090818172556.ktlh757rc4gg440o@mail.elegosoft.com> <20090819002253.esfhmrovogc44gcg@mail.elegosoft.com> <20090819003250.go8ismls04kogg44@mail.elegosoft.com> Message-ID: > Hm, my mails seem to get truncated too, now. I think this is a matter of playing the odds. The more mail you send, the more frequently you send, the longer the mails, the more likely they are to be truncated. - Jay ---------------------------------------- > Date: Wed, 19 Aug 2009 00:32:50 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] m3gdb build errors > > Hm, my mails seem to get truncated too, now. > > Quoting Olaf Wagner : > >> Quoting Olaf Wagner : >> "-t" is not a file or directory. >> luthien [~/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb] hudson >> % ls > > Why has this ls been shipped to bin though? The makefile says > > ./m3-sys/cm3ide/src/examples/files/src/m3makefile:program ("ls") > > Has anybody changed the shipping semantics? If yes, it is an > incompatible change which should be reverted. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From wagner at elegosoft.com Wed Aug 19 08:47:12 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 19 Aug 2009 08:47:12 +0200 Subject: [M3devel] Wrong shipping needs investigation, was: Re: m3gdb build errors In-Reply-To: <4CA7696C-C79F-4E9F-BC0D-5F68566679BC@hotmail.com> References: <20090818172556.ktlh757rc4gg440o@mail.elegosoft.com> <20090819002253.esfhmrovogc44gcg@mail.elegosoft.com> <20090819003250.go8ismls04kogg44@mail.elegosoft.com> <4CA7696C-C79F-4E9F-BC0D-5F68566679BC@hotmail.com> Message-ID: <20090819084712.deqwnkyk0s488go8@mail.elegosoft.com> Quoting jay.krell at cornell.edu: > I agree that would be wrong. The no-resolution changes? (case > sensitivity is too subtle I think but I've known about it) I thought so, too. but it is at least not obvious. The implementation of program and Program looks innocent enough, and the diffs to 2009-07-15 don't bring up anything related. At least in m3-sys/cm3. Perhaps it's a side-effect of another package? But how could this be? Can anybody investigate this further? If we don't fix it soon, RC3 won't be ready at the weekend, as building packages for all platforms takes rather long. We also need to add some tests for the correct contents of shipping files to m3-sys/m3tests. Any volunteers there? Olaf PS: I'm off to work now and not home again until tomorrow evening. Connectivity will be infrequent and slow. PPS: I've opened ticket #1060 for this. > - Jay (phone) >> Quoting Olaf Wagner : >> >>> Quoting Olaf Wagner : >>> "-t" is not a file or directory. >>> luthien [~/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb] hudson >>> % ls >> >> Why has this ls been shipped to bin though? The makefile says >> >> ./m3-sys/cm3ide/src/examples/files/src/m3makefile:program ("ls") >> >> Has anybody changed the shipping semantics? If yes, it is an >> incompatible change which should be reverted. -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Wed Aug 19 21:22:47 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 19 Aug 2009 21:22:47 +0200 Subject: [M3devel] m3gdb build errors In-Reply-To: <20090819003250.go8ismls04kogg44@mail.elegosoft.com> References: <20090818172556.ktlh757rc4gg440o@mail.elegosoft.com> <20090819002253.esfhmrovogc44gcg@mail.elegosoft.com> <20090819003250.go8ismls04kogg44@mail.elegosoft.com> Message-ID: <20090819212247.xlgbut6jtcccs0sw@mail.elegosoft.com> Quoting Olaf Wagner : > Hm, my mails seem to get truncated too, now. > > Quoting Olaf Wagner : > >> Quoting Olaf Wagner : >> "-t" is not a file or directory. >> luthien [~/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb] hudson >> % ls > > Why has this ls been shipped to bin though? The makefile says > > ./m3-sys/cm3ide/src/examples/files/src/m3makefile:program ("ls") > > Has anybody changed the shipping semantics? If yes, it is an > incompatible change which should be reverted. This is a strange day. I don't seem to be able to reproduce this any more. If I hadn't saved the .M3SHIP file in the ticket I'd say I was still dreaming this morning. Has anybody fixed it already? Ah, browsing the changelog I find this: 2009-08-19 13:06 jkrell * m3-sys/cminstall/src/config-no-install/: NT386.common, cm3cfg.common: manual merge from release_branch_cm3_5_8 to head: let cm3 decide where to ship stuff -- not everything goes to BinInstall So it was only in the config files? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Aug 19 21:56:10 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 19 Aug 2009 19:56:10 +0000 Subject: [M3devel] m3gdb build errors In-Reply-To: <20090819212247.xlgbut6jtcccs0sw@mail.elegosoft.com> References: <20090818172556.ktlh757rc4gg440o@mail.elegosoft.com> <20090819002253.esfhmrovogc44gcg@mail.elegosoft.com> <20090819003250.go8ismls04kogg44@mail.elegosoft.com> <20090819212247.xlgbut6jtcccs0sw@mail.elegosoft.com> Message-ID: Yes it was in the config files. Only if skip_ was called -- you have to run cm3 twice or such. - Jay ---------------------------------------- > Date: Wed, 19 Aug 2009 21:22:47 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] m3gdb build errors > > Quoting Olaf Wagner : > >> Hm, my mails seem to get truncated too, now. >> >> Quoting Olaf Wagner : >> >>> Quoting Olaf Wagner : >>> "-t" is not a file or directory. >>> luthien [~/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb] hudson >>> % ls >> >> Why has this ls been shipped to bin though? The makefile says >> >> ./m3-sys/cm3ide/src/examples/files/src/m3makefile:program ("ls") >> >> Has anybody changed the shipping semantics? If yes, it is an >> incompatible change which should be reverted. > > This is a strange day. I don't seem to be able to reproduce this > any more. If I hadn't saved the .M3SHIP file in the ticket I'd > say I was still dreaming this morning. > > Has anybody fixed it already? > > Ah, browsing the changelog I find this: > > 2009-08-19 13:06 jkrell > > * m3-sys/cminstall/src/config-no-install/: NT386.common, cm3cfg.common: > > manual merge from release_branch_cm3_5_8 to head: let cm3 decide > where to ship stuff -- not everything goes to BinInstall > > So it was only in the config files? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Wed Aug 19 22:44:26 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 19 Aug 2009 20:44:26 +0000 Subject: [M3devel] m3gdb build errors In-Reply-To: <20090819212247.xlgbut6jtcccs0sw@mail.elegosoft.com> References: <20090818172556.ktlh757rc4gg440o@mail.elegosoft.com> <20090819002253.esfhmrovogc44gcg@mail.elegosoft.com> <20090819003250.go8ismls04kogg44@mail.elegosoft.com> <20090819212247.xlgbut6jtcccs0sw@mail.elegosoft.com> Message-ID: ps: There's a related small NT specific problem where the symbols -- the .pdb file -- always gets shipped to the bin directory, whereas the intent was to ship next to the binary. I believe the fix is to move the code, very few lines, into cm3. The catch I couldn't solve right away is that the file isn't always present, even on NT, depending on config file details, so it's probably best done "only if exists", ignoring the corner case where it existed in an earlier run, config file changed, doesn't exist in later run -- though that can be dealt with too by deleting the destination if the source doesn't exist. I don't think we have a CopyIfExists primitive though. I can add one. The name should probaby be different to reflect...you know..like... CopyIfExistsElseDeleteDestination?? - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Subject: RE: [M3devel] m3gdb build errors > Date: Wed, 19 Aug 2009 19:56:10 +0000 > > > Yes it was in the config files. > Only if skip_ was called -- you have to run cm3 twice or such. > > - Jay > > > ---------------------------------------- >> Date: Wed, 19 Aug 2009 21:22:47 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] m3gdb build errors >> >> Quoting Olaf Wagner : >> >>> Hm, my mails seem to get truncated too, now. >>> >>> Quoting Olaf Wagner : >>> >>>> Quoting Olaf Wagner : >>>> "-t" is not a file or directory. >>>> luthien [~/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb] hudson >>>> % ls >>> >>> Why has this ls been shipped to bin though? The makefile says >>> >>> ./m3-sys/cm3ide/src/examples/files/src/m3makefile:program ("ls") >>> >>> Has anybody changed the shipping semantics? If yes, it is an >>> incompatible change which should be reverted. >> >> This is a strange day. I don't seem to be able to reproduce this >> any more. If I hadn't saved the .M3SHIP file in the ticket I'd >> say I was still dreaming this morning. >> >> Has anybody fixed it already? >> >> Ah, browsing the changelog I find this: >> >> 2009-08-19 13:06 jkrell >> >> * m3-sys/cminstall/src/config-no-install/: NT386.common, cm3cfg.common: >> >> manual merge from release_branch_cm3_5_8 to head: let cm3 decide >> where to ship stuff -- not everything goes to BinInstall >> >> So it was only in the config files? >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> From wagner at elegosoft.com Thu Aug 20 08:58:07 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 20 Aug 2009 08:58:07 +0200 Subject: [M3devel] m3gdb build errors In-Reply-To: References: <20090818172556.ktlh757rc4gg440o@mail.elegosoft.com> <20090819002253.esfhmrovogc44gcg@mail.elegosoft.com> <20090819003250.go8ismls04kogg44@mail.elegosoft.com> <20090819212247.xlgbut6jtcccs0sw@mail.elegosoft.com> Message-ID: <20090820085807.qxd84gjkcg40g4cg@mail.elegosoft.com> Quoting Jay K : > ps: There's a related small NT specific problem where the symbols -- > the .pdb file -- always gets shipped to the bin directory, whereas > the intent was to ship next to the binary. I believe the fix is to > move the code, very few lines, into cm3. The catch I couldn't solve > right away is that the file isn't always present, even on NT, > depending on config file details, so it's probably best done "only > if exists", ignoring the corner case where it existed in an earlier > run, config file changed, doesn't exist in later run -- though that > can be dealt with too by deleting the destination if the source > doesn't exist. I don't think we have a CopyIfExists primitive > though. I can add one. The name should probaby be different to > reflect...you know..like... CopyIfExistsElseDeleteDestination?? Can you please add a reference to the fix to the ticket, and the above information, too? If we need a complex installation function, we can add it, but perhaps somebody can suggest a better name? Olaf > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com; m3devel at elegosoft.com >> Subject: RE: [M3devel] m3gdb build errors >> Date: Wed, 19 Aug 2009 19:56:10 +0000 >> >> >> Yes it was in the config files. >> Only if skip_ was called -- you have to run cm3 twice or such. >> >> - Jay >> >> ---------------------------------------- >>> Date: Wed, 19 Aug 2009 21:22:47 +0200 >>> From: wagner at elegosoft.com >>> To: m3devel at elegosoft.com >>> Subject: Re: [M3devel] m3gdb build errors >>> >>> Quoting Olaf Wagner : >>> >>>> Hm, my mails seem to get truncated too, now. >>>> >>>> Quoting Olaf Wagner : >>>> >>>>> Quoting Olaf Wagner : >>>>> "-t" is not a file or directory. >>>>> luthien [~/workspace/cm3-test-all-pkgs-FreeBSD4/cm3/m3-sys/m3gdb] hudson >>>>> % ls >>>> >>>> Why has this ls been shipped to bin though? The makefile says >>>> >>>> ./m3-sys/cm3ide/src/examples/files/src/m3makefile:program ("ls") >>>> >>>> Has anybody changed the shipping semantics? If yes, it is an >>>> incompatible change which should be reverted. >>> >>> This is a strange day. I don't seem to be able to reproduce this >>> any more. If I hadn't saved the .M3SHIP file in the ticket I'd >>> say I was still dreaming this morning. >>> >>> Has anybody fixed it already? >>> >>> Ah, browsing the changelog I find this: >>> >>> 2009-08-19 13:06 jkrell >>> >>> * m3-sys/cminstall/src/config-no-install/: NT386.common, cm3cfg.common: >>> >>> manual merge from release_branch_cm3_5_8 to head: let cm3 decide >>> where to ship stuff -- not everything goes to BinInstall >>> >>> So it was only in the config files? -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Thu Aug 20 09:03:54 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 20 Aug 2009 09:03:54 +0200 Subject: [M3devel] Trac/CVS/Hudson integration Message-ID: <20090820090354.pki6jxajokgsgwo0@mail.elegosoft.com> If you commit a fix for a change related to a ticket in trac, you should add the ticket number in the form # to the commit message. Then Hudson (and other tools) will be able to cross-reference tickets and version changes. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Aug 20 11:45:21 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 20 Aug 2009 09:45:21 +0000 Subject: [M3devel] formedit crash Message-ID: Just a note that I have 5.4.0 running on Solaris. I've run its formsedit many times, never a crash. It crashes at least 10% of the time in the current tree. I tried copying all the "nearby" code, that merely turned my assertion back into SIGSEGV. Indeed the nearby diffs are not significant. - Jay From jay.krell at cornell.edu Thu Aug 20 11:55:07 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 20 Aug 2009 09:55:07 +0000 Subject: [M3devel] @M3paranoidgc always crashes Message-ID: Verified on SOLgnu and AMD64_LINUX. Probably related to initialization order changes that let user threads work again. Probably should just use untraced? % gdb --args ./cm3 @M3paranoidgc GNU gdb 6.4.90-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run Starting program: /home/jkrell/cm3/bin/cm3 @M3paranoidgc [Thread debugging using libthread_db enabled] [New Thread 47899659458256 (LWP 29607)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 47899659458256 (LWP 29607)] 0x00000000006934c5 in RTAllocator__GetTracedObj (M3_Eic7CK_def=Cannot access mem ory at address 0x800028d97718 ) at ../src/runtime/common/RTAllocator.m3:221 221 INC(thread.inCritical); (gdb) bt #0 0x00000000006934c5 in RTAllocator__GetTracedObj (M3_Eic7CK_def=Cannot access memory at address 0x800028d97718 ) at ../src/runtime/common/RTAllocator.m3:221 #1 0x0000000000692e1f in RTHooks__AllocateTracedObj (M3_AJWxb1_defn=Cannot acce ss memory at address 0x800028d97788 ) at ../src/runtime/common/RTAllocator.m3:120 #2 0x000000000069b3ae in RTCollector__InstallSanityCheck () at ../src/runtime/common/RTCollector.m3:1637 #3 0x00000000006a1747 in RTHeapRep__Init () at ../src/runtime/common/RTCollector.m3:2769 #4 0x00000000006a2a1d in RTLinker__InitRuntime (M3_AcxOUs_p_argc=Cannot access memory at address 0x800028d97858 ) at ../src/runtime/common/RTLinker.m3:58 #5 0x00000000004160bc in main (argc=Cannot access memory at address 0x800028d97 8a8 ) at _m3main.mc:3 (gdb) From hosking at cs.purdue.edu Thu Aug 20 16:03:19 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 20 Aug 2009 10:03:19 -0400 Subject: [M3devel] @M3paranoidgc always crashes In-Reply-To: References: Message-ID: Indeed, the use of paranoidgc itself now seems to be broken (independently of any other bug you might be trying to track down by invoking paranoidgc). This is a serious bug, that should be rectified *before* any release. Without it, we cannot easily diagnose GC bugs in the field. I have little to no time to devote to this right now, but it does look like the recent changes to threading initialisation has broken things. I remember being very careful about initialization of threads and heap components of the run-time when working on the original native threads. In particular, the ability to invoke ThreadF.GetActivation was allowed before ThreadF.Init had been called, because ThreadF.InitActivations was able to be invoked on-demand independently of ThreadF.Init. This independence now seems to have been eliminated so as to eliminate a run-time check in GetActivation. On 20 Aug 2009, at 05:55, Jay K wrote: > > Verified on SOLgnu and AMD64_LINUX. > Probably related to initialization order changes that let user > threads work again. > Probably should just use untraced? > > > > % gdb --args ./cm3 @M3paranoidgc > GNU gdb 6.4.90-debian > Copyright (C) 2006 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and > you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "x86_64-linux-gnu"...Using host > libthread_db library > "/lib/libthread_db.so.1". > (gdb) run > Starting program: /home/jkrell/cm3/bin/cm3 @M3paranoidgc > [Thread debugging using libthread_db enabled] > [New Thread 47899659458256 (LWP 29607)] > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 47899659458256 (LWP 29607)] > 0x00000000006934c5 in RTAllocator__GetTracedObj > (M3_Eic7CK_def=Cannot access mem > ory at address 0x800028d97718 > ) > at ../src/runtime/common/RTAllocator.m3:221 > 221 INC(thread.inCritical); > (gdb) bt > #0 0x00000000006934c5 in RTAllocator__GetTracedObj > (M3_Eic7CK_def=Cannot access > memory at address 0x800028d97718 > ) > at ../src/runtime/common/RTAllocator.m3:221 > #1 0x0000000000692e1f in RTHooks__AllocateTracedObj > (M3_AJWxb1_defn=Cannot acce > ss memory at address 0x800028d97788 > ) > at ../src/runtime/common/RTAllocator.m3:120 > #2 0x000000000069b3ae in RTCollector__InstallSanityCheck () > at ../src/runtime/common/RTCollector.m3:1637 > #3 0x00000000006a1747 in RTHeapRep__Init () > at ../src/runtime/common/RTCollector.m3:2769 > #4 0x00000000006a2a1d in RTLinker__InitRuntime > (M3_AcxOUs_p_argc=Cannot access > memory at address 0x800028d97858 > ) > at ../src/runtime/common/RTLinker.m3:58 > #5 0x00000000004160bc in main (argc=Cannot access memory at address > 0x800028d97 > 8a8 > ) at _m3main.mc:3 > (gdb) > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Thu Aug 20 16:37:31 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 20 Aug 2009 16:37:31 +0200 Subject: [M3devel] SYSTEM_LIBS, quake, ./configure Message-ID: <1250779051.3002.6.camel@faramir.m3w.org> In this ticket, https://projects.elego.de/cm3/ticket/1048, cvsup problem with libz on some systems is described. But, that problem is bigger than this - whole C portability issue. We need quake standardized way for locating (or not allocating:) system libraries. That way, it'll be possible to have Modula-3 programs and libraries which depend on C libraries like.... expat, tidy, mysqlclient, sqlite... distributed as wide as cm3 is. This is solvable with some quake magic? -- Dragi?a Duri? From wagner at elegosoft.com Thu Aug 20 17:07:37 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 20 Aug 2009 17:07:37 +0200 Subject: [M3devel] SYSTEM_LIBS, quake, ./configure In-Reply-To: <1250779051.3002.6.camel@faramir.m3w.org> References: <1250779051.3002.6.camel@faramir.m3w.org> Message-ID: <20090820170737.xlylo4e268oo480o@mail.elegosoft.com> Quoting Dragi?a Duri? : > In this ticket, https://projects.elego.de/cm3/ticket/1048, cvsup problem > with libz on some systems is described. But, that problem is bigger than > this - whole C portability issue. > > We need quake standardized way for locating (or not allocating:) system > libraries. That way, it'll be possible to have Modula-3 programs and > libraries which depend on C libraries like.... expat, tidy, mysqlclient, > sqlite... distributed as wide as cm3 is. > > This is solvable with some quake magic? This kind of configure-function was part of the old CM3 installer, but has become unused now, because Jay insists that it is unnecessary. I don't think this should be a quake function executed at compile time. Interfaces to a well-known set of system libraries are contained in the config files. A quake definition of such a function would necessarily be system- dependent, as it would need to know about all standard locations to search on a certain platform. Or search all known locations, but then the problem of resolving multiple hits comes up... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Thu Aug 20 17:10:58 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 20 Aug 2009 17:10:58 +0200 Subject: [M3devel] @M3paranoidgc always crashes In-Reply-To: References: Message-ID: <20090820171058.0stkh5eu68cw0ksk@mail.elegosoft.com> Quoting Tony Hosking : > Indeed, the use of paranoidgc itself now seems to be broken > (independently of any other bug you might be trying to track down by > invoking paranoidgc). > This is a serious bug, that should be rectified *before* any release. > Without it, we cannot easily diagnose GC bugs in the field. I have > little to no time to devote to this right now, but it does look like > the recent changes to threading initialisation has broken things. I > remember being very careful about initialization of threads and heap > components of the run-time when working on the original native > threads. In particular, the ability to invoke ThreadF.GetActivation > was allowed before ThreadF.Init had been called, because > ThreadF.InitActivations was able to be invoked on-demand independently > of ThreadF.Init. This independence now seems to have been eliminated > so as to eliminate a run-time check in GetActivation. Jay, could you open a ticket for that, too? And we also need to add tests for running with various @M3 options... Olaf > > On 20 Aug 2009, at 05:55, Jay K wrote: > >> >> Verified on SOLgnu and AMD64_LINUX. >> Probably related to initialization order changes that let user >> threads work again. >> Probably should just use untraced? >> >> >> >> % gdb --args ./cm3 @M3paranoidgc >> GNU gdb 6.4.90-debian >> Copyright (C) 2006 Free Software Foundation, Inc. >> GDB is free software, covered by the GNU General Public License, >> and you are >> welcome to change it and/or distribute copies of it under certain >> conditions. >> Type "show copying" to see the conditions. >> There is absolutely no warranty for GDB. Type "show warranty" for details. >> This GDB was configured as "x86_64-linux-gnu"...Using host >> libthread_db library >> "/lib/libthread_db.so.1". >> (gdb) run >> Starting program: /home/jkrell/cm3/bin/cm3 @M3paranoidgc >> [Thread debugging using libthread_db enabled] >> [New Thread 47899659458256 (LWP 29607)] >> Program received signal SIGSEGV, Segmentation fault. >> [Switching to Thread 47899659458256 (LWP 29607)] >> 0x00000000006934c5 in RTAllocator__GetTracedObj >> (M3_Eic7CK_def=Cannot access mem >> ory at address 0x800028d97718 >> ) >> at ../src/runtime/common/RTAllocator.m3:221 >> 221 INC(thread.inCritical); >> (gdb) bt >> #0 0x00000000006934c5 in RTAllocator__GetTracedObj >> (M3_Eic7CK_def=Cannot access >> memory at address 0x800028d97718 >> ) >> at ../src/runtime/common/RTAllocator.m3:221 >> #1 0x0000000000692e1f in RTHooks__AllocateTracedObj >> (M3_AJWxb1_defn=Cannot acce >> ss memory at address 0x800028d97788 >> ) >> at ../src/runtime/common/RTAllocator.m3:120 >> #2 0x000000000069b3ae in RTCollector__InstallSanityCheck () >> at ../src/runtime/common/RTCollector.m3:1637 >> #3 0x00000000006a1747 in RTHeapRep__Init () >> at ../src/runtime/common/RTCollector.m3:2769 >> #4 0x00000000006a2a1d in RTLinker__InitRuntime >> (M3_AcxOUs_p_argc=Cannot access >> memory at address 0x800028d97858 >> ) >> at ../src/runtime/common/RTLinker.m3:58 >> #5 0x00000000004160bc in main (argc=Cannot access memory at >> address 0x800028d97 >> 8a8 >> ) at _m3main.mc:3 >> (gdb) >> >> >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Thu Aug 20 17:26:52 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 20 Aug 2009 11:26:52 -0400 Subject: [M3devel] @M3paranoidgc always crashes In-Reply-To: <20090820171058.0stkh5eu68cw0ksk@mail.elegosoft.com> References: <20090820171058.0stkh5eu68cw0ksk@mail.elegosoft.com> Message-ID: <007DD8EA-4A1C-447A-B8FB-56396A8F6560@cs.purdue.edu> Jay may have fixed this for now. On 20 Aug 2009, at 11:10, Olaf Wagner wrote: > Quoting Tony Hosking : > >> Indeed, the use of paranoidgc itself now seems to be broken >> (independently of any other bug you might be trying to track down by >> invoking paranoidgc). >> This is a serious bug, that should be rectified *before* any release. >> Without it, we cannot easily diagnose GC bugs in the field. I have >> little to no time to devote to this right now, but it does look like >> the recent changes to threading initialisation has broken things. I >> remember being very careful about initialization of threads and heap >> components of the run-time when working on the original native >> threads. In particular, the ability to invoke ThreadF.GetActivation >> was allowed before ThreadF.Init had been called, because >> ThreadF.InitActivations was able to be invoked on-demand >> independently >> of ThreadF.Init. This independence now seems to have been eliminated >> so as to eliminate a run-time check in GetActivation. > > Jay, could you open a ticket for that, too? > > And we also need to add tests for running with various @M3 options... > > Olaf > >> >> On 20 Aug 2009, at 05:55, Jay K wrote: >> >>> >>> Verified on SOLgnu and AMD64_LINUX. >>> Probably related to initialization order changes that let user >>> threads work again. >>> Probably should just use untraced? >>> >>> >>> >>> % gdb --args ./cm3 @M3paranoidgc >>> GNU gdb 6.4.90-debian >>> Copyright (C) 2006 Free Software Foundation, Inc. >>> GDB is free software, covered by the GNU General Public License, >>> and you are >>> welcome to change it and/or distribute copies of it under >>> certain conditions. >>> Type "show copying" to see the conditions. >>> There is absolutely no warranty for GDB. Type "show warranty" >>> for details. >>> This GDB was configured as "x86_64-linux-gnu"...Using host >>> libthread_db library >>> "/lib/libthread_db.so.1". >>> (gdb) run >>> Starting program: /home/jkrell/cm3/bin/cm3 @M3paranoidgc >>> [Thread debugging using libthread_db enabled] >>> [New Thread 47899659458256 (LWP 29607)] >>> Program received signal SIGSEGV, Segmentation fault. >>> [Switching to Thread 47899659458256 (LWP 29607)] >>> 0x00000000006934c5 in RTAllocator__GetTracedObj >>> (M3_Eic7CK_def=Cannot access mem >>> ory at address 0x800028d97718 >>> ) >>> at ../src/runtime/common/RTAllocator.m3:221 >>> 221 INC(thread.inCritical); >>> (gdb) bt >>> #0 0x00000000006934c5 in RTAllocator__GetTracedObj >>> (M3_Eic7CK_def=Cannot access >>> memory at address 0x800028d97718 >>> ) >>> at ../src/runtime/common/RTAllocator.m3:221 >>> #1 0x0000000000692e1f in RTHooks__AllocateTracedObj >>> (M3_AJWxb1_defn=Cannot acce >>> ss memory at address 0x800028d97788 >>> ) >>> at ../src/runtime/common/RTAllocator.m3:120 >>> #2 0x000000000069b3ae in RTCollector__InstallSanityCheck () >>> at ../src/runtime/common/RTCollector.m3:1637 >>> #3 0x00000000006a1747 in RTHeapRep__Init () >>> at ../src/runtime/common/RTCollector.m3:2769 >>> #4 0x00000000006a2a1d in RTLinker__InitRuntime >>> (M3_AcxOUs_p_argc=Cannot access >>> memory at address 0x800028d97858 >>> ) >>> at ../src/runtime/common/RTLinker.m3:58 >>> #5 0x00000000004160bc in main (argc=Cannot access memory at >>> address 0x800028d97 >>> 8a8 >>> ) at _m3main.mc:3 >>> (gdb) >>> >>> >>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lchretien at mac.com Thu Aug 20 20:57:36 2009 From: lchretien at mac.com (Louis =?ISO-8859-1?B?Q2hy6XRpZW4=?=) Date: Thu, 20 Aug 2009 14:57:36 -0400 Subject: [M3devel] A question about the M3 licensing... Message-ID: I remember reading on this list (or was it the website...) that the way the licensing of Modula-3 is written, it would make it incompatible/impossible to merge this project with the GCC front-end from the GCC foundation, the way that GNU Ada was incorporated into that project. Because M3 uses a modified GCC code generator, it would have a made sense to go that way. But another, intriguing possibility exists: the LLVM project (http://www.llvm.org). It looks like a very high-performance, optimizing, multiple target infrastructure, that would make Modula-3 highly portable. I'm sure i'm not the first to think of this, but what are the obstacle to porting M3 to that environment (apart from the obvious effort in programming required... ;-))) -- Louis Chr?tien lchretien at mac.com From mbishop at esoteriq.org Thu Aug 20 22:30:06 2009 From: mbishop at esoteriq.org (Martin Bishop) Date: Thu, 20 Aug 2009 15:30:06 -0500 Subject: [M3devel] A question about the M3 licensing... In-Reply-To: References: Message-ID: <4A8DB24E.7010807@esoteriq.org> I definitely wondered about getting CM3 to use LLVM as well. I have none of the skills required to make it happen, but just wondered about doing so. LLVM is the "hot thing" now (deservedly so) and it would be nice if Modula-3 could get a little bit of life in it by association. Louis Chr?tien wrote: > I remember reading on this list (or was it the website...) that the way the > licensing of Modula-3 is written, it would make it incompatible/impossible > to merge this project with the GCC front-end from the GCC foundation, the > way that GNU Ada was incorporated into that project. > > Because M3 uses a modified GCC code generator, it would have a made sense to > go that way. > > But another, intriguing possibility exists: the LLVM project > (http://www.llvm.org). It looks like a very high-performance, optimizing, > multiple target infrastructure, that would make Modula-3 highly portable. > > I'm sure i'm not the first to think of this, but what are the obstacle to > porting M3 to that environment (apart from the obvious effort in programming > required... ;-))) > > -- > Louis Chr?tien > lchretien at mac.com > > > > From hosking at cs.purdue.edu Thu Aug 20 23:50:16 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 20 Aug 2009 17:50:16 -0400 Subject: [M3devel] A question about the M3 licensing... In-Reply-To: References: Message-ID: <1F753DA1-D9A2-46C5-B490-8F4D08A4392F@cs.purdue.edu> Yes, I have thought that this would be a great idea for some time now. Similarly for .NET. The only obstacle of course is time... :-) On 20 Aug 2009, at 14:57, Louis Chr?tien wrote: > I remember reading on this list (or was it the website...) that the > way the > licensing of Modula-3 is written, it would make it incompatible/ > impossible > to merge this project with the GCC front-end from the GCC > foundation, the > way that GNU Ada was incorporated into that project. > > Because M3 uses a modified GCC code generator, it would have a made > sense to > go that way. > > But another, intriguing possibility exists: the LLVM project > (http://www.llvm.org). It looks like a very high-performance, > optimizing, > multiple target infrastructure, that would make Modula-3 highly > portable. > > I'm sure i'm not the first to think of this, but what are the > obstacle to > porting M3 to that environment (apart from the obvious effort in > programming > required... ;-))) > > -- > Louis Chr?tien > lchretien at mac.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.m.bates at cox.net Thu Aug 20 22:37:21 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Thu, 20 Aug 2009 15:37:21 -0500 Subject: [M3devel] How to update tickets myself Message-ID: <4A8DB401.2020209@cox.net> I just checked in fixed to ticket #1058. How can I access the ticket system and update it myself? Sorry, I forgot the # before the ticket number in the commit message. Rodney Bates From hendrik at topoi.pooq.com Fri Aug 21 01:48:26 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 20 Aug 2009 19:48:26 -0400 Subject: [M3devel] A question about the M3 licensing... In-Reply-To: References: Message-ID: <20090820234825.GB3925@topoi.pooq.com> On Thu, Aug 20, 2009 at 02:57:36PM -0400, Louis Chr?tien wrote: > I remember reading on this list (or was it the website...) that the way the > licensing of Modula-3 is written, it would make it incompatible/impossible > to merge this project with the GCC front-end from the GCC foundation, the > way that GNU Ada was incorporated into that project. > > Because M3 uses a modified GCC code generator, it would have a made sense to > go that way. > > But another, intriguing possibility exists: the LLVM project > (http://www.llvm.org). It looks like a very high-performance, optimizing, > multiple target infrastructure, that would make Modula-3 highly portable. I looked into LLVM for another language, with the idea of using its in-memory interface and constructing the parse tree directly. It turns out that it does type calculation during parse tree construction. THe result is that any type I want to use has to be completely defined before I can use it anywhere in the parse tree I'm trying to build. For compiler-synthesized records whose fields are invented while generating the intermediate code that uses them, this turned out to be an unacceptable ordering constraint. There are ways around this by storing the entire intermediate code in RAM as a kind of insertable-text data structure, and then writing it all to a disk file, and then having the LLVM back end read that file .... but it got messy. > > I'm sure i'm not the first to think of this, but what are the obstacle to > porting M3 to that environment (apart from the obvious effort in programming > required... ;-))) I suppose there's another possibility -- writing a new M3 front end with a different licence, and being free of SRC forever. Except that if some of our libraries are compiled from SRC source code, will we have to compile at installation tiem to avould distributing mixed GNU/SRC binaries? -- hendrik From hendrik at topoi.pooq.com Fri Aug 21 02:04:29 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 20 Aug 2009 20:04:29 -0400 Subject: [M3devel] Using LLVM (WAS; A question about the M3 licensing...) In-Reply-To: <20090820234825.GB3925@topoi.pooq.com> References: <20090820234825.GB3925@topoi.pooq.com> Message-ID: <20090821000429.GC3925@topoi.pooq.com> On Thu, Aug 20, 2009 at 07:48:26PM -0400, hendrik at topoi.pooq.com wrote: > > I looked into LLVM for another language, with the idea of using its > in-memory interface and constructing the parse tree directly. It turns > out that it does type calculation during parse tree construction. THe > result is that any type I want to use has to be completely defined > before I can use it anywhere in the parse tree I'm trying to build. For > compiler-synthesized records whose fields are invented while generating > the intermediate code that uses them, this turned out to be an > unacceptable ordering constraint. > > There are ways around this by storing the entire intermediate code in > RAM as a kind of insertable-text data structure, and then writing it all > to a disk file, and then having the LLVM back end read that file .... > but it got messy. By the way, I ended up using C-- for the project, which looks like a better-designed langauge, but with less of an organisation backing it for when things go wrong. I ended uo using the insertable-text data structure to generate the C-- code, too. But at least C-- was designed to have the text file be the primary form of inout; LLVM was designed to have parse trees built in RAM by the front end. -- hendrik. From jay.krell at cornell.edu Fri Aug 21 10:03:11 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 21 Aug 2009 08:03:11 +0000 Subject: [M3devel] SYSTEM_LIBS, quake, ./configure In-Reply-To: <20090820170737.xlylo4e268oo480o@mail.elegosoft.com> References: <1250779051.3002.6.camel@faramir.m3w.org> <20090820170737.xlylo4e268oo480o@mail.elegosoft.com> Message-ID: I know I'm guilty, and I'm a little on the fence. I think /maybe/ we should have m3-sys/cminstall/src/config-no-install/Solaris.libraries m3-sys/cminstall/src/config-no-install/Linux.libraries m3-sys/cminstall/src/config-no-install/NetBSD.libraries m3-sys/cminstall/src/config-no-install/OpenBSD.libraries m3-sys/cminstall/src/config-no-install/FreeBSD.libraries m3-sys/cminstall/src/config-no-install/IRIX.libraries m3-sys/cminstall/src/config-no-install/HPUX.libraries etc. and in packages we'd copy one of these to /usr/local/cm3/bin/config/cm3cfg.libraries so that we'd maintain the "codify the 'standard' locations" while also easing custom editing. More generally there's probably install/cm3/bin/config/libraries/*.quake. X11.quake c.quake ODBC.quake z.quake possibly install/cm3/bin/config/libraries/TARGET/*.quake. possibly probe between them. Each one or two lines. m3makefile dependent on ODBC would read: UseLibrary("X11") and/or UseLibraries(["X11", "ODBC"]) proc UseLibraries(a) is foreach b in a local c = CONFIG_ROOT & "/" & a & ".quake" if exists(c) include(c) else print("WARNING: not building package " & package_name & " because library " & a " is missing)" inform_cm3_to_skip_current_directory() end end proc UseLibrary(a) is UseLibraries([a]) end cm3 and scripts would have switches like: -error-for-missing-libraries -error-for-missing-library:X11 -ignore-missing-libraries -ignore-missing-libraries:X11,ODBC -ignore-missing-library:X11 and where I have print above, well, more like: inform_cm3_of_missing_library(a) but for that matter, move all the logic to cm3 probably. Probably should be using Modula-3 more and Quake less. But it's just so adequate and reasonably pleasant.. As well, need to consider what the "two level" aspect of the current design allows for and how to preserve that. I think it is "how to link library FOO" and "what global order to link libraries in". What I find ambiguous is code that checks for presence in SYSTEM_LIBORDER or SYSTEM_LIBRARIES. Seems to me like, probably, their members should always be the same? (The keys in one should be the members in the other and vice versa). ?? There are like three main scenarios I think. - It is a "package" available on the system, and therefore in a known platform specific location on the vast majority of systems. e.g. /usr on Debian, /usr/pkg on NetBSD, /usr/local on FreeBSD, /usr/sfw or /opt on Solaris. - It may or may not be an available package and user builds it from source and it goes to the library owner's default, usually /usr/local - Sometimes this is the same as the first. - User builds it from source and it goes to the system owner's preference. I have really only catered to the first. And since I emphasize folding common code, the other two have suffered. There is also the possibility of knowing about "pkgconfig". Which only solves the problem for packages that use it. Similarly I'm on the fence regarding autoconf and/or its approach. Autoconf seems quite messy and slow, but doing similar sorts of things in Quake hasn't seemed so bad. - Jay > Date: Thu, 20 Aug 2009 17:07:37 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] SYSTEM_LIBS, quake, ./configure > > Quoting Dragi?a Duri? : > > > In this ticket, https://projects.elego.de/cm3/ticket/1048, cvsup problem > > with libz on some systems is described. But, that problem is bigger than > > this - whole C portability issue. > > > > We need quake standardized way for locating (or not allocating:) system > > libraries. That way, it'll be possible to have Modula-3 programs and > > libraries which depend on C libraries like.... expat, tidy, mysqlclient, > > sqlite... distributed as wide as cm3 is. > > > > This is solvable with some quake magic? > > This kind of configure-function was part of the old CM3 installer, > but has become unused now, because Jay insists that it is unnecessary. > I don't think this should be a quake function executed at compile time. > Interfaces to a well-known set of system libraries are contained in > the config files. > > A quake definition of such a function would necessarily be system- > dependent, as it would need to know about all standard locations to > search on a certain platform. Or search all known locations, but then > the problem of resolving multiple hits comes up... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Aug 21 10:06:14 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 21 Aug 2009 10:06:14 +0200 Subject: [M3devel] How to update tickets myself In-Reply-To: <4A8DB401.2020209@cox.net> References: <4A8DB401.2020209@cox.net> Message-ID: <20090821100614.1hrjhbdou80ggowg@mail.elegosoft.com> Quoting "Rodney M. Bates" : > I just checked in fixed to ticket #1058. How can I > access the ticket system and update it myself? You need to login to trac to view further menu options, but you don't have an account yet as far as I can see. I'll create one for you this evening. Unfortunately the HTTP administration is broken in our trac setup (will be fixed and upgraded when our sysadmin stuff is complete again). > Sorry, I forgot the # > before the ticket number in > the commit message. You can correct/change CVS commit messages with the `cvs admin' command. Use something like cvs admin '-m:message text' Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Fri Aug 21 10:20:56 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 21 Aug 2009 10:20:56 +0200 Subject: [M3devel] A question about the M3 licensing... In-Reply-To: <20090820234825.GB3925@topoi.pooq.com> References: <20090820234825.GB3925@topoi.pooq.com> Message-ID: <20090821102056.nbcql8hsc8ww80cc@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > I suppose there's another possibility -- writing a new M3 front end with > a different licence, and being free of SRC forever. Except that if > some of our libraries are compiled from SRC source code, will we have to > compile at installation tiem to avould distributing mixed GNU/SRC > binaries? I don't think this is correct. The SRC license allows much more than the GNU FSF license. That was exactly the stumbling block when it came to integrating the M3 extensions to gcc into the gcc distribution. The FSF didn't like the way the backend was used in a different process context in order to avoid infecting all compiler code with the FSF license. Of course you can write another compiler front-end under the FSF license. I'd assume this will take several man-years though until you reach the quality of the current system. And any commercial use will then be much more difficult, but this is probably moot regarding the current widespread user base :-) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Aug 21 11:32:31 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 21 Aug 2009 09:32:31 +0000 Subject: [M3devel] A question about the M3 licensing... In-Reply-To: <20090821102056.nbcql8hsc8ww80cc@mail.elegosoft.com> References: <20090820234825.GB3925@topoi.pooq.com> <20090821102056.nbcql8hsc8ww80cc@mail.elegosoft.com> Message-ID: > Of course you can write another compiler front-end under the FSF It's surprising how similar Ada looks to Modula-3.. I've looked into llvm but haven't really got my head around it and/or the cm3 intermediate representation. If I could get my head around the latter I'd really like to try to translate that into C, for better and worse. Gcc relatively recently grew a plugin interface. That might be useful to us. Might -- you know, like, we'd say gcc -plugin-something-somesuch *.mc and gcc would load cm3cg.so or somesuch. Potentially m3-sys/m3cc would drop in size dramatically. - Jay > Date: Fri, 21 Aug 2009 10:20:56 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] A question about the M3 licensing... > > Quoting hendrik at topoi.pooq.com: > > > I suppose there's another possibility -- writing a new M3 front end with > > a different licence, and being free of SRC forever. Except that if > > some of our libraries are compiled from SRC source code, will we have to > > compile at installation tiem to avould distributing mixed GNU/SRC > > binaries? > > I don't think this is correct. The SRC license allows much more than > the GNU FSF license. That was exactly the stumbling block when it came > to integrating the M3 extensions to gcc into the gcc distribution. > The FSF didn't like the way the backend was used in a different process > context in order to avoid infecting all compiler code with the FSF > license. > > Of course you can write another compiler front-end under the FSF > license. I'd assume this will take several man-years though until > you reach the quality of the current system. And any commercial use > will then be much more difficult, but this is probably moot > regarding the current widespread user base :-) > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Fri Aug 21 11:47:16 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 21 Aug 2009 05:47:16 -0400 Subject: [M3devel] A question about the M3 licensing... In-Reply-To: References: <20090820234825.GB3925@topoi.pooq.com> <20090821102056.nbcql8hsc8ww80cc@mail.elegosoft.com> Message-ID: <20090821094716.GA5222@topoi.pooq.com> On Fri, Aug 21, 2009 at 09:32:31AM +0000, Jay K wrote: > > It's surprising how similar Ada looks to Modula-3.. I think they both dated from the same era, and both are ultimately based on Pascal syntax. > I've looked into llvm but haven't really got my head around it and/or > the cm3 intermediate representation. Do you mean the internal parse tree? > If I could get my head around the > latter I'd really like to try to translate that into C, for better and > worse. Didn't there use to be a translator from Modula 3 to C before people gave up on C as not being a good object code language? Wouldn't it still be lurking in anckent CVS branches somewhere? -- hendrik From wagner at elegosoft.com Fri Aug 21 12:18:25 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 21 Aug 2009 12:18:25 +0200 Subject: [M3devel] A question about the M3 licensing... In-Reply-To: References: <20090820234825.GB3925@topoi.pooq.com> <20090821102056.nbcql8hsc8ww80cc@mail.elegosoft.com> Message-ID: <20090821121825.pk6wsoyrb4w4gkgo@mail.elegosoft.com> Quoting Jay K : > > Of course you can write another compiler front-end under the FSF > > It's surprising how similar Ada looks to Modula-3.. > > I've looked into llvm but haven't really got my head around it > and/or the cm3 intermediate representation. If I could get my head > around the latter I'd really like to try to translate that into C, > for better and worse. Perhaps it would be best if we start to document the intermediate code representation. I.e. write a short but useful interface spec? Who would be able and willing to do that? > Gcc relatively recently grew a plugin interface. > > That might be useful to us. Might -- you know, like, we'd say gcc > -plugin-something-somesuch *.mc and gcc would load cm3cg.so or > somesuch. Potentially m3-sys/m3cc would drop in size dramatically. This sounds interesting, too. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Fri Aug 21 12:31:39 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 21 Aug 2009 12:31:39 +0200 Subject: [M3devel] A question about the M3 licensing... In-Reply-To: <20090821094716.GA5222@topoi.pooq.com> References: <20090820234825.GB3925@topoi.pooq.com> <20090821102056.nbcql8hsc8ww80cc@mail.elegosoft.com> <20090821094716.GA5222@topoi.pooq.com> Message-ID: <20090821123139.wy7bo0jhmgwg8s8c@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > On Fri, Aug 21, 2009 at 09:32:31AM +0000, Jay K wrote: >> >> It's surprising how similar Ada looks to Modula-3.. > > I think they both dated from the same era, and both are ultimately based > on Pascal syntax. > >> I've looked into llvm but haven't really got my head around it and/or >> the cm3 intermediate representation. > > Do you mean the internal parse tree? > >> If I could get my head around the >> latter I'd really like to try to translate that into C, for better and >> worse. > > Didn't there use to be a translator from Modula 3 to C before people > gave up on C as not being a good object code language? Wouldn't it > still be lurking in anckent CVS branches somewhere? AFAIK only the first release of M3 used C as intermediate code. Later SRC releases used gcc as backend. I don't know if any of the old archives are still accessible somewhere. SRC never used/provided a public version control system (though they internally had bindings for Vesta AFAIK). (For Vesta, see http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-168.pdf.) So there will be no public record of the old compiler sources in any repository. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dmuysers at hotmail.com Fri Aug 21 13:25:36 2009 From: dmuysers at hotmail.com (Dirk Muysers) Date: Fri, 21 Aug 2009 13:25:36 +0200 Subject: [M3devel] A question about the M3 licensing... In-Reply-To: <20090820234825.GB3925@topoi.pooq.com><20090821102056.nbcql8hsc8ww80cc@mail.elegosoft.com><20090821094716.GA5222@topoi.pooq.com> <20090821123139.wy7bo0jhmgwg8s8c@mail.elegosoft.com> References: <20090820234825.GB3925@topoi.pooq.com><20090821102056.nbcql8hsc8ww80cc@mail.elegosoft.com><20090821094716.GA5222@topoi.pooq.com> <20090821123139.wy7bo0jhmgwg8s8c@mail.elegosoft.com> Message-ID: Have a look at the Klagenfurt site (http://www.cs.tut.fi/lintula/manual/modula3/modula-3/html/m3pc.html) Maybe it still hangs around. If not, I have the source on my hard disk. -------------------------------------------------- From: "Olaf Wagner" Sent: Friday, August 21, 2009 12:31 PM To: Subject: Re: [M3devel] A question about the M3 licensing... > Quoting hendrik at topoi.pooq.com: > >> On Fri, Aug 21, 2009 at 09:32:31AM +0000, Jay K wrote: >>> >>> It's surprising how similar Ada looks to Modula-3.. >> >> I think they both dated from the same era, and both are ultimately based >> on Pascal syntax. >> >>> I've looked into llvm but haven't really got my head around it and/or >>> the cm3 intermediate representation. >> >> Do you mean the internal parse tree? >> >>> If I could get my head around the >>> latter I'd really like to try to translate that into C, for better and >>> worse. >> >> Didn't there use to be a translator from Modula 3 to C before people >> gave up on C as not being a good object code language? Wouldn't it >> still be lurking in anckent CVS branches somewhere? > > AFAIK only the first release of M3 used C as intermediate code. > Later SRC releases used gcc as backend. I don't know if any of > the old archives are still accessible somewhere. > > SRC never used/provided a public version control system (though they > internally had bindings for Vesta AFAIK). > (For Vesta, see > http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-168.pdf.) > > So there will be no public record of the old compiler sources in any > repository. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 > 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > From jay.krell at cornell.edu Fri Aug 21 16:19:18 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 21 Aug 2009 14:19:18 +0000 Subject: [M3devel] lock before or after try? Message-ID: lock try stuff finally unlock end or try lock stuff finally unlock end Lock can't fail so no difference? - Jay From lchretien at mac.com Fri Aug 21 20:35:03 2009 From: lchretien at mac.com (Louis =?ISO-8859-1?B?Q2hy6XRpZW4=?=) Date: Fri, 21 Aug 2009 14:35:03 -0400 Subject: [M3devel] A more precise question about M3 licensing... Message-ID: >From what I gathered so far on this thread, the SRC licence was quite a bit more liberal than the FSF license, which led to this "separate process" business for the code generation phase, which displeased the FSF somewhat... After having read the licence for the LLVM project (a one pager on their website), i find it quite liberal and you can basically do anything with the code, as long as you give proper credit and keep the license with the files. I'm no lawyer, but it seems that the SRC and LLVM licenses could play along fine, as opposed to the FSF trying to "infect" everything it touches... So, here's the idea I had: Combine the existing CM3 (and/or PM3) front-end, and modify it to emit LLVM bytecodes, so that we could use the LLVM back-end and infrastructure to create a complete compiler/linker. Would such a beast, by combining code from both licenses, be viable? I would like to keep the licensing as liberal as possible. I sure would like your ideas on this subject, P.S.: Olaf, I think your suggestion of documenting the existing intermidiate representation of the CM3 compiler would be an absolute first step... -- Louis Chr?tien lchretien at mac.com From wagner at elegosoft.com Fri Aug 21 21:36:52 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 21 Aug 2009 21:36:52 +0200 Subject: [M3devel] @M3paranoidgc always crashes In-Reply-To: <007DD8EA-4A1C-447A-B8FB-56396A8F6560@cs.purdue.edu> References: <20090820171058.0stkh5eu68cw0ksk@mail.elegosoft.com> <007DD8EA-4A1C-447A-B8FB-56396A8F6560@cs.purdue.edu> Message-ID: <20090821213652.nd7w7ddirkwookgk@mail.elegosoft.com> Quoting Tony Hosking : > Jay may have fixed this for now. It seems to be still broken, at least in the release branch. I'm currently adding some tests. Running a simple test program with @M3paranoidgc does not terminate: % ../src/p2/p213/FreeBSD4/pgm `Hello world' and `Hello world' are equal. The length of the first is 11 Extracting four chars from position 3 yields --lo w-- Salut = Hello done. luthien [~/work/cm3/m3-sys/m3tests/src] wagner % ../src/p2/p213/FreeBSD4/pgm @M3paranoidgc *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL^C It only prints half of the message and eats lots of CPU afterwards. I'll open a ticket for it and won't build release packages until it is fixed. Ticket is #1063. Olaf > > On 20 Aug 2009, at 11:10, Olaf Wagner wrote: > >> Quoting Tony Hosking : >> >>> Indeed, the use of paranoidgc itself now seems to be broken >>> (independently of any other bug you might be trying to track down by >>> invoking paranoidgc). >>> This is a serious bug, that should be rectified *before* any release. >>> Without it, we cannot easily diagnose GC bugs in the field. I have >>> little to no time to devote to this right now, but it does look like >>> the recent changes to threading initialisation has broken things. I >>> remember being very careful about initialization of threads and heap >>> components of the run-time when working on the original native >>> threads. In particular, the ability to invoke ThreadF.GetActivation >>> was allowed before ThreadF.Init had been called, because >>> ThreadF.InitActivations was able to be invoked on-demand independently >>> of ThreadF.Init. This independence now seems to have been eliminated >>> so as to eliminate a run-time check in GetActivation. >> >> Jay, could you open a ticket for that, too? >> >> And we also need to add tests for running with various @M3 options... >> >> Olaf >> >>> >>> On 20 Aug 2009, at 05:55, Jay K wrote: >>> >>>> >>>> Verified on SOLgnu and AMD64_LINUX. >>>> Probably related to initialization order changes that let user >>>> threads work again. >>>> Probably should just use untraced? >>>> >>>> >>>> >>>> % gdb --args ./cm3 @M3paranoidgc >>>> GNU gdb 6.4.90-debian >>>> Copyright (C) 2006 Free Software Foundation, Inc. >>>> GDB is free software, covered by the GNU General Public License, >>>> and you are >>>> welcome to change it and/or distribute copies of it under >>>> certain conditions. >>>> Type "show copying" to see the conditions. >>>> There is absolutely no warranty for GDB. Type "show warranty" >>>> for details. >>>> This GDB was configured as "x86_64-linux-gnu"...Using host >>>> libthread_db library >>>> "/lib/libthread_db.so.1". >>>> (gdb) run >>>> Starting program: /home/jkrell/cm3/bin/cm3 @M3paranoidgc >>>> [Thread debugging using libthread_db enabled] >>>> [New Thread 47899659458256 (LWP 29607)] >>>> Program received signal SIGSEGV, Segmentation fault. >>>> [Switching to Thread 47899659458256 (LWP 29607)] >>>> 0x00000000006934c5 in RTAllocator__GetTracedObj >>>> (M3_Eic7CK_def=Cannot access mem >>>> ory at address 0x800028d97718 >>>> ) >>>> at ../src/runtime/common/RTAllocator.m3:221 >>>> 221 INC(thread.inCritical); >>>> (gdb) bt >>>> #0 0x00000000006934c5 in RTAllocator__GetTracedObj >>>> (M3_Eic7CK_def=Cannot access >>>> memory at address 0x800028d97718 >>>> ) >>>> at ../src/runtime/common/RTAllocator.m3:221 >>>> #1 0x0000000000692e1f in RTHooks__AllocateTracedObj >>>> (M3_AJWxb1_defn=Cannot acce >>>> ss memory at address 0x800028d97788 >>>> ) >>>> at ../src/runtime/common/RTAllocator.m3:120 >>>> #2 0x000000000069b3ae in RTCollector__InstallSanityCheck () >>>> at ../src/runtime/common/RTCollector.m3:1637 >>>> #3 0x00000000006a1747 in RTHeapRep__Init () >>>> at ../src/runtime/common/RTCollector.m3:2769 >>>> #4 0x00000000006a2a1d in RTLinker__InitRuntime >>>> (M3_AcxOUs_p_argc=Cannot access >>>> memory at address 0x800028d97858 >>>> ) >>>> at ../src/runtime/common/RTLinker.m3:58 >>>> #5 0x00000000004160bc in main (argc=Cannot access memory at >>>> address 0x800028d97 >>>> 8a8 >>>> ) at _m3main.mc:3 >>>> (gdb) -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From roland.illig at gmx.de Fri Aug 21 21:44:50 2009 From: roland.illig at gmx.de (Roland Illig) Date: Fri, 21 Aug 2009 21:44:50 +0200 Subject: [M3devel] lock before or after try? In-Reply-To: References: Message-ID: <4A8EF932.2020804@gmx.de> Jay K schrieb: > lock > try > stuff > finally > unlock > end > > or > try > lock > stuff > finally > unlock > end > > Lock can't fail so no difference? I would always choose the first variant, because if locking fails for some reason (although it cannot, I know), unlock will not be called without a corresponding lock. At least in Java, it may happen that another thread interrupts this one just in the very nanosecond between the try and lock, throwing an exception, and then you would unlock something that hasn't been locked before. Roland From lchretien at mac.com Fri Aug 21 21:57:48 2009 From: lchretien at mac.com (Louis =?ISO-8859-1?B?Q2hy6XRpZW4=?=) Date: Fri, 21 Aug 2009 15:57:48 -0400 Subject: [M3devel] A more precise question about M3 licensing... Message-ID: (I don't know why it was truncated the first time...) >From what I gathered so far on this thread, the SRC licence was quite a bit more liberal than the FSF license, which led to this "separate process" business for the code generation phase, which displeased the FSF somewhat... After having read the licence for the LLVM project (a one pager on their website), i find it quite liberal and you can basically do anything with the code, as long as you give proper credit and keep the license with the files. I'm no lawyer, but it seems that the SRC and LLVM licenses could play along fine, as opposed to the FSF trying to "infect" everything it touches... So, here's the idea I had: Combine the existing CM3 (and/or PM3) front-end, and modify it to emit LLVM bytecodes, so that we could use the LLVM back-end and infrastructure to create a complete compiler/linker. Would such a beast, by combining code from both licenses, be viable? I would like to keep the licensing as liberal as possible. I sure would like your ideas on this subject, P.S.: Olaf, I think your suggestion of documenting the existing intermidiate representation of the CM3 compiler would be an absolute first step... -- Louis Chr?tien lchretien at mac.com From jay.krell at cornell.edu Fri Aug 21 23:47:35 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 21 Aug 2009 21:47:35 +0000 Subject: [M3devel] @M3paranoidgc always crashes In-Reply-To: <20090821213652.nd7w7ddirkwookgk@mail.elegosoft.com> References: <20090820171058.0stkh5eu68cw0ksk@mail.elegosoft.com> <007DD8EA-4A1C-447A-B8FB-56396A8F6560@cs.purdue.edu> <20090821213652.nd7w7ddirkwookgk@mail.elegosoft.com> Message-ID: Fix is in head. - Jay > Date: Fri, 21 Aug 2009 21:36:52 +0200 > From: wagner at elegosoft.com > To: hosking at cs.purdue.edu; jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] @M3paranoidgc always crashes > > Quoting Tony Hosking : > > > Jay may have fixed this for now. > > It seems to be still broken, at least in the release branch. I'm currently > adding some tests. Running a simple test program with @M3paranoidgc > does not terminate: > > % ../src/p2/p213/FreeBSD4/pgm > `Hello world' and `Hello world' are equal. > The length of the first is 11 > Extracting four chars from position 3 yields --lo w-- > Salut = Hello > > done. > luthien [~/work/cm3/m3-sys/m3tests/src] wagner > % ../src/p2/p213/FreeBSD4/pgm @M3paranoidgc > > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL^C > > It only prints half of the message and eats lots of CPU afterwards. > > I'll open a ticket for it and won't build release packages until it is > fixed. > > Ticket is #1063. > > Olaf > > > > > On 20 Aug 2009, at 11:10, Olaf Wagner wrote: > > > >> Quoting Tony Hosking : > >> > >>> Indeed, the use of paranoidgc itself now seems to be broken > >>> (independently of any other bug you might be trying to track down by > >>> invoking paranoidgc). > >>> This is a serious bug, that should be rectified *before* any release. > >>> Without it, we cannot easily diagnose GC bugs in the field. I have > >>> little to no time to devote to this right now, but it does look like > >>> the recent changes to threading initialisation has broken things. I > >>> remember being very careful about initialization of threads and heap > >>> components of the run-time when working on the original native > >>> threads. In particular, the ability to invoke ThreadF.GetActivation > >>> was allowed before ThreadF.Init had been called, because > >>> ThreadF.InitActivations was able to be invoked on-demand independently > >>> of ThreadF.Init. This independence now seems to have been eliminated > >>> so as to eliminate a run-time check in GetActivation. > >> > >> Jay, could you open a ticket for that, too? > >> > >> And we also need to add tests for running with various @M3 options... > >> > >> Olaf > >> > >>> > >>> On 20 Aug 2009, at 05:55, Jay K wrote: > >>> > >>>> > >>>> Verified on SOLgnu and AMD64_LINUX. > >>>> Probably related to initialization order changes that let user > >>>> threads work again. > >>>> Probably should just use untraced? > >>>> > >>>> > >>>> > >>>> % gdb --args ./cm3 @M3paranoidgc > >>>> GNU gdb 6.4.90-debian > >>>> Copyright (C) 2006 Free Software Foundation, Inc. > >>>> GDB is free software, covered by the GNU General Public License, > >>>> and you are > >>>> welcome to change it and/or distribute copies of it under > >>>> certain conditions. > >>>> Type "show copying" to see the conditions. > >>>> There is absolutely no warranty for GDB. Type "show warranty" > >>>> for details. > >>>> This GDB was configured as "x86_64-linux-gnu"...Using host > >>>> libthread_db library > >>>> "/lib/libthread_db.so.1". > >>>> (gdb) run > >>>> Starting program: /home/jkrell/cm3/bin/cm3 @M3paranoidgc > >>>> [Thread debugging using libthread_db enabled] > >>>> [New Thread 47899659458256 (LWP 29607)] > >>>> Program received signal SIGSEGV, Segmentation fault. > >>>> [Switching to Thread 47899659458256 (LWP 29607)] > >>>> 0x00000000006934c5 in RTAllocator__GetTracedObj > >>>> (M3_Eic7CK_def=Cannot access mem > >>>> ory at address 0x800028d97718 > >>>> ) > >>>> at ../src/runtime/common/RTAllocator.m3:221 > >>>> 221 INC(thread.inCritical); > >>>> (gdb) bt > >>>> #0 0x00000000006934c5 in RTAllocator__GetTracedObj > >>>> (M3_Eic7CK_def=Cannot access > >>>> memory at address 0x800028d97718 > >>>> ) > >>>> at ../src/runtime/common/RTAllocator.m3:221 > >>>> #1 0x0000000000692e1f in RTHooks__AllocateTracedObj > >>>> (M3_AJWxb1_defn=Cannot acce > >>>> ss memory at address 0x800028d97788 > >>>> ) > >>>> at ../src/runtime/common/RTAllocator.m3:120 > >>>> #2 0x000000000069b3ae in RTCollector__InstallSanityCheck () > >>>> at ../src/runtime/common/RTCollector.m3:1637 > >>>> #3 0x00000000006a1747 in RTHeapRep__Init () > >>>> at ../src/runtime/common/RTCollector.m3:2769 > >>>> #4 0x00000000006a2a1d in RTLinker__InitRuntime > >>>> (M3_AcxOUs_p_argc=Cannot access > >>>> memory at address 0x800028d97858 > >>>> ) > >>>> at ../src/runtime/common/RTLinker.m3:58 > >>>> #5 0x00000000004160bc in main (argc=Cannot access memory at > >>>> address 0x800028d97 > >>>> 8a8 > >>>> ) at _m3main.mc:3 > >>>> (gdb) > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Aug 22 00:32:44 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 22 Aug 2009 00:32:44 +0200 Subject: [M3devel] A more precise question about M3 licensing... In-Reply-To: References: Message-ID: <20090822003244.xwf5l3f5icswcgks@mail.elegosoft.com> Quoting Louis Chr?tien : > (I don't know why it was truncated the first time...) I've got a theory now regarding mail truncation. > From what I gathered so far on this thread, the SRC licence was quite a bit > more liberal than the FSF license, which led to this "separate process" > business for the code generation phase, which displeased the FSF somewhat.. It happens when a period gets wrapped to the start of a line. A line starting with a period is the ancient way to end a message or a file. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Sat Aug 22 00:36:24 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 22 Aug 2009 00:36:24 +0200 Subject: [M3devel] @M3paranoidgc always crashes In-Reply-To: References: <20090820171058.0stkh5eu68cw0ksk@mail.elegosoft.com> <007DD8EA-4A1C-447A-B8FB-56396A8F6560@cs.purdue.edu> <20090821213652.nd7w7ddirkwookgk@mail.elegosoft.com> Message-ID: <20090822003624.i5xcphcf4gsgo44o@mail.elegosoft.com> Quoting Jay K : > Fix is in head. OK. I merged runtime and thread from the trunk head. I couldn't compile it though. Some imports were missing. Strange. With the added imports, the tests seem to run fine. Thanks, Olaf > - Jay > >> Date: Fri, 21 Aug 2009 21:36:52 +0200 >> From: wagner at elegosoft.com >> To: hosking at cs.purdue.edu; jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] @M3paranoidgc always crashes >> >> Quoting Tony Hosking : >> >> > Jay may have fixed this for now. >> >> It seems to be still broken, at least in the release branch. I'm currently >> adding some tests. Running a simple test program with @M3paranoidgc >> does not terminate: >> >> % ../src/p2/p213/FreeBSD4/pgm >> `Hello world' and `Hello world' are equal. >> The length of the first is 11 >> Extracting four chars from position 3 yields --lo w-- >> Salut = Hello >> >> done. >> luthien [~/work/cm3/m3-sys/m3tests/src] wagner >> % ../src/p2/p213/FreeBSD4/pgm @M3paranoidgc >> >> >> *** >> *** runtime error: >> *** Segmentation violation - possible attempt to dereference NIL^C >> >> It only prints half of the message and eats lots of CPU afterwards. >> >> I'll open a ticket for it and won't build release packages until it is >> fixed. >> >> Ticket is #1063. >> >> Olaf >> >> > >> > On 20 Aug 2009, at 11:10, Olaf Wagner wrote: >> > >> >> Quoting Tony Hosking : >> >> >> >>> Indeed, the use of paranoidgc itself now seems to be broken >> >>> (independently of any other bug you might be trying to track down by >> >>> invoking paranoidgc). >> >>> This is a serious bug, that should be rectified *before* any release. >> >>> Without it, we cannot easily diagnose GC bugs in the field. I have >> >>> little to no time to devote to this right now, but it does look like >> >>> the recent changes to threading initialisation has broken things. I >> >>> remember being very careful about initialization of threads and heap >> >>> components of the run-time when working on the original native >> >>> threads. In particular, the ability to invoke ThreadF.GetActivation >> >>> was allowed before ThreadF.Init had been called, because >> >>> ThreadF.InitActivations was able to be invoked on-demand independently >> >>> of ThreadF.Init. This independence now seems to have been eliminated >> >>> so as to eliminate a run-time check in GetActivation. >> >> >> >> Jay, could you open a ticket for that, too? >> >> >> >> And we also need to add tests for running with various @M3 options... >> >> >> >> Olaf >> >> >> >>> >> >>> On 20 Aug 2009, at 05:55, Jay K wrote: >> >>> >> >>>> >> >>>> Verified on SOLgnu and AMD64_LINUX. >> >>>> Probably related to initialization order changes that let user >> >>>> threads work again. >> >>>> Probably should just use untraced? >> >>>> >> >>>> >> >>>> >> >>>> % gdb --args ./cm3 @M3paranoidgc >> >>>> GNU gdb 6.4.90-debian >> >>>> Copyright (C) 2006 Free Software Foundation, Inc. >> >>>> GDB is free software, covered by the GNU General Public License, >> >>>> and you are >> >>>> welcome to change it and/or distribute copies of it under >> >>>> certain conditions. >> >>>> Type "show copying" to see the conditions. >> >>>> There is absolutely no warranty for GDB. Type "show warranty" >> >>>> for details. >> >>>> This GDB was configured as "x86_64-linux-gnu"...Using host >> >>>> libthread_db library >> >>>> "/lib/libthread_db.so.1". >> >>>> (gdb) run >> >>>> Starting program: /home/jkrell/cm3/bin/cm3 @M3paranoidgc >> >>>> [Thread debugging using libthread_db enabled] >> >>>> [New Thread 47899659458256 (LWP 29607)] >> >>>> Program received signal SIGSEGV, Segmentation fault. >> >>>> [Switching to Thread 47899659458256 (LWP 29607)] >> >>>> 0x00000000006934c5 in RTAllocator__GetTracedObj >> >>>> (M3_Eic7CK_def=Cannot access mem >> >>>> ory at address 0x800028d97718 >> >>>> ) >> >>>> at ../src/runtime/common/RTAllocator.m3:221 >> >>>> 221 INC(thread.inCritical); >> >>>> (gdb) bt >> >>>> #0 0x00000000006934c5 in RTAllocator__GetTracedObj >> >>>> (M3_Eic7CK_def=Cannot access >> >>>> memory at address 0x800028d97718 >> >>>> ) >> >>>> at ../src/runtime/common/RTAllocator.m3:221 >> >>>> #1 0x0000000000692e1f in RTHooks__AllocateTracedObj >> >>>> (M3_AJWxb1_defn=Cannot acce >> >>>> ss memory at address 0x800028d97788 >> >>>> ) >> >>>> at ../src/runtime/common/RTAllocator.m3:120 >> >>>> #2 0x000000000069b3ae in RTCollector__InstallSanityCheck () >> >>>> at ../src/runtime/common/RTCollector.m3:1637 >> >>>> #3 0x00000000006a1747 in RTHeapRep__Init () >> >>>> at ../src/runtime/common/RTCollector.m3:2769 >> >>>> #4 0x00000000006a2a1d in RTLinker__InitRuntime >> >>>> (M3_AcxOUs_p_argc=Cannot access >> >>>> memory at address 0x800028d97858 >> >>>> ) >> >>>> at ../src/runtime/common/RTLinker.m3:58 >> >>>> #5 0x00000000004160bc in main (argc=Cannot access memory at >> >>>> address 0x800028d97 >> >>>> 8a8 >> >>>> ) at _m3main.mc:3 >> >>>> (gdb) >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From lchretien at mac.com Fri Aug 21 23:40:27 2009 From: lchretien at mac.com (Louis =?ISO-8859-1?B?Q2hy6XRpZW4=?=) Date: Fri, 21 Aug 2009 17:40:27 -0400 Subject: [M3devel] A more precise question about M3 licensing... Message-ID: (Real sorry about this, I don't know why it keeps being truncated...) >From what I gathered so far on this thread, the SRC licence was quite a bit more liberal than the FSF license, which led to this "separate process" business for the code generation phase, which displeased the FSF somewhat. ;-) After having read the licence for the LLVM project (a one pager on their website), i find it quite liberal and you can basically do anything with the code, as long as you give proper credit and keep the license with the files. I'm no lawyer, but it seems that the SRC and LLVM licenses could play along fine, as opposed to the FSF trying to "infect" everything it touches... So, here's the idea I had: Combine the existing CM3 (and/or PM3) front-end, and modify it to emit LLVM bytecodes, so that we could use the LLVM back-end and infrastructure to create a complete compiler/linker. Would such a beast, by combining code from both licenses, be viable? I would like to keep the licensing as liberal as possible. I sure would like your ideas on this subject, P.S.: Olaf, I think your suggestion of documenting the existing intermidiate representation of the CM3 compiler would be an absolute first step... -- Louis Chr?tien lchretien at mac.com From wagner at elegosoft.com Sat Aug 22 01:16:49 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 22 Aug 2009 01:16:49 +0200 Subject: [M3devel] config init problem Message-ID: <20090822011649.81l7rnebgg8884k4@mail.elegosoft.com> In MxConfig.m3 quake runtime exception were ignored and thrown away in EvalConfig. Writing them to stderr, we get the following output for a simple cm3.cfg file: % cat ~/cm3-rc3/bin/cm3.cfg %INSTALL_ROOT = "/ad0e/home/wagner/cm3-rc3" INSTALL_ROOT = path() & SL & ".." include(path() & "/config/FreeBSD4") luthien [~/work/cm3] wagner % cm3 -trace -version Critical Mass Modula-3 version p5.8.3 last updated: 2009-08-10 compiled: 2009-08-21 22:59:34 configuration: /ad0e/home/wagner/cm3-rc3/bin/cm3.cfg host: FreeBSD4 ****** /ad0e/home/wagner/cm3-rc3/bin/cm3.cfg ****** .0 SetLine 1 .1 SetLine 3 .2 LoadVar (193) "path" .3 StartCall .4 CallFunc 0 .5 LoadVar (373) "SL" quake runtime error: "/ad0e/home/wagner/cm3-rc3/bin/cm3.cfg", line 3: quake runtime error: undefined variable: SL --procedure-- -line- -file--- 3 /ad0e/home/wagner/cm3-rc3/bin/cm3.cfg target: SL gets defined in M3Build.m3 in cm3, along with all the other builtins that the compiler may use (and the config file author). Of course MxConfig in package m3quake does not know about these, as it creates its own quake machine on the fly. So configuration evaluation won't work in general currently, unless only standard quake functions and definitions are used. Any ideas? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sat Aug 22 04:13:59 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 22 Aug 2009 02:13:59 +0000 Subject: [M3devel] config init problem In-Reply-To: <20090822011649.81l7rnebgg8884k4@mail.elegosoft.com> References: <20090822011649.81l7rnebgg8884k4@mail.elegosoft.com> Message-ID: In the top of cm3.cfg put if not defined("SL") SL = "/" and/or just hardcode forward slash -- it works on Windows. There is already similar in a few places. Look at cminstall/src/config-no-install/cm3.cfg. This is why m3tohtml and such were crashing, but I dealt with them. I thought. Again, see the cm3.cfg and cm3cfg.common, etc. I have a proposal for next release that the predefines that cm3 does be made available to all quake clients via some new function. - Jay > Date: Sat, 22 Aug 2009 01:16:49 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] config init problem > > In MxConfig.m3 quake runtime exception were ignored and thrown away > in EvalConfig. Writing them to stderr, we get the following output > for a simple cm3.cfg file: > > % cat ~/cm3-rc3/bin/cm3.cfg > > %INSTALL_ROOT = "/ad0e/home/wagner/cm3-rc3" > INSTALL_ROOT = path() & SL & ".." > > include(path() & "/config/FreeBSD4") > > luthien [~/work/cm3] wagner > % cm3 -trace -version > Critical Mass Modula-3 version p5.8.3 > last updated: 2009-08-10 > compiled: 2009-08-21 22:59:34 > configuration: /ad0e/home/wagner/cm3-rc3/bin/cm3.cfg > host: FreeBSD4 > ****** /ad0e/home/wagner/cm3-rc3/bin/cm3.cfg ****** > .0 SetLine 1 > .1 SetLine 3 > .2 LoadVar (193) "path" > .3 StartCall > .4 CallFunc 0 > .5 LoadVar (373) "SL" > quake runtime error: "/ad0e/home/wagner/cm3-rc3/bin/cm3.cfg", line 3: > quake runtime error: undefined variable: SL > > --procedure-- -line- -file--- > 3 /ad0e/home/wagner/cm3-rc3/bin/cm3.cfg > target: > > SL gets defined in M3Build.m3 in cm3, along with all the other > builtins that the compiler may use (and the config file author). > Of course MxConfig in package m3quake does not know about these, > as it creates its own quake machine on the fly. > > So configuration evaluation won't work in general currently, > unless only standard quake functions and definitions are used. > > Any ideas? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Aug 22 11:07:41 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 22 Aug 2009 11:07:41 +0200 Subject: [M3devel] A more precise question about M3 licensing... In-Reply-To: <20090822003244.xwf5l3f5icswcgks@mail.elegosoft.com> References: <20090822003244.xwf5l3f5icswcgks@mail.elegosoft.com> Message-ID: <20090822110741.s6vo69beo000k8c8@mail.elegosoft.com> Quoting Olaf Wagner : > Quoting Louis Chr?tien : > >> (I don't know why it was truncated the first time...) > > I've got a theory now regarding mail truncation. > >> From what I gathered so far on this thread, the SRC licence was quite a bit >> more liberal than the FSF license, which led to this "separate process" >> business for the code generation phase, which displeased the FSF somewhat > > It happens when a period gets wrapped to the start of a line. A line > starting with a period is the ancient way to end a message or a > file. This got truncated, too. Another attempt with some periods removed. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Sat Aug 22 11:45:44 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 22 Aug 2009 11:45:44 +0200 Subject: [M3devel] config init problem In-Reply-To: References: <20090822011649.81l7rnebgg8884k4@mail.elegosoft.com> Message-ID: <20090822114544.i2wwhjp1wsgwws0c@mail.elegosoft.com> Quoting Jay K : > In the top of cm3.cfg put > if not defined("SL") SL = "/" > and/or just hardcode forward slash -- it works on Windows. > > There is already similar in a few places. > Look at cminstall/src/config-no-install/cm3.cfg. I'm not really comfortable with this solution. And I don't think you are ;-) It's just a workaround for SL, but doesn't deal with the other several dozens of definitions whiche _might_ be used in the config scripts. > This is why m3tohtml and such were crashing, but I dealt with them. > I thought. Again, see the cm3.cfg and cm3cfg.common, etc. If the exception wouldn't have been silently ignored in MxConfig.m3, that should have been easy to diagnose. We probably need to build some kind of quality-check tool for M3, which warns about such coding, or should review our changes more often and better. Alas, I'm afraid that won't happen because nobody has enougth time :-( Or perhpas just add a warning to the compiler if a caught exception is just thrown away? > I have a proposal for next release that the predefines that cm3 does > be made available to all quake clients via some new function. We could of course pass down the correctly initialized QM in cm3 (M3Build -> Makefile -> MxConfig). That would fix the problem for cm3, but not for other clients, unless we make them depend on most of the build functions. The latter seems rather unnecessary and inconvenient if only some simple definitions like TARGET are needed. Perhaps we need to distinguish between two kinds of config files: one level for simple clients which may only contain assignments and basic quake functions from m3quake, and more complex initialization for cm3. I agree we should probably not make such changes in the release branch now and postpone them. Olaf >> Date: Sat, 22 Aug 2009 01:16:49 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] config init problem >> >> In MxConfig.m3 quake runtime exception were ignored and thrown away >> in EvalConfig. Writing them to stderr, we get the following output >> for a simple cm3.cfg file: >> >> % cat ~/cm3-rc3/bin/cm3.cfg >> >> %INSTALL_ROOT = "/ad0e/home/wagner/cm3-rc3" >> INSTALL_ROOT = path() & SL & ".." >> >> include(path() & "/config/FreeBSD4") >> >> luthien [~/work/cm3] wagner >> % cm3 -trace -version >> Critical Mass Modula-3 version p5.8.3 >> last updated: 2009-08-10 >> compiled: 2009-08-21 22:59:34 >> configuration: /ad0e/home/wagner/cm3-rc3/bin/cm3.cfg >> host: FreeBSD4 >> ****** /ad0e/home/wagner/cm3-rc3/bin/cm3.cfg ****** >> .0 SetLine 1 >> .1 SetLine 3 >> .2 LoadVar (193) "path" >> .3 StartCall >> .4 CallFunc 0 >> .5 LoadVar (373) "SL" >> quake runtime error: "/ad0e/home/wagner/cm3-rc3/bin/cm3.cfg", line 3: >> quake runtime error: undefined variable: SL >> >> --procedure-- -line- -file--- >> 3 /ad0e/home/wagner/cm3-rc3/bin/cm3.cfg >> target: >> >> SL gets defined in M3Build.m3 in cm3, along with all the other >> builtins that the compiler may use (and the config file author). >> Of course MxConfig in package m3quake does not know about these, >> as it creates its own quake machine on the fly. >> >> So configuration evaluation won't work in general currently, >> unless only standard quake functions and definitions are used. >> >> Any ideas? -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From lchretien at mac.com Sat Aug 22 13:19:09 2009 From: lchretien at mac.com (Louis =?ISO-8859-1?B?Q2hy6XRpZW4=?=) Date: Sat, 22 Aug 2009 07:19:09 -0400 Subject: [M3devel] A more precise question about M3 licensing Message-ID: (Real sorry about this, I don't know why it keeps being truncated...) >From what I gathered so far on this thread, the SRC licence was quite a bit more liberal than the FSF license, which led to this "separate process" business for the code generation phase, which displeased the FSF somewhat. ;-) After having read the licence for the LLVM project (a one pager on their website), i find it quite liberal and you can basically do anything with the code, as long as you give proper credit and keep the license with the files. I'm no lawyer, but it seems that the SRC and LLVM licenses could play along fine, as opposed to the FSF trying to "infect" everything it touches. So, here's the idea I had: Combine the existing CM3 (and/or PM3) front-end, and modify it to emit LLVM bytecodes, so that we could use the LLVM back-end and infrastructure to create a complete compiler/linker. Would such a beast, by combining code from both licenses, be viable? I would like to keep the licensing as liberal as possible. I sure would like your ideas on this subject, P.S.: Olaf, I think your suggestion of documenting the existing intermidiate representation of the CM3 compiler would be an absolute first step. -- Louis Chr?tien lchretien at mac.com From jay.krell at cornell.edu Sat Aug 22 12:34:29 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Sat, 22 Aug 2009 05:34:29 -0500 Subject: [M3devel] config init problem In-Reply-To: <20090822011649.81l7rnebgg8884k4@mail.elegosoft.com> References: <20090822011649.81l7rnebgg8884k4@mail.elegosoft.com> Message-ID: Ignoring errors is very common and usually wrong. Better to have a system terminate than keep running in an unknown state.. "exceptions are better than error return codes" because they have the proper default -- to propagate -- but 1 they still lead to many bugs because lazy programmers still do play along in the escalating game and put in extra code to do the wrong thing and eat exceptions 2 disciplined C programmers know that almost anything can fail and can spot missing error checks at a glance. To wit even simple integer arithmetic can overflow. Look at the intsafe.h header on windows for what to do about that. - Jay (phone) On Aug 21, 2009, at 6:16 PM, Olaf Wagner wrote: > In MxConfig.m3 quake runtime exception were ignored and thrown away > in EvalConfig. Writing them to stderr, we get the following output > for a simple cm3.cfg file: > > % cat ~/cm3-rc3/bin/cm3.cfg > > %INSTALL_ROOT = "/ad0e/home/wagner/cm3-rc3" > INSTALL_ROOT = path() & SL & ".." > > include(path() & "/config/FreeBSD4") > > luthien [~/work/cm3] wagner > % cm3 -trace -version > Critical Mass Modula-3 version p5.8.3 > last updated: 2009-08-10 > compiled: 2009-08-21 22:59:34 > configuration: /ad0e/home/wagner/cm3-rc3/bin/cm3.cfg > host: FreeBSD4 > ****** /ad0e/home/wagner/cm3-rc3/bin/cm3.cfg ****** > .0 SetLine 1 > .1 SetLine 3 > .2 LoadVar (193) "path" > .3 StartCall > .4 CallFunc 0 > .5 LoadVar (373) "SL" > quake runtime error: "/ad0e/home/wagner/cm3-rc3/bin/cm3.cfg", line > 3: quake runtime error: undefined variable: SL > > --procedure-- -line- -file--- > 3 /ad0e/home/wagner/cm3-rc3/bin/cm3.cfg > target: > > SL gets defined in M3Build.m3 in cm3, along with all the other > builtins that the compiler may use (and the config file author). > Of course MxConfig in package m3quake does not know about these, > as it creates its own quake machine on the fly. > > So configuration evaluation won't work in general currently, > unless only standard quake functions and definitions are used. > > Any ideas? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ > any > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be > rlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > From hendrik at topoi.pooq.com Sat Aug 22 13:38:26 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sat, 22 Aug 2009 07:38:26 -0400 Subject: [M3devel] A more precise question about M3 licensing... In-Reply-To: References: Message-ID: <20090822113826.GC7643@topoi.pooq.com> On Fri, Aug 21, 2009 at 02:35:03PM -0400, Louis Chr?tien wrote: > >From what I gathered so far on this thread, the SRC licence was quite a bit > more liberal than the FSF license, which led to this "separate process" > business for the code generation phase, which displeased the FSF somewhat.. The SRC licence specified that if any of this code, whether the original SRC code or other peoples' modifications or additions, ever got back to SRC, they could do anything they wanted with it. This means that if you add code to the M3 system, you have to allow SRC to do anything they want to it. This clause is incompatible with the GPL, which restricts the freedom to distribute binary code without source. Existing GPL'd code can therefore not be incorporated into the Modula 3 system because SRC would not have the freedom to do anything they want with it. -- hendrik From hendrik at topoi.pooq.com Sat Aug 22 13:40:55 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sat, 22 Aug 2009 07:40:55 -0400 Subject: [M3devel] A more precise question about M3 licensing... In-Reply-To: References: Message-ID: <20090822114055.GD7643@topoi.pooq.com> On Fri, Aug 21, 2009 at 05:40:27PM -0400, Louis Chr?tien wrote: > (Real sorry about this, I don't know why it keeps being truncated...) > > >From what I gathered so far on this thread, the SRC licence was quite a bit > more liberal than the FSF license, which led to this "separate process" > business for the code generation phase, which displeased the FSF somewhat. > ;-) > > After having read the licence for the LLVM project (a one pager on their > website), i find it quite liberal and you can basically do anything with the > code, as long as you give proper credit and keep the license with the files So is the licence for C--, which I believe says simply "This software can be used by anyone for any purpose". -- hendrik From jay.krell at cornell.edu Sat Aug 22 13:41:31 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Sat, 22 Aug 2009 06:41:31 -0500 Subject: [M3devel] config init problem In-Reply-To: <20090822114544.i2wwhjp1wsgwws0c@mail.elegosoft.com> References: <20090822011649.81l7rnebgg8884k4@mail.elegosoft.com> <20090822114544.i2wwhjp1wsgwws0c@mail.elegosoft.com> Message-ID: <2190F957-A6DE-426A-9159-8E498373F140@hotmail.com> Most config file readers need very little -- the paths and target. I think we can probably get by with very little change. I don't think we need worry much about all the functions in cm3 but not m3quake. I dare suggest a small library instead if quake that parses command line for target, defaults it to host, maybe checks $cm3_path, searches $path to decide the paths. A wrinkle is like profiling twiddling build_dir. Has that ever worked in reactor?? - Jay (phone) On Aug 22, 2009, at 4:45 AM, Olaf Wagner wrote: > Quoting Jay K : > >> In the top of cm3.cfg put >> if not defined("SL") SL = "/" >> and/or just hardcode forward slash -- it works on Windows. >> >> There is already similar in a few places. >> Look at cminstall/src/config-no-install/cm3.cfg. > > I'm not really comfortable with this solution. And I don't think > you are ;-) It's just a workaround for SL, but doesn't deal with the > other several dozens of definitions whiche _might_ be used in the > config scripts. > >> This is why m3tohtml and such were crashing, but I dealt with them. >> I thought. Again, see the cm3.cfg and cm3cfg.common, etc. > > If the exception wouldn't have been silently ignored in MxConfig.m3, > that should have been easy to diagnose. We probably need to build > some kind of quality-check tool for M3, which warns about such > coding, or should review our changes more often and better. Alas, > I'm afraid that won't happen because nobody has enougth time :-( > > Or perhpas just add a warning to the compiler if a caught exception > is just thrown away? > >> I have a proposal for next release that the predefines that cm3 does >> be made available to all quake clients via some new function. > > We could of course pass down the correctly initialized QM in cm3 > (M3Build -> Makefile -> MxConfig). That would fix the problem for > cm3, but not for other clients, unless we make them depend on most > of the build functions. The latter seems rather unnecessary and > inconvenient if only some simple definitions like TARGET are needed. > Perhaps we need to distinguish between two kinds of config files: > one level for simple clients which may only contain assignments > and basic quake functions from m3quake, and more complex > initialization > for cm3. > > I agree we should probably not make such changes in the release branch > now and postpone them. > > Olaf > >>> Date: Sat, 22 Aug 2009 01:16:49 +0200 >>> From: wagner at elegosoft.com >>> To: m3devel at elegosoft.com >>> Subject: [M3devel] config init problem >>> >>> In MxConfig.m3 quake runtime exception were ignored and thrown away >>> in EvalConfig. Writing them to stderr, we get the following output >>> for a simple cm3.cfg file: >>> >>> % cat ~/cm3-rc3/bin/cm3.cfg >>> >>> %INSTALL_ROOT = "/ad0e/home/wagner/cm3-rc3" >>> INSTALL_ROOT = path() & SL & ".." >>> >>> include(path() & "/config/FreeBSD4") >>> >>> luthien [~/work/cm3] wagner >>> % cm3 -trace -version >>> Critical Mass Modula-3 version p5.8.3 >>> last updated: 2009-08-10 >>> compiled: 2009-08-21 22:59:34 >>> configuration: /ad0e/home/wagner/cm3-rc3/bin/cm3.cfg >>> host: FreeBSD4 >>> ****** /ad0e/home/wagner/cm3-rc3/bin/cm3.cfg ****** >>> .0 SetLine 1 >>> .1 SetLine 3 >>> .2 LoadVar (193) "path" >>> .3 StartCall >>> .4 CallFunc 0 >>> .5 LoadVar (373) "SL" >>> quake runtime error: "/ad0e/home/wagner/cm3-rc3/bin/cm3.cfg", line >>> 3: >>> quake runtime error: undefined variable: SL >>> >>> --procedure-- -line- -file--- >>> 3 /ad0e/home/wagner/cm3-rc3/bin/cm3.cfg >>> target: >>> >>> SL gets defined in M3Build.m3 in cm3, along with all the other >>> builtins that the compiler may use (and the config file author). >>> Of course MxConfig in package m3quake does not know about these, >>> as it creates its own quake machine on the fly. >>> >>> So configuration evaluation won't work in general currently, >>> unless only standard quake functions and definitions are used. >>> >>> Any ideas? > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ > any > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be > rlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > From rodney.m.bates at cox.net Sat Aug 22 21:17:46 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Sat, 22 Aug 2009 14:17:46 -0500 Subject: [M3devel] A question about the M3 licensing... In-Reply-To: <20090821102056.nbcql8hsc8ww80cc@mail.elegosoft.com> References: <20090820234825.GB3925@topoi.pooq.com> <20090821102056.nbcql8hsc8ww80cc@mail.elegosoft.com> Message-ID: <4A90445A.9070201@cox.net> Olaf Wagner wrote: > Quoting hendrik at topoi.pooq.com: > >> I suppose there's another possibility -- writing a new M3 front end with >> a different licence, and being free of SRC forever. Except that if >> some of our libraries are compiled from SRC source code, will we have to >> compile at installation tiem to avould distributing mixed GNU/SRC >> binaries? > > I don't think this is correct. The SRC license allows much more than > the GNU FSF license. That was exactly the stumbling block when it came > to integrating the M3 extensions to gcc into the gcc distribution. > The FSF didn't like the way the backend was used in a different process > context in order to avoid infecting all compiler code with the FSF > license. > > Of course you can write another compiler front-end under the FSF > license. I'd assume this will take several man-years though until > you reach the quality of the current system. And any commercial use > will then be much more difficult, but this is probably moot > regarding the current widespread user base :-) This could be very hard to pull off, or maybe not so hard, but I think the best result would be if HP, as SRC's successor, could be persuaded to assign copyright ownership to FSF, or maybe even some other entity, such as a nonprofit foundation or something. I can't think how keeping it themselves would have any business value to HP, and anything to get it more widely used might have positive value to them. Of course, it would be complicated by the fact that there are some files around with a half-dozen or so other copyright owners and licenses. > > Olaf From wagner at elegosoft.com Sun Aug 23 01:51:25 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 23 Aug 2009 01:51:25 +0200 Subject: [M3devel] CM3 Release 5.8 RC3 Message-ID: <20090823015125.e1mq5xiogc4gkkw8@mail.elegosoft.com> The first packages of CM3 release 5.8 RC3 are now available on www.opencm3.net. More packages will be built during the next days. As there are still 11 open tickets for 5.8 and more are to be expected when RC3 is tested by more users, I've also retargeted the date for the final release to the end of September. Please let me know of any problems you encounter and features that you are missing. The best way of doing this is opening a ticket at https://projects.elego.de/cm3/newticket. Thanks for your support and cooperation, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Sun Aug 23 06:43:44 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 23 Aug 2009 00:43:44 -0400 Subject: [M3devel] A question about the M3 licensing... In-Reply-To: <4A90445A.9070201@cox.net> References: <20090820234825.GB3925@topoi.pooq.com> <20090821102056.nbcql8hsc8ww80cc@mail.elegosoft.com> <4A90445A.9070201@cox.net> Message-ID: <20090823044343.GA9202@topoi.pooq.com> On Sat, Aug 22, 2009 at 02:17:46PM -0500, Rodney M. Bates wrote: > Olaf Wagner wrote: > >Quoting hendrik at topoi.pooq.com: > > > >>I suppose there's another possibility -- writing a new M3 front end with > >>a different licence, and being free of SRC forever. Except that if > >>some of our libraries are compiled from SRC source code, will we have to > >>compile at installation tiem to avould distributing mixed GNU/SRC > >>binaries? > > > >I don't think this is correct. The SRC license allows much more than > >the GNU FSF license. That was exactly the stumbling block when it came > >to integrating the M3 extensions to gcc into the gcc distribution. > >The FSF didn't like the way the backend was used in a different process > >context in order to avoid infecting all compiler code with the FSF > >license. > > > >Of course you can write another compiler front-end under the FSF > >license. I'd assume this will take several man-years though until > >you reach the quality of the current system. And any commercial use > >will then be much more difficult, but this is probably moot > >regarding the current widespread user base :-) > > This could be very hard to pull off, or maybe not so hard, but I think > the best result would be if HP, as SRC's successor, could be persuaded > to assign copyright ownership to FSF, or maybe even some other > entity, such as a nonprofit foundation or something. I can't think how > keeping it themselves would have any business value to HP, and > anything to get it more widely used might have positive value to them. > > Of course, it would be complicated by the fact that there are some > files around with a half-dozen or so other copyright owners and > licenses. But liberating the SRC stuff would handle most of it. And I're recommend a licence that is strictly more liberal than FSF's. Perhaps something like the MIT license, or BSD. They're compatible with GPL, and we may end up having fewer problems in the far future. We might someday, for example, have users needing to link proprietary code with parts of the compiler, and it would be good for that to be possible. - hendrik From jay.krell at cornell.edu Sun Aug 23 07:41:45 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 23 Aug 2009 05:41:45 +0000 Subject: [M3devel] http://www.opencm3.net/ Message-ID: http://www.opencm3.net/ is now remarkably bad. Besides the low contrast high frequency mix of greens and blues, there is also a double nesting of frames by default. - Jay From jay.krell at cornell.edu Sun Aug 23 07:52:36 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 23 Aug 2009 05:52:36 +0000 Subject: [M3devel] more web site problems Message-ID: http://www.opencm3.net/releng/collection-core.html has various README links. I'm certain many are not useful (like under gcc) and I'm not certain if any would be, but asis they all give access denied. "platform-specific library imports for Windows systems" is bogus. They are called "import libraries", not "library imports". The Description is obviously wrong. Maybe that is a placeholder? Or not expanded? The Dependencies look funny but maybe as intended? Or maybe this is a unique output of having no dependencies? Actually they look quite good for other package collections, to provide all that data. I can't tell if only immediately dependent package collections are listed or transitive. The access denied on README isn't unique to core. http://www.opencm3.net/releng/collection-database.html http://www.opencm3.net/releng/collection-cvsup.html contains broken link to "manual page cvpasswd". http://www.opencm3.net/releng/collection-devlib.html README access denied - Jay From jay.krell at cornell.edu Sun Aug 23 08:17:41 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 23 Aug 2009 06:17:41 +0000 Subject: [M3devel] DoRootExport vs. DoRootdExport? Message-ID: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/cm3/src/M3Build.m3?r1=1.28.2.1&r2=1.28.2.2 "d" is or derived, and therefore there is a missing edit after the copy/paste? - Jay From jay.krell at cornell.edu Sun Aug 23 08:26:34 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 23 Aug 2009 06:26:34 +0000 Subject: [M3devel] Posix/Win32 linger options inverted? Message-ID: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-comm/tcp/src/POSIX/TCP.m3?rev=1.7;content-type=text%2Fplain vs. http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-comm/tcp/src/WIN32/TCP.m3?rev=1.3;content-type=text%2Fplain search for linger: PROCEDURE InitFD(fd: CARDINAL) = (* We assume that the runtime ignores SIGPIPE signals *) VAR one: int := 1; linger := Usocket.struct_linger{1, 1}; vs. PROCEDURE InitSock(sock: WinSock.SOCKET) = (* We assume that the runtime ignores SIGPIPE signals *) VAR one : BOOL := 1; linger := WinSock.struct_linger{0, 0}; Surely they can't both be correct. Which is correct? The Posix one? - Jay From jay.krell at cornell.edu Sun Aug 23 09:28:42 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 23 Aug 2009 07:28:42 +0000 Subject: [M3devel] sin_len? Message-ID: I'm looking to - remove the platform dependency defining struct_sockaddr_in - provide a platform independent struct_sockaddr_un What is the deal with the sin_len field? We never fill it in? It is difficult to find documentation as to the meaning of the field. There is this: http://lists.samba.org/archive/rsync/2002-February/001531.html But I believe we have always just left it as zero and I will probably do that. I believe the historical practise here is out of date with IPv6 around, as well. - Jay From jay.krell at cornell.edu Sun Aug 23 10:11:42 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 23 Aug 2009 08:11:42 +0000 Subject: [M3devel] sin_len? In-Reply-To: References: Message-ID: I was going to convert from a portable idealized form of struct_sockaddr_in/un, but I could only support AF_INET and AF_LOCAL/UNIX, and there are many others, so this isn't really viable. Instead I'll strive for the current approach of duplicating the headers reliably, in this small case. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Sun, 23 Aug 2009 07:28:42 +0000 > Subject: [M3devel] sin_len? > > > I'm looking to > - remove the platform dependency defining struct_sockaddr_in > - provide a platform independent struct_sockaddr_un > > What is the deal with the sin_len field? > We never fill it in? > It is difficult to find documentation as to the meaning of the field. > > There is this: > > http://lists.samba.org/archive/rsync/2002-February/001531.html > > But I believe we have always just left it as zero and I will probably do that. > > > I believe the historical practise here is out of date with IPv6 around, as well. > > - Jay From dragisha at m3w.org Sun Aug 23 10:47:57 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 23 Aug 2009 10:47:57 +0200 Subject: [M3devel] New Socket.[im]3? was: Re: sin_len? In-Reply-To: References: Message-ID: <1251017277.30939.31.camel@faramir.m3w.org> There were once (and still is, but not only ones for IPv4) different APIs for TCP and UDP. cmass people unified that in Socket.i3 API, but only for IPv4... What we really need here is even more general Socket.i3, covering AF_UNIX and IPv6... To accomplish this, we have to generalize (OO-ize :) ) Socket.EndPoint to include IPv4/IPv6/AF_UNIX (whatever it's called on Windows, named pipe or...) addresses so Socket(Posix|WIN32).m3 can decide about how to progress through related operations. Good news - Socket interface is unused from current cm3 source tree. Bad news - we don't know about other clients to it. Good news - this is Modula-3 and such changes are easy do detect and easier to change. Thus said... This is probably nothing for 5.8 to care about. If others agreee, and nobody does it, I can find some time in following months to unify work I already have done for AF_UNIX and also to cook what is needed for IPv6 (not much I believe). And of course there's always a "but". What will we do about SCTP? On Sun, 2009-08-23 at 08:11 +0000, Jay K wrote: > I was going to convert from a portable idealized form of struct_sockaddr_in/un, but I could only support AF_INET and AF_LOCAL/UNIX, and there are many others, so this isn't really viable. Instead I'll strive for the current approach of duplicating the headers reliably, in this small case. > > - Jay > > > > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: m3devel at elegosoft.com > > Date: Sun, 23 Aug 2009 07:28:42 +0000 > > Subject: [M3devel] sin_len? > > > > > > I'm looking to > > - remove the platform dependency defining struct_sockaddr_in > > - provide a platform independent struct_sockaddr_un > > > > What is the deal with the sin_len field? > > We never fill it in? > > It is difficult to find documentation as to the meaning of the field. > > > > There is this: > > > > http://lists.samba.org/archive/rsync/2002-February/001531.html > > > > But I believe we have always just left it as zero and I will probably do that. > > > > > > I believe the historical practise here is out of date with IPv6 around, as well. > > > > - Jay -- Dragi?a Duri? From wagner at elegosoft.com Sun Aug 23 12:52:49 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 23 Aug 2009 12:52:49 +0200 Subject: [M3devel] more web site problems In-Reply-To: References: Message-ID: <20090823125249.cc7q0zjwxwcoo84g@mail.elegosoft.com> Quoting Jay K : > http://www.opencm3.net/releng/collection-core.html > > has various README links. > I'm certain many are not useful (like under gcc) and I'm not certain if > any would be, but asis they all give access denied. All README links should now be fixed. I had renamed the workspace and forgot to adapt the link. > "platform-specific library imports for Windows systems" > is bogus. They are called "import libraries", not > "library imports". All package descriptions are in the DESC files. I've fixed this one now. Feel free to improve further. HTML needs to be regenerated now. I'll do that soon. > The Description is obviously wrong. > Maybe that is a placeholder? > Or not expanded? > The Dependencies look funny but maybe as intended? > Or maybe this is a unique output of having no dependencies? > Actually they look quite good for other package collections, > to provide all that data. I can't tell if only > immediately dependent package collections are listed > or transitive. It's just the output of my scripts that compute the dependencies. I haven't had put any efforts into making it beautiful. I thought it would be easily understandable, but that's probably wrong ;-) > The access denied on README isn't unique to core. > http://www.opencm3.net/releng/collection-database.html > > http://www.opencm3.net/releng/collection-cvsup.html > contains broken link to "manual page cvpasswd". That's the result of your putting overrides into the CVSup m3makefiles. Now nothing gets shipped. Probably all the CVSup packages are broken in this respect. Overrides should only be in m3override files and be activated with the -override option. > http://www.opencm3.net/releng/collection-devlib.html > README access denied Thanks for the comments, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Sun Aug 23 13:00:19 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 23 Aug 2009 13:00:19 +0200 Subject: [M3devel] DoRootExport vs. DoRootdExport? In-Reply-To: References: Message-ID: <20090823130019.yucefnpwe8cksgkw@mail.elegosoft.com> Quoting Jay K : > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/cm3/src/M3Build.m3?r1=1.28.2.1&r2=1.28.2.2 > > "d" is or derived, and therefore there is a missing edit after the > copy/paste? Yes, that's wrong. Should be no problem for RC3 though. Fixed in the branch, tag not moved. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Sun Aug 23 13:06:44 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 23 Aug 2009 13:06:44 +0200 Subject: [M3devel] New Socket.[im]3? was: Re: sin_len? In-Reply-To: <1251017277.30939.31.camel@faramir.m3w.org> References: <1251017277.30939.31.camel@faramir.m3w.org> Message-ID: <20090823130644.c3rv6u1dcs0wookk@mail.elegosoft.com> Quoting Dragi?a Duri? : > There were once (and still is, but not only ones for IPv4) different > APIs for TCP and UDP. cmass people unified that in Socket.i3 API, but > only for IPv4... What we really need here is even more general > Socket.i3, covering AF_UNIX and IPv6... > > To accomplish this, we have to generalize (OO-ize :) ) Socket.EndPoint > to include IPv4/IPv6/AF_UNIX (whatever it's called on Windows, named > pipe or...) addresses so Socket(Posix|WIN32).m3 can decide about how to > progress through related operations. > > Good news - Socket interface is unused from current cm3 source tree. Bad > news - we don't know about other clients to it. Good news - this is > Modula-3 and such changes are easy do detect and easier to change. > > Thus said... This is probably nothing for 5.8 to care about. If others > agreee, and nobody does it, I can find some time in following months to > unify work I already have done for AF_UNIX and also to cook what is > needed for IPv6 (not much I believe). > > And of course there's always a "but". What will we do about SCTP? This is definitely nothing for the release. There are still enough problems without refactoring network layers. I'd really appreciate it if you or somebody else takes care of it though. IPv6 has been on my wishlist for M3 for years, too. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Sun Aug 23 18:31:38 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 23 Aug 2009 18:31:38 +0200 Subject: [M3devel] New Socket.[im]3? was: Re: sin_len? In-Reply-To: <20090823130644.c3rv6u1dcs0wookk@mail.elegosoft.com> References: <1251017277.30939.31.camel@faramir.m3w.org> <20090823130644.c3rv6u1dcs0wookk@mail.elegosoft.com> Message-ID: <1251045098.30939.36.camel@faramir.m3w.org> IPv6 is a plaything right now... I've had setup for it on few machines, but it did not last... Though it's not a hassle to make LAN setup... I'll look through this, and esp unifying interface for IPv4/IPv6/(AF_UNIX|named pipes). On Sun, 2009-08-23 at 13:06 +0200, Olaf Wagner wrote: > This is definitely nothing for the release. There are still enough > problems without refactoring network layers. > > I'd really appreciate it if you or somebody else takes care of it > though. > > IPv6 has been on my wishlist for M3 for years, too. -- Dragi?a Duri? From hendrik at topoi.pooq.com Mon Aug 24 02:56:58 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 23 Aug 2009 20:56:58 -0400 Subject: [M3devel] trying RC3 Message-ID: <20090824005658.GA11486@topoi.pooq.com> Well, core and gui installed flaelessly on a Debian lenny system. But cvsup ended with the message: package was built with overrides, not shipping. Now maybe that's correct behaviour, but It doesn't look like it. Here are the details: hendrik at lovesong:~/cm3/ia32/RC3$ mkdir cvsup hendrik at lovesong:~/cm3/ia32/RC3$ cd cvsup hendrik at lovesong:~/cm3/ia32/RC3/cvsup$ tar -zxf ../../../dn/cm3-bin-ws-cvsup-LINUXLIBC6-5.8.3-RC3.tgz hendrik at lovesong:~/cm3/ia32/RC3/cvsup$ ls collection-cvsup.html install.sh m3-tools setup.cmd hendrik at lovesong:~/cm3/ia32/RC3/cvsup$ ./install.sh installing package m3-tools/cvsup/suplib --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/suplib/LINUXLIBC6 .M3EXPORTS . => /usr/local/cm3/lib libsuplib.so.5 . => /usr/local/cm3/pkg/suplib/LINUXLIBC6 libsuplib.a libsuplib.m3x .M3WEB ../LINUXLIBC6 => /usr/local/cm3/pkg/suplib/LINUXLIBC6 ExecRecSeq.i3 ExecRecSeq.m3 DirEntryList.i3 DirEntryList.m3 DirEntryListSort.i3 DirEntryListSort.m3 TextGlobTreeTbl.i3 TextGlobTreeTbl.m3 ExecRecSeqRep.i3 RCSAccessList.i3 RCSAccessList.m3 RCSTagList.i3 RCSTagList.m3 RCSTagListSort.i3 RCSTagListSort.m3 RCSEditTbl.i3 RCSEditTbl.m3 SortedRCSEditTbl.i3 SortedRCSEditTbl.m3 RCSDeltaList.i3 RCSDeltaList.m3 RCSDeltaListSort.i3 RCSDeltaListSort.m3 RCSDeltaTbl.i3 RCSDeltaTbl.m3 SortedRCSDeltaTbl.i3 SortedRCSDeltaTbl.m3 RsyncBlockArraySort.i3 RsyncBlockArraySort.m3 ../src => /usr/local/cm3/pkg/suplib/src RegEx.i3 RegEx.m3 Merger.ig Merger.mg merger.tmpl CText.i3 Uglob.i3 PathComp.i3 PathComp.m3 ChannelMux.m3 ChannelMux.i3 Logger.i3 Logger.m3 LoggerClass.i3 SplitLogger.i3 SplitLogger.m3 SysLogger.i3 SysLogger.m3 TimeStampLogger.i3 TimeStampLogger.m3 WrLogger.i3 WrLogger.m3 ProcTitle.i3 Ugzip.i3 Ugzip.m3 UgzipP.i3 Umd5.i3 MySyslog.i3 WatchDog.i3 WatchDog.m3 IOWatchDog.i3 IOWatchDog.m3 MD5Digest.i3 MD5Digest.m3 MD5.m3 MD5.i3 AuthMD5.m3 AuthMD5.i3 TokScan.m3 TokScan.i3 DevT.i3 FileAttr.i3 FileAttr.m3 FileAttrRep.i3 FileID.m3 FileID.i3 CVProto.m3 CVProto.i3 EscapedRd.i3 EscapedRd.m3 EscapedWr.i3 EscapedWr.m3 MD5Wr.i3 MD5Wr.m3 ErrMsg.i3 ErrMsg.m3 DirEntry.i3 DirEntry.m3 Glob.m3 Glob.i3 GlobTree.i3 GlobTree.m3 LockFile.m3 LockFile.i3 ExecRec.i3 RCSError.i3 RCSString.m3 RCSString.i3 RCSPhrase.i3 RCSPhrase.m3 RCSPhrases.i3 RCSPhrases.m3 RCSDate.m3 RCSDate.i3 RCSRevNum.i3 RCSRevNum.m3 RCSAccess.m3 RCSAccess.i3 RCSTag.i3 RCSTag.m3 RCSEdit.i3 RCSDelta.m3 RCSDelta.i3 RCSDeltaClass.i3 RCSKeyword.m3 RCSKeyword.i3 RCSFile.i3 RCSFile.m3 SupFileRec.i3 SupFileRec.m3 SupMisc.i3 SupMisc.m3 FileStatus.m3 FileStatus.i3 FileStatusRaw.i3 StatusFile.i3 StatusFile.m3 CVTree.m3 CVTree.i3 GzipError.m3 GzipError.i3 GzipRd.i3 GzipRd.m3 GzipWr.i3 GzipWr.m3 RsyncBlock.m3 RsyncBlock.i3 RsyncFile.m3 RsyncFile.i3 Reaper.i3 Reaper.m3 SigHandler.m3 SigHandler.i3 UnixMisc.m3 UnixMisc.i3 UnixMiscC.c Attic.i3 Attic.m3 ../src/POSIX => /usr/local/cm3/pkg/suplib/src/POSIX ProcTitle.m3 FileAttrOS.m3 ../src/libmd => /usr/local/cm3/pkg/suplib/src/libmd md5c.c md5hl.c ../src/libglob => /usr/local/cm3/pkg/suplib/src/libglob fnmatch.c ../src/dev_t_posix => /usr/local/cm3/pkg/suplib/src/dev_t_posix DevT.m3 ../src/text_cm3 => /usr/local/cm3/pkg/suplib/src/text_cm3 CText.m3 SupMiscText.m3 installing package m3-tools/cvsup/client --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/client/LINUXLIBC6 .M3EXPORTS .M3WEB ../LINUXLIBC6 => /usr/local/cm3/pkg/client/LINUXLIBC6 Version.m3 SupGUIBundle.i3 SupGUIBundle.m3 FixupSeq.i3 FixupSeq.m3 FixupSeqRep.i3 SyncFixupQueue.i3 SyncFixupQueue.m3 SupFileRecSeq.m3 SupFileRecSeq.i3 SupFileRecSeqRep.i3 FileAttrSeq.i3 FileAttrSeq.m3 FileAttrSeqRep.i3 ../src => /usr/local/cm3/pkg/client/src Version.i3 SyncQueue.mg SyncQueue.ig syncqueue.tmpl Fixup.i3 Auth.m3 Auth.i3 SupFile.i3 SupFile.m3 Receive.i3 Receive.m3 FileUpdater.i3 FileUpdater.m3 CheckoutCreator.i3 CheckoutCreator.m3 CheckoutUpdater.i3 CheckoutUpdater.m3 RCSUpdater.m3 RCSUpdater.i3 RegularCreator.i3 RegularCreator.m3 RegularUpdater.i3 RegularUpdater.m3 RsyncUpdater.i3 RsyncUpdater.m3 TreeList.i3 TreeList.m3 Detailer.i3 Detailer.m3 Updater.i3 Updater.m3 FSClient.m3 FSClient.i3 SupGUI.i3 SupGUI.m3 EventSync.i3 EventSync.m3 TextPortLogger.m3 TextPortLogger.i3 TextVBTLogger.i3 TextVBTLogger.m3 BackoffTimer.i3 BackoffTimer.m3 Main.m3 . => /usr/local/cm3/bin cvsup . => /usr/local/cm3/man/man1 cvsup.1 installing package m3-tools/cvsup/server --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/server/LINUXLIBC6 .M3EXPORTS .M3WEB ../LINUXLIBC6 => /usr/local/cm3/pkg/server/LINUXLIBC6 Version.m3 FileInfoMerger.i3 FileInfoMerger.m3 LinkTbl.m3 LinkTbl.i3 RCSDeltaMerger.m3 RCSDeltaMerger.i3 RCSTagMerger.i3 RCSTagMerger.m3 SupFileRecSeq.m3 SupFileRecSeq.i3 SupFileRecSeqRep.i3 FileAttrSeq.i3 FileAttrSeq.m3 FileAttrSeqRep.i3 ParsedDeltaList.i3 ParsedDeltaList.m3 ../src => /usr/local/cm3/pkg/server/src Version.i3 FileInfo.m3 FileInfo.i3 ParsedDelta.m3 ParsedDelta.i3 AccessRules.i3 AccessRules.m3 Passwd.i3 Passwd.m3 ClientClass.i3 ClientClass.m3 ClassDB.m3 ClassDB.i3 RCSComp.i3 RCSComp.m3 TreeComp.i3 TreeComp.m3 FSServer.m3 FSServer.i3 FSServerRep.i3 FSServerU.m3 Main.m3 . => /usr/local/cm3/bin cvsupd . => /usr/local/cm3/man/man8 cvsupd.8 . => /usr/local/cm3/man/man5 cvsupd.class.5 installing package m3-tools/cvsup/cvpasswd --- shipping from LINUXLIBC6 --- package was built with overrides, not shipping. hendrik at lovesong:~/cm3/ia32/RC3/cvsup$ ls -- hendrik From jay.krell at cornell.edu Mon Aug 24 03:05:17 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 24 Aug 2009 01:05:17 +0000 Subject: [M3devel] more web site problems In-Reply-To: <20090823125249.cc7q0zjwxwcoo84g@mail.elegosoft.com> References: <20090823125249.cc7q0zjwxwcoo84g@mail.elegosoft.com> Message-ID: > That's the result of your putting overrides into the CVSup I don't think it was me though I should have noticed it in the initial version. - Jay ---------------------------------------- > Date: Sun, 23 Aug 2009 12:52:49 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: more web site problems > > Quoting Jay K : > >> http://www.opencm3.net/releng/collection-core.html >> >> has various README links. >> I'm certain many are not useful (like under gcc) and I'm not certain if >> any would be, but asis they all give access denied. > > All README links should now be fixed. I had renamed the workspace > and forgot to adapt the link. > >> "platform-specific library imports for Windows systems" >> is bogus. They are called "import libraries", not >> "library imports". > > All package descriptions are in the DESC files. I've fixed this one > now. Feel free to improve further. > > HTML needs to be regenerated now. I'll do that soon. > >> The Description is obviously wrong. >> Maybe that is a placeholder? >> Or not expanded? > > >> The Dependencies look funny but maybe as intended? >> Or maybe this is a unique output of having no dependencies? >> Actually they look quite good for other package collections, >> to provide all that data. I can't tell if only >> immediately dependent package collections are listed >> or transitive. > > It's just the output of my scripts that compute the dependencies. > I haven't had put any efforts into making it beautiful. I thought > it would be easily understandable, but that's probably wrong ;-) > >> The access denied on README isn't unique to core. >> http://www.opencm3.net/releng/collection-database.html >> >> http://www.opencm3.net/releng/collection-cvsup.html >> contains broken link to "manual page cvpasswd". > > That's the result of your putting overrides into the CVSup > m3makefiles. Now nothing gets shipped. Probably all the CVSup > packages are broken in this respect. Overrides should only be > in m3override files and be activated with the -override option. > >> http://www.opencm3.net/releng/collection-devlib.html >> README access denied > > Thanks for the comments, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Mon Aug 24 03:07:25 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 24 Aug 2009 01:07:25 +0000 Subject: [M3devel] trying RC3 In-Reply-To: <20090824005658.GA11486@topoi.pooq.com> References: <20090824005658.GA11486@topoi.pooq.com> Message-ID: This is understood and fixed, specific to cvsup. Thanks, - Jay ---------------------------------------- > Date: Sun, 23 Aug 2009 20:56:58 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: [M3devel] trying RC3 > > Well, core and gui installed flaelessly on a Debian lenny system. > > But cvsup ended with the message: > > package was built with overrides, not shipping. > > Now maybe that's correct behaviour, but It doesn't look like it. > > Here are the details: > > hendrik at lovesong:~/cm3/ia32/RC3$ mkdir cvsup > hendrik at lovesong:~/cm3/ia32/RC3$ cd cvsup > hendrik at lovesong:~/cm3/ia32/RC3/cvsup$ tar -zxf > ../../../dn/cm3-bin-ws-cvsup-LINUXLIBC6-5.8.3-RC3.tgz > hendrik at lovesong:~/cm3/ia32/RC3/cvsup$ ls > collection-cvsup.html install.sh m3-tools setup.cmd > hendrik at lovesong:~/cm3/ia32/RC3/cvsup$ ./install.sh > installing package m3-tools/cvsup/suplib > --- shipping from LINUXLIBC6 --- > > . => /usr/local/cm3/pkg/suplib/LINUXLIBC6 > .M3EXPORTS > . => /usr/local/cm3/lib > libsuplib.so.5 > . => /usr/local/cm3/pkg/suplib/LINUXLIBC6 > libsuplib.a libsuplib.m3x .M3WEB > ../LINUXLIBC6 => /usr/local/cm3/pkg/suplib/LINUXLIBC6 > ExecRecSeq.i3 ExecRecSeq.m3 DirEntryList.i3 DirEntryList.m3 > DirEntryListSort.i3 DirEntryListSort.m3 TextGlobTreeTbl.i3 > TextGlobTreeTbl.m3 ExecRecSeqRep.i3 RCSAccessList.i3 > RCSAccessList.m3 > RCSTagList.i3 RCSTagList.m3 RCSTagListSort.i3 > RCSTagListSort.m3 > RCSEditTbl.i3 RCSEditTbl.m3 SortedRCSEditTbl.i3 > SortedRCSEditTbl.m3 RCSDeltaList.i3 RCSDeltaList.m3 > RCSDeltaListSort.i3 RCSDeltaListSort.m3 RCSDeltaTbl.i3 > RCSDeltaTbl.m3 SortedRCSDeltaTbl.i3 SortedRCSDeltaTbl.m3 > RsyncBlockArraySort.i3 RsyncBlockArraySort.m3 > ../src => /usr/local/cm3/pkg/suplib/src > RegEx.i3 RegEx.m3 Merger.ig Merger.mg > merger.tmpl CText.i3 Uglob.i3 PathComp.i3 > PathComp.m3 ChannelMux.m3 ChannelMux.i3 Logger.i3 > Logger.m3 LoggerClass.i3 SplitLogger.i3 SplitLogger.m3 > SysLogger.i3 SysLogger.m3 TimeStampLogger.i3 > TimeStampLogger.m3 WrLogger.i3 WrLogger.m3 ProcTitle.i3 > Ugzip.i3 Ugzip.m3 UgzipP.i3 Umd5.i3 > MySyslog.i3 WatchDog.i3 WatchDog.m3 IOWatchDog.i3 > IOWatchDog.m3 MD5Digest.i3 MD5Digest.m3 MD5.m3 > MD5.i3 AuthMD5.m3 AuthMD5.i3 TokScan.m3 > TokScan.i3 DevT.i3 FileAttr.i3 FileAttr.m3 > FileAttrRep.i3 FileID.m3 FileID.i3 CVProto.m3 > CVProto.i3 EscapedRd.i3 EscapedRd.m3 EscapedWr.i3 > EscapedWr.m3 MD5Wr.i3 MD5Wr.m3 ErrMsg.i3 > ErrMsg.m3 DirEntry.i3 DirEntry.m3 Glob.m3 > Glob.i3 GlobTree.i3 GlobTree.m3 LockFile.m3 > LockFile.i3 ExecRec.i3 RCSError.i3 RCSString.m3 > RCSString.i3 RCSPhrase.i3 RCSPhrase.m3 RCSPhrases.i3 > RCSPhrases.m3 RCSDate.m3 RCSDate.i3 RCSRevNum.i3 > RCSRevNum.m3 RCSAccess.m3 RCSAccess.i3 RCSTag.i3 > RCSTag.m3 RCSEdit.i3 RCSDelta.m3 RCSDelta.i3 > RCSDeltaClass.i3 RCSKeyword.m3 RCSKeyword.i3 RCSFile.i3 > RCSFile.m3 SupFileRec.i3 SupFileRec.m3 SupMisc.i3 > SupMisc.m3 FileStatus.m3 FileStatus.i3 FileStatusRaw.i3 > StatusFile.i3 StatusFile.m3 CVTree.m3 CVTree.i3 > GzipError.m3 GzipError.i3 GzipRd.i3 GzipRd.m3 > GzipWr.i3 GzipWr.m3 RsyncBlock.m3 RsyncBlock.i3 > RsyncFile.m3 RsyncFile.i3 Reaper.i3 Reaper.m3 > SigHandler.m3 SigHandler.i3 UnixMisc.m3 UnixMisc.i3 > UnixMiscC.c Attic.i3 Attic.m3 > ../src/POSIX => /usr/local/cm3/pkg/suplib/src/POSIX > ProcTitle.m3 FileAttrOS.m3 > ../src/libmd => /usr/local/cm3/pkg/suplib/src/libmd > md5c.c md5hl.c > ../src/libglob => /usr/local/cm3/pkg/suplib/src/libglob > fnmatch.c > ../src/dev_t_posix => /usr/local/cm3/pkg/suplib/src/dev_t_posix > DevT.m3 > ../src/text_cm3 => /usr/local/cm3/pkg/suplib/src/text_cm3 > CText.m3 SupMiscText.m3 > installing package m3-tools/cvsup/client > --- shipping from LINUXLIBC6 --- > > . => /usr/local/cm3/pkg/client/LINUXLIBC6 > .M3EXPORTS .M3WEB > ../LINUXLIBC6 => /usr/local/cm3/pkg/client/LINUXLIBC6 > Version.m3 SupGUIBundle.i3 SupGUIBundle.m3 FixupSeq.i3 > FixupSeq.m3 FixupSeqRep.i3 SyncFixupQueue.i3 SyncFixupQueue.m3 > SupFileRecSeq.m3 SupFileRecSeq.i3 SupFileRecSeqRep.i3 FileAttrSeq.i3 > FileAttrSeq.m3 FileAttrSeqRep.i3 > ../src => /usr/local/cm3/pkg/client/src > Version.i3 SyncQueue.mg SyncQueue.ig syncqueue.tmpl > Fixup.i3 Auth.m3 Auth.i3 SupFile.i3 > SupFile.m3 Receive.i3 Receive.m3 FileUpdater.i3 > FileUpdater.m3 CheckoutCreator.i3 CheckoutCreator.m3 > CheckoutUpdater.i3 CheckoutUpdater.m3 RCSUpdater.m3 > RCSUpdater.i3 RegularCreator.i3 RegularCreator.m3 RegularUpdater.i3 > RegularUpdater.m3 RsyncUpdater.i3 RsyncUpdater.m3 TreeList.i3 > TreeList.m3 Detailer.i3 Detailer.m3 Updater.i3 > Updater.m3 FSClient.m3 FSClient.i3 SupGUI.i3 > SupGUI.m3 EventSync.i3 EventSync.m3 TextPortLogger.m3 > TextPortLogger.i3 TextVBTLogger.i3 TextVBTLogger.m3 BackoffTimer.i3 > BackoffTimer.m3 Main.m3 > . => /usr/local/cm3/bin > cvsup > . => /usr/local/cm3/man/man1 > cvsup.1 > installing package m3-tools/cvsup/server > --- shipping from LINUXLIBC6 --- > > . => /usr/local/cm3/pkg/server/LINUXLIBC6 > .M3EXPORTS .M3WEB > ../LINUXLIBC6 => /usr/local/cm3/pkg/server/LINUXLIBC6 > Version.m3 FileInfoMerger.i3 FileInfoMerger.m3 LinkTbl.m3 > LinkTbl.i3 RCSDeltaMerger.m3 RCSDeltaMerger.i3 RCSTagMerger.i3 > RCSTagMerger.m3 SupFileRecSeq.m3 SupFileRecSeq.i3 SupFileRecSeqRep.i3 > FileAttrSeq.i3 FileAttrSeq.m3 FileAttrSeqRep.i3 ParsedDeltaList.i3 > ParsedDeltaList.m3 > ../src => /usr/local/cm3/pkg/server/src > Version.i3 FileInfo.m3 FileInfo.i3 ParsedDelta.m3 > ParsedDelta.i3 AccessRules.i3 AccessRules.m3 Passwd.i3 > Passwd.m3 ClientClass.i3 ClientClass.m3 ClassDB.m3 > ClassDB.i3 RCSComp.i3 RCSComp.m3 TreeComp.i3 > TreeComp.m3 FSServer.m3 FSServer.i3 FSServerRep.i3 > FSServerU.m3 Main.m3 > . => /usr/local/cm3/bin > cvsupd > . => /usr/local/cm3/man/man8 > cvsupd.8 > . => /usr/local/cm3/man/man5 > cvsupd.class.5 > installing package m3-tools/cvsup/cvpasswd > --- shipping from LINUXLIBC6 --- > > package was built with overrides, not shipping. > hendrik at lovesong:~/cm3/ia32/RC3/cvsup$ ls > > > -- hendrik > From hendrik at topoi.pooq.com Mon Aug 24 03:32:45 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 23 Aug 2009 21:32:45 -0400 Subject: [M3devel] trying RC3 In-Reply-To: References: <20090824005658.GA11486@topoi.pooq.com> Message-ID: <20090824013245.GA11619@topoi.pooq.com> On Mon, Aug 24, 2009 at 01:07:25AM +0000, Jay K wrote: > > This is understood and fixed, specific to cvsup. Does 'fixed' mean you've replaced the RC3 archive, in which case I'll try it again soon, or that it'll be OK in RC4? Or just fixed in CVS? > > Thanks, > - Jay You're welcome. Each time a new RC comes out, I shunt aside my existing cm3, and try an install. Then I report on the problems, and move the working cm3 back. I'll spend some time this week testing the other ws-packages. Thanks. -- hendrik From jay.krell at cornell.edu Mon Aug 24 04:43:52 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 24 Aug 2009 02:43:52 +0000 Subject: [M3devel] trying RC3 In-Reply-To: <20090824013245.GA11619@topoi.pooq.com> References: <20090824005658.GA11486@topoi.pooq.com> <20090824013245.GA11619@topoi.pooq.com> Message-ID: In CVS. - Jay ---------------------------------------- > Date: Sun, 23 Aug 2009 21:32:45 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] trying RC3 > > On Mon, Aug 24, 2009 at 01:07:25AM +0000, Jay K wrote: >> >> This is understood and fixed, specific to cvsup. > > Does 'fixed' mean you've replaced the RC3 archive, in which case I'll > try it again soon, or that it'll be OK in RC4? > > Or just fixed in CVS? > >> >> Thanks, >> - Jay > > You're welcome. Each time a new RC comes out, I shunt aside my existing > cm3, and try an install. Then I report on the problems, and move the > working cm3 back. > > I'll spend some time this week testing the other ws-packages. > > Thanks. > > -- hendrik > From wagner at elegosoft.com Mon Aug 24 09:56:39 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 24 Aug 2009 09:56:39 +0200 Subject: [M3devel] more web site problems Message-ID: <20090824095639.smnfmx03w0og8sc8@mail.elegosoft.com> Quoting Jay K : >> That's the result of your putting overrides into the CVSup > > I don't think it was me though I should have noticed it in the > initial version. Sorry, I didn't want to sound accusatory; I just remembered that you imported CVSup into the tree and later changed all the overrides, too. But these oversights happen all the time; you cannot avoid them. So never mind, Olaf > - Jay > > > > ---------------------------------------- >> Date: Sun, 23 Aug 2009 12:52:49 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: more web site problems >> >> Quoting Jay K : >> >>> http://www.opencm3.net/releng/collection-core.html >>> >>> has various README links. >>> I'm certain many are not useful (like under gcc) and I'm not certain if >>> any would be, but asis they all give access denied. >> >> All README links should now be fixed. I had renamed the workspace >> and forgot to adapt the link. >> >>> "platform-specific library imports for Windows systems" >>> is bogus. They are called "import libraries", not >>> "library imports". >> >> All package descriptions are in the DESC files. I've fixed this one >> now. Feel free to improve further. >> >> HTML needs to be regenerated now. I'll do that soon. >> >>> The Description is obviously wrong. >>> Maybe that is a placeholder? >>> Or not expanded? >> >> >>> The Dependencies look funny but maybe as intended? >>> Or maybe this is a unique output of having no dependencies? >>> Actually they look quite good for other package collections, >>> to provide all that data. I can't tell if only >>> immediately dependent package collections are listed >>> or transitive. >> >> It's just the output of my scripts that compute the dependencies. >> I haven't had put any efforts into making it beautiful. I thought >> it would be easily understandable, but that's probably wrong ;-) >> >>> The access denied on README isn't unique to core. >>> http://www.opencm3.net/releng/collection-database.html >>> >>> http://www.opencm3.net/releng/collection-cvsup.html >>> contains broken link to "manual page cvpasswd". >> >> That's the result of your putting overrides into the CVSup >> m3makefiles. Now nothing gets shipped. Probably all the CVSup >> packages are broken in this respect. Overrides should only be >> in m3override files and be activated with the -override option. >> >>> http://www.opencm3.net/releng/collection-devlib.html >>> README access denied >> >> Thanks for the comments, >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From lchretien at mac.com Mon Aug 24 16:08:45 2009 From: lchretien at mac.com (Louis =?ISO-8859-1?B?Q2hy6XRpZW4=?=) Date: Mon, 24 Aug 2009 10:08:45 -0400 Subject: [M3devel] Could you post this for me on m3devel In-Reply-To: <20090822003244.xwf5l3f5icswcgks@mail.elegosoft.com> Message-ID: Hi Olaf, try as I can, i cannot post the message on the list completely. Could you do that for me please? Thanks, ******************* Object: A more precise question about M3 licensing... (Real sorry about this, I don't know why it keeps being truncated...) >From what I gathered so far on this thread, the SRC licence was quite a bit more liberal than the FSF license, which led to this "separate process" business for the code generation phase, which displeased the FSF somewhat. ;-) After having read the licence for the LLVM project (a one pager on their website), i find it quite liberal and you can basically do anything with the code, as long as you give proper credit and keep the license with the files. I'm no lawyer, but it seems that the SRC and LLVM licenses could play along fine, as opposed to the FSF trying to "infect" everything it touches... So, here's the idea I had: Combine the existing CM3 (and/or PM3) front-end, and modify it to emit LLVM bytecodes, so that we could use the LLVM back-end and infrastructure to create a complete compiler/linker. Would such a beast, by combining code from both licenses, be viable? I would like to keep the licensing as liberal as possible. I sure would like your ideas on this subject, P.S.: Olaf, I think your suggestion of documenting the existing intermidiate representation of the CM3 compiler would be an absolute first step... -- Louis Chr?tien lchretien at mac.com From wagner at elegosoft.com Mon Aug 24 17:36:46 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 24 Aug 2009 17:36:46 +0200 Subject: [M3devel] Fwd: Could you post this for me on m3devel Message-ID: <20090824173646.l0yae49dgkwoks8o@mail.elegosoft.com> Trying once again with some periods removed ----- Forwarded message from lchretien at mac.com ----- Date: Mon, 24 Aug 2009 10:08:45 -0400 From: Louis Chr?tien Reply-To: Louis Chr?tien Subject: Could you post this for me on m3devel To: Olaf Wagner Hi Olaf, try as I can, i cannot post the message on the list completely. Could you do that for me please? Thanks, ******************* Object: A more precise question about M3 licensing (Real sorry about this, I don't know why it keeps being truncated) From what I gathered so far on this thread, the SRC licence was quite a bit more liberal than the FSF license, which led to this "separate process" business for the code generation phase, which displeased the FSF somewhat. ;-) After having read the licence for the LLVM project (a one pager on their website), i find it quite liberal and you can basically do anything with the code, as long as you give proper credit and keep the license with the files. I'm no lawyer, but it seems that the SRC and LLVM licenses could play along fine, as opposed to the FSF trying to "infect" everything it touches So, here's the idea I had: Combine the existing CM3 (and/or PM3) front-end, and modify it to emit LLVM bytecodes, so that we could use the LLVM back-end and infrastructure to create a complete compiler/linker. Would such a beast, by combining code from both licenses, be viable? I would like to keep the licensing as liberal as possible. I sure would like your ideas on this subject, P.S.: Olaf, I think your suggestion of documenting the existing intermidiate representation of the CM3 compiler would be an absolute first step -- Louis Chr?tien lchretien at mac.com ----- End forwarded message ----- -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Mon Aug 24 18:47:42 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 24 Aug 2009 12:47:42 -0400 Subject: [M3devel] Fwd: Could you post this for me on m3devel In-Reply-To: <20090824173646.l0yae49dgkwoks8o@mail.elegosoft.com> References: <20090824173646.l0yae49dgkwoks8o@mail.elegosoft.com> Message-ID: <20090824164741.GB13116@topoi.pooq.com> On Mon, Aug 24, 2009 at 05:36:46PM +0200, Olaf Wagner wrote: > > Object: A more precise question about M3 licensing > > From what I gathered so far on this thread, the SRC licence was quite a bit > more liberal than the FSF license, which led to this "separate process" > business for the code generation phase, which displeased the FSF somewhat. > ;-) As far as I know, the problem is that the SRC licence was restrictive at one point that conflicted with the FSF licence. In particular, you had to grant SRC the ability to do anything whatsoever with anything you added or modified in the system. That is a restriction on how you can redistribute -- a restriction more severe than the FSF licence allows.. But there's nothing preventing any of us from releasing your own code under multiple licences, including the FSF one. Even if you link directly to FSF code and distribute binaries, and aggregate your source with FSF code more intimately than "mere aggregation", nothing prevents you from licencing your code under as many different licences as you want in addition to the FSF one. But without SRS's say-so, we can't do it to their code. -- hendrik From hendrik at topoi.pooq.com Mon Aug 24 19:06:24 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 24 Aug 2009 13:06:24 -0400 Subject: [M3devel] platform names again. Message-ID: <20090824170624.GA13190@topoi.pooq.com> I have one home directory, shared via NFS among several machines. Some run Debian lenny, some run Debian squeeze, one is and AMD64. Now I really appreciate the fact that when I run cm3 I get my executables in a system-dependent diractory. But it occurs to me that both Debian lenny and Debian squeeze end you using the directory LINUXLIBC6. Are the files generated there truly Debian-release-independent? Might they depend in some way on the contents of Debian's shared C libraries, for example? And if so, is there a way of overriding the word "LINUXLIBC6" with some other word so that I can distinguish them? By the time I ship them to /usr/local/cm3, the problem is over, of course, since eash system has its own /usr/local. But on the way to there, there could be mishaps in LinuxLIBC6. -- hendrik From jay.krell at cornell.edu Mon Aug 24 20:12:37 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Mon, 24 Aug 2009 14:12:37 -0400 Subject: [M3devel] platform names again. In-Reply-To: <20090824170624.GA13190@topoi.pooq.com> References: <20090824170624.GA13190@topoi.pooq.com> Message-ID: <5E5E68F4-45DF-47A7-A97D-483398DFF529@hotmail.com> We have the same compatibility of any uninteresting multithreaded C code, whatever that is. On reasonable systems that is full compatibility. I don't know if Linux is reasonable. For example 64 bit FreeBSD is not reasonable, struct sockaddr changed from 6.4 to 7.0. - Jay (phone) On Aug 24, 2009, at 1:06 PM, hendrik at topoi.pooq.com wrote: > I have one home directory, shared via NFS among several machines. > Some > run Debian lenny, some run Debian squeeze, one is and AMD64. > > Now I really appreciate the fact that when I run cm3 I get my > executables in a system-dependent diractory. > > But it occurs to me that both Debian lenny and Debian squeeze end you > using the directory LINUXLIBC6. > > Are the files generated there truly Debian-release-independent? Might > they depend in some way on the contents of Debian's shared C > libraries, > for example? And if so, is there a way of overriding the word > "LINUXLIBC6" with some other word so that I can distinguish > them? > > By the time I ship them to /usr/local/cm3, the problem is over, of > course, since eash system has its own /usr/local. But on the way to > there, there could be mishaps in LinuxLIBC6. > > -- hendrik > > From jay.krell at cornell.edu Mon Aug 24 22:58:56 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 24 Aug 2009 20:58:56 +0000 Subject: [M3devel] platform names again. In-Reply-To: <20090824182526.6A6871A209F@newasync.async.caltech.edu> References: <20090824170624.GA13190@topoi.pooq.com> <5E5E68F4-45DF-47A7-A97D-483398DFF529@hotmail.com> <20090824182526.6A6871A209F@newasync.async.caltech.edu> Message-ID: I'm not sure that is true. I know some of the BSDs sometimes carry compatibility libraries -- old versions of libc. I'm not sure the struct sockaddr is a libc change or a kernel change. The mention in the release notes sounds like possibly a kernel change. I find the level of incompatibility knowingly introduced surprising in some of these systems. The commercial systems all seem to try and do achieve much better. As to more of the original questions, no, I don't think there is much you can do about the "LINUXLIBC6" directory name, in the distributed packages. For when you build from source, BUILD_DIR and TARGET are strictly speaking separate values. BUILD_DIR perhaps should be more fine grained and include more of uname. Ultimately we may very well go back to a release form of: assembly code for all the Modula-3 code, that goes into just cm3 uncompiled C code, again just what cm3 uses a makefile source to everything else That will address this issue. And then specific builds for specific systems, like Debian 4.0, Debian 5.0, OpenSUSE 11.0, Fedora 10, etc., the small number we can afford to provide -- possibly in the generic form, possibly in rpm/deb format as the systems "prefer" -- note that this is two separate variables -- the packaging format and the actual ABI. It would be good to nail this all down with more certainty -- what actually has changed in the past and/or is likely to change in the future. I wish the set was empty, but 64bit FreeBSD provides enough of an example to prove it is not. But, I have to ask, how the check do things like Adobe Flash, Acrobat Reader, etc. work? - Jay ---------------------------------------- > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] platform names again. > Date: Mon, 24 Aug 2009 11:25:26 -0700 > From: mika at newasync.async.caltech.edu > > > On FreeBSD, I find that generally you can install the compiler and > libraries and headers from the older version and always have that work. > > You cannot, however, expect to use a compiler, or an object, from a > newer version of the system on an older version and have it work. > > Mika > > jay.krell at cornell.edu writes: >>We have the same compatibility of any uninteresting multithreaded C >>code, whatever that is. >>On reasonable systems that is full compatibility. I don't know if >>Linux is reasonable. For example 64 bit FreeBSD is not reasonable, >>struct sockaddr changed from 6.4 to 7.0. >> >> - Jay (phone) >> >>On Aug 24, 2009, at 1:06 PM, hendrik at topoi.pooq.com wrote: >> >>> I have one home directory, shared via NFS among several machines. >>> Some >>> run Debian lenny, some run Debian squeeze, one is and AMD64. >>> >>> Now I really appreciate the fact that when I run cm3 I get my >>> executables in a system-dependent diractory. >>> >>> But it occurs to me that both Debian lenny and Debian squeeze end you >>> using the directory LINUXLIBC6. >>> >>> Are the files generated there truly Debian-release-independent? Might >>> they depend in some way on the contents of Debian's shared C >>> libraries, >>> for example? And if so, is there a way of overriding the word >>> "LINUXLIBC6" with some other word so that I can distinguish >>> them? >>> >>> By the time I ship them to /usr/local/cm3, the problem is over, of >>> course, since eash system has its own /usr/local. But on the way to >>> there, there could be mishaps in LinuxLIBC6. >>> >>> -- hendrik >>> >>> From jay.krell at cornell.edu Mon Aug 24 23:19:17 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 24 Aug 2009 21:19:17 +0000 Subject: [M3devel] ignored errors Message-ID: http://www.modula3.com:8080/view/SOLgnu/job/cm3-makedist-SOLgnu/11/console === package m3-sys/cminstall === +++ cm3 -build -override $RARGS -DROOT='/home/hudson/workspace/cm3-makedist-SOLgnu/cm3' -DCM3_VERSION_TEXT='5.8.3' -DCM3_VERSION_NUMBER='050803' -DCM3_LAST_CHANGED='2009-08-22' +++ /bin/sh: /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/m3-tools/m3bundle/SOLsun/m3bundle: not found "/home/hudson/workspace/cm3-makedist-SOLgnu/cm3/m3-libs/libm3/src/bundleintf/bundle.tmpl", line 53: quake runtime error: exit 1: /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/m3-tools/m3bundle/SOLsun/m3bundle -name Setup -element config ../src/config/SOLgnu --procedure-- -line- -file--- exec -- bundle 53 /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/m3-libs/libm3/src/bundleintf/bundle.tmpl include_dir 17 /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/m3-sys/cminstall/src/m3makefile 9 /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/m3-sys/cminstall/SOLgnu/m3make.args --- building in SOLgnu --- /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/m3-tools/m3bundle/SOLsun/m3bundle -name Setup -element config ../src/config/SOLgnu Fatal Error: package build failed ==> m3-sys/cminstall done Seems like that should not be ignored. I'll try to fix the actual error -- host vs. target -- SOLsun vs. SOLgnu. stage 2: installing cm3 compiler ---------------------------------------------------------------------------- installing /home/hudson/tmp/cm3/bin/cm3 /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/scripts/make-bin-dist-min.sh: strip: not found installing /home/hudson/tmp/cm3/bin/cm3cg /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/scripts/make-bin-dist-min.sh: strip: not found configuring temporary config file /home/hudson/tmp/cm3/bin/cm3.cfg cp: /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/m3-sys/cminstall/src/config-no-install/CVS: is a directory not sure if that should be ignored. I can fix it too, like: for a in [ /usr/ccs/bin/strip strip ]; then if [ type $a ]; then STRIP=$a fi fi Preferably put the options in the other order, if there is a "break" command in sh for for loops. - Jay From jay.krell at cornell.edu Mon Aug 24 23:22:01 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 24 Aug 2009 21:22:01 +0000 Subject: [M3devel] RC3 tag Message-ID: I don't see commit mails about this, so, fyi: I moved the RC3 tag forward: scripts/sysinfo.sh scripts/regression/defs.sh m3-sys/m3cc/src/m3makefile m3-sys/m3cc/src/gnucc.common (rename it gnucc.quake?) m3-sys/m3cc/src/gnumake.common (rename it gnumake.quake?) TAR was unconditionally being set to tar, which is wrong on Solaris without hacks. No attempt to set TAR or PATH in Hudson could fix that, nor do I think that would be the right fix. I might move m3gdb/src/m3makefile forward too, and something regarding bundle, and maybe more scripts for the strip error. - Jay From hendrik at topoi.pooq.com Tue Aug 25 01:31:18 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 24 Aug 2009 19:31:18 -0400 Subject: [M3devel] platform names again. In-Reply-To: References: <20090824170624.GA13190@topoi.pooq.com> <5E5E68F4-45DF-47A7-A97D-483398DFF529@hotmail.com> <20090824182526.6A6871A209F@newasync.async.caltech.edu> Message-ID: <20090824233118.GB13751@topoi.pooq.com> On Mon, Aug 24, 2009 at 08:58:56PM +0000, Jay K wrote: > > I'm not sure that is true. > I know some of the BSDs sometimes carry compatibility libraries -- old versions of libc. > I'm not sure the struct sockaddr is a libc change or a kernel change. > The mention in the release notes sounds like possibly a kernel change. > > > I find the level of incompatibility knowingly introduced surprising in some of these systems. > The commercial systems all seem to try and do achieve much better. > > > As to more of the original questions, no, I don't think there is much > you can do about the "LINUXLIBC6" directory name, in the distributed > packages. For when you build from source, BUILD_DIR and TARGET are > strictly speaking separate values. BUILD_DIR perhaps should be more > fine grained and include more of uname. So does TARGET identify the target platform and does BUILD_DIR identify the name of the directory (in this case .../LINUXLIBC6/ ) into which all the derived files should go? Could BUILD_DIR be overridden? That would suffice. I'd just pick a different BUILD_DIR when I compile on one of y systems. > > > Ultimately we may very well go back to a release form of: > assembly code for all the Modula-3 code, that goes into just cm3 > uncompiled C code, again just what cm3 uses > a makefile > source to everything else > > > That will address this issue. > > > And then specific builds for specific systems, like Debian 4.0, Debian 5.0, OpenSUSE 11.0, Fedora 10, etc., the small number we can afford to provide -- possibly in the generic form, possibly in rpm/deb format as the systems "prefer" -- note that this is two separate variables -- the packaging format and the actual ABI. > > > It would be good to nail this all down with more certainty -- what actually has changed in the past and/or is likely to change in the future. I wish the set was empty, but 64bit FreeBSD provides enough of an example to prove it is not. > > > But, I have to ask, how the check do things like Adobe Flash, Acrobat > Reader, etc. work? Every now and them Adobe Flash just stops working altogether on my system. -- hendrik From jay.krell at cornell.edu Tue Aug 25 03:08:31 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 25 Aug 2009 01:08:31 +0000 Subject: [M3devel] platform names again. In-Reply-To: <20090824233118.GB13751@topoi.pooq.com> References: <20090824170624.GA13190@topoi.pooq.com> <5E5E68F4-45DF-47A7-A97D-483398DFF529@hotmail.com> <20090824182526.6A6871A209F@newasync.async.caltech.edu> <20090824233118.GB13751@topoi.pooq.com> Message-ID: Yes BUILD_DIR apparently is meant to be overridable/changable. I'm not sure if all the various tools that kinda sorta know what is going on will play along. When I pointed out that TARGET does not necessarily equal BUILD_DIR, Randy said that would break cm3ide. Yet it was apparently always theoretically true, for profiled builds. Not that I have done a profiled build. And it is always true in practise. Since I never do a profiled build and probably nobody else does either. But you can try varying it. Try this: in config file, change BUILD_DIR = whatever to if !defined("BUILD_DIR)" around BUILD_DIR = whatever end and then on the cm3 command line, try cm3 -DBUILD_DIR=foo scripts -realclean will tend to not play along here. - Jay ---------------------------------------- > Date: Mon, 24 Aug 2009 19:31:18 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] platform names again. > > On Mon, Aug 24, 2009 at 08:58:56PM +0000, Jay K wrote: >> >> I'm not sure that is true. >> I know some of the BSDs sometimes carry compatibility libraries -- old versions of libc. >> I'm not sure the struct sockaddr is a libc change or a kernel change. >> The mention in the release notes sounds like possibly a kernel change. >> >> >> I find the level of incompatibility knowingly introduced surprising in some of these systems. >> The commercial systems all seem to try and do achieve much better. >> >> >> As to more of the original questions, no, I don't think there is much >> you can do about the "LINUXLIBC6" directory name, in the distributed >> packages. For when you build from source, BUILD_DIR and TARGET are >> strictly speaking separate values. BUILD_DIR perhaps should be more >> fine grained and include more of uname. > > So does TARGET identify the target platform and does BUILD_DIR identify > the name of the directory (in this case .../LINUXLIBC6/ ) into which all > the derived files should go? Could BUILD_DIR be overridden? That would > suffice. I'd just pick a different BUILD_DIR when I compile on one of y > systems. > >> >> >> Ultimately we may very well go back to a release form of: >> assembly code for all the Modula-3 code, that goes into just cm3 >> uncompiled C code, again just what cm3 uses >> a makefile >> source to everything else >> >> >> That will address this issue. >> >> >> And then specific builds for specific systems, like Debian 4.0, Debian 5.0, OpenSUSE 11.0, Fedora 10, etc., the small number we can afford to provide -- possibly in the generic form, possibly in rpm/deb format as the systems "prefer" -- note that this is two separate variables -- the packaging format and the actual ABI. >> >> >> It would be good to nail this all down with more certainty -- what actually has changed in the past and/or is likely to change in the future. I wish the set was empty, but 64bit FreeBSD provides enough of an example to prove it is not. >> >> >> But, I have to ask, how the check do things like Adobe Flash, Acrobat >> Reader, etc. work? > > Every now and them Adobe Flash just stops working altogether on my > system. > > -- hendrik From hendrik at topoi.pooq.com Tue Aug 25 03:36:10 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 24 Aug 2009 21:36:10 -0400 Subject: [M3devel] How to compile system from (modified) source? Message-ID: <20090825013610.GA13985@topoi.pooq.com> I downloaded the complete source tree via cvs. I downloaded some of the RC3 archives. I start with an empty /usr/local/cm3. I install the core and RC3 gui archives. I make a copy of the source tree so as not to mess with the original. I make small changes to ButtonVBT.i3 and ButtonVBT.m3 I run the script do-cm3-std.sh It fails in odbc. I figure maybe I don;t have the right db stuff on my system and modify do-cm3-std.sh by removing all packages having anything to do with db. Hereby I replace toe command P=`lots of stuff` by P="long list of packages" I obtained the long list by sticking an echo $P into the script, copying the result into the script, and removing odbc postgres95 db smalldb stablegen stable Now I rerun the script. The package I modified appears to compile withoug problems. In fact, the script seems to compile everything but doesn't seem to ship anything. Aha! I forgot to say "ship". Now I rerun again, specifying "ship". Almost all package fails to ship with the message: package was built with overrides, not shipping. How am I supposed to do this. -- hendrik From hendrik at topoi.pooq.com Tue Aug 25 03:53:43 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 24 Aug 2009 21:53:43 -0400 Subject: [M3devel] my small changes to ButtonVBT. In-Reply-To: <20090825013610.GA13985@topoi.pooq.com> References: <20090825013610.GA13985@topoi.pooq.com> Message-ID: <20090825015343.GA14032@topoi.pooq.com> On Mon, Aug 24, 2009 at 09:36:10PM -0400, hendrik at topoi.pooq.com wrote: > > I make small changes to ButtonVBT.i3 and ButtonVBT.m3 By the way, here are the small changes: hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ cvs diff cvs diff: Diffing . Index: ButtonVBT.i3 =================================================================== RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.i3,v retrieving revision 1.2 diff -r1.2 ButtonVBT.i3 39a40 > act(READONLY cd: VBT.MouseRec); Index: ButtonVBT.m3 =================================================================== RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.m3,v retrieving revision 1.2 diff -r1.2 ButtonVBT.m3 28c28,29 < init := Be --- > init := Be; > act := act 46a48,52 > PROCEDURE act(v : T; READONLY cd: VBT.MouseRec) = > BEGIN > v.action(v, cd); > END act; > 59c65 < v.action(v, cd); --- > v.act(cd); hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ -- hendrik From jay.krell at cornell.edu Tue Aug 25 03:56:21 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 25 Aug 2009 01:56:21 +0000 Subject: [M3devel] How to compile system from (modified) source? In-Reply-To: <20090825013610.GA13985@topoi.pooq.com> References: <20090825013610.GA13985@topoi.pooq.com> Message-ID: apt-get install unixodbc etc. ? ./do-cm3-std.sh buildship ./do-pkg.sh buildship list of packages The scripts just cd around and run cm3 -build and/or cm3 -ship and/or other commands. Do ./do-cm3-std.sh realclean to remove the "local" build you did. - Jay ---------------------------------------- > Date: Mon, 24 Aug 2009 21:36:10 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: [M3devel] How to compile system from (modified) source? > > I downloaded the complete source tree via cvs. > > I downloaded some of the RC3 archives. > > I start with an empty /usr/local/cm3. > > I install the core and RC3 gui archives. > > I make a copy of the source tree so as not to mess with the original. > > I make small changes to ButtonVBT.i3 and ButtonVBT.m3 > > I run the script do-cm3-std.sh > > It fails in odbc. > > I figure maybe I don;t have the right db stuff on my system and modify > do-cm3-std.sh by removing all packages having anything to do with db. > Hereby I replace toe command P=`lots of stuff` > by P="long list of packages" > > I obtained the long list by sticking an echo $P into the script, copying > the result into the script, and removing odbc postgres95 db smalldb > stablegen stable > > Now I rerun the script. The package I modified appears to compile > withoug problems. In fact, the script seems to compile everything but > doesn't seem to ship anything. Aha! I forgot to say "ship". > > Now I rerun again, specifying "ship". Almost all package fails to ship > with the message: > package was built with overrides, not shipping. > > How am I supposed to do this. > > -- hendrik > From hendrik at topoi.pooq.com Tue Aug 25 04:45:50 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 24 Aug 2009 22:45:50 -0400 Subject: [M3devel] How to compile system from (modified) source? In-Reply-To: References: <20090825013610.GA13985@topoi.pooq.com> Message-ID: <20090825024550.GA14124@topoi.pooq.com> On Tue, Aug 25, 2009 at 01:56:21AM +0000, Jay K wrote: > > apt-get install unixodbc > etc. > ? > > ./do-cm3-std.sh buildship > > ./do-pkg.sh buildship list of packages > > > The scripts just cd around and run cm3 -build and/or cm3 -ship and/or other commands. > > Do ./do-cm3-std.sh realclean to remove the "local" build you did. Yay! It works! -- hendrik > > > - Jay > > > > > > > ---------------------------------------- > > Date: Mon, 24 Aug 2009 21:36:10 -0400 > > From: hendrik at topoi.pooq.com > > To: m3devel at elegosoft.com > > Subject: [M3devel] How to compile system from (modified) source? > > > > I downloaded the complete source tree via cvs. > > > > I downloaded some of the RC3 archives. > > > > I start with an empty /usr/local/cm3. > > > > I install the core and RC3 gui archives. > > > > I make a copy of the source tree so as not to mess with the original. > > > > I make small changes to ButtonVBT.i3 and ButtonVBT.m3 > > > > I run the script do-cm3-std.sh > > > > It fails in odbc. > > > > I figure maybe I don;t have the right db stuff on my system and modify > > do-cm3-std.sh by removing all packages having anything to do with db. > > Hereby I replace toe command P=`lots of stuff` > > by P="long list of packages" > > > > I obtained the long list by sticking an echo $P into the script, copying > > the result into the script, and removing odbc postgres95 db smalldb > > stablegen stable > > > > Now I rerun the script. The package I modified appears to compile > > withoug problems. In fact, the script seems to compile everything but > > doesn't seem to ship anything. Aha! I forgot to say "ship". > > > > Now I rerun again, specifying "ship". Almost all package fails to ship > > with the message: > > package was built with overrides, not shipping. > > > > How am I supposed to do this. > > > > -- hendrik > > From hendrik at topoi.pooq.com Tue Aug 25 05:01:14 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 24 Aug 2009 23:01:14 -0400 Subject: [M3devel] small design problem in ButtonVBT? In-Reply-To: <20090401120347.x8cneize8oscg44o@mail.elegosoft.com> References: <20090331145127.GB9624@topoi.pooq.com> <20090401120347.x8cneize8oscg44o@mail.elegosoft.com> Message-ID: <20090825030114.GA14152@topoi.pooq.com> On Wed, Apr 01, 2009 at 12:03:47PM +0200, Olaf Wagner wrote: > Quoting hendrik at topoi.pooq.com: > > >The BottonVBT contains an action, which is a procedure rather than a > >method. b This makes it awkward to subclass ButtonVBT becaue the action > >will still expect its first parameter to be a ButtonVBT instead of > >belonging to the subclass, and an explicit downcast of some sort will be > >needed to acess the subclass's members. > > > >The Trestle manual says this was a deliberate decision: > > > >: The action procedure is a field rather than a method in order to allow > >: buttons with different action procedures to share their method suites. > > > >I, however, find it massively inconvenient because it mans I have to > >resort to downcasting or the very kludgey VBT.GetProp to access what > >should be just there. I'd rather the action procedure was a method. > > > >But it should be possible to have the best of both worlds. Have an > >action2 (better name wanted here) method that is available for > >overriding, and by default calls the procedure in the existing action. > >field. That action2 method wounl then be called by Trestle wherever > >action is now called. > > > >Does anyone see problems with this? > > Sounds fine to me offhand. You should test your extensions with > some of the existing larger applications, like mentor and Juno-2, > of course. How should I go about testing my extensions with mentor and Juno-2? I don't know what they do. Is there an automated test? By the way, mentor and Juno (downloaded out of current CVS) do seem to compile and link correctly with this change on a 32-bit Debian squeeze system. I decided to call the new mathid 'act' instead of 'action2', by the way. It's a verb. -- hendrik From wagner at elegosoft.com Tue Aug 25 08:00:01 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 25 Aug 2009 08:00:01 +0200 Subject: [M3devel] ignored errors In-Reply-To: References: Message-ID: <20090825080001.4ptdm2ce8ws4oogk@mail.elegosoft.com> Quoting Jay K : > http://www.modula3.com:8080/view/SOLgnu/job/cm3-makedist-SOLgnu/11/console > === package m3-sys/cminstall === > +++ cm3 -build -override $RARGS > -DROOT='/home/hudson/workspace/cm3-makedist-SOLgnu/cm3' > -DCM3_VERSION_TEXT='5.8.3' -DCM3_VERSION_NUMBER='050803' > -DCM3_LAST_CHANGED='2009-08-22' +++ > /bin/sh: > /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/m3-tools/m3bundle/SOLsun/m3bundle: not > found > "/home/hudson/workspace/cm3-makedist-SOLgnu/cm3/m3-libs/libm3/src/bundleintf/bundle.tmpl", line 53: quake runtime error: exit 1: /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/m3-tools/m3bundle/SOLsun/m3bundle -name Setup -element config > ../src/config/SOLgnu > --procedure-- -line- -file--- > exec -- > bundle 53 > /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/m3-libs/libm3/src/bundleintf/bundle.tmpl > include_dir 17 > /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/m3-sys/cminstall/src/m3makefile > 9 > /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/m3-sys/cminstall/SOLgnu/m3make.args > --- building in SOLgnu --- > /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/m3-tools/m3bundle/SOLsun/m3bundle -name Setup -element config > ../src/config/SOLgnu > Fatal Error: package build failed > ==> m3-sys/cminstall done > > Seems like that should not be ignored. > I'll try to fix the actual error -- host vs. target -- SOLsun vs. SOLgnu. Probably the first stage of upgrade? And calling make-dist without a already-compiled cm3 installation? > stage 2: installing cm3 compiler > ---------------------------------------------------------------------------- > installing /home/hudson/tmp/cm3/bin/cm3 > /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/scripts/make-bin-dist-min.sh: > strip: not found > installing /home/hudson/tmp/cm3/bin/cm3cg > /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/scripts/make-bin-dist-min.sh: > strip: not found > configuring temporary config file /home/hudson/tmp/cm3/bin/cm3.cfg > cp: > /home/hudson/workspace/cm3-makedist-SOLgnu/cm3/m3-sys/cminstall/src/config-no-install/CVS: is a > directory > > not sure if that should be ignored. > I can fix it too, like: > > for a in [ /usr/ccs/bin/strip strip ]; then > if [ type $a ]; then > STRIP=$a > fi > fi We need /usr/ccs/bin in the PATH on Solaris. I just noticed that the PATH was reset to /usr/bin after the latest installation, but forgot about /usr/ccs/bin. > Preferably put the options in the other order, if there is a "break" > command in sh for for loops. We didn't need special handling for strip before AFAIK. It should be there on all POSIX systems. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Aug 25 08:07:01 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 25 Aug 2009 08:07:01 +0200 Subject: [M3devel] RC3 tag In-Reply-To: References: Message-ID: <20090825080701.cfz0fs2wao0880gc@mail.elegosoft.com> Quoting Jay K : > I don't see commit mails about this, so, fyi: > > I moved the RC3 tag forward: > scripts/sysinfo.sh > scripts/regression/defs.sh > m3-sys/m3cc/src/m3makefile > m3-sys/m3cc/src/gnucc.common (rename it gnucc.quake?) > m3-sys/m3cc/src/gnumake.common (rename it gnumake.quake?) > > TAR was unconditionally being set to tar, which is wrong on Solaris > without hacks. > No attempt to set TAR or PATH in Hudson could fix that, nor do I > think that would be the right fix. > > I might move m3gdb/src/m3makefile forward too, and something > regarding bundle, and maybe more scripts for the strip error. Let me know when that's done. I assume you've fixed the build error on Solaris. We should then rebuild all packages. Olaf PS: So far for just pressing a button to build the release packages... :-/ -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Aug 25 09:21:48 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 25 Aug 2009 07:21:48 +0000 Subject: [M3devel] ignored errors In-Reply-To: <20090825080001.4ptdm2ce8ws4oogk@mail.elegosoft.com> References: <20090825080001.4ptdm2ce8ws4oogk@mail.elegosoft.com> Message-ID: > Probably the first stage of upgrade? > And calling make-dist without a already-compiled cm3 installation? Yes, granted, probably unconvential that way. > We need /usr/ccs/bin in the PATH on Solaris. I just noticed that the > PATH was reset to /usr/bin after the latest installation, but forgot > about /usr/ccs/bin. I go back and forth here. I tried out emptying my Solaris .profile file etc. The default path is just /usr/bin. I have made things work with that. gcc, strip, ar, gtar, gmake are not in $PATH but they are present (in a "full" install of what Sun provides0. Usually I check $PATH first, let user override that way, though granted, for strip I was not consistent. - Jay From hendrik at topoi.pooq.com Tue Aug 25 13:29:47 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 25 Aug 2009 07:29:47 -0400 Subject: [M3devel] RC3 tag In-Reply-To: <20090825080701.cfz0fs2wao0880gc@mail.elegosoft.com> References: <20090825080701.cfz0fs2wao0880gc@mail.elegosoft.com> Message-ID: <20090825112947.GB14914@topoi.pooq.com> On Tue, Aug 25, 2009 at 08:07:01AM +0200, Olaf Wagner wrote: > > We should then rebuild all packages. With some distinction in the version numbers so people know which is which. RC3.1? RC4? -- hendrik > > Olaf > > PS: So far for just pressing a button to build the release packages... :-/ That's what's being debugged now. How long has it been since a release? -- hendrik From wagner at elegosoft.com Tue Aug 25 13:45:28 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 25 Aug 2009 13:45:28 +0200 Subject: [M3devel] HEADS UP: Rebuild RC3 or wait for RC4 next week? was Re: RC3 tag In-Reply-To: <20090825112947.GB14914@topoi.pooq.com> References: <20090825080701.cfz0fs2wao0880gc@mail.elegosoft.com> <20090825112947.GB14914@topoi.pooq.com> Message-ID: <20090825134528.ah9lydnwgwgs0skg@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > On Tue, Aug 25, 2009 at 08:07:01AM +0200, Olaf Wagner wrote: >> >> We should then rebuild all packages. > > With some distinction in the version numbers so people know which is > which. RC3.1? RC4? RC3.1 does not make sense. Doing everthing according to plan, we had to abandon RC3 and build RC4 now. The RC3 tag has been moved which shouldn't happen strictly speaking. There's no mechanism in CVS to lock a tag though. There have been only minor corrections, mostly in the build tooling and system dependencies AFAIK. So we could make a concession and rebuild the RC3 packages as they only have been announced on the m3 mailing lists so far. I'd vote for that in this case. Switching to RC4 requires changing several scripts and docs again and applying a new tag. I cannot do that from here, nor will it probably be done until the next weekend. So more delay (until somebody else steps in). NT386 failures are still not resolved, too, AFAIK. Any volunteers? Please note that the built packages now available for RC3 are mostly working, at least better than RC2. But SOLgnu and NT386 couldn't be built with the RC3 tag. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Aug 25 18:28:34 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 25 Aug 2009 16:28:34 +0000 Subject: [M3devel] timeout at the end of makedist? Message-ID: http://www.modula3.com:8080/view/SOLgnu/job/cm3-makedist-SOLgnu/14/console all the way at the bottom: -rw-r--r-- 1 hudson other 2785402 Aug 25 05:56 /home/hudson/tmp/cm3-bin-ws-game-SOLgnu-5.8.3-RC3.tgz Received disconnect from 88.198.39.217: 2: Timeout, your session not responding. lost connection Finished: SUCCESS This is copying the packages to birch? It shouldn't report success? We should do some incremental copy? - Jay From jay.krell at cornell.edu Tue Aug 25 18:31:55 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 25 Aug 2009 16:31:55 +0000 Subject: [M3devel] HEADS UP: Rebuild RC3 or wait for RC4 next week? was Re: RC3 tag In-Reply-To: <20090825134528.ah9lydnwgwgs0skg@mail.elegosoft.com> References: <20090825080701.cfz0fs2wao0880gc@mail.elegosoft.com> <20090825112947.GB14914@topoi.pooq.com> <20090825134528.ah9lydnwgwgs0skg@mail.elegosoft.com> Message-ID: Please let's not create extra process and secretarial work. It's bad enough to have to any branching. I'll move the RC3 tag forward as needed for SOLgnu, SOLsun, NT386. SOLgnu looks good now except for the timeout at the end with scp, and the cvsup problem to fix. - Jay ---------------------------------------- > Date: Tue, 25 Aug 2009 13:45:28 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] HEADS UP: Rebuild RC3 or wait for RC4 next week? was Re: RC3 tag > > Quoting hendrik at topoi.pooq.com: > >> On Tue, Aug 25, 2009 at 08:07:01AM +0200, Olaf Wagner wrote: >>> >>> We should then rebuild all packages. >> >> With some distinction in the version numbers so people know which is >> which. RC3.1? RC4? > > RC3.1 does not make sense. Doing everthing according to plan, we had > to abandon RC3 and build RC4 now. The RC3 tag has been moved which shouldn't > happen strictly speaking. There's no mechanism in CVS to lock a tag though. > > There have been only minor corrections, mostly in the build tooling > and system dependencies AFAIK. So we could make a concession and rebuild > the RC3 packages as they only have been announced on the m3 mailing lists > so far. I'd vote for that in this case. > > Switching to RC4 requires changing several scripts and docs again > and applying a new tag. I cannot do that from here, nor will it probably > be done until the next weekend. So more delay (until somebody else > steps in). NT386 failures are still not resolved, too, AFAIK. > Any volunteers? > > Please note that the built packages now available for RC3 are mostly > working, at least better than RC2. But SOLgnu and NT386 couldn't be > built with the RC3 tag. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Tue Aug 25 18:38:35 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 25 Aug 2009 16:38:35 +0000 Subject: [M3devel] SOLsun and versions Message-ID: Fyi, I'm running a very current Solaris 2.10 2009/05 and its SunStudio 12. http://www.modula3.com:8080/view/SOLsun/job/boot-solsun/9/console "../src/os/POSIX/FilePosixC.c", line 19: warning: typedef redeclared: flock_t cc: Warning: -xarch=v8plus is deprecated, use -m32 -xarch=sparc instead cc: Warning: -xarch=v8plus is deprecated, use -m32 -xarch=sparc instead "/home/hudson/work/solsun/cm3-inst/ssol/rel-d5.8.2/pkg/m3core/src/unix/Common/m3unix.h", line 83: warning: typedef redeclared: timespec_t "../src/os/POSIX/FSPosixC.c", line 12: warning: typedef redeclared: dirent_t cc: Warning: -xarch=v8plus is deprecated, use -m32 -xarch=sparc instead cc: Warning: -xarch=v8plus is deprecated, use -m32 -xarch=sparc instead Undefined first referenced symbol in file __floatdidf FilePosix.mo Could very well be that if/when I fix these or some of them, we'll lose compatibility with older releases. Maybe I'll read the man pages and find out what is compatibile with what. Maybe we can/should do something more "like" autoconf in places. - Jay From jay.krell at cornell.edu Tue Aug 25 19:07:52 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 25 Aug 2009 17:07:52 +0000 Subject: [M3devel] HEADS UP: Rebuild RC3 or wait for RC4 next week? was Re: RC3 tag In-Reply-To: References: <20090825080701.cfz0fs2wao0880gc@mail.elegosoft.com> <20090825112947.GB14914@topoi.pooq.com> <20090825134528.ah9lydnwgwgs0skg@mail.elegosoft.com> Message-ID: The NT386 problems look small btw. "C:\cygwin\home\elego\tmp\cm3\pkg\cit_util\src\generics.tmpl", line 38: quake runtime error: exit 1: C:\cygwin\home\elego\workspace\cm3-makedist-NT386\cm3\caltech-parser\parserlib\klex\NT386\klex ..\src\Calc.l -o CalcLex.i3 -t ..\src\Calc.t -ti3 CalcTok.i3 "C:\cygwin\home\elego\tmp\cm3\pkg\cit_util\src\generics.tmpl", line 38: quake runtime error: exit 1: C:\cygwin\home\elego\workspace\cm3-makedist-NT386\cm3\caltech-parser\parserlib\klex\NT386\klex ..\src\Calc.l -o CalcLex.i3 -t ..\src\Calc.t -ti3 CalcTok.i3 Fatal Error: package build failed errors during build-all; some packages will be missing m3-win/import-libs/NT386/.M3SHIP seems to be broken: make_dir("C:/cygwin/home/elego/tmp/cm3/lib") install_file("wsock32.lib", "C:/cygwin/home/elego/tmp/cm3/lib", "0775") Probably a matter of forward vs. backward slashes on the second set. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Date: Tue, 25 Aug 2009 16:31:55 +0000 > Subject: Re: [M3devel] HEADS UP: Rebuild RC3 or wait for RC4 next week? was Re: RC3 tag > > > Please let's not create extra process and secretarial work. It's bad enough to have to any branching. > I'll move the RC3 tag forward as needed for SOLgnu, SOLsun, NT386. > SOLgnu looks good now except for the timeout at the end with scp, and the cvsup problem to fix. > > - Jay > > ---------------------------------------- >> Date: Tue, 25 Aug 2009 13:45:28 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] HEADS UP: Rebuild RC3 or wait for RC4 next week? was Re: RC3 tag >> >> Quoting hendrik at topoi.pooq.com: >> >>> On Tue, Aug 25, 2009 at 08:07:01AM +0200, Olaf Wagner wrote: >>>> >>>> We should then rebuild all packages. >>> >>> With some distinction in the version numbers so people know which is >>> which. RC3.1? RC4? >> >> RC3.1 does not make sense. Doing everthing according to plan, we had >> to abandon RC3 and build RC4 now. The RC3 tag has been moved which shouldn't >> happen strictly speaking. There's no mechanism in CVS to lock a tag though. >> >> There have been only minor corrections, mostly in the build tooling >> and system dependencies AFAIK. So we could make a concession and rebuild >> the RC3 packages as they only have been announced on the m3 mailing lists >> so far. I'd vote for that in this case. >> >> Switching to RC4 requires changing several scripts and docs again >> and applying a new tag. I cannot do that from here, nor will it probably >> be done until the next weekend. So more delay (until somebody else >> steps in). NT386 failures are still not resolved, too, AFAIK. >> Any volunteers? >> >> Please note that the built packages now available for RC3 are mostly >> working, at least better than RC2. But SOLgnu and NT386 couldn't be >> built with the RC3 tag. >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> From hendrik at topoi.pooq.com Tue Aug 25 20:13:05 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 25 Aug 2009 14:13:05 -0400 Subject: [M3devel] How to compile system from (modified) source? In-Reply-To: References: <20090825013610.GA13985@topoi.pooq.com> Message-ID: <20090825181305.GB15646@topoi.pooq.com> On Tue, Aug 25, 2009 at 01:56:21AM +0000, Jay K wrote: > > apt-get install unixodbc > etc. > ? I already had unixodbc installed on my system. Just in case the installation was affected by the build vd buildship problem, I restored the std script to its original code (uncommenting the fgrep line I had commented out, and commenting out the P= line with the long list I had put in, and reran. Here's what appears to be the relevant part of the log: === package m3-db/odbc === +++ cm3 -build -DROOT='/farhome/hendrik/cm3/love-sq/cm3' -DCM3_VERSION_TEXT='d5.8.2' -DCM3_VERSION_NUMBER='050802' -DCM3_LAST_CHANGED='2009-07-15' $RARGS && cm3 -ship $RARGS -DROOT='/farhome/hendrik/cm3/love-sq/cm3' -DCM3_VERSION_TEXT='d5.8.2' -DCM3_VERSION_NUMBER='050802' -DCM3_LAST_CHANGED='2009-07-15' +++ --- building in LINUXLIBC6 --- ignoring ../src/m3overrides new "/usr/local/cm3/pkg/m3core/LINUXLIBC6/libm3core.a" -> archiving libm3odbc.a /usr/bin/ld: cannot find -lodbc collect2: ld returned 1 exit status make_lib => 1 librarian failed building: m3odbc Fatal Error: package build failed *** execution of cm3 -build -DROOT='/farhome/hendrik/cm3/love-sq/cm3' -DCM3_VERSION_TEXT='d5.8.2' -DCM3_VERSION_NUMBER='050802' -DCM3_LAST_CHANGED='2009-07-15' $RARGS && cm3 -ship $RARGS -DROOT='/farhome/hendrik/cm3/love-sq/cm3' -DCM3_VERSION_TEXT='d5.8.2' -DCM3_VERSION_NUMBER='050802' -DCM3_LAST_CHANGED='2009-07-15' failed *** hendrik at lovesong:~/cm3/love-sq/cm3$ exit Script done, file is log9-with-db-again And here's the list of files for package unixodbc in squeeze, according to the Debian packages website in case it's useful: /usr/bin/isql /usr/bin/iusql /usr/lib/libgtrtst.so.1 /usr/lib/libgtrtst.so.1.0.0 /usr/lib/libodbc.so.1 /usr/lib/libodbc.so.1.0.0 /usr/lib/libodbccr.so.1 /usr/lib/libodbccr.so.1.0.0 /usr/lib/odbc/libnn.so /usr/lib/odbc/libodbctxt.so /usr/share/doc/unixodbc/AUTHORS /usr/share/doc/unixodbc/NEWS.gz /usr/share/doc/unixodbc/README /usr/share/doc/unixodbc/README.GTK /usr/share/doc/unixodbc/README.MySql /usr/share/doc/unixodbc/changelog.Debian.gz /usr/share/doc/unixodbc/changelog.gz /usr/share/doc/unixodbc/copyright /usr/share/lintian/overrides/unixodbc /usr/share/man/man1/isql.1.gz /usr/share/man/man1/iusql.1.gz -- hendrik From jay.krell at cornell.edu Tue Aug 25 21:19:05 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Tue, 25 Aug 2009 15:19:05 -0400 Subject: [M3devel] SOLsun and versions In-Reply-To: References: Message-ID: <55A850EF-4F94-4568-8A00-D4CD5D54F9CD@hotmail.com> (truncated!) - Jay (phone) On Aug 25, 2009, at 12:38 PM, Jay K wrote: > > Fyi, I'm running a very current Solaris 2.10 2009/05 and its > SunStudio 12 From jay.krell at cornell.edu Tue Aug 25 21:22:08 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Tue, 25 Aug 2009 15:22:08 -0400 Subject: [M3devel] How to compile system from (modified) source? In-Reply-To: <20090825181305.GB15646@topoi.pooq.com> References: <20090825013610.GA13985@topoi.pooq.com> <20090825181305.GB15646@topoi.pooq.com> Message-ID: <8A772E75-0495-44E2-9751-3032E9031FD4@hotmail.com> cd m3-db/odbc rm -rf LINUXLIBC6 cm3 -commands or look for odbc in install/bin/config/* - Jay (phone) On Aug 25, 2009, at 2:13 PM, hendrik at topoi.pooq.com wrote: > On Tue, Aug 25, 2009 at 01:56:21AM +0000, Jay K wrote: >> >> apt-get install unixodbc >> etc. >> ? > > I already had unixodbc installed on my system. > > Just in case the installation was affected by the build vd buildship > problem, I restored the std script to its original code (uncommenting > the fgrep line I had commented out, and commenting out the P= line > with > the long list I had put in, and reran. Here's what appears to be the > relevant part of the log: > > === package m3-db/odbc === > +++ cm3 -build -DROOT='/farhome/hendrik/cm3/love-sq/cm3' - > DCM3_VERSION_TEXT='d5.8.2' -DCM3_VERSION_NUMBER='050802' - > DCM3_LAST_CHANGED='2009-07-15' $RARGS && cm3 -ship $RARGS -DROOT='/ > farhome/hendrik/cm3/love-sq/cm3' -DCM3_VERSION_TEXT='d5.8.2' - > DCM3_VERSION_NUMBER='050802' -DCM3_LAST_CHANGED='2009-07-15' +++ > --- building in LINUXLIBC6 --- > > ignoring ../src/m3overrides > > new "/usr/local/cm3/pkg/m3core/LINUXLIBC6/libm3core.a" -> archiving > libm3odbc.a > /usr/bin/ld: cannot find -lodbc > collect2: ld returned 1 exit status > make_lib => 1 > librarian failed building: m3odbc > Fatal Error: package build failed > *** execution of cm3 -build -DROOT='/farhome/hendrik/cm3/love-sq/ > cm3' -DCM3_VERSION_TEXT='d5.8.2' -DCM3_VERSION_NUMBER='050802' - > DCM3_LAST_CHANGED='2009-07-15' $RARGS && cm3 -ship $RARGS -DROOT='/ > farhome/hendrik/cm3/love-sq/cm3' -DCM3_VERSION_TEXT='d5.8.2' - > DCM3_VERSION_NUMBER='050802' -DCM3_LAST_CHANGED='2009-07-15' failed > *** > hendrik at lovesong:~/cm3/love-sq/cm3$ exit > Script done, file is log9-with-db-again > > > And here's the list of files for package unixodbc in squeeze, > according to the Debian packages website in case it's useful: > > /usr/bin/isql > /usr/bin/iusql > /usr/lib/libgtrtst.so.1 > /usr/lib/libgtrtst.so.1.0.0 > /usr/lib/libodbc.so.1 > /usr/lib/libodbc.so.1.0.0 > /usr/lib/libodbccr.so.1 > /usr/lib/libodbccr.so.1.0.0 > /usr/lib/odbc/libnn.so > /usr/lib/odbc/libodbctxt.so > /usr/share/doc/unixodbc/AUTHORS > /usr/share/doc/unixodbc/NEWS.gz > /usr/share/doc/unixodbc/README > /usr/share/doc/unixodbc/README.GTK > /usr/share/doc/unixodbc/README.MySql > /usr/share/doc/unixodbc/changelog.Debian.gz > /usr/share/doc/unixodbc/changelog.gz > /usr/share/doc/unixodbc/copyright > /usr/share/lintian/overrides/unixodbc > /usr/share/man/man1/isql.1.gz > /usr/share/man/man1/iusql.1.gz > > > -- hendrik > From wagner at elegosoft.com Tue Aug 25 22:30:24 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 25 Aug 2009 22:30:24 +0200 Subject: [M3devel] timeout at the end of makedist? In-Reply-To: References: Message-ID: <20090825223024.wye2lz0is44004cs@mail.elegosoft.com> Quoting Jay K : > http://www.modula3.com:8080/view/SOLgnu/job/cm3-makedist-SOLgnu/14/console > > all the way at the bottom: > > -rw-r--r-- 1 hudson other 2785402 Aug 25 05:56 > /home/hudson/tmp/cm3-bin-ws-game-SOLgnu-5.8.3-RC3.tgz > Received disconnect from 88.198.39.217: 2: Timeout, your session not > responding. > lost connection > Finished: SUCCESS > > > > This is copying the packages to birch? > It shouldn't report success? > We should do some incremental copy? scp, like rcp, is inherently unsafe (though more secure) :-/ We should try rsync via ssh instead. Though all ssh-based transfer seems to be a bot unreliable (especially from/to your net). Do we have rsync on all systems? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Aug 25 23:11:33 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 25 Aug 2009 21:11:33 +0000 Subject: [M3devel] timeout at the end of makedist? In-Reply-To: <20090825223024.wye2lz0is44004cs@mail.elegosoft.com> References: <20090825223024.wye2lz0is44004cs@mail.elegosoft.com> Message-ID: > Do we have rsync on all systems? No idea. I've never used it. - Jay From hendrik at topoi.pooq.com Wed Aug 26 02:26:06 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 25 Aug 2009 20:26:06 -0400 Subject: [M3devel] small design problem in ButtonVBT? In-Reply-To: <20090401120347.x8cneize8oscg44o@mail.elegosoft.com> References: <20090331145127.GB9624@topoi.pooq.com> <20090401120347.x8cneize8oscg44o@mail.elegosoft.com> Message-ID: <20090826002606.GB16386@topoi.pooq.com> On Wed, Apr 01, 2009 at 12:03:47PM +0200, Olaf Wagner wrote: > Quoting hendrik at topoi.pooq.com: > > >The BottonVBT contains an action, which is a procedure rather than a > >method. b This makes it awkward to subclass ButtonVBT becaue the action > >will still expect its first parameter to be a ButtonVBT instead of > >belonging to the subclass, and an explicit downcast of some sort will be > >needed to acess the subclass's members. > > > >The Trestle manual says this was a deliberate decision: > > > >: The action procedure is a field rather than a method in order to allow > >: buttons with different action procedures to share their method suites. > > > >I, however, find it massively inconvenient because it mans I have to > >resort to downcasting or the very kludgey VBT.GetProp to access what > >should be just there. I'd rather the action procedure was a method. > > > >But it should be possible to have the best of both worlds. Have an > >action2 (better name wanted here) method that is available for > >overriding, and by default calls the procedure in the existing action. > >field. That action2 method wounl then be called by Trestle wherever > >action is now called. > > > >Does anyone see problems with this? > > Sounds fine to me offhand. You should test your extensions with > some of the existing larger applications, like mentor and Juno-2, > of course. OK. Here's the patch. Would it be possible for someone to check it in for me? mentor runs fine with this change; I watched it animate a heap-sort. I have no idea what Juno is supposed to do, but it did respond to button-pushes. hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ cvs diff cvs diff: Diffing . Index: ButtonVBT.i3 =================================================================== RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.i3,v retrieving revision 1.2 diff -r1.2 ButtonVBT.i3 39a40 > act(READONLY cd: VBT.MouseRec); Index: ButtonVBT.m3 =================================================================== RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.m3,v retrieving revision 1.2 diff -r1.2 ButtonVBT.m3 28c28,29 < init := Be --- > init := Be; > act := act 46a48,52 > PROCEDURE act(v : T; READONLY cd: VBT.MouseRec) = > BEGIN > v.action(v, cd); > END act; > 59c65 < v.action(v, cd); --- > v.act(cd); hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ -- hendrik From jay.krell at cornell.edu Wed Aug 26 09:02:56 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 26 Aug 2009 07:02:56 +0000 Subject: [M3devel] caltech-parser NT386 Hudson problems Message-ID: I think the caltech-parser on NT386 problems are related to line endings. I'm not sure. I see it outputing carriage returns and backslash line continuations -- though Modula-3 has no such line continuations. I haven't been able to find the code in caltech-parser that does that. http://www.modula3.com:8080/computer/elego-win-vm/configure I removed the CYGWIN variable, that previously was nobinmode. The tasks also fiddle around with the mount command. I think all the -o options should be removed. I've left it alone for now. We should try to make it work either way, perhaps. I'm not super keen on changing my local setting, nor debugging it remotely -- it is slow. If pushed I'll try changing my local setting. I set: C:\>set cyg CYGWIN=server but that's probably not needed. and: C:\>mount c:\cygwin\bin on /usr/bin type system (binmode) c:\cygwin\lib on /usr/lib type system (binmode) c:\cygwin on / type system (binmode) c:\obj on /obj type system (binmode) c:\src on /src type system (binmode) c: on /cygdrive/c type user (binmode,noumount) The caltech-parser/parerlib/parerlib/test directory works for me. I get newlines only in the output. Given that the caltech-parser binaries aren't cygwin binaries, I'm actually not sure how any of this could matter. Could be cvs though. Yes, that is a big possibility. For example I only got klex to output files by first running dos2unix on some files, which shouldn't do anything. caltech-parser should imho accept \r and \r\n as line delimiters. I'm not sure if empty lines are significant to it. If not, this is easy. If so, it appears not. It appears to split lines on single characters. - Jay From jay.krell at cornell.edu Wed Aug 26 09:18:03 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 26 Aug 2009 07:18:03 +0000 Subject: [M3devel] caltech-parser NT386 Hudson problems In-Reply-To: References: Message-ID: On second thought, upon further investigation, I changed all the mount commands. We'll see how that does. Probably should also re-checkout all the workspaces. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Date: Wed, 26 Aug 2009 07:02:56 +0000 > Subject: [M3devel] caltech-parser NT386 Hudson problems > > > I think the caltech-parser on NT386 problems are related to line endings. > I'm not sure. > I see it outputing carriage returns and backslash line continuations -- > though Modula-3 has no such line continuations. > I haven't been able to find the code in caltech-parser that does that. > > > http://www.modula3.com:8080/computer/elego-win-vm/configure > > > I removed the CYGWIN variable, that previously was nobinmode. > The tasks also fiddle around with the mount command. > I think all the -o options should be removed. > I've left it alone for now. > > > We should try to make it work either way, perhaps. > > > I'm not super keen on changing my local setting, nor debugging > it remotely -- it is slow. If pushed I'll try changing my local setting. > > > I set: > > > C:\>set cyg > CYGWIN=server > > > but that's probably not needed. > > and: > C:\>mount > c:\cygwin\bin on /usr/bin type system (binmode) > c:\cygwin\lib on /usr/lib type system (binmode) > c:\cygwin on / type system (binmode) > c:\obj on /obj type system (binmode) > c:\src on /src type system (binmode) > c: on /cygdrive/c type user (binmode,noumount) > > > The caltech-parser/parerlib/parerlib/test directory works for me. > I get newlines only in the output. > > > Given that the caltech-parser binaries aren't cygwin binaries, I'm > actually not sure how any of this could matter. > > > Could be cvs though. Yes, that is a big possibility. > For example I only got klex to output files by first running dos2unix on some > files, which shouldn't do anything. > > > caltech-parser should imho accept \r and \r\n as line delimiters. > I'm not sure if empty lines are significant to it. > If not, this is easy. > If so, it appears not. It appears to split lines on single characters. > > > - Jay From wagner at elegosoft.com Wed Aug 26 10:04:41 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 26 Aug 2009 10:04:41 +0200 Subject: [M3devel] small design problem in ButtonVBT? In-Reply-To: <20090826002606.GB16386@topoi.pooq.com> References: <20090331145127.GB9624@topoi.pooq.com> <20090401120347.x8cneize8oscg44o@mail.elegosoft.com> <20090826002606.GB16386@topoi.pooq.com> Message-ID: <20090826100441.ftj2zoekg0kook0w@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > OK. Here's the patch. Would it be possible for someone to check it in > for me? I can do that tonight if nobody is faster. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Aug 26 17:37:16 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 26 Aug 2009 15:37:16 +0000 Subject: [M3devel] running cm3 by relative path Message-ID: Running cm3 by relative path seems to act wierd. $ ./last-ok/bin/cm3 -version Critical Mass Modula-3 version 5.8.3 last updated: 2009-08-22 compiled: 2009-08-25 09:52:28 configuration: ./last-ok/bin/cm3.cfg host: SOLgnu quake runtime error: "./last-ok/bin/cm3.cfg", line 2: quake runtime error: unabl e to open "./last-ok/bin/./last-ok/bin/config/SOLsun" for reading --procedure-- -line- -file--- include -- 2 ./last-ok/bin/cm3.cfg target: $ `pwd`/last-ok/bin/cm3 -version Critical Mass Modula-3 version 5.8.3 last updated: 2009-08-22 compiled: 2009-08-25 09:52:28 configuration: /home/hudson/work/cm3-inst/ssol-sun/last-ok/bin/cm3.cfg host: SOLgnu target: SOLsun I'll have to see if this is related to my recent change or not. I'm also seemingly not able to change host to SOLsun from SOLgnu but that's not likely a bug in cm3. -Jay From hendrik at topoi.pooq.com Wed Aug 26 20:44:17 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 26 Aug 2009 14:44:17 -0400 Subject: [M3devel] trying RC3 In-Reply-To: References: <20090824005658.GA11486@topoi.pooq.com> <20090824013245.GA11619@topoi.pooq.com> Message-ID: <20090826184417.GA18029@topoi.pooq.com> On Mon, Aug 24, 2009 at 02:43:52AM +0000, Jay K wrote: > > In CVS. > > - Jay Now that it seems some RC3 packages are being rebuilt, will this include new builds for LINUXLIBC6? If so, I'll try again with the new RC3. If not, I'll just wait for RC4. By the wat, P.S. I'm not sitting on he edge of my seat, waiting for a usable cvsup release. I have compiled my own. What I'm really doing here is testing the tgz packages. Just let me know when it's useful to test again. -- hendrik > > > ---------------------------------------- > > Date: Sun, 23 Aug 2009 21:32:45 -0400 > > From: hendrik at topoi.pooq.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] trying RC3 > > > > On Mon, Aug 24, 2009 at 01:07:25AM +0000, Jay K wrote: > >> > >> This is understood and fixed, specific to cvsup. > > > > Does 'fixed' mean you've replaced the RC3 archive, in which case I'll > > try it again soon, or that it'll be OK in RC4? > > > > Or just fixed in CVS? > > > >> > >> Thanks, > >> - Jay > > > > You're welcome. Each time a new RC comes out, I shunt aside my existing > > cm3, and try an install. Then I report on the problems, and move the > > working cm3 back. > > > > I'll spend some time this week testing the other ws-packages. > > > > Thanks. > > > > -- hendrik > > From wagner at elegosoft.com Thu Aug 27 08:06:57 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 27 Aug 2009 08:06:57 +0200 Subject: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems In-Reply-To: References: <20090826142644.r6yabwff5wc84cgg@mail.elegosoft.com> Message-ID: <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> Quoting Jay K : > Something or some things very wierd here. I'll keep looking into it. I'm not sure if we should spend/waste(?) more time in trying to make this VM with Windows work. Last night I reactivated my own qemu-based VM and was able to checkout and build some current CM3 stuff. CVS behaves correctly there, and no need to adapt any of the shell scripts at all. It's agonizingly slow though. And it has no remote access. However, building the release archives failed with two errors: vbtkit: new source -> compiling VBTKitResources.m3 "..\src\lego\VBTKitResources.m3", line 10: unable to find interface (VBTKitBundle) 1 error encountered and errors during build-all; some packages will be missing m3-win/import-libs/NT386/.M3SHIP seems to be broken: make_dir("c:/tmp/cm3/lib") install_file("wsock32.lib", "c:/tmp/cm3/lib", "0775") install_file("advapi32.lib", "c:/tmp/cm3/lib", "0775") install_file("opengl32.lib", "c:/tmp/cm3/lib", "0775") install_file("netapi32.lib", "c:/tmp/cm3/lib", "0775") install_file("comctl32.lib", "c:/tmp/cm3/lib", "0775") install_file("user32.lib", "c:/tmp/cm3/lib", "0775") install_file("comdlg32.lib", "c:/tmp/cm3/lib", "0775") install_file("kernel32.lib", "c:/tmp/cm3/lib", "0775") install_file("winspool.lib", "c:/tmp/cm3/lib", "0775") install_file("glu32.lib", "c:/tmp/cm3/lib", "0775") install_file("gdi32.lib", "c:/tmp/cm3/lib", "0775") install_file("odbc32.lib", "c:/tmp/cm3/lib", "0775") (wrong shippind destination, already reported) I suggest we rather concentrate on these and build the Windows packages manually. I'm off to (paid) work again now... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Aug 27 08:09:52 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 27 Aug 2009 06:09:52 +0000 Subject: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems In-Reply-To: <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> References: <20090826142644.r6yabwff5wc84cgg@mail.elegosoft.com> <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> Message-ID: I'm testing a fix for the VM right now actually. Once that works I'll look into the Unresolve problem further. I put in some printing to help diagnose it and possibly a fix. It could be a slash mixup; the printing will tell us. The VBT problem is new seeming. I'll look at that too. Anyone else is welcome to also. - Jay ---------------------------------------- > Date: Thu, 27 Aug 2009 08:06:57 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems > > Quoting Jay K : > >> Something or some things very wierd here. I'll keep looking into it. > I'm not sure if we should spend/waste(?) more time in trying to make > this VM with Windows work. > > Last night I reactivated my own qemu-based VM and was able to checkout > and build some current CM3 stuff. > > CVS behaves correctly there, and no need to adapt any of the shell > scripts at all. It's agonizingly slow though. And it has no remote > access. > > However, building the release archives failed with two errors: > > vbtkit: > new source -> compiling VBTKitResources.m3 > "..\src\lego\VBTKitResources.m3", line 10: unable to find interface > (VBTKitBundle) > 1 error encountered > > and > > errors during build-all; some packages will be missing > m3-win/import-libs/NT386/.M3SHIP seems to be broken: > make_dir("c:/tmp/cm3/lib") > install_file("wsock32.lib", "c:/tmp/cm3/lib", "0775") > install_file("advapi32.lib", "c:/tmp/cm3/lib", "0775") > install_file("opengl32.lib", "c:/tmp/cm3/lib", "0775") > install_file("netapi32.lib", "c:/tmp/cm3/lib", "0775") > install_file("comctl32.lib", "c:/tmp/cm3/lib", "0775") > install_file("user32.lib", "c:/tmp/cm3/lib", "0775") > install_file("comdlg32.lib", "c:/tmp/cm3/lib", "0775") > install_file("kernel32.lib", "c:/tmp/cm3/lib", "0775") > install_file("winspool.lib", "c:/tmp/cm3/lib", "0775") > install_file("glu32.lib", "c:/tmp/cm3/lib", "0775") > install_file("gdi32.lib", "c:/tmp/cm3/lib", "0775") > install_file("odbc32.lib", "c:/tmp/cm3/lib", "0775") > > (wrong shippind destination, already reported) > > I suggest we rather concentrate on these and build the Windows > packages manually. > > I'm off to (paid) work again now... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Thu Aug 27 08:41:46 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 27 Aug 2009 06:41:46 +0000 Subject: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems In-Reply-To: References: <20090826142644.r6yabwff5wc84cgg@mail.elegosoft.com> <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> Message-ID: >> vbtkit: >> new source -> compiling VBTKitResources.m3 >> "..\src\lego\VBTKitResources.m3", line 10: unable to find interface >> (VBTKitBundle) >> 1 error encountered Is m3bundle working for you? In head I have the files: C:\dev2\cm3.2\m3-ui\vbtkit>dir /s/b *kit*bund* C:\dev2\cm3.2\m3-ui\vbtkit\NT386\VBTKitBundle.i3 C:\dev2\cm3.2\m3-ui\vbtkit\NT386\VBTKitBundle.io C:\dev2\cm3.2\m3-ui\vbtkit\NT386\VBTKitBundle.m3 C:\dev2\cm3.2\m3-ui\vbtkit\NT386\VBTKitBundle.mo - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > Date: Thu, 27 Aug 2009 06:09:52 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems > > > I'm testing a fix for the VM right now actually. > Once that works I'll look into the Unresolve problem further. I put in some printing to help diagnose it and possibly a fix. It could be a slash mixup; the printing will tell us. > The VBT problem is new seeming. I'll look at that too. > Anyone else is welcome to also. > > - Jay > > > ---------------------------------------- >> Date: Thu, 27 Aug 2009 08:06:57 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems >> >> Quoting Jay K : >> >>> Something or some things very wierd here. I'll keep looking into it. >> I'm not sure if we should spend/waste(?) more time in trying to make >> this VM with Windows work. >> >> Last night I reactivated my own qemu-based VM and was able to checkout >> and build some current CM3 stuff. >> >> CVS behaves correctly there, and no need to adapt any of the shell >> scripts at all. It's agonizingly slow though. And it has no remote >> access. >> >> However, building the release archives failed with two errors: >> >> vbtkit: >> new source -> compiling VBTKitResources.m3 >> "..\src\lego\VBTKitResources.m3", line 10: unable to find interface >> (VBTKitBundle) >> 1 error encountered >> >> and >> >> errors during build-all; some packages will be missing >> m3-win/import-libs/NT386/.M3SHIP seems to be broken: >> make_dir("c:/tmp/cm3/lib") >> install_file("wsock32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("advapi32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("opengl32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("netapi32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("comctl32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("user32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("comdlg32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("kernel32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("winspool.lib", "c:/tmp/cm3/lib", "0775") >> install_file("glu32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("gdi32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("odbc32.lib", "c:/tmp/cm3/lib", "0775") >> >> (wrong shippind destination, already reported) >> >> I suggest we rather concentrate on these and build the Windows >> packages manually. >> >> I'm off to (paid) work again now... >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> From wagner at elegosoft.com Thu Aug 27 10:02:42 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 27 Aug 2009 10:02:42 +0200 Subject: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems In-Reply-To: References: <20090826142644.r6yabwff5wc84cgg@mail.elegosoft.com> <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> Message-ID: <20090827100242.uyc9fca968s480c4@mail.elegosoft.com> Quoting Jay K : >>> vbtkit: >>> new source -> compiling VBTKitResources.m3 >>> "..\src\lego\VBTKitResources.m3", line 10: unable to find interface >>> (VBTKitBundle) >>> 1 error encountered > > Is m3bundle working for you? > In head I have the files: > > C:\dev2\cm3.2\m3-ui\vbtkit>dir /s/b *kit*bund* > C:\dev2\cm3.2\m3-ui\vbtkit\NT386\VBTKitBundle.i3 > C:\dev2\cm3.2\m3-ui\vbtkit\NT386\VBTKitBundle.io > C:\dev2\cm3.2\m3-ui\vbtkit\NT386\VBTKitBundle.m3 > C:\dev2\cm3.2\m3-ui\vbtkit\NT386\VBTKitBundle.mo Sorry, I cannot check from here. I only remember that the missing interfaces seemed to be the first problem. Maybe I've overseeen failing m3bundle calls though. Strange. Olaf > - Jay > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com >> Date: Thu, 27 Aug 2009 06:09:52 +0000 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] RC3 build problems, was: RE: caltech-parser >> NT386 Hudson problems >> >> >> I'm testing a fix for the VM right now actually. >> Once that works I'll look into the Unresolve problem further. I put >> in some printing to help diagnose it and possibly a fix. It could >> be a slash mixup; the printing will tell us. >> The VBT problem is new seeming. I'll look at that too. >> Anyone else is welcome to also. >> >> - Jay >> >> >> ---------------------------------------- >>> Date: Thu, 27 Aug 2009 08:06:57 +0200 >>> From: wagner at elegosoft.com >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com >>> Subject: [M3devel] RC3 build problems, was: RE: caltech-parser >>> NT386 Hudson problems >>> >>> Quoting Jay K : >>> >>>> Something or some things very wierd here. I'll keep looking into it. >>> I'm not sure if we should spend/waste(?) more time in trying to make >>> this VM with Windows work. >>> >>> Last night I reactivated my own qemu-based VM and was able to checkout >>> and build some current CM3 stuff. >>> >>> CVS behaves correctly there, and no need to adapt any of the shell >>> scripts at all. It's agonizingly slow though. And it has no remote >>> access. >>> >>> However, building the release archives failed with two errors: >>> >>> vbtkit: >>> new source -> compiling VBTKitResources.m3 >>> "..\src\lego\VBTKitResources.m3", line 10: unable to find interface >>> (VBTKitBundle) >>> 1 error encountered >>> >>> and >>> >>> errors during build-all; some packages will be missing >>> m3-win/import-libs/NT386/.M3SHIP seems to be broken: >>> make_dir("c:/tmp/cm3/lib") >>> install_file("wsock32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("advapi32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("opengl32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("netapi32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("comctl32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("user32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("comdlg32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("kernel32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("winspool.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("glu32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("gdi32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("odbc32.lib", "c:/tmp/cm3/lib", "0775") >>> >>> (wrong shippind destination, already reported) >>> >>> I suggest we rather concentrate on these and build the Windows >>> packages manually. >>> >>> I'm off to (paid) work again now... >>> >>> Olaf >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Aug 27 14:14:02 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 27 Aug 2009 12:14:02 +0000 Subject: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems In-Reply-To: <20090827100242.uyc9fca968s480c4@mail.elegosoft.com> References: <20090826142644.r6yabwff5wc84cgg@mail.elegosoft.com> <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> <20090827100242.uyc9fca968s480c4@mail.elegosoft.com> Message-ID: Maybe your initial install lacked it? - Jay ---------------------------------------- > Date: Thu, 27 Aug 2009 10:02:42 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems > > Quoting Jay K : > >>>> vbtkit: >>>> new source -> compiling VBTKitResources.m3 >>>> "..\src\lego\VBTKitResources.m3", line 10: unable to find interface >>>> (VBTKitBundle) >>>> 1 error encountered >> >> Is m3bundle working for you? >> In head I have the files: >> >> C:\dev2\cm3.2\m3-ui\vbtkit>dir /s/b *kit*bund* >> C:\dev2\cm3.2\m3-ui\vbtkit\NT386\VBTKitBundle.i3 >> C:\dev2\cm3.2\m3-ui\vbtkit\NT386\VBTKitBundle.io >> C:\dev2\cm3.2\m3-ui\vbtkit\NT386\VBTKitBundle.m3 >> C:\dev2\cm3.2\m3-ui\vbtkit\NT386\VBTKitBundle.mo > > Sorry, I cannot check from here. I only remember that the > missing interfaces seemed to be the first problem. Maybe I've > overseeen failing m3bundle calls though. Strange. > > Olaf > >> - Jay >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: wagner at elegosoft.com >>> Date: Thu, 27 Aug 2009 06:09:52 +0000 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] RC3 build problems, was: RE: caltech-parser >>> NT386 Hudson problems >>> >>> >>> I'm testing a fix for the VM right now actually. >>> Once that works I'll look into the Unresolve problem further. I put >>> in some printing to help diagnose it and possibly a fix. It could >>> be a slash mixup; the printing will tell us. >>> The VBT problem is new seeming. I'll look at that too. >>> Anyone else is welcome to also. >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> Date: Thu, 27 Aug 2009 08:06:57 +0200 >>>> From: wagner at elegosoft.com >>>> To: jay.krell at cornell.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: [M3devel] RC3 build problems, was: RE: caltech-parser >>>> NT386 Hudson problems >>>> >>>> Quoting Jay K : >>>> >>>>> Something or some things very wierd here. I'll keep looking into it. >>>> I'm not sure if we should spend/waste(?) more time in trying to make >>>> this VM with Windows work. >>>> >>>> Last night I reactivated my own qemu-based VM and was able to checkout >>>> and build some current CM3 stuff. >>>> >>>> CVS behaves correctly there, and no need to adapt any of the shell >>>> scripts at all. It's agonizingly slow though. And it has no remote >>>> access. >>>> >>>> However, building the release archives failed with two errors: >>>> >>>> vbtkit: >>>> new source -> compiling VBTKitResources.m3 >>>> "..\src\lego\VBTKitResources.m3", line 10: unable to find interface >>>> (VBTKitBundle) >>>> 1 error encountered >>>> >>>> and >>>> >>>> errors during build-all; some packages will be missing >>>> m3-win/import-libs/NT386/.M3SHIP seems to be broken: >>>> make_dir("c:/tmp/cm3/lib") >>>> install_file("wsock32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("advapi32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("opengl32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("netapi32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("comctl32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("user32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("comdlg32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("kernel32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("winspool.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("glu32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("gdi32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("odbc32.lib", "c:/tmp/cm3/lib", "0775") >>>> >>>> (wrong shippind destination, already reported) >>>> >>>> I suggest we rather concentrate on these and build the Windows >>>> packages manually. >>>> >>>> I'm off to (paid) work again now... >>>> >>>> Olaf >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>> DE163214194 >>>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Thu Aug 27 14:15:14 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 27 Aug 2009 12:15:14 +0000 Subject: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems In-Reply-To: <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> References: <20090826142644.r6yabwff5wc84cgg@mail.elegosoft.com> <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> Message-ID: My current theory is the unresolve problem is due to that wierd initial build of import-libs in the Hudson task, which was related to the line endings problem, which was related to using CVSNT instead of Cygwin cvs. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems > Date: Thu, 27 Aug 2009 06:09:52 +0000 > > > I'm testing a fix for the VM right now actually. > Once that works I'll look into the Unresolve problem further. I put in some printing to help diagnose it and possibly a fix. It could be a slash mixup; the printing will tell us. > The VBT problem is new seeming. I'll look at that too. > Anyone else is welcome to also. > > - Jay > > > ---------------------------------------- >> Date: Thu, 27 Aug 2009 08:06:57 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems >> >> Quoting Jay K : >> >>> Something or some things very wierd here. I'll keep looking into it. >> I'm not sure if we should spend/waste(?) more time in trying to make >> this VM with Windows work. >> >> Last night I reactivated my own qemu-based VM and was able to checkout >> and build some current CM3 stuff. >> >> CVS behaves correctly there, and no need to adapt any of the shell >> scripts at all. It's agonizingly slow though. And it has no remote >> access. >> >> However, building the release archives failed with two errors: >> >> vbtkit: >> new source -> compiling VBTKitResources.m3 >> "..\src\lego\VBTKitResources.m3", line 10: unable to find interface >> (VBTKitBundle) >> 1 error encountered >> >> and >> >> errors during build-all; some packages will be missing >> m3-win/import-libs/NT386/.M3SHIP seems to be broken: >> make_dir("c:/tmp/cm3/lib") >> install_file("wsock32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("advapi32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("opengl32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("netapi32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("comctl32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("user32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("comdlg32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("kernel32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("winspool.lib", "c:/tmp/cm3/lib", "0775") >> install_file("glu32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("gdi32.lib", "c:/tmp/cm3/lib", "0775") >> install_file("odbc32.lib", "c:/tmp/cm3/lib", "0775") >> >> (wrong shippind destination, already reported) >> >> I suggest we rather concentrate on these and build the Windows >> packages manually. >> >> I'm off to (paid) work again now... >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> From wagner at elegosoft.com Thu Aug 27 14:17:41 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 27 Aug 2009 14:17:41 +0200 Subject: [M3devel] small design problem in ButtonVBT? In-Reply-To: <20090826002606.GB16386@topoi.pooq.com> References: <20090331145127.GB9624@topoi.pooq.com> <20090401120347.x8cneize8oscg44o@mail.elegosoft.com> <20090826002606.GB16386@topoi.pooq.com> Message-ID: <20090827141741.9g1u2vrgfgokkksg@mail.elegosoft.com> Though I promised to do it, I have lost sight of this task while trying to build some RC3 archives on Windows. As I'm not at home this evening, can somebody else please commit Hendrik's extension? Is this something we should should have in the release branch, too? Probably not necessary? Olaf Quoting hendrik at topoi.pooq.com: > On Wed, Apr 01, 2009 at 12:03:47PM +0200, Olaf Wagner wrote: >> Quoting hendrik at topoi.pooq.com: >> >> >The BottonVBT contains an action, which is a procedure rather than a >> >method. b This makes it awkward to subclass ButtonVBT becaue the action >> >will still expect its first parameter to be a ButtonVBT instead of >> >belonging to the subclass, and an explicit downcast of some sort will be >> >needed to acess the subclass's members. >> > >> >The Trestle manual says this was a deliberate decision: >> > >> >: The action procedure is a field rather than a method in order to allow >> >: buttons with different action procedures to share their method suites. >> > >> >I, however, find it massively inconvenient because it mans I have to >> >resort to downcasting or the very kludgey VBT.GetProp to access what >> >should be just there. I'd rather the action procedure was a method. >> > >> >But it should be possible to have the best of both worlds. Have an >> >action2 (better name wanted here) method that is available for >> >overriding, and by default calls the procedure in the existing action. >> >field. That action2 method wounl then be called by Trestle wherever >> >action is now called. >> > >> >Does anyone see problems with this? >> >> Sounds fine to me offhand. You should test your extensions with >> some of the existing larger applications, like mentor and Juno-2, >> of course. > > OK. Here's the patch. Would it be possible for someone to check it in > for me? > > mentor runs fine with this change; I watched it animate a heap-sort. > > I have no idea what Juno is supposed to do, but it did respond to > button-pushes. > > > hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ cvs diff > cvs diff: Diffing . > Index: ButtonVBT.i3 > =================================================================== > RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.i3,v > retrieving revision 1.2 > diff -r1.2 ButtonVBT.i3 > 39a40 >> act(READONLY cd: VBT.MouseRec); > Index: ButtonVBT.m3 > =================================================================== > RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.m3,v > retrieving revision 1.2 > diff -r1.2 ButtonVBT.m3 > 28c28,29 > < init := Be > --- >> init := Be; >> act := act > 46a48,52 >> PROCEDURE act(v : T; READONLY cd: VBT.MouseRec) = >> BEGIN >> v.action(v, cd); >> END act; >> > 59c65 > < v.action(v, cd); > --- >> v.act(cd); > hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ > > -- hendrik > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Thu Aug 27 14:22:01 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 27 Aug 2009 14:22:01 +0200 Subject: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems In-Reply-To: References: <20090826142644.r6yabwff5wc84cgg@mail.elegosoft.com> <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> Message-ID: <20090827142201.qim3orxd4488ssss@mail.elegosoft.com> Quoting Jay K : > My current theory is the unresolve problem is due to that wierd > initial build of import-libs in the Hudson task, which was related > to the line endings problem, which was related to using CVSNT > instead of Cygwin cvs. Hm, I don't think so, as is happend in my Home-VM, too. And there's everything with proper NL endings. As for m3bundle, that should have been built by do-cm3-core.sh long before the build of vbtkit fails. But I cannot really check until tomorrow evening. Olaf > - Jay > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] RC3 build problems, was: RE: caltech-parser >> NT386 Hudson problems >> Date: Thu, 27 Aug 2009 06:09:52 +0000 >> >> >> I'm testing a fix for the VM right now actually. >> Once that works I'll look into the Unresolve problem further. I put >> in some printing to help diagnose it and possibly a fix. It could >> be a slash mixup; the printing will tell us. >> The VBT problem is new seeming. I'll look at that too. >> Anyone else is welcome to also. >> >> - Jay >> >> >> ---------------------------------------- >>> Date: Thu, 27 Aug 2009 08:06:57 +0200 >>> From: wagner at elegosoft.com >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com >>> Subject: [M3devel] RC3 build problems, was: RE: caltech-parser >>> NT386 Hudson problems >>> >>> Quoting Jay K : >>> >>>> Something or some things very wierd here. I'll keep looking into it. >>> I'm not sure if we should spend/waste(?) more time in trying to make >>> this VM with Windows work. >>> >>> Last night I reactivated my own qemu-based VM and was able to checkout >>> and build some current CM3 stuff. >>> >>> CVS behaves correctly there, and no need to adapt any of the shell >>> scripts at all. It's agonizingly slow though. And it has no remote >>> access. >>> >>> However, building the release archives failed with two errors: >>> >>> vbtkit: >>> new source -> compiling VBTKitResources.m3 >>> "..\src\lego\VBTKitResources.m3", line 10: unable to find interface >>> (VBTKitBundle) >>> 1 error encountered >>> >>> and >>> >>> errors during build-all; some packages will be missing >>> m3-win/import-libs/NT386/.M3SHIP seems to be broken: >>> make_dir("c:/tmp/cm3/lib") >>> install_file("wsock32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("advapi32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("opengl32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("netapi32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("comctl32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("user32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("comdlg32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("kernel32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("winspool.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("glu32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("gdi32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("odbc32.lib", "c:/tmp/cm3/lib", "0775") >>> >>> (wrong shippind destination, already reported) >>> >>> I suggest we rather concentrate on these and build the Windows >>> packages manually. >>> >>> I'm off to (paid) work again now... -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Aug 27 14:28:49 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 27 Aug 2009 12:28:49 +0000 Subject: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems In-Reply-To: <20090827142201.qim3orxd4488ssss@mail.elegosoft.com> References: <20090826142644.r6yabwff5wc84cgg@mail.elegosoft.com> <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> <20090827142201.qim3orxd4488ssss@mail.elegosoft.com> Message-ID: The debugprint doesn't show up. http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/cm3/src/M3Build.m3?r1=1.28.2.4&r2=1.28.2.5 could be tools aren't updated yet. But that is also explained by my theory. Are you sure? I've put in realclean for this package in the Hudson task. I'll do another release and lastok build. We'll see. - Jay ---------------------------------------- > Date: Thu, 27 Aug 2009 14:22:01 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems > > Quoting Jay K : > >> My current theory is the unresolve problem is due to that wierd >> initial build of import-libs in the Hudson task, which was related >> to the line endings problem, which was related to using CVSNT >> instead of Cygwin cvs. > > Hm, I don't think so, as is happend in my Home-VM, too. > And there's everything with proper NL endings. > > As for m3bundle, that should have been built by do-cm3-core.sh > long before the build of vbtkit fails. > > But I cannot really check until tomorrow evening. > > Olaf > >> - Jay >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: wagner at elegosoft.com >>> CC: m3devel at elegosoft.com >>> Subject: RE: [M3devel] RC3 build problems, was: RE: caltech-parser >>> NT386 Hudson problems >>> Date: Thu, 27 Aug 2009 06:09:52 +0000 >>> >>> >>> I'm testing a fix for the VM right now actually. >>> Once that works I'll look into the Unresolve problem further. I put >>> in some printing to help diagnose it and possibly a fix. It could >>> be a slash mixup; the printing will tell us. >>> The VBT problem is new seeming. I'll look at that too. >>> Anyone else is welcome to also. >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> Date: Thu, 27 Aug 2009 08:06:57 +0200 >>>> From: wagner at elegosoft.com >>>> To: jay.krell at cornell.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: [M3devel] RC3 build problems, was: RE: caltech-parser >>>> NT386 Hudson problems >>>> >>>> Quoting Jay K : >>>> >>>>> Something or some things very wierd here. I'll keep looking into it. >>>> I'm not sure if we should spend/waste(?) more time in trying to make >>>> this VM with Windows work. >>>> >>>> Last night I reactivated my own qemu-based VM and was able to checkout >>>> and build some current CM3 stuff. >>>> >>>> CVS behaves correctly there, and no need to adapt any of the shell >>>> scripts at all. It's agonizingly slow though. And it has no remote >>>> access. >>>> >>>> However, building the release archives failed with two errors: >>>> >>>> vbtkit: >>>> new source -> compiling VBTKitResources.m3 >>>> "..\src\lego\VBTKitResources.m3", line 10: unable to find interface >>>> (VBTKitBundle) >>>> 1 error encountered >>>> >>>> and >>>> >>>> errors during build-all; some packages will be missing >>>> m3-win/import-libs/NT386/.M3SHIP seems to be broken: >>>> make_dir("c:/tmp/cm3/lib") >>>> install_file("wsock32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("advapi32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("opengl32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("netapi32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("comctl32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("user32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("comdlg32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("kernel32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("winspool.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("glu32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("gdi32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("odbc32.lib", "c:/tmp/cm3/lib", "0775") >>>> >>>> (wrong shippind destination, already reported) >>>> >>>> I suggest we rather concentrate on these and build the Windows >>>> packages manually. >>>> >>>> I'm off to (paid) work again now... > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Thu Aug 27 14:37:21 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 27 Aug 2009 12:37:21 +0000 Subject: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems In-Reply-To: <20090827142201.qim3orxd4488ssss@mail.elegosoft.com> References: <20090826142644.r6yabwff5wc84cgg@mail.elegosoft.com> <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> <20090827142201.qim3orxd4488ssss@mail.elegosoft.com> Message-ID: ps: It doesn't take CVSNT to cause this, but the workaround of building import-libs up front w/o noresolve. I assume you were missing m3bundle, as consistently build ok here in the birch VM and on my machine. - Jay ---------------------------------------- > Date: Thu, 27 Aug 2009 14:22:01 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems > > Quoting Jay K : > >> My current theory is the unresolve problem is due to that wierd >> initial build of import-libs in the Hudson task, which was related >> to the line endings problem, which was related to using CVSNT >> instead of Cygwin cvs. > > Hm, I don't think so, as is happend in my Home-VM, too. > And there's everything with proper NL endings. > > As for m3bundle, that should have been built by do-cm3-core.sh > long before the build of vbtkit fails. > > But I cannot really check until tomorrow evening. > > Olaf > >> - Jay >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: wagner at elegosoft.com >>> CC: m3devel at elegosoft.com >>> Subject: RE: [M3devel] RC3 build problems, was: RE: caltech-parser >>> NT386 Hudson problems >>> Date: Thu, 27 Aug 2009 06:09:52 +0000 >>> >>> >>> I'm testing a fix for the VM right now actually. >>> Once that works I'll look into the Unresolve problem further. I put >>> in some printing to help diagnose it and possibly a fix. It could >>> be a slash mixup; the printing will tell us. >>> The VBT problem is new seeming. I'll look at that too. >>> Anyone else is welcome to also. >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> Date: Thu, 27 Aug 2009 08:06:57 +0200 >>>> From: wagner at elegosoft.com >>>> To: jay.krell at cornell.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: [M3devel] RC3 build problems, was: RE: caltech-parser >>>> NT386 Hudson problems >>>> >>>> Quoting Jay K : >>>> >>>>> Something or some things very wierd here. I'll keep looking into it. >>>> I'm not sure if we should spend/waste(?) more time in trying to make >>>> this VM with Windows work. >>>> >>>> Last night I reactivated my own qemu-based VM and was able to checkout >>>> and build some current CM3 stuff. >>>> >>>> CVS behaves correctly there, and no need to adapt any of the shell >>>> scripts at all. It's agonizingly slow though. And it has no remote >>>> access. >>>> >>>> However, building the release archives failed with two errors: >>>> >>>> vbtkit: >>>> new source -> compiling VBTKitResources.m3 >>>> "..\src\lego\VBTKitResources.m3", line 10: unable to find interface >>>> (VBTKitBundle) >>>> 1 error encountered >>>> >>>> and >>>> >>>> errors during build-all; some packages will be missing >>>> m3-win/import-libs/NT386/.M3SHIP seems to be broken: >>>> make_dir("c:/tmp/cm3/lib") >>>> install_file("wsock32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("advapi32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("opengl32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("netapi32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("comctl32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("user32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("comdlg32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("kernel32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("winspool.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("glu32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("gdi32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("odbc32.lib", "c:/tmp/cm3/lib", "0775") >>>> >>>> (wrong shippind destination, already reported) >>>> >>>> I suggest we rather concentrate on these and build the Windows >>>> packages manually. >>>> >>>> I'm off to (paid) work again now... > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From wagner at elegosoft.com Thu Aug 27 15:50:56 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 27 Aug 2009 15:50:56 +0200 Subject: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems In-Reply-To: References: <20090826142644.r6yabwff5wc84cgg@mail.elegosoft.com> <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> <20090827142201.qim3orxd4488ssss@mail.elegosoft.com> Message-ID: <20090827155056.7tsrrlb0qo8c0sc4@mail.elegosoft.com> Quoting Jay K : > > ps: It doesn't take CVSNT to cause this, but the workaround of > building import-libs up front w/o noresolve. > I assume you were missing m3bundle, as consistently build ok here in > the birch VM and on my machine. Ah, so we should probably use the unresolve switch for all packages in upgrade, too? Olaf > - Jay > > > ---------------------------------------- >> Date: Thu, 27 Aug 2009 14:22:01 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] RC3 build problems, was: RE: caltech-parser >> NT386 Hudson problems >> >> Quoting Jay K : >> >>> My current theory is the unresolve problem is due to that wierd >>> initial build of import-libs in the Hudson task, which was related >>> to the line endings problem, which was related to using CVSNT >>> instead of Cygwin cvs. >> >> Hm, I don't think so, as is happend in my Home-VM, too. >> And there's everything with proper NL endings. >> >> As for m3bundle, that should have been built by do-cm3-core.sh >> long before the build of vbtkit fails. >> >> But I cannot really check until tomorrow evening. >> >> Olaf >> >>> - Jay >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: wagner at elegosoft.com >>>> CC: m3devel at elegosoft.com >>>> Subject: RE: [M3devel] RC3 build problems, was: RE: caltech-parser >>>> NT386 Hudson problems >>>> Date: Thu, 27 Aug 2009 06:09:52 +0000 >>>> >>>> >>>> I'm testing a fix for the VM right now actually. >>>> Once that works I'll look into the Unresolve problem further. I put >>>> in some printing to help diagnose it and possibly a fix. It could >>>> be a slash mixup; the printing will tell us. >>>> The VBT problem is new seeming. I'll look at that too. >>>> Anyone else is welcome to also. >>>> >>>> - Jay >>>> >>>> >>>> ---------------------------------------- >>>>> Date: Thu, 27 Aug 2009 08:06:57 +0200 >>>>> From: wagner at elegosoft.com >>>>> To: jay.krell at cornell.edu >>>>> CC: m3devel at elegosoft.com >>>>> Subject: [M3devel] RC3 build problems, was: RE: caltech-parser >>>>> NT386 Hudson problems >>>>> >>>>> Quoting Jay K : >>>>> >>>>>> Something or some things very wierd here. I'll keep looking into it. >>>>> I'm not sure if we should spend/waste(?) more time in trying to make >>>>> this VM with Windows work. >>>>> >>>>> Last night I reactivated my own qemu-based VM and was able to checkout >>>>> and build some current CM3 stuff. >>>>> >>>>> CVS behaves correctly there, and no need to adapt any of the shell >>>>> scripts at all. It's agonizingly slow though. And it has no remote >>>>> access. >>>>> >>>>> However, building the release archives failed with two errors: >>>>> >>>>> vbtkit: >>>>> new source -> compiling VBTKitResources.m3 >>>>> "..\src\lego\VBTKitResources.m3", line 10: unable to find interface >>>>> (VBTKitBundle) >>>>> 1 error encountered >>>>> >>>>> and >>>>> >>>>> errors during build-all; some packages will be missing >>>>> m3-win/import-libs/NT386/.M3SHIP seems to be broken: >>>>> make_dir("c:/tmp/cm3/lib") >>>>> install_file("wsock32.lib", "c:/tmp/cm3/lib", "0775") >>>>> install_file("advapi32.lib", "c:/tmp/cm3/lib", "0775") >>>>> install_file("opengl32.lib", "c:/tmp/cm3/lib", "0775") >>>>> install_file("netapi32.lib", "c:/tmp/cm3/lib", "0775") >>>>> install_file("comctl32.lib", "c:/tmp/cm3/lib", "0775") >>>>> install_file("user32.lib", "c:/tmp/cm3/lib", "0775") >>>>> install_file("comdlg32.lib", "c:/tmp/cm3/lib", "0775") >>>>> install_file("kernel32.lib", "c:/tmp/cm3/lib", "0775") >>>>> install_file("winspool.lib", "c:/tmp/cm3/lib", "0775") >>>>> install_file("glu32.lib", "c:/tmp/cm3/lib", "0775") >>>>> install_file("gdi32.lib", "c:/tmp/cm3/lib", "0775") >>>>> install_file("odbc32.lib", "c:/tmp/cm3/lib", "0775") >>>>> >>>>> (wrong shippind destination, already reported) >>>>> >>>>> I suggest we rather concentrate on these and build the Windows >>>>> packages manually. >>>>> >>>>> I'm off to (paid) work again now... >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Thu Aug 27 16:17:43 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 27 Aug 2009 16:17:43 +0200 Subject: [M3devel] m3gdb build error in RC3 Message-ID: <20090827161743.mkz8qhp7lco88og8@mail.elegosoft.com> I just found this in Hudson for AMD64_LINUX: http://hudson.modula3.com:8080/view/AMD64_LINUX/job/cm3-test-all-pkgs-AMD64_LINUX/lastBuild/testReport/(root)/CM3%20package%20build%20status/m3_sys_m3gdb/ I've created ticket #1067 for it. Perhaps a wrong/incomplete merge of changes from the main trunk? (I may be the culprit myself, though I'm sure I remember to have compiled m3gdb after merging some changes some days ago.) @Rodney, did you get the account information for trac I sent you? I took the liberty to assign the new ticket to you, too :-) #1058 is not closed yet, too, though you had fixed that. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Thu Aug 27 16:20:11 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 27 Aug 2009 10:20:11 -0400 Subject: [M3devel] small design problem in ButtonVBT? In-Reply-To: <20090827141741.9g1u2vrgfgokkksg@mail.elegosoft.com> References: <20090331145127.GB9624@topoi.pooq.com> <20090401120347.x8cneize8oscg44o@mail.elegosoft.com> <20090826002606.GB16386@topoi.pooq.com> <20090827141741.9g1u2vrgfgokkksg@mail.elegosoft.com> Message-ID: <88690174-5B88-442C-816C-4CACBCB2CDEF@cs.purdue.edu> I'll do it. On 27 Aug 2009, at 08:17, Olaf Wagner wrote: > Though I promised to do it, I have lost sight of this task while > trying to build some RC3 archives on Windows. As I'm not at home this > evening, can somebody else please commit Hendrik's extension? > > Is this something we should should have in the release branch, too? > Probably not necessary? > > Olaf > > Quoting hendrik at topoi.pooq.com: > >> On Wed, Apr 01, 2009 at 12:03:47PM +0200, Olaf Wagner wrote: >>> Quoting hendrik at topoi.pooq.com: >>> >>> >The BottonVBT contains an action, which is a procedure rather >>> than a >>> >method. b This makes it awkward to subclass ButtonVBT becaue the >>> action >>> >will still expect its first parameter to be a ButtonVBT instead of >>> >belonging to the subclass, and an explicit downcast of some sort >>> will be >>> >needed to acess the subclass's members. >>> > >>> >The Trestle manual says this was a deliberate decision: >>> > >>> >: The action procedure is a field rather than a method in order >>> to allow >>> >: buttons with different action procedures to share their method >>> suites. >>> > >>> >I, however, find it massively inconvenient because it mans I have >>> to >>> >resort to downcasting or the very kludgey VBT.GetProp to access >>> what >>> >should be just there. I'd rather the action procedure was a >>> method. >>> > >>> >But it should be possible to have the best of both worlds. Have an >>> >action2 (better name wanted here) method that is available for >>> >overriding, and by default calls the procedure in the existing >>> action. >>> >field. That action2 method wounl then be called by Trestle >>> wherever >>> >action is now called. >>> > >>> >Does anyone see problems with this? >>> >>> Sounds fine to me offhand. You should test your extensions with >>> some of the existing larger applications, like mentor and Juno-2, >>> of course. >> >> OK. Here's the patch. Would it be possible for someone to check it >> in >> for me? >> >> mentor runs fine with this change; I watched it animate a heap-sort. >> >> I have no idea what Juno is supposed to do, but it did respond to >> button-pushes. >> >> >> hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ cvs diff >> cvs diff: Diffing . >> Index: ButtonVBT.i3 >> =================================================================== >> RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.i3,v >> retrieving revision 1.2 >> diff -r1.2 ButtonVBT.i3 >> 39a40 >>> act(READONLY cd: VBT.MouseRec); >> Index: ButtonVBT.m3 >> =================================================================== >> RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.m3,v >> retrieving revision 1.2 >> diff -r1.2 ButtonVBT.m3 >> 28c28,29 >> < init := Be >> --- >>> init := Be; >>> act := act >> 46a48,52 >>> PROCEDURE act(v : T; READONLY cd: VBT.MouseRec) = >>> BEGIN >>> v.action(v, cd); >>> END act; >>> >> 59c65 >> < v.action(v, cd); >> --- >>> v.act(cd); >> hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ >> >> -- hendrik >> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Aug 27 21:15:41 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 27 Aug 2009 15:15:41 -0400 Subject: [M3devel] small design problem in ButtonVBT? In-Reply-To: <20090827141741.9g1u2vrgfgokkksg@mail.elegosoft.com> References: <20090331145127.GB9624@topoi.pooq.com> <20090401120347.x8cneize8oscg44o@mail.elegosoft.com> <20090826002606.GB16386@topoi.pooq.com> <20090827141741.9g1u2vrgfgokkksg@mail.elegosoft.com> Message-ID: I am nervous about having the two alternative entries to the action procedure that other code might not be aware of. Yes, you've modified the default mouse method to call the action method instead of the procedure, but what about other places where the mouse method has been overridden. If you want to be smart about it in your own code you can simply invert your suggestion and do the following: TYPE T = ButtonVBT.T OBJECT METHODS action(cd: VBT.MouseRec) := Action; PROCEDURE Action(v: T; cd: VBT.MouseRec) = ... PROCEDURE ActionProc(v: ButtonVBT.T; cd: VBT.MouseRec) = BEGIN NARROW(v, T).action(cd); END ActionProc; and initialize your T thingy with ButtonVBT.New(..., action := ActionProc; ...) Then in your code you can go ahead and override the action method to your hearts content. Am I just being paranoid? On 27 Aug 2009, at 08:17, Olaf Wagner wrote: > Though I promised to do it, I have lost sight of this task while > trying to build some RC3 archives on Windows. As I'm not at home this > evening, can somebody else please commit Hendrik's extension? > > Is this something we should should have in the release branch, too? > Probably not necessary? > > Olaf > > Quoting hendrik at topoi.pooq.com: > >> On Wed, Apr 01, 2009 at 12:03:47PM +0200, Olaf Wagner wrote: >>> Quoting hendrik at topoi.pooq.com: >>> >>> >The BottonVBT contains an action, which is a procedure rather >>> than a >>> >method. b This makes it awkward to subclass ButtonVBT becaue the >>> action >>> >will still expect its first parameter to be a ButtonVBT instead of >>> >belonging to the subclass, and an explicit downcast of some sort >>> will be >>> >needed to acess the subclass's members. >>> > >>> >The Trestle manual says this was a deliberate decision: >>> > >>> >: The action procedure is a field rather than a method in order >>> to allow >>> >: buttons with different action procedures to share their method >>> suites. >>> > >>> >I, however, find it massively inconvenient because it mans I have >>> to >>> >resort to downcasting or the very kludgey VBT.GetProp to access >>> what >>> >should be just there. I'd rather the action procedure was a >>> method. >>> > >>> >But it should be possible to have the best of both worlds. Have an >>> >action2 (better name wanted here) method that is available for >>> >overriding, and by default calls the procedure in the existing >>> action. >>> >field. That action2 method wounl then be called by Trestle >>> wherever >>> >action is now called. >>> > >>> >Does anyone see problems with this? >>> >>> Sounds fine to me offhand. You should test your extensions with >>> some of the existing larger applications, like mentor and Juno-2, >>> of course. >> >> OK. Here's the patch. Would it be possible for someone to check it >> in >> for me? >> >> mentor runs fine with this change; I watched it animate a heap-sort. >> >> I have no idea what Juno is supposed to do, but it did respond to >> button-pushes. >> >> >> hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ cvs diff >> cvs diff: Diffing . >> Index: ButtonVBT.i3 >> =================================================================== >> RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.i3,v >> retrieving revision 1.2 >> diff -r1.2 ButtonVBT.i3 >> 39a40 >>> act(READONLY cd: VBT.MouseRec); >> Index: ButtonVBT.m3 >> =================================================================== >> RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.m3,v >> retrieving revision 1.2 >> diff -r1.2 ButtonVBT.m3 >> 28c28,29 >> < init := Be >> --- >>> init := Be; >>> act := act >> 46a48,52 >>> PROCEDURE act(v : T; READONLY cd: VBT.MouseRec) = >>> BEGIN >>> v.action(v, cd); >>> END act; >>> >> 59c65 >> < v.action(v, cd); >> --- >>> v.act(cd); >> hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ >> >> -- hendrik >> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From rodney.m.bates at cox.net Thu Aug 27 23:37:12 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Thu, 27 Aug 2009 16:37:12 -0500 Subject: [M3devel] m3gdb build error in RC3 In-Reply-To: <20090827161743.mkz8qhp7lco88og8@mail.elegosoft.com> References: <20090827161743.mkz8qhp7lco88og8@mail.elegosoft.com> Message-ID: <4A96FC88.3030006@cox.net> Olaf Wagner wrote: > I just found this in Hudson for AMD64_LINUX: > > http://hudson.modula3.com:8080/view/AMD64_LINUX/job/cm3-test-all-pkgs-AMD64_LINUX/lastBuild/testReport/(root)/CM3%20package%20build%20status/m3_sys_m3gdb/ > > > I've created ticket #1067 for it. > > Perhaps a wrong/incomplete merge of changes from the main trunk? > (I may be the culprit myself, though I'm sure I remember to have compiled > m3gdb after merging some changes some days ago.) > > @Rodney, did you get the account information for trac I sent you? > I took the liberty to assign the new ticket to you, too :-) > #1058 is not closed yet, too, though you had fixed that. I got the account info and figured out how to close it. My own responsivness is bit erratic these days, as I am often away from internet access for 4 or 5 days at a time. > > Olaf From jay.krell at cornell.edu Fri Aug 28 03:30:47 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 28 Aug 2009 01:30:47 +0000 Subject: [M3devel] m3gdb build error in RC3 In-Reply-To: <4A96FC88.3030006@cox.net> References: <20090827161743.mkz8qhp7lco88og8@mail.elegosoft.com> <4A96FC88.3030006@cox.net> Message-ID: I'll fix this shortly. We can't use stdbool.h. It #errors on Solaris. And we can't use bool either. It conflicts on Linux. I'll change to m3bool, m3true, m3false. - Jay ---------------------------------------- > Date: Thu, 27 Aug 2009 16:37:12 -0500 > From: rodney.m.bates at cox.net > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] m3gdb build error in RC3 > > Olaf Wagner wrote: >> I just found this in Hudson for AMD64_LINUX: >> >> http://hudson.modula3.com:8080/view/AMD64_LINUX/job/cm3-test-all-pkgs-AMD64_LINUX/lastBuild/testReport/(root)/CM3%20package%20build%20status/m3_sys_m3gdb/ >> >> >> I've created ticket #1067 for it. >> >> Perhaps a wrong/incomplete merge of changes from the main trunk? >> (I may be the culprit myself, though I'm sure I remember to have compiled >> m3gdb after merging some changes some days ago.) >> >> @Rodney, did you get the account information for trac I sent you? >> I took the liberty to assign the new ticket to you, too :-) >> #1058 is not closed yet, too, though you had fixed that. > I got the account info and figured out how to close it. My own > responsivness > is bit erratic these days, as I am often away from internet access > for 4 or 5 days at a time. >> >> Olaf > From jay.krell at cornell.edu Fri Aug 28 04:53:47 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 28 Aug 2009 02:53:47 +0000 Subject: [M3devel] CM3 on windows In-Reply-To: <20090828020144.B5E7C1A209A@async.async.caltech.edu> References: <20090828020144.B5E7C1A209A@async.async.caltech.edu> Message-ID: I fixed the access on 5.8.2. Try that? I can poke around.. As I recall 5.8.1 used VC 8.0 and 5.8.2 used 9.0. If that helps. - Jay ---------------------------------------- > To: m3devel at elegosoft.com; jay.krell at cornell.edu > CC: mika at async.caltech.edu > Subject: CM3 on windows > Date: Thu, 27 Aug 2009 19:01:44 -0700 > From: mika at async.async.caltech.edu > > Hi m3devel, > > Not sure if my earlier message today went anywhere. I never saw it on > the list. > > I'd like to try running CM3 on Windows 2000, so I've downloaded > > http://www.opencm3.com/uploaded-archives/cm3-std-NT386-d5.8.1.msi > > (5.8.2 didn't work---no access). > > Having installed it as well as I can figure, following the directions at > > http://www.opencm3.com/installation-windows.html > > I don't really seem to get all the way. Compiling in the CMD window fails > at a link (can't find winspool.lib), and the binaries have problems. > > Funnily enough, WebScape seems to work (as well or poorly as anywhere else), > but mentor and Juno both fail miserably: > > > mika at scruff /cygdrive/c/cm3/bin > $ ./mentor > > > *** > *** runtime error: > *** Attempt to reference an illegal memory location. > *** pc = 0x1061634 = GetAttributes + 0x179 in ..\src\lego\WIN32\ScrollerVBTCl > ass.m3 > *** > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x30af668 0x6a6e4d SystemError + 0x66 in ..\src\runtime\NT386\RTSignal.m3 > 0x30af70c 0x1061634 GetAttributes + 0x179 in ..\src\lego\WIN32\ScrollerVBTClas > s.m3 > 0x30af7e4 0x10993d8 AddView + 0x101e(!) in ..\src\lego\ViewportVBT.m3 > 0x30af830 0x109743e Init + 0x30e in ..\src\lego\ViewportVBT.m3 > 0x30af950 0x1004ee0 pViewport + 0x512 in ..\src\FormsVBT.m3 > 0x30af9b0 0xff33df Item + 0x48b in ..\src\FormsVBT.m3 > 0x30af9dc 0x1010f66 OneChild + 0xf8 in ..\src\FormsVBT.m3 > 0x30afae4 0xff7448 pShape + 0x19c in ..\src\FormsVBT.m3 > 0x30afb44 0xff33df Item + 0x48b in ..\src\FormsVBT.m3 > 0x30afb70 0x1010f66 OneChild + 0xf8 in ..\src\FormsVBT.m3 > ......... ......... ... more frames ... > > mika at scruff /cygdrive/c/cm3/bin > $ ./Juno > > > *** > *** runtime error: > *** failed. > *** file "..\src\winvbt\WinContext.m3", line 165 > *** > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x1b6f854 0xea1e03 PushPixmap + 0x4cb in ..\src\winvbt\WinContext.m3 > 0x1b6f91c 0xeb10c7 PixmapCom + 0x9ed in ..\src\winvbt\WinPaint.m3 > 0x1b6fd78 0xeaedaf PaintBatch + 0x25f in ..\src\winvbt\WinPaint.m3 > 0x1b6fde4 0xea91f3 PaintBatchVBT + 0x13f in ..\src\winvbt\WinTrestle.m3 > 0x1b6fe2c 0xea7919 WindowProc + 0x763 in ..\src\winvbt\WinTrestle.m3 > 0x1b6fe4c 0x77e3a454 > 0x1b6fed8 0x77e14605 > 0x1b6ff30 0x77e15b77 > 0x1b6ff88 0x4fb015 RunThread + 0x234 in ..\src\thread\WIN32\ThreadWin32.m3 > 0x1b6ffb4 0x4fad57 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3 > ......... ......... ... more frames ... > > mika at scruff /cygdrive/c/cm3/bin > $ > > This is running from the cygwin shell but it doesn't do anything different > from CMD... > > Should I not expect to be able to get this to work? > > Mika From hendrik at topoi.pooq.com Fri Aug 28 05:17:23 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 27 Aug 2009 23:17:23 -0400 Subject: [M3devel] small design problem in ButtonVBT? In-Reply-To: References: <20090331145127.GB9624@topoi.pooq.com> <20090401120347.x8cneize8oscg44o@mail.elegosoft.com> <20090826002606.GB16386@topoi.pooq.com> <20090827141741.9g1u2vrgfgokkksg@mail.elegosoft.com> Message-ID: <20090828031722.GB22883@topoi.pooq.com> On Thu, Aug 27, 2009 at 03:15:41PM -0400, Tony Hosking wrote: > I am nervous about having the two alternative entries to the action > procedure that other code might not be aware of. Yes, you've modified > the default mouse method to call the action method instead of the > procedure, but what about other places where the mouse method has been > overridden. > > If you want to be smart about it in your own code you can simply > invert your suggestion and do the following: > > TYPE T = ButtonVBT.T OBJECT > METHODS action(cd: VBT.MouseRec) := Action; > > PROCEDURE Action(v: T; cd: VBT.MouseRec) = ... > > PROCEDURE ActionProc(v: ButtonVBT.T; cd: VBT.MouseRec) = > BEGIN > NARROW(v, T).action(cd); > END ActionProc; > > and initialize your T thingy with ButtonVBT.New(..., action := > ActionProc; ...) > > Then in your code you can go ahead and override the action method to > your hearts content. This kind of thing would work. But, like the existing semantics of ButtonVBT, it seems to be fighting the language instead of working with it. I'd be happiest to get rid of the action variable altogether, but that would be a massively incompatible change, and would require change to a lot of existing code. What I proposed is compatible with existing code, and also has the advantage that someone who subclasses ButtonVBT.T and overrides act can completely ignore the action variable altogether. You say > and initialize your T thingy with ButtonVBT.New(..., action := > ActionProc; ...) But that requires every object I make of type T or any sibclass to be explicitly initialised with ActionProc, certainly a nuisance, and certainly error-prone. The inelegance I see with my approach is that there are two mechanisms for specifying the action to be taken. Either will work without the programmer paying any attention to the other, but if you use both, one will override the other. This is not a problem with legacy software. I'll have to come up with some documentation that makes this clear. It's the inelegance that comes from backward compatibility, and I think my solution is less inelegant, and easier to use, than yours. Yours, however, involves no change in existing code. > > Am I just being paranoid? No. Perhaps just paranoid about different things. I had hoped for someone to come up with a solid technical reason for the action variable. The original designers were clever people, and I'd *still* like to know why they thought it was a good idea. It's awkward and error-prone to use, and they had to use the PutProp/GetProp kludge just to approximate what the language provided for free with inheritance. I'm tempted to go over the entire code-base and change the buttons to use act instead of action, but I have to admit I'm not tempted enough to actually do it... -- hendrik > On 27 Aug 2009, at 08:17, Olaf Wagner wrote: > > >Though I promised to do it, I have lost sight of this task while > >trying to build some RC3 archives on Windows. As I'm not at home this > >evening, can somebody else please commit Hendrik's extension? > > > >Is this something we should should have in the release branch, too? > >Probably not necessary? > > > >Olaf > > > >Quoting hendrik at topoi.pooq.com: > > > >>On Wed, Apr 01, 2009 at 12:03:47PM +0200, Olaf Wagner wrote: > >>>Quoting hendrik at topoi.pooq.com: > >>> > >>>>The BottonVBT contains an action, which is a procedure rather > >>>than a > >>>>method. b This makes it awkward to subclass ButtonVBT becaue the > >>>action > >>>>will still expect its first parameter to be a ButtonVBT instead of > >>>>belonging to the subclass, and an explicit downcast of some sort > >>>will be > >>>>needed to acess the subclass's members. > >>>> > >>>>The Trestle manual says this was a deliberate decision: > >>>> > >>>>: The action procedure is a field rather than a method in order > >>>to allow > >>>>: buttons with different action procedures to share their method > >>>suites. > >>>> > >>>>I, however, find it massively inconvenient because it mans I have > >>>to > >>>>resort to downcasting or the very kludgey VBT.GetProp to access > >>>what > >>>>should be just there. I'd rather the action procedure was a > >>>method. > >>>> > >>>>But it should be possible to have the best of both worlds. Have an > >>>>action2 (better name wanted here) method that is available for > >>>>overriding, and by default calls the procedure in the existing > >>>action. > >>>>field. That action2 method wounl then be called by Trestle > >>>wherever > >>>>action is now called. > >>>> > >>>>Does anyone see problems with this? > >>> > >>>Sounds fine to me offhand. You should test your extensions with > >>>some of the existing larger applications, like mentor and Juno-2, > >>>of course. > >> > >>OK. Here's the patch. Would it be possible for someone to check it > >>in > >>for me? > >> > >>mentor runs fine with this change; I watched it animate a heap-sort. > >> > >>I have no idea what Juno is supposed to do, but it did respond to > >>button-pushes. > >> > >> > >>hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ cvs diff > >>cvs diff: Diffing . > >>Index: ButtonVBT.i3 > >>=================================================================== > >>RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.i3,v > >>retrieving revision 1.2 > >>diff -r1.2 ButtonVBT.i3 > >>39a40 > >>> act(READONLY cd: VBT.MouseRec); > >>Index: ButtonVBT.m3 > >>=================================================================== > >>RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.m3,v > >>retrieving revision 1.2 > >>diff -r1.2 ButtonVBT.m3 > >>28c28,29 > >>< init := Be > >>--- > >>> init := Be; > >>> act := act > >>46a48,52 > >>>PROCEDURE act(v : T; READONLY cd: VBT.MouseRec) = > >>> BEGIN > >>> v.action(v, cd); > >>> END act; > >>> > >>59c65 > >>< v.action(v, cd); > >>--- > >>> v.act(cd); > >>hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ > >> > >>-- hendrik > >> > > > > > > > >-- > >Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > >Germany > >phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > >45 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > >Berlin > >Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > >DE163214194 > > > From jay.krell at cornell.edu Fri Aug 28 05:28:32 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 28 Aug 2009 03:28:32 +0000 Subject: [M3devel] small design problem in ButtonVBT? In-Reply-To: <20090828031722.GB22883@topoi.pooq.com> References: <20090331145127.GB9624@topoi.pooq.com> <20090401120347.x8cneize8oscg44o@mail.elegosoft.com> <20090826002606.GB16386@topoi.pooq.com> <20090827141741.9g1u2vrgfgokkksg@mail.elegosoft.com> <20090828031722.GB22883@topoi.pooq.com> Message-ID: I think I know the reason it is this way. It is very common to override action and nothing else. It is "inconvenient" to derive a new type, just to change one function. - Jay ---------------------------------------- > Date: Thu, 27 Aug 2009 23:17:23 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] small design problem in ButtonVBT? > > On Thu, Aug 27, 2009 at 03:15:41PM -0400, Tony Hosking wrote: >> I am nervous about having the two alternative entries to the action >> procedure that other code might not be aware of. Yes, you've modified >> the default mouse method to call the action method instead of the >> procedure, but what about other places where the mouse method has been >> overridden. >> >> If you want to be smart about it in your own code you can simply >> invert your suggestion and do the following: >> >> TYPE T = ButtonVBT.T OBJECT >> METHODS action(cd: VBT.MouseRec) := Action; >> >> PROCEDURE Action(v: T; cd: VBT.MouseRec) = ... >> >> PROCEDURE ActionProc(v: ButtonVBT.T; cd: VBT.MouseRec) = >> BEGIN >> NARROW(v, T).action(cd); >> END ActionProc; >> >> and initialize your T thingy with ButtonVBT.New(..., action := >> ActionProc; ...) >> >> Then in your code you can go ahead and override the action method to >> your hearts content. > > This kind of thing would work. But, like the existing semantics of > ButtonVBT, it seems to be fighting the language instead of working with > it. I'd be happiest to get rid of the action variable altogether, but > that would be a massively incompatible change, and would require change > to a lot of existing code. What I proposed is compatible with existing > code, and also has the advantage that someone who subclasses ButtonVBT.T > and overrides act can completely ignore the action variable altogether. > > You say > >> and initialize your T thingy with ButtonVBT.New(..., action := >> ActionProc; ...) > > But that requires every object I make of type T or any sibclass to be > explicitly initialised with ActionProc, certainly a nuisance, and > certainly error-prone. > > The inelegance I see with my approach is that there are two mechanisms > for specifying the action to be taken. Either will work without the > programmer paying any attention to the other, but if you use both, one > will override the other. This is not a problem with legacy software. > I'll have to come up with some documentation that makes this clear. > It's the inelegance that comes from backward compatibility, and I think > my solution is less inelegant, and easier to use, than yours. Yours, > however, involves no change in existing code. > >> >> Am I just being paranoid? > > No. Perhaps just paranoid about different things. > > I had hoped for someone to come up with a solid technical reason for the > action variable. The original designers were clever people, and I'd > *still* like to know why they thought it was a good idea. It's awkward > and error-prone to use, and they had to use the PutProp/GetProp kludge > just to approximate what the language provided for free with inheritance. > > I'm tempted to go over the entire code-base and change the buttons to > use act instead of action, but I have to admit I'm not tempted enough to > actually do it... > > -- hendrik > >> On 27 Aug 2009, at 08:17, Olaf Wagner wrote: >> >>>Though I promised to do it, I have lost sight of this task while >>>trying to build some RC3 archives on Windows. As I'm not at home this >>>evening, can somebody else please commit Hendrik's extension? >>> >>>Is this something we should should have in the release branch, too? >>>Probably not necessary? >>> >>>Olaf >>> >>>Quoting hendrik at topoi.pooq.com: >>> >>>>On Wed, Apr 01, 2009 at 12:03:47PM +0200, Olaf Wagner wrote: >>>>>Quoting hendrik at topoi.pooq.com: >>>>> >>>>>>The BottonVBT contains an action, which is a procedure rather >>>>>than a >>>>>>method. b This makes it awkward to subclass ButtonVBT becaue the >>>>>action >>>>>>will still expect its first parameter to be a ButtonVBT instead of >>>>>>belonging to the subclass, and an explicit downcast of some sort >>>>>will be >>>>>>needed to acess the subclass's members. >>>>>> >>>>>>The Trestle manual says this was a deliberate decision: >>>>>> >>>>>>: The action procedure is a field rather than a method in order >>>>>to allow >>>>>>: buttons with different action procedures to share their method >>>>>suites. >>>>>> >>>>>>I, however, find it massively inconvenient because it mans I have >>>>>to >>>>>>resort to downcasting or the very kludgey VBT.GetProp to access >>>>>what >>>>>>should be just there. I'd rather the action procedure was a >>>>>method. >>>>>> >>>>>>But it should be possible to have the best of both worlds. Have an >>>>>>action2 (better name wanted here) method that is available for >>>>>>overriding, and by default calls the procedure in the existing >>>>>action. >>>>>>field. That action2 method wounl then be called by Trestle >>>>>wherever >>>>>>action is now called. >>>>>> >>>>>>Does anyone see problems with this? >>>>> >>>>>Sounds fine to me offhand. You should test your extensions with >>>>>some of the existing larger applications, like mentor and Juno-2, >>>>>of course. >>>> >>>>OK. Here's the patch. Would it be possible for someone to check it >>>>in >>>>for me? >>>> >>>>mentor runs fine with this change; I watched it animate a heap-sort. >>>> >>>>I have no idea what Juno is supposed to do, but it did respond to >>>>button-pushes. >>>> >>>> >>>>hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ cvs diff >>>>cvs diff: Diffing . >>>>Index: ButtonVBT.i3 >>>>=================================================================== >>>>RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.i3,v >>>>retrieving revision 1.2 >>>>diff -r1.2 ButtonVBT.i3 >>>>39a40 >>>>> act(READONLY cd: VBT.MouseRec); >>>>Index: ButtonVBT.m3 >>>>=================================================================== >>>>RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.m3,v >>>>retrieving revision 1.2 >>>>diff -r1.2 ButtonVBT.m3 >>>>28c28,29 >>>>< init := Be >>>>--- >>>>> init := Be; >>>>> act := act >>>>46a48,52 >>>>>PROCEDURE act(v : T; READONLY cd: VBT.MouseRec) = >>>>> BEGIN >>>>> v.action(v, cd); >>>>> END act; >>>>> >>>>59c65 >>>>< v.action(v, cd); >>>>--- >>>>> v.act(cd); >>>>hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ >>>> >>>>-- hendrik >>>> >>> >>> >>> >>>-- >>>Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>>Germany >>>phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>>Berlin >>>Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>DE163214194 >>> >> From hosking at cs.purdue.edu Fri Aug 28 05:26:23 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 27 Aug 2009 23:26:23 -0400 Subject: [M3devel] small design problem in ButtonVBT? In-Reply-To: <20090828031722.GB22883@topoi.pooq.com> References: <20090331145127.GB9624@topoi.pooq.com> <20090401120347.x8cneize8oscg44o@mail.elegosoft.com> <20090826002606.GB16386@topoi.pooq.com> <20090827141741.9g1u2vrgfgokkksg@mail.elegosoft.com> <20090828031722.GB22883@topoi.pooq.com> Message-ID: <433A59EF-4617-424C-8355-893C104F02D4@cs.purdue.edu> I suspect they were concerned about space bloat, if every different kind of button ends up with a separate method suite (because it overrides action). The expectation was that most buttons would inherit the standard behavior, and simply provide a tailored action procedure. It is elegant insofar as it avoids copying the default method suite entries for every different kind of button, but as you say kludgey in practice. If you go ahead and replace the proc with the method everywhere then you will increase the memory footprint. On 27 Aug 2009, at 23:17, hendrik at topoi.pooq.com wrote: > On Thu, Aug 27, 2009 at 03:15:41PM -0400, Tony Hosking wrote: >> I am nervous about having the two alternative entries to the action >> procedure that other code might not be aware of. Yes, you've >> modified >> the default mouse method to call the action method instead of the >> procedure, but what about other places where the mouse method has >> been >> overridden. >> >> If you want to be smart about it in your own code you can simply >> invert your suggestion and do the following: >> >> TYPE T = ButtonVBT.T OBJECT >> METHODS action(cd: VBT.MouseRec) := Action; >> >> PROCEDURE Action(v: T; cd: VBT.MouseRec) = ... >> >> PROCEDURE ActionProc(v: ButtonVBT.T; cd: VBT.MouseRec) = >> BEGIN >> NARROW(v, T).action(cd); >> END ActionProc; >> >> and initialize your T thingy with ButtonVBT.New(..., action := >> ActionProc; ...) >> >> Then in your code you can go ahead and override the action method to >> your hearts content. > > This kind of thing would work. But, like the existing semantics of > ButtonVBT, it seems to be fighting the language instead of working > with > it. I'd be happiest to get rid of the action variable altogether, but > that would be a massively incompatible change, and would require > change > to a lot of existing code. What I proposed is compatible with > existing > code, and also has the advantage that someone who subclasses > ButtonVBT.T > and overrides act can completely ignore the action variable > altogether. > > You say > >> and initialize your T thingy with ButtonVBT.New(..., action := >> ActionProc; ...) > > But that requires every object I make of type T or any sibclass to be > explicitly initialised with ActionProc, certainly a nuisance, and > certainly error-prone. > > The inelegance I see with my approach is that there are two mechanisms > for specifying the action to be taken. Either will work without the > programmer paying any attention to the other, but if you use both, one > will override the other. This is not a problem with legacy software. > I'll have to come up with some documentation that makes this clear. > It's the inelegance that comes from backward compatibility, and I > think > my solution is less inelegant, and easier to use, than yours. Yours, > however, involves no change in existing code. > >> >> Am I just being paranoid? > > No. Perhaps just paranoid about different things. > > I had hoped for someone to come up with a solid technical reason for > the > action variable. The original designers were clever people, and I'd > *still* like to know why they thought it was a good idea. It's > awkward > and error-prone to use, and they had to use the PutProp/GetProp kludge > just to approximate what the language provided for free with > inheritance. > > I'm tempted to go over the entire code-base and change the buttons to > use act instead of action, but I have to admit I'm not tempted > enough to > actually do it... > > -- hendrik > >> On 27 Aug 2009, at 08:17, Olaf Wagner wrote: >> >>> Though I promised to do it, I have lost sight of this task while >>> trying to build some RC3 archives on Windows. As I'm not at home >>> this >>> evening, can somebody else please commit Hendrik's extension? >>> >>> Is this something we should should have in the release branch, too? >>> Probably not necessary? >>> >>> Olaf >>> >>> Quoting hendrik at topoi.pooq.com: >>> >>>> On Wed, Apr 01, 2009 at 12:03:47PM +0200, Olaf Wagner wrote: >>>>> Quoting hendrik at topoi.pooq.com: >>>>> >>>>>> The BottonVBT contains an action, which is a procedure rather >>>>> than a >>>>>> method. b This makes it awkward to subclass ButtonVBT becaue the >>>>> action >>>>>> will still expect its first parameter to be a ButtonVBT instead >>>>>> of >>>>>> belonging to the subclass, and an explicit downcast of some sort >>>>> will be >>>>>> needed to acess the subclass's members. >>>>>> >>>>>> The Trestle manual says this was a deliberate decision: >>>>>> >>>>>> : The action procedure is a field rather than a method in order >>>>> to allow >>>>>> : buttons with different action procedures to share their method >>>>> suites. >>>>>> >>>>>> I, however, find it massively inconvenient because it mans I have >>>>> to >>>>>> resort to downcasting or the very kludgey VBT.GetProp to access >>>>> what >>>>>> should be just there. I'd rather the action procedure was a >>>>> method. >>>>>> >>>>>> But it should be possible to have the best of both worlds. >>>>>> Have an >>>>>> action2 (better name wanted here) method that is available for >>>>>> overriding, and by default calls the procedure in the existing >>>>> action. >>>>>> field. That action2 method wounl then be called by Trestle >>>>> wherever >>>>>> action is now called. >>>>>> >>>>>> Does anyone see problems with this? >>>>> >>>>> Sounds fine to me offhand. You should test your extensions with >>>>> some of the existing larger applications, like mentor and Juno-2, >>>>> of course. >>>> >>>> OK. Here's the patch. Would it be possible for someone to check it >>>> in >>>> for me? >>>> >>>> mentor runs fine with this change; I watched it animate a heap- >>>> sort. >>>> >>>> I have no idea what Juno is supposed to do, but it did respond to >>>> button-pushes. >>>> >>>> >>>> hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ cvs diff >>>> cvs diff: Diffing . >>>> Index: ButtonVBT.i3 >>>> =================================================================== >>>> RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.i3,v >>>> retrieving revision 1.2 >>>> diff -r1.2 ButtonVBT.i3 >>>> 39a40 >>>>> act(READONLY cd: VBT.MouseRec); >>>> Index: ButtonVBT.m3 >>>> =================================================================== >>>> RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.m3,v >>>> retrieving revision 1.2 >>>> diff -r1.2 ButtonVBT.m3 >>>> 28c28,29 >>>> < init := Be >>>> --- >>>>> init := Be; >>>>> act := act >>>> 46a48,52 >>>>> PROCEDURE act(v : T; READONLY cd: VBT.MouseRec) = >>>>> BEGIN >>>>> v.action(v, cd); >>>>> END act; >>>>> >>>> 59c65 >>>> < v.action(v, cd); >>>> --- >>>>> v.act(cd); >>>> hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ >>>> >>>> -- hendrik >>>> >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>> Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>> 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>> Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Aug 28 05:53:27 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 27 Aug 2009 23:53:27 -0400 Subject: [M3devel] small design problem in ButtonVBT? In-Reply-To: References: <20090331145127.GB9624@topoi.pooq.com> <20090401120347.x8cneize8oscg44o@mail.elegosoft.com> <20090826002606.GB16386@topoi.pooq.com> <20090827141741.9g1u2vrgfgokkksg@mail.elegosoft.com> <20090828031722.GB22883@topoi.pooq.com> Message-ID: <36DAB001-70F3-4C96-B1D5-57E8A7322464@cs.purdue.edu> Right. Plus, overriding copies the entire method suite for the new type. On 27 Aug 2009, at 23:28, Jay K wrote: > > I think I know the reason it is this way. > It is very common to override action and nothing else. > It is "inconvenient" to derive a new type, just to change one > function. > > - Jay > > ---------------------------------------- >> Date: Thu, 27 Aug 2009 23:17:23 -0400 >> From: hendrik at topoi.pooq.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] small design problem in ButtonVBT? >> >> On Thu, Aug 27, 2009 at 03:15:41PM -0400, Tony Hosking wrote: >>> I am nervous about having the two alternative entries to the action >>> procedure that other code might not be aware of. Yes, you've >>> modified >>> the default mouse method to call the action method instead of the >>> procedure, but what about other places where the mouse method has >>> been >>> overridden. >>> >>> If you want to be smart about it in your own code you can simply >>> invert your suggestion and do the following: >>> >>> TYPE T = ButtonVBT.T OBJECT >>> METHODS action(cd: VBT.MouseRec) := Action; >>> >>> PROCEDURE Action(v: T; cd: VBT.MouseRec) = ... >>> >>> PROCEDURE ActionProc(v: ButtonVBT.T; cd: VBT.MouseRec) = >>> BEGIN >>> NARROW(v, T).action(cd); >>> END ActionProc; >>> >>> and initialize your T thingy with ButtonVBT.New(..., action := >>> ActionProc; ...) >>> >>> Then in your code you can go ahead and override the action method to >>> your hearts content. >> >> This kind of thing would work. But, like the existing semantics of >> ButtonVBT, it seems to be fighting the language instead of working >> with >> it. I'd be happiest to get rid of the action variable altogether, but >> that would be a massively incompatible change, and would require >> change >> to a lot of existing code. What I proposed is compatible with >> existing >> code, and also has the advantage that someone who subclasses >> ButtonVBT.T >> and overrides act can completely ignore the action variable >> altogether. >> >> You say >> >>> and initialize your T thingy with ButtonVBT.New(..., action := >>> ActionProc; ...) >> >> But that requires every object I make of type T or any sibclass to be >> explicitly initialised with ActionProc, certainly a nuisance, and >> certainly error-prone. >> >> The inelegance I see with my approach is that there are two >> mechanisms >> for specifying the action to be taken. Either will work without the >> programmer paying any attention to the other, but if you use both, >> one >> will override the other. This is not a problem with legacy software. >> I'll have to come up with some documentation that makes this clear. >> It's the inelegance that comes from backward compatibility, and I >> think >> my solution is less inelegant, and easier to use, than yours. Yours, >> however, involves no change in existing code. >> >>> >>> Am I just being paranoid? >> >> No. Perhaps just paranoid about different things. >> >> I had hoped for someone to come up with a solid technical reason >> for the >> action variable. The original designers were clever people, and I'd >> *still* like to know why they thought it was a good idea. It's >> awkward >> and error-prone to use, and they had to use the PutProp/GetProp >> kludge >> just to approximate what the language provided for free with >> inheritance. >> >> I'm tempted to go over the entire code-base and change the buttons to >> use act instead of action, but I have to admit I'm not tempted >> enough to >> actually do it... >> >> -- hendrik >> >>> On 27 Aug 2009, at 08:17, Olaf Wagner wrote: >>> >>>> Though I promised to do it, I have lost sight of this task while >>>> trying to build some RC3 archives on Windows. As I'm not at home >>>> this >>>> evening, can somebody else please commit Hendrik's extension? >>>> >>>> Is this something we should should have in the release branch, too? >>>> Probably not necessary? >>>> >>>> Olaf >>>> >>>> Quoting hendrik at topoi.pooq.com: >>>> >>>>> On Wed, Apr 01, 2009 at 12:03:47PM +0200, Olaf Wagner wrote: >>>>>> Quoting hendrik at topoi.pooq.com: >>>>>> >>>>>>> The BottonVBT contains an action, which is a procedure rather >>>>>> than a >>>>>>> method. b This makes it awkward to subclass ButtonVBT becaue the >>>>>> action >>>>>>> will still expect its first parameter to be a ButtonVBT >>>>>>> instead of >>>>>>> belonging to the subclass, and an explicit downcast of some sort >>>>>> will be >>>>>>> needed to acess the subclass's members. >>>>>>> >>>>>>> The Trestle manual says this was a deliberate decision: >>>>>>> >>>>>>> : The action procedure is a field rather than a method in order >>>>>> to allow >>>>>>> : buttons with different action procedures to share their method >>>>>> suites. >>>>>>> >>>>>>> I, however, find it massively inconvenient because it mans I >>>>>>> have >>>>>> to >>>>>>> resort to downcasting or the very kludgey VBT.GetProp to access >>>>>> what >>>>>>> should be just there. I'd rather the action procedure was a >>>>>> method. >>>>>>> >>>>>>> But it should be possible to have the best of both worlds. >>>>>>> Have an >>>>>>> action2 (better name wanted here) method that is available for >>>>>>> overriding, and by default calls the procedure in the existing >>>>>> action. >>>>>>> field. That action2 method wounl then be called by Trestle >>>>>> wherever >>>>>>> action is now called. >>>>>>> >>>>>>> Does anyone see problems with this? >>>>>> >>>>>> Sounds fine to me offhand. You should test your extensions with >>>>>> some of the existing larger applications, like mentor and Juno-2, >>>>>> of course. >>>>> >>>>> OK. Here's the patch. Would it be possible for someone to check it >>>>> in >>>>> for me? >>>>> >>>>> mentor runs fine with this change; I watched it animate a heap- >>>>> sort. >>>>> >>>>> I have no idea what Juno is supposed to do, but it did respond to >>>>> button-pushes. >>>>> >>>>> >>>>> hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ cvs diff >>>>> cvs diff: Diffing . >>>>> Index: ButtonVBT.i3 >>>>> = >>>>> ================================================================== >>>>> RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.i3,v >>>>> retrieving revision 1.2 >>>>> diff -r1.2 ButtonVBT.i3 >>>>> 39a40 >>>>>> act(READONLY cd: VBT.MouseRec); >>>>> Index: ButtonVBT.m3 >>>>> = >>>>> ================================================================== >>>>> RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.m3,v >>>>> retrieving revision 1.2 >>>>> diff -r1.2 ButtonVBT.m3 >>>>> 28c28,29 >>>>> < init := Be >>>>> --- >>>>>> init := Be; >>>>>> act := act >>>>> 46a48,52 >>>>>> PROCEDURE act(v : T; READONLY cd: VBT.MouseRec) = >>>>>> BEGIN >>>>>> v.action(v, cd); >>>>>> END act; >>>>>> >>>>> 59c65 >>>>> < v.action(v, cd); >>>>> --- >>>>>> v.act(cd); >>>>> hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ >>>>> >>>>> -- hendrik >>>>> >>>> >>>> >>>> >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>>> Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>> 45 86 95 >>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>>> Berlin >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>> DE163214194 >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Aug 28 06:02:38 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 28 Aug 2009 04:02:38 +0000 Subject: [M3devel] CM3 on windows In-Reply-To: <20090828034057.475DD1A209A@async.async.caltech.edu> References: <20090828020144.B5E7C1A209A@async.async.caltech.edu> <20090828034057.475DD1A209A@async.async.caltech.edu> Message-ID: > Compiling in the CMD window fails>> at a link (can't find winspool.lib)=2C and the binaries have problems Where is it getting kernel32.lib? c:\cm3\lib? %LIB%? What is your compiler/linker? What are the "problems"? - Jay ---------------------------------------- > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: CM3 on windows > Date: Thu, 27 Aug 2009 20:40:57 -0700 > From: mika at async.async.caltech.edu > > Jay K writes: >> >>I fixed the access on 5.8.2. >>Try that? >>I can poke around.. >>=20 >>As I recall 5.8.1 used VC 8.0 and 5.8.2 used 9.0. >>If that helps. > > Well I can try but I don't think 9.0 works on Win2k... > >>=20 >> - Jay >> >> >>---------------------------------------- >>> To: m3devel at elegosoft.com=3B jay.krell at cornell.edu >>> CC: mika at async.caltech.edu >>> Subject: CM3 on windows >>> Date: Thu=2C 27 Aug 2009 19:01:44 -0700 >>> From: mika at async.async.caltech.edu >>> >>> Hi m3devel=2C >>> >>> Not sure if my earlier message today went anywhere. I never saw it on >>> the list. >>> >>> I'd like to try running CM3 on Windows 2000=2C so I've downloaded >>> >>> http://www.opencm3.com/uploaded-archives/cm3-std-NT386-d5.8.1.msi >>> >>> (5.8.2 didn't work---no access). >>> >>> Having installed it as well as I can figure=2C following the directions a= >>t >>> >>> http://www.opencm3.com/installation-windows.html >>> >>> I don't really seem to get all the way. Compiling in the CMD window fails >>> at a link (can't find winspool.lib)=2C and the binaries have problems. >>> >>> Funnily enough=2C WebScape seems to work (as well or poorly as anywhere e= >>lse)=2C >>> but mentor and Juno both fail miserably: >>> >>> >>> mika at scruff /cygdrive/c/cm3/bin >>> $ ./mentor >>> >>> >>> *** >>> *** runtime error: >>> *** Attempt to reference an illegal memory location. >>> *** pc =3D 0x1061634 =3D GetAttributes + 0x179 in ..\src\lego\WIN32\Scrol= >>lerVBTCl >>> ass.m3 >>> *** >>> >>> Stack trace: >>> FP PC Procedure >>> --------- --------- ------------------------------- >>> 0x30af668 0x6a6e4d SystemError + 0x66 in ..\src\runtime\NT386\RTSignal.m3 >>> 0x30af70c 0x1061634 GetAttributes + 0x179 in ..\src\lego\WIN32\ScrollerVB= >>TClas >>> s.m3 >>> 0x30af7e4 0x10993d8 AddView + 0x101e(!) in ..\src\lego\ViewportVBT.m3 >>> 0x30af830 0x109743e Init + 0x30e in ..\src\lego\ViewportVBT.m3 >>> 0x30af950 0x1004ee0 pViewport + 0x512 in ..\src\FormsVBT.m3 >>> 0x30af9b0 0xff33df Item + 0x48b in ..\src\FormsVBT.m3 >>> 0x30af9dc 0x1010f66 OneChild + 0xf8 in ..\src\FormsVBT.m3 >>> 0x30afae4 0xff7448 pShape + 0x19c in ..\src\FormsVBT.m3 >>> 0x30afb44 0xff33df Item + 0x48b in ..\src\FormsVBT.m3 >>> 0x30afb70 0x1010f66 OneChild + 0xf8 in ..\src\FormsVBT.m3 >>> ......... ......... ... more frames ... >>> >>> mika at scruff /cygdrive/c/cm3/bin >>> $ ./Juno >>> >>> >>> *** >>> *** runtime error: >>> *** failed. >>> *** file "..\src\winvbt\WinContext.m3"=2C line 165 >>> *** >>> >>> Stack trace: >>> FP PC Procedure >>> --------- --------- ------------------------------- >>> 0x1b6f854 0xea1e03 PushPixmap + 0x4cb in ..\src\winvbt\WinContext.m3 >>> 0x1b6f91c 0xeb10c7 PixmapCom + 0x9ed in ..\src\winvbt\WinPaint.m3 >>> 0x1b6fd78 0xeaedaf PaintBatch + 0x25f in ..\src\winvbt\WinPaint.m3 >>> 0x1b6fde4 0xea91f3 PaintBatchVBT + 0x13f in ..\src\winvbt\WinTrestle.m3 >>> 0x1b6fe2c 0xea7919 WindowProc + 0x763 in ..\src\winvbt\WinTrestle.m3 >>> 0x1b6fe4c 0x77e3a454=20 >>> 0x1b6fed8 0x77e14605=20 >>> 0x1b6ff30 0x77e15b77=20 >>> 0x1b6ff88 0x4fb015 RunThread + 0x234 in ..\src\thread\WIN32\ThreadWin32.m= >>3 >>> 0x1b6ffb4 0x4fad57 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m= >>3 >>> ......... ......... ... more frames ... >>> >>> mika at scruff /cygdrive/c/cm3/bin >>> $ >>> >>> This is running from the cygwin shell but it doesn't do anything differen= >>t >>> from CMD... >>> >>> Should I not expect to be able to get this to work? >>> >>> Mika= From jay.krell at cornell.edu Fri Aug 28 06:32:02 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 28 Aug 2009 04:32:02 +0000 Subject: [M3devel] CM3 on windows In-Reply-To: <20090828042715.B05E51A20A1@async.async.caltech.edu> References: <20090828020144.B5E7C1A209A@async.async.caltech.edu> <20090828034057.475DD1A209A@async.async.caltech.edu> <20090828042715.B05E51A20A1@async.async.caltech.edu> Message-ID: NT386GNU => Do you have an X Windows server? Compiler -- I meant the C compiler. set show: set LIB set PATH set INCLUDE and then among the directories in LIB, and your cm3 install\lib, where is kernel32.lib? Where is winspool.lib? Cm3 has its own, but for /almost/ no good reason. Older cm3 had its own modified ones for reasons related to the VM-sychronized GC. If you were to keep those around, they wouldn't work any longer -- probably fail to link. So current cm3 replaces them. As well, some much less usual toolsets, such as the Visual C++ 2003 Express or somesuch, which isn't available any longer, only included a C runtime and no kernel32.lib, user32.lib, winspool.lib, etc. So we provide them for such users. Perhaps we should 1) assume a new clean install, no old cm3 .libs 2) not support that one odd toolset -- heck, we can keep the import-libs directory, just remove it from any package set, and any such users can build it themselves. Long story short: normally among the directories in %LIB%, you should find kernel32.lib, msvcrt.lib, winspool.lib, user32.lib, gdi32.lib, comctl32.lib, etc. Windows 2000, really? Plan to upgrade to XP or newer any time soon? - Jay ---------------------------------------- > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: CM3 on windows > Date: Thu, 27 Aug 2009 21:27:15 -0700 > From: mika at async.async.caltech.edu > > Jay K writes: >> >>> Compiling in the CMD window fails>> at a link (can't find winspool.lib)= >>=3D2C and the binaries have problems >> >>=20 >>Where is it getting kernel32.lib? >> c:\cm3\lib? >> %LIB%? >>What is your compiler/linker? >>What are the "problems"? > > I installed Visual C++ Express Edition 8.0. > > It appears to use "link.exe" (not the Cygwin one, but a Windows one) as linker. > > Compiler... cm3?? > > The "problems" are mentioned in my email (scroll down a bit... mentor, Juno, ...) > > I tried NT386GNU as well, which does let me do text mode applications but crashes > if I try to open a window. "TrestleComm.Failure" > > I have to warn you I am a *complete* novice when it comes to programming in > Windows... > > Mika > >>=20 >>=20 >> - Jay >> >> >> >>---------------------------------------- >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com >>> Subject: Re: CM3 on windows >>> Date: Thu=2C 27 Aug 2009 20:40:57 -0700 >>> From: mika at async.async.caltech.edu >>> >>> Jay K writes: >>>> >>>>I fixed the access on 5.8.2. >>>>Try that? >>>>I can poke around.. >>>>=3D20 >>>>As I recall 5.8.1 used VC 8.0 and 5.8.2 used 9.0. >>>>If that helps. >>> >>> Well I can try but I don't think 9.0 works on Win2k... >>> >>>>=3D20 >>>> - Jay >>>> >>>> >>>>---------------------------------------- >>>>> To: m3devel at elegosoft.com=3D3B jay.krell at cornell.edu >>>>> CC: mika at async.caltech.edu >>>>> Subject: CM3 on windows >>>>> Date: Thu=3D2C 27 Aug 2009 19:01:44 -0700 >>>>> From: mika at async.async.caltech.edu >>>>> >>>>> Hi m3devel=3D2C >>>>> >>>>> Not sure if my earlier message today went anywhere. I never saw it on >>>>> the list. >>>>> >>>>> I'd like to try running CM3 on Windows 2000=3D2C so I've downloaded >>>>> >>>>> http://www.opencm3.com/uploaded-archives/cm3-std-NT386-d5.8.1.msi >>>>> >>>>> (5.8.2 didn't work---no access). >>>>> >>>>> Having installed it as well as I can figure=3D2C following the directio= >>ns a=3D >>>>t >>>>> >>>>> http://www.opencm3.com/installation-windows.html >>>>> >>>>> I don't really seem to get all the way. Compiling in the CMD window fai= >>ls >>>>> at a link (can't find winspool.lib)=3D2C and the binaries have problems= >>. >>>>> >>>>> Funnily enough=3D2C WebScape seems to work (as well or poorly as anywhe= >>re e=3D >>>>lse)=3D2C >>>>> but mentor and Juno both fail miserably: >>>>> >>>>> >>>>> mika at scruff /cygdrive/c/cm3/bin >>>>> $ ./mentor >>>>> >>>>> >>>>> *** >>>>> *** runtime error: >>>>> *** Attempt to reference an illegal memory location. >>>>> *** pc =3D3D 0x1061634 =3D3D GetAttributes + 0x179 in ..\src\lego\WIN32= >>\Scrol=3D >>>>lerVBTCl >>>>> ass.m3 >>>>> *** >>>>> >>>>> Stack trace: >>>>> FP PC Procedure >>>>> --------- --------- ------------------------------- >>>>> 0x30af668 0x6a6e4d SystemError + 0x66 in ..\src\runtime\NT386\RTSignal.= >>m3 >>>>> 0x30af70c 0x1061634 GetAttributes + 0x179 in ..\src\lego\WIN32\Scroller= >>VB=3D >>>>TClas >>>>> s.m3 >>>>> 0x30af7e4 0x10993d8 AddView + 0x101e(!) in ..\src\lego\ViewportVBT.m3 >>>>> 0x30af830 0x109743e Init + 0x30e in ..\src\lego\ViewportVBT.m3 >>>>> 0x30af950 0x1004ee0 pViewport + 0x512 in ..\src\FormsVBT.m3 >>>>> 0x30af9b0 0xff33df Item + 0x48b in ..\src\FormsVBT.m3 >>>>> 0x30af9dc 0x1010f66 OneChild + 0xf8 in ..\src\FormsVBT.m3 >>>>> 0x30afae4 0xff7448 pShape + 0x19c in ..\src\FormsVBT.m3 >>>>> 0x30afb44 0xff33df Item + 0x48b in ..\src\FormsVBT.m3 >>>>> 0x30afb70 0x1010f66 OneChild + 0xf8 in ..\src\FormsVBT.m3 >>>>> ......... ......... ... more frames ... >>>>> >>>>> mika at scruff /cygdrive/c/cm3/bin >>>>> $ ./Juno >>>>> >>>>> >>>>> *** >>>>> *** runtime error: >>>>> *** failed. >>>>> *** file "..\src\winvbt\WinContext.m3"=3D2C line 165 >>>>> *** >>>>> >>>>> Stack trace: >>>>> FP PC Procedure >>>>> --------- --------- ------------------------------- >>>>> 0x1b6f854 0xea1e03 PushPixmap + 0x4cb in ..\src\winvbt\WinContext.m3 >>>>> 0x1b6f91c 0xeb10c7 PixmapCom + 0x9ed in ..\src\winvbt\WinPaint.m3 >>>>> 0x1b6fd78 0xeaedaf PaintBatch + 0x25f in ..\src\winvbt\WinPaint.m3 >>>>> 0x1b6fde4 0xea91f3 PaintBatchVBT + 0x13f in ..\src\winvbt\WinTrestle.m3 >>>>> 0x1b6fe2c 0xea7919 WindowProc + 0x763 in ..\src\winvbt\WinTrestle.m3 >>>>> 0x1b6fe4c 0x77e3a454=3D20 >>>>> 0x1b6fed8 0x77e14605=3D20 >>>>> 0x1b6ff30 0x77e15b77=3D20 >>>>> 0x1b6ff88 0x4fb015 RunThread + 0x234 in ..\src\thread\WIN32\ThreadWin32= >>.m=3D >>>>3 >>>>> 0x1b6ffb4 0x4fad57 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32= >>.m=3D >>>>3 >>>>> ......... ......... ... more frames ... >>>>> >>>>> mika at scruff /cygdrive/c/cm3/bin >>>>> $ >>>>> >>>>> This is running from the cygwin shell but it doesn't do anything differ= >>en=3D >>>>t >>>>> from CMD... >>>>> >>>>> Should I not expect to be able to get this to work? >>>>> >>>>> Mika=3D= From jay.krell at cornell.edu Fri Aug 28 07:03:58 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 28 Aug 2009 05:03:58 +0000 Subject: [M3devel] CM3 on windows In-Reply-To: <20090828045055.BA3C81A20A1@async.async.caltech.edu> References: <20090828020144.B5E7C1A209A@async.async.caltech.edu> <20090828034057.475DD1A209A@async.async.caltech.edu> <20090828042715.B05E51A20A1@async.async.caltech.edu> <20090828045055.BA3C81A20A1@async.async.caltech.edu> Message-ID: Yes NT386GNU uses X. Olaf expressed an interest in that. Apparently the Windows port of Trestle has never been completed. (I suspect we should punt Trestle and bind to Qt, but that is another matter.) NT386GMINGNU doesn't use X. Though it had problems last I checked. NT386GNU I think also uses pthreads. And NT386MINGNU does not. The names should be I386_CYGWIN and I386_MINGW. There are few variables, and they are largely but not completely independent of each other: Which cm3 backend, integrated or gcc? Which C compiler, Visual C++ or gcc? (or Watcom or Borland, etc.) Which linker, same choices as previous. Win32 or Posix? In terms of path syntax. fork/exec vs. CreateProcess. Which threading library? Which windowing library? NT386GNU aka I386_CYGWIN is "very Posix". NT386MINGNU is totally Win32, except that the compiler backend is gcc. Oh and maybe the compiler/linker are gcc/GNU ld also. In future I expect to rename the platforms to I386_CYGWIN and I386_MINGW, and I386_NT (NT386)). There was good evicence that the gcc backend has never been used to target Win32 GUI. In particular there wasn't support for __stdcall, and the support is still broken in an usual case. I put in a workaround. - Jay ---------------------------------------- > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: CM3 on windows > Date: Thu, 27 Aug 2009 21:50:55 -0700 > From: mika at async.async.caltech.edu > > Jay K writes: >> >>NT386GNU =3D> Do you have an X Windows server? > > Hmm, really, NT386GNU just uses X? I could swear my ancient > Klagenfurt/PM3 uses Windows windows, not X... > >>Compiler -- I meant the C compiler. > > As far as I know the compiler I'm using is "cl" that came with VC++ 8.0 ("2003"?) > >>=20 >>=20 >>set show: >> set LIB >> set PATH >> set INCLUDE >>=20 >>=20 >>and then among the directories in LIB=2C and your cm3 install\lib=2C where = >>is kernel32.lib? Where is winspool.lib? > > kernel32 is in > > ...Visual Studio 8\VC\lib > > aha.. I think the only winspool I have is in C:\cm3, and that directory is > not in LIB. > > That would explain why things aren't compiling, but not why I get the errors > in mentor, Juno, etc. > > >>=20 >>Cm3 has its own=2C but for /almost/ no good reason. >> Older cm3 had its own modified ones for reasons related to the VM-sychroni= >>zed GC. >> If you were to keep those around=2C they wouldn't work any longer -- proba= >>bly fail to link. >> So current cm3 replaces them. >> As well=2C some much less usual toolsets=2C such as the Visual C++ 2003 Ex= >>press or somesuch=2C which isn't available any longer=2C only included a C = >>runtime and no kernel32.lib=2C user32.lib=2C winspool.lib=2C etc. So we pro= >>vide them for such users. Perhaps we should 1) assume a new clean install= >>=2C no old cm3 .libs 2) not support that one odd toolset -- heck=2C we can = >>keep the import-libs directory=2C just remove it from any package set=2C an= >>d any such users can build it themselves. >>=20 >>=20 >>Long story short: normally among the directories in %LIB%=2C you should fin= >>d kernel32.lib=2C msvcrt.lib=2C winspool.lib=2C user32.lib=2C gdi32.lib=2C = >>comctl32.lib=2C etc. >>=20 >>=20 >>Windows 2000=2C really? >>Plan to upgrade to XP or newer any time soon? > > Wasn't planning on it.. I try to use Windows as little as possible.. but if > it's necessary to get CM3 working.. > > I should mention that my goal is actually to build .exes that can be > distributed to people with Vista. Is that possible with my system? > > Mika > >>=20 >>=20 >> - Jay >> >> >>---------------------------------------- >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com >>> Subject: Re: CM3 on windows >>> Date: Thu=2C 27 Aug 2009 21:27:15 -0700 >>> From: mika at async.async.caltech.edu >>> >>> Jay K writes: >>>> >>>>> Compiling in the CMD window fails>> at a link (can't find winspool.lib)= >>=3D >>>>=3D3D2C and the binaries have problems >>>> >>>>=3D20 >>>>Where is it getting kernel32.lib? >>>> c:\cm3\lib? >>>> %LIB%? >>>>What is your compiler/linker? >>>>What are the "problems"? >>> >>> I installed Visual C++ Express Edition 8.0. >>> >>> It appears to use "link.exe" (not the Cygwin one=2C but a Windows one) as= >> linker. >>> >>> Compiler... cm3?? >>> >>> The "problems" are mentioned in my email (scroll down a bit... mentor=2C = >>Juno=2C ...) >>> >>> I tried NT386GNU as well=2C which does let me do text mode applications b= >>ut crashes >>> if I try to open a window. "TrestleComm.Failure" >>> >>> I have to warn you I am a *complete* novice when it comes to programming = >>in >>> Windows... >>> >>> Mika >>> >>>>=3D20 >>>>=3D20 >>>> - Jay >>>> >>>> >>>> >>>>---------------------------------------- >>>>> To: jay.krell at cornell.edu >>>>> CC: m3devel at elegosoft.com >>>>> Subject: Re: CM3 on windows >>>>> Date: Thu=3D2C 27 Aug 2009 20:40:57 -0700 >>>>> From: mika at async.async.caltech.edu >>>>> >>>>> Jay K writes: >>>>>> >>>>>>I fixed the access on 5.8.2. >>>>>>Try that? >>>>>>I can poke around.. >>>>>>=3D3D20 >>>>>>As I recall 5.8.1 used VC 8.0 and 5.8.2 used 9.0. >>>>>>If that helps. >>>>> >>>>> Well I can try but I don't think 9.0 works on Win2k... >>>>> >>>>>>=3D3D20 >>>>>> - Jay >>>>>> >>>>>> >>>>>>---------------------------------------- >>>>>>> To: m3devel at elegosoft.com=3D3D3B jay.krell at cornell.edu >>>>>>> CC: mika at async.caltech.edu >>>>>>> Subject: CM3 on windows >>>>>>> Date: Thu=3D3D2C 27 Aug 2009 19:01:44 -0700 >>>>>>> From: mika at async.async.caltech.edu >>>>>>> >>>>>>> Hi m3devel=3D3D2C >>>>>>> >>>>>>> Not sure if my earlier message today went anywhere. I never saw it on >>>>>>> the list. >>>>>>> >>>>>>> I'd like to try running CM3 on Windows 2000=3D3D2C so I've downloaded >>>>>>> >>>>>>> http://www.opencm3.com/uploaded-archives/cm3-std-NT386-d5.8.1.msi >>>>>>> >>>>>>> (5.8.2 didn't work---no access). >>>>>>> >>>>>>> Having installed it as well as I can figure=3D3D2C following the dire= >>ctio=3D >>>>ns a=3D3D >>>>>>t >>>>>>> >>>>>>> http://www.opencm3.com/installation-windows.html >>>>>>> >>>>>>> I don't really seem to get all the way. Compiling in the CMD window f= >>ai=3D >>>>ls >>>>>>> at a link (can't find winspool.lib)=3D3D2C and the binaries have prob= >>lems=3D >>>>. >>>>>>> >>>>>>> Funnily enough=3D3D2C WebScape seems to work (as well or poorly as an= >>ywhe=3D >>>>re e=3D3D >>>>>>lse)=3D3D2C >>>>>>> but mentor and Juno both fail miserably: >>>>>>> >>>>>>> >>>>>>> mika at scruff /cygdrive/c/cm3/bin >>>>>>> $ ./mentor >>>>>>> >>>>>>> >>>>>>> *** >>>>>>> *** runtime error: >>>>>>> *** Attempt to reference an illegal memory location. >>>>>>> *** pc =3D3D3D 0x1061634 =3D3D3D GetAttributes + 0x179 in ..\src\lego= >>\WIN32=3D >>>>\Scrol=3D3D >>>>>>lerVBTCl >>>>>>> ass.m3 >>>>>>> *** >>>>>>> >>>>>>> Stack trace: >>>>>>> FP PC Procedure >>>>>>> --------- --------- ------------------------------- >>>>>>> 0x30af668 0x6a6e4d SystemError + 0x66 in ..\src\runtime\NT386\RTSigna= >>l.=3D >>>>m3 >>>>>>> 0x30af70c 0x1061634 GetAttributes + 0x179 in ..\src\lego\WIN32\Scroll= >>er=3D >>>>VB=3D3D >>>>>>TClas >>>>>>> s.m3 >>>>>>> 0x30af7e4 0x10993d8 AddView + 0x101e(!) in ..\src\lego\ViewportVBT.m3 >>>>>>> 0x30af830 0x109743e Init + 0x30e in ..\src\lego\ViewportVBT.m3 >>>>>>> 0x30af950 0x1004ee0 pViewport + 0x512 in ..\src\FormsVBT.m3 >>>>>>> 0x30af9b0 0xff33df Item + 0x48b in ..\src\FormsVBT.m3 >>>>>>> 0x30af9dc 0x1010f66 OneChild + 0xf8 in ..\src\FormsVBT.m3 >>>>>>> 0x30afae4 0xff7448 pShape + 0x19c in ..\src\FormsVBT.m3 >>>>>>> 0x30afb44 0xff33df Item + 0x48b in ..\src\FormsVBT.m3 >>>>>>> 0x30afb70 0x1010f66 OneChild + 0xf8 in ..\src\FormsVBT.m3 >>>>>>> ......... ......... ... more frames ... >>>>>>> >>>>>>> mika at scruff /cygdrive/c/cm3/bin >>>>>>> $ ./Juno >>>>>>> >>>>>>> >>>>>>> *** >>>>>>> *** runtime error: >>>>>>> *** failed. >>>>>>> *** file "..\src\winvbt\WinContext.m3"=3D3D2C line 165 >>>>>>> *** >>>>>>> >>>>>>> Stack trace: >>>>>>> FP PC Procedure >>>>>>> --------- --------- ------------------------------- >>>>>>> 0x1b6f854 0xea1e03 PushPixmap + 0x4cb in ..\src\winvbt\WinContext.m3 >>>>>>> 0x1b6f91c 0xeb10c7 PixmapCom + 0x9ed in ..\src\winvbt\WinPaint.m3 >>>>>>> 0x1b6fd78 0xeaedaf PaintBatch + 0x25f in ..\src\winvbt\WinPaint.m3 >>>>>>> 0x1b6fde4 0xea91f3 PaintBatchVBT + 0x13f in ..\src\winvbt\WinTrestle.= >>m3 >>>>>>> 0x1b6fe2c 0xea7919 WindowProc + 0x763 in ..\src\winvbt\WinTrestle.m3 >>>>>>> 0x1b6fe4c 0x77e3a454=3D3D20 >>>>>>> 0x1b6fed8 0x77e14605=3D3D20 >>>>>>> 0x1b6ff30 0x77e15b77=3D3D20 >>>>>>> 0x1b6ff88 0x4fb015 RunThread + 0x234 in ..\src\thread\WIN32\ThreadWin= >>32=3D >>>>.m=3D3D >>>>>>3 >>>>>>> 0x1b6ffb4 0x4fad57 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin= >>32=3D >>>>.m=3D3D >>>>>>3 >>>>>>> ......... ......... ... more frames ... >>>>>>> >>>>>>> mika at scruff /cygdrive/c/cm3/bin >>>>>>> $ >>>>>>> >>>>>>> This is running from the cygwin shell but it doesn't do anything diff= >>er=3D >>>>en=3D3D >>>>>>t >>>>>>> from CMD... >>>>>>> >>>>>>> Should I not expect to be able to get this to work? >>>>>>> >>>>>>> Mika=3D3D=3D= From jay.krell at cornell.edu Fri Aug 28 09:21:19 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 28 Aug 2009 07:21:19 +0000 Subject: [M3devel] strange code in scripts Message-ID: This sequence is odd: [ ${TARGET} != NT386 ] && "${ROOT}/scripts/do-pkg.sh" buildship echo "${ROOT}/scripts/do-cm3-${DIST}.sh" buildlocal "${ROOT}/scripts/do-cm3-${DIST}.sh" buildlocal || exit 1 header "stage 4: installing libraries using new cm3 compiler" echo "${ROOT}/scripts/do-cm3-${DIST}.sh" buildglobal "${ROOT}/scripts/do-cm3-${DIST}.sh" buildglobal || exit 1 The first line doesn't do anything. In the logs you can see it just says "no packages". I don't understand why buildlocal + buildglobal. Is that, um, to delete the .M3OVERRIDES files, so that "On the other side", ship won't refuse? - Jay From jay.krell at cornell.edu Fri Aug 28 09:22:28 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 28 Aug 2009 07:22:28 +0000 Subject: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems In-Reply-To: <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> References: <20090826142644.r6yabwff5wc84cgg@mail.elegosoft.com> <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> Message-ID: It was backslashes vs. forward slashes as I had originally suspected. My debugprinting never hit because I was guessing the elego paths wrong. I finally made it always print and tested it in-situ in the VM. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems > Date: Thu, 27 Aug 2009 12:15:14 +0000 > > > My current theory is the unresolve problem is due to that wierd initial build of import-libs in the Hudson task, which was related to the line endings problem, which was related to using CVSNT instead of Cygwin cvs. > > - Jay > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems >> Date: Thu, 27 Aug 2009 06:09:52 +0000 >> >> >> I'm testing a fix for the VM right now actually. >> Once that works I'll look into the Unresolve problem further. I put in some printing to help diagnose it and possibly a fix. It could be a slash mixup; the printing will tell us. >> The VBT problem is new seeming. I'll look at that too. >> Anyone else is welcome to also. >> >> - Jay >> >> >> ---------------------------------------- >>> Date: Thu, 27 Aug 2009 08:06:57 +0200 >>> From: wagner at elegosoft.com >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com >>> Subject: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems >>> >>> Quoting Jay K : >>> >>>> Something or some things very wierd here. I'll keep looking into it. >>> I'm not sure if we should spend/waste(?) more time in trying to make >>> this VM with Windows work. >>> >>> Last night I reactivated my own qemu-based VM and was able to checkout >>> and build some current CM3 stuff. >>> >>> CVS behaves correctly there, and no need to adapt any of the shell >>> scripts at all. It's agonizingly slow though. And it has no remote >>> access. >>> >>> However, building the release archives failed with two errors: >>> >>> vbtkit: >>> new source -> compiling VBTKitResources.m3 >>> "..\src\lego\VBTKitResources.m3", line 10: unable to find interface >>> (VBTKitBundle) >>> 1 error encountered >>> >>> and >>> >>> errors during build-all; some packages will be missing >>> m3-win/import-libs/NT386/.M3SHIP seems to be broken: >>> make_dir("c:/tmp/cm3/lib") >>> install_file("wsock32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("advapi32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("opengl32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("netapi32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("comctl32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("user32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("comdlg32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("kernel32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("winspool.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("glu32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("gdi32.lib", "c:/tmp/cm3/lib", "0775") >>> install_file("odbc32.lib", "c:/tmp/cm3/lib", "0775") >>> >>> (wrong shippind destination, already reported) >>> >>> I suggest we rather concentrate on these and build the Windows >>> packages manually. >>> >>> I'm off to (paid) work again now... >>> >>> Olaf >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >>> From wagner at elegosoft.com Fri Aug 28 09:45:53 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 28 Aug 2009 09:45:53 +0200 Subject: [M3devel] CM3 on windows In-Reply-To: References: <20090828020144.B5E7C1A209A@async.async.caltech.edu> Message-ID: <20090828094553.hbdkyxsi8ss84oos@mail.elegosoft.com> I don't think Juno and mentor ever worked without an X server. The Trestle implementation on Windows was never complete nor stable enough for that AFAIK. Using the X implementation and an X server on Windows should work though (but I haven't tried that for years with M3). Of course it would be great if somebody took care to fix the Trestle ui package for Windows. Others please contradict me if I'm out of date here. Olaf Quoting Jay K : > > I fixed the access on 5.8.2. > Try that? > I can poke around.. > > As I recall 5.8.1 used VC 8.0 and 5.8.2 used 9.0. > If that helps. > > - Jay > > > ---------------------------------------- >> To: m3devel at elegosoft.com; jay.krell at cornell.edu >> CC: mika at async.caltech.edu >> Subject: CM3 on windows >> Date: Thu, 27 Aug 2009 19:01:44 -0700 >> From: mika at async.async.caltech.edu >> >> Hi m3devel, >> >> Not sure if my earlier message today went anywhere. I never saw it on >> the list. >> >> I'd like to try running CM3 on Windows 2000, so I've downloaded >> >> http://www.opencm3.com/uploaded-archives/cm3-std-NT386-d5.8.1.msi >> >> (5.8.2 didn't work---no access). >> >> Having installed it as well as I can figure, following the directions at >> >> http://www.opencm3.com/installation-windows.html >> >> I don't really seem to get all the way. Compiling in the CMD window fails >> at a link (can't find winspool.lib), and the binaries have problems. >> >> Funnily enough, WebScape seems to work (as well or poorly as anywhere else), >> but mentor and Juno both fail miserably: >> >> >> mika at scruff /cygdrive/c/cm3/bin >> $ ./mentor >> >> >> *** >> *** runtime error: >> *** Attempt to reference an illegal memory location. >> *** pc = 0x1061634 = GetAttributes + 0x179 in >> ..\src\lego\WIN32\ScrollerVBTCl >> ass.m3 >> *** >> >> Stack trace: >> FP PC Procedure >> --------- --------- ------------------------------- >> 0x30af668 0x6a6e4d SystemError + 0x66 in ..\src\runtime\NT386\RTSignal.m3 >> 0x30af70c 0x1061634 GetAttributes + 0x179 in >> ..\src\lego\WIN32\ScrollerVBTClas >> s.m3 >> 0x30af7e4 0x10993d8 AddView + 0x101e(!) in ..\src\lego\ViewportVBT.m3 >> 0x30af830 0x109743e Init + 0x30e in ..\src\lego\ViewportVBT.m3 >> 0x30af950 0x1004ee0 pViewport + 0x512 in ..\src\FormsVBT.m3 >> 0x30af9b0 0xff33df Item + 0x48b in ..\src\FormsVBT.m3 >> 0x30af9dc 0x1010f66 OneChild + 0xf8 in ..\src\FormsVBT.m3 >> 0x30afae4 0xff7448 pShape + 0x19c in ..\src\FormsVBT.m3 >> 0x30afb44 0xff33df Item + 0x48b in ..\src\FormsVBT.m3 >> 0x30afb70 0x1010f66 OneChild + 0xf8 in ..\src\FormsVBT.m3 >> ......... ......... ... more frames ... >> >> mika at scruff /cygdrive/c/cm3/bin >> $ ./Juno >> >> >> *** >> *** runtime error: >> *** failed. >> *** file "..\src\winvbt\WinContext.m3", line 165 >> *** >> >> Stack trace: >> FP PC Procedure >> --------- --------- ------------------------------- >> 0x1b6f854 0xea1e03 PushPixmap + 0x4cb in ..\src\winvbt\WinContext.m3 >> 0x1b6f91c 0xeb10c7 PixmapCom + 0x9ed in ..\src\winvbt\WinPaint.m3 >> 0x1b6fd78 0xeaedaf PaintBatch + 0x25f in ..\src\winvbt\WinPaint.m3 >> 0x1b6fde4 0xea91f3 PaintBatchVBT + 0x13f in ..\src\winvbt\WinTrestle.m3 >> 0x1b6fe2c 0xea7919 WindowProc + 0x763 in ..\src\winvbt\WinTrestle.m3 >> 0x1b6fe4c 0x77e3a454 >> 0x1b6fed8 0x77e14605 >> 0x1b6ff30 0x77e15b77 >> 0x1b6ff88 0x4fb015 RunThread + 0x234 in ..\src\thread\WIN32\ThreadWin32.m3 >> 0x1b6ffb4 0x4fad57 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3 >> ......... ......... ... more frames ... >> >> mika at scruff /cygdrive/c/cm3/bin >> $ >> >> This is running from the cygwin shell but it doesn't do anything different >> from CMD... >> >> Should I not expect to be able to get this to work? >> >> Mika -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Fri Aug 28 10:09:03 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 28 Aug 2009 10:09:03 +0200 Subject: [M3devel] strange code in scripts In-Reply-To: References: Message-ID: <20090828100903.7lsknqfqt5w0csk4@mail.elegosoft.com> I assume you're talking about make-bin-dist-min.sh. Quoting Jay K : > This sequence is odd: > > [ ${TARGET} != NT386 ] && "${ROOT}/scripts/do-pkg.sh" buildship > echo "${ROOT}/scripts/do-cm3-${DIST}.sh" buildlocal > "${ROOT}/scripts/do-cm3-${DIST}.sh" buildlocal || exit 1 > > header "stage 4: installing libraries using new cm3 compiler" > echo "${ROOT}/scripts/do-cm3-${DIST}.sh" buildglobal > "${ROOT}/scripts/do-cm3-${DIST}.sh" buildglobal || exit 1 > > The first line doesn't do anything. > In the logs you can see it just says "no packages". Have a look at http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/scripts/make-bin-dist-min.sh?annotate=1.42.2.5 This line is from Tony with the following comment: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/scripts/make-bin-dist-min.sh#rev1.24 It should be completely removed. > I don't understand why buildlocal + buildglobal. This is (a) a reasonable precaution, as building local will test everything before shipping it, and (b) it will show us if both building against the workspace and against the global package pool succeeds. Missing/wrong overrides have often enough broken the released packages. > Is that, um, to delete the .M3OVERRIDES files, so that "On the other side", > ship won't refuse? Of course, if we'd only build with overrides we couldn't ship anything. The second run will mostly just change the .M3SHIP files (and relink some programs, because M3 is usually not smart enough to avoid that -- but the discussion about dynamic linking has shown that that can be viewed as a feature :-). Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Fri Aug 28 10:15:11 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 28 Aug 2009 10:15:11 +0200 Subject: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems In-Reply-To: References: <20090826142644.r6yabwff5wc84cgg@mail.elegosoft.com> <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> Message-ID: <20090828101511.zsm14bsqow0k4w8o@mail.elegosoft.com> Quoting Jay K : > It was backslashes vs. forward slashes as I had originally suspected. > My debugprinting never hit because I was guessing the elego paths wrong. > I finally made it always print and tested it in-situ in the VM. So we now have Windows packages on birch for RC3? No, not yet. But I see that makedist is currently running... I think we should do something about this pathname confusion on Windows. See separate mail. Olaf > > - Jay > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] RC3 build problems, was: RE: caltech-parser >> NT386 Hudson problems >> Date: Thu, 27 Aug 2009 12:15:14 +0000 >> >> >> My current theory is the unresolve problem is due to that wierd >> initial build of import-libs in the Hudson task, which was related >> to the line endings problem, which was related to using CVSNT >> instead of Cygwin cvs. >> >> - Jay >> >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: wagner at elegosoft.com >>> CC: m3devel at elegosoft.com >>> Subject: RE: [M3devel] RC3 build problems, was: RE: caltech-parser >>> NT386 Hudson problems >>> Date: Thu, 27 Aug 2009 06:09:52 +0000 >>> >>> >>> I'm testing a fix for the VM right now actually. >>> Once that works I'll look into the Unresolve problem further. I >>> put in some printing to help diagnose it and possibly a fix. It >>> could be a slash mixup; the printing will tell us. >>> The VBT problem is new seeming. I'll look at that too. >>> Anyone else is welcome to also. >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> Date: Thu, 27 Aug 2009 08:06:57 +0200 >>>> From: wagner at elegosoft.com >>>> To: jay.krell at cornell.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: [M3devel] RC3 build problems, was: RE: caltech-parser >>>> NT386 Hudson problems >>>> >>>> Quoting Jay K : >>>> >>>>> Something or some things very wierd here. I'll keep looking into it. >>>> I'm not sure if we should spend/waste(?) more time in trying to make >>>> this VM with Windows work. >>>> >>>> Last night I reactivated my own qemu-based VM and was able to checkout >>>> and build some current CM3 stuff. >>>> >>>> CVS behaves correctly there, and no need to adapt any of the shell >>>> scripts at all. It's agonizingly slow though. And it has no remote >>>> access. >>>> >>>> However, building the release archives failed with two errors: >>>> >>>> vbtkit: >>>> new source -> compiling VBTKitResources.m3 >>>> "..\src\lego\VBTKitResources.m3", line 10: unable to find interface >>>> (VBTKitBundle) >>>> 1 error encountered >>>> >>>> and >>>> >>>> errors during build-all; some packages will be missing >>>> m3-win/import-libs/NT386/.M3SHIP seems to be broken: >>>> make_dir("c:/tmp/cm3/lib") >>>> install_file("wsock32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("advapi32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("opengl32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("netapi32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("comctl32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("user32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("comdlg32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("kernel32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("winspool.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("glu32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("gdi32.lib", "c:/tmp/cm3/lib", "0775") >>>> install_file("odbc32.lib", "c:/tmp/cm3/lib", "0775") >>>> >>>> (wrong shippind destination, already reported) >>>> >>>> I suggest we rather concentrate on these and build the Windows >>>> packages manually. >>>> >>>> I'm off to (paid) work again now... >>>> >>>> Olaf >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>> DE163214194 >>>> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Fri Aug 28 10:26:35 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 28 Aug 2009 10:26:35 +0200 Subject: [M3devel] Change Pathname abstraction for Windows? was: RE: RC3 build problems, was: RE: caltech-parser NT386 Hudson problems In-Reply-To: References: <20090826142644.r6yabwff5wc84cgg@mail.elegosoft.com> <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> Message-ID: <20090828102635.0iyxllukro8o44o4@mail.elegosoft.com> Quoting Jay K : > It was backslashes vs. forward slashes as I had originally suspected. > My debugprinting never hit because I was guessing the elego paths wrong. > I finally made it always print and tested it in-situ in the VM. It is amazing how much (pointless) work the difference in pathname denotations on Windows and POSIX systems has caused and still causes. While there are some conceptual differences that cannot easily be generalized (one root <-> many roots, logical <-> physical view of disks etc.), the simple fact that Windows uses \ instead of / makes life needlessly difficult for many programmers. In Modula-3, the Pathname interface is intended to abstract from this, but this works only to a certain degree. It uses \ as the arc separator on Windows, while in fact all modern Windows systems accept both \ and /. I think this should be corrected. Pathnames should be split into elements at both \ and / on Windows, and checks for equality should ignore any differences in separator characters only. Does this sound reasonable? Is there any (non)obvious problem I'm overseeing right now which will make this strategy fail? Olaf PS: I'm not suggesting we do that in this release of course... -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Fri Aug 28 11:11:50 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 28 Aug 2009 05:11:50 -0400 Subject: [M3devel] small design problem in ButtonVBT? In-Reply-To: <36DAB001-70F3-4C96-B1D5-57E8A7322464@cs.purdue.edu> References: <20090331145127.GB9624@topoi.pooq.com> <20090401120347.x8cneize8oscg44o@mail.elegosoft.com> <20090826002606.GB16386@topoi.pooq.com> <20090827141741.9g1u2vrgfgokkksg@mail.elegosoft.com> <20090828031722.GB22883@topoi.pooq.com> <36DAB001-70F3-4C96-B1D5-57E8A7322464@cs.purdue.edu> Message-ID: <20090828091150.GA23396@topoi.pooq.com> On Thu, Aug 27, 2009 at 11:53:27PM -0400, Tony Hosking wrote: > Right. Plus, overriding copies the entire method suite for the new > type. Now that makes sense. I'll re-evaluate my suggestion in this light. > > On 27 Aug 2009, at 23:28, Jay K wrote: > > > > >I think I know the reason it is this way. > >It is very common to override action and nothing else. > >It is "inconvenient" to derive a new type, just to change one > >function. It's more a matter of letting the action procedure or method have clean access to application data in the subclassed function. But your code suggests a simpler way to do this than either your code or mine. It takes a run-time type check, which is conceptually messy. But the code is smaller, and seems to have a smaller memory footprint. See below. > > > >- Jay > > > >---------------------------------------- > >>Date: Thu, 27 Aug 2009 23:17:23 -0400 > >>From: hendrik at topoi.pooq.com > >>To: m3devel at elegosoft.com > >>Subject: Re: [M3devel] small design problem in ButtonVBT? > >> > >>On Thu, Aug 27, 2009 at 03:15:41PM -0400, Tony Hosking wrote: > >>>I am nervous about having the two alternative entries to the action > >>>procedure that other code might not be aware of. Yes, you've > >>>modified > >>>the default mouse method to call the action method instead of the > >>>procedure, but what about other places where the mouse method has > >>>been > >>>overridden. Yes. That could be an issue. But only if act is also overridden, which won't happen in legacy code, since the defauly act behaves identically to the action procedure. > >>> > >>>If you want to be smart about it in your own code you can simply > >>>invert your suggestion and do the following: > >>> > >>>TYPE T = ButtonVBT.T OBJECT > >>>METHODS action(cd: VBT.MouseRec) := Action; > >>> > >>>PROCEDURE Action(v: T; cd: VBT.MouseRec) = ... > >>> > >>>PROCEDURE ActionProc(v: ButtonVBT.T; cd: VBT.MouseRec) = > >>>BEGIN > >>>NARROW(v, T).action(cd); > >>>END ActionProc; > >>> > >>>and initialize your T thingy with ButtonVBT.New(..., action := > >>>ActionProc; ...) > >>> > >>>Then in your code you can go ahead and override the action method to > >>>your hearts content. But I can simplify this further. TYPE T = ButtonVBT.T OBJECT (* as you propose. *) For each action that I had wanted a subclass for, write PROCEDURE Action(vv: T; cd: VBT.MouseRec) = ... VAR v : T; BEGIN v := NARROW(vv, T); ... normal code for performing the action END Action; and initialize my T thingy using this Action. So instead of multiple subclasses to get the various actions, I get two extra lines of code in each action procedure. And I don't have to use GetProp or PutProp (which probably involve some kind of search). The run-time cost is the type-check in the NARROW(vv, T), which is probably cheaper than a method-dispatch on act. Hmmm. I'm starting to think you're right, and my change is unnecessary. I'll have a look in my applicatin code, and see if there are further glitches. I'm not expecting any. -- hendrik > >> > >>This kind of thing would work. But, like the existing semantics of > >>ButtonVBT, it seems to be fighting the language instead of working > >>with > >>it. I'd be happiest to get rid of the action variable altogether, but > >>that would be a massively incompatible change, and would require > >>change > >>to a lot of existing code. What I proposed is compatible with > >>existing > >>code, and also has the advantage that someone who subclasses > >>ButtonVBT.T > >>and overrides act can completely ignore the action variable > >>altogether. > >> > >>You say > >> > >>>and initialize your T thingy with ButtonVBT.New(..., action := > >>>ActionProc; ...) > >> > >>But that requires every object I make of type T or any sibclass to be > >>explicitly initialised with ActionProc, certainly a nuisance, and > >>certainly error-prone. > >> > >>The inelegance I see with my approach is that there are two > >>mechanisms > >>for specifying the action to be taken. Either will work without the > >>programmer paying any attention to the other, but if you use both, > >>one > >>will override the other. This is not a problem with legacy software. > >>I'll have to come up with some documentation that makes this clear. > >>It's the inelegance that comes from backward compatibility, and I > >>think > >>my solution is less inelegant, and easier to use, than yours. Yours, > >>however, involves no change in existing code. > >> > >>> > >>>Am I just being paranoid? > >> > >>No. Perhaps just paranoid about different things. > >> > >>I had hoped for someone to come up with a solid technical reason > >>for the > >>action variable. The original designers were clever people, and I'd > >>*still* like to know why they thought it was a good idea. It's > >>awkward > >>and error-prone to use, and they had to use the PutProp/GetProp > >>kludge > >>just to approximate what the language provided for free with > >>inheritance. > >> > >>I'm tempted to go over the entire code-base and change the buttons to > >>use act instead of action, but I have to admit I'm not tempted > >>enough to > >>actually do it... > >> > >>-- hendrik > >> > >>>On 27 Aug 2009, at 08:17, Olaf Wagner wrote: > >>> > >>>>Though I promised to do it, I have lost sight of this task while > >>>>trying to build some RC3 archives on Windows. As I'm not at home > >>>>this > >>>>evening, can somebody else please commit Hendrik's extension? > >>>> > >>>>Is this something we should should have in the release branch, too? > >>>>Probably not necessary? > >>>> > >>>>Olaf > >>>> > >>>>Quoting hendrik at topoi.pooq.com: > >>>> > >>>>>On Wed, Apr 01, 2009 at 12:03:47PM +0200, Olaf Wagner wrote: > >>>>>>Quoting hendrik at topoi.pooq.com: > >>>>>> > >>>>>>>The BottonVBT contains an action, which is a procedure rather > >>>>>>than a > >>>>>>>method. b This makes it awkward to subclass ButtonVBT becaue the > >>>>>>action > >>>>>>>will still expect its first parameter to be a ButtonVBT > >>>>>>>instead of > >>>>>>>belonging to the subclass, and an explicit downcast of some sort > >>>>>>will be > >>>>>>>needed to acess the subclass's members. > >>>>>>> > >>>>>>>The Trestle manual says this was a deliberate decision: > >>>>>>> > >>>>>>>: The action procedure is a field rather than a method in order > >>>>>>to allow > >>>>>>>: buttons with different action procedures to share their method > >>>>>>suites. > >>>>>>> > >>>>>>>I, however, find it massively inconvenient because it mans I > >>>>>>>have > >>>>>>to > >>>>>>>resort to downcasting or the very kludgey VBT.GetProp to access > >>>>>>what > >>>>>>>should be just there. I'd rather the action procedure was a > >>>>>>method. > >>>>>>> > >>>>>>>But it should be possible to have the best of both worlds. > >>>>>>>Have an > >>>>>>>action2 (better name wanted here) method that is available for > >>>>>>>overriding, and by default calls the procedure in the existing > >>>>>>action. > >>>>>>>field. That action2 method wounl then be called by Trestle > >>>>>>wherever > >>>>>>>action is now called. > >>>>>>> > >>>>>>>Does anyone see problems with this? > >>>>>> > >>>>>>Sounds fine to me offhand. You should test your extensions with > >>>>>>some of the existing larger applications, like mentor and Juno-2, > >>>>>>of course. > >>>>> > >>>>>OK. Here's the patch. Would it be possible for someone to check it > >>>>>in > >>>>>for me? > >>>>> > >>>>>mentor runs fine with this change; I watched it animate a heap- > >>>>>sort. > >>>>> > >>>>>I have no idea what Juno is supposed to do, but it did respond to > >>>>>button-pushes. > >>>>> > >>>>> > >>>>>hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ cvs diff > >>>>>cvs diff: Diffing . > >>>>>Index: ButtonVBT.i3 > >>>>>= > >>>>>================================================================== > >>>>>RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.i3,v > >>>>>retrieving revision 1.2 > >>>>>diff -r1.2 ButtonVBT.i3 > >>>>>39a40 > >>>>>>act(READONLY cd: VBT.MouseRec); > >>>>>Index: ButtonVBT.m3 > >>>>>= > >>>>>================================================================== > >>>>>RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.m3,v > >>>>>retrieving revision 1.2 > >>>>>diff -r1.2 ButtonVBT.m3 > >>>>>28c28,29 > >>>>>< init := Be > >>>>>--- > >>>>>>init := Be; > >>>>>>act := act > >>>>>46a48,52 > >>>>>>PROCEDURE act(v : T; READONLY cd: VBT.MouseRec) = > >>>>>>BEGIN > >>>>>>v.action(v, cd); > >>>>>>END act; > >>>>>> > >>>>>59c65 > >>>>>< v.action(v, cd); > >>>>>--- > >>>>>>v.act(cd); > >>>>>hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ > >>>>> > >>>>>-- hendrik > >>>>> > >>>> > >>>> > >>>> > >>>>-- > >>>>Olaf Wagner -- elego Software Solutions GmbH > >>>>Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > >>>>Germany > >>>>phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > >>>>45 86 95 > >>>>http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > >>>>Berlin > >>>>Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > >>>>DE163214194 > >>>> > >>> > From hendrik at topoi.pooq.com Fri Aug 28 11:21:41 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 28 Aug 2009 05:21:41 -0400 Subject: [M3devel] CM3 on windows In-Reply-To: References: <20090828020144.B5E7C1A209A@async.async.caltech.edu> <20090828034057.475DD1A209A@async.async.caltech.edu> <20090828042715.B05E51A20A1@async.async.caltech.edu> <20090828045055.BA3C81A20A1@async.async.caltech.edu> Message-ID: <20090828092141.GB23396@topoi.pooq.com> On Fri, Aug 28, 2009 at 05:03:58AM +0000, Jay K wrote: > > Yes NT386GNU uses X. > Olaf expressed an interest in that. > Apparently the Windows port of Trestle has never been completed. > (I suspect we should punt Trestle and bind to Qt, but that is another > matter.) I've been wondering about that point with one of my applications -- Does Trestle have access to the underlying OS's fonts, or does it provide its own. I'm specifically thinking of the huge Unicode fonts, and suspect that Trestle doesn't has neither its own nor access to the OS's, on either Unix or WIndows. I happened to be wondering about gtk instead of qt, but that's a detail. Are there reasons I should be aware of for preferring one to the other? Portability or other? -- hendrik From jay.krell at cornell.edu Fri Aug 28 12:32:34 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Fri, 28 Aug 2009 06:32:34 -0400 Subject: [M3devel] CM3 on windows In-Reply-To: <20090828094553.hbdkyxsi8ss84oos@mail.elegosoft.com> References: <20090828020144.B5E7C1A209A@async.async.caltech.edu> <20090828094553.hbdkyxsi8ss84oos@mail.elegosoft.com> Message-ID: I'll have to double check but I thought Juno and mentor both worked a bunch. automation to really put them through their paces welcome. :) - Jay (phone) On Aug 28, 2009, at 3:45 AM, Olaf Wagner wrote: > I don't think Juno and mentor ever worked without an X server. > The Trestle implementation on Windows was never complete nor > stable enough for that AFAIK. > > Using the X implementation and an X server on Windows should work > though (but I haven't tried that for years with M3). > > Of course it would be great if somebody took care to fix the > Trestle ui package for Windows. > > Others please contradict me if I'm out of date here. > > Olaf > > Quoting Jay K : > >> >> I fixed the access on 5.8.2. >> Try that? >> I can poke around.. >> >> As I recall 5.8.1 used VC 8.0 and 5.8.2 used 9.0. >> If that helps. >> >> - Jay >> >> >> ---------------------------------------- >>> To: m3devel at elegosoft.com; jay.krell at cornell.edu >>> CC: mika at async.caltech.edu >>> Subject: CM3 on windows >>> Date: Thu, 27 Aug 2009 19:01:44 -0700 >>> From: mika at async.async.caltech.edu >>> >>> Hi m3devel, >>> >>> Not sure if my earlier message today went anywhere. I never saw it >>> on >>> the list. >>> >>> I'd like to try running CM3 on Windows 2000, so I've downloaded >>> >>> http://www.opencm3.com/uploaded-archives/cm3-std-NT386-d5.8.1.msi >>> >>> (5.8.2 didn't work---no access). >>> >>> Having installed it as well as I can figure, following the >>> directions at >>> >>> http://www.opencm3.com/installation-windows.html >>> >>> I don't really seem to get all the way. Compiling in the CMD >>> window fails >>> at a link (can't find winspool.lib), and the binaries have problems. >>> >>> Funnily enough, WebScape seems to work (as well or poorly as >>> anywhere else), >>> but mentor and Juno both fail miserably: >>> >>> >>> mika at scruff /cygdrive/c/cm3/bin >>> $ ./mentor >>> >>> >>> *** >>> *** runtime error: >>> *** Attempt to reference an illegal memory location. >>> *** pc = 0x1061634 = GetAttributes + 0x179 in ..\src\lego >>> \WIN32\ScrollerVBTCl >>> ass.m3 >>> *** >>> >>> Stack trace: >>> FP PC Procedure >>> --------- --------- ------------------------------- >>> 0x30af668 0x6a6e4d SystemError + 0x66 in ..\src\runtime >>> \NT386\RTSignal.m3 >>> 0x30af70c 0x1061634 GetAttributes + 0x179 in ..\src\lego >>> \WIN32\ScrollerVBTClas >>> s.m3 >>> 0x30af7e4 0x10993d8 AddView + 0x101e(!) in ..\src\lego >>> \ViewportVBT.m3 >>> 0x30af830 0x109743e Init + 0x30e in ..\src\lego\ViewportVBT.m3 >>> 0x30af950 0x1004ee0 pViewport + 0x512 in ..\src\FormsVBT.m3 >>> 0x30af9b0 0xff33df Item + 0x48b in ..\src\FormsVBT.m3 >>> 0x30af9dc 0x1010f66 OneChild + 0xf8 in ..\src\FormsVBT.m3 >>> 0x30afae4 0xff7448 pShape + 0x19c in ..\src\FormsVBT.m3 >>> 0x30afb44 0xff33df Item + 0x48b in ..\src\FormsVBT.m3 >>> 0x30afb70 0x1010f66 OneChild + 0xf8 in ..\src\FormsVBT.m3 >>> ......... ......... ... more frames ... >>> >>> mika at scruff /cygdrive/c/cm3/bin >>> $ ./Juno >>> >>> >>> *** >>> *** runtime error: >>> *** failed. >>> *** file "..\src\winvbt\WinContext.m3", line 165 >>> *** >>> >>> Stack trace: >>> FP PC Procedure >>> --------- --------- ------------------------------- >>> 0x1b6f854 0xea1e03 PushPixmap + 0x4cb in ..\src\winvbt\WinContext.m3 >>> 0x1b6f91c 0xeb10c7 PixmapCom + 0x9ed in ..\src\winvbt\WinPaint.m3 >>> 0x1b6fd78 0xeaedaf PaintBatch + 0x25f in ..\src\winvbt\WinPaint.m3 >>> 0x1b6fde4 0xea91f3 PaintBatchVBT + 0x13f in ..\src\winvbt >>> \WinTrestle.m3 >>> 0x1b6fe2c 0xea7919 WindowProc + 0x763 in ..\src\winvbt\WinTrestle.m3 >>> 0x1b6fe4c 0x77e3a454 >>> 0x1b6fed8 0x77e14605 >>> 0x1b6ff30 0x77e15b77 >>> 0x1b6ff88 0x4fb015 RunThread + 0x234 in ..\src\thread >>> \WIN32\ThreadWin32.m3 >>> 0x1b6ffb4 0x4fad57 ThreadBase + 0x3a in ..\src\thread >>> \WIN32\ThreadWin32.m3 >>> ......... ......... ... more frames ... >>> >>> mika at scruff /cygdrive/c/cm3/bin >>> $ >>> >>> This is running from the cygwin shell but it doesn't do anything >>> different >>> from CMD... >>> >>> Should I not expect to be able to get this to work? >>> >>> Mika > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ > any > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be > rlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > From jay.krell at cornell.edu Fri Aug 28 13:11:07 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Fri, 28 Aug 2009 07:11:07 -0400 Subject: [M3devel] RC3 build problems, was: RE: caltech-parser NT386 Hudson problems In-Reply-To: <20090828101511.zsm14bsqow0k4w8o@mail.elegosoft.com> References: <20090826142644.r6yabwff5wc84cgg@mail.elegosoft.com> <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> <20090828101511.zsm14bsqow0k4w8o@mail.elegosoft.com> Message-ID: Olaf wrote: > > So we now have Windows packages on birch for RC3? No, not yet. > But I see that makedist is currently running... Seems like it got further and then the node disappeared and hasn't reappeared. :( - Jay (phone) From wagner at elegosoft.com Fri Aug 28 13:58:01 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 28 Aug 2009 13:58:01 +0200 Subject: [M3devel] CM3 on windows In-Reply-To: References: <20090828020144.B5E7C1A209A@async.async.caltech.edu> <20090828094553.hbdkyxsi8ss84oos@mail.elegosoft.com> Message-ID: <20090828135801.rja2kahis8wo8ocg@mail.elegosoft.com> Quoting jay.krell at cornell.edu: > I'll have to double check but I thought Juno and mentor both worked a > bunch. automation to really put them through their paces welcome. :) We don't have any support for testing GUI applications currently. I doubt that it will appear soon ;-) Olaf > - Jay (phone) > > On Aug 28, 2009, at 3:45 AM, Olaf Wagner wrote: > >> I don't think Juno and mentor ever worked without an X server. >> The Trestle implementation on Windows was never complete nor >> stable enough for that AFAIK. >> >> Using the X implementation and an X server on Windows should work >> though (but I haven't tried that for years with M3). >> >> Of course it would be great if somebody took care to fix the >> Trestle ui package for Windows. >> >> Others please contradict me if I'm out of date here. >> >> Olaf >> >> Quoting Jay K : >> >>> >>> I fixed the access on 5.8.2. >>> Try that? >>> I can poke around.. >>> >>> As I recall 5.8.1 used VC 8.0 and 5.8.2 used 9.0. >>> If that helps. >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> To: m3devel at elegosoft.com; jay.krell at cornell.edu >>>> CC: mika at async.caltech.edu >>>> Subject: CM3 on windows >>>> Date: Thu, 27 Aug 2009 19:01:44 -0700 >>>> From: mika at async.async.caltech.edu >>>> >>>> Hi m3devel, >>>> >>>> Not sure if my earlier message today went anywhere. I never saw it on >>>> the list. >>>> >>>> I'd like to try running CM3 on Windows 2000, so I've downloaded >>>> >>>> http://www.opencm3.com/uploaded-archives/cm3-std-NT386-d5.8.1.msi >>>> >>>> (5.8.2 didn't work---no access). >>>> >>>> Having installed it as well as I can figure, following the directions at >>>> >>>> http://www.opencm3.com/installation-windows.html >>>> >>>> I don't really seem to get all the way. Compiling in the CMD window fails >>>> at a link (can't find winspool.lib), and the binaries have problems. >>>> >>>> Funnily enough, WebScape seems to work (as well or poorly as >>>> anywhere else), >>>> but mentor and Juno both fail miserably: >>>> >>>> >>>> mika at scruff /cygdrive/c/cm3/bin >>>> $ ./mentor >>>> >>>> >>>> *** >>>> *** runtime error: >>>> *** Attempt to reference an illegal memory location. >>>> *** pc = 0x1061634 = GetAttributes + 0x179 in >>>> ..\src\lego\WIN32\ScrollerVBTCl >>>> ass.m3 >>>> *** >>>> >>>> Stack trace: >>>> FP PC Procedure >>>> --------- --------- ------------------------------- >>>> 0x30af668 0x6a6e4d SystemError + 0x66 in ..\src\runtime\NT386\RTSignal.m3 >>>> 0x30af70c 0x1061634 GetAttributes + 0x179 in >>>> ..\src\lego\WIN32\ScrollerVBTClas >>>> s.m3 >>>> 0x30af7e4 0x10993d8 AddView + 0x101e(!) in ..\src\lego\ViewportVBT.m3 >>>> 0x30af830 0x109743e Init + 0x30e in ..\src\lego\ViewportVBT.m3 >>>> 0x30af950 0x1004ee0 pViewport + 0x512 in ..\src\FormsVBT.m3 >>>> 0x30af9b0 0xff33df Item + 0x48b in ..\src\FormsVBT.m3 >>>> 0x30af9dc 0x1010f66 OneChild + 0xf8 in ..\src\FormsVBT.m3 >>>> 0x30afae4 0xff7448 pShape + 0x19c in ..\src\FormsVBT.m3 >>>> 0x30afb44 0xff33df Item + 0x48b in ..\src\FormsVBT.m3 >>>> 0x30afb70 0x1010f66 OneChild + 0xf8 in ..\src\FormsVBT.m3 >>>> ......... ......... ... more frames ... >>>> >>>> mika at scruff /cygdrive/c/cm3/bin >>>> $ ./Juno >>>> >>>> >>>> *** >>>> *** runtime error: >>>> *** failed. >>>> *** file "..\src\winvbt\WinContext.m3", line 165 >>>> *** >>>> >>>> Stack trace: >>>> FP PC Procedure >>>> --------- --------- ------------------------------- >>>> 0x1b6f854 0xea1e03 PushPixmap + 0x4cb in ..\src\winvbt\WinContext.m3 >>>> 0x1b6f91c 0xeb10c7 PixmapCom + 0x9ed in ..\src\winvbt\WinPaint.m3 >>>> 0x1b6fd78 0xeaedaf PaintBatch + 0x25f in ..\src\winvbt\WinPaint.m3 >>>> 0x1b6fde4 0xea91f3 PaintBatchVBT + 0x13f in ..\src\winvbt\WinTrestle.m3 >>>> 0x1b6fe2c 0xea7919 WindowProc + 0x763 in ..\src\winvbt\WinTrestle.m3 >>>> 0x1b6fe4c 0x77e3a454 >>>> 0x1b6fed8 0x77e14605 >>>> 0x1b6ff30 0x77e15b77 >>>> 0x1b6ff88 0x4fb015 RunThread + 0x234 in ..\src\thread\WIN32\ThreadWin32.m3 >>>> 0x1b6ffb4 0x4fad57 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3 >>>> ......... ......... ... more frames ... >>>> >>>> mika at scruff /cygdrive/c/cm3/bin >>>> $ >>>> >>>> This is running from the cygwin shell but it doesn't do anything different >>>> from CMD... >>>> >>>> Should I not expect to be able to get this to work? >>>> >>>> Mika >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Fri Aug 28 14:06:40 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 28 Aug 2009 14:06:40 +0200 Subject: [M3devel] elego-win-vm unreachable again Message-ID: <20090828140640.krinzx4ls0wco08w@mail.elegosoft.com> Hi Kay, why does the route/tunnel to elego-win-vm keep vanishing? There have been no reboots? [08/28/09 13:46:54] Launching slave agent $ ssh -p 2222 elego at localhost2 "java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=29999 -jar c:\cygwin\home\elego\slave.jar -text" ssh: connect to host localhost2 port 2222: Connection refused Unable to launch the slave agent for elego-win-vm java.io.EOFException: unexpected stream termination at hudson.remoting.Channel.(Channel.java:313) at hudson.remoting.Channel.(Channel.java:252) at hudson.slaves.SlaveComputer.setChannel(SlaveComputer.java:283) at hudson.slaves.CommandLauncher.launch(CommandLauncher.java:111) at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:175) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:619) Please check and install a watch script which rebuilds the tunnel when necessary. TIA, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Aug 28 12:30:20 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Fri, 28 Aug 2009 06:30:20 -0400 Subject: [M3devel] CM3 on windows In-Reply-To: <20090828092141.GB23396@topoi.pooq.com> References: <20090828020144.B5E7C1A209A@async.async.caltech.edu> <20090828034057.475DD1A209A@async.async.caltech.edu> <20090828042715.B05E51A20A1@async.async.caltech.edu> <20090828045055.BA3C81A20A1@async.async.caltech.edu> <20090828092141.GB23396@topoi.pooq.com> Message-ID: <726E21C8-625B-4B2C-8089-2038B9930AB5@hotmail.com> Fonts I don't know. I don't think gtk folks care much about windows. Qt folks do. - Jay (phone) On Aug 28, 2009, at 5:21 AM, hendrik at topoi.pooq.com wrote: > On Fri, Aug 28, 2009 at 05:03:58AM +0000, Jay K wrote: >> >> Yes NT386GNU uses X. >> Olaf expressed an interest in that. >> Apparently the Windows port of Trestle has never been completed. >> (I suspect we should punt Trestle and bind to Qt, but that is another >> matter.) > > I've been wondering about that point with one of my applications -- > Does > Trestle have access to the underlying OS's fonts, or does it provide > its > own. I'm specifically thinking of the huge Unicode fonts, and suspect > that Trestle doesn't has neither its own nor access to the OS's, on > either Unix or WIndows. > > I happened to be wondering about gtk instead of qt, but that's a > detail. > Are there reasons I should be aware of for preferring one to the > other? > Portability or other? > > -- hendrik > > From jay.krell at cornell.edu Fri Aug 28 13:33:45 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Fri, 28 Aug 2009 07:33:45 -0400 Subject: [M3devel] Change Pathname abstraction for Windows? was: RE: RC3 build problems, was: RE: caltech-parser NT386 Hudson problems In-Reply-To: <20090828102635.0iyxllukro8o44o4@mail.elegosoft.com> References: <20090826142644.r6yabwff5wc84cgg@mail.elegosoft.com> <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> <20090828102635.0iyxllukro8o44o4@mail.elegosoft.com> Message-ID: <17E1903E-EA50-4EF3-8273-C55B0FE1952C@hotmail.com> I believe this goes back to CP/M compatibility. I wish the file open dialogs accepted forward slashes. :( I will change cm3 to write back into quake state the canonicalized forms. I believe I already changed Pathname on Windows to accept either slash. I need to check if equality uses decomposed elements. Lots of folks just use strings and skip the abstraction, such as cm3. My personal programming often uses a small library over strings -- GetLastPathElement, RemoveLastElement, JoinPath, EnsureTrailingPathSeparator, ... IMHO you might as well also have posix allow backward slashes as separators, but that was rejected here. To wit I believe cygwin now accepts colons and backward slashes in paths, as non-separators. Interix also one or the other or both. Interix encodes them by oring in 0xFF00 (what happens with Samba to ext3??) There are other issues such as case sensivity not being an OS-wide thing but per volume or directory (NTFS has mount points, directories can lead to volumes, with different filesystems) as well as just what the case mapping tables are (written to NTFS volume at time of format, presumably can vary). The Mac historically used colon as separator and allowed forward slash as non separator. Presumably hidden through some encoding/decoding at the posix layer? - Jay (phone) On Aug 28, 2009, at 4:26 AM, Olaf Wagner wrote: > Quoting Jay K : > >> It was backslashes vs. forward slashes as I had originally suspected. >> My debugprinting never hit because I was guessing the elego paths >> wrong. >> I finally made it always print and tested it in-situ in the VM. > > It is amazing how much (pointless) work the difference in pathname > denotations on Windows and POSIX systems has caused and still causes. > While there are some conceptual differences that cannot easily be > generalized (one root <-> many roots, logical <-> physical view of > disks etc.), the simple fact that Windows uses \ instead of / > makes life needlessly difficult for many programmers. > > In Modula-3, the Pathname interface is intended to abstract from > this, but this works only to a certain degree. It uses \ as the > arc separator on Windows, while in fact all modern Windows systems > accept both \ and /. I think this should be corrected. > > Pathnames should be split into elements at both \ and / on Windows, > and checks for equality should ignore any differences in separator > characters only. Does this sound reasonable? > > Is there any (non)obvious problem I'm overseeing right now which > will make this strategy fail? > > Olaf > > PS: I'm not suggesting we do that in this release of course... > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ > any > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be > rlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > From hosking at cs.purdue.edu Fri Aug 28 15:44:14 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 28 Aug 2009 09:44:14 -0400 Subject: [M3devel] small design problem in ButtonVBT? In-Reply-To: <20090828091150.GA23396@topoi.pooq.com> References: <20090331145127.GB9624@topoi.pooq.com> <20090401120347.x8cneize8oscg44o@mail.elegosoft.com> <20090826002606.GB16386@topoi.pooq.com> <20090827141741.9g1u2vrgfgokkksg@mail.elegosoft.com> <20090828031722.GB22883@topoi.pooq.com> <36DAB001-70F3-4C96-B1D5-57E8A7322464@cs.purdue.edu> <20090828091150.GA23396@topoi.pooq.com> Message-ID: <570C6C84-C41D-446E-A43C-13F85F1C378C@cs.purdue.edu> Yes, exactly! I don't think the change is needed and goes against the grain of a pervasive design principle. We might question that decision, but I hesitate to apply a piecemeal tweak that violates the principle. On 28 Aug 2009, at 05:11, hendrik at topoi.pooq.com wrote: > On Thu, Aug 27, 2009 at 11:53:27PM -0400, Tony Hosking wrote: >> Right. Plus, overriding copies the entire method suite for the new >> type. > > Now that makes sense. I'll re-evaluate my suggestion in this light. > >> >> On 27 Aug 2009, at 23:28, Jay K wrote: >> >>> >>> I think I know the reason it is this way. >>> It is very common to override action and nothing else. >>> It is "inconvenient" to derive a new type, just to change one >>> function. > > It's more a matter of letting the action procedure or method have > clean > access to application data in the subclassed function. But your code > suggests a simpler way to do this than either your code or mine. It > takes a run-time type check, which is conceptually messy. But the > code > is smaller, and seems to have a smaller memory footprint. > > See below. > >>> >>> - Jay >>> >>> ---------------------------------------- >>>> Date: Thu, 27 Aug 2009 23:17:23 -0400 >>>> From: hendrik at topoi.pooq.com >>>> To: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] small design problem in ButtonVBT? >>>> >>>> On Thu, Aug 27, 2009 at 03:15:41PM -0400, Tony Hosking wrote: >>>>> I am nervous about having the two alternative entries to the >>>>> action >>>>> procedure that other code might not be aware of. Yes, you've >>>>> modified >>>>> the default mouse method to call the action method instead of the >>>>> procedure, but what about other places where the mouse method has >>>>> been >>>>> overridden. > > Yes. That could be an issue. But only if act is also overridden, > which > won't happen in legacy code, since the defauly act behaves identically > to the action procedure. > >>>>> >>>>> If you want to be smart about it in your own code you can simply >>>>> invert your suggestion and do the following: >>>>> >>>>> TYPE T = ButtonVBT.T OBJECT >>>>> METHODS action(cd: VBT.MouseRec) := Action; >>>>> >>>>> PROCEDURE Action(v: T; cd: VBT.MouseRec) = ... >>>>> >>>>> PROCEDURE ActionProc(v: ButtonVBT.T; cd: VBT.MouseRec) = >>>>> BEGIN >>>>> NARROW(v, T).action(cd); >>>>> END ActionProc; >>>>> >>>>> and initialize your T thingy with ButtonVBT.New(..., action := >>>>> ActionProc; ...) >>>>> >>>>> Then in your code you can go ahead and override the action >>>>> method to >>>>> your hearts content. > > But I can simplify this further. > > TYPE T = ButtonVBT.T OBJECT (* as you propose. *) > > For each action that I had wanted a subclass for, write > > PROCEDURE Action(vv: T; cd: VBT.MouseRec) = ... > VAR v : T; > BEGIN > v := NARROW(vv, T); > ... normal code for performing the action > END Action; > > and initialize my T thingy using this Action. > > So instead of multiple subclasses to get the various actions, I get > two > extra lines of code in each action procedure. And I don't have to use > GetProp or PutProp (which probably involve some kind of search). The > run-time cost is the type-check in the NARROW(vv, T), which is > probably > cheaper than a method-dispatch on act. > > Hmmm. I'm starting to think you're right, and my change is > unnecessary. > > I'll have a look in my applicatin code, and see if there are further > glitches. I'm not expecting any. > > -- hendrik > >>>> >>>> This kind of thing would work. But, like the existing semantics of >>>> ButtonVBT, it seems to be fighting the language instead of working >>>> with >>>> it. I'd be happiest to get rid of the action variable altogether, >>>> but >>>> that would be a massively incompatible change, and would require >>>> change >>>> to a lot of existing code. What I proposed is compatible with >>>> existing >>>> code, and also has the advantage that someone who subclasses >>>> ButtonVBT.T >>>> and overrides act can completely ignore the action variable >>>> altogether. >>>> >>>> You say >>>> >>>>> and initialize your T thingy with ButtonVBT.New(..., action := >>>>> ActionProc; ...) >>>> >>>> But that requires every object I make of type T or any sibclass >>>> to be >>>> explicitly initialised with ActionProc, certainly a nuisance, and >>>> certainly error-prone. >>>> >>>> The inelegance I see with my approach is that there are two >>>> mechanisms >>>> for specifying the action to be taken. Either will work without the >>>> programmer paying any attention to the other, but if you use both, >>>> one >>>> will override the other. This is not a problem with legacy >>>> software. >>>> I'll have to come up with some documentation that makes this clear. >>>> It's the inelegance that comes from backward compatibility, and I >>>> think >>>> my solution is less inelegant, and easier to use, than yours. >>>> Yours, >>>> however, involves no change in existing code. >>>> >>>>> >>>>> Am I just being paranoid? >>>> >>>> No. Perhaps just paranoid about different things. >>>> >>>> I had hoped for someone to come up with a solid technical reason >>>> for the >>>> action variable. The original designers were clever people, and I'd >>>> *still* like to know why they thought it was a good idea. It's >>>> awkward >>>> and error-prone to use, and they had to use the PutProp/GetProp >>>> kludge >>>> just to approximate what the language provided for free with >>>> inheritance. >>>> >>>> I'm tempted to go over the entire code-base and change the >>>> buttons to >>>> use act instead of action, but I have to admit I'm not tempted >>>> enough to >>>> actually do it... >>>> >>>> -- hendrik >>>> >>>>> On 27 Aug 2009, at 08:17, Olaf Wagner wrote: >>>>> >>>>>> Though I promised to do it, I have lost sight of this task while >>>>>> trying to build some RC3 archives on Windows. As I'm not at home >>>>>> this >>>>>> evening, can somebody else please commit Hendrik's extension? >>>>>> >>>>>> Is this something we should should have in the release branch, >>>>>> too? >>>>>> Probably not necessary? >>>>>> >>>>>> Olaf >>>>>> >>>>>> Quoting hendrik at topoi.pooq.com: >>>>>> >>>>>>> On Wed, Apr 01, 2009 at 12:03:47PM +0200, Olaf Wagner wrote: >>>>>>>> Quoting hendrik at topoi.pooq.com: >>>>>>>> >>>>>>>>> The BottonVBT contains an action, which is a procedure rather >>>>>>>> than a >>>>>>>>> method. b This makes it awkward to subclass ButtonVBT becaue >>>>>>>>> the >>>>>>>> action >>>>>>>>> will still expect its first parameter to be a ButtonVBT >>>>>>>>> instead of >>>>>>>>> belonging to the subclass, and an explicit downcast of some >>>>>>>>> sort >>>>>>>> will be >>>>>>>>> needed to acess the subclass's members. >>>>>>>>> >>>>>>>>> The Trestle manual says this was a deliberate decision: >>>>>>>>> >>>>>>>>> : The action procedure is a field rather than a method in >>>>>>>>> order >>>>>>>> to allow >>>>>>>>> : buttons with different action procedures to share their >>>>>>>>> method >>>>>>>> suites. >>>>>>>>> >>>>>>>>> I, however, find it massively inconvenient because it mans I >>>>>>>>> have >>>>>>>> to >>>>>>>>> resort to downcasting or the very kludgey VBT.GetProp to >>>>>>>>> access >>>>>>>> what >>>>>>>>> should be just there. I'd rather the action procedure was a >>>>>>>> method. >>>>>>>>> >>>>>>>>> But it should be possible to have the best of both worlds. >>>>>>>>> Have an >>>>>>>>> action2 (better name wanted here) method that is available for >>>>>>>>> overriding, and by default calls the procedure in the existing >>>>>>>> action. >>>>>>>>> field. That action2 method wounl then be called by Trestle >>>>>>>> wherever >>>>>>>>> action is now called. >>>>>>>>> >>>>>>>>> Does anyone see problems with this? >>>>>>>> >>>>>>>> Sounds fine to me offhand. You should test your extensions with >>>>>>>> some of the existing larger applications, like mentor and >>>>>>>> Juno-2, >>>>>>>> of course. >>>>>>> >>>>>>> OK. Here's the patch. Would it be possible for someone to >>>>>>> check it >>>>>>> in >>>>>>> for me? >>>>>>> >>>>>>> mentor runs fine with this change; I watched it animate a heap- >>>>>>> sort. >>>>>>> >>>>>>> I have no idea what Juno is supposed to do, but it did respond >>>>>>> to >>>>>>> button-pushes. >>>>>>> >>>>>>> >>>>>>> hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ cvs diff >>>>>>> cvs diff: Diffing . >>>>>>> Index: ButtonVBT.i3 >>>>>>> = >>>>>>> = >>>>>>> = >>>>>>> ================================================================ >>>>>>> RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.i3,v >>>>>>> retrieving revision 1.2 >>>>>>> diff -r1.2 ButtonVBT.i3 >>>>>>> 39a40 >>>>>>>> act(READONLY cd: VBT.MouseRec); >>>>>>> Index: ButtonVBT.m3 >>>>>>> = >>>>>>> = >>>>>>> = >>>>>>> ================================================================ >>>>>>> RCS file: /usr/cvs/cm3/m3-ui/ui/src/split/ButtonVBT.m3,v >>>>>>> retrieving revision 1.2 >>>>>>> diff -r1.2 ButtonVBT.m3 >>>>>>> 28c28,29 >>>>>>> < init := Be >>>>>>> --- >>>>>>>> init := Be; >>>>>>>> act := act >>>>>>> 46a48,52 >>>>>>>> PROCEDURE act(v : T; READONLY cd: VBT.MouseRec) = >>>>>>>> BEGIN >>>>>>>> v.action(v, cd); >>>>>>>> END act; >>>>>>>> >>>>>>> 59c65 >>>>>>> < v.action(v, cd); >>>>>>> --- >>>>>>>> v.act(cd); >>>>>>> hendrik at lovesong:~/cm3/love-sq/cm3/m3-ui/ui/src/split$ >>>>>>> >>>>>>> -- hendrik >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>>>>> Germany >>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>>>> 45 86 95 >>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>>>>> Berlin >>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>>> DE163214194 >>>>>> >>>>> >> From rodney.m.bates at cox.net Fri Aug 28 15:35:17 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Fri, 28 Aug 2009 08:35:17 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20090828025553.5272F2474002@birch.elegosoft.com> References: <20090828025553.5272F2474002@birch.elegosoft.com> Message-ID: <4A97DD15.1030907@cox.net> Whenever I write/add code, in any language, I am in the habit of always surrounding every identifier with at least one blank, before and after. Otherwise, grepping for all occurrences of an identifier is a nightmare. You usually get overwhelmed with false hits where the identifier you want is a substring of others. This is extremely common. On the other hand, surrounding your search string with the Cartesian product of all the characters that could conceivably surround identifiers in code is a different kind of nightmare, and can fail to find important hits. Combinations of grep piped to grep -v with wild cards, gets closer, but that's a big pain too. (Hmm, maybe sometime I should try to script that.) Starting decades ago, I have wished every string-searching function had some kind of metacharacter to mean "at beginning of identifier" and "at end of identifier". It wouldn't be that hard, and the rules are so very close to language-independent. But, AFAIK, it has never happened. Not that adding the blanks in m3gdb mattered much, since my additions and modifications to it are a tiny subset of what is there. And the surrounding-with-blanks idea only works if you know for certain it has been done everywhere. Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/08/28 04:55:49 > > Modified files: > cm3/m3-sys/m3gdb/gdb/gdb/: Tag: release_branch_cm3_5_8 m3-eval.c > m3-exp.c m3-lang.c m3-threads.c > m3-util.c m3-valprint.c > cm3/m3-sys/m3gdb/gdb/gdb/save/: Tag: release_branch_cm3_5_8 > m3-lang.c m3-lang.h > m3-valprint.c > > Log message: > fix more pointless and inconsistent formating -- spaces before semicolons > > > From wagner at elegosoft.com Fri Aug 28 16:35:32 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 28 Aug 2009 16:35:32 +0200 Subject: [M3devel] Windows packages for RC3 Message-ID: <20090828163532.mtbood3o2ssckogo@mail.elegosoft.com> Now finally the packages have been built, but not copied to birch: /usr/bin/ssh: No such file or directory lost connection This is getting ridiculous. If there wasn't an ssh there would be no connection at all, and it has been explicitly checked before. I'll try to copy the packages manually later when I'm at home. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Fri Aug 28 16:35:39 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 28 Aug 2009 10:35:39 -0400 Subject: [M3devel] small design problem in ButtonVBT? In-Reply-To: <570C6C84-C41D-446E-A43C-13F85F1C378C@cs.purdue.edu> References: <20090331145127.GB9624@topoi.pooq.com> <20090401120347.x8cneize8oscg44o@mail.elegosoft.com> <20090826002606.GB16386@topoi.pooq.com> <20090827141741.9g1u2vrgfgokkksg@mail.elegosoft.com> <20090828031722.GB22883@topoi.pooq.com> <36DAB001-70F3-4C96-B1D5-57E8A7322464@cs.purdue.edu> <20090828091150.GA23396@topoi.pooq.com> <570C6C84-C41D-446E-A43C-13F85F1C378C@cs.purdue.edu> Message-ID: <20090828143539.GA23965@topoi.pooq.com> On Fri, Aug 28, 2009 at 09:44:14AM -0400, Tony Hosking wrote: > Yes, exactly! I don't think the change is needed and goes against the > grain of a pervasive design principle. We might question that > decision, but I hesitate to apply a piecemeal tweak that violates the > principle. Care to state that pervasive design principle? Whatever it is, Modula 3 seems to have done well by it. -- hendrik From jay.krell at cornell.edu Fri Aug 28 16:58:25 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Fri, 28 Aug 2009 10:58:25 -0400 Subject: [M3devel] Change Pathname abstraction for Windows? was: RE: RC3 build problems, was: RE: caltech-parser NT386 Hudson problems In-Reply-To: <20090828102635.0iyxllukro8o44o4@mail.elegosoft.com> References: <20090826142644.r6yabwff5wc84cgg@mail.elegosoft.com> <20090827080657.qehc5c9j44ow0ssw@mail.elegosoft.com> <20090828102635.0iyxllukro8o44o4@mail.elegosoft.com> Message-ID: <5C022EFA-8D3E-49CF-9867-2D39AF515B78@hotmail.com> (including m3devel this time) I believe this goes back to CP/M compatibility. I wish the file open dialogs accepted forward slashes. :( I will change cm3 to write back into quake state the canonicalized forms. I believe I already changed Pathname on Windows to accept either slash. I need to check if equality uses decomposed elements. Lots of folks just use strings and skip the abstraction, such as cm3. My personal programming often uses a small library over strings -- GetLastPathElement, RemoveLastElement, JoinPath, EnsureTrailingPathSeparator, ... IMHO you might as well also have posix allow backward slashes as separators, but that was rejected here. To wit I believe cygwin now accepts colons and backward slashes in paths, as non-separators. Interix also one or the other or both. Interix encodes them by oring in 0xFF00 (what happens with Samba to ext3??) There are other issues such as case sensivity not being an OS-wide thing but per volume or directory (NTFS has mount points, directories can lead to volumes, with different filesystems) as well as just what the case mapping tables are (written to NTFS volume at time of format, presumably can vary). The Mac historically used colon as separator and allowed forward slash as non separator. Presumably hidden through some encoding/decoding at the posix layer? - Jay (phone) On Aug 28, 2009, at 4:26 AM, Olaf Wagner wrote: > Quoting Jay K : > >> It was backslashes vs. forward slashes as I had originally suspected. >> My debugprinting never hit because I was guessing the elego paths >> wrong. >> I finally made it always print and tested it in-situ in the VM. > > It is amazing how much (pointless) work the difference in pathname > denotations on Windows and POSIX systems has caused and still causes. > While there are some conceptual differences that cannot easily be > generalized (one root <-> many roots, logical <-> physical view of > disks etc.), the simple fact that Windows uses \ instead of / > makes life needlessly difficult for many programmers. > > In Modula-3, the Pathname interface is intended to abstract from > this, but this works only to a certain degree. It uses \ as the > arc separator on Windows, while in fact all modern Windows systems > accept both \ and /. I think this should be corrected. > > Pathnames should be split into elements at both \ and / on Windows, > and checks for equality should ignore any differences in separator > characters only. Does this sound reasonable? > > Is there any (non)obvious problem I'm overseeing right now which > will make this strategy fail? > > Olaf > > PS: I'm not suggesting we do that in this release of course... > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ > any > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be > rlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Aug 28 18:44:34 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Fri, 28 Aug 2009 12:44:34 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <4A97DD15.1030907@cox.net> References: <20090828025553.5272F2474002@birch.elegosoft.com> <4A97DD15.1030907@cox.net> Message-ID: <9DA06850-DE99-4D69-A1E2-91DADDF38312@hotmail.com> Perl regexp has word boundary notion. Visual C++ 5.0 find-in-files feature, which overall is an excellent feature, has a "whole word" option. - Jay (phone) On Aug 28, 2009, at 9:35 AM, "Rodney M. Bates" wrote: > Whenever I write/add code, in any language, I am in the habit of > always surrounding > every identifier with at least one blank, before and after. > Otherwise, grepping > for all occurrences of an identifier is a nightmare. You usually > get overwhelmed > with false hits where the identifier you want is a substring of > others. > This is extremely common. > > On the other hand, surrounding your search string with the Cartesian > product of all the characters that could conceivably surround > identifiers > in code is a different kind of nightmare, and can fail to find > important > hits. Combinations of grep piped to grep -v with wild cards, gets > closer, > but that's a big pain too. (Hmm, maybe sometime I should try to > script > that.) > > Starting decades ago, I have wished every string-searching function > had > some kind of metacharacter to mean "at beginning of identifier" and > "at end of identifier". It wouldn't be that hard, and the rules are > so very > close to language-independent. But, AFAIK, it has never happened. > > Not that adding the blanks in m3gdb mattered much, since my additions > and modifications to it are a tiny subset of what is there. And the > surrounding-with-blanks idea only works if you know for certain it has > been done everywhere. > > Jay Krell wrote: >> CVSROOT: /usr/cvs >> Changes by: jkrell at birch. 09/08/28 04:55:49 >> >> Modified files: >> cm3/m3-sys/m3gdb/gdb/gdb/: Tag: release_branch_cm3_5_8 m3- >> eval.c m3-exp.c m3-lang.c m3- >> threads.c m3-util.c m3-valprint.c >> cm3/m3-sys/m3gdb/gdb/gdb/save/: Tag: >> release_branch_cm3_5_8 m3-lang.c >> m3-lang.h m3-valprint.c >> Log message: >> fix more pointless and inconsistent formating -- spaces before >> semicolons >> >> >> > > From hosking at cs.purdue.edu Fri Aug 28 18:44:48 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 28 Aug 2009 12:44:48 -0400 Subject: [M3devel] small design problem in ButtonVBT? In-Reply-To: <20090828143539.GA23965@topoi.pooq.com> References: <20090331145127.GB9624@topoi.pooq.com> <20090401120347.x8cneize8oscg44o@mail.elegosoft.com> <20090826002606.GB16386@topoi.pooq.com> <20090827141741.9g1u2vrgfgokkksg@mail.elegosoft.com> <20090828031722.GB22883@topoi.pooq.com> <36DAB001-70F3-4C96-B1D5-57E8A7322464@cs.purdue.edu> <20090828091150.GA23396@topoi.pooq.com> <570C6C84-C41D-446E-A43C-13F85F1C378C@cs.purdue.edu> <20090828143539.GA23965@topoi.pooq.com> Message-ID: <2B370785-C8C1-4964-87DC-5EF3B839B898@cs.purdue.edu> I meant the principle articulated for use of a procedure instead of a method for ButtonVBT. On 28 Aug 2009, at 10:35, hendrik at topoi.pooq.com wrote: > On Fri, Aug 28, 2009 at 09:44:14AM -0400, Tony Hosking wrote: >> Yes, exactly! I don't think the change is needed and goes against >> the >> grain of a pervasive design principle. We might question that >> decision, but I hesitate to apply a piecemeal tweak that violates the >> principle. > > Care to state that pervasive design principle? Whatever it is, > Modula 3 > seems to have done well by it. > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Aug 29 13:36:37 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 29 Aug 2009 13:36:37 +0200 Subject: [M3devel] RC3 status and open tickets Message-ID: <20090829133637.49ywpog80ggwsogs@mail.elegosoft.com> There have been many problems again building the release archives on some platforms, especially NT386 and Solaris, but there is progress. The SOLgnu packages seem to be OK now, but the SOLsun packages are still all more or less broken. You can find the results of installation tests at http://hudson.modula3.com:8080/view/test-install/ Several build machines we used in RC2 are still not available (traveling on Jay's new computer ;-); those will be added later. Build and other regression test results are in http://hudson.modula3.com:8080/ There are still many open tickets regarding RC3 https://projects.elego.de/cm3/query?status=resolved&status=reopened&status=assigned&status=analyzed&status=new&status=accepted&group=status&milestone=CM3+Release+5.8+RC3 and the final 5.8 release: https://projects.elego.de/cm3/query?status=resolved&status=reopened&status=assigned&status=analyzed&status=new&status=accepted&group=status&milestone=CM3+release+5.8 Help in analyzing and resolving them is very welcome. I'll be on vacation for two weeks to the south of France, and won't be able to do anything for CM3 then (leaving my laptop behind ;-). I think it is unrealistic that the final release is availble until then, but I hope that we at least have a more or less stable RC3. Thanks for your patience and support, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Sat Aug 29 23:51:06 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 29 Aug 2009 23:51:06 +0200 Subject: [M3devel] tinderbox failures: undefined variables in quake Message-ID: <20090829235106.lb9zq4ouo8kcckgs@mail.elegosoft.com> Several release builds fail with undefined variables in quake now (this is probably in the trunk I assume). Who broke this now? Is it just missing backward compatibility or a more serious problem? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sun Aug 30 00:24:53 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Sat, 29 Aug 2009 17:24:53 -0500 Subject: [M3devel] tinderbox failures: undefined variables in quake In-Reply-To: <20090829235106.lb9zq4ouo8kcckgs@mail.elegosoft.com> References: <20090829235106.lb9zq4ouo8kcckgs@mail.elegosoft.com> Message-ID: <4AC5146C-68FE-40F0-828C-462428AF8E6F@hotmail.com> Tinderbox head or Hudson release? Either way probably me I can look tonight. - Jay (phone) On Aug 29, 2009, at 4:51 PM, Olaf Wagner wrote: > Several release builds fail with undefined variables in quake now > (this is probably in the trunk I assume). > > Who broke this now? Is it just missing backward compatibility > or a more serious problem? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germ > any > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Be > rlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > From jay.krell at cornell.edu Sun Aug 30 11:05:33 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 30 Aug 2009 09:05:33 +0000 Subject: [M3devel] cminstall too many errors if not root, in fact maybe infinite Message-ID: It bugs me how many packages there are -- too much to test. So I'll test just a few. Starting with cm3-bin-min-SOLsun-5.8.3-RC3.tgz: ./cminstall => endless stream of Unable to create directory: /usr/local/cm3 ./cminstall | wc -l => I've been waiting a while and it hasn't terminated. As I've said before, cminstall doesn't do much and doesn't do it well. Granted, claiming that nothing is needed here is a stretch. If I go ahead and in another console as root mkdir /usr/local, no progress. mkdir /usr/local/cm3. Then it stops with: Unexpected problem: Unable to open the log file: /usr/local/cm3/Install.log: errno=13 Please feel free to contact m3-support at elego.de to troubleshoot this problem. Now, I understand that refusing to run as non-root is not the solution. -bash-3.00$ ./cminstall --help Unexpected problem: Unrecognized option: --help Please feel free to contact m3-support at elego.de to troubleshoot this problem. I'll fix that. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Aug 30 11:11:20 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 30 Aug 2009 09:11:20 +0000 Subject: [M3devel] cminstall says too much Message-ID: cminstall is really not so great. Here is one criticism -- it says too much. -bash-3.00$ ./cminstall Thank you for using Critical Mass CM3. This program will configure and install the system. cminstall_root is set to /home/jay/t/min If this is not correct, please restart the installer with -root [Jay Is it ever wrong? Must it always be reported?] If the installer runs interactively, it will ask you some questions about the locations of programs and libraries. Usually it will display a default inside [], which can be accepted with . If the installer has found several choices, you may cycle through them with `+' or `.' for the next and `-' for the previous one. You may of course also enter a completely different value. [I didn't run it interactively. Why tell me all this?] Installing CM3 in: /usr/local/cm3 This may take a few minutes... CM3 is now installed. Before you begin, here's a few reminders: 1) The CM3 compiler executable is in: /usr/local/cm3/bin/cm3 You may need to modify your PATH environment variable to find it. And on Unix, you may need to type "rehash" to your shell. 2) CM3's shared libraries and any you create and ship are in: /usr/local/cm3/lib On some Unix systems you may need to set the LD_LIBRARY_PATH (on Darwin / MacOS X it's called DYLD_LIBRARY_PATH) environment variable before running programs that use these shared libraries (usually not necessary). [This applies to almost no systems, esp. the Mac part.] 3) Your system configuration file is: /usr/local/cm3/bin/cm3.cfg At any point in time, you may edit it to modify or update your installation. 4) A copy of this installation dialogue is in: /usr/local/cm3/Install.log [dialogue for non-interactive installs?] 5) If you had trouble with this installation or need more assistance, please send us a transcript of this installation via e-mail at "m3-support at elego.de". Thank you. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Aug 30 13:00:00 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 30 Aug 2009 11:00:00 +0000 Subject: [M3devel] RandomTest runtime error FileWr.Error not in Raises list Message-ID: I think this is two or three problems. - missing raises - why does it raise - why does it hang Often but not always: jay at xlin2:/dev2/release_branch_cm3_5_8/m3-libs/libm3/tests/random$ pwd /dev2/release_branch_cm3_5_8/m3-libs/libm3/tests/random jay at xlin2:/dev2/release_branch_cm3_5_8/m3-libs/libm3/tests/random$ ./LINUXLIBC6 /RandomTest -perm under gdb: *** *** runtime error: *** Exception "FileWr.Error" not in RAISES list *** file "../src/rw/FileWr.m3", line 81 *** Program received signal SIGABRT, Aborted. [Switching to Thread -1210370368 (LWP 21415)] 0xb7f25410 in ?? () (gdb) bt #0 0xb7f25410 in ?? () #1 0xbfc4f14c in ?? () #2 0x00000006 in ?? () #3 0x000053a7 in ?? () #4 0xb7ddc811 in raise () from /lib/tls/i686/cmov/libc.so.6 #5 0xb7dddfb9 in abort () from /lib/tls/i686/cmov/libc.so.6 #6 0x0808bb12 in RTOS__Crash () at ../src/runtime/POSIX/RTOS.m3:20 #7 0x08085d83 in RTProcess__Crash (M3_Bd56fi_msg=0x0) at ../src/runtime/common/RTProcess.m3:65 #8 0x08083a8e in RTError__EndError (M3_AicXUJ_crash=1 '\001') at ../src/runtime/common/RTError.m3:118 #9 0x08083752 in RTError__MsgS (M3_AJWxb1_file=0x80c437c, M3_AcxOUs_line=81, M3_Bd56fi_msgA=0x80cc350, M3_Bd56fi_msgB=0xb7d7eba0, M3_Bd56fi_msgC=0x80cc378) at ../src/runtime/common/RTError.m3:40 #10 0x08083ef6 in RTException__Crash (M3_Cblw37_a=0xbfc4f460, M3_AicXUJ_raises=1 '\001', M3_AJWxb1_rte=0x80c8400) at ../src/runtime/common/RTException.m3:79 #11 0x08083c5f in RTException__DefaultBackstop (M3_Cblw37_a=0xbfc4f460, M3_AicXUJ_raises=0 '\0') at ../src/runtime/common/RTException.m3:41 #12 0x08083b59 in RTException__InvokeBackstop (M3_Cblw37_a=0xbfc4f460, M3_AicXUJ_raises=0 '\0') at ../src/runtime/common/RTException.m3:25 #13 0x0808c5a8 in RTException__Raise (M3_Cblw37_act=0xbfc4f460) at ../src/runtime/ex_frame/RTExFrame.m3:29 #14 0x08083cb6 in RTException__DefaultBackstop (M3_Cblw37_a=0xbfc4f460, ---Type to continue, or q to quit--- M3_AicXUJ_raises=1 '\001') at ../src/runtime/common/RTException.m3:47 #15 0x08083b59 in RTException__InvokeBackstop (M3_Cblw37_a=0xbfc4f460, M3_AicXUJ_raises=1 '\001') at ../src/runtime/common/RTException.m3:25 #16 0x0808c689 in RTException__Raise (M3_Cblw37_act=0xbfc4f460) at ../src/runtime/ex_frame/RTExFrame.m3:51 #17 0x08073e99 in RTHooks__Raise (M3_AJWxb1_ex=0x80c42a0, M3_AJWxb1_arg=0x0, M3_AJWxb1_module=0x80c43e0, M3_AcxOUs_line=81) at ../src/runtime/common/RTHooks.m3:79 #18 0x0806a9c4 in FileWr__Seek (M3_EJV0jI_wr=0xb7d73234, M3_Cwb5VA_n=4198) at ../src/rw/FileWr.m3:81 #19 0x080559ea in AutoFlushWr__Seek (M3_Aauo9c_wr=0xb7d790a4, M3_Cwb5VA_n=4198) at ../src/rw/AutoFlushWr.m3:106 #20 0x080544bf in WrClass__PutStringDefault (M3_BxxOH1_wr=0xb7d790a4, M3_CKMnXU_a=0xbfc4f7f4) at ../src/rw/Wr.m3:193 #21 0x080539de in UnsafeWr__FastPutText (M3_BxxOH1_wr=0xb7d790a4, M3_Bd56fi_t=0xb7d7eb84) at ../src/rw/Wr.m3:105 #22 0x08053837 in Wr__PutText (M3_BxxOH1_wr=0xb7d790a4, M3_Bd56fi_t=0xb7d7eb84) at ../src/rw/Wr.m3:93 #23 0x0804f561 in RandomTest__TestPerm () at ../src/RandomTest.m3:387 #24 0x0804bedf in RandomTest__Main () at ../src/RandomTest.m3:64 #25 0x08050235 in RandomTest_M3 (M3_AcxOUs_mode=1) at ../src/RandomTest.m3:458 #26 0x08082bf8 in RTLinker__RunMainBody (M3_DjPxE3_m=0x80be120) at ../src/runtime/common/RTLinker.m3:399 #27 0x08081fb2 in RTLinker__AddUnitI (M3_DjPxE3_m=0x80be120) ---Type to continue, or q to quit--- at ../src/runtime/common/RTLinker.m3:113 #28 0x08082040 in RTLinker__AddUnit (M3_DjPxE5_b=0x8050165) at ../src/runtime/common/RTLinker.m3:122 #29 0x0804baee in main (argc=2, argv=0xbfc4fe94, envp=0xbfc4fea0) at _m3main.mc:4 (gdb) This test hangs on OpenBSD/x86. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun Aug 30 22:33:23 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 30 Aug 2009 22:33:23 +0200 Subject: [M3devel] RC3 Message-ID: <20090830223323.qpwzvxkdckw0o480@mail.elegosoft.com> Though there are still several open problem, I suggest that we now stop making changes to the codebase for RC3 and retarget the issues to the final release. This means * We do not move the tag for RC3 any further (except perhaps for some make-dist scripts which need some tweaking but have no direct impact on cm3) * Exception is the addition of the native installation archives for NT386 * We continue adding installation archives for new platforms The installation archives should be much better than RC2. All further improvements and fixes go into the final release (or RC4). We should also announce the availability of RC3 outside of m3devel. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Aug 31 03:10:55 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 31 Aug 2009 01:10:55 +0000 Subject: [M3devel] how to find cm3.cfg Message-ID: how to find cm3.cfg I propose, in this order: - -config or --config switch (actually any number of dashes) - $M3_CONFIG environment variable (however it is already spelled) This is a preferably path to a specific file, not some directory to further probe. I'll have to check the current implementation though. It might be a directory containing cm3.cfg as well. Whatever it currently does is how it should likely stay. - cm3.cfg next to executable, be it cm3.exe, cm3ide.exe, etc. - possibly one other choice, if none of the above exist, and executable is not cm3/cm3.exe, then search $PATH for cm3/cm3.exe and use cm3.cfg next to it This includes NOT looking in: - /etc - current directory - $PATH in general One problem is, you can't really directly/easily even find the current executable in Posix. I'll do more research on this. It is easy in Win32 and I assume Mac. Otherwise will probably fall back to: I believe everyone's best effort here is looking at argv[0] and if that isn't a full or current working directory relative path, search $PATH. Any other search should be layerable upon this. That is, cm3.cfg can include(/etc/cm3.cfg) or such. One thing not accounted for here is a --target command line option. Given the current layout and code, that doesn't work out well. Specifically, using config/target wouldn't set INSTALL_ROOT correctly. --target could set $TARGET and cm3.cfg could include config/target if target is already set. Or cm3 could set INSTALL_ROOT itself. We could look for next-to-executable/target.cfg. I think I'll punt on all this for now -- any accomodation of --target on command line. I think this change should probably go in this release, given that there was another change already that this undoes and given th bug I found regarding running by relative path (granted, I should debug that before replacing the code). Or, I guess, at the very least, remove the new probes and fix the bug I found. I guess. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Aug 31 09:15:49 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 31 Aug 2009 09:15:49 +0200 Subject: [M3devel] how to find cm3.cfg In-Reply-To: References: Message-ID: <20090831091549.ii6ae9sr40cwg804@mail.elegosoft.com> Some quick comments: o It is rather late in the release to change the interfaces, i.e. introduce new command line options like -config or -target. -config is currently the same as -version, so this is incompatible. I'd rather leave changes like this for the trunk. The release branch is _not_ for development. o I do not remember that an agreement was reached concerning the config search discussion. There were some contradictory mails on the matter as far as I remember, but no conclusion, so I didn't change anything again. As long as we haven't really resolved this, we are likely to change again and again. o I'm not against simplifying the initial search in the cm3 executable, but if we agree that customizations for system-specific layouts should be done in the quake code, this should be documented and even prepared in the provided config files. o If anything is changed again, at least not for RC3. The correct way would be to test such changes on the trunk and then merge them for a later RC4. Let's do it this way. It is almost impossible to get the system stable enough for a multi-platform package build. IIRC, we've been trying for more than two weeks now to build RC3. Olaf Quoting Jay K : > how to find cm3.cfg > > I propose, in this order: > > - -config or --config switch (actually any number of dashes) > > - $M3_CONFIG environment variable (however it is already spelled) > > This is a preferably path to a specific file, not some > directory to further probe. > > I'll have to check the current implementation though. It might be > > a directory containing cm3.cfg as well. Whatever it currently > does is how it should likely stay. > > - cm3.cfg next to executable, be it cm3.exe, cm3ide.exe, etc. > > - possibly one other choice, if none of the above exist, and > executable is not cm3/cm3.exe, > > then search $PATH for cm3/cm3.exe and use cm3.cfg next to it > > This includes NOT looking in: > > - /etc > > - current directory > > - $PATH in general > > One problem is, you can't really directly/easily even find the > current executable in Posix. > > I'll do more research on this. > > It is easy in Win32 and I assume Mac. > > Otherwise will probably fall back to: > > I believe everyone's best effort here is looking at argv[0] and if > that isn't a full or > > current working directory relative path, search $PATH. > > Any other search should be layerable upon this. > > That is, cm3.cfg can include(/etc/cm3.cfg) or such. > > One thing not accounted for here is a --target command line option. > > Given the current layout and code, that doesn't work out well. > > Specifically, using config/target wouldn't set INSTALL_ROOT correctly. > > --target could set $TARGET and cm3.cfg could include config/target if > > target is already set. > > Or cm3 could set INSTALL_ROOT itself. > > We could look for next-to-executable/target.cfg. > > I think I'll punt on all this for now -- any accomodation of > --target on command line. > > I think this change should probably go in this release, given that > there was another change > > already that this undoes and given th bug I found regarding running > by relative path (granted, > > I should debug that before replacing the code). > > Or, I guess, at the very least, remove the new probes and fix the > bug I found. > > I guess. -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Aug 31 09:55:00 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 31 Aug 2009 07:55:00 +0000 Subject: [M3devel] RandomTest runtime error FileWr.Error not in Raises list Message-ID: Easy to trigger problems here, also on NT, like with: VAR r: Random.T; stdout := NEW(AutoFlushWr.T).init(Stdio.stdout); PROCEDURE Main () = BEGIN WHILE TRUE DO Wr.PutText(stdout, "foofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoo\n"); END; foofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoo FileWr.Seek:wr.seekable=FALSE,n=53300,wr.hi=57396 *** *** runtime error: *** Exception "FileWr.Error" not in RAISES list *** file "..\src\rw\FileWr.m3", line 85 *** *** *** runtime error: *** Thread client error: Attempt to lock mutex already locked by self *** file "..\src\thread\WIN32\ThreadWin32.m3", line 119 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12fcfc 0x41c2d6 Seek + 0x125 in ..\src\rw\FileWr.m3 0x12fd58 0x40e6b1 Seek + 0x165 in ..\src\rw\AutoFlushWr.m3 0x12fd9c 0x407c9a PutStringDefault + 0x281 in ..\src\rw\Wr.m3 0x12fe50 0x407460 FastPutText + 0x105 in ..\src\rw\Wr.m3 0x12fe78 0x407328 PutText + 0x4e in ..\src\rw\Wr.m3 0x12febc 0x4010c6 Main + 0x76 in ..\src\RandomTest.m3 0x12fee0 0x405795 RandomTest_M3 + 0xb5 in ..\src\RandomTest.m3 Must be some race condition between flushing and other writers? - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: RandomTest runtime error FileWr.Error not in Raises list Date: Sun, 30 Aug 2009 11:00:00 +0000 I think this is two or three problems. - missing raises - why does it raise - why does it hang Often but not always: jay at xlin2:/dev2/release_branch_cm3_5_8/m3-libs/libm3/tests/random$ pwd /dev2/release_branch_cm3_5_8/m3-libs/libm3/tests/random jay at xlin2:/dev2/release_branch_cm3_5_8/m3-libs/libm3/tests/random$ ./LINUXLIBC6 /RandomTest -perm under gdb: *** *** runtime error: *** Exception "FileWr.Error" not in RAISES list *** file "../src/rw/FileWr.m3", line 81 *** Program received signal SIGABRT, Aborted. [Switching to Thread -1210370368 (LWP 21415)] 0xb7f25410 in ?? () (gdb) bt #0 0xb7f25410 in ?? () #1 0xbfc4f14c in ?? () #2 0x00000006 in ?? () #3 0x000053a7 in ?? () #4 0xb7ddc811 in raise () from /lib/tls/i686/cmov/libc.so.6 #5 0xb7dddfb9 in abort () from /lib/tls/i686/cmov/libc.so.6 #6 0x0808bb12 in RTOS__Crash () at ../src/runtime/POSIX/RTOS.m3:20 #7 0x08085d83 in RTProcess__Crash (M3_Bd56fi_msg=0x0) at ../src/runtime/common/RTProcess.m3:65 #8 0x08083a8e in RTError__EndError (M3_AicXUJ_crash=1 '\001') at ../src/runtime/common/RTError.m3:118 #9 0x08083752 in RTError__MsgS (M3_AJWxb1_file=0x80c437c, M3_AcxOUs_line=81, M3_Bd56fi_msgA=0x80cc350, M3_Bd56fi_msgB=0xb7d7eba0, M3_Bd56fi_msgC=0x80cc378) at ../src/runtime/common/RTError.m3:40 #10 0x08083ef6 in RTException__Crash (M3_Cblw37_a=0xbfc4f460, M3_AicXUJ_raises=1 '\001', M3_AJWxb1_rte=0x80c8400) at ../src/runtime/common/RTException.m3:79 #11 0x08083c5f in RTException__DefaultBackstop (M3_Cblw37_a=0xbfc4f460, M3_AicXUJ_raises=0 '\0') at ../src/runtime/common/RTException.m3:41 #12 0x08083b59 in RTException__InvokeBackstop (M3_Cblw37_a=0xbfc4f460, M3_AicXUJ_raises=0 '\0') at ../src/runtime/common/RTException.m3:25 #13 0x0808c5a8 in RTException__Raise (M3_Cblw37_act=0xbfc4f460) at ../src/runtime/ex_frame/RTExFrame.m3:29 #14 0x08083cb6 in RTException__DefaultBackstop (M3_Cblw37_a=0xbfc4f460, ---Type to continue, or q to quit--- M3_AicXUJ_raises=1 '\001') at ../src/runtime/common/RTException.m3:47 #15 0x08083b59 in RTException__InvokeBackstop (M3_Cblw37_a=0xbfc4f460, M3_AicXUJ_raises=1 '\001') at ../src/runtime/common/RTException.m3:25 #16 0x0808c689 in RTException__Raise (M3_Cblw37_act=0xbfc4f460) at ../src/runtime/ex_frame/RTExFrame.m3:51 #17 0x08073e99 in RTHooks__Raise (M3_AJWxb1_ex=0x80c42a0, M3_AJWxb1_arg=0x0, M3_AJWxb1_module=0x80c43e0, M3_AcxOUs_line=81) at ../src/runtime/common/RTHooks.m3:79 #18 0x0806a9c4 in FileWr__Seek (M3_EJV0jI_wr=0xb7d73234, M3_Cwb5VA_n=4198) at ../src/rw/FileWr.m3:81 #19 0x080559ea in AutoFlushWr__Seek (M3_Aauo9c_wr=0xb7d790a4, M3_Cwb5VA_n=4198) at ../src/rw/AutoFlushWr.m3:106 #20 0x080544bf in WrClass__PutStringDefault (M3_BxxOH1_wr=0xb7d790a4, M3_CKMnXU_a=0xbfc4f7f4) at ../src/rw/Wr.m3:193 #21 0x080539de in UnsafeWr__FastPutText (M3_BxxOH1_wr=0xb7d790a4, M3_Bd56fi_t=0xb7d7eb84) at ../src/rw/Wr.m3:105 #22 0x08053837 in Wr__PutText (M3_BxxOH1_wr=0xb7d790a4, M3_Bd56fi_t=0xb7d7eb84) at ../src/rw/Wr.m3:93 #23 0x0804f561 in RandomTest__TestPerm () at ../src/RandomTest.m3:387 #24 0x0804bedf in RandomTest__Main () at ../src/RandomTest.m3:64 #25 0x08050235 in RandomTest_M3 (M3_AcxOUs_mode=1) at ../src/RandomTest.m3:458 #26 0x08082bf8 in RTLinker__RunMainBody (M3_DjPxE3_m=0x80be120) at ../src/runtime/common/RTLinker.m3:399 #27 0x08081fb2 in RTLinker__AddUnitI (M3_DjPxE3_m=0x80be120) ---Type to continue, or q to quit--- at ../src/runtime/common/RTLinker.m3:113 #28 0x08082040 in RTLinker__AddUnit (M3_DjPxE5_b=0x8050165) at ../src/runtime/common/RTLinker.m3:122 #29 0x0804baee in main (argc=2, argv=0xbfc4fe94, envp=0xbfc4fea0) at _m3main.mc:4 (gdb) This test hangs on OpenBSD/x86. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Aug 31 12:02:26 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 31 Aug 2009 10:02:26 +0000 Subject: [M3devel] FW: Wr.Unlock to restore invariants? In-Reply-To: <20090831091151.71CD12474001@birch.elegosoft.com> References: <20090831091151.71CD12474001@birch.elegosoft.com> Message-ID: My later change undoes this, and in general AutoFlushWr wasn't honoring it before -- in particular Flush and Length. Insert the extra unlock/lock to "fix" that? In particular, WrClass.i3: PROCEDURE Unlock(wr: Wr.T); (* The writer wr must be locked and valid; unlock it and restore the private invariant of the writer implementation. *) - Jay > Date: Mon, 31 Aug 2009 11:11:51 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/08/31 11:11:51 > > Modified files: > cm3/m3-libs/libm3/src/rw/: AutoFlushWr.m3 > > Log message: > Since Unlock is also documented as restoring invariants, restore > the early Unlock, and then put in an extra Lock after that. > In reality all the reader/writers implemented here don't do > anything in Unlock except unlock, so it was ok. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Aug 31 12:15:55 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 31 Aug 2009 10:15:55 +0000 Subject: [M3devel] "RandomTest" (that is its name) hangs on I386_OPENBSD Message-ID: "RandomTest" (that is its name) always hangs on I386_OPENBSD. The main thread never finishes StopWorld: (gdb) bt #0 0x00ba08f1 in poll () from /usr/lib/libc.so.50.1 #1 0x04ab5314 in _thread_kern_poll (wait_reqd=1) at /usr/src/lib/libpthread/uthread/uthread_kern.c:760 #2 0x04ab4e53 in _thread_kern_sched (scp=0x0) at /usr/src/lib/libpthread/uthread/uthread_kern.c:382 #3 0x04ab519f in _thread_kern_sched_state (state=615149768, fname=0x24aa70c8 "", lineno=615149768) at /usr/src/lib/libpthread/uthread/uthread_kern.c:550 #4 0x04aaf085 in nanosleep (time_to_sleep=0xcfbcc1a8, time_remaining=0xcfbcc1b0) at /usr/src/lib/libpthread/uthread/uthread_nanosleep.c:84 #5 0x0166eafd in ThreadPThread__Nanosleep (req=0xcfbcc1a8, rem=0xcfbcc1b0) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 #6 0x0166b6f4 in ThreadPThread__CommonSleep () at ../src/thread/PTHREAD/ThreadPThread.m3:651 #7 0x0166d355 in ThreadPThread__StopWorld () at ../src/thread/PTHREAD/ThreadPThread.m3:1142 #8 0x0166c9c3 in ThreadF__SuspendOthers () at ../src/thread/PTHREAD/ThreadPThread.m3:918 #9 0x0164e70b in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:747 #10 0x0164e6ca in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:721 #11 0x0164e161 in RTCollector__CollectEnough (M3_AicXUJ_allocator=1 '\001') ---Type to continue, or q to quit--- at ../src/runtime/common/RTCollector.m3:653 #12 0x01650cb7 in RTCollector__LongAlloc (M3_Cwb5VA_dataSize=92, M3_Cwb5VA_dataAlignment=4, M3_CAzbsM_pool=0x86770ab8) at ../src/runtime/common/RTCollector.m3:1438 #13 0x01650b14 in RTHeapRep__AllocTraced (M3_Cwb5VA_dataSize=92, M3_Cwb5VA_dataAlignment=4, M3_CAzbsM_pool=0x86770ab8) at ../src/runtime/common/RTCollector.m3:1400 #14 0x01645b47 in RTAllocator__GetOpenArray (M3_Eic7CK_def=0x216259d0, M3_ANmeAM_s=0xcfbcc4fc) at ../src/runtime/common/RTAllocator.m3:292 #15 0x01644e3c in RTHooks__AllocateOpenArray (M3_AJWxb1_defn=0x216259d0, M3_ANmeAM_s=0xcfbcc4fc) at ../src/runtime/common/RTAllocator.m3:141 #16 0x0c4b364f in RandomPerm__HQInit (M3_AMLmtL_t=0x7eed1fb0, M3_Cwb5VA_n=21, M3_BUCfej_r=0x7eecb0f4) at ../src/random/Common/RandomPerm.m3:55 #17 0x1c00489e in RandomTest__TestPerm () at ../src/RandomTest.m3:367 #18 0x1c0015f7 in RandomTest__Main () at ../src/RandomTest.m3:64 #19 0x1c00595c in RandomTest_M3 (M3_AcxOUs_mode=1) at ../src/RandomTest.m3:458 #20 0x01658a19 in RTLinker__RunMainBody (M3_DjPxE3_m=0x3c001660) at ../src/runtime/common/RTLinker.m3:400 #21 0x01657dd3 in RTLinker__AddUnitI (M3_DjPxE3_m=0x3c001660) at ../src/runtime/common/RTLinker.m3:114 #22 0x01657e61 in RTLinker__AddUnit (M3_DjPxE5_b=0x1c00588c) at ../src/runtime/common/RTLinker.m3:123 #23 0x1c001206 in main (argc=2, argv=0xcfbccadc, envp=0xcfbccae8) at _m3main.mc:4 While the other thread is in: Thread 2 (process 5611, thread 0x7fc1d400): #0 _thread_kern_sched (scp=0x0) at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 #1 0x04ab5200 in _thread_kern_sched_state_unlock (state=PS_SIGTHREAD, lock=0x7fc1d4b0, fname=0x1
, lineno=1) at /usr/src/lib/libpthread/uthread/uthread_kern.c:581 #2 0x04ab2bc9 in pthread_cond_wait (cond=0x80dda100, mutex=0x80dda1e0) at /usr/src/lib/libpthread/uthread/uthread_cond.c:261 #3 0x01668b89 in ThreadPThread__XWait (M3_BXP32l_self=0x7eeff13c, M3_AYIbX3_m=0x7eecb018, M3_Bl0jv4_c=0x7eecb06c, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x01669235 in Thread__Wait (M3_AYIbX3_m=0x7eecb018, M3_Bl0jv4_c=0x7eecb06c) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x0c4c1de7 in AutoFlushWr__Worker (M3_EMTrVz_cl=0x7eeff134) at ../src/rw/AutoFlushWr.m3:210 #6 0x0166acfb in ThreadPThread__RunThread (M3_BeUkBA_me=0x86770b00) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x0166aa26 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x86770b00) at ../src/thread/PTHREAD/ThreadPThread.m3:523 #8 0x04aac37f in _thread_start () at /usr/src/lib/libpthread/uthread/uthread_create.c:240 #9 0x0000002b in ?? () #10 0x00000000 in ?? () Maybe AutoFlushWr needs more work? (It was crashing on platforms it didn't hang on.) I'll try to dig around more here.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Aug 31 12:16:32 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 31 Aug 2009 10:16:32 +0000 Subject: [M3devel] Posix/Win32 linger options inverted? In-Reply-To: References: Message-ID: ? > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Sun, 23 Aug 2009 06:26:34 +0000 > Subject: [M3devel] Posix/Win32 linger options inverted? > > > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-comm/tcp/src/POSIX/TCP.m3?rev=1.7;content-type=text%2Fplain > > vs. > > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-comm/tcp/src/WIN32/TCP.m3?rev=1.3;content-type=text%2Fplain > > > search for linger: > > PROCEDURE InitFD(fd: CARDINAL) = > (* We assume that the runtime ignores SIGPIPE signals *) > VAR > one: int := 1; > linger := Usocket.struct_linger{1, 1}; > > vs. > > PROCEDURE InitSock(sock: WinSock.SOCKET) = > (* We assume that the runtime ignores SIGPIPE signals *) > VAR > one : BOOL := 1; > linger := WinSock.struct_linger{0, 0}; > > > Surely they can't both be correct. > Which is correct? The Posix one? > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Aug 31 13:20:56 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 31 Aug 2009 13:20:56 +0200 Subject: [M3devel] Posix/Win32 linger options inverted? In-Reply-To: References: Message-ID: <20090831132056.dpkpp6z5pkw4os0c@mail.elegosoft.com> On Solaris I find /* * Structure used for manipulating linger option. */ struct linger { int l_onoff; /* option on/off */ int l_linger; /* linger time */ }; so {1, 1} would make the socket linger for at most 1 second after close, while {0, 0} would close the socket immediately and throw away any data not sent yet. The default linger time on Solaris seems to be 120 seconds btw. I cannot really say why this difference is present, I can only guess that one of them is a workaround for a bug. Perhaps the intention was indeed to allow 1 second until data is sent, but this didn't work on Windows? Does anybody here know more? Olaf Quoting Jay K : > > ? > > > >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Date: Sun, 23 Aug 2009 06:26:34 +0000 >> Subject: [M3devel] Posix/Win32 linger options inverted? >> >> >> http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-comm/tcp/src/POSIX/TCP.m3?rev=1.7;content-type=text%2Fplain >> >> vs. >> >> http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-comm/tcp/src/WIN32/TCP.m3?rev=1.3;content-type=text%2Fplain >> >> >> search for linger: >> >> PROCEDURE InitFD(fd: CARDINAL) = >> (* We assume that the runtime ignores SIGPIPE signals *) >> VAR >> one: int := 1; >> linger := Usocket.struct_linger{1, 1}; >> >> vs. >> >> PROCEDURE InitSock(sock: WinSock.SOCKET) = >> (* We assume that the runtime ignores SIGPIPE signals *) >> VAR >> one : BOOL := 1; >> linger := WinSock.struct_linger{0, 0}; >> >> >> Surely they can't both be correct. >> Which is correct? The Posix one? >> >> >> - Jay > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Aug 31 14:16:21 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 31 Aug 2009 12:16:21 +0000 Subject: [M3devel] tinderbox failures: undefined variables in quake In-Reply-To: <20090829235106.lb9zq4ouo8kcckgs@mail.elegosoft.com> References: <20090829235106.lb9zq4ouo8kcckgs@mail.elegosoft.com> Message-ID: There are definitely some bugs in old cm3 that I don't understand. My use of "local" at global scope may be dubious, granted. I can build cm3cg now from Linux/x86 5.4.0, but I'm not sure about the M3_PROFILING error. We'll see how the next runs go. The Tinderbox build scripts should run cm3 -version so we know what we are dealing with. - Jay > Date: Sat, 29 Aug 2009 23:51:06 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] tinderbox failures: undefined variables in quake > > Several release builds fail with undefined variables in quake now > (this is probably in the trunk I assume). > > Who broke this now? Is it just missing backward compatibility > or a more serious problem? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Aug 31 17:06:44 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 31 Aug 2009 11:06:44 -0400 Subject: [M3devel] "RandomTest" (that is its name) hangs on I386_OPENBSD In-Reply-To: References: Message-ID: <04B5CB8B-5D26-4529-86CA-25B399DE6F0C@cs.purdue.edu> The main thread should never hang here... Looks like thread 2 is not receiving/responding to the signal to stop. Something very wrong... On 31 Aug 2009, at 06:15, Jay K wrote: > "RandomTest" (that is its name) always hangs on I386_OPENBSD. > > > The main thread never finishes StopWorld: > > > (gdb) bt > #0 0x00ba08f1 in poll () from /usr/lib/libc.so.50.1 > #1 0x04ab5314 in _thread_kern_poll (wait_reqd=1) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:760 > #2 0x04ab4e53 in _thread_kern_sched (scp=0x0) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:382 > #3 0x04ab519f in _thread_kern_sched_state (state=615149768, > fname=0x24aa70c8 "", lineno=615149768) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:550 > #4 0x04aaf085 in nanosleep (time_to_sleep=0xcfbcc1a8, > time_remaining=0xcfbcc1b0) > at /usr/src/lib/libpthread/uthread/uthread_nanosleep.c:84 > #5 0x0166eafd in ThreadPThread__Nanosleep (req=0xcfbcc1a8, > rem=0xcfbcc1b0) > at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #6 0x0166b6f4 in ThreadPThread__CommonSleep () > at ../src/thread/PTHREAD/ThreadPThread.m3:651 > #7 0x0166d355 in ThreadPThread__StopWorld () > at ../src/thread/PTHREAD/ThreadPThread.m3:1142 > #8 0x0166c9c3 in ThreadF__SuspendOthers () > at ../src/thread/PTHREAD/ThreadPThread.m3:918 > #9 0x0164e70b in RTCollector__CollectSomeInStateZero () > at ../src/runtime/common/RTCollector.m3:747 > #10 0x0164e6ca in RTCollector__CollectSome () > at ../src/runtime/common/RTCollector.m3:721 > #11 0x0164e161 in RTCollector__CollectEnough (M3_AicXUJ_allocator=1 > '\001') > ---Type to continue, or q to quit--- > at ../src/runtime/common/RTCollector.m3:653 > #12 0x01650cb7 in RTCollector__LongAlloc (M3_Cwb5VA_dataSize=92, > M3_Cwb5VA_dataAlignment=4, M3_CAzbsM_pool=0x86770ab8) > at ../src/runtime/common/RTCollector.m3:1438 > #13 0x01650b14 in RTHeapRep__AllocTraced (M3_Cwb5VA_dataSize=92, > M3_Cwb5VA_dataAlignment=4, M3_CAzbsM_pool=0x86770ab8) > at ../src/runtime/common/RTCollector.m3:1400 > #14 0x01645b47 in RTAllocator__GetOpenArray (M3_Eic7CK_def=0x216259d0, > M3_ANmeAM_s=0xcfbcc4fc) at ../src/runtime/common/ > RTAllocator.m3:292 > #15 0x01644e3c in RTHooks__AllocateOpenArray > (M3_AJWxb1_defn=0x216259d0, > M3_ANmeAM_s=0xcfbcc4fc) at ../src/runtime/common/ > RTAllocator.m3:141 > #16 0x0c4b364f in RandomPerm__HQInit (M3_AMLmtL_t=0x7eed1fb0, > M3_Cwb5VA_n=21, > M3_BUCfej_r=0x7eecb0f4) at ../src/random/Common/RandomPerm.m3:55 > #17 0x1c00489e in RandomTest__TestPerm () at ../src/RandomTest.m3:367 > #18 0x1c0015f7 in RandomTest__Main () at ../src/RandomTest.m3:64 > #19 0x1c00595c in RandomTest_M3 (M3_AcxOUs_mode=1) at ../src/ > RandomTest.m3:458 > #20 0x01658a19 in RTLinker__RunMainBody (M3_DjPxE3_m=0x3c001660) > at ../src/runtime/common/RTLinker.m3:400 > #21 0x01657dd3 in RTLinker__AddUnitI (M3_DjPxE3_m=0x3c001660) > at ../src/runtime/common/RTLinker.m3:114 > #22 0x01657e61 in RTLinker__AddUnit (M3_DjPxE5_b=0x1c00588c) > at ../src/runtime/common/RTLinker.m3:123 > #23 0x1c001206 in main (argc=2, argv=0xcfbccadc, envp=0xcfbccae8) > at _m3main.mc:4 > > > While the other thread is in: > > > Thread 2 (process 5611, thread 0x7fc1d400): > #0 _thread_kern_sched (scp=0x0) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:482 > #1 0x04ab5200 in _thread_kern_sched_state_unlock (state=PS_SIGTHREAD, > lock=0x7fc1d4b0, fname=0x1
, lineno=1) > at /usr/src/lib/libpthread/uthread/uthread_kern.c:581 > #2 0x04ab2bc9 in pthread_cond_wait (cond=0x80dda100, > mutex=0x80dda1e0) > at /usr/src/lib/libpthread/uthread/uthread_cond.c:261 > #3 0x01668b89 in ThreadPThread__XWait (M3_BXP32l_self=0x7eeff13c, > M3_AYIbX3_m=0x7eecb018, M3_Bl0jv4_c=0x7eecb06c, > M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ > ThreadPThread.m3:227 > #4 0x01669235 in Thread__Wait (M3_AYIbX3_m=0x7eecb018, > M3_Bl0jv4_c=0x7eecb06c) at ../src/thread/PTHREAD/ > ThreadPThread.m3:278 > #5 0x0c4c1de7 in AutoFlushWr__Worker (M3_EMTrVz_cl=0x7eeff134) > at ../src/rw/AutoFlushWr.m3:210 > #6 0x0166acfb in ThreadPThread__RunThread (M3_BeUkBA_me=0x86770b00) > at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #7 0x0166aa26 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x86770b00) > at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #8 0x04aac37f in _thread_start () > at /usr/src/lib/libpthread/uthread/uthread_create.c:240 > #9 0x0000002b in ?? () > #10 0x00000000 in ?? () > > > Maybe AutoFlushWr needs more work? > (It was crashing on platforms it didn't hang on.) > > I'll try to dig around more here.. > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Aug 31 19:16:43 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 31 Aug 2009 19:16:43 +0200 Subject: [M3devel] Pickling problem from 64 to 32 bit platforms Message-ID: <20090831191643.7djdygpgg08wksko@mail.elegosoft.com> I think we've got a problem with pickles from 64 to 32 bit target platforms. Details can be found in https://projects.elego.de/cm3/ticket/1068. Pickle experts should have a look at that. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney.m.bates at cox.net Mon Aug 31 23:37:31 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Mon, 31 Aug 2009 16:37:31 -0500 Subject: [M3devel] Pickling problem from 64 to 32 bit platforms In-Reply-To: <20090831191643.7djdygpgg08wksko@mail.elegosoft.com> References: <20090831191643.7djdygpgg08wksko@mail.elegosoft.com> Message-ID: <4A9C429B.9070308@cox.net> Some initial observations: I don't understand the circumstances where this is happening. "pickles from 64 to 32 bit" sounds to me like the pickle was written on a 64-bit machine and read on a 32-bit machine. But the backtrace seems to be of a run on a 64-bit machine, in part because of the filename in the outermost frame: #38 0x0000000000408409 in _start () at ../sysdeps/x86_64/elf/start.S:113 ^^^^^^ and in part, because all the hexadecimal addresses are 64-bit values. This example seems to be using version 1 of pickles: #5 0x000000000045ac12 in ReadRef (reader=16_00000000025b2018) at ../src/pickle/ver1/Pickle.m3:529 ^^^^ Without some vetting, I can't say for sure, but I'm not sure this version ever did all the cross-target stuff completely. Did this case work earlier under the same circumstances? The len parameter to String8.Hash has surely gone bad. Could there something wrong with operations on CARDINAL on 64-bit machines? What is the symptom of the failure? What needs to be run to reproduce it? Olaf Wagner wrote: > I think we've got a problem with pickles from 64 to 32 bit > target platforms. Details can be found in > https://projects.elego.de/cm3/ticket/1068. > > Pickle experts should have a look at that. > > Olaf