From hendrik at topoi.pooq.com Tue Apr 1 00:56:38 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 31 Mar 2008 18:56:38 -0400 Subject: [M3devel] target naming again..DJGPP? In-Reply-To: References: <1206874390.7023.16.camel@faramir.m3w.org> Message-ID: <20080331225638.GA12935@topoi.pooq.com> On Sun, Mar 30, 2008 at 03:38:28PM +0000, Jay wrote: > The environment variable is still "AMD64" on Windows machines with Intel CPUs. It can't change, for compatibility. > The headers mention AMD64 repeatedly. And it's the name of the platform on Debian Linux. -- hendrik From hosking at cs.purdue.edu Tue Apr 1 01:01:01 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 31 Mar 2008 19:01:01 -0400 Subject: [M3devel] target naming again..DJGPP? In-Reply-To: <20080331225638.GA12935@topoi.pooq.com> References: <1206874390.7023.16.camel@faramir.m3w.org> <20080331225638.GA12935@topoi.pooq.com> Message-ID: On Linux you get x86_64-pc-linux-gnu. This is on an AMD box: zed 52 $ gcc --version gcc (GCC) 4.1.2 (Gentoo 4.1.2 p1.0.2) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. zed 53 $ gcc --verbose Using built-in specs. Target: x86_64-pc-linux-gnu Configured with: /scratch/portage/tmp/portage/sys-devel/gcc-4.1.2/work/ gcc-4.1.2/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/ gcc-bin/4.1.2 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/ include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.2 -- mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.2/man --infodir=/ usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.2/info --with-gxx-include- dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include/g++-v4 -- host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-nls --with-system-zlib --disable-checking --disable-werror -- enable-secureplt --disable-libunwind-exceptions --enable-multilib -- enable-libmudflap --disable-libssp --enable-java-awt=gtk --enable- languages=c,c++,java,treelang,fortran --enable-shared --enable- threads=posix --enable-__cxa_atexit --enable-clocale=gnu Thread model: posix gcc version 4.1.2 (Gentoo 4.1.2 p1.0.2) 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 Mar 31, 2008, at 6:56 PM, hendrik at topoi.pooq.com wrote: > On Sun, Mar 30, 2008 at 03:38:28PM +0000, Jay wrote: >> The environment variable is still "AMD64" on Windows machines with >> Intel CPUs. It can't change, for compatibility. >> The headers mention AMD64 repeatedly. > > And it's the name of the platform on Debian Linux. > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Tue Apr 1 01:08:08 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 31 Mar 2008 19:08:08 -0400 Subject: [M3devel] target naming again..DJGPP? In-Reply-To: References: <1206874390.7023.16.camel@faramir.m3w.org> <20080331225638.GA12935@topoi.pooq.com> Message-ID: <20080331230808.GC12532@topoi.pooq.com> On Mon, Mar 31, 2008 at 07:01:01PM -0400, Tony Hosking wrote: > On Linux you get x86_64-pc-linux-gnu. This is on an AMD box: > Interesting. Linux's naming seems to be inconsistent with gcc. hendrik at april:~$ uname -a Linux april 2.6.18-3-amd64 #1 SMP Mon Dec 4 17:04:37 CET 2006 x86_64 GNU/Linux hendrik at april:~$ but hendrik at april:~$ gcc --verbose Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release x86_64-linux-gnu Thread model: posix gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) hendrik at april:~$ -- hendrik From hosking at cs.purdue.edu Tue Apr 1 01:26:03 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 31 Mar 2008 19:26:03 -0400 Subject: [M3devel] target naming again..DJGPP? In-Reply-To: <20080331230808.GC12532@topoi.pooq.com> References: <1206874390.7023.16.camel@faramir.m3w.org> <20080331225638.GA12935@topoi.pooq.com> <20080331230808.GC12532@topoi.pooq.com> Message-ID: Umm... zed 51 $ uname -a Linux zed.cs.purdue.edu 2.6.23.16 #2 SMP Mon Feb 11 13:01:13 EST 2008 x86_64 Intel(R) Xeon(R) CPU E5310 @ 1.60GHz GenuineIntel GNU/Linux On Mar 31, 2008, at 7:08 PM, hendrik at topoi.pooq.com wrote: > On Mon, Mar 31, 2008 at 07:01:01PM -0400, Tony Hosking wrote: >> On Linux you get x86_64-pc-linux-gnu. This is on an AMD box: >> > > Interesting. Linux's naming seems to be inconsistent with gcc. > > hendrik at april:~$ uname -a > Linux april 2.6.18-3-amd64 #1 SMP Mon Dec 4 17:04:37 CET 2006 x86_64 > GNU/Linux > hendrik at april:~$ > > but > > hendrik at april:~$ gcc --verbose > Using built-in specs. > Target: x86_64-linux-gnu > Configured with: ../src/configure -v > --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr > --enable-shared --with-system-zlib --libexecdir=/usr/lib > --without-included-gettext --enable-threads=posix --enable-nls > --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu > --enable-libstdcxx-debug --enable-mpfr --enable-checking=release > x86_64-linux-gnu > Thread model: posix > gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) > hendrik at april:~$ > > > -- hendrik From wagner at elegosoft.com Tue Apr 1 14:39:00 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 01 Apr 2008 14:39:00 +0200 Subject: [M3devel] cm3 for 64 bit linux In-Reply-To: <47F1BF9D.2010803@sirfrt.com.au> References: <47F1BF9D.2010803@sirfrt.com.au> Message-ID: <20080401143900.hmb8fm7ls0s0ks4c@mail.elegosoft.com> Quoting peter mckinna : > Hey, > > I tried to install the linuxlibc6 on my new debian phenom box running > 64 bit linux and had errors > in the assembler for rthooks mostly something about push and pop > invalid length > So I was wondering if you plan to support a 64 bit modula3 distribution? Support for 64 bit targets is definitely on the todo list, but there is no finished port yet. I wonder if it might be possible to get a 32 bit version to run as a workaround though. Perhaps others on the m3devel list have some experience there? It would also be helpful if you could send the exact action and errors to the list. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Tue Apr 1 15:12:04 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 1 Apr 2008 09:12:04 -0400 Subject: [M3devel] cm3 for 64 bit linux In-Reply-To: <20080401143900.hmb8fm7ls0s0ks4c@mail.elegosoft.com> References: <47F1BF9D.2010803@sirfrt.com.au> <20080401143900.hmb8fm7ls0s0ks4c@mail.elegosoft.com> Message-ID: I have Modula-3 running in 32-bit mode on our x86_64 SMP boxes at Purdue. I just checked in the changes needed for the LINUXLIBC6 config file to do this. You can easily bootstrap from the existing LINUXLIBC6 binary distribution. 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 Apr 1, 2008, at 8:39 AM, Olaf Wagner wrote: > Quoting peter mckinna : > >> Hey, >> >> I tried to install the linuxlibc6 on my new debian phenom box >> running >> 64 bit linux and had errors >> in the assembler for rthooks mostly something about push and pop >> invalid length >> So I was wondering if you plan to support a 64 bit modula3 >> distribution? > > Support for 64 bit targets is definitely on the todo list, but there > is > no finished port yet. I wonder if it might be possible to get a 32 bit > version to run as a workaround though. Perhaps others on the m3devel > list have some experience there? > > It would also be helpful if you could send the exact action and errors > to the list. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Tue Apr 1 21:01:55 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 1 Apr 2008 15:01:55 -0400 Subject: [M3devel] target naming again..DJGPP? In-Reply-To: References: <1206874390.7023.16.camel@faramir.m3w.org> <20080331225638.GA12935@topoi.pooq.com> <20080331230808.GC12532@topoi.pooq.com> Message-ID: <20080401190155.GB14168@topoi.pooq.com> On Mon, Mar 31, 2008 at 07:26:03PM -0400, Tony Hosking wrote: > Umm... > > zed 51 $ uname -a > Linux zed.cs.purdue.edu 2.6.23.16 #2 SMP Mon Feb 11 13:01:13 EST 2008 > x86_64 Intel(R) Xeon(R) CPU E5310 @ 1.60GHz GenuineIntel GNU/Linux Interesting. I'm running Debian etch on a real AMD processor. Could it be you have a 64-bit Intel processor? Could there be a subtle difference between the processors? Or might you be using a different Linux distribution, that might use different terminology? Puzzling. -- hendrik From ndantam at purdue.edu Tue Apr 1 21:52:46 2008 From: ndantam at purdue.edu (Neil Thomas Dantam) Date: Tue, 01 Apr 2008 15:52:46 -0400 Subject: [M3devel] target naming again..DJGPP? In-Reply-To: <20080401190155.GB14168@topoi.pooq.com> References: <1206874390.7023.16.camel@faramir.m3w.org> <20080331225638.GA12935@topoi.pooq.com> <20080331230808.GC12532@topoi.pooq.com> <20080401190155.GB14168@topoi.pooq.com> Message-ID: <47F2928E.5010001@purdue.edu> hendrik at topoi.pooq.com wrote: > On Mon, Mar 31, 2008 at 07:26:03PM -0400, Tony Hosking wrote: >> Umm... >> >> zed 51 $ uname -a >> Linux zed.cs.purdue.edu 2.6.23.16 #2 SMP Mon Feb 11 13:01:13 EST 2008 >> x86_64 Intel(R) Xeon(R) CPU E5310 @ 1.60GHz GenuineIntel GNU/Linux > > Interesting. I'm running Debian etch on a real AMD processor. Could it > be you have a 64-bit Intel processor? Could there be a subtle > difference between the processors? Or might you be using a different > Linux distribution, that might use different terminology? My understanding of these names are as follows: - AMD started calling it's new architecture x86_64 - The Linux Kernel chose to call it's support for the the architecture x86_64 - AMD then changed the architecture name to AMD64 so that they could trademark it - Some Linux Distributions choose to call the architecture AMD64, perhaps to give credit to AMD - Sun and Microsoft marketing call the architecture x64, perhaps just to be contrary The instruction set should be the same for Intel and AMD, modulo extensions like SSE3/4 and virtualization. The differing names are the result of AMD changing the name of the architecture and different developers choosing to use the original or modified name. Also, for linux kernel version "2.6.18-3-amd64", the "-3-amd64" part is a patch version tag added by the distribution maintainer. -- Neil From hosking at cs.purdue.edu Wed Apr 2 01:12:00 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 1 Apr 2008 19:12:00 -0400 Subject: [M3devel] target naming again..DJGPP? In-Reply-To: <20080401190155.GB14168@topoi.pooq.com> References: <1206874390.7023.16.camel@faramir.m3w.org> <20080331225638.GA12935@topoi.pooq.com> <20080331230808.GC12532@topoi.pooq.com> <20080401190155.GB14168@topoi.pooq.com> Message-ID: Even more amusing: http://www.x86-64.org/ On Apr 1, 2008, at 3:01 PM, hendrik at topoi.pooq.com wrote: > On Mon, Mar 31, 2008 at 07:26:03PM -0400, Tony Hosking wrote: >> Umm... >> >> zed 51 $ uname -a >> Linux zed.cs.purdue.edu 2.6.23.16 #2 SMP Mon Feb 11 13:01:13 EST 2008 >> x86_64 Intel(R) Xeon(R) CPU E5310 @ 1.60GHz GenuineIntel GNU/Linux > > Interesting. I'm running Debian etch on a real AMD processor. > Could it > be you have a 64-bit Intel processor? Could there be a subtle > difference between the processors? Or might you be using a different > Linux distribution, that might use different terminology? > > Puzzling. > > -- hendrik From hendrik at topoi.pooq.com Wed Apr 2 12:01:04 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 2 Apr 2008 06:01:04 -0400 Subject: [M3devel] target naming again..DJGPP? In-Reply-To: References: <1206874390.7023.16.camel@faramir.m3w.org> <20080331225638.GA12935@topoi.pooq.com> <20080331230808.GC12532@topoi.pooq.com> <20080401190155.GB14168@topoi.pooq.com> Message-ID: <20080402100104.GA16148@topoi.pooq.com> On Tue, Apr 01, 2008 at 07:12:00PM -0400, Tony Hosking wrote: > Even more amusing: http://www.x86-64.org/ I gather that the amusing thing about x86-64.org is that they seem to talk only about AMD64? -- hendrik From hosking at cs.purdue.edu Wed Apr 2 16:03:46 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 2 Apr 2008 10:03:46 -0400 Subject: [M3devel] target naming again..DJGPP? In-Reply-To: <20080402100104.GA16148@topoi.pooq.com> References: <1206874390.7023.16.camel@faramir.m3w.org> <20080331225638.GA12935@topoi.pooq.com> <20080331230808.GC12532@topoi.pooq.com> <20080401190155.GB14168@topoi.pooq.com> <20080402100104.GA16148@topoi.pooq.com> Message-ID: Precisely! :-) Anyway, given that the target would be to both AMD and Intel versions of x86_64/AMD64 perhaps it is best to go with a neutral name. To that end, x86_64 is probably preferable to AMD64. On Apr 2, 2008, at 6:01 AM, hendrik at topoi.pooq.com wrote: > On Tue, Apr 01, 2008 at 07:12:00PM -0400, Tony Hosking wrote: >> Even more amusing: http://www.x86-64.org/ > > I gather that the amusing thing about x86-64.org is that they seem to > talk only about AMD64? > > -- hendrik From jayk123 at hotmail.com Wed Apr 2 23:35:09 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 2 Apr 2008 21:35:09 +0000 Subject: [M3devel] target naming again..DJGPP? In-Reply-To: References: <1206874390.7023.16.camel@faramir.m3w.org> <20080331225638.GA12935@topoi.pooq.com> <20080331230808.GC12532@topoi.pooq.com> <20080401190155.GB14168@topoi.pooq.com> <20080402100104.GA16148@topoi.pooq.com> Message-ID: AMD was the original implementor. Intel is a clone. Admittedly AMD64 is derived from Intel 8086. AMD64 ascribes credit, and is shorter, is consistent with a widespread name that is not going away (not unique in this aspect), and avoids pesky characters like '-' or '_'. I cast my one vote for AMD64 (for the second time at least :) ) - Jay > From: hosking at cs.purdue.edu> To: hendrik at topoi.pooq.com> Date: Wed, 2 Apr 2008 10:03:46 -0400> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] target naming again..DJGPP?> > Precisely! :-)> > Anyway, given that the target would be to both AMD and Intel versions > of x86_64/AMD64 perhaps it is best to go with a neutral name. To that > end, x86_64 is probably preferable to AMD64.> > On Apr 2, 2008, at 6:01 AM, hendrik at topoi.pooq.com wrote:> > > On Tue, Apr 01, 2008 at 07:12:00PM -0400, Tony Hosking wrote:> >> Even more amusing: http://www.x86-64.org/> >> > I gather that the amusing thing about x86-64.org is that they seem to> > talk only about AMD64?> >> > -- hendrik> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Apr 3 23:59:14 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 3 Apr 2008 21:59:14 +0000 Subject: [M3devel] target naming again..DJGPP? In-Reply-To: References: <1206874390.7023.16.camel@faramir.m3w.org> <20080331225638.GA12935@topoi.pooq.com> <20080331230808.GC12532@topoi.pooq.com> <20080401190155.GB14168@topoi.pooq.com> <20080402100104.GA16148@topoi.pooq.com> Message-ID: While I favor AMD64, another popular name is X64. - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; hendrik at topoi.pooq.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] target naming again..DJGPP?Date: Wed, 2 Apr 2008 21:35:09 +0000 AMD was the original implementor. Intel is a clone. Admittedly AMD64 is derived from Intel 8086. AMD64 ascribes credit, and is shorter, is consistent with a widespread name that is not going away (not unique in this aspect), and avoids pesky characters like '-' or '_'.I cast my one vote for AMD64 (for the second time at least :) ) - Jay > From: hosking at cs.purdue.edu> To: hendrik at topoi.pooq.com> Date: Wed, 2 Apr 2008 10:03:46 -0400> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] target naming again..DJGPP?> > Precisely! :-)> > Anyway, given that the target would be to both AMD and Intel versions > of x86_64/AMD64 perhaps it is best to go with a neutral name. To that > end, x86_64 is probably preferable to AMD64.> > On Apr 2, 2008, at 6:01 AM, hendrik at topoi.pooq.com wrote:> > > On Tue, Apr 01, 2008 at 07:12:00PM -0400, Tony Hosking wrote:> >> Even more amusing: http://www.x86-64.org/> >> > I gather that the amusing thing about x86-64.org is that they seem to> > talk only about AMD64?> >> > -- hendrik> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Apr 4 07:38:06 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 4 Apr 2008 05:38:06 +0000 Subject: [M3devel] environment variables..? Message-ID: for example, currently: export CM3_GCC_BACKEND=yesexport CM3_OSTYPE=POSIXexport CM3_TARGET=NT386export OMIT_GCC=yesexport CM3_ROOT=/dev2/cm3.2export CM3_INSTALL=/cm3export M3CONFIG=/dev2/cm3.2/m3-sys/cminstall/src/config/NT386GNU I propose that CM3_OMIT_GCC and CM3_CONFIG be supported. ? Support for M3CONFIG and OMIT_GCC shall remain for compatibility, reluctantly. OMIT_GCC is strictly a "scripts" thing. M3CONFIG is a cm3 thing. I would grant that M3CONFIG isn't terrible, on the theory that really cm3==m3. Anyway, I'm off to do more important stuff probably. :) (such as investigating test failures) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sat Apr 5 02:39:28 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 4 Apr 2008 20:39:28 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. Message-ID: <20080405003928.GA25238@topoi.pooq.com> I downloaded cm3-min-POSIX-LINUXLIBC6-d5.5.0.tgz, unpacked it, ran ./cminstall and got as far as checking for directory /usr/lib... found 1: /usr/lib Where are the X11 libraries? [/usr/lib](1 of 1) The libraries libX11.so libICE.so libSM.so libXt.so libXext.so libXmu.so libXaw.so are not present in the chosen directory. Would you like to change the library names? [yes] However, lovesong:/usr/lib# ls -l libX11.so* libICE.so* libSM.so* libXt.so* libXext.so* libXmu.so* libXaw.so* lrwxrwxrwx 1 root root 15 2007-12-27 21:38 libICE.so -> libICE.so.6.3.0 lrwxrwxrwx 1 root root 15 2007-12-27 21:38 libICE.so.6 -> libICE.so.6.3.0 -rw-r--r-- 1 root root 84880 2007-08-21 03:19 libICE.so.6.3.0 lrwxrwxrwx 1 root root 14 2007-12-27 21:38 libSM.so -> libSM.so.6.0.0 lrwxrwxrwx 1 root root 14 2007-12-27 21:38 libSM.so.6 -> libSM.so.6.0.0 -rw-r--r-- 1 root root 27944 2007-07-11 04:40 libSM.so.6.0.0 lrwxrwxrwx 1 root root 15 2007-12-27 15:59 libX11.so -> libX11.so.6.2.0 lrwxrwxrwx 1 root root 15 2007-12-27 15:59 libX11.so.6 -> libX11.so.6.2.0 -rw-r--r-- 1 root root 965952 2007-04-03 13:24 libX11.so.6.2.0 lrwxrwxrwx 1 root root 12 2007-12-27 21:39 libXaw.so.7 -> libXaw7.so.7 lrwxrwxrwx 1 root root 16 2008-03-25 21:35 libXext.so -> libXext.so.6.4.0 lrwxrwxrwx 1 root root 16 2008-03-25 21:35 libXext.so.6 -> libXext.so.6.4.0 -rw-r--r-- 1 root root 53788 2008-03-02 10:30 libXext.so.6.4.0 lrwxrwxrwx 1 root root 15 2008-01-30 10:01 libXmu.so.6 -> libXmu.so.6.2.0 -rw-r--r-- 1 root root 85528 2008-01-17 08:58 libXmu.so.6.2.0 lrwxrwxrwx 1 root root 14 2007-12-27 21:38 libXt.so -> libXt.so.6.0.0 lrwxrwxrwx 1 root root 14 2007-12-27 21:38 libXt.so.6 -> libXt.so.6.0.0 -rw-r--r-- 1 root root 324484 2007-05-18 18:15 libXt.so.6.0.0 lovesong:/usr/lib# -- hendrik From hosking at cs.purdue.edu Sat Apr 5 03:08:06 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 4 Apr 2008 21:08:06 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080405003928.GA25238@topoi.pooq.com> References: <20080405003928.GA25238@topoi.pooq.com> Message-ID: <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> Looks like you have a strangely configured X11 subsystem. Look at how libXaw (the one cminstall is actually looking for) is not visible in / usr/lib. On Apr 4, 2008, at 8:39 PM, hendrik at topoi.pooq.com wrote: > I downloaded cm3-min-POSIX-LINUXLIBC6-d5.5.0.tgz, unpacked it, > ran ./cminstall and got as far as > > checking for directory /usr/lib... found > > 1: /usr/lib > Where are the X11 libraries? [/usr/lib](1 of 1) > The libraries libX11.so libICE.so libSM.so libXt.so libXext.so > libXmu.so > libXaw.so are not present in the chosen directory. > Would you like to change the library names? [yes] > > > However, > > > lovesong:/usr/lib# ls -l libX11.so* libICE.so* libSM.so* libXt.so* > libXext.so* libXmu.so* libXaw.so* > lrwxrwxrwx 1 root root 15 2007-12-27 21:38 libICE.so -> > libICE.so.6.3.0 > lrwxrwxrwx 1 root root 15 2007-12-27 21:38 libICE.so.6 -> > libICE.so.6.3.0 > -rw-r--r-- 1 root root 84880 2007-08-21 03:19 libICE.so.6.3.0 > lrwxrwxrwx 1 root root 14 2007-12-27 21:38 libSM.so -> libSM.so. > 6.0.0 > lrwxrwxrwx 1 root root 14 2007-12-27 21:38 libSM.so.6 -> > libSM.so.6.0.0 > -rw-r--r-- 1 root root 27944 2007-07-11 04:40 libSM.so.6.0.0 > lrwxrwxrwx 1 root root 15 2007-12-27 15:59 libX11.so -> > libX11.so.6.2.0 > lrwxrwxrwx 1 root root 15 2007-12-27 15:59 libX11.so.6 -> > libX11.so.6.2.0 > -rw-r--r-- 1 root root 965952 2007-04-03 13:24 libX11.so.6.2.0 > lrwxrwxrwx 1 root root 12 2007-12-27 21:39 libXaw.so.7 -> > libXaw7.so.7 > lrwxrwxrwx 1 root root 16 2008-03-25 21:35 libXext.so -> > libXext.so.6.4.0 > lrwxrwxrwx 1 root root 16 2008-03-25 21:35 libXext.so.6 -> > libXext.so.6.4.0 > -rw-r--r-- 1 root root 53788 2008-03-02 10:30 libXext.so.6.4.0 > lrwxrwxrwx 1 root root 15 2008-01-30 10:01 libXmu.so.6 -> > libXmu.so.6.2.0 > -rw-r--r-- 1 root root 85528 2008-01-17 08:58 libXmu.so.6.2.0 > lrwxrwxrwx 1 root root 14 2007-12-27 21:38 libXt.so -> libXt.so. > 6.0.0 > lrwxrwxrwx 1 root root 14 2007-12-27 21:38 libXt.so.6 -> > libXt.so.6.0.0 > -rw-r--r-- 1 root root 324484 2007-05-18 18:15 libXt.so.6.0.0 > lovesong:/usr/lib# > > > -- hendrik From jayk123 at hotmail.com Sat Apr 5 21:02:01 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 5 Apr 2008 19:02:01 +0000 Subject: [M3devel] returning an array from a function?? Message-ID: How does one return a constant array of unspecified size from a function? You know, what might otherwise be a constant array in the interface, but I'd rather hide it behind a function? something like this, though I haven't found anything that compiles and runs: PROCEDURE GetPathVariableNames(): REF ARRAY OF TEXT = BEGIN RETURN ARRAY OF TEXT { (* not all of these presently have meaning but they are suggested synonyms *) (* 0123456789012345 *) (* 8*) "CM3_ROOT", (* root of source tree *) (* 8*) "M3CONFIG", (*10*) "CM3_CONFIG", (* new unimplemented synonym for M3CONFIG *) (*11*) "CM3_INSTALL", (*11*) "INSTALLROOT", (*12*) "INSTALL_ROOT", (*14*) "CM3_SOURCEROOT", (* new unimplemented synonym for CM3_ROOT *) (*15*) "CM3_INSTALLROOT", (*15*) "CM3_SOURCE_ROOT", (* new unimplemented synonym for CM3_ROOT *) (*16*) "CM3_INSTALL_ROOT" (* 0123456789012345 *) }; END GetPathVariableNames; in C I would write: char** GetWhatever() { const static char* strings[] = { "abc", "def", 0 }; return strings; } or char** GetWhatever(size_t* Count) { const static char* strings[] = { "abc", "def" }; *Count = sizeof(strings)/sizeof(strings[0]); return strings; } The client doesn't have to know if it is constant or not. It could be initialized at runtime, with a dynamic size, or not I should not have to make a copy per call. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Sat Apr 5 21:36:53 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat, 05 Apr 2008 21:36:53 +0200 (CEST) Subject: [M3devel] returning an array from a function?? In-Reply-To: References: Message-ID: On Sat, 5 Apr 2008, Jay wrote: > How does one return a constant array of unspecified size from a function? > You know, what might otherwise be a constant array in the interface, but I'd > rather hide it behind a function? Since you cannot obtain a traced pointer to an existing object, you can only create a reference as global variable, initialize it with NEW and := in the modules startup code and return that pointer by GetPathVariableNames. From jayk123 at hotmail.com Sat Apr 5 21:47:20 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 5 Apr 2008 19:47:20 +0000 Subject: [M3devel] returning an array from a function?? In-Reply-To: References: Message-ID: I made it a constant in the interface. I shouldn't have to pay for heap allocation for constants.. :( Thanks, - Jay > Date: Sat, 5 Apr 2008 21:36:53 +0200 > From: lemming at henning-thielemann.de > Subject: Re: [M3devel] returning an array from a function?? > To: jayk123 at hotmail.com > CC: m3devel at elegosoft.com > > > On Sat, 5 Apr 2008, Jay wrote: > > > How does one return a constant array of unspecified size from a function? > > You know, what might otherwise be a constant array in the interface, but I'd > > rather hide it behind a function? > > Since you cannot obtain a traced pointer to an existing object, you can > only create a reference as global variable, initialize it with NEW and := > in the modules startup code and return that pointer by > GetPathVariableNames. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sun Apr 6 15:49:33 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 6 Apr 2008 09:49:33 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> References: <20080405003928.GA25238@topoi.pooq.com> <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> Message-ID: <20080406134933.GA28414@topoi.pooq.com> On Fri, Apr 04, 2008 at 09:08:06PM -0400, Tony Hosking wrote: > Looks like you have a strangely configured X11 subsystem. Look at how > libXaw (the one cminstall is actually looking for) is not visible in / > usr/lib. So you seem to be telling me that the problem is that a symbolic link libXaw->libXaw7.so.7 is missing, even though libXaw.so.7->libXaw7.so.7 is clearly present, there's a complete suite of links for libXaw7, and, as far as I know, no other programs are having problems with this. hendrik at april:/usr/lib$ ls -l libXaw* lrwxrwxrwx 1 root root 15 2006-06-15 11:33 libXaw3d.so.6 -> libXaw3d.so.6.1 -rw-r--r-- 1 root root 367784 2006-05-03 07:20 libXaw3d.so.6.1 lrwxrwxrwx 1 root root 16 2006-09-20 11:39 libXaw7.so.7 -> libXaw7.so.7.0.0 -rw-r--r-- 1 root root 440496 2006-08-27 19:51 libXaw7.so.7.0.0 lrwxrwxrwx 1 root root 12 2006-09-20 11:39 libXaw.so.7 -> libXaw7.so.7 hendrik at april:/usr/lib$ So, since I run a pretty-well autoconfigured X installed from Debian-stable packages, and regularly updated, something must have gone wrong with one of the upgrades since the dawn of time. Or maybe Debian is just weird. I'll go on the Debian sites and try to identify the misbehaving package. Thanks. From hosking at cs.purdue.edu Sun Apr 6 17:29:48 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 6 Apr 2008 11:29:48 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080406134933.GA28414@topoi.pooq.com> References: <20080405003928.GA25238@topoi.pooq.com> <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> Message-ID: <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> You should have a link from libXaw.so, etc. 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 Apr 6, 2008, at 9:49 AM, hendrik at topoi.pooq.com wrote: > On Fri, Apr 04, 2008 at 09:08:06PM -0400, Tony Hosking wrote: >> Looks like you have a strangely configured X11 subsystem. Look at >> how >> libXaw (the one cminstall is actually looking for) is not visible >> in / >> usr/lib. > > So you seem to be telling me that the problem is that a symbolic > link libXaw->libXaw7.so.7 is missing, even though > libXaw.so.7->libXaw7.so.7 is clearly present, there's a complete suite > of links for libXaw7, and, as far as I know, no other programs are > having problems with this. > > hendrik at april:/usr/lib$ ls -l libXaw* > lrwxrwxrwx 1 root root 15 2006-06-15 11:33 libXaw3d.so.6 -> > libXaw3d.so.6.1 > -rw-r--r-- 1 root root 367784 2006-05-03 07:20 libXaw3d.so.6.1 > lrwxrwxrwx 1 root root 16 2006-09-20 11:39 libXaw7.so.7 -> > libXaw7.so.7.0.0 > -rw-r--r-- 1 root root 440496 2006-08-27 19:51 libXaw7.so.7.0.0 > lrwxrwxrwx 1 root root 12 2006-09-20 11:39 libXaw.so.7 -> > libXaw7.so.7 > hendrik at april:/usr/lib$ > > So, since I run a pretty-well autoconfigured X installed from > Debian-stable packages, and regularly updated, something must have > gone > wrong with one of the upgrades since the dawn of time. Or maybe > Debian > is just weird. I'll go on the Debian sites and try to identify the > misbehaving package. > > Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Apr 6 23:43:12 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 6 Apr 2008 21:43:12 +0000 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> References: <20080405003928.GA25238@topoi.pooq.com> <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> Message-ID: Here is birch: % ls -l /usr/lib/libXaw*lrwxrwxrwx 1 root root 15 2007-05-15 10:55 /usr/lib/libXaw3d.so.6 -> libXaw3d.so.6.1-rw-r--r-- 1 root root 290444 2006-05-03 12:21 /usr/lib/libXaw3d.so.6.1-rw-r--r-- 1 root root 342464 2006-08-27 21:27 /usr/lib/libXaw6.a lrwxrwxrwx 1 root root 16 2007-05-30 11:00 /usr/lib/libXaw6.so -> libXaw6.so.6.0.1lrwxrwxrwx 1 root root 16 2007-05-30 11:00 /usr/lib/libXaw6.so.6 -> libXaw6.so.6.0.1-rw-r--r-- 1 root root 253332 2006-08-27 21:27 /usr/lib/libXaw6.so.6.0.1lrwxrwxrwx 1 root root 16 2007-05-30 10:50 /usr/lib/libXaw7.so.7 -> libXaw7.so.7.0.0-rw-r--r-- 1 root root 363260 2006-08-27 21:27 /usr/lib/libXaw7.so.7.0.0lrwxrwxrwx 1 root root 10 2007-05-30 11:00 /usr/lib/libXaw.so -> libXaw6.solrwxrwxrwx 1 root root 12 2007-05-30 11:00 /usr/lib/libXaw.so.6 -> libXaw6.so.6lrwxrwxrwx 1 root root 12 2007-05-30 10:50 /usr/lib/libXaw.so.7 -> libXaw7.so.7 - Jay From: hosking at cs.purdue.eduTo: hendrik at topoi.pooq.comDate: Sun, 6 Apr 2008 11:29:48 -0400CC: m3devel at elegosoft.comSubject: Re: [M3devel] trouble installing on a Debian lenny system.You should have a link from libXaw.so, etc. 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 Apr 6, 2008, at 9:49 AM, hendrik at topoi.pooq.com wrote: On Fri, Apr 04, 2008 at 09:08:06PM -0400, Tony Hosking wrote: Looks like you have a strangely configured X11 subsystem. Look at how libXaw (the one cminstall is actually looking for) is not visible in / usr/lib.So you seem to be telling me that the problem is that a symbolic link libXaw->libXaw7.so.7 is missing, even though libXaw.so.7->libXaw7.so.7 is clearly present, there's a complete suite of links for libXaw7, and, as far as I know, no other programs are having problems with this.hendrik at april:/usr/lib$ ls -l libXaw*lrwxrwxrwx 1 root root 15 2006-06-15 11:33 libXaw3d.so.6 -> libXaw3d.so.6.1-rw-r--r-- 1 root root 367784 2006-05-03 07:20 libXaw3d.so.6.1lrwxrwxrwx 1 root root 16 2006-09-20 11:39 libXaw7.so.7 -> libXaw7.so.7.0.0-rw-r--r-- 1 root root 440496 2006-08-27 19:51 libXaw7.so.7.0.0lrwxrwxrwx 1 root root 12 2006-09-20 11:39 libXaw.so.7 -> libXaw7.so.7hendrik at april:/usr/lib$ So, since I run a pretty-well autoconfigured X installed from Debian-stable packages, and regularly updated, something must have gone wrong with one of the upgrades since the dawn of time. Or maybe Debian is just weird. I'll go on the Debian sites and try to identify the misbehaving package.Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Apr 7 01:39:58 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 6 Apr 2008 23:39:58 +0000 Subject: [M3devel] RTAllocator.OutOfMemory Message-ID: Is the fix really to annotate these with RAISES declarations? In the klex case, I suspect it'll percolate all the way up. And there is some "difference" between explicit calls to the allocator, vs. regular NEW? 27611 NEXT "../src/DeepCopy.m3", line 56: warning: potentially unhandled exception: RTAllocator.OutOfMemory27972 NEXT "../LINUXLIBC6/RegExpTok.m3", line 41: warning: potentially unhandled exception: RTAllocator.OutOfMemory - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Apr 7 02:38:01 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 7 Apr 2008 00:38:01 +0000 Subject: [M3devel] set relationships? Message-ID: I'm looking at test p1\p155. I haven't started debugging it, just trying to understand it. C:\dev2\cm3\doc\reference\relations.html: " infix <=, >= ... (x,y: Set) : BOOLEAN ... <= returns TRUE if every element of x is an element of y. ... The expression x >= y is equivalent to y <= x. ... In all cases, x < y means (x <= y) AND (x # y), and x > y means y < x " Let's just use the sets {1} and {2}. {1} <= {2} {2} <= {1} {1} < {2} {2} < {1} {1} >= {2} {2} >= {1} {1} > {2} {2} > {1} All these expressions are true from the definitions above. Is that reasonable? It seems a little strange to me. I guess I am very used to strongly ordered things, such that a <= b && a => b implies a == b, not true here, and you can't have both a < b and b < a, which you have here, and that (a < b) == !(a >= b) and similar, which is not true here. In this case, every relation but equality is true. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Apr 7 02:52:10 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 7 Apr 2008 00:52:10 +0000 Subject: [M3devel] set relationships? In-Reply-To: References: Message-ID: oops -- I mean they are all false. From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Mon, 7 Apr 2008 00:38:01 +0000Subject: [M3devel] set relationships? I'm looking at test p1\p155.I haven't started debugging it, just trying to understand it. C:\dev2\cm3\doc\reference\relations.html:" infix <=, >= ... (x,y: Set) : BOOLEAN ... <= returns TRUE if every element of x is an element of y....The expression x >= y is equivalent to y <= x. ...In all cases, x < y means (x <= y) AND (x # y), and x > y means y < x" Let's just use the sets {1} and {2}. {1} <= {2} {2} <= {1} {1} < {2} {2} < {1} {1} >= {2} {2} >= {1} {1} > {2} {2} > {1} All these expressions are true from the definitions above.Is that reasonable?It seems a little strange to me. I guess I am very used to strongly ordered things, such that a <= b && a => b implies a == b, not true here, and you can't have both a < b and b < a, which you have here, and that (a < b) == !(a >= b) and similar, which is not true here. In this case, every relation but equality is true. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Mon Apr 7 03:39:18 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 6 Apr 2008 21:39:18 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> References: <20080405003928.GA25238@topoi.pooq.com> <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> Message-ID: <20080407013918.GA29466@topoi.pooq.com> On Sun, Apr 06, 2008 at 11:29:48AM -0400, Tony Hosking wrote: > You should have a link from libXaw.so, etc. It turns out that link was in the package libXaw7-dev, which was missing on both my 64- and 32-bit systems. -- hendrik hendrik at lovesong:/usr/lib$ ls -l libXaw.so lrwxrwxrwx 1 root root 10 2008-04-06 20:38 libXaw.so -> libXaw7.so hendrik at lovesong:/usr/lib$ From wagner at elegosoft.com Mon Apr 7 12:03:50 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 07 Apr 2008 12:03:50 +0200 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080407013918.GA29466@topoi.pooq.com> References: <20080405003928.GA25238@topoi.pooq.com> <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> Message-ID: <20080407120350.2dkp81ly0gs0ko8s@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > On Sun, Apr 06, 2008 at 11:29:48AM -0400, Tony Hosking wrote: >> You should have a link from libXaw.so, etc. > > It turns out that link was in the package libXaw7-dev, which was missing > on both my 64- and 32-bit systems. This sounds broken to me. M3 has been changed some time ago to look for shared objects instead of archives, as the latter are often not installed on modern systems, but come only as part of development packages. But there must be a simple unique name for the resource; we cannot per default refer to libXaw.so.7.0 or similar, since this would need more updates and maintenance and would break if another version is actually installed. So I don't see a reason for this kind of link to be in the development packages. Should we report this as a bug? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 7 15:56:19 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 7 Apr 2008 09:56:19 -0400 Subject: [M3devel] RTAllocator.OutOfMemory In-Reply-To: References: Message-ID: Just put FATAL declarations to have the system die when it receives those errors. On Apr 6, 2008, at 7:39 PM, Jay wrote: > Is the fix really to annotate these with RAISES declarations? > In the klex case, I suspect it'll percolate all the way up. > And there is some "difference" between explicit calls to the > allocator, vs. regular NEW? > > 27611 NEXT "../src/DeepCopy.m3", line 56: warning: potentially > unhandled exception: RTAllocator.OutOfMemory > 27972 NEXT "../LINUXLIBC6/RegExpTok.m3", line 41: warning: > potentially unhandled exception: RTAllocator.OutOfMemory > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Apr 7 18:29:26 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 7 Apr 2008 12:29:26 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080407120350.2dkp81ly0gs0ko8s@mail.elegosoft.com> References: <20080405003928.GA25238@topoi.pooq.com> <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> <20080407120350.2dkp81ly0gs0ko8s@mail.elegosoft.com> Message-ID: Generally, you'll need all dev packages with CM3. 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 Apr 7, 2008, at 6:03 AM, Olaf Wagner wrote: > Quoting hendrik at topoi.pooq.com: > >> On Sun, Apr 06, 2008 at 11:29:48AM -0400, Tony Hosking wrote: >>> You should have a link from libXaw.so, etc. >> >> It turns out that link was in the package libXaw7-dev, which was >> missing >> on both my 64- and 32-bit systems. > > This sounds broken to me. > > M3 has been changed some time ago to look for shared objects instead > of > archives, as the latter are often not installed on modern systems, but > come only as part of development packages. > > But there must be a simple unique name for the resource; we cannot > per default refer to libXaw.so.7.0 or similar, since this would > need more updates and maintenance and would break if another version > is actually installed. > > So I don't see a reason for this kind of link to be in the development > packages. Should we report this as a bug? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Apr 7 21:28:49 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 07 Apr 2008 21:28:49 +0200 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: References: <20080405003928.GA25238@topoi.pooq.com> <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> <20080407120350.2dkp81ly0gs0ko8s@mail.elegosoft.com> Message-ID: <20080407212849.1ovvw8niaocs8g0g@mail.elegosoft.com> Quoting Tony Hosking : > Generally, you'll need all dev packages with CM3. Hm 8-/ Seems I'm not really up-to-date here... Olaf > 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 Apr 7, 2008, at 6:03 AM, Olaf Wagner wrote: > >> Quoting hendrik at topoi.pooq.com: >> >>> On Sun, Apr 06, 2008 at 11:29:48AM -0400, Tony Hosking wrote: >>>> You should have a link from libXaw.so, etc. >>> >>> It turns out that link was in the package libXaw7-dev, which was missing >>> on both my 64- and 32-bit systems. >> >> This sounds broken to me. >> >> M3 has been changed some time ago to look for shared objects instead of >> archives, as the latter are often not installed on modern systems, but >> come only as part of development packages. >> >> But there must be a simple unique name for the resource; we cannot >> per default refer to libXaw.so.7.0 or similar, since this would >> need more updates and maintenance and would break if another version >> is actually installed. >> >> So I don't see a reason for this kind of link to be in the development >> packages. Should we report this as a bug? >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Mon Apr 7 21:41:08 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 7 Apr 2008 15:41:08 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080407212849.1ovvw8niaocs8g0g@mail.elegosoft.com> References: <20080405003928.GA25238@topoi.pooq.com> <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> <20080407120350.2dkp81ly0gs0ko8s@mail.elegosoft.com> <20080407212849.1ovvw8niaocs8g0g@mail.elegosoft.com> Message-ID: <78F773EF-E82D-43B7-B402-60C854A6BDE1@cs.purdue.edu> Perhaps you're right. 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 Apr 7, 2008, at 3:28 PM, Olaf Wagner wrote: > Quoting Tony Hosking : > >> Generally, you'll need all dev packages with CM3. > > Hm 8-/ Seems I'm not really up-to-date here... > > Olaf > >> 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 Apr 7, 2008, at 6:03 AM, Olaf Wagner wrote: >> >>> Quoting hendrik at topoi.pooq.com: >>> >>>> On Sun, Apr 06, 2008 at 11:29:48AM -0400, Tony Hosking wrote: >>>>> You should have a link from libXaw.so, etc. >>>> >>>> It turns out that link was in the package libXaw7-dev, which was >>>> missing >>>> on both my 64- and 32-bit systems. >>> >>> This sounds broken to me. >>> >>> M3 has been changed some time ago to look for shared objects >>> instead of >>> archives, as the latter are often not installed on modern systems, >>> but >>> come only as part of development packages. >>> >>> But there must be a simple unique name for the resource; we cannot >>> per default refer to libXaw.so.7.0 or similar, since this would >>> need more updates and maintenance and would break if another version >>> is actually installed. >>> >>> So I don't see a reason for this kind of link to be in the >>> development >>> packages. Should we report this as a bug? >>> >>> Olaf >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>> Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Tue Apr 8 02:36:30 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 7 Apr 2008 20:36:30 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080407120350.2dkp81ly0gs0ko8s@mail.elegosoft.com> References: <20080405003928.GA25238@topoi.pooq.com> <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> <20080407120350.2dkp81ly0gs0ko8s@mail.elegosoft.com> Message-ID: <20080408003630.GA30598@topoi.pooq.com> On Mon, Apr 07, 2008 at 12:03:50PM +0200, Olaf Wagner wrote: > Quoting hendrik at topoi.pooq.com: > > >On Sun, Apr 06, 2008 at 11:29:48AM -0400, Tony Hosking wrote: > >>You should have a link from libXaw.so, etc. > > > >It turns out that link was in the package libXaw7-dev, which was missing > >on both my 64- and 32-bit systems. > > This sounds broken to me. > > M3 has been changed some time ago to look for shared objects instead of > archives, as the latter are often not installed on modern systems, but > come only as part of development packages. > > But there must be a simple unique name for the resource; we cannot > per default refer to libXaw.so.7.0 or similar, since this would > need more updates and maintenance and would break if another version > is actually installed. > > So I don't see a reason for this kind of link to be in the development > packages. Should we report this as a bug? I suppose that depends on whether the linker and loader understand the version numbers in the name and does the right thing in the absence of links. I know there's a convention as to which parts of the versin number indicate compatible vs incompatible changes. I thought that compatible alternatives could be found automatically at load time, and (I thought) the wrong alternatives would not be. I don't know whether the mechanism for this is symbolic links. I suppose it could be. So I don't know whether this is a bug. The major version number changes for incompatible changes. If the linker links a program to a particular shared library, changes in the minor version wouldn't matter, but change in the major version likely would. So I'd guess that the linker would include a reference to the particular major version in the linked binary, not a reference to the versin-free file name. Thus the version-free library name would not be needed just for running the binary. It might end up referring to an incompatible version. I could be wrong, of course. I'm just trying to guess what Debian's reasoning might have been. -- hendrik From hendrik at topoi.pooq.com Tue Apr 8 19:17:34 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 8 Apr 2008 13:17:34 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080407013918.GA29466@topoi.pooq.com> References: <20080405003928.GA25238@topoi.pooq.com> <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> Message-ID: <20080408171734.GA31674@topoi.pooq.com> On Sun, Apr 06, 2008 at 09:39:18PM -0400, hendrik at topoi.pooq.com wrote: > On Sun, Apr 06, 2008 at 11:29:48AM -0400, Tony Hosking wrote: > > You should have a link from libXaw.so, etc. > > It turns out that link was in the package libXaw7-dev, which was missing > on both my 64- and 32-bit systems. > > -- hendrik > > hendrik at lovesong:/usr/lib$ ls -l libXaw.so > lrwxrwxrwx 1 root root 10 2008-04-06 20:38 libXaw.so -> libXaw7.so > hendrik at lovesong:/usr/lib$ I resumed installation. Ths installer failed to find my odbc or my postresql, which I thought would be OK since I don't expect to need them and I didn't have them installed. I then followed the instructions on http://modula3.elegosoft.com/cm3/installation.html using the commands mkdir cm3 cd cm3 tar -zxf /path/to/cm3-src-sys-CM3VERSION.tgz tar -zxf /path/to/cm3-src-gnu-CM3VERSION.tgz tar -zxf /path/to/cm3-src-std-CM3VERSION.tgz (1) I patched to avoid the asm/ipc.h problem. (2) the last step failed as follows: hendrik at lovesong:~/cm3/scripts$ ./do-cm3-std.sh buildship CM3C = /farhome/hendrik/cm3/scripts/pkgmap.sh -c "cm3 -build -DROOT='/farhome/hendrik/cm3' && cm3 -ship -DROOT='/farhome/hendrik/cm3' " m3gc-simple m3core libm3 patternmatching m3middle m3quake m3scanner m3tools m3cgcat m3cggen m3gdb m3bundle arithmetic bitvector digraph parseparams realgeometry set slisp sortedtableextras table-list tempfiles tcp udp libsio libbuf debug listfuncs embutils m3tk-misc http binIO commandrw m3tk mtex m3totex m3tohtml m3scan m3markup m3browser cmpdir cmpfp dirfp uniq netobj netobjd stubgen events rdwr sharedobj sharedobjgen odbc postgres95 db smalldb stable stablegen X11R4 ui PEX vbtkit cmvbt jvideo videovbt web formsvbtpixmaps formsvbt formsview formsedit codeview mg mgkit opengl anim3D zeus m3zume synloc synex metasyn obliqrt obliqparse obliqprint obliq obliqlibemb obliqlibm3 obliqlibui obliqlibanim obliqsrvstd obliqsrvui obliqbinmin obliqbinstd obliqbinui obliqbinanim visualobliq vocgi voquery vorun webvbt recordheap rehearsecode replayheap showheap shownew showthread pkl-fonts juno-machine juno-compiler juno-app cube calculator fisheye mentor === package /farhome/hendrik/cm3/m3-libs/m3gc-simple === +++ cm3 -build -DROOT='/farhome/hendrik/cm3' && cm3 -ship -DROOT='/farhome/hendrik/cm3' +++ /bin/sh: line 1: 10644 Segmentation fault cm3 -build -DROOT='/farhome/hendrik/cm3' *** execution of failed *** hendrik at lovesong:~/cm3/scripts$ (my text editor wrapped the lines when I pasted them into this message)) Presumably there's something else weird about my system. Any ideas what to look for? -- hendrik From jayk123 at hotmail.com Tue Apr 8 22:16:05 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 8 Apr 2008 20:16:05 +0000 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080408171734.GA31674@topoi.pooq.com> References: <20080405003928.GA25238@topoi.pooq.com> <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> <20080408171734.GA31674@topoi.pooq.com> Message-ID: Try current source from CVS instead of the .tgz files.Be sure to delete scripts/PKGS. m3gc-simple no longer exists. - Jay > Date: Tue, 8 Apr 2008 13:17:34 -0400> From: hendrik at topoi.pooq.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] trouble installing on a Debian lenny system.> > On Sun, Apr 06, 2008 at 09:39:18PM -0400, hendrik at topoi.pooq.com wrote:> > On Sun, Apr 06, 2008 at 11:29:48AM -0400, Tony Hosking wrote:> > > You should have a link from libXaw.so, etc.> > > > It turns out that link was in the package libXaw7-dev, which was missing > > on both my 64- and 32-bit systems.> > > > -- hendrik> > > > hendrik at lovesong:/usr/lib$ ls -l libXaw.so> > lrwxrwxrwx 1 root root 10 2008-04-06 20:38 libXaw.so -> libXaw7.so> > hendrik at lovesong:/usr/lib$ > > I resumed installation. Ths installer failed to find my odbc or my > postresql, which I thought would be OK since I don't expect to need > them and I didn't have them installed.> > I then followed the instructions on > http://modula3.elegosoft.com/cm3/installation.html using the commands> > mkdir cm3> cd cm3> tar -zxf /path/to/cm3-src-sys-CM3VERSION.tgz> tar -zxf /path/to/cm3-src-gnu-CM3VERSION.tgz> tar -zxf /path/to/cm3-src-std-CM3VERSION.tgz> > > (1) I patched to avoid the asm/ipc.h problem.> (2) the last step failed as follows:> > hendrik at lovesong:~/cm3/scripts$ ./do-cm3-std.sh buildship> CM3C => /farhome/hendrik/cm3/scripts/pkgmap.sh -c "cm3 -build > -DROOT='/farhome/hendrik/cm3' && cm3 -ship > -DROOT='/farhome/hendrik/cm3' " m3gc-simple m3core libm3 patternmatching > m3middle m3quake m3scanner m3tools m3cgcat m3cggen m3gdb m3bundle > arithmetic bitvector digraph parseparams realgeometry set slisp > sortedtableextras table-list tempfiles tcp udp libsio libbuf debug > listfuncs embutils m3tk-misc http binIO commandrw m3tk mtex m3totex > m3tohtml m3scan m3markup m3browser cmpdir cmpfp dirfp uniq netobj > netobjd stubgen events rdwr sharedobj sharedobjgen odbc postgres95 db > smalldb stable stablegen X11R4 ui PEX vbtkit cmvbt jvideo videovbt web > formsvbtpixmaps formsvbt formsview formsedit codeview mg mgkit opengl > anim3D zeus m3zume synloc synex metasyn obliqrt obliqparse obliqprint > obliq obliqlibemb obliqlibm3 obliqlibui obliqlibanim obliqsrvstd > obliqsrvui obliqbinmin obliqbinstd obliqbinui obliqbinanim visualobliq > vocgi voquery vorun webvbt recordheap rehearsecode replayheap showheap > shownew showthread pkl-fonts juno-machine juno-compiler juno-app cube > calculator fisheye mentor> === package /farhome/hendrik/cm3/m3-libs/m3gc-simple ===> +++ cm3 -build -DROOT='/farhome/hendrik/cm3' && cm3 -ship > -DROOT='/farhome/hendrik/cm3' +++> /bin/sh: line 1: 10644 Segmentation fault cm3 -build > -DROOT='/farhome/hendrik/cm3'> *** execution of failed ***> hendrik at lovesong:~/cm3/scripts$ > > > (my text editor wrapped the lines when I pasted them into this message))> > Presumably there's something else weird about my system.> > Any ideas what to look for?> > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Wed Apr 9 01:15:41 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 8 Apr 2008 19:15:41 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: References: <20080405003928.GA25238@topoi.pooq.com> <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> <20080408171734.GA31674@topoi.pooq.com> Message-ID: <20080408231541.GA31929@topoi.pooq.com> On Tue, Apr 08, 2008 at 08:16:05PM +0000, Jay wrote: > Try current source from CVS instead of the .tgz files.Be sure to delete scripts/PKGS. > m3gc-simple no longer exists. > > - Jay Did that. Used cvs -z 3 -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 as described in http://modula3.elegosoft.com/cm3/install-cm3-on-ubuntu-7-10.html (although I have Debian) and got hendrik at lovesong:~/cm3/scripts$ ./do-cm3-core.sh buildship making /farhome/hendrik/cm3/scripts/PKGS (slow but rare) /farhome/hendrik/cm3/scripts/pkgmap.sh -c "cm3 -build -DROOT='/farhome/hendrik/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' && cm3 -ship -DROOT='/farhome/hendrik/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' " import-libs m3cc m3core libm3 patternmatching sysutils unittest m3middle m3objfile m3linker m3back m3staloneback m3front m3quake cm3 m3scanner m3tools m3cgcat m3cggen m3bundle mklib fix_nl libdump bitvector digraph parseparams realgeometry set slisp sortedtableextras table-list tempfiles tcl === package /farhome/hendrik/cm3/m3-win/import-libs === === package omitted on this platform === ==> /farhome/hendrik/cm3/m3-win/import-libs done === package /farhome/hendrik/cm3/m3-sys/m3cc === +++ cm3 -build -DROOT='/farhome/hendrik/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' && cm3 -ship -DROOT='/farhome/hendrik/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' +++ /bin/sh: line 1: 30590 Segmentation fault cm3 -build -DROOT='/farhome/hendrik/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' *** execution of cm3 -build -DROOT='/farhome/hendrik/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' && cm3 -ship -DROOT='/farhome/hendrik/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' failed *** hendrik at lovesong:~/cm3/scripts$ -- hendrik Perhaps I have to wipe /usr/local/cm3 and start again with the cm3-install script? - hendrik From hendrik at topoi.pooq.com Wed Apr 9 01:33:38 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 8 Apr 2008 19:33:38 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080408231541.GA31929@topoi.pooq.com> References: <20080405003928.GA25238@topoi.pooq.com> <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> <20080408171734.GA31674@topoi.pooq.com> <20080408231541.GA31929@topoi.pooq.com> Message-ID: <20080408233338.GA32037@topoi.pooq.com> On Tue, Apr 08, 2008 at 07:15:41PM -0400, hendrik at topoi.pooq.com wrote: > > Perhaps I have to wipe /usr/local/cm3 and start again with the > cm3-install script? > > - hendrik Now doing that. It seems to be working better now. -- hendrik From hendrik at topoi.pooq.com Wed Apr 9 02:02:07 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 8 Apr 2008 20:02:07 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080408233338.GA32037@topoi.pooq.com> References: <20080405003928.GA25238@topoi.pooq.com> <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> <20080408171734.GA31674@topoi.pooq.com> <20080408231541.GA31929@topoi.pooq.com> <20080408233338.GA32037@topoi.pooq.com> Message-ID: <20080409000207.GA32073@topoi.pooq.com> On Tue, Apr 08, 2008 at 07:33:38PM -0400, hendrik at topoi.pooq.com wrote: > On Tue, Apr 08, 2008 at 07:15:41PM -0400, hendrik at topoi.pooq.com wrote: > > > > Perhaps I have to wipe /usr/local/cm3 and start again with the > > cm3-install script? > > > > - hendrik > > Now doing that. It seems to be working better now. > > -- hendrik > Everything went fine until new source -> compiling Cstdlib.i3 "../src/word/LongRep.i3", line 2: undefined (LONGINT) "../src/C/32BITS/BasicCtypes.i3", line 18: undefined (LONGINT) "../src/C/Common/Cstdlib.i3", line 13: imported interface contains errors (Ctypes) 3 errors encountered It looks as if LONGINT isn't defined. This is within package === package /farhome/hendrik/cm3/m3-libs/m3core === At this point I presume it is still using the cminstalled compiler. Does that need to be nudged?. -- hendrik From hendrik at topoi.pooq.com Wed Apr 9 02:33:29 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 8 Apr 2008 20:33:29 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080409000207.GA32073@topoi.pooq.com> References: <20080405003928.GA25238@topoi.pooq.com> <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> <20080408171734.GA31674@topoi.pooq.com> <20080408231541.GA31929@topoi.pooq.com> <20080408233338.GA32037@topoi.pooq.com> <20080409000207.GA32073@topoi.pooq.com> Message-ID: <20080409003329.GB32073@topoi.pooq.com> On Tue, Apr 08, 2008 at 08:02:07PM -0400, hendrik at topoi.pooq.com wrote: > > At this point I presume it is still using the cminstalled compiler. > Does that need to be nudged?. > > -- hendrik > I obtained another cminstall, from ../cm3-min-POSIX-LINUXLIBC6-d5.7.0-2008-04-08-14-00-05.tgz Tried it. It rushed through the dialogues without giving me a chance to answer anything. (Is this a bug?) It even found odbc and postgres95, which I thought hadn't been installed. Where are the Postgres95 libraries? looking for library file(s): libpq.so checking for library files in directory /usr/lib... not found checking for library files in directory /usr/local/postgres95/lib... not found checking for library files in directory /usr/local/lib... not found checking for directory /usr/lib... found --> "-L/usr/lib" But, hendrik at lovesong:~$ ls /usr/lib/libpq* ls: cannot access /usr/lib/libpq*: No such file or directory hendrik at lovesong:~$ and Where are the ODBC libraries? looking for library file(s): libiodbc.so checking for library files in directory /usr/lib... not found checking for library files in directory /usr/local/lib... not found checking for library files in directory /usr/local/pgsql/lib... not found checking for library files in directory /usr/local/postgres95/lib... not found checking for directory /usr/lib... found --> "-L/usr/lib" but hendrik at lovesong:~$ ls /usr/lib/libio* ls: cannot access /usr/lib/libio*: No such file or directory hendrik at lovesong:~$ Finding these two nonexistent files does seem to be a bug. -- hendrik From jay.krell at cornell.edu Wed Apr 9 02:57:39 2008 From: jay.krell at cornell.edu (Jay) Date: Wed, 9 Apr 2008 00:57:39 +0000 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080409003329.GB32073@topoi.pooq.com> References: <20080405003928.GA25238@topoi.pooq.com> <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> <20080408171734.GA31674@topoi.pooq.com> <20080408231541.GA31929@topoi.pooq.com> <20080408233338.GA32037@topoi.pooq.com> <20080409000207.GA32073@topoi.pooq.com> <20080409003329.GB32073@topoi.pooq.com> Message-ID: "Rushing through the dialogues" is a new feature. I kept complaining about how dumb it was. On NT386* at least, I stopped using cminstall altogether. There is an -interactive option or somesuch. - Jay > Date: Tue, 8 Apr 2008 20:33:29 -0400> From: hendrik at topoi.pooq.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] trouble installing on a Debian lenny system.> > On Tue, Apr 08, 2008 at 08:02:07PM -0400, hendrik at topoi.pooq.com wrote:> > > > At this point I presume it is still using the cminstalled compiler. > > Does that need to be nudged?.> > > > -- hendrik> > > > I obtained another cminstall, from > ../cm3-min-POSIX-LINUXLIBC6-d5.7.0-2008-04-08-14-00-05.tgz> > Tried it. It rushed through the dialogues without giving me a chance to > answer anything. (Is this a bug?) It even found odbc and postgres95, > which I thought hadn't been installed.> > Where are the Postgres95 libraries?> looking for library file(s): libpq.so> checking for library files in directory /usr/lib... not found> checking for library files in directory /usr/local/postgres95/lib... not > found> checking for library files in directory /usr/local/lib... not found> checking for directory /usr/lib... found > --> "-L/usr/lib"> > > But, > > hendrik at lovesong:~$ ls /usr/lib/libpq*> ls: cannot access /usr/lib/libpq*: No such file or directory> hendrik at lovesong:~$ > > > and > > Where are the ODBC libraries?> looking for library file(s): libiodbc.so> checking for library files in directory /usr/lib... not found> checking for library files in directory /usr/local/lib... not found> checking for library files in directory /usr/local/pgsql/lib... not > found> checking for library files in directory /usr/local/postgres95/lib... not > found> checking for directory /usr/lib... found > --> "-L/usr/lib"> > but> > hendrik at lovesong:~$ ls /usr/lib/libio*> ls: cannot access /usr/lib/libio*: No such file or directory> hendrik at lovesong:~$ > > Finding these two nonexistent files does seem to be a bug.> > -- hendrik> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Apr 9 03:00:20 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 9 Apr 2008 01:00:20 +0000 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080409000207.GA32073@topoi.pooq.com> References: <20080405003928.GA25238@topoi.pooq.com> <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> <20080408171734.GA31674@topoi.pooq.com> <20080408231541.GA31929@topoi.pooq.com> <20080408233338.GA32037@topoi.pooq.com> <20080409000207.GA32073@topoi.pooq.com> Message-ID: Right. This is a normal symptom of using an "old" compiler to compile current source. You must first build a new compiler against an old runtime (which you must get from "somewhere", such as an existing older install), then use that to build a new runtime. scripts/upgrade.sh scripts/python/upgrade.py scripts/win/upgrade.cmd should all handle the "dance" for you. - Jay > Date: Tue, 8 Apr 2008 20:02:07 -0400> From: hendrik at topoi.pooq.com > "../src/word/LongRep.i3", line 2: undefined (LONGINT)> "../src/C/32BITS/BasicCtypes.i3", line 18: undefined (LONGINT)> "../src/C/Common/Cstdlib.i3", line 13: imported interface contains errors (Ctypes)> 3 errors encountered> > At this point I presume it is still using the cminstalled compiler. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Wed Apr 9 03:14:18 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 8 Apr 2008 21:14:18 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: References: <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> <20080408171734.GA31674@topoi.pooq.com> <20080408231541.GA31929@topoi.pooq.com> <20080408233338.GA32037@topoi.pooq.com> <20080409000207.GA32073@topoi.pooq.com> Message-ID: <20080409011418.GC32073@topoi.pooq.com> On Wed, Apr 09, 2008 at 01:00:20AM +0000, Jay wrote: > Right. > This is a normal symptom of using an "old" compiler to compile current source. > You must first build a new compiler against an old runtime (which you must get from "somewhere", such as an existing older install), then use that to build a new runtime. > > scripts/upgrade.sh > scripts/python/upgrade.py > scripts/win/upgrade.cmd > > should all handle the "dance" for you. > > - Jay Except I don't *have* a working old runtime. I've mentioned my experiences with ../cm3-min-POSIX-LINUXLIBC6-d5.7.0-2008-04-08-14-00-05.tgz in another post. I acquired it in the hope that it wouldn't be an old runtime. -- hendrik > > > > > Date: Tue, 8 Apr 2008 20:02:07 -0400> From: hendrik at topoi.pooq.com > > "../src/word/LongRep.i3", line 2: undefined (LONGINT)> "../src/C/32BITS/BasicCtypes.i3", line 18: undefined (LONGINT)> "../src/C/Common/Cstdlib.i3", line 13: imported interface contains errors (Ctypes)> 3 errors encountered> > At this point I presume it is still using the cminstalled compiler. From hendrik at topoi.pooq.com Wed Apr 9 03:17:42 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 8 Apr 2008 21:17:42 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: References: <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> <20080408171734.GA31674@topoi.pooq.com> <20080408231541.GA31929@topoi.pooq.com> <20080408233338.GA32037@topoi.pooq.com> <20080409000207.GA32073@topoi.pooq.com> <20080409003329.GB32073@topoi.pooq.com> Message-ID: <20080409011742.GD32073@topoi.pooq.com> On Wed, Apr 09, 2008 at 12:57:39AM +0000, Jay wrote: > "Rushing through the dialogues" is a new feature. I kept complaining about how dumb it was. On NT386* at least, I stopped using cminstall altogether. There is an -interactive option or somesuch. > > - Jay > But I suspect finding nonexistent files isn't a feature, new or old. Is it going to cause trouble later on? Is it going to try to install things that depend on postgres and odbc and fall apart? -- hendrik From hendrik at topoi.pooq.com Wed Apr 9 03:24:11 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 8 Apr 2008 21:24:11 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080409011742.GD32073@topoi.pooq.com> References: <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> <20080408171734.GA31674@topoi.pooq.com> <20080408231541.GA31929@topoi.pooq.com> <20080408233338.GA32037@topoi.pooq.com> <20080409000207.GA32073@topoi.pooq.com> <20080409003329.GB32073@topoi.pooq.com> <20080409011742.GD32073@topoi.pooq.com> Message-ID: <20080409012411.GE32073@topoi.pooq.com> On Tue, Apr 08, 2008 at 09:17:42PM -0400, hendrik at topoi.pooq.com wrote: > On Wed, Apr 09, 2008 at 12:57:39AM +0000, Jay wrote: > > "Rushing through the dialogues" is a new feature. I kept complaining > about how dumb it was. On NT386* at least, I stopped using cminstall > altogether. There is an -interactive option or somesuch. > > > > > - Jay > > > > But I suspect finding nonexistent files isn't a feature, new or old. Is > it going to cause trouble later on? Is it going to try to install > things that depend on postgres and odbc and fall apart? The -interactive option gives me interaction. But it still finds the nonexistent libpq.so in /usr/lib. Where are the Postgres95 libraries? looking for library file(s): libpq.so checking for library files in directory /usr/lib... not found checking for library files in directory /usr/local/postgres95/lib... not found checking for library files in directory /usr/local/lib... not found checking for directory /usr/lib... found 1: /usr/lib Where are the Postgres95 libraries? [/usr/lib](1 of 1) Only after I accept the default location does it notice threre's no such file there. I find this confusing, because it correctly fails to find in in all the other locations. But I guess I can live with this, because it gives me the chance to say: The libraries libpq.so are not present in the chosen directory. Would you like to change the library names? [yes] no Would you like to continue nonetheless? [yes] yes Thanks. -- hendrik From hendrik at topoi.pooq.com Wed Apr 9 04:25:29 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 8 Apr 2008 22:25:29 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080409012411.GE32073@topoi.pooq.com> References: <20080407013918.GA29466@topoi.pooq.com> <20080408171734.GA31674@topoi.pooq.com> <20080408231541.GA31929@topoi.pooq.com> <20080408233338.GA32037@topoi.pooq.com> <20080409000207.GA32073@topoi.pooq.com> <20080409003329.GB32073@topoi.pooq.com> <20080409011742.GD32073@topoi.pooq.com> <20080409012411.GE32073@topoi.pooq.com> Message-ID: <20080409022529.GF32073@topoi.pooq.com> On Tue, Apr 08, 2008 at 09:24:11PM -0400, hendrik at topoi.pooq.com wrote: > On Tue, Apr 08, 2008 at 09:17:42PM -0400, hendrik at topoi.pooq.com wrote: > > On Wed, Apr 09, 2008 at 12:57:39AM +0000, Jay wrote: > > > "Rushing through the dialogues" is a new feature. I kept complaining > > about how dumb it was. On NT386* at least, I stopped using cminstall > > altogether. There is an -interactive option or somesuch. > > > > > > > > - Jay > > > > > > > But I suspect finding nonexistent files isn't a feature, new or old. Is > > it going to cause trouble later on? Is it going to try to install > > things that depend on postgres and odbc and fall apart? > > The -interactive option gives me interaction. But it still finds the > nonexistent libpq.so in /usr/lib. > > Where are the Postgres95 libraries? > looking for library file(s): libpq.so > checking for library files in directory /usr/lib... not found > checking for library files in directory /usr/local/postgres95/lib... > not found > checking for library files in directory /usr/local/lib... not found > checking for directory /usr/lib... found > > 1: /usr/lib > Where are the Postgres95 libraries? [/usr/lib](1 of 1) > > > Only after I accept the default location does it notice threre's no such > file there. I find this confusing, because it correctly fails to find > in in all the other locations. > > But I guess I can live with this, because it gives me the chance to say: > > The libraries libpq.so are not present in the chosen directory. > Would you like to change the library names? [yes] no > Would you like to continue nonetheless? [yes] yes > > Thanks. > > -- hendrik Well, it's working now. My trouble do suggest to me that the downloads and instructions obtained from http://modula3.elegosoft.com/cm3/installation.html may no longer work properly. The ones that worked for me were http://modula3.elegosoft.com/cm3/install-cm3-on-ubuntu-7-10.html Further, the noninteractive default for cminstall is quite confusing. The instructions should recommend the -interactive option. Finally, I kept typing cm3 --version instead of cm3 -version The double hyphen is such a standard on other software that it should perhaps be accepted here, too. -- hendrik From wagner at elegosoft.com Wed Apr 9 09:05:49 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 09 Apr 2008 09:05:49 +0200 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080409011418.GC32073@topoi.pooq.com> References: <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> <20080408171734.GA31674@topoi.pooq.com> <20080408231541.GA31929@topoi.pooq.com> <20080408233338.GA32037@topoi.pooq.com> <20080409000207.GA32073@topoi.pooq.com> <20080409011418.GC32073@topoi.pooq.com> Message-ID: <20080409090549.cdpk2tjocgg0wcg8@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > On Wed, Apr 09, 2008 at 01:00:20AM +0000, Jay wrote: >> Right. >> This is a normal symptom of using an "old" compiler to compile >> current source. >> You must first build a new compiler against an old runtime (which >> you must get from "somewhere", such as an existing older install), >> then use that to build a new runtime. >> >> scripts/upgrade.sh >> scripts/python/upgrade.py >> scripts/win/upgrade.cmd >> >> should all handle the "dance" for you. >> >> - Jay > > Except I don't *have* a working old runtime. I've mentioned my > experiences with > ../cm3-min-POSIX-LINUXLIBC6-d5.7.0-2008-04-08-14-00-05.tgz > in another post. I acquired it in the hope that it wouldn't be an old > runtime. Three short notes: o cminstall didn't find the non-existent libraries, it just checked the existence of a directory: checking for library files in directory /usr/local/lib... not found ^^^^^^^^^^^^^^^^^^^^^^^^^^ checking for directory /usr/lib... found ^^^^^^^^^^^^^ o Your compiler didn't have LONGINT support, so you need to use upgrade.sh. This should be documented (I think it is), as the introduction of LONGINT was an incompatible change wrt. bootstrapping. o cm3-min-POSIX-LINUXLIBC6-d5.7.0-2008-04-08-14-00-05.tgz should contain a new compiler and a new runtime, so there's no need for bootstrapping cm3, only normal package compilation. Realclean is required though to remove old derived 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 hendrik at topoi.pooq.com Wed Apr 9 14:29:12 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 9 Apr 2008 08:29:12 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080409090549.cdpk2tjocgg0wcg8@mail.elegosoft.com> References: <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> <20080408171734.GA31674@topoi.pooq.com> <20080408231541.GA31929@topoi.pooq.com> <20080408233338.GA32037@topoi.pooq.com> <20080409000207.GA32073@topoi.pooq.com> <20080409011418.GC32073@topoi.pooq.com> <20080409090549.cdpk2tjocgg0wcg8@mail.elegosoft.com> Message-ID: <20080409122912.GA1060@topoi.pooq.com> On Wed, Apr 09, 2008 at 09:05:49AM +0200, Olaf Wagner wrote: > Quoting hendrik at topoi.pooq.com: > > >On Wed, Apr 09, 2008 at 01:00:20AM +0000, Jay wrote: > >>Right. > >>This is a normal symptom of using an "old" compiler to compile > >>current source. > >>You must first build a new compiler against an old runtime (which > >>you must get from "somewhere", such as an existing older install), > >>then use that to build a new runtime. > >> > >> scripts/upgrade.sh > >> scripts/python/upgrade.py > >> scripts/win/upgrade.cmd > >> > >>should all handle the "dance" for you. > >> > >> - Jay > > > >Except I don't *have* a working old runtime. I've mentioned my > >experiences with > >../cm3-min-POSIX-LINUXLIBC6-d5.7.0-2008-04-08-14-00-05.tgz > >in another post. I acquired it in the hope that it wouldn't be an old > >runtime. > > Three short notes: > > o cminstall didn't find the non-existent libraries, it just checked > the existence of a directory: > > checking for library files in directory /usr/local/lib... not found > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > checking for directory /usr/lib... found > ^^^^^^^^^^^^^ That explains the messages. Thanks. > > o Your compiler didn't have LONGINT support, so you need to use > upgrade.sh. This should be documented (I think it is), as the > introduction of LONGINT was an incompatible change wrt. > bootstrapping. I was doing a new install. The first installation (the stable release obtained from the .tgz archives) crashed. I was advised to use the latest version from cvs, which failed because of the LONGINT problem and the fact I was still using the old cminstall file for bootstrapping. Finally I found a new place to get a new cminstall, and that one finally worked. > > o cm3-min-POSIX-LINUXLIBC6-d5.7.0-2008-04-08-14-00-05.tgz > should contain a new compiler and a new runtime, so there's > no need for bootstrapping cm3, only normal package compilation. And this should be documented somewhere on the installation and download pages, which is what a beginner sees. A beginner, who wasn't already sold on the virtues of Modula 3, would have given up long before I did. > Realclean is required though to remove old derived files. That's something I hadn't heard of. It looks useful. Where is it documented? -- hendrik From wagner at elegosoft.com Wed Apr 9 14:54:08 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 09 Apr 2008 14:54:08 +0200 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080409122912.GA1060@topoi.pooq.com> References: <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> <20080408171734.GA31674@topoi.pooq.com> <20080408231541.GA31929@topoi.pooq.com> <20080408233338.GA32037@topoi.pooq.com> <20080409000207.GA32073@topoi.pooq.com> <20080409011418.GC32073@topoi.pooq.com> <20080409090549.cdpk2tjocgg0wcg8@mail.elegosoft.com> <20080409122912.GA1060@topoi.pooq.com> Message-ID: <20080409145408.ekn7fszvrk8084ko@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > On Wed, Apr 09, 2008 at 09:05:49AM +0200, Olaf Wagner wrote: >> Three short notes: >> o cminstall didn't find the non-existent libraries, it just checked >> the existence of a directory: >> >> checking for library files in directory /usr/local/lib... not found >> ^^^^^^^^^^^^^^^^^^^^^^^^^^ >> checking for directory /usr/lib... found >> ^^^^^^^^^^^^^ > That explains the messages. Thanks. >> >> o Your compiler didn't have LONGINT support, so you need to use >> upgrade.sh. This should be documented (I think it is), as the >> introduction of LONGINT was an incompatible change wrt. >> bootstrapping. > > I was doing a new install. The first installation (the stable > release obtained from the .tgz archives) crashed. I was advised to use > the latest version from cvs, which failed because of the LONGINT > problem and the fact I was still using the old cminstall file for > bootstrapping. Finally I found a new place to get a new cminstall, and > that one finally worked. > >> o cm3-min-POSIX-LINUXLIBC6-d5.7.0-2008-04-08-14-00-05.tgz >> should contain a new compiler and a new runtime, so there's >> no need for bootstrapping cm3, only normal package compilation. > > And this should be documented somewhere on the installation and download > pages, which is what a beginner sees. A beginner, who wasn't already > sold on the virtues of Modula 3, would have given up long before I did. > >> Realclean is required though to remove old derived files. > > That's something I hadn't heard of. It looks useful. Where is it > documented? Hi, I agree that the documentation is probably neither consistent nor complete not completely up-to-date :-/ I'm working on it when I've got some spare time, but currently I'm really busy and can spare none. Would you mind providing some patches to cm3/www that address at least the problems you encountered? That would be very helpful. I'll ship them to our WWW server on the request of any m3devel member. Thanks in advance for any doc contributions (from you or others), Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From mika at async.caltech.edu Thu Apr 10 12:41:12 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 10 Apr 2008 03:41:12 -0700 Subject: [M3devel] set relationships? In-Reply-To: Your message of "Mon, 07 Apr 2008 00:52:10 -0000." Message-ID: <200804101041.m3AAfCKQ099273@camembert.async.caltech.edu> I think the point is, <= for sets, in the form you describe, defines a partial order. There are libraries full of math books describing what you can and can't do with partial orders. And yes all your examples should be all false. Mika Jay writes: >--_dbaf03aa-e4eb-4ef2-8579-90576f2305db_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >oops -- I mean they are all false. > > >From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Mon, 7 Apr 2008 00:= >38:01 +0000Subject: [M3devel] set relationships? > > >I'm looking at test p1\p155.I haven't started debugging it, just trying to = >understand it. C:\dev2\cm3\doc\reference\relations.html:" infix <=3D= >, >=3D ... (x,y: Set) : BOOLEAN ... <=3D returns TRUE if every element= > of x is an element of y....The expression x >=3D y is equivalent to y <=3D= > x. ...In all cases, x < y means (x <=3D y) AND (x # y), and x > y means y = >< x" Let's just use the sets {1} and {2}. {1} <=3D {2} {2} <=3D {1} {= >1} < {2} {2} < {1} {1} >=3D {2} {2} >=3D {1} {1} > {2} {2} > {1} = > All these expressions are true from the definitions above.Is that reasonab= >le?It seems a little strange to me. I guess I am very used to strongly orde= >red things, such that a <=3D b && a =3D> b implies a =3D=3D b, not true her= >e, and you can't have both a < b and b < a, which you have here, and that (= >a < b) =3D=3D !(a >=3D b) and similar, which is not true here. In this case= >, every relation but equality is true. - Jay= > >--_dbaf03aa-e4eb-4ef2-8579-90576f2305db_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > >oops -- I mean they are all false.


>
>
>From: jayk123 at hotmail.com
To: m3devel at elegosoft.com
Date: Mon, 7 Apr = >2008 00:38:01 +0000
Subject: [M3devel] set relationships?

> > >I'm looking at test p1\p155.
I haven't started debugging it, just trying= > to understand it.
 
C:\dev2\cm3\doc\reference\relations.html:R>"
     infix&nbs= >p;   <=3D, >=3D  ... 
(x,y: Set) &nbs= >p;   : BOOLEAN

 
... <=3D returns= > TRUE if every element of x is an element of y.<= >BR>...
The expression x >=3D y is equivalent to y <= >=3D x.
...
In all cases, x < y means (x <=3D= > y) AND (x # y), and x > y means y < x
= >"
 
Let's just use the sets {1} and {2}.
 
 = >; {1} <=3D {2}
  {2} <=3D {1}
  {1} < {2}
&n= >bsp; {2} < {1}
  {1} >=3D {2}
  {2} >= >=3D {1}
  {1} > {2}
  {2} > {1}
 = >;
All these expressions are true from the definitions above.
Is that = >reasonable?
It seems a little strange to me.
 
I guess I am v= >ery used to strongly ordered things, such that a <=3D b && a =3D= >> b implies a =3D=3D b, not true here, and you can't have both= > a < b and b < a, which you have here, and that (a < b) =3D=3D !(a= > >=3D b) and similar, which is not true here. In this case, every relati= >on but equality is true.
 
 - Jay

y> >= > >--_dbaf03aa-e4eb-4ef2-8579-90576f2305db_-- From hosking at cs.purdue.edu Thu Apr 10 14:29:38 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 10 Apr 2008 08:29:38 -0400 Subject: [M3devel] Fwd: Output from "cron" command References: <200804101030.m3AAU76w002296@niagara.cs.purdue.edu> Message-ID: <81A65E59-E09B-49C4-A7DE-DD139A219A2D@cs.purdue.edu> Regressions are broken... Begin forwarded message: > From: Tony Hosking > Date: April 10, 2008 6:30:07 AM GMT-04:00 > To: hosking at cs.purdue.edu > Subject: Output from "cron" command > > Your "cron" job on niagara.cs.purdue.edu > $HOME/cm3/scripts/regression/cron.sh > > produced the following output: > > ./tinderbox-build.sh: syntax error at line 270: `R=$' unexpected > ./tinderbox-build.sh: syntax error at line 270: `R=$' unexpected -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Apr 10 14:41:10 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 10 Apr 2008 12:41:10 +0000 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: <81A65E59-E09B-49C4-A7DE-DD139A219A2D@cs.purdue.edu> References: <200804101030.m3AAU76w002296@niagara.cs.purdue.edu> <81A65E59-E09B-49C4-A7DE-DD139A219A2D@cs.purdue.edu> Message-ID: This was surely my attempt at "fixing" them to honor my $CVSROOT. It worked for me on Cygwin..my checkin comment was "good" -- it said I don't know if it was bash or Cygwin specific. C:\dev2\cm3.2\scripts\regression\cm3.build# checkout the current cm3 regression script and source it(echo $CVSROOT | grep @m3.elegosoft.com:/usr/cvs > /dev/null) || CVSROOT=":ext:modula3.elegosoft.com:/usr/cvs" cvs -d $CVSROOT checkout -A \ -d ${REGRESSION_SCRIPTS_DIR} cm3/scripts/regression/defs.sh Can you quickly/easily massage that into something more portable? Otherwise I'll just put back. I have hardly gotten anywhere trying to run the Tinderbox stuff, but can run various tests manually.. Looks like I'm getting a cheap Sun machine from eBay..might be a bit interesting... - Jay From: hosking at cs.purdue.eduTo: m3devel at elegosoft.comDate: Thu, 10 Apr 2008 08:29:38 -0400Subject: [M3devel] Fwd: Output from "cron" command Regressions are broken... Begin forwarded message: From: Tony Hosking Date: April 10, 2008 6:30:07 AM GMT-04:00 To: hosking at cs.purdue.edu Subject: Output from "cron" command Your "cron" job on niagara.cs.purdue.edu$HOME/cm3/scripts/regression/cron.shproduced the following output:./tinderbox-build.sh: syntax error at line 270: `R=$' unexpected./tinderbox-build.sh: syntax error at line 270: `R=$' unexpected -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Apr 10 14:46:10 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 10 Apr 2008 12:46:10 +0000 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: References: <200804101030.m3AAU76w002296@niagara.cs.purdue.edu> <81A65E59-E09B-49C4-A7DE-DD139A219A2D@cs.purdue.edu> Message-ID: > I have hardly gotten anywhere trying to run the Tinderbox stuff, but can run various tests manually.. The first problem is finding distributions to download. Maybe it can fallback to that less tested directory where I have put stuff (which reminds me, I should delete what is there and put up newer...) - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; m3devel at elegosoft.comDate: Thu, 10 Apr 2008 12:41:10 +0000Subject: Re: [M3devel] Fwd: Output from "cron" command This was surely my attempt at "fixing" them to honor my $CVSROOT.It worked for me on Cygwin..my checkin comment was "good" -- it said I don't know if it was bash or Cygwin specific. C:\dev2\cm3.2\scripts\regression\cm3.build# checkout the current cm3 regression script and source it(echo $CVSROOT | grep @m3.elegosoft.com:/usr/cvs > /dev/null) || CVSROOT=":ext:modula3.elegosoft.com:/usr/cvs"cvs -d $CVSROOT checkout -A \ -d ${REGRESSION_SCRIPTS_DIR} cm3/scripts/regression/defs.shCan you quickly/easily massage that into something more portable?Otherwise I'll just put back. I have hardly gotten anywhere trying to run the Tinderbox stuff, but can run various tests manually.. Looks like I'm getting a cheap Sun machine from eBay..might be a bit interesting... - Jay From: hosking at cs.purdue.eduTo: m3devel at elegosoft.comDate: Thu, 10 Apr 2008 08:29:38 -0400Subject: [M3devel] Fwd: Output from "cron" command Regressions are broken... Begin forwarded message: From: Tony Hosking Date: April 10, 2008 6:30:07 AM GMT-04:00 To: hosking at cs.purdue.edu Subject: Output from "cron" command Your "cron" job on niagara.cs.purdue.edu$HOME/cm3/scripts/regression/cron.shproduced the following output:./tinderbox-build.sh: syntax error at line 270: `R=$' unexpected./tinderbox-build.sh: syntax error at line 270: `R=$' unexpected -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu Apr 10 15:19:07 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 10 Apr 2008 09:19:07 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080409145408.ekn7fszvrk8084ko@mail.elegosoft.com> References: <20080408171734.GA31674@topoi.pooq.com> <20080408231541.GA31929@topoi.pooq.com> <20080408233338.GA32037@topoi.pooq.com> <20080409000207.GA32073@topoi.pooq.com> <20080409011418.GC32073@topoi.pooq.com> <20080409090549.cdpk2tjocgg0wcg8@mail.elegosoft.com> <20080409122912.GA1060@topoi.pooq.com> <20080409145408.ekn7fszvrk8084ko@mail.elegosoft.com> Message-ID: <20080410131907.GA2401@topoi.pooq.com> Looking at your message, and trying to imagine the documentation changes, it suddenly doesn't seem so easy. For one thing, I'm not familiar enough with the various systems to know what to say. On Wed, Apr 09, 2008 at 02:54:08PM +0200, Olaf Wagner wrote: > Quoting hendrik at topoi.pooq.com: > > >On Wed, Apr 09, 2008 at 09:05:49AM +0200, Olaf Wagner wrote: > >>Three short notes: > >> o cminstall didn't find the non-existent libraries, it just checked > >> the existence of a directory: > >> > >> checking for library files in directory /usr/local/lib... not found > >> ^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> checking for directory /usr/lib... found > >> ^^^^^^^^^^^^^ > > >That explains the messages. Thanks. > >> > >> o Your compiler didn't have LONGINT support, so you need to use > >> upgrade.sh. This should be documented (I think it is), as the > >> introduction of LONGINT was an incompatible change wrt. > >> bootstrapping. ********** > > > >I was doing a new install. The first installation (the stable > >release obtained from the .tgz archives) crashed. This crash isn't a matter of a documentation change. If the stable release crashes during installation, it probably need to be replaced with one that doesn't crash. Or is that just a problem on Ubuntu, Debian and related distributions? The http://modula3.elegosoft.com/cm3/ page says only: : If you would like to : : * install on Ubuntu, Debian or a related distribution, or : * install a recent snapshot of CM3, : you will want to read these more specific installation instructions. : Alternatively, continue reading the general instructions below. Which, I suppose wasn't worded strongly enough to warn me off the "more general" method. Perhaps it should say, : you will need to use these different installation instructions,. : Otherwise, continue reading the general instructions below. ********** On the page of "CM3 5.5.1 Installation on Ubuntu 7.10 and Similar GNU/Linux Distributions" there's a list of software you should already have installed. It should include cvs. ********** > I was advised to use > >the latest version from cvs, which failed because of the LONGINT > >problem and the fact I was still using the old cminstall file for > >bootstrapping. I gather that normally there isn't a bootstrapping problem from one compiler to the next. The CVS instructions should mention that you have to start with a new cm3-min- file, and not proceed from the old compiler, or and old cm3-min-. And, in fact, they do. So this was my fault for not noticing it. A friend of mine once said that his mother was a superhero, and that her superpower was the ability to follow instructions correctly. I'm starting to realize how true that is. *********** When it says, : the newest available stable tarballs (version 5.4.0) are too old. it should perhaps say that they do not work, as : the newest available stable tarballs (version 5.4.0) are too old and : do not work. By the way, what was too old about them -- are they no longer compatible with current versions of Ubuntu, Debian, or other related distributions? *********** > > > >> o cm3-min-POSIX-LINUXLIBC6-d5.7.0-2008-04-08-14-00-05.tgz > >> should contain a new compiler and a new runtime, so there's > >> no need for bootstrapping cm3, only normal package compilation. Do you mean that there was no reason to run the commands ./do-cm3-core.sh buildship ./install-cm3-compiler.sh upgrade ? ********** > >> Realclean is required though to remove old derived files. > > > >That's something I hadn't heard of. It looks useful. Where is it > >documented? And I have no idea how to document Realclean, or even how to use it. I've found the cm3 option cm3 -clean . Is realclean something like this, as cm3 -realclean ? And if so, what is the difference? > > Hi, > > I agree that the documentation is probably neither consistent nor > complete not completely up-to-date :-/ > > I'm working on it when I've got some spare time, but currently > I'm really busy and can spare none. Would you mind providing some > patches to cm3/www that address at least the problems you encountered? > That would be very helpful. I'd be happy to try. -- hendrik > > I'll ship them to our WWW server on the request of any m3devel > member. > > Thanks in advance for any doc contributions (from you or others), > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 10 17:14:44 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 10 Apr 2008 17:14:44 +0200 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080410131907.GA2401@topoi.pooq.com> References: <20080408171734.GA31674@topoi.pooq.com> <20080408231541.GA31929@topoi.pooq.com> <20080408233338.GA32037@topoi.pooq.com> <20080409000207.GA32073@topoi.pooq.com> <20080409011418.GC32073@topoi.pooq.com> <20080409090549.cdpk2tjocgg0wcg8@mail.elegosoft.com> <20080409122912.GA1060@topoi.pooq.com> <20080409145408.ekn7fszvrk8084ko@mail.elegosoft.com> <20080410131907.GA2401@topoi.pooq.com> Message-ID: <20080410171444.n9kt2aim68oss00w@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > Looking at your message, and trying to imagine the documentation > changes, it suddenly doesn't seem so easy. For one thing, I'm not > familiar enough with the various systems to know what to say. In Germany we've got a saying `the devil lurks in the details'; don't know if that is known to English speaking people, too :-) > On Wed, Apr 09, 2008 at 02:54:08PM +0200, Olaf Wagner wrote: >> Quoting hendrik at topoi.pooq.com: >> >> >On Wed, Apr 09, 2008 at 09:05:49AM +0200, Olaf Wagner wrote: >> >I was doing a new install. The first installation (the stable >> >release obtained from the .tgz archives) crashed. > > This crash isn't a matter of a documentation change. If the stable > release crashes during installation, it probably need to be replaced > with one that doesn't crash. Or is that just a problem on Ubuntu, > Debian and related distributions? > > The http://modula3.elegosoft.com/cm3/ page says only: > > : If you would like to > : > : * install on Ubuntu, Debian or a related distribution, or > : * install a recent snapshot of CM3, > > : you will want to read these more specific installation instructions. > > : Alternatively, continue reading the general instructions below. > > Which, I suppose wasn't worded strongly enough to warn me off the "more > general" method. > > Perhaps it should say, > > : you will need to use these different installation instructions,. > > : Otherwise, continue reading the general instructions below. Sounds good. > ********** > > On the page of "CM3 5.5.1 Installation on Ubuntu 7.10 and Similar > GNU/Linux Distributions" > > there's a list of software you should already have installed. It should > include cvs. OK. But you can get the daily source snapshots without CVS, too. > ********** > >> I was advised to use >> >the latest version from cvs, which failed because of the LONGINT >> >problem and the fact I was still using the old cminstall file for >> >bootstrapping. > > I gather that normally there isn't a bootstrapping problem from one > compiler to the next. The CVS instructions should mention that > you have to start with a new cm3-min- file, and not proceed from the old > compiler, or and old cm3-min-. And, in fact, they do. So this was my > fault for not noticing it. > > A friend of mine once said that his mother was a superhero, and that her > superpower was the ability to follow instructions correctly. I'm > starting to realize how true that is. :-) > *********** > > When it says, > > : the newest available stable tarballs (version 5.4.0) are too old. > > it should perhaps say that they do not work, as > > : the newest available stable tarballs (version 5.4.0) are too old and > : do not work. OK. > By the way, what was too old about them -- are they no longer compatible > with current versions of Ubuntu, Debian, or other related > distributions? IIRC, the problem is that these systems encrypt their jmp_bufs which are used for user threads in M3. I don't know if this can be turned off globally. I'm also not sure if there wasn't something else. Perhaps somebody else remembers? > *********** > >> >> o cm3-min-POSIX-LINUXLIBC6-d5.7.0-2008-04-08-14-00-05.tgz >> >> should contain a new compiler and a new runtime, so there's >> >> no need for bootstrapping cm3, only normal package compilation. > > Do you mean that there was no reason to run the commands > > ./do-cm3-core.sh buildship > > ./install-cm3-compiler.sh upgrade > > ? Yes. If the compiler works, it's up-to-date, as is m3core and libm3. Everything that is not contained can then be compiled. > ********** > >> >> Realclean is required though to remove old derived files. >> > >> >That's something I hadn't heard of. It looks useful. Where is it >> >documented? > > And I have no idea how to document Realclean, or even how to use it. > I've found the cm3 option > > cm3 -clean > > . Is realclean something like this, as > > cm3 -realclean > > ? And if so, what is the difference? No, there's no cm3 -realclean. It's only a command for the scripts, as in scripts/do-cm3-all.sh realclean which performs rm -rf $TARGET in every package. >> Hi, >> >> I agree that the documentation is probably neither consistent nor >> complete not completely up-to-date :-/ >> >> I'm working on it when I've got some spare time, but currently >> I'm really busy and can spare none. Would you mind providing some >> patches to cm3/www that address at least the problems you encountered? >> That would be very helpful. > > I'd be happy to try. Great. I hope the remarks above will help. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 10 18:56:13 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 10 Apr 2008 12:56:13 -0400 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: References: <200804101030.m3AAU76w002296@niagara.cs.purdue.edu> <81A65E59-E09B-49C4-A7DE-DD139A219A2D@cs.purdue.edu> Message-ID: <2B8FF29D-E004-4F74-A60C-F215814BAFDC@cs.purdue.edu> I don't even use $CVSROOT generally, so it probably should not be assumed. I don't have the time to fix this right now. On Apr 10, 2008, at 8:41 AM, Jay wrote: > This was surely my attempt at "fixing" them to honor my $CVSROOT. > It worked for me on Cygwin..my checkin comment was "good" -- it said > I don't know if it was bash or Cygwin specific. > > C:\dev2\cm3.2\scripts\regression\cm3.build > > # checkout the current cm3 regression script and source it > (echo $CVSROOT | grep @m3.elegosoft.com:/usr/cvs > /dev/null) || > CVSROOT=":ext:modula3.elegosoft.com:/usr/cvs" > > > cvs -d $CVSROOT checkout -A \ > -d ${REGRESSION_SCRIPTS_DIR} cm3/scripts/regression/defs.sh > > > Can you quickly/easily massage that into something more portable? > Otherwise I'll just put back. I have hardly gotten anywhere trying > to run the Tinderbox stuff, but can run various tests manually.. > > Looks like I'm getting a cheap Sun machine from eBay..might be a bit > interesting... > > - Jay > > From: hosking at cs.purdue.edu > To: m3devel at elegosoft.com > Date: Thu, 10 Apr 2008 08:29:38 -0400 > Subject: [M3devel] Fwd: Output from "cron" command > > Regressions are broken... > > Begin forwarded message: > From: Tony Hosking > Date: April 10, 2008 6:30:07 AM GMT-04:00 > To: hosking at cs.purdue.edu > Subject: Output from "cron" command > > Your "cron" job on niagara.cs.purdue.edu > $HOME/cm3/scripts/regression/cron.sh > > produced the following output: > > ./tinderbox-build.sh: syntax error at line 270: `R=$' unexpected > ./tinderbox-build.sh: syntax error at line 270: `R=$' unexpected > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Thu Apr 10 21:46:29 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 10 Apr 2008 14:46:29 -0500 Subject: [M3devel] Need CVS help fixing log message Message-ID: <47FE6E95.4070405@wichita.edu> I committed a bunch of files and mistakenly used -m when I should have used -F. The result is, the log message is a local path to a file. My CVS book shows a -m option to cvs admin to repair log messages, but nothing that does what the -F option to commit does. My log message has several lines. How can I fix the logs? Is there an equivalent to admin -F? Will the -m accept newlines between the quotes? -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From wagner at elegosoft.com Thu Apr 10 22:45:24 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 10 Apr 2008 22:45:24 +0200 Subject: [M3devel] Need CVS help fixing log message In-Reply-To: <47FE6E95.4070405@wichita.edu> References: <47FE6E95.4070405@wichita.edu> Message-ID: <20080410224524.tnubedsin4cck4ks@mail.elegosoft.com> Quoting "Rodney M. Bates" : > I committed a bunch of files and mistakenly used -m when I should > have used -F. The result is, the log message is a local path to > a file. My CVS book shows a -m option to cvs admin to repair log > messages, but nothing that does what the -F option to commit does. > My log message has several lines. How can I fix the logs? Is there > an equivalent to admin -F? Will the -m accept newlines between the > quotes? Use something like cvs admin -m1.24:'line 1 line 2 line 3' fn Note that it is based on the RCS revision; so you've got to do it for each file with the correct revision number. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Sat Apr 12 22:54:16 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 12 Apr 2008 16:54:16 -0400 Subject: [M3devel] AMD64_DARWIN Message-ID: <9CC27F14-E89D-49D8-AA69-2CC173B61CFA@cs.purdue.edu> I have successfully bootstrapped a AMD64_DARWIN (64-bit x86_64 Mac OS X) target. In order to do this I needed to upgrade the gcc-based compiler backend to a newer version. Does anyone have any objection to my checking in a newer version of m3cc, as I check in my support for AMD64_DARWIN? From rodney.bates at wichita.edu Sun Apr 13 01:02:50 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Sat, 12 Apr 2008 18:02:50 -0500 Subject: [M3devel] AMD64_DARWIN In-Reply-To: <9CC27F14-E89D-49D8-AA69-2CC173B61CFA@cs.purdue.edu> References: <9CC27F14-E89D-49D8-AA69-2CC173B61CFA@cs.purdue.edu> Message-ID: <48013F9A.6090500@wichita.edu> Short answer: No. But maybe put the old one on a branch, for thoroughness? In the past, I have made a few changes to it to support m3gdb. They might revert as a result. But I made a copy of the current m3cc, and I can't think of anything else that might be needed for that purpose, before a new version checkin. Tony Hosking wrote: > I have successfully bootstrapped a AMD64_DARWIN (64-bit x86_64 Mac OS > X) target. In order to do this I needed to upgrade the gcc-based > compiler backend to a newer version. Does anyone have any objection > to my checking in a newer version of m3cc, as I check in my support for > AMD64_DARWIN? > > -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From jayk123 at hotmail.com Sun Apr 13 00:58:14 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 12 Apr 2008 22:58:14 +0000 Subject: [M3devel] AMD64_DARWIN In-Reply-To: <48013F9A.6090500@wichita.edu> References: <9CC27F14-E89D-49D8-AA69-2CC173B61CFA@cs.purdue.edu> <48013F9A.6090500@wichita.edu> Message-ID: Rodney, I bet he is doing that already as a matter of course. And I bet he will merge your changes, and any others. I have no objection but I'm sure that was obvious. :) - Jay > Date: Sat, 12 Apr 2008 18:02:50 -0500> From: rodney.bates at wichita.edu> To: hosking at cs.purdue.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] AMD64_DARWIN> > Short answer: No. But maybe put the old one on a branch, for> thoroughness?> > In the past, I have made a few changes to it to support m3gdb. They> might revert as a result. But I made a copy of the current m3cc,> and I can't think of anything else that might be needed for that> purpose, before a new version checkin.> > Tony Hosking wrote:> > I have successfully bootstrapped a AMD64_DARWIN (64-bit x86_64 Mac OS > > X) target. In order to do this I needed to upgrade the gcc-based > > compiler backend to a newer version. Does anyone have any objection > > to my checking in a newer version of m3cc, as I check in my support for > > AMD64_DARWIN?> > > > > > -- > -------------------------------------------------------------> Rodney M. Bates, retired assistant professor> Dept. of Computer Science, Wichita State University> Wichita, KS 67260-0083> 316-978-3922> rodney.bates at wichita.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Apr 13 01:40:28 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 12 Apr 2008 19:40:28 -0400 Subject: [M3devel] AMD64_DARWIN In-Reply-To: References: <9CC27F14-E89D-49D8-AA69-2CC173B61CFA@cs.purdue.edu> <48013F9A.6090500@wichita.edu> Message-ID: <0DE77BAB-EE98-44FA-8E56-385085E8B1EA@cs.purdue.edu> I've propagated all the prior diffs. In fact, I'll do this as a cvs import and merge so we shouldn't lose anything. There are some bugfixes for 64-bit as well, but nothing major. On Apr 12, 2008, at 6:58 PM, Jay wrote: > Rodney, I bet he is doing that already as a matter of course. And I > bet he will merge your changes, and any others. > I have no objection but I'm sure that was obvious. :) > > - Jay > > > > > Date: Sat, 12 Apr 2008 18:02:50 -0500 > > From: rodney.bates at wichita.edu > > To: hosking at cs.purdue.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] AMD64_DARWIN > > > > Short answer: No. But maybe put the old one on a branch, for > > thoroughness? > > > > In the past, I have made a few changes to it to support m3gdb. They > > might revert as a result. But I made a copy of the current m3cc, > > and I can't think of anything else that might be needed for that > > purpose, before a new version checkin. > > > > Tony Hosking wrote: > > > I have successfully bootstrapped a AMD64_DARWIN (64-bit x86_64 > Mac OS > > > X) target. In order to do this I needed to upgrade the gcc-based > > > compiler backend to a newer version. Does anyone have any > objection > > > to my checking in a newer version of m3cc, as I check in my > support for > > > AMD64_DARWIN? > > > > > > > > > > -- > > ------------------------------------------------------------- > > Rodney M. Bates, retired assistant professor > > Dept. of Computer Science, Wichita State University > > Wichita, KS 67260-0083 > > 316-978-3922 > > rodney.bates at wichita.edu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sun Apr 13 06:03:40 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 13 Apr 2008 00:03:40 -0400 Subject: [M3devel] AMD64_DARWIN In-Reply-To: <9CC27F14-E89D-49D8-AA69-2CC173B61CFA@cs.purdue.edu> References: <9CC27F14-E89D-49D8-AA69-2CC173B61CFA@cs.purdue.edu> Message-ID: <20080413040340.GC9473@topoi.pooq.com> On Sat, Apr 12, 2008 at 04:54:16PM -0400, Tony Hosking wrote: > I have successfully bootstrapped a AMD64_DARWIN (64-bit x86_64 Mac OS > X) target. In order to do this I needed to upgrade the gcc-based > compiler backend to a newer version. Does anyone have any objection > to my checking in a newer version of m3cc, as I check in my support > for AMD64_DARWIN? > While we're on a related subjext -- is m3 available on an AMD64 Linux box yet (in 64-bit mode)? From hosking at cs.purdue.edu Sun Apr 13 06:15:56 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 13 Apr 2008 00:15:56 -0400 Subject: [M3devel] AMD64_DARWIN In-Reply-To: <20080413040340.GC9473@topoi.pooq.com> References: <9CC27F14-E89D-49D8-AA69-2CC173B61CFA@cs.purdue.edu> <20080413040340.GC9473@topoi.pooq.com> Message-ID: <5C33687C-D899-429C-86A0-F55C2676051B@cs.purdue.edu> Not that I know, but porting to AMD64_DARWIN should give us most of what is needed for AMD64_LINUX. Stay tuned. On Apr 13, 2008, at 12:03 AM, hendrik at topoi.pooq.com wrote: > On Sat, Apr 12, 2008 at 04:54:16PM -0400, Tony Hosking wrote: >> I have successfully bootstrapped a AMD64_DARWIN (64-bit x86_64 Mac OS >> X) target. In order to do this I needed to upgrade the gcc-based >> compiler backend to a newer version. Does anyone have any objection >> to my checking in a newer version of m3cc, as I check in my support >> for AMD64_DARWIN? >> > > While we're on a related subjext -- is m3 available on an AMD64 Linux > box yet (in 64-bit mode)? From wagner at elegosoft.com Mon Apr 14 08:48:55 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 14 Apr 2008 08:48:55 +0200 Subject: [M3devel] cm3 regression Message-ID: <20080414084855.tebzp7f2cksss004@mail.elegosoft.com> Building of libm3 now fails even in release-builds with 4539 new source -> compiling SocketPosix.m3 4540 4541 NEXT Fatal Error: bad version stamps: SocketPosix.m3 4542 4543 version stamp mismatch: Compiler.Platform 4544 => SocketPosix.m3 4545 => Compiler.i3 4546 version stamp mismatch: Compiler.ThisPlatform 4547 <92d2f58d2092154f> => SocketPosix.m3 4548 => Compiler.i3 4549 NEXT *** execution of cm3 -build -DROOT=?/home/m3/work/cm3-ws/birch.elegosoft.com-2008-04-14-00-00-03/cm3? -DCM3_VERSION_TEXT=?d5.7.0? -DCM3_VERSION_NUMBER=?050700? -DCM3_LAST_CHANGED=?2008-03-16? && cm3 -ship -DROOT=?/home/m3/work/cm3-ws/birch.elegosoft.com-2008-04-14-00-00-03/cm3? -DCM3_VERSION_TEXT=?d5.7.0? -DCM3_VERSION_NUMBER=?050700? -DCM3_LAST_CHANGED=?2008-03-16? failed *** 4550 compile return value: 0 4551 [end compile 2008.04.14 02:54:34] 4552 *** COMPILE FAILED Does anybody understand what's going on? During upgrade(), libm3 should only be built _after_ the new compiler has been installed, at least that is the intention. I'm in a hurry, so if anybody else cares to fix this, it would be great. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 14 08:52:52 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 14 Apr 2008 08:52:52 +0200 Subject: [M3devel] cm3 regression In-Reply-To: <20080414084855.tebzp7f2cksss004@mail.elegosoft.com> References: <20080414084855.tebzp7f2cksss004@mail.elegosoft.com> Message-ID: <20080414085252.mzhkll84kk408gso@mail.elegosoft.com> Quoting Olaf Wagner : > Building of libm3 now fails even in release-builds with > > 4539 new source -> compiling SocketPosix.m3 > 4540 > 4541 NEXT Fatal Error: bad version stamps: SocketPosix.m3 > 4542 > 4543 version stamp mismatch: Compiler.Platform > 4544 => SocketPosix.m3 > 4545 => Compiler.i3 > 4546 version stamp mismatch: Compiler.ThisPlatform > 4547 <92d2f58d2092154f> => SocketPosix.m3 > 4548 => Compiler.i3 > 4549 NEXT *** execution of cm3 -build > -DROOT=?/home/m3/work/cm3-ws/birch.elegosoft.com-2008-04-14-00-00-03/cm3? > -DCM3_VERSION_TEXT=?d5.7.0? -DCM3_VERSION_NUMBER=?050700? > -DCM3_LAST_CHANGED=?2008-03-16? && cm3 -ship > -DROOT=?/home/m3/work/cm3-ws/birch.elegosoft.com-2008-04-14-00-00-03/cm3? > -DCM3_VERSION_TEXT=?d5.7.0? -DCM3_VERSION_NUMBER=?050700? > -DCM3_LAST_CHANGED=?2008-03-16? failed *** > 4550 compile return value: 0 > 4551 [end compile 2008.04.14 02:54:34] > 4552 *** COMPILE FAILED > > Does anybody understand what's going on? > During upgrade(), libm3 should only be built _after_ the new compiler > has been installed, at least that is the intention. > > I'm in a hurry, so if anybody else cares to fix this, it would be great. I sent that mail too fast. It seems that only I386_DARWIN fails in the release-build, but for other reasons. The last-ok builds can be expexted to fail after incompatible changes in the runtime. So this should cure itself during the next days. We should however note that we need a full compiler bootstrap again even from older d5.7.0 archives now to compile current sources. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Mon Apr 14 09:17:53 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 14 Apr 2008 07:17:53 +0000 Subject: [M3devel] cm3 regression In-Reply-To: <20080414085252.mzhkll84kk408gso@mail.elegosoft.com> References: <20080414084855.tebzp7f2cksss004@mail.elegosoft.com> <20080414085252.mzhkll84kk408gso@mail.elegosoft.com> Message-ID: new source -> compiling Cstdlib.i3"..\src\C\32BITS\BasicCtypes.i3", line 18: illegal based LONGINT literal, zero used"..\src\C\32BITS\BasicCtypes.i3", line 18: illegal based LONGINT literal, zero used long_long = [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL]; Why isn't this LONGINT? So that NT386 can limp along? And it'd be correct for the rest, eh? I'll try it and see.. The underlying system (the compiler) has (U)Int[8,16,32,64] They should just be used here imho.. Also, what should "long" be on 64bit? On Windows it is 32 bits always. On 32 bit systems it is 32 bits. I think the 64bits directory is going to be forked for AMD64_NT_*. The Windows decision imho has successfully been applied to more code and more users so therefore is better by practical success, even if the whole issue is problematic almost no matter what. Clearly the C and Modula-3 notions of integers are pretty poor.. - Jay > Date: Mon, 14 Apr 2008 08:52:52 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] cm3 regression> > Quoting Olaf Wagner :> > > Building of libm3 now fails even in release-builds with> >> > 4539 new source -> compiling SocketPosix.m3> > 4540> > 4541 NEXT Fatal Error: bad version stamps: SocketPosix.m3> > 4542> > 4543 version stamp mismatch: Compiler.Platform> > 4544 => SocketPosix.m3> > 4545 => Compiler.i3> > 4546 version stamp mismatch: Compiler.ThisPlatform> > 4547 <92d2f58d2092154f> => SocketPosix.m3> > 4548 => Compiler.i3> > 4549 NEXT *** execution of cm3 -build> > -DROOT=?/home/m3/work/cm3-ws/birch.elegosoft.com-2008-04-14-00-00-03/cm3?> > -DCM3_VERSION_TEXT=?d5.7.0? -DCM3_VERSION_NUMBER=?050700?> > -DCM3_LAST_CHANGED=?2008-03-16? && cm3 -ship> > -DROOT=?/home/m3/work/cm3-ws/birch.elegosoft.com-2008-04-14-00-00-03/cm3?> > -DCM3_VERSION_TEXT=?d5.7.0? -DCM3_VERSION_NUMBER=?050700?> > -DCM3_LAST_CHANGED=?2008-03-16? failed ***> > 4550 compile return value: 0> > 4551 [end compile 2008.04.14 02:54:34]> > 4552 *** COMPILE FAILED> >> > Does anybody understand what's going on?> > During upgrade(), libm3 should only be built _after_ the new compiler> > has been installed, at least that is the intention.> >> > I'm in a hurry, so if anybody else cares to fix this, it would be great.> > I sent that mail too fast. It seems that only I386_DARWIN fails in> the release-build, but for other reasons. The last-ok builds can> be expexted to fail after incompatible changes in the runtime.> So this should cure itself during the next days.> > We should however note that we need a full compiler bootstrap again> even from older d5.7.0 archives now to compile current sources.> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Apr 14 09:18:35 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 14 Apr 2008 09:18:35 +0200 Subject: [M3devel] latest failure on NT386 Message-ID: <20080414091835.gm0aycpxcwg4s0k4@mail.elegosoft.com> Just when I thought that I finally might be able to run a complete regression on NT386, the compilation breaks with this: new source -> compiling Cstdlib.i3 "..\src\C\32BITS\BasicCtypes.i3", line 18: illegal based LONGINT literal, zero used "..\src\C\32BITS\BasicCtypes.i3", line 18: illegal based LONGINT literal, zero used "..\src\C\Common\Cstdlib.i3", line 13: imported interface contains errors (Ctypes) 3 errors encountered new source -> compiling Csetjmp.i3 "..\src\C\NT386\Csetjmp.i3", line 13: imported interface contains errors (Ctypes) 1 error encountered Can anybody look into 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: DE16321419 From jayk123 at hotmail.com Mon Apr 14 09:32:51 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 14 Apr 2008 07:32:51 +0000 Subject: [M3devel] latest failure on NT386 In-Reply-To: <20080414091835.gm0aycpxcwg4s0k4@mail.elegosoft.com> References: <20080414091835.gm0aycpxcwg4s0k4@mail.elegosoft.com> Message-ID: Olaf, this will fix your problem. Tony should speak to it probably before it is commited -- like if it works on AMD64_DARWIN. Here is my reluctant proposal: cvs diff: Diffing 32BITSIndex: 32BITS/BasicCtypes.i3===================================================================RCS file: /usr/cvs/cm3/m3-libs/m3core/src/C/32BITS/BasicCtypes.i3,vretrieving revision 1.10diff -c -r1.10 BasicCtypes.i3*** 32BITS/BasicCtypes.i3 13 Apr 2008 19:41:49 -0000 1.10--- 32BITS/BasicCtypes.i3 14 Apr 2008 07:20:59 -0000****************** 13,21 **** (* the four signed integer types *) signed_char = [-16_7f-1 .. 16_7f]; short_int = [-16_7fff-1 .. 16_7fff];! int = [-16_7fffffff-1 .. 16_7fffffff];! long_int = [-16_7fffffff-1 .. 16_7fffffff];! long_long = [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL]; (* the four unsigned integer types *) unsigned_char = [16_0 .. 16_ff];--- 13,21 ---- (* the four signed integer types *) signed_char = [-16_7f-1 .. 16_7f]; short_int = [-16_7fff-1 .. 16_7fff];! int = INTEGER;! long_int = INTEGER;! long_long = LONGINT; (* the four unsigned integer types *) unsigned_char = [16_0 .. 16_ff];cvs diff: Diffing 64BITSIndex: 64BITS/BasicCtypes.i3===================================================================RCS file: /usr/cvs/cm3/m3-libs/m3core/src/C/64BITS/BasicCtypes.i3,vretrieving revision 1.8diff -c -r1.8 BasicCtypes.i3*** 64BITS/BasicCtypes.i3 13 Apr 2008 19:44:02 -0000 1.8--- 64BITS/BasicCtypes.i3 14 Apr 2008 07:20:59 -0000****************** 14,21 **** signed_char = [-16_7f-1 .. 16_7f]; short_int = [-16_7fff-1 .. 16_7fff]; int = [-16_7fffffff-1 .. 16_7fffffff];! long_int = [-16_7fffffffffffffff -1 .. 16_7fffffffffffffff ];! long_long = [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL]; (* the four unsigned integer types *) unsigned_char = [16_0 .. 16_ff];--- 14,21 ---- signed_char = [-16_7f-1 .. 16_7f]; short_int = [-16_7fff-1 .. 16_7fff]; int = [-16_7fffffff-1 .. 16_7fffffff];! long_int = INTEGER;! long_long = LONGINT; (* the four unsigned integer types *) unsigned_char = [16_0 .. 16_ff]; Win64 might not be able to use this but I guess the other 64 bit systems can. The bigger point is the 32bit fix to get NT386 compiling again. Type "long" is just dumb imho.By corrolary LONGINT. There should be the explicitly sized types [u]int[8,16,32,64,more in the future] and then unsigned and signed pointer sized types aka size_t, ptrdiff_t or size_t, ssize_t or Word.T, INTEGER I think it's unfortunate that Modula-3 followed C's lead here.This is one thing C definitely did wrong.You just know, 128 bit types are going to be called "long long long".. When they should have been called like int128 and uint128 and possibly size_t, ssize_t. Arguably "size_t" should be "word". "size_t" isn't the best name probably, but I'm not fighting that one. :) (I'm not really fighting any of this; I lost already.) - Jay > Date: Mon, 14 Apr 2008 09:18:35 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: [M3devel] latest failure on NT386> > Just when I thought that I finally might be able to run a complete> regression on NT386, the compilation breaks with this:> > new source -> compiling Cstdlib.i3> "..\src\C\32BITS\BasicCtypes.i3", line 18: illegal based LONGINT > literal, zero used> "..\src\C\32BITS\BasicCtypes.i3", line 18: illegal based LONGINT > literal, zero used> "..\src\C\Common\Cstdlib.i3", line 13: imported interface contains > errors (Ctypes)> 3 errors encountered> new source -> compiling Csetjmp.i3> "..\src\C\NT386\Csetjmp.i3", line 13: imported interface contains > errors (Ctypes)> 1 error encountered> > Can anybody look into 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: DE16321419> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Apr 14 10:00:34 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 14 Apr 2008 08:00:34 +0000 Subject: [M3devel] target naming? AMD64_NT, UWIN? In-Reply-To: <20080414091835.gm0aycpxcwg4s0k4@mail.elegosoft.com> References: <20080414091835.gm0aycpxcwg4s0k4@mail.elegosoft.com> Message-ID: the old target name game Lately I'm playing around at home with AMD64 Linux and Windows.Been using AMD64 Windows a while otherwise.I've also been playing around with UWin, which is something like Cygwin.Really nothing substantial yet.Anyone else with similar inclination, go ahead. UWin has an optional runtime, and not really a toolset.It has cc, ld, ar, but cc and ld are just wrappers forVisual C++ cl/link or other alternatives like Digital Mars,Borland, etc.ar is either a link -lib wrapper or doesn't do all that much in any case. They also have ncc -- native compiler, to produce Win32 executables.pcc for Posix executables, not sure of the point. Their runtime supports fork/vfork/exec/spawn, Posix file names, pthreads.They have sh that is ksh, vi.So far gcc does not build in this environment. I tried a bit.They are a much smaller system than Cygwin.Far fewer packages. They DO have X Windows. They say they will have 64 bit soon -- presumably AMD64. (IA64?) Cygwin is fairly x86 specific at this point.I haven't seen any movement on an AMD64 port, though it probably isn't that difficult. MinGWin is out there too already of course, and has a 64 bit port (shouldn't behard to just rebuild gcc, esp. with Tony's update). Therefore there are bunch more viable targets or configurations.It is hard to even describe them, other than via the earlier proposedand essentially implemented calculus: processor + runtime + C compiler + linker + modula-3 backend processor = x86, AMD64 runtime = msvc, uwin C compiler = msvc, gcc (borland, watcom, metrowerks, etc.) (now I see a reason to eliminate C -- so it doesn't figure into the target calculus! :) ) modula-3 backend = integrated, gcc NT386.Common implements something like this, though not always correctly, just enough for the three existing instantiations to work. UWin does not provide setjmp/longjmp, good.They have sigsetjmp/siglongjmp that only adds a /small/ amount, like 2 integers or 2 pointers.I have no qualm inflating always an AMD64 jmpbuf to accomodate, if needed.Inflating the NT386 one is still tempting to reduce variety. On one hand there is a quandary of too many target combinations to consider.But on the other hand is the solution that I implemented under the covers, the above calculus.Therefore, the compiler need only know about AMD64_NT, and the rest can be just "configurations". Besides, this same answer can be applied to any 32 bit UWin target. ??? Given the "configuration" idea, I would be ok with NTAMD64, or AMD64_NT, or AMD64_MSWIN, etc.I assume most folks will chose AMD64_NT. Some other names should probably be chosen, for the Quake files. AMD64_NT_WIN_UWIN -- "native runtime" AMD64_NT_POSIX_UWIN -- posix, X Windows AMD64_NT_MINGWIN -- native runtime AMD64_NT - reserved for future port of integrated backend? But in the compiler these could all be the same. or, shorter: AMD64_UWINN - UWin native AMD64_UWINP - UWin posix AMD64_UWINX - UWin posix ? "UWIN" implies "Windows" implies "NT", so good enough? or, processor, ostype, variant, and again UWin implies NT, ostype=win implies NT?: AMD64_POSIX_UWIN AMD64_WIN_UWIN (not very interesting, really) AMD64_WIN_GCC (MinGWin) AMD64_POSIX_CYG (future) same as AMD64_CYGWIN or NTAMD64GNU?? AMD64_WIN_NATIVE -- integrated backend, msvc cl/link (future) Usually "ostype" is not interesting in targets, since nearly everything is Posix.And "variant" is just a random escape hatch to try to come up with something. ??? I know I talk more about making new targets than actually doing it, sorry. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Apr 14 11:28:07 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 14 Apr 2008 09:28:07 +0000 Subject: [M3devel] target naming? AMD64_NT, UWIN? In-Reply-To: References: <20080414091835.gm0aycpxcwg4s0k4@mail.elegosoft.com> Message-ID: > processor + runtime + C compiler + linker + modula-3 backend correction: processor + kernel/"operating system" + C runtime + C compiler + linker + modula-3 backend + gui runtime Often only the first two vary, but not always. Most systems have "native" and GNU as I understand for C compiler and linker -- Solaris, AIX, HP-UX. And then Windows has multiple compilers, linkers, runtimes. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Apr 14 14:45:15 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Apr 2008 08:45:15 -0400 Subject: [M3devel] cm3 regression In-Reply-To: References: <20080414084855.tebzp7f2cksss004@mail.elegosoft.com> <20080414085252.mzhkll84kk408gso@mail.elegosoft.com> Message-ID: <4434FAA9-237F-4977-AAB8-DDE36FB2B503@cs.purdue.edu> Yes, sorry, probably best to make it LONGINT. I'll fix. 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 Apr 14, 2008, at 3:17 AM, Jay wrote: > new source -> compiling Cstdlib.i3 > "..\src\C\32BITS\BasicCtypes.i3", line 18: illegal based LONGINT > literal, zero used > "..\src\C\32BITS\BasicCtypes.i3", line 18: illegal based LONGINT > literal, zero used > > long_long = [-16_7fffffffffffffffL-1L .. > 16_7fffffffffffffffL]; > > > Why isn't this LONGINT? So that NT386 can limp along? And it'd be > correct for the rest, eh? > I'll try it and see.. > > The underlying system (the compiler) has (U)Int[8,16,32,64] > They should just be used here imho.. > > Also, what should "long" be on 64bit? > On Windows it is 32 bits always. > On 32 bit systems it is 32 bits. > I think the 64bits directory is going to be forked for AMD64_NT_*. > The Windows decision imho has successfully been applied to more code > and more users so therefore is better by practical success, even if > the whole issue is problematic almost no matter what. Clearly the C > and Modula-3 notions of integers are pretty poor.. > > - Jay > > > > > Date: Mon, 14 Apr 2008 08:52:52 +0200 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] cm3 regression > > > > Quoting Olaf Wagner : > > > > > Building of libm3 now fails even in release-builds with > > > > > > 4539 new source -> compiling SocketPosix.m3 > > > 4540 > > > 4541 NEXT Fatal Error: bad version stamps: SocketPosix.m3 > > > 4542 > > > 4543 version stamp mismatch: Compiler.Platform > > > 4544 => SocketPosix.m3 > > > 4545 => Compiler.i3 > > > 4546 version stamp mismatch: Compiler.ThisPlatform > > > 4547 <92d2f58d2092154f> => SocketPosix.m3 > > > 4548 => Compiler.i3 > > > 4549 NEXT *** execution of cm3 -build > > > -DROOT=?/home/m3/work/cm3-ws/ > birch.elegosoft.com-2008-04-14-00-00-03/cm3? > > > -DCM3_VERSION_TEXT=?d5.7.0? -DCM3_VERSION_NUMBER=?050700? > > > -DCM3_LAST_CHANGED=?2008-03-16? && cm3 -ship > > > -DROOT=?/home/m3/work/cm3-ws/ > birch.elegosoft.com-2008-04-14-00-00-03/cm3? > > > -DCM3_VERSION_TEXT=?d5.7.0? -DCM3_VERSION_NUMBER=?050700? > > > -DCM3_LAST_CHANGED=?2008-03-16? failed *** > > > 4550 compile return value: 0 > > > 4551 [end compile 2008.04.14 02:54:34] > > > 4552 *** COMPILE FAILED > > > > > > Does anybody understand what's going on? > > > During upgrade(), libm3 should only be built _after_ the new > compiler > > > has been installed, at least that is the intention. > > > > > > I'm in a hurry, so if anybody else cares to fix this, it would > be great. > > > > I sent that mail too fast. It seems that only I386_DARWIN fails in > > the release-build, but for other reasons. The last-ok builds can > > be expexted to fail after incompatible changes in the runtime. > > So this should cure itself during the next days. > > > > We should however note that we need a full compiler bootstrap again > > even from older d5.7.0 archives now to compile current sources. > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Apr 14 14:45:37 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Apr 2008 08:45:37 -0400 Subject: [M3devel] cm3 regression In-Reply-To: <20080414085252.mzhkll84kk408gso@mail.elegosoft.com> References: <20080414084855.tebzp7f2cksss004@mail.elegosoft.com> <20080414085252.mzhkll84kk408gso@mail.elegosoft.com> Message-ID: <8F8EDEDC-5AD4-4E0E-8C88-CF597D613049@cs.purdue.edu> Some regression to be expected while dust settles from AMD64_DARWIN changes. 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 Apr 14, 2008, at 2:52 AM, Olaf Wagner wrote: > Quoting Olaf Wagner : > >> Building of libm3 now fails even in release-builds with >> >> 4539 new source -> compiling SocketPosix.m3 >> 4540 >> 4541 NEXT Fatal Error: bad version stamps: SocketPosix.m3 >> 4542 >> 4543 version stamp mismatch: Compiler.Platform >> 4544 => SocketPosix.m3 >> 4545 => Compiler.i3 >> 4546 version stamp mismatch: Compiler.ThisPlatform >> 4547 <92d2f58d2092154f> => SocketPosix.m3 >> 4548 => Compiler.i3 >> 4549 NEXT *** execution of cm3 -build >> -DROOT=?/home/m3/work/cm3-ws/ >> birch.elegosoft.com-2008-04-14-00-00-03/cm3? >> -DCM3_VERSION_TEXT=?d5.7.0? -DCM3_VERSION_NUMBER=?050700? >> -DCM3_LAST_CHANGED=?2008-03-16? && cm3 -ship >> -DROOT=?/home/m3/work/cm3-ws/ >> birch.elegosoft.com-2008-04-14-00-00-03/cm3? >> -DCM3_VERSION_TEXT=?d5.7.0? -DCM3_VERSION_NUMBER=?050700? >> -DCM3_LAST_CHANGED=?2008-03-16? failed *** >> 4550 compile return value: 0 >> 4551 [end compile 2008.04.14 02:54:34] >> 4552 *** COMPILE FAILED >> >> Does anybody understand what's going on? >> During upgrade(), libm3 should only be built _after_ the new compiler >> has been installed, at least that is the intention. >> >> I'm in a hurry, so if anybody else cares to fix this, it would be >> great. > > I sent that mail too fast. It seems that only I386_DARWIN fails in > the release-build, but for other reasons. The last-ok builds can > be expexted to fail after incompatible changes in the runtime. > So this should cure itself during the next days. > > We should however note that we need a full compiler bootstrap again > even from older d5.7.0 archives now to compile current sources. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 jayk123 at hotmail.com Mon Apr 14 16:51:37 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 14 Apr 2008 14:51:37 +0000 Subject: [M3devel] small set comparisons understood, now just to understand the front end code.. Message-ID: currently set <,>,<=,>= are implemented merely as integer <,>,<=,>= This is wrong. I believe it should be: a < b => (a & b) == a a <= b => (a & b) == a (same as <=) a > b => (a & b) == b a >= b => (a & b) == b (same as >) The bug is in the frontend. m3-sys\m3front\src\misc\CG.m3. The code should be /something/ like: PROCEDURE Set_compare (s: Size; op: Cmp) = VAR tmp: Val; swap := FALSE; BEGIN (* a op b => BOOLEAN *) IF Force_pair (commute := TRUE) THEN op := M3CG.SwappedCompare [op]; END; IF (s <= Target.Integer.size) THEN IF (op = Cmp.EQ) OR (op = Cmp.NE) THEN cg.compare (Target.Word.cg_type, Target.Integer.cg_type, op); ELSE (* set a is less than or equal to set b, if all of set a's members are in set b. *) IF (op = Cmp.LT) OR (op = Cmp.LE) THEN swap := TRUE; Swap (); END; tmp := Pop (); Push (tmp); IF swap THEN Swap (); END; cg.and (Target.Integer.cg_type); Push (tmp); SimpleIndirectLoad (tmp^, Target.Word.cg_type); EVAL Force_pair (commute := TRUE); cg.compare (Target.Word.cg_type, Target.Integer.cg_type, Cmp.EQ); SPop (1, "Set_compare"); Free (tmp); END; ELSE cg.set_compare (AsBytes (s), op, Target.Integer.cg_type); END; SPop (2, "Set_compare"); SPush (Type.Int32); END Set_compare; though this doesn't quite drive all the machinery correctly, since it yields assertion failures in the compiler due to an unbalanced software stack. upgrade works, but the test case (p155) fails assertions in the integrated backend. I'd love to figure this out but have to do other stuff for now. Anyone (if there is anyone) familiar with what all is being pushed and popped around here should be able to figure it out easily from this mail. Otherwise I'll stare at more later. ps: "small" sets should probably be anything up to the number of bits in longint, rather than int or pointer, since that is probably efficient enough at the next level down. This is tangential. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Apr 14 17:22:35 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Apr 2008 11:22:35 -0400 Subject: [M3devel] small set comparisons understood, now just to understand the front end code.. In-Reply-To: References: Message-ID: <32E9EDBE-18FC-4F1B-8653-E60FC39DD534@cs.purdue.edu> I would hesitate to implement small sets as LONGINT instead of INTEGER, since there is no guarantee that LONGINT is necessarily efficient, whereas INTEGER is intended to be the same as the natural word size of the target. I could take a look at this but not anytime soon, since I have several other things I need to work on. On Apr 14, 2008, at 10:51 AM, Jay wrote: > currently set <,>,<=,>= are implemented merely as > integer <,>,<=,>= Yes, that seems quite wrong. I can't imagine things ever worked properly if that is how they are implemented. > > > This is wrong. > > I believe it should be: > > a < b => (a & b) == a > a <= b => (a & b) == a (same as <=) > a > b => (a & b) == b > a >= b => (a & b) == b (same as >) Probably should be: a <= b => (a & b) == a a < b => (a # b) && ((a & b) == a) a >= b => (a & b) == b a > b => (a # b) && ((a & b) == b) > > > The bug is in the frontend. > > m3-sys\m3front\src\misc\CG.m3. > > The code should be /something/ like: > > PROCEDURE Set_compare (s: Size; op: Cmp) = > VAR tmp: Val; > swap := FALSE; > BEGIN > (* a op b => BOOLEAN *) > IF Force_pair (commute := TRUE) THEN > op := M3CG.SwappedCompare [op]; > END; > IF (s <= Target.Integer.size) THEN > IF (op = Cmp.EQ) OR (op = Cmp.NE) THEN > cg.compare (Target.Word.cg_type, Target.Integer.cg_type, op); > ELSE > (* set a is less than or equal to set b, if all of set a's > members are in set b. *) > IF (op = Cmp.LT) OR (op = Cmp.LE) THEN > swap := TRUE; > Swap (); > END; > tmp := Pop (); > Push (tmp); > IF swap THEN > Swap (); > END; > cg.and (Target.Integer.cg_type); > Push (tmp); > SimpleIndirectLoad (tmp^, Target.Word.cg_type); > EVAL Force_pair (commute := TRUE); > cg.compare (Target.Word.cg_type, Target.Integer.cg_type, > Cmp.EQ); > SPop (1, "Set_compare"); > Free (tmp); > END; > ELSE > cg.set_compare (AsBytes (s), op, Target.Integer.cg_type); > END; > SPop (2, "Set_compare"); > SPush (Type.Int32); > END Set_compare; > > though this doesn't quite drive all the machinery correctly, since > it yields assertion failures in the compiler due to an unbalanced > software stack. > upgrade works, but the test case (p155) fails assertions in the > integrated backend. > > I'd love to figure this out but have to do other stuff for now. > Anyone (if there is anyone) familiar with what all is being pushed > and popped around here should be able to figure it out easily from > this mail. > Otherwise I'll stare at more later. > > ps: "small" sets should probably be anything up to the number of > bits in longint, rather than int or pointer, since that is probably > efficient enough at the next level down. This is tangential. > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Apr 14 19:18:14 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 14 Apr 2008 10:18:14 -0700 Subject: [M3devel] cm3 regression In-Reply-To: Your message of "Mon, 14 Apr 2008 07:17:53 -0000." Message-ID: <200804141718.m3EHIExE075667@camembert.async.caltech.edu> Jay writes: >--_50e47a65-f79d-472b-8eaf-fbcc30b6410e_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >new source -> compiling Cstdlib.i3"..\src\C\32BITS\BasicCtypes.i3", line 18= >: illegal based LONGINT literal, zero used"..\src\C\32BITS\BasicCtypes.i3",= > line 18: illegal based LONGINT literal, zero used > long_long =3D [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL]= >; >=20 >Why isn't this LONGINT? So that NT386 can limp along? And it'd be correct f= >or the rest, eh? >I'll try it and see.. >=20 >The underlying system (the compiler) has (U)Int[8,16,32,64] >They should just be used here imho.. >=20 >Also, what should "long" be on 64bit? >On Windows it is 32 bits always. >On 32 bit systems it is 32 bits. >I think the 64bits directory is going to be forked for AMD64_NT_*. >The Windows decision imho has successfully been applied to more code and mo= >re users so therefore is better by practical success, even if the whole iss= >ue is problematic almost no matter what. Clearly the C and Modula-3 notions= > of integers are pretty poor.. I have to re-code my program to use Int64 if I want it to use the natural INTEGER size on 64 bit machines? No thanks. From jayk123 at hotmail.com Mon Apr 14 19:52:24 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 14 Apr 2008 17:52:24 +0000 Subject: [M3devel] cm3 regression In-Reply-To: <200804141718.m3EHIExE075667@camembert.async.caltech.edu> References: Your message of "Mon, 14 Apr 2008 07:17:53 -0000." <200804141718.m3EHIExE075667@camembert.async.caltech.edu> Message-ID: Well, something has to give somewhere. INTEGER could be a "natural" signed integer if you want, however you have to balance the desire for a "natural" integer with any persistant format. It's not like 32 bit integers are going to be inefficient anywhere, so not changing the more concrete meaning of various code isn't going to really hurt it. What does hurt is 1) breaking code that really needs to represent the entire address space or 2) breaking code that really needs to maintain binary compatibility with persistant file formats. You lose either way. It just seems like the best tradeoff is to provide explicitly sized signed and unsigned types, and pointer sized signed and unsigned. And then decide what your ranges are and know that 32 bit integers are always efficient and 64 bit integers are always ok or better. Really, 32 bit integers are usually adequate or no less efficient. Really, it's hard to go wrong for efficiency, 32bit or 64bit integers, and easy to go wrong in terms of compatibility by changing the sizes of types.. - Jay > To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] cm3 regression > Date: Mon, 14 Apr 2008 10:18:14 -0700> From: mika at async.caltech.edu> > Jay writes:> >--_50e47a65-f79d-472b-8eaf-fbcc30b6410e_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >new source -> compiling Cstdlib.i3"..\src\C\32BITS\BasicCtypes.i3", line 18=> >: illegal based LONGINT literal, zero used"..\src\C\32BITS\BasicCtypes.i3",=> > line 18: illegal based LONGINT literal, zero used> > long_long =3D [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL]=> >;> >=20> >Why isn't this LONGINT? So that NT386 can limp along? And it'd be correct f=> >or the rest, eh?> >I'll try it and see..> >=20> >The underlying system (the compiler) has (U)Int[8,16,32,64]> >They should just be used here imho..> >=20> >Also, what should "long" be on 64bit?> >On Windows it is 32 bits always.> >On 32 bit systems it is 32 bits.> >I think the 64bits directory is going to be forked for AMD64_NT_*.> >The Windows decision imho has successfully been applied to more code and mo=> >re users so therefore is better by practical success, even if the whole iss=> >ue is problematic almost no matter what. Clearly the C and Modula-3 notions=> > of integers are pretty poor..> > I have to re-code my program to use Int64 if I want it to use the> natural INTEGER size on 64 bit machines? No thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Apr 14 19:55:47 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 14 Apr 2008 17:55:47 +0000 Subject: [M3devel] small set comparisons understood, now just to understand the front end code.. In-Reply-To: <32E9EDBE-18FC-4F1B-8653-E60FC39DD534@cs.purdue.edu> References: <32E9EDBE-18FC-4F1B-8653-E60FC39DD534@cs.purdue.edu> Message-ID: If they fit in an INT32, use an INT32. But if they fit in an INT64, that's still probably more efficient than an otherwise "big set". Well, of course, there's always the inline vs. non-inline size vs. speed. And here I teeter toward hypocricy in taking advantage of two "natural" integer types. Heck, generalize it to a list of efficient sizes: 8, 16, 32, 64, pick the smallest that fits, and in the future when otherwise there would have been LONGLONGINT, add 128 to the list. - Jay CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] small set comparisons understood, now just to understand the front end code..Date: Mon, 14 Apr 2008 11:22:35 -0400 I would hesitate to implement small sets as LONGINT instead of INTEGER, since there is no guarantee that LONGINT is necessarily efficient, whereas INTEGER is intended to be the same as the natural word size of the target. I could take a look at this but not anytime soon, since I have several other things I need to work on. On Apr 14, 2008, at 10:51 AM, Jay wrote: currently set <,>,<=,>= are implemented merely asinteger <,>,<=,>= Yes, that seems quite wrong. I can't imagine things ever worked properly if that is how they are implemented. This is wrong. I believe it should be: a < b => (a & b) == aa <= b => (a & b) == a (same as <=) a > b => (a & b) == ba >= b => (a & b) == b (same as >) Probably should be: a <= b => (a & b) == a a < b => (a # b) && ((a & b) == a) a >= b => (a & b) == b a > b => (a # b) && ((a & b) == b) The bug is in the frontend. m3-sys\m3front\src\misc\CG.m3. The code should be /something/ like: PROCEDURE Set_compare (s: Size; op: Cmp) =VAR tmp: Val; swap := FALSE;BEGIN (* a op b => BOOLEAN *) IF Force_pair (commute := TRUE) THEN op := M3CG.SwappedCompare [op]; END; IF (s <= Target.Integer.size) THEN IF (op = Cmp.EQ) OR (op = Cmp.NE) THEN cg.compare (Target.Word.cg_type, Target.Integer.cg_type, op); ELSE (* set a is less than or equal to set b, if all of set a's members are in set b. *) IF (op = Cmp.LT) OR (op = Cmp.LE) THEN swap := TRUE; Swap (); END; tmp := Pop (); Push (tmp); IF swap THEN Swap (); END; cg.and (Target.Integer.cg_type); Push (tmp); SimpleIndirectLoad (tmp^, Target.Word.cg_type); EVAL Force_pair (commute := TRUE); cg.compare (Target.Word.cg_type, Target.Integer.cg_type, Cmp.EQ); SPop (1, "Set_compare"); Free (tmp); END; ELSE cg.set_compare (AsBytes (s), op, Target.Integer.cg_type); END; SPop (2, "Set_compare"); SPush (Type.Int32);END Set_compare; though this doesn't quite drive all the machinery correctly, since it yields assertion failures in the compiler due to an unbalanced software stack.upgrade works, but the test case (p155) fails assertions in the integrated backend. I'd love to figure this out but have to do other stuff for now.Anyone (if there is anyone) familiar with what all is being pushed and popped around here should be able to figure it out easily from this mail.Otherwise I'll stare at more later. ps: "small" sets should probably be anything up to the number of bits in longint, rather than int or pointer, since that is probably efficient enough at the next level down. This is tangential. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Apr 14 20:14:05 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 14 Apr 2008 18:14:05 +0000 Subject: [M3devel] FW: small set comparisons understood, now just to understand the front end code.. In-Reply-To: <32E9EDBE-18FC-4F1B-8653-E60FC39DD534@cs.purdue.edu> References: <32E9EDBE-18FC-4F1B-8653-E60FC39DD534@cs.purdue.edu> Message-ID: [truncated again..] From: jayk123 at hotmail.comTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] small set comparisons understood, now just to understand the front end code..Date: Mon, 14 Apr 2008 17:55:47 +0000 If they fit in an INT32, use an INT32.But if they fit in an INT64, that's still probably more efficient than an otherwise "big set". Well, of course, there's always the inline vs. non-inline size vs. speed.And here I teeter toward hypocricy in taking advantage of two "natural" integer types.Heck, generalize it to a list of efficient sizes: 8, 16, 32, 64, pick the smallest that fits, and in the future when otherwise there would have been LONGLONGINT, add 128 to the list. - Jay[snip] -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Apr 14 20:42:07 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Apr 2008 14:42:07 -0400 Subject: [M3devel] cm3 regression In-Reply-To: <200804141718.m3EHIExE075667@camembert.async.caltech.edu> References: <200804141718.m3EHIExE075667@camembert.async.caltech.edu> Message-ID: <692B2748-B602-4A6E-B729-3C543772233F@cs.purdue.edu> I think Modula-3 has it exactly right in that the base types INTEGER and Word.T use the natural word size of the machine, and that there are no guarantees about BITSIZE on those. If you want a specific bit size you use BITS FOR or simply a subrange type, both of which pack down in memory to just the number of bytes needed. C is generally a mess since you have both LLP64 (Windows) and LP64 (everyone else, for good reason -- see http://www.unix.org/version2/whatsnew/ lp64_wp.html). In any case, yes, I expect there will need to be a fork of BasicCTypes along the lines of ILP32, LP64, and LLP64. Currently, we have the strangeness that NT386 = ILP32/LL32 (because the integrated backend can't grok LL64), but this is an anomaly. Ideally, this would go to LLP64 (IL32) to match the Win64 world. Remember, this is only for *C types*. On all 64-bit platforms, we should aim for 64-bit INTEGER and 64-bit Word.T as the native Modula-3 types. How C types fall out depends on the native C expectations of the platform, and really are just about interfacing to C APIs. On Apr 14, 2008, at 1:18 PM, Mika Nystrom wrote: > Jay writes: >> --_50e47a65-f79d-472b-8eaf-fbcc30b6410e_ >> Content-Type: text/plain; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> new source -> compiling Cstdlib.i3"..\src\C\32BITS\BasicCtypes.i3", >> line 18= >> : illegal based LONGINT literal, zero used"..\src\C\32BITS >> \BasicCtypes.i3",= >> line 18: illegal based LONGINT literal, zero used >> long_long =3D [-16_7fffffffffffffffL-1L .. >> 16_7fffffffffffffffL]= >> ; >> =20 >> Why isn't this LONGINT? So that NT386 can limp along? And it'd be >> correct f= >> or the rest, eh? >> I'll try it and see.. >> =20 >> The underlying system (the compiler) has (U)Int[8,16,32,64] >> They should just be used here imho.. >> =20 >> Also, what should "long" be on 64bit? >> On Windows it is 32 bits always. >> On 32 bit systems it is 32 bits. >> I think the 64bits directory is going to be forked for AMD64_NT_*. >> The Windows decision imho has successfully been applied to more >> code and mo= >> re users so therefore is better by practical success, even if the >> whole iss= >> ue is problematic almost no matter what. Clearly the C and Modula-3 >> notions= >> of integers are pretty poor.. > > I have to re-code my program to use Int64 if I want it to use the > natural INTEGER size on 64 bit machines? No thanks. From hosking at cs.purdue.edu Mon Apr 14 20:44:50 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Apr 2008 14:44:50 -0400 Subject: [M3devel] small set comparisons understood, now just to understand the front end code.. In-Reply-To: References: <32E9EDBE-18FC-4F1B-8653-E60FC39DD534@cs.purdue.edu> Message-ID: Premature optimization is usually time wasted and results in unnecessary complexity. On Apr 14, 2008, at 1:55 PM, Jay wrote: > If they fit in an INT32, use an INT32. > But if they fit in an INT64, that's still probably more efficient > than an otherwise "big set". > Well, of course, there's always the inline vs. non-inline size > vs. speed. > And here I teeter toward hypocricy in taking advantage of two > "natural" integer types. > Heck, generalize it to a list of efficient sizes: 8, 16, 32, 64, > pick the smallest that fits, and in the future when otherwise there > would have been LONGLONGINT, add 128 to the list. > > - Jay > > > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jayk123 at hotmail.com > Subject: Re: [M3devel] small set comparisons understood, now just to > understand the front end code.. > Date: Mon, 14 Apr 2008 11:22:35 -0400 > > I would hesitate to implement small sets as LONGINT instead of > INTEGER, since there is no guarantee that LONGINT is necessarily > efficient, whereas INTEGER is intended to be the same as the natural > word size of the target. > > I could take a look at this but not anytime soon, since I have > several other things I need to work on. > > On Apr 14, 2008, at 10:51 AM, Jay wrote: > > currently set <,>,<=,>= are implemented merely as > integer <,>,<=,>= > > Yes, that seems quite wrong. I can't imagine things ever worked > properly if that is how they are implemented. > > > > This is wrong. > > I believe it should be: > > a < b => (a & b) == a > a <= b => (a & b) == a (same as <=) > a > b => (a & b) == b > a >= b => (a & b) == b (same as >) > > Probably should be: > > a <= b => (a & b) == a > a < b => (a # b) && ((a & b) == a) > a >= b => (a & b) == b > a > b => (a # b) && ((a & b) == b) > > > > The bug is in the frontend. > > m3-sys\m3front\src\misc\CG.m3. > > The code should be /something/ like: > > PROCEDURE Set_compare (s: Size; op: Cmp) = > VAR tmp: Val; > swap := FALSE; > BEGIN > (* a op b => BOOLEAN *) > IF Force_pair (commute := TRUE) THEN > op := M3CG.SwappedCompare [op]; > END; > IF (s <= Target.Integer.size) THEN > IF (op = Cmp.EQ) OR (op = Cmp.NE) THEN > cg.compare (Target.Word.cg_type, Target.Integer.cg_type, op); > ELSE > (* set a is less than or equal to set b, if all of set a's > members are in set b. *) > IF (op = Cmp.LT) OR (op = Cmp.LE) THEN > swap := TRUE; > Swap (); > END; > tmp := Pop (); > Push (tmp); > IF swap THEN > Swap (); > END; > cg.and (Target.Integer.cg_type); > Push (tmp); > SimpleIndirectLoad (tmp^, Target.Word.cg_type); > EVAL Force_pair (commute := TRUE); > cg.compare (Target.Word.cg_type, Target.Integer.cg_type, > Cmp.EQ); > SPop (1, "Set_compare"); > Free (tmp); > END; > ELSE > cg.set_compare (AsBytes (s), op, Target.Integer.cg_type); > END; > SPop (2, "Set_compare"); > SPush (Type.Int32); > END Set_compare; > > though this doesn't quite drive all the machinery correctly, since > it yields assertion failures in the compiler due to an unbalanced > software stack. > upgrade works, but the test case (p155) fails assertions in the > integrated backend. > > I'd love to figure this out but have to do other stuff for now. > Anyone (if there is anyone) familiar with what all is being pushed > and popped around here should be able to figure it out easily from > this mail. > Otherwise I'll stare at more later. > > ps: "small" sets should probably be anything up to the number of > bits in longint, rather than int or pointer, since that is probably > efficient enough at the next level down. This is tangential. > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Apr 14 20:59:22 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 14 Apr 2008 18:59:22 +0000 Subject: [M3devel] cm3 regression In-Reply-To: <692B2748-B602-4A6E-B729-3C543772233F@cs.purdue.edu> References: <200804141718.m3EHIExE075667@camembert.async.caltech.edu> <692B2748-B602-4A6E-B729-3C543772233F@cs.purdue.edu> Message-ID: Right. Win64 will be: INTEGER = 64 bits LONGINT = 64 bits Word.T = INTEGER (should be common to all platforms) LongWord.T = LONGINT (should be common to all platforms) BasicCtypes.int = 32 bits (should be common to all platforms?) BasicCtypes.long = 32 bits (the difference) BasicCtypes.longlong = 64 bits if this even exists > mess since you have both LLP64 (Windows) and LP64 (everyone else, for > good reason -- see http://www.unix.org/version2/whatsnew/ > lp64_wp.html). In any case, yes, I expect there will need to be a I think everyone else had the advantage of: 1) doing it earlier 2) and with much less code 3) no 16 bit legacy that pushed stuff to "long" earlier, thereby taking it away as an option, whereas I GUESS on Unix int was more common, or more "care" had already been taken more often given an earlier "variety" of systems, but again #1 and #2. Hey, good redirect, want to name the directories: ILP32 (aka 32 bits) LP64 (aka 64 bits except Windows) LLP64 (aka 64 bit Windows) ? Too cryptic? While I don't want a bunch of "Win64" directories, maybe put in some selectively, and have: 32bit (same as today) 64bit (same as today) Win64 Anyway, this is still getting a bit ahead of things. - Jay > CC: jayk123 at hotmail.com; m3devel at elegosoft.com> From: hosking at cs.purdue.edu> To: mika at async.caltech.edu> Subject: Re: [M3devel] cm3 regression> Date: Mon, 14 Apr 2008 14:42:07 -0400> > I think Modula-3 has it exactly right in that the base types INTEGER > and Word.T use the natural word size of the machine, and that there > are no guarantees about BITSIZE on those. If you want a specific bit > size you use BITS FOR or simply a subrange type, both of which pack > down in memory to just the number of bytes needed. C is generally a > mess since you have both LLP64 (Windows) and LP64 (everyone else, for > good reason -- see http://www.unix.org/version2/whatsnew/ > lp64_wp.html). In any case, yes, I expect there will need to be a > fork of BasicCTypes along the lines of ILP32, LP64, and LLP64. > Currently, we have the strangeness that NT386 = ILP32/LL32 (because > the integrated backend can't grok LL64), but this is an anomaly. > Ideally, this would go to LLP64 (IL32) to match the Win64 world. > Remember, this is only for *C types*. On all 64-bit platforms, we > should aim for 64-bit INTEGER and 64-bit Word.T as the native Modula-3 > types. How C types fall out depends on the native C expectations of > the platform, and really are just about interfacing to C APIs.> > On Apr 14, 2008, at 1:18 PM, Mika Nystrom wrote:> > > Jay writes:> >> --_50e47a65-f79d-472b-8eaf-fbcc30b6410e_> >> Content-Type: text/plain; charset="iso-8859-1"> >> Content-Transfer-Encoding: quoted-printable> >>> >> new source -> compiling Cstdlib.i3"..\src\C\32BITS\BasicCtypes.i3", > >> line 18=> >> : illegal based LONGINT literal, zero used"..\src\C\32BITS > >> \BasicCtypes.i3",=> >> line 18: illegal based LONGINT literal, zero used> >> long_long =3D [-16_7fffffffffffffffL-1L .. > >> 16_7fffffffffffffffL]=> >> ;> >> =20> >> Why isn't this LONGINT? So that NT386 can limp along? And it'd be > >> correct f=> >> or the rest, eh?> >> I'll try it and see..> >> =20> >> The underlying system (the compiler) has (U)Int[8,16,32,64]> >> They should just be used here imho..> >> =20> >> Also, what should "long" be on 64bit?> >> On Windows it is 32 bits always.> >> On 32 bit systems it is 32 bits.> >> I think the 64bits directory is going to be forked for AMD64_NT_*.> >> The Windows decision imho has successfully been applied to more > >> code and mo=> >> re users so therefore is better by practical success, even if the > >> whole iss=> >> ue is problematic almost no matter what. Clearly the C and Modula-3 > >> notions=> >> of integers are pretty poor..> >> > I have to re-code my program to use Int64 if I want it to use the> > natural INTEGER size on 64 bit machines? No thanks.> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Apr 14 21:03:00 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 14 Apr 2008 19:03:00 +0000 Subject: [M3devel] small set comparisons understood, now just to understand the front end code.. In-Reply-To: References: <32E9EDBE-18FC-4F1B-8653-E60FC39DD534@cs.purdue.edu> Message-ID: Mika corrected my proposed implementation of set_compare. I had it right for <= and >= but wrong for < and >. < and > need to check if the sets are equal, in which case return false. My confidence here wasn't particularly high, I intend(ed) to test a bunch, once it works at all, and it doesn't yet. Should also 1) check the history; I suspect it never worked 2) as a stopgap if really desparate can probably omit the optimization and just use the functions but that's lame.. well, for < and >, the inline code might be kind of large actually.. could write helpers just for int-sized sets... - Jay[snip -- the below is wrong] I believe it should be: a < b => (a & b) == aa <= b => (a & b) == a (same as <=) a > b => (a & b) == ba >= b => (a & b) == b (same as >) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Apr 14 22:10:05 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 14 Apr 2008 13:10:05 -0700 Subject: [M3devel] small set comparisons understood, now just to understand the front end code.. In-Reply-To: Your message of "Mon, 14 Apr 2008 17:48:06 -0000." Message-ID: <200804142010.m3EKA5ep081393@camembert.async.caltech.edu> Sorry, I think the Green Book is completely unambiguous about this. a < b is the same as a <= b AND a # b for all a and b, no matter the type (set, integer, or floating). That's what 2.6.11 says, and it seems correct, because it implies that for sets, <= is the subset relation, and < is the proper subset relation. Mika Jay writes: >--_a67e670a-e4c4-4f68-a1a3-4f4661e52338_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > a < b "should be implemented as" (a & b) =3D=3D a=20 >=20 > I believe, and so on.=20 >I could be wrong. I only thought about it a few minutes.=20 >=20 > The current incorrect code is:=20 >PROCEDURE Set_compare (s: Size; op: Cmp) =3D BEGIN IF Force_pair (comm= >ute :=3D TRUE) THEN op :=3D M3CG.SwappedCompare [op]; END; IF (s= > <=3D Target.Integer.size) THEN cg.compare (Target.Word.cg_type, Targe= >t.Integer.cg_type, op); ELSE cg.set_compare (AsBytes (s), op, Target.I= >nteger.cg_type); END; SPop (2, "Set_eq"); SPush (Type.Int32); END= > Set_compare; >=20 >which generates simply, I think this was <=3D (jbe -- jump if below or equa= >l): >=20 >=20 > 0040119C: 56 push esi 0040119D: E8 AE FE FF FF = > call _Main__m 004011A2: 83 C4 04 add esp,4 >=20 > ... end of previous line that just called m("foo")=20 >=20 > ; push a string to print=20 > 004011A5: 8D 35 2C 12 40 00 lea esi,ds:[40122Ch] 004011AB: 56 = > push esi >=20 > ; compare two sets=20 > ; one is constant 0x15; one is a global=20 > 004011AC: 83 3D 44 90 45 00 cmp dword ptr ds:[459044h],15h = > 15 >=20 > ; spend a while converting the compare result to a boolean 004011B3: 0F = >96 45 FC setbe byte ptr [ebp-4] 004011B7: 33 DB = >xor ebx,ebx 004011B9: 8A 5D FC mov bl,byte ptr [= ebp-4] 004011BC: 83 FB 00 cmp ebx,0 004011BF: 0F 94 45 = >F8 sete byte ptr [ebp-8] 004011C3: 33 D2 xor = > edx,edx 004011C5: 8A 55 F8 mov dl,byte ptr [ebp-8] > ; and then push that boolean=20 > 004011C8: 52 push edx > 004011C9: E8 6C FF FF FF call _Main__checkM >oh, you are right, < needs to also be !=3D. >I thought it was suspicious to have only two implementations of four operat= >ions, but I did like the resulting efficiency. :) >Hey, I was at least sure the current code was wrong. >=20 > - Jay > > > >> To: jayk123 at hotmail.com> Subject: Re: [M3devel] small set comparisons und= >erstood, now just to understand the front end code.. > Date: Mon, 14 Apr 20= >08 10:16:01 -0700> From: mika at async.caltech.edu> > Jay writes:> >--_6435b74= >a-d943-44c2-9091-ab0408dc7ed0_> >Content-Type: text/plain; charset=3D"iso-8= >859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >currently set = ><,>,<=3D3D,>=3D3D are implemented merely as> >integer <,>,<=3D3D,>=3D3D> >= >=3D20> >This is wrong.> >=3D20> >I believe it should be:> >=3D20> >a < b = >=3D3D> (a & b) =3D3D=3D3D a> >a <=3D3D b =3D3D> (a & b) =3D3D=3D3D a (same = >as <=3D3D)> >a > b =3D3D> (a & b) =3D3D=3D3D b> >a >=3D3D b =3D3D> (a & b) = >=3D3D=3D3D b (same as >)> > You don't actually mean logical implication by = >your arrows do you,> but equivalence, where the objects to the left of the = >arrow refer> to the abstract sets a and b and the objects to the right of t= >he> arrow refer to bit-vector implementations (in C) of the same?> > Green = >Book, page 57, section 2.6.1:> > "In all cases, x < y means (x <=3D y) AND = >(x # y), and x > y means y < x."> > So in your syntax a > b would be ((a & = >b) =3D=3D a) && (a !=3D b).> > Also, just above it, > > "The expression x >= >=3D y is equivalent to y <=3D x."> > Why not define the operation "x >=3D y= >" and then use the two statements> from the Green Book to generate the rest= >?> > Mika= > >--_a67e670a-e4c4-4f68-a1a3-4f4661e52338_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > a < b "should be implemented as" (a &= >; b) =3D=3D a
> 
> I believe, and so on.
>I could be wrong. I only thought about it a few minutes.
> 
> The current incorrect code is:
>
PROCEDURE Set_compare (s: Size;  op: Cmp) =3D
  BEGIN
&= >nbsp;   IF Force_pair (commute :=3D TRUE) THEN
  &nb= >sp;   op :=3D M3CG.SwappedCompare [op];
    END= >;
    IF (s <=3D Target.Integer.size)
  &= >nbsp;   THEN cg.compare (Target.Word.cg_type, Target.Integer.cg_t= >ype, op);
      ELSE cg.set_compare (AsBytes (s= >), op, Target.Integer.cg_type);
    END;
  &= >nbsp; SPop (2, "Set_eq");
    SPush (Type.Int32);
&nbs= >p; END Set_compare;

> 
>which generates simply, I think this was <=3D (jbe -- jump if below or e= >qual):
> 
> 
>  0040119C: 56         &n= >bsp;       push     = >   esi
  0040119D: E8 AE FE FF FF    = > call        _Main__m
  004011A2= >: 83 C4 04           add&= >nbsp;        esp,4
> 
> ... end of previous line that just called m("foo")
> 
> ; push a string to print
>  004011A5: 8D 35 2C 12 40 00  lea     &= >nbsp;   esi,ds:[40122Ch]
  004011AB: 56   = >            &nb= >sp; push        esi
> 
> ; compare two sets
> ; one is constant 0x15; one is a global
>  004011AC: 83 3D 44 90 45 00  cmp     &= >nbsp;   dword ptr ds:[459044h],15h
    &nb= >sp;       15
> 
> ; spend a while converting the compare result to a boolean
 = > 004011B3: 0F 96 45 FC        setbe = >;      byte ptr [ebp-4]
  004011B7: 33 DB&= >nbsp;           &nbs= >p; xor         ebx,ebx
  00= >4011B9: 8A 5D FC          = >; mov         bl,byte ptr [ebp-4]R>  004011BC: 83 FB 00        = >   cmp         ebx,0
&= >nbsp; 004011BF: 0F 94 45 F8        sete&= >nbsp;       byte ptr [ebp-8]
  004011= >C3: 33 D2           = >   xor         edx,edx>  004011C5: 8A 55 F8        &= >nbsp;  mov         dl,byte ptr= > [ebp-8]

> ; and then push that boolean
>  004011C8: 52         &n= >bsp;       push     = >   edx
>  004011C9: E8 6C FF FF FF     call  &nb= >sp;     _Main__checkM


>oh, you are right, < needs to also be !=3D.
>I thought it was suspicious to have only two implementations of four operat= >ions, but I did like the resulting efficiency. :)
Hey, I was at least sure the current code was wrong.
> 
> - Jay



> >
>
>> To: jayk123 at hotmail.com
> Subject: Re: [M3devel] small set compa= >risons understood, now just to understand the front end code..
> Dat= >e: Mon, 14 Apr 2008 10:16:01 -0700
> From: mika at async.caltech.edu
= >>
> Jay writes:
> >--_6435b74a-d943-44c2-9091-ab0408dc7e= >d0_
> >Content-Type: text/plain; charset=3D"iso-8859-1"
> &g= >t;Content-Transfer-Encoding: quoted-printable
> >
> >
= >> >currently set <,>,<=3D3D,>=3D3D are implemented merely= > as
> >integer <,>,<=3D3D,>=3D3D
> >=3D20
= >> >This is wrong.
> >=3D20
> >I believe it should b= >e:
> >=3D20
> >a < b =3D3D> (a & b) =3D3D=3D3D = >a
> >a <=3D3D b =3D3D> (a & b) =3D3D=3D3D a (same as <= >;=3D3D)
> >a > b =3D3D> (a & b) =3D3D=3D3D b
> >= >;a >=3D3D b =3D3D> (a & b) =3D3D=3D3D b (same as >)
> R>> You don't actually mean logical implication by your arrows do you,R>> but equivalence, where the objects to the left of the arrow refer>> to the abstract sets a and b and the objects to the right of the
&= >gt; arrow refer to bit-vector implementations (in C) of the same?
> <= >BR>> Green Book, page 57, section 2.6.1:
>
> "In all cases,= > x < y means (x <=3D y) AND (x # y), and x > y means y < x.">>
> So in your syntax a > b would be ((a & b) =3D=3D a) &= >amp;& (a !=3D b).
>
> Also, just above it,
>
&g= >t; "The expression x >=3D y is equivalent to y <=3D x."
>
&= >gt; Why not define the operation "x >=3D y" and then use the two stateme= >nts
> from the Green Book to generate the rest?
>
> Mika= >

>= > >--_a67e670a-e4c4-4f68-a1a3-4f4661e52338_-- From jayk123 at hotmail.com Mon Apr 14 23:55:48 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 14 Apr 2008 21:55:48 +0000 Subject: [M3devel] small set comparisons understood, now just to understand the front end code.. In-Reply-To: <200804142010.m3EKA5ep081393@camembert.async.caltech.edu> References: Your message of "Mon, 14 Apr 2008 17:48:06 -0000." <200804142010.m3EKA5ep081393@camembert.async.caltech.edu> Message-ID: I think we are in agreement now on this. My original assertions were indeed wrong for <= and >=. I'm not even sure they were correct for < and >. - Jay > To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] small set comparisons understood, now just to understand the front end code.. > Date: Mon, 14 Apr 2008 13:10:05 -0700> From: mika at async.caltech.edu> > Sorry, I think the Green Book is completely unambiguous about this.> > a < b is the same as a <= b AND a # b for all a and b, no matter> the type (set, integer, or floating). That's what 2.6.11 says, and> it seems correct, because it implies that for sets, <= is the subset> relation, and < is the proper subset relation.> > Mika> > Jay writes:> >--_a67e670a-e4c4-4f68-a1a3-4f4661e52338_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> > a < b "should be implemented as" (a & b) =3D=3D a=20> >=20> > I believe, and so on.=20> >I could be wrong. I only thought about it a few minutes.=20> >=20> > The current incorrect code is:=20> >PROCEDURE Set_compare (s: Size; op: Cmp) =3D BEGIN IF Force_pair (comm=> >ute :=3D TRUE) THEN op :=3D M3CG.SwappedCompare [op]; END; IF (s=> > <=3D Target.Integer.size) THEN cg.compare (Target.Word.cg_type, Targe=> >t.Integer.cg_type, op); ELSE cg.set_compare (AsBytes (s), op, Target.I=> >nteger.cg_type); END; SPop (2, "Set_eq"); SPush (Type.Int32); END=> > Set_compare;> >=20> >which generates simply, I think this was <=3D (jbe -- jump if below or equa=> >l):> >=20> >=20> > 0040119C: 56 push esi 0040119D: E8 AE FE FF FF => > call _Main__m 004011A2: 83 C4 04 add esp,4> >=20> > ... end of previous line that just called m("foo")=20> >=20> > ; push a string to print=20> > 004011A5: 8D 35 2C 12 40 00 lea esi,ds:[40122Ch] 004011AB: 56 => > push esi> >=20> > ; compare two sets=20> > ; one is constant 0x15; one is a global=20> > 004011AC: 83 3D 44 90 45 00 cmp dword ptr ds:[459044h],15h => > 15> >=20> > ; spend a while converting the compare result to a boolean 004011B3: 0F => >96 45 FC setbe byte ptr [ebp-4] 004011B7: 33 DB => >xor ebx,ebx 004011B9: 8A 5D FC mov bl,byte ptr [=> ebp-4] 004011BC: 83 FB 00 cmp ebx,0 004011BF: 0F 94 45 => >F8 sete byte ptr [ebp-8] 004011C3: 33 D2 xor => > edx,edx 004011C5: 8A 55 F8 mov dl,byte ptr [ebp-8]> > ; and then push that boolean=20> > 004011C8: 52 push edx> > 004011C9: E8 6C FF FF FF call _Main__checkM> >oh, you are right, < needs to also be !=3D.> >I thought it was suspicious to have only two implementations of four operat=> >ions, but I did like the resulting efficiency. :)> >Hey, I was at least sure the current code was wrong.> >=20> > - Jay> >> >> >> >> To: jayk123 at hotmail.com> Subject: Re: [M3devel] small set comparisons und=> >erstood, now just to understand the front end code.. > Date: Mon, 14 Apr 20=> >08 10:16:01 -0700> From: mika at async.caltech.edu> > Jay writes:> >--_6435b74=> >a-d943-44c2-9091-ab0408dc7ed0_> >Content-Type: text/plain; charset=3D"iso-8=> >859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >currently set => ><,>,<=3D3D,>=3D3D are implemented merely as> >integer <,>,<=3D3D,>=3D3D> >=> >=3D20> >This is wrong.> >=3D20> >I believe it should be:> >=3D20> >a < b => >=3D3D> (a & b) =3D3D=3D3D a> >a <=3D3D b =3D3D> (a & b) =3D3D=3D3D a (same => >as <=3D3D)> >a > b =3D3D> (a & b) =3D3D=3D3D b> >a >=3D3D b =3D3D> (a & b) => >=3D3D=3D3D b (same as >)> > You don't actually mean logical implication by => >your arrows do you,> but equivalence, where the objects to the left of the => >arrow refer> to the abstract sets a and b and the objects to the right of t=> >he> arrow refer to bit-vector implementations (in C) of the same?> > Green => >Book, page 57, section 2.6.1:> > "In all cases, x < y means (x <=3D y) AND => >(x # y), and x > y means y < x."> > So in your syntax a > b would be ((a & => >b) =3D=3D a) && (a !=3D b).> > Also, just above it, > > "The expression x >=> >=3D y is equivalent to y <=3D x."> > Why not define the operation "x >=3D y=> >" and then use the two statements> from the Green Book to generate the rest=> >?> > Mika=> >> >--_a67e670a-e4c4-4f68-a1a3-4f4661e52338_> >Content-Type: text/html; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >> >> >> > a < b "should be implemented as" (a &=> >; b) =3D=3D a
> > 
> > I believe, and so on.
> >I could be wrong. I only thought about it a few minutes.
> > 
> > The current incorrect code is:
> >
PROCEDURE Set_compare (s: Size;  op: Cmp) =3D
  BEGIN
&=> >nbsp;   IF Force_pair (commute :=3D TRUE) THEN
  &nb=> >sp;   op :=3D M3CG.SwappedCompare [op];
    END=> >;
    IF (s <=3D Target.Integer.size)
  &=> >nbsp;   THEN cg.compare (Target.Word.cg_type, Target.Integer.cg_t=> >ype, op);
      ELSE cg.set_compare (AsBytes (s=> >), op, Target.Integer.cg_type);
    END;
  &=> >nbsp; SPop (2, "Set_eq");
    SPush (Type.Int32);
&nbs=> >p; END Set_compare;

> > 
> >which generates simply, I think this was <=3D (jbe -- jump if below or e=> >qual):
> > 
> > 
> >  0040119C: 56         &n=> >bsp;       push     => >   esi
  0040119D: E8 AE FE FF FF    => > call        _Main__m
  004011A2=> >: 83 C4 04           add&=> >nbsp;        esp,4
> > 
> > ... end of previous line that just called m("foo")
> > 
> > ; push a string to print
> >  004011A5: 8D 35 2C 12 40 00  lea     &=> >nbsp;   esi,ds:[40122Ch]
  004011AB: 56   => >            &nb=> >sp; push        esi
> > 
> > ; compare two sets
> > ; one is constant 0x15; one is a global
> >  004011AC: 83 3D 44 90 45 00  cmp     &=> >nbsp;   dword ptr ds:[459044h],15h
    &nb=> >sp;       15
> > 
> > ; spend a while converting the compare result to a boolean
 => > 004011B3: 0F 96 45 FC        setbe => >;      byte ptr [ebp-4]
  004011B7: 33 DB&=> >nbsp;           &nbs=> >p; xor         ebx,ebx
  00=> >4011B9: 8A 5D FC          => >; mov         bl,byte ptr [ebp-4] >R>  004011BC: 83 FB 00        => >   cmp         ebx,0
&=> >nbsp; 004011BF: 0F 94 45 F8        sete&=> >nbsp;       byte ptr [ebp-8]
  004011=> >C3: 33 D2           => >   xor         edx,edx >>  004011C5: 8A 55 F8        &=> >nbsp;  mov         dl,byte ptr=> > [ebp-8]

> > ; and then push that boolean
> >  004011C8: 52         &n=> >bsp;       push     => >   edx
> >  004011C9: E8 6C FF FF FF     call  &nb=> >sp;     _Main__checkM


> >oh, you are right, < needs to also be !=3D.
> >I thought it was suspicious to have only two implementations of four operat=> >ions, but I did like the resulting efficiency. :)
> Hey, I was at least sure the current code was wrong.
> > 
> > - Jay



> >> >
> >
> >> To: jayk123 at hotmail.com
> Subject: Re: [M3devel] small set compa=> >risons understood, now just to understand the front end code..
> Dat=> >e: Mon, 14 Apr 2008 10:16:01 -0700
> From: mika at async.caltech.edu
=> >>
> Jay writes:
> >--_6435b74a-d943-44c2-9091-ab0408dc7e=> >d0_
> >Content-Type: text/plain; charset=3D"iso-8859-1"
> &g=> >t;Content-Transfer-Encoding: quoted-printable
> >
> >
=> >> >currently set <,>,<=3D3D,>=3D3D are implemented merely=> > as
> >integer <,>,<=3D3D,>=3D3D
> >=3D20
=> >> >This is wrong.
> >=3D20
> >I believe it should b=> >e:
> >=3D20
> >a < b =3D3D> (a & b) =3D3D=3D3D => >a
> >a <=3D3D b =3D3D> (a & b) =3D3D=3D3D a (same as <=> >;=3D3D)
> >a > b =3D3D> (a & b) =3D3D=3D3D b
> >=> >;a >=3D3D b =3D3D> (a & b) =3D3D=3D3D b (same as >)
> >R>> You don't actually mean logical implication by your arrows do you, >R>> but equivalence, where the objects to the left of the arrow refer >>> to the abstract sets a and b and the objects to the right of the
&=> >gt; arrow refer to bit-vector implementations (in C) of the same?
> <=> >BR>> Green Book, page 57, section 2.6.1:
>
> "In all cases,=> > x < y means (x <=3D y) AND (x # y), and x > y means y < x." >>>
> So in your syntax a > b would be ((a & b) =3D=3D a) &=> >amp;& (a !=3D b).
>
> Also, just above it,
>
&g=> >t; "The expression x >=3D y is equivalent to y <=3D x."
>
&=> >gt; Why not define the operation "x >=3D y" and then use the two stateme=> >nts
> from the Green Book to generate the rest?
>
> Mika=> >

> >=> >> >--_a67e670a-e4c4-4f68-a1a3-4f4661e52338_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Apr 14 23:58:31 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 14 Apr 2008 21:58:31 +0000 Subject: [M3devel] small set comparisons understood, now just to understand the front end code.. In-Reply-To: References: <32E9EDBE-18FC-4F1B-8653-E60FC39DD534@cs.purdue.edu> Message-ID: And doing no optimization up front, or not designing to allow it later, leads to it being difficult to doing all of it later. Early optimization and profiling followed by late optimization are both needed. A balance must be found. "Premature" has a negative connotation, "early" does not. Complexity is imho often overstated also.. ..Jay CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] small set comparisons understood, now just to understand the front end code..Date: Mon, 14 Apr 2008 14:44:50 -0400 Premature optimization is usually time wasted and results in unnecessary complexity. On Apr 14, 2008, at 1:55 PM, Jay wrote: If they fit in an INT32, use an INT32.But if they fit in an INT64, that's still probably more efficient than an otherwise "big set". Well, of course, there's always the inline vs. non-inline size vs. speed.And here I teeter toward hypocricy in taking advantage of two "natural" integer types.Heck, generalize it to a list of efficient sizes: 8, 16, 32, 64, pick the smallest that fits, and in the future when otherwise there would have been LONGLONGINT, add 128 to the list. - Jay CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] small set comparisons understood, now just to understand the front end code..Date: Mon, 14 Apr 2008 11:22:35 -0400 I would hesitate to implement small sets as LONGINT instead of INTEGER, since there is no guarantee that LONGINT is necessarily efficient, whereas INTEGER is intended to be the same as the natural word size of the target. I could take a look at this but not anytime soon, since I have several other things I need to work on. On Apr 14, 2008, at 10:51 AM, Jay wrote: currently set <,>,<=,>= are implemented merely asinteger <,>,<=,>= Yes, that seems quite wrong. I can't imagine things ever worked properly if that is how they are implemented. This is wrong. I believe it should be: a < b => (a & b) == aa <= b => (a & b) == a (same as <=) a > b => (a & b) == ba >= b => (a & b) == b (same as >) Probably should be: a <= b => (a & b) == a a < b => (a # b) && ((a & b) == a) a >= b => (a & b) == b a > b => (a # b) && ((a & b) == b) The bug is in the frontend. m3-sys\m3front\src\misc\CG.m3. The code should be /something/ like: PROCEDURE Set_compare (s: Size; op: Cmp) =VAR tmp: Val; swap := FALSE;BEGIN (* a op b => BOOLEAN *) IF Force_pair (commute := TRUE) THEN op := M3CG.SwappedCompare [op]; END; IF (s <= Target.Integer.size) THEN IF (op = Cmp.EQ) OR (op = Cmp.NE) THEN cg.compare (Target.Word.cg_type, Target.Integer.cg_type, op); ELSE (* set a is less than or equal to set b, if all of set a's members are in set b. *) IF (op = Cmp.LT) OR (op = Cmp.LE) THEN swap := TRUE; Swap (); END; tmp := Pop (); Push (tmp); IF swap THEN Swap (); END; cg.and (Target.Integer.cg_type); Push (tmp); SimpleIndirectLoad (tmp^, Target.Word.cg_type); EVAL Force_pair (commute := TRUE); cg.compare (Target.Word.cg_type, Target.Integer.cg_type, Cmp.EQ); SPop (1, "Set_compare"); Free (tmp); END; ELSE cg.set_compare (AsBytes (s), op, Target.Integer.cg_type); END; SPop (2, "Set_compare"); SPush (Type.Int32);END Set_compare; though this doesn't quite drive all the machinery correctly, since it yields assertion failures in the compiler due to an unbalanced software stack.upgrade works, but the test case (p155) fails assertions in the integrated backend. I'd love to figure this out but have to do other stuff for now.Anyone (if there is anyone) familiar with what all is being pushed and popped around here should be able to figure it out easily from this mail.Otherwise I'll stare at more later. ps: "small" sets should probably be anything up to the number of bits in longint, rather than int or pointer, since that is probably efficient enough at the next level down. This is tangential. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Apr 15 08:35:16 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 15 Apr 2008 08:35:16 +0200 Subject: [M3devel] new cm3 backend dependencies Message-ID: <20080415083516.i3vino6o0w400osw@mail.elegosoft.com> Hi Ronny, Antony Hosking has updated the gcc in cm3, which leads to new build dependencies which are not available at our regression test systems: 1088 NEXT configure: error: Building GCC requires GMP 4.1+ and MPFR 2.3.0+. Can you provide these? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From ronny.forberger at elegosoft.com Tue Apr 15 12:51:55 2008 From: ronny.forberger at elegosoft.com (Ronny Forberger) Date: Tue, 15 Apr 2008 12:51:55 +0200 Subject: [M3devel] new cm3 backend dependencies In-Reply-To: <20080415083516.i3vino6o0w400osw@mail.elegosoft.com> References: <20080415083516.i3vino6o0w400osw@mail.elegosoft.com> Message-ID: <20080415125155.wi1hnkfy4gsk4cks@mail.elegosoft.com> Hi there, on birch.elego.de (LINUXLIBC6) there is GMP 4.2.1 on the package management system, which I installed. Also there is MPFR but only at version <2.3.0, this is why I installed MPFR 2.3.0 under the prefix /usr/local. I guess cm3 will automatically find the libs there. On new.elego.de (FreeBSD4) there was libgmp-4.2.1_1 already installed under /usr/local. MPFR was too old there too, so I installed 2.3.0 manually to /usr/contrib. I guess cm3 needs to be told to use libs residing under /usr/contrib ? Cheers, Ronny -- Message from: Olaf Wagner Date: Di 15 Apr 2008 08:35:16 CEST Subject: new cm3 backend dependencies > Hi Ronny, > > Antony Hosking has updated the gcc in cm3, which leads to new > build dependencies which are not available at our regression test > systems: > > 1088 NEXT configure: error: Building GCC requires GMP 4.1+ and MPFR > 2.3.0+. > > Can you provide these? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -- Ronny Forberger Systemadministration & IT-Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Geb?ude 12, Raum 227 D-13355 Berlin Tel. +49 30 23 45 86 96 ronny.forberger at elegosoft.com Fax +49 30 23 45 86 95 http://www.elegosoft.com Gesch?ftsf?hrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Apr 15 13:05:31 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 15 Apr 2008 13:05:31 +0200 Subject: [M3devel] new cm3 backend dependencies In-Reply-To: <20080415125155.wi1hnkfy4gsk4cks@mail.elegosoft.com> References: <20080415083516.i3vino6o0w400osw@mail.elegosoft.com> <20080415125155.wi1hnkfy4gsk4cks@mail.elegosoft.com> Message-ID: <20080415130531.kjb7fdsbjswk4sck@mail.elegosoft.com> Quoting Ronny Forberger : > Hi there, > > on birch.elego.de (LINUXLIBC6) there is GMP 4.2.1 on the package > management system, which I installed. > > Also there is MPFR but only at version <2.3.0, this is why I installed > MPFR 2.3.0 under the prefix /usr/local. I guess cm3 will automatically > find the libs there. > > On new.elego.de (FreeBSD4) there was libgmp-4.2.1_1 already installed > under /usr/local. > > MPFR was too old there too, so I installed 2.3.0 manually to > /usr/contrib. I guess cm3 needs to be told to use libs residing under > /usr/contrib ? Probably. Doesn't the FreeBSD ports system provide an update? If you can build it manually, perhaps it is sufficient to just increase the version numbers in the port and send the patch to a FreeBSD committer / the port maintainer? Olaf > Cheers, > > Ronny > > -- > Message from: Olaf Wagner > Date: Di 15 Apr 2008 08:35:16 CEST > Subject: new cm3 backend dependencies > > >> Hi Ronny, >> >> Antony Hosking has updated the gcc in cm3, which leads to new >> build dependencies which are not available at our regression test >> systems: >> >> 1088 NEXT configure: error: Building GCC requires GMP 4.1+ and MPFR >> 2.3.0+. >> >> Can you provide these? >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > > > -- > > Ronny Forberger > Systemadministration & IT-Support > > elego Software Solutions GmbH > Gustav-Meyer-Allee 25 > Geb?ude 12, Raum 227 > D-13355 Berlin > > Tel. +49 30 23 45 86 96 ronny.forberger at elegosoft.com > Fax +49 30 23 45 86 95 http://www.elegosoft.com > > Gesch?ftsf?hrer: Olaf Wagner, Sitz Berlin > Amtsgericht Berlin-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 hendrik at topoi.pooq.com Tue Apr 15 13:07:40 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 15 Apr 2008 07:07:40 -0400 Subject: [M3devel] small set comparisons understood, now just to understand the front end code.. In-Reply-To: <32E9EDBE-18FC-4F1B-8653-E60FC39DD534@cs.purdue.edu> References: <32E9EDBE-18FC-4F1B-8653-E60FC39DD534@cs.purdue.edu> Message-ID: <20080415110740.GA12952@topoi.pooq.com> On Mon, Apr 14, 2008 at 11:22:35AM -0400, Tony Hosking wrote: > > Yes, that seems quite wrong. I can't imagine things ever worked > properly if that is how they are implemented. Maybe stick a test in the compiler to see if < > <= >= are ever used on small sets anywhere in the m3 system? You might want to do this anyway in case anyone is relying on them doing integer comparisons. I seem to remember using them for subset comparisons in a Pascal program I converted to modula 3 many years ago. I was using the PM3 compiler then, and I haven't tried it on cm3 yet. I'd have to check the code to see what I was really doing, though. -- hendrik From hendrik at topoi.pooq.com Tue Apr 15 13:09:19 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 15 Apr 2008 07:09:19 -0400 Subject: [M3devel] small set comparisons understood, now just to understand the front end code.. In-Reply-To: References: <32E9EDBE-18FC-4F1B-8653-E60FC39DD534@cs.purdue.edu> Message-ID: <20080415110919.GB12952@topoi.pooq.com> On Mon, Apr 14, 2008 at 07:03:00PM +0000, Jay wrote: > Should also 1) check the history; I suspect it never worked 2) as a stopgap if really desparate can probably omit the optimization and just use the functions but that's lame.. well, for < and >, the inline code might be kind of large actually.. could write helpers just for int-sized sets... You might compare the cm3 code with the pm3 code. I think I may have used it on pm3 long ago without mishap. -- hendrik From jayk123 at hotmail.com Tue Apr 15 13:23:38 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 15 Apr 2008 11:23:38 +0000 Subject: [M3devel] small set comparisons understood, now just to understand the front end code.. In-Reply-To: <20080415110919.GB12952@topoi.pooq.com> References: <32E9EDBE-18FC-4F1B-8653-E60FC39DD534@cs.purdue.edu> <20080415110919.GB12952@topoi.pooq.com> Message-ID: PM3 has it wrong too. http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/pm3/m3/pm3/language/modula3/m3compiler/m3front/src/misc/CG.m3?rev=1.4;content-type=text%2FplainPROCEDURE Set_compare (s: Size; op: Cmp) = BEGIN IF Force_pair (commute := TRUE) THEN op := M3CG.SwappedCompare [op]; END; IF (s <= Target.Integer.size) THEN cg.compare (Target.Word.cg_type, Target.Integer.cg_type, op); ELSE cg.set_compare (AsBytes (s), op, Target.Integer.cg_type); END; SPop (2, "Set_eq"); SPush (Type.Int32); END Set_compare; I didn't run it and look at the generate code, but this is the same as cm3 had and it just generated <,<=,>,>= for integers. Anyway, I checked in a fix for it. - Jay > Date: Tue, 15 Apr 2008 07:09:19 -0400> From: hendrik at topoi.pooq.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] small set comparisons understood, now just to understand the front end code..> > On Mon, Apr 14, 2008 at 07:03:00PM +0000, Jay wrote:> > > Should also 1) check the history; I suspect it never worked 2) as a stopgap if really desparate can probably omit the optimization and just use the functions but that's lame.. well, for < and >, the inline code might be kind of large actually.. could write helpers just for int-sized sets...> > You might compare the cm3 code with the pm3 code. I think I may have > used it on pm3 long ago without mishap.> > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Apr 15 13:24:13 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 15 Apr 2008 11:24:13 +0000 Subject: [M3devel] small set comparisons understood, now just to understand the front end code.. In-Reply-To: <20080415110919.GB12952@topoi.pooq.com> References: <32E9EDBE-18FC-4F1B-8653-E60FC39DD534@cs.purdue.edu> <20080415110919.GB12952@topoi.pooq.com> Message-ID: PM3 has it wrong too. http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/pm3/m3/pm3/language/modula3/m3compiler/m3front/src/misc/CG.m3?rev=1.4;content-type=text%2FplainPROCEDURE Set_compare (s: Size; op: Cmp) = BEGIN IF Force_pair (commute := TRUE) THEN op := M3CG.SwappedCompare [op]; END; IF (s <= Target.Integer.size) THEN cg.compare (Target.Word.cg_type, Target.Integer.cg_type, op); ELSE cg.set_compare (AsBytes (s), op, Target.Integer.cg_type); END; SPop (2, "Set_eq"); SPush (Type.Int32); END Set_compare; I didn't run it and look at the generate code, but this is the same as cm3 had and it just generated <,<=,>,>= for integers. Anyway, I checked in a fix for it. - Jay > Date: Tue, 15 Apr 2008 07:09:19 -0400> From: hendrik at topoi.pooq.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] small set comparisons understood, now just to understand the front end code..> > On Mon, Apr 14, 2008 at 07:03:00PM +0000, Jay wrote:> > > Should also 1) check the history; I suspect it never worked 2) as a stopgap if really desparate can probably omit the optimization and just use the functions but that's lame.. well, for < and >, the inline code might be kind of large actually.. could write helpers just for int-sized sets...> > You might compare the cm3 code with the pm3 code. I think I may have > used it on pm3 long ago without mishap.> > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronny.forberger at elegosoft.com Tue Apr 15 13:31:29 2008 From: ronny.forberger at elegosoft.com (Ronny Forberger) Date: Tue, 15 Apr 2008 13:31:29 +0200 Subject: [M3devel] new cm3 backend dependencies In-Reply-To: <20080415130531.kjb7fdsbjswk4sck@mail.elegosoft.com> References: <20080415083516.i3vino6o0w400osw@mail.elegosoft.com> <20080415125155.wi1hnkfy4gsk4cks@mail.elegosoft.com> <20080415130531.kjb7fdsbjswk4sck@mail.elegosoft.com> Message-ID: <20080415133129.d6xwc1x1oo40co0c@mail.elegosoft.com> -- Message from: Olaf Wagner Date: Di 15 Apr 2008 13:05:31 CEST Subject: Re: new cm3 backend dependencies > Quoting Ronny Forberger : > >> Hi there, >> >> on birch.elego.de (LINUXLIBC6) there is GMP 4.2.1 on the package >> management system, which I installed. >> >> Also there is MPFR but only at version <2.3.0, this is why I installed >> MPFR 2.3.0 under the prefix /usr/local. I guess cm3 will automatically >> find the libs there. >> >> On new.elego.de (FreeBSD4) there was libgmp-4.2.1_1 already installed >> under /usr/local. >> >> MPFR was too old there too, so I installed 2.3.0 manually to >> /usr/contrib. I guess cm3 needs to be told to use libs residing under >> /usr/contrib ? > > Probably. Doesn't the FreeBSD ports system provide an update? Only with a later release tag (RELASE_6_3_0), you know I won't upgrade ports on a productive system apart from upgrading the base system as this can cause tremendous problems and might break other things running on the machine. > If you can build it manually, perhaps it is sufficient to just > increase the version numbers in the port and send the patch > to a FreeBSD committer / the port maintainer? It has been built, but the next FreeBSD release and higher cope it anyways. I think it's better to some day upgrade new.elego.de to FreeBSD 7 in order to have more current package versions. But we could probably move the FreeBSD-targeted cm3 regression tests from new.elego.de to willow.elego.de, which can be more easily upgraded to FreeBSD 7. Stupidly this would cause trouble in the tinderbox view, when a new hostname would appear. Cheers, Ronny > > Olaf > >> Cheers, >> >> Ronny >> >> -- >> Message from: Olaf Wagner >> Date: Di 15 Apr 2008 08:35:16 CEST >> Subject: new cm3 backend dependencies >> >> >>> Hi Ronny, >>> >>> Antony Hosking has updated the gcc in cm3, which leads to new >>> build dependencies which are not available at our regression test >>> systems: >>> >>> 1088 NEXT configure: error: Building GCC requires GMP 4.1+ and MPFR >>> 2.3.0+. >>> >>> Can you provide these? >>> >>> Olaf >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>> 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >> >> >> >> -- >> >> Ronny Forberger >> Systemadministration & IT-Support >> >> elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 >> Geb?ude 12, Raum 227 >> D-13355 Berlin >> >> Tel. +49 30 23 45 86 96 ronny.forberger at elegosoft.com >> Fax +49 30 23 45 86 95 http://www.elegosoft.com >> >> Gesch?ftsf?hrer: Olaf Wagner, Sitz Berlin >> Amtsgericht Berlin-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 -- Ronny Forberger Systemadministration & IT-Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Geb?ude 12, Raum 227 D-13355 Berlin Tel. +49 30 23 45 86 96 ronny.forberger at elegosoft.com Fax +49 30 23 45 86 95 http://www.elegosoft.com Gesch?ftsf?hrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Tue Apr 15 14:09:13 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 15 Apr 2008 08:09:13 -0400 Subject: [M3devel] small set comparisons understood, now just to understand the front end code.. In-Reply-To: <20080415110740.GA12952@topoi.pooq.com> References: <32E9EDBE-18FC-4F1B-8653-E60FC39DD534@cs.purdue.edu> <20080415110740.GA12952@topoi.pooq.com> Message-ID: <20080415120913.GC12952@topoi.pooq.com> On Tue, Apr 15, 2008 at 07:07:40AM -0400, hendrik at topoi.pooq.com wrote: > On Mon, Apr 14, 2008 at 11:22:35AM -0400, Tony Hosking wrote: > > > > Yes, that seems quite wrong. I can't imagine things ever worked > > properly if that is how they are implemented. > > Maybe stick a test in the compiler to see if < > <= >= are ever used on > small sets anywhere in the m3 system? You might want to do this anyway > in case anyone is relying on them doing integer comparisons. > > I seem to remember using them for subset comparisons in a Pascal program > I converted to modula 3 many years ago. I was using the PM3 compiler > then, and I haven't tried it on cm3 yet. I'd have to check the code to > see what I was really doing, though. Found it. I didn't actually use < or <=. I used *. - hendrik From wagner at elegosoft.com Tue Apr 15 15:11:17 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 15 Apr 2008 15:11:17 +0200 Subject: [M3devel] new cm3 backend dependencies In-Reply-To: <20080415133129.d6xwc1x1oo40co0c@mail.elegosoft.com> References: <20080415083516.i3vino6o0w400osw@mail.elegosoft.com> <20080415125155.wi1hnkfy4gsk4cks@mail.elegosoft.com> <20080415130531.kjb7fdsbjswk4sck@mail.elegosoft.com> <20080415133129.d6xwc1x1oo40co0c@mail.elegosoft.com> Message-ID: <20080415151117.ns7s255eckoowgow@mail.elegosoft.com> Quoting Ronny Forberger : > -- > Message from: Olaf Wagner > Date: Di 15 Apr 2008 13:05:31 CEST > Subject: Re: new cm3 backend dependencies > > >> Quoting Ronny Forberger : >> >>> Hi there, >>> >>> on birch.elego.de (LINUXLIBC6) there is GMP 4.2.1 on the package >>> management system, which I installed. >>> >>> Also there is MPFR but only at version <2.3.0, this is why I installed >>> MPFR 2.3.0 under the prefix /usr/local. I guess cm3 will automatically >>> find the libs there. >>> >>> On new.elego.de (FreeBSD4) there was libgmp-4.2.1_1 already installed >>> under /usr/local. >>> >>> MPFR was too old there too, so I installed 2.3.0 manually to >>> /usr/contrib. I guess cm3 needs to be told to use libs residing under >>> /usr/contrib ? >> >> Probably. Doesn't the FreeBSD ports system provide an update? > > Only with a later release tag (RELASE_6_3_0), you know I won't upgrade > ports on a productive system apart from upgrading the base system as > this can cause tremendous problems and might break other things running > on the machine. This is OK as a base strategy, but not in the following cases: (1) security updates of ports which need to be installed (2) development servers which need to provide a more recent and active view for the programmer To (1): Even on stable production systems security fixes should lead to port upgrades. To (2): Developers often need the latest version of any software, so if the standard one provided is too old, a second port hierarchy needs to be available. Is this the current use of /usr/contrib? >> If you can build it manually, perhaps it is sufficient to just >> increase the version numbers in the port and send the patch >> to a FreeBSD committer / the port maintainer? > > It has been built, but the next FreeBSD release and higher cope it > anyways. I think it's better to some day upgrade new.elego.de to > FreeBSD 7 in order to have more current package versions. This is a major upgrade and might have other impacts due to incompatibilities. I'd be more careful in upgrading the base system than in upgrading ports. > But we could probably move the FreeBSD-targeted cm3 regression tests > from new.elego.de to willow.elego.de, which can be more easily upgraded > to FreeBSD 7. Stupidly this would cause trouble in the tinderbox view, > when a new hostname would appear. This may be a good idea anyway, but we should progress carefully towards the FreeBSD 7 upgrade. We should also take this discussion from the m3devel-list ;-) I'll see if I can provide a fix for gcc to scan /usr/contrib for dependencies, too. It may take some time. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Tue Apr 15 19:38:56 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 15 Apr 2008 13:38:56 -0400 Subject: [M3devel] new cm3 backend dependencies In-Reply-To: <20080415125155.wi1hnkfy4gsk4cks@mail.elegosoft.com> References: <20080415083516.i3vino6o0w400osw@mail.elegosoft.com> <20080415125155.wi1hnkfy4gsk4cks@mail.elegosoft.com> Message-ID: <5B0A38FF-7170-40A1-AD8F-6E792AC73CD8@cs.purdue.edu> Yes, forgot to mention this. /usr/lib will get foun by configure, so that is the best option if it is not installed as a package to /usr/lib. On Apr 15, 2008, at 6:51 AM, Ronny Forberger wrote: > Hi there, > > on birch.elego.de (LINUXLIBC6) there is GMP 4.2.1 on the package > management system, which I installed. > > Also there is MPFR but only at version <2.3.0, this is why I > installed MPFR 2.3.0 under the prefix /usr/local. I guess cm3 will > automatically find the libs there. > > On new.elego.de (FreeBSD4) there was libgmp-4.2.1_1 already > installed under /usr/local. > > MPFR was too old there too, so I installed 2.3.0 manually to /usr/ > contrib. I guess cm3 needs to be told to use libs residing under / > usr/contrib ? > > Cheers, > > Ronny > > -- > Message from: Olaf Wagner > Date: Di 15 Apr 2008 08:35:16 CEST > Subject: new cm3 backend dependencies > > >> Hi Ronny, >> >> Antony Hosking has updated the gcc in cm3, which leads to new >> build dependencies which are not available at our regression test >> systems: >> >> 1088 NEXT configure: error: Building GCC requires GMP 4.1+ and >> MPFR >> 2.3.0+. >> >> Can you provide these? >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >> Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >> 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >> Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 > > > > -- > > Ronny Forberger > Systemadministration & IT-Support > > elego Software Solutions GmbH > Gustav-Meyer-Allee 25 > Geb?ude 12, Raum 227 > D-13355 Berlin > > Tel. +49 30 23 45 86 96 ronny.forberger at elegosoft.com > Fax +49 30 23 45 86 95 http://www.elegosoft.com > > Gesch?ftsf?hrer: Olaf Wagner, Sitz Berlin > Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 > > From jayk123 at hotmail.com Wed Apr 16 12:18:38 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 16 Apr 2008 10:18:38 +0000 Subject: [M3devel] cm3 regression In-Reply-To: <692B2748-B602-4A6E-B729-3C543772233F@cs.purdue.edu> References: <200804141718.m3EHIExE075667@camembert.async.caltech.edu> <692B2748-B602-4A6E-B729-3C543772233F@cs.purdue.edu> Message-ID: [tangential...] I think the definition of INTEGER is OK, but it'd be nice imho for the language or m3core to also build-in UINTEGER, INT8, INT16, INT32, INT64, UINT8, UINT16, UINT32, UINT64, just so folks wouldn't have to provide them themselves. (CARDINAL I don't think is what I want.) Add them somewhere in m3core? MODULE Integers; ? Unfortunately, actually, I want more than this, and then coming up with names is hard. I want "safe" integers that raise exceptions or something upon overflow. I want "unsafe" integers that silently "wrap around". And maybe "arbitrary precision" integers that grow to accomodate, but also are smart and shrink to throw away trailing zeros. I know you can often push stuff out of the language and into a library. As long as the language allows the library writer to provide a "nice enough" interface. For example the use of the plus sign on user defined types.. You know..like C++... but less complicated and easier to implement and fully understand... In C, "officially", unsigned integers are unsafe and wrap around silently, and overflow on signed integers is undefined, however in reality, they are also silent, and I suspect, but am not sure, that I want both versions..maybe only for compat with existing code. Which reminds me -- am I correct that the Modula-3 language defines overflow as raising an exception but nobody implements it that way? I can check. Are folks interested in fixing that? - Jay > CC: jayk123 at hotmail.com; m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: mika at async.caltech.edu > Subject: Re: [M3devel] cm3 regression > Date: Mon, 14 Apr 2008 14:42:07 -0400 > > I think Modula-3 has it exactly right in that the base types INTEGER > and Word.T use the natural word size of the machine, and that there > are no guarantees about BITSIZE on those. If you want a specific bit > size you use BITS FOR or simply a subrange type, both of which pack > down in memory to just the number of bytes needed. C is generally a > mess since you have both LLP64 (Windows) and LP64 (everyone else, for > good reason -- see http://www.unix.org/version2/whatsnew/ > lp64_wp.html). In any case, yes, I expect there will need to be a > fork of BasicCTypes along the lines of ILP32, LP64, and LLP64. > Currently, we have the strangeness that NT386 = ILP32/LL32 (because > the integrated backend can't grok LL64), but this is an anomaly. > Ideally, this would go to LLP64 (IL32) to match the Win64 world. > Remember, this is only for *C types*. On all 64-bit platforms, we > should aim for 64-bit INTEGER and 64-bit Word.T as the native Modula-3 > types. How C types fall out depends on the native C expectations of > the platform, and really are just about interfacing to C APIs. > > On Apr 14, 2008, at 1:18 PM, Mika Nystrom wrote: > > > Jay writes: > >> --_50e47a65-f79d-472b-8eaf-fbcc30b6410e_ > >> Content-Type: text/plain; charset="iso-8859-1" > >> Content-Transfer-Encoding: quoted-printable > >> > >> new source -> compiling Cstdlib.i3"..\src\C\32BITS\BasicCtypes.i3", > >> line 18= > >> : illegal based LONGINT literal, zero used"..\src\C\32BITS > >> \BasicCtypes.i3",= > >> line 18: illegal based LONGINT literal, zero used > >> long_long =3D [-16_7fffffffffffffffL-1L .. > >> 16_7fffffffffffffffL]= > >> ; > >> =20 > >> Why isn't this LONGINT? So that NT386 can limp along? And it'd be > >> correct f= > >> or the rest, eh? > >> I'll try it and see.. > >> =20 > >> The underlying system (the compiler) has (U)Int[8,16,32,64] > >> They should just be used here imho.. > >> =20 > >> Also, what should "long" be on 64bit? > >> On Windows it is 32 bits always. > >> On 32 bit systems it is 32 bits. > >> I think the 64bits directory is going to be forked for AMD64_NT_*. > >> The Windows decision imho has successfully been applied to more > >> code and mo= > >> re users so therefore is better by practical success, even if the > >> whole iss= > >> ue is problematic almost no matter what. Clearly the C and Modula-3 > >> notions= > >> of integers are pretty poor.. > > > > I have to re-code my program to use Int64 if I want it to use the > > natural INTEGER size on 64 bit machines? No thanks. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Apr 16 12:47:58 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 16 Apr 2008 12:47:58 +0200 Subject: [M3devel] cm3 regression In-Reply-To: References: <200804141718.m3EHIExE075667@camembert.async.caltech.edu> <692B2748-B602-4A6E-B729-3C543772233F@cs.purdue.edu> Message-ID: <20080416124758.lgyai5sjs40wc8k4@mail.elegosoft.com> Quoting Jay : > [tangential...] > > I think the definition of INTEGER is OK, but it'd be nice imho for > the language or m3core to also build-in UINTEGER, INT8, INT16, > INT32, INT64, UINT8, UINT16, UINT32, UINT64, just so folks wouldn't > have to provide them themselves. (CARDINAL I don't think is what I > want.) > Add them somewhere in m3core? > MODULE Integers; ? Such things may be convenient for programmers, but are left out of the language because the specification must not become too long, I think. I'd opt for library extensions in this case. > Unfortunately, actually, I want more than this, and then coming up > with names is hard. > > I know you can often push stuff out of the language and into a > library. As long as the language allows the library writer to > provide a "nice enough" interface. For example the use of the plus > sign on user defined types.. You know..like C++... but less > complicated and easier to implement and fully understand... Ah, operator overloading opens up another of Pandora's boxes, I think. It will dramatically increase the complexity of the language. > In C, "officially", unsigned integers are unsafe and wrap around > silently, and overflow on signed integers is undefined, however in > reality, they are also silent, and I suspect, but am not sure, that > I want both versions..maybe only for compat with existing code. > > Which reminds me -- am I correct that the Modula-3 language defines > overflow as raising an exception but nobody implements it that way? > I can check. Are folks interested in fixing that? Yes, IIRC there are no checks on integer overflow; this is an implementation flaw. How would you provide this? Add generation of checks on every integer operation? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Wed Apr 16 14:30:14 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 16 Apr 2008 08:30:14 -0400 Subject: [M3devel] cm3 regression In-Reply-To: <20080416124758.lgyai5sjs40wc8k4@mail.elegosoft.com> References: <200804141718.m3EHIExE075667@camembert.async.caltech.edu> <692B2748-B602-4A6E-B729-3C543772233F@cs.purdue.edu> <20080416124758.lgyai5sjs40wc8k4@mail.elegosoft.com> Message-ID: <20080416123014.GA13596@topoi.pooq.com> On Wed, Apr 16, 2008 at 12:47:58PM +0200, Olaf Wagner wrote: > Quoting Jay : > > >[tangential...] > > > >I think the definition of INTEGER is OK, but it'd be nice imho for > >the language or m3core to also build-in UINTEGER, INT8, INT16, > >INT32, INT64, UINT8, UINT16, UINT32, UINT64, just so folks wouldn't > >have to provide them themselves. (CARDINAL I don't think is what I > >want.) > >Add them somewhere in m3core? > >MODULE Integers; ? > > Such things may be convenient for programmers, but are left out of the > language because the specification must not become too long, I think. > I'd opt for library extensions in this case. > > >Unfortunately, actually, I want more than this, and then coming up > >with names is hard. > > > >I know you can often push stuff out of the language and into a > >library. As long as the language allows the library writer to > >provide a "nice enough" interface. For example the use of the plus > >sign on user defined types.. You know..like C++... but less > >complicated and easier to implement and fully understand... > > Ah, operator overloading opens up another of Pandora's boxes, > I think. It will dramatically increase the complexity of the > language. > > >In C, "officially", unsigned integers are unsafe and wrap around > >silently, and overflow on signed integers is undefined, however in > >reality, they are also silent, and I suspect, but am not sure, that > >I want both versions..maybe only for compat with existing code. > > > >Which reminds me -- am I correct that the Modula-3 language defines > >overflow as raising an exception but nobody implements it that way? > >I can check. Are folks interested in fixing that? > > Yes, IIRC there are no checks on integer overflow; this is an > implementation flaw. How would you provide this? Add generation of > checks on every integer operation? IIRC, most hardware provides a mechanism for efficient overflow detection. If the language does not provide access to this hardware mechanism, if becomes difficult and inefficient for the programmer to detect overflow. Since checked overflow is necessary for many security issues, the language needs to make it possible to check. How it should do so can be a subject for much dispute. And for Modula 3 it may be difficult if the gcc back end does not support it. -- hendrik From jayk123 at hotmail.com Wed Apr 16 15:31:03 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 16 Apr 2008 13:31:03 +0000 Subject: [M3devel] current cm3cg works? Message-ID: bootstrapping from 5.4.0 on KUbuntu Hardy Heron 8.4 beta AMD64 cm3 just core dumps..around ThreadF__Init probably the setjmp/longjmp scrambling bug 5.4.0 is what the regression framework defaulted to starting with, that's how I picked it. so tried from d5.7.0-2008-04-10-02-00-05 instead my cm3cg yields like: new source -> compiling SystemPosix.m3 ../src/POSIX/SystemPosix.m3: In function 'System__Hostname': ../src/POSIX/SystemPosix.m3:37: internal compiler error: in simplify_subreg, at simplify-rtx.c:4923 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling FSUnix_cm3.m3 ../src/POSIX/FSUnix_cm3.m3: In function 'FSUtils__IsReadable': ../src/POSIX/FSUnix_cm3.m3:10: internal compiler error: in int_mode_for_mode, at stor-layout.c:258 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling TextUtils.m3 ../src/cm3/TextUtils.m3: In function 'TextUtils__SkipLeft': ../src/cm3/TextUtils.m3:36: internal compiler error: in int_mode_for_mode, at stor-layout.c:258 Please submit a full bug report, so now going back to the cm3cg in d5.7.0-2008-04-10-02-00-05 That works, scripts/python/upgrade.py succeeds, having set OMIT_GCC (probably should be CM3_OMIT_GCC). No time right now to dig in.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Apr 16 16:08:11 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 16 Apr 2008 14:08:11 +0000 Subject: [M3devel] cm3 regression In-Reply-To: <20080416124758.lgyai5sjs40wc8k4@mail.elegosoft.com> References: <200804141718.m3EHIExE075667@camembert.async.caltech.edu> <692B2748-B602-4A6E-B729-3C543772233F@cs.purdue.edu> <20080416124758.lgyai5sjs40wc8k4@mail.elegosoft.com> Message-ID: > > it'd be nice imho for the language or m3core to also build-in UINTEGER, INT8, INT16, > > INT32, INT64, UINT8, UINT16, UINT32, UINT64, just so folks wouldn't > > have to provide them themselves. (CARDINAL I don't think is what I > > want.) > > Add them somewhere in m3core? > > MODULE Integers; ? > > Such things may be convenient for programmers, but are left out of the > language because the specification must not become too long, I think. > I'd opt for library extensions in this case. Good enough. Except I'm not sure about UINTEGER..like..why is CARDINAL only half range? I'd have to dig in..NOT now.. > Yes, IIRC there are no checks on integer overflow; this is an > implementation flaw. How would you provide this? Add generation of > checks on every integer operation? Well, it's a no-win situation. The check would bloat the code. Even function calls would bloat and slow. Probably function calls. And then hopefully optimize them some. For example: FOR i := 0 TO n DO ... END; Check up front then n isn't negative, and then no checking is needed for the incrementing of n to overflow. Similarly, FOR i := 0 TO n BY 2 DO ... END; or whatever is the syntax, check if the start/end are divisible by the increment and the start is less than the end, and then no overflow check needed. I guess on most architectures every add/sub/mul/div instruction would tend to have one additional instruction, a conditional branch, after it. It will take some investigation. Perhaps gnat (GNU Ada compiler, part of gcc) or gpc (Pascal, I think likewise, maybe) already provide this though. Maybe just some simple reuse. There'd probably be pragmas or other types to choise behavior, esp. in unsafe modules. Anyway, none of this particular soon, at least by me, I have a bunch of other things I want to do or see done first. But sure we can talk about it or someone else can do it. :) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Wed Apr 16 17:17:23 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 16 Apr 2008 08:17:23 -0700 Subject: [M3devel] cm3 regression In-Reply-To: Your message of "Wed, 16 Apr 2008 10:18:38 -0000." Message-ID: <200804161517.m3GFHNTt056611@camembert.async.caltech.edu> Jay writes: >--_17f831a5-9311-459c-8ba3-fd6675a58221_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >[tangential...] > >I think the definition of INTEGER is OK, but it'd be nice imho for the lang= >uage or m3core to also build-in UINTEGER, INT8, INT16, INT32, INT64, UINT8,= > UINT16, UINT32, UINT64, just so folks wouldn't have to provide them themse= >lves. (CARDINAL I don't think is what I want.) >Add them somewhere in m3core? >MODULE Integers; ? I don't see why you can't provide all these types for yourself in a library that users can import or not as they see fit... as long as my old INTEGER programs are still going to use the "default fast integer type" on the machine! I can see your arguments for using such pre-defined fixed-width types inside system-dependent compiler bits or specific system-dependent source files even in other situations. (Although I would still argue that part of the point of Modula-3 is to get away from this kind of system-dependent-everything programming! Write once, run anywhere! Oops, am I using someone else's slogan?) > >Unfortunately, actually, I want more than this, and then coming up with nam= >es is hard. > >I want "safe" integers that raise exceptions or something upon overflow. INTEGER/CARDINAL? You could just name yours INTEGER32, CARDINAL64, etc. According to the Green Book, overflows for these types are supposed to raise exceptions or cause some other kind of runtime error. (Actually, I am not sure it says so explicitly, but that is definitely the simplest interpretation of what it does say.) If you want exceptions on overflow, you do want CARDINAL, not UINTEGER. Or what would you like 4-5 to return in this "exceptional unsigned" integer type? >I want "unsafe" integers that silently "wrap around". Word.T? Word128.T? By the way there is nothing "unsafe" about this. "Unsafe" has a very specific meaning to Modula-3 people, which I think it would be nice if we could maintain at least on the "m3devel" mailing list! See sections 2.1 (first paragraph of the language definition), 2.5.7, and 2.7 of the Green Book. >And maybe "arbitrary precision" integers that grow to accomodate, but also = >are smart and shrink to throw away trailing zeros. Isn't there already a library for this in CM3? Mika From rodney.bates at wichita.edu Wed Apr 16 22:40:57 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Wed, 16 Apr 2008 15:40:57 -0500 Subject: [M3devel] cm3 regression In-Reply-To: References: <200804141718.m3EHIExE075667@camembert.async.caltech.edu> <692B2748-B602-4A6E-B729-3C543772233F@cs.purdue.edu> <20080416124758.lgyai5sjs40wc8k4@mail.elegosoft.com> Message-ID: <48066459.8000301@wichita.edu> Jay wrote: >>>it'd be nice imho for the language or m3core to also build-in UINTEGER, INT8, INT16, >>>INT32, INT64, UINT8, UINT16, UINT32, UINT64, just so folks wouldn't >>>have to provide them themselves. (CARDINAL I don't think is what I >>>want.) >>>Add them somewhere in m3core? >>>MODULE Integers; ? >> >>Such things may be convenient for programmers, but are left out of the >>language because the specification must not become too long, I think. >>I'd opt for library extensions in this case. > > > Good enough. > Except I'm not sure about UINTEGER..like..why is CARDINAL only half range? > I'd have to dig in..NOT now.. > I've been through this in Modula-2. There, CARDINAL is a whole, unsigned range. Unfortunately, this created a linguistic and portability nightmare. It was worse because I don't think the original Modula-2 definition completely specified things like assignability between the two, operators on mixtures of the two, implied conversions, etc. I know different implementations were different to the point it was difficult even to write code that would compile on them all. Maybe there is a cleaner way to have two distinct types, one signed, one unsigned, and both full range, but it would at least be tricky. The Modula-3 way is found in Word. Word.T is the same type as INTEGER, but the operations in Word (e.g. Word.Times) apply unsigned interpretation to the bits of the same-typed value. This avoids a lot of problems. So for full range, unsigned, values, use Word (and probably, to show your intent to readers, declare variables as Word.T rather than INTEGER, even though it is the same type). As for CARDINAL in Modula-3, it was originally exactly [0..LAST(INTEGER)]. This was changed later to say it is "just like" [0..LAST(INTEGER)]. It was years before I fully understood this. I once posted a question on the M3 newsgroup about it and gave up waiting for an answer. Then I read the compiler code and found what it means, literally, is that CARDINAL is a different type from [0..LAST(INTEGER)], but the two have all the same legal operations. This distinction seldom matters, because it is almost always assignability and not type equality that is relevant. Which didn't help explain why. Then there was an answer to my question saying that the change in the definition of CARDINAL was to support Pickles, but this still left me in the dark. Finally, while working on Pickles, it dawned on me that, without the change, it would not be possible for Pickles to change the size of a CARDINAL between 32 & 64 bits. The type [0..LAST(INTEGER)] (or any other similar subrange) is a different type if LAST(INTEGER) has a different value. CARDINAL, in contrast, can change range between platforms and still be the same type. Moral: Don't pickle anything whose type contains values like LAST(INTEGER) that differ from platform to platform. > >>Yes, IIRC there are no checks on integer overflow; this is an >>implementation flaw. How would you provide this? Add generation of >>checks on every integer operation? > > > Well, it's a no-win situation. > The check would bloat the code. > Even function calls would bloat and slow. > Probably function calls. I happen to be extremely conservative on the value of detecting runtime errors, even at efficiency cost. I heard some horror stories in the early years of my career about programs that had been in use for years and whose output had been used to plan the expenditure of huge amounts of money, then were accidentally found to be producing wrong (though not obviously so) output, that would have been caught by running with runtime checks enabled. In any case, big time cost increases (e.g. double) associated with a few operations very often amortize over the whole program's run time to only 1% or 2%. > > And then hopefully optimize them some. > For example: > FOR i := 0 TO n DO > ... > END; > > Check up front then n isn't negative, and then no checking is needed for the incrementing of n to overflow. Overflow in compiler-generated arithmetic is a little different than in arithmetic explicitly coded by the programmer. In this example, the language specifically exempts the compiler from worrying about this. 2.3.16, last sentence: "If the upper bound of the loop is LAST(INTEGER), it should be rewritten as a WHILE loop to avoid overflow." As for other optimizations, the language specifies the semantics, so a compiler is free to do anything that complies with this. > > Similarly, > FOR i := 0 TO n BY 2 DO > > ... > > END; > > or whatever is the syntax, check if the start/end are divisible by the increment and the start is less than the end, and then no overflow check needed -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From dabenavidesd at yahoo.es Wed Apr 16 23:47:16 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 16 Apr 2008 23:47:16 +0200 (CEST) Subject: [M3devel] cm3 regression In-Reply-To: <48066459.8000301@wichita.edu> Message-ID: <734362.39663.qm@web27109.mail.ukl.yahoo.com> Hi all: The best idea I thing, tough I'm not an expert is to use static methods at the low level of the m3 system, let's say the gcc backend. This is not something really easy, but it's doable. I know for Open64 project http://www.open64.net, see "Implement a static program analysis tool based on Open64 compiler". It's something I found interesting in that area. SRC Modula-3 version 3.3 does not do arithmetic overflow or underflow checking, see the manual reference attached in the mail (see section 1.11.1). But what about pm3 or cm3? The other way it's also more traditional with static tools in the source code of the compiled program (well it's more tedious for most of us, it's using a specification language for a checker). Someone has checked open 64 as a possible backend of cm3? Thanks "Rodney M. Bates" escribi?: Jay wrote: >>>it'd be nice imho for the language or m3core to also build-in UINTEGER, INT8, INT16, >>>INT32, INT64, UINT8, UINT16, UINT32, UINT64, just so folks wouldn't >>>have to provide them themselves. (CARDINAL I don't think is what I >>>want.) >>>Add them somewhere in m3core? >>>MODULE Integers; ? >> >>Such things may be convenient for programmers, but are left out of the >>language because the specification must not become too long, I think. >>I'd opt for library extensions in this case. > > > Good enough. > Except I'm not sure about UINTEGER..like..why is CARDINAL only half range? > I'd have to dig in..NOT now.. > I've been through this in Modula-2. There, CARDINAL is a whole, unsigned range. Unfortunately, this created a linguistic and portability nightmare. It was worse because I don't think the original Modula-2 definition completely specified things like assignability between the two, operators on mixtures of the two, implied conversions, etc. I know different implementations were different to the point it was difficult even to write code that would compile on them all. Maybe there is a cleaner way to have two distinct types, one signed, one unsigned, and both full range, but it would at least be tricky. The Modula-3 way is found in Word. Word.T is the same type as INTEGER, but the operations in Word (e.g. Word.Times) apply unsigned interpretation to the bits of the same-typed value. This avoids a lot of problems. So for full range, unsigned, values, use Word (and probably, to show your intent to readers, declare variables as Word.T rather than INTEGER, even though it is the same type). As for CARDINAL in Modula-3, it was originally exactly [0..LAST(INTEGER)]. This was changed later to say it is "just like" [0..LAST(INTEGER)]. It was years before I fully understood this. I once posted a question on the M3 newsgroup about it and gave up waiting for an answer. Then I read the compiler code and found what it means, literally, is that CARDINAL is a different type from [0..LAST(INTEGER)], but the two have all the same legal operations. This distinction seldom matters, because it is almost always assignability and not type equality that is relevant. Which didn't help explain why. Then there was an answer to my question saying that the change in the definition of CARDINAL was to support Pickles, but this still left me in the dark. Finally, while working on Pickles, it dawned on me that, without the change, it would not be possible for Pickles to change the size of a CARDINAL between 32 & 64 bits. The type [0..LAST(INTEGER)] (or any other similar subrange) is a different type if LAST(INTEGER) has a different value. CARDINAL, in contrast, can change range between platforms and still be the same type. Moral: Don't pickle anything whose type contains values like LAST(INTEGER) that differ from platform to platform. > >>Yes, IIRC there are no checks on integer overflow; this is an >>implementation flaw. How would you provide this? Add generation of >>checks on every integer operation? > > > Well, it's a no-win situation. > The check would bloat the code. > Even function calls would bloat and slow. > Probably function calls. I happen to be extremely conservative on the value of detecting runtime errors, even at efficiency cost. I heard some horror stories in the early years of my career about programs that had been in use for years and whose output had been used to plan the expenditure of huge amounts of money, then were accidentally found to be producing wrong (though not obviously so) output, that would have been caught by running with runtime checks enabled. In any case, big time cost increases (e.g. double) associated with a few operations very often amortize over the whole program's run time to only 1% or 2%. > > And then hopefully optimize them some. > For example: > FOR i := 0 TO n DO > ... > END; > > Check up front then n isn't negative, and then no checking is needed for the incrementing of n to overflow. Overflow in compiler-generated arithmetic is a little different than in arithmetic explicitly coded by the programmer. In this example, the language specifically exempts the compiler from worrying about this. 2.3.16, last sentence: "If the upper bound of the loop is LAST(INTEGER), it should be rewritten as a WHILE loop to avoid overflow." As for other optimizations, the language specifies the semantics, so a compiler is free to do anything that complies with this. > > Similarly, > FOR i := 0 TO n BY 2 DO > > ... > > END; > > or whatever is the syntax, check if the start/end are divisible by the increment and the start is less than the end, and then no overflow check needed -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu --------------------------------- Tu correo tambi?n desde el m?vil. Desc?rgate gratis Yahoo! Go. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SRCm3-3.3.ps.gz Type: application/x-gzip Size: 95592 bytes Desc: 18170785-SRCm3-3.3.ps.gz URL: From neels at elego.de Thu Apr 17 00:59:56 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Thu, 17 Apr 2008 00:59:56 +0200 Subject: [M3devel] snapshot compilation fails on FreeBSD Message-ID: <480684EC.4060401@elego.de> Hi all, on new.elego.de, a FreeBSD 6.2-RELEASE-p3, using the files cm3-min-POSIX-FreeBSD4-d5.7.0-2008-04-14-01-30-39.tgz cm3-src-gnu-d5.7.0-2008-04-16-14-07-05.tgz cm3-src-std-d5.6.0-2008-02-23-22-14-00.tgz cm3-src-sys-d5.7.0-2008-04-16-14-07-05.tgz and running ./cminstall -i issuing installation target as /home/neels/local-new/cm3 then changing the $PATH so that $ which cm3 /home/neels/local-new/cm3/bin/cm3 and running $ cd scripts $ ./do-cm3-core.sh buildship yielded after a few minutes the following error: ... ==> /home/neels/cm3/cm3/m3-libs/m3core done === package /home/neels/cm3/cm3/m3-libs/libm3 === +++ cm3 -build -DROOT='/home/neels/cm3/cm3' -DCM3_VERSION_TEXT='d5.6.0' -DCM3_VERSION_NUMBER='050600' -DCM3_LAST_CHANGED='2008-01-31' && cm3 -ship -DROOT='/home/neels/cm3/cm3' -DCM3_VERSION_TEXT='d5.6.0' -DCM3_VERSION_NUMBER='050600' -DCM3_LAST_CHANGED='2008-01-31' +++ --- building in FreeBSD4 --- ignoring ../src/m3overrides new source -> compiling Atom.i3 new source -> compiling AtomList.i3 new source -> compiling OSError.i3 new source -> compiling File.i3 new source -> compiling RegularFile.i3 new source -> compiling Pipe.i3 new source -> compiling TextSeq.i3 new source -> compiling Pathname.i3 new source -> compiling FS.i3 new source -> compiling Process.i3 new source -> compiling Socket.i3 new source -> compiling Terminal.i3 new source -> compiling FS.m3 new source -> compiling Terminal.m3 new source -> compiling RegularFile.m3 new source -> compiling Pipe.m3 new source -> compiling Socket.m3 new source -> compiling OSConfig.i3 new source -> compiling OSErrorPosix.i3 new source -> compiling Fmt.i3 new source -> compiling OSErrorPosix.m3 new source -> compiling FilePosix.i3 new source -> compiling FilePosix.m3 new source -> compiling FSPosix.m3 new source -> compiling PipePosix.m3 new source -> compiling PathnamePosix.m3 new source -> compiling Env.i3 new source -> compiling ProcessPosix.m3 new source -> compiling SocketPosix.m3 Fatal Error: bad version stamps: SocketPosix.m3 version stamp mismatch: Compiler.Platform => SocketPosix.m3 => Compiler.i3 version stamp mismatch: Compiler.ThisPlatform => SocketPosix.m3 => Compiler.i3 *** execution of cm3 -build -DROOT='/home/neels/cm3/cm3' -DCM3_VERSION_TEXT='d5.6.0' -DCM3_VERSION_NUMBER='050600' -DCM3_LAST_CHANGED='2008-01-31' && cm3 -ship -DROOT='/home/neels/cm3/cm3' -DCM3_VERSION_TEXT='d5.6.0' -DCM3_VERSION_NUMBER='050600' -DCM3_LAST_CHANGED='2008-01-31' failed *** What does this mean? Thanks, Neels From hosking at cs.purdue.edu Thu Apr 17 01:24:37 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 16 Apr 2008 19:24:37 -0400 Subject: [M3devel] snapshot compilation fails on FreeBSD In-Reply-To: <480684EC.4060401@elego.de> References: <480684EC.4060401@elego.de> Message-ID: <0CE452FA-BE6F-40BC-8530-6AD84909223A@cs.purdue.edu> This is a result of the recent addition of an additional target AMD64_DARWIN to the compiler. You need to compile a new bootstrap compiler with the new target in it and use that to compile m3core. 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 Apr 16, 2008, at 6:59 PM, Neels Janosch Hofmeyr wrote: > Hi all, > > on new.elego.de, a FreeBSD 6.2-RELEASE-p3, using the files > > cm3-min-POSIX-FreeBSD4-d5.7.0-2008-04-14-01-30-39.tgz > cm3-src-gnu-d5.7.0-2008-04-16-14-07-05.tgz > cm3-src-std-d5.6.0-2008-02-23-22-14-00.tgz > cm3-src-sys-d5.7.0-2008-04-16-14-07-05.tgz > > > and running > > ./cminstall -i > > issuing installation target as > > /home/neels/local-new/cm3 > > then changing the $PATH so that > > $ which cm3 > /home/neels/local-new/cm3/bin/cm3 > > > and running > > $ cd scripts > $ ./do-cm3-core.sh buildship > > > yielded after a few minutes the following error: > > ... > ==> /home/neels/cm3/cm3/m3-libs/m3core done > > === package /home/neels/cm3/cm3/m3-libs/libm3 === > +++ cm3 -build -DROOT='/home/neels/cm3/cm3' - > DCM3_VERSION_TEXT='d5.6.0' > -DCM3_VERSION_NUMBER='050600' -DCM3_LAST_CHANGED='2008-01-31' && cm3 > -ship -DROOT='/home/neels/cm3/cm3' -DCM3_VERSION_TEXT='d5.6.0' > -DCM3_VERSION_NUMBER='050600' -DCM3_LAST_CHANGED='2008-01-31' +++ > --- building in FreeBSD4 --- > > ignoring ../src/m3overrides > > new source -> compiling Atom.i3 > new source -> compiling AtomList.i3 > new source -> compiling OSError.i3 > new source -> compiling File.i3 > new source -> compiling RegularFile.i3 > new source -> compiling Pipe.i3 > new source -> compiling TextSeq.i3 > new source -> compiling Pathname.i3 > new source -> compiling FS.i3 > new source -> compiling Process.i3 > new source -> compiling Socket.i3 > new source -> compiling Terminal.i3 > new source -> compiling FS.m3 > new source -> compiling Terminal.m3 > new source -> compiling RegularFile.m3 > new source -> compiling Pipe.m3 > new source -> compiling Socket.m3 > new source -> compiling OSConfig.i3 > new source -> compiling OSErrorPosix.i3 > new source -> compiling Fmt.i3 > new source -> compiling OSErrorPosix.m3 > new source -> compiling FilePosix.i3 > new source -> compiling FilePosix.m3 > new source -> compiling FSPosix.m3 > new source -> compiling PipePosix.m3 > new source -> compiling PathnamePosix.m3 > new source -> compiling Env.i3 > new source -> compiling ProcessPosix.m3 > new source -> compiling SocketPosix.m3 > > Fatal Error: bad version stamps: SocketPosix.m3 > > version stamp mismatch: Compiler.Platform > => SocketPosix.m3 > => Compiler.i3 > version stamp mismatch: Compiler.ThisPlatform > => SocketPosix.m3 > => Compiler.i3 > *** execution of cm3 -build -DROOT='/home/neels/cm3/cm3' > -DCM3_VERSION_TEXT='d5.6.0' -DCM3_VERSION_NUMBER='050600' > -DCM3_LAST_CHANGED='2008-01-31' && cm3 -ship > -DROOT='/home/neels/cm3/cm3' -DCM3_VERSION_TEXT='d5.6.0' > -DCM3_VERSION_NUMBER='050600' -DCM3_LAST_CHANGED='2008-01-31' > failed *** > > > > What does this mean? > > Thanks, > Neels -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Apr 17 08:40:10 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 17 Apr 2008 08:40:10 +0200 Subject: [M3devel] new gcc build time Message-ID: <20080417084010.k3clt47rk8go4www@mail.elegosoft.com> The first regression test run on my own system has now been successful after the import of the new gcc. The run time has increased dramatically from about 45 minutes to more than 5 hours :-/ Can anybody explain this? And can we do something about it? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Thu Apr 17 13:53:22 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 17 Apr 2008 11:53:22 +0000 Subject: [M3devel] new gcc build time In-Reply-To: <20080417084010.k3clt47rk8go4www@mail.elegosoft.com> References: <20080417084010.k3clt47rk8go4www@mail.elegosoft.com> Message-ID: I see this too. I've been experimenting.. --disable-bootstrap? I don't know yet. You know, it wants to build gcc to build gcc, but the host gcc usually suffices. Unless maybe bootstrapping from other than gcc, like using the Sun/SGI/AIX/whatever compilers? (Or old gcc on Mac OSX, has trouble building lots of stuff, though a switch worked..) It's also a pain to build on an AMD64 system, even though x86 stuff generally works. I have a whiny email coming up.. There's also this stage1, 2, 3 stuff, related to gcc building itself to build itself, and then again to verify. - Jay > Date: Thu, 17 Apr 2008 08:40:10 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] new gcc build time > > The first regression test run on my own system has now been successful > after the import of the new gcc. > > The run time has increased dramatically from about 45 minutes to > more than 5 hours :-/ > > Can anybody explain this? And can we do something about it? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 jayk123 at hotmail.com Thu Apr 17 14:03:59 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 17 Apr 2008 12:03:59 +0000 Subject: [M3devel] biarch, multilib, etc? Message-ID: Can anyone explain how Linux and gcc are managing that AMD64 systems can run and presumably build x86 code? I know there is /lib32 and /lib64. I know there is gcc -m32 and gcc -m64. I know that gcc itself delegates out to target specific executables, so one gcc plus flags suffices, it's those other executables that multiply out. That ld has the -m flag. That as has --32 and --64. I don't know how much stuff goes through gcc, vs. needs the get the as/ld flags correct. I'm not talking about Modula-3 here, but, like of building gcc and its dependencies. I can deal with the smaller Modula-3 system contained in far more readable Quake code than all the "sh" and layers upon layers of makefiles and autoconf and sh and m4 etc.. ./configure on various things tend to build just AMD64. It appears in general that for any apt-get install foo you can often but not always apt-get install foo-i386 This is on KUbuntu 8.4 Hardy Heron KDE4 beta AMD64 (mouthful!) It looks like in general: CC="gcc -m32" .../configure --prefix=/usr --libdir=/usr/lib32 --build=i686-pc-linux-gnu is what you want, but that many packages are only native. in particular gmp and mpfr: apt-get install mpfr-i386 => no luck Maybe these are not considered "mainstream"? I'll build them myself, something like: cd /usr/src apt-get source mpfr mkdir -p obj/mpfr cd obj/mpfr CC="gcc -m32" /usr/src/mpfr-2.3.1.dfsg.1/configure --prefix=/usr --libdir=/usr/lib32 --build=i686-pc-linux-gnu make sudo make install cd /usr/src apt-get source libgmp3-dev mkdir -p /usr/src/obj/gmp cd /usr/src/obj/obj CC="gcc -m32" /usr/src/gmp-4.2.2+dfsg/configure --prefix=/usr --libdir=/usr/lib32 --build=i686-pc-linux-gnu make sudo make install You know, I just want building the Modula-3 system on AMD64_LINUX to at first merely build an x86 hosted, x86 targeted binary. And then start changing things. And between host, target, and build, I find the names confusing. I understand why there are three -- the current system to build the compiler, a system to run the compiler, a system to run the compiler's output, but these names host, target, build, aren't very mnemonic with me yet. Is it build=now, host=runs the compier, target=runs the compiler's output? I'll dig around. I know, I can figure it all out, there's the www to search, but this biarch/multilib is hard to find the docs for..and I can't read the masses of m4/sh/gmake.. ps: it's easy to get the ld to crash when doing this stuff wrong.. (I can explain how Windows does it, fyi. 1) The system is "doubled up", generally .dlls and .exes, but not kernel and drivers c:\windows\system32 is native c:\windows\syswow64 is 32bit Yeah it's wierd/backwards, but it is source compatible. There is runtime magic to redirect from "system32" in 32 bit processes to syswow64. Though if folks used the very long standing APIs, this wouldn't have been needed. Oh well. There is also c:\program files and c:\program files (x86). I guess people are better about using the APIs here. "Introspection" is "broken" but this -- link -dump against c:\windows\system32 can get "redirected" but devtools aren't the priority and it does all generally work out, despite the hokiness. The registry is similarly doubled up and redirected, in some places at least, since it tends to give paths to .dlls -- a process is either 32bit or 64bit -- can't load one type .dll in other type process. On the devtools side, well, you know, NT always had ppc/mips/alpha/x86, so .libs are generally already in a directory named "i386" or "x86". In any case, folks don't hardcode paths as much, because they are already so variable. So you set up your environment or such using the %LIB% variable and it works easily. For running devtools, there is a separate set of .exes for each target. And sometimes for host. The matrix is filled out as necessary. AMD64 runs x86 fast so not always useful to fill out the matrix. Sometimes a slash is used, sometimes an underscore, sometimes "win64" inserted, but again, it's generally reasonable hidden behind a .bat file to set the environment and set $PATH and set the console's title (console == xterm, not the one special console). If you have more than one cl.exe or link.exe on your path, not good. cl.exe does more work than the gcc driver, it doesn't delegate out as much. There are no "fat" files like Apple does, well, not mechanized/systematic. Something like sysinternals handle.exe that has an embedded driver has a toplevel x86 file that runs on everything and then on demand extracts the AMD64 or IA64 executable and driver, runs the other version of itself, installs the driver on demand and voila.. ) - Jay From wagner at elegosoft.com Thu Apr 17 14:25:25 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 17 Apr 2008 14:25:25 +0200 Subject: [M3devel] new gcc build time In-Reply-To: References: <20080417084010.k3clt47rk8go4www@mail.elegosoft.com> Message-ID: <20080417142525.crce5s5s1wggk04c@mail.elegosoft.com> Quoting Jay : > I see this too. > I've been experimenting.. > --disable-bootstrap? > I don't know yet. I don't think we have ever done a full gcc bootstrap for cm3cg, have we? Is there any reason to do that now? If not, complete bootstrapping of gcc should be disabled again. Or we should make it an option depending on a variable setting like -DCOMPLETE_GCC_BOOTSTRAP or similar. Any other opinions? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Thu Apr 17 15:00:51 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 17 Apr 2008 13:00:51 +0000 Subject: [M3devel] new gcc build time In-Reply-To: <20080417142525.crce5s5s1wggk04c@mail.elegosoft.com> References: <20080417084010.k3clt47rk8go4www@mail.elegosoft.com> <20080417142525.crce5s5s1wggk04c@mail.elegosoft.com> Message-ID: I don't think so. I don't think so. I don't think so. :) I don't think we bootstrapped. I don't think there's much reason. I don't think it should even be an option. But I don't know. It should be faster. I think a reason to bootstrap would be if the system's C compiler can't compile gcc. That is, if it isn't gcc, or is an old gcc. Or maybe even that is false -- not sure what the requirements to build gcc are. Given that usually it is gcc and recent, seems like little reason. Maybe "SOLsun" would do it, for example. ?????? I'm still having trouble just making an x86 hosted x86 targeted build on AMD64, but I'm close. Something like CC="gcc -m32 -Xassembler --32" configure --target=i686-pc-linux-gnu --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu though I'm sure that's overkill to specify three architectures. I have to read the explanation of which is which. When there are only two, host and target make sense, is "build" the current one that is building the compiler, host is where it will run, target is what it will produce? I guess that's reasonable. So build could always be sniffed automatically and it might as well be native -- this compiler already must exist, or it is stage1 if bootstrapping from other than gcc. ? I guess stage1 is build a build-hosted host-targeted compiler, stage2 is host-hosted, target-targeted, what you actually want, stage3 is the same, and compare? Something like that? I should read up.. this doesn't seem like enough passes when building a cross-compiler, or just you have skip the "compare" when building a cross compiler? Later.. - Jay > Date: Thu, 17 Apr 2008 14:25:25 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] new gcc build time > > Quoting Jay : > > > I see this too. > > I've been experimenting.. > > --disable-bootstrap? > > I don't know yet. > > I don't think we have ever done a full gcc bootstrap for cm3cg, > have we? Is there any reason to do that now? > If not, complete bootstrapping of gcc should be disabled again. > Or we should make it an option depending on a variable setting > like -DCOMPLETE_GCC_BOOTSTRAP or similar. > > Any other opinions? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 jayk123 at hotmail.com Thu Apr 17 15:32:19 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 17 Apr 2008 13:32:19 +0000 Subject: [M3devel] biarch, multilib, etc? Message-ID: > And between host, target, and build, I find the names confusing. Ok I was the victim of an older less clear document. The current docs are clear and agreed with my guess. Host is the "future host", the machine that will run the compiler you are building. Target is the target of the compiler you are building. Build is the *Host* you are building the compiler on right now. The terminology I believe derives from the viewpoint that not many people build compilers. Host the machine are you developing on, running the compiler, editor. Target is the machine you are producing code for. "Build" is much less often seen, so its name isn't so clear. It is the host that builds the compiler. But not the host that, like, builds "the real code". Unless that real code, is, uh, the compiler (and linker). While "Build" should be reliably guessable from uname et. al., I think the docs warned against not specifying it if specifying others. You know, if I'm on AMD64, whether "build" is AMD64 or x86 has theoretically no bearing on the result, so I shouldn't care. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Apr 17 19:00:10 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 17 Apr 2008 13:00:10 -0400 Subject: [M3devel] new gcc build time In-Reply-To: References: <20080417084010.k3clt47rk8go4www@mail.elegosoft.com> <20080417142525.crce5s5s1wggk04c@mail.elegosoft.com> Message-ID: <09ABDD15-A087-4CD7-B2E1-C368A35E92A4@cs.purdue.edu> Some suggested flags for gcc configure to avoid full bootstrap: --enable-languages=m3cg --disable-multilib --enable-stage1-languages=m3cg --disable-bootstrap I haven't tried any of these, but some combination in m3cc/src/ m3makefile should have the intended effect. On Apr 17, 2008, at 9:00 AM, Jay wrote: > I don't think so. I don't think so. I don't think so. :) > I don't think we bootstrapped. I don't think there's much reason. I > don't think it should even be an option. > But I don't know. > It should be faster. > > I think a reason to bootstrap would be if the system's C compiler > can't compile gcc. > That is, if it isn't gcc, or is an old gcc. Or maybe even that is > false -- not sure what the requirements to build gcc are. > Given that usually it is gcc and recent, seems like little reason. > Maybe "SOLsun" would do it, for example. > ?????? > > I'm still having trouble just making an x86 hosted x86 targeted > build on AMD64, but I'm close. > Something like > CC="gcc -m32 -Xassembler --32" configure --target=i686-pc-linux-gnu > --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu > though I'm sure that's overkill to specify three architectures. I > have to read the explanation of which is which. > When there are only two, host and target make sense, is "build" the > current one that is building the compiler, host is where it will > run, target is what it will produce? I guess that's reasonable. So > build could always be sniffed automatically and it might as well be > native -- this compiler already must exist, or it is stage1 if > bootstrapping from other than gcc. ? I guess stage1 is build a build- > hosted host-targeted compiler, stage2 is host-hosted, target- > targeted, what you actually want, stage3 is the same, and compare? > Something like that? I should read up.. this doesn't seem like > enough passes when building a cross-compiler, or just you have skip > the "compare" when building a cross compiler? > > Later.. > - Jay > > > Date: Thu, 17 Apr 2008 14:25:25 +0200 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] new gcc build time > > > > Quoting Jay : > > > > > I see this too. > > > I've been experimenting.. > > > --disable-bootstrap? > > > I don't know yet. > > > > I don't think we have ever done a full gcc bootstrap for cm3cg, > > have we? Is there any reason to do that now? > > If not, complete bootstrapping of gcc should be disabled again. > > Or we should make it an option depending on a variable setting > > like -DCOMPLETE_GCC_BOOTSTRAP or similar. > > > > Any other opinions? > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Apr 17 19:03:41 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 17 Apr 2008 13:03:41 -0400 Subject: [M3devel] biarch, multilib, etc? In-Reply-To: References: Message-ID: <527623C3-BC62-4CF0-B338-068D149378C2@cs.purdue.edu> Check the latest version of m3-sys/cminstall/src/config/LINUXLIBC6. Notice that it now always uses -m32, --32 flags to the various compiler components (cm3cg, SYSTEM_CC, SYSTEM_AS). This forces use of the x86 variants. An AMD64_LINUX port will have an almost identical configuration file that forces use of the x86_64 toolchain. 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 Apr 17, 2008, at 8:03 AM, Jay wrote: > > Can anyone explain how Linux and gcc are managing that AMD64 systems > can run > and presumably build x86 code? > > > I know there is /lib32 and /lib64. > I know there is gcc -m32 and gcc -m64. > I know that gcc itself delegates out to target specific executables, > so one gcc plus flags suffices, > it's those other executables that multiply out. That ld has the -m > flag. That as has --32 and --64. > I don't know how much stuff goes through gcc, vs. needs the get the > as/ld flags correct. > I'm not talking about Modula-3 here, but, like of building gcc and > its dependencies. > I can deal with the smaller Modula-3 system contained in far more > readable Quake code than all the "sh" > and layers upon layers of makefiles and autoconf and sh and m4 etc.. > > > ./configure on various things tend to build just AMD64. > > > It appears in general that for any > apt-get install foo > you can often but not always > apt-get install foo-i386 > > > This is on KUbuntu 8.4 Hardy Heron KDE4 beta AMD64 (mouthful!) > > > It looks like in general: > CC="gcc -m32" .../configure --prefix=/usr --libdir=/usr/lib32 -- > build=i686-pc-linux-gnu > > > is what you want, but that many packages are only native. > in particular gmp and mpfr: > apt-get install mpfr-i386 > => no luck > > > Maybe these are not considered "mainstream"? > > > I'll build them myself, something like: > > cd /usr/src > apt-get source mpfr > mkdir -p obj/mpfr > cd obj/mpfr > CC="gcc -m32" /usr/src/mpfr-2.3.1.dfsg.1/configure --prefix=/usr -- > libdir=/usr/lib32 --build=i686-pc-linux-gnu > make > sudo make install > > > cd /usr/src > apt-get source libgmp3-dev > mkdir -p /usr/src/obj/gmp > cd /usr/src/obj/obj > CC="gcc -m32" /usr/src/gmp-4.2.2+dfsg/configure --prefix=/usr -- > libdir=/usr/lib32 --build=i686-pc-linux-gnu > make > sudo make install > > You know, I just want building the Modula-3 system on AMD64_LINUX to > at first merely build > an x86 hosted, x86 targeted binary. And then start changing things. > > > And between host, target, and build, I find the names confusing. > I understand why there are three -- the current system to build the > compiler, a system to run the > compiler, a system to run the compiler's output, but these names > host, target, build, aren't very > mnemonic with me yet. Is it build=now, host=runs the compier, > target=runs the compiler's output? > I'll dig around. > > I know, I can figure it all out, there's the www to search, but this > biarch/multilib is hard > to find the docs for..and I can't read the masses of m4/sh/gmake.. > > ps: it's easy to get the ld to crash when doing this stuff wrong.. > > (I can explain how Windows does it, fyi. > 1) The system is "doubled up", generally .dlls and .exes, but not > kernel and drivers > c:\windows\system32 is native > c:\windows\syswow64 is 32bit > Yeah it's wierd/backwards, but it is source compatible. > There is runtime magic to redirect from "system32" in 32 bit > processes to syswow64. > Though if folks used the very long standing APIs, this wouldn't have > been needed. Oh well. > There is also c:\program files and c:\program files (x86). I guess > people are better about using the APIs here. > "Introspection" is "broken" but this -- link -dump against c:\windows > \system32 can get "redirected" but devtools aren't the priority and > it does all generally work out, despite the hokiness. > The registry is similarly doubled up and redirected, in some places > at least, since it tends to give paths to .dlls -- a process is > either 32bit or 64bit -- can't load one type .dll in other type > process. > > On the devtools side, well, you know, NT always had ppc/mips/alpha/ > x86, so .libs are generally already in a directory named "i386" or > "x86". > In any case, folks don't hardcode paths as much, because they are > already so variable. > So you set up your environment or such using the %LIB% variable and > it works easily. > > For running devtools, there is a separate set of .exes for each > target. > And sometimes for host. > The matrix is filled out as necessary. > AMD64 runs x86 fast so not always useful to fill out the matrix. > Sometimes a slash is used, sometimes an underscore, sometimes > "win64" inserted, but again, it's generally reasonable hidden behind > a .bat file to set the environment and set $PATH and set the > console's title (console == xterm, not the one special console). > > If you have more than one cl.exe or link.exe on your path, not good. > cl.exe does more work than the gcc driver, it doesn't delegate out > as much. > > There are no "fat" files like Apple does, well, not mechanized/ > systematic. > Something like sysinternals handle.exe that has an embedded driver > has a toplevel x86 file that runs on everything and then on demand > extracts the AMD64 or IA64 executable and driver, runs the other > version of itself, installs the driver on demand and voila.. > ) > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Apr 18 03:13:17 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Apr 2008 01:13:17 +0000 Subject: [M3devel] biarch, multilib, etc? In-Reply-To: <527623C3-BC62-4CF0-B338-068D149378C2@cs.purdue.edu> References: <527623C3-BC62-4CF0-B338-068D149378C2@cs.purdue.edu> Message-ID: What I want to start is an x86 hosted x86 targeted cm3cg to (build and) run on my AMD64 system, just to get where we already are. I have this: jay at jayx2:~/dev2/cm3/m3-sys/m3cc$ ldd LINUXLIBC6.1/cm3cg linux-vdso.so.1 => (0x00007fffe21fe000) libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00007f3fd9c8a000) libc.so.6 => /lib/libc.so.6 (0x00007f3fd9928000) /lib64/ld-linux-x86-64.so.2 (0x00007f3fd9ec9000) which I think got via straightforward methods and which I think is not what I want -- it won't run on other people's x86 system. Once I get that working, x86 hosted AMD64 target would be good, or AMD64 hosted, AMD64 targeted if I must. That is, tools can "just" be x86 hosted and work ok, enabling fewer tools that run one more hosts to target more targets. You know, I just want gcc to pretend to ignore all the AMD64 stuff, at least to start. There are a variety of promising methods but stuff keeps failing somewhere or another. stuff like CC="gcc -m32" etc. e.g.: collect2: ld terminated with signal 11 [Segmentation fault], core dumped /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a(hashtab.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a(xmalloc.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a(xstrdup.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a(xexit.o)' is incompatible with i386 output - Jay ________________________________ CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jayk123 at hotmail.com Subject: Re: [M3devel] biarch, multilib, etc? Date: Thu, 17 Apr 2008 13:03:41 -0400 Check the latest version of m3-sys/cminstall/src/config/LINUXLIBC6. Notice that it now always uses -m32, --32 flags to the various compiler components (cm3cg, SYSTEM_CC, SYSTEM_AS). This forces use of the x86 variants. An AMD64_LINUX port will have an almost identical configuration file that forces use of the x86_64 toolchain. 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 Apr 17, 2008, at 8:03 AM, Jay wrote: Can anyone explain how Linux and gcc are managing that AMD64 systems can run and presumably build x86 code? I know there is /lib32 and /lib64. I know there is gcc -m32 and gcc -m64. I know that gcc itself delegates out to target specific executables, so one gcc plus flags suffices, it's those other executables that multiply out. That ld has the -m flag. That as has --32 and --64. I don't know how much stuff goes through gcc, vs. needs the get the as/ld flags correct. I'm not talking about Modula-3 here, but, like of building gcc and its dependencies. I can deal with the smaller Modula-3 system contained in far more readable Quake code than all the "sh" and layers upon layers of makefiles and autoconf and sh and m4 etc.. ./configure on various things tend to build just AMD64. It appears in general that for any apt-get install foo you can often but not always apt-get install foo-i386 This is on KUbuntu 8.4 Hardy Heron KDE4 beta AMD64 (mouthful!) It looks like in general: CC="gcc -m32" .../configure --prefix=/usr --libdir=/usr/lib32 --build=i686-pc-linux-gnu is what you want, but that many packages are only native. in particular gmp and mpfr: apt-get install mpfr-i386 => no luck Maybe these are not considered "mainstream"? I'll build them myself, something like: cd /usr/src apt-get source mpfr mkdir -p obj/mpfr cd obj/mpfr CC="gcc -m32" /usr/src/mpfr-2.3.1.dfsg.1/configure --prefix=/usr --libdir=/usr/lib32 --build=i686-pc-linux-gnu make sudo make install cd /usr/src apt-get source libgmp3-dev mkdir -p /usr/src/obj/gmp cd /usr/src/obj/obj CC="gcc -m32" /usr/src/gmp-4.2.2+dfsg/configure --prefix=/usr --libdir=/usr/lib32 --build=i686-pc-linux-gnu make sudo make install You know, I just want building the Modula-3 system on AMD64_LINUX to at first merely build an x86 hosted, x86 targeted binary. And then start changing things. And between host, target, and build, I find the names confusing. I understand why there are three -- the current system to build the compiler, a system to run the compiler, a system to run the compiler's output, but these names host, target, build, aren't very mnemonic with me yet. Is it build=now, host=runs the compier, target=runs the compiler's output? I'll dig around. I know, I can figure it all out, there's the www to search, but this biarch/multilib is hard to find the docs for..and I can't read the masses of m4/sh/gmake.. ps: it's easy to get the ld to crash when doing this stuff wrong.. (I can explain how Windows does it, fyi. 1) The system is "doubled up", generally .dlls and .exes, but not kernel and drivers c:\windows\system32 is native c:\windows\syswow64 is 32bit Yeah it's wierd/backwards, but it is source compatible. There is runtime magic to redirect from "system32" in 32 bit processes to syswow64. Though if folks used the very long standing APIs, this wouldn't have been needed. Oh well. There is also c:\program files and c:\program files (x86). I guess people are better about using the APIs here. "Introspection" is "broken" but this -- link -dump against c:\windows\system32 can get "redirected" but devtools aren't the priority and it does all generally work out, despite the hokiness. The registry is similarly doubled up and redirected, in some places at least, since it tends to give paths to .dlls -- a process is either 32bit or 64bit -- can't load one type .dll in other type process. On the devtools side, well, you know, NT always had ppc/mips/alpha/x86, so .libs are generally already in a directory named "i386" or "x86". In any case, folks don't hardcode paths as much, because they are already so variable. So you set up your environment or such using the %LIB% variable and it works easily. For running devtools, there is a separate set of .exes for each target. And sometimes for host. The matrix is filled out as necessary. AMD64 runs x86 fast so not always useful to fill out the matrix. Sometimes a slash is used, sometimes an underscore, sometimes "win64" inserted, but again, it's generally reasonable hidden behind a .bat file to set the environment and set $PATH and set the console's title (console == xterm, not the one special console). If you have more than one cl.exe or link.exe on your path, not good. cl.exe does more work than the gcc driver, it doesn't delegate out as much. There are no "fat" files like Apple does, well, not mechanized/systematic. Something like sysinternals handle.exe that has an embedded driver has a toplevel x86 file that runs on everything and then on demand extracts the AMD64 or IA64 executable and driver, runs the other version of itself, installs the driver on demand and voila.. ) - Jay From hosking at cs.purdue.edu Fri Apr 18 04:02:16 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 17 Apr 2008 22:02:16 -0400 Subject: [M3devel] biarch, multilib, etc? In-Reply-To: References: <527623C3-BC62-4CF0-B338-068D149378C2@cs.purdue.edu> Message-ID: Have you tried the following: cd cm3/m3-sys/m3cc mkdir build cd build ../gcc/configure --enable-languages=m3cg make This works for me on Mac OS X and builds a bi-arch version of m3cg that will accept both -m32 and -m64 flags to target x86_32 and x86_64. Admittedly, it does go through the full bootstrap, which is probably overkill. I haven't had a chance to try AMD64_LINUX yet, but I assume it will behave much the same in building a bi-arch compiler. On Apr 17, 2008, at 9:13 PM, Jay wrote: > > What I want to start is an x86 hosted x86 targeted cm3cg to (build > and) run on my AMD64 system, just to get where we already are. > > I have this: > > jay at jayx2:~/dev2/cm3/m3-sys/m3cc$ ldd LINUXLIBC6.1/cm3cg > linux-vdso.so.1 => (0x00007fffe21fe000) > libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00007f3fd9c8a000) > libc.so.6 => /lib/libc.so.6 (0x00007f3fd9928000) > /lib64/ld-linux-x86-64.so.2 (0x00007f3fd9ec9000) > > > which I think got via straightforward methods and which I think is > not what I want -- it won't run on other people's x86 system. > > Once I get that working, x86 hosted AMD64 target would be good, or > AMD64 hosted, AMD64 targeted if I must. > That is, tools can "just" be x86 hosted and work ok, enabling fewer > tools that run one more hosts to target more targets. > > You know, I just want gcc to pretend to ignore all the AMD64 stuff, > at least to start. > There are a variety of promising methods but stuff keeps failing > somewhere or another. > stuff like CC="gcc -m32" etc. > > e.g.: > collect2: ld terminated with signal 11 [Segmentation fault], core > dumped > /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- > unknown-linux-gnu/libiberty/libiberty.a(hashtab.o)' is incompatible > with i386 output > /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- > unknown-linux-gnu/libiberty/libiberty.a(xmalloc.o)' is incompatible > with i386 output > /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- > unknown-linux-gnu/libiberty/libiberty.a(xstrdup.o)' is incompatible > with i386 output > /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- > unknown-linux-gnu/libiberty/libiberty.a(xexit.o)' is incompatible > with i386 output > > - Jay > > ________________________________ > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jayk123 at hotmail.com > Subject: Re: [M3devel] biarch, multilib, etc? > Date: Thu, 17 Apr 2008 13:03:41 -0400 > > Check the latest version of m3-sys/cminstall/src/config/LINUXLIBC6. > Notice that it now always uses -m32, --32 flags to the various > compiler components (cm3cg, SYSTEM_CC, SYSTEM_AS). This forces use > of the x86 variants. An AMD64_LINUX port will have an almost > identical configuration file that forces use of the x86_64 toolchain. > > 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 Apr 17, 2008, at 8:03 AM, Jay wrote: > > Can anyone explain how Linux and gcc are managing that AMD64 systems > can run > and presumably build x86 code? > > > I know there is /lib32 and /lib64. > I know there is gcc -m32 and gcc -m64. > I know that gcc itself delegates out to target specific executables, > so one gcc plus flags suffices, > it's those other executables that multiply out. That ld has the -m > flag. That as has --32 and --64. > I don't know how much stuff goes through gcc, vs. needs the get the > as/ld flags correct. > I'm not talking about Modula-3 here, but, like of building gcc and > its dependencies. > I can deal with the smaller Modula-3 system contained in far more > readable Quake code than all the "sh" > and layers upon layers of makefiles and autoconf and sh and m4 etc.. > > > ./configure on various things tend to build just AMD64. > > > It appears in general that for any > apt-get install foo > you can often but not always > apt-get install foo-i386 > > > This is on KUbuntu 8.4 Hardy Heron KDE4 beta AMD64 (mouthful!) > > > It looks like in general: > CC="gcc -m32" .../configure --prefix=/usr --libdir=/usr/lib32 -- > build=i686-pc-linux-gnu > > > is what you want, but that many packages are only native. > in particular gmp and mpfr: > apt-get install mpfr-i386 > => no luck > > > Maybe these are not considered "mainstream"? > > > I'll build them myself, something like: > > cd /usr/src > apt-get source mpfr > mkdir -p obj/mpfr > cd obj/mpfr > CC="gcc -m32" /usr/src/mpfr-2.3.1.dfsg.1/configure --prefix=/usr -- > libdir=/usr/lib32 --build=i686-pc-linux-gnu > make > sudo make install > > > cd /usr/src > apt-get source libgmp3-dev > mkdir -p /usr/src/obj/gmp > cd /usr/src/obj/obj > CC="gcc -m32" /usr/src/gmp-4.2.2+dfsg/configure --prefix=/usr -- > libdir=/usr/lib32 --build=i686-pc-linux-gnu > make > sudo make install > > You know, I just want building the Modula-3 system on AMD64_LINUX to > at first merely build > an x86 hosted, x86 targeted binary. And then start changing things. > > > And between host, target, and build, I find the names confusing. > I understand why there are three -- the current system to build the > compiler, a system to run the > compiler, a system to run the compiler's output, but these names > host, target, build, aren't very > mnemonic with me yet. Is it build=now, host=runs the compier, > target=runs the compiler's output? > I'll dig around. > > I know, I can figure it all out, there's the www to search, but this > biarch/multilib is hard > to find the docs for..and I can't read the masses of m4/sh/gmake.. > > ps: it's easy to get the ld to crash when doing this stuff wrong.. > > (I can explain how Windows does it, fyi. > 1) The system is "doubled up", generally .dlls and .exes, but not > kernel and drivers > c:\windows\system32 is native > c:\windows\syswow64 is 32bit > Yeah it's wierd/backwards, but it is source compatible. > There is runtime magic to redirect from "system32" in 32 bit > processes to syswow64. > Though if folks used the very long standing APIs, this wouldn't have > been needed. Oh well. > There is also c:\program files and c:\program files (x86). I guess > people are better about using the APIs here. > "Introspection" is "broken" but this -- link -dump against c:\windows > \system32 can get "redirected" but devtools aren't the priority and > it does all generally work out, despite the hokiness. > The registry is similarly doubled up and redirected, in some places > at least, since it tends to give paths to .dlls -- a process is > either 32bit or 64bit -- can't load one type .dll in other type > process. > > On the devtools side, well, you know, NT always had ppc/mips/alpha/ > x86, so .libs are generally already in a directory named "i386" or > "x86". > In any case, folks don't hardcode paths as much, because they are > already so variable. > So you set up your environment or such using the %LIB% variable and > it works easily. > > For running devtools, there is a separate set of .exes for each > target. > And sometimes for host. > The matrix is filled out as necessary. > AMD64 runs x86 fast so not always useful to fill out the matrix. > Sometimes a slash is used, sometimes an underscore, sometimes > "win64" inserted, but again, it's generally reasonable hidden behind > a .bat file to set the environment and set $PATH and set the > console's title (console == xterm, not the one special console). > > If you have more than one cl.exe or link.exe on your path, not good. > cl.exe does more work than the gcc driver, it doesn't delegate out > as much. > > There are no "fat" files like Apple does, well, not mechanized/ > systematic. > Something like sysinternals handle.exe that has an embedded driver > has a toplevel x86 file that runs on everything and then on demand > extracts the AMD64 or IA64 executable and driver, runs the other > version of itself, installs the driver on demand and voila.. > ) > > - Jay > From jayk123 at hotmail.com Fri Apr 18 06:00:27 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Apr 2008 04:00:27 +0000 Subject: [M3devel] biarch, multilib, etc? In-Reply-To: References: <527623C3-BC62-4CF0-B338-068D149378C2@cs.purdue.edu> Message-ID: Kinda sorta but not quite. I am now trying without --disable-bootstrap and --disable-multilib for non-native builds. I'll see how that goes. I understand the niceness of a multarch toolset. I also would like an option for that toolset to be x86 hosted instead of AMD64 hosted, but I'll take either at this point. It still likes to look for i686-pc-linux-gnu-ar and ld and such, rather than just using the existing biarch tools. Epiphany: There are the following platforms: build -- what is building the compiler host -- what the compiler will run on target -- what the compiler's output will run on However each one is potentially biarch or multiarch. (multiarch -- Mac OS X AMD64 machines can run 32 bit PowerPC, 32 bit x86, and AMD64 -- triarch). I understand in the general simple case, gcc -m32 is all it takes, but I don't trust that to suffice for building gcc, since there is at least one more architecture involved and there are a bunch of suspiciously relevant sounding configurable knobs, not just CC and CFLAGS, but AS_FOR_TARGET, GCC_FOR_TARGET, etc., but there aren't FOO_FOR_BUILD, FOO_FOR_HOST, FOO_FOR_TARGET; I guess plain FOO is FOO_FOR_BUILD. I'll keep poking.. - Jay > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jayk123 at hotmail.com > Subject: Re: [M3devel] biarch, multilib, etc? > Date: Thu, 17 Apr 2008 22:02:16 -0400 > > Have you tried the following: > > cd cm3/m3-sys/m3cc > mkdir build > cd build > ../gcc/configure --enable-languages=m3cg > make > > This works for me on Mac OS X and builds a bi-arch version of m3cg > that will accept both -m32 and -m64 flags to target x86_32 and x86_64. > > Admittedly, it does go through the full bootstrap, which is probably > overkill. > > I haven't had a chance to try AMD64_LINUX yet, but I assume it will > behave much the same in building a bi-arch compiler. > > On Apr 17, 2008, at 9:13 PM, Jay wrote: > > > > > What I want to start is an x86 hosted x86 targeted cm3cg to (build > > and) run on my AMD64 system, just to get where we already are. > > > > I have this: > > > > jay at jayx2:~/dev2/cm3/m3-sys/m3cc$ ldd LINUXLIBC6.1/cm3cg > > linux-vdso.so.1 => (0x00007fffe21fe000) > > libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00007f3fd9c8a000) > > libc.so.6 => /lib/libc.so.6 (0x00007f3fd9928000) > > /lib64/ld-linux-x86-64.so.2 (0x00007f3fd9ec9000) > > > > > > which I think got via straightforward methods and which I think is > > not what I want -- it won't run on other people's x86 system. > > > > Once I get that working, x86 hosted AMD64 target would be good, or > > AMD64 hosted, AMD64 targeted if I must. > > That is, tools can "just" be x86 hosted and work ok, enabling fewer > > tools that run one more hosts to target more targets. > > > > You know, I just want gcc to pretend to ignore all the AMD64 stuff, > > at least to start. > > There are a variety of promising methods but stuff keeps failing > > somewhere or another. > > stuff like CC="gcc -m32" etc. > > > > e.g.: > > collect2: ld terminated with signal 11 [Segmentation fault], core > > dumped > > /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- > > unknown-linux-gnu/libiberty/libiberty.a(hashtab.o)' is incompatible > > with i386 output > > /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- > > unknown-linux-gnu/libiberty/libiberty.a(xmalloc.o)' is incompatible > > with i386 output > > /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- > > unknown-linux-gnu/libiberty/libiberty.a(xstrdup.o)' is incompatible > > with i386 output > > /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- > > unknown-linux-gnu/libiberty/libiberty.a(xexit.o)' is incompatible > > with i386 output > > > > - Jay > > > > ________________________________ > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > To: jayk123 at hotmail.com > > Subject: Re: [M3devel] biarch, multilib, etc? > > Date: Thu, 17 Apr 2008 13:03:41 -0400 > > > > Check the latest version of m3-sys/cminstall/src/config/LINUXLIBC6. > > Notice that it now always uses -m32, --32 flags to the various > > compiler components (cm3cg, SYSTEM_CC, SYSTEM_AS). This forces use > > of the x86 variants. An AMD64_LINUX port will have an almost > > identical configuration file that forces use of the x86_64 toolchain. > > > > 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 Apr 17, 2008, at 8:03 AM, Jay wrote: > > > > Can anyone explain how Linux and gcc are managing that AMD64 systems > > can run > > and presumably build x86 code? > > > > > > I know there is /lib32 and /lib64. > > I know there is gcc -m32 and gcc -m64. > > I know that gcc itself delegates out to target specific executables, > > so one gcc plus flags suffices, > > it's those other executables that multiply out. That ld has the -m > > flag. That as has --32 and --64. > > I don't know how much stuff goes through gcc, vs. needs the get the > > as/ld flags correct. > > I'm not talking about Modula-3 here, but, like of building gcc and > > its dependencies. > > I can deal with the smaller Modula-3 system contained in far more > > readable Quake code than all the "sh" > > and layers upon layers of makefiles and autoconf and sh and m4 etc.. > > > > > > ./configure on various things tend to build just AMD64. > > > > > > It appears in general that for any > > apt-get install foo > > you can often but not always > > apt-get install foo-i386 > > > > > > This is on KUbuntu 8.4 Hardy Heron KDE4 beta AMD64 (mouthful!) > > > > > > It looks like in general: > > CC="gcc -m32" .../configure --prefix=/usr --libdir=/usr/lib32 -- > > build=i686-pc-linux-gnu > > > > > > is what you want, but that many packages are only native. > > in particular gmp and mpfr: > > apt-get install mpfr-i386 > > => no luck > > > > > > Maybe these are not considered "mainstream"? > > > > > > I'll build them myself, something like: > > > > cd /usr/src > > apt-get source mpfr > > mkdir -p obj/mpfr > > cd obj/mpfr > > CC="gcc -m32" /usr/src/mpfr-2.3.1.dfsg.1/configure --prefix=/usr -- > > libdir=/usr/lib32 --build=i686-pc-linux-gnu > > make > > sudo make install > > > > > > cd /usr/src > > apt-get source libgmp3-dev > > mkdir -p /usr/src/obj/gmp > > cd /usr/src/obj/obj > > CC="gcc -m32" /usr/src/gmp-4.2.2+dfsg/configure --prefix=/usr -- > > libdir=/usr/lib32 --build=i686-pc-linux-gnu > > make > > sudo make install > > > > You know, I just want building the Modula-3 system on AMD64_LINUX to > > at first merely build > > an x86 hosted, x86 targeted binary. And then start changing things. > > > > > > And between host, target, and build, I find the names confusing. > > I understand why there are three -- the current system to build the > > compiler, a system to run the > > compiler, a system to run the compiler's output, but these names > > host, target, build, aren't very > > mnemonic with me yet. Is it build=now, host=runs the compier, > > target=runs the compiler's output? > > I'll dig around. > > > > I know, I can figure it all out, there's the www to search, but this > > biarch/multilib is hard > > to find the docs for..and I can't read the masses of m4/sh/gmake.. > > > > ps: it's easy to get the ld to crash when doing this stuff wrong.. > > > > (I can explain how Windows does it, fyi. > > 1) The system is "doubled up", generally .dlls and .exes, but not > > kernel and drivers > > c:\windows\system32 is native > > c:\windows\syswow64 is 32bit > > Yeah it's wierd/backwards, but it is source compatible. > > There is runtime magic to redirect from "system32" in 32 bit > > processes to syswow64. > > Though if folks used the very long standing APIs, this wouldn't have > > been needed. Oh well. > > There is also c:\program files and c:\program files (x86). I guess > > people are better about using the APIs here. > > "Introspection" is "broken" but this -- link -dump against c:\windows > > \system32 can get "redirected" but devtools aren't the priority and > > it does all generally work out, despite the hokiness. > > The registry is similarly doubled up and redirected, in some places > > at least, since it tends to give paths to .dlls -- a process is > > either 32bit or 64bit -- can't load one type .dll in other type > > process. > > > > On the devtools side, well, you know, NT always had ppc/mips/alpha/ > > x86, so .libs are generally already in a directory named "i386" or > > "x86". > > In any case, folks don't hardcode paths as much, because they are > > already so variable. > > So you set up your environment or such using the %LIB% variable and > > it works easily. > > > > For running devtools, there is a separate set of .exes for each > > target. > > And sometimes for host. > > The matrix is filled out as necessary. > > AMD64 runs x86 fast so not always useful to fill out the matrix. > > Sometimes a slash is used, sometimes an underscore, sometimes > > "win64" inserted, but again, it's generally reasonable hidden behind > > a .bat file to set the environment and set $PATH and set the > > console's title (console == xterm, not the one special console). > > > > If you have more than one cl.exe or link.exe on your path, not good. > > cl.exe does more work than the gcc driver, it doesn't delegate out > > as much. > > > > There are no "fat" files like Apple does, well, not mechanized/ > > systematic. > > Something like sysinternals handle.exe that has an embedded driver > > has a toplevel x86 file that runs on everything and then on demand > > extracts the AMD64 or IA64 executable and driver, runs the other > > version of itself, installs the driver on demand and voila.. > > ) > > > > - Jay > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Apr 18 06:44:57 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 18 Apr 2008 00:44:57 -0400 Subject: [M3devel] biarch, multilib, etc? In-Reply-To: References: <527623C3-BC62-4CF0-B338-068D149378C2@cs.purdue.edu> Message-ID: 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 Apr 18, 2008, at 12:00 AM, Jay wrote: > Kinda sorta but not quite. > I am now trying without --disable-bootstrap and --disable-multilib > for non-native builds. I'll see how that goes. > I understand the niceness of a multarch toolset. > > I also would like an option for that toolset to be x86 hosted > instead of AMD64 hosted, but I'll take either at this point. > It still likes to look for i686-pc-linux-gnu-ar and ld and such, > rather than just using the existing biarch tools. Who? When building gcc? My build of cm3cg on OS X appears to be x86 hosted. cm3cg does not need to look for any tools... > Epiphany: > There are the following platforms: > build -- what is building the compiler > host -- what the compiler will run on > target -- what the compiler's output will run on > > However each one is potentially biarch or multiarch. > (multiarch -- Mac OS X AMD64 machines can run 32 bit PowerPC, 32 bit > x86, and AMD64 -- triarch). I build gcc without any special setup other than described above. I host on whatever that build turns out to be. I target using -m32/-m64. > I understand in the general simple case, gcc -m32 is all it takes, > but I don't trust that to suffice for building gcc, since there is > at least one more architecture involved and there are a bunch of > suspiciously relevant sounding configurable knobs, not just CC and > CFLAGS, but AS_FOR_TARGET, GCC_FOR_TARGET, etc., but there aren't > FOO_FOR_BUILD, FOO_FOR_HOST, FOO_FOR_TARGET; I guess plain FOO is > FOO_FOR_BUILD. I don't specify -m32 or -m64 to build gcc itself. It automatically builds a biarch compiler. > I'll keep poking.. > > - Jay > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > To: jayk123 at hotmail.com > > Subject: Re: [M3devel] biarch, multilib, etc? > > Date: Thu, 17 Apr 2008 22:02:16 -0400 > > > > Have you tried the following: > > > > cd cm3/m3-sys/m3cc > > mkdir build > > cd build > > ../gcc/configure --enable-languages=m3cg > > make > > > > This works for me on Mac OS X and builds a bi-arch version of m3cg > > that will accept both -m32 and -m64 flags to target x86_32 and > x86_64. > > > > Admittedly, it does go through the full bootstrap, which is probably > > overkill. > > > > I haven't had a chance to try AMD64_LINUX yet, but I assume it will > > behave much the same in building a bi-arch compiler. > > > > On Apr 17, 2008, at 9:13 PM, Jay wrote: > > > > > > > > What I want to start is an x86 hosted x86 targeted cm3cg to (build > > > and) run on my AMD64 system, just to get where we already are. > > > > > > I have this: > > > > > > jay at jayx2:~/dev2/cm3/m3-sys/m3cc$ ldd LINUXLIBC6.1/cm3cg > > > linux-vdso.so.1 => (0x00007fffe21fe000) > > > libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00007f3fd9c8a000) > > > libc.so.6 => /lib/libc.so.6 (0x00007f3fd9928000) > > > /lib64/ld-linux-x86-64.so.2 (0x00007f3fd9ec9000) > > > > > > > > > which I think got via straightforward methods and which I think is > > > not what I want -- it won't run on other people's x86 system. > > > > > > Once I get that working, x86 hosted AMD64 target would be good, or > > > AMD64 hosted, AMD64 targeted if I must. > > > That is, tools can "just" be x86 hosted and work ok, enabling > fewer > > > tools that run one more hosts to target more targets. > > > > > > You know, I just want gcc to pretend to ignore all the AMD64 > stuff, > > > at least to start. > > > There are a variety of promising methods but stuff keeps failing > > > somewhere or another. > > > stuff like CC="gcc -m32" etc. > > > > > > e.g.: > > > collect2: ld terminated with signal 11 [Segmentation fault], core > > > dumped > > > /usr/bin/ld: i386:x86-64 architecture of input file `../build- > x86_64- > > > unknown-linux-gnu/libiberty/libiberty.a(hashtab.o)' is > incompatible > > > with i386 output > > > /usr/bin/ld: i386:x86-64 architecture of input file `../build- > x86_64- > > > unknown-linux-gnu/libiberty/libiberty.a(xmalloc.o)' is > incompatible > > > with i386 output > > > /usr/bin/ld: i386:x86-64 architecture of input file `../build- > x86_64- > > > unknown-linux-gnu/libiberty/libiberty.a(xstrdup.o)' is > incompatible > > > with i386 output > > > /usr/bin/ld: i386:x86-64 architecture of input file `../build- > x86_64- > > > unknown-linux-gnu/libiberty/libiberty.a(xexit.o)' is incompatible > > > with i386 output > > > > > > - Jay > > > > > > ________________________________ > > > CC: m3devel at elegosoft.com > > > From: hosking at cs.purdue.edu > > > To: jayk123 at hotmail.com > > > Subject: Re: [M3devel] biarch, multilib, etc? > > > Date: Thu, 17 Apr 2008 13:03:41 -0400 > > > > > > Check the latest version of m3-sys/cminstall/src/config/ > LINUXLIBC6. > > > Notice that it now always uses -m32, --32 flags to the various > > > compiler components (cm3cg, SYSTEM_CC, SYSTEM_AS). This forces use > > > of the x86 variants. An AMD64_LINUX port will have an almost > > > identical configuration file that forces use of the x86_64 > toolchain. > > > > > > 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 Apr 17, 2008, at 8:03 AM, Jay wrote: > > > > > > Can anyone explain how Linux and gcc are managing that AMD64 > systems > > > can run > > > and presumably build x86 code? > > > > > > > > > I know there is /lib32 and /lib64. > > > I know there is gcc -m32 and gcc -m64. > > > I know that gcc itself delegates out to target specific > executables, > > > so one gcc plus flags suffices, > > > it's those other executables that multiply out. That ld has the -m > > > flag. That as has --32 and --64. > > > I don't know how much stuff goes through gcc, vs. needs the get > the > > > as/ld flags correct. > > > I'm not talking about Modula-3 here, but, like of building gcc and > > > its dependencies. > > > I can deal with the smaller Modula-3 system contained in far more > > > readable Quake code than all the "sh" > > > and layers upon layers of makefiles and autoconf and sh and m4 > etc.. > > > > > > > > > ./configure on various things tend to build just AMD64. > > > > > > > > > It appears in general that for any > > > apt-get install foo > > > you can often but not always > > > apt-get install foo-i386 > > > > > > > > > This is on KUbuntu 8.4 Hardy Heron KDE4 beta AMD64 (mouthful!) > > > > > > > > > It looks like in general: > > > CC="gcc -m32" .../configure --prefix=/usr --libdir=/usr/lib32 -- > > > build=i686-pc-linux-gnu > > > > > > > > > is what you want, but that many packages are only native. > > > in particular gmp and mpfr: > > > apt-get install mpfr-i386 > > > => no luck > > > > > > > > > Maybe these are not considered "mainstream"? > > > > > > > > > I'll build them myself, something like: > > > > > > cd /usr/src > > > apt-get source mpfr > > > mkdir -p obj/mpfr > > > cd obj/mpfr > > > CC="gcc -m32" /usr/src/mpfr-2.3.1.dfsg.1/configure --prefix=/usr > -- > > > libdir=/usr/lib32 --build=i686-pc-linux-gnu > > > make > > > sudo make install > > > > > > > > > cd /usr/src > > > apt-get source libgmp3-dev > > > mkdir -p /usr/src/obj/gmp > > > cd /usr/src/obj/obj > > > CC="gcc -m32" /usr/src/gmp-4.2.2+dfsg/configure --prefix=/usr -- > > > libdir=/usr/lib32 --build=i686-pc-linux-gnu > > > make > > > sudo make install > > > > > > You know, I just want building the Modula-3 system on > AMD64_LINUX to > > > at first merely build > > > an x86 hosted, x86 targeted binary. And then start changing > things. > > > > > > > > > And between host, target, and build, I find the names confusing. > > > I understand why there are three -- the current system to build > the > > > compiler, a system to run the > > > compiler, a system to run the compiler's output, but these names > > > host, target, build, aren't very > > > mnemonic with me yet. Is it build=now, host=runs the compier, > > > target=runs the compiler's output? > > > I'll dig around. > > > > > > I know, I can figure it all out, there's the www to search, but > this > > > biarch/multilib is hard > > > to find the docs for..and I can't read the masses of m4/sh/gmake.. > > > > > > ps: it's easy to get the ld to crash when doing this stuff wrong.. > > > > > > (I can explain how Windows does it, fyi. > > > 1) The system is "doubled up", generally .dlls and .exes, but not > > > kernel and drivers > > > c:\windows\system32 is native > > > c:\windows\syswow64 is 32bit > > > Yeah it's wierd/backwards, but it is source compatible. > > > There is runtime magic to redirect from "system32" in 32 bit > > > processes to syswow64. > > > Though if folks used the very long standing APIs, this wouldn't > have > > > been needed. Oh well. > > > There is also c:\program files and c:\program files (x86). I guess > > > people are better about using the APIs here. > > > "Introspection" is "broken" but this -- link -dump against c: > \windows > > > \system32 can get "redirected" but devtools aren't the priority > and > > > it does all generally work out, despite the hokiness. > > > The registry is similarly doubled up and redirected, in some > places > > > at least, since it tends to give paths to .dlls -- a process is > > > either 32bit or 64bit -- can't load one type .dll in other type > > > process. > > > > > > On the devtools side, well, you know, NT always had ppc/mips/ > alpha/ > > > x86, so .libs are generally already in a directory named "i386" or > > > "x86". > > > In any case, folks don't hardcode paths as much, because they are > > > already so variable. > > > So you set up your environment or such using the %LIB% variable > and > > > it works easily. > > > > > > For running devtools, there is a separate set of .exes for each > > > target. > > > And sometimes for host. > > > The matrix is filled out as necessary. > > > AMD64 runs x86 fast so not always useful to fill out the matrix. > > > Sometimes a slash is used, sometimes an underscore, sometimes > > > "win64" inserted, but again, it's generally reasonable hidden > behind > > > a .bat file to set the environment and set $PATH and set the > > > console's title (console == xterm, not the one special console). > > > > > > If you have more than one cl.exe or link.exe on your path, not > good. > > > cl.exe does more work than the gcc driver, it doesn't delegate out > > > as much. > > > > > > There are no "fat" files like Apple does, well, not mechanized/ > > > systematic. > > > Something like sysinternals handle.exe that has an embedded driver > > > has a toplevel x86 file that runs on everything and then on demand > > > extracts the AMD64 or IA64 executable and driver, runs the other > > > version of itself, installs the driver on demand and voila.. > > > ) > > > > > > - Jay > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Apr 18 07:11:54 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Apr 2008 05:11:54 +0000 Subject: [M3devel] biarch, multilib, etc? In-Reply-To: References: <527623C3-BC62-4CF0-B338-068D149378C2@cs.purdue.edu> Message-ID: I agree this could work on Mac OS X and I will run it again, but I believe that is how I essentially got: jay at jayx2:~/dev2/cm3/m3-sys/m3cc/LINUXLIBC6.1$ ./cm3cg --help | grep -e " -m[0-9]" -m128bit-long-double [disabled] -m32 [disabled] -m3dnow [disabled] -m64 [enabled] -m80387 [enabled] -m96bit-long-double [enabled] jay at jayx2:~/dev2/cm3/m3-sys/m3cc/LINUXLIBC6.1$ ldd ./cm3cg linux-vdso.so.1 => (0x00007fffc7bff000) libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00007fbfbf6fd000) libc.so.6 => /lib/libc.so.6 (0x00007fbfbf39b000) /lib64/ld-linux-x86-64.so.2 (0x00007fbfbf93c000) which I believe will only run on AMD64 and only produce AMD64 code. (Which is probably why I got internal compiler errors trying to use it.) - Jay ________________________________ CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jayk123 at hotmail.com Subject: Re: [M3devel] biarch, multilib, etc? Date: Fri, 18 Apr 2008 00:44:57 -0400 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 Apr 18, 2008, at 12:00 AM, Jay wrote: Kinda sorta but not quite. I am now trying without --disable-bootstrap and --disable-multilib for non-native builds. I'll see how that goes. I understand the niceness of a multarch toolset. I also would like an option for that toolset to be x86 hosted instead of AMD64 hosted, but I'll take either at this point. It still likes to look for i686-pc-linux-gnu-ar and ld and such, rather than just using the existing biarch tools. Who? When building gcc? My build of cm3cg on OS X appears to be x86 hosted. cm3cg does not need to look for any tools... Epiphany: There are the following platforms: build -- what is building the compiler host -- what the compiler will run on target -- what the compiler's output will run on However each one is potentially biarch or multiarch. (multiarch -- Mac OS X AMD64 machines can run 32 bit PowerPC, 32 bit x86, and AMD64 -- triarch). I build gcc without any special setup other than described above. I host on whatever that build turns out to be. I target using -m32/-m64. I understand in the general simple case, gcc -m32 is all it takes, but I don't trust that to suffice for building gcc, since there is at least one more architecture involved and there are a bunch of suspiciously relevant sounding configurable knobs, not just CC and CFLAGS, but AS_FOR_TARGET, GCC_FOR_TARGET, etc., but there aren't FOO_FOR_BUILD, FOO_FOR_HOST, FOO_FOR_TARGET; I guess plain FOO is FOO_FOR_BUILD. I don't specify -m32 or -m64 to build gcc itself. It automatically builds a biarch compiler. I'll keep poking.. - Jay > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jayk123 at hotmail.com > Subject: Re: [M3devel] biarch, multilib, etc? > Date: Thu, 17 Apr 2008 22:02:16 -0400 > > Have you tried the following: > > cd cm3/m3-sys/m3cc > mkdir build > cd build > ../gcc/configure --enable-languages=m3cg > make > > This works for me on Mac OS X and builds a bi-arch version of m3cg > that will accept both -m32 and -m64 flags to target x86_32 and x86_64. > > Admittedly, it does go through the full bootstrap, which is probably > overkill. > > I haven't had a chance to try AMD64_LINUX yet, but I assume it will > behave much the same in building a bi-arch compiler. > > On Apr 17, 2008, at 9:13 PM, Jay wrote: > >> >> What I want to start is an x86 hosted x86 targeted cm3cg to (build >> and) run on my AMD64 system, just to get where we already are. >> >> I have this: >> >> jay at jayx2:~/dev2/cm3/m3-sys/m3cc$ ldd LINUXLIBC6.1/cm3cg >> linux-vdso.so.1 => (0x00007fffe21fe000) >> libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00007f3fd9c8a000) >> libc.so.6 => /lib/libc.so.6 (0x00007f3fd9928000) >> /lib64/ld-linux-x86-64.so.2 (0x00007f3fd9ec9000) >> >> >> which I think got via straightforward methods and which I think is >> not what I want -- it won't run on other people's x86 system. >> >> Once I get that working, x86 hosted AMD64 target would be good, or >> AMD64 hosted, AMD64 targeted if I must. >> That is, tools can "just" be x86 hosted and work ok, enabling fewer >> tools that run one more hosts to target more targets. >> >> You know, I just want gcc to pretend to ignore all the AMD64 stuff, >> at least to start. >> There are a variety of promising methods but stuff keeps failing >> somewhere or another. >> stuff like CC="gcc -m32" etc. >> >> e.g.: >> collect2: ld terminated with signal 11 [Segmentation fault], core >> dumped >> /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- >> unknown-linux-gnu/libiberty/libiberty.a(hashtab.o)' is incompatible >> with i386 output >> /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- >> unknown-linux-gnu/libiberty/libiberty.a(xmalloc.o)' is incompatible >> with i386 output >> /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- >> unknown-linux-gnu/libiberty/libiberty.a(xstrdup.o)' is incompatible >> with i386 output >> /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- >> unknown-linux-gnu/libiberty/libiberty.a(xexit.o)' is incompatible >> with i386 output >> >> - Jay >> >> ________________________________ >> CC: m3devel at elegosoft.com >> From: hosking at cs.purdue.edu >> To: jayk123 at hotmail.com >> Subject: Re: [M3devel] biarch, multilib, etc? >> Date: Thu, 17 Apr 2008 13:03:41 -0400 >> >> Check the latest version of m3-sys/cminstall/src/config/LINUXLIBC6. >> Notice that it now always uses -m32, --32 flags to the various >> compiler components (cm3cg, SYSTEM_CC, SYSTEM_AS). This forces use >> of the x86 variants. An AMD64_LINUX port will have an almost >> identical configuration file that forces use of the x86_64 toolchain. >> >> 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 Apr 17, 2008, at 8:03 AM, Jay wrote: >> >> Can anyone explain how Linux and gcc are managing that AMD64 systems >> can run >> and presumably build x86 code? >> >> >> I know there is /lib32 and /lib64. >> I know there is gcc -m32 and gcc -m64. >> I know that gcc itself delegates out to target specific executables, >> so one gcc plus flags suffices, >> it's those other executables that multiply out. That ld has the -m >> flag. That as has --32 and --64. >> I don't know how much stuff goes through gcc, vs. needs the get the >> as/ld flags correct. >> I'm not talking about Modula-3 here, but, like of building gcc and >> its dependencies. >> I can deal with the smaller Modula-3 system contained in far more >> readable Quake code than all the "sh" >> and layers upon layers of makefiles and autoconf and sh and m4 etc.. >> >> >> ./configure on various things tend to build just AMD64. >> >> >> It appears in general that for any >> apt-get install foo >> you can often but not always >> apt-get install foo-i386 >> >> >> This is on KUbuntu 8.4 Hardy Heron KDE4 beta AMD64 (mouthful!) >> >> >> It looks like in general: >> CC="gcc -m32" .../configure --prefix=/usr --libdir=/usr/lib32 -- >> build=i686-pc-linux-gnu >> >> >> is what you want, but that many packages are only native. >> in particular gmp and mpfr: >> apt-get install mpfr-i386 >> => no luck >> >> >> Maybe these are not considered "mainstream"? >> >> >> I'll build them myself, something like: >> >> cd /usr/src >> apt-get source mpfr >> mkdir -p obj/mpfr >> cd obj/mpfr >> CC="gcc -m32" /usr/src/mpfr-2.3.1.dfsg.1/configure --prefix=/usr -- >> libdir=/usr/lib32 --build=i686-pc-linux-gnu >> make >> sudo make install >> >> >> cd /usr/src >> apt-get source libgmp3-dev >> mkdir -p /usr/src/obj/gmp >> cd /usr/src/obj/obj >> CC="gcc -m32" /usr/src/gmp-4.2.2+dfsg/configure --prefix=/usr -- >> libdir=/usr/lib32 --build=i686-pc-linux-gnu >> make >> sudo make install >> >> You know, I just want building the Modula-3 system on AMD64_LINUX to >> at first merely build >> an x86 hosted, x86 targeted binary. And then start changing things. >> >> >> And between host, target, and build, I find the names confusing. >> I understand why there are three -- the current system to build the >> compiler, a system to run the >> compiler, a system to run the compiler's output, but these names >> host, target, build, aren't very >> mnemonic with me yet. Is it build=now, host=runs the compier, >> target=runs the compiler's output? >> I'll dig around. >> >> I know, I can figure it all out, there's the www to search, but this >> biarch/multilib is hard >> to find the docs for..and I can't read the masses of m4/sh/gmake.. >> >> ps: it's easy to get the ld to crash when doing this stuff wrong.. >> >> (I can explain how Windows does it, fyi. >> 1) The system is "doubled up", generally .dlls and .exes, but not >> kernel and drivers >> c:\windows\system32 is native >> c:\windows\syswow64 is 32bit >> Yeah it's wierd/backwards, but it is source compatible. >> There is runtime magic to redirect from "system32" in 32 bit >> processes to syswow64. >> Though if folks used the very long standing APIs, this wouldn't have >> been needed. Oh well. >> There is also c:\program files and c:\program files (x86). I guess >> people are better about using the APIs here. >> "Introspection" is "broken" but this -- link -dump against c:\windows >> \system32 can get "redirected" but devtools aren't the priority and >> it does all generally work out, despite the hokiness. >> The registry is similarly doubled up and redirected, in some places >> at least, since it tends to give paths to .dlls -- a process is >> either 32bit or 64bit -- can't load one type .dll in other type >> process. >> >> On the devtools side, well, you know, NT always had ppc/mips/alpha/ >> x86, so .libs are generally already in a directory named "i386" or >> "x86". >> In any case, folks don't hardcode paths as much, because they are >> already so variable. >> So you set up your environment or such using the %LIB% variable and >> it works easily. >> >> For running devtools, there is a separate set of .exes for each >> target. >> And sometimes for host. >> The matrix is filled out as necessary. >> AMD64 runs x86 fast so not always useful to fill out the matrix. >> Sometimes a slash is used, sometimes an underscore, sometimes >> "win64" inserted, but again, it's generally reasonable hidden behind >> a .bat file to set the environment and set $PATH and set the >> console's title (console == xterm, not the one special console). >> >> If you have more than one cl.exe or link.exe on your path, not good. >> cl.exe does more work than the gcc driver, it doesn't delegate out >> as much. >> >> There are no "fat" files like Apple does, well, not mechanized/ >> systematic. >> Something like sysinternals handle.exe that has an embedded driver >> has a toplevel x86 file that runs on everything and then on demand >> extracts the AMD64 or IA64 executable and driver, runs the other >> version of itself, installs the driver on demand and voila.. >> ) >> >> - Jay >> > From jayk123 at hotmail.com Fri Apr 18 08:23:08 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Apr 2008 06:23:08 +0000 Subject: [M3devel] biarch, multilib, etc? In-Reply-To: References: <527623C3-BC62-4CF0-B338-068D149378C2@cs.purdue.edu> Message-ID: I definitely need to try again..reading the docs: http://gcc.gnu.org/install/specific.html#x86-64-x-x x86_64-*-*, amd64-*-* GCC supports the x86-64 architecture implemented by the AMD64 processor (amd64-*-* is an alias for x86_64-*-*) on GNU/Linux, FreeBSD and NetBSD. On GNU/Linux the default is a bi-arch compiler which is able to generate both 64-bit x86-64 and 32-bit x86 code (via the -m32 switch). I was able to build an AMD64 hosted x86 targeted compiler and somehow it seemed to go very very quick, like 15 minutes.I need to verify that result, and try the default again for biarch even if it takes 5 hours. There is also --enable-targets=all or a list, which sounded promising, until I saw the above. - Jay > From: jayk123 at hotmail.com > To: hosking at cs.purdue.edu > Date: Fri, 18 Apr 2008 05:11:54 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] biarch, multilib, etc? > > > I agree this could work on Mac OS X and I will run it again, but I believe that is how I essentially got: > > jay at jayx2:~/dev2/cm3/m3-sys/m3cc/LINUXLIBC6.1$ ./cm3cg --help | grep -e " -m[0-9]" > -m128bit-long-double [disabled] > -m32 [disabled] > -m3dnow [disabled] > -m64 [enabled] > -m80387 [enabled] > -m96bit-long-double [enabled] > > jay at jayx2:~/dev2/cm3/m3-sys/m3cc/LINUXLIBC6.1$ ldd ./cm3cg > linux-vdso.so.1 => (0x00007fffc7bff000) > libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00007fbfbf6fd000) > libc.so.6 => /lib/libc.so.6 (0x00007fbfbf39b000) > /lib64/ld-linux-x86-64.so.2 (0x00007fbfbf93c000) > > which I believe will only run on AMD64 and only produce AMD64 code. > (Which is probably why I got internal compiler errors trying to use it.) > > - Jay > > > ________________________________ > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jayk123 at hotmail.com > Subject: Re: [M3devel] biarch, multilib, etc? > Date: Fri, 18 Apr 2008 00:44:57 -0400 > > > 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 Apr 18, 2008, at 12:00 AM, Jay wrote: > Kinda sorta but not quite. > I am now trying without --disable-bootstrap and --disable-multilib for non-native builds. I'll see how that goes. > I understand the niceness of a multarch toolset. > > I also would like an option for that toolset to be x86 hosted instead of AMD64 hosted, but I'll take either at this point. > It still likes to look for i686-pc-linux-gnu-ar and ld and such, rather than just using the existing biarch tools. > > Who? When building gcc? My build of cm3cg on OS X appears to be x86 hosted. cm3cg does not need to look for any tools... > > Epiphany: > There are the following platforms: > build -- what is building the compiler > host -- what the compiler will run on > target -- what the compiler's output will run on > > However each one is potentially biarch or multiarch. > (multiarch -- Mac OS X AMD64 machines can run 32 bit PowerPC, 32 bit x86, and AMD64 -- triarch). > > I build gcc without any special setup other than described above. > I host on whatever that build turns out to be. > I target using -m32/-m64. > > I understand in the general simple case, gcc -m32 is all it takes, but I don't trust that to suffice for building gcc, since there is at least one more architecture involved and there are a bunch of suspiciously relevant sounding configurable knobs, not just CC and CFLAGS, but AS_FOR_TARGET, GCC_FOR_TARGET, etc., but there aren't FOO_FOR_BUILD, FOO_FOR_HOST, FOO_FOR_TARGET; I guess plain FOO is FOO_FOR_BUILD. > > I don't specify -m32 or -m64 to build gcc itself. It automatically builds a biarch compiler. > > I'll keep poking.. > > - Jay > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > To: jayk123 at hotmail.com > > Subject: Re: [M3devel] biarch, multilib, etc? > > Date: Thu, 17 Apr 2008 22:02:16 -0400 > > > > Have you tried the following: > > > > cd cm3/m3-sys/m3cc > > mkdir build > > cd build > > ../gcc/configure --enable-languages=m3cg > > make > > > > This works for me on Mac OS X and builds a bi-arch version of m3cg > > that will accept both -m32 and -m64 flags to target x86_32 and x86_64. > > > > Admittedly, it does go through the full bootstrap, which is probably > > overkill. > > > > I haven't had a chance to try AMD64_LINUX yet, but I assume it will > > behave much the same in building a bi-arch compiler. > > > > On Apr 17, 2008, at 9:13 PM, Jay wrote: > > > >> > >> What I want to start is an x86 hosted x86 targeted cm3cg to (build > >> and) run on my AMD64 system, just to get where we already are. > >> > >> I have this: > >> > >> jay at jayx2:~/dev2/cm3/m3-sys/m3cc$ ldd LINUXLIBC6.1/cm3cg > >> linux-vdso.so.1 => (0x00007fffe21fe000) > >> libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00007f3fd9c8a000) > >> libc.so.6 => /lib/libc.so.6 (0x00007f3fd9928000) > >> /lib64/ld-linux-x86-64.so.2 (0x00007f3fd9ec9000) > >> > >> > >> which I think got via straightforward methods and which I think is > >> not what I want -- it won't run on other people's x86 system. > >> > >> Once I get that working, x86 hosted AMD64 target would be good, or > >> AMD64 hosted, AMD64 targeted if I must. > >> That is, tools can "just" be x86 hosted and work ok, enabling fewer > >> tools that run one more hosts to target more targets. > >> > >> You know, I just want gcc to pretend to ignore all the AMD64 stuff, > >> at least to start. > >> There are a variety of promising methods but stuff keeps failing > >> somewhere or another. > >> stuff like CC="gcc -m32" etc. > >> > >> e.g.: > >> collect2: ld terminated with signal 11 [Segmentation fault], core > >> dumped > >> /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- > >> unknown-linux-gnu/libiberty/libiberty.a(hashtab.o)' is incompatible > >> with i386 output > >> /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- > >> unknown-linux-gnu/libiberty/libiberty.a(xmalloc.o)' is incompatible > >> with i386 output > >> /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- > >> unknown-linux-gnu/libiberty/libiberty.a(xstrdup.o)' is incompatible > >> with i386 output > >> /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- > >> unknown-linux-gnu/libiberty/libiberty.a(xexit.o)' is incompatible > >> with i386 output > >> > >> - Jay > >> > >> ________________________________ > >> CC: m3devel at elegosoft.com > >> From: hosking at cs.purdue.edu > >> To: jayk123 at hotmail.com > >> Subject: Re: [M3devel] biarch, multilib, etc? > >> Date: Thu, 17 Apr 2008 13:03:41 -0400 > >> > >> Check the latest version of m3-sys/cminstall/src/config/LINUXLIBC6. > >> Notice that it now always uses -m32, --32 flags to the various > >> compiler components (cm3cg, SYSTEM_CC, SYSTEM_AS). This forces use > >> of the x86 variants. An AMD64_LINUX port will have an almost > >> identical configuration file that forces use of the x86_64 toolchain. > >> > >> 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 Apr 17, 2008, at 8:03 AM, Jay wrote: > >> > >> Can anyone explain how Linux and gcc are managing that AMD64 systems > >> can run > >> and presumably build x86 code? > >> > >> > >> I know there is /lib32 and /lib64. > >> I know there is gcc -m32 and gcc -m64. > >> I know that gcc itself delegates out to target specific executables, > >> so one gcc plus flags suffices, > >> it's those other executables that multiply out. That ld has the -m > >> flag. That as has --32 and --64. > >> I don't know how much stuff goes through gcc, vs. needs the get the > >> as/ld flags correct. > >> I'm not talking about Modula-3 here, but, like of building gcc and > >> its dependencies. > >> I can deal with the smaller Modula-3 system contained in far more > >> readable Quake code than all the "sh" > >> and layers upon layers of makefiles and autoconf and sh and m4 etc.. > >> > >> > >> ./configure on various things tend to build just AMD64. > >> > >> > >> It appears in general that for any > >> apt-get install foo > >> you can often but not always > >> apt-get install foo-i386 > >> > >> > >> This is on KUbuntu 8.4 Hardy Heron KDE4 beta AMD64 (mouthful!) > >> > >> > >> It looks like in general: > >> CC="gcc -m32" .../configure --prefix=/usr --libdir=/usr/lib32 -- > >> build=i686-pc-linux-gnu > >> > >> > >> is what you want, but that many packages are only native. > >> in particular gmp and mpfr: > >> apt-get install mpfr-i386 > >> => no luck > >> > >> > >> Maybe these are not considered "mainstream"? > >> > >> > >> I'll build them myself, something like: > >> > >> cd /usr/src > >> apt-get source mpfr > >> mkdir -p obj/mpfr > >> cd obj/mpfr > >> CC="gcc -m32" /usr/src/mpfr-2.3.1.dfsg.1/configure --prefix=/usr -- > >> libdir=/usr/lib32 --build=i686-pc-linux-gnu > >> make > >> sudo make install > >> > >> > >> cd /usr/src > >> apt-get source libgmp3-dev > >> mkdir -p /usr/src/obj/gmp > >> cd /usr/src/obj/obj > >> CC="gcc -m32" /usr/src/gmp-4.2.2+dfsg/configure --prefix=/usr -- > >> libdir=/usr/lib32 --build=i686-pc-linux-gnu > >> make > >> sudo make install > >> > >> You know, I just want building the Modula-3 system on AMD64_LINUX to > >> at first merely build > >> an x86 hosted, x86 targeted binary. And then start changing things. > >> > >> > >> And between host, target, and build, I find the names confusing. > >> I understand why there are three -- the current system to build the > >> compiler, a system to run the > >> compiler, a system to run the compiler's output, but these names > >> host, target, build, aren't very > >> mnemonic with me yet. Is it build=now, host=runs the compier, > >> target=runs the compiler's output? > >> I'll dig around. > >> > >> I know, I can figure it all out, there's the www to search, but this > >> biarch/multilib is hard > >> to find the docs for..and I can't read the masses of m4/sh/gmake.. > >> > >> ps: it's easy to get the ld to crash when doing this stuff wrong.. > >> > >> (I can explain how Windows does it, fyi. > >> 1) The system is "doubled up", generally .dlls and .exes, but not > >> kernel and drivers > >> c:\windows\system32 is native > >> c:\windows\syswow64 is 32bit > >> Yeah it's wierd/backwards, but it is source compatible. > >> There is runtime magic to redirect from "system32" in 32 bit > >> processes to syswow64. > >> Though if folks used the very long standing APIs, this wouldn't have > >> been needed. Oh well. > >> There is also c:\program files and c:\program files (x86). I guess > >> people are better about using the APIs here. > >> "Introspection" is "broken" but this -- link -dump against c:\windows > >> \system32 can get "redirected" but devtools aren't the priority and > >> it does all generally work out, despite the hokiness. > >> The registry is similarly doubled up and redirected, in some places > >> at least, since it tends to give paths to .dlls -- a process is > >> either 32bit or 64bit -- can't load one type .dll in other type > >> process. > >> > >> On the devtools side, well, you know, NT always had ppc/mips/alpha/ > >> x86, so .libs are generally already in a directory named "i386" or > >> "x86". > >> In any case, folks don't hardcode paths as much, because they are > >> already so variable. > >> So you set up your environment or such using the %LIB% variable and > >> it works easily. > >> > >> For running devtools, there is a separate set of .exes for each > >> target. > >> And sometimes for host. > >> The matrix is filled out as necessary. > >> AMD64 runs x86 fast so not always useful to fill out the matrix. > >> Sometimes a slash is used, sometimes an underscore, sometimes > >> "win64" inserted, but again, it's generally reasonable hidden behind > >> a .bat file to set the environment and set $PATH and set the > >> console's title (console == xterm, not the one special console). > >> > >> If you have more than one cl.exe or link.exe on your path, not good. > >> cl.exe does more work than the gcc driver, it doesn't delegate out > >> as much. > >> > >> There are no "fat" files like Apple does, well, not mechanized/ > >> systematic. > >> Something like sysinternals handle.exe that has an embedded driver > >> has a toplevel x86 file that runs on everything and then on demand > >> extracts the AMD64 or IA64 executable and driver, runs the other > >> version of itself, installs the driver on demand and voila.. > >> ) > >> > >> - Jay > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Apr 18 08:52:06 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Apr 2008 06:52:06 +0000 Subject: [M3devel] biarch, multilib, etc? In-Reply-To: References: <527623C3-BC62-4CF0-B338-068D149378C2@cs.purdue.edu> Message-ID: ok, indeed, it looks like if you omit target or targets, the default for an AMD64 host is to be able to target x86 and AMD64. If you do specify --target, then you only get one. I think. --disable-bootstrap may also lead to getting one. I think. Using an x86 probably also only gives you one, but maybe you can get multiple? I'll keep digging. I can reproduce the 17 minute build. So maybe two 17 minute builds to get two uniarch cm3cg's is the way, though it should be viable to get a biarch x86 hosted in 34 minutes. Fooling gcc into building an x86 hosted tool on an AMD64 system without a bootstrap may indeed bit a little tricky. Lots of variables.. more later.. Or maybe I should take the AMD64 targeted compiler and look into the rest of the system here.. - Jay From: jayk123 at hotmail.com To: hosking at cs.purdue.edu Date: Fri, 18 Apr 2008 06:23:08 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] biarch, multilib, etc? I definitely need to try again..reading the docs: http://gcc.gnu.org/install/specific.html#x86-64-x-x x86_64-*-*, amd64-*-* GCC supports the x86-64 architecture implemented by the AMD64 processor (amd64-*-* is an alias for x86_64-*-*) on GNU/Linux, FreeBSD and NetBSD. On GNU/Linux the default is a bi-arch compiler which is able to generate both 64-bit x86-64 and 32-bit x86 code (via the -m32 switch). I was able to build an AMD64 hosted x86 targeted compiler and somehow it seemed to go very very quick, like 15 minutes. I need to verify that result, and try the default again for biarch even if it takes 5 hours. There is also --enable-targets=all or a list, which sounded promising, until I saw the above. - Jay > From: jayk123 at hotmail.com > To: hosking at cs.purdue.edu > Date: Fri, 18 Apr 2008 05:11:54 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] biarch, multilib, etc? > > > I agree this could work on Mac OS X and I will run it again, but I believe that is how I essentially got: > > jay at jayx2:~/dev2/cm3/m3-sys/m3cc/LINUXLIBC6.1$ ./cm3cg --help | grep -e " -m[0-9]" > -m128bit-long-double [disabled] > -m32 [disabled] > -m3dnow [disabled] > -m64 [enabled] > -m80387 [enabled] > -m96bit-long-double [enabled] > > jay at jayx2:~/dev2/cm3/m3-sys/m3cc/LINUXLIBC6.1$ ldd ./cm3cg > linux-vdso.so.1 => (0x00007fffc7bff000) > libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00007fbfbf6fd000) > libc.so.6 => /lib/libc.so.6 (0x00007fbfbf39b000) > /lib64/ld-linux-x86-64.so.2 (0x00007fbfbf93c000) > > which I believe will only run on AMD64 and only produce AMD64 code. > (Which is probably why I got internal compiler errors trying to use it.) > > - Jay > > > ________________________________ > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jayk123 at hotmail.com > Subject: Re: [M3devel] biarch, multilib, etc? > Date: Fri, 18 Apr 2008 00:44:57 -0400 > > > 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 Apr 18, 2008, at 12:00 AM, Jay wrote: > Kinda sorta but not quite. > I am now trying without --disable-bootstrap and --disable-multilib for non-native builds. I'll see how that goes. > I understand the niceness of a multarch toolset. > > I also would like an option for that toolset to be x86 hosted instead of AMD64 hosted, but I'll take either at this point. > It still likes to look for i686-pc-linux-gnu-ar and ld and such, rather than just using the existing biarch tools. > > Who? When building gcc? My build of cm3cg on OS X appears to be x86 hosted. cm3cg does not need to look for any tools... > > Epiphany: > There are the following platforms: > build -- what is building the compiler > host -- what the compiler will run on > target -- what the compiler's output will run on > > However each one is potentially biarch or multiarch. > (multiarch -- Mac OS X AMD64 machines can run 32 bit PowerPC, 32 bit x86, and AMD64 -- triarch). > > I build gcc without any special setup other than described above. > I host on whatever that build turns out to be. > I target using -m32/-m64. > > I understand in the general simple case, gcc -m32 is all it takes, but I don't trust that to suffice for building gcc, since there is at least one more architecture involved and there are a bunch of suspiciously relevant sounding configurable knobs, not just CC and CFLAGS, but AS_FOR_TARGET, GCC_FOR_TARGET, etc., but there aren't FOO_FOR_BUILD, FOO_FOR_HOST, FOO_FOR_TARGET; I guess plain FOO is FOO_FOR_BUILD. > > I don't specify -m32 or -m64 to build gcc itself. It automatically builds a biarch compiler. > > I'll keep poking.. > > - Jay > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > To: jayk123 at hotmail.com > > Subject: Re: [M3devel] biarch, multilib, etc? > > Date: Thu, 17 Apr 2008 22:02:16 -0400 > > > > Have you tried the following: > > > > cd cm3/m3-sys/m3cc > > mkdir build > > cd build > > ../gcc/configure --enable-languages=m3cg > > make > > > > This works for me on Mac OS X and builds a bi-arch version of m3cg > > that will accept both -m32 and -m64 flags to target x86_32 and x86_64. > > > > Admittedly, it does go through the full bootstrap, which is probably > > overkill. > > > > I haven't had a chance to try AMD64_LINUX yet, but I assume it will > > behave much the same in building a bi-arch compiler. > > > > On Apr 17, 2008, at 9:13 PM, Jay wrote: > > > >> > >> What I want to start is an x86 hosted x86 targeted cm3cg to (build > >> and) run on my AMD64 system, just to get where we already are. > >> > >> I have this: > >> > >> jay at jayx2:~/dev2/cm3/m3-sys/m3cc$ ldd LINUXLIBC6.1/cm3cg > >> linux-vdso.so.1 => (0x00007fffe21fe000) > >> libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00007f3fd9c8a000) > >> libc.so.6 => /lib/libc.so.6 (0x00007f3fd9928000) > >> /lib64/ld-linux-x86-64.so.2 (0x00007f3fd9ec9000) > >> > >> > >> which I think got via straightforward methods and which I think is > >> not what I want -- it won't run on other people's x86 system. > >> > >> Once I get that working, x86 hosted AMD64 target would be good, or > >> AMD64 hosted, AMD64 targeted if I must. > >> That is, tools can "just" be x86 hosted and work ok, enabling fewer > >> tools that run one more hosts to target more targets. > >> > >> You know, I just want gcc to pretend to ignore all the AMD64 stuff, > >> at least to start. > >> There are a variety of promising methods but stuff keeps failing > >> somewhere or another. > >> stuff like CC="gcc -m32" etc. > >> > >> e.g.: > >> collect2: ld terminated with signal 11 [Segmentation fault], core > >> dumped > >> /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- > >> unknown-linux-gnu/libiberty/libiberty.a(hashtab.o)' is incompatible > >> with i386 output > >> /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- > >> unknown-linux-gnu/libiberty/libiberty.a(xmalloc.o)' is incompatible > >> with i386 output > >> /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- > >> unknown-linux-gnu/libiberty/libiberty.a(xstrdup.o)' is incompatible > >> with i386 output > >> /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- > >> unknown-linux-gnu/libiberty/libiberty.a(xexit.o)' is incompatible > >> with i386 output > >> > >> - Jay > >> > >> ________________________________ > >> CC: m3devel at elegosoft.com > >> From: hosking at cs.purdue.edu > >> To: jayk123 at hotmail.com > >> Subject: Re: [M3devel] biarch, multilib, etc? > >> Date: Thu, 17 Apr 2008 13:03:41 -0400 > >> > >> Check the latest version of m3-sys/cminstall/src/config/LINUXLIBC6. > >> Notice that it now always uses -m32, --32 flags to the various > >> compiler components (cm3cg, SYSTEM_CC, SYSTEM_AS). This forces use > >> of the x86 variants. An AMD64_LINUX port will have an almost > >> identical configuration file that forces use of the x86_64 toolchain. > >> > >> 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 Apr 17, 2008, at 8:03 AM, Jay wrote: > >> > >> Can anyone explain how Linux and gcc are managing that AMD64 systems > >> can run > >> and presumably build x86 code? > >> > >> > >> I know there is /lib32 and /lib64. > >> I know there is gcc -m32 and gcc -m64. > >> I know that gcc itself delegates out to target specific executables, > >> so one gcc plus flags suffices, > >> it's those other executables that multiply out. That ld has the -m > >> flag. That as has --32 and --64. > >> I don't know how much stuff goes through gcc, vs. needs the get the > >> as/ld flags correct. > >> I'm not talking about Modula-3 here, but, like of building gcc and > >> its dependencies. > >> I can deal with the smaller Modula-3 system contained in far more > >> readable Quake code than all the "sh" > >> and layers upon layers of makefiles and autoconf and sh and m4 etc.. > >> > >> > >> ./configure on various things tend to build just AMD64. > >> > >> > >> It appears in general that for any > >> apt-get install foo > >> you can often but not always > >> apt-get install foo-i386 > >> > >> > >> This is on KUbuntu 8.4 Hardy Heron KDE4 beta AMD64 (mouthful!) > >> > >> > >> It looks like in general: > >> CC="gcc -m32" .../configure --prefix=/usr --libdir=/usr/lib32 -- > >> build=i686-pc-linux-gnu > >> > >> > >> is what you want, but that many packages are only native. > >> in particular gmp and mpfr: > >> apt-get install mpfr-i386 > >> => no luck > >> > >> > >> Maybe these are not considered "mainstream"? > >> > >> > >> I'll build them myself, something like: > >> > >> cd /usr/src > >> apt-get source mpfr > >> mkdir -p obj/mpfr > >> cd obj/mpfr > >> CC="gcc -m32" /usr/src/mpfr-2.3.1.dfsg.1/configure --prefix=/usr -- > >> libdir=/usr/lib32 --build=i686-pc-linux-gnu > >> make > >> sudo make install > >> > >> > >> cd /usr/src > >> apt-get source libgmp3-dev > >> mkdir -p /usr/src/obj/gmp > >> cd /usr/src/obj/obj > >> CC="gcc -m32" /usr/src/gmp-4.2.2+dfsg/configure --prefix=/usr -- > >> libdir=/usr/lib32 --build=i686-pc-linux-gnu > >> make > >> sudo make install > >> > >> You know, I just want building the Modula-3 system on AMD64_LINUX to > >> at first merely build > >> an x86 hosted, x86 targeted binary. And then start changing things. > >> > >> > >> And between host, target, and build, I find the names confusing. > >> I understand why there are three -- the current system to build the > >> compiler, a system to run the > >> compiler, a system to run the compiler's output, but these names > >> host, target, build, aren't very > >> mnemonic with me yet. Is it build=now, host=runs the compier, > >> target=runs the compiler's output? > >> I'll dig around. > >> > >> I know, I can figure it all out, there's the www to search, but this > >> biarch/multilib is hard > >> to find the docs for..and I can't read the masses of m4/sh/gmake.. > >> > >> ps: it's easy to get the ld to crash when doing this stuff wrong.. > >> > >> (I can explain how Windows does it, fyi. > >> 1) The system is "doubled up", generally .dlls and .exes, but not > >> kernel and drivers > >> c:\windows\system32 is native > >> c:\windows\syswow64 is 32bit > >> Yeah it's wierd/backwards, but it is source compatible. > >> There is runtime magic to redirect from "system32" in 32 bit > >> processes to syswow64. > >> Though if folks used the very long standing APIs, this wouldn't have > >> been needed. Oh well. > >> There is also c:\program files and c:\program files (x86). I guess > >> people are better about using the APIs here. > >> "Introspection" is "broken" but this -- link -dump against c:\windows > >> \system32 can get "redirected" but devtools aren't the priority and > >> it does all generally work out, despite the hokiness. > >> The registry is similarly doubled up and redirected, in some places > >> at least, since it tends to give paths to .dlls -- a process is > >> either 32bit or 64bit -- can't load one type .dll in other type > >> process. > >> > >> On the devtools side, well, you know, NT always had ppc/mips/alpha/ > >> x86, so .libs are generally already in a directory named "i386" or > >> "x86". > >> In any case, folks don't hardcode paths as much, because they are > >> already so variable. > >> So you set up your environment or such using the %LIB% variable and > >> it works easily. > >> > >> For running devtools, there is a separate set of .exes for each > >> target. > >> And sometimes for host. > >> The matrix is filled out as necessary. > >> AMD64 runs x86 fast so not always useful to fill out the matrix. > >> Sometimes a slash is used, sometimes an underscore, sometimes > >> "win64" inserted, but again, it's generally reasonable hidden behind > >> a .bat file to set the environment and set $PATH and set the > >> console's title (console == xterm, not the one special console). > >> > >> If you have more than one cl.exe or link.exe on your path, not good. > >> cl.exe does more work than the gcc driver, it doesn't delegate out > >> as much. > >> > >> There are no "fat" files like Apple does, well, not mechanized/ > >> systematic. > >> Something like sysinternals handle.exe that has an embedded driver > >> has a toplevel x86 file that runs on everything and then on demand > >> extracts the AMD64 or IA64 executable and driver, runs the other > >> version of itself, installs the driver on demand and voila.. > >> ) > >> > >> - Jay > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Apr 18 09:15:24 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 18 Apr 2008 09:15:24 +0200 Subject: [M3devel] current tinderbox failures / new release? Message-ID: <20080418091524.nlijnhwta8cwk4co@mail.elegosoft.com> Currently builds of cm3 fail because quake's getwd is not in the last release (5.4.0) and so cannot be used for bootstrapping. Could somebody fix that? We really need to provide a new release soon to be able to safely use all the new functionality. But there are still no working tests on NT386*, and X64 porting seems to be underway. I think we should define a goal or milestone (we can even do that with trac), define the needed features or blocking bugs and work towards it. Or is everybody just as busy as I am and this is no good idea? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Fri Apr 18 10:00:56 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Apr 2008 08:00:56 +0000 Subject: [M3devel] current tinderbox failures / new release? In-Reply-To: <20080418091524.nlijnhwta8cwk4co@mail.elegosoft.com> References: <20080418091524.nlijnhwta8cwk4co@mail.elegosoft.com> Message-ID: getwd was my doing. Yeah I guess I'll workaround, with some sh. Sorry, I didn't realize. I guess fs_cp same problem? Tony "argues" for removing the useof getwd, but so far it seems to fix something that is actually a problem. I think any release is ok...sort of. > NT386 tests NT386 tests aren't runnable, but presumably no major regression, right? There is still the bitmap thing. > AMD64 AMD64 Certainly ok to release without. And you meant AMD64_NT/LINUX. AMD64_DARWIN is already there from Tony. :) Am I going to have to stop checking in, or use a branch? > needed features, blocking bugs Just having new targets even in "prerelease" form are nice features already present: AMD64_DARWIN (aka AMD64_MACOSX :) ) NT386GNU NT386MINGNU (still without gui working due to __stdcall; I should workaround..) plus: Quake extensions set relationship bug fix non-interactive install install-less archives possibly available possible perf benefits from sleep() removal in Process Would be nice to get PPC_LINUX up to pthreads but not high priority. Not sure what the marketing department says, if this is "enough" to have a "major" release that everyone will "buy". :) What's the "official" QA/release process anyway, for the daily snapshots, the snapshots I uploaded, vs. anything else? Would be nice to see if .debs/.rpms could be made and available through "official" channels. - Jay > Date: Fri, 18 Apr 2008 09:15:24 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] current tinderbox failures / new release? > > Currently builds of cm3 fail because quake's getwd is not in the > last release (5.4.0) and so cannot be used for bootstrapping. > Could somebody fix that? > > We really need to provide a new release soon to be able to safely use > all the new functionality. But there are still no working tests on > NT386*, and X64 porting seems to be underway. > > I think we should define a goal or milestone (we can even do that with > trac), define the needed features or blocking bugs and work towards > it. > > Or is everybody just as busy as I am and this is no good idea? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 jayk123 at hotmail.com Fri Apr 18 12:19:07 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Apr 2008 10:19:07 +0000 Subject: [M3devel] bootstrap and Compiler.i3 change? Message-ID: What is the deal with building and the Compiler.i3 change? I had difficulty here, despite using upgrade.py and upgrade.sh that have gotten things correct before (and I understand what they are doing). I ended up doing something that didn't make sense to me and I got past it, but then I had another problem. I ran ugprade until it failed -- it built/shipped compiler and m3core; then libm3 fails. Then I think I ran either do-cm3-front.py, or I rolled back tools and then ran do-cm3-front.py. I understand the change to Compiler.i3. It should be ok. It is in m3core, build/ship that and then build libm3 should work, right? The code that is actually using Compiler.i3 is for fairly unused targets, however it actually sets a good example I intend to follow. Rather than probing for what Pathname.Join returns a\b or a/b, you can check Compiler.Platform or whatnot directly. But if there are more uses of this, outside m3core, this build problem needs to be understood. Probably I'm just missing something? The other problem I ran into was, merely running a particular cm3 with no parameters, crash in module initialization: (gdb) r Starting program: /home/jkrell/cm3/bin/cm3 Failed to read a valid object file image from memory. [Thread debugging using libthread_db enabled] [New Thread -1210100032 (LWP 32329)] *** *** runtime error: *** Attempt to reference an illegal memory location. *** file "../src/runtime/common/RTAllocator.m3", line 203 *** Program received signal SIGABRT, Aborted. [Switching to Thread -1210100032 (LWP 32329)] 0xb7f6d410 in ?? () (gdb) bt #0 0xb7f6d410 in ?? () #1 0xbfa24f6c in ?? () #2 0x00000006 in ?? () #3 0x00007e49 in ?? () #4 0xb7e1e811 in raise () from /lib/tls/i686/cmov/libc.so.6 #5 0xb7e1ffb9 in abort () from /lib/tls/i686/cmov/libc.so.6 #6 0x082c4cfe in RTOS__Crash () at ../src/runtime/POSIX/RTOS.m3:20 #7 0x082ba6c5 in RTProcess__Crash (M3_Bd56fi_msg=0x0) at ../src/runtime/common/RTProcess.m3:65 #8 0x082b7e8e in RTError__EndError (M3_AicXUJ_crash=1 '\001') at ../src/runtime/common/RTError.m3:118 #9 0x082b7b52 in RTError__MsgS (M3_AJWxb1_file=0x8359a68, M3_AcxOUs_line=203, M3_Bd56fi_msgA=0x835cd48, M3_Bd56fi_msgB=0x8358f14, M3_Bd56fi_msgC=0x835cd48) at ../src/runtime/common/RTError.m3:40 #10 0x082b8314 in RTException__Crash (M3_Cblw37_a=0xbfa252d8, M3_AicXUJ_raises=0 '\0', M3_AJWxb1_rte=0x8358d00) at ../src/runtime/common/RTException.m3:79 #11 0x082b801d in RTException__DefaultBackstop (M3_Cblw37_a=0xbfa252d8, M3_AicXUJ_raises=0 '\0') at ../src/runtime/common/RTException.m3:39 #12 0x082b7f59 in RTException__InvokeBackstop (M3_Cblw37_a=0xbfa252d8, M3_AicXUJ_raises=0 '\0') at ../src/runtime/common/RTException.m3:25 #13 0x082c5f90 in RTException__Raise (M3_Cblw37_act=0xbfa252d8) at ../src/runtime/ex_frame/RTExFrame.m3:29 #14 0x082b80b6 in RTException__DefaultBackstop (M3_Cblw37_a=0xbfa252d8, M3_AicXUJ_raises=0 '\0') at ../src/runtime/common/RTException.m3:47 #15 0x082b7f59 in RTException__InvokeBackstop (M3_Cblw37_a=0xbfa252d8, M3_AicXUJ_raises=0 '\0') at ../src/runtime/common/RTException.m3:25 #16 0x082c5f90 in RTException__Raise (M3_Cblw37_act=0xbfa252d8) at ../src/runtime/ex_frame/RTExFrame.m3:29 #17 0x082a380f in RTHooks__ReportFault (M3_AJWxb1_module=0x8359aa0, M3_AcxOUs_info=6500) at ../src/runtime/common/RTHooks.m3:110 #18 0x082a5c81 in _m3_fault (M3_AcxOUs_arg=6500) ---Type to continue, or q to quit--- #19 0x082a497e in RTAllocator__GetTracedObj (M3_Eic7CK_def=0x0) at ../src/runtime/common/RTAllocator.m3:203 #20 0x082a4524 in RTHooks__AllocateTracedObj (M3_AJWxb1_defn=0x0) at ../src/runtime/common/RTAllocator.m3:131 #21 0x08272fae in Pathname__Decompose (M3_Bd56fi_pn=0xb7dbb02c) at ../src/os/POSIX/PathnamePosix.m3:31 #22 0x08104d95 in PathRepr__Root (M3_Bd56fi_pn=0xb7dbb02c) at PathReprCommon.m3:37 #23 0x08104e7f in PathReprCommon_M3 (M3_AcxOUs_mode=1) at PathReprCommon.m3:45 #24 0x082b6e9b in RTLinker__RunMainBody (M3_DjPxE3_m=0x830b380) at ../src/runtime/common/RTLinker.m3:399 #25 0x082b6b67 in RTLinker__RunMainBody (M3_DjPxE3_m=0x830a280) at ../src/runtime/common/RTLinker.m3:379 #26 0x082b6b67 in RTLinker__RunMainBody (M3_DjPxE3_m=0x8309c00) at ../src/runtime/common/RTLinker.m3:379 #27 0x082b6b67 in RTLinker__RunMainBody (M3_DjPxE3_m=0x8308360) at ../src/runtime/common/RTLinker.m3:379 #28 0x082b6b67 in RTLinker__RunMainBody (M3_DjPxE3_m=0x8305c00) at ../src/runtime/common/RTLinker.m3:379 #29 0x082b6b67 in RTLinker__RunMainBody (M3_DjPxE3_m=0x82f91e0) at ../src/runtime/common/RTLinker.m3:379 #30 0x082b6b67 in RTLinker__RunMainBody (M3_DjPxE3_m=0x82f89a0) at ../src/runtime/common/RTLinker.m3:379 #31 0x082b6b67 in RTLinker__RunMainBody (M3_DjPxE3_m=0x82fccc0) at ../src/runtime/common/RTLinker.m3:379 #32 0x082b5911 in RTLinker__AddUnitI (M3_DjPxE3_m=0x82fccc0) at ../src/runtime/common/RTLinker.m3:113 #33 0x082b599f in RTLinker__AddUnit (M3_DjPxE5_b=0x808e9a2) at ../src/runtime/common/RTLinker.m3:122 #34 0x08057038 in main (argc=1, argv=0xbfa25eb4, envp=0xbfa25ebc) at _m3main.mc:4 which I'll look into further if I still see it, later.. - Jay From wagner at elegosoft.com Fri Apr 18 12:40:02 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 18 Apr 2008 12:40:02 +0200 Subject: [M3devel] bootstrap and Compiler.i3 change? In-Reply-To: References: Message-ID: <20080418124002.rc7rondrwkc04go8@mail.elegosoft.com> Quoting Jay : > What is the deal with building and the Compiler.i3 change? > I had difficulty here, despite using upgrade.py and upgrade.sh that > have gotten things correct before (and I understand what they are > doing). > > I ended up doing something that didn't make sense to me and I got > past it, but then I had another problem. > > I ran ugprade until it failed -- it built/shipped compiler and > m3core; then libm3 fails. > Then I think I ran either do-cm3-front.py, or I rolled back tools > and then ran do-cm3-front.py. > > I understand the change to Compiler.i3. It should be ok. It is in > m3core, build/ship that and then build libm3 should work, right? > > The code that is actually using Compiler.i3 is for fairly unused > targets, however it actually sets a good example I intend to follow. > Rather than probing for what Pathname.Join returns a\b or a/b, you > can check Compiler.Platform or whatnot directly. > But if there are more uses of this, outside m3core, this build > problem needs to be understood. > Probably I'm just missing something? Are you sure you didn't just forget to clean everything after building the first cm3? upgrade.sh should do it right though... My own regression tests at home seem to have recoverd from the target extension without further help (except for the new required libraries), too, so I'm quite sure that upgrade.sh does the right things. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Fri Apr 18 13:28:43 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Apr 2008 11:28:43 +0000 Subject: [M3devel] bootstrap and Compiler.i3 change? In-Reply-To: <20080418124002.rc7rondrwkc04go8@mail.elegosoft.com> References: <20080418124002.rc7rondrwkc04go8@mail.elegosoft.com> Message-ID: I really thought I did the right thing. Hm. I will have to start over. And I'm seeing this again on birch, alas: at ../src/runtime/ex_frame/RTExFrame.m3:29 #17 0x082a394b in RTHooks__ReportFault (M3_AJWxb1_module=0x8359be0, M3_AcxOUs_info=6500) at ../src/runtime/common/RTHooks.m3:110 #18 0x082a5dbd in _m3_fault (M3_AcxOUs_arg=6500) ---Type to continue, or q to quit--- #19 0x082a4aba in RTAllocator__GetTracedObj (M3_Eic7CK_def=0x0) at ../src/runtime/common/RTAllocator.m3:203 #20 0x082a4660 in RTHooks__AllocateTracedObj (M3_AJWxb1_defn=0x0) at ../src/runtime/common/RTAllocator.m3:131 #21 0x082730ea in Pathname__Decompose (M3_Bd56fi_pn=0xb7e1302c) at ../src/os/POSIX/PathnamePosix.m3:31 #22 0x08104ed1 in PathRepr__Root (M3_Bd56fi_pn=0xb7e1302c) at ../src/PathReprCommon.m3:37 #23 0x08104fbb in PathReprCommon_M3 (M3_AcxOUs_mode=1) at ../src/PathReprCommon.m3:45 #24 0x082b6fd7 in RTLinker__RunMainBody (M3_DjPxE3_m=0x830b4c0) I have AMD64 host building an x86 hosted x86/AMD64 target compiler now..and if you change "make" to "make all-gcc", it does a lot less...though still wastes time building unneeded stuff. - Jay > Date: Fri, 18 Apr 2008 12:40:02 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] bootstrap and Compiler.i3 change? > > Quoting Jay : > >> What is the deal with building and the Compiler.i3 change? >> I had difficulty here, despite using upgrade.py and upgrade.sh that >> have gotten things correct before (and I understand what they are >> doing). >> >> I ended up doing something that didn't make sense to me and I got >> past it, but then I had another problem. >> >> I ran ugprade until it failed -- it built/shipped compiler and >> m3core; then libm3 fails. >> Then I think I ran either do-cm3-front.py, or I rolled back tools >> and then ran do-cm3-front.py. >> >> I understand the change to Compiler.i3. It should be ok. It is in >> m3core, build/ship that and then build libm3 should work, right? >> >> The code that is actually using Compiler.i3 is for fairly unused >> targets, however it actually sets a good example I intend to follow. >> Rather than probing for what Pathname.Join returns a\b or a/b, you >> can check Compiler.Platform or whatnot directly. >> But if there are more uses of this, outside m3core, this build >> problem needs to be understood. >> Probably I'm just missing something? > > Are you sure you didn't just forget to clean everything after > building the first cm3? upgrade.sh should do it right though... > > My own regression tests at home seem to have recoverd from the > target extension without further help (except for the new required > libraries), too, so I'm quite sure that upgrade.sh does the right > things. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 18 16:15:51 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 18 Apr 2008 10:15:51 -0400 Subject: [M3devel] TOT CM3 compile. In-Reply-To: References: <7F1A2BCF-BBFE-4C62-B74C-255D29A31183@cs.purdue.edu> Message-ID: <5A42A212-D002-4ADA-9BF5-E170B7E7C9C3@cs.purdue.edu> I haven't touched that portion of things (bash syntax). Jay may be the culprit. :-) On Apr 18, 2008, at 1:37 AM, Alex Bochannek wrote: > Tony Hosking writes: > >> Because there is now a new target, you need to first build a >> bootstrap >> compiler that understands the new target specs. To build a bootstrap >> compiler, compile and ship the following packages: > > That's what happens when I can't pay attention to the mailing list > for a > while. Suddenly everything changes :-) Building right now... > > Couple of related things. > > I happened to be looking at script/boot-cm3-core.sh and noticed that > there some Bash syntax crept in. You touched that file more recently > and > since it is a bit late for me, I thought maybe you can check if I've > got > the logic right in the replacement for the -ot operator > > Index: boot-cm3-core.sh > =================================================================== > RCS file: /usr/cvs/cm3/scripts/boot-cm3-core.sh,v > retrieving revision 1.9 > diff -u -r1.9 boot-cm3-core.sh > --- boot-cm3-core.sh 13 Apr 2008 18:22:32 -0000 1.9 > +++ boot-cm3-core.sh 18 Apr 2008 05:37:02 -0000 > @@ -25,7 +25,7 @@ > BUILDARGS="${BUILDARGS:--DM3_BOOTSTRAP=TRUE -keep}" > M3CONFIG_SRC=${ROOT}/m3-sys/cm3/src/config/${CROSS_TARGET} > M3CONFIG=${ROOT}/scripts/${TARGET}-${CROSS_TARGET}.cfg > -if [ ! -f "${M3CONFIG}" -o "${M3CONFIG}" -ot "${M3CONFIG_SRC}" ] ; > then > +if [ ! -f "${M3CONFIG}" -o -z `find "${M3CONFIG}" -prune -newer "$ > {M3CONFIG_SRC}"` ] ; then > sed -e "s;m3back.*=.*;m3back = \"@${ROOT}/m3-sys/m3cc/${TARGET}-$ > {CROSS_TARGET}/cm3cg\";" \ > ${M3CONFIG_SRC} > ${M3CONFIG} > fi > > > I noticed that the new GCC needs GMP and MPFR. I can't install > anything > in /usr on my machine (it's a zone on a Solaris server) and instead > use > Blastwave, which puts things into /opt/csw. The only way to tell the > build process where to pick up the libraries is by modifying line > 319 in > m3-sys/m3cc/src/m3makefile. Is there a better way? > > Thanks, > > Alex. From jayk123 at hotmail.com Fri Apr 18 16:58:02 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Apr 2008 14:58:02 +0000 Subject: [M3devel] TOT CM3 compile. In-Reply-To: <5A42A212-D002-4ADA-9BF5-E170B7E7C9C3@cs.purdue.edu> References: <7F1A2BCF-BBFE-4C62-B74C-255D29A31183@cs.purdue.edu> <5A42A212-D002-4ADA-9BF5-E170B7E7C9C3@cs.purdue.edu> Message-ID: > gmp/mpfr Go ahead and either: cm3 -DM3CC_CONFIG="...lots..." which should circument a bunch of the m3makefile content, or edit the m3makefile to probe for your location. /Presumably/ nobody is going to have anything there, that they don't mind getting used in this way. ? The whole m3-sys/m3cc/m3makefile could be considered "optional". It's a "thin" wrapper over just building gcc. It tries to do the right thing in "all" situations, but I'm sure it often fails or is incomplete, such as for cross builds. This is my newfound wisdom from just this week, still subject to sinking in and being wrong. :) > bash syntax Sorry I really don't know what is sh vs. ksh vs. bash. Does anyone know of an implementation that adheres closely to sh that I can use to stop regressing stuff? Preferably that runs on one or more of: MacOS X (PowerPC for now) x86 or AMD64 or PowerPC Linux x86 or AMD64 NT Kubuntu (that I'm using) has "dash" for /bin/sh. Good? Or some flag I should use for bash? I can check the docs, but, next two points: I do usually use the Python stuff, partly to avoid this problem. Oh, but this about boot*.sh. I never looked at, ran, or changed that, sorry. Really...writing scripts/python and quake/m3makefile is usually relatively fun and productive but not this *.sh :) - Jay > From: hosking at cs.purdue.edu > To: alexb at juniper.net > Date: Fri, 18 Apr 2008 10:15:51 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] TOT CM3 compile. > > I haven't touched that portion of things (bash syntax). Jay may be > the culprit. :-) > > On Apr 18, 2008, at 1:37 AM, Alex Bochannek wrote: > > > Tony Hosking writes: > > > >> Because there is now a new target, you need to first build a > >> bootstrap > >> compiler that understands the new target specs. To build a bootstrap > >> compiler, compile and ship the following packages: > > > > That's what happens when I can't pay attention to the mailing list > > for a > > while. Suddenly everything changes :-) Building right now... > > > > Couple of related things. > > > > I happened to be looking at script/boot-cm3-core.sh and noticed that > > there some Bash syntax crept in. You touched that file more recently > > and > > since it is a bit late for me, I thought maybe you can check if I've > > got > > the logic right in the replacement for the -ot operator > > > > Index: boot-cm3-core.sh > > =================================================================== > > RCS file: /usr/cvs/cm3/scripts/boot-cm3-core.sh,v > > retrieving revision 1.9 > > diff -u -r1.9 boot-cm3-core.sh > > --- boot-cm3-core.sh 13 Apr 2008 18:22:32 -0000 1.9 > > +++ boot-cm3-core.sh 18 Apr 2008 05:37:02 -0000 > > @@ -25,7 +25,7 @@ > > BUILDARGS="${BUILDARGS:--DM3_BOOTSTRAP=TRUE -keep}" > > M3CONFIG_SRC=${ROOT}/m3-sys/cm3/src/config/${CROSS_TARGET} > > M3CONFIG=${ROOT}/scripts/${TARGET}-${CROSS_TARGET}.cfg > > -if [ ! -f "${M3CONFIG}" -o "${M3CONFIG}" -ot "${M3CONFIG_SRC}" ] ; > > then > > +if [ ! -f "${M3CONFIG}" -o -z `find "${M3CONFIG}" -prune -newer "$ > > {M3CONFIG_SRC}"` ] ; then > > sed -e "s;m3back.*=.*;m3back = \"@${ROOT}/m3-sys/m3cc/${TARGET}-$ > > {CROSS_TARGET}/cm3cg\";" \ > > ${M3CONFIG_SRC} > ${M3CONFIG} > > fi > > > > > > I noticed that the new GCC needs GMP and MPFR. I can't install > > anything > > in /usr on my machine (it's a zone on a Solaris server) and instead > > use > > Blastwave, which puts things into /opt/csw. The only way to tell the > > build process where to pick up the libraries is by modifying line > > 319 in > > m3-sys/m3cc/src/m3makefile. Is there a better way? > > > > Thanks, > > > > Alex. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Apr 18 17:01:32 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Apr 2008 15:01:32 +0000 Subject: [M3devel] whitespace rationale? Message-ID: Does anyone know of a reason to put a space between a function and the paren to start its call? Other than "When in Rome"? I've long not put that in, but I see a fair amount of code that does, and a fair amount of code that I didn't write that doesn't (e.g. sysutils). Seems to be all over the place, but a lot of Modula-3 code puts it in (not that I have seen much Modula-3 code in the world...but...) Similarly for array indexing array [index] vs. array[index]. (Not to mention if (expr) and not if ( expr ). Modula-3 (and Python!) doesn't require the parens so it comes up less often.) I always like to know why.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Apr 18 17:13:24 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Apr 2008 15:13:24 +0000 Subject: [M3devel] some multi-arch conclusions Message-ID: When cm3cg --help prints -m32 [enabled] -m64 [disabled] enabled/disabled is the present (default) setting. It doesn't indicate if the compiler supports the flag. To see the meaning of the switch spelled out, use cm3cg --quiet --help. Found by searching the code for [enabled]. Seems backwards, and gcc/cc1 don't work this way. No matter. To see if the switch works, try running it: cm3cg -m32 cm3cg -m64 Some variants will give a clear error that the feature isn't there. Otherwise press control-d (or z) twice to exit. AMD64 hosts by default can target 64 bit and 32 bit. PowerPC and SPARC ought to be the same imho but I don't think they are (yet). I saw some mail thread people asking for this for PowerPC. The docs indicate it is there for PowerPC. The code or the ChangeLog at least shows churn here for SPARC. 32 bit hosts do not default to being able to target multiple architectures. But you can configure them so: x86 hosts can be configured to have a working -m64 switch via --enable-targets=all or --enable-targets=i686-pc-linux-gnu,amd64-pc-linux-gnu Same for 32 bit PowerPC I think, and maybe SPARC. Those same switches should work for AMD64 hosts, but it is the default. I guess you might be able to trim out the x86 target via --enable-targets-amd64-pc-linux-gnu or --disable-targets=i686-pc-linux-gnu, but I didn't try that. There is a term "biarch" or "bi-arch" for "two architectures". When searching the code, be sure to also look for bi-arch. Searching the web I see people refer to --enable-biarch, but I don't believe there is any "biarch" flag anywhere in gcc. Just this --enable-targets=all. And --multilibs stuff. I can't speak to glibc and binutils. Perhaps biarch does mean something in the code. Or maybe it used to. That's what I know. Tony -- your multiarch cm3cg may or may not run on x86. As I understand, there are both 32 bit and 64 bit Intel Macintoshes out there. The first generation were "Core" not "Core 2" and no 64 bit. In the hardware. And presumably in the software. I don't know when they enabled 64 bit Intel. Lately I believe all Intel Macintoshes are 64 bit hardware. I don't know if therefore they can all run 64 bit user mode code, or if this isn't always enabled. I'm not sure if the kernel is 32 bit or 64 bit but we don't care, I'm sure. Historically we have built WAY more of gcc than is generally needed. I can see there being bootstrap scenarios from Sun/IBM/SGI tools, and whatnot, and certainly gcc needs this stuff, they need the bootstrap scenario, etc. However for Modula-3, on systems with a reasonably current gcc already, lots of extra. My machine also took hours to build m3cc recently and now just 7 minutes. Yeah. Later, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Apr 18 17:18:43 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Apr 2008 15:18:43 +0000 Subject: [M3devel] current failures? Message-ID: If anyone else sees this consistently, please let me know. There's only about two of us under suspicion. :) If it's just me, on Birch, I try not to worry too much. I have to take a break but will test out more to see if it occurs, like on PPC_DARWIN, NT386GNU, NT386.. Hopefully the Tinderbox is back under way. % gdb cm3 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 "i486-linux-gnu"...Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (gdb) r Starting program: /home/jkrell/cm3/bin/cm3 Failed to read a valid object file image from memory. [Thread debugging using libthread_db enabled] [New Thread -1210534208 (LWP 5467)] *** *** runtime error: *** Attempt to reference an illegal memory location. *** file "../src/runtime/common/RTAllocator.m3", line 203 *** Program received signal SIGABRT, Aborted. [Switching to Thread -1210534208 (LWP 5467)] 0xb7f03410 in ?? () (gdb) bt #0 0xb7f03410 in ?? () #1 0xbfbfa93c in ?? () #2 0x00000006 in ?? () #3 0x0000155b in ?? () #4 0xb7db4811 in raise () from /lib/tls/i686/cmov/libc.so.6 #5 0xb7db5fb9 in abort () from /lib/tls/i686/cmov/libc.so.6 #6 0x082c4e36 in RTOS__Crash () at ../src/runtime/POSIX/RTOS.m3:20 #7 0x082ba7fd in RTProcess__Crash (M3_Bd56fi_msg=0x0) at ../src/runtime/common/RTProcess.m3:65 #8 0x082b7fc6 in RTError__EndError (M3_AicXUJ_crash=1 '\001') at ../src/runtime/common/RTError.m3:118 #9 0x082b7c8a in RTError__MsgS (M3_AJWxb1_file=0x8359ba8, M3_AcxOUs_line=203, M3_Bd56fi_msgA=0x835ce88, M3_Bd56fi_msgB=0x8359054, M3_Bd56fi_msgC=0x835ce88) at ../src/runtime/common/RTError.m3:40 #10 0x082b844c in RTException__Crash (M3_Cblw37_a=0xbfbfaca8, M3_AicXUJ_raises=0 '\0', M3_AJWxb1_rte=0x8358e40) at ../src/runtime/common/RTException.m3:79 #11 0x082b8155 in RTException__DefaultBackstop (M3_Cblw37_a=0xbfbfaca8, M3_AicXUJ_raises=0 '\0') at ../src/runtime/common/RTException.m3:39 #12 0x082b8091 in RTException__InvokeBackstop (M3_Cblw37_a=0xbfbfaca8, M3_AicXUJ_raises=0 '\0') at ../src/runtime/common/RTException.m3:25 #13 0x082c60c8 in RTException__Raise (M3_Cblw37_act=0xbfbfaca8) at ../src/runtime/ex_frame/RTExFrame.m3:29 #14 0x082b81ee in RTException__DefaultBackstop (M3_Cblw37_a=0xbfbfaca8, M3_AicXUJ_raises=0 '\0') at ../src/runtime/common/RTException.m3:47 #15 0x082b8091 in RTException__InvokeBackstop (M3_Cblw37_a=0xbfbfaca8, M3_AicXUJ_raises=0 '\0') at ../src/runtime/common/RTException.m3:25 #16 0x082c60c8 in RTException__Raise (M3_Cblw37_act=0xbfbfaca8) at ../src/runtime/ex_frame/RTExFrame.m3:29 #17 0x082a3947 in RTHooks__ReportFault (M3_AJWxb1_module=0x8359be0, M3_AcxOUs_info=6500) at ../src/runtime/common/RTHooks.m3:110 #18 0x082a5db9 in _m3_fault (M3_AcxOUs_arg=6500) ---Type to continue, or q to quit--- #19 0x082a4ab6 in RTAllocator__GetTracedObj (M3_Eic7CK_def=0x0) at ../src/runtime/common/RTAllocator.m3:203 #20 0x082a465c in RTHooks__AllocateTracedObj (M3_AJWxb1_defn=0x0) at ../src/runtime/common/RTAllocator.m3:131 #21 0x082730e6 in Pathname__Decompose (M3_Bd56fi_pn=0xb7d5102c) at ../src/os/POSIX/PathnamePosix.m3:31 #22 0x08104ecd in PathRepr__Root (M3_Bd56fi_pn=0xb7d5102c) at ../src/PathReprCommon.m3:37 #23 0x08104fb7 in PathReprCommon_M3 (M3_AcxOUs_mode=1) at ../src/PathReprCommon.m3:45 #24 0x082b6fd3 in RTLinker__RunMainBody (M3_DjPxE3_m=0x830b4c0) at ../src/runtime/common/RTLinker.m3:399 #25 0x082b6c9f in RTLinker__RunMainBody (M3_DjPxE3_m=0x830a3c0) at ../src/runtime/common/RTLinker.m3:379 #26 0x082b6c9f in RTLinker__RunMainBody (M3_DjPxE3_m=0x8309d40) at ../src/runtime/common/RTLinker.m3:379 #27 0x082b6c9f in RTLinker__RunMainBody (M3_DjPxE3_m=0x83084a0) at ../src/runtime/common/RTLinker.m3:379 #28 0x082b6c9f in RTLinker__RunMainBody (M3_DjPxE3_m=0x8305d40) at ../src/runtime/common/RTLinker.m3:379 #29 0x082b6c9f in RTLinker__RunMainBody (M3_DjPxE3_m=0x82f9320) at ../src/runtime/common/RTLinker.m3:379 #30 0x082b6c9f in RTLinker__RunMainBody (M3_DjPxE3_m=0x82f8ae0) at ../src/runtime/common/RTLinker.m3:379 #31 0x082b6c9f in RTLinker__RunMainBody (M3_DjPxE3_m=0x82fce00) at ../src/runtime/common/RTLinker.m3:379 #32 0x082b5a49 in RTLinker__AddUnitI (M3_DjPxE3_m=0x82fce00) at ../src/runtime/common/RTLinker.m3:113 #33 0x082b5ad7 in RTLinker__AddUnit (M3_DjPxE5_b=0x808e9a0) at ../src/runtime/common/RTLinker.m3:122 #34 0x08057038 in main (argc=1, argv=0xbfbfb884, envp=0xbfbfb88c) at _m3main.mc:4 Thanks, - Jay From hosking at cs.purdue.edu Fri Apr 18 18:02:04 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 18 Apr 2008 12:02:04 -0400 Subject: [M3devel] whitespace rationale? In-Reply-To: References: Message-ID: <1E08B814-50D5-4A19-930F-76725E6BF426@cs.purdue.edu> Purely a matter of style. I generally don't put the space for calls: EVAL f(); but I do for declarations: PROCEDURE f () = ... just so that when I want to search for a local declaration I can easily do that with a text search for "f ()". Just my 2 cents. However, when editing code in any one style, I tend to preserve the style. On Apr 18, 2008, at 11:01 AM, Jay wrote: > Does anyone know of a reason to put a space between a function and > the paren to start its call? > Other than "When in Rome"? > > I've long not put that in, but I see a fair amount of code that > does, and a fair amount of code that I didn't write that doesn't > (e.g. sysutils). > Seems to be all over the place, but a lot of Modula-3 code puts it > in (not that I have seen much Modula-3 code in the world...but...) > > Similarly for array indexing array [index] vs. array[index]. > > (Not to mention if (expr) and not if ( expr ). Modula-3 (and > Python!) doesn't require the parens so it comes up less often.) > > I always like to know why.. > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Apr 18 18:03:56 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 18 Apr 2008 12:03:56 -0400 Subject: [M3devel] some multi-arch conclusions In-Reply-To: References: Message-ID: On Apr 18, 2008, at 11:13 AM, Jay wrote: > 32 bit hosts do not default to being able to target multiple > architectures. My x86 Mac OS X box seems to. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Apr 18 18:32:02 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Apr 2008 16:32:02 +0000 Subject: [M3devel] whitespace rationale? In-Reply-To: <1E08B814-50D5-4A19-930F-76725E6BF426@cs.purdue.edu> References: <1E08B814-50D5-4A19-930F-76725E6BF426@cs.purdue.edu> Message-ID: I like the function names at the first column to find definitions, but lots of folks don't do that and it is rare/nonexistant in cm3. :( Granted, your way doesn't require a regexp search. Subtle, but also very useful, one of those things that most folks wouldn't think of -- not just style, but style with function. Of course, it's arbitrary which of the two ways, I think. A parameter per line also eases diff/merge, but uses a lot of vertical space.. I still think it's worth coming up with a style and a rationale for new code. Not necessarily in this forum :). It's not all maintenance hopefully. (And yeah I've heard of syntax tree editors that present the text in the user's preferred style. Been an open research question for probably decades now. Plain text in regular file systems wins.) - Jay ________________________________ > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jayk123 at hotmail.com > Subject: Re: [M3devel] whitespace rationale? > Date: Fri, 18 Apr 2008 12:02:04 -0400 > > Purely a matter of style. I generally don't put the space for calls: > > EVAL f(); > > but I do for declarations: > > PROCEDURE f () = ... > > just so that when I want to search for a local declaration I can easily do that with a text search for "f ()". Just my 2 cents. > > However, when editing code in any one style, I tend to preserve the style. > > On Apr 18, 2008, at 11:01 AM, Jay wrote: > Does anyone know of a reason to put a space between a function and the paren to start its call? > Other than "When in Rome"? > > I've long not put that in, but I see a fair amount of code that does, and a fair amount of code that I didn't write that doesn't (e.g. sysutils). > Seems to be all over the place, but a lot of Modula-3 code puts it in (not that I have seen much Modula-3 code in the world...but...) > > Similarly for array indexing array [index] vs. array[index]. > > (Not to mention if (expr) and not if ( expr ). Modula-3 (and Python!) doesn't require the parens so it comes up less often.) > > I always like to know why.. > > - Jay From mika at async.caltech.edu Fri Apr 18 19:30:41 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 18 Apr 2008 10:30:41 -0700 Subject: [M3devel] whitespace rationale? In-Reply-To: Your message of "Fri, 18 Apr 2008 15:01:32 -0000." Message-ID: <200804181730.m3IHUfF0049162@camembert.async.caltech.edu> Dunno, but "m3pp -callspace" does it that way... someone at SRC liked that style?? Mika Jay writes: >--_04796398-baf6-48c8-ba84-074241a4e579_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Does anyone know of a reason to put a space between a function and the pare= >n to start its call? >Other than "When in Rome"? > >I've long not put that in, but I see a fair amount of code that does, and a= > fair amount of code that I didn't write that doesn't (e.g. sysutils). >Seems to be all over the place, but a lot of Modula-3 code puts it in (not = >that I have seen much Modula-3 code in the world...but...) > >Similarly for array indexing array [index] vs. array[index]. > >(Not to mention if (expr) and not if ( expr ). Modula-3 (and Python!) doesn= >'t require the parens so it comes up less often.) > >I always like to know why.. > > - Jay From mika at async.caltech.edu Fri Apr 18 19:34:17 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 18 Apr 2008 10:34:17 -0700 Subject: [M3devel] whitespace rationale? In-Reply-To: Your message of "Fri, 18 Apr 2008 16:32:02 -0000." Message-ID: <200804181734.m3IHYHrw049300@camembert.async.caltech.edu> Jay writes: > >I like the function names at the first column to find definitions, but lots of folks don't do that and it is rare/nonexistant in cm3. :( That's necessary in C, but in Modula-3 you can just search for "EDURE F"! From hosking at cs.purdue.edu Fri Apr 18 19:39:30 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 18 Apr 2008 13:39:30 -0400 Subject: [M3devel] current failures? In-Reply-To: References: Message-ID: <360F3641-769A-4B44-9BF4-3DAD3A805BD6@cs.purdue.edu> Could be an out-of-sync build state. Did you start from clean? On Apr 18, 2008, at 11:18 AM, Jay wrote: > > If anyone else sees this consistently, please let me know. > There's only about two of us under suspicion. :) > If it's just me, on Birch, I try not to worry too much. > I have to take a break but will test out more to see if it occurs, > like on PPC_DARWIN, NT386GNU, NT386.. > > Hopefully the Tinderbox is back under way. > > % gdb cm3 > 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 "i486-linux-gnu"...Using host > libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". > > (gdb) r > Starting program: /home/jkrell/cm3/bin/cm3 > Failed to read a valid object file image from memory. > [Thread debugging using libthread_db enabled] > [New Thread -1210534208 (LWP 5467)] > > > *** > *** runtime error: > *** Attempt to reference an illegal memory location. > *** file "../src/runtime/common/RTAllocator.m3", line 203 > *** > > > Program received signal SIGABRT, Aborted. > [Switching to Thread -1210534208 (LWP 5467)] > 0xb7f03410 in ?? () > (gdb) bt > #0 0xb7f03410 in ?? () > #1 0xbfbfa93c in ?? () > #2 0x00000006 in ?? () > #3 0x0000155b in ?? () > #4 0xb7db4811 in raise () from /lib/tls/i686/cmov/libc.so.6 > #5 0xb7db5fb9 in abort () from /lib/tls/i686/cmov/libc.so.6 > #6 0x082c4e36 in RTOS__Crash () at ../src/runtime/POSIX/RTOS.m3:20 > #7 0x082ba7fd in RTProcess__Crash (M3_Bd56fi_msg=0x0) at ../src/ > runtime/common/RTProcess.m3:65 > #8 0x082b7fc6 in RTError__EndError (M3_AicXUJ_crash=1 '\001') > at ../src/runtime/common/RTError.m3:118 > #9 0x082b7c8a in RTError__MsgS (M3_AJWxb1_file=0x8359ba8, > M3_AcxOUs_line=203, > M3_Bd56fi_msgA=0x835ce88, M3_Bd56fi_msgB=0x8359054, > M3_Bd56fi_msgC=0x835ce88) > at ../src/runtime/common/RTError.m3:40 > #10 0x082b844c in RTException__Crash (M3_Cblw37_a=0xbfbfaca8, > M3_AicXUJ_raises=0 '\0', > M3_AJWxb1_rte=0x8358e40) at ../src/runtime/common/RTException.m3:79 > #11 0x082b8155 in RTException__DefaultBackstop > (M3_Cblw37_a=0xbfbfaca8, M3_AicXUJ_raises=0 '\0') > at ../src/runtime/common/RTException.m3:39 > #12 0x082b8091 in RTException__InvokeBackstop > (M3_Cblw37_a=0xbfbfaca8, M3_AicXUJ_raises=0 '\0') > at ../src/runtime/common/RTException.m3:25 > #13 0x082c60c8 in RTException__Raise (M3_Cblw37_act=0xbfbfaca8) > at ../src/runtime/ex_frame/RTExFrame.m3:29 > #14 0x082b81ee in RTException__DefaultBackstop > (M3_Cblw37_a=0xbfbfaca8, M3_AicXUJ_raises=0 '\0') > at ../src/runtime/common/RTException.m3:47 > #15 0x082b8091 in RTException__InvokeBackstop > (M3_Cblw37_a=0xbfbfaca8, M3_AicXUJ_raises=0 '\0') > at ../src/runtime/common/RTException.m3:25 > #16 0x082c60c8 in RTException__Raise (M3_Cblw37_act=0xbfbfaca8) > at ../src/runtime/ex_frame/RTExFrame.m3:29 > #17 0x082a3947 in RTHooks__ReportFault (M3_AJWxb1_module=0x8359be0, > M3_AcxOUs_info=6500) > at ../src/runtime/common/RTHooks.m3:110 > #18 0x082a5db9 in _m3_fault (M3_AcxOUs_arg=6500) > ---Type to continue, or q to quit--- > #19 0x082a4ab6 in RTAllocator__GetTracedObj (M3_Eic7CK_def=0x0) > at ../src/runtime/common/RTAllocator.m3:203 > #20 0x082a465c in RTHooks__AllocateTracedObj (M3_AJWxb1_defn=0x0) > at ../src/runtime/common/RTAllocator.m3:131 > #21 0x082730e6 in Pathname__Decompose (M3_Bd56fi_pn=0xb7d5102c) > at ../src/os/POSIX/PathnamePosix.m3:31 > #22 0x08104ecd in PathRepr__Root (M3_Bd56fi_pn=0xb7d5102c) at ../src/ > PathReprCommon.m3:37 > #23 0x08104fb7 in PathReprCommon_M3 (M3_AcxOUs_mode=1) at ../src/ > PathReprCommon.m3:45 > #24 0x082b6fd3 in RTLinker__RunMainBody (M3_DjPxE3_m=0x830b4c0) > at ../src/runtime/common/RTLinker.m3:399 > #25 0x082b6c9f in RTLinker__RunMainBody (M3_DjPxE3_m=0x830a3c0) > at ../src/runtime/common/RTLinker.m3:379 > #26 0x082b6c9f in RTLinker__RunMainBody (M3_DjPxE3_m=0x8309d40) > at ../src/runtime/common/RTLinker.m3:379 > #27 0x082b6c9f in RTLinker__RunMainBody (M3_DjPxE3_m=0x83084a0) > at ../src/runtime/common/RTLinker.m3:379 > #28 0x082b6c9f in RTLinker__RunMainBody (M3_DjPxE3_m=0x8305d40) > at ../src/runtime/common/RTLinker.m3:379 > #29 0x082b6c9f in RTLinker__RunMainBody (M3_DjPxE3_m=0x82f9320) > at ../src/runtime/common/RTLinker.m3:379 > #30 0x082b6c9f in RTLinker__RunMainBody (M3_DjPxE3_m=0x82f8ae0) > at ../src/runtime/common/RTLinker.m3:379 > #31 0x082b6c9f in RTLinker__RunMainBody (M3_DjPxE3_m=0x82fce00) > at ../src/runtime/common/RTLinker.m3:379 > #32 0x082b5a49 in RTLinker__AddUnitI (M3_DjPxE3_m=0x82fce00) > at ../src/runtime/common/RTLinker.m3:113 > #33 0x082b5ad7 in RTLinker__AddUnit (M3_DjPxE5_b=0x808e9a0) > at ../src/runtime/common/RTLinker.m3:122 > #34 0x08057038 in main (argc=1, argv=0xbfbfb884, envp=0xbfbfb88c) at > _m3main.mc:4 > > Thanks, > - Jay From rcoleburn at scires.com Fri Apr 18 21:56:28 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 18 Apr 2008 15:56:28 -0400 Subject: [M3devel] whitespace rationale? In-Reply-To: References: <1E08B814-50D5-4A19-930F-76725E6BF426@cs.purdue.edu> Message-ID: <4808C4AE.1E75.00D7.1@scires.com> I have a Modula-3 style guide that I developed for my company a number of years ago. If anyone is interested, I don't mind contributing it to the repository. Regards, Randy >>> Jay 4/18/2008 12:32 PM >>> I like the function names at the first column to find definitions, but lots of folks don't do that and it is rare/nonexistant in cm3. :( Granted, your way doesn't require a regexp search. Subtle, but also very useful, one of those things that most folks wouldn't think of -- not just style, but style with function. Of course, it's arbitrary which of the two ways, I think. A parameter per line also eases diff/merge, but uses a lot of vertical space.. I still think it's worth coming up with a style and a rationale for new code. Not necessarily in this forum :). It's not all maintenance hopefully. (And yeah I've heard of syntax tree editors that present the text in the user's preferred style. Been an open research question for probably decades now. Plain text in regular file systems wins.) - Jay ________________________________ > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jayk123 at hotmail.com > Subject: Re: [M3devel] whitespace rationale? > Date: Fri, 18 Apr 2008 12:02:04 -0400 > > Purely a matter of style. I generally don't put the space for calls: > > EVAL f(); > > but I do for declarations: > > PROCEDURE f () = ... > > just so that when I want to search for a local declaration I can easily do that with a text search for "f ()". Just my 2 cents. > > However, when editing code in any one style, I tend to preserve the style -------------- next part -------------- An HTML attachment was scrubbed... URL: From HOSKING at cs.purdue.edu Fri Apr 18 23:23:24 2008 From: HOSKING at cs.purdue.edu (Tony Hosking) Date: Fri, 18 Apr 2008 17:23:24 -0400 Subject: [M3devel] gmp and mpfr Message-ID: I have added the necessary gmp and mpfr distributions to the m3cc/gcc package. It turns out that gcc will try to build from local source if it is available in the gcc hierarchy. Now, the only question is how to make sure that installs will put things in the right place. One option is to configure gcc to install into INSTALL_ROOT from the m3cc m3makefile. But that would mean a full install of gcc and libraries. Any other thoughts? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Apr 19 01:31:27 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Apr 2008 23:31:27 +0000 Subject: [M3devel] gmp and mpfr In-Reply-To: References: Message-ID: Thanks. > other thoughts? Static link? I should measure the bloat. I accidentally statically linked to libc.a and the bloat was small, I think x86 static was smaller than AMD64 dynamic. > But that would mean a full install of gcc and libraries. Really? Why not just gmp and mpfr and then point configure at them? Besides, if necessary, import them but not under gcc? - Jay From: HOSKING at cs.purdue.edu To: m3devel at elegosoft.com Date: Fri, 18 Apr 2008 17:23:24 -0400 Subject: [M3devel] gmp and mpfr I have added the necessary gmp and mpfr distributions to the m3cc/gcc package. It turns out that gcc will try to build from local source if it is available in the gcc hierarchy. Now, the only question is how to make sure that installs will put things in the right place. One option is to configure gcc to install into INSTALL_ROOT from the m3cc m3makefile. But that would mean a full install of gcc and libraries. Any other thoughts? -------------- next part -------------- An HTML attachment was scrubbed... URL: From neels at elego.de Sat Apr 19 01:43:45 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Sat, 19 Apr 2008 01:43:45 +0200 Subject: [M3devel] Umman.off_t Message-ID: <48093231.8010800@elego.de> Hi, I am having problems deploying the suplib on FreeBSD (FreeBSD new.elego.de 6.2-RELEASE-p3), using the latest cm3 snapshot (cm3-src-all-d5.7.0-2008-04-16-14-07-05.tgz). A type mismatch error is encountered at the last parameter of the call addr := Umman.mmap(NIL, StatBuf.GetStatSize(statbuf), Umman.PROT_READ, Umman.MAP_SHARED, fd, 0); , the zero, that is. The parameter is called "off" and of type off_t. cm3/m3-libs/m3core/src/unix/freebsd-4/Umman.i3 declares the following about off_t: FROM Utypes IMPORT caddr_t, size_t, off_t; <*EXTERNAL*> PROCEDURE mmap (addr: caddr_t; len: size_t; prot,flags,fd: int; off: off_t) : caddr_t; and Utypes.i3 adds: FROM Ctypes IMPORT long, unsigned_long, int, unsigned_int, short, unsigned_short, char, unsigned_char, long_long; TYPE int64_t = long_long; off_t = int64_t; It turns out that using 0L instead of just 0 solves the compilation error on FreeBSD. Yes, but on linux-libc6, Utypes.i3 says something different, and the 0L in turn causes a type mismatch there. So this is a dilemma situation where the porting between linux and FreeBSD involves source code editing - certainly not good. linux-libc6/Utypes.i3: FROM Ctypes IMPORT long, ... off_t = long; Any help? Thanks! -- Neels Hofmeyr -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Sat Apr 19 01:58:41 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Apr 2008 23:58:41 +0000 Subject: [M3devel] Umman.off_t In-Reply-To: <48093231.8010800@elego.de> References: <48093231.8010800@elego.de> Message-ID: Imho constant integer expressions should be promoted silently. But that's just me. Try one of these: ORD (0, off_t) VAL (0, off_t) ORD (off_t, 0) VAL (off_t, 0) - Jay ---------------------------------------- > Date: Sat, 19 Apr 2008 01:43:45 +0200 > From: neels at elego.de > To: m3devel at elego.de > Subject: [M3devel] Umman.off_t > > Hi, > > I am having problems deploying the suplib on FreeBSD (FreeBSD > new.elego.de 6.2-RELEASE-p3), using the latest cm3 snapshot > (cm3-src-all-d5.7.0-2008-04-16-14-07-05.tgz). > > A type mismatch error is encountered at the last parameter of the call > > addr := Umman.mmap(NIL, StatBuf.GetStatSize(statbuf), > Umman.PROT_READ, > Umman.MAP_SHARED, fd, 0); > > , the zero, that is. The parameter is called "off" and of type off_t. > > cm3/m3-libs/m3core/src/unix/freebsd-4/Umman.i3 > > declares the following about off_t: > > > FROM Utypes IMPORT caddr_t, size_t, off_t; > > > PROCEDURE mmap (addr: caddr_t; len: size_t; prot,flags,fd: int; off: off_t) > : caddr_t; > > > and Utypes.i3 adds: > > > FROM Ctypes IMPORT > long, unsigned_long, int, unsigned_int, short, unsigned_short, > char, unsigned_char, long_long; > > TYPE > int64_t = long_long; > > off_t = int64_t; > > > It turns out that using 0L instead of just 0 solves the compilation > error on FreeBSD. > > Yes, but on linux-libc6, Utypes.i3 says something different, and the 0L > in turn causes a type mismatch there. So this is a dilemma situation > where the porting between linux and FreeBSD involves source code editing > - certainly not good. > > linux-libc6/Utypes.i3: > > FROM Ctypes IMPORT > long, ... > off_t = long; > > > Any help? > > Thanks! > > -- > Neels Hofmeyr -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 19 12:43:06 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 19 Apr 2008 12:43:06 +0200 Subject: [M3devel] gmp and mpfr In-Reply-To: References: Message-ID: <20080419124306.oxag3l6ego0owgw0@mail.elegosoft.com> Quoting Jay : > Thanks. > > > other thoughts? > > Static link? > > I should measure the bloat. > I accidentally statically linked to libc.a and the bloat was small, > I think x86 static was smaller than AMD64 dynamic. We must not link _any_ executable completely statically, we've been through that. Modern Unix systems all require dynamic linking, at least for all the standard C libraries. > > But that would mean a full install of gcc and libraries. > > Really? > Why not just gmp and mpfr and then point configure at them? > Besides, if necessary, import them but not under gcc? > > - Jay > > > From: HOSKING at cs.purdue.edu > To: m3devel at elegosoft.com > Date: Fri, 18 Apr 2008 17:23:24 -0400 > Subject: [M3devel] gmp and mpfr > > I have added the necessary gmp and mpfr distributions to the > m3cc/gcc package. It turns out that gcc will try to build from > local source if it is available in the gcc hierarchy. Now, the only > question is how to make sure that installs will put things in the > right place. One option is to configure gcc to install into > INSTALL_ROOT from the m3cc m3makefile. But that would mean a full > install of gcc and libraries. Any other thoughts? If we really need to have these libraries in the distribution, we should either link them in statically or put the shared objects into INSTALL_ROOT/lib. We could either create different packages (that would require adding these to several scripts) or add some special quake code to build them all as part of m3cc: build libgmp ship libgmp to INSTALL_ROOT/lib build mpfr ship mpfr to INSTALL_ROOT/lib configure gcc with --with-mpfr=INSTALL_ROOT/lib/libmpfr.so \ --with-gmp=INSTALL_ROOT/lib/libgmp.so (I don't think the argument are completely correct, but you get the idea.) build gcc ship gcc The problem with this setup is that it wouldn't work for local builds (without shipping), and we'd have problems when the libraries need upgrade and we overwrite them (bootstrap will break). Or ensure proper versioning here (which is nowhere done up=to-now in cm3). Or (in case of build without ship) just specify the locations in the workspace? Then we'd need to re-link cm3cg in case of later build and ship. What do you think? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 19 13:00:13 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 19 Apr 2008 13:00:13 +0200 Subject: [M3devel] gmp and mpfr In-Reply-To: References: Message-ID: <20080419130013.mo2bzawq9kwo0s0g@mail.elegosoft.com> Quoting Tony Hosking : > I have added the necessary gmp and mpfr distributions to the m3cc/gcc > package. It turns out that gcc will try to build from local source if > it is available in the gcc hierarchy. Now, the only question is how > to make sure that installs will put things in the right place. One > option is to configure gcc to install into INSTALL_ROOT from the m3cc > m3makefile. But that would mean a full install of gcc and libraries. > Any other thoughts? After wondering where the libraries might be, I've now found them at /usr/cvs/cm3/m3cc/gcc/{mpfr,gmp}. I think you wanted to import them to usr/cvs/cm3/m3-sys/m3cc/gcc/{mpfr,gmp}, didn't you? Any objections to move them inside the repository (will break existing workspaces and repo copies...) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Sat Apr 19 14:27:38 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Apr 2008 12:27:38 +0000 Subject: [M3devel] gmp and mpfr In-Reply-To: <20080419124306.oxag3l6ego0owgw0@mail.elegosoft.com> References: <20080419124306.oxag3l6ego0owgw0@mail.elegosoft.com> Message-ID: Static linking libc is a different matter. It should work on Linux and NT but I realize it isn't universally supported. I did it by accident. The kernel does have a compatiblity burden, at least where the interfaces have been published. (On NT, the layering is different. You can link statically to libcmt.lib, which to a very large extent is what people think of libc, but it doesn't call the kernel directly, it goes through kernel32.dll, which goes through ntdll.dll, and syscall numbers are not stable.) Anyway, for libgmp and libmpfr, I still think static linking to these two is definitely ok, or better. Whether we import the source is a separate variable -- can still build a static .a file and link to it and drop the runtime dependency. That, or we get to deal with LD_LIBRARY_PATH and/or -rpath. It sure is nice how on Windows you can at least colocate .exes and .dlls in the same directory and the .dlls get found. This is a different matter vs. if current directory is in the search path for .exes. - Jay > Date: Sat, 19 Apr 2008 12:43:06 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] gmp and mpfr > > Quoting Jay : > > > Thanks. > > > > > other thoughts? > > > > Static link? > > > > I should measure the bloat. > > I accidentally statically linked to libc.a and the bloat was small, > > I think x86 static was smaller than AMD64 dynamic. > > We must not link _any_ executable completely statically, we've been > through that. Modern Unix systems all require dynamic linking, at > least for all the standard C libraries. > > > > But that would mean a full install of gcc and libraries. > > > > Really? > > Why not just gmp and mpfr and then point configure at them? > > Besides, if necessary, import them but not under gcc? > > > > - Jay > > > > > > From: HOSKING at cs.purdue.edu > > To: m3devel at elegosoft.com > > Date: Fri, 18 Apr 2008 17:23:24 -0400 > > Subject: [M3devel] gmp and mpfr > > > > I have added the necessary gmp and mpfr distributions to the > > m3cc/gcc package. It turns out that gcc will try to build from > > local source if it is available in the gcc hierarchy. Now, the only > > question is how to make sure that installs will put things in the > > right place. One option is to configure gcc to install into > > INSTALL_ROOT from the m3cc m3makefile. But that would mean a full > > install of gcc and libraries. Any other thoughts? > > If we really need to have these libraries in the distribution, > we should either link them in statically or put the shared objects > into INSTALL_ROOT/lib. We could either create different packages > (that would require adding these to several scripts) or add some > special quake code to build them all as part of m3cc: > > build libgmp > ship libgmp to INSTALL_ROOT/lib > build mpfr > ship mpfr to INSTALL_ROOT/lib > configure gcc with --with-mpfr=INSTALL_ROOT/lib/libmpfr.so \ > --with-gmp=INSTALL_ROOT/lib/libgmp.so > (I don't think the argument are completely correct, but you get the idea.) > build gcc > ship gcc > > The problem with this setup is that it wouldn't work for local builds > (without shipping), and we'd have problems when the libraries need > upgrade and we overwrite them (bootstrap will break). Or ensure > proper versioning here (which is nowhere done up=to-now in cm3). > > Or (in case of build without ship) just specify the locations in the > workspace? Then we'd need to re-link cm3cg in case of later build and > ship. > > What do you think? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 jayk123 at hotmail.com Sat Apr 19 14:41:52 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Apr 2008 12:41:52 +0000 Subject: [M3devel] gmp and mpfr In-Reply-To: <20080419124306.oxag3l6ego0owgw0@mail.elegosoft.com> References: <20080419124306.oxag3l6ego0owgw0@mail.elegosoft.com> Message-ID: Truncated again.. Static linking libc is a different matter. It should work on Linux and NT but I realize it isn't universally supported. I did it by accident. The kernel does have a compatiblity burden, at least where the interfaces have been published. (On NT, the layering is different. You can link statically to libcmt.lib, which to a very large extent is what people think of libc, but it doesn't call the kernel directly, it goes through kernel32.dll, which goes through ntdll.dll, and syscall numbers are not stable.) Anyway, for libgmp and libmpfr, I still think static linking to these two is definitely ok, or better. Whether we import the source is a separate variable -- can still build a static .a file and link to it and drop the runtime dependency. That, or we get to deal with LD_LIBRARY_PATH and/or -rpath. It sure is nice how on Windows you can at least colocate .exes and .dlls in the same directory and the .dlls get found. This is a different matter vs. if current directory is in the search path for .exes. - Jay > Date: Sat, 19 Apr 2008 12:43:06 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] gmp and mpfr > > Quoting Jay : > > > Thanks. > > > > > other thoughts? > > > > Static link? > > > > I should measure the bloat. > > I accidentally statically linked to libc.a and the bloat was small, > > I think x86 static was smaller than AMD64 dynamic. > > We must not link _any_ executable completely statically, we've been > through that. Modern Unix systems all require dynamic linking, at > least for all the standard C libraries. > > > > But that would mean a full install of gcc and libraries. > > > > Really? > > Why not just gmp and mpfr and then point configure at them? > > Besides, if necessary, import them but not under gcc? > > > > - Jay > > > > > > From: HOSKING at cs.purdue.edu > > To: m3devel at elegosoft.com > > Date: Fri, 18 Apr 2008 17:23:24 -0400 > > Subject: [M3devel] gmp and mpfr > > > > I have added the necessary gmp and mpfr distributions to the > > m3cc/gcc package. It turns out that gcc will try to build from > > local source if it is available in the gcc hierarchy. Now, the only > > question is how to make sure that installs will put things in the > > right place. One option is to configure gcc to install into > > INSTALL_ROOT from the m3cc m3makefile. But that would mean a full > > install of gcc and libraries. Any other thoughts? > > If we really need to have these libraries in the distribution, > we should either link them in statically or put the shared objects > into INSTALL_ROOT/lib. We could either create different packages > (that would require adding these to several scripts) or add some > special quake code to build them all as part of m3cc: > > build libgmp > ship libgmp to INSTALL_ROOT/lib > build mpfr > ship mpfr to INSTALL_ROOT/lib > configure gcc with --with-mpfr=INSTALL_ROOT/lib/libmpfr.so \ > --with-gmp=INSTALL_ROOT/lib/libgmp.so > (I don't think the argument are completely correct, but you get the idea.) > build gcc > ship gcc > > The problem with this setup is that it wouldn't work for local builds > (without shipping), and we'd have problems when the libraries need > upgrade and we overwrite them (bootstrap will break). Or ensure > proper versioning here (which is nowhere done up=to-now in cm3). > > Or (in case of build without ship) just specify the locations in the > workspace? Then we'd need to re-link cm3cg in case of later build and > ship. > > What do you think? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 jayk123 at hotmail.com Sat Apr 19 14:55:18 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Apr 2008 12:55:18 +0000 Subject: [M3devel] FW: gmp and mpfr In-Reply-To: <20080419124306.oxag3l6ego0owgw0@mail.elegosoft.com> References: <20080419124306.oxag3l6ego0owgw0@mail.elegosoft.com> Message-ID: truncated yet again, maybe I have to forward instead of reply.. Truncated again.. Static linking libc is a different matter. It should work on Linux and NT but I realize it isn't universally supported. I did it by accident. The kernel does have a compatiblity burden, at least where the interfaces have been published. (On NT, the layering is different. You can link statically to libcmt.lib, which to a very large extent is what people think of libc, but it doesn't call the kernel directly, it goes through kernel32.dll, which goes through ntdll.dll, and syscall numbers are not stable.) Anyway, for libgmp and libmpfr, I still think static linking to these two is definitely ok, or better. Whether we import the source is a separate variable -- can still build a static .a file and link to it and drop the runtime dependency. That, or we get to deal with LD_LIBRARY_PATH and/or -rpath. It sure is nice how on Windows you can at least colocate .exes and .dlls in the same directory and the .dlls get found. This is a different matter vs. if current directory is in the search path for .exes. - Jay > Date: Sat, 19 Apr 2008 12:43:06 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] gmp and mpfr > > Quoting Jay : > > > Thanks. > > > > > other thoughts? > > > > Static link? > > > > I should measure the bloat. > > I accidentally statically linked to libc.a and the bloat was small, > > I think x86 static was smaller than AMD64 dynamic. > > We must not link _any_ executable completely statically, we've been > through that. Modern Unix systems all require dynamic linking, at > least for all the standard C libraries. > > > > But that would mean a full install of gcc and libraries. > > > > Really? > > Why not just gmp and mpfr and then point configure at them? > > Besides, if necessary, import them but not under gcc? > > > > - Jay > > > > > > From: HOSKING at cs.purdue.edu > > To: m3devel at elegosoft.com > > Date: Fri, 18 Apr 2008 17:23:24 -0400 > > Subject: [M3devel] gmp and mpfr > > > > I have added the necessary gmp and mpfr distributions to the > > m3cc/gcc package. It turns out that gcc will try to build from > > local source if it is available in the gcc hierarchy. Now, the only > > question is how to make sure that installs will put things in the > > right place. One option is to configure gcc to install into > > INSTALL_ROOT from the m3cc m3makefile. But that would mean a full > > install of gcc and libraries. Any other thoughts? > > If we really need to have these libraries in the distribution, > we should either link them in statically or put the shared objects > into INSTALL_ROOT/lib. We could either create different packages > (that would require adding these to several scripts) or add some > special quake code to build them all as part of m3cc: > > build libgmp > ship libgmp to INSTALL_ROOT/lib > build mpfr > ship mpfr to INSTALL_ROOT/lib > configure gcc with --with-mpfr=INSTALL_ROOT/lib/libmpfr.so \ > --with-gmp=INSTALL_ROOT/lib/libgmp.so > (I don't think the argument are completely correct, but you get the idea.) > build gcc > ship gcc > > The problem with this setup is that it wouldn't work for local builds > (without shipping), and we'd have problems when the libraries need > upgrade and we overwrite them (bootstrap will break). Or ensure > proper versioning here (which is nowhere done up=to-now in cm3). > > Or (in case of build without ship) just specify the locations in the > workspace? Then we'd need to re-link cm3cg in case of later build and > ship. > > What do you think? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 jayk123 at hotmail.com Sat Apr 19 14:57:48 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Apr 2008 12:57:48 +0000 Subject: [M3devel] FW: gmp and mpfr In-Reply-To: References: <20080419124306.oxag3l6ego0owgw0@mail.elegosoft.com> Message-ID: truncated a second time, I'll try from amother machine, geez short version -- static link libgmp and libmpfr, nothing else static linking libc ought to work imho but that is a different matter; kernels should be compatible with their published interfaces, if they have any -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Apr 19 15:50:00 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Apr 2008 13:50:00 +0000 Subject: [M3devel] gmp and mpfr In-Reply-To: <20080419130013.mo2bzawq9kwo0s0g@mail.elegosoft.com> References: <20080419130013.mo2bzawq9kwo0s0g@mail.elegosoft.com> Message-ID: Isn't it more proper to delete and re-add/re-import in the correct place? I mean, cvs -z3 upd can just work, right? - Jay > Date: Sat, 19 Apr 2008 13:00:13 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] gmp and mpfr > > Quoting Tony Hosking : > > > I have added the necessary gmp and mpfr distributions to the m3cc/gcc > > package. It turns out that gcc will try to build from local source if > > it is available in the gcc hierarchy. Now, the only question is how > > to make sure that installs will put things in the right place. One > > option is to configure gcc to install into INSTALL_ROOT from the m3cc > > m3makefile. But that would mean a full install of gcc and libraries. > > Any other thoughts? > > After wondering where the libraries might be, I've now found them > at /usr/cvs/cm3/m3cc/gcc/{mpfr,gmp}. > I think you wanted to import them to usr/cvs/cm3/m3-sys/m3cc/gcc/{mpfr,gmp}, > didn't you? > Any objections to move them inside the repository (will break existing > workspaces and repo copies...) > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 jayk123 at hotmail.com Sat Apr 19 16:31:32 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Apr 2008 14:31:32 +0000 Subject: [M3devel] a hope for dynamic linking! Message-ID: http://www.eyrie.org/~eagle/notes/rpath.html http://people.debian.org/~che/personal/rpath-considered-harmful but yet: http://www.scons.org/wiki/UsingOrigin So you can either colocate executables and .sos in the same directory or, like /cm3/bin /cm3/lib/m3core.so and vary the install root. We should be using this where available -- Linux, Solaris, Irix. Too bad not supported elsewhere. On Windows you can colocate; the .exe's directory is always searched. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Apr 19 16:40:25 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 19 Apr 2008 10:40:25 -0400 Subject: [M3devel] gmp and mpfr In-Reply-To: <20080419130013.mo2bzawq9kwo0s0g@mail.elegosoft.com> References: <20080419130013.mo2bzawq9kwo0s0g@mail.elegosoft.com> Message-ID: No, the gcc distros are set up to expect them in top-level gcc directory, if at all, along with the other libraries. The configure script will find them there and build locally as necessary rather than finding them in the usual installed places. On Apr 19, 2008, at 7:00 AM, Olaf Wagner wrote: > Quoting Tony Hosking : > >> I have added the necessary gmp and mpfr distributions to the m3cc/gcc >> package. It turns out that gcc will try to build from local source >> if >> it is available in the gcc hierarchy. Now, the only question is how >> to make sure that installs will put things in the right place. One >> option is to configure gcc to install into INSTALL_ROOT from the m3cc >> m3makefile. But that would mean a full install of gcc and libraries. >> Any other thoughts? > > After wondering where the libraries might be, I've now found them > at /usr/cvs/cm3/m3cc/gcc/{mpfr,gmp}. > I think you wanted to import them to usr/cvs/cm3/m3-sys/m3cc/gcc/ > {mpfr,gmp}, > didn't you? > Any objections to move them inside the repository (will break existing > workspaces and repo copies...) > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Sat Apr 19 16:42:54 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 19 Apr 2008 10:42:54 -0400 Subject: [M3devel] gmp and mpfr In-Reply-To: References: <20080419130013.mo2bzawq9kwo0s0g@mail.elegosoft.com> Message-ID: <44D5D5D2-7032-465D-B90E-EBDE9AD7DA75@cs.purdue.edu> Sorry. Looks like they're in the right place now. On Apr 19, 2008, at 9:50 AM, Jay wrote: > Isn't it more proper to delete and re-add/re-import in the correct > place? > I mean, cvs -z3 upd can just work, right? > > - Jay > > > > > Date: Sat, 19 Apr 2008 13:00:13 +0200 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] gmp and mpfr > > > > Quoting Tony Hosking : > > > > > I have added the necessary gmp and mpfr distributions to the > m3cc/gcc > > > package. It turns out that gcc will try to build from local > source if > > > it is available in the gcc hierarchy. Now, the only question is > how > > > to make sure that installs will put things in the right place. One > > > option is to configure gcc to install into INSTALL_ROOT from the > m3cc > > > m3makefile. But that would mean a full install of gcc and > libraries. > > > Any other thoughts? > > > > After wondering where the libraries might be, I've now found them > > at /usr/cvs/cm3/m3cc/gcc/{mpfr,gmp}. > > I think you wanted to import them to usr/cvs/cm3/m3-sys/m3cc/gcc/ > {mpfr,gmp}, > > didn't you? > > Any objections to move them inside the repository (will break > existing > > workspaces and repo copies...) > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Sat Apr 19 16:50:04 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 19 Apr 2008 10:50:04 -0400 Subject: [M3devel] a hope for dynamic linking! In-Reply-To: References: Message-ID: Hold on! I am strongly in favor of static linking for cm3cg/m3cgc1 so that it is a standalone executable. Should be easy enough with gcc configure. On Apr 19, 2008, at 10:31 AM, Jay wrote: > http://www.eyrie.org/~eagle/notes/rpath.html > http://people.debian.org/~che/personal/rpath-considered-harmful > > > but yet: > > http://www.scons.org/wiki/UsingOrigin > > So you can either colocate executables and .sos in the same > directory or, like > /cm3/bin > /cm3/lib/m3core.so > > and vary the install root. > > We should be using this where available -- Linux, Solaris, Irix. > Too bad not supported elsewhere. > On Windows you can colocate; the .exe's directory is always searched. > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Apr 19 17:02:44 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Apr 2008 15:02:44 +0000 Subject: [M3devel] a hope for dynamic linking! In-Reply-To: References: Message-ID: I mean for the "regular" Modula-3 "app" stuff, not cm3cg. It looks like it is already static, good. 1) http://gcc.gnu.org/ml/gcc/2006-10/msg00141.html 2) The current code: m3-sys/m3cc/gcc/Makefile.in: configure-gmp: ... echo Configuring in $(HOST_SUBDIR)/gmp; \ ... $(HOST_CONFIGARGS) --build=${build_alias} --host=none-${host_vendor}-${host_os} \ --target=none-${host_vendor}-${host_os} $${srcdiroption} --disable-shared \ || exit 1 @endif gmp configure-mpfr: ... echo Configuring in $(HOST_SUBDIR)/mpfr; \ ... $(HOST_CONFIGARGS) --build=${build_alias} --host=none-${host_vendor}-${host_os} \ --target=none-${host_vendor}-${host_os} $${srcdiroption} --disable-shared --with-gmp-build=$$r/$(HOST_SUBDIR)/gmp \ || exit 1 @endif mpfr Let me test it and then I'll remove the Quake code related to this. - Jay CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jayk123 at hotmail.com Subject: Re: [M3devel] a hope for dynamic linking! Date: Sat, 19 Apr 2008 10:50:04 -0400 Hold on! I am strongly in favor of static linking for cm3cg/m3cgc1 so that it is a standalone executable. Should be easy enough with gcc configure. On Apr 19, 2008, at 10:31 AM, Jay wrote:http://www.eyrie.org/~eagle/notes/rpath.html http://people.debian.org/~che/personal/rpath-considered-harmful but yet: http://www.scons.org/wiki/UsingOrigin So you can either colocate executables and .sos in the same directory or, like /cm3/bin /cm3/lib/m3core.so and vary the install root. We should be using this where available -- Linux, Solaris, Irix. Too bad not supported elsewhere. On Windows you can colocate; the .exe's directory is always searched. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Apr 19 17:10:16 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Apr 2008 15:10:16 +0000 Subject: [M3devel] a hope for dynamic linking! In-Reply-To: References: Message-ID: (ok, actually I meant maybe for cm3cg but ok either way, there'd only be one use of "/usr/local/cm3/bin/libgmp.so" so might as well be static) From: jayk123 at hotmail.com To: hosking at cs.purdue.edu Date: Sat, 19 Apr 2008 15:02:44 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] a hope for dynamic linking! I mean for the "regular" Modula-3 "app" stuff, not cm3cg. It looks like it is already static, good. 1) http://gcc.gnu.org/ml/gcc/2006-10/msg00141.html 2) The current code: m3-sys/m3cc/gcc/Makefile.in: configure-gmp: ... echo Configuring in $(HOST_SUBDIR)/gmp; \ ... $(HOST_CONFIGARGS) --build=${build_alias} --host=none-${host_vendor}-${host_os} \ --target=none-${host_vendor}-${host_os} $${srcdiroption} --disable-shared \ || exit 1 @endif gmp configure-mpfr: ... echo Configuring in $(HOST_SUBDIR)/mpfr; \ ... $(HOST_CONFIGARGS) --build=${build_alias} --host=none-${host_vendor}-${host_os} \ --target=none-${host_vendor}-${host_os} $${srcdiroption} --disable-shared --with-gmp-build=$$r/$(HOST_SUBDIR)/gmp \ || exit 1 @endif mpfr Let me test it and then I'll remove the Quake code related to this. - Jay CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jayk123 at hotmail.com Subject: Re: [M3devel] a hope for dynamic linking! Date: Sat, 19 Apr 2008 10:50:04 -0400 Hold on! I am strongly in favor of static linking for cm3cg/m3cgc1 so that it is a standalone executable. Should be easy enough with gcc configure. On Apr 19, 2008, at 10:31 AM, Jay wrote:http://www.eyrie.org/~eagle/notes/rpath.html http://people.debian.org/~che/personal/rpath-considered-harmful but yet: http://www.scons.org/wiki/UsingOrigin So you can either colocate executables and .sos in the same directory or, like /cm3/bin /cm3/lib/m3core.so and vary the install root. We should be using this where available -- Linux, Solaris, Irix. Too bad not supported elsewhere. On Windows you can colocate; the .exe's directory is always searched. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Apr 19 17:34:38 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 19 Apr 2008 11:34:38 -0400 Subject: [M3devel] a hope for dynamic linking! In-Reply-To: References: Message-ID: Regular Modula-3 app stuff should build statically already, where it makes sense. build_standalone() achieves this. On some systems static libraries for certain system libraries are not available and cannot be assumed. We always build static Modula-3 libraries, so the current setup will link those statically even if other libraries are not available. For example, cm3 on I386_DARWIN gives: hosking$ otool -L /usr/local/cm3/bin/cm3 /usr/local/cm3/bin/cm3: /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) Notice that all the M3 libraries are static, but libgcc and friends are dynamic. So, I don't know what you are attempting to do. Did you try --disable- shared for m3cc configuration? On Apr 19, 2008, at 11:10 AM, Jay wrote: > (ok, actually I meant maybe for cm3cg but ok either way, there'd > only be one use of "/usr/local/cm3/bin/libgmp.so" so might as well > be static) > > > > > From: jayk123 at hotmail.com > To: hosking at cs.purdue.edu > Date: Sat, 19 Apr 2008 15:02:44 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] a hope for dynamic linking! > > I mean for the "regular" Modula-3 "app" stuff, not cm3cg. > > It looks like it is already static, good. > > 1) http://gcc.gnu.org/ml/gcc/2006-10/msg00141.html > > 2) The current code: > > m3-sys/m3cc/gcc/Makefile.in: > > configure-gmp: > ... > echo Configuring in $(HOST_SUBDIR)/gmp; \ > ... > $(HOST_CONFIGARGS) --build=${build_alias} --host=none-$ > {host_vendor}-${host_os} \ > --target=none-${host_vendor}-${host_os} $${srcdiroption} -- > disable-shared \ > || exit 1 > @endif gmp > > > configure-mpfr: > ... > echo Configuring in $(HOST_SUBDIR)/mpfr; \ > ... > $(HOST_CONFIGARGS) --build=${build_alias} --host=none-$ > {host_vendor}-${host_os} \ > --target=none-${host_vendor}-${host_os} $${srcdiroption} -- > disable-shared --with-gmp-build=$$r/$(HOST_SUBDIR)/gmp \ > || exit 1 > @endif mpfr > > > Let me test it and then I'll remove the Quake code related to this. > > > - Jay > > > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jayk123 at hotmail.com > Subject: Re: [M3devel] a hope for dynamic linking! > Date: Sat, 19 Apr 2008 10:50:04 -0400 > > Hold on! I am strongly in favor of static linking for cm3cg/m3cgc1 > so that it is a standalone executable. Should be easy enough with > gcc configure. > > On Apr 19, 2008, at 10:31 AM, Jay wrote: > http://www.eyrie.org/~eagle/notes/rpath.html > http://people.debian.org/~che/personal/rpath-considered-harmful > > > but yet: > > http://www.scons.org/wiki/UsingOrigin > > So you can either colocate executables and .sos in the same > directory or, like > /cm3/bin > /cm3/lib/m3core.so > > and vary the install root. > > We should be using this where available -- Linux, Solaris, Irix. > Too bad not supported elsewhere. > On Windows you can colocate; the .exe's directory is always searched. > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Apr 19 17:46:31 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Apr 2008 15:46:31 +0000 Subject: [M3devel] a hope for dynamic linking! In-Reply-To: References: Message-ID: I understand. But when dynamic linking is actually used, -rpath/$ORIGIN might be a little better than having to modify LD_LIBRARY_PATH. I realize it's not night and day. It doesn't make dynamic linking suddenly problem free, just maybe every so slightly better. When that still isn't adequate and diskspace/memory not a concern, or there are issues of circular dependencies (cm3), build_standalone. (I think cm3 is statically linked for subtle reasons I can't quite grasp at the moment. Not just so it can copy m3core.dll around while it is running, that could probably be dealt with less severely.) It looks like when gmp/mpfr source are in the gcc tree, it always does --disable-shared on them. I'm testing some now. libgcc seems to be a bit of a middle ground, like Modula3 stuff -- available both static and dynamic, and the need for dynamic varies. libgcc I believe contains roughly: 1) math helpers -- multiply/divide, 64 bit stuff 2) exception handling #1 is a case of kinda like, hey, I didn't make any function calls, why do I do need a .lib or .dll and no thank you on the dynamic linking headaches #2 is similar, but rather than "no function calls", it's using language constructs that actually have heavy dependencies, and if people want to throw/catch exceptions across linkage boundaries, the exception handling implementation might need to be shared building with the in-gcc-tree gmp/mpfr: gcc -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_STDARG=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SETLOCALE=1 -DHAVE_GETTIMEOFDAY=1 -DMPFR_HAVE_FESETROUND=1 -DHAVE_ROUND=1 -DHAVE_TRUNC=1 -DHAVE_FLOOR=1 -DHAVE_CEIL=1 -DHAVE_NEARBYINT=1 -DHAVE_ATTRIBUTE_MODE=1 -DHAVE_ALLOCA_H=1 -I. -I../../gcc/mpfr -I/dev2/cm3/m3-sys/m3cc/PPC_DARWIN/./gmp -I/dev2/cm3/m3-sys/m3cc/PPC_DARWIN/./gmp/tune -g -MT remquo.lo -MD -MP -MF .deps/remquo.Tpo -c ../../gcc/mpfr/remquo.c -o remquo.o ./get_patches.sh > get_patches.c || rm -f get_patches.c /bin/sh: line 1: ./get_patches.sh: No such file or directory if /bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_STDARG=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SETLOCALE=1 -DHAVE_GETTIMEOFDAY=1 -DMPFR_HAVE_FESETROUND=1 -DHAVE_ROUND=1 -DHAVE_TRUNC=1 -DHAVE_FLOOR=1 -DHAVE_CEIL=1 -DHAVE_NEARBYINT=1 -DHAVE_ATTRIBUTE_MODE=1 -DHAVE_ALLOCA_H=1 -I. -I../../gcc/mpfr -I/dev2/cm3/m3-sys/m3cc/PPC_DARWIN/./gmp -I/dev2/cm3/m3-sys/m3cc/PPC_DARWIN/./gmp/tune -g -MT get_patches.lo -MD -MP -MF ".deps/get_patches.Tpo" -c -o get_patches.lo get_patches.c; \ then mv -f ".deps/get_patches.Tpo" ".deps/get_patches.Plo"; else rm -f ".deps/get_patches.Tpo"; exit 1; fi gcc -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_STDARG=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SETLOCALE=1 -DHAVE_GETTIMEOFDAY=1 -DMPFR_HAVE_FESETROUND=1 -DHAVE_ROUND=1 -DHAVE_TRUNC=1 -DHAVE_FLOOR=1 -DHAVE_CEIL=1 -DHAVE_NEARBYINT=1 -DHAVE_ATTRIBUTE_MODE=1 -DHAVE_ALLOCA_H=1 -I. -I../../gcc/mpfr -I/dev2/cm3/m3-sys/m3cc/PPC_DARWIN/./gmp -I/dev2/cm3/m3-sys/m3cc/PPC_DARWIN/./gmp/tune -g -MT get_patches.lo -MD -MP -MF .deps/get_patches.Tpo -c get_patches.c -o get_patches.o powerpc-apple-darwin8-gcc-4.0.1: get_patches.c: No such file or directory I'll investigate. I was able to build them on another machine via apt-get source. Maybe you missed a file? I'll look.. - Jay CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jayk123 at hotmail.com Subject: Re: [M3devel] a hope for dynamic linking! Date: Sat, 19 Apr 2008 11:34:38 -0400 Regular Modula-3 app stuff should build statically already, where it makes sense. build_standalone() achieves this. On some systems static libraries for certain system libraries are not available and cannot be assumed. We always build static Modula-3 libraries, so the current setup will link those statically even if other libraries are not available. For example, cm3 on I386_DARWIN gives: hosking$ otool -L /usr/local/cm3/bin/cm3/usr/local/cm3/bin/cm3: /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) Notice that all the M3 libraries are static, but libgcc and friends are dynamic. So, I don't know what you are attempting to do. Did you try --disable-shared for m3cc configuration? On Apr 19, 2008, at 11:10 AM, Jay wrote:(ok, actually I meant maybe for cm3cg but ok either way, there'd only be one use of "/usr/local/cm3/bin/libgmp.so" so might as well be static) From: jayk123 at hotmail.com To: hosking at cs.purdue.edu Date: Sat, 19 Apr 2008 15:02:44 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] a hope for dynamic linking! I mean for the "regular" Modula-3 "app" stuff, not cm3cg. It looks like it is already static, good. 1) http://gcc.gnu.org/ml/gcc/2006-10/msg00141.html 2) The current code: m3-sys/m3cc/gcc/Makefile.in: configure-gmp: ... echo Configuring in $(HOST_SUBDIR)/gmp; \ ... $(HOST_CONFIGARGS) --build=${build_alias} --host=none-${host_vendor}-${host_os} \ --target=none-${host_vendor}-${host_os} $${srcdiroption} --disable-shared \ || exit 1 @endif gmp configure-mpfr: ... echo Configuring in $(HOST_SUBDIR)/mpfr; \ ... $(HOST_CONFIGARGS) --build=${build_alias} --host=none-${host_vendor}-${host_os} \ --target=none-${host_vendor}-${host_os} $${srcdiroption} --disable-shared --with-gmp-build=$$r/$(HOST_SUBDIR)/gmp \ || exit 1 @endif mpfr Let me test it and then I'll remove the Quake code related to this. - Jay CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jayk123 at hotmail.com Subject: Re: [M3devel] a hope for dynamic linking! Date: Sat, 19 Apr 2008 10:50:04 -0400 Hold on! I am strongly in favor of static linking for cm3cg/m3cgc1 so that it is a standalone executable. Should be easy enough with gcc configure. On Apr 19, 2008, at 10:31 AM, Jay wrote:http://www.eyrie.org/~eagle/notes/rpath.html http://people.debian.org/~che/personal/rpath-considered-harmful but yet: http://www.scons.org/wiki/UsingOrigin So you can either colocate executables and .sos in the same directory or, like /cm3/bin /cm3/lib/m3core.so and vary the install root. We should be using this where available -- Linux, Solaris, Irix. Too bad not supported elsewhere. On Windows you can colocate; the .exe's directory is always searched. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Apr 19 17:56:34 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Apr 2008 15:56:34 +0000 Subject: [M3devel] a hope for dynamic linking! In-Reply-To: References: Message-ID: sorry, that was with them symlinked in, from before the fix; maybe that's the problem I'll see. - Jay From: jayk123 at hotmail.com To: hosking at cs.purdue.edu Date: Sat, 19 Apr 2008 15:46:31 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] a hope for dynamic linking! I understand. But when dynamic linking is actually used, -rpath/$ORIGIN might be a little better than having to modify LD_LIBRARY_PATH. I realize it's not night and day. It doesn't make dynamic linking suddenly problem free, just maybe every so slightly better. When that still isn't adequate and diskspace/memory not a concern, or there are issues of circular dependencies (cm3), build_standalone. (I think cm3 is statically linked for subtle reasons I can't quite grasp at the moment. Not just so it can copy m3core.dll around while it is running, that could probably be dealt with less severely.) It looks like when gmp/mpfr source are in the gcc tree, it always does --disable-shared on them. I'm testing some now. libgcc seems to be a bit of a middle ground, like Modula3 stuff -- available both static and dynamic, and the need for dynamic varies. libgcc I believe contains roughly: 1) math helpers -- multiply/divide, 64 bit stuff 2) exception handling #1 is a case of kinda like, hey, I didn't make any function calls, why do I do need a .lib or .dll and no thank you on the dynamic linking headaches #2 is similar, but rather than "no function calls", it's using language constructs that actually have heavy dependencies, and if people want to throw/catch exceptions across linkage boundaries, the exception handling implementation might need to be shared building with the in-gcc-tree gmp/mpfr: gcc -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_STDARG=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SETLOCALE=1 -DHAVE_GETTIMEOFDAY=1 -DMPFR_HAVE_FESETROUND=1 -DHAVE_ROUND=1 -DHAVE_TRUNC=1 -DHAVE_FLOOR=1 -DHAVE_CEIL=1 -DHAVE_NEARBYINT=1 -DHAVE_ATTRIBUTE_MODE=1 -DHAVE_ALLOCA_H=1 -I. -I../../gcc/mpfr -I/dev2/cm3/m3-sys/m3cc/PPC_DARWIN/./gmp -I/dev2/cm3/m3-sys/m3cc/PPC_DARWIN/./gmp/tune -g -MT remquo.lo -MD -MP -MF .deps/remquo.Tpo -c ../../gcc/mpfr/remquo.c -o remquo.o ./get_patches.sh > get_patches.c || rm -f get_patches.c /bin/sh: line 1: ./get_patches.sh: No such file or directory if /bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_STDARG=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SETLOCALE=1 -DHAVE_GETTIMEOFDAY=1 -DMPFR_HAVE_FESETROUND=1 -DHAVE_ROUND=1 -DHAVE_TRUNC=1 -DHAVE_FLOOR=1 -DHAVE_CEIL=1 -DHAVE_NEARBYINT=1 -DHAVE_ATTRIBUTE_MODE=1 -DHAVE_ALLOCA_H=1 -I. -I../../gcc/mpfr -I/dev2/cm3/m3-sys/m3cc/PPC_DARWIN/./gmp -I/dev2/cm3/m3-sys/m3cc/PPC_DARWIN/./gmp/tune -g -MT get_patches.lo -MD -MP -MF ".deps/get_patches.Tpo" -c -o get_patches.lo get_patches.c; \ then mv -f ".deps/get_patches.Tpo" ".deps/get_patches.Plo"; else rm -f ".deps/get_patches.Tpo"; exit 1; fi gcc -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_STDARG=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SETLOCALE=1 -DHAVE_GETTIMEOFDAY=1 -DMPFR_HAVE_FESETROUND=1 -DHAVE_ROUND=1 -DHAVE_TRUNC=1 -DHAVE_FLOOR=1 -DHAVE_CEIL=1 -DHAVE_NEARBYINT=1 -DHAVE_ATTRIBUTE_MODE=1 -DHAVE_ALLOCA_H=1 -I. -I../../gcc/mpfr -I/dev2/cm3/m3-sys/m3cc/PPC_DARWIN/./gmp -I/dev2/cm3/m3-sys/m3cc/PPC_DARWIN/./gmp/tune -g -MT get_patches.lo -MD -MP -MF .deps/get_patches.Tpo -c get_patches.c -o get_patches.o powerpc-apple-darwin8-gcc-4.0.1: get_patches.c: No such file or directory I'll investigate. I was able to build them on another machine via apt-get source. Maybe you missed a file? I'll look.. - Jay CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jayk123 at hotmail.com Subject: Re: [M3devel] a hope for dynamic linking! Date: Sat, 19 Apr 2008 11:34:38 -0400 Regular Modula-3 app stuff should build statically already, where it makes sense. build_standalone() achieves this. On some systems static libraries for certain system libraries are not available and cannot be assumed. We always build static Modula-3 libraries, so the current setup will link those statically even if other libraries are not available. For example, cm3 on I386_DARWIN gives: hosking$ otool -L /usr/local/cm3/bin/cm3/usr/local/cm3/bin/cm3: /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) Notice that all the M3 libraries are static, but libgcc and friends are dynamic. So, I don't know what you are attempting to do. Did you try --disable-shared for m3cc configuration? On Apr 19, 2008, at 11:10 AM, Jay wrote:(ok, actually I meant maybe for cm3cg but ok either way, there'd only be one use of "/usr/local/cm3/bin/libgmp.so" so might as well be static) From: jayk123 at hotmail.com To: hosking at cs.purdue.edu Date: Sat, 19 Apr 2008 15:02:44 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] a hope for dynamic linking! I mean for the "regular" Modula-3 "app" stuff, not cm3cg. It looks like it is already static, good. 1) http://gcc.gnu.org/ml/gcc/2006-10/msg00141.html 2) The current code: m3-sys/m3cc/gcc/Makefile.in: configure-gmp: ... echo Configuring in $(HOST_SUBDIR)/gmp; \ ... $(HOST_CONFIGARGS) --build=${build_alias} --host=none-${host_vendor}-${host_os} \ --target=none-${host_vendor}-${host_os} $${srcdiroption} --disable-shared \ || exit 1 @endif gmp configure-mpfr: ... echo Configuring in $(HOST_SUBDIR)/mpfr; \ ... $(HOST_CONFIGARGS) --build=${build_alias} --host=none-${host_vendor}-${host_os} \ --target=none-${host_vendor}-${host_os} $${srcdiroption} --disable-shared --with-gmp-build=$$r/$(HOST_SUBDIR)/gmp \ || exit 1 @endif mpfr Let me test it and then I'll remove the Quake code related to this. - Jay CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jayk123 at hotmail.com Subject: Re: [M3devel] a hope for dynamic linking! Date: Sat, 19 Apr 2008 10:50:04 -0400 Hold on! I am strongly in favor of static linking for cm3cg/m3cgc1 so that it is a standalone executable. Should be easy enough with gcc configure. On Apr 19, 2008, at 10:31 AM, Jay wrote:http://www.eyrie.org/~eagle/notes/rpath.html http://people.debian.org/~che/personal/rpath-considered-harmful but yet: http://www.scons.org/wiki/UsingOrigin So you can either colocate executables and .sos in the same directory or, like /cm3/bin /cm3/lib/m3core.so and vary the install root. We should be using this where available -- Linux, Solaris, Irix. Too bad not supported elsewhere. On Windows you can colocate; the .exe's directory is always searched. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Apr 19 18:09:37 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 19 Apr 2008 12:09:37 -0400 Subject: [M3devel] a hope for dynamic linking! In-Reply-To: References: Message-ID: <1C5B9FD1-2B46-4C4E-9F21-A7CD1119C5F5@cs.purdue.edu> I just ran into this one myself. Looks like this version of mpfr doesn't play totally nicely with building within gcc. I've commented out the following lines in mpfr/Makefile.in which appear to do the trick. If so, then I will commit it... get_patches.c: PATCHES get_patches.sh ./get_patches.sh > $@ || rm -f $@ On Apr 19, 2008, at 11:46 AM, Jay wrote: > building with the in-gcc-tree gmp/mpfr: > > gcc -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DTIME_WITH_SYS_TIME=1 - > DHAVE_STDARG=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SETLOCALE=1 - > DHAVE_GETTIMEOFDAY=1 -DMPFR_HAVE_FESETROUND=1 -DHAVE_ROUND=1 - > DHAVE_TRUNC=1 -DHAVE_FLOOR=1 -DHAVE_CEIL=1 -DHAVE_NEARBYINT=1 - > DHAVE_ATTRIBUTE_MODE=1 -DHAVE_ALLOCA_H=1 -I. -I../../gcc/mpfr -I/ > dev2/cm3/m3-sys/m3cc/PPC_DARWIN/./gmp -I/dev2/cm3/m3-sys/m3cc/ > PPC_DARWIN/./gmp/tune -g -MT remquo.lo -MD -MP -MF .deps/remquo.Tpo - > c ../../gcc/mpfr/remquo.c -o remquo.o > ./get_patches.sh > get_patches.c || rm -f get_patches.c > /bin/sh: line 1: ./get_patches.sh: No such file or directory > if /bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_INTTYPES_H=1 > -DHAVE_STDINT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_STDARG=1 - > DHAVE_SYS_TIME_H=1 -DHAVE_SETLOCALE=1 -DHAVE_GETTIMEOFDAY=1 - > DMPFR_HAVE_FESETROUND=1 -DHAVE_ROUND=1 -DHAVE_TRUNC=1 -DHAVE_FLOOR=1 > -DHAVE_CEIL=1 -DHAVE_NEARBYINT=1 -DHAVE_ATTRIBUTE_MODE=1 - > DHAVE_ALLOCA_H=1 -I. -I../../gcc/mpfr -I/dev2/cm3/m3-sys/m3cc/ > PPC_DARWIN/./gmp -I/dev2/cm3/m3-sys/m3cc/PPC_DARWIN/./gmp/tune -g - > MT get_patches.lo -MD -MP -MF ".deps/get_patches.Tpo" -c -o > get_patches.lo get_patches.c; \ > then mv -f ".deps/get_patches.Tpo" ".deps/get_patches.Plo"; else rm - > f ".deps/get_patches.Tpo"; exit 1; fi > gcc -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DTIME_WITH_SYS_TIME=1 - > DHAVE_STDARG=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SETLOCALE=1 - > DHAVE_GETTIMEOFDAY=1 -DMPFR_HAVE_FESETROUND=1 -DHAVE_ROUND=1 - > DHAVE_TRUNC=1 -DHAVE_FLOOR=1 -DHAVE_CEIL=1 -DHAVE_NEARBYINT=1 - > DHAVE_ATTRIBUTE_MODE=1 -DHAVE_ALLOCA_H=1 -I. -I../../gcc/mpfr -I/ > dev2/cm3/m3-sys/m3cc/PPC_DARWIN/./gmp -I/dev2/cm3/m3-sys/m3cc/ > PPC_DARWIN/./gmp/tune -g -MT get_patches.lo -MD -MP -MF .deps/ > get_patches.Tpo -c get_patches.c -o get_patches.o > powerpc-apple-darwin8-gcc-4.0.1: get_patches.c: No such file or > directory -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Apr 19 22:06:43 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 19 Apr 2008 22:06:43 +0200 Subject: [M3devel] new gcc configure and setup In-Reply-To: References: <20080419113533.zi4vqsvxs0ocgs4c@mail.elegosoft.com> <3E4BBF85-989B-4649-AC7D-20E82610940B@cs.purdue.edu> <2A490CE3-D906-4795-B7A8-5928276CA2FD@cs.purdue.edu> Message-ID: <20080419220643.d9sfh9gx8kggkw8g@mail.elegosoft.com> I manually started a build on new.elego.de some hours ago, which succeeded; everything seems to build again now, thanks to you both! And we have the base for X64 support in CM3, which is a great step forward! Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Sun Apr 20 05:56:15 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 20 Apr 2008 03:56:15 +0000 Subject: [M3devel] moving versions into simple text file (sh?) Message-ID: I'd like to (finally) move the default versions out into a simple file. Given: jbook15:/dev2/cm3/scripts jay$ cat version CM3VERSION d5.7.0 CM3VERSIONNUM 050700 CM3LASTCHANGED 2008-03-16 Is there any chance this is Posix/Solaris compliant? get_version() { if [ -n "$(eval echo \$$1)" ] ; then return fi eval "$1=\"$(echo $(grep "$1 " $root/scripts/version | awk '{print $2}'))\"" } get_version CM3VERSION get_version CM3VERSIONNUM get_version CM3LASTCHANGED echo "CM3VERSION is $CM3VERSION" echo "CM3VERSIONNUM is $CM3VERSIONNUM" echo "CM3LASTCHANGED is $CM3LASTCHANGED" It works on my Mac. This is not what I would have expected, in particular the need for eval and echo seems strange. The quoting is all unfortunate as usual too. If this isn't standard, then how about just the last line: get_version() { eval "$1=\"$(echo $(grep "$1 " $root/scripts/version | awk '{print $2}'))\"" } ? Otherwise, I guess dumb it down and be repetitive, like: CM3VERSION=${CM3VERSION-`grep "CM3VERSION " $root/scripts/version | awk '{print $2}'))`} ? I didn't want to repeat the variable names three times each. What I really want is to append version to PKGS and regenerate PKGS whenever its lines aren't all there, so as to trigger an automatic rebuild of PKGS when the version changes. One more application of the version numbers, and I was pushed to fix them. Full diff: Index: sysinfo.sh =================================================================== RCS file: /usr/cvs/cm3/scripts/sysinfo.sh,v retrieving revision 1.61 diff -c -r1.61 sysinfo.sh *** sysinfo.sh 15 Apr 2008 06:51:31 -0000 1.61 --- sysinfo.sh 20 Apr 2008 03:48:13 -0000 *************** *** 10,38 **** PRJ_ROOT=${PRJ_ROOT:-${HOME}/work} - #----------------------------------------------------------------------------- - # set some defaults # ! # These three lines must be carefully formed as they are parsed by other code. # ! # For cmd: ! # They must start with a name and an equals sign. ! # They must contain one and only one colon. ! # They must contain one and only one equals sign. ! # The content to the right of the colon, minus the first two ! # and last two characters, is the value. # ! # For Python, we have much more flexibility. Currently the code ! # looks for fairly precisely A=${A:-"value"}, but this can be easily ! # relaxed or changed. # ! # Refer to scripts/win/sysinfo.cmd and scripts/python/lib.py. ! # Specifically look for "DefaultsFromSh". # CM3VERSION=${CM3VERSION:-"d5.7.0"} CM3VERSIONNUM=${CM3VERSIONNUM:-"050700"} CM3LASTCHANGED=${CM3LASTCHANGED:-"2008-03-16"} CM3_GCC_BACKEND=yes CM3_GDB=no # --- 10,49 ---- PRJ_ROOT=${PRJ_ROOT:-${HOME}/work} # ! # Allow direct invocation of sysinfo.sh for testing purposes. # ! if [ -z "$root" -o ! -d "$root" ] ; then ! root=`pwd` ! while [ -n "$root" -a ! -f "$root/scripts/sysinfo.sh" ] ; do ! root=`dirname $root` ! done ! fi ! ! #----------------------------------------------------------------------------- ! # set some defaults # ! ! get_version() { ! if [ -n "$(eval echo \$$1)" ] ; then ! return ! fi ! eval "$1=\"$(echo $(grep "$1 " $root/scripts/version | awk '{print $2}'))\"" ! } ! ! get_version CM3VERSION ! get_version CM3VERSIONNUM ! get_version CM3LASTCHANGED ! # ! # Leave these lines in TEMPORARILY for compat with cmd, Python, Quake. # CM3VERSION=${CM3VERSION:-"d5.7.0"} CM3VERSIONNUM=${CM3VERSIONNUM:-"050700"} CM3LASTCHANGED=${CM3LASTCHANGED:-"2008-03-16"} + CM3_INSTALL=${CM3_INSTALL:-`dirname \`find_exe cm3 /usr/local/cm3/\ \``} + CM3_GCC_BACKEND=yes CM3_GDB=no # - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.illig at gmx.de Sun Apr 20 09:58:28 2008 From: roland.illig at gmx.de (Roland Illig) Date: Sun, 20 Apr 2008 08:58:28 +0100 Subject: [M3devel] moving versions into simple text file (sh?) In-Reply-To: References: Message-ID: <480AF7A4.4060905@gmx.de> Jay schrieb: > I'd like to (finally) move the default versions out into a simple file. > > Given: > > jbook15:/dev2/cm3/scripts jay$ cat version > CM3VERSION d5.7.0 > CM3VERSIONNUM 050700 > CM3LASTCHANGED 2008-03-16 > > Is there any chance this is Posix/Solaris compliant? > > get_version() { > if [ -n "$(eval echo \$$1)" ] ; then > return > fi > eval "$1=\"$(echo $(grep "$1 " $root/scripts/version | awk '{print > $2}'))\"" > } Solaris' /bin/sh doesn't know the $(...) operator. Why do you need "eval echo" at all? Better use this: # usage: get_version VARNAME get_version() { eval "gv__set=\${$1+set}" if [ "$gv__set" != "set" ]; then gv__value=`awk '$1 == "'"$1"'" { print $2 }' $root/scripts/version` eval "$1=\$gv__value" fi } $ /bin/sh $ . ./get_version.sh $ set -x $ get_version CM3VERSION + get_version CM3VERSION + eval __set=${CM3VERSION+set} __set= + [ != set ] + awk $1 == "CM3VERSION" { print $2 } version value=d5.7.0 + eval CM3VERSION=$value CM3VERSION=d5.7.0 $ get_version CM3VERSION + get_version CM3VERSION + eval __set=${CM3VERSION+set} __set=set + [ set != set ] Roland From roland.illig at gmx.de Sun Apr 20 10:05:25 2008 From: roland.illig at gmx.de (Roland Illig) Date: Sun, 20 Apr 2008 09:05:25 +0100 Subject: [M3devel] moving versions into simple text file (sh?) In-Reply-To: <480AF7A4.4060905@gmx.de> References: <480AF7A4.4060905@gmx.de> Message-ID: <480AF945.40602@gmx.de> Roland Illig schrieb: > Jay schrieb: >> I'd like to (finally) move the default versions out into a simple file. >> >> Given: >> >> jbook15:/dev2/cm3/scripts jay$ cat version >> CM3VERSION d5.7.0 >> CM3VERSIONNUM 050700 >> CM3LASTCHANGED 2008-03-16 or maybe this, which is even easier: $ eval "`sed 's, ,=,' $root/scripts/version`" Roland From jayk123 at hotmail.com Sun Apr 20 16:26:34 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 20 Apr 2008 14:26:34 +0000 Subject: [M3devel] moving versions into simple text file (sh?) In-Reply-To: <480AF945.40602@gmx.de> References: <480AF7A4.4060905@gmx.de> <480AF945.40602@gmx.de> Message-ID: Right -- turning it into executable code is tempting, however what you show isn't quite the whole story. Perhaps if the sed sticks default_ on the front or something. How about: > $ eval "`awk < $root/scripts/version '{print default_$1=$2}'`" FOO=${FOO:$default_FOO} BAR=${FOO:$default_BAR} So then I am back to repeating every variable name three times, but hey at least I only run awk/sed once instead of three times. :) I will try something like that. The other code you shows was not understandable to me, alas. I wasn't going to use $( ), but it does seem to be posix and nested ` bit me before. So I've been reading about bash vs. sh vs. dash, and autoconfigure..and I learn that Solaris sh is pre-Posix and not conformant. That /bin/sh isn't even where you get Posix sh from, according to Posix. I am more and more convinced that the way to go "here" (not actually "here", not Modula-3 related, but GNU/Unix related) is a really small "portable" "thingy" that is used only to bootstrap the next level up which would be much richer. For example, a decent non-extensible single-threaded scripting language written in one large C file, that only used like stdio and/or open/read/write.. Then the "configure" script is really small: configure-unix #!/bin/sh cc foo.c -o foo if ! -f foo then echo "C compilation failed, please see $0" exit 1 end ./foo $0 And then write the rest in C, but the "script" can contain some "scripting language" for the C to interpret from there. Write the above in .cmd/.bat and the VMS language and done. Add some probes for the compiler name, cl, bcc, icc, dmc, etc. I mean, all the gnarly workarounds in autoconf output, heck, can't bash be distilled down to a small portable useful base, that doesn't need configuring, and just use it without workarounds? I just don't see much value in all the layers.. or I'm too lazy to keep learning more and more and more similar stuff full of history and cruft.... - Jay ---------------------------------------- > Date: Sun, 20 Apr 2008 09:05:25 +0100 > From: roland.illig at gmx.de > To: m3devel at elegosoft.com > Subject: Re: [M3devel] moving versions into simple text file (sh?) > > Roland Illig schrieb: >> Jay schrieb: >>> I'd like to (finally) move the default versions out into a simple file. >>> >>> Given: >>> >>> jbook15:/dev2/cm3/scripts jay$ cat version >>> CM3VERSION d5.7.0 >>> CM3VERSIONNUM 050700 >>> CM3LASTCHANGED 2008-03-16 > > or maybe this, which is even easier: > > $ eval "`sed 's, ,=,' $root/scripts/version`" > > Roland From hosking at cs.purdue.edu Mon Apr 21 00:52:51 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 20 Apr 2008 18:52:51 -0400 Subject: [M3devel] Update on cm3cg for x86_64 Linux Message-ID: <7281A261-2AC4-46CA-938C-785C1C4D1EE1@cs.purdue.edu> It seems there is an incompatibility between cm3cg built using default gcc (not -m32) on x86_64 Linux and the CM3 front-end targeting 32-bit LINUXLIBC6. I get errors in the gcc-based backend code if I build it without -m32 using it to compile M3IR. Looks like some problem with LONGREAL alignment. If I build using -m32 then cm3cg works just fine on x86_64. Anyway, something to watch out for. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Apr 22 01:15:05 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Apr 2008 23:15:05 +0000 Subject: [M3devel] more path stuff, sorry Message-ID: Maybe this is dubious. The question is, like, should native NT386 cm3 accept /cygdrive/c/foo and translate to c:\foo?Or trickier, /usr/bin/foo and translate to c:\cygwin\usr\bin\foo?And vice versa, should NT386GNU accept c:\foo? The translation is not simple in general./ maps to the Cygwin install root.There can be symlinks.But many common cases can be handled with little, simple code.It's already in. Ultimately the way to do this correctly is to link to cygwin1.dll, which is only done sometimes, and which probably license-undesirable when not done. As well, a path like /foo is actually ambiguous.It is a valid native Win32 path, equivalent to \foo.Or it could be Cygwin path requivalent to c:\cygwin\foo. While it is nice to keep cm3 simple, it is also nice to have a more uniform interfaceacross hosts, I think. Maybe. To some extent a user can do this himself.That is, NTFS junctions and/or Cygwin symblinks can cause their to be identical pathswith identical meanings: e.g. for me, symlink /msdev => c:\msdev, /cm3 => c:\cm3 /dev => c:\dev2 In some places Cygwin open et. al. accept Win32 paths, but lately taking advantage ofthat issues a warning. In some places, I think, it isn't sufficient to have Cygwin handle it. The harder question then is, if I feed Cygwin paths of a particular form, should ittry to report back paths in the same form? I put some code in M3Path.m3 "like this", but it may not be advisable. I also had an NTFS junction on my system so Win32 /cygdrive/c => c:\, but this causesa circularity in the file system, which I'd rather not have. As well, there are at least three or four Posix runtimes for Windows, and they each mapdifferently. UWin I think uses /c <=> c:\.Cygwin /cygdrive <=> c:\Interix/ServicesForUnix/SUA I think something via /dev.MinGWin also has a runtime that I think uses the UWin mapping, but this runtime is onlymeant for sh/gcc to use, not user apps. Having special code that only knows the Cygwin convention is questionable. I was often setting up some environment variables one way or the other, and thenrunning one cm3 or the other, without thinking about which form the variables were in.Indeed, it might be nice to set CM3_ROOT and CM3_INSTALL "once and for all", while still switching between different forms of cm3.exe?Though granted, CM3_INSTALL cm3.exe can usually figure out from its own path, andCM3_ROOT could usually be figured out by looking at the CVS directories in the currentworking directory, not always, but often. Basically, instead of setting these variblesone way or the other, I'd like to set them always one way, or even not at all. Hm, in fact, I think cm3 could figure out all overrides itself? You know, if there is a shipped package store, it can use that to determine the source <=> pkg mapping. And it can figure out CM3_ROOT by looking at the current directory and on up until the CVS/Root changes? As well, you know, the source <=> pkg mapping could be a simple generated checked in file. You know, like the PKGS file, but stripped down to only what is needed? Maybe just remove the code I put in and forget the whole thing.Maybe most people only ever stay in one of the worlds and "translation" isn't important? Just me stuck with providing support for both and therefore living with both more? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Apr 22 03:44:17 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 21 Apr 2008 21:44:17 -0400 Subject: [M3devel] more path stuff, sorry In-Reply-To: References: Message-ID: Why would native NT386 know anything at all about Cygwin. I say just avoid split personalities like the plague. Similarly, I'd be happy for NT386GNU (i.e., Cygwin?) to simply behave like a POSIX build (modulo native threads perhaps). On Apr 21, 2008, at 7:15 PM, Jay wrote: > Maybe this is dubious. > > The question is, like, should native NT386 cm3 accept /cygdrive/c/ > foo and translate to c:\foo? > Or trickier, /usr/bin/foo and translate to c:\cygwin\usr\bin\foo? > And vice versa, should NT386GNU accept c:\foo? > > The translation is not simple in general. > / maps to the Cygwin install root. > There can be symlinks. > But many common cases can be handled with little, simple code. > It's already in. > > Ultimately the way to do this correctly is to link to cygwin1.dll, > which is only done sometimes, > and which probably license-undesirable when not done. > > As well, a path like /foo is actually ambiguous. > It is a valid native Win32 path, equivalent to \foo. > Or it could be Cygwin path requivalent to c:\cygwin\foo. > > While it is nice to keep cm3 simple, it is also nice to have a more > uniform interface > across hosts, I think. Maybe. > > To some extent a user can do this himself. > That is, NTFS junctions and/or Cygwin symblinks can cause their to > be identical paths > with identical meanings: > e.g. for me, symlink /msdev => c:\msdev, /cm3 => c:\cm3 /dev => c: > \dev2 > > In some places Cygwin open et. al. accept Win32 paths, but lately > taking advantage of > that issues a warning. In some places, I think, it isn't sufficient > to have Cygwin handle it. > > The harder question then is, if I feed Cygwin paths of a particular > form, should it > try to report back paths in the same form? > > I put some code in M3Path.m3 "like this", but it may not be advisable. > > I also had an NTFS junction on my system so Win32 /cygdrive/c => c: > \, but this causes > a circularity in the file system, which I'd rather not have. > > As well, there are at least three or four Posix runtimes for > Windows, and they each map > differently. > > UWin I think uses /c <=> c:\. > Cygwin /cygdrive <=> c:\ > Interix/ServicesForUnix/SUA I think something via /dev. > MinGWin also has a runtime that I think uses the UWin mapping, but > this runtime is only > meant for sh/gcc to use, not user apps. > > Having special code that only knows the Cygwin convention is > questionable. > > I was often setting up some environment variables one way or the > other, and then > running one cm3 or the other, without thinking about which form the > variables were in. > Indeed, it might be nice to set CM3_ROOT and CM3_INSTALL "once and > for all", > while still switching between different forms of cm3.exe? > Though granted, CM3_INSTALL cm3.exe can usually figure out from its > own path, and > CM3_ROOT could usually be figured out by looking at the CVS > directories in the current > working directory, not always, but often. Basically, instead of > setting these varibles > one way or the other, I'd like to set them always one way, or even > not at all. > > > Hm, in fact, I think cm3 could figure out all overrides itself? > You know, if there is a shipped package store, it can use that to > determine the source <=> pkg mapping. > And it can figure out CM3_ROOT by looking at the current directory > and on up until the CVS/Root > changes? > > As well, you know, the source <=> pkg mapping could be a simple > generated checked in file. > You know, like the PKGS file, but stripped down to only what is > needed? > > Maybe just remove the code I put in and forget the whole thing. > Maybe most people only ever stay in one of the worlds and > "translation" isn't important? > Just me stuck with providing support for both and therefore living > with both more? > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Apr 22 04:21:38 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 22 Apr 2008 02:21:38 +0000 Subject: [M3devel] more path stuff, sorry In-Reply-To: References: Message-ID: The split personality has to be somewhere -- either in the user of both or in the code. But maybe there are no users of both. :) Ok, they are it. I'll remove the code, and see how my experience fairs, and try to keep the results to myself. :) > Why would native NT386 know anything at all about Cygwin It depends on why someone choses the one cm3 or the other. If a user "likes Unix" but finds gcc too slow, he might be passing Cygwin paths to the native compiler. If a user "likes Windows" but really wants 64 bit integers right now, he might be inclined to pass Win32 paths to the Cygwin compiler. Granted, the second user could also use NT386MINGNU (__stdcall still broken, I should be able to fix or workaround.) As well, um, the first user could make up a configurationi that suites actually. That is, the choice of backend and the choice "what runtime cm3 uses" are two independent variables.I am answering my question though -- all four combinations should work, and three of them even have names. Mostly user doesn't care "what runtime in use", but user could easily care about the command lines accepted. And, you know, accepting different path forms..doesn't really require cygwin. If the inputs are human generated, he/she can probably live with c:/foo, or /c/foo and make a junction -- c:\c\foo => c:\foo. Oh that second one is a new idea to me actually. I should type that up -- "Windows paths for people that like forward slashes". Again, I know I'm a broken record, but it comes down to what someone wants in "NT386GNU". And the host and target are independently configurable, mostly, maybe -- NT386 can output NT386GNU and vice versa. User might like backward slashes but need to produce code that works in a more Posixish environment. This is like a cross build, except both targets run on the same OS. It probably just comes down what we have -- the two or three canned config files, and someone that wants to mix and match differently can do so. The toplevel NT386/NT386GNU/NT386MINGNU are small thin easily rewritten wrappers over NT386.common anyway. User can provide his own. At some hypothetical point, that will probably never arrive, config files should be tried out for Borland, Watcom, Digital Mars, and ideally, they follow this same pattern -- managing to get by with no compiler change and no new target, just a config file, possibly growing the jmpbuf to the largest of them, if that isn't too large. Actually the compiler doesn't do this correctly. I think it assumes the external backend targets one jumpbuf size and integrated one another. This should either be a dangerous integer directly set in the config file, or keyed off the "CRuntime" parameter there, values like MS, GNU, WATCOM, MWERKS, DMARS. It could be more configuration knobs make sense, since Windows compilers tend to have so many switches, the M3 compiler might have to know more stuff, to interoperate. Anyway..I'm skeptical these targets/configs would have any customers..on to other stuff for now. :) This reminds me of maybe a more important problem -- discerning host and target, I'll start a separate thread. - Jay CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] more path stuff, sorryDate: Mon, 21 Apr 2008 21:44:17 -0400 Why would native NT386 know anything at all about Cygwin. I say just avoid split personalities like the plague. Similarly, I'd be happy for NT386GNU (i.e., Cygwin?) to simply behave like a POSIX build (modulo native threads perhaps). On Apr 21, 2008, at 7:15 PM, Jay wrote: Maybe this is dubious.The question is, like, should native NT386 cm3 accept /cygdrive/c/foo and translate to c:\foo?Or trickier, /usr/bin/foo and translate to c:\cygwin\usr\bin\foo?And vice versa, should NT386GNU accept c:\foo?The translation is not simple in general./ maps to the Cygwin install root.There can be symlinks.But many common cases can be handled with little, simple code.It's already in.Ultimately the way to do this correctly is to link to cygwin1.dll, which is only done sometimes, and which probably license-undesirable when not done.As well, a path like /foo is actually ambiguous.It is a valid native Win32 path, equivalent to \foo.Or it could be Cygwin path requivalent to c:\cygwin\foo.While it is nice to keep cm3 simple, it is also nice to have a more uniform interfaceacross hosts, I think. Maybe.To some extent a user can do this himself.That is, NTFS junctions and/or Cygwin symblinks can cause their to be identical pathswith identical meanings:e.g. for me, symlink /msdev => c:\msdev, /cm3 => c:\cm3 /dev => c:\dev2In some places Cygwin open et. al. accept Win32 paths, but lately taking advantage ofthat issues a warning. In some places, I think, it isn't sufficient to have Cygwin handle it.The harder question then is, if I feed Cygwin paths of a particular form, should ittry to report back paths in the same form?I put some code in M3Path.m3 "like this", but it may not be advisable.I also had an NTFS junction on my system so Win32 /cygdrive/c => c:\, but this causesa circularity in the file system, which I'd rather not have.As well, there are at least three or four Posix runtimes for Windows, and they each mapdifferently.UWin I think uses /c <=> c:\.Cygwin /cygdrive <=> c:\Interix/ServicesForUnix/SUA I think something via /dev.MinGWin also has a runtime that I think uses the UWin mapping, but this runtime is onlymeant for sh/gcc to use, not user apps.Having special code that only knows the Cygwin convention is questionable. I was often setting up some environment variables one way or the other, and thenrunning one cm3 or the other, without thinking about which form the variables were in.Indeed, it might be nice to set CM3_ROOT and CM3_INSTALL "once and for all",while still switching between different forms of cm3.exe?Though granted, CM3_INSTALL cm3.exe can usually figure out from its own path, andCM3_ROOT could usually be figured out by looking at the CVS directories in the currentworking directory, not always, but often. Basically, instead of setting these variblesone way or the other, I'd like to set them always one way, or even not at all.Hm, in fact, I think cm3 could figure out all overrides itself?You know, if there is a shipped package store, it can use that to determine the source <=> pkg mapping.And it can figure out CM3_ROOT by looking at the current directory and on up until the CVS/Rootchanges? As well, you know, the source <=> pkg mapping could be a simple generated checked in file.You know, like the PKGS file, but stripped down to only what is needed? Maybe just remove the code I put in and forget the whole thing.Maybe most people only ever stay in one of the worlds and "translation" isn't important?Just me stuck with providing support for both and therefore living with both more? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Apr 22 04:36:42 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 22 Apr 2008 02:36:42 +0000 Subject: [M3devel] host vs. target and host_ostype exposed to quake? In-Reply-To: References: Message-ID: I found Compiler.i3 recently.I had been writing Quake code like: if equal ($OS, "Windows_NT") and: if equal (SL, "/") I propose that the data in Compiler.i3 be exposed to Quake with variable names something like: HOST -- ALPHA_OSF, NT386, LINUXLIBC6, AMD64_DARWIN, etc. HOST_OSTYPE -- POSIX, WIN32 /maybe/ booleans thereof: HOST_IS_POSIX HOST_IS_WIN32 and /possibly/ others: HOST_GNU_PLATFORM -- maybe needed, maybe not -- currently m3makefile maps from HOST, and the config files have unused declarations for the target. HOST_WORDSIZE -- shouldn't be relevant I /speculate/ as well that the following should be introduced: TARGET_ARCHITECTURE -- AMD64, I386, PPC (Compiler.i3 already separates this out) HOST_ARCHITECTURE TARGET_OS -- SOLARIS (SOL?), NT, DARWIN (MACOSX? Too late.), LINUX, OSF, VMS, HPUX, FREEBSD, OPENBSD, NETBSD (FBSD, OBSD, NBSD?) HOST_OS And then, /maybe/ ultimately, the full calculus I have described: TARGET_C_LIBRARY -- native, cygwin, ms (multiple versions?) TARGET_C_COMPILER -- gnu, sun, ms, dmars, mwerks, borland, watcom, darwin TARGET_C_LINKER -- similar to previous TARGET_WINDOW_LIBRARY -- xwin, mswin TARGET_THREAD_LIBRARY -- pthreads, alarmthreads, nt or at least just the very first two: HOST -- ALPHA_OSF, NT386, LINUXLIBC6, AMD64_DARWIN, etc. HOST_OSTYPE -- POSIX, WIN32 This is super easy, like two lines of code in m3quake to expose the data in Compiler.i3. Also, related, all the places that check Pathname.Join(a, b) == a/b or Epoch = 0, should use Compiler.OSType instead, or whatever it is. I'd have to check if Compiler.i3 puts anything in the .i3 vs. the .m3, if in the .m3, that could be slower, but easily fixed too. Oh, and maybe cm3 --print-var HOST. gcc has all those useful --print flags. Thus, all the uname stuff in sysinfo could go away, you just default to what the compiler runs on. You'd override it for cross builds with -D on the command line or a config file as usual (ie: the Quake variable would lose its read-onlyness, possibly taking on a new special form of "write-once"). One downside is that, as written, the config files are more readable and self-documenting by starting with the important settings up front. Whatever is buried in cm3 is more hidden from users, good and bad. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Tue Apr 22 05:09:39 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 21 Apr 2008 23:09:39 -0400 Subject: [M3devel] more path stuff, sorry In-Reply-To: References: Message-ID: <480D1EAD.1E75.00D7.1@scires.com> I think I've made my opinion on the path issue known, but just so there is no doubt, I do not want the underlying code trying to translate paths from one format to another. I think this is a recipe for problems since different OS represent paths and switches etc differently. Programmers should use the standard interfaces to construct paths appropriate for the current host operating system. Part of the beauty of Modula-3 is write once run everywhere. I have code that uses pathnames that runs on multiple platforms without the need to make any source code modifications. Regards, Randy >>> Jay 4/21/2008 7:15 PM >>> Maybe this is dubious. The question is, like, should native NT386 cm3 accept /cygdrive/c/foo and translate to c:\foo? Or trickier, /usr/bin/foo and translate to c:\cygwin\usr\bin\foo? And vice versa, should NT386GNU accept c:\foo? The translation is not simple in general. / maps to the Cygwin install root. There can be symlinks. But many common cases can be handled with little, simple code. It's already in. Ultimately the way to do this correctly is to link to cygwin1.dll, which is only done sometimes, and which probably license-undesirable when not done. As well, a path like /foo is actually ambiguous. It is a valid native Win32 path, equivalent to \foo. Or it could be Cygwin path requivalent to c:\cygwin\foo. While it is nice to keep cm3 simple, it is also nice to have a more uniform interface across hosts, I think. Maybe. To some extent a user can do this himself. That is, NTFS junctions and/or Cygwin symblinks can cause their to be identical paths with identical meanings: e.g. for me, symlink /msdev => c:\msdev, /cm3 => c:\cm3 /dev => c:\dev2 In some places Cygwin open et. al. accept Win32 paths, but lately taking advantage of that issues a warning. In some places, I think, it isn't sufficient to have Cygwin handle it. The harder question then is, if I feed Cygwin paths of a particular form, should it try to report back paths in the same form? I put some code in M3Path.m3 "like this", but it may not be advisable. I also had an NTFS junction on my system so Win32 /cygdrive/c => c:\, but this causes a circularity in the file system, which I'd rather not have. As well, there are at least three or four Posix runtimes for Windows, and they each map differently. UWin I think uses /c <=> c:\. Cygwin /cygdrive <=> c:\ Interix/ServicesForUnix/SUA I think something via /dev. MinGWin also has a runtime that I think uses the UWin mapping, but this runtime is only meant for sh/gcc to use, not user apps. Having special code that only knows the Cygwin convention is questionable. I was often setting up some environment variables one way or the other, and then running one cm3 or the other, without thinking about which form the variables were in. Indeed, it might be nice to set CM3_ROOT and CM3_INSTALL "once and for all", while still switching between different forms of cm3.exe? Though granted, CM3_INSTALL cm3.exe can usually figure out from its own path, and CM3_ROOT could usually be figured out by looking at the CVS directories in the current working directory, not always, but often. Basically, instead of setting these varibles one way or the other, I'd like to set them always one way, or even not at all. Hm, in fact, I think cm3 could figure out all overrides itself? You know, if there is a shipped package store, it can use that to determine the source <=> pkg mapping. And it can figure out CM3_ROOT by looking at the current directory and on up until the CVS/Root changes? As well, you know, the source <=> pkg mapping could be a simple generated checked in file. You know, like the PKGS file, but stripped down to only what is needed? Maybe just remove the code I put in and forget the whole thing. Maybe most people only ever stay in one of the worlds and "translation" isn't important? Just me stuck with providing support for both and therefore living with both more? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Tue Apr 22 05:14:00 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 21 Apr 2008 23:14:00 -0400 Subject: [M3devel] more path stuff, sorry In-Reply-To: References: Message-ID: <480D1FB2.1E75.00D7.1@scires.com> I concur wholeheartedly. I absolutely DO NOT want native NT386 to have any knowledge of or dependency on Cygwin. Regards, Randy >>> Tony Hosking 4/21/2008 9:44 PM >>> Why would native NT386 know anything at all about Cygwin. I say just avoid split personalities like the plague. Similarly, I'd be happy for NT386GNU (i.e., Cygwin?) to simply behave like a POSIX build (modulo native threads perhaps). On Apr 21, 2008, at 7:15 PM, Jay wrote: Maybe this is dubious. The question is, like, should native NT386 cm3 accept /cygdrive/c/foo and translate to c:\foo? Or trickier, /usr/bin/foo and translate to c:\cygwin\usr\bin\foo? And vice versa, should NT386GNU accept c:\foo? The translation is not simple in general. / maps to the Cygwin install root. There can be symlinks. But many common cases can be handled with little, simple code. It's already in. Ultimately the way to do this correctly is to link to cygwin1.dll, which is only done sometimes, and which probably license-undesirable when not done. As well, a path like /foo is actually ambiguous. It is a valid native Win32 path, equivalent to \foo. Or it could be Cygwin path requivalent to c:\cygwin\foo. While it is nice to keep cm3 simple, it is also nice to have a more uniform interface across hosts, I think. Maybe. To some extent a user can do this himself. That is, NTFS junctions and/or Cygwin symblinks can cause their to be identical paths with identical meanings: e.g. for me, symlink /msdev => c:\msdev, /cm3 => c:\cm3 /dev => c:\dev2 In some places Cygwin open et. al. accept Win32 paths, but lately taking advantage of that issues a warning. In some places, I think, it isn't sufficient to have Cygwin handle it. The harder question then is, if I feed Cygwin paths of a particular form, should it try to report back paths in the same form? I put some code in M3Path.m3 "like this", but it may not be advisable. I also had an NTFS junction on my system so Win32 /cygdrive/c => c:\, but this causes a circularity in the file system, which I'd rather not have. As well, there are at least three or four Posix runtimes for Windows, and they each map differently. UWin I think uses /c <=> c:\. Cygwin /cygdrive <=> c:\ Interix/ServicesForUnix/SUA I think something via /dev. MinGWin also has a runtime that I think uses the UWin mapping, but this runtime is only meant for sh/gcc to use, not user apps. Having special code that only knows the Cygwin convention is questionable. I was often setting up some environment variables one way or the other, and then running one cm3 or the other, without thinking about which form the variables were in. Indeed, it might be nice to set CM3_ROOT and CM3_INSTALL "once and for all", while still switching between different forms of cm3.exe? Though granted, CM3_INSTALL cm3.exe can usually figure out from its own path, and CM3_ROOT could usually be figured out by looking at the CVS directories in the current working directory, not always, but often. Basically, instead of setting these varibles one way or the other, I'd like to set them always one way, or even not at all. Hm, in fact, I think cm3 could figure out all overrides itself? You know, if there is a shipped package store, it can use that to determine the source <=> pkg mapping. And it can figure out CM3_ROOT by looking at the current directory and on up until the CVS/Root changes? As well, you know, the source <=> pkg mapping could be a simple generated checked in file. You know, like the PKGS file, but stripped down to only what is needed? Maybe just remove the code I put in and forget the whole thing. Maybe most people only ever stay in one of the worlds and "translation" isn't important? Just me stuck with providing support for both and therefore living with both more? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Apr 22 06:16:44 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 22 Apr 2008 04:16:44 +0000 Subject: [M3devel] more path stuff, sorry In-Reply-To: <480D1EAD.1E75.00D7.1@scires.com> References: <480D1EAD.1E75.00D7.1@scires.com> Message-ID: Randy we are kind of saying the same thing. Imagine if you will code out that that assumes all "full paths" start with a forward slash. There is surely a lot of this code. Imagine if you will code out there that assumes that all "full paths" start with either two slashes or a letter, colon, slash. There is a lot of this code too. (I think btw that Windows CE paths all start with one leading slash, and I suspect it must be a backward one, but I don't have a CE Phone yet, maybe soon, ARM_CE? :) ARM_WINCE?) Now imagine that this code is being used in some build automation and feeding the paths it forms to cm3. There is actually probably not much of this, but it is "reasonable". The idea then would be for such code to be "portable" to Posix and/or Win32, without having to adopt "some abstraction". You know...there's some tension in programming, between inventing abstractions and layers to bridge different underlying implementations, ahead of time or in all paths, vs. inserting new layers in some paths to make them "look like" preexisting paths. "Emulation layers" if you will. The advantage of "emulation" is that at least some variants run "native" and skip the "emulation". That is, like, survey the landscape of existing implementations, pick one that is reasonable and popular and easily emulated, write all your code to it, and add an emulation layer for the other cases. The trick of course is that it isn't always possible. Sometimes the job of the "abstraction layer" includes narrowing the underlying interfaces/feature set to the intersection, often refered to as "least common denominator". And then, some "abstraction layers" to "fix" this problem, let you "break through" to the underlying system. Such allowing of "break through" is obviously good and bad in multiple ways. The ability to break through takes away the ability of the layer to be stateful. Stateful layers are also to be avoided in the first place if performance is a concern. Now, in reality, paths are not a great example of this, because paths don't have all that many "features", so an abstraction boundary isn't likely to be lossy. Besides features, there issues of "capacity". For example, imagine I have a system that allows files larger than 4gig and a system that does not. Imagine the portability layer lets through file sizes larger than 4gig. While this enables the better system to have a larger capacity, it also enables a situation where users on one system can write files that users on another cannot read. Sometimes people suggest warnings for these kinds of things, like when you save a Word document in an older format and some formating may or may not be lost. Another problem with abstraction boundaries is you that you inevitably create yet another way of doing things, in the service of papering over that there is already more than one way. The cure is similar to the disease, sort of. You know, there is some set of programmers who can read XWindows code, some set that can read MSWindows, and the set that can read Trestle is bound to be less. Of course, this varies. Like, probably more people are familiar now with MFC, Qt, GTk than XOpenDisplay or CreateWindow. Sometimes the underlying systems are too hard to use, too unfeatureful and the layers built on them are not just for portability but also ease of use and sometimes add a bunch of value. In the end, I think I'll remove the code. But I'm not crazy. Portability can be served by catering to existing practises rather than inventing new ones. But granted it doesn't always work well. The Posix systems for Windows all seem to stink, and Wine seems to really stink. Btw, interesting point I think is how cm3cg manages to not care -- its input and output are always in the current working directory. It doesn't create any threads, no gui. While the "build system", sh, nmake, sed, awk, might have heavier requirements on their runtime (I don't know, haven't looked, not sure if Cygwin was for them or the larger goal), m3cg is light. Gcc is somewhere in between since it does look up paths "around the system" and run sub processes. But it still shouldn't be much OS dependent code, vs. all the work of parsing C, codegen, optimization. I must point out that the landscape is strewn with abstraction boundaries that work a lot and fail a lot. File systems are a huge example here. Some file systems allow files over 2 or 4 gig, some do not. Some perform at the much greater speed of nearby mechanically spinning disks, some at the usually slow rate of a network, some write at the very very slow speed of flash, some (flash) cannot stand too many writes. Some have readonly/hidden/system/etc. bits, some do not. Sometimes people stash the extra data in one form or another, sometimes it tends to get lost (Mac resource fork), sometimes now. I vaguely recall that Mac OSX implements hardlinks on HFS+ in a pretty convoluted way. File systems, thinking about paths, are also a big problem in terms of preservation of file names across file systems. At one extreme is MS-DOS 8.3 and some 14 character Unix systems. At another extreme is 255 character Unicode names. Files created one system cannot necessarily be moved to another. Yet the abstraction boundary to the file system, fopen, or whatever Modula-3 has, doesn't somehow deal with this. You know, you could do something whacky like put everything in a .zip file. But then you lose interoperability when the data would have been ok. Case sensitivity...how many folks think "Win32" is case sensitive and "Unix" is not? And yet, that is not how it works. It depends on the file system. How much code in the world is not prepared for symlinks or hard links? A lot. We muddle along. - Jay Date: Mon, 21 Apr 2008 23:09:39 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] more path stuff, sorry I think I've made my opinion on the path issue known, but just so there is no doubt, I do not want the underlying code trying to translate paths from one format to another. I think this is a recipe for problems since different OS represent paths and switches etc differently. Programmers should use the standard interfaces to construct paths appropriate for the current host operating system. Part of the beauty of Modula-3 is write once run everywhere. I have code that uses pathnames that runs on multiple platforms without the need to make any source code modifications. Regards, Randy>>> Jay 4/21/2008 7:15 PM >>>Maybe this is dubious.The question is, like, should native NT386 cm3 accept /cygdrive/c/foo and translate to c:\foo?Or trickier, /usr/bin/foo and translate to c:\cygwin\usr\bin\foo?And vice versa, should NT386GNU accept c:\foo?The translation is not simple in general./ maps to the Cygwin install root.There can be symlinks.But many common cases can be handled with little, simple code.It's already in.Ultimately the way to do this correctly is to link to cygwin1.dll, which is only done sometimes, and which probably license-undesirable when not done.As well, a path like /foo is actually ambiguous.It is a valid native Win32 path, equivalent to \foo.Or it could be Cygwin path requivalent to c:\cygwin\foo.While it is nice to keep cm3 simple, it is also nice to have a more uniform interfaceacross hosts, I think. Maybe.To some extent a user can do this himself.That is, NTFS junctions and/or Cygwin symblinks can cause their to be identical pathswith identical meanings:e.g. for me, symlink /msdev => c:\msdev, /cm3 => c:\cm3 /dev => c:\dev2In some places Cygwin open et. al. accept Win32 paths, but lately taking advantage ofthat issues a warning. In some places, I think, it isn't sufficient to have Cygwin handle it.The harder question then is, if I feed Cygwin paths of a particular form, should ittry to report back paths in the same form?I put some code in M3Path.m3 "like this", but it may not be advisable.I also had an NTFS junction on my system so Win32 /cygdrive/c => c:\, but this causesa circularity in the file system, which I'd rather not have.As well, there are at least three or four Posix runtimes for Windows, and they each mapdifferently.UWin I think uses /c <=> c:\.Cygwin /cygdrive <=> c:\Interix/ServicesForUnix/SUA I think something via /dev.MinGWin also has a runtime that I think uses the UWin mapping, but this runtime is onlymeant for sh/gcc to use, not user apps.Having special code that only knows the Cygwin convention is questionable. I was often setting up some environment variables one way or the other, and thenrunning one cm3 or the other, without thinking about which form the variables were in.Indeed, it might be nice to set CM3_ROOT and CM3_INSTALL "once and for all",while still switching between different forms of cm3.exe?Though granted, CM3_INSTALL cm3.exe can usually figure out from its own path, andCM3_ROOT could usually be figured out by looking at the CVS directories in the currentworking directory, not always, but often. Basically, instead of setting these variblesone way or the other, I'd like to set them always one way, or even not at all.Hm, in fact, I think cm3 could figure out all overrides itself?You know, if there is a shipped package store, it can use that to determine the source <=> pkg mapping.And it can figure out CM3_ROOT by looking at the current directory and on up until the CVS/Rootchanges? As well, you know, the source <=> pkg mapping could be a simple generated checked in file.You know, like the PKGS file, but stripped down to only what is needed? Maybe just remove the code I put in and forget the whole thing.Maybe most people only ever stay in one of the worlds and "translation" isn't important?Just me stuck with providing support for both and therefore living with both more? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Apr 22 06:19:52 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 22 Apr 2008 04:19:52 +0000 Subject: [M3devel] more path stuff, sorry In-Reply-To: <480D1FB2.1E75.00D7.1@scires.com> References: <480D1FB2.1E75.00D7.1@scires.com> Message-ID: There's no dependency, no linkage. Just a few simple string operations. I'll probably remove it tonight. Modula-3 has a split personality no matter what, in that it calls into very varying underlying layers, often trafficing in their specific data formats. It's just that it can strive to aid portability between them or not, by accepting either input and massaging it to work, vs. passing it along "unchanged" (well, that's not what happens actually). If there were no ambiguous cases and the Posix systems on Windows were consistent in their conventions, I'd be more for it. But the ambiguity and varying Posix conventions weaken the case tremendously. - Jay Date: Mon, 21 Apr 2008 23:14:00 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] more path stuff, sorry I concur wholeheartedly. I absolutely DO NOT want native NT386 to have any knowledge of or dependency on Cygwin. Regards, Randy>>> Tony Hosking 4/21/2008 9:44 PM >>> Why would native NT386 know anything at all about Cygwin. I say just avoid split personalities like the plague. Similarly, I'd be happy for NT386GNU (i.e., Cygwin?) to simply behave like a POSIX build (modulo native threads perhaps). On Apr 21, 2008, at 7:15 PM, Jay wrote: Maybe this is dubious.The question is, like, should native NT386 cm3 accept /cygdrive/c/foo and translate to c:\foo?Or trickier, /usr/bin/foo and translate to c:\cygwin\usr\bin\foo?And vice versa, should NT386GNU accept c:\foo?The translation is not simple in general./ maps to the Cygwin install root.There can be symlinks.But many common cases can be handled with little, simple code.It's already in.Ultimately the way to do this correctly is to link to cygwin1.dll, which is only done sometimes, and which probably license-undesirable when not done.As well, a path like /foo is actually ambiguous.It is a valid native Win32 path, equivalent to \foo.Or it could be Cygwin path requivalent to c:\cygwin\foo.While it is nice to keep cm3 simple, it is also nice to have a more uniform interfaceacross hosts, I think. Maybe.To some extent a user can do this himself.That is, NTFS junctions and/or Cygwin symblinks can cause their to be identical pathswith identical meanings:e.g. for me, symlink /msdev => c:\msdev, /cm3 => c:\cm3 /dev => c:\dev2In some places Cygwin open et. al. accept Win32 paths, but lately taking advantage ofthat issues a warning. In some places, I think, it isn't sufficient to have Cygwin handle it.The harder question then is, if I feed Cygwin paths of a particular form, should ittry to report back paths in the same form?I put some code in M3Path.m3 "like this", but it may not be advisable.I also had an NTFS junction on my system so Win32 /cygdrive/c => c:\, but this causesa circularity in the file system, which I'd rather not have.As well, there are at least three or four Posix runtimes for Windows, and they each mapdifferently.UWin I think uses /c <=> c:\.Cygwin /cygdrive <=> c:\Interix/ServicesForUnix/SUA I think something via /dev.MinGWin also has a runtime that I think uses the UWin mapping, but this runtime is onlymeant for sh/gcc to use, not user apps.Having special code that only knows the Cygwin convention is questionable. I was often setting up some environment variables one way or the other, and thenrunning one cm3 or the other, without thinking about which form the variables were in.Indeed, it might be nice to set CM3_ROOT and CM3_INSTALL "once and for all",while still switching between different forms of cm3.exe?Though granted, CM3_INSTALL cm3.exe can usually figure out from its own path, andCM3_ROOT could usually be figured out by looking at the CVS directories in the currentworking directory, not always, but often. Basically, instead of setting these variblesone way or the other, I'd like to set them always one way, or even not at all.Hm, in fact, I think cm3 could figure out all overrides itself?You know, if there is a shipped package store, it can use that to determine the source <=> pkg mapping.And it can figure out CM3_ROOT by looking at the current directory and on up until the CVS/Rootchanges? As well, you know, the source <=> pkg mapping could be a simple generated checked in file.You know, like the PKGS file, but stripped down to only what is needed? Maybe just remove the code I put in and forget the whole thing.Maybe most people only ever stay in one of the worlds and "translation" isn't important?Just me stuck with providing support for both and therefore living with both more? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Apr 22 06:28:23 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 22 Apr 2008 04:28:23 +0000 Subject: [M3devel] FW: more path stuff, sorry In-Reply-To: <480D1FB2.1E75.00D7.1@scires.com> References: <480D1FB2.1E75.00D7.1@scires.com> Message-ID: [truncated]... From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] more path stuff, sorryDate: Tue, 22 Apr 2008 04:19:52 +0000 There's no dependency, no linkage. Just a few simple string operations.I'll probably remove it tonight. Modula-3 has a split personality no matter what, in that it calls into very varying underlying layers, often trafficing in their specific data formats.It's just that it can strive to aid portability between them or not, by accepting either input and massaging it to work, vs. passing it along "unchanged" (well, that's not what happens actually). If there were no ambiguous cases and the Posix systems on Windows were consistent in their conventions, I'd be more for it. But the ambiguity and varying Posix conventions weaken the case tremendously. - Jay Date: Mon, 21 Apr 2008 23:14:00 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] more path stuff, sorry I concur wholeheartedly. I absolutely DO NOT want native NT386 to have any knowledge of or dependency on Cygwin. Regards, Randy>>> Tony Hosking 4/21/2008 9:44 PM >>> Why would native NT386 know anything at all about Cygwin. I say just avoid split personalities like the plague. Similarly, I'd be happy for NT386GNU (i.e., Cygwin?) to simply behave like a POSIX build (modulo native threads perhaps). On Apr 21, 2008, at 7:15 PM, Jay wrote: Maybe this is dubious.The question is, like, should native NT386 cm3 accept /cygdrive/c/foo and translate to c:\foo?Or trickier, /usr/bin/foo and translate to c:\cygwin\usr\bin\foo?And vice versa, should NT386GNU accept c:\foo?... -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Apr 22 14:29:09 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 22 Apr 2008 08:29:09 -0400 Subject: [M3devel] FW: more path stuff, sorry In-Reply-To: References: <480D1FB2.1E75.00D7.1@scires.com> Message-ID: <08DD9502-27D3-4C5C-9E30-A9E9D2CADAB4@cs.purdue.edu> Jay, there is an underlying principle here that you seem to be missing so I will make it explicit. Cross-product systems tend to acquire unmanageable complexity, especially when it comes to testing. By making each target one personality we are able to test machine- dependent code in isolation from machine-independent code. Often, when something breaks on one target I will test on another just to isolate the problem. This is a very powerful approach and I am very leery of destroying any ability to do this -- it allows us to maintain the high-level portability of most Modula-3 code while isolating the small fraction of machine-/target-dependent stuff. On Apr 22, 2008, at 12:28 AM, Jay wrote: > [truncated]... > > > > > From: jayk123 at hotmail.com > To: rcoleburn at scires.com; m3devel at elegosoft.com > Subject: RE: [M3devel] more path stuff, sorry > Date: Tue, 22 Apr 2008 04:19:52 +0000 > > There's no dependency, no linkage. Just a few simple string > operations. > I'll probably remove it tonight. > > Modula-3 has a split personality no matter what, in that it calls > into very varying underlying layers, often trafficing in their > specific data formats. > It's just that it can strive to aid portability between them or not, > by accepting either input and massaging it to work, vs. passing it > along "unchanged" (well, that's not what happens actually). If there > were no ambiguous cases and the Posix systems on Windows were > consistent in their conventions, I'd be more for it. But the > ambiguity and varying Posix conventions weaken the case tremendously. > > - Jay > > Date: Mon, 21 Apr 2008 23:14:00 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] more path stuff, sorry > > I concur wholeheartedly. I absolutely DO NOT want native NT386 to > have any knowledge of or dependency on Cygwin. > Regards, > Randy > > >>> Tony Hosking 4/21/2008 9:44 PM >>> > Why would native NT386 know anything at all about Cygwin. I say > just avoid split personalities like the plague. Similarly, I'd be > happy for NT386GNU (i.e., Cygwin?) to simply behave like a POSIX > build (modulo native threads perhaps). > > On Apr 21, 2008, at 7:15 PM, Jay wrote: > > Maybe this is dubious. > > The question is, like, should native NT386 cm3 accept /cygdrive/c/ > foo and translate to c:\foo? > Or trickier, /usr/bin/foo and translate to c:\cygwin\usr\bin\foo? > And vice versa, should NT386GNU accept c:\foo? > > ... -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Apr 22 14:52:05 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 22 Apr 2008 12:52:05 +0000 Subject: [M3devel] type mismatches? Message-ID: 4797 NEXT Fatal Error: bad version stamps: SocketPosix.m3 4798 4799 version stamp mismatch: Compiler.Platform 4800 => SocketPosix.m3 4801 => Compiler.i3 4802 version stamp mismatch: Compiler.ThisPlatform 4803 => SocketPosix.m3 4804 => Compiler.i3 This is now in the Tinderbox, on some machines, e.g. FreeBSD4. I have two source trees on same machine sharing same install root, one sees it, one does not. Even though I start the install root out by extracting the same initial snapshot, I think. I think they are the same except for path but that needs scrutiny. I am making SOME attempt to isolate it, but I'm not looking forward to it.. One expensive potshot is wait for a full hours-long gcc build with no switches. In case it is a cm3cg problem, emanating from the compiler used to build cm3cg. (I just did another build of cm3cg, took 11 minutes..) That is: There is a problem here. It's not just me. I MIGHT find it. If anyone can save me the trouble, please do. :) Other potshots include more conservative codegen like -fno-reorder-blocks -mno-double-align -O0, some/all of which are already in use. I was going to commit blindly such conservatism for FreeBSD4, however my local repro is persisting despite this. It could still be some simple bootstrapping issue. I don't know. SocketPosix is only using Compiler for some dormant platforms. The code is probably dead. But hey, extra dead code finds extra live bugs. :) Question: Am I correct that, in the absence of cm3/cm3cg/underlying bugs, the following should never occur: cd .../m3core rm -rf cm3 cm3 -ship cd ../libm3 rm -rf cm3 => version stamp mismatch ? That is -- if this happens, it can't be any bootstrapping problem? These checks are libm3 vs. m3core, right? What the compiler itself is? - Jay From hosking at cs.purdue.edu Tue Apr 22 19:02:47 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 22 Apr 2008 13:02:47 -0400 Subject: [M3devel] type mismatches? In-Reply-To: References: Message-ID: This happens whenever you add a new target to the compiler. You need to bootstrap a new compiler with the old libraries (m3core, libm3) before trying to build the new libraries containing the new Compiler.tmpl. On Apr 22, 2008, at 8:52 AM, Jay wrote: > > 4797 NEXT Fatal Error: bad version stamps: SocketPosix.m3 > 4798 > 4799 version stamp mismatch: Compiler.Platform > 4800 => SocketPosix.m3 > 4801 => Compiler.i3 > 4802 version stamp mismatch: Compiler.ThisPlatform > 4803 => SocketPosix.m3 > 4804 => Compiler.i3 > > This is now in the Tinderbox, on some machines, e.g. FreeBSD4. > I have two source trees on same machine sharing same install root, > one sees it, one does not. > Even though I start the install root out by extracting the same > initial snapshot, I think. > I think they are the same except for path but that needs scrutiny. > > I am making SOME attempt to isolate it, but I'm not looking forward > to it.. > One expensive potshot is wait for a full hours-long gcc build with > no switches. > In case it is a cm3cg problem, emanating from the compiler used to > build cm3cg. > (I just did another build of cm3cg, took 11 minutes..) > > That is: > There is a problem here. It's not just me. I MIGHT find it. > If anyone can save me the trouble, please do. :) > > Other potshots include more conservative codegen like -fno-reorder- > blocks -mno-double-align -O0, some/all of which are already in use. > I was going to commit blindly such conservatism for FreeBSD4, > however my local repro is persisting despite this. > > It could still be some simple bootstrapping issue. I don't know. > > SocketPosix is only using Compiler for some dormant platforms. The > code is probably dead. > But hey, extra dead code finds extra live bugs. :) > > Question: > Am I correct that, in the absence of cm3/cm3cg/underlying bugs, the > following should never occur: > cd .../m3core > rm -rf > cm3 > cm3 -ship > cd ../libm3 > rm -rf > cm3 > => version stamp mismatch > > ? That is -- if this happens, it can't be any bootstrapping problem? > These checks are libm3 vs. m3core, right? What the compiler itself is? > > - Jay From jayk123 at hotmail.com Tue Apr 22 20:31:53 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 22 Apr 2008 18:31:53 +0000 Subject: [M3devel] type mismatches? In-Reply-To: References: Message-ID: Tony, I thought I understood, I thought the automation handled this, both that I run and that the Tinderbox runs, such that one would never see this. I'll poke around a bit more. Oh, I think I see now. m3front/src/builtInfo/InfoModule.m3 This will happen also if you only change one side. Could be I had that edit on my machine. Still not sure about the Tinderbox but I'll wait and see. Thanks, - Jay > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jayk123 at hotmail.com > Subject: Re: [M3devel] type mismatches? > Date: Tue, 22 Apr 2008 13:02:47 -0400 > > This happens whenever you add a new target to the compiler. You need > to bootstrap a new compiler with the old libraries (m3core, libm3) > before trying to build the new libraries containing the new > Compiler.tmpl. > > On Apr 22, 2008, at 8:52 AM, Jay wrote: > > > > > 4797 NEXT Fatal Error: bad version stamps: SocketPosix.m3 > > 4798 > > 4799 version stamp mismatch: Compiler.Platform > > 4800 => SocketPosix.m3 > > 4801 => Compiler.i3 > > 4802 version stamp mismatch: Compiler.ThisPlatform > > 4803 => SocketPosix.m3 > > 4804 => Compiler.i3 > > > > This is now in the Tinderbox, on some machines, e.g. FreeBSD4. > > I have two source trees on same machine sharing same install root, > > one sees it, one does not. > > Even though I start the install root out by extracting the same > > initial snapshot, I think. > > I think they are the same except for path but that needs scrutiny. > > > > I am making SOME attempt to isolate it, but I'm not looking forward > > to it.. > > One expensive potshot is wait for a full hours-long gcc build with > > no switches. > > In case it is a cm3cg problem, emanating from the compiler used to > > build cm3cg. > > (I just did another build of cm3cg, took 11 minutes..) > > > > That is: > > There is a problem here. It's not just me. I MIGHT find it. > > If anyone can save me the trouble, please do. :) > > > > Other potshots include more conservative codegen like -fno-reorder- > > blocks -mno-double-align -O0, some/all of which are already in use. > > I was going to commit blindly such conservatism for FreeBSD4, > > however my local repro is persisting despite this. > > > > It could still be some simple bootstrapping issue. I don't know. > > > > SocketPosix is only using Compiler for some dormant platforms. The > > code is probably dead. > > But hey, extra dead code finds extra live bugs. :) > > > > Question: > > Am I correct that, in the absence of cm3/cm3cg/underlying bugs, the > > following should never occur: > > cd .../m3core > > rm -rf > > cm3 > > cm3 -ship > > cd ../libm3 > > rm -rf > > cm3 > > => version stamp mismatch > > > > ? That is -- if this happens, it can't be any bootstrapping problem? > > These checks are libm3 vs. m3core, right? What the compiler itself is? > > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Wed Apr 23 06:00:43 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 23 Apr 2008 06:00:43 +0200 (CEST) Subject: [M3devel] FW: more path stuff, sorry In-Reply-To: <08DD9502-27D3-4C5C-9E30-A9E9D2CADAB4@cs.purdue.edu> Message-ID: <135722.70767.qm@web27113.mail.ukl.yahoo.com> Hi all: Does pm3 treat NT386GNU paths as POSIX class? I think if one take the definition the Interface Pathname, NT386GNU target should not have access directly to use POSIX paths but Win32 ones because of: "A Pathname.T (or just a pathname) is a text conforming to the syntax of the underlying operating system" in http://www.opencm3.net/doc/help/gen_html/libm3/src/os/Common/Pathname.i3.html But if we think in "the underlying operating system" as the cygwin api, it should be the natural POSIX paths. I agree Pathname is a common interface, but what happens with that sense of portability we want? Maybe the answer is in the cygwin api; the non-standard functions of converting one style to the other: http://cygwin.com/cygwin-api/cygwin-functions.html . See http://www.cygwin.com/cygwin-ug-net/using.html#using-pathnames for the main notes of compatibility. It seems clear that cygwin can use both kind of path styles, so it's not a problem to use just one of POSIX or Win32 paths. So defining a Pathname of type POSIX style for NT386GNU, it is not resign to the more capable functions of cygwin? I mean if Pathname accept both kind of forward and back slashes in different Pathnames it should be defined a new kind of Pathname syntax. Oh I remember saw the mix of both kind of slashes in pm3 quake/config files of NT386GNU :) Is this really confusing or unthinkable? I think this is clear for some of yous (NT386GNU should just accept POSIX paths, not even a Win32 one, and obviously not a mix of the two syntax in a same path), but it is not for me. In my opinion both styles should be acceptable without defining a new kind of path syntax, and convert only using the cygwin api functions. For instance when using netbios resources but also trying to mount disks partitions on the cygwin mount table file we need both kind of syntax. Is that even logical? Thanks in advance. Tony Hosking escribi?: Jay, there is an underlying principle here that you seem to be missing so I will make it explicit. Cross-product systems tend to acquire unmanageable complexity, especially when it comes to testing. By making each target one personality we are able to test machine-dependent code in isolation from machine-independent code. Often, when something breaks on one target I will test on another just to isolate the problem. This is a very powerful approach and I am very leery of destroying any ability to do this -- it allows us to maintain the high-level portability of most Modula-3 code while isolating the small fraction of machine-/target-dependent stuff. On Apr 22, 2008, at 12:28 AM, Jay wrote: [truncated]... --------------------------------- From: jayk123 at hotmail.com To: rcoleburn at scires.com; m3devel at elegosoft.com Subject: RE: [M3devel] more path stuff, sorry Date: Tue, 22 Apr 2008 04:19:52 +0000 There's no dependency, no linkage. Just a few simple string operations. I'll probably remove it tonight. Modula-3 has a split personality no matter what, in that it calls into very varying underlying layers, often trafficing in their specific data formats. It's just that it can strive to aid portability between them or not, by accepting either input and massaging it to work, vs. passing it along "unchanged" (well, that's not what happens actually). If there were no ambiguous cases and the Posix systems on Windows were consistent in their conventions, I'd be more for it. But the ambiguity and varying Posix conventions weaken the case tremendously. - Jay --------------------------------- Date: Mon, 21 Apr 2008 23:14:00 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] more path stuff, sorry I concur wholeheartedly. I absolutely DO NOT want native NT386 to have any knowledge of or dependency on Cygwin. Regards, Randy >>> Tony Hosking 4/21/2008 9:44 PM >>> Why would native NT386 know anything at all about Cygwin. I say just avoid split personalities like the plague. Similarly, I'd be happy for NT386GNU (i.e., Cygwin?) to simply behave like a POSIX build (modulo native threads perhaps). On Apr 21, 2008, at 7:15 PM, Jay wrote: Maybe this is dubious. The question is, like, should native NT386 cm3 accept /cygdrive/c/foo and translate to c:\foo? Or trickier, /usr/bin/foo and translate to c:\cygwin\usr\bin\foo? And vice versa, should NT386GNU accept c:\foo? ... --------------------------------- Enviado desde Correo Yahoo! La bandeja de entrada m?s inteligente. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Apr 23 06:44:23 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Apr 2008 04:44:23 +0000 Subject: [M3devel] FW: more path stuff, sorry In-Reply-To: <135722.70767.qm@web27113.mail.ukl.yahoo.com> References: <08DD9502-27D3-4C5C-9E30-A9E9D2CADAB4@cs.purdue.edu> <135722.70767.qm@web27113.mail.ukl.yahoo.com> Message-ID: Daniel, this should address SOME but not necessarily all of your concern and questions: The underlying libraries are mostly Cygwin. Underlying THEM is another library, but the way it works, there is approximately zero "break through". Except for threads. Also, I intend, somehow, to expose FilePosix.T and FileWin32.T, besides the regular File.T. This would be part of enabling the serial package to build, using strictly "break through" and the Win32 code. However FilePosix.m3 and FileWin32.m3 both reveal File.T. I need to split the revelation out into a separate interface/module I think, shouldn't be hard. >From SOME point of view, forward slashes are perfectly acceptable in Win32 paths and have the same meaning as backward slashs. It is not 100%, but largely. This isn't Modula-3 code doing any "translation" but the Modula-3 does treat \ and / equivalent upon read. The lowest level Win32 File functions in kernel32.dll -- CreateFile, DeleteFile, MoveFile, CreateDirectory, RemoveDirectory, CopyFile, GetCurrentDirectory, SetCurrentDirectory, GetFileAttributes[Ex], FindFirst[Next]File[Ex], what else am I forgetting? Maybe CreateProcess? GetFullPathName, GetShortPathName, usually consider \ and / the same. Unless the paths starts \\?. The / are all converted to \ before getting to the underlying system, the NtCreateFile, where strictly \ is the separator and there is no working directory. If a path starts \\?, it is passed on directly. You don't have to pass full paths. You can pass a handle to a parent directory. Now, I recently read, regarding NTFS-3G for Linux, about allowing : and \ in file names. The claim is that if you install SFU (Services For Unix, previously Interix, now SUA), you can access such names on NT. I tried it out. In fact this claim seems wrong. I create those paths, and then enumerated and printed from Win32. Their lower 8 bits were : and \. But their upper 8 bits were 0xF0 or 0xFF or somesuch. SFU has some ability to access unicode file names, but not that I could find that would reveal this trickery. In particular, there is like wcs_opendir that opens a directory with a unicode path, but there is only the asii/ansi/utf8/7bit/8bit/whatever readdir/readdir_r. So the 0xF000 cannot show through. And proper unicode Win32 code still doesn't see ':' or '\' per se in file names (in paths, but not individual names). I think I happened to accidentally copy this stuff to a Linux machine, and they didn't come across as ':' or '\'. Maybe I used wine cmd copy though. I should try with NTFS-3G. I do suspect I'll get ':' and '\'. Speaking of portability -- should Modula-3 on Posix systems allow file names with ':' and '\'? There are pluses and minuses. It's a rhetorical question -- in that, I don't really want to discuss it that much. I don't think there's a good answer, so I'd just as soon leave the code alone vs. trying in vain to come up with what is "correct". Yes there are Cygwin specific functions for converting paths. It would be reasonable for some NT386GNU-specific paths to use them. You can write up the *.i3 files and call them where you deem appropriate. Where deemed appropriate is not clear. It would not be great for the NT386 tools to use them -- to link to cygwin1.dll, for any reason. Maybe via LoadLibrary/GetProcAddress -- an optional dependency. Maybe. I believe "linkage" should mean "static linkage in the same file" and not "dynamic linkage in the same process" but it isn't up to me and it very well might be this way. I think the Linux kernel grants an exception, but I'm skeptical that non-GPL code doesn't dynamically link to in-proc GPL code that hasn't granted an exception. Anyway, Modula-3 except for NT386GNU is not in any uniquely worrying boat, for sure. You see, like my little speech about emulation layers and "break though", Cygwin is an emulation layer. But its users may or may not consider it to have much "break through". It's users might be very accustomed to Posix paths and a full set of Posix-path-using tools, and have no need to give any of them a Win32 path, and if they do, might be prepared to stop and think about it and do their own conversion. I think it's gray, because gcc as a compiler is arguably way more valuable than a Posix porting layer for other code. Or really, they are both useful. Some people will want one, or the other, or both, or neither. And again I am confusing Cygwin, NT386GNU, and the backend vs. the runtime. You can very well combine the integrated backend with a Posixish runtime -- remember all the systems now have the integrated backend, you should be able to output NT386 .obj files on any platform just by saying TARGET= "NT386" in cm3.cfg. And you can combine the gcc backend with a Win32 runtime -- that is what NT386MINGNU is. Also, while kernel32.dll treats / like \, other Win32 functions/libraries do not, such as comdlg32.dll (File.Open, File.Save), and shlwapi.dll, I think. You'd have to read the docs and/or experiment. Win32 has a lot of nice internal consistencies, but it isn't 100% consistent. Probably nothing is. A mix of slashes works fine on NT386. Does some of this make sense? Again again again, "NT386GNU" is different things to different people, and some of them are in fact independent and you can pick and chose which parts you compose. There is the runtime the compiler uses. There is the backend. There is the library the output uses, both the "C library" (fopen), the threading library (pthreads vs. Win32), the windowing library (X Windows vs. Win32), the naming conventions (libfoo.a vs. foo.lib). Nearly every one of these factors is independent of the others, The config files are written as such and you should be able to experiment and make your own other combinations. Three such combinations are provided, and there's sort of a tendency for the host and the target to be the same, but they don't have to be. There are other factors, like which C compiler do you use, which linker. The compiler, backend, and linker conspire to determine which debugger you can use. If you se the integrated backend and MS linker, you can use MS debuggers. If you use the gcc backend and GNU linker, you can use gdb. Oh, well you can always use either debugger, but the point here is if you have symbols or not. Currently there is some problem mixing the gcc backend with the MS linker and/or the integrated backend with the GNU linker. I think gcc backend with MS linker, and only sometimes the other. There is a symbol alway injected into the .o files that the GNU linker knows about but that the MS linker gives as unresolved. The MS linker has a different name for it, but I don't believe it is always injected by the integrated backend. This is the symbol that lets you point to the start of your image, it is __ImageBase in MS. It isn't used much. But for some reason gcc always generates references to it, and gives it a different name. Therefore some of the supposedly independent factors are not independent as they should be. For network paths, Cygwin allows //machine/server. Current Cygwin issues warnings when you use Win32 paths, and the warning says you can quash it by setting CYGWIN=nodospathwarning or somesuch. Does this make some sense? At some point maybe I'll put together distributions for other combinations. Oh, one more thing, the gcc backend can use __int64. I was feeling guilty about taking so long adding that to the integrated backend, thus I fast-forwarded and got NT386GNU to work. I should still go back and add it though. Also, currently the compiler assumes some linkage of these factors. It assumes OS_TYPE=POSIX means targeting Cygwin. Eh that's pretty much correct. At some point maybe UWin and SFU will be options, but not right now. The compiler's main concern is the jumpbuf size, which is much larger for Cygwin. You can to some extent maybe link NT386 and NT386GNU together, but this jumpbuf thing could really hurt in a hard to diagnose way. (Maybe it's safe due to setjmp vs. _setjmp?)? Sorry this is too long. As Olaf said, what I say might be very true and an accurate model, but it confuses everyone. People want very very few variables. Sorry I have to run, no proofreading this "masterpiece". - Jay Date: Wed, 23 Apr 2008 06:00:43 +0200From: dabenavidesd at yahoo.esTo: m3devel at elegosoft.comSubject: Re: [M3devel] FW: more path stuff, sorryHi all:Does pm3 treat NT386GNU paths as POSIX class? I think if one take the definition the Interface Pathname, NT386GNU target should not have access directly to use POSIX paths but Win32 ones because of:"A Pathname.T (or just a pathname) is a text conforming to the syntax of the underlying operating system" inhttp://www.opencm3.net/doc/help/gen_html/libm3/src/os/Common/Pathname.i3.htmlBut if we think in "the underlying operating system" as the cygwin api, it should be the natural POSIX paths.I agree Pathname is a common interface, but what happens with that sense of portability we want? Maybe the answer is in the cygwin api; the non-standard functions of converting one style to the other: http://cygwin.com/cygwin-api/cygwin-functions.html .See http://www.cygwin.com/cygwin-ug-net/using.html#using-pathnamesfor the main notes of compatibility. It seems clear that cygwin can use both kind of path styles, so it's not a problem to use just one of POSIX or Win32 paths. So defining a Pathname of type POSIX style for NT386GNU, it is not resign to the more capable functions of cygwin?I mean if Pathname accept both kind of forward and back slashes in different Pathnames it should be defined a new kind of Pathname syntax. Oh I remember saw the mix of both kind of slashes in pm3 quake/config files of NT386GNU :) Is this really confusing or unthinkable?I think this is clear for some of yous (NT386GNU should just accept POSIX paths, not even a Win32 one, and obviously not a mix of the two syntax in a same path), but it is not for me.In my opinion both styles should be acceptable without defining a new kind of path syntax, and convert only using the cygwin api functions. For instance when using netbios resources but also trying to mount disks partitions on the cygwin mount table file we need both kind of syntax. Is that even logical?Thanks in advance.Tony Hosking escribi?: Jay, there is an underlying principle here that you seem to be missing so I will make it explicit. Cross-product systems tend to acquire unmanageable complexity, especially when it comes to testing. By making each target one personality we are able to test machine-dependent code in isolation from machine-independent code. Often, when something breaks on one target I will test on another just to isolate the problem. This is a very powerful approach and I am very leery of destroying any ability to do this -- it allows us to maintain the high-level portability of most Modula-3 code while isolating the small fraction of machine-/target-dependent stuff. On Apr 22, 2008, at 12:28 AM, Jay wrote: [truncated]... From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] more path stuff, sorryDate: Tue, 22 Apr 2008 04:19:52 +0000There's no dependency, no linkage. Just a few simple string operations.I'll probably remove it tonight. Modula-3 has a split personality no matter what, in that it calls into very varying underlying layers, often trafficing in their specific data formats.It's just that it can strive to aid portability between them or not, by accepting either input and massaging it to work, vs. passing it along "unchanged" (well, that's not what happens actually). If there were no ambiguous cases and the Posix systems on Windows were consistent in their conventions, I'd be more for it. But the ambiguity and varying Posix conventions weaken the case tremendously. - Jay Date: Mon, 21 Apr 2008 23:14:00 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] more path stuff, sorry I concur wholeheartedly. I absolutely DO NOT want native NT386 to have any knowledge of or dependency on Cygwin. Regards, Randy>>> Tony Hosking 4/21/2008 9:44 PM >>> Why would native NT386 know anything at all about Cygwin. I say just avoid split personalities like the plague. Similarly, I'd be happy for NT386GNU (i.e., Cygwin?) to simply behave like a POSIX build (modulo native threads perhaps). On Apr 21, 2008, at 7:15 PM, Jay wrote: Maybe this is dubious.The question is, like, should native NT386 cm3 accept /cygdrive/c/foo and translate to c:\foo?Or trickier, /usr/bin/foo and translate to c:\cygwin\usr\bin\foo?And vice versa, should NT386GNU accept c:\foo?... Enviado desde Correo Yahoo!La bandeja de entrada m?s inteligente. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Apr 23 06:59:51 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Apr 2008 04:59:51 +0000 Subject: [M3devel] FW: more path stuff, sorry In-Reply-To: <135722.70767.qm@web27113.mail.ukl.yahoo.com> References: <08DD9502-27D3-4C5C-9E30-A9E9D2CADAB4@cs.purdue.edu> <135722.70767.qm@web27113.mail.ukl.yahoo.com> Message-ID: I forgot some points.Daniel, in order to convert paths between the two, you need context to know what type the provider of the path intended. There are paths that are valid in both systems but that have different means. The path /usr/bin in Win32 is the same as \usr\bin and on the drive of the current working directory (the working, if you will)The path /usr/bin in Cygwin is \usr\bin under the Cygwin root, so often like c:\cygwin\usr\bin. The path /cygdrive/c/foo is also valid in Win32, and has a different meaning there than in Cygwin. Get it? The path c:/foo is unambiguous. The "string" c:/foo is ambiguous, depending on point of view. Let's say I want a string that contains colon delimited paths. Then this is the path c and the path /foo. But if paths themselves can have colons then it is also the single element list with the element c:/foo. You could get fancy shmancy and escape the colon c\:/foo but that's insane. Quoting is already a big problem in existing systems and usage, and I just made that garbage up. One of the points maybe the Modula-3 folks are alluding is that Pathname.T is a TYPE with an INTERFACE. It is not a "string". In many other systems a "path" is "just" a "string", it just gets pass around, and both sides party on it and hope they give it the same meaning. If your notion of type is not clear, between Win32 and Posix, then neither is the meaning. Strings are a terribly loose overused type.... This does save people from coming up with those fancy complicated difficult to learn INTERFACES, and it aids interoperability, since everyone can use a string...it's good and it's bad, the glass is half full and half empty... c:\ "looks" like a win32 path, but hey, be careful there, I'm just smiling big and wearing a crooked hat, you have interpreted it completely incorretly, eh? Types are important. I think much more so than modules. And /foo/ looks like a Posix path, but actually it's italicized text. :) Or then again, this whole email is a valid Posix path, newlines and all, since it has no embedded nuls. :) - Jay From: jayk123 at hotmail.comTo: dabenavidesd at yahoo.es; m3devel at elegosoft.comSubject: RE: [M3devel] FW: more path stuff, sorryDate: Wed, 23 Apr 2008 04:44:23 +0000 Daniel, this should address SOME but not necessarily all of your concern and questions: The underlying libraries are mostly Cygwin.Underlying THEM is another library, but the way it works, there is approximately zero "break through".Except for threads.Also, I intend, somehow, to expose FilePosix.T and FileWin32.T, besides the regular File.T.This would be part of enabling the serial package to build, using strictly "break through" and the Win32 code.However FilePosix.m3 and FileWin32.m3 both reveal File.T. I need to split the revelation out into a separate interface/module I think, shouldn't be hard. From SOME point of view, forward slashes are perfectly acceptable in Win32 paths and have the same meaning as backward slashs. It is not 100%, but largely. This isn't Modula-3 code doing any "translation" but the Modula-3 does treat \ and / equivalent upon read. The lowest level Win32 File functions in kernel32.dll -- CreateFile, DeleteFile, MoveFile, CreateDirectory, RemoveDirectory, CopyFile, GetCurrentDirectory, SetCurrentDirectory, GetFileAttributes[Ex], FindFirst[Next]File[Ex], what else am I forgetting? Maybe CreateProcess? GetFullPathName, GetShortPathName, usually consider \ and / the same. Unless the paths starts \\?. The / are all converted to \ before getting to the underlying system, the NtCreateFile, where strictly \ is the separator and there is no working directory. If a path starts \\?, it is passed on directly. You don't have to pass full paths. You can pass a handle to a parent directory. Now, I recently read, regarding NTFS-3G for Linux, about allowing : and \ in file names.The claim is that if you install SFU (Services For Unix, previously Interix, now SUA), you can access such names on NT.I tried it out. In fact this claim seems wrong. I create those paths, and then enumerated and printed from Win32. Their lower 8 bits were : and \. But their upper 8 bits were 0xF0 or 0xFF or somesuch. SFU has some ability to access unicode file names, but not that I could find that would reveal this trickery. In particular, there is like wcs_opendir that opens a directory with a unicode path, but there is only the asii/ansi/utf8/7bit/8bit/whatever readdir/readdir_r. So the 0xF000 cannot show through.And proper unicode Win32 code still doesn't see ':' or '\' per se in file names (in paths, but not individual names). I think I happened to accidentally copy this stuff to a Linux machine, and they didn't come across as ':' or '\'.Maybe I used wine cmd copy though. I should try with NTFS-3G. I do suspect I'll get ':' and '\'. Speaking of portability -- should Modula-3 on Posix systems allow file names with ':' and '\'? There are pluses and minuses. It's a rhetorical question -- in that, I don't really want to discuss it that much. I don't think there's a good answer, so I'd just as soon leave the code alone vs. trying in vain to come up with what is "correct". Yes there are Cygwin specific functions for converting paths.It would be reasonable for some NT386GNU-specific paths to use them.You can write up the *.i3 files and call them where you deem appropriate. Where deemed appropriate is not clear.It would not be great for the NT386 tools to use them -- to link to cygwin1.dll, for any reason.Maybe via LoadLibrary/GetProcAddress -- an optional dependency. Maybe.I believe "linkage" should mean "static linkage in the same file" and not "dynamic linkage in the same process" but it isn't up to me and it very well might be this way. I think the Linux kernel grants an exception, but I'm skeptical that non-GPL code doesn't dynamically link to in-proc GPL code that hasn't granted an exception. Anyway, Modula-3 except for NT386GNU is not in any uniquely worrying boat, for sure. You see, like my little speech about emulation layers and "break though", Cygwin is an emulation layer.But its users may or may not consider it to have much "break through".It's users might be very accustomed to Posix paths and a full set of Posix-path-using tools, and have no need to give any of them a Win32 path, and if they do, might be prepared to stop and think about it and do their own conversion. I think it's gray, because gcc as a compiler is arguably way more valuable than a Posix porting layer for other code.Or really, they are both useful. Some people will want one, or the other, or both, or neither. And again I am confusing Cygwin, NT386GNU, and the backend vs. the runtime. You can very well combine the integrated backend with a Posixish runtime -- remember all the systems now have the integrated backend, you should be able to output NT386 .obj files on any platform just by saying TARGET= "NT386" in cm3.cfg. And you can combine the gcc backend with a Win32 runtime -- that is what NT386MINGNU is. Also, while kernel32.dll treats / like \, other Win32 functions/libraries do not, such as comdlg32.dll (File.Open, File.Save), and shlwapi.dll, I think. You'd have to read the docs and/or experiment.Win32 has a lot of nice internal consistencies, but it isn't 100% consistent. Probably nothing is. A mix of slashes works fine on NT386. Does some of this make sense? Again again again, "NT386GNU" is different things to different people, and some of them are in fact independent and you can pick and chose which parts you compose. There is the runtime the compiler uses. There is the backend. There is the library the output uses, both the "C library" (fopen), the threading library (pthreads vs. Win32), the windowing library (X Windows vs. Win32), the naming conventions (libfoo.a vs. foo.lib). Nearly every one of these factors is independent of the others, The config files are written as such and you should be able to experiment and make your own other combinations. Three such combinations are provided, and there's sort of a tendency for the host and the target to be the same, but they don't have to be. There are other factors, like which C compiler do you use, which linker. The compiler, backend, and linker conspire to determine which debugger you can use. If you se the integrated backend and MS linker, you can use MS debuggers. If you use the gcc backend and GNU linker, you can use gdb. Oh, well you can always use either debugger, but the point here is if you have symbols or not. Currently there is some problem mixing the gcc backend with the MS linker and/or the integrated backend with the GNU linker. I think gcc backend with MS linker, and only sometimes the other. There is a symbol alway injected into the .o files that the GNU linker knows about but that the MS linker gives as unresolved. The MS linker has a different name for it, but I don't believe it is always injected by the integrated backend. This is the symbol that lets you point to the start of your image, it is __ImageBase in MS. It isn't used much. But for some reason gcc always generates references to it, and gives it a different name. Therefore some of the supposedly independent factors are not independent as they should be. For network paths, Cygwin allows //machine/server. Current Cygwin issues warnings when you use Win32 paths, and the warning says you can quash it by setting CYGWIN=nodospathwarning or somesuch. Does this make some sense? At some point maybe I'll put together distributions for other combinations. Oh, one more thing, the gcc backend can use __int64.I was feeling guilty about taking so long adding that to the integrated backend, thus I fast-forwarded and got NT386GNU to work. I should still go back and add it though. Also, currently the compiler assumes some linkage of these factors. It assumes OS_TYPE=POSIX means targeting Cygwin. Eh that's pretty much correct. At some point maybe UWin and SFU will be options, but not right now. The compiler's main concern is the jumpbuf size, which is much larger for Cygwin. You can to some extent maybe link NT386 and NT386GNU together, but this jumpbuf thing could really hurt in a hard to diagnose way. (Maybe it's safe due to setjmp vs. _setjmp?)? Sorry this is too long. As Olaf said, what I say might be very true and an accurate model, but it confuses everyone.People want very very few variables. Sorry I have to run, no proofreading this "masterpiece". - Jay Date: Wed, 23 Apr 2008 06:00:43 +0200From: dabenavidesd at yahoo.esTo: m3devel at elegosoft.comSubject: Re: [M3devel] FW: more path stuff, sorryHi all:Does pm3 treat NT386GNU paths as POSIX class? I think if one take the definition the Interface Pathname, NT386GNU target should not have access directly to use POSIX paths but Win32 ones because of:"A Pathname.T (or just a pathname) is a text conforming to the syntax of the underlying operating system" inhttp://www.opencm3.net/doc/help/gen_html/libm3/src/os/Common/Pathname.i3.htmlBut if we think in "the underlying operating system" as the cygwin api, it should be the natural POSIX paths.I agree Pathname is a common interface, but what happens with that sense of portability we want? Maybe the answer is in the cygwin api; the non-standard functions of converting one style to the other: http://cygwin.com/cygwin-api/cygwin-functions.html .See http://www.cygwin.com/cygwin-ug-net/using.html#using-pathnamesfor the main notes of compatibility. It seems clear that cygwin can use both kind of path styles, so it's not a problem to use just one of POSIX or Win32 paths. So defining a Pathname of type POSIX style for NT386GNU, it is not resign to the more capable functions of cygwin?I mean if Pathname accept both kind of forward and back slashes in different Pathnames it should be defined a new kind of Pathname syntax. Oh I remember saw the mix of both kind of slashes in pm3 quake/config files of NT386GNU :) Is this really confusing or unthinkable?I think this is clear for some of yous (NT386GNU should just accept POSIX paths, not even a Win32 one, and obviously not a mix of the two syntax in a same path), but it is not for me.In my opinion both styles should be acceptable without defining a new kind of path syntax, and convert only using the cygwin api functions. For instance when using netbios resources but also trying to mount disks partitions on the cygwin mount table file we need both kind of syntax. Is that even logical?Thanks in advance.Tony Hosking escribi?: Jay, there is an underlying principle here that you seem to be missing so I will make it explicit. Cross-product systems tend to acquire unmanageable complexity, especially when it comes to testing. By making each target one personality we are able to test machine-dependent code in isolation from machine-independent code. Often, when something breaks on one target I will test on another just to isolate the problem. This is a very powerful approach and I am very leery of destroying any ability to do this -- it allows us to maintain the high-level portability of most Modula-3 code while isolating the small fraction of machine-/target-dependent stuff. On Apr 22, 2008, at 12:28 AM, Jay wrote: [truncated]... From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] more path stuff, sorryDate: Tue, 22 Apr 2008 04:19:52 +0000There's no dependency, no linkage. Just a few simple string operations.I'll probably remove it tonight. Modula-3 has a split personality no matter what, in that it calls into very varying underlying layers, often trafficing in their specific data formats.It's just that it can strive to aid portability between them or not, by accepting either input and massaging it to work, vs. passing it along "unchanged" (well, that's not what happens actually). If there were no ambiguous cases and the Posix systems on Windows were consistent in their conventions, I'd be more for it. But the ambiguity and varying Posix conventions weaken the case tremendously. - Jay Date: Mon, 21 Apr 2008 23:14:00 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] more path stuff, sorry I concur wholeheartedly. I absolutely DO NOT want native NT386 to have any knowledge of or dependency on Cygwin. Regards, Randy>>> Tony Hosking 4/21/2008 9:44 PM >>> Why would native NT386 know anything at all about Cygwin. I say just avoid split personalities like the plague. Similarly, I'd be happy for NT386GNU (i.e., Cygwin?) to simply behave like a POSIX build (modulo native threads perhaps). On Apr 21, 2008, at 7:15 PM, Jay wrote: Maybe this is dubious.The question is, like, should native NT386 cm3 accept /cygdrive/c/foo and translate to c:\foo?Or trickier, /usr/bin/foo and translate to c:\cygwin\usr\bin\foo?And vice versa, should NT386GNU accept c:\foo?... Enviado desde Correo Yahoo!La bandeja de entrada m?s inteligente. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Apr 23 07:17:43 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Apr 2008 05:17:43 +0000 Subject: [M3devel] FW: more path stuff, sorry In-Reply-To: References: <08DD9502-27D3-4C5C-9E30-A9E9D2CADAB4@cs.purdue.edu> <135722.70767.qm@web27113.mail.ukl.yahoo.com> Message-ID: > Types are important. I think much more so than modules. But user input, esp. in the form of a command line, are ambiguous and not strongly typed, and therefore sometimes open to "sniffing", to loose interpretation, guessing what was intended. There IS a place for guessing, but not everywhere. For example maybe?: cp foo bar What does that do? Copy one file or a directory full of files? A really bad example, what does this command line do: c:\program files\microsoft visual studio\cl.exe Does it run "cl.exe" in the directory "c:\program files\microsoft visual studio". Or does it run the "program" in c:\ with parameters "files\microsoft", "visual", "studio\cl.exe"? I BELIEVE the answer is that it DEPENDS. Both can exist at the same time -- "c:\program" and "C:\program files" I BELIEVE if "c:\program" exists, it is run. I'm not sure. CreateProcess has two parameters here and so there is a way to disambiguate and execve is probably unambiguous, but system() is ambiguous and CreateProcess has an ambiguous mode since you don't have to use both parameters -- like path to .exe and command line, you can leave the first NULL, something like that it's considered poor practise. Command lines are awfully weakly typed. You know -- you need to hit those keys harder. :) Or watch this, sometimes you don't need spaces between command line parameters: D:\>dir cd foo => nothing D:\>mkdir foo D:\>cd\foo => changes into the foo directory. let's go back up: cd \ and now... enable running extensionless files: set PATHEXT=.;%PATHEXT% create one.. mkdir \cd copy %windir%\notepad.exe \cd\foo and..: cd\foo now cd\foo runs the copy of notepad. ambiguity abounds... - Jay From: jayk123 at hotmail.comTo: dabenavidesd at yahoo.es; m3devel at elegosoft.comDate: Wed, 23 Apr 2008 04:59:51 +0000Subject: Re: [M3devel] FW: more path stuff, sorry I forgot some points.Daniel, in order to convert paths between the two, you need context to know what type the provider of the path intended. There are paths that are valid in both systems but that have different means. The path /usr/bin in Win32 is the same as \usr\bin and on the drive of the current working directory (the working, if you will)The path /usr/bin in Cygwin is \usr\bin under the Cygwin root, so often like c:\cygwin\usr\bin. The path /cygdrive/c/foo is also valid in Win32, and has a different meaning there than in Cygwin. Get it? The path c:/foo is unambiguous. The "string" c:/foo is ambiguous, depending on point of view.Let's say I want a string that contains colon delimited paths.Then this is the path c and the path /foo.But if paths themselves can have colons then it is also the single element list with the element c:/foo. You could get fancy shmancy and escape the colon c\:/foo but that's insane.Quoting is already a big problem in existing systems and usage, and I just made that garbage up. One of the points maybe the Modula-3 folks are alluding is that Pathname.T is a TYPE with an INTERFACE. It is not a "string".In many other systems a "path" is "just" a "string", it just gets pass around, and both sides party on it and hope they give it the same meaning.If your notion of type is not clear, between Win32 and Posix, then neither is the meaning.Strings are a terribly loose overused type....This does save people from coming up with those fancy complicated difficult to learn INTERFACES, and it aids interoperability, since everyone can use a string...it's good and it's bad, the glass is half full and half empty... c:\ "looks" like a win32 path, but hey, be careful there, I'm just smiling big and wearing a crooked hat, you have interpreted it completely incorretly, eh? Types are important. I think much more so than modules. And /foo/ looks like a Posix path, but actually it's italicized text. :)Or then again, this whole email is a valid Posix path, newlines and all, since it has no embedded nuls. :) - Jay From: jayk123 at hotmail.comTo: dabenavidesd at yahoo.es; m3devel at elegosoft.comSubject: RE: [M3devel] FW: more path stuff, sorryDate: Wed, 23 Apr 2008 04:44:23 +0000 Daniel, this should address SOME but not necessarily all of your concern and questions: The underlying libraries are mostly Cygwin.Underlying THEM is another library, but the way it works, there is approximately zero "break through".Except for threads.Also, I intend, somehow, to expose FilePosix.T and FileWin32.T, besides the regular File.T.This would be part of enabling the serial package to build, using strictly "break through" and the Win32 code.However FilePosix.m3 and FileWin32.m3 both reveal File.T. I need to split the revelation out into a separate interface/module I think, shouldn't be hard. From SOME point of view, forward slashes are perfectly acceptable in Win32 paths and have the same meaning as backward slashs. It is not 100%, but largely. This isn't Modula-3 code doing any "translation" but the Modula-3 does treat \ and / equivalent upon read. The lowest level Win32 File functions in kernel32.dll -- CreateFile, DeleteFile, MoveFile, CreateDirectory, RemoveDirectory, CopyFile, GetCurrentDirectory, SetCurrentDirectory, GetFileAttributes[Ex], FindFirst[Next]File[Ex], what else am I forgetting? Maybe CreateProcess? GetFullPathName, GetShortPathName, usually consider \ and / the same. Unless the paths starts \\?. The / are all converted to \ before getting to the underlying system, the NtCreateFile, where strictly \ is the separator and there is no working directory. If a path starts \\?, it is passed on directly. You don't have to pass full paths. You can pass a handle to a parent directory. Now, I recently read, regarding NTFS-3G for Linux, about allowing : and \ in file names.The claim is that if you install SFU (Services For Unix, previously Interix, now SUA), you can access such names on NT.I tried it out. In fact this claim seems wrong. I create those paths, and then enumerated and printed from Win32. Their lower 8 bits were : and \. But their upper 8 bits were 0xF0 or 0xFF or somesuch. SFU has some ability to access unicode file names, but not that I could find that would reveal this trickery. In particular, there is like wcs_opendir that opens a directory with a unicode path, but there is only the asii/ansi/utf8/7bit/8bit/whatever readdir/readdir_r. So the 0xF000 cannot show through.And proper unicode Win32 code still doesn't see ':' or '\' per se in file names (in paths, but not individual names). I think I happened to accidentally copy this stuff to a Linux machine, and they didn't come across as ':' or '\'.Maybe I used wine cmd copy though. I should try with NTFS-3G. I do suspect I'll get ':' and '\'. Speaking of portability -- should Modula-3 on Posix systems allow file names with ':' and '\'? There are pluses and minuses. It's a rhetorical question -- in that, I don't really want to discuss it that much. I don't think there's a good answer, so I'd just as soon leave the code alone vs. trying in vain to come up with what is "correct". Yes there are Cygwin specific functions for converting paths.It would be reasonable for some NT386GNU-specific paths to use them.You can write up the *.i3 files and call them where you deem appropriate. Where deemed appropriate is not clear.It would not be great for the NT386 tools to use them -- to link to cygwin1.dll, for any reason.Maybe via LoadLibrary/GetProcAddress -- an optional dependency. Maybe.I believe "linkage" should mean "static linkage in the same file" and not "dynamic linkage in the same process" but it isn't up to me and it very well might be this way. I think the Linux kernel grants an exception, but I'm skeptical that non-GPL code doesn't dynamically link to in-proc GPL code that hasn't granted an exception. Anyway, Modula-3 except for NT386GNU is not in any uniquely worrying boat, for sure. You see, like my little speech about emulation layers and "break though", Cygwin is an emulation layer.But its users may or may not consider it to have much "break through".It's users might be very accustomed to Posix paths and a full set of Posix-path-using tools, and have no need to give any of them a Win32 path, and if they do, might be prepared to stop and think about it and do their own conversion. I think it's gray, because gcc as a compiler is arguably way more valuable than a Posix porting layer for other code.Or really, they are both useful. Some people will want one, or the other, or both, or neither. And again I am confusing Cygwin, NT386GNU, and the backend vs. the runtime. You can very well combine the integrated backend with a Posixish runtime -- remember all the systems now have the integrated backend, you should be able to output NT386 .obj files on any platform just by saying TARGET= "NT386" in cm3.cfg. And you can combine the gcc backend with a Win32 runtime -- that is what NT386MINGNU is. Also, while kernel32.dll treats / like \, other Win32 functions/libraries do not, such as comdlg32.dll (File.Open, File.Save), and shlwapi.dll, I think. You'd have to read the docs and/or experiment.Win32 has a lot of nice internal consistencies, but it isn't 100% consistent. Probably nothing is. A mix of slashes works fine on NT386. Does some of this make sense? Again again again, "NT386GNU" is different things to different people, and some of them are in fact independent and you can pick and chose which parts you compose. There is the runtime the compiler uses. There is the backend. There is the library the output uses, both the "C library" (fopen), the threading library (pthreads vs. Win32), the windowing library (X Windows vs. Win32), the naming conventions (libfoo.a vs. foo.lib). Nearly every one of these factors is independent of the others, The config files are written as such and you should be able to experiment and make your own other combinations. Three such combinations are provided, and there's sort of a tendency for the host and the target to be the same, but they don't have to be. There are other factors, like which C compiler do you use, which linker. The compiler, backend, and linker conspire to determine which debugger you can use. If you se the integrated backend and MS linker, you can use MS debuggers. If you use the gcc backend and GNU linker, you can use gdb. Oh, well you can always use either debugger, but the point here is if you have symbols or not. Currently there is some problem mixing the gcc backend with the MS linker and/or the integrated backend with the GNU linker. I think gcc backend with MS linker, and only sometimes the other. There is a symbol alway injected into the .o files that the GNU linker knows about but that the MS linker gives as unresolved. The MS linker has a different name for it, but I don't believe it is always injected by the integrated backend. This is the symbol that lets you point to the start of your image, it is __ImageBase in MS. It isn't used much. But for some reason gcc always generates references to it, and gives it a different name. Therefore some of the supposedly independent factors are not independent as they should be. For network paths, Cygwin allows //machine/server. Current Cygwin issues warnings when you use Win32 paths, and the warning says you can quash it by setting CYGWIN=nodospathwarning or somesuch. Does this make some sense? At some point maybe I'll put together distributions for other combinations. Oh, one more thing, the gcc backend can use __int64.I was feeling guilty about taking so long adding that to the integrated backend, thus I fast-forwarded and got NT386GNU to work. I should still go back and add it though. Also, currently the compiler assumes some linkage of these factors. It assumes OS_TYPE=POSIX means targeting Cygwin. Eh that's pretty much correct. At some point maybe UWin and SFU will be options, but not right now. The compiler's main concern is the jumpbuf size, which is much larger for Cygwin. You can to some extent maybe link NT386 and NT386GNU together, but this jumpbuf thing could really hurt in a hard to diagnose way. (Maybe it's safe due to setjmp vs. _setjmp?)? Sorry this is too long. As Olaf said, what I say might be very true and an accurate model, but it confuses everyone.People want very very few variables. Sorry I have to run, no proofreading this "masterpiece". - Jay Date: Wed, 23 Apr 2008 06:00:43 +0200From: dabenavidesd at yahoo.esTo: m3devel at elegosoft.comSubject: Re: [M3devel] FW: more path stuff, sorryHi all:Does pm3 treat NT386GNU paths as POSIX class? I think if one take the definition the Interface Pathname, NT386GNU target should not have access directly to use POSIX paths but Win32 ones because of:"A Pathname.T (or just a pathname) is a text conforming to the syntax of the underlying operating system" inhttp://www.opencm3.net/doc/help/gen_html/libm3/src/os/Common/Pathname.i3.htmlBut if we think in "the underlying operating system" as the cygwin api, it should be the natural POSIX paths.I agree Pathname is a common interface, but what happens with that sense of portability we want? Maybe the answer is in the cygwin api; the non-standard functions of converting one style to the other: http://cygwin.com/cygwin-api/cygwin-functions.html .See http://www.cygwin.com/cygwin-ug-net/using.html#using-pathnamesfor the main notes of compatibility. It seems clear that cygwin can use both kind of path styles, so it's not a problem to use just one of POSIX or Win32 paths. So defining a Pathname of type POSIX style for NT386GNU, it is not resign to the more capable functions of cygwin?I mean if Pathname accept both kind of forward and back slashes in different Pathnames it should be defined a new kind of Pathname syntax. Oh I remember saw the mix of both kind of slashes in pm3 quake/config files of NT386GNU :) Is this really confusing or unthinkable?I think this is clear for some of yous (NT386GNU should just accept POSIX paths, not even a Win32 one, and obviously not a mix of the two syntax in a same path), but it is not for me.In my opinion both styles should be acceptable without defining a new kind of path syntax, and convert only using the cygwin api functions. For instance when using netbios resources but also trying to mount disks partitions on the cygwin mount table file we need both kind of syntax. Is that even logical?Thanks in advance.Tony Hosking escribi?: Jay, there is an underlying principle here that you seem to be missing so I will make it explicit. Cross-product systems tend to acquire unmanageable complexity, especially when it comes to testing. By making each target one personality we are able to test machine-dependent code in isolation from machine-independent code. Often, when something breaks on one target I will test on another just to isolate the problem. This is a very powerful approach and I am very leery of destroying any ability to do this -- it allows us to maintain the high-level portability of most Modula-3 code while isolating the small fraction of machine-/target-dependent stuff. On Apr 22, 2008, at 12:28 AM, Jay wrote: [truncated]... From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] more path stuff, sorryDate: Tue, 22 Apr 2008 04:19:52 +0000There's no dependency, no linkage. Just a few simple string operations.I'll probably remove it tonight. Modula-3 has a split personality no matter what, in that it calls into very varying underlying layers, often trafficing in their specific data formats.It's just that it can strive to aid portability between them or not, by accepting either input and massaging it to work, vs. passing it along "unchanged" (well, that's not what happens actually). If there were no ambiguous cases and the Posix systems on Windows were consistent in their conventions, I'd be more for it. But the ambiguity and varying Posix conventions weaken the case tremendously. - Jay Date: Mon, 21 Apr 2008 23:14:00 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] more path stuff, sorry I concur wholeheartedly. I absolutely DO NOT want native NT386 to have any knowledge of or dependency on Cygwin. Regards, Randy>>> Tony Hosking 4/21/2008 9:44 PM >>> Why would native NT386 know anything at all about Cygwin. I say just avoid split personalities like the plague. Similarly, I'd be happy for NT386GNU (i.e., Cygwin?) to simply behave like a POSIX build (modulo native threads perhaps). On Apr 21, 2008, at 7:15 PM, Jay wrote: Maybe this is dubious.The question is, like, should native NT386 cm3 accept /cygdrive/c/foo and translate to c:\foo?Or trickier, /usr/bin/foo and translate to c:\cygwin\usr\bin\foo?And vice versa, should NT386GNU accept c:\foo?... Enviado desde Correo Yahoo!La bandeja de entrada m?s inteligente. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Apr 23 07:20:12 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Apr 2008 05:20:12 +0000 Subject: [M3devel] FW: more path stuff, sorry In-Reply-To: References: <08DD9502-27D3-4C5C-9E30-A9E9D2CADAB4@cs.purdue.edu> <135722.70767.qm@web27113.mail.ukl.yahoo.com> Message-ID: > enable running extensionless files: > set PATHEXT=.;%PATHEXT% Oh, hey, better yet: mkdir \cd\foo.exe, then you don't need to alter PATHEXT. Directories with extensions often occuring on files..that might cause some interesting problems.. - Jay From: jayk123 at hotmail.comTo: dabenavidesd at yahoo.es; m3devel at elegosoft.comSubject: RE: [M3devel] FW: more path stuff, sorryDate: Wed, 23 Apr 2008 05:17:43 +0000 > Types are important. I think much more so than modules.But user input, esp. in the form of a command line, are ambiguous and not strongly typed, and therefore sometimes open to "sniffing", to loose interpretation, guessing what was intended. There IS a place for guessing, but not everywhere. For example maybe?: cp foo bar What does that do? Copy one file or a directory full of files? A really bad example, what does this command line do: c:\program files\microsoft visual studio\cl.exe Does it run "cl.exe" in the directory "c:\program files\microsoft visual studio".Or does it run the "program" in c:\ with parameters "files\microsoft", "visual", "studio\cl.exe"? I BELIEVE the answer is that it DEPENDS. Both can exist at the same time -- "c:\program" and "C:\program files" I BELIEVE if "c:\program" exists, it is run.I'm not sure. CreateProcess has two parameters here and so there is a way to disambiguate and execve is probably unambiguous, but system() is ambiguous and CreateProcess has an ambiguous mode since you don't have to use both parameters -- like path to .exe and command line, you can leave the first NULL, something like that it's considered poor practise. Command lines are awfully weakly typed.You know -- you need to hit those keys harder. :) Or watch this, sometimes you don't need spaces between command line parameters: D:\>dir cd foo => nothing D:\>mkdir fooD:\>cd\foo => changes into the foo directory. let's go back up:cd \ and now...enable running extensionless files: set PATHEXT=.;%PATHEXT% create one.. mkdir \cd copy %windir%\notepad.exe \cd\foo and..: cd\foo now cd\foo runs the copy of notepad. ambiguity abounds... - Jay From: jayk123 at hotmail.comTo: dabenavidesd at yahoo.es; m3devel at elegosoft.comDate: Wed, 23 Apr 2008 04:59:51 +0000Subject: Re: [M3devel] FW: more path stuff, sorry I forgot some points.Daniel, in order to convert paths between the two, you need context to know what type the provider of the path intended. There are paths that are valid in both systems but that have different means. The path /usr/bin in Win32 is the same as \usr\bin and on the drive of the current working directory (the working, if you will)The path /usr/bin in Cygwin is \usr\bin under the Cygwin root, so often like c:\cygwin\usr\bin. The path /cygdrive/c/foo is also valid in Win32, and has a different meaning there than in Cygwin. Get it? The path c:/foo is unambiguous. The "string" c:/foo is ambiguous, depending on point of view.Let's say I want a string that contains colon delimited paths.Then this is the path c and the path /foo.But if paths themselves can have colons then it is also the single element list with the element c:/foo. You could get fancy shmancy and escape the colon c\:/foo but that's insane.Quoting is already a big problem in existing systems and usage, and I just made that garbage up. One of the points maybe the Modula-3 folks are alluding is that Pathname.T is a TYPE with an INTERFACE. It is not a "string".In many other systems a "path" is "just" a "string", it just gets pass around, and both sides party on it and hope they give it the same meaning.If your notion of type is not clear, between Win32 and Posix, then neither is the meaning.Strings are a terribly loose overused type....This does save people from coming up with those fancy complicated difficult to learn INTERFACES, and it aids interoperability, since everyone can use a string...it's good and it's bad, the glass is half full and half empty... c:\ "looks" like a win32 path, but hey, be careful there, I'm just smiling big and wearing a crooked hat, you have interpreted it completely incorretly, eh? Types are important. I think much more so than modules. And /foo/ looks like a Posix path, but actually it's italicized text. :)Or then again, this whole email is a valid Posix path, newlines and all, since it has no embedded nuls. :) - Jay From: jayk123 at hotmail.comTo: dabenavidesd at yahoo.es; m3devel at elegosoft.comSubject: RE: [M3devel] FW: more path stuff, sorryDate: Wed, 23 Apr 2008 04:44:23 +0000 Daniel, this should address SOME but not necessarily all of your concern and questions: The underlying libraries are mostly Cygwin.Underlying THEM is another library, but the way it works, there is approximately zero "break through".Except for threads.Also, I intend, somehow, to expose FilePosix.T and FileWin32.T, besides the regular File.T.This would be part of enabling the serial package to build, using strictly "break through" and the Win32 code.However FilePosix.m3 and FileWin32.m3 both reveal File.T. I need to split the revelation out into a separate interface/module I think, shouldn't be hard. From SOME point of view, forward slashes are perfectly acceptable in Win32 paths and have the same meaning as backward slashs. It is not 100%, but largely. This isn't Modula-3 code doing any "translation" but the Modula-3 does treat \ and / equivalent upon read. The lowest level Win32 File functions in kernel32.dll -- CreateFile, DeleteFile, MoveFile, CreateDirectory, RemoveDirectory, CopyFile, GetCurrentDirectory, SetCurrentDirectory, GetFileAttributes[Ex], FindFirst[Next]File[Ex], what else am I forgetting? Maybe CreateProcess? GetFullPathName, GetShortPathName, usually consider \ and / the same. Unless the paths starts \\?. The / are all converted to \ before getting to the underlying system, the NtCreateFile, where strictly \ is the separator and there is no working directory. If a path starts \\?, it is passed on directly. You don't have to pass full paths. You can pass a handle to a parent directory. Now, I recently read, regarding NTFS-3G for Linux, about allowing : and \ in file names.The claim is that if you install SFU (Services For Unix, previously Interix, now SUA), you can access such names on NT.I tried it out. In fact this claim seems wrong. I create those paths, and then enumerated and printed from Win32. Their lower 8 bits were : and \. But their upper 8 bits were 0xF0 or 0xFF or somesuch. SFU has some ability to access unicode file names, but not that I could find that would reveal this trickery. In particular, there is like wcs_opendir that opens a directory with a unicode path, but there is only the asii/ansi/utf8/7bit/8bit/whatever readdir/readdir_r. So the 0xF000 cannot show through.And proper unicode Win32 code still doesn't see ':' or '\' per se in file names (in paths, but not individual names). I think I happened to accidentally copy this stuff to a Linux machine, and they didn't come across as ':' or '\'.Maybe I used wine cmd copy though. I should try with NTFS-3G. I do suspect I'll get ':' and '\'. Speaking of portability -- should Modula-3 on Posix systems allow file names with ':' and '\'? There are pluses and minuses. It's a rhetorical question -- in that, I don't really want to discuss it that much. I don't think there's a good answer, so I'd just as soon leave the code alone vs. trying in vain to come up with what is "correct". Yes there are Cygwin specific functions for converting paths.It would be reasonable for some NT386GNU-specific paths to use them.You can write up the *.i3 files and call them where you deem appropriate. Where deemed appropriate is not clear.It would not be great for the NT386 tools to use them -- to link to cygwin1.dll, for any reason.Maybe via LoadLibrary/GetProcAddress -- an optional dependency. Maybe.I believe "linkage" should mean "static linkage in the same file" and not "dynamic linkage in the same process" but it isn't up to me and it very well might be this way. I think the Linux kernel grants an exception, but I'm skeptical that non-GPL code doesn't dynamically link to in-proc GPL code that hasn't granted an exception. Anyway, Modula-3 except for NT386GNU is not in any uniquely worrying boat, for sure. You see, like my little speech about emulation layers and "break though", Cygwin is an emulation layer.But its users may or may not consider it to have much "break through".It's users might be very accustomed to Posix paths and a full set of Posix-path-using tools, and have no need to give any of them a Win32 path, and if they do, might be prepared to stop and think about it and do their own conversion. I think it's gray, because gcc as a compiler is arguably way more valuable than a Posix porting layer for other code.Or really, they are both useful. Some people will want one, or the other, or both, or neither. And again I am confusing Cygwin, NT386GNU, and the backend vs. the runtime. You can very well combine the integrated backend with a Posixish runtime -- remember all the systems now have the integrated backend, you should be able to output NT386 .obj files on any platform just by saying TARGET= "NT386" in cm3.cfg. And you can combine the gcc backend with a Win32 runtime -- that is what NT386MINGNU is. Also, while kernel32.dll treats / like \, other Win32 functions/libraries do not, such as comdlg32.dll (File.Open, File.Save), and shlwapi.dll, I think. You'd have to read the docs and/or experiment.Win32 has a lot of nice internal consistencies, but it isn't 100% consistent. Probably nothing is. A mix of slashes works fine on NT386. Does some of this make sense? Again again again, "NT386GNU" is different things to different people, and some of them are in fact independent and you can pick and chose which parts you compose. There is the runtime the compiler uses. There is the backend. There is the library the output uses, both the "C library" (fopen), the threading library (pthreads vs. Win32), the windowing library (X Windows vs. Win32), the naming conventions (libfoo.a vs. foo.lib). Nearly every one of these factors is independent of the others, The config files are written as such and you should be able to experiment and make your own other combinations. Three such combinations are provided, and there's sort of a tendency for the host and the target to be the same, but they don't have to be. There are other factors, like which C compiler do you use, which linker. The compiler, backend, and linker conspire to determine which debugger you can use. If you se the integrated backend and MS linker, you can use MS debuggers. If you use the gcc backend and GNU linker, you can use gdb. Oh, well you can always use either debugger, but the point here is if you have symbols or not. Currently there is some problem mixing the gcc backend with the MS linker and/or the integrated backend with the GNU linker. I think gcc backend with MS linker, and only sometimes the other. There is a symbol alway injected into the .o files that the GNU linker knows about but that the MS linker gives as unresolved. The MS linker has a different name for it, but I don't believe it is always injected by the integrated backend. This is the symbol that lets you point to the start of your image, it is __ImageBase in MS. It isn't used much. But for some reason gcc always generates references to it, and gives it a different name. Therefore some of the supposedly independent factors are not independent as they should be. For network paths, Cygwin allows //machine/server. Current Cygwin issues warnings when you use Win32 paths, and the warning says you can quash it by setting CYGWIN=nodospathwarning or somesuch. Does this make some sense? At some point maybe I'll put together distributions for other combinations. Oh, one more thing, the gcc backend can use __int64.I was feeling guilty about taking so long adding that to the integrated backend, thus I fast-forwarded and got NT386GNU to work. I should still go back and add it though. Also, currently the compiler assumes some linkage of these factors. It assumes OS_TYPE=POSIX means targeting Cygwin. Eh that's pretty much correct. At some point maybe UWin and SFU will be options, but not right now. The compiler's main concern is the jumpbuf size, which is much larger for Cygwin. You can to some extent maybe link NT386 and NT386GNU together, but this jumpbuf thing could really hurt in a hard to diagnose way. (Maybe it's safe due to setjmp vs. _setjmp?)? Sorry this is too long. As Olaf said, what I say might be very true and an accurate model, but it confuses everyone.People want very very few variables. Sorry I have to run, no proofreading this "masterpiece". - Jay Date: Wed, 23 Apr 2008 06:00:43 +0200From: dabenavidesd at yahoo.esTo: m3devel at elegosoft.comSubject: Re: [M3devel] FW: more path stuff, sorryHi all:Does pm3 treat NT386GNU paths as POSIX class? I think if one take the definition the Interface Pathname, NT386GNU target should not have access directly to use POSIX paths but Win32 ones because of:"A Pathname.T (or just a pathname) is a text conforming to the syntax of the underlying operating system" inhttp://www.opencm3.net/doc/help/gen_html/libm3/src/os/Common/Pathname.i3.htmlBut if we think in "the underlying operating system" as the cygwin api, it should be the natural POSIX paths.I agree Pathname is a common interface, but what happens with that sense of portability we want? Maybe the answer is in the cygwin api; the non-standard functions of converting one style to the other: http://cygwin.com/cygwin-api/cygwin-functions.html .See http://www.cygwin.com/cygwin-ug-net/using.html#using-pathnamesfor the main notes of compatibility. It seems clear that cygwin can use both kind of path styles, so it's not a problem to use just one of POSIX or Win32 paths. So defining a Pathname of type POSIX style for NT386GNU, it is not resign to the more capable functions of cygwin?I mean if Pathname accept both kind of forward and back slashes in different Pathnames it should be defined a new kind of Pathname syntax. Oh I remember saw the mix of both kind of slashes in pm3 quake/config files of NT386GNU :) Is this really confusing or unthinkable?I think this is clear for some of yous (NT386GNU should just accept POSIX paths, not even a Win32 one, and obviously not a mix of the two syntax in a same path), but it is not for me.In my opinion both styles should be acceptable without defining a new kind of path syntax, and convert only using the cygwin api functions. For instance when using netbios resources but also trying to mount disks partitions on the cygwin mount table file we need both kind of syntax. Is that even logical?Thanks in advance.Tony Hosking escribi?: Jay, there is an underlying principle here that you seem to be missing so I will make it explicit. Cross-product systems tend to acquire unmanageable complexity, especially when it comes to testing. By making each target one personality we are able to test machine-dependent code in isolation from machine-independent code. Often, when something breaks on one target I will test on another just to isolate the problem. This is a very powerful approach and I am very leery of destroying any ability to do this -- it allows us to maintain the high-level portability of most Modula-3 code while isolating the small fraction of machine-/target-dependent stuff. On Apr 22, 2008, at 12:28 AM, Jay wrote: [truncated]... From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] more path stuff, sorryDate: Tue, 22 Apr 2008 04:19:52 +0000There's no dependency, no linkage. Just a few simple string operations.I'll probably remove it tonight. Modula-3 has a split personality no matter what, in that it calls into very varying underlying layers, often trafficing in their specific data formats.It's just that it can strive to aid portability between them or not, by accepting either input and massaging it to work, vs. passing it along "unchanged" (well, that's not what happens actually). If there were no ambiguous cases and the Posix systems on Windows were consistent in their conventions, I'd be more for it. But the ambiguity and varying Posix conventions weaken the case tremendously. - Jay Date: Mon, 21 Apr 2008 23:14:00 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] more path stuff, sorry I concur wholeheartedly. I absolutely DO NOT want native NT386 to have any knowledge of or dependency on Cygwin. Regards, Randy>>> Tony Hosking 4/21/2008 9:44 PM >>> Why would native NT386 know anything at all about Cygwin. I say just avoid split personalities like the plague. Similarly, I'd be happy for NT386GNU (i.e., Cygwin?) to simply behave like a POSIX build (modulo native threads perhaps). On Apr 21, 2008, at 7:15 PM, Jay wrote: Maybe this is dubious.The question is, like, should native NT386 cm3 accept /cygdrive/c/foo and translate to c:\foo?Or trickier, /usr/bin/foo and translate to c:\cygwin\usr\bin\foo?And vice versa, should NT386GNU accept c:\foo?... Enviado desde Correo Yahoo!La bandeja de entrada m?s inteligente. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Apr 23 15:06:12 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 23 Apr 2008 09:06:12 -0400 Subject: [M3devel] FW: more path stuff, sorry In-Reply-To: References: <08DD9502-27D3-4C5C-9E30-A9E9D2CADAB4@cs.purdue.edu> <135722.70767.qm@web27113.mail.ukl.yahoo.com> Message-ID: <2CB6197F-E4CA-4D05-8363-BA18A60B0DF3@cs.purdue.edu> Jay, Daniel was referring to PM3, not CM3. 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 Apr 23, 2008, at 12:44 AM, Jay wrote: > Daniel, this should address SOME but not necessarily all of your > concern and questions: > > The underlying libraries are mostly Cygwin. > Underlying THEM is another library, but the way it works, there is > approximately zero "break through". > Except for threads. > Also, I intend, somehow, to expose FilePosix.T and FileWin32.T, > besides the regular File.T. > This would be part of enabling the serial package to build, using > strictly "break through" and the Win32 code. > However FilePosix.m3 and FileWin32.m3 both reveal File.T. I need to > split the revelation out into a separate interface/module I think, > shouldn't be hard. > > >From SOME point of view, forward slashes are perfectly acceptable > in Win32 paths and have the same meaning as backward slashs. It is > not 100%, but largely. This isn't Modula-3 code doing any > "translation" but the Modula-3 does treat \ and / equivalent upon > read. > > The lowest level Win32 File functions in kernel32.dll -- CreateFile, > DeleteFile, MoveFile, CreateDirectory, RemoveDirectory, CopyFile, > GetCurrentDirectory, SetCurrentDirectory, GetFileAttributes[Ex], > FindFirst[Next]File[Ex], what else am I forgetting? Maybe > CreateProcess? GetFullPathName, GetShortPathName, usually consider \ > and / the same. Unless the paths starts \\?. The / are all converted > to \ before getting to the underlying system, the NtCreateFile, > where strictly \ is the separator and there is no working directory. > If a path starts \\?, it is passed on directly. You don't have to > pass full paths. You can pass a handle to a parent directory. > > Now, I recently read, regarding NTFS-3G for Linux, about allowing : > and \ in file names. > The claim is that if you install SFU (Services For Unix, previously > Interix, now SUA), you can access such names on NT. > I tried it out. In fact this claim seems wrong. I create those > paths, and then enumerated and printed from Win32. Their lower 8 > bits were : and \. But their upper 8 bits were 0xF0 or 0xFF or > somesuch. SFU has some ability to access unicode file names, but not > that I could find that would reveal this trickery. In particular, > there is like wcs_opendir that opens a directory with a unicode > path, but there is only the asii/ansi/utf8/7bit/8bit/whatever > readdir/readdir_r. So the 0xF000 cannot show through. > And proper unicode Win32 code still doesn't see ':' or '\' per se in > file names (in paths, but not individual names). > > I think I happened to accidentally copy this stuff to a Linux > machine, and they didn't come across as ':' or '\'. > Maybe I used wine cmd copy though. I should try with NTFS-3G. I do > suspect I'll get ':' and '\'. > > Speaking of portability -- should Modula-3 on Posix systems allow > file names with ':' and '\'? There are pluses and minuses. It's a > rhetorical question -- in that, I don't really want to discuss it > that much. I don't think there's a good answer, so I'd just as soon > leave the code alone vs. trying in vain to come up with what is > "correct". > > Yes there are Cygwin specific functions for converting paths. > It would be reasonable for some NT386GNU-specific paths to use them. > You can write up the *.i3 files and call them where you deem > appropriate. > Where deemed appropriate is not clear. > It would not be great for the NT386 tools to use them -- to link to > cygwin1.dll, for any reason. > Maybe via LoadLibrary/GetProcAddress -- an optional dependency. Maybe. > > I believe "linkage" should mean "static linkage in the same file" > and not "dynamic linkage in the same process" but it isn't up to me > and it very well might be this way. I think the Linux kernel grants > an exception, but I'm skeptical that non-GPL code doesn't > dynamically link to in-proc GPL code that hasn't granted an > exception. Anyway, Modula-3 except for NT386GNU is not in any > uniquely worrying boat, for sure. > > You see, like my little speech about emulation layers and "break > though", Cygwin is an emulation layer. > But its users may or may not consider it to have much "break through". > It's users might be very accustomed to Posix paths and a full set of > Posix-path-using tools, and have no need to give any of them a Win32 > path, and if they do, might be prepared to stop and think about it > and do their own conversion. > > I think it's gray, because gcc as a compiler is arguably way more > valuable than a Posix porting layer for other code. > Or really, they are both useful. Some people will want one, or the > other, or both, or neither. > > And again I am confusing Cygwin, NT386GNU, and the backend vs. the > runtime. > > You can very well combine the integrated backend with a Posixish > runtime -- remember all the systems now have the integrated backend, > you should be able to output NT386 .obj files on any platform just > by saying TARGET= "NT386" in cm3.cfg. > > And you can combine the gcc backend with a Win32 runtime -- that is > what NT386MINGNU is. > > Also, while kernel32.dll treats / like \, other Win32 functions/ > libraries do not, such as comdlg32.dll (File.Open, File.Save), and > shlwapi.dll, I think. You'd have to read the docs and/or experiment. > Win32 has a lot of nice internal consistencies, but it isn't 100% > consistent. Probably nothing is. > > A mix of slashes works fine on NT386. > > Does some of this make sense? > > Again again again, "NT386GNU" is different things to different > people, and some of them are in fact independent and you can pick > and chose which parts you compose. There is the runtime the compiler > uses. There is the backend. There is the library the output uses, > both the "C library" (fopen), the threading library (pthreads vs. > Win32), the windowing library (X Windows vs. Win32), the naming > conventions (libfoo.a vs. foo.lib). Nearly every one of these > factors is independent of the others, The config files are written > as such and you should be able to experiment and make your own other > combinations. Three such combinations are provided, and there's sort > of a tendency for the host and the target to be the same, but they > don't have to be. There are other factors, like which C compiler do > you use, which linker. The compiler, backend, and linker conspire to > determine which debugger you can use. If you se the integrated > backend and MS linker, you can use MS debuggers. If you use the gcc > backend and GNU linker, you can use gdb. Oh, well you can always use > either debugger, but the point here is if you have symbols or not. > Currently there is some problem mixing the gcc backend with the MS > linker and/or the integrated backend with the GNU linker. I think > gcc backend with MS linker, and only sometimes the other. There is a > symbol alway injected into the .o files that the GNU linker knows > about but that the MS linker gives as unresolved. The MS linker has > a different name for it, but I don't believe it is always injected > by the integrated backend. This is the symbol that lets you point to > the start of your image, it is __ImageBase in MS. It isn't used > much. But for some reason gcc always generates references to it, and > gives it a different name. Therefore some of the supposedly > independent factors are not independent as they should be. > > For network paths, Cygwin allows //machine/server. > > Current Cygwin issues warnings when you use Win32 paths, and the > warning says you can quash it by setting CYGWIN=nodospathwarning or > somesuch. > > Does this make some sense? > > At some point maybe I'll put together distributions for other > combinations. > > Oh, one more thing, the gcc backend can use __int64. > I was feeling guilty about taking so long adding that to the > integrated backend, thus I fast-forwarded and got NT386GNU to work. > I should still go back and add it though. > > Also, currently the compiler assumes some linkage of these factors. > It assumes OS_TYPE=POSIX means targeting Cygwin. Eh that's pretty > much correct. At some point maybe UWin and SFU will be options, but > not right now. The compiler's main concern is the jumpbuf size, > which is much larger for Cygwin. You can to some extent maybe link > NT386 and NT386GNU together, but this jumpbuf thing could really > hurt in a hard to diagnose way. (Maybe it's safe due to setjmp vs. > _setjmp?)? > > Sorry this is too long. As Olaf said, what I say might be very true > and an accurate model, but it confuses everyone. > People want very very few variables. > > Sorry I have to run, no proofreading this "masterpiece". deprecating humor inserted here.> > > > - Jay > > Date: Wed, 23 Apr 2008 06:00:43 +0200 > From: dabenavidesd at yahoo.es > To: m3devel at elegosoft.com > Subject: Re: [M3devel] FW: more path stuff, sorry > > Hi all: > Does pm3 treat NT386GNU paths as POSIX class? I think if one take > the definition the Interface Pathname, NT386GNU target should not > have access directly to use POSIX paths but Win32 ones because of: > "A Pathname.T (or just a pathname) is a text conforming to the > syntax of the underlying operating system" in > http://www.opencm3.net/doc/help/gen_html/libm3/src/os/Common/Pathname.i3.html > But if we think in "the underlying operating system" as the cygwin > api, it should be the natural POSIX paths. > I agree Pathname is a common interface, but what happens with that > sense of portability we want? Maybe the answer is in the cygwin api; > the non-standard functions of converting one style to the other: http://cygwin.com/cygwin-api/cygwin-functions.html > . > See http://www.cygwin.com/cygwin-ug-net/using.html#using-pathnames > for the main notes of compatibility. It seems clear that cygwin can > use both kind of path styles, so it's not a problem to use just one > of POSIX or Win32 paths. So defining a Pathname of type POSIX style > for NT386GNU, it is not resign to the more capable functions of > cygwin? > I mean if Pathname accept both kind of forward and back slashes in > different Pathnames it should be defined a new kind of Pathname > syntax. Oh I remember saw the mix of both kind of slashes in pm3 > quake/config files of NT386GNU :) Is this really confusing or > unthinkable? > I think this is clear for some of yous (NT386GNU should just accept > POSIX paths, not even a Win32 one, and obviously not a mix of the > two syntax in a same path), but it is not for me. > In my opinion both styles should be acceptable without defining a > new kind of path syntax, and convert only using the cygwin api > functions. For instance when using netbios resources but also trying > to mount disks partitions on the cygwin mount table file we need > both kind of syntax. Is that even logical? > Thanks in advance. > > Tony Hosking escribi?: > Jay, there is an underlying principle here that you seem to be > missing so I will make it explicit. Cross-product systems tend to > acquire unmanageable complexity, especially when it comes to > testing. By making each target one personality we are able to test > machine-dependent code in isolation from machine-independent code. > Often, when something breaks on one target I will test on another > just to isolate the problem. This is a very powerful approach and I > am very leery of destroying any ability to do this -- it allows us > to maintain the high-level portability of most Modula-3 code while > isolating the small fraction of machine-/target-dependent stuff. > > > > On Apr 22, 2008, at 12:28 AM, Jay wrote: > > [truncated]... > > > > > From: jayk123 at hotmail.com > To: rcoleburn at scires.com; m3devel at elegosoft.com > Subject: RE: [M3devel] more path stuff, sorry > Date: Tue, 22 Apr 2008 04:19:52 +0000 > > There's no dependency, no linkage. Just a few simple string > operations. > I'll probably remove it tonight. > > Modula-3 has a split personality no matter what, in that it calls > into very varying underlying layers, often trafficing in their > specific data formats. > It's just that it can strive to aid portability between them or not, > by accepting either input and massaging it to work, vs. passing it > along "unchanged" (well, that's not what happens actually). If there > were no ambiguous cases and the Posix systems on Windows were > consistent in their conventions, I'd be more for it. But the > ambiguity and varying Posix conventions weaken the case tremendously. > > - Jay > > Date: Mon, 21 Apr 2008 23:14:00 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] more path stuff, sorry > > I concur wholeheartedly. I absolutely DO NOT want native NT386 to > have any knowledge of or dependency on Cygwin. > Regards, > Randy > > >>> Tony Hosking 4/21/2008 9:44 PM >>> > Why would native NT386 know anything at all about Cygwin. I say > just avoid split personalities like the plague. Similarly, I'd be > happy for NT386GNU (i.e., Cygwin?) to simply behave like a POSIX > build (modulo native threads perhaps). > > On Apr 21, 2008, at 7:15 PM, Jay wrote: > > Maybe this is dubious. > > The question is, like, should native NT386 cm3 accept /cygdrive/c/ > foo and translate to c:\foo? > Or trickier, /usr/bin/foo and translate to c:\cygwin\usr\bin\foo? > And vice versa, should NT386GNU accept c:\foo? > > ... > > > > Enviado desde Correo Yahoo! > La bandeja de entrada m?s inteligente. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Apr 23 17:20:41 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Apr 2008 15:20:41 +0000 Subject: [M3devel] naming conventions for split/composed interfaces? Message-ID: So I'm fixing AMD64_LINUX Utypes.i3, Ustat.i3, etc. Look at what I did for example with Upthread.i3 vs. UpthreadMachine.i3. Ustat.i3 shall be mostly the same between PPC_LINUX, LINUXLIBC6 (I386_LINUX), AMD64_LINUX, etc. However struct_stat will not likely be. It appears, though I have to double check, the difference cannot be abstracted out to pointer-sized integer types, that the fields are of varying orders. So I want to say: linux-i386/UstatPlatformSpecific.i3 TYPE struct_stat = ... linux-amd64/UstatPlatformSpecific.i3 TYPE struct_stat = ... linux-ppc/UstatPlatformSpecific.i3 TYPE struct_stat = ... linuxlibc/Ustat.i3 TYPE struct_stat = UstatsPlatformSpecific.struct_stat; My question is simply: What is the, or a good, naming convention for UstatPlatformSpecific? Note that it /could/ be that all but x86 have the same definition, so "PlatformSpecific", might be too, um, specific. UstatMachine? (Similarly wrong, but maybe no matter, and shorter.) UstatNotCommon? Sounds dumb. UstatX? Not as bad as it sounds. There is a precedent. It self-documents the idea that there isn't an obvious good name. UstatInternal? UstatPrivate? It's not really about hiding, so much as implementation factoring. But implementation structure is an internal detail. UstatF? (Friend?) Ustructstat? no -- ideally, anything in existing Ustat.i3 that varies goess here, not necessarily just this type. I do not want fork entire files. The system is composed of common and uncommon pieces. I believe the decision where to split should be in general pushed down. However not without judgement calls. You know, there are things that must be shared, things that are nice to share, things that are more efficient to share, things that cannot be shared. Type declarations are usually "must" but in this case largely "nice" (not Ustat, but e.g. Upthreads), and some parts of them "cannot". This split/compose pattern, you know, is a way to get something like #ifdef, without any language change or such. It does make existing code harder to read, because it is broken up into more pieces, but code will always be broken up into pieces and never all in one place and always require some assumption or tracking down of what the next level down does (until you get to atoms, quantum physics, and all that), the thing is merely to decide on just what amount is the right amount (says Goldilocks.) - Jay From hosking at cs.purdue.edu Wed Apr 23 17:33:00 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 23 Apr 2008 11:33:00 -0400 Subject: [M3devel] naming conventions for split/composed interfaces? In-Reply-To: References: Message-ID: <06FA077F-C6FB-4E42-B4AE-1A040EE2698E@cs.purdue.edu> Generally, what I try to do is to make Uxxxxx.i3 files for every corresponding C xxxx.h file. This way, as the C headers change it is easy to figure out where things should go. Why do you need a platform- specific name at all? Simply put it into a platform-specific subdirectory which will then be selectively included by the parent m3makefile. That way, we retain a consistent name for the files containing relevant declarations *across* platforms. Remember, only one of these subdirectories gets included in any given build (these are part of the run-time). So, for simplicity's sake I would argue that you are once more making unneeded complexity where simplicity is needed. So, simply having a "linux-generic" directory, and "linux-amd64" + "linux-ppc" + "linux-x86" subdirectories, each with "Upthread", "Ustat", etc. should work just fine. What's the point in making it more complicated? On Apr 23, 2008, at 11:20 AM, Jay wrote: > > So I'm fixing AMD64_LINUX Utypes.i3, Ustat.i3, etc. > > Look at what I did for example with Upthread.i3 vs. > UpthreadMachine.i3. > > Ustat.i3 shall be mostly the same between PPC_LINUX, LINUXLIBC6 > (I386_LINUX), AMD64_LINUX, etc. > > However struct_stat will not likely be. It appears, though I have to > double check, the difference cannot be abstracted out to pointer- > sized integer types, that the fields are of varying orders. > > So I want to say: > > linux-i386/UstatPlatformSpecific.i3 > TYPE struct_stat = ... > > linux-amd64/UstatPlatformSpecific.i3 > TYPE struct_stat = ... > > linux-ppc/UstatPlatformSpecific.i3 > TYPE struct_stat = ... > > linuxlibc/Ustat.i3 > TYPE struct_stat = UstatsPlatformSpecific.struct_stat; > > My question is simply: > > What is the, or a good, naming convention for UstatPlatformSpecific? > > Note that it /could/ be that all but x86 have the same definition, > so "PlatformSpecific", might be too, um, specific. > UstatMachine? (Similarly wrong, but maybe no matter, and shorter.) > UstatNotCommon? Sounds dumb. > UstatX? Not as bad as it sounds. There is a precedent. It self- > documents the idea that there isn't an obvious good name. > UstatInternal? UstatPrivate? > It's not really about hiding, so much as implementation factoring. > But implementation structure is an internal detail. > UstatF? (Friend?) > Ustructstat? no -- ideally, anything in existing Ustat.i3 that > varies goess here, not necessarily just this type. > > I do not want fork entire files. > The system is composed of common and uncommon pieces. > I believe the decision where to split should be in general pushed > down. > However not without judgement calls. > You know, there are things that must be shared, things that are nice > to share, things that are more efficient to share, things that > cannot be shared. > Type declarations are usually "must" but in this case largely > "nice" (not Ustat, but e.g. Upthreads), and some parts of them > "cannot". > > This split/compose pattern, you know, is a way to get something like > #ifdef, without any language change or such. > It does make existing code harder to read, because it is broken up > into more pieces, but code will always be broken up into pieces and > never all in one place and always require some assumption or > tracking down of what the next level down does (until you get to > atoms, quantum physics, and all that), the thing is merely to decide > on just what amount is the right amount (says Goldilocks.) > > - Jay From jayk123 at hotmail.com Wed Apr 23 17:35:57 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Apr 2008 15:35:57 +0000 Subject: [M3devel] naming conventions for split/composed interfaces? Message-ID: another idea: merge UpthreadMachine.i3 and UstatMachine.i3 into just Umachine.i3. Seems like it produces fewer medium sized files instead of more tiny ones but I think I see a drawback too, and until I hear back will go with UstatMachine. Eventually more sharing is probably possible, like of all of Ustat across all platforms, except for struct_stat. And all of Upthread except the sizes of the types and possibly the initializers (Cygwin has non-zero initializers, ideally they are all zero though.) And most of Cstd*. It bugs me to have so many so similar files.... - Jay have moved struct > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Subject: naming conventions for split/composed interfaces? > Date: Wed, 23 Apr 2008 15:20:41 +0000 > > > So I'm fixing AMD64_LINUX Utypes.i3, Ustat.i3, etc. > > Look at what I did for example with Upthread.i3 vs. UpthreadMachine.i3. > > Ustat.i3 shall be mostly the same between PPC_LINUX, LINUXLIBC6 (I386_LINUX), AMD64_LINUX, etc. > > However struct_stat will not likely be. It appears, though I have to double check, the difference cannot be abstracted out to pointer-sized integer types, that the fields are of varying orders. > > So I want to say: > > linux-i386/UstatPlatformSpecific.i3 > TYPE struct_stat = ... > > linux-amd64/UstatPlatformSpecific.i3 > TYPE struct_stat = ... > > linux-ppc/UstatPlatformSpecific.i3 > TYPE struct_stat = ... > > linuxlibc/Ustat.i3 > TYPE struct_stat = UstatsPlatformSpecific.struct_stat; > > My question is simply: > > What is the, or a good, naming convention for UstatPlatformSpecific? > > Note that it /could/ be that all but x86 have the same definition, so "PlatformSpecific", might be too, um, specific. > UstatMachine? (Similarly wrong, but maybe no matter, and shorter.) > UstatNotCommon? Sounds dumb. > UstatX? Not as bad as it sounds. There is a precedent. It self-documents the idea that there isn't an obvious good name. > UstatInternal? UstatPrivate? > It's not really about hiding, so much as implementation factoring. But implementation structure is an internal detail. > UstatF? (Friend?) > Ustructstat? no -- ideally, anything in existing Ustat.i3 that varies goess here, not necessarily just this type. > > I do not want fork entire files. > The system is composed of common and uncommon pieces. > I believe the decision where to split should be in general pushed down. > However not without judgement calls. > You know, there are things that must be shared, things that are nice to share, things that are more efficient to share, things that cannot be shared. > Type declarations are usually "must" but in this case largely "nice" (not Ustat, but e.g. Upthreads), and some parts of them "cannot". > > This split/compose pattern, you know, is a way to get something like #ifdef, without any language change or such. > It does make existing code harder to read, because it is broken up into more pieces, but code will always be broken up into pieces and never all in one place and always require some assumption or tracking down of what the next level down does (until you get to atoms, quantum physics, and all that), the thing is merely to decide on just what amount is the right amount (says Goldilocks.) > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Apr 23 22:01:24 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 23 Apr 2008 16:01:24 -0400 Subject: [M3devel] naming conventions for split/composed interfaces? In-Reply-To: References: <06FA077F-C6FB-4E42-B4AE-1A040EE2698E@cs.purdue.edu> <7F9C2510-13AB-4CB0-8C79-4315C75C90E6@cs.purdue.edu> Message-ID: Basically, I hate the idea of tangling together multiple machine- dependent systems in the same files. Yes, it is verbose with duplicated functionality, but it *is* separable. I can delete one set of files without breaking builds on other targets. I hate the idea of C wrappers even more! So, my position remains that while it is verbose having separate target-specific directories, at least they are independent and isolated. I actually think your suggestion is much messier than the current situation! On Apr 23, 2008, at 1:12 PM, Jay wrote: > ok. stat is an evolutionary mess actually. > > > Tony, Are you against having one Modula-3 definition of the type, > arbitrarily defined (any order, no padding, omit the nanoseconds > probably) and then wrappers in C to copy the data out? That is very > simple and obviously correct and just a tad inefficient. I'm very > much leaning toward this. Just for all live Linux variants for now, > not anything else (until I see if they have messy slightly hard to > read headers -- really, I can read them, or preprocess them, but I > am a little off put, others would be more off put and checking my > work becomes harder). I think there's gains to be in Cygwin too -- > you can ask it for not all the fields and have it be faster, you > know, if you don't need some complicated made up ino. > > Either that, or I rather think I should work out the two or three > struct declarations precisely and write non-copying wrappers in > Modula-3 that call __lxstat64, __fxstat64, etc., copying the inlines > out of the header. > > I approach from both sides -- read the header, and have C code print > sizes and offsets. > > It's a little messy. Read the comments. > There is a version number parameter to an underlying wrapper function. > The wrapper is either inlined or statically linked. > > I have to check if /usr/include represents all architectures, or > just x86 and AMD64. > It could be that the fork is on 32 and 64. > It could also be that using stat64 makes it all a little simpler, > but still a little messy. I have to see when then was introduced, I > assume well before LINUXLIBC6 but I have to check. Even stat64 isn't > the same between architectures though, it is split 32bit and 64bit.. > > - Jay > > From: hosking at cs.purdue.edu > To: jayk123 at hotmail.com > Subject: Re: [M3devel] naming conventions for split/composed > interfaces? > Date: Wed, 23 Apr 2008 12:40:23 -0400 > > Yeah, but in this case they really are for the platform -- header > files in /usr/include. I just want to make sure that we don't > slice and dice in ways that multiply the confusion. Right now, if I > know what platform I am on I know where to look in cm3/m3-libs/ > m3core/src/unix. I do try to use generic stuff where possible > (witness my darwin-generic, darwin-ppc, darwin-i386, darwin-amd64). > > On Apr 23, 2008, at 11:39 AM, Jay wrote: > > The point is to reduce massive duplication. > > Sometimes we split on ostype, sometimes on wordsize, sometimes on > the entire platform, sometimes otherwise. > Imagine if we always split on entire platform, what a mess that > would be. > > Upthread.i3 should be nearly identical across all platforms. > I know some platforms might have more functions, but the next > level up is not split and is therefore consistent in what it uses, > so no point in splitting the entire interface. > Let's not multiply everything out just to change a few lines. > > There is too much duplication in the system imho and I'd like to see > it reduced. > > - Jay > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > To: jayk123 at hotmail.com > > Subject: Re: [M3devel] naming conventions for split/composed > interfaces? > > Date: Wed, 23 Apr 2008 11:33:00 -0400 > > > > Generally, what I try to do is to make Uxxxxx.i3 files for every > > corresponding C xxxx.h file. This way, as the C headers change it is > > easy to figure out where things should go. Why do you need a > platform- > > specific name at all? Simply put it into a platform-specific > > subdirectory which will then be selectively included by the parent > > m3makefile. That way, we retain a consistent name for the files > > containing relevant declarations *across* platforms. Remember, only > > one of these subdirectories gets included in any given build (these > > are part of the run-time). So, for simplicity's sake I would argue > > that you are once more making unneeded complexity where simplicity > is > > needed. > > > > So, simply having a "linux-generic" directory, and "linux-amd64" + > > "linux-ppc" + "linux-x86" subdirectories, each with "Upthread", > > "Ustat", etc. should work just fine. What's the point in making it > > more complicated? > > > > On Apr 23, 2008, at 11:20 AM, Jay wrote: > > > > > > > > So I'm fixing AMD64_LINUX Utypes.i3, Ustat.i3, etc. > > > > > > Look at what I did for example with Upthread.i3 vs. > > > UpthreadMachine.i3. > > > > > > Ustat.i3 shall be mostly the same between PPC_LINUX, LINUXLIBC6 > > > (I386_LINUX), AMD64_LINUX, etc. > > > > > > However struct_stat will not likely be. It appears, though I > have to > > > double check, the difference cannot be abstracted out to pointer- > > > sized integer types, that the fields are of varying orders. > > > > > > So I want to say: > > > > > > linux-i386/UstatPlatformSpecific.i3 > > > TYPE struct_stat = ... > > > > > > linux-amd64/UstatPlatformSpecific.i3 > > > TYPE struct_stat = ... > > > > > > linux-ppc/UstatPlatformSpecific.i3 > > > TYPE struct_stat = ... > > > > > > linuxlibc/Ustat.i3 > > > TYPE struct_stat = UstatsPlatformSpecific.struct_stat; > > > > > > My question is simply: > > > > > > What is the, or a good, naming convention for > UstatPlatformSpecific? > > > > > > Note that it /could/ be that all but x86 have the same definition, > > > so "PlatformSpecific", might be too, um, specific. > > > UstatMachine? (Similarly wrong, but maybe no matter, and shorter.) > > > UstatNotCommon? Sounds dumb. > > > UstatX? Not as bad as it sounds. There is a precedent. It self- > > > documents the idea that there isn't an obvious good name. > > > UstatInternal? UstatPrivate? > > > It's not really about hiding, so much as implementation factoring. > > > But implementation structure is an internal detail. > > > UstatF? (Friend?) > > > Ustructstat? no -- ideally, anything in existing Ustat.i3 that > > > varies goess here, not necessarily just this type. > > > > > > I do not want fork entire files. > > > The system is composed of common and uncommon pieces. > > > I believe the decision where to split should be in general pushed > > > down. > > > However not without judgement calls. > > > You know, there are things that must be shared, things that are > nice > > > to share, things that are more efficient to share, things that > > > cannot be shared. > > > Type declarations are usually "must" but in this case largely > > > "nice" (not Ustat, but e.g. Upthreads), and some parts of them > > > "cannot". > > > > > > This split/compose pattern, you know, is a way to get something > like > > > #ifdef, without any language change or such. > > > It does make existing code harder to read, because it is broken up > > > into more pieces, but code will always be broken up into pieces > and > > > never all in one place and always require some assumption or > > > tracking down of what the next level down does (until you get to > > > atoms, quantum physics, and all that), the thing is merely to > decide > > > on just what amount is the right amount (says Goldilocks.) > > > > > > - Jay > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Apr 23 23:32:43 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 23 Apr 2008 23:32:43 +0200 Subject: [M3devel] naming conventions for split/composed interfaces? In-Reply-To: References: <06FA077F-C6FB-4E42-B4AE-1A040EE2698E@cs.purdue.edu> <7F9C2510-13AB-4CB0-8C79-4315C75C90E6@cs.purdue.edu> Message-ID: <20080423233243.ijpvrxlgwsw8s4og@mail.elegosoft.com> Quoting Tony Hosking : > Basically, I hate the idea of tangling together multiple machine- > dependent systems in the same files. Yes, it is verbose with > duplicated functionality, but it *is* separable. I can delete one set > of files without breaking builds on other targets. I hate the idea of > C wrappers even more! > > So, my position remains that while it is verbose having separate > target-specific directories, at least they are independent and isolated. > > I actually think your suggestion is much messier than the current situation! I agree with Tony here: we should keep the structure as simple and easily manageable as possible. While I understand your idea to join together files based on content (or, ultimately, on Unix history) we should keep in mind that a minimal amount of code does not always mean the minimal amount of maintenance costs, as the underlying systems evolve, too, and may (and will) do so in different directions. This may then require a different internal structure. So I like the idea of keeping different directories for different systems, even if there is some redundancy. Another argument to keep the structure is that is has proven to be easily portable; and we should be very careful to change it. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Thu Apr 24 01:01:27 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 23 Apr 2008 19:01:27 -0400 Subject: [M3devel] naming conventions for split/composed interfaces? In-Reply-To: <20080423233243.ijpvrxlgwsw8s4og@mail.elegosoft.com> References: <06FA077F-C6FB-4E42-B4AE-1A040EE2698E@cs.purdue.edu> <7F9C2510-13AB-4CB0-8C79-4315C75C90E6@cs.purdue.edu> <20080423233243.ijpvrxlgwsw8s4og@mail.elegosoft.com> Message-ID: <480F8783.1E75.00D7.1@scires.com> I too agree with Tony and Olaf on this point. The type of change Jay is suggesting goes against the way the language development has been set up and established since the beginning. Regards, Randy >>> Olaf Wagner 4/23/2008 5:32 PM >>> Quoting Tony Hosking : > Basically, I hate the idea of tangling together multiple machine- > dependent systems in the same files. Yes, it is verbose with > duplicated functionality, but it *is* separable. I can delete one set > of files without breaking builds on other targets. I hate the idea of > C wrappers even more! > > So, my position remains that while it is verbose having separate > target-specific directories, at least they are independent and isolated. > > I actually think your suggestion is much messier than the current situation! I agree with Tony here: we should keep the structure as simple and easily manageable as possible. While I understand your idea to join together files based on content (or, ultimately, on Unix history) we should keep in mind that a minimal amount of code does not always mean the minimal amount of maintenance costs, as the underlying systems evolve, too, and may (and will) do so in different directions. This may then require a different internal structure. So I like the idea of keeping different directories for different systems, even if there is some redundancy. Another argument to keep the structure is that is has proven to be easily portable; and we should be very careful to change it. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com ( 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 jayk123 at hotmail.com Thu Apr 24 12:58:12 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 24 Apr 2008 10:58:12 +0000 Subject: [M3devel] naming conventions for split/composed interfaces? In-Reply-To: <20080423233243.ijpvrxlgwsw8s4og@mail.elegosoft.com> References: <06FA077F-C6FB-4E42-B4AE-1A040EE2698E@cs.purdue.edu> <7F9C2510-13AB-4CB0-8C79-4315C75C90E6@cs.purdue.edu> <20080423233243.ijpvrxlgwsw8s4og@mail.elegosoft.com> Message-ID: Um..I have spent quite some time reading stat.h. At least 5 minutes. :) I must say, I really really really like the copyout method. Obviously, it goes something like this: struct_stat = RECORD st_dev : uint64_t; st_ino : uint64_t; st_mode : uint64_t; st_nlink : uint64_t; st_uid : uint64_t; st_gid : uint64_t; st_rdev : uint64_t; st_size : uint64_t; st_blksize: uint64_t; st_blocks : uint64_t; st_atime : uint64_t; st_mtime : uint64_t; st_ctime : uint64_t; END; struct_stat_star = UNTRACED REF struct_stat; void copyout(const stat_t* s, m3_stat_t* m) { m->st_ctime = s.st_stime; ... } int m3_stat(const char* path, m3_stat_t* m) { int result; struct stat s; result = m3_stat(path, &s); copyout(&s, m); return result; } and this one type definition and wrapper function is, like, arbitrarily portable to all systems. Quite simple. A little inefficient -- but it's not like the stat call itself won't dwarf the copying. I think I agree merging the files into Umachine.i3. However consider the part of Ustat.i3 other than the struct. The bit masks are probably identical across ALL platforms. The function declarations are. Actually even the struct can often be factored just by giving types like gid_t, ino_t, but I don't think that's worth it. I'd rather uint16_t, uint32_t, uint64_t. So I think moving just the struct into its own file, or using copyout, not a bad idea. Ustat.i3 is not quite the best example. I think a much better one is Upthread.i3. The file is very large and basically I think varies by 3-5 lines per variation. Lastly, you know, I do work to generate the headers kind of, and/or to derive them somewhat automatically. This work should probably be fully automated, at least for test cases, so assert the correctness. You know, write Modula-3 and C code to print field offsets and sizes and verify they are identical. This should aid maintenability. I assert the current system, no matter how the files are laid out, is overly fragile. I assert that transcribing .h files into .i3 files is a very dubious practise. It has an upside of easier cross building -- don't need the platform-specific headers. And it has the upside of not needing to worry about parsing .h files. But it is obviously bad maintainability. Better would be do wrappers like the above, except where perf is critical. Or at least actively (daily) assert the sizes/offsets. > Another argument to keep the structure is that is has proven to be > easily portable; and we should be very careful to change it. I think the current structure has proven easily copied around and then not fixed and bugs lurking.. This is not really my original point, but I have to harp a bit, it's been simmering in my brain a long time. Any time I see header cloning I cringe significantly. Visual Basic and C# have this same problem. - Jay > Date: Wed, 23 Apr 2008 23:32:43 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] naming conventions for split/composed interfaces? > > Quoting Tony Hosking : > > > Basically, I hate the idea of tangling together multiple machine- > > dependent systems in the same files. Yes, it is verbose with > > duplicated functionality, but it *is* separable. I can delete one set > > of files without breaking builds on other targets. I hate the idea of > > C wrappers even more! > > > > So, my position remains that while it is verbose having separate > > target-specific directories, at least they are independent and isolated. > > > > I actually think your suggestion is much messier than the current situation! > > I agree with Tony here: we should keep the structure as simple and > easily manageable as possible. > > While I understand your idea to join together files based on content > (or, ultimately, on Unix history) we should keep in mind that a > minimal amount of code does not always mean the minimal amount > of maintenance costs, as the underlying systems evolve, too, and may > (and will) do so in different directions. This may then require a > different internal structure. > > So I like the idea of keeping different directories for different > systems, even if there is some redundancy. > > Another argument to keep the structure is that is has proven to be > easily portable; and we should be very careful to change it. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Apr 24 14:44:57 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 24 Apr 2008 08:44:57 -0400 Subject: [M3devel] naming conventions for split/composed interfaces? In-Reply-To: References: <06FA077F-C6FB-4E42-B4AE-1A040EE2698E@cs.purdue.edu> <7F9C2510-13AB-4CB0-8C79-4315C75C90E6@cs.purdue.edu> <20080423233243.ijpvrxlgwsw8s4og@mail.elegosoft.com> Message-ID: Please, avoid C wrappers wherever possible. 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 Apr 24, 2008, at 6:58 AM, Jay wrote: > > Um..I have spent quite some time reading stat.h. At least 5 > minutes. :) > > I must say, I really really really like the copyout method. > > Obviously, it goes something like this: > > struct_stat = RECORD > st_dev : uint64_t; > st_ino : uint64_t; > st_mode : uint64_t; > st_nlink : uint64_t; > st_uid : uint64_t; > st_gid : uint64_t; > st_rdev : uint64_t; > st_size : uint64_t; > st_blksize: uint64_t; > st_blocks : uint64_t; > st_atime : uint64_t; > st_mtime : uint64_t; > st_ctime : uint64_t; > END; > struct_stat_star = UNTRACED REF struct_stat; > > > void copyout(const stat_t* s, m3_stat_t* m) > { > m->st_ctime = s.st_stime; > ... > } > int m3_stat(const char* path, m3_stat_t* m) > { > int result; > struct stat s; > > result = m3_stat(path, &s); > copyout(&s, m); > return result; > } > > and this one type definition and wrapper function is, like, > arbitrarily portable to all systems. > Quite simple. A little inefficient -- but it's not like the stat > call itself won't dwarf the copying. > > I think I agree merging the files into Umachine.i3. > > However consider the part of Ustat.i3 other than the struct. > The bit masks are probably identical across ALL platforms. > The function declarations are. > Actually even the struct can often be factored just by giving types > like gid_t, ino_t, but I don't think that's worth it. > I'd rather uint16_t, uint32_t, uint64_t. > > So I think moving just the struct into its own file, or using > copyout, not a bad idea. > > Ustat.i3 is not quite the best example. > I think a much better one is Upthread.i3. > The file is very large and basically I think varies by 3-5 lines per > variation. > > Lastly, you know, I do work to generate the headers kind of, and/or > to derive them somewhat automatically. > This work should probably be fully automated, at least for test > cases, so assert the correctness. > You know, write Modula-3 and C code to print field offsets and sizes > and verify they are identical. > This should aid maintenability. I assert the current system, no > matter how the files are laid out, is overly fragile. > I assert that transcribing .h files into .i3 files is a very dubious > practise. > It has an upside of easier cross building -- don't need the platform- > specific headers. > And it has the upside of not needing to worry about parsing .h files. > But it is obviously bad maintainability. > > Better would be do wrappers like the above, except where perf is > critical. > Or at least actively (daily) assert the sizes/offsets. > >> Another argument to keep the structure is that is has proven to be >> easily portable; and we should be very careful to change it. > > I think the current structure has proven easily copied around and > then not fixed and bugs lurking.. > This is not really my original point, but I have to harp a bit, it's > been simmering in my brain a long time. > Any time I see header cloning I cringe significantly. Visual Basic > and C# have this same problem. > > - Jay > > > > >> Date: Wed, 23 Apr 2008 23:32:43 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] naming conventions for split/composed >> interfaces? >> >> Quoting Tony Hosking : >> >>> Basically, I hate the idea of tangling together multiple machine- >>> dependent systems in the same files. Yes, it is verbose with >>> duplicated functionality, but it *is* separable. I can delete one >>> set >>> of files without breaking builds on other targets. I hate the >>> idea of >>> C wrappers even more! >>> >>> So, my position remains that while it is verbose having separate >>> target-specific directories, at least they are independent and >>> isolated -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Apr 25 02:28:00 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 25 Apr 2008 00:28:00 +0000 Subject: [M3devel] naming conventions for split/composed interfaces? In-Reply-To: References: <06FA077F-C6FB-4E42-B4AE-1A040EE2698E@cs.purdue.edu> <7F9C2510-13AB-4CB0-8C79-4315C75C90E6@cs.purdue.edu> <20080423233243.ijpvrxlgwsw8s4og@mail.elegosoft.com> Message-ID: What cost are you willing to pay? It is EASY to write one simple Ustat.i3 and UstatC.c that is correct for all platforms, totally portable, simple, efficient enough etc. The cost of avoiding the wrapper is pain, uncertainty, much higher risk of the implementation being wrong or becoming silently wrong, though... Well, how about this suggestion? How about we start writing some C code that asserts the correctness of the .i3 files?Or even having the compiler output such C code? Just make sure it compiles? Ustat.i3 would get some directive LIKE: <* PRAGMA C-derived "#include sys/stat.h", "struct stat" *> struct_stat = RECORD ... END The second parameter is the type that the record should "match". This would generate and a compile a file something like: #include #define size(a,b,c) (sizeof((a)(a*)0)->b == c) #define field(a,b) ((a*)0)->b) #define offset(a,b) ((size_t)a) type_size_size(struct stat, 0x123) size(struct stat, st_dev, 8) size(field(struct stat, st_dev), 8) size(field(struct stat, st_ino), 8) offset(field(struct stat, st_dev), 0) offset(field(struct stat, st_ino), 8) etc. where all the numbers on the right are what the compiler computes. This way, the transcription of C into Modula-3 is checked for correctness. It can be optional -- like for cross builds that might have a C compiler or headers/libs. I have to admit, there is an aspect of avoiding C that I really like -- the idea of building one tool for all targets, all in one, no need to get a cross compiler or headers/libs. To me that is a potential big upside to avoiding wrappers. I would even suggest -- can the dtoa.c and hand.c be rewritten in Modula-3. dtoa.c was very very gnarly last I looked. Could be they dropped support for IBM/Cray/VAX and it's simpler now, I don't know. While I like the idea, I would be reluctant because I don't understand the code much. hand.c though, I strongly suspect can be written in perfectly portable efficient Modula-3. It may or MIGHT not compiler down as efficiently, just if the compiler doesn't do a good job, but I don't think, like, "there any layers in the model" that prevent it, like you wouldn't have to do extra heap allocs or copies. You might get some extra array bounds checks, that would be good to avoid introducing. Well, I'm too busy right now, but: 1) I'll maybe the errno wrapper in NT386. As long as you avoid the thread-unsafe library, this area has been stable forever. And building in a dependency on thread safety is a good thing. 2) I'll see about rewriting hand.c in Modula-3 and see if I can convince myself there's no perf loss. 3) I look at gtoa.c to confirm it is still way to gnarly to consider changing. 4) Eventually see about building in this checking. It removes the upside of not having a compiler/headers, that's why optional. 5) Wonder about automating generation of the Modula-3 in the first place? Something like SWIG? I don't know. Problem with #4 and #5 is special cases. Coming up with some mechanized translation that actually exists and works. Gotta run, - Jay CC: wagner at elegosoft.com; m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] naming conventions for split/composed interfaces?Date: Thu, 24 Apr 2008 08:44:57 -0400 Please, avoid C wrappers wherever possible. 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 Apr 24, 2008, at 6:58 AM, Jay wrote: Um..I have spent quite some time reading stat.h. At least 5 minutes. :)I must say, I really really really like the copyout method.Obviously, it goes something like this: struct_stat = RECORD st_dev : uint64_t; st_ino : uint64_t; st_mode : uint64_t; st_nlink : uint64_t; st_uid : uint64_t; st_gid : uint64_t; st_rdev : uint64_t; st_size : uint64_t; st_blksize: uint64_t; st_blocks : uint64_t; st_atime : uint64_t; st_mtime : uint64_t; st_ctime : uint64_t; END; struct_stat_star = UNTRACED REF struct_stat;void copyout(const stat_t* s, m3_stat_t* m){ m->st_ctime = s.st_stime; ...}int m3_stat(const char* path, m3_stat_t* m){ int result; struct stat s; result = m3_stat(path, &s); copyout(&s, m); return result;}and this one type definition and wrapper function is, like, arbitrarily portable to all systems.Quite simple. A little inefficient -- but it's not like the stat call itself won't dwarf the copying.I think I agree merging the files into Umachine.i3.However consider the part of Ustat.i3 other than the struct.The bit masks are probably identical across ALL platforms.The function declarations are.Actually even the struct can often be factored just by giving types like gid_t, ino_t, but I don't think that's worth it.I'd rather uint16_t, uint32_t, uint64_t.So I think moving just the struct into its own file, or using copyout, not a bad idea.Ustat.i3 is not quite the best example.I think a much better one is Upthread.i3.The file is very large and basically I think varies by 3-5 lines per variation.Lastly, you know, I do work to generate the headers kind of, and/or to derive them somewhat automatically.This work should probably be fully automated, at least for test cases, so assert the correctness.You know, write Modula-3 and C code to print field offsets and sizes and verify they are identical.This should aid maintenability. I assert the current system, no matter how the files are laid out, is overly fragile.I assert that transcribing .h files into .i3 files is a very dubious practise.It has an upside of easier cross building -- don't need the platform-specific headers.And it has the upside of not needing to worry about parsing .h files.But it is obviously bad maintainability.Better would be do wrappers like the above, except where perf is critical.Or at least actively (daily) assert the sizes/offsets. Another argument to keep the structure is that is has proven to be easily portable; and we should be very careful to change it.I think the current structure has proven easily copied around and then not fixed and bugs lurking..This is not really my original point, but I have to harp a bit, it's been simmering in my brain a long time.Any time I see header cloning I cringe significantly. Visual Basic and C# have this same problem.- Jay Date: Wed, 23 Apr 2008 23:32:43 +0200 From: wagner at elegosoft.com To: m3devel at elegosoft.com Subject: Re: [M3devel] naming conventions for split/composed interfaces? Quoting Tony Hosking : Basically, I hate the idea of tangling together multiple machine- dependent systems in the same files. Yes, it is verbose with duplicated functionality, but it *is* separable. I can delete one set of files without breaking builds on other targets. I hate the idea of C wrappers even more! So, my position remains that while it is verbose having separate target-specific directories, at least they are independent and isolated -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Apr 25 08:19:05 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 25 Apr 2008 08:19:05 +0200 Subject: [M3devel] naming conventions for split/composed interfaces? In-Reply-To: References: <06FA077F-C6FB-4E42-B4AE-1A040EE2698E@cs.purdue.edu> <7F9C2510-13AB-4CB0-8C79-4315C75C90E6@cs.purdue.edu> <20080423233243.ijpvrxlgwsw8s4og@mail.elegosoft.com> Message-ID: <20080425081905.bibtuvhnhcg8k4wk@mail.elegosoft.com> Quoting Jay : > What cost are you willing to pay? > It is EASY to write one simple Ustat.i3 and UstatC.c that is correct > for all platforms, totally portable, simple, efficient enough etc. > The cost of avoiding the wrapper is pain, uncertainty, much higher > risk of the implementation being wrong or becoming silently wrong, > though... In case of stat, copying the structure may lead to performance bottle- necks in I/O intensive programs (like build systmes etc.). Build systems for example may start by stat-ing ten thousands of files in their first phase. I'd not object to adding something like a generic posix subdir, which could be used for fast porting, but I wouldn't want this to be used for current plaforms if it has performance impacts. > Well, how about this suggestion? > How about we start writing some C code that asserts the correctness > of the .i3 files?Or even having the compiler output such C code? > Just make sure it compiles? This sounds more than what I'd like to do. I think we need to analyze what exactly M3 really needs from the underlying target platform, and automate a way of generating the correct interfaces for that. Something configure-like that will only be used for porting (or checking the correctness of existing interfaces). > Ustat.i3 would get some directive LIKE: > > <* PRAGMA C-derived "#include sys/stat.h", "struct stat" *> > struct_stat = RECORD ... END > > The second parameter is the type that the record should "match". > > This would generate and a compile a file something like: > #include > #define size(a,b,c) (sizeof((a)(a*)0)->b == c) > #define field(a,b) ((a*)0)->b) > #define offset(a,b) ((size_t)a) > > type_size_size(struct stat, 0x123) > size(struct stat, st_dev, 8) > size(field(struct stat, st_dev), 8) > size(field(struct stat, st_ino), 8) > offset(field(struct stat, st_dev), 0) > offset(field(struct stat, st_ino), 8) > etc. > > where all the numbers on the right are what the compiler computes. > > This way, the transcription of C into Modula-3 is checked for correctness. > > It can be optional -- like for cross builds that might have a C > compiler or headers/libs. > I have to admit, there is an aspect of avoiding C that I really like > -- the idea of building one tool for all targets, all in one, no > need to get a cross compiler or headers/libs. To me that is a > potential big upside to avoiding wrappers. > I would even suggest -- can the dtoa.c and hand.c be rewritten in Modula-3. > dtoa.c was very very gnarly last I looked. Could be they dropped > support for IBM/Cray/VAX and it's simpler now, I don't know. While I > like the idea, I would be reluctant because I don't understand the > code much. > hand.c though, I strongly suspect can be written in perfectly > portable efficient Modula-3. There have been some discussions in the past about updating or replacing dtoa.h in M3. Have a look at the mailing list archives before spending too much time on it. > It may or MIGHT not compiler down as efficiently, just if the > compiler doesn't do a good job, but I don't think, like, "there any > layers in the model" that prevent it, like you wouldn't have to do > extra heap allocs or copies. You might get some extra array bounds > checks, that would be good to avoid introducing. > > Well, I'm too busy right now, but: > > 1) I'll maybe the errno wrapper in NT386. As long as you avoid the > thread-unsafe library, this area has been stable forever. > And building in a dependency on thread safety is a good thing. > > 2) I'll see about rewriting hand.c in Modula-3 and see if I can > convince myself there's no perf loss. > > 3) I look at gtoa.c to confirm it is still way to gnarly to consider > changing. > > 4) Eventually see about building in this checking. It removes the > upside of not having a compiler/headers, that's why optional. > > 5) Wonder about automating generation of the Modula-3 in the first > place? Something like SWIG? I don't know. > Problem with #4 and #5 is special cases. Coming up with some > mechanized translation that actually exists and works. SWIG has already been tried at least twice for M3, and found to be somewhat unhandy and insufficient. It does not really speed up the process of getting correct M3 interfaces for C headers IIRC. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Fri Apr 25 08:37:13 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 25 Apr 2008 06:37:13 +0000 Subject: [M3devel] naming conventions for split/composed interfaces? In-Reply-To: <20080425081905.bibtuvhnhcg8k4wk@mail.elegosoft.com> References: <06FA077F-C6FB-4E42-B4AE-1A040EE2698E@cs.purdue.edu> <7F9C2510-13AB-4CB0-8C79-4315C75C90E6@cs.purdue.edu> <20080423233243.ijpvrxlgwsw8s4og@mail.elegosoft.com> <20080425081905.bibtuvhnhcg8k4wk@mail.elegosoft.com> Message-ID: Copying around 64 bytes per stat call is never going to be the bottleneck.I am not 100% sure, but I believe every stat call is akernel call. Data already has to be copied betweenkernel and user mode, and some i/o, possibly cached,has to occur.Maybe if someone stats a bunch of files, and thenstats them many times afterward. I'm all for thin (zero thickness) wrappers, keeping things fast, but header cloning really bugs me. If you really want to stat a lot of files, at somepoint you'll win by using something like opendir/readdirto just get all the data -- given some readdir thatreturns the needed stat information.On Windows this is simply FindFirstFile/FindNextFile. (and yes I realize I'm partly rearranging deck chairs -- the readdir has to return some struct with the same issues as stat, however maybe there'd be knowledge of it operating on larger data and less tendency to slow it down) > generic posix directory to speed ports Sounds like a good compromise.And existing ports could even try it and measure the difference maybe. > swig vs. my compiler-based idea vs. generating some other> way only what is needed Good point. I did some stuff for Cygwin along these linesthat may be close to just right. Fairly simple C code that prints out the Modula-3.Again, what you could do, is in the build, optionallyrecompile/rerun the C and assert the output is unchanged. This is super easy for constants and chosing the rightinteger type for record fields.It is easy enough for getting the record fields in the rightorder, and asserting that you didn't miss any (no holes), thoughI didn't do that (yet). Perhaps I should try that?Come up with reasonably simple very very portable C (probablyc++, with specific reasons) code that prints out..well..some set of .i3 files that bother me.I guess it is fairly scientific, which .i3 files describeC and which Modula-3.It is presence of <* external *>, the types they take and return.Constants, harder to identify mechanically. I also made a large stab to determine exactly what is neededand no or very little more. The Cygwin stuff should be a goodbasis for determing this, except it doesn't use pthreads. Another problem here not yet addressed is picking out functionsignatures. I think some simple uses of C++ templates mightwork here, but I have to experiment. There would still be much duplicity, but I guess generated(and still checked in, and often regenerated), is better thanhand written once and then not checked through time.Granted, if you get Ustat.i3 wrong, you do tend to find andfix the bugs fairly fast, but I'd like "static" checkingto get this stuff right. I'm not going to do much of anything here for now,but maybe I'll get around to it. It depends what bugs me most. :) - Jay > Date: Fri, 25 Apr 2008 08:19:05 +0200> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com> Subject: RE: [M3devel] naming conventions for split/composed interfaces?> > Quoting Jay :> > > What cost are you willing to pay?> > It is EASY to write one simple Ustat.i3 and UstatC.c that is correct > > for all platforms, totally portable, simple, efficient enough etc. > > The cost of avoiding the wrapper is pain, uncertainty, much higher > > risk of the implementation being wrong or becoming silently wrong, > > though...> > In case of stat, copying the structure may lead to performance bottle-> necks in I/O intensive programs (like build systmes etc.). Build> systems for example may start by stat-ing ten thousands of files in> their first phase.> > I'd not object to adding something like a generic posix subdir,> which could be used for fast porting, but I wouldn't want this> to be used for current plaforms if it has performance impacts.> > > Well, how about this suggestion?> > How about we start writing some C code that asserts the correctness > > of the .i3 files?Or even having the compiler output such C code? > > Just make sure it compiles?> > This sounds more than what I'd like to do. I think we need to> analyze what exactly M3 really needs from the underlying target> platform, and automate a way of generating the correct interfaces for> that. Something configure-like that will only be used for porting> (or checking the correctness of existing interfaces).> > > Ustat.i3 would get some directive LIKE:> >> > <* PRAGMA C-derived "#include sys/stat.h", "struct stat" *>> > struct_stat = RECORD ... END> >> > The second parameter is the type that the record should "match".> >> > This would generate and a compile a file something like:> > #include > > #define size(a,b,c) (sizeof((a)(a*)0)->b == c)> > #define field(a,b) ((a*)0)->b)> > #define offset(a,b) ((size_t)a)> >> > type_size_size(struct stat, 0x123)> > size(struct stat, st_dev, 8)> > size(field(struct stat, st_dev), 8)> > size(field(struct stat, st_ino), 8)> > offset(field(struct stat, st_dev), 0)> > offset(field(struct stat, st_ino), 8)> > etc.> >> > where all the numbers on the right are what the compiler computes.> >> > This way, the transcription of C into Modula-3 is checked for correctness.> >> > It can be optional -- like for cross builds that might have a C > > compiler or headers/libs.> > I have to admit, there is an aspect of avoiding C that I really like > > -- the idea of building one tool for all targets, all in one, no > > need to get a cross compiler or headers/libs. To me that is a > > potential big upside to avoiding wrappers.> > I would even suggest -- can the dtoa.c and hand.c be rewritten in Modula-3.> > dtoa.c was very very gnarly last I looked. Could be they dropped > > support for IBM/Cray/VAX and it's simpler now, I don't know. While I > > like the idea, I would be reluctant because I don't understand the > > code much.> > hand.c though, I strongly suspect can be written in perfectly > > portable efficient Modula-3.> > There have been some discussions in the past about updating or> replacing dtoa.h in M3. Have a look at the mailing list archives> before spending too much time on it.> > > It may or MIGHT not compiler down as efficiently, just if the > > compiler doesn't do a good job, but I don't think, like, "there any > > layers in the model" that prevent it, like you wouldn't have to do > > extra heap allocs or copies. You might get some extra array bounds > > checks, that would be good to avoid introducing.> >> > Well, I'm too busy right now, but:> >> > 1) I'll maybe the errno wrapper in NT386. As long as you avoid the > > thread-unsafe library, this area has been stable forever.> > And building in a dependency on thread safety is a good thing.> >> > 2) I'll see about rewriting hand.c in Modula-3 and see if I can > > convince myself there's no perf loss.> >> > 3) I look at gtoa.c to confirm it is still way to gnarly to consider > > changing.> >> > 4) Eventually see about building in this checking. It removes the > > upside of not having a compiler/headers, that's why optional.> >> > 5) Wonder about automating generation of the Modula-3 in the first > > place? Something like SWIG? I don't know.> > Problem with #4 and #5 is special cases. Coming up with some > > mechanized translation that actually exists and works.> > SWIG has already been tried at least twice for M3, and found to be> somewhat unhandy and insufficient. It does not really speed up the> process of getting correct M3 interfaces for C headers IIRC.> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 roland.illig at gmx.de Fri Apr 25 09:20:28 2008 From: roland.illig at gmx.de (Roland Illig) Date: Fri, 25 Apr 2008 08:20:28 +0100 Subject: [M3devel] moving versions into simple text file (sh?) In-Reply-To: <480AF7A4.4060905@gmx.de> References: <480AF7A4.4060905@gmx.de> Message-ID: <4811863C.40506@gmx.de> I'm explaining my code for getting the version numbers into a shell script, since it is not completely obvious. Roland Illig schrieb: > # usage: get_version VARNAME > get_version() { > eval "gv__set=\${$1+set}" This code tests whether VARNAME is already defined. When it is, gv__set will become "set", otherwise the empty string. > if [ "$gv__set" != "set" ]; then > gv__value=`awk '$1 == "'"$1"'" { print $2 }' $root/scripts/version` The awk script compares the first field ($1) of each line with VARNAME, and if they are equal, prints the second field ($2). The funny quotes ("'") are used to insert a shell variable ($1, the first argument to the function) literally into the awk script. > eval "$1=\$gv__value" Finally, the VARNAME variable gets the value that has been read from the file. If there was no value, the empty string is used. > fi > } Roland From hosking at cs.purdue.edu Fri Apr 25 15:53:54 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 25 Apr 2008 09:53:54 -0400 Subject: [M3devel] naming conventions for split/composed interfaces? In-Reply-To: References: <06FA077F-C6FB-4E42-B4AE-1A040EE2698E@cs.purdue.edu> <7F9C2510-13AB-4CB0-8C79-4315C75C90E6@cs.purdue.edu> <20080423233243.ijpvrxlgwsw8s4og@mail.elegosoft.com> <20080425081905.bibtuvhnhcg8k4wk@mail.elegosoft.com> Message-ID: <448E8A93-88BC-495B-A11D-587310A43F39@cs.purdue.edu> Header cloning is the price we pay for straightforward, uncomplicated, untangled, porting. Yes, there is a small amount of effort (usually an hour or so in my experience) putting together the *very few* interfaces to match C headers in order to bring up a new target. The resulting code is easily maintained as a faithful mirror of the original C headers. I really think you are overstating the difficulty here, and as others have observed, this approach has not impeded the development and portability of the system. On Apr 25, 2008, at 2:37 AM, Jay wrote: > Copying around 64 bytes per stat call is never going to be the > bottleneck. > I am not 100% sure, but I believe every stat call is a > kernel call. Data already has to be copied between > kernel and user mode, and some i/o, possibly cached, > has to occur. > Maybe if someone stats a bunch of files, and then > stats them many times afterward. > > I'm all for thin (zero thickness) wrappers, keeping things fast, but > header cloning really bugs me. > > If you really want to stat a lot of files, at some > point you'll win by using something like opendir/readdir > to just get all the data -- given some readdir that > returns the needed stat information. > On Windows this is simply FindFirstFile/FindNextFile. > (and yes I realize I'm partly rearranging deck chairs -- the readdir > has to return > some struct with the same issues as stat, however maybe there'd be > knowledge > of it operating on larger data and less tendency to slow it down) > > > generic posix directory to speed ports > > Sounds like a good compromise. > And existing ports could even try it and measure the difference maybe. > > > swig vs. my compiler-based idea vs. generating some other > > way only what is needed > > Good point. I did some stuff for Cygwin along these lines > that may be close to just right. > > Fairly simple C code that prints out the Modula-3. > Again, what you could do, is in the build, optionally > recompile/rerun the C and assert the output is unchanged. > > This is super easy for constants and chosing the right > integer type for record fields. > It is easy enough for getting the record fields in the right > order, and asserting that you didn't miss any (no holes), though > I didn't do that (yet). > > Perhaps I should try that? > Come up with reasonably simple very very portable C (probably > c++, with specific reasons) code that prints out..well.. > some set of .i3 files that bother me. > I guess it is fairly scientific, which .i3 files describe > C and which Modula-3. > It is presence of <* external *>, the types they take and return. > Constants, harder to identify mechanically. > > I also made a large stab to determine exactly what is needed > and no or very little more. The Cygwin stuff should be a good > basis for determing this, except it doesn't use pthreads. > > Another problem here not yet addressed is picking out function > signatures. I think some simple uses of C++ templates might > work here, but I have to experiment. > > There would still be much duplicity, but I guess generated > (and still checked in, and often regenerated), is better than > hand written once and then not checked through time. > Granted, if you get Ustat.i3 wrong, you do tend to find and > fix the bugs fairly fast, but I'd like "static" checking > to get this stuff right. > > I'm not going to do much of anything here for now, > but maybe I'll get around to it. It depends what bugs me most. :) > > - Jay > > > > > > > > Date: Fri, 25 Apr 2008 08:19:05 +0200 > > From: wagner at elegosoft.com > > To: jayk123 at hotmail.com > > CC: hosking at cs.purdue.edu; m3devel at elegosoft.com > > Subject: RE: [M3devel] naming conventions for split/composed > interfaces? > > > > Quoting Jay : > > > > > What cost are you willing to pay? > > > It is EASY to write one simple Ustat.i3 and UstatC.c that is > correct > > > for all platforms, totally portable, simple, efficient enough etc. > > > The cost of avoiding the wrapper is pain, uncertainty, much higher > > > risk of the implementation being wrong or becoming silently wrong, > > > though... > > > > In case of stat, copying the structure may lead to performance > bottle- > > necks in I/O intensive programs (like build systmes etc.). Build > > systems for example may start by stat-ing ten thousands of files in > > their first phase. > > > > I'd not object to adding something like a generic posix subdir, > > which could be used for fast porting, but I wouldn't want this > > to be used for current plaforms if it has performance impacts. > > > > > Well, how about this suggestion? > > > How about we start writing some C code that asserts the > correctness > > > of the .i3 files?Or even having the compiler output such C code? > > > Just make sure it compiles? > > > > This sounds more than what I'd like to do. I think we need to > > analyze what exactly M3 really needs from the underlying target > > platform, and automate a way of generating the correct interfaces > for > > that. Something configure-like that will only be used for porting > > (or checking the correctness of existing interfaces). > > > > > Ustat.i3 would get some directive LIKE: > > > > > > <* PRAGMA C-derived "#include sys/stat.h", "struct stat" *> > > > struct_stat = RECORD ... END > > > > > > The second parameter is the type that the record should "match". > > > > > > This would generate and a compile a file something like: > > > #include > > > #define size(a,b,c) (sizeof((a)(a*)0)->b == c) > > > #define field(a,b) ((a*)0)->b) > > > #define offset(a,b) ((size_t)a) > > > > > > type_size_size(struct stat, 0x123) > > > size(struct stat, st_dev, 8) > > > size(field(struct stat, st_dev), 8) > > > size(field(struct stat, st_ino), 8) > > > offset(field(struct stat, st_dev), 0) > > > offset(field(struct stat, st_ino), 8) > > > etc. > > > > > > where all the numbers on the right are what the compiler computes. > > > > > > This way, the transcription of C into Modula-3 is checked for > correctness. > > > > > > It can be optional -- like for cross builds that might have a C > > > compiler or headers/libs. > > > I have to admit, there is an aspect of avoiding C that I really > like > > > -- the idea of building one tool for all targets, all in one, no > > > need to get a cross compiler or headers/libs. To me that is a > > > potential big upside to avoiding wrappers. > > > I would even suggest -- can the dtoa.c and hand.c be rewritten > in Modula-3. > > > dtoa.c was very very gnarly last I looked. Could be they dropped > > > support for IBM/Cray/VAX and it's simpler now, I don't know. > While I > > > like the idea, I would be reluctant because I don't understand the > > > code much. > > > hand.c though, I strongly suspect can be written in perfectly > > > portable efficient Modula-3. > > > > There have been some discussions in the past about updating or > > replacing dtoa.h in M3. Have a look at the mailing list archives > > before spending too much time on it. > > > > > It may or MIGHT not compiler down as efficiently, just if the > > > compiler doesn't do a good job, but I don't think, like, "there > any > > > layers in the model" that prevent it, like you wouldn't have to do > > > extra heap allocs or copies. You might get some extra array bounds > > > checks, that would be good to avoid introducing. > > > > > > Well, I'm too busy right now, but: > > > > > > 1) I'll maybe the errno wrapper in NT386. As long as you avoid the > > > thread-unsafe library, this area has been stable forever. > > > And building in a dependency on thread safety is a good thing. > > > > > > 2) I'll see about rewriting hand.c in Modula-3 and see if I can > > > convince myself there's no perf loss. > > > > > > 3) I look at gtoa.c to confirm it is still way to gnarly to > consider > > > changing. > > > > > > 4) Eventually see about building in this checking. It removes the > > > upside of not having a compiler/headers, that's why optional. > > > > > > 5) Wonder about automating generation of the Modula-3 in the first > > > place? Something like SWIG? I don't know. > > > Problem with #4 and #5 is special cases. Coming up with some > > > mechanized translation that actually exists and works. > > > > SWIG has already been tried at least twice for M3, and found to be > > somewhat unhandy and insufficient. It does not really speed up the > > process of getting correct M3 interfaces for C headers IIRC. > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Apr 26 09:17:04 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 26 Apr 2008 09:17:04 +0200 Subject: [M3devel] tinderbox failures / release builds broken Message-ID: <20080426091704.472e30pem8ww8wgs@mail.elegosoft.com> Jay, this seems to have broken all release builds: (+34/18) Lines changed. When Who File Rev +/- Description 2008-04-25 22:33 jkrell cm3/m3-sys/m3cc/src/m3makefile 1.58 34/18 workaround strange problems building gmp/mpfr for NT386GNU as well as non-strange problem building m3cg1.exe (the makefile wants m3cg1. '.exe' is dealt with some other way Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Sat Apr 26 10:03:06 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 26 Apr 2008 08:03:06 +0000 Subject: [M3devel] tinderbox failures / release builds broken In-Reply-To: <20080426091704.472e30pem8ww8wgs@mail.elegosoft.com> References: <20080426091704.472e30pem8ww8wgs@mail.elegosoft.com> Message-ID: oops, sorry, should be ok now > Date: Sat, 26 Apr 2008 09:17:04 +0200 > From: wagner at elegosoft.com > To: jayk123 at hotmail.com > CC: m3devel at elegosoft.com > Subject: tinderbox failures / release builds broken > > Jay, > > this seems to have broken all release builds: > > (+34/18) Lines changed. > When Who File Rev +/- Description > 2008-04-25 22:33 jkrell cm3/m3-sys/m3cc/src/m3makefile 1.58 34/18 > workaround strange problems building gmp/mpfr for NT386GNU as well as > non-strange problem building m3cg1.exe (the makefile wants m3cg1. > '.exe' is dealt with some other way > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Apr 28 18:42:17 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 28 Apr 2008 18:42:17 +0200 Subject: [M3devel] Popup Windows stalling regression tests on WinXP Message-ID: <20080428184217.dizt8loly8go80gg@mail.elegosoft.com> Hi Jay, everytime I have a look why the regression tests haven't terminated yet, I find another popup window with a message like this: cm3.exe has encountered a problem and needs to close. We are sorry for the inconvenience. Any idea how to suppress this kind of error notification? We'll never get reliable regression testing with popup windows :-/ Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Mon Apr 28 23:47:35 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Apr 2008 21:47:35 +0000 Subject: [M3devel] Popup Windows stalling regression tests on WinXP In-Reply-To: <20080428184217.dizt8loly8go80gg@mail.elegosoft.com> References: <20080428184217.dizt8loly8go80gg@mail.elegosoft.com> Message-ID: Olaf, this is a bug and should be fixed.Like someone calling abort or assert(false) or NtRaiseHardError or dereferencing NULL or such.Or skip those tests on NT386 for now.And please provide an easy way to run specific tests.I'm working on adding some tests (ok, just one) and it seems to be a pain.I think it's just cm3 -FA ../../TESTARGS but it wasn't working. Install the debuggers: http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx I install to c:\bin\x86 and c:\bin\amd64, though the default is c:\program files\blah. mkdir c:\symbols this is just for a local cache, not needed but nice cd c:\bin\x86\windbg -o -G -g -y srv*c:\symbols*http://msdl.microsoft.com/download/symbols cm3 When there is a popup, type: ~*k to get all the thread stacks, and see which one is in MessageBox or abort or whatnot. And send the stack? Or all of them if uncertain. You can also make a full or minidump with .dump for someone else to look at. Good to have the cm3.exe and cm3.pdb as well. Or I guess I can/should just fix them.I think I've seen a few of these myself. The stack might not be well displayed by the debugger. It could be this in the toplevel exception handler/watson thingy. Another thing to try is: c:\bin\x86\windbg -I to install windbg as the JIT debugger. That way, some crashes will bring up a debugger, possibly prompting first. I need to make a web page with a Win32 debugging primer at some point. Anyway, I'll try to bump this up in priority. Could be that SetErrorMode(something) quashes them, but that doesn't mean it isn't a bug. Another very good theory is that the "app type", console vs. gui, is relevant. Console apps upon abort() or assert(false) print something to stdout/stderr and then exit, whereas gui apps use MessageBox. The type is determined from the .exe, and you can change it at runtime via a call. Not clear to me which of the various catastrophic errors this is though. I think abort(). - Jay > Date: Mon, 28 Apr 2008 18:42:17 +0200> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Popup Windows stalling regression tests on WinXP> > Hi Jay,> > everytime I have a look why the regression tests haven't terminated> yet, I find another popup window with a message like this:> > cm3.exe has encountered a problem and needs to close.> We are sorry for the inconvenience.> > Any idea how to suppress this kind of error notification?> We'll never get reliable regression testing with popup windows :-/> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 jayk123 at hotmail.com Mon Apr 28 23:56:17 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Apr 2008 21:56:17 +0000 Subject: [M3devel] Popup Windows stalling regression tests on WinXP In-Reply-To: <20080428184217.dizt8loly8go80gg@mail.elegosoft.com> References: <20080428184217.dizt8loly8go80gg@mail.elegosoft.com> Message-ID: truncated and newlines got removed, I wonder if email will ever work.. From: jayk123 at hotmail.comTo: wagner at elegosoft.comCC: m3devel at elegosoft.comSubject: RE: Popup Windows stalling regression tests on WinXPDate: Mon, 28 Apr 2008 21:47:35 +0000 Olaf, this is a bug and should be fixed.Like someone calling abort or assert(false) or NtRaiseHardError or dereferencing NULL or such.Or skip those tests on NT386 for now.And please provide an easy way to run specific tests.I'm working on adding some tests (ok, just one) and it seems to be a pain.I think it's just cm3 -FA ../../TESTARGS but it wasn't working.Install the debuggers: http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx I install to c:\bin\x86 and c:\bin\amd64, though the default is c:\program files\blah. mkdir c:\symbols this is just for a local cache, not needed but nice cd c:\bin\x86\windbg -o -G -g -y srv*c:\symbols*http://msdl.microsoft.com/download/symbols cm3 When there is a popup, type: ~*k to get all the thread stacks, and see which one is in MessageBox or abort or whatnot.And send the stack? Or all of them if uncertain.You can also make a full or minidump with .dump for someone else to look at.Good to have the cm3.exe and cm3.pdb as well.Or I guess I can/should just fix them.I think I've seen a few of these myself. The stack might not be well displayed by the debugger.It could be this in the toplevel exception handler/watson thingy. Another thing to try is:c:\bin\x86\windbg -I to install windbg as the JIT debugger. That way, some crashes will bring up a debugger, possibly prompting first. I need to make a web page with a Win32 debugging primer at some point.Anyway, I'll try to bump this up in priority. Could be that SetErrorMode(something) quashes them, but that doesn't mean it isn't a bug.Another very good theory is that the "app type", console vs. gui, is relevant.Console apps upon abort() or assert(false) print something to stdout/stderr and then exit, whereas gui appsuse MessageBox. The type is determined from the .exe, and you can change it at runtime via a call. Not clear to me which of the various catastrophic errors this is though. I think abort(). - Jay > Date: Mon, 28 Apr 2008 18:42:17 +0200> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Popup Windows stalling regression tests on WinXP> > Hi Jay,> > everytime I have a look why the regression tests haven't terminated> yet, I find another popup window with a message like this:> > cm3.exe has encountered a problem and needs to close.> We are sorry for the inconvenience.> > Any idea how to suppress this kind of error notification?> We'll never get reliable regression testing with popup windows :-/> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 dabenavidesd at yahoo.es Tue Apr 29 04:26:43 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 29 Apr 2008 04:26:43 +0200 (CEST) Subject: [M3devel] Popup Windows stalling regression tests on WinXP In-Reply-To: Message-ID: <700233.58102.qm@web27105.mail.ukl.yahoo.com> Hi all: What test(s) it fails? What happens if you append the options the compiler has for building on Win boxes: -console produce a Windows CONSOLE subsystem program -gui produce a Windows GUI subsystem program -windows produce a Windows GUI subsystem program About the options above , does the last two: - gui and -windows have the same meaning? Should the NT386 cm3 compiler build with any of these options? What does the compiler know about this options? That errors should be just understood by the runtime (I think that's the beauty of the SAFE subset of the language), the system (Nt386) M3 runtime doesn't have the capacity to avoid the segment violation, etc of the program before it gets killed by the OS? Thanks Jay escribi?: .hmmessage P { margin:0px; padding:0px } body.hmmessage { FONT-SIZE: 10pt; FONT-FAMILY:Tahoma } truncated and newlines got removed, I wonder if email will ever work.. --------------------------------- From: jayk123 at hotmail.com To: wagner at elegosoft.com CC: m3devel at elegosoft.com Subject: RE: Popup Windows stalling regression tests on WinXP Date: Mon, 28 Apr 2008 21:47:35 +0000 .ExternalClass .EC_hmmessage P {padding:0px;} .ExternalClass body.EC_hmmessage {font-size:10pt;font-family:Tahoma;} Olaf, this is a bug and should be fixed. Like someone calling abort or assert(false) or NtRaiseHardError or dereferencing NULL or such. Or skip those tests on NT386 for now. And please provide an easy way to run specific tests. I'm working on adding some tests (ok, just one) and it seems to be a pain. I think it's just cm3 -FA ../../TESTARGS but it wasn't working. Install the debuggers: http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx I install to c:\bin\x86 and c:\bin\amd64, though the default is c:\program files\blah. mkdir c:\symbols this is just for a local cache, not needed but nice cd c:\bin\x86\windbg -o -G -g -y srv*c:\symbols*http://msdl.microsoft.com/download/symbols cm3 When there is a popup, type: ~*k to get all the thread stacks, and see which one is in MessageBox or abort or whatnot. And send the stack? Or all of them if uncertain. You can also make a full or minidump with .dump for someone else to look at. Good to have the cm3.exe and cm3.pdb as well. Or I guess I can/should just fix them. I think I've seen a few of these myself. The stack might not be well displayed by the debugger. It could be this in the toplevel exception handler/watson thingy. Another thing to try is: c:\bin\x86\windbg -I to install windbg as the JIT debugger. That way, some crashes will bring up a debugger, possibly prompting first. I need to make a web page with a Win32 debugging primer at some point. Anyway, I'll try to bump this up in priority. Could be that SetErrorMode(something) quashes them, but that doesn't mean it isn't a bug. Another very good theory is that the "app type", console vs. gui, is relevant. Console apps upon abort() or assert(false) print something to stdout/stderr and then exit, whereas gui apps use MessageBox. The type is determined from the .exe, and you can change it at runtime via a call. Not clear to me which of the various catastrophic errors this is though. I think abort(). - Jay --------------------------------- > Date: Mon, 28 Apr 2008 18:42:17 +0200 > From: wagner at elegosoft.com > To: jayk123 at hotmail.com > CC: m3devel at elegosoft.com > Subject: Popup Windows stalling regression tests on WinXP > > Hi Jay, > > everytime I have a look why the regression tests haven't terminated > yet, I find another popup window with a message like this: > > cm3.exe has encountered a problem and needs to close. > We are sorry for the inconvenience. > > Any idea how to suppress this kind of error notification? > We'll never get reliable regression testing with popup windows :-/ > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > --------------------------------- Yahoo! Solidario. Intercambia los objetos que ya no necesitas y ayuda a mantener un entorno m?s ecol?gico. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Apr 29 04:36:25 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 29 Apr 2008 02:36:25 +0000 Subject: [M3devel] Popup Windows stalling regression tests on WinXP In-Reply-To: <700233.58102.qm@web27105.mail.ukl.yahoo.com> References: <700233.58102.qm@web27105.mail.ukl.yahoo.com> Message-ID: I'd bet the correct options are already in use. Otherwise functionality would be badly messed up. At least for cm3.exe. MAYBE not the tests. -gui and -windows show the same meaning below. You'd have to read the code. This is an area that needs repair for NT386GNU and NT386MINGNU, but it should be ok for NT386. What the compiler should know about these is how it marks the "system" in the resulting .exe. (It is meaningless for .dlls.) It's just one field in the .exe, via a switch to the linker. Oh, and I guess there is mainCRTStartup vs. WinMainCRTStartup, which drags in different associated data, to inform the C runtime as to your type. However...I'm sure you can mix and match these. A GUI app can start with main, they just don't tend to. main and WinMain have different signatures, but mainCRTStartup and WinMainCRTStartup do not. They both take no parameters and get their data from GetCommandLine, GetStartupInfo, GetEnvironmentVariables, etc. > That errors should be just understood by the runtime Maybe. > the system (Nt386) M3 runtime doesn't have the capacity to > avoid the segment violation, etc of the program before it gets killed by the OS? It probably does. It depends, but maybe. Best just to avoid them if possible. I realize there could be tests that want to deliberately dereference NULL to test the runtime handling.It might be viable to have runtime hooks for testing. Maybe that are only supported in standalone() or something. I'll have to look into it. I have seen errors like this running the tests but I have ignored them before. - Jay Date: Tue, 29 Apr 2008 04:26:43 +0200From: dabenavidesd at yahoo.esSubject: Re: [M3devel] Popup Windows stalling regression tests on WinXPTo: jayk123 at hotmail.com; wagner at elegosoft.comCC: m3devel at elegosoft.comHi all:What test(s) it fails? What happens if you append the options the compiler has for building on Win boxes:-console produce a Windows CONSOLE subsystem program-gui produce a Windows GUI subsystem program-windows produce a Windows GUI subsystem programAbout the options above , does the last two: - gui and -windows have the same meaning? Should the NT386 cm3 compiler build with any of these options? What does the compiler know about this options?That errors should be just understood by the runtime (I think that's the beauty of the SAFE subset of the language), the system (Nt386) M3 runtime doesn't have the capacity to avoid the segment violation, etc of the program before it gets killed by the OS?ThanksJay escribi?: truncated and newlines got removed, I wonder if email will ever work.. From: jayk123 at hotmail.comTo: wagner at elegosoft.comCC: m3devel at elegosoft.comSubject: RE: Popup Windows stalling regression tests on WinXPDate: Mon, 28 Apr 2008 21:47:35 +0000 Olaf, this is a bug and should be fixed.Like someone calling abort or assert(false) or NtRaiseHardError or dereferencing NULL or such.Or skip those tests on NT386 for now.And please provide an easy way to run specific tests.I'm working on adding some tests (ok, just one) and it seems to be a pain.I think it's just cm3 -FA ../../TESTARGS but it wasn't working.Install the debuggers: http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx I install to c:\bin\x86 and c:\bin\amd64, though the default is c:\program files\blah. mkdir c:\symbols this is just for a local cache, not needed but nice cd c:\bin\x86\windbg -o -G -g -y srv*c:\symbols*http://msdl.microsoft.com/download/symbols cm3 When there is a popup, type: ~*k to get all the thread stacks, and see which one is in MessageBox or abort or whatnot.And send the stack? Or all of them if uncertain.You can also make a full or minidump with .dump for someone else to look at.Good to have the cm3.exe and cm3.pdb as well.Or I guess I can/should just fix them.I think I've seen a few of these myself. The stack might not be well displayed by the debugger.It could be this in the toplevel exception handler/watson thingy. Another thing to try is:c:\bin\x86\windbg -I to install windbg as the JIT debugger. That way, some crashes will bring up a debugger, possibly prompting first. I need to make a web page with a Win32 debugging primer at some point.Anyway, I'll try to bump this up in priority. Could be that SetErrorMode(something) quashes them, but that doesn't mean it isn't a bug.Another very good theory is that the "app type", console vs. gui, is relevant.Console apps upon abort() or assert(false) print something to stdout/stderr and then exit, whereas gui appsuse MessageBox. The type is determined from the .exe, and you can change it at runtime via a call. Not clear to me which of the various catastrophic errors this is though. I think abort(). - Jay > Date: Mon, 28 Apr 2008 18:42:17 +0200> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Popup Windows stalling regression tests on WinXP> > Hi Jay,> > everytime I have a look why the regression tests haven't terminated> yet, I find another popup window with a message like this:> > cm3.exe has encountered a problem and needs to close.> We are sorry for the inconvenience.> > Any idea how to suppress this kind of error notification?> We'll never get reliable regression testing with popup windows :-/> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> Yahoo! Solidario.Intercambia los objetos que ya no necesitas y ayuda a mantener un entorno m?s ecol?gico. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Apr 29 13:51:20 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 29 Apr 2008 13:51:20 +0200 Subject: [M3devel] Popup Windows stalling regression tests on WinXP In-Reply-To: References: <20080428184217.dizt8loly8go80gg@mail.elegosoft.com> Message-ID: <20080429135120.m5413443cwo884so@mail.elegosoft.com> Sorry, I currently have neither the time to install debuggers on my slow VM machine nor to chase after such bugs. What I hoped is that there is some system switch that turns off all such popups. If there is not, there may not be much further progress from me for some time. If I start a program like the compiler without any GUI from the command line, I do not expect to get any popup boxes on some unmonitored server machine. It will just not work this way. Even if I found and fixed this special problem now, we'll run into the next one some time later when the tests are hanging again... Olaf PS: As for running only one test with the m3tests makefile, I simply switch off most of the definitions with `if "" ... end' and copy the interesting line just before. Quoting Jay : > Olaf, this is a bug and should be fixed.Like someone calling abort > or assert(false) or NtRaiseHardError or dereferencing NULL or > such.Or skip those tests on NT386 for now.And please provide an easy > way to run specific tests.I'm working on adding some tests (ok, > just one) and it seems to be a pain.I think it's just cm3 -FA > ../../TESTARGS but it wasn't working. > Install the debuggers: > http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx > > I install to c:\bin\x86 and c:\bin\amd64, though the default is > c:\program files\blah. mkdir c:\symbols this is just for a local > cache, not needed but nice > > cd > c:\bin\x86\windbg -o -G -g -y > srv*c:\symbols*http://msdl.microsoft.com/download/symbols cm3 > > When there is a popup, type: > > ~*k > to get all the thread stacks, and see which one is in MessageBox or > abort or whatnot. > And send the stack? Or all of them if uncertain. > You can also make a full or minidump with .dump for someone else to look at. > Good to have the cm3.exe and cm3.pdb as well. > Or I guess I can/should just fix them.I think I've seen a few of > these myself. > > The stack might not be well displayed by the debugger. > It could be this in the toplevel exception handler/watson thingy. > > Another thing to try is: > c:\bin\x86\windbg -I > > to install windbg as the JIT debugger. That way, some crashes will > bring up a debugger, possibly prompting first. > > I need to make a web page with a Win32 debugging primer at some point. > Anyway, I'll try to bump this up in priority. > > Could be that SetErrorMode(something) quashes them, but that doesn't > mean it isn't a bug. > Another very good theory is that the "app type", console vs. gui, is > relevant. > Console apps upon abort() or assert(false) print something to > stdout/stderr and then exit, whereas gui apps > use MessageBox. The type is determined from the .exe, and you can > change it at runtime via a call. > > Not clear to me which of the various catastrophic errors this is > though. I think abort(). > - Jay > > > >> Date: Mon, 28 Apr 2008 18:42:17 +0200> From: wagner at elegosoft.com> >> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Popup >> Windows stalling regression tests on WinXP> > Hi Jay,> > everytime >> I have a look why the regression tests haven't terminated> yet, I >> find another popup window with a message like this:> > cm3.exe has >> encountered a problem and needs to close.> We are sorry for the >> inconvenience.> > Any idea how to suppress this kind of error >> notification?> We'll never get reliable regression testing with >> popup windows :-/> > Olaf> -- > Olaf Wagner -- elego Software >> Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >> Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: >> +49 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 dabenavidesd at yahoo.es Tue Apr 29 14:46:31 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 29 Apr 2008 14:46:31 +0200 (CEST) Subject: [M3devel] Popup Windows stalling regression tests on WinXP In-Reply-To: <20080429135120.m5413443cwo884so@mail.elegosoft.com> Message-ID: <444151.41574.qm@web27109.mail.ukl.yahoo.com> Hi all: Olaf, but in the case is not even the cm3 process, but a sub process of it, maybe the linker or/and the assembler (what VS version do you have?) which in turn throws the fault, how do you know from sure is cm3 only causing that?, Can you check the label of "Click here for more information". Then you can click on see the files involved in the fault. There you should see the list of files like dll or lib and executable involved, can you send that info? Thanks Olaf Wagner wrote: Sorry, I currently have neither the time to install debuggers on my slow VM machine nor to chase after such bugs. What I hoped is that there is some system switch that turns off all such popups. If there is not, there may not be much further progress from me for some time. If I start a program like the compiler without any GUI from the command line, I do not expect to get any popup boxes on some unmonitored server machine. It will just not work this way. Even if I found and fixed this special problem now, we'll run into the next one some time later when the tests are hanging again... Olaf PS: As for running only one test with the m3tests makefile, I simply switch off most of the definitions with `if "" ... end' and copy the interesting line just before. Quoting Jay : > Olaf, this is a bug and should be fixed.Like someone calling abort > or assert(false) or NtRaiseHardError or dereferencing NULL or > such.Or skip those tests on NT386 for now.And please provide an easy > way to run specific tests.I'm working on adding some tests (ok, > just one) and it seems to be a pain.I think it's just cm3 -FA > ../../TESTARGS but it wasn't working. > Install the debuggers: > http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx > > I install to c:\bin\x86 and c:\bin\amd64, though the default is > c:\program files\blah. mkdir c:\symbols this is just for a local > cache, not needed but nice > > cd > c:\bin\x86\windbg -o -G -g -y > srv*c:\symbols*http://msdl.microsoft.com/download/symbols cm3 > > When there is a popup, type: > > ~*k > to get all the thread stacks, and see which one is in MessageBox or > abort or whatnot. > And send the stack? Or all of them if uncertain. > You can also make a full or minidump with .dump for someone else to look at. > Good to have the cm3.exe and cm3.pdb as well. > Or I guess I can/should just fix them.I think I've seen a few of > these myself. > > The stack might not be well displayed by the debugger. > It could be this in the toplevel exception handler/watson thingy. > > Another thing to try is: > c:\bin\x86\windbg -I > > to install windbg as the JIT debugger. That way, some crashes will > bring up a debugger, possibly prompting first. > > I need to make a web page with a Win32 debugging primer at some point. > Anyway, I'll try to bump this up in priority. > > Could be that SetErrorMode(something) quashes them, but that doesn't > mean it isn't a bug. > Another very good theory is that the "app type", console vs. gui, is > relevant. > Console apps upon abort() or assert(false) print something to > stdout/stderr and then exit, whereas gui apps > use MessageBox. The type is determined from the .exe, and you can > change it at runtime via a call. > > Not clear to me which of the various catastrophic errors this is > though. I think abort(). > - Jay > > > >> Date: Mon, 28 Apr 2008 18:42:17 +0200> From: wagner at elegosoft.com> >> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Popup >> Windows stalling regression tests on WinXP> > Hi Jay,> > everytime >> I have a look why the regression tests haven't terminated> yet, I >> find another popup window with a message like this:> > cm3.exe has >> encountered a problem and needs to close.> We are sorry for the >> inconvenience.> > Any idea how to suppress this kind of error >> notification?> We'll never get reliable regression testing with >> popup windows :-/> > Olaf> -- > Olaf Wagner -- elego Software >> Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >> Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: >> +49 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 --------------------------------- Enviado desde Correo Yahoo! La bandeja de entrada m?s inteligente. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Apr 29 16:00:27 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 29 Apr 2008 16:00:27 +0200 Subject: [M3devel] Popup Windows stalling regression tests on WinXP In-Reply-To: <444151.41574.qm@web27109.mail.ukl.yahoo.com> References: <444151.41574.qm@web27109.mail.ukl.yahoo.com> Message-ID: <20080429160027.hp9wb3dhc0g0kkko@mail.elegosoft.com> Quoting "Daniel Alejandro Benavides D." : > Hi all: > Olaf, but in the case is not even the cm3 process, but a sub process > of it, maybe the linker or/and the assembler (what VS version do > you have?) which in turn throws the fault, how do you know from > sure is cm3 only causing that?, Can you check the label of "Click > here for more information". Then you can click on see the files > involved in the fault. There you should see the list of files like > dll or lib and executable involved, can you send that info? I'll restart the tests after some more obvious fixes later this evening and may be able to send more information tomorrow. IIRC there was no label `click here for more information', but just `send report to Microsoft' and `do not send'. Currently we're working hard on a completely different release... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dabenavidesd at yahoo.es Tue Apr 29 16:47:23 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 29 Apr 2008 16:47:23 +0200 (CEST) Subject: [M3devel] Popup Windows stalling regression tests on WinXP In-Reply-To: <20080429160027.hp9wb3dhc0g0kkko@mail.elegosoft.com> Message-ID: <495318.48565.qm@web27105.mail.ukl.yahoo.com> Hi all: Olaf, I don't have the Win box here (just a Kubuntu one). But even if you don't want to send the file, one can see the report file in a window. Should be with two steps: The first click on the blue label "Click here " in the first pop up window. That throws another window with a label that you can click-on and actually see it Well I found with google the instruction to disable that error pop up: http://pcsupport.about.com/od/windowsxp/ht/disableerror.htm I hope this helps to you. Thanks Olaf Wagner escribi?: Quoting "Daniel Alejandro Benavides D." : > Hi all: > Olaf, but in the case is not even the cm3 process, but a sub process > of it, maybe the linker or/and the assembler (what VS version do > you have?) which in turn throws the fault, how do you know from > sure is cm3 only causing that?, Can you check the label of "Click > here for more information". Then you can click on see the files > involved in the fault. There you should see the list of files like > dll or lib and executable involved, can you send that info? I'll restart the tests after some more obvious fixes later this evening and may be able to send more information tomorrow. IIRC there was no label `click here for more information', but just `send report to Microsoft' and `do not send'. Currently we're working hard on a completely different release... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 --------------------------------- Enviado desde Correo Yahoo! La bandeja de entrada m?s inteligente. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Apr 29 17:11:17 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 29 Apr 2008 17:11:17 +0200 Subject: [M3devel] Popup Windows stalling regression tests on WinXP In-Reply-To: <495318.48565.qm@web27105.mail.ukl.yahoo.com> References: <495318.48565.qm@web27105.mail.ukl.yahoo.com> Message-ID: <20080429171117.oopp3fpcpc84ccwk@mail.elegosoft.com> Quoting "Daniel Alejandro Benavides D." : > Hi all: > Olaf, I don't have the Win box here (just a Kubuntu one). But even > if you don't want to send the file, one can see the report file in > a window. Should be with two steps: The first click on the blue > label "Click here " in the first pop up window. That throws another > window with a label that you can click-on and actually see it > Well I found with google the instruction to disable that error pop up: > http://pcsupport.about.com/od/windowsxp/ht/disableerror.htm > I hope this helps to you. Thanks, that sounds good, I'll try it tonight. Olaf > > Thanks > > Olaf Wagner escribi?: Quoting "Daniel > Alejandro Benavides D." : > >> Hi all: >> Olaf, but in the case is not even the cm3 process, but a sub process >> of it, maybe the linker or/and the assembler (what VS version do >> you have?) which in turn throws the fault, how do you know from >> sure is cm3 only causing that?, Can you check the label of "Click >> here for more information". Then you can click on see the files >> involved in the fault. There you should see the list of files like >> dll or lib and executable involved, can you send that info? > > I'll restart the tests after some more obvious fixes later this > evening and may be able to send more information tomorrow. > IIRC there was no label `click here for more information', but > just `send report to Microsoft' and `do not send'. > > Currently we're working hard on a completely different release... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > > > > --------------------------------- > > Enviado desde Correo Yahoo! > La bandeja de entrada m?s inteligente. > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Tue Apr 29 17:52:24 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 29 Apr 2008 11:52:24 -0400 Subject: [M3devel] Your recent change to parse.c Message-ID: I don't understand your change to parse.c re TREE_PUBLIC being set on procedure declarations. TREE_PUBLIC just means that it is possible to call the procedure from outside the current compilation unit. It has nothing to do with intra-library visibility. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Apr 29 23:38:14 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 29 Apr 2008 21:38:14 +0000 Subject: [M3devel] Popup Windows stalling regression tests on WinXP In-Reply-To: <20080429171117.oopp3fpcpc84ccwk@mail.elegosoft.com> References: <495318.48565.qm@web27105.mail.ukl.yahoo.com> <20080429171117.oopp3fpcpc84ccwk@mail.elegosoft.com> Message-ID: Yes, this might be it. My x86 Windows machine is out on loan this week, my AMD64 Windows machine needed a reinstall, and I was deep into debugging the AMD64_LINUX problem (on same machine, multi-boot), so I punted. Now I've reinstalled AMD64 Windows and can debug to see what the problem is, to decide if it is quashable..There should be a way without global changes to the machine, but if that's ok, ok. (If this even it.) - Jay> Date: Tue, 29 Apr 2008 17:11:17 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] Popup Windows stalling regression tests on WinXP> > Quoting "Daniel Alejandro Benavides D." :> > > Hi all:> > Olaf, I don't have the Win box here (just a Kubuntu one). But even > > if you don't want to send the file, one can see the report file in > > a window. Should be with two steps: The first click on the blue > > label "Click here " in the first pop up window. That throws another > > window with a label that you can click-on and actually see it> > Well I found with google the instruction to disable that error pop up:> > http://pcsupport.about.com/od/windowsxp/ht/disableerror.htm> > I hope this helps to you.> > Thanks, that sounds good, I'll try it tonight.> > Olaf> > >> > Thanks> >> > Olaf Wagner escribi?: Quoting "Daniel > > Alejandro Benavides D." :> >> >> Hi all:> >> Olaf, but in the case is not even the cm3 process, but a sub process> >> of it, maybe the linker or/and the assembler (what VS version do> >> you have?) which in turn throws the fault, how do you know from> >> sure is cm3 only causing that?, Can you check the label of "Click> >> here for more information". Then you can click on see the files> >> involved in the fault. There you should see the list of files like> >> dll or lib and executable involved, can you send that info?> >> > I'll restart the tests after some more obvious fixes later this> > evening and may be able to send more information tomorrow.> > IIRC there was no label `click here for more information', but> > just `send report to Microsoft' and `do not send'.> >> > Currently we're working hard on a completely different release...> >> > Olaf> > --> > Olaf Wagner -- elego Software Solutions GmbH> > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> >> >> >> >> > ---------------------------------> >> > Enviado desde Correo Yahoo!> > La bandeja de entrada m?s inteligente.> >> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 jayk123 at hotmail.com Tue Apr 29 23:57:45 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 29 Apr 2008 21:57:45 +0000 Subject: [M3devel] Your recent change to parse.c In-Reply-To: References: Message-ID: Tony, this is a serious problem on AMD64_LINUX.It is not a problem at all on Win32, as Win32 has amuch better codegen model. It's amazing how Linux works.. Look at the .ms file for ThreadPThread.I looked on AMD64_LINUX and LINUXLIBC6. ThreadPThread__InitMutex's call to its own finallyblock goes through the PLT and on AMD64_LINUX the static linkin r10 is trashed. It's possible that if you turn on optimizations, the finallyblock is inlined and that hides the problem, but you can'tcount on that. I was experimenting with another fix at the same time,that of using -fvisibility=hidden on m3cg, butto me that seems more like a C/C++ front end switch,even though cm3cg supports it. I can try again and carefully tweak the two variables,see if -fvisibility=hidden suffices. At the levelcm3cg operates though, it marks the visibility of everythingexplicitly, so again, I think my fix is the way. As well calls within a file to functions within that filethat aren't in an interface are going through the PLT.This is just wasteful. They shouldn't even go through the PLT for calls within thesame "library" (ie: m3core to m3core, libm3 to libm3). What such indirect calls "buy" is that, e.g. the .exe or libm3can replace functions in m3core, or such, and function pointerequality might be achieved. I think the "interposition" featureis widely accepted on Linux, though it is dodgy.I think on Linux going through the PLT for exported functions mightbe the norm. I'll have to read up more. But going through the PLTfor unexported functions is not the norm. Documentation stronglyencourages marking visibility and saving the PLT indirection. In C/C++ there's further problems of name uniquess of unexportedfunctions across the dynamic link. I believe Modula-3 deals with that,since pretty much every function in the system gets a unique name,exported or not. One or the other or both these changes (public = exported,or -fvisibilit=hidden) optimizes those calls. In general going through the PLT is very wasteful whenit isn't necessary. There's a bunch of "literature" aboutthis on the web. On Windows, to call a function Foo, you just call Foo.If Foo ends up imported, the linker generates a single instructionfunction for you, Foo, that jumps through __imp__Foo.If you are absolutely sure Foo will be imported and want tooptimize a little, you can mark Foo as __declspec(dllimport),however for functions this is totally optional. To export functions, you either mark them __declspec(dllexport)or list them in a .def file. For C++, .def files are a pain, butfor C they work just fine, or better. For importing data, you pretty much have to mark it as __declspec(dllimport).Importing data is rare.gcc/ld on Windows have some hack to make this easier that I'm not familiar with. So in the absence of importing data, there is just one codegenmodel that is acceptable -- call Foo.Most function calls, theoretically, are not imported, and thisends up as a normal direct call. There may be issues of position-independence, but on AMD64 thisis not relevant. On AMD64_NT, I believe the vast majority ofcode is naturally position-indendent via RIP-relative addressing.It is true that things like vtables might have relocs.I think that is unfortunate. It would be nice to have 100%position independence for .dlls and .exes. On Linux, if you are compiling for a .dll, you must be position-independent,I think fully, and all function calls by default go through the PLT.Maybe to statics don't. But just sharing across two source files does.Every call is therefore indirect, subject to loader machinations ateither load or first-call time, and "interposable" -- someone elsecan export a function of the same name and take over the function.As well, someone else can call these internal functions more easilythan otherwise. Granted, anyone can call any of your code at any time, justby jumping to it. But symbolic exports are considered more attackablesurface area than random code sitting in memory. If you don't use -fPIC, I think all calls are direct.And you can't link into a .dll. And then, really, the truth is in between.Individual calls can be marked one way or the other. But Modula-3 is marking everything as public, exported, subjectto dynamic linking, called through the PLT. As to why only AMD64_LINUX is seeing this, I don't know.I'd have to check how the static link is passed on others andif the loader preserves it. Could be it is an extra parameteron the stack, since x86 has so few registers. Could be AMD64_LINUX could/should pass it another way, butreally, avoiding the PLT for unexported functions seems likepure goodness. I was quite surprised and dismayed to learn about all this lastnight when I was debugging. Why must inline function bodies for unexported functions be preservedanyway? They are just dead code, right? Is there another way to preserve them? If it is <*inline*> on the implementation but listed in the *.i3 file, that should be public/exported. Is it not? I was able to build LINUXLIBC6 this way as far as building on AMD64 gets, which is pretty far -- eventually failing for lack of some X .libs. Oh, I guess I should be sure optimization is on? I didn't twiddle that. I can try again. - Jay From: hosking at cs.purdue.eduTo: jkrell at elegosoft.comDate: Tue, 29 Apr 2008 11:52:24 -0400CC: m3devel at elegosoft.comSubject: [M3devel] Your recent change to parse.c I don't understand your change to parse.c re TREE_PUBLIC being set on procedure declarations. TREE_PUBLIC just means that it is possible to call the procedure from outside the current compilation unit. It has nothing to do with intra-library visibility. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Apr 30 00:01:51 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 29 Apr 2008 22:01:51 +0000 Subject: [M3devel] Popup Windows stalling regression tests on WinXP In-Reply-To: References: <495318.48565.qm@web27105.mail.ukl.yahoo.com> <20080429171117.oopp3fpcpc84ccwk@mail.elegosoft.com> Message-ID: ps: Olaf, the debugger install is incredibly fast and small. This isn't Visual Studio. I get, but hadn't previously considered, that future regressions would hang the machine, so a fix is only "temporary", but hey...maybe a process needs to monitor the tests and kill them if they take too long? SetErrorMode will probably fix this, now that I think more. We can add a switch to cm3 and it can call that on itself, and it always gets inherited by child processes. Or we can have a trivial wrapper .exe to run the tests, if the switch to cm3 is not liked. But I have to test it out. Suggest an .exe or switch name? :) If indeed it is SetErrorMode, I'd do seterrormode.exe Though this is a low level name. It could be testwrapper.exe or quashpopups.exe. -Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Tue, 29 Apr 2008 21:38:14 +0000Subject: Re: [M3devel] Popup Windows stalling regression tests on WinXP Yes, this might be it.My x86 Windows machine is out on loan this week, my AMD64 Windows machine needed a reinstall, and I was deep into debugging the AMD64_LINUX problem (on same machine, multi-boot), so I punted. Now I've reinstalled AMD64 Windows and can debug to see what the problem is, to decide if it is quashable..There should be a way without global changes to the machine, but if that's ok, ok. (If this even it.) - Jay> Date: Tue, 29 Apr 2008 17:11:17 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] Popup Windows stalling regression tests on WinXP> > Quoting "Daniel Alejandro Benavides D." :> > > Hi all:> > Olaf, I don't have the Win box here (just a Kubuntu one). But even > > if you don't want to send the file, one can see the report file in > > a window. Should be with two steps: The first click on the blue > > label "Click here " in the first pop up window. That throws another > > window with a label that you can click-on and actually see it> > Well I found with google the instruction to disable that error pop up:> > http://pcsupport.about.com/od/windowsxp/ht/disableerror.htm> > I hope this helps to you.> > Thanks, that sounds good, I'll try it tonight.> > Olaf> > >> > Thanks> >> > Olaf Wagner escribi?: Quoting "Daniel > > Alejandro Benavides D." :> >> >> Hi all:> >> Olaf, but in the case is not even the cm3 process, but a sub process> >> of it, maybe the linker or/and the assembler (what VS version do> >> you have?) which in turn throws the fault, how do you know from> >> sure is cm3 only causing that?, Can you check the label of "Click> >> here for more information". Then you can click on see the files> >> involved in the fault. There you should see the list of files like> >> dll or lib and executable involved, can you send that info?> >> > I'll restart the tests after some more obvious fixes later this> > evening and may be able to send more information tomorrow.> > IIRC there was no label `click here for more information', but> > just `send report to Microsoft' and `do not send'.> >> > Currently we're working hard on a completely different release...> >> > Olaf> > --> > Olaf Wagner -- elego Software Solutions GmbH> > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> >> >> >> >> > ---------------------------------> >> > Enviado desde Correo Yahoo!> > La bandeja de entrada m?s inteligente.> >> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 jayk123 at hotmail.com Wed Apr 30 00:28:57 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 29 Apr 2008 22:28:57 +0000 Subject: [M3devel] Your recent change to parse.c In-Reply-To: References: Message-ID: simply: probably: calls to finally blocks must not go through PLT definitely: calls to finally blocks must successfully pass the static link (assuming any locals/parameters are used, and don't bother otherwise); perhaps they just be inlined and not even calls; of course it's a bit more than that, I'd have to try except and actually raising exceptions, but as a start, successful runs of finally blocks need to work, they don't currently on AMD64 due to the call through PLT trashing r10 optionally: calls through PLT should be in general decreased as they are just very wasteful; it's disheartening to realize how it currently is inlines that are declared in an .i3 should be callable from other .m3 files in the same "library" and even exportable and callable outside the .dll/.so - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; jkrell at elegosoft.comDate: Tue, 29 Apr 2008 21:57:45 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] Your recent change to parse.c Tony, this is a serious problem on AMD64_LINUX.It is not a problem at all on Win32, as Win32 has amuch better codegen model. It's amazing how Linux works..Look at the .ms file for ThreadPThread.I looked on AMD64_LINUX and LINUXLIBC6.ThreadPThread__InitMutex's call to its own finallyblock goes through the PLT and on AMD64_LINUX the static linkin r10 is trashed.It's possible that if you turn on optimizations, the finallyblock is inlined and that hides the problem, but you can'tcount on that.I was experimenting with another fix at the same time,that of using -fvisibility=hidden on m3cg, butto me that seems more like a C/C++ front end switch,even though cm3cg supports it.I can try again and carefully tweak the two variables,see if -fvisibility=hidden suffices. At the levelcm3cg operates though, it marks the visibility of everythingexplicitly, so again, I think my fix is the way.As well calls within a file to functions within that filethat aren't in an interface are going through the PLT.This is just wasteful.They shouldn't even go through the PLT for calls within thesame "library" (ie: m3core to m3core, libm3 to libm3).What such indirect calls "buy" is that, e.g. the .exe or libm3can replace functions in m3core, or such, and function pointerequality might be achieved. I think the "interposition" featureis widely accepted on Linux, though it is dodgy.I think on Linux going through the PLT for exported functions mightbe the norm. I'll have to read up more. But going through the PLTfor unexported functions is not the norm. Documentation stronglyencourages marking visibility and saving the PLT indirection.In C/C++ there's further problems of name uniquess of unexportedfunctions across the dynamic link. I believe Modula-3 deals with that,since pretty much every function in the system gets a unique name,exported or not. One or the other or both these changes (public = exported,or -fvisibilit=hidden) optimizes those calls.In general going through the PLT is very wasteful whenit isn't necessary. There's a bunch of "literature" aboutthis on the web.On Windows, to call a function Foo, you just call Foo.If Foo ends up imported, the linker generates a single instructionfunction for you, Foo, that jumps through __imp__Foo.If you are absolutely sure Foo will be imported and want tooptimize a little, you can mark Foo as __declspec(dllimport),however for functions this is totally optional.To export functions, you either mark them __declspec(dllexport)or list them in a .def file. For C++, .def files are a pain, butfor C they work just fine, or better.For importing data, you pretty much have to mark it as __declspec(dllimport).Importing data is rare.gcc/ld on Windows have some hack to make this easier that I'm not familiar with.So in the absence of importing data, there is just one codegenmodel that is acceptable -- call Foo.Most function calls, theoretically, are not imported, and thisends up as a normal direct call.There may be issues of position-independence, but on AMD64 thisis not relevant. On AMD64_NT, I believe the vast majority ofcode is naturally position-indendent via RIP-relative addressing.It is true that things like vtables might have relocs.I think that is unfortunate. It would be nice to have 100%position independence for .dlls and .exes. On Linux, if you are compiling for a .dll, you must be position-independent,I think fully, and all function calls by default go through the PLT.Maybe to statics don't. But just sharing across two source files does.Every call is therefore indirect, subject to loader machinations ateither load or first-call time, and "interposable" -- someone elsecan export a function of the same name and take over the function.As well, someone else can call these internal functions more easilythan otherwise. Granted, anyone can call any of your code at any time, justby jumping to it. But symbolic exports are considered more attackablesurface area than random code sitting in memory.If you don't use -fPIC, I think all calls are direct.And you can't link into a .dll.And then, really, the truth is in between.Individual calls can be marked one way or the other.But Modula-3 is marking everything as public, exported, subjectto dynamic linking, called through the PLT.As to why only AMD64_LINUX is seeing this, I don't know.I'd have to check how the static link is passed on others andif the loader preserves it. Could be it is an extra parameteron the stack, since x86 has so few registers.Could be AMD64_LINUX could/should pass it another way, butreally, avoiding the PLT for unexported functions seems likepure goodness.I was quite surprised and dismayed to learn about all this lastnight when I was debugging.Why must inline function bodies for unexported functions be preservedanyway? They are just dead code, right? Is there another way to preserve them?If it is <*inline*> on the implementation but listed in the *.i3 file, that should be public/exported. Is it not? I was able to build LINUXLIBC6 this way as far as building on AMD64 gets, which is pretty far -- eventually failing for lack of some X .libs.Oh, I guess I should be sure optimization is on? I didn't twiddle that. I can try again. - Jay From: hosking at cs.purdue.eduTo: jkrell at elegosoft.comDate: Tue, 29 Apr 2008 11:52:24 -0400CC: m3devel at elegosoft.comSubject: [M3devel] Your recent change to parse.c I don't understand your change to parse.c re TREE_PUBLIC being set on procedure declarations. TREE_PUBLIC just means that it is possible to call the procedure from outside the current compilation unit. It has nothing to do with intra-library visibility. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Apr 30 00:32:28 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 29 Apr 2008 18:32:28 -0400 Subject: [M3devel] Your recent change to parse.c In-Reply-To: References: Message-ID: <78640E3D-7188-456B-98A1-8450D0F9F419@cs.purdue.edu> Jay, thanks for your explanation! If your log message could have had some of this information I might have understood what the need was. OK, I've gone back through the logs and see that I did not put this in for specific optimization reasons, though it may have had a historic basis in making something work. So, let's restore your fix and see what happens. I wonder if it breaks procedure values (code address + static chain records)? On Apr 29, 2008, at 5:57 PM, Jay wrote: > Tony, this is a serious problem on AMD64_LINUX. > It is not a problem at all on Win32, as Win32 has a > much better codegen model. It's amazing how Linux works.. > > Look at the .ms file for ThreadPThread. > I looked on AMD64_LINUX and LINUXLIBC6. > > ThreadPThread__InitMutex's call to its own finally > block goes through the PLT and on AMD64_LINUX the static link > in r10 is trashed. > > It's possible that if you turn on optimizations, the finally > block is inlined and that hides the problem, but you can't > count on that. > > I was experimenting with another fix at the same time, > that of using -fvisibility=hidden on m3cg, but > to me that seems more like a C/C++ front end switch, > even though cm3cg supports it. > > I can try again and carefully tweak the two variables, > see if -fvisibility=hidden suffices. At the level > cm3cg operates though, it marks the visibility of everything > explicitly, so again, I think my fix is the way. > > As well calls within a file to functions within that file > that aren't in an interface are going through the PLT. > This is just wasteful. > > They shouldn't even go through the PLT for calls within the > same "library" (ie: m3core to m3core, libm3 to libm3). > > What such indirect calls "buy" is that, e.g. the .exe or libm3 > can replace functions in m3core, or such, and function pointer > equality might be achieved. I think the "interposition" feature > is widely accepted on Linux, though it is dodgy. > I think on Linux going through the PLT for exported functions might > be the norm. I'll have to read up more. But going through the PLT > for unexported functions is not the norm. Documentation strongly > encourages marking visibility and saving the PLT indirection. > > In C/C++ there's further problems of name uniquess of unexported > functions across the dynamic link. I believe Modula-3 deals with that, > since pretty much every function in the system gets a unique name, > exported or not. > > One or the other or both these changes (public = exported, > or -fvisibilit=hidden) optimizes those calls. > > In general going through the PLT is very wasteful when > it isn't necessary. There's a bunch of "literature" about > this on the web. > > On Windows, to call a function Foo, you just call Foo. > If Foo ends up imported, the linker generates a single instruction > function for you, Foo, that jumps through __imp__Foo. > If you are absolutely sure Foo will be imported and want to > optimize a little, you can mark Foo as __declspec(dllimport), > however for functions this is totally optional. > To export functions, you either mark them __declspec(dllexport) > or list them in a .def file. For C++, .def files are a pain, but > for C they work just fine, or better. > For importing data, you pretty much have to mark it as > __declspec(dllimport). > Importing data is rare. > gcc/ld on Windows have some hack to make this easier that I'm not > familiar with. > > So in the absence of importing data, there is just one codegen > model that is acceptable -- call Foo. > Most function calls, theoretically, are not imported, and this > ends up as a normal direct call. > There may be issues of position-independence, but on AMD64 this > is not relevant. On AMD64_NT, I believe the vast majority of > code is naturally position-indendent via RIP-relative addressing. > It is true that things like vtables might have relocs. > I think that is unfortunate. It would be nice to have 100% > position independence for .dlls and .exes. > > On Linux, if you are compiling for a .dll, you must be position- > independent, > I think fully, and all function calls by default go through the PLT. > Maybe to statics don't. But just sharing across two source files does. > Every call is therefore indirect, subject to loader machinations at > either load or first-call time, and "interposable" -- someone else > can export a function of the same name and take over the function. > As well, someone else can call these internal functions more easily > than otherwise. Granted, anyone can call any of your code at any > time, just > by jumping to it. But symbolic exports are considered more attackable > surface area than random code sitting in memory. > > If you don't use -fPIC, I think all calls are direct. > And you can't link into a .dll. > > And then, really, the truth is in between. > Individual calls can be marked one way or the other. > > But Modula-3 is marking everything as public, exported, subject > to dynamic linking, called through the PLT. > > As to why only AMD64_LINUX is seeing this, I don't know. > I'd have to check how the static link is passed on others and > if the loader preserves it. Could be it is an extra parameter > on the stack, since x86 has so few registers. > > Could be AMD64_LINUX could/should pass it another way, but > really, avoiding the PLT for unexported functions seems like > pure goodness. > > I was quite surprised and dismayed to learn about all this last > night when I was debugging. > > Why must inline function bodies for unexported functions be preserved > anyway? They are just dead code, right? > Is there another way to preserve them? > If it is <*inline*> on the implementation but listed in the *.i3 > file, that should be public/exported. Is it not? I was able to build > LINUXLIBC6 this way as far as building on AMD64 gets, which is > pretty far -- eventually failing for lack of some X .libs. > Oh, I guess I should be sure optimization is on? I didn't twiddle > that. I can try again. > > - Jay > > From: hosking at cs.purdue.edu > To: jkrell at elegosoft.com > Date: Tue, 29 Apr 2008 11:52:24 -0400 > CC: m3devel at elegosoft.com > Subject: [M3devel] Your recent change to parse.c > > I don't understand your change to parse.c re TREE_PUBLIC being set > on procedure declarations. TREE_PUBLIC just means that it is > possible to call the procedure from outside the current compilation > unit. It has nothing to do with intra-library visibility. > > > 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 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Apr 30 02:19:51 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 30 Apr 2008 00:19:51 +0000 Subject: [M3devel] silenly allowing "WINAPI" on all targets? (wrt Popup Windows stalling regression tests on WinXP) In-Reply-To: References: <495318.48565.qm@web27105.mail.ukl.yahoo.com> <20080429171117.oopp3fpcpc84ccwk@mail.elegosoft.com> Message-ID: I think cm3 can just make this call unconditionally. As long as the crash is bubbled up as a failure that is printed or something. There should also be a public interface for collecting and sending the reports without a prompt. Various command line tools (cl, link) now have switches to control this behavior. I know the crash is not in cm3 but what it runs -- the setting is inherited by child processes. So, I have a function that exists and I want to call on Win32, and doesn't exist anywhere else, in which case I want to do nothing. In my opinion, a good way to do this is: something.i3 <* extern WINAPI *> PROCEDURE SetErrorMode(UINT32); I wouldn't mind a way to write this in Modula-3, but the naming is in the way. common/something.c void SetErrorMode(UINT32 a) { /* do nothing */ } and only compile something.c on non-Win32. This raises some issues, that I have raised before. I think WINAPI should be silently ignored for all but NT386. It's a small change. It lets this kind of thing work. I know there are other ideas, like <* extern NT386:WINAPI LINUXLIBC:FOOAPI *> or <* extern SYSAPI *> but really I think what I propose is sufficient (and simplest). I doubt that a generalization or renaming has any point. In fact I'd argue for removing all the synonyms and supporting just __stdcall, __cdecl, __fastcall, and __thiscall, possibly as STDCALL, CDECL, FASTCALL, THISCALL, since Modula-3 doesn't like identifiers to start with underscore, and the last two are optional. As I said/implied before, having multiple calling conventions on one target is a terrible idea and I don't expect it to occur again, not at this level at least. I know, for example, you could describe the Linux kernel as exposing two calling conventions, depending on if there is a "small" or "large" number of parameters, but really, even neither of these two are the "normal" convention and such things always get wrapped up in a little wrapper with the "standard" calling convention of the platform (except on NT386, sort of, where the wrapper is one of a few conventions). Precedent is that calling conventions are allowed in source for other Windows platforms, but are ignored. They might be #defined away sometimes, but I bet the compiler ignores them. This provides better source compatibility. As x86 gradually goes away, people will stop putting these things in. I guess the alternative to my proposal is an extra level of wrapping behind some made up "portable" interface: something.i3: PROCEDURE SetErrorMode(UINT32); win32/something.m3 PROCEDURE SetErrorMode(UINT32 a) = BEGIN WinBase.SetErrorMode(a); END SetErrorMode; posix/something.m3 PROCEDURE SetErrorMode(UINT32 <* unused *> a) = BEGIN (* do nothing *); END SetErrorMode; The alternative does have more flexibility, obviously, if the Posix implementation is anything other than "do nothing", such as even having to return a value, which might be the case here, then it'd go this way. Also this saves there from being a .c file. Is that sleazy to use the same function name in two modules? I know Modula-3 prepends module names always. It seems like a feature more than a bug. Anyway, as before, a gain here would be to reduce the doubled up odbc and maybe opengl .i3 files, which vary only in calling convention. - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comSubject: RE: [M3devel] Popup Windows stalling regression tests on WinXPDate: Tue, 29 Apr 2008 22:01:51 +0000 ps: Olaf, the debugger install is incredibly fast and small.This isn't Visual Studio.I get, but hadn't previously considered, that future regressions would hang the machine, so a fix is only "temporary", but hey...maybe a process needs to monitor the tests and kill them if they take too long? SetErrorMode will probably fix this, now that I think more.We can add a switch to cm3 and it can call that on itself, and it always gets inherited by child processes. Or we can have a trivial wrapper .exe to run the tests, if the switch to cm3 is not liked. But I have to test it out.Suggest an .exe or switch name? :)If indeed it is SetErrorMode, I'd doseterrormode.exe Though this is a low level name.It could be testwrapper.exe or quashpopups.exe. -Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Tue, 29 Apr 2008 21:38:14 +0000Subject: Re: [M3devel] Popup Windows stalling regression tests on WinXP Yes, this might be it.My x86 Windows machine is out on loan this week, my AMD64 Windows machine needed a reinstall, and I was deep into debugging the AMD64_LINUX problem (on same machine, multi-boot), so I punted. Now I've reinstalled AMD64 Windows and can debug to see what the problem is, to decide if it is quashable..There should be a way without global changes to the machine, but if that's ok, ok. (If this even it.) - Jay> Date: Tue, 29 Apr 2008 17:11:17 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] Popup Windows stalling regression tests on WinXP> > Quoting "Daniel Alejandro Benavides D." :> > > Hi all:> > Olaf, I don't have the Win box here (just a Kubuntu one). But even > > if you don't want to send the file, one can see the report file in > > a window. Should be with two steps: The first click on the blue > > label "Click here " in the first pop up window. That throws another > > window with a label that you can click-on and actually see it> > Well I found with google the instruction to disable that error pop up:> > http://pcsupport.about.com/od/windowsxp/ht/disableerror.htm> > I hope this helps to you.> > Thanks, that sounds good, I'll try it tonight.> > Olaf> > >> > Thanks> >> > Olaf Wagner escribi?: Quoting "Daniel > > Alejandro Benavides D." :> >> >> Hi all:> >> Olaf, but in the case is not even the cm3 process, but a sub process> >> of it, maybe the linker or/and the assembler (what VS version do> >> you have?) which in turn throws the fault, how do you know from> >> sure is cm3 only causing that?, Can you check the label of "Click> >> here for more information". Then you can click on see the files> >> involved in the fault. There you should see the list of files like> >> dll or lib and executable involved, can you send that info?> >> > I'll restart the tests after some more obvious fixes later this> > evening and may be able to send more information tomorrow.> > IIRC there was no label `click here for more information', but> > just `send report to Microsoft' and `do not send'.> >> > Currently we're working hard on a completely different release...> >> > Olaf> > --> > Olaf Wagner -- elego Software Solutions GmbH> > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> >> >> >> >> > ---------------------------------> >> > Enviado desde Correo Yahoo!> > La bandeja de entrada m?s inteligente.> >> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 jayk123 at hotmail.com Wed Apr 30 05:25:01 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 30 Apr 2008 03:25:01 +0000 Subject: [M3devel] Your recent change to parse.c In-Reply-To: <78640E3D-7188-456B-98A1-8450D0F9F419@cs.purdue.edu> References: <78640E3D-7188-456B-98A1-8450D0F9F419@cs.purdue.edu> Message-ID: Tony, another thing to try here is: TREE_PUBLIC (p) = (lev == 0); I should have noticed that, and can't confirm right now if itis what I think -- nested procedures and finally/except blocksI assume are (lev > 0). I still think calls through the PLT should be drastically reducedand hope to look into this further. In particular, calls that are known to resolve in the same .soneed not be through the PLT, at least on AMD64. I have to check others. There is a paper dsohowto.pdf that talks about this stuff. So it's not just me. I need to read it more closely but I think it resolves to simply that the front end does know what is in the same .so and can pass the information on to cm3cg. - Jay CC: jkrell at elegosoft.com; m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] Your recent change to parse.cDate: Tue, 29 Apr 2008 18:32:28 -0400 Jay, thanks for your explanation! If your log message could have had some of this information I might have understood what the need was. OK, I've gone back through the logs and see that I did not put this in for specific optimization reasons, though it may have had a historic basis in making something work. So, let's restore your fix and see what happens. I wonder if it breaks procedure values (code address + static chain records)? On Apr 29, 2008, at 5:57 PM, Jay wrote: Tony, this is a serious problem on AMD64_LINUX.It is not a problem at all on Win32, as Win32 has amuch better codegen model. It's amazing how Linux works..Look at the .ms file for ThreadPThread.I looked on AMD64_LINUX and LINUXLIBC6.ThreadPThread__InitMutex's call to its own finallyblock goes through the PLT and on AMD64_LINUX the static linkin r10 is trashed.It's possible that if you turn on optimizations, the finallyblock is inlined and that hides the problem, but you can'tcount on that.I was experimenting with another fix at the same time,that of using -fvisibility=hidden on m3cg, butto me that seems more like a C/C++ front end switch,even though cm3cg supports it.I can try again and carefully tweak the two variables,see if -fvisibility=hidden suffices. At the levelcm3cg operates though, it marks the visibility of everythingexplicitly, so again, I think my fix is the way.As well calls within a file to functions within that filethat aren't in an interface are going through the PLT.This is just wasteful.They shouldn't even go through the PLT for calls within thesame "library" (ie: m3core to m3core, libm3 to libm3).What such indirect calls "buy" is that, e.g. the .exe or libm3can replace functions in m3core, or such, and function pointerequality might be achieved. I think the "interposition" featureis widely accepted on Linux, though it is dodgy.I think on Linux going through the PLT for exported functions mightbe the norm. I'll have to read up more. But going through the PLTfor unexported functions is not the norm. Documentation stronglyencourages marking visibility and saving the PLT indirection.In C/C++ there's further problems of name uniquess of unexportedfunctions across the dynamic link. I believe Modula-3 deals with that,since pretty much every function in the system gets a unique name,exported or not. One or the other or both these changes (public = exported,or -fvisibilit=hidden) optimizes those calls.In general going through the PLT is very wasteful whenit isn't necessary. There's a bunch of "literature" aboutthis on the web.On Windows, to call a function Foo, you just call Foo.If Foo ends up imported, the linker generates a single instructionfunction for you, Foo, that jumps through __imp__Foo.If you are absolutely sure Foo will be imported and want tooptimize a little, you can mark Foo as __declspec(dllimport),however for functions this is totally optional.To export functions, you either mark them __declspec(dllexport)or list them in a .def file. For C++, .def files are a pain, butfor C they work just fine, or better.For importing data, you pretty much have to mark it as __declspec(dllimport).Importing data is rare.gcc/ld on Windows have some hack to make this easier that I'm not familiar with.So in the absence of importing data, there is just one codegenmodel that is acceptable -- call Foo.Most function calls, theoretically, are not imported, and thisends up as a normal direct call.There may be issues of position-independence, but on AMD64 thisis not relevant. On AMD64_NT, I believe the vast majority ofcode is naturally position-indendent via RIP-relative addressing.It is true that things like vtables might have relocs.I think that is unfortunate. It would be nice to have 100%position independence for .dlls and .exes. On Linux, if you are compiling for a .dll, you must be position-independent,I think fully, and all function calls by default go through the PLT.Maybe to statics don't. But just sharing across two source files does.Every call is therefore indirect, subject to loader machinations ateither load or first-call time, and "interposable" -- someone elsecan export a function of the same name and take over the function.As well, someone else can call these internal functions more easilythan otherwise. Granted, anyone can call any of your code at any time, justby jumping to it. But symbolic exports are considered more attackablesurface area than random code sitting in memory.If you don't use -fPIC, I think all calls are direct.And you can't link into a .dll.And then, really, the truth is in between.Individual calls can be marked one way or the other.But Modula-3 is marking everything as public, exported, subjectto dynamic linking, called through the PLT.As to why only AMD64_LINUX is seeing this, I don't know.I'd have to check how the static link is passed on others andif the loader preserves it. Could be it is an extra parameteron the stack, since x86 has so few registers.Could be AMD64_LINUX could/should pass it another way, butreally, avoiding the PLT for unexported functions seems likepure goodness.I was quite surprised and dismayed to learn about all this lastnight when I was debugging.Why must inline function bodies for unexported functions be preservedanyway? They are just dead code, right? Is there another way to preserve them?If it is <*inline*> on the implementation but listed in the *.i3 file, that should be public/exported. Is it not? I was able to build LINUXLIBC6 this way as far as building on AMD64 gets, which is pretty far -- eventually failing for lack of some X .libs.Oh, I guess I should be sure optimization is on? I didn't twiddle that. I can try again. - Jay From: hosking at cs.purdue.eduTo: jkrell at elegosoft.comDate: Tue, 29 Apr 2008 11:52:24 -0400CC: m3devel at elegosoft.comSubject: [M3devel] Your recent change to parse.c I don't understand your change to parse.c re TREE_PUBLIC being set on procedure declarations. TREE_PUBLIC just means that it is possible to call the procedure from outside the current compilation unit. It has nothing to do with intra-library visibility. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Apr 30 08:00:23 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 30 Apr 2008 08:00:23 +0200 Subject: [M3devel] Popup Windows stalling regression tests on WinXP In-Reply-To: <495318.48565.qm@web27105.mail.ukl.yahoo.com> References: <495318.48565.qm@web27105.mail.ukl.yahoo.com> Message-ID: <20080430080023.egxncs5vk4sk0skg@mail.elegosoft.com> This is the only information I can copy&paste into this mail: AppName: cm3.exe AppVer: 0.0.0.0 ModName: ntdll.dll ModVer: 5.1.2600.2180 Offset: 00001230 There is a lot more, but I cannot copy it now (many pages), and copy&paste does not work :-( I'll attach the binary file that the system wants to send to Microsoft in case somebody can decode that. The error occurs reproduciably in test p204. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb??ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 -------------- ??<?xml version="1.0" encoding="UTF-16"?> <DATABASE> <EXE NAME="cm3.exe" FILTER="GRABMI_FILTER_PRIVACY"> <MATCHING_FILE NAME="anim3D.dll" SIZE="480768" CHECKSUM="0x823BB10C" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:48:19" UPTO_LINK_DATE="04/08/2008 00:48:19" /> <MATCHING_FILE NAME="arithmetic.dll" SIZE="1219072" CHECKSUM="0x91EC1B94" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:42:26" UPTO_LINK_DATE="04/07/2008 07:42:26" /> <MATCHING_FILE NAME="binIO.dll" SIZE="10240" CHECKSUM="0xAEC61462" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:51:00" UPTO_LINK_DATE="04/07/2008 07:51:00" /> <MATCHING_FILE NAME="BitVector.dll" SIZE="29184" CHECKSUM="0xF72FA5FB" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:13:22" UPTO_LINK_DATE="04/07/2008 07:13:22" /> <MATCHING_FILE NAME="Calculator.exe" SIZE="13312" CHECKSUM="0x33E2EBD2" MODULE_TYPE="WIN32" PE_CHECKSUM="0xCC73" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:07:16" UPTO_LINK_DATE="04/08/2008 01:07:16" /> <MATCHING_FILE NAME="cit_common.dll" SIZE="8704" CHECKSUM="0xBD445A42" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:11:43" UPTO_LINK_DATE="04/08/2008 01:11:43" /> <MATCHING_FILE NAME="cit_util.dll" SIZE="71680" CHECKSUM="0x7EC274E4" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:12:48" UPTO_LINK_DATE="04/08/2008 01:12:48" /> <MATCHING_FILE NAME="cm3-d5.5.0.exe" SIZE="2465792" CHECKSUM="0x262627D" MODULE_TYPE="WIN32" PE_CHECKSUM="0x25BD65" LINKER_VERSION="0x0" LINK_DATE="12/18/2007 13:38:27" UPTO_LINK_DATE="12/18/2007 13:38:27" /> <MATCHING_FILE NAME="cm3-d5.7.0.exe" SIZE="2610176" CHECKSUM="0x4626C839" MODULE_TYPE="WIN32" PE_CHECKSUM="0x2852D5" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:11:03" UPTO_LINK_DATE="04/07/2008 07:11:03" /> <MATCHING_FILE NAME="cm3.exe" SIZE="2610176" CHECKSUM="0x4626C839" MODULE_TYPE="WIN32" PE_CHECKSUM="0x2852D5" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:11:03" UPTO_LINK_DATE="04/07/2008 07:11:03" /> <MATCHING_FILE NAME="cmpdir.exe" SIZE="419840" CHECKSUM="0x2EF852E6" MODULE_TYPE="WIN32" PE_CHECKSUM="0x6F5C9" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:57:15" UPTO_LINK_DATE="04/07/2008 07:57:15" /> <MATCHING_FILE NAME="cmvbt.dll" SIZE="75264" CHECKSUM="0x635777BC" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:43:24" UPTO_LINK_DATE="04/08/2008 00:43:24" /> <MATCHING_FILE NAME="commandrw.dll" SIZE="7680" CHECKSUM="0x9DC9781E" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:51:33" UPTO_LINK_DATE="04/07/2008 07:51:33" /> <MATCHING_FILE NAME="Cube.exe" SIZE="46080" CHECKSUM="0xD7ABA671" MODULE_TYPE="WIN32" PE_CHECKSUM="0x130C9" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:06:49" UPTO_LINK_DATE="04/08/2008 01:06:49" /> <MATCHING_FILE NAME="db.dll" SIZE="35840" CHECKSUM="0x1EFF81F3" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:38:55" UPTO_LINK_DATE="04/08/2008 00:38:55" /> <MATCHING_FILE NAME="debug.dll" SIZE="6656" CHECKSUM="0xF04EFA2E" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:48:50" UPTO_LINK_DATE="04/07/2008 07:48:50" /> <MATCHING_FILE NAME="deepcopy.dll" SIZE="7680" CHECKSUM="0xAADDF510" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:13:35" UPTO_LINK_DATE="04/08/2008 01:13:35" /> <MATCHING_FILE NAME="DiGraph.dll" SIZE="5632" CHECKSUM="0x5C4C3FA0" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:13:35" UPTO_LINK_DATE="04/07/2008 07:13:35" /> <MATCHING_FILE NAME="dirfp.exe" SIZE="413184" CHECKSUM="0x64276DAC" MODULE_TYPE="WIN32" PE_CHECKSUM="0x6E347" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:58:14" UPTO_LINK_DATE="04/07/2008 07:58:14" /> <MATCHING_FILE NAME="drawcontext.dll" SIZE="80896" CHECKSUM="0x1A411D15" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:14:33" UPTO_LINK_DATE="04/08/2008 01:14:33" /> <MATCHING_FILE NAME="embutils.dll" SIZE="3584" CHECKSUM="0xF9483DB8" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:49:39" UPTO_LINK_DATE="04/07/2008 07:49:39" /> <MATCHING_FILE NAME="events.dll" SIZE="150528" CHECKSUM="0xB2FF58BF" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:35:28" UPTO_LINK_DATE="04/08/2008 00:35:28" /> <MATCHING_FILE NAME="ext.exe" SIZE="660992" CHECKSUM="0xE037ACC0" MODULE_TYPE="WIN32" PE_CHECKSUM="0xA1D01" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:18:47" UPTO_LINK_DATE="04/08/2008 01:18:47" /> <MATCHING_FILE NAME="fisheye.exe" SIZE="309248" CHECKSUM="0x14677CD5" MODULE_TYPE="WIN32" PE_CHECKSUM="0x539B1" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:07:46" UPTO_LINK_DATE="04/08/2008 01:07:46" /> <MATCHING_FILE NAME="fix_nl.exe" SIZE="416256" CHECKSUM="0x1CA96408" MODULE_TYPE="WIN32" PE_CHECKSUM="0x73894" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:12:51" UPTO_LINK_DATE="04/07/2008 07:12:51" /> <MATCHING_FILE NAME="formsedit.exe" SIZE="95232" CHECKSUM="0x9557EA01" MODULE_TYPE="WIN32" PE_CHECKSUM="0x27173" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:46:02" UPTO_LINK_DATE="04/08/2008 00:46:02" /> <MATCHING_FILE NAME="Geometry.dll" SIZE="49664" CHECKSUM="0x6898BD6D" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:14:00" UPTO_LINK_DATE="04/07/2008 07:14:00" /> <MATCHING_FILE NAME="http.dll" SIZE="175104" CHECKSUM="0x8E6BC41A" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:50:33" UPTO_LINK_DATE="04/07/2008 07:50:33" /> <MATCHING_FILE NAME="juno-compiler.dll" SIZE="365056" CHECKSUM="0xAAAC820F" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:05:24" UPTO_LINK_DATE="04/08/2008 01:05:24" /> <MATCHING_FILE NAME="juno-machine.dll" SIZE="175104" CHECKSUM="0xF1339677" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:04:48" UPTO_LINK_DATE="04/08/2008 01:04:48" /> <MATCHING_FILE NAME="Juno.exe" SIZE="769024" CHECKSUM="0xEADA1C8A" MODULE_TYPE="WIN32" PE_CHECKSUM="0xBEA28" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:06:10" UPTO_LINK_DATE="04/08/2008 01:06:10" /> <MATCHING_FILE NAME="jvideo.dll" SIZE="3072" CHECKSUM="0x25A85F31" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:43:46" UPTO_LINK_DATE="04/08/2008 00:43:46" /> <MATCHING_FILE NAME="klexlib.dll" SIZE="79360" CHECKSUM="0xEDD959F" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:16:56" UPTO_LINK_DATE="04/08/2008 01:16:56" /> <MATCHING_FILE NAME="ktoklib.dll" SIZE="57856" CHECKSUM="0x60EB40FE" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:16:20" UPTO_LINK_DATE="04/08/2008 01:16:20" /> <MATCHING_FILE NAME="kyacclib.dll" SIZE="52224" CHECKSUM="0x4DF59544" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:17:23" UPTO_LINK_DATE="04/08/2008 01:17:23" /> <MATCHING_FILE NAME="libbuf.dll" SIZE="10752" CHECKSUM="0xE225AC88" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:48:27" UPTO_LINK_DATE="04/07/2008 07:48:27" /> <MATCHING_FILE NAME="libsio.dll" SIZE="10240" CHECKSUM="0x402B9346" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:48:04" UPTO_LINK_DATE="04/07/2008 07:48:04" /> <MATCHING_FILE NAME="listfuncs.dll" SIZE="15872" CHECKSUM="0x82D3DC0C" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:49:15" UPTO_LINK_DATE="04/07/2008 07:49:15" /> <MATCHING_FILE NAME="m3.dll" SIZE="900608" CHECKSUM="0xCC3412E7" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:06:55" UPTO_LINK_DATE="04/07/2008 07:06:55" /> <MATCHING_FILE NAME="m3browser.exe" SIZE="108032" CHECKSUM="0x2175DA6F" MODULE_TYPE="WIN32" PE_CHECKSUM="0x22355" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:56:47" UPTO_LINK_DATE="04/07/2008 07:56:47" /> <MATCHING_FILE NAME="m3browserhack.exe" SIZE="10240" CHECKSUM="0x981D39D9" MODULE_TYPE="WIN32" PE_CHECKSUM="0x84D8" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:15:53" UPTO_LINK_DATE="04/08/2008 01:15:53" /> <MATCHING_FILE NAME="m3bundle.exe" SIZE="419328" CHECKSUM="0xE00DA5B9" MODULE_TYPE="WIN32" PE_CHECKSUM="0x6FA98" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:12:21" UPTO_LINK_DATE="04/07/2008 07:12:21" /> <MATCHING_FILE NAME="m3codeview.dll" SIZE="48128" CHECKSUM="0xEC827D5C" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:46:28" UPTO_LINK_DATE="04/08/2008 00:46:28" /> <MATCHING_FILE NAME="m3core.dll" SIZE="453120" CHECKSUM="0xFE42B480" MODULE_TYPE="WIN32" PE_CHECKSUM="0x7DC99" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:05:45" UPTO_LINK_DATE="04/07/2008 07:05:45" /> <MATCHING_FILE NAME="m3formsvbt.dll" SIZE="321536" CHECKSUM="0x74283C1A" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:45:16" UPTO_LINK_DATE="04/08/2008 00:45:16" /> <MATCHING_FILE NAME="m3formsvbtpixmaps.dll" SIZE="41984" CHECKSUM="0xD32CC0F2" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:44:50" UPTO_LINK_DATE="04/08/2008 00:44:50" /> <MATCHING_FILE NAME="m3markup.dll" SIZE="61952" CHECKSUM="0x275E2179" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:56:25" UPTO_LINK_DATE="04/07/2008 07:56:25" /> <MATCHING_FILE NAME="m3mg.dll" SIZE="150016" CHECKSUM="0x933B256B" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:46:53" UPTO_LINK_DATE="04/08/2008 00:46:53" /> <MATCHING_FILE NAME="m3mgkit.dll" SIZE="258048" CHECKSUM="0x8E793FF" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:47:21" UPTO_LINK_DATE="04/08/2008 00:47:21" /> <MATCHING_FILE NAME="m3netobj.dll" SIZE="163328" CHECKSUM="0xF3EEB081" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:33:33" UPTO_LINK_DATE="04/08/2008 00:33:33" /> <MATCHING_FILE NAME="m3parseparams.dll" SIZE="12800" CHECKSUM="0x5679B98A" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:13:47" UPTO_LINK_DATE="04/07/2008 07:13:47" /> <MATCHING_FILE NAME="m3scan.dll" SIZE="26624" CHECKSUM="0x4B4C853" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:55:59" UPTO_LINK_DATE="04/07/2008 07:55:59" /> <MATCHING_FILE NAME="m3slisp.dll" SIZE="75776" CHECKSUM="0xA6274123" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:14:30" UPTO_LINK_DATE="04/07/2008 07:14:30" /> <MATCHING_FILE NAME="m3smalldb.dll" SIZE="18944" CHECKSUM="0xFBFCFF44" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:39:33" UPTO_LINK_DATE="04/08/2008 00:39:33" /> <MATCHING_FILE NAME="m3tcp.dll" SIZE="40448" CHECKSUM="0x2CDEA533" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:47:24" UPTO_LINK_DATE="04/07/2008 07:47:24" /> <MATCHING_FILE NAME="m3tk-misc.dll" SIZE="60928" CHECKSUM="0x5AFD1714" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:50:06" UPTO_LINK_DATE="04/07/2008 07:50:06" /> <MATCHING_FILE NAME="m3tk.dll" SIZE="1691648" CHECKSUM="0x499FCE79" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:53:43" UPTO_LINK_DATE="04/07/2008 07:53:43" /> <MATCHING_FILE NAME="m3tmplhack.exe" SIZE="463872" CHECKSUM="0x59869FAE" MODULE_TYPE="WIN32" PE_CHECKSUM="0x7DC69" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:12:11" UPTO_LINK_DATE="04/08/2008 01:12:11" /> <MATCHING_FILE NAME="m3tohtml.exe" SIZE="680448" CHECKSUM="0xE7446678" MODULE_TYPE="WIN32" PE_CHECKSUM="0xA6717" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:55:26" UPTO_LINK_DATE="04/07/2008 07:55:26" /> <MATCHING_FILE NAME="m3totex.exe" SIZE="22528" CHECKSUM="0x913128DB" MODULE_TYPE="WIN32" PE_CHECKSUM="0x789E" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:55:00" UPTO_LINK_DATE="04/07/2008 07:55:00" /> <MATCHING_FILE NAME="m3ui.dll" SIZE="690688" CHECKSUM="0xC8B3CE03" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:41:35" UPTO_LINK_DATE="04/08/2008 00:41:35" /> <MATCHING_FILE NAME="m3unit-numeric.dll" SIZE="6656" CHECKSUM="0x8ED35521" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:43:48" UPTO_LINK_DATE="04/07/2008 07:43:48" /> <MATCHING_FILE NAME="m3unit.dll" SIZE="11776" CHECKSUM="0x5A90BF01" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:08:06" UPTO_LINK_DATE="04/07/2008 07:08:06" /> <MATCHING_FILE NAME="m3vbtkit.dll" SIZE="803328" CHECKSUM="0xF78DE500" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:42:45" UPTO_LINK_DATE="04/08/2008 00:42:45" /> <MATCHING_FILE NAME="m3zeus.dll" SIZE="193536" CHECKSUM="0x66C70909" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:48:59" UPTO_LINK_DATE="04/08/2008 00:48:59" /> <MATCHING_FILE NAME="m3zume.exe" SIZE="98816" CHECKSUM="0x818FF503" MODULE_TYPE="WIN32" PE_CHECKSUM="0x220C1" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:49:25" UPTO_LINK_DATE="04/08/2008 00:49:25" /> <MATCHING_FILE NAME="mentor.exe" SIZE="2422784" CHECKSUM="0x894619CE" MODULE_TYPE="WIN32" PE_CHECKSUM="0x251B4E" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:10:20" UPTO_LINK_DATE="04/08/2008 01:10:20" /> <MATCHING_FILE NAME="metasyn.dll" SIZE="60416" CHECKSUM="0x5468CC37" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:50:33" UPTO_LINK_DATE="04/08/2008 00:50:33" /> <MATCHING_FILE NAME="mklib.exe" SIZE="469504" CHECKSUM="0xB73A8C0D" MODULE_TYPE="WIN32" PE_CHECKSUM="0x7A22B" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:12:35" UPTO_LINK_DATE="04/07/2008 07:12:35" /> <MATCHING_FILE NAME="netobjd.exe" SIZE="740352" CHECKSUM="0xB9498D42" MODULE_TYPE="WIN32" PE_CHECKSUM="0xB84DF" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:33:57" UPTO_LINK_DATE="04/08/2008 00:33:57" /> <MATCHING_FILE NAME="obliq-anim.exe" SIZE="8192" CHECKSUM="0xA7016EDE" MODULE_TYPE="WIN32" PE_CHECKSUM="0x49B1" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:57:23" UPTO_LINK_DATE="04/08/2008 00:57:23" /> <MATCHING_FILE NAME="obliq-min.exe" SIZE="7168" CHECKSUM="0xE52FCFC9" MODULE_TYPE="WIN32" PE_CHECKSUM="0xB6EF" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:55:54" UPTO_LINK_DATE="04/08/2008 00:55:54" /> <MATCHING_FILE NAME="obliq-std.exe" SIZE="1801728" CHECKSUM="0x58C1C1A5" MODULE_TYPE="WIN32" PE_CHECKSUM="0x1BD08F" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:56:18" UPTO_LINK_DATE="04/08/2008 00:56:18" /> <MATCHING_FILE NAME="obliq-ui.exe" SIZE="8192" CHECKSUM="0xD3965549" MODULE_TYPE="WIN32" PE_CHECKSUM="0x636F" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:56:49" UPTO_LINK_DATE="04/08/2008 00:56:49" /> <MATCHING_FILE NAME="obliq.dll" SIZE="97280" CHECKSUM="0xB788243" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:52:59" UPTO_LINK_DATE="04/08/2008 00:52:59" /> <MATCHING_FILE NAME="obliqlib3D.dll" SIZE="558592" CHECKSUM="0x467E1BA3" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:58:23" UPTO_LINK_DATE="04/08/2008 00:58:23" /> <MATCHING_FILE NAME="obliqlibanim.dll" SIZE="115712" CHECKSUM="0x8F8DA488" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:54:49" UPTO_LINK_DATE="04/08/2008 00:54:49" /> <MATCHING_FILE NAME="obliqlibemb.dll" SIZE="43008" CHECKSUM="0xE3A39039" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:53:39" UPTO_LINK_DATE="04/08/2008 00:53:39" /> <MATCHING_FILE NAME="obliqlibm3.dll" SIZE="68608" CHECKSUM="0x9F00F489" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:54:03" UPTO_LINK_DATE="04/08/2008 00:54:03" /> <MATCHING_FILE NAME="obliqlibui.dll" SIZE="86528" CHECKSUM="0xE452A083" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:54:27" UPTO_LINK_DATE="04/08/2008 00:54:27" /> <MATCHING_FILE NAME="obliqparse.dll" SIZE="109568" CHECKSUM="0x119B3185" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:51:58" UPTO_LINK_DATE="04/08/2008 00:51:58" /> <MATCHING_FILE NAME="obliqprint.dll" SIZE="55296" CHECKSUM="0xCACF7E42" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:52:22" UPTO_LINK_DATE="04/08/2008 00:52:22" /> <MATCHING_FILE NAME="obliqrt.dll" SIZE="399872" CHECKSUM="0x1E58E57D" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:51:20" UPTO_LINK_DATE="04/08/2008 00:51:20" /> <MATCHING_FILE NAME="obliqsrv-std.exe" SIZE="8704" CHECKSUM="0x46689203" MODULE_TYPE="WIN32" PE_CHECKSUM="0xFDDC" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:55:08" UPTO_LINK_DATE="04/08/2008 00:55:08" /> <MATCHING_FILE NAME="obliqsrv-ui.exe" SIZE="8704" CHECKSUM="0xB1EE543D" MODULE_TYPE="WIN32" PE_CHECKSUM="0xF242" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:55:31" UPTO_LINK_DATE="04/08/2008 00:55:31" /> <MATCHING_FILE NAME="odbc.dll" SIZE="4096" CHECKSUM="0xF8BE9A14" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:37:54" UPTO_LINK_DATE="04/08/2008 00:37:54" /> <MATCHING_FILE NAME="opengl.dll" SIZE="3584" CHECKSUM="0xB2C33385" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:47:44" UPTO_LINK_DATE="04/08/2008 00:47:44" /> <MATCHING_FILE NAME="parserlib.dll" SIZE="12800" CHECKSUM="0x5502B841" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:19:18" UPTO_LINK_DATE="04/08/2008 01:19:18" /> <MATCHING_FILE NAME="patternmatching.dll" SIZE="24064" CHECKSUM="0x8373AD2D" MODULE_TYPE="WIN32" PE_CHECKSUM="0xFDD7" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:07:27" UPTO_LINK_DATE="04/07/2008 07:07:27" /> <MATCHING_FILE NAME="rdwr.dll" SIZE="32256" CHECKSUM="0x7B9046A7" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:36:01" UPTO_LINK_DATE="04/08/2008 00:36:01" /> <MATCHING_FILE NAME="RehearseCode.exe" SIZE="25088" CHECKSUM="0xD3390093" MODULE_TYPE="WIN32" PE_CHECKSUM="0xDAA9" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:01:59" UPTO_LINK_DATE="04/08/2008 01:01:59" /> <MATCHING_FILE NAME="replayheap.exe" SIZE="15360" CHECKSUM="0x52932983" MODULE_TYPE="WIN32" PE_CHECKSUM="0x545F" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:02:26" UPTO_LINK_DATE="04/08/2008 01:02:26" /> <MATCHING_FILE NAME="serialio.dll" SIZE="8704" CHECKSUM="0x4E2838D6" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:52:26" UPTO_LINK_DATE="04/07/2008 07:52:26" /> <MATCHING_FILE NAME="set.dll" SIZE="53248" CHECKSUM="0x3EA73D8F" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:14:18" UPTO_LINK_DATE="04/07/2008 07:14:18" /> <MATCHING_FILE NAME="sgml.dll" SIZE="149504" CHECKSUM="0x7F0C814D" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:20:38" UPTO_LINK_DATE="04/08/2008 01:20:38" /> <MATCHING_FILE NAME="sharedobj.dll" SIZE="193024" CHECKSUM="0x2F138704" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:36:34" UPTO_LINK_DATE="04/08/2008 00:36:34" /> <MATCHING_FILE NAME="shobjcodegen.exe" SIZE="1941504" CHECKSUM="0xE2CE99C2" MODULE_TYPE="WIN32" PE_CHECKSUM="0x1E04EE" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:37:08" UPTO_LINK_DATE="04/08/2008 00:37:08" /> <MATCHING_FILE NAME="showheap.exe" SIZE="22528" CHECKSUM="0xFA5909F9" MODULE_TYPE="WIN32" PE_CHECKSUM="0x6897" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:02:52" UPTO_LINK_DATE="04/08/2008 01:02:52" /> <MATCHING_FILE NAME="shownew.exe" SIZE="32256" CHECKSUM="0xEA1457E3" MODULE_TYPE="WIN32" PE_CHECKSUM="0xB820" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:03:18" UPTO_LINK_DATE="04/08/2008 01:03:18" /> <MATCHING_FILE NAME="showthread.exe" SIZE="16384" CHECKSUM="0x31F5DB4C" MODULE_TYPE="WIN32" PE_CHECKSUM="0x8316" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:03:44" UPTO_LINK_DATE="04/08/2008 01:03:44" /> <MATCHING_FILE NAME="SortedTableExtras.dll" SIZE="33280" CHECKSUM="0x7991D3EC" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:14:42" UPTO_LINK_DATE="04/07/2008 07:14:42" /> <MATCHING_FILE NAME="stable.dll" SIZE="27648" CHECKSUM="0xF3B16723" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:40:34" UPTO_LINK_DATE="04/08/2008 00:40:34" /> <MATCHING_FILE NAME="stablegen.exe" SIZE="1832960" CHECKSUM="0xBF99DCCB" MODULE_TYPE="WIN32" PE_CHECKSUM="0x1CBB89" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:39:56" UPTO_LINK_DATE="04/08/2008 00:39:56" /> <MATCHING_FILE NAME="stubgen.exe" SIZE="1844224" CHECKSUM="0x61009FC5" MODULE_TYPE="WIN32" PE_CHECKSUM="0x1C7A67" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:34:34" UPTO_LINK_DATE="04/08/2008 00:34:34" /> <MATCHING_FILE NAME="synex.dll" SIZE="60928" CHECKSUM="0x1642437E" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:50:10" UPTO_LINK_DATE="04/08/2008 00:50:10" /> <MATCHING_FILE NAME="synwr.dll" SIZE="13824" CHECKSUM="0xB1A73466" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:49:49" UPTO_LINK_DATE="04/08/2008 00:49:49" /> <MATCHING_FILE NAME="sysutils.dll" SIZE="113152" CHECKSUM="0x17DC14FE" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:07:52" UPTO_LINK_DATE="04/07/2008 07:07:52" /> <MATCHING_FILE NAME="table-list.dll" SIZE="49152" CHECKSUM="0x6D75D670" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:14:55" UPTO_LINK_DATE="04/07/2008 07:14:55" /> <MATCHING_FILE NAME="TempFiles.dll" SIZE="6656" CHECKSUM="0x9C140244" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:15:07" UPTO_LINK_DATE="04/07/2008 07:15:07" /> <MATCHING_FILE NAME="tok.exe" SIZE="532992" CHECKSUM="0x9944F2E6" MODULE_TYPE="WIN32" PE_CHECKSUM="0x891E6" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:17:46" UPTO_LINK_DATE="04/08/2008 01:17:46" /> <MATCHING_FILE NAME="videovbt.dll" SIZE="9216" CHECKSUM="0x2237D9BE" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:44:07" UPTO_LINK_DATE="04/08/2008 00:44:07" /> <MATCHING_FILE NAME="visobliq.exe" SIZE="414208" CHECKSUM="0x97B860F1" MODULE_TYPE="WIN32" PE_CHECKSUM="0x6C676" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:59:02" UPTO_LINK_DATE="04/08/2008 00:59:02" /> <MATCHING_FILE NAME="vocgi.exe" SIZE="51712" CHECKSUM="0xDE0557FD" MODULE_TYPE="WIN32" PE_CHECKSUM="0x10853" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:59:33" UPTO_LINK_DATE="04/08/2008 00:59:33" /> <MATCHING_FILE NAME="voquery.exe" SIZE="9216" CHECKSUM="0xC2E99515" MODULE_TYPE="WIN32" PE_CHECKSUM="0xD556" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:00:01" UPTO_LINK_DATE="04/08/2008 01:00:01" /> <MATCHING_FILE NAME="vorun.exe" SIZE="80896" CHECKSUM="0xF5FF2444" MODULE_TYPE="WIN32" PE_CHECKSUM="0x23646" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:00:34" UPTO_LINK_DATE="04/08/2008 01:00:34" /> <MATCHING_FILE NAME="web.dll" SIZE="20480" CHECKSUM="0x4AD2B1F7" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:44:29" UPTO_LINK_DATE="04/08/2008 00:44:29" /> <MATCHING_FILE NAME="webvbt.dll" SIZE="180736" CHECKSUM="0x8823E2FB" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:01:13" UPTO_LINK_DATE="04/08/2008 01:01:13" /> </EXE> <EXE NAME="ntdll.dll" FILTER="GRABMI_FILTER_THISFILEONLY"> <MATCHING_FILE NAME="ntdll.dll" SIZE="708096" CHECKSUM="0x9D20568" BIN_FILE_VERSION="5.1.2600.2180" BIN_PRODUCT_VERSION="5.1.2600.2180" PRODUCT_VERSION="5.1.2600.2180" FILE_DESCRIPTION="NT Layer DLL" COMPANY_NAME="Microsoft Corporation" PRODUCT_NAME="Microsoft? Windows? Operating System" FILE_VERSION="5.1.2600.2180 (xpsp_sp2_rtm.040803-2158)" ORIGINAL_FILENAME="ntdll.dll" INTERNAL_NAME="ntdll.dll" LEGAL_COPYRIGHT="? Microsoft Corporation. All rights reserved." VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x40004" VERFILETYPE="0x2" MODULE_TYPE="WIN32" PE_CHECKSUM="0xAF2F7" LINKER_VERSION="0x50001" UPTO_BIN_FILE_VERSION="5.1.2600.2180" UPTO_BIN_PRODUCT_VERSION="5.1.2600.2180" LINK_DATE="08/04/2004 07:56:36" UPTO_LINK_DATE="08/04/2004 07:56:36" VER_LANGUAGE="English (United States) [0x409]" /> </EXE> <EXE NAME="kernel32.dll" FILTER="GRABMI_FILTER_THISFILEONLY"> <MATCHING_FILE NAME="kernel32.dll" SIZE="984576" CHECKSUM="0xF0B331F6" BIN_FILE_VERSION="5.1.2600.3119" BIN_PRODUCT_VERSION="5.1.2600.3119" PRODUCT_VERSION="5.1.2600.3119" FILE_DESCRIPTION="Windows NT BASE API Client DLL" COMPANY_NAME="Microsoft Corporation" PRODUCT_NAME="Microsoft? Windows? Operating System" FILE_VERSION="5.1.2600.3119 (xpsp_sp2_gdr.070416-1301)" ORIGINAL_FILENAME="kernel32" INTERNAL_NAME="kernel32" LEGAL_COPYRIGHT="? Microsoft Corporation. All rights reserved." VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x40004" VERFILETYPE="0x2" MODULE_TYPE="WIN32" PE_CHECKSUM="0xF9293" LINKER_VERSION="0x50001" UPTO_BIN_FILE_VERSION="5.1.2600.3119" UPTO_BIN_PRODUCT_VERSION="5.1.2600.3119" LINK_DATE="04/16/2007 15:52:53" UPTO_LINK_DATE="04/16/2007 15:52:53" VER_LANGUAGE="English (United States) [0x409]" /> </EXE> </DATABASE> From jayk123 at hotmail.com Wed Apr 30 14:40:17 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 30 Apr 2008 12:40:17 +0000 Subject: [M3devel] silenly allowing "WINAPI" on all targets? (wrt Popup Windows stalling regression tests In-Reply-To: References: <495318.48565.qm@web27105.mail.ukl.yahoo.com> <20080429171117.oopp3fpcpc84ccwk@mail.elegosoft.com> Message-ID: I still really like this idea, but this turned out to be something else.. - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Wed, 30 Apr 2008 00:19:51 +0000Subject: [M3devel] silenly allowing "WINAPI" on all targets? (wrt Popup Windows stalling regression tests on WinXP) I think cm3 can just make this call unconditionally. As long as the crash is bubbled up as a failure that is printed or something. There should also be a public interface for collecting and sending the reports without a prompt. Various command line tools (cl, link) now have switches to control this behavior.I know the crash is not in cm3 but what it runs -- the setting is inherited by child processes. So, I have a function that exists and I want to call on Win32, and doesn't exist anywhere else, in which case I want to do nothing. In my opinion, a good way to do this is: something.i3 <* extern WINAPI *> PROCEDURE SetErrorMode(UINT32); I wouldn't mind a way to write this in Modula-3, but the naming is in the way.common/something.c void SetErrorMode(UINT32 a) { /* do nothing */ } and only compile something.c on non-Win32. This raises some issues, that I have raised before. I think WINAPI should be silently ignored for all but NT386.It's a small change. It lets this kind of thing work. I know there are other ideas, like <* extern NT386:WINAPI LINUXLIBC:FOOAPI *>or <* extern SYSAPI *> but really I think what I propose is sufficient (and simplest).I doubt that a generalization or renaming has any point.In fact I'd argue for removing all the synonyms and supporting just __stdcall, __cdecl, __fastcall, and __thiscall, possibly as STDCALL, CDECL, FASTCALL, THISCALL, since Modula-3 doesn't like identifiers to start with underscore, and the last two are optional. As I said/implied before, having multiple calling conventions on one target is a terrible idea and I don't expect it to occur again, not at this level at least. I know, for example, you could describe the Linux kernel as exposing two calling conventions, depending on if there is a "small" or "large" number of parameters, but really, even neither of these two are the "normal" convention and such things always get wrapped up in a little wrapper with the "standard" calling convention of the platform (except on NT386, sort of, where the wrapper is one of a few conventions). Precedent is that calling conventions are allowed in source for other Windows platforms, but are ignored.They might be #defined away sometimes, but I bet the compiler ignores them.This provides better source compatibility.As x86 gradually goes away, people will stop putting these things in. I guess the alternative to my proposal is an extra level of wrapping behind some made up "portable" interface: something.i3: PROCEDURE SetErrorMode(UINT32); win32/something.m3 PROCEDURE SetErrorMode(UINT32 a) = BEGIN WinBase.SetErrorMode(a); END SetErrorMode; posix/something.m3 PROCEDURE SetErrorMode(UINT32 <* unused *> a) = BEGIN (* do nothing *); END SetErrorMode; The alternative does have more flexibility, obviously, if the Posix implementation is anything other than "do nothing", such as even having to return a value, which might be the case here, then it'd go this way. Also this saves there from being a .c file. Is that sleazy to use the same function name in two modules? I know Modula-3 prepends module names always. It seems like a feature more than a bug. Anyway, as before, a gain here would be to reduce the doubled up odbc and maybe opengl .i3 files, which vary only in calling convention. - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comSubject: RE: [M3devel] Popup Windows stalling regression tests on WinXPDate: Tue, 29 Apr 2008 22:01:51 +0000 ps: Olaf, the debugger install is incredibly fast and small.This isn't Visual Studio.I get, but hadn't previously considered, that future regressions would hang the machine, so a fix is only "temporary", but hey...maybe a process needs to monitor the tests and kill them if they take too long? SetErrorMode will probably fix this, now that I think more.We can add a switch to cm3 and it can call that on itself, and it always gets inherited by child processes. Or we can have a trivial wrapper .exe to run the tests, if the switch to cm3 is not liked. But I have to test it out.Suggest an .exe or switch name? :)If indeed it is SetErrorMode, I'd doseterrormode.exe Though this is a low level name.It could be testwrapper.exe or quashpopups.exe. -Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Tue, 29 Apr 2008 21:38:14 +0000Subject: Re: [M3devel] Popup Windows stalling regression tests on WinXP Yes, this might be it.My x86 Windows machine is out on loan this week, my AMD64 Windows machine needed a reinstall, and I was deep into debugging the AMD64_LINUX problem (on same machine, multi-boot), so I punted. Now I've reinstalled AMD64 Windows and can debug to see what the problem is, to decide if it is quashable..There should be a way without global changes to the machine, but if that's ok, ok. (If this even it.) - Jay> Date: Tue, 29 Apr 2008 17:11:17 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] Popup Windows stalling regression tests on WinXP> > Quoting "Daniel Alejandro Benavides D." :> > > Hi all:> > Olaf, I don't have the Win box here (just a Kubuntu one). But even > > if you don't want to send the file, one can see the report file in > > a window. Should be with two steps: The first click on the blue > > label "Click here " in the first pop up window. That throws another > > window with a label that you can click-on and actually see it> > Well I found with google the instruction to disable that error pop up:> > http://pcsupport.about.com/od/windowsxp/ht/disableerror.htm> > I hope this helps to you.> > Thanks, that sounds good, I'll try it tonight.> > Olaf> > >> > Thanks> >> > Olaf Wagner escribi?: Quoting "Daniel > > Alejandro Benavides D." :> >> >> Hi all:> >> Olaf, but in the case is not even the cm3 process, but a sub process> >> of it, maybe the linker or/and the assembler (what VS version do> >> you have?) which in turn throws the fault, how do you know from> >> sure is cm3 only causing that?, Can you check the label of "Click> >> here for more information". Then you can click on see the files> >> involved in the fault. There you should see the list of files like> >> dll or lib and executable involved, can you send that info?> >> > I'll restart the tests after some more obvious fixes later this> > evening and may be able to send more information tomorrow.> > IIRC there was no label `click here for more information', but> > just `send report to Microsoft' and `do not send'.> >> > Currently we're working hard on a completely different release...> >> > Olaf> > --> > Olaf Wagner -- elego Software Solutions GmbH> > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> >> >> >> >> > ---------------------------------> >> > Enviado desde Correo Yahoo!> > La bandeja de entrada m?s inteligente.> >> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Tue Apr 1 00:56:38 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 31 Mar 2008 18:56:38 -0400 Subject: [M3devel] target naming again..DJGPP? In-Reply-To: References: <1206874390.7023.16.camel@faramir.m3w.org> Message-ID: <20080331225638.GA12935@topoi.pooq.com> On Sun, Mar 30, 2008 at 03:38:28PM +0000, Jay wrote: > The environment variable is still "AMD64" on Windows machines with Intel CPUs. It can't change, for compatibility. > The headers mention AMD64 repeatedly. And it's the name of the platform on Debian Linux. -- hendrik From hosking at cs.purdue.edu Tue Apr 1 01:01:01 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 31 Mar 2008 19:01:01 -0400 Subject: [M3devel] target naming again..DJGPP? In-Reply-To: <20080331225638.GA12935@topoi.pooq.com> References: <1206874390.7023.16.camel@faramir.m3w.org> <20080331225638.GA12935@topoi.pooq.com> Message-ID: On Linux you get x86_64-pc-linux-gnu. This is on an AMD box: zed 52 $ gcc --version gcc (GCC) 4.1.2 (Gentoo 4.1.2 p1.0.2) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. zed 53 $ gcc --verbose Using built-in specs. Target: x86_64-pc-linux-gnu Configured with: /scratch/portage/tmp/portage/sys-devel/gcc-4.1.2/work/ gcc-4.1.2/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/ gcc-bin/4.1.2 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/ include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.2 -- mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.2/man --infodir=/ usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.2/info --with-gxx-include- dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include/g++-v4 -- host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-nls --with-system-zlib --disable-checking --disable-werror -- enable-secureplt --disable-libunwind-exceptions --enable-multilib -- enable-libmudflap --disable-libssp --enable-java-awt=gtk --enable- languages=c,c++,java,treelang,fortran --enable-shared --enable- threads=posix --enable-__cxa_atexit --enable-clocale=gnu Thread model: posix gcc version 4.1.2 (Gentoo 4.1.2 p1.0.2) 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 Mar 31, 2008, at 6:56 PM, hendrik at topoi.pooq.com wrote: > On Sun, Mar 30, 2008 at 03:38:28PM +0000, Jay wrote: >> The environment variable is still "AMD64" on Windows machines with >> Intel CPUs. It can't change, for compatibility. >> The headers mention AMD64 repeatedly. > > And it's the name of the platform on Debian Linux. > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Tue Apr 1 01:08:08 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 31 Mar 2008 19:08:08 -0400 Subject: [M3devel] target naming again..DJGPP? In-Reply-To: References: <1206874390.7023.16.camel@faramir.m3w.org> <20080331225638.GA12935@topoi.pooq.com> Message-ID: <20080331230808.GC12532@topoi.pooq.com> On Mon, Mar 31, 2008 at 07:01:01PM -0400, Tony Hosking wrote: > On Linux you get x86_64-pc-linux-gnu. This is on an AMD box: > Interesting. Linux's naming seems to be inconsistent with gcc. hendrik at april:~$ uname -a Linux april 2.6.18-3-amd64 #1 SMP Mon Dec 4 17:04:37 CET 2006 x86_64 GNU/Linux hendrik at april:~$ but hendrik at april:~$ gcc --verbose Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release x86_64-linux-gnu Thread model: posix gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) hendrik at april:~$ -- hendrik From hosking at cs.purdue.edu Tue Apr 1 01:26:03 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 31 Mar 2008 19:26:03 -0400 Subject: [M3devel] target naming again..DJGPP? In-Reply-To: <20080331230808.GC12532@topoi.pooq.com> References: <1206874390.7023.16.camel@faramir.m3w.org> <20080331225638.GA12935@topoi.pooq.com> <20080331230808.GC12532@topoi.pooq.com> Message-ID: Umm... zed 51 $ uname -a Linux zed.cs.purdue.edu 2.6.23.16 #2 SMP Mon Feb 11 13:01:13 EST 2008 x86_64 Intel(R) Xeon(R) CPU E5310 @ 1.60GHz GenuineIntel GNU/Linux On Mar 31, 2008, at 7:08 PM, hendrik at topoi.pooq.com wrote: > On Mon, Mar 31, 2008 at 07:01:01PM -0400, Tony Hosking wrote: >> On Linux you get x86_64-pc-linux-gnu. This is on an AMD box: >> > > Interesting. Linux's naming seems to be inconsistent with gcc. > > hendrik at april:~$ uname -a > Linux april 2.6.18-3-amd64 #1 SMP Mon Dec 4 17:04:37 CET 2006 x86_64 > GNU/Linux > hendrik at april:~$ > > but > > hendrik at april:~$ gcc --verbose > Using built-in specs. > Target: x86_64-linux-gnu > Configured with: ../src/configure -v > --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr > --enable-shared --with-system-zlib --libexecdir=/usr/lib > --without-included-gettext --enable-threads=posix --enable-nls > --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu > --enable-libstdcxx-debug --enable-mpfr --enable-checking=release > x86_64-linux-gnu > Thread model: posix > gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) > hendrik at april:~$ > > > -- hendrik From wagner at elegosoft.com Tue Apr 1 14:39:00 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 01 Apr 2008 14:39:00 +0200 Subject: [M3devel] cm3 for 64 bit linux In-Reply-To: <47F1BF9D.2010803@sirfrt.com.au> References: <47F1BF9D.2010803@sirfrt.com.au> Message-ID: <20080401143900.hmb8fm7ls0s0ks4c@mail.elegosoft.com> Quoting peter mckinna : > Hey, > > I tried to install the linuxlibc6 on my new debian phenom box running > 64 bit linux and had errors > in the assembler for rthooks mostly something about push and pop > invalid length > So I was wondering if you plan to support a 64 bit modula3 distribution? Support for 64 bit targets is definitely on the todo list, but there is no finished port yet. I wonder if it might be possible to get a 32 bit version to run as a workaround though. Perhaps others on the m3devel list have some experience there? It would also be helpful if you could send the exact action and errors to the list. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Tue Apr 1 15:12:04 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 1 Apr 2008 09:12:04 -0400 Subject: [M3devel] cm3 for 64 bit linux In-Reply-To: <20080401143900.hmb8fm7ls0s0ks4c@mail.elegosoft.com> References: <47F1BF9D.2010803@sirfrt.com.au> <20080401143900.hmb8fm7ls0s0ks4c@mail.elegosoft.com> Message-ID: I have Modula-3 running in 32-bit mode on our x86_64 SMP boxes at Purdue. I just checked in the changes needed for the LINUXLIBC6 config file to do this. You can easily bootstrap from the existing LINUXLIBC6 binary distribution. 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 Apr 1, 2008, at 8:39 AM, Olaf Wagner wrote: > Quoting peter mckinna : > >> Hey, >> >> I tried to install the linuxlibc6 on my new debian phenom box >> running >> 64 bit linux and had errors >> in the assembler for rthooks mostly something about push and pop >> invalid length >> So I was wondering if you plan to support a 64 bit modula3 >> distribution? > > Support for 64 bit targets is definitely on the todo list, but there > is > no finished port yet. I wonder if it might be possible to get a 32 bit > version to run as a workaround though. Perhaps others on the m3devel > list have some experience there? > > It would also be helpful if you could send the exact action and errors > to the list. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Tue Apr 1 21:01:55 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 1 Apr 2008 15:01:55 -0400 Subject: [M3devel] target naming again..DJGPP? In-Reply-To: References: <1206874390.7023.16.camel@faramir.m3w.org> <20080331225638.GA12935@topoi.pooq.com> <20080331230808.GC12532@topoi.pooq.com> Message-ID: <20080401190155.GB14168@topoi.pooq.com> On Mon, Mar 31, 2008 at 07:26:03PM -0400, Tony Hosking wrote: > Umm... > > zed 51 $ uname -a > Linux zed.cs.purdue.edu 2.6.23.16 #2 SMP Mon Feb 11 13:01:13 EST 2008 > x86_64 Intel(R) Xeon(R) CPU E5310 @ 1.60GHz GenuineIntel GNU/Linux Interesting. I'm running Debian etch on a real AMD processor. Could it be you have a 64-bit Intel processor? Could there be a subtle difference between the processors? Or might you be using a different Linux distribution, that might use different terminology? Puzzling. -- hendrik From ndantam at purdue.edu Tue Apr 1 21:52:46 2008 From: ndantam at purdue.edu (Neil Thomas Dantam) Date: Tue, 01 Apr 2008 15:52:46 -0400 Subject: [M3devel] target naming again..DJGPP? In-Reply-To: <20080401190155.GB14168@topoi.pooq.com> References: <1206874390.7023.16.camel@faramir.m3w.org> <20080331225638.GA12935@topoi.pooq.com> <20080331230808.GC12532@topoi.pooq.com> <20080401190155.GB14168@topoi.pooq.com> Message-ID: <47F2928E.5010001@purdue.edu> hendrik at topoi.pooq.com wrote: > On Mon, Mar 31, 2008 at 07:26:03PM -0400, Tony Hosking wrote: >> Umm... >> >> zed 51 $ uname -a >> Linux zed.cs.purdue.edu 2.6.23.16 #2 SMP Mon Feb 11 13:01:13 EST 2008 >> x86_64 Intel(R) Xeon(R) CPU E5310 @ 1.60GHz GenuineIntel GNU/Linux > > Interesting. I'm running Debian etch on a real AMD processor. Could it > be you have a 64-bit Intel processor? Could there be a subtle > difference between the processors? Or might you be using a different > Linux distribution, that might use different terminology? My understanding of these names are as follows: - AMD started calling it's new architecture x86_64 - The Linux Kernel chose to call it's support for the the architecture x86_64 - AMD then changed the architecture name to AMD64 so that they could trademark it - Some Linux Distributions choose to call the architecture AMD64, perhaps to give credit to AMD - Sun and Microsoft marketing call the architecture x64, perhaps just to be contrary The instruction set should be the same for Intel and AMD, modulo extensions like SSE3/4 and virtualization. The differing names are the result of AMD changing the name of the architecture and different developers choosing to use the original or modified name. Also, for linux kernel version "2.6.18-3-amd64", the "-3-amd64" part is a patch version tag added by the distribution maintainer. -- Neil From hosking at cs.purdue.edu Wed Apr 2 01:12:00 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 1 Apr 2008 19:12:00 -0400 Subject: [M3devel] target naming again..DJGPP? In-Reply-To: <20080401190155.GB14168@topoi.pooq.com> References: <1206874390.7023.16.camel@faramir.m3w.org> <20080331225638.GA12935@topoi.pooq.com> <20080331230808.GC12532@topoi.pooq.com> <20080401190155.GB14168@topoi.pooq.com> Message-ID: Even more amusing: http://www.x86-64.org/ On Apr 1, 2008, at 3:01 PM, hendrik at topoi.pooq.com wrote: > On Mon, Mar 31, 2008 at 07:26:03PM -0400, Tony Hosking wrote: >> Umm... >> >> zed 51 $ uname -a >> Linux zed.cs.purdue.edu 2.6.23.16 #2 SMP Mon Feb 11 13:01:13 EST 2008 >> x86_64 Intel(R) Xeon(R) CPU E5310 @ 1.60GHz GenuineIntel GNU/Linux > > Interesting. I'm running Debian etch on a real AMD processor. > Could it > be you have a 64-bit Intel processor? Could there be a subtle > difference between the processors? Or might you be using a different > Linux distribution, that might use different terminology? > > Puzzling. > > -- hendrik From hendrik at topoi.pooq.com Wed Apr 2 12:01:04 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 2 Apr 2008 06:01:04 -0400 Subject: [M3devel] target naming again..DJGPP? In-Reply-To: References: <1206874390.7023.16.camel@faramir.m3w.org> <20080331225638.GA12935@topoi.pooq.com> <20080331230808.GC12532@topoi.pooq.com> <20080401190155.GB14168@topoi.pooq.com> Message-ID: <20080402100104.GA16148@topoi.pooq.com> On Tue, Apr 01, 2008 at 07:12:00PM -0400, Tony Hosking wrote: > Even more amusing: http://www.x86-64.org/ I gather that the amusing thing about x86-64.org is that they seem to talk only about AMD64? -- hendrik From hosking at cs.purdue.edu Wed Apr 2 16:03:46 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 2 Apr 2008 10:03:46 -0400 Subject: [M3devel] target naming again..DJGPP? In-Reply-To: <20080402100104.GA16148@topoi.pooq.com> References: <1206874390.7023.16.camel@faramir.m3w.org> <20080331225638.GA12935@topoi.pooq.com> <20080331230808.GC12532@topoi.pooq.com> <20080401190155.GB14168@topoi.pooq.com> <20080402100104.GA16148@topoi.pooq.com> Message-ID: Precisely! :-) Anyway, given that the target would be to both AMD and Intel versions of x86_64/AMD64 perhaps it is best to go with a neutral name. To that end, x86_64 is probably preferable to AMD64. On Apr 2, 2008, at 6:01 AM, hendrik at topoi.pooq.com wrote: > On Tue, Apr 01, 2008 at 07:12:00PM -0400, Tony Hosking wrote: >> Even more amusing: http://www.x86-64.org/ > > I gather that the amusing thing about x86-64.org is that they seem to > talk only about AMD64? > > -- hendrik From jayk123 at hotmail.com Wed Apr 2 23:35:09 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 2 Apr 2008 21:35:09 +0000 Subject: [M3devel] target naming again..DJGPP? In-Reply-To: References: <1206874390.7023.16.camel@faramir.m3w.org> <20080331225638.GA12935@topoi.pooq.com> <20080331230808.GC12532@topoi.pooq.com> <20080401190155.GB14168@topoi.pooq.com> <20080402100104.GA16148@topoi.pooq.com> Message-ID: AMD was the original implementor. Intel is a clone. Admittedly AMD64 is derived from Intel 8086. AMD64 ascribes credit, and is shorter, is consistent with a widespread name that is not going away (not unique in this aspect), and avoids pesky characters like '-' or '_'. I cast my one vote for AMD64 (for the second time at least :) ) - Jay > From: hosking at cs.purdue.edu> To: hendrik at topoi.pooq.com> Date: Wed, 2 Apr 2008 10:03:46 -0400> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] target naming again..DJGPP?> > Precisely! :-)> > Anyway, given that the target would be to both AMD and Intel versions > of x86_64/AMD64 perhaps it is best to go with a neutral name. To that > end, x86_64 is probably preferable to AMD64.> > On Apr 2, 2008, at 6:01 AM, hendrik at topoi.pooq.com wrote:> > > On Tue, Apr 01, 2008 at 07:12:00PM -0400, Tony Hosking wrote:> >> Even more amusing: http://www.x86-64.org/> >> > I gather that the amusing thing about x86-64.org is that they seem to> > talk only about AMD64?> >> > -- hendrik> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Apr 3 23:59:14 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 3 Apr 2008 21:59:14 +0000 Subject: [M3devel] target naming again..DJGPP? In-Reply-To: References: <1206874390.7023.16.camel@faramir.m3w.org> <20080331225638.GA12935@topoi.pooq.com> <20080331230808.GC12532@topoi.pooq.com> <20080401190155.GB14168@topoi.pooq.com> <20080402100104.GA16148@topoi.pooq.com> Message-ID: While I favor AMD64, another popular name is X64. - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; hendrik at topoi.pooq.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] target naming again..DJGPP?Date: Wed, 2 Apr 2008 21:35:09 +0000 AMD was the original implementor. Intel is a clone. Admittedly AMD64 is derived from Intel 8086. AMD64 ascribes credit, and is shorter, is consistent with a widespread name that is not going away (not unique in this aspect), and avoids pesky characters like '-' or '_'.I cast my one vote for AMD64 (for the second time at least :) ) - Jay > From: hosking at cs.purdue.edu> To: hendrik at topoi.pooq.com> Date: Wed, 2 Apr 2008 10:03:46 -0400> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] target naming again..DJGPP?> > Precisely! :-)> > Anyway, given that the target would be to both AMD and Intel versions > of x86_64/AMD64 perhaps it is best to go with a neutral name. To that > end, x86_64 is probably preferable to AMD64.> > On Apr 2, 2008, at 6:01 AM, hendrik at topoi.pooq.com wrote:> > > On Tue, Apr 01, 2008 at 07:12:00PM -0400, Tony Hosking wrote:> >> Even more amusing: http://www.x86-64.org/> >> > I gather that the amusing thing about x86-64.org is that they seem to> > talk only about AMD64?> >> > -- hendrik> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Apr 4 07:38:06 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 4 Apr 2008 05:38:06 +0000 Subject: [M3devel] environment variables..? Message-ID: for example, currently: export CM3_GCC_BACKEND=yesexport CM3_OSTYPE=POSIXexport CM3_TARGET=NT386export OMIT_GCC=yesexport CM3_ROOT=/dev2/cm3.2export CM3_INSTALL=/cm3export M3CONFIG=/dev2/cm3.2/m3-sys/cminstall/src/config/NT386GNU I propose that CM3_OMIT_GCC and CM3_CONFIG be supported. ? Support for M3CONFIG and OMIT_GCC shall remain for compatibility, reluctantly. OMIT_GCC is strictly a "scripts" thing. M3CONFIG is a cm3 thing. I would grant that M3CONFIG isn't terrible, on the theory that really cm3==m3. Anyway, I'm off to do more important stuff probably. :) (such as investigating test failures) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sat Apr 5 02:39:28 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 4 Apr 2008 20:39:28 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. Message-ID: <20080405003928.GA25238@topoi.pooq.com> I downloaded cm3-min-POSIX-LINUXLIBC6-d5.5.0.tgz, unpacked it, ran ./cminstall and got as far as checking for directory /usr/lib... found 1: /usr/lib Where are the X11 libraries? [/usr/lib](1 of 1) The libraries libX11.so libICE.so libSM.so libXt.so libXext.so libXmu.so libXaw.so are not present in the chosen directory. Would you like to change the library names? [yes] However, lovesong:/usr/lib# ls -l libX11.so* libICE.so* libSM.so* libXt.so* libXext.so* libXmu.so* libXaw.so* lrwxrwxrwx 1 root root 15 2007-12-27 21:38 libICE.so -> libICE.so.6.3.0 lrwxrwxrwx 1 root root 15 2007-12-27 21:38 libICE.so.6 -> libICE.so.6.3.0 -rw-r--r-- 1 root root 84880 2007-08-21 03:19 libICE.so.6.3.0 lrwxrwxrwx 1 root root 14 2007-12-27 21:38 libSM.so -> libSM.so.6.0.0 lrwxrwxrwx 1 root root 14 2007-12-27 21:38 libSM.so.6 -> libSM.so.6.0.0 -rw-r--r-- 1 root root 27944 2007-07-11 04:40 libSM.so.6.0.0 lrwxrwxrwx 1 root root 15 2007-12-27 15:59 libX11.so -> libX11.so.6.2.0 lrwxrwxrwx 1 root root 15 2007-12-27 15:59 libX11.so.6 -> libX11.so.6.2.0 -rw-r--r-- 1 root root 965952 2007-04-03 13:24 libX11.so.6.2.0 lrwxrwxrwx 1 root root 12 2007-12-27 21:39 libXaw.so.7 -> libXaw7.so.7 lrwxrwxrwx 1 root root 16 2008-03-25 21:35 libXext.so -> libXext.so.6.4.0 lrwxrwxrwx 1 root root 16 2008-03-25 21:35 libXext.so.6 -> libXext.so.6.4.0 -rw-r--r-- 1 root root 53788 2008-03-02 10:30 libXext.so.6.4.0 lrwxrwxrwx 1 root root 15 2008-01-30 10:01 libXmu.so.6 -> libXmu.so.6.2.0 -rw-r--r-- 1 root root 85528 2008-01-17 08:58 libXmu.so.6.2.0 lrwxrwxrwx 1 root root 14 2007-12-27 21:38 libXt.so -> libXt.so.6.0.0 lrwxrwxrwx 1 root root 14 2007-12-27 21:38 libXt.so.6 -> libXt.so.6.0.0 -rw-r--r-- 1 root root 324484 2007-05-18 18:15 libXt.so.6.0.0 lovesong:/usr/lib# -- hendrik From hosking at cs.purdue.edu Sat Apr 5 03:08:06 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 4 Apr 2008 21:08:06 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080405003928.GA25238@topoi.pooq.com> References: <20080405003928.GA25238@topoi.pooq.com> Message-ID: <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> Looks like you have a strangely configured X11 subsystem. Look at how libXaw (the one cminstall is actually looking for) is not visible in / usr/lib. On Apr 4, 2008, at 8:39 PM, hendrik at topoi.pooq.com wrote: > I downloaded cm3-min-POSIX-LINUXLIBC6-d5.5.0.tgz, unpacked it, > ran ./cminstall and got as far as > > checking for directory /usr/lib... found > > 1: /usr/lib > Where are the X11 libraries? [/usr/lib](1 of 1) > The libraries libX11.so libICE.so libSM.so libXt.so libXext.so > libXmu.so > libXaw.so are not present in the chosen directory. > Would you like to change the library names? [yes] > > > However, > > > lovesong:/usr/lib# ls -l libX11.so* libICE.so* libSM.so* libXt.so* > libXext.so* libXmu.so* libXaw.so* > lrwxrwxrwx 1 root root 15 2007-12-27 21:38 libICE.so -> > libICE.so.6.3.0 > lrwxrwxrwx 1 root root 15 2007-12-27 21:38 libICE.so.6 -> > libICE.so.6.3.0 > -rw-r--r-- 1 root root 84880 2007-08-21 03:19 libICE.so.6.3.0 > lrwxrwxrwx 1 root root 14 2007-12-27 21:38 libSM.so -> libSM.so. > 6.0.0 > lrwxrwxrwx 1 root root 14 2007-12-27 21:38 libSM.so.6 -> > libSM.so.6.0.0 > -rw-r--r-- 1 root root 27944 2007-07-11 04:40 libSM.so.6.0.0 > lrwxrwxrwx 1 root root 15 2007-12-27 15:59 libX11.so -> > libX11.so.6.2.0 > lrwxrwxrwx 1 root root 15 2007-12-27 15:59 libX11.so.6 -> > libX11.so.6.2.0 > -rw-r--r-- 1 root root 965952 2007-04-03 13:24 libX11.so.6.2.0 > lrwxrwxrwx 1 root root 12 2007-12-27 21:39 libXaw.so.7 -> > libXaw7.so.7 > lrwxrwxrwx 1 root root 16 2008-03-25 21:35 libXext.so -> > libXext.so.6.4.0 > lrwxrwxrwx 1 root root 16 2008-03-25 21:35 libXext.so.6 -> > libXext.so.6.4.0 > -rw-r--r-- 1 root root 53788 2008-03-02 10:30 libXext.so.6.4.0 > lrwxrwxrwx 1 root root 15 2008-01-30 10:01 libXmu.so.6 -> > libXmu.so.6.2.0 > -rw-r--r-- 1 root root 85528 2008-01-17 08:58 libXmu.so.6.2.0 > lrwxrwxrwx 1 root root 14 2007-12-27 21:38 libXt.so -> libXt.so. > 6.0.0 > lrwxrwxrwx 1 root root 14 2007-12-27 21:38 libXt.so.6 -> > libXt.so.6.0.0 > -rw-r--r-- 1 root root 324484 2007-05-18 18:15 libXt.so.6.0.0 > lovesong:/usr/lib# > > > -- hendrik From jayk123 at hotmail.com Sat Apr 5 21:02:01 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 5 Apr 2008 19:02:01 +0000 Subject: [M3devel] returning an array from a function?? Message-ID: How does one return a constant array of unspecified size from a function? You know, what might otherwise be a constant array in the interface, but I'd rather hide it behind a function? something like this, though I haven't found anything that compiles and runs: PROCEDURE GetPathVariableNames(): REF ARRAY OF TEXT = BEGIN RETURN ARRAY OF TEXT { (* not all of these presently have meaning but they are suggested synonyms *) (* 0123456789012345 *) (* 8*) "CM3_ROOT", (* root of source tree *) (* 8*) "M3CONFIG", (*10*) "CM3_CONFIG", (* new unimplemented synonym for M3CONFIG *) (*11*) "CM3_INSTALL", (*11*) "INSTALLROOT", (*12*) "INSTALL_ROOT", (*14*) "CM3_SOURCEROOT", (* new unimplemented synonym for CM3_ROOT *) (*15*) "CM3_INSTALLROOT", (*15*) "CM3_SOURCE_ROOT", (* new unimplemented synonym for CM3_ROOT *) (*16*) "CM3_INSTALL_ROOT" (* 0123456789012345 *) }; END GetPathVariableNames; in C I would write: char** GetWhatever() { const static char* strings[] = { "abc", "def", 0 }; return strings; } or char** GetWhatever(size_t* Count) { const static char* strings[] = { "abc", "def" }; *Count = sizeof(strings)/sizeof(strings[0]); return strings; } The client doesn't have to know if it is constant or not. It could be initialized at runtime, with a dynamic size, or not I should not have to make a copy per call. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Sat Apr 5 21:36:53 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat, 05 Apr 2008 21:36:53 +0200 (CEST) Subject: [M3devel] returning an array from a function?? In-Reply-To: References: Message-ID: On Sat, 5 Apr 2008, Jay wrote: > How does one return a constant array of unspecified size from a function? > You know, what might otherwise be a constant array in the interface, but I'd > rather hide it behind a function? Since you cannot obtain a traced pointer to an existing object, you can only create a reference as global variable, initialize it with NEW and := in the modules startup code and return that pointer by GetPathVariableNames. From jayk123 at hotmail.com Sat Apr 5 21:47:20 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 5 Apr 2008 19:47:20 +0000 Subject: [M3devel] returning an array from a function?? In-Reply-To: References: Message-ID: I made it a constant in the interface. I shouldn't have to pay for heap allocation for constants.. :( Thanks, - Jay > Date: Sat, 5 Apr 2008 21:36:53 +0200 > From: lemming at henning-thielemann.de > Subject: Re: [M3devel] returning an array from a function?? > To: jayk123 at hotmail.com > CC: m3devel at elegosoft.com > > > On Sat, 5 Apr 2008, Jay wrote: > > > How does one return a constant array of unspecified size from a function? > > You know, what might otherwise be a constant array in the interface, but I'd > > rather hide it behind a function? > > Since you cannot obtain a traced pointer to an existing object, you can > only create a reference as global variable, initialize it with NEW and := > in the modules startup code and return that pointer by > GetPathVariableNames. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sun Apr 6 15:49:33 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 6 Apr 2008 09:49:33 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> References: <20080405003928.GA25238@topoi.pooq.com> <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> Message-ID: <20080406134933.GA28414@topoi.pooq.com> On Fri, Apr 04, 2008 at 09:08:06PM -0400, Tony Hosking wrote: > Looks like you have a strangely configured X11 subsystem. Look at how > libXaw (the one cminstall is actually looking for) is not visible in / > usr/lib. So you seem to be telling me that the problem is that a symbolic link libXaw->libXaw7.so.7 is missing, even though libXaw.so.7->libXaw7.so.7 is clearly present, there's a complete suite of links for libXaw7, and, as far as I know, no other programs are having problems with this. hendrik at april:/usr/lib$ ls -l libXaw* lrwxrwxrwx 1 root root 15 2006-06-15 11:33 libXaw3d.so.6 -> libXaw3d.so.6.1 -rw-r--r-- 1 root root 367784 2006-05-03 07:20 libXaw3d.so.6.1 lrwxrwxrwx 1 root root 16 2006-09-20 11:39 libXaw7.so.7 -> libXaw7.so.7.0.0 -rw-r--r-- 1 root root 440496 2006-08-27 19:51 libXaw7.so.7.0.0 lrwxrwxrwx 1 root root 12 2006-09-20 11:39 libXaw.so.7 -> libXaw7.so.7 hendrik at april:/usr/lib$ So, since I run a pretty-well autoconfigured X installed from Debian-stable packages, and regularly updated, something must have gone wrong with one of the upgrades since the dawn of time. Or maybe Debian is just weird. I'll go on the Debian sites and try to identify the misbehaving package. Thanks. From hosking at cs.purdue.edu Sun Apr 6 17:29:48 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 6 Apr 2008 11:29:48 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080406134933.GA28414@topoi.pooq.com> References: <20080405003928.GA25238@topoi.pooq.com> <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> Message-ID: <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> You should have a link from libXaw.so, etc. 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 Apr 6, 2008, at 9:49 AM, hendrik at topoi.pooq.com wrote: > On Fri, Apr 04, 2008 at 09:08:06PM -0400, Tony Hosking wrote: >> Looks like you have a strangely configured X11 subsystem. Look at >> how >> libXaw (the one cminstall is actually looking for) is not visible >> in / >> usr/lib. > > So you seem to be telling me that the problem is that a symbolic > link libXaw->libXaw7.so.7 is missing, even though > libXaw.so.7->libXaw7.so.7 is clearly present, there's a complete suite > of links for libXaw7, and, as far as I know, no other programs are > having problems with this. > > hendrik at april:/usr/lib$ ls -l libXaw* > lrwxrwxrwx 1 root root 15 2006-06-15 11:33 libXaw3d.so.6 -> > libXaw3d.so.6.1 > -rw-r--r-- 1 root root 367784 2006-05-03 07:20 libXaw3d.so.6.1 > lrwxrwxrwx 1 root root 16 2006-09-20 11:39 libXaw7.so.7 -> > libXaw7.so.7.0.0 > -rw-r--r-- 1 root root 440496 2006-08-27 19:51 libXaw7.so.7.0.0 > lrwxrwxrwx 1 root root 12 2006-09-20 11:39 libXaw.so.7 -> > libXaw7.so.7 > hendrik at april:/usr/lib$ > > So, since I run a pretty-well autoconfigured X installed from > Debian-stable packages, and regularly updated, something must have > gone > wrong with one of the upgrades since the dawn of time. Or maybe > Debian > is just weird. I'll go on the Debian sites and try to identify the > misbehaving package. > > Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Apr 6 23:43:12 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 6 Apr 2008 21:43:12 +0000 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> References: <20080405003928.GA25238@topoi.pooq.com> <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> Message-ID: Here is birch: % ls -l /usr/lib/libXaw*lrwxrwxrwx 1 root root 15 2007-05-15 10:55 /usr/lib/libXaw3d.so.6 -> libXaw3d.so.6.1-rw-r--r-- 1 root root 290444 2006-05-03 12:21 /usr/lib/libXaw3d.so.6.1-rw-r--r-- 1 root root 342464 2006-08-27 21:27 /usr/lib/libXaw6.a lrwxrwxrwx 1 root root 16 2007-05-30 11:00 /usr/lib/libXaw6.so -> libXaw6.so.6.0.1lrwxrwxrwx 1 root root 16 2007-05-30 11:00 /usr/lib/libXaw6.so.6 -> libXaw6.so.6.0.1-rw-r--r-- 1 root root 253332 2006-08-27 21:27 /usr/lib/libXaw6.so.6.0.1lrwxrwxrwx 1 root root 16 2007-05-30 10:50 /usr/lib/libXaw7.so.7 -> libXaw7.so.7.0.0-rw-r--r-- 1 root root 363260 2006-08-27 21:27 /usr/lib/libXaw7.so.7.0.0lrwxrwxrwx 1 root root 10 2007-05-30 11:00 /usr/lib/libXaw.so -> libXaw6.solrwxrwxrwx 1 root root 12 2007-05-30 11:00 /usr/lib/libXaw.so.6 -> libXaw6.so.6lrwxrwxrwx 1 root root 12 2007-05-30 10:50 /usr/lib/libXaw.so.7 -> libXaw7.so.7 - Jay From: hosking at cs.purdue.eduTo: hendrik at topoi.pooq.comDate: Sun, 6 Apr 2008 11:29:48 -0400CC: m3devel at elegosoft.comSubject: Re: [M3devel] trouble installing on a Debian lenny system.You should have a link from libXaw.so, etc. 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 Apr 6, 2008, at 9:49 AM, hendrik at topoi.pooq.com wrote: On Fri, Apr 04, 2008 at 09:08:06PM -0400, Tony Hosking wrote: Looks like you have a strangely configured X11 subsystem. Look at how libXaw (the one cminstall is actually looking for) is not visible in / usr/lib.So you seem to be telling me that the problem is that a symbolic link libXaw->libXaw7.so.7 is missing, even though libXaw.so.7->libXaw7.so.7 is clearly present, there's a complete suite of links for libXaw7, and, as far as I know, no other programs are having problems with this.hendrik at april:/usr/lib$ ls -l libXaw*lrwxrwxrwx 1 root root 15 2006-06-15 11:33 libXaw3d.so.6 -> libXaw3d.so.6.1-rw-r--r-- 1 root root 367784 2006-05-03 07:20 libXaw3d.so.6.1lrwxrwxrwx 1 root root 16 2006-09-20 11:39 libXaw7.so.7 -> libXaw7.so.7.0.0-rw-r--r-- 1 root root 440496 2006-08-27 19:51 libXaw7.so.7.0.0lrwxrwxrwx 1 root root 12 2006-09-20 11:39 libXaw.so.7 -> libXaw7.so.7hendrik at april:/usr/lib$ So, since I run a pretty-well autoconfigured X installed from Debian-stable packages, and regularly updated, something must have gone wrong with one of the upgrades since the dawn of time. Or maybe Debian is just weird. I'll go on the Debian sites and try to identify the misbehaving package.Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Apr 7 01:39:58 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 6 Apr 2008 23:39:58 +0000 Subject: [M3devel] RTAllocator.OutOfMemory Message-ID: Is the fix really to annotate these with RAISES declarations? In the klex case, I suspect it'll percolate all the way up. And there is some "difference" between explicit calls to the allocator, vs. regular NEW? 27611 NEXT "../src/DeepCopy.m3", line 56: warning: potentially unhandled exception: RTAllocator.OutOfMemory27972 NEXT "../LINUXLIBC6/RegExpTok.m3", line 41: warning: potentially unhandled exception: RTAllocator.OutOfMemory - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Apr 7 02:38:01 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 7 Apr 2008 00:38:01 +0000 Subject: [M3devel] set relationships? Message-ID: I'm looking at test p1\p155. I haven't started debugging it, just trying to understand it. C:\dev2\cm3\doc\reference\relations.html: " infix <=, >= ... (x,y: Set) : BOOLEAN ... <= returns TRUE if every element of x is an element of y. ... The expression x >= y is equivalent to y <= x. ... In all cases, x < y means (x <= y) AND (x # y), and x > y means y < x " Let's just use the sets {1} and {2}. {1} <= {2} {2} <= {1} {1} < {2} {2} < {1} {1} >= {2} {2} >= {1} {1} > {2} {2} > {1} All these expressions are true from the definitions above. Is that reasonable? It seems a little strange to me. I guess I am very used to strongly ordered things, such that a <= b && a => b implies a == b, not true here, and you can't have both a < b and b < a, which you have here, and that (a < b) == !(a >= b) and similar, which is not true here. In this case, every relation but equality is true. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Apr 7 02:52:10 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 7 Apr 2008 00:52:10 +0000 Subject: [M3devel] set relationships? In-Reply-To: References: Message-ID: oops -- I mean they are all false. From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Mon, 7 Apr 2008 00:38:01 +0000Subject: [M3devel] set relationships? I'm looking at test p1\p155.I haven't started debugging it, just trying to understand it. C:\dev2\cm3\doc\reference\relations.html:" infix <=, >= ... (x,y: Set) : BOOLEAN ... <= returns TRUE if every element of x is an element of y....The expression x >= y is equivalent to y <= x. ...In all cases, x < y means (x <= y) AND (x # y), and x > y means y < x" Let's just use the sets {1} and {2}. {1} <= {2} {2} <= {1} {1} < {2} {2} < {1} {1} >= {2} {2} >= {1} {1} > {2} {2} > {1} All these expressions are true from the definitions above.Is that reasonable?It seems a little strange to me. I guess I am very used to strongly ordered things, such that a <= b && a => b implies a == b, not true here, and you can't have both a < b and b < a, which you have here, and that (a < b) == !(a >= b) and similar, which is not true here. In this case, every relation but equality is true. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Mon Apr 7 03:39:18 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 6 Apr 2008 21:39:18 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> References: <20080405003928.GA25238@topoi.pooq.com> <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> Message-ID: <20080407013918.GA29466@topoi.pooq.com> On Sun, Apr 06, 2008 at 11:29:48AM -0400, Tony Hosking wrote: > You should have a link from libXaw.so, etc. It turns out that link was in the package libXaw7-dev, which was missing on both my 64- and 32-bit systems. -- hendrik hendrik at lovesong:/usr/lib$ ls -l libXaw.so lrwxrwxrwx 1 root root 10 2008-04-06 20:38 libXaw.so -> libXaw7.so hendrik at lovesong:/usr/lib$ From wagner at elegosoft.com Mon Apr 7 12:03:50 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 07 Apr 2008 12:03:50 +0200 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080407013918.GA29466@topoi.pooq.com> References: <20080405003928.GA25238@topoi.pooq.com> <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> Message-ID: <20080407120350.2dkp81ly0gs0ko8s@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > On Sun, Apr 06, 2008 at 11:29:48AM -0400, Tony Hosking wrote: >> You should have a link from libXaw.so, etc. > > It turns out that link was in the package libXaw7-dev, which was missing > on both my 64- and 32-bit systems. This sounds broken to me. M3 has been changed some time ago to look for shared objects instead of archives, as the latter are often not installed on modern systems, but come only as part of development packages. But there must be a simple unique name for the resource; we cannot per default refer to libXaw.so.7.0 or similar, since this would need more updates and maintenance and would break if another version is actually installed. So I don't see a reason for this kind of link to be in the development packages. Should we report this as a bug? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 7 15:56:19 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 7 Apr 2008 09:56:19 -0400 Subject: [M3devel] RTAllocator.OutOfMemory In-Reply-To: References: Message-ID: Just put FATAL declarations to have the system die when it receives those errors. On Apr 6, 2008, at 7:39 PM, Jay wrote: > Is the fix really to annotate these with RAISES declarations? > In the klex case, I suspect it'll percolate all the way up. > And there is some "difference" between explicit calls to the > allocator, vs. regular NEW? > > 27611 NEXT "../src/DeepCopy.m3", line 56: warning: potentially > unhandled exception: RTAllocator.OutOfMemory > 27972 NEXT "../LINUXLIBC6/RegExpTok.m3", line 41: warning: > potentially unhandled exception: RTAllocator.OutOfMemory > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Apr 7 18:29:26 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 7 Apr 2008 12:29:26 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080407120350.2dkp81ly0gs0ko8s@mail.elegosoft.com> References: <20080405003928.GA25238@topoi.pooq.com> <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> <20080407120350.2dkp81ly0gs0ko8s@mail.elegosoft.com> Message-ID: Generally, you'll need all dev packages with CM3. 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 Apr 7, 2008, at 6:03 AM, Olaf Wagner wrote: > Quoting hendrik at topoi.pooq.com: > >> On Sun, Apr 06, 2008 at 11:29:48AM -0400, Tony Hosking wrote: >>> You should have a link from libXaw.so, etc. >> >> It turns out that link was in the package libXaw7-dev, which was >> missing >> on both my 64- and 32-bit systems. > > This sounds broken to me. > > M3 has been changed some time ago to look for shared objects instead > of > archives, as the latter are often not installed on modern systems, but > come only as part of development packages. > > But there must be a simple unique name for the resource; we cannot > per default refer to libXaw.so.7.0 or similar, since this would > need more updates and maintenance and would break if another version > is actually installed. > > So I don't see a reason for this kind of link to be in the development > packages. Should we report this as a bug? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Apr 7 21:28:49 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 07 Apr 2008 21:28:49 +0200 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: References: <20080405003928.GA25238@topoi.pooq.com> <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> <20080407120350.2dkp81ly0gs0ko8s@mail.elegosoft.com> Message-ID: <20080407212849.1ovvw8niaocs8g0g@mail.elegosoft.com> Quoting Tony Hosking : > Generally, you'll need all dev packages with CM3. Hm 8-/ Seems I'm not really up-to-date here... Olaf > 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 Apr 7, 2008, at 6:03 AM, Olaf Wagner wrote: > >> Quoting hendrik at topoi.pooq.com: >> >>> On Sun, Apr 06, 2008 at 11:29:48AM -0400, Tony Hosking wrote: >>>> You should have a link from libXaw.so, etc. >>> >>> It turns out that link was in the package libXaw7-dev, which was missing >>> on both my 64- and 32-bit systems. >> >> This sounds broken to me. >> >> M3 has been changed some time ago to look for shared objects instead of >> archives, as the latter are often not installed on modern systems, but >> come only as part of development packages. >> >> But there must be a simple unique name for the resource; we cannot >> per default refer to libXaw.so.7.0 or similar, since this would >> need more updates and maintenance and would break if another version >> is actually installed. >> >> So I don't see a reason for this kind of link to be in the development >> packages. Should we report this as a bug? >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Mon Apr 7 21:41:08 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 7 Apr 2008 15:41:08 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080407212849.1ovvw8niaocs8g0g@mail.elegosoft.com> References: <20080405003928.GA25238@topoi.pooq.com> <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> <20080407120350.2dkp81ly0gs0ko8s@mail.elegosoft.com> <20080407212849.1ovvw8niaocs8g0g@mail.elegosoft.com> Message-ID: <78F773EF-E82D-43B7-B402-60C854A6BDE1@cs.purdue.edu> Perhaps you're right. 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 Apr 7, 2008, at 3:28 PM, Olaf Wagner wrote: > Quoting Tony Hosking : > >> Generally, you'll need all dev packages with CM3. > > Hm 8-/ Seems I'm not really up-to-date here... > > Olaf > >> 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 Apr 7, 2008, at 6:03 AM, Olaf Wagner wrote: >> >>> Quoting hendrik at topoi.pooq.com: >>> >>>> On Sun, Apr 06, 2008 at 11:29:48AM -0400, Tony Hosking wrote: >>>>> You should have a link from libXaw.so, etc. >>>> >>>> It turns out that link was in the package libXaw7-dev, which was >>>> missing >>>> on both my 64- and 32-bit systems. >>> >>> This sounds broken to me. >>> >>> M3 has been changed some time ago to look for shared objects >>> instead of >>> archives, as the latter are often not installed on modern systems, >>> but >>> come only as part of development packages. >>> >>> But there must be a simple unique name for the resource; we cannot >>> per default refer to libXaw.so.7.0 or similar, since this would >>> need more updates and maintenance and would break if another version >>> is actually installed. >>> >>> So I don't see a reason for this kind of link to be in the >>> development >>> packages. Should we report this as a bug? >>> >>> Olaf >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>> Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Tue Apr 8 02:36:30 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 7 Apr 2008 20:36:30 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080407120350.2dkp81ly0gs0ko8s@mail.elegosoft.com> References: <20080405003928.GA25238@topoi.pooq.com> <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> <20080407120350.2dkp81ly0gs0ko8s@mail.elegosoft.com> Message-ID: <20080408003630.GA30598@topoi.pooq.com> On Mon, Apr 07, 2008 at 12:03:50PM +0200, Olaf Wagner wrote: > Quoting hendrik at topoi.pooq.com: > > >On Sun, Apr 06, 2008 at 11:29:48AM -0400, Tony Hosking wrote: > >>You should have a link from libXaw.so, etc. > > > >It turns out that link was in the package libXaw7-dev, which was missing > >on both my 64- and 32-bit systems. > > This sounds broken to me. > > M3 has been changed some time ago to look for shared objects instead of > archives, as the latter are often not installed on modern systems, but > come only as part of development packages. > > But there must be a simple unique name for the resource; we cannot > per default refer to libXaw.so.7.0 or similar, since this would > need more updates and maintenance and would break if another version > is actually installed. > > So I don't see a reason for this kind of link to be in the development > packages. Should we report this as a bug? I suppose that depends on whether the linker and loader understand the version numbers in the name and does the right thing in the absence of links. I know there's a convention as to which parts of the versin number indicate compatible vs incompatible changes. I thought that compatible alternatives could be found automatically at load time, and (I thought) the wrong alternatives would not be. I don't know whether the mechanism for this is symbolic links. I suppose it could be. So I don't know whether this is a bug. The major version number changes for incompatible changes. If the linker links a program to a particular shared library, changes in the minor version wouldn't matter, but change in the major version likely would. So I'd guess that the linker would include a reference to the particular major version in the linked binary, not a reference to the versin-free file name. Thus the version-free library name would not be needed just for running the binary. It might end up referring to an incompatible version. I could be wrong, of course. I'm just trying to guess what Debian's reasoning might have been. -- hendrik From hendrik at topoi.pooq.com Tue Apr 8 19:17:34 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 8 Apr 2008 13:17:34 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080407013918.GA29466@topoi.pooq.com> References: <20080405003928.GA25238@topoi.pooq.com> <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> Message-ID: <20080408171734.GA31674@topoi.pooq.com> On Sun, Apr 06, 2008 at 09:39:18PM -0400, hendrik at topoi.pooq.com wrote: > On Sun, Apr 06, 2008 at 11:29:48AM -0400, Tony Hosking wrote: > > You should have a link from libXaw.so, etc. > > It turns out that link was in the package libXaw7-dev, which was missing > on both my 64- and 32-bit systems. > > -- hendrik > > hendrik at lovesong:/usr/lib$ ls -l libXaw.so > lrwxrwxrwx 1 root root 10 2008-04-06 20:38 libXaw.so -> libXaw7.so > hendrik at lovesong:/usr/lib$ I resumed installation. Ths installer failed to find my odbc or my postresql, which I thought would be OK since I don't expect to need them and I didn't have them installed. I then followed the instructions on http://modula3.elegosoft.com/cm3/installation.html using the commands mkdir cm3 cd cm3 tar -zxf /path/to/cm3-src-sys-CM3VERSION.tgz tar -zxf /path/to/cm3-src-gnu-CM3VERSION.tgz tar -zxf /path/to/cm3-src-std-CM3VERSION.tgz (1) I patched to avoid the asm/ipc.h problem. (2) the last step failed as follows: hendrik at lovesong:~/cm3/scripts$ ./do-cm3-std.sh buildship CM3C = /farhome/hendrik/cm3/scripts/pkgmap.sh -c "cm3 -build -DROOT='/farhome/hendrik/cm3' && cm3 -ship -DROOT='/farhome/hendrik/cm3' " m3gc-simple m3core libm3 patternmatching m3middle m3quake m3scanner m3tools m3cgcat m3cggen m3gdb m3bundle arithmetic bitvector digraph parseparams realgeometry set slisp sortedtableextras table-list tempfiles tcp udp libsio libbuf debug listfuncs embutils m3tk-misc http binIO commandrw m3tk mtex m3totex m3tohtml m3scan m3markup m3browser cmpdir cmpfp dirfp uniq netobj netobjd stubgen events rdwr sharedobj sharedobjgen odbc postgres95 db smalldb stable stablegen X11R4 ui PEX vbtkit cmvbt jvideo videovbt web formsvbtpixmaps formsvbt formsview formsedit codeview mg mgkit opengl anim3D zeus m3zume synloc synex metasyn obliqrt obliqparse obliqprint obliq obliqlibemb obliqlibm3 obliqlibui obliqlibanim obliqsrvstd obliqsrvui obliqbinmin obliqbinstd obliqbinui obliqbinanim visualobliq vocgi voquery vorun webvbt recordheap rehearsecode replayheap showheap shownew showthread pkl-fonts juno-machine juno-compiler juno-app cube calculator fisheye mentor === package /farhome/hendrik/cm3/m3-libs/m3gc-simple === +++ cm3 -build -DROOT='/farhome/hendrik/cm3' && cm3 -ship -DROOT='/farhome/hendrik/cm3' +++ /bin/sh: line 1: 10644 Segmentation fault cm3 -build -DROOT='/farhome/hendrik/cm3' *** execution of failed *** hendrik at lovesong:~/cm3/scripts$ (my text editor wrapped the lines when I pasted them into this message)) Presumably there's something else weird about my system. Any ideas what to look for? -- hendrik From jayk123 at hotmail.com Tue Apr 8 22:16:05 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 8 Apr 2008 20:16:05 +0000 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080408171734.GA31674@topoi.pooq.com> References: <20080405003928.GA25238@topoi.pooq.com> <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> <20080408171734.GA31674@topoi.pooq.com> Message-ID: Try current source from CVS instead of the .tgz files.Be sure to delete scripts/PKGS. m3gc-simple no longer exists. - Jay > Date: Tue, 8 Apr 2008 13:17:34 -0400> From: hendrik at topoi.pooq.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] trouble installing on a Debian lenny system.> > On Sun, Apr 06, 2008 at 09:39:18PM -0400, hendrik at topoi.pooq.com wrote:> > On Sun, Apr 06, 2008 at 11:29:48AM -0400, Tony Hosking wrote:> > > You should have a link from libXaw.so, etc.> > > > It turns out that link was in the package libXaw7-dev, which was missing > > on both my 64- and 32-bit systems.> > > > -- hendrik> > > > hendrik at lovesong:/usr/lib$ ls -l libXaw.so> > lrwxrwxrwx 1 root root 10 2008-04-06 20:38 libXaw.so -> libXaw7.so> > hendrik at lovesong:/usr/lib$ > > I resumed installation. Ths installer failed to find my odbc or my > postresql, which I thought would be OK since I don't expect to need > them and I didn't have them installed.> > I then followed the instructions on > http://modula3.elegosoft.com/cm3/installation.html using the commands> > mkdir cm3> cd cm3> tar -zxf /path/to/cm3-src-sys-CM3VERSION.tgz> tar -zxf /path/to/cm3-src-gnu-CM3VERSION.tgz> tar -zxf /path/to/cm3-src-std-CM3VERSION.tgz> > > (1) I patched to avoid the asm/ipc.h problem.> (2) the last step failed as follows:> > hendrik at lovesong:~/cm3/scripts$ ./do-cm3-std.sh buildship> CM3C => /farhome/hendrik/cm3/scripts/pkgmap.sh -c "cm3 -build > -DROOT='/farhome/hendrik/cm3' && cm3 -ship > -DROOT='/farhome/hendrik/cm3' " m3gc-simple m3core libm3 patternmatching > m3middle m3quake m3scanner m3tools m3cgcat m3cggen m3gdb m3bundle > arithmetic bitvector digraph parseparams realgeometry set slisp > sortedtableextras table-list tempfiles tcp udp libsio libbuf debug > listfuncs embutils m3tk-misc http binIO commandrw m3tk mtex m3totex > m3tohtml m3scan m3markup m3browser cmpdir cmpfp dirfp uniq netobj > netobjd stubgen events rdwr sharedobj sharedobjgen odbc postgres95 db > smalldb stable stablegen X11R4 ui PEX vbtkit cmvbt jvideo videovbt web > formsvbtpixmaps formsvbt formsview formsedit codeview mg mgkit opengl > anim3D zeus m3zume synloc synex metasyn obliqrt obliqparse obliqprint > obliq obliqlibemb obliqlibm3 obliqlibui obliqlibanim obliqsrvstd > obliqsrvui obliqbinmin obliqbinstd obliqbinui obliqbinanim visualobliq > vocgi voquery vorun webvbt recordheap rehearsecode replayheap showheap > shownew showthread pkl-fonts juno-machine juno-compiler juno-app cube > calculator fisheye mentor> === package /farhome/hendrik/cm3/m3-libs/m3gc-simple ===> +++ cm3 -build -DROOT='/farhome/hendrik/cm3' && cm3 -ship > -DROOT='/farhome/hendrik/cm3' +++> /bin/sh: line 1: 10644 Segmentation fault cm3 -build > -DROOT='/farhome/hendrik/cm3'> *** execution of failed ***> hendrik at lovesong:~/cm3/scripts$ > > > (my text editor wrapped the lines when I pasted them into this message))> > Presumably there's something else weird about my system.> > Any ideas what to look for?> > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Wed Apr 9 01:15:41 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 8 Apr 2008 19:15:41 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: References: <20080405003928.GA25238@topoi.pooq.com> <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> <20080408171734.GA31674@topoi.pooq.com> Message-ID: <20080408231541.GA31929@topoi.pooq.com> On Tue, Apr 08, 2008 at 08:16:05PM +0000, Jay wrote: > Try current source from CVS instead of the .tgz files.Be sure to delete scripts/PKGS. > m3gc-simple no longer exists. > > - Jay Did that. Used cvs -z 3 -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 as described in http://modula3.elegosoft.com/cm3/install-cm3-on-ubuntu-7-10.html (although I have Debian) and got hendrik at lovesong:~/cm3/scripts$ ./do-cm3-core.sh buildship making /farhome/hendrik/cm3/scripts/PKGS (slow but rare) /farhome/hendrik/cm3/scripts/pkgmap.sh -c "cm3 -build -DROOT='/farhome/hendrik/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' && cm3 -ship -DROOT='/farhome/hendrik/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' " import-libs m3cc m3core libm3 patternmatching sysutils unittest m3middle m3objfile m3linker m3back m3staloneback m3front m3quake cm3 m3scanner m3tools m3cgcat m3cggen m3bundle mklib fix_nl libdump bitvector digraph parseparams realgeometry set slisp sortedtableextras table-list tempfiles tcl === package /farhome/hendrik/cm3/m3-win/import-libs === === package omitted on this platform === ==> /farhome/hendrik/cm3/m3-win/import-libs done === package /farhome/hendrik/cm3/m3-sys/m3cc === +++ cm3 -build -DROOT='/farhome/hendrik/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' && cm3 -ship -DROOT='/farhome/hendrik/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' +++ /bin/sh: line 1: 30590 Segmentation fault cm3 -build -DROOT='/farhome/hendrik/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' *** execution of cm3 -build -DROOT='/farhome/hendrik/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' && cm3 -ship -DROOT='/farhome/hendrik/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' failed *** hendrik at lovesong:~/cm3/scripts$ -- hendrik Perhaps I have to wipe /usr/local/cm3 and start again with the cm3-install script? - hendrik From hendrik at topoi.pooq.com Wed Apr 9 01:33:38 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 8 Apr 2008 19:33:38 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080408231541.GA31929@topoi.pooq.com> References: <20080405003928.GA25238@topoi.pooq.com> <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> <20080408171734.GA31674@topoi.pooq.com> <20080408231541.GA31929@topoi.pooq.com> Message-ID: <20080408233338.GA32037@topoi.pooq.com> On Tue, Apr 08, 2008 at 07:15:41PM -0400, hendrik at topoi.pooq.com wrote: > > Perhaps I have to wipe /usr/local/cm3 and start again with the > cm3-install script? > > - hendrik Now doing that. It seems to be working better now. -- hendrik From hendrik at topoi.pooq.com Wed Apr 9 02:02:07 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 8 Apr 2008 20:02:07 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080408233338.GA32037@topoi.pooq.com> References: <20080405003928.GA25238@topoi.pooq.com> <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> <20080408171734.GA31674@topoi.pooq.com> <20080408231541.GA31929@topoi.pooq.com> <20080408233338.GA32037@topoi.pooq.com> Message-ID: <20080409000207.GA32073@topoi.pooq.com> On Tue, Apr 08, 2008 at 07:33:38PM -0400, hendrik at topoi.pooq.com wrote: > On Tue, Apr 08, 2008 at 07:15:41PM -0400, hendrik at topoi.pooq.com wrote: > > > > Perhaps I have to wipe /usr/local/cm3 and start again with the > > cm3-install script? > > > > - hendrik > > Now doing that. It seems to be working better now. > > -- hendrik > Everything went fine until new source -> compiling Cstdlib.i3 "../src/word/LongRep.i3", line 2: undefined (LONGINT) "../src/C/32BITS/BasicCtypes.i3", line 18: undefined (LONGINT) "../src/C/Common/Cstdlib.i3", line 13: imported interface contains errors (Ctypes) 3 errors encountered It looks as if LONGINT isn't defined. This is within package === package /farhome/hendrik/cm3/m3-libs/m3core === At this point I presume it is still using the cminstalled compiler. Does that need to be nudged?. -- hendrik From hendrik at topoi.pooq.com Wed Apr 9 02:33:29 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 8 Apr 2008 20:33:29 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080409000207.GA32073@topoi.pooq.com> References: <20080405003928.GA25238@topoi.pooq.com> <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> <20080408171734.GA31674@topoi.pooq.com> <20080408231541.GA31929@topoi.pooq.com> <20080408233338.GA32037@topoi.pooq.com> <20080409000207.GA32073@topoi.pooq.com> Message-ID: <20080409003329.GB32073@topoi.pooq.com> On Tue, Apr 08, 2008 at 08:02:07PM -0400, hendrik at topoi.pooq.com wrote: > > At this point I presume it is still using the cminstalled compiler. > Does that need to be nudged?. > > -- hendrik > I obtained another cminstall, from ../cm3-min-POSIX-LINUXLIBC6-d5.7.0-2008-04-08-14-00-05.tgz Tried it. It rushed through the dialogues without giving me a chance to answer anything. (Is this a bug?) It even found odbc and postgres95, which I thought hadn't been installed. Where are the Postgres95 libraries? looking for library file(s): libpq.so checking for library files in directory /usr/lib... not found checking for library files in directory /usr/local/postgres95/lib... not found checking for library files in directory /usr/local/lib... not found checking for directory /usr/lib... found --> "-L/usr/lib" But, hendrik at lovesong:~$ ls /usr/lib/libpq* ls: cannot access /usr/lib/libpq*: No such file or directory hendrik at lovesong:~$ and Where are the ODBC libraries? looking for library file(s): libiodbc.so checking for library files in directory /usr/lib... not found checking for library files in directory /usr/local/lib... not found checking for library files in directory /usr/local/pgsql/lib... not found checking for library files in directory /usr/local/postgres95/lib... not found checking for directory /usr/lib... found --> "-L/usr/lib" but hendrik at lovesong:~$ ls /usr/lib/libio* ls: cannot access /usr/lib/libio*: No such file or directory hendrik at lovesong:~$ Finding these two nonexistent files does seem to be a bug. -- hendrik From jay.krell at cornell.edu Wed Apr 9 02:57:39 2008 From: jay.krell at cornell.edu (Jay) Date: Wed, 9 Apr 2008 00:57:39 +0000 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080409003329.GB32073@topoi.pooq.com> References: <20080405003928.GA25238@topoi.pooq.com> <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> <20080408171734.GA31674@topoi.pooq.com> <20080408231541.GA31929@topoi.pooq.com> <20080408233338.GA32037@topoi.pooq.com> <20080409000207.GA32073@topoi.pooq.com> <20080409003329.GB32073@topoi.pooq.com> Message-ID: "Rushing through the dialogues" is a new feature. I kept complaining about how dumb it was. On NT386* at least, I stopped using cminstall altogether. There is an -interactive option or somesuch. - Jay > Date: Tue, 8 Apr 2008 20:33:29 -0400> From: hendrik at topoi.pooq.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] trouble installing on a Debian lenny system.> > On Tue, Apr 08, 2008 at 08:02:07PM -0400, hendrik at topoi.pooq.com wrote:> > > > At this point I presume it is still using the cminstalled compiler. > > Does that need to be nudged?.> > > > -- hendrik> > > > I obtained another cminstall, from > ../cm3-min-POSIX-LINUXLIBC6-d5.7.0-2008-04-08-14-00-05.tgz> > Tried it. It rushed through the dialogues without giving me a chance to > answer anything. (Is this a bug?) It even found odbc and postgres95, > which I thought hadn't been installed.> > Where are the Postgres95 libraries?> looking for library file(s): libpq.so> checking for library files in directory /usr/lib... not found> checking for library files in directory /usr/local/postgres95/lib... not > found> checking for library files in directory /usr/local/lib... not found> checking for directory /usr/lib... found > --> "-L/usr/lib"> > > But, > > hendrik at lovesong:~$ ls /usr/lib/libpq*> ls: cannot access /usr/lib/libpq*: No such file or directory> hendrik at lovesong:~$ > > > and > > Where are the ODBC libraries?> looking for library file(s): libiodbc.so> checking for library files in directory /usr/lib... not found> checking for library files in directory /usr/local/lib... not found> checking for library files in directory /usr/local/pgsql/lib... not > found> checking for library files in directory /usr/local/postgres95/lib... not > found> checking for directory /usr/lib... found > --> "-L/usr/lib"> > but> > hendrik at lovesong:~$ ls /usr/lib/libio*> ls: cannot access /usr/lib/libio*: No such file or directory> hendrik at lovesong:~$ > > Finding these two nonexistent files does seem to be a bug.> > -- hendrik> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Apr 9 03:00:20 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 9 Apr 2008 01:00:20 +0000 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080409000207.GA32073@topoi.pooq.com> References: <20080405003928.GA25238@topoi.pooq.com> <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> <20080408171734.GA31674@topoi.pooq.com> <20080408231541.GA31929@topoi.pooq.com> <20080408233338.GA32037@topoi.pooq.com> <20080409000207.GA32073@topoi.pooq.com> Message-ID: Right. This is a normal symptom of using an "old" compiler to compile current source. You must first build a new compiler against an old runtime (which you must get from "somewhere", such as an existing older install), then use that to build a new runtime. scripts/upgrade.sh scripts/python/upgrade.py scripts/win/upgrade.cmd should all handle the "dance" for you. - Jay > Date: Tue, 8 Apr 2008 20:02:07 -0400> From: hendrik at topoi.pooq.com > "../src/word/LongRep.i3", line 2: undefined (LONGINT)> "../src/C/32BITS/BasicCtypes.i3", line 18: undefined (LONGINT)> "../src/C/Common/Cstdlib.i3", line 13: imported interface contains errors (Ctypes)> 3 errors encountered> > At this point I presume it is still using the cminstalled compiler. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Wed Apr 9 03:14:18 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 8 Apr 2008 21:14:18 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: References: <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> <20080408171734.GA31674@topoi.pooq.com> <20080408231541.GA31929@topoi.pooq.com> <20080408233338.GA32037@topoi.pooq.com> <20080409000207.GA32073@topoi.pooq.com> Message-ID: <20080409011418.GC32073@topoi.pooq.com> On Wed, Apr 09, 2008 at 01:00:20AM +0000, Jay wrote: > Right. > This is a normal symptom of using an "old" compiler to compile current source. > You must first build a new compiler against an old runtime (which you must get from "somewhere", such as an existing older install), then use that to build a new runtime. > > scripts/upgrade.sh > scripts/python/upgrade.py > scripts/win/upgrade.cmd > > should all handle the "dance" for you. > > - Jay Except I don't *have* a working old runtime. I've mentioned my experiences with ../cm3-min-POSIX-LINUXLIBC6-d5.7.0-2008-04-08-14-00-05.tgz in another post. I acquired it in the hope that it wouldn't be an old runtime. -- hendrik > > > > > Date: Tue, 8 Apr 2008 20:02:07 -0400> From: hendrik at topoi.pooq.com > > "../src/word/LongRep.i3", line 2: undefined (LONGINT)> "../src/C/32BITS/BasicCtypes.i3", line 18: undefined (LONGINT)> "../src/C/Common/Cstdlib.i3", line 13: imported interface contains errors (Ctypes)> 3 errors encountered> > At this point I presume it is still using the cminstalled compiler. From hendrik at topoi.pooq.com Wed Apr 9 03:17:42 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 8 Apr 2008 21:17:42 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: References: <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> <20080408171734.GA31674@topoi.pooq.com> <20080408231541.GA31929@topoi.pooq.com> <20080408233338.GA32037@topoi.pooq.com> <20080409000207.GA32073@topoi.pooq.com> <20080409003329.GB32073@topoi.pooq.com> Message-ID: <20080409011742.GD32073@topoi.pooq.com> On Wed, Apr 09, 2008 at 12:57:39AM +0000, Jay wrote: > "Rushing through the dialogues" is a new feature. I kept complaining about how dumb it was. On NT386* at least, I stopped using cminstall altogether. There is an -interactive option or somesuch. > > - Jay > But I suspect finding nonexistent files isn't a feature, new or old. Is it going to cause trouble later on? Is it going to try to install things that depend on postgres and odbc and fall apart? -- hendrik From hendrik at topoi.pooq.com Wed Apr 9 03:24:11 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 8 Apr 2008 21:24:11 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080409011742.GD32073@topoi.pooq.com> References: <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> <20080408171734.GA31674@topoi.pooq.com> <20080408231541.GA31929@topoi.pooq.com> <20080408233338.GA32037@topoi.pooq.com> <20080409000207.GA32073@topoi.pooq.com> <20080409003329.GB32073@topoi.pooq.com> <20080409011742.GD32073@topoi.pooq.com> Message-ID: <20080409012411.GE32073@topoi.pooq.com> On Tue, Apr 08, 2008 at 09:17:42PM -0400, hendrik at topoi.pooq.com wrote: > On Wed, Apr 09, 2008 at 12:57:39AM +0000, Jay wrote: > > "Rushing through the dialogues" is a new feature. I kept complaining > about how dumb it was. On NT386* at least, I stopped using cminstall > altogether. There is an -interactive option or somesuch. > > > > > - Jay > > > > But I suspect finding nonexistent files isn't a feature, new or old. Is > it going to cause trouble later on? Is it going to try to install > things that depend on postgres and odbc and fall apart? The -interactive option gives me interaction. But it still finds the nonexistent libpq.so in /usr/lib. Where are the Postgres95 libraries? looking for library file(s): libpq.so checking for library files in directory /usr/lib... not found checking for library files in directory /usr/local/postgres95/lib... not found checking for library files in directory /usr/local/lib... not found checking for directory /usr/lib... found 1: /usr/lib Where are the Postgres95 libraries? [/usr/lib](1 of 1) Only after I accept the default location does it notice threre's no such file there. I find this confusing, because it correctly fails to find in in all the other locations. But I guess I can live with this, because it gives me the chance to say: The libraries libpq.so are not present in the chosen directory. Would you like to change the library names? [yes] no Would you like to continue nonetheless? [yes] yes Thanks. -- hendrik From hendrik at topoi.pooq.com Wed Apr 9 04:25:29 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 8 Apr 2008 22:25:29 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080409012411.GE32073@topoi.pooq.com> References: <20080407013918.GA29466@topoi.pooq.com> <20080408171734.GA31674@topoi.pooq.com> <20080408231541.GA31929@topoi.pooq.com> <20080408233338.GA32037@topoi.pooq.com> <20080409000207.GA32073@topoi.pooq.com> <20080409003329.GB32073@topoi.pooq.com> <20080409011742.GD32073@topoi.pooq.com> <20080409012411.GE32073@topoi.pooq.com> Message-ID: <20080409022529.GF32073@topoi.pooq.com> On Tue, Apr 08, 2008 at 09:24:11PM -0400, hendrik at topoi.pooq.com wrote: > On Tue, Apr 08, 2008 at 09:17:42PM -0400, hendrik at topoi.pooq.com wrote: > > On Wed, Apr 09, 2008 at 12:57:39AM +0000, Jay wrote: > > > "Rushing through the dialogues" is a new feature. I kept complaining > > about how dumb it was. On NT386* at least, I stopped using cminstall > > altogether. There is an -interactive option or somesuch. > > > > > > > > - Jay > > > > > > > But I suspect finding nonexistent files isn't a feature, new or old. Is > > it going to cause trouble later on? Is it going to try to install > > things that depend on postgres and odbc and fall apart? > > The -interactive option gives me interaction. But it still finds the > nonexistent libpq.so in /usr/lib. > > Where are the Postgres95 libraries? > looking for library file(s): libpq.so > checking for library files in directory /usr/lib... not found > checking for library files in directory /usr/local/postgres95/lib... > not found > checking for library files in directory /usr/local/lib... not found > checking for directory /usr/lib... found > > 1: /usr/lib > Where are the Postgres95 libraries? [/usr/lib](1 of 1) > > > Only after I accept the default location does it notice threre's no such > file there. I find this confusing, because it correctly fails to find > in in all the other locations. > > But I guess I can live with this, because it gives me the chance to say: > > The libraries libpq.so are not present in the chosen directory. > Would you like to change the library names? [yes] no > Would you like to continue nonetheless? [yes] yes > > Thanks. > > -- hendrik Well, it's working now. My trouble do suggest to me that the downloads and instructions obtained from http://modula3.elegosoft.com/cm3/installation.html may no longer work properly. The ones that worked for me were http://modula3.elegosoft.com/cm3/install-cm3-on-ubuntu-7-10.html Further, the noninteractive default for cminstall is quite confusing. The instructions should recommend the -interactive option. Finally, I kept typing cm3 --version instead of cm3 -version The double hyphen is such a standard on other software that it should perhaps be accepted here, too. -- hendrik From wagner at elegosoft.com Wed Apr 9 09:05:49 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 09 Apr 2008 09:05:49 +0200 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080409011418.GC32073@topoi.pooq.com> References: <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> <20080408171734.GA31674@topoi.pooq.com> <20080408231541.GA31929@topoi.pooq.com> <20080408233338.GA32037@topoi.pooq.com> <20080409000207.GA32073@topoi.pooq.com> <20080409011418.GC32073@topoi.pooq.com> Message-ID: <20080409090549.cdpk2tjocgg0wcg8@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > On Wed, Apr 09, 2008 at 01:00:20AM +0000, Jay wrote: >> Right. >> This is a normal symptom of using an "old" compiler to compile >> current source. >> You must first build a new compiler against an old runtime (which >> you must get from "somewhere", such as an existing older install), >> then use that to build a new runtime. >> >> scripts/upgrade.sh >> scripts/python/upgrade.py >> scripts/win/upgrade.cmd >> >> should all handle the "dance" for you. >> >> - Jay > > Except I don't *have* a working old runtime. I've mentioned my > experiences with > ../cm3-min-POSIX-LINUXLIBC6-d5.7.0-2008-04-08-14-00-05.tgz > in another post. I acquired it in the hope that it wouldn't be an old > runtime. Three short notes: o cminstall didn't find the non-existent libraries, it just checked the existence of a directory: checking for library files in directory /usr/local/lib... not found ^^^^^^^^^^^^^^^^^^^^^^^^^^ checking for directory /usr/lib... found ^^^^^^^^^^^^^ o Your compiler didn't have LONGINT support, so you need to use upgrade.sh. This should be documented (I think it is), as the introduction of LONGINT was an incompatible change wrt. bootstrapping. o cm3-min-POSIX-LINUXLIBC6-d5.7.0-2008-04-08-14-00-05.tgz should contain a new compiler and a new runtime, so there's no need for bootstrapping cm3, only normal package compilation. Realclean is required though to remove old derived 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 hendrik at topoi.pooq.com Wed Apr 9 14:29:12 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 9 Apr 2008 08:29:12 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080409090549.cdpk2tjocgg0wcg8@mail.elegosoft.com> References: <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> <20080408171734.GA31674@topoi.pooq.com> <20080408231541.GA31929@topoi.pooq.com> <20080408233338.GA32037@topoi.pooq.com> <20080409000207.GA32073@topoi.pooq.com> <20080409011418.GC32073@topoi.pooq.com> <20080409090549.cdpk2tjocgg0wcg8@mail.elegosoft.com> Message-ID: <20080409122912.GA1060@topoi.pooq.com> On Wed, Apr 09, 2008 at 09:05:49AM +0200, Olaf Wagner wrote: > Quoting hendrik at topoi.pooq.com: > > >On Wed, Apr 09, 2008 at 01:00:20AM +0000, Jay wrote: > >>Right. > >>This is a normal symptom of using an "old" compiler to compile > >>current source. > >>You must first build a new compiler against an old runtime (which > >>you must get from "somewhere", such as an existing older install), > >>then use that to build a new runtime. > >> > >> scripts/upgrade.sh > >> scripts/python/upgrade.py > >> scripts/win/upgrade.cmd > >> > >>should all handle the "dance" for you. > >> > >> - Jay > > > >Except I don't *have* a working old runtime. I've mentioned my > >experiences with > >../cm3-min-POSIX-LINUXLIBC6-d5.7.0-2008-04-08-14-00-05.tgz > >in another post. I acquired it in the hope that it wouldn't be an old > >runtime. > > Three short notes: > > o cminstall didn't find the non-existent libraries, it just checked > the existence of a directory: > > checking for library files in directory /usr/local/lib... not found > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > checking for directory /usr/lib... found > ^^^^^^^^^^^^^ That explains the messages. Thanks. > > o Your compiler didn't have LONGINT support, so you need to use > upgrade.sh. This should be documented (I think it is), as the > introduction of LONGINT was an incompatible change wrt. > bootstrapping. I was doing a new install. The first installation (the stable release obtained from the .tgz archives) crashed. I was advised to use the latest version from cvs, which failed because of the LONGINT problem and the fact I was still using the old cminstall file for bootstrapping. Finally I found a new place to get a new cminstall, and that one finally worked. > > o cm3-min-POSIX-LINUXLIBC6-d5.7.0-2008-04-08-14-00-05.tgz > should contain a new compiler and a new runtime, so there's > no need for bootstrapping cm3, only normal package compilation. And this should be documented somewhere on the installation and download pages, which is what a beginner sees. A beginner, who wasn't already sold on the virtues of Modula 3, would have given up long before I did. > Realclean is required though to remove old derived files. That's something I hadn't heard of. It looks useful. Where is it documented? -- hendrik From wagner at elegosoft.com Wed Apr 9 14:54:08 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 09 Apr 2008 14:54:08 +0200 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080409122912.GA1060@topoi.pooq.com> References: <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> <20080408171734.GA31674@topoi.pooq.com> <20080408231541.GA31929@topoi.pooq.com> <20080408233338.GA32037@topoi.pooq.com> <20080409000207.GA32073@topoi.pooq.com> <20080409011418.GC32073@topoi.pooq.com> <20080409090549.cdpk2tjocgg0wcg8@mail.elegosoft.com> <20080409122912.GA1060@topoi.pooq.com> Message-ID: <20080409145408.ekn7fszvrk8084ko@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > On Wed, Apr 09, 2008 at 09:05:49AM +0200, Olaf Wagner wrote: >> Three short notes: >> o cminstall didn't find the non-existent libraries, it just checked >> the existence of a directory: >> >> checking for library files in directory /usr/local/lib... not found >> ^^^^^^^^^^^^^^^^^^^^^^^^^^ >> checking for directory /usr/lib... found >> ^^^^^^^^^^^^^ > That explains the messages. Thanks. >> >> o Your compiler didn't have LONGINT support, so you need to use >> upgrade.sh. This should be documented (I think it is), as the >> introduction of LONGINT was an incompatible change wrt. >> bootstrapping. > > I was doing a new install. The first installation (the stable > release obtained from the .tgz archives) crashed. I was advised to use > the latest version from cvs, which failed because of the LONGINT > problem and the fact I was still using the old cminstall file for > bootstrapping. Finally I found a new place to get a new cminstall, and > that one finally worked. > >> o cm3-min-POSIX-LINUXLIBC6-d5.7.0-2008-04-08-14-00-05.tgz >> should contain a new compiler and a new runtime, so there's >> no need for bootstrapping cm3, only normal package compilation. > > And this should be documented somewhere on the installation and download > pages, which is what a beginner sees. A beginner, who wasn't already > sold on the virtues of Modula 3, would have given up long before I did. > >> Realclean is required though to remove old derived files. > > That's something I hadn't heard of. It looks useful. Where is it > documented? Hi, I agree that the documentation is probably neither consistent nor complete not completely up-to-date :-/ I'm working on it when I've got some spare time, but currently I'm really busy and can spare none. Would you mind providing some patches to cm3/www that address at least the problems you encountered? That would be very helpful. I'll ship them to our WWW server on the request of any m3devel member. Thanks in advance for any doc contributions (from you or others), Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From mika at async.caltech.edu Thu Apr 10 12:41:12 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 10 Apr 2008 03:41:12 -0700 Subject: [M3devel] set relationships? In-Reply-To: Your message of "Mon, 07 Apr 2008 00:52:10 -0000." Message-ID: <200804101041.m3AAfCKQ099273@camembert.async.caltech.edu> I think the point is, <= for sets, in the form you describe, defines a partial order. There are libraries full of math books describing what you can and can't do with partial orders. And yes all your examples should be all false. Mika Jay writes: >--_dbaf03aa-e4eb-4ef2-8579-90576f2305db_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >oops -- I mean they are all false. > > >From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Mon, 7 Apr 2008 00:= >38:01 +0000Subject: [M3devel] set relationships? > > >I'm looking at test p1\p155.I haven't started debugging it, just trying to = >understand it. C:\dev2\cm3\doc\reference\relations.html:" infix <=3D= >, >=3D ... (x,y: Set) : BOOLEAN ... <=3D returns TRUE if every element= > of x is an element of y....The expression x >=3D y is equivalent to y <=3D= > x. ...In all cases, x < y means (x <=3D y) AND (x # y), and x > y means y = >< x" Let's just use the sets {1} and {2}. {1} <=3D {2} {2} <=3D {1} {= >1} < {2} {2} < {1} {1} >=3D {2} {2} >=3D {1} {1} > {2} {2} > {1} = > All these expressions are true from the definitions above.Is that reasonab= >le?It seems a little strange to me. I guess I am very used to strongly orde= >red things, such that a <=3D b && a =3D> b implies a =3D=3D b, not true her= >e, and you can't have both a < b and b < a, which you have here, and that (= >a < b) =3D=3D !(a >=3D b) and similar, which is not true here. In this case= >, every relation but equality is true. - Jay= > >--_dbaf03aa-e4eb-4ef2-8579-90576f2305db_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > >oops -- I mean they are all false.


>
>
>From: jayk123 at hotmail.com
To: m3devel at elegosoft.com
Date: Mon, 7 Apr = >2008 00:38:01 +0000
Subject: [M3devel] set relationships?

> > >I'm looking at test p1\p155.
I haven't started debugging it, just trying= > to understand it.
 
C:\dev2\cm3\doc\reference\relations.html:R>"
     infix&nbs= >p;   <=3D, >=3D  ... 
(x,y: Set) &nbs= >p;   : BOOLEAN

 
... <=3D returns= > TRUE if every element of x is an element of y.<= >BR>...
The expression x >=3D y is equivalent to y <= >=3D x.
...
In all cases, x < y means (x <=3D= > y) AND (x # y), and x > y means y < x
= >"
 
Let's just use the sets {1} and {2}.
 
 = >; {1} <=3D {2}
  {2} <=3D {1}
  {1} < {2}
&n= >bsp; {2} < {1}
  {1} >=3D {2}
  {2} >= >=3D {1}
  {1} > {2}
  {2} > {1}
 = >;
All these expressions are true from the definitions above.
Is that = >reasonable?
It seems a little strange to me.
 
I guess I am v= >ery used to strongly ordered things, such that a <=3D b && a =3D= >> b implies a =3D=3D b, not true here, and you can't have both= > a < b and b < a, which you have here, and that (a < b) =3D=3D !(a= > >=3D b) and similar, which is not true here. In this case, every relati= >on but equality is true.
 
 - Jay

y> >= > >--_dbaf03aa-e4eb-4ef2-8579-90576f2305db_-- From hosking at cs.purdue.edu Thu Apr 10 14:29:38 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 10 Apr 2008 08:29:38 -0400 Subject: [M3devel] Fwd: Output from "cron" command References: <200804101030.m3AAU76w002296@niagara.cs.purdue.edu> Message-ID: <81A65E59-E09B-49C4-A7DE-DD139A219A2D@cs.purdue.edu> Regressions are broken... Begin forwarded message: > From: Tony Hosking > Date: April 10, 2008 6:30:07 AM GMT-04:00 > To: hosking at cs.purdue.edu > Subject: Output from "cron" command > > Your "cron" job on niagara.cs.purdue.edu > $HOME/cm3/scripts/regression/cron.sh > > produced the following output: > > ./tinderbox-build.sh: syntax error at line 270: `R=$' unexpected > ./tinderbox-build.sh: syntax error at line 270: `R=$' unexpected -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Apr 10 14:41:10 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 10 Apr 2008 12:41:10 +0000 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: <81A65E59-E09B-49C4-A7DE-DD139A219A2D@cs.purdue.edu> References: <200804101030.m3AAU76w002296@niagara.cs.purdue.edu> <81A65E59-E09B-49C4-A7DE-DD139A219A2D@cs.purdue.edu> Message-ID: This was surely my attempt at "fixing" them to honor my $CVSROOT. It worked for me on Cygwin..my checkin comment was "good" -- it said I don't know if it was bash or Cygwin specific. C:\dev2\cm3.2\scripts\regression\cm3.build# checkout the current cm3 regression script and source it(echo $CVSROOT | grep @m3.elegosoft.com:/usr/cvs > /dev/null) || CVSROOT=":ext:modula3.elegosoft.com:/usr/cvs" cvs -d $CVSROOT checkout -A \ -d ${REGRESSION_SCRIPTS_DIR} cm3/scripts/regression/defs.sh Can you quickly/easily massage that into something more portable? Otherwise I'll just put back. I have hardly gotten anywhere trying to run the Tinderbox stuff, but can run various tests manually.. Looks like I'm getting a cheap Sun machine from eBay..might be a bit interesting... - Jay From: hosking at cs.purdue.eduTo: m3devel at elegosoft.comDate: Thu, 10 Apr 2008 08:29:38 -0400Subject: [M3devel] Fwd: Output from "cron" command Regressions are broken... Begin forwarded message: From: Tony Hosking Date: April 10, 2008 6:30:07 AM GMT-04:00 To: hosking at cs.purdue.edu Subject: Output from "cron" command Your "cron" job on niagara.cs.purdue.edu$HOME/cm3/scripts/regression/cron.shproduced the following output:./tinderbox-build.sh: syntax error at line 270: `R=$' unexpected./tinderbox-build.sh: syntax error at line 270: `R=$' unexpected -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Apr 10 14:46:10 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 10 Apr 2008 12:46:10 +0000 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: References: <200804101030.m3AAU76w002296@niagara.cs.purdue.edu> <81A65E59-E09B-49C4-A7DE-DD139A219A2D@cs.purdue.edu> Message-ID: > I have hardly gotten anywhere trying to run the Tinderbox stuff, but can run various tests manually.. The first problem is finding distributions to download. Maybe it can fallback to that less tested directory where I have put stuff (which reminds me, I should delete what is there and put up newer...) - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; m3devel at elegosoft.comDate: Thu, 10 Apr 2008 12:41:10 +0000Subject: Re: [M3devel] Fwd: Output from "cron" command This was surely my attempt at "fixing" them to honor my $CVSROOT.It worked for me on Cygwin..my checkin comment was "good" -- it said I don't know if it was bash or Cygwin specific. C:\dev2\cm3.2\scripts\regression\cm3.build# checkout the current cm3 regression script and source it(echo $CVSROOT | grep @m3.elegosoft.com:/usr/cvs > /dev/null) || CVSROOT=":ext:modula3.elegosoft.com:/usr/cvs"cvs -d $CVSROOT checkout -A \ -d ${REGRESSION_SCRIPTS_DIR} cm3/scripts/regression/defs.shCan you quickly/easily massage that into something more portable?Otherwise I'll just put back. I have hardly gotten anywhere trying to run the Tinderbox stuff, but can run various tests manually.. Looks like I'm getting a cheap Sun machine from eBay..might be a bit interesting... - Jay From: hosking at cs.purdue.eduTo: m3devel at elegosoft.comDate: Thu, 10 Apr 2008 08:29:38 -0400Subject: [M3devel] Fwd: Output from "cron" command Regressions are broken... Begin forwarded message: From: Tony Hosking Date: April 10, 2008 6:30:07 AM GMT-04:00 To: hosking at cs.purdue.edu Subject: Output from "cron" command Your "cron" job on niagara.cs.purdue.edu$HOME/cm3/scripts/regression/cron.shproduced the following output:./tinderbox-build.sh: syntax error at line 270: `R=$' unexpected./tinderbox-build.sh: syntax error at line 270: `R=$' unexpected -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu Apr 10 15:19:07 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 10 Apr 2008 09:19:07 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080409145408.ekn7fszvrk8084ko@mail.elegosoft.com> References: <20080408171734.GA31674@topoi.pooq.com> <20080408231541.GA31929@topoi.pooq.com> <20080408233338.GA32037@topoi.pooq.com> <20080409000207.GA32073@topoi.pooq.com> <20080409011418.GC32073@topoi.pooq.com> <20080409090549.cdpk2tjocgg0wcg8@mail.elegosoft.com> <20080409122912.GA1060@topoi.pooq.com> <20080409145408.ekn7fszvrk8084ko@mail.elegosoft.com> Message-ID: <20080410131907.GA2401@topoi.pooq.com> Looking at your message, and trying to imagine the documentation changes, it suddenly doesn't seem so easy. For one thing, I'm not familiar enough with the various systems to know what to say. On Wed, Apr 09, 2008 at 02:54:08PM +0200, Olaf Wagner wrote: > Quoting hendrik at topoi.pooq.com: > > >On Wed, Apr 09, 2008 at 09:05:49AM +0200, Olaf Wagner wrote: > >>Three short notes: > >> o cminstall didn't find the non-existent libraries, it just checked > >> the existence of a directory: > >> > >> checking for library files in directory /usr/local/lib... not found > >> ^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> checking for directory /usr/lib... found > >> ^^^^^^^^^^^^^ > > >That explains the messages. Thanks. > >> > >> o Your compiler didn't have LONGINT support, so you need to use > >> upgrade.sh. This should be documented (I think it is), as the > >> introduction of LONGINT was an incompatible change wrt. > >> bootstrapping. ********** > > > >I was doing a new install. The first installation (the stable > >release obtained from the .tgz archives) crashed. This crash isn't a matter of a documentation change. If the stable release crashes during installation, it probably need to be replaced with one that doesn't crash. Or is that just a problem on Ubuntu, Debian and related distributions? The http://modula3.elegosoft.com/cm3/ page says only: : If you would like to : : * install on Ubuntu, Debian or a related distribution, or : * install a recent snapshot of CM3, : you will want to read these more specific installation instructions. : Alternatively, continue reading the general instructions below. Which, I suppose wasn't worded strongly enough to warn me off the "more general" method. Perhaps it should say, : you will need to use these different installation instructions,. : Otherwise, continue reading the general instructions below. ********** On the page of "CM3 5.5.1 Installation on Ubuntu 7.10 and Similar GNU/Linux Distributions" there's a list of software you should already have installed. It should include cvs. ********** > I was advised to use > >the latest version from cvs, which failed because of the LONGINT > >problem and the fact I was still using the old cminstall file for > >bootstrapping. I gather that normally there isn't a bootstrapping problem from one compiler to the next. The CVS instructions should mention that you have to start with a new cm3-min- file, and not proceed from the old compiler, or and old cm3-min-. And, in fact, they do. So this was my fault for not noticing it. A friend of mine once said that his mother was a superhero, and that her superpower was the ability to follow instructions correctly. I'm starting to realize how true that is. *********** When it says, : the newest available stable tarballs (version 5.4.0) are too old. it should perhaps say that they do not work, as : the newest available stable tarballs (version 5.4.0) are too old and : do not work. By the way, what was too old about them -- are they no longer compatible with current versions of Ubuntu, Debian, or other related distributions? *********** > > > >> o cm3-min-POSIX-LINUXLIBC6-d5.7.0-2008-04-08-14-00-05.tgz > >> should contain a new compiler and a new runtime, so there's > >> no need for bootstrapping cm3, only normal package compilation. Do you mean that there was no reason to run the commands ./do-cm3-core.sh buildship ./install-cm3-compiler.sh upgrade ? ********** > >> Realclean is required though to remove old derived files. > > > >That's something I hadn't heard of. It looks useful. Where is it > >documented? And I have no idea how to document Realclean, or even how to use it. I've found the cm3 option cm3 -clean . Is realclean something like this, as cm3 -realclean ? And if so, what is the difference? > > Hi, > > I agree that the documentation is probably neither consistent nor > complete not completely up-to-date :-/ > > I'm working on it when I've got some spare time, but currently > I'm really busy and can spare none. Would you mind providing some > patches to cm3/www that address at least the problems you encountered? > That would be very helpful. I'd be happy to try. -- hendrik > > I'll ship them to our WWW server on the request of any m3devel > member. > > Thanks in advance for any doc contributions (from you or others), > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 10 17:14:44 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 10 Apr 2008 17:14:44 +0200 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080410131907.GA2401@topoi.pooq.com> References: <20080408171734.GA31674@topoi.pooq.com> <20080408231541.GA31929@topoi.pooq.com> <20080408233338.GA32037@topoi.pooq.com> <20080409000207.GA32073@topoi.pooq.com> <20080409011418.GC32073@topoi.pooq.com> <20080409090549.cdpk2tjocgg0wcg8@mail.elegosoft.com> <20080409122912.GA1060@topoi.pooq.com> <20080409145408.ekn7fszvrk8084ko@mail.elegosoft.com> <20080410131907.GA2401@topoi.pooq.com> Message-ID: <20080410171444.n9kt2aim68oss00w@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > Looking at your message, and trying to imagine the documentation > changes, it suddenly doesn't seem so easy. For one thing, I'm not > familiar enough with the various systems to know what to say. In Germany we've got a saying `the devil lurks in the details'; don't know if that is known to English speaking people, too :-) > On Wed, Apr 09, 2008 at 02:54:08PM +0200, Olaf Wagner wrote: >> Quoting hendrik at topoi.pooq.com: >> >> >On Wed, Apr 09, 2008 at 09:05:49AM +0200, Olaf Wagner wrote: >> >I was doing a new install. The first installation (the stable >> >release obtained from the .tgz archives) crashed. > > This crash isn't a matter of a documentation change. If the stable > release crashes during installation, it probably need to be replaced > with one that doesn't crash. Or is that just a problem on Ubuntu, > Debian and related distributions? > > The http://modula3.elegosoft.com/cm3/ page says only: > > : If you would like to > : > : * install on Ubuntu, Debian or a related distribution, or > : * install a recent snapshot of CM3, > > : you will want to read these more specific installation instructions. > > : Alternatively, continue reading the general instructions below. > > Which, I suppose wasn't worded strongly enough to warn me off the "more > general" method. > > Perhaps it should say, > > : you will need to use these different installation instructions,. > > : Otherwise, continue reading the general instructions below. Sounds good. > ********** > > On the page of "CM3 5.5.1 Installation on Ubuntu 7.10 and Similar > GNU/Linux Distributions" > > there's a list of software you should already have installed. It should > include cvs. OK. But you can get the daily source snapshots without CVS, too. > ********** > >> I was advised to use >> >the latest version from cvs, which failed because of the LONGINT >> >problem and the fact I was still using the old cminstall file for >> >bootstrapping. > > I gather that normally there isn't a bootstrapping problem from one > compiler to the next. The CVS instructions should mention that > you have to start with a new cm3-min- file, and not proceed from the old > compiler, or and old cm3-min-. And, in fact, they do. So this was my > fault for not noticing it. > > A friend of mine once said that his mother was a superhero, and that her > superpower was the ability to follow instructions correctly. I'm > starting to realize how true that is. :-) > *********** > > When it says, > > : the newest available stable tarballs (version 5.4.0) are too old. > > it should perhaps say that they do not work, as > > : the newest available stable tarballs (version 5.4.0) are too old and > : do not work. OK. > By the way, what was too old about them -- are they no longer compatible > with current versions of Ubuntu, Debian, or other related > distributions? IIRC, the problem is that these systems encrypt their jmp_bufs which are used for user threads in M3. I don't know if this can be turned off globally. I'm also not sure if there wasn't something else. Perhaps somebody else remembers? > *********** > >> >> o cm3-min-POSIX-LINUXLIBC6-d5.7.0-2008-04-08-14-00-05.tgz >> >> should contain a new compiler and a new runtime, so there's >> >> no need for bootstrapping cm3, only normal package compilation. > > Do you mean that there was no reason to run the commands > > ./do-cm3-core.sh buildship > > ./install-cm3-compiler.sh upgrade > > ? Yes. If the compiler works, it's up-to-date, as is m3core and libm3. Everything that is not contained can then be compiled. > ********** > >> >> Realclean is required though to remove old derived files. >> > >> >That's something I hadn't heard of. It looks useful. Where is it >> >documented? > > And I have no idea how to document Realclean, or even how to use it. > I've found the cm3 option > > cm3 -clean > > . Is realclean something like this, as > > cm3 -realclean > > ? And if so, what is the difference? No, there's no cm3 -realclean. It's only a command for the scripts, as in scripts/do-cm3-all.sh realclean which performs rm -rf $TARGET in every package. >> Hi, >> >> I agree that the documentation is probably neither consistent nor >> complete not completely up-to-date :-/ >> >> I'm working on it when I've got some spare time, but currently >> I'm really busy and can spare none. Would you mind providing some >> patches to cm3/www that address at least the problems you encountered? >> That would be very helpful. > > I'd be happy to try. Great. I hope the remarks above will help. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 10 18:56:13 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 10 Apr 2008 12:56:13 -0400 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: References: <200804101030.m3AAU76w002296@niagara.cs.purdue.edu> <81A65E59-E09B-49C4-A7DE-DD139A219A2D@cs.purdue.edu> Message-ID: <2B8FF29D-E004-4F74-A60C-F215814BAFDC@cs.purdue.edu> I don't even use $CVSROOT generally, so it probably should not be assumed. I don't have the time to fix this right now. On Apr 10, 2008, at 8:41 AM, Jay wrote: > This was surely my attempt at "fixing" them to honor my $CVSROOT. > It worked for me on Cygwin..my checkin comment was "good" -- it said > I don't know if it was bash or Cygwin specific. > > C:\dev2\cm3.2\scripts\regression\cm3.build > > # checkout the current cm3 regression script and source it > (echo $CVSROOT | grep @m3.elegosoft.com:/usr/cvs > /dev/null) || > CVSROOT=":ext:modula3.elegosoft.com:/usr/cvs" > > > cvs -d $CVSROOT checkout -A \ > -d ${REGRESSION_SCRIPTS_DIR} cm3/scripts/regression/defs.sh > > > Can you quickly/easily massage that into something more portable? > Otherwise I'll just put back. I have hardly gotten anywhere trying > to run the Tinderbox stuff, but can run various tests manually.. > > Looks like I'm getting a cheap Sun machine from eBay..might be a bit > interesting... > > - Jay > > From: hosking at cs.purdue.edu > To: m3devel at elegosoft.com > Date: Thu, 10 Apr 2008 08:29:38 -0400 > Subject: [M3devel] Fwd: Output from "cron" command > > Regressions are broken... > > Begin forwarded message: > From: Tony Hosking > Date: April 10, 2008 6:30:07 AM GMT-04:00 > To: hosking at cs.purdue.edu > Subject: Output from "cron" command > > Your "cron" job on niagara.cs.purdue.edu > $HOME/cm3/scripts/regression/cron.sh > > produced the following output: > > ./tinderbox-build.sh: syntax error at line 270: `R=$' unexpected > ./tinderbox-build.sh: syntax error at line 270: `R=$' unexpected > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Thu Apr 10 21:46:29 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 10 Apr 2008 14:46:29 -0500 Subject: [M3devel] Need CVS help fixing log message Message-ID: <47FE6E95.4070405@wichita.edu> I committed a bunch of files and mistakenly used -m when I should have used -F. The result is, the log message is a local path to a file. My CVS book shows a -m option to cvs admin to repair log messages, but nothing that does what the -F option to commit does. My log message has several lines. How can I fix the logs? Is there an equivalent to admin -F? Will the -m accept newlines between the quotes? -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From wagner at elegosoft.com Thu Apr 10 22:45:24 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 10 Apr 2008 22:45:24 +0200 Subject: [M3devel] Need CVS help fixing log message In-Reply-To: <47FE6E95.4070405@wichita.edu> References: <47FE6E95.4070405@wichita.edu> Message-ID: <20080410224524.tnubedsin4cck4ks@mail.elegosoft.com> Quoting "Rodney M. Bates" : > I committed a bunch of files and mistakenly used -m when I should > have used -F. The result is, the log message is a local path to > a file. My CVS book shows a -m option to cvs admin to repair log > messages, but nothing that does what the -F option to commit does. > My log message has several lines. How can I fix the logs? Is there > an equivalent to admin -F? Will the -m accept newlines between the > quotes? Use something like cvs admin -m1.24:'line 1 line 2 line 3' fn Note that it is based on the RCS revision; so you've got to do it for each file with the correct revision number. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Sat Apr 12 22:54:16 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 12 Apr 2008 16:54:16 -0400 Subject: [M3devel] AMD64_DARWIN Message-ID: <9CC27F14-E89D-49D8-AA69-2CC173B61CFA@cs.purdue.edu> I have successfully bootstrapped a AMD64_DARWIN (64-bit x86_64 Mac OS X) target. In order to do this I needed to upgrade the gcc-based compiler backend to a newer version. Does anyone have any objection to my checking in a newer version of m3cc, as I check in my support for AMD64_DARWIN? From rodney.bates at wichita.edu Sun Apr 13 01:02:50 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Sat, 12 Apr 2008 18:02:50 -0500 Subject: [M3devel] AMD64_DARWIN In-Reply-To: <9CC27F14-E89D-49D8-AA69-2CC173B61CFA@cs.purdue.edu> References: <9CC27F14-E89D-49D8-AA69-2CC173B61CFA@cs.purdue.edu> Message-ID: <48013F9A.6090500@wichita.edu> Short answer: No. But maybe put the old one on a branch, for thoroughness? In the past, I have made a few changes to it to support m3gdb. They might revert as a result. But I made a copy of the current m3cc, and I can't think of anything else that might be needed for that purpose, before a new version checkin. Tony Hosking wrote: > I have successfully bootstrapped a AMD64_DARWIN (64-bit x86_64 Mac OS > X) target. In order to do this I needed to upgrade the gcc-based > compiler backend to a newer version. Does anyone have any objection > to my checking in a newer version of m3cc, as I check in my support for > AMD64_DARWIN? > > -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From jayk123 at hotmail.com Sun Apr 13 00:58:14 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 12 Apr 2008 22:58:14 +0000 Subject: [M3devel] AMD64_DARWIN In-Reply-To: <48013F9A.6090500@wichita.edu> References: <9CC27F14-E89D-49D8-AA69-2CC173B61CFA@cs.purdue.edu> <48013F9A.6090500@wichita.edu> Message-ID: Rodney, I bet he is doing that already as a matter of course. And I bet he will merge your changes, and any others. I have no objection but I'm sure that was obvious. :) - Jay > Date: Sat, 12 Apr 2008 18:02:50 -0500> From: rodney.bates at wichita.edu> To: hosking at cs.purdue.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] AMD64_DARWIN> > Short answer: No. But maybe put the old one on a branch, for> thoroughness?> > In the past, I have made a few changes to it to support m3gdb. They> might revert as a result. But I made a copy of the current m3cc,> and I can't think of anything else that might be needed for that> purpose, before a new version checkin.> > Tony Hosking wrote:> > I have successfully bootstrapped a AMD64_DARWIN (64-bit x86_64 Mac OS > > X) target. In order to do this I needed to upgrade the gcc-based > > compiler backend to a newer version. Does anyone have any objection > > to my checking in a newer version of m3cc, as I check in my support for > > AMD64_DARWIN?> > > > > > -- > -------------------------------------------------------------> Rodney M. Bates, retired assistant professor> Dept. of Computer Science, Wichita State University> Wichita, KS 67260-0083> 316-978-3922> rodney.bates at wichita.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Apr 13 01:40:28 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 12 Apr 2008 19:40:28 -0400 Subject: [M3devel] AMD64_DARWIN In-Reply-To: References: <9CC27F14-E89D-49D8-AA69-2CC173B61CFA@cs.purdue.edu> <48013F9A.6090500@wichita.edu> Message-ID: <0DE77BAB-EE98-44FA-8E56-385085E8B1EA@cs.purdue.edu> I've propagated all the prior diffs. In fact, I'll do this as a cvs import and merge so we shouldn't lose anything. There are some bugfixes for 64-bit as well, but nothing major. On Apr 12, 2008, at 6:58 PM, Jay wrote: > Rodney, I bet he is doing that already as a matter of course. And I > bet he will merge your changes, and any others. > I have no objection but I'm sure that was obvious. :) > > - Jay > > > > > Date: Sat, 12 Apr 2008 18:02:50 -0500 > > From: rodney.bates at wichita.edu > > To: hosking at cs.purdue.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] AMD64_DARWIN > > > > Short answer: No. But maybe put the old one on a branch, for > > thoroughness? > > > > In the past, I have made a few changes to it to support m3gdb. They > > might revert as a result. But I made a copy of the current m3cc, > > and I can't think of anything else that might be needed for that > > purpose, before a new version checkin. > > > > Tony Hosking wrote: > > > I have successfully bootstrapped a AMD64_DARWIN (64-bit x86_64 > Mac OS > > > X) target. In order to do this I needed to upgrade the gcc-based > > > compiler backend to a newer version. Does anyone have any > objection > > > to my checking in a newer version of m3cc, as I check in my > support for > > > AMD64_DARWIN? > > > > > > > > > > -- > > ------------------------------------------------------------- > > Rodney M. Bates, retired assistant professor > > Dept. of Computer Science, Wichita State University > > Wichita, KS 67260-0083 > > 316-978-3922 > > rodney.bates at wichita.edu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sun Apr 13 06:03:40 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 13 Apr 2008 00:03:40 -0400 Subject: [M3devel] AMD64_DARWIN In-Reply-To: <9CC27F14-E89D-49D8-AA69-2CC173B61CFA@cs.purdue.edu> References: <9CC27F14-E89D-49D8-AA69-2CC173B61CFA@cs.purdue.edu> Message-ID: <20080413040340.GC9473@topoi.pooq.com> On Sat, Apr 12, 2008 at 04:54:16PM -0400, Tony Hosking wrote: > I have successfully bootstrapped a AMD64_DARWIN (64-bit x86_64 Mac OS > X) target. In order to do this I needed to upgrade the gcc-based > compiler backend to a newer version. Does anyone have any objection > to my checking in a newer version of m3cc, as I check in my support > for AMD64_DARWIN? > While we're on a related subjext -- is m3 available on an AMD64 Linux box yet (in 64-bit mode)? From hosking at cs.purdue.edu Sun Apr 13 06:15:56 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 13 Apr 2008 00:15:56 -0400 Subject: [M3devel] AMD64_DARWIN In-Reply-To: <20080413040340.GC9473@topoi.pooq.com> References: <9CC27F14-E89D-49D8-AA69-2CC173B61CFA@cs.purdue.edu> <20080413040340.GC9473@topoi.pooq.com> Message-ID: <5C33687C-D899-429C-86A0-F55C2676051B@cs.purdue.edu> Not that I know, but porting to AMD64_DARWIN should give us most of what is needed for AMD64_LINUX. Stay tuned. On Apr 13, 2008, at 12:03 AM, hendrik at topoi.pooq.com wrote: > On Sat, Apr 12, 2008 at 04:54:16PM -0400, Tony Hosking wrote: >> I have successfully bootstrapped a AMD64_DARWIN (64-bit x86_64 Mac OS >> X) target. In order to do this I needed to upgrade the gcc-based >> compiler backend to a newer version. Does anyone have any objection >> to my checking in a newer version of m3cc, as I check in my support >> for AMD64_DARWIN? >> > > While we're on a related subjext -- is m3 available on an AMD64 Linux > box yet (in 64-bit mode)? From wagner at elegosoft.com Mon Apr 14 08:48:55 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 14 Apr 2008 08:48:55 +0200 Subject: [M3devel] cm3 regression Message-ID: <20080414084855.tebzp7f2cksss004@mail.elegosoft.com> Building of libm3 now fails even in release-builds with 4539 new source -> compiling SocketPosix.m3 4540 4541 NEXT Fatal Error: bad version stamps: SocketPosix.m3 4542 4543 version stamp mismatch: Compiler.Platform 4544 => SocketPosix.m3 4545 => Compiler.i3 4546 version stamp mismatch: Compiler.ThisPlatform 4547 <92d2f58d2092154f> => SocketPosix.m3 4548 => Compiler.i3 4549 NEXT *** execution of cm3 -build -DROOT=?/home/m3/work/cm3-ws/birch.elegosoft.com-2008-04-14-00-00-03/cm3? -DCM3_VERSION_TEXT=?d5.7.0? -DCM3_VERSION_NUMBER=?050700? -DCM3_LAST_CHANGED=?2008-03-16? && cm3 -ship -DROOT=?/home/m3/work/cm3-ws/birch.elegosoft.com-2008-04-14-00-00-03/cm3? -DCM3_VERSION_TEXT=?d5.7.0? -DCM3_VERSION_NUMBER=?050700? -DCM3_LAST_CHANGED=?2008-03-16? failed *** 4550 compile return value: 0 4551 [end compile 2008.04.14 02:54:34] 4552 *** COMPILE FAILED Does anybody understand what's going on? During upgrade(), libm3 should only be built _after_ the new compiler has been installed, at least that is the intention. I'm in a hurry, so if anybody else cares to fix this, it would be great. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 14 08:52:52 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 14 Apr 2008 08:52:52 +0200 Subject: [M3devel] cm3 regression In-Reply-To: <20080414084855.tebzp7f2cksss004@mail.elegosoft.com> References: <20080414084855.tebzp7f2cksss004@mail.elegosoft.com> Message-ID: <20080414085252.mzhkll84kk408gso@mail.elegosoft.com> Quoting Olaf Wagner : > Building of libm3 now fails even in release-builds with > > 4539 new source -> compiling SocketPosix.m3 > 4540 > 4541 NEXT Fatal Error: bad version stamps: SocketPosix.m3 > 4542 > 4543 version stamp mismatch: Compiler.Platform > 4544 => SocketPosix.m3 > 4545 => Compiler.i3 > 4546 version stamp mismatch: Compiler.ThisPlatform > 4547 <92d2f58d2092154f> => SocketPosix.m3 > 4548 => Compiler.i3 > 4549 NEXT *** execution of cm3 -build > -DROOT=?/home/m3/work/cm3-ws/birch.elegosoft.com-2008-04-14-00-00-03/cm3? > -DCM3_VERSION_TEXT=?d5.7.0? -DCM3_VERSION_NUMBER=?050700? > -DCM3_LAST_CHANGED=?2008-03-16? && cm3 -ship > -DROOT=?/home/m3/work/cm3-ws/birch.elegosoft.com-2008-04-14-00-00-03/cm3? > -DCM3_VERSION_TEXT=?d5.7.0? -DCM3_VERSION_NUMBER=?050700? > -DCM3_LAST_CHANGED=?2008-03-16? failed *** > 4550 compile return value: 0 > 4551 [end compile 2008.04.14 02:54:34] > 4552 *** COMPILE FAILED > > Does anybody understand what's going on? > During upgrade(), libm3 should only be built _after_ the new compiler > has been installed, at least that is the intention. > > I'm in a hurry, so if anybody else cares to fix this, it would be great. I sent that mail too fast. It seems that only I386_DARWIN fails in the release-build, but for other reasons. The last-ok builds can be expexted to fail after incompatible changes in the runtime. So this should cure itself during the next days. We should however note that we need a full compiler bootstrap again even from older d5.7.0 archives now to compile current sources. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Mon Apr 14 09:17:53 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 14 Apr 2008 07:17:53 +0000 Subject: [M3devel] cm3 regression In-Reply-To: <20080414085252.mzhkll84kk408gso@mail.elegosoft.com> References: <20080414084855.tebzp7f2cksss004@mail.elegosoft.com> <20080414085252.mzhkll84kk408gso@mail.elegosoft.com> Message-ID: new source -> compiling Cstdlib.i3"..\src\C\32BITS\BasicCtypes.i3", line 18: illegal based LONGINT literal, zero used"..\src\C\32BITS\BasicCtypes.i3", line 18: illegal based LONGINT literal, zero used long_long = [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL]; Why isn't this LONGINT? So that NT386 can limp along? And it'd be correct for the rest, eh? I'll try it and see.. The underlying system (the compiler) has (U)Int[8,16,32,64] They should just be used here imho.. Also, what should "long" be on 64bit? On Windows it is 32 bits always. On 32 bit systems it is 32 bits. I think the 64bits directory is going to be forked for AMD64_NT_*. The Windows decision imho has successfully been applied to more code and more users so therefore is better by practical success, even if the whole issue is problematic almost no matter what. Clearly the C and Modula-3 notions of integers are pretty poor.. - Jay > Date: Mon, 14 Apr 2008 08:52:52 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] cm3 regression> > Quoting Olaf Wagner :> > > Building of libm3 now fails even in release-builds with> >> > 4539 new source -> compiling SocketPosix.m3> > 4540> > 4541 NEXT Fatal Error: bad version stamps: SocketPosix.m3> > 4542> > 4543 version stamp mismatch: Compiler.Platform> > 4544 => SocketPosix.m3> > 4545 => Compiler.i3> > 4546 version stamp mismatch: Compiler.ThisPlatform> > 4547 <92d2f58d2092154f> => SocketPosix.m3> > 4548 => Compiler.i3> > 4549 NEXT *** execution of cm3 -build> > -DROOT=?/home/m3/work/cm3-ws/birch.elegosoft.com-2008-04-14-00-00-03/cm3?> > -DCM3_VERSION_TEXT=?d5.7.0? -DCM3_VERSION_NUMBER=?050700?> > -DCM3_LAST_CHANGED=?2008-03-16? && cm3 -ship> > -DROOT=?/home/m3/work/cm3-ws/birch.elegosoft.com-2008-04-14-00-00-03/cm3?> > -DCM3_VERSION_TEXT=?d5.7.0? -DCM3_VERSION_NUMBER=?050700?> > -DCM3_LAST_CHANGED=?2008-03-16? failed ***> > 4550 compile return value: 0> > 4551 [end compile 2008.04.14 02:54:34]> > 4552 *** COMPILE FAILED> >> > Does anybody understand what's going on?> > During upgrade(), libm3 should only be built _after_ the new compiler> > has been installed, at least that is the intention.> >> > I'm in a hurry, so if anybody else cares to fix this, it would be great.> > I sent that mail too fast. It seems that only I386_DARWIN fails in> the release-build, but for other reasons. The last-ok builds can> be expexted to fail after incompatible changes in the runtime.> So this should cure itself during the next days.> > We should however note that we need a full compiler bootstrap again> even from older d5.7.0 archives now to compile current sources.> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Apr 14 09:18:35 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 14 Apr 2008 09:18:35 +0200 Subject: [M3devel] latest failure on NT386 Message-ID: <20080414091835.gm0aycpxcwg4s0k4@mail.elegosoft.com> Just when I thought that I finally might be able to run a complete regression on NT386, the compilation breaks with this: new source -> compiling Cstdlib.i3 "..\src\C\32BITS\BasicCtypes.i3", line 18: illegal based LONGINT literal, zero used "..\src\C\32BITS\BasicCtypes.i3", line 18: illegal based LONGINT literal, zero used "..\src\C\Common\Cstdlib.i3", line 13: imported interface contains errors (Ctypes) 3 errors encountered new source -> compiling Csetjmp.i3 "..\src\C\NT386\Csetjmp.i3", line 13: imported interface contains errors (Ctypes) 1 error encountered Can anybody look into 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: DE16321419 From jayk123 at hotmail.com Mon Apr 14 09:32:51 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 14 Apr 2008 07:32:51 +0000 Subject: [M3devel] latest failure on NT386 In-Reply-To: <20080414091835.gm0aycpxcwg4s0k4@mail.elegosoft.com> References: <20080414091835.gm0aycpxcwg4s0k4@mail.elegosoft.com> Message-ID: Olaf, this will fix your problem. Tony should speak to it probably before it is commited -- like if it works on AMD64_DARWIN. Here is my reluctant proposal: cvs diff: Diffing 32BITSIndex: 32BITS/BasicCtypes.i3===================================================================RCS file: /usr/cvs/cm3/m3-libs/m3core/src/C/32BITS/BasicCtypes.i3,vretrieving revision 1.10diff -c -r1.10 BasicCtypes.i3*** 32BITS/BasicCtypes.i3 13 Apr 2008 19:41:49 -0000 1.10--- 32BITS/BasicCtypes.i3 14 Apr 2008 07:20:59 -0000****************** 13,21 **** (* the four signed integer types *) signed_char = [-16_7f-1 .. 16_7f]; short_int = [-16_7fff-1 .. 16_7fff];! int = [-16_7fffffff-1 .. 16_7fffffff];! long_int = [-16_7fffffff-1 .. 16_7fffffff];! long_long = [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL]; (* the four unsigned integer types *) unsigned_char = [16_0 .. 16_ff];--- 13,21 ---- (* the four signed integer types *) signed_char = [-16_7f-1 .. 16_7f]; short_int = [-16_7fff-1 .. 16_7fff];! int = INTEGER;! long_int = INTEGER;! long_long = LONGINT; (* the four unsigned integer types *) unsigned_char = [16_0 .. 16_ff];cvs diff: Diffing 64BITSIndex: 64BITS/BasicCtypes.i3===================================================================RCS file: /usr/cvs/cm3/m3-libs/m3core/src/C/64BITS/BasicCtypes.i3,vretrieving revision 1.8diff -c -r1.8 BasicCtypes.i3*** 64BITS/BasicCtypes.i3 13 Apr 2008 19:44:02 -0000 1.8--- 64BITS/BasicCtypes.i3 14 Apr 2008 07:20:59 -0000****************** 14,21 **** signed_char = [-16_7f-1 .. 16_7f]; short_int = [-16_7fff-1 .. 16_7fff]; int = [-16_7fffffff-1 .. 16_7fffffff];! long_int = [-16_7fffffffffffffff -1 .. 16_7fffffffffffffff ];! long_long = [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL]; (* the four unsigned integer types *) unsigned_char = [16_0 .. 16_ff];--- 14,21 ---- signed_char = [-16_7f-1 .. 16_7f]; short_int = [-16_7fff-1 .. 16_7fff]; int = [-16_7fffffff-1 .. 16_7fffffff];! long_int = INTEGER;! long_long = LONGINT; (* the four unsigned integer types *) unsigned_char = [16_0 .. 16_ff]; Win64 might not be able to use this but I guess the other 64 bit systems can. The bigger point is the 32bit fix to get NT386 compiling again. Type "long" is just dumb imho.By corrolary LONGINT. There should be the explicitly sized types [u]int[8,16,32,64,more in the future] and then unsigned and signed pointer sized types aka size_t, ptrdiff_t or size_t, ssize_t or Word.T, INTEGER I think it's unfortunate that Modula-3 followed C's lead here.This is one thing C definitely did wrong.You just know, 128 bit types are going to be called "long long long".. When they should have been called like int128 and uint128 and possibly size_t, ssize_t. Arguably "size_t" should be "word". "size_t" isn't the best name probably, but I'm not fighting that one. :) (I'm not really fighting any of this; I lost already.) - Jay > Date: Mon, 14 Apr 2008 09:18:35 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: [M3devel] latest failure on NT386> > Just when I thought that I finally might be able to run a complete> regression on NT386, the compilation breaks with this:> > new source -> compiling Cstdlib.i3> "..\src\C\32BITS\BasicCtypes.i3", line 18: illegal based LONGINT > literal, zero used> "..\src\C\32BITS\BasicCtypes.i3", line 18: illegal based LONGINT > literal, zero used> "..\src\C\Common\Cstdlib.i3", line 13: imported interface contains > errors (Ctypes)> 3 errors encountered> new source -> compiling Csetjmp.i3> "..\src\C\NT386\Csetjmp.i3", line 13: imported interface contains > errors (Ctypes)> 1 error encountered> > Can anybody look into 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: DE16321419> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Apr 14 10:00:34 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 14 Apr 2008 08:00:34 +0000 Subject: [M3devel] target naming? AMD64_NT, UWIN? In-Reply-To: <20080414091835.gm0aycpxcwg4s0k4@mail.elegosoft.com> References: <20080414091835.gm0aycpxcwg4s0k4@mail.elegosoft.com> Message-ID: the old target name game Lately I'm playing around at home with AMD64 Linux and Windows.Been using AMD64 Windows a while otherwise.I've also been playing around with UWin, which is something like Cygwin.Really nothing substantial yet.Anyone else with similar inclination, go ahead. UWin has an optional runtime, and not really a toolset.It has cc, ld, ar, but cc and ld are just wrappers forVisual C++ cl/link or other alternatives like Digital Mars,Borland, etc.ar is either a link -lib wrapper or doesn't do all that much in any case. They also have ncc -- native compiler, to produce Win32 executables.pcc for Posix executables, not sure of the point. Their runtime supports fork/vfork/exec/spawn, Posix file names, pthreads.They have sh that is ksh, vi.So far gcc does not build in this environment. I tried a bit.They are a much smaller system than Cygwin.Far fewer packages. They DO have X Windows. They say they will have 64 bit soon -- presumably AMD64. (IA64?) Cygwin is fairly x86 specific at this point.I haven't seen any movement on an AMD64 port, though it probably isn't that difficult. MinGWin is out there too already of course, and has a 64 bit port (shouldn't behard to just rebuild gcc, esp. with Tony's update). Therefore there are bunch more viable targets or configurations.It is hard to even describe them, other than via the earlier proposedand essentially implemented calculus: processor + runtime + C compiler + linker + modula-3 backend processor = x86, AMD64 runtime = msvc, uwin C compiler = msvc, gcc (borland, watcom, metrowerks, etc.) (now I see a reason to eliminate C -- so it doesn't figure into the target calculus! :) ) modula-3 backend = integrated, gcc NT386.Common implements something like this, though not always correctly, just enough for the three existing instantiations to work. UWin does not provide setjmp/longjmp, good.They have sigsetjmp/siglongjmp that only adds a /small/ amount, like 2 integers or 2 pointers.I have no qualm inflating always an AMD64 jmpbuf to accomodate, if needed.Inflating the NT386 one is still tempting to reduce variety. On one hand there is a quandary of too many target combinations to consider.But on the other hand is the solution that I implemented under the covers, the above calculus.Therefore, the compiler need only know about AMD64_NT, and the rest can be just "configurations". Besides, this same answer can be applied to any 32 bit UWin target. ??? Given the "configuration" idea, I would be ok with NTAMD64, or AMD64_NT, or AMD64_MSWIN, etc.I assume most folks will chose AMD64_NT. Some other names should probably be chosen, for the Quake files. AMD64_NT_WIN_UWIN -- "native runtime" AMD64_NT_POSIX_UWIN -- posix, X Windows AMD64_NT_MINGWIN -- native runtime AMD64_NT - reserved for future port of integrated backend? But in the compiler these could all be the same. or, shorter: AMD64_UWINN - UWin native AMD64_UWINP - UWin posix AMD64_UWINX - UWin posix ? "UWIN" implies "Windows" implies "NT", so good enough? or, processor, ostype, variant, and again UWin implies NT, ostype=win implies NT?: AMD64_POSIX_UWIN AMD64_WIN_UWIN (not very interesting, really) AMD64_WIN_GCC (MinGWin) AMD64_POSIX_CYG (future) same as AMD64_CYGWIN or NTAMD64GNU?? AMD64_WIN_NATIVE -- integrated backend, msvc cl/link (future) Usually "ostype" is not interesting in targets, since nearly everything is Posix.And "variant" is just a random escape hatch to try to come up with something. ??? I know I talk more about making new targets than actually doing it, sorry. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Apr 14 11:28:07 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 14 Apr 2008 09:28:07 +0000 Subject: [M3devel] target naming? AMD64_NT, UWIN? In-Reply-To: References: <20080414091835.gm0aycpxcwg4s0k4@mail.elegosoft.com> Message-ID: > processor + runtime + C compiler + linker + modula-3 backend correction: processor + kernel/"operating system" + C runtime + C compiler + linker + modula-3 backend + gui runtime Often only the first two vary, but not always. Most systems have "native" and GNU as I understand for C compiler and linker -- Solaris, AIX, HP-UX. And then Windows has multiple compilers, linkers, runtimes. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Apr 14 14:45:15 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Apr 2008 08:45:15 -0400 Subject: [M3devel] cm3 regression In-Reply-To: References: <20080414084855.tebzp7f2cksss004@mail.elegosoft.com> <20080414085252.mzhkll84kk408gso@mail.elegosoft.com> Message-ID: <4434FAA9-237F-4977-AAB8-DDE36FB2B503@cs.purdue.edu> Yes, sorry, probably best to make it LONGINT. I'll fix. 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 Apr 14, 2008, at 3:17 AM, Jay wrote: > new source -> compiling Cstdlib.i3 > "..\src\C\32BITS\BasicCtypes.i3", line 18: illegal based LONGINT > literal, zero used > "..\src\C\32BITS\BasicCtypes.i3", line 18: illegal based LONGINT > literal, zero used > > long_long = [-16_7fffffffffffffffL-1L .. > 16_7fffffffffffffffL]; > > > Why isn't this LONGINT? So that NT386 can limp along? And it'd be > correct for the rest, eh? > I'll try it and see.. > > The underlying system (the compiler) has (U)Int[8,16,32,64] > They should just be used here imho.. > > Also, what should "long" be on 64bit? > On Windows it is 32 bits always. > On 32 bit systems it is 32 bits. > I think the 64bits directory is going to be forked for AMD64_NT_*. > The Windows decision imho has successfully been applied to more code > and more users so therefore is better by practical success, even if > the whole issue is problematic almost no matter what. Clearly the C > and Modula-3 notions of integers are pretty poor.. > > - Jay > > > > > Date: Mon, 14 Apr 2008 08:52:52 +0200 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] cm3 regression > > > > Quoting Olaf Wagner : > > > > > Building of libm3 now fails even in release-builds with > > > > > > 4539 new source -> compiling SocketPosix.m3 > > > 4540 > > > 4541 NEXT Fatal Error: bad version stamps: SocketPosix.m3 > > > 4542 > > > 4543 version stamp mismatch: Compiler.Platform > > > 4544 => SocketPosix.m3 > > > 4545 => Compiler.i3 > > > 4546 version stamp mismatch: Compiler.ThisPlatform > > > 4547 <92d2f58d2092154f> => SocketPosix.m3 > > > 4548 => Compiler.i3 > > > 4549 NEXT *** execution of cm3 -build > > > -DROOT=?/home/m3/work/cm3-ws/ > birch.elegosoft.com-2008-04-14-00-00-03/cm3? > > > -DCM3_VERSION_TEXT=?d5.7.0? -DCM3_VERSION_NUMBER=?050700? > > > -DCM3_LAST_CHANGED=?2008-03-16? && cm3 -ship > > > -DROOT=?/home/m3/work/cm3-ws/ > birch.elegosoft.com-2008-04-14-00-00-03/cm3? > > > -DCM3_VERSION_TEXT=?d5.7.0? -DCM3_VERSION_NUMBER=?050700? > > > -DCM3_LAST_CHANGED=?2008-03-16? failed *** > > > 4550 compile return value: 0 > > > 4551 [end compile 2008.04.14 02:54:34] > > > 4552 *** COMPILE FAILED > > > > > > Does anybody understand what's going on? > > > During upgrade(), libm3 should only be built _after_ the new > compiler > > > has been installed, at least that is the intention. > > > > > > I'm in a hurry, so if anybody else cares to fix this, it would > be great. > > > > I sent that mail too fast. It seems that only I386_DARWIN fails in > > the release-build, but for other reasons. The last-ok builds can > > be expexted to fail after incompatible changes in the runtime. > > So this should cure itself during the next days. > > > > We should however note that we need a full compiler bootstrap again > > even from older d5.7.0 archives now to compile current sources. > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Apr 14 14:45:37 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Apr 2008 08:45:37 -0400 Subject: [M3devel] cm3 regression In-Reply-To: <20080414085252.mzhkll84kk408gso@mail.elegosoft.com> References: <20080414084855.tebzp7f2cksss004@mail.elegosoft.com> <20080414085252.mzhkll84kk408gso@mail.elegosoft.com> Message-ID: <8F8EDEDC-5AD4-4E0E-8C88-CF597D613049@cs.purdue.edu> Some regression to be expected while dust settles from AMD64_DARWIN changes. 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 Apr 14, 2008, at 2:52 AM, Olaf Wagner wrote: > Quoting Olaf Wagner : > >> Building of libm3 now fails even in release-builds with >> >> 4539 new source -> compiling SocketPosix.m3 >> 4540 >> 4541 NEXT Fatal Error: bad version stamps: SocketPosix.m3 >> 4542 >> 4543 version stamp mismatch: Compiler.Platform >> 4544 => SocketPosix.m3 >> 4545 => Compiler.i3 >> 4546 version stamp mismatch: Compiler.ThisPlatform >> 4547 <92d2f58d2092154f> => SocketPosix.m3 >> 4548 => Compiler.i3 >> 4549 NEXT *** execution of cm3 -build >> -DROOT=?/home/m3/work/cm3-ws/ >> birch.elegosoft.com-2008-04-14-00-00-03/cm3? >> -DCM3_VERSION_TEXT=?d5.7.0? -DCM3_VERSION_NUMBER=?050700? >> -DCM3_LAST_CHANGED=?2008-03-16? && cm3 -ship >> -DROOT=?/home/m3/work/cm3-ws/ >> birch.elegosoft.com-2008-04-14-00-00-03/cm3? >> -DCM3_VERSION_TEXT=?d5.7.0? -DCM3_VERSION_NUMBER=?050700? >> -DCM3_LAST_CHANGED=?2008-03-16? failed *** >> 4550 compile return value: 0 >> 4551 [end compile 2008.04.14 02:54:34] >> 4552 *** COMPILE FAILED >> >> Does anybody understand what's going on? >> During upgrade(), libm3 should only be built _after_ the new compiler >> has been installed, at least that is the intention. >> >> I'm in a hurry, so if anybody else cares to fix this, it would be >> great. > > I sent that mail too fast. It seems that only I386_DARWIN fails in > the release-build, but for other reasons. The last-ok builds can > be expexted to fail after incompatible changes in the runtime. > So this should cure itself during the next days. > > We should however note that we need a full compiler bootstrap again > even from older d5.7.0 archives now to compile current sources. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 jayk123 at hotmail.com Mon Apr 14 16:51:37 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 14 Apr 2008 14:51:37 +0000 Subject: [M3devel] small set comparisons understood, now just to understand the front end code.. Message-ID: currently set <,>,<=,>= are implemented merely as integer <,>,<=,>= This is wrong. I believe it should be: a < b => (a & b) == a a <= b => (a & b) == a (same as <=) a > b => (a & b) == b a >= b => (a & b) == b (same as >) The bug is in the frontend. m3-sys\m3front\src\misc\CG.m3. The code should be /something/ like: PROCEDURE Set_compare (s: Size; op: Cmp) = VAR tmp: Val; swap := FALSE; BEGIN (* a op b => BOOLEAN *) IF Force_pair (commute := TRUE) THEN op := M3CG.SwappedCompare [op]; END; IF (s <= Target.Integer.size) THEN IF (op = Cmp.EQ) OR (op = Cmp.NE) THEN cg.compare (Target.Word.cg_type, Target.Integer.cg_type, op); ELSE (* set a is less than or equal to set b, if all of set a's members are in set b. *) IF (op = Cmp.LT) OR (op = Cmp.LE) THEN swap := TRUE; Swap (); END; tmp := Pop (); Push (tmp); IF swap THEN Swap (); END; cg.and (Target.Integer.cg_type); Push (tmp); SimpleIndirectLoad (tmp^, Target.Word.cg_type); EVAL Force_pair (commute := TRUE); cg.compare (Target.Word.cg_type, Target.Integer.cg_type, Cmp.EQ); SPop (1, "Set_compare"); Free (tmp); END; ELSE cg.set_compare (AsBytes (s), op, Target.Integer.cg_type); END; SPop (2, "Set_compare"); SPush (Type.Int32); END Set_compare; though this doesn't quite drive all the machinery correctly, since it yields assertion failures in the compiler due to an unbalanced software stack. upgrade works, but the test case (p155) fails assertions in the integrated backend. I'd love to figure this out but have to do other stuff for now. Anyone (if there is anyone) familiar with what all is being pushed and popped around here should be able to figure it out easily from this mail. Otherwise I'll stare at more later. ps: "small" sets should probably be anything up to the number of bits in longint, rather than int or pointer, since that is probably efficient enough at the next level down. This is tangential. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Apr 14 17:22:35 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Apr 2008 11:22:35 -0400 Subject: [M3devel] small set comparisons understood, now just to understand the front end code.. In-Reply-To: References: Message-ID: <32E9EDBE-18FC-4F1B-8653-E60FC39DD534@cs.purdue.edu> I would hesitate to implement small sets as LONGINT instead of INTEGER, since there is no guarantee that LONGINT is necessarily efficient, whereas INTEGER is intended to be the same as the natural word size of the target. I could take a look at this but not anytime soon, since I have several other things I need to work on. On Apr 14, 2008, at 10:51 AM, Jay wrote: > currently set <,>,<=,>= are implemented merely as > integer <,>,<=,>= Yes, that seems quite wrong. I can't imagine things ever worked properly if that is how they are implemented. > > > This is wrong. > > I believe it should be: > > a < b => (a & b) == a > a <= b => (a & b) == a (same as <=) > a > b => (a & b) == b > a >= b => (a & b) == b (same as >) Probably should be: a <= b => (a & b) == a a < b => (a # b) && ((a & b) == a) a >= b => (a & b) == b a > b => (a # b) && ((a & b) == b) > > > The bug is in the frontend. > > m3-sys\m3front\src\misc\CG.m3. > > The code should be /something/ like: > > PROCEDURE Set_compare (s: Size; op: Cmp) = > VAR tmp: Val; > swap := FALSE; > BEGIN > (* a op b => BOOLEAN *) > IF Force_pair (commute := TRUE) THEN > op := M3CG.SwappedCompare [op]; > END; > IF (s <= Target.Integer.size) THEN > IF (op = Cmp.EQ) OR (op = Cmp.NE) THEN > cg.compare (Target.Word.cg_type, Target.Integer.cg_type, op); > ELSE > (* set a is less than or equal to set b, if all of set a's > members are in set b. *) > IF (op = Cmp.LT) OR (op = Cmp.LE) THEN > swap := TRUE; > Swap (); > END; > tmp := Pop (); > Push (tmp); > IF swap THEN > Swap (); > END; > cg.and (Target.Integer.cg_type); > Push (tmp); > SimpleIndirectLoad (tmp^, Target.Word.cg_type); > EVAL Force_pair (commute := TRUE); > cg.compare (Target.Word.cg_type, Target.Integer.cg_type, > Cmp.EQ); > SPop (1, "Set_compare"); > Free (tmp); > END; > ELSE > cg.set_compare (AsBytes (s), op, Target.Integer.cg_type); > END; > SPop (2, "Set_compare"); > SPush (Type.Int32); > END Set_compare; > > though this doesn't quite drive all the machinery correctly, since > it yields assertion failures in the compiler due to an unbalanced > software stack. > upgrade works, but the test case (p155) fails assertions in the > integrated backend. > > I'd love to figure this out but have to do other stuff for now. > Anyone (if there is anyone) familiar with what all is being pushed > and popped around here should be able to figure it out easily from > this mail. > Otherwise I'll stare at more later. > > ps: "small" sets should probably be anything up to the number of > bits in longint, rather than int or pointer, since that is probably > efficient enough at the next level down. This is tangential. > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Apr 14 19:18:14 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 14 Apr 2008 10:18:14 -0700 Subject: [M3devel] cm3 regression In-Reply-To: Your message of "Mon, 14 Apr 2008 07:17:53 -0000." Message-ID: <200804141718.m3EHIExE075667@camembert.async.caltech.edu> Jay writes: >--_50e47a65-f79d-472b-8eaf-fbcc30b6410e_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >new source -> compiling Cstdlib.i3"..\src\C\32BITS\BasicCtypes.i3", line 18= >: illegal based LONGINT literal, zero used"..\src\C\32BITS\BasicCtypes.i3",= > line 18: illegal based LONGINT literal, zero used > long_long =3D [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL]= >; >=20 >Why isn't this LONGINT? So that NT386 can limp along? And it'd be correct f= >or the rest, eh? >I'll try it and see.. >=20 >The underlying system (the compiler) has (U)Int[8,16,32,64] >They should just be used here imho.. >=20 >Also, what should "long" be on 64bit? >On Windows it is 32 bits always. >On 32 bit systems it is 32 bits. >I think the 64bits directory is going to be forked for AMD64_NT_*. >The Windows decision imho has successfully been applied to more code and mo= >re users so therefore is better by practical success, even if the whole iss= >ue is problematic almost no matter what. Clearly the C and Modula-3 notions= > of integers are pretty poor.. I have to re-code my program to use Int64 if I want it to use the natural INTEGER size on 64 bit machines? No thanks. From jayk123 at hotmail.com Mon Apr 14 19:52:24 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 14 Apr 2008 17:52:24 +0000 Subject: [M3devel] cm3 regression In-Reply-To: <200804141718.m3EHIExE075667@camembert.async.caltech.edu> References: Your message of "Mon, 14 Apr 2008 07:17:53 -0000." <200804141718.m3EHIExE075667@camembert.async.caltech.edu> Message-ID: Well, something has to give somewhere. INTEGER could be a "natural" signed integer if you want, however you have to balance the desire for a "natural" integer with any persistant format. It's not like 32 bit integers are going to be inefficient anywhere, so not changing the more concrete meaning of various code isn't going to really hurt it. What does hurt is 1) breaking code that really needs to represent the entire address space or 2) breaking code that really needs to maintain binary compatibility with persistant file formats. You lose either way. It just seems like the best tradeoff is to provide explicitly sized signed and unsigned types, and pointer sized signed and unsigned. And then decide what your ranges are and know that 32 bit integers are always efficient and 64 bit integers are always ok or better. Really, 32 bit integers are usually adequate or no less efficient. Really, it's hard to go wrong for efficiency, 32bit or 64bit integers, and easy to go wrong in terms of compatibility by changing the sizes of types.. - Jay > To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] cm3 regression > Date: Mon, 14 Apr 2008 10:18:14 -0700> From: mika at async.caltech.edu> > Jay writes:> >--_50e47a65-f79d-472b-8eaf-fbcc30b6410e_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >new source -> compiling Cstdlib.i3"..\src\C\32BITS\BasicCtypes.i3", line 18=> >: illegal based LONGINT literal, zero used"..\src\C\32BITS\BasicCtypes.i3",=> > line 18: illegal based LONGINT literal, zero used> > long_long =3D [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL]=> >;> >=20> >Why isn't this LONGINT? So that NT386 can limp along? And it'd be correct f=> >or the rest, eh?> >I'll try it and see..> >=20> >The underlying system (the compiler) has (U)Int[8,16,32,64]> >They should just be used here imho..> >=20> >Also, what should "long" be on 64bit?> >On Windows it is 32 bits always.> >On 32 bit systems it is 32 bits.> >I think the 64bits directory is going to be forked for AMD64_NT_*.> >The Windows decision imho has successfully been applied to more code and mo=> >re users so therefore is better by practical success, even if the whole iss=> >ue is problematic almost no matter what. Clearly the C and Modula-3 notions=> > of integers are pretty poor..> > I have to re-code my program to use Int64 if I want it to use the> natural INTEGER size on 64 bit machines? No thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Apr 14 19:55:47 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 14 Apr 2008 17:55:47 +0000 Subject: [M3devel] small set comparisons understood, now just to understand the front end code.. In-Reply-To: <32E9EDBE-18FC-4F1B-8653-E60FC39DD534@cs.purdue.edu> References: <32E9EDBE-18FC-4F1B-8653-E60FC39DD534@cs.purdue.edu> Message-ID: If they fit in an INT32, use an INT32. But if they fit in an INT64, that's still probably more efficient than an otherwise "big set". Well, of course, there's always the inline vs. non-inline size vs. speed. And here I teeter toward hypocricy in taking advantage of two "natural" integer types. Heck, generalize it to a list of efficient sizes: 8, 16, 32, 64, pick the smallest that fits, and in the future when otherwise there would have been LONGLONGINT, add 128 to the list. - Jay CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] small set comparisons understood, now just to understand the front end code..Date: Mon, 14 Apr 2008 11:22:35 -0400 I would hesitate to implement small sets as LONGINT instead of INTEGER, since there is no guarantee that LONGINT is necessarily efficient, whereas INTEGER is intended to be the same as the natural word size of the target. I could take a look at this but not anytime soon, since I have several other things I need to work on. On Apr 14, 2008, at 10:51 AM, Jay wrote: currently set <,>,<=,>= are implemented merely asinteger <,>,<=,>= Yes, that seems quite wrong. I can't imagine things ever worked properly if that is how they are implemented. This is wrong. I believe it should be: a < b => (a & b) == aa <= b => (a & b) == a (same as <=) a > b => (a & b) == ba >= b => (a & b) == b (same as >) Probably should be: a <= b => (a & b) == a a < b => (a # b) && ((a & b) == a) a >= b => (a & b) == b a > b => (a # b) && ((a & b) == b) The bug is in the frontend. m3-sys\m3front\src\misc\CG.m3. The code should be /something/ like: PROCEDURE Set_compare (s: Size; op: Cmp) =VAR tmp: Val; swap := FALSE;BEGIN (* a op b => BOOLEAN *) IF Force_pair (commute := TRUE) THEN op := M3CG.SwappedCompare [op]; END; IF (s <= Target.Integer.size) THEN IF (op = Cmp.EQ) OR (op = Cmp.NE) THEN cg.compare (Target.Word.cg_type, Target.Integer.cg_type, op); ELSE (* set a is less than or equal to set b, if all of set a's members are in set b. *) IF (op = Cmp.LT) OR (op = Cmp.LE) THEN swap := TRUE; Swap (); END; tmp := Pop (); Push (tmp); IF swap THEN Swap (); END; cg.and (Target.Integer.cg_type); Push (tmp); SimpleIndirectLoad (tmp^, Target.Word.cg_type); EVAL Force_pair (commute := TRUE); cg.compare (Target.Word.cg_type, Target.Integer.cg_type, Cmp.EQ); SPop (1, "Set_compare"); Free (tmp); END; ELSE cg.set_compare (AsBytes (s), op, Target.Integer.cg_type); END; SPop (2, "Set_compare"); SPush (Type.Int32);END Set_compare; though this doesn't quite drive all the machinery correctly, since it yields assertion failures in the compiler due to an unbalanced software stack.upgrade works, but the test case (p155) fails assertions in the integrated backend. I'd love to figure this out but have to do other stuff for now.Anyone (if there is anyone) familiar with what all is being pushed and popped around here should be able to figure it out easily from this mail.Otherwise I'll stare at more later. ps: "small" sets should probably be anything up to the number of bits in longint, rather than int or pointer, since that is probably efficient enough at the next level down. This is tangential. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Apr 14 20:14:05 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 14 Apr 2008 18:14:05 +0000 Subject: [M3devel] FW: small set comparisons understood, now just to understand the front end code.. In-Reply-To: <32E9EDBE-18FC-4F1B-8653-E60FC39DD534@cs.purdue.edu> References: <32E9EDBE-18FC-4F1B-8653-E60FC39DD534@cs.purdue.edu> Message-ID: [truncated again..] From: jayk123 at hotmail.comTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] small set comparisons understood, now just to understand the front end code..Date: Mon, 14 Apr 2008 17:55:47 +0000 If they fit in an INT32, use an INT32.But if they fit in an INT64, that's still probably more efficient than an otherwise "big set". Well, of course, there's always the inline vs. non-inline size vs. speed.And here I teeter toward hypocricy in taking advantage of two "natural" integer types.Heck, generalize it to a list of efficient sizes: 8, 16, 32, 64, pick the smallest that fits, and in the future when otherwise there would have been LONGLONGINT, add 128 to the list. - Jay[snip] -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Apr 14 20:42:07 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Apr 2008 14:42:07 -0400 Subject: [M3devel] cm3 regression In-Reply-To: <200804141718.m3EHIExE075667@camembert.async.caltech.edu> References: <200804141718.m3EHIExE075667@camembert.async.caltech.edu> Message-ID: <692B2748-B602-4A6E-B729-3C543772233F@cs.purdue.edu> I think Modula-3 has it exactly right in that the base types INTEGER and Word.T use the natural word size of the machine, and that there are no guarantees about BITSIZE on those. If you want a specific bit size you use BITS FOR or simply a subrange type, both of which pack down in memory to just the number of bytes needed. C is generally a mess since you have both LLP64 (Windows) and LP64 (everyone else, for good reason -- see http://www.unix.org/version2/whatsnew/ lp64_wp.html). In any case, yes, I expect there will need to be a fork of BasicCTypes along the lines of ILP32, LP64, and LLP64. Currently, we have the strangeness that NT386 = ILP32/LL32 (because the integrated backend can't grok LL64), but this is an anomaly. Ideally, this would go to LLP64 (IL32) to match the Win64 world. Remember, this is only for *C types*. On all 64-bit platforms, we should aim for 64-bit INTEGER and 64-bit Word.T as the native Modula-3 types. How C types fall out depends on the native C expectations of the platform, and really are just about interfacing to C APIs. On Apr 14, 2008, at 1:18 PM, Mika Nystrom wrote: > Jay writes: >> --_50e47a65-f79d-472b-8eaf-fbcc30b6410e_ >> Content-Type: text/plain; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> new source -> compiling Cstdlib.i3"..\src\C\32BITS\BasicCtypes.i3", >> line 18= >> : illegal based LONGINT literal, zero used"..\src\C\32BITS >> \BasicCtypes.i3",= >> line 18: illegal based LONGINT literal, zero used >> long_long =3D [-16_7fffffffffffffffL-1L .. >> 16_7fffffffffffffffL]= >> ; >> =20 >> Why isn't this LONGINT? So that NT386 can limp along? And it'd be >> correct f= >> or the rest, eh? >> I'll try it and see.. >> =20 >> The underlying system (the compiler) has (U)Int[8,16,32,64] >> They should just be used here imho.. >> =20 >> Also, what should "long" be on 64bit? >> On Windows it is 32 bits always. >> On 32 bit systems it is 32 bits. >> I think the 64bits directory is going to be forked for AMD64_NT_*. >> The Windows decision imho has successfully been applied to more >> code and mo= >> re users so therefore is better by practical success, even if the >> whole iss= >> ue is problematic almost no matter what. Clearly the C and Modula-3 >> notions= >> of integers are pretty poor.. > > I have to re-code my program to use Int64 if I want it to use the > natural INTEGER size on 64 bit machines? No thanks. From hosking at cs.purdue.edu Mon Apr 14 20:44:50 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Apr 2008 14:44:50 -0400 Subject: [M3devel] small set comparisons understood, now just to understand the front end code.. In-Reply-To: References: <32E9EDBE-18FC-4F1B-8653-E60FC39DD534@cs.purdue.edu> Message-ID: Premature optimization is usually time wasted and results in unnecessary complexity. On Apr 14, 2008, at 1:55 PM, Jay wrote: > If they fit in an INT32, use an INT32. > But if they fit in an INT64, that's still probably more efficient > than an otherwise "big set". > Well, of course, there's always the inline vs. non-inline size > vs. speed. > And here I teeter toward hypocricy in taking advantage of two > "natural" integer types. > Heck, generalize it to a list of efficient sizes: 8, 16, 32, 64, > pick the smallest that fits, and in the future when otherwise there > would have been LONGLONGINT, add 128 to the list. > > - Jay > > > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jayk123 at hotmail.com > Subject: Re: [M3devel] small set comparisons understood, now just to > understand the front end code.. > Date: Mon, 14 Apr 2008 11:22:35 -0400 > > I would hesitate to implement small sets as LONGINT instead of > INTEGER, since there is no guarantee that LONGINT is necessarily > efficient, whereas INTEGER is intended to be the same as the natural > word size of the target. > > I could take a look at this but not anytime soon, since I have > several other things I need to work on. > > On Apr 14, 2008, at 10:51 AM, Jay wrote: > > currently set <,>,<=,>= are implemented merely as > integer <,>,<=,>= > > Yes, that seems quite wrong. I can't imagine things ever worked > properly if that is how they are implemented. > > > > This is wrong. > > I believe it should be: > > a < b => (a & b) == a > a <= b => (a & b) == a (same as <=) > a > b => (a & b) == b > a >= b => (a & b) == b (same as >) > > Probably should be: > > a <= b => (a & b) == a > a < b => (a # b) && ((a & b) == a) > a >= b => (a & b) == b > a > b => (a # b) && ((a & b) == b) > > > > The bug is in the frontend. > > m3-sys\m3front\src\misc\CG.m3. > > The code should be /something/ like: > > PROCEDURE Set_compare (s: Size; op: Cmp) = > VAR tmp: Val; > swap := FALSE; > BEGIN > (* a op b => BOOLEAN *) > IF Force_pair (commute := TRUE) THEN > op := M3CG.SwappedCompare [op]; > END; > IF (s <= Target.Integer.size) THEN > IF (op = Cmp.EQ) OR (op = Cmp.NE) THEN > cg.compare (Target.Word.cg_type, Target.Integer.cg_type, op); > ELSE > (* set a is less than or equal to set b, if all of set a's > members are in set b. *) > IF (op = Cmp.LT) OR (op = Cmp.LE) THEN > swap := TRUE; > Swap (); > END; > tmp := Pop (); > Push (tmp); > IF swap THEN > Swap (); > END; > cg.and (Target.Integer.cg_type); > Push (tmp); > SimpleIndirectLoad (tmp^, Target.Word.cg_type); > EVAL Force_pair (commute := TRUE); > cg.compare (Target.Word.cg_type, Target.Integer.cg_type, > Cmp.EQ); > SPop (1, "Set_compare"); > Free (tmp); > END; > ELSE > cg.set_compare (AsBytes (s), op, Target.Integer.cg_type); > END; > SPop (2, "Set_compare"); > SPush (Type.Int32); > END Set_compare; > > though this doesn't quite drive all the machinery correctly, since > it yields assertion failures in the compiler due to an unbalanced > software stack. > upgrade works, but the test case (p155) fails assertions in the > integrated backend. > > I'd love to figure this out but have to do other stuff for now. > Anyone (if there is anyone) familiar with what all is being pushed > and popped around here should be able to figure it out easily from > this mail. > Otherwise I'll stare at more later. > > ps: "small" sets should probably be anything up to the number of > bits in longint, rather than int or pointer, since that is probably > efficient enough at the next level down. This is tangential. > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Apr 14 20:59:22 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 14 Apr 2008 18:59:22 +0000 Subject: [M3devel] cm3 regression In-Reply-To: <692B2748-B602-4A6E-B729-3C543772233F@cs.purdue.edu> References: <200804141718.m3EHIExE075667@camembert.async.caltech.edu> <692B2748-B602-4A6E-B729-3C543772233F@cs.purdue.edu> Message-ID: Right. Win64 will be: INTEGER = 64 bits LONGINT = 64 bits Word.T = INTEGER (should be common to all platforms) LongWord.T = LONGINT (should be common to all platforms) BasicCtypes.int = 32 bits (should be common to all platforms?) BasicCtypes.long = 32 bits (the difference) BasicCtypes.longlong = 64 bits if this even exists > mess since you have both LLP64 (Windows) and LP64 (everyone else, for > good reason -- see http://www.unix.org/version2/whatsnew/ > lp64_wp.html). In any case, yes, I expect there will need to be a I think everyone else had the advantage of: 1) doing it earlier 2) and with much less code 3) no 16 bit legacy that pushed stuff to "long" earlier, thereby taking it away as an option, whereas I GUESS on Unix int was more common, or more "care" had already been taken more often given an earlier "variety" of systems, but again #1 and #2. Hey, good redirect, want to name the directories: ILP32 (aka 32 bits) LP64 (aka 64 bits except Windows) LLP64 (aka 64 bit Windows) ? Too cryptic? While I don't want a bunch of "Win64" directories, maybe put in some selectively, and have: 32bit (same as today) 64bit (same as today) Win64 Anyway, this is still getting a bit ahead of things. - Jay > CC: jayk123 at hotmail.com; m3devel at elegosoft.com> From: hosking at cs.purdue.edu> To: mika at async.caltech.edu> Subject: Re: [M3devel] cm3 regression> Date: Mon, 14 Apr 2008 14:42:07 -0400> > I think Modula-3 has it exactly right in that the base types INTEGER > and Word.T use the natural word size of the machine, and that there > are no guarantees about BITSIZE on those. If you want a specific bit > size you use BITS FOR or simply a subrange type, both of which pack > down in memory to just the number of bytes needed. C is generally a > mess since you have both LLP64 (Windows) and LP64 (everyone else, for > good reason -- see http://www.unix.org/version2/whatsnew/ > lp64_wp.html). In any case, yes, I expect there will need to be a > fork of BasicCTypes along the lines of ILP32, LP64, and LLP64. > Currently, we have the strangeness that NT386 = ILP32/LL32 (because > the integrated backend can't grok LL64), but this is an anomaly. > Ideally, this would go to LLP64 (IL32) to match the Win64 world. > Remember, this is only for *C types*. On all 64-bit platforms, we > should aim for 64-bit INTEGER and 64-bit Word.T as the native Modula-3 > types. How C types fall out depends on the native C expectations of > the platform, and really are just about interfacing to C APIs.> > On Apr 14, 2008, at 1:18 PM, Mika Nystrom wrote:> > > Jay writes:> >> --_50e47a65-f79d-472b-8eaf-fbcc30b6410e_> >> Content-Type: text/plain; charset="iso-8859-1"> >> Content-Transfer-Encoding: quoted-printable> >>> >> new source -> compiling Cstdlib.i3"..\src\C\32BITS\BasicCtypes.i3", > >> line 18=> >> : illegal based LONGINT literal, zero used"..\src\C\32BITS > >> \BasicCtypes.i3",=> >> line 18: illegal based LONGINT literal, zero used> >> long_long =3D [-16_7fffffffffffffffL-1L .. > >> 16_7fffffffffffffffL]=> >> ;> >> =20> >> Why isn't this LONGINT? So that NT386 can limp along? And it'd be > >> correct f=> >> or the rest, eh?> >> I'll try it and see..> >> =20> >> The underlying system (the compiler) has (U)Int[8,16,32,64]> >> They should just be used here imho..> >> =20> >> Also, what should "long" be on 64bit?> >> On Windows it is 32 bits always.> >> On 32 bit systems it is 32 bits.> >> I think the 64bits directory is going to be forked for AMD64_NT_*.> >> The Windows decision imho has successfully been applied to more > >> code and mo=> >> re users so therefore is better by practical success, even if the > >> whole iss=> >> ue is problematic almost no matter what. Clearly the C and Modula-3 > >> notions=> >> of integers are pretty poor..> >> > I have to re-code my program to use Int64 if I want it to use the> > natural INTEGER size on 64 bit machines? No thanks.> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Apr 14 21:03:00 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 14 Apr 2008 19:03:00 +0000 Subject: [M3devel] small set comparisons understood, now just to understand the front end code.. In-Reply-To: References: <32E9EDBE-18FC-4F1B-8653-E60FC39DD534@cs.purdue.edu> Message-ID: Mika corrected my proposed implementation of set_compare. I had it right for <= and >= but wrong for < and >. < and > need to check if the sets are equal, in which case return false. My confidence here wasn't particularly high, I intend(ed) to test a bunch, once it works at all, and it doesn't yet. Should also 1) check the history; I suspect it never worked 2) as a stopgap if really desparate can probably omit the optimization and just use the functions but that's lame.. well, for < and >, the inline code might be kind of large actually.. could write helpers just for int-sized sets... - Jay[snip -- the below is wrong] I believe it should be: a < b => (a & b) == aa <= b => (a & b) == a (same as <=) a > b => (a & b) == ba >= b => (a & b) == b (same as >) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Apr 14 22:10:05 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 14 Apr 2008 13:10:05 -0700 Subject: [M3devel] small set comparisons understood, now just to understand the front end code.. In-Reply-To: Your message of "Mon, 14 Apr 2008 17:48:06 -0000." Message-ID: <200804142010.m3EKA5ep081393@camembert.async.caltech.edu> Sorry, I think the Green Book is completely unambiguous about this. a < b is the same as a <= b AND a # b for all a and b, no matter the type (set, integer, or floating). That's what 2.6.11 says, and it seems correct, because it implies that for sets, <= is the subset relation, and < is the proper subset relation. Mika Jay writes: >--_a67e670a-e4c4-4f68-a1a3-4f4661e52338_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > a < b "should be implemented as" (a & b) =3D=3D a=20 >=20 > I believe, and so on.=20 >I could be wrong. I only thought about it a few minutes.=20 >=20 > The current incorrect code is:=20 >PROCEDURE Set_compare (s: Size; op: Cmp) =3D BEGIN IF Force_pair (comm= >ute :=3D TRUE) THEN op :=3D M3CG.SwappedCompare [op]; END; IF (s= > <=3D Target.Integer.size) THEN cg.compare (Target.Word.cg_type, Targe= >t.Integer.cg_type, op); ELSE cg.set_compare (AsBytes (s), op, Target.I= >nteger.cg_type); END; SPop (2, "Set_eq"); SPush (Type.Int32); END= > Set_compare; >=20 >which generates simply, I think this was <=3D (jbe -- jump if below or equa= >l): >=20 >=20 > 0040119C: 56 push esi 0040119D: E8 AE FE FF FF = > call _Main__m 004011A2: 83 C4 04 add esp,4 >=20 > ... end of previous line that just called m("foo")=20 >=20 > ; push a string to print=20 > 004011A5: 8D 35 2C 12 40 00 lea esi,ds:[40122Ch] 004011AB: 56 = > push esi >=20 > ; compare two sets=20 > ; one is constant 0x15; one is a global=20 > 004011AC: 83 3D 44 90 45 00 cmp dword ptr ds:[459044h],15h = > 15 >=20 > ; spend a while converting the compare result to a boolean 004011B3: 0F = >96 45 FC setbe byte ptr [ebp-4] 004011B7: 33 DB = >xor ebx,ebx 004011B9: 8A 5D FC mov bl,byte ptr [= ebp-4] 004011BC: 83 FB 00 cmp ebx,0 004011BF: 0F 94 45 = >F8 sete byte ptr [ebp-8] 004011C3: 33 D2 xor = > edx,edx 004011C5: 8A 55 F8 mov dl,byte ptr [ebp-8] > ; and then push that boolean=20 > 004011C8: 52 push edx > 004011C9: E8 6C FF FF FF call _Main__checkM >oh, you are right, < needs to also be !=3D. >I thought it was suspicious to have only two implementations of four operat= >ions, but I did like the resulting efficiency. :) >Hey, I was at least sure the current code was wrong. >=20 > - Jay > > > >> To: jayk123 at hotmail.com> Subject: Re: [M3devel] small set comparisons und= >erstood, now just to understand the front end code.. > Date: Mon, 14 Apr 20= >08 10:16:01 -0700> From: mika at async.caltech.edu> > Jay writes:> >--_6435b74= >a-d943-44c2-9091-ab0408dc7ed0_> >Content-Type: text/plain; charset=3D"iso-8= >859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >currently set = ><,>,<=3D3D,>=3D3D are implemented merely as> >integer <,>,<=3D3D,>=3D3D> >= >=3D20> >This is wrong.> >=3D20> >I believe it should be:> >=3D20> >a < b = >=3D3D> (a & b) =3D3D=3D3D a> >a <=3D3D b =3D3D> (a & b) =3D3D=3D3D a (same = >as <=3D3D)> >a > b =3D3D> (a & b) =3D3D=3D3D b> >a >=3D3D b =3D3D> (a & b) = >=3D3D=3D3D b (same as >)> > You don't actually mean logical implication by = >your arrows do you,> but equivalence, where the objects to the left of the = >arrow refer> to the abstract sets a and b and the objects to the right of t= >he> arrow refer to bit-vector implementations (in C) of the same?> > Green = >Book, page 57, section 2.6.1:> > "In all cases, x < y means (x <=3D y) AND = >(x # y), and x > y means y < x."> > So in your syntax a > b would be ((a & = >b) =3D=3D a) && (a !=3D b).> > Also, just above it, > > "The expression x >= >=3D y is equivalent to y <=3D x."> > Why not define the operation "x >=3D y= >" and then use the two statements> from the Green Book to generate the rest= >?> > Mika= > >--_a67e670a-e4c4-4f68-a1a3-4f4661e52338_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > a < b "should be implemented as" (a &= >; b) =3D=3D a
> 
> I believe, and so on.
>I could be wrong. I only thought about it a few minutes.
> 
> The current incorrect code is:
>
PROCEDURE Set_compare (s: Size;  op: Cmp) =3D
  BEGIN
&= >nbsp;   IF Force_pair (commute :=3D TRUE) THEN
  &nb= >sp;   op :=3D M3CG.SwappedCompare [op];
    END= >;
    IF (s <=3D Target.Integer.size)
  &= >nbsp;   THEN cg.compare (Target.Word.cg_type, Target.Integer.cg_t= >ype, op);
      ELSE cg.set_compare (AsBytes (s= >), op, Target.Integer.cg_type);
    END;
  &= >nbsp; SPop (2, "Set_eq");
    SPush (Type.Int32);
&nbs= >p; END Set_compare;

> 
>which generates simply, I think this was <=3D (jbe -- jump if below or e= >qual):
> 
> 
>  0040119C: 56         &n= >bsp;       push     = >   esi
  0040119D: E8 AE FE FF FF    = > call        _Main__m
  004011A2= >: 83 C4 04           add&= >nbsp;        esp,4
> 
> ... end of previous line that just called m("foo")
> 
> ; push a string to print
>  004011A5: 8D 35 2C 12 40 00  lea     &= >nbsp;   esi,ds:[40122Ch]
  004011AB: 56   = >            &nb= >sp; push        esi
> 
> ; compare two sets
> ; one is constant 0x15; one is a global
>  004011AC: 83 3D 44 90 45 00  cmp     &= >nbsp;   dword ptr ds:[459044h],15h
    &nb= >sp;       15
> 
> ; spend a while converting the compare result to a boolean
 = > 004011B3: 0F 96 45 FC        setbe = >;      byte ptr [ebp-4]
  004011B7: 33 DB&= >nbsp;           &nbs= >p; xor         ebx,ebx
  00= >4011B9: 8A 5D FC          = >; mov         bl,byte ptr [ebp-4]R>  004011BC: 83 FB 00        = >   cmp         ebx,0
&= >nbsp; 004011BF: 0F 94 45 F8        sete&= >nbsp;       byte ptr [ebp-8]
  004011= >C3: 33 D2           = >   xor         edx,edx>  004011C5: 8A 55 F8        &= >nbsp;  mov         dl,byte ptr= > [ebp-8]

> ; and then push that boolean
>  004011C8: 52         &n= >bsp;       push     = >   edx
>  004011C9: E8 6C FF FF FF     call  &nb= >sp;     _Main__checkM


>oh, you are right, < needs to also be !=3D.
>I thought it was suspicious to have only two implementations of four operat= >ions, but I did like the resulting efficiency. :)
Hey, I was at least sure the current code was wrong.
> 
> - Jay



> >
>
>> To: jayk123 at hotmail.com
> Subject: Re: [M3devel] small set compa= >risons understood, now just to understand the front end code..
> Dat= >e: Mon, 14 Apr 2008 10:16:01 -0700
> From: mika at async.caltech.edu
= >>
> Jay writes:
> >--_6435b74a-d943-44c2-9091-ab0408dc7e= >d0_
> >Content-Type: text/plain; charset=3D"iso-8859-1"
> &g= >t;Content-Transfer-Encoding: quoted-printable
> >
> >
= >> >currently set <,>,<=3D3D,>=3D3D are implemented merely= > as
> >integer <,>,<=3D3D,>=3D3D
> >=3D20
= >> >This is wrong.
> >=3D20
> >I believe it should b= >e:
> >=3D20
> >a < b =3D3D> (a & b) =3D3D=3D3D = >a
> >a <=3D3D b =3D3D> (a & b) =3D3D=3D3D a (same as <= >;=3D3D)
> >a > b =3D3D> (a & b) =3D3D=3D3D b
> >= >;a >=3D3D b =3D3D> (a & b) =3D3D=3D3D b (same as >)
> R>> You don't actually mean logical implication by your arrows do you,R>> but equivalence, where the objects to the left of the arrow refer>> to the abstract sets a and b and the objects to the right of the
&= >gt; arrow refer to bit-vector implementations (in C) of the same?
> <= >BR>> Green Book, page 57, section 2.6.1:
>
> "In all cases,= > x < y means (x <=3D y) AND (x # y), and x > y means y < x.">>
> So in your syntax a > b would be ((a & b) =3D=3D a) &= >amp;& (a !=3D b).
>
> Also, just above it,
>
&g= >t; "The expression x >=3D y is equivalent to y <=3D x."
>
&= >gt; Why not define the operation "x >=3D y" and then use the two stateme= >nts
> from the Green Book to generate the rest?
>
> Mika= >

>= > >--_a67e670a-e4c4-4f68-a1a3-4f4661e52338_-- From jayk123 at hotmail.com Mon Apr 14 23:55:48 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 14 Apr 2008 21:55:48 +0000 Subject: [M3devel] small set comparisons understood, now just to understand the front end code.. In-Reply-To: <200804142010.m3EKA5ep081393@camembert.async.caltech.edu> References: Your message of "Mon, 14 Apr 2008 17:48:06 -0000." <200804142010.m3EKA5ep081393@camembert.async.caltech.edu> Message-ID: I think we are in agreement now on this. My original assertions were indeed wrong for <= and >=. I'm not even sure they were correct for < and >. - Jay > To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] small set comparisons understood, now just to understand the front end code.. > Date: Mon, 14 Apr 2008 13:10:05 -0700> From: mika at async.caltech.edu> > Sorry, I think the Green Book is completely unambiguous about this.> > a < b is the same as a <= b AND a # b for all a and b, no matter> the type (set, integer, or floating). That's what 2.6.11 says, and> it seems correct, because it implies that for sets, <= is the subset> relation, and < is the proper subset relation.> > Mika> > Jay writes:> >--_a67e670a-e4c4-4f68-a1a3-4f4661e52338_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> > a < b "should be implemented as" (a & b) =3D=3D a=20> >=20> > I believe, and so on.=20> >I could be wrong. I only thought about it a few minutes.=20> >=20> > The current incorrect code is:=20> >PROCEDURE Set_compare (s: Size; op: Cmp) =3D BEGIN IF Force_pair (comm=> >ute :=3D TRUE) THEN op :=3D M3CG.SwappedCompare [op]; END; IF (s=> > <=3D Target.Integer.size) THEN cg.compare (Target.Word.cg_type, Targe=> >t.Integer.cg_type, op); ELSE cg.set_compare (AsBytes (s), op, Target.I=> >nteger.cg_type); END; SPop (2, "Set_eq"); SPush (Type.Int32); END=> > Set_compare;> >=20> >which generates simply, I think this was <=3D (jbe -- jump if below or equa=> >l):> >=20> >=20> > 0040119C: 56 push esi 0040119D: E8 AE FE FF FF => > call _Main__m 004011A2: 83 C4 04 add esp,4> >=20> > ... end of previous line that just called m("foo")=20> >=20> > ; push a string to print=20> > 004011A5: 8D 35 2C 12 40 00 lea esi,ds:[40122Ch] 004011AB: 56 => > push esi> >=20> > ; compare two sets=20> > ; one is constant 0x15; one is a global=20> > 004011AC: 83 3D 44 90 45 00 cmp dword ptr ds:[459044h],15h => > 15> >=20> > ; spend a while converting the compare result to a boolean 004011B3: 0F => >96 45 FC setbe byte ptr [ebp-4] 004011B7: 33 DB => >xor ebx,ebx 004011B9: 8A 5D FC mov bl,byte ptr [=> ebp-4] 004011BC: 83 FB 00 cmp ebx,0 004011BF: 0F 94 45 => >F8 sete byte ptr [ebp-8] 004011C3: 33 D2 xor => > edx,edx 004011C5: 8A 55 F8 mov dl,byte ptr [ebp-8]> > ; and then push that boolean=20> > 004011C8: 52 push edx> > 004011C9: E8 6C FF FF FF call _Main__checkM> >oh, you are right, < needs to also be !=3D.> >I thought it was suspicious to have only two implementations of four operat=> >ions, but I did like the resulting efficiency. :)> >Hey, I was at least sure the current code was wrong.> >=20> > - Jay> >> >> >> >> To: jayk123 at hotmail.com> Subject: Re: [M3devel] small set comparisons und=> >erstood, now just to understand the front end code.. > Date: Mon, 14 Apr 20=> >08 10:16:01 -0700> From: mika at async.caltech.edu> > Jay writes:> >--_6435b74=> >a-d943-44c2-9091-ab0408dc7ed0_> >Content-Type: text/plain; charset=3D"iso-8=> >859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >currently set => ><,>,<=3D3D,>=3D3D are implemented merely as> >integer <,>,<=3D3D,>=3D3D> >=> >=3D20> >This is wrong.> >=3D20> >I believe it should be:> >=3D20> >a < b => >=3D3D> (a & b) =3D3D=3D3D a> >a <=3D3D b =3D3D> (a & b) =3D3D=3D3D a (same => >as <=3D3D)> >a > b =3D3D> (a & b) =3D3D=3D3D b> >a >=3D3D b =3D3D> (a & b) => >=3D3D=3D3D b (same as >)> > You don't actually mean logical implication by => >your arrows do you,> but equivalence, where the objects to the left of the => >arrow refer> to the abstract sets a and b and the objects to the right of t=> >he> arrow refer to bit-vector implementations (in C) of the same?> > Green => >Book, page 57, section 2.6.1:> > "In all cases, x < y means (x <=3D y) AND => >(x # y), and x > y means y < x."> > So in your syntax a > b would be ((a & => >b) =3D=3D a) && (a !=3D b).> > Also, just above it, > > "The expression x >=> >=3D y is equivalent to y <=3D x."> > Why not define the operation "x >=3D y=> >" and then use the two statements> from the Green Book to generate the rest=> >?> > Mika=> >> >--_a67e670a-e4c4-4f68-a1a3-4f4661e52338_> >Content-Type: text/html; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >> >> >> > a < b "should be implemented as" (a &=> >; b) =3D=3D a
> > 
> > I believe, and so on.
> >I could be wrong. I only thought about it a few minutes.
> > 
> > The current incorrect code is:
> >
PROCEDURE Set_compare (s: Size;  op: Cmp) =3D
  BEGIN
&=> >nbsp;   IF Force_pair (commute :=3D TRUE) THEN
  &nb=> >sp;   op :=3D M3CG.SwappedCompare [op];
    END=> >;
    IF (s <=3D Target.Integer.size)
  &=> >nbsp;   THEN cg.compare (Target.Word.cg_type, Target.Integer.cg_t=> >ype, op);
      ELSE cg.set_compare (AsBytes (s=> >), op, Target.Integer.cg_type);
    END;
  &=> >nbsp; SPop (2, "Set_eq");
    SPush (Type.Int32);
&nbs=> >p; END Set_compare;

> > 
> >which generates simply, I think this was <=3D (jbe -- jump if below or e=> >qual):
> > 
> > 
> >  0040119C: 56         &n=> >bsp;       push     => >   esi
  0040119D: E8 AE FE FF FF    => > call        _Main__m
  004011A2=> >: 83 C4 04           add&=> >nbsp;        esp,4
> > 
> > ... end of previous line that just called m("foo")
> > 
> > ; push a string to print
> >  004011A5: 8D 35 2C 12 40 00  lea     &=> >nbsp;   esi,ds:[40122Ch]
  004011AB: 56   => >            &nb=> >sp; push        esi
> > 
> > ; compare two sets
> > ; one is constant 0x15; one is a global
> >  004011AC: 83 3D 44 90 45 00  cmp     &=> >nbsp;   dword ptr ds:[459044h],15h
    &nb=> >sp;       15
> > 
> > ; spend a while converting the compare result to a boolean
 => > 004011B3: 0F 96 45 FC        setbe => >;      byte ptr [ebp-4]
  004011B7: 33 DB&=> >nbsp;           &nbs=> >p; xor         ebx,ebx
  00=> >4011B9: 8A 5D FC          => >; mov         bl,byte ptr [ebp-4] >R>  004011BC: 83 FB 00        => >   cmp         ebx,0
&=> >nbsp; 004011BF: 0F 94 45 F8        sete&=> >nbsp;       byte ptr [ebp-8]
  004011=> >C3: 33 D2           => >   xor         edx,edx >>  004011C5: 8A 55 F8        &=> >nbsp;  mov         dl,byte ptr=> > [ebp-8]

> > ; and then push that boolean
> >  004011C8: 52         &n=> >bsp;       push     => >   edx
> >  004011C9: E8 6C FF FF FF     call  &nb=> >sp;     _Main__checkM


> >oh, you are right, < needs to also be !=3D.
> >I thought it was suspicious to have only two implementations of four operat=> >ions, but I did like the resulting efficiency. :)
> Hey, I was at least sure the current code was wrong.
> > 
> > - Jay



> >> >
> >
> >> To: jayk123 at hotmail.com
> Subject: Re: [M3devel] small set compa=> >risons understood, now just to understand the front end code..
> Dat=> >e: Mon, 14 Apr 2008 10:16:01 -0700
> From: mika at async.caltech.edu
=> >>
> Jay writes:
> >--_6435b74a-d943-44c2-9091-ab0408dc7e=> >d0_
> >Content-Type: text/plain; charset=3D"iso-8859-1"
> &g=> >t;Content-Transfer-Encoding: quoted-printable
> >
> >
=> >> >currently set <,>,<=3D3D,>=3D3D are implemented merely=> > as
> >integer <,>,<=3D3D,>=3D3D
> >=3D20
=> >> >This is wrong.
> >=3D20
> >I believe it should b=> >e:
> >=3D20
> >a < b =3D3D> (a & b) =3D3D=3D3D => >a
> >a <=3D3D b =3D3D> (a & b) =3D3D=3D3D a (same as <=> >;=3D3D)
> >a > b =3D3D> (a & b) =3D3D=3D3D b
> >=> >;a >=3D3D b =3D3D> (a & b) =3D3D=3D3D b (same as >)
> >R>> You don't actually mean logical implication by your arrows do you, >R>> but equivalence, where the objects to the left of the arrow refer >>> to the abstract sets a and b and the objects to the right of the
&=> >gt; arrow refer to bit-vector implementations (in C) of the same?
> <=> >BR>> Green Book, page 57, section 2.6.1:
>
> "In all cases,=> > x < y means (x <=3D y) AND (x # y), and x > y means y < x." >>>
> So in your syntax a > b would be ((a & b) =3D=3D a) &=> >amp;& (a !=3D b).
>
> Also, just above it,
>
&g=> >t; "The expression x >=3D y is equivalent to y <=3D x."
>
&=> >gt; Why not define the operation "x >=3D y" and then use the two stateme=> >nts
> from the Green Book to generate the rest?
>
> Mika=> >

> >=> >> >--_a67e670a-e4c4-4f68-a1a3-4f4661e52338_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Apr 14 23:58:31 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 14 Apr 2008 21:58:31 +0000 Subject: [M3devel] small set comparisons understood, now just to understand the front end code.. In-Reply-To: References: <32E9EDBE-18FC-4F1B-8653-E60FC39DD534@cs.purdue.edu> Message-ID: And doing no optimization up front, or not designing to allow it later, leads to it being difficult to doing all of it later. Early optimization and profiling followed by late optimization are both needed. A balance must be found. "Premature" has a negative connotation, "early" does not. Complexity is imho often overstated also.. ..Jay CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] small set comparisons understood, now just to understand the front end code..Date: Mon, 14 Apr 2008 14:44:50 -0400 Premature optimization is usually time wasted and results in unnecessary complexity. On Apr 14, 2008, at 1:55 PM, Jay wrote: If they fit in an INT32, use an INT32.But if they fit in an INT64, that's still probably more efficient than an otherwise "big set". Well, of course, there's always the inline vs. non-inline size vs. speed.And here I teeter toward hypocricy in taking advantage of two "natural" integer types.Heck, generalize it to a list of efficient sizes: 8, 16, 32, 64, pick the smallest that fits, and in the future when otherwise there would have been LONGLONGINT, add 128 to the list. - Jay CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] small set comparisons understood, now just to understand the front end code..Date: Mon, 14 Apr 2008 11:22:35 -0400 I would hesitate to implement small sets as LONGINT instead of INTEGER, since there is no guarantee that LONGINT is necessarily efficient, whereas INTEGER is intended to be the same as the natural word size of the target. I could take a look at this but not anytime soon, since I have several other things I need to work on. On Apr 14, 2008, at 10:51 AM, Jay wrote: currently set <,>,<=,>= are implemented merely asinteger <,>,<=,>= Yes, that seems quite wrong. I can't imagine things ever worked properly if that is how they are implemented. This is wrong. I believe it should be: a < b => (a & b) == aa <= b => (a & b) == a (same as <=) a > b => (a & b) == ba >= b => (a & b) == b (same as >) Probably should be: a <= b => (a & b) == a a < b => (a # b) && ((a & b) == a) a >= b => (a & b) == b a > b => (a # b) && ((a & b) == b) The bug is in the frontend. m3-sys\m3front\src\misc\CG.m3. The code should be /something/ like: PROCEDURE Set_compare (s: Size; op: Cmp) =VAR tmp: Val; swap := FALSE;BEGIN (* a op b => BOOLEAN *) IF Force_pair (commute := TRUE) THEN op := M3CG.SwappedCompare [op]; END; IF (s <= Target.Integer.size) THEN IF (op = Cmp.EQ) OR (op = Cmp.NE) THEN cg.compare (Target.Word.cg_type, Target.Integer.cg_type, op); ELSE (* set a is less than or equal to set b, if all of set a's members are in set b. *) IF (op = Cmp.LT) OR (op = Cmp.LE) THEN swap := TRUE; Swap (); END; tmp := Pop (); Push (tmp); IF swap THEN Swap (); END; cg.and (Target.Integer.cg_type); Push (tmp); SimpleIndirectLoad (tmp^, Target.Word.cg_type); EVAL Force_pair (commute := TRUE); cg.compare (Target.Word.cg_type, Target.Integer.cg_type, Cmp.EQ); SPop (1, "Set_compare"); Free (tmp); END; ELSE cg.set_compare (AsBytes (s), op, Target.Integer.cg_type); END; SPop (2, "Set_compare"); SPush (Type.Int32);END Set_compare; though this doesn't quite drive all the machinery correctly, since it yields assertion failures in the compiler due to an unbalanced software stack.upgrade works, but the test case (p155) fails assertions in the integrated backend. I'd love to figure this out but have to do other stuff for now.Anyone (if there is anyone) familiar with what all is being pushed and popped around here should be able to figure it out easily from this mail.Otherwise I'll stare at more later. ps: "small" sets should probably be anything up to the number of bits in longint, rather than int or pointer, since that is probably efficient enough at the next level down. This is tangential. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Apr 15 08:35:16 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 15 Apr 2008 08:35:16 +0200 Subject: [M3devel] new cm3 backend dependencies Message-ID: <20080415083516.i3vino6o0w400osw@mail.elegosoft.com> Hi Ronny, Antony Hosking has updated the gcc in cm3, which leads to new build dependencies which are not available at our regression test systems: 1088 NEXT configure: error: Building GCC requires GMP 4.1+ and MPFR 2.3.0+. Can you provide these? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From ronny.forberger at elegosoft.com Tue Apr 15 12:51:55 2008 From: ronny.forberger at elegosoft.com (Ronny Forberger) Date: Tue, 15 Apr 2008 12:51:55 +0200 Subject: [M3devel] new cm3 backend dependencies In-Reply-To: <20080415083516.i3vino6o0w400osw@mail.elegosoft.com> References: <20080415083516.i3vino6o0w400osw@mail.elegosoft.com> Message-ID: <20080415125155.wi1hnkfy4gsk4cks@mail.elegosoft.com> Hi there, on birch.elego.de (LINUXLIBC6) there is GMP 4.2.1 on the package management system, which I installed. Also there is MPFR but only at version <2.3.0, this is why I installed MPFR 2.3.0 under the prefix /usr/local. I guess cm3 will automatically find the libs there. On new.elego.de (FreeBSD4) there was libgmp-4.2.1_1 already installed under /usr/local. MPFR was too old there too, so I installed 2.3.0 manually to /usr/contrib. I guess cm3 needs to be told to use libs residing under /usr/contrib ? Cheers, Ronny -- Message from: Olaf Wagner Date: Di 15 Apr 2008 08:35:16 CEST Subject: new cm3 backend dependencies > Hi Ronny, > > Antony Hosking has updated the gcc in cm3, which leads to new > build dependencies which are not available at our regression test > systems: > > 1088 NEXT configure: error: Building GCC requires GMP 4.1+ and MPFR > 2.3.0+. > > Can you provide these? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -- Ronny Forberger Systemadministration & IT-Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Geb?ude 12, Raum 227 D-13355 Berlin Tel. +49 30 23 45 86 96 ronny.forberger at elegosoft.com Fax +49 30 23 45 86 95 http://www.elegosoft.com Gesch?ftsf?hrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Apr 15 13:05:31 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 15 Apr 2008 13:05:31 +0200 Subject: [M3devel] new cm3 backend dependencies In-Reply-To: <20080415125155.wi1hnkfy4gsk4cks@mail.elegosoft.com> References: <20080415083516.i3vino6o0w400osw@mail.elegosoft.com> <20080415125155.wi1hnkfy4gsk4cks@mail.elegosoft.com> Message-ID: <20080415130531.kjb7fdsbjswk4sck@mail.elegosoft.com> Quoting Ronny Forberger : > Hi there, > > on birch.elego.de (LINUXLIBC6) there is GMP 4.2.1 on the package > management system, which I installed. > > Also there is MPFR but only at version <2.3.0, this is why I installed > MPFR 2.3.0 under the prefix /usr/local. I guess cm3 will automatically > find the libs there. > > On new.elego.de (FreeBSD4) there was libgmp-4.2.1_1 already installed > under /usr/local. > > MPFR was too old there too, so I installed 2.3.0 manually to > /usr/contrib. I guess cm3 needs to be told to use libs residing under > /usr/contrib ? Probably. Doesn't the FreeBSD ports system provide an update? If you can build it manually, perhaps it is sufficient to just increase the version numbers in the port and send the patch to a FreeBSD committer / the port maintainer? Olaf > Cheers, > > Ronny > > -- > Message from: Olaf Wagner > Date: Di 15 Apr 2008 08:35:16 CEST > Subject: new cm3 backend dependencies > > >> Hi Ronny, >> >> Antony Hosking has updated the gcc in cm3, which leads to new >> build dependencies which are not available at our regression test >> systems: >> >> 1088 NEXT configure: error: Building GCC requires GMP 4.1+ and MPFR >> 2.3.0+. >> >> Can you provide these? >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > > > -- > > Ronny Forberger > Systemadministration & IT-Support > > elego Software Solutions GmbH > Gustav-Meyer-Allee 25 > Geb?ude 12, Raum 227 > D-13355 Berlin > > Tel. +49 30 23 45 86 96 ronny.forberger at elegosoft.com > Fax +49 30 23 45 86 95 http://www.elegosoft.com > > Gesch?ftsf?hrer: Olaf Wagner, Sitz Berlin > Amtsgericht Berlin-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 hendrik at topoi.pooq.com Tue Apr 15 13:07:40 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 15 Apr 2008 07:07:40 -0400 Subject: [M3devel] small set comparisons understood, now just to understand the front end code.. In-Reply-To: <32E9EDBE-18FC-4F1B-8653-E60FC39DD534@cs.purdue.edu> References: <32E9EDBE-18FC-4F1B-8653-E60FC39DD534@cs.purdue.edu> Message-ID: <20080415110740.GA12952@topoi.pooq.com> On Mon, Apr 14, 2008 at 11:22:35AM -0400, Tony Hosking wrote: > > Yes, that seems quite wrong. I can't imagine things ever worked > properly if that is how they are implemented. Maybe stick a test in the compiler to see if < > <= >= are ever used on small sets anywhere in the m3 system? You might want to do this anyway in case anyone is relying on them doing integer comparisons. I seem to remember using them for subset comparisons in a Pascal program I converted to modula 3 many years ago. I was using the PM3 compiler then, and I haven't tried it on cm3 yet. I'd have to check the code to see what I was really doing, though. -- hendrik From hendrik at topoi.pooq.com Tue Apr 15 13:09:19 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 15 Apr 2008 07:09:19 -0400 Subject: [M3devel] small set comparisons understood, now just to understand the front end code.. In-Reply-To: References: <32E9EDBE-18FC-4F1B-8653-E60FC39DD534@cs.purdue.edu> Message-ID: <20080415110919.GB12952@topoi.pooq.com> On Mon, Apr 14, 2008 at 07:03:00PM +0000, Jay wrote: > Should also 1) check the history; I suspect it never worked 2) as a stopgap if really desparate can probably omit the optimization and just use the functions but that's lame.. well, for < and >, the inline code might be kind of large actually.. could write helpers just for int-sized sets... You might compare the cm3 code with the pm3 code. I think I may have used it on pm3 long ago without mishap. -- hendrik From jayk123 at hotmail.com Tue Apr 15 13:23:38 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 15 Apr 2008 11:23:38 +0000 Subject: [M3devel] small set comparisons understood, now just to understand the front end code.. In-Reply-To: <20080415110919.GB12952@topoi.pooq.com> References: <32E9EDBE-18FC-4F1B-8653-E60FC39DD534@cs.purdue.edu> <20080415110919.GB12952@topoi.pooq.com> Message-ID: PM3 has it wrong too. http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/pm3/m3/pm3/language/modula3/m3compiler/m3front/src/misc/CG.m3?rev=1.4;content-type=text%2FplainPROCEDURE Set_compare (s: Size; op: Cmp) = BEGIN IF Force_pair (commute := TRUE) THEN op := M3CG.SwappedCompare [op]; END; IF (s <= Target.Integer.size) THEN cg.compare (Target.Word.cg_type, Target.Integer.cg_type, op); ELSE cg.set_compare (AsBytes (s), op, Target.Integer.cg_type); END; SPop (2, "Set_eq"); SPush (Type.Int32); END Set_compare; I didn't run it and look at the generate code, but this is the same as cm3 had and it just generated <,<=,>,>= for integers. Anyway, I checked in a fix for it. - Jay > Date: Tue, 15 Apr 2008 07:09:19 -0400> From: hendrik at topoi.pooq.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] small set comparisons understood, now just to understand the front end code..> > On Mon, Apr 14, 2008 at 07:03:00PM +0000, Jay wrote:> > > Should also 1) check the history; I suspect it never worked 2) as a stopgap if really desparate can probably omit the optimization and just use the functions but that's lame.. well, for < and >, the inline code might be kind of large actually.. could write helpers just for int-sized sets...> > You might compare the cm3 code with the pm3 code. I think I may have > used it on pm3 long ago without mishap.> > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Apr 15 13:24:13 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 15 Apr 2008 11:24:13 +0000 Subject: [M3devel] small set comparisons understood, now just to understand the front end code.. In-Reply-To: <20080415110919.GB12952@topoi.pooq.com> References: <32E9EDBE-18FC-4F1B-8653-E60FC39DD534@cs.purdue.edu> <20080415110919.GB12952@topoi.pooq.com> Message-ID: PM3 has it wrong too. http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/pm3/m3/pm3/language/modula3/m3compiler/m3front/src/misc/CG.m3?rev=1.4;content-type=text%2FplainPROCEDURE Set_compare (s: Size; op: Cmp) = BEGIN IF Force_pair (commute := TRUE) THEN op := M3CG.SwappedCompare [op]; END; IF (s <= Target.Integer.size) THEN cg.compare (Target.Word.cg_type, Target.Integer.cg_type, op); ELSE cg.set_compare (AsBytes (s), op, Target.Integer.cg_type); END; SPop (2, "Set_eq"); SPush (Type.Int32); END Set_compare; I didn't run it and look at the generate code, but this is the same as cm3 had and it just generated <,<=,>,>= for integers. Anyway, I checked in a fix for it. - Jay > Date: Tue, 15 Apr 2008 07:09:19 -0400> From: hendrik at topoi.pooq.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] small set comparisons understood, now just to understand the front end code..> > On Mon, Apr 14, 2008 at 07:03:00PM +0000, Jay wrote:> > > Should also 1) check the history; I suspect it never worked 2) as a stopgap if really desparate can probably omit the optimization and just use the functions but that's lame.. well, for < and >, the inline code might be kind of large actually.. could write helpers just for int-sized sets...> > You might compare the cm3 code with the pm3 code. I think I may have > used it on pm3 long ago without mishap.> > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronny.forberger at elegosoft.com Tue Apr 15 13:31:29 2008 From: ronny.forberger at elegosoft.com (Ronny Forberger) Date: Tue, 15 Apr 2008 13:31:29 +0200 Subject: [M3devel] new cm3 backend dependencies In-Reply-To: <20080415130531.kjb7fdsbjswk4sck@mail.elegosoft.com> References: <20080415083516.i3vino6o0w400osw@mail.elegosoft.com> <20080415125155.wi1hnkfy4gsk4cks@mail.elegosoft.com> <20080415130531.kjb7fdsbjswk4sck@mail.elegosoft.com> Message-ID: <20080415133129.d6xwc1x1oo40co0c@mail.elegosoft.com> -- Message from: Olaf Wagner Date: Di 15 Apr 2008 13:05:31 CEST Subject: Re: new cm3 backend dependencies > Quoting Ronny Forberger : > >> Hi there, >> >> on birch.elego.de (LINUXLIBC6) there is GMP 4.2.1 on the package >> management system, which I installed. >> >> Also there is MPFR but only at version <2.3.0, this is why I installed >> MPFR 2.3.0 under the prefix /usr/local. I guess cm3 will automatically >> find the libs there. >> >> On new.elego.de (FreeBSD4) there was libgmp-4.2.1_1 already installed >> under /usr/local. >> >> MPFR was too old there too, so I installed 2.3.0 manually to >> /usr/contrib. I guess cm3 needs to be told to use libs residing under >> /usr/contrib ? > > Probably. Doesn't the FreeBSD ports system provide an update? Only with a later release tag (RELASE_6_3_0), you know I won't upgrade ports on a productive system apart from upgrading the base system as this can cause tremendous problems and might break other things running on the machine. > If you can build it manually, perhaps it is sufficient to just > increase the version numbers in the port and send the patch > to a FreeBSD committer / the port maintainer? It has been built, but the next FreeBSD release and higher cope it anyways. I think it's better to some day upgrade new.elego.de to FreeBSD 7 in order to have more current package versions. But we could probably move the FreeBSD-targeted cm3 regression tests from new.elego.de to willow.elego.de, which can be more easily upgraded to FreeBSD 7. Stupidly this would cause trouble in the tinderbox view, when a new hostname would appear. Cheers, Ronny > > Olaf > >> Cheers, >> >> Ronny >> >> -- >> Message from: Olaf Wagner >> Date: Di 15 Apr 2008 08:35:16 CEST >> Subject: new cm3 backend dependencies >> >> >>> Hi Ronny, >>> >>> Antony Hosking has updated the gcc in cm3, which leads to new >>> build dependencies which are not available at our regression test >>> systems: >>> >>> 1088 NEXT configure: error: Building GCC requires GMP 4.1+ and MPFR >>> 2.3.0+. >>> >>> Can you provide these? >>> >>> Olaf >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>> 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >> >> >> >> -- >> >> Ronny Forberger >> Systemadministration & IT-Support >> >> elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 >> Geb?ude 12, Raum 227 >> D-13355 Berlin >> >> Tel. +49 30 23 45 86 96 ronny.forberger at elegosoft.com >> Fax +49 30 23 45 86 95 http://www.elegosoft.com >> >> Gesch?ftsf?hrer: Olaf Wagner, Sitz Berlin >> Amtsgericht Berlin-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 -- Ronny Forberger Systemadministration & IT-Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Geb?ude 12, Raum 227 D-13355 Berlin Tel. +49 30 23 45 86 96 ronny.forberger at elegosoft.com Fax +49 30 23 45 86 95 http://www.elegosoft.com Gesch?ftsf?hrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Tue Apr 15 14:09:13 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 15 Apr 2008 08:09:13 -0400 Subject: [M3devel] small set comparisons understood, now just to understand the front end code.. In-Reply-To: <20080415110740.GA12952@topoi.pooq.com> References: <32E9EDBE-18FC-4F1B-8653-E60FC39DD534@cs.purdue.edu> <20080415110740.GA12952@topoi.pooq.com> Message-ID: <20080415120913.GC12952@topoi.pooq.com> On Tue, Apr 15, 2008 at 07:07:40AM -0400, hendrik at topoi.pooq.com wrote: > On Mon, Apr 14, 2008 at 11:22:35AM -0400, Tony Hosking wrote: > > > > Yes, that seems quite wrong. I can't imagine things ever worked > > properly if that is how they are implemented. > > Maybe stick a test in the compiler to see if < > <= >= are ever used on > small sets anywhere in the m3 system? You might want to do this anyway > in case anyone is relying on them doing integer comparisons. > > I seem to remember using them for subset comparisons in a Pascal program > I converted to modula 3 many years ago. I was using the PM3 compiler > then, and I haven't tried it on cm3 yet. I'd have to check the code to > see what I was really doing, though. Found it. I didn't actually use < or <=. I used *. - hendrik From wagner at elegosoft.com Tue Apr 15 15:11:17 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 15 Apr 2008 15:11:17 +0200 Subject: [M3devel] new cm3 backend dependencies In-Reply-To: <20080415133129.d6xwc1x1oo40co0c@mail.elegosoft.com> References: <20080415083516.i3vino6o0w400osw@mail.elegosoft.com> <20080415125155.wi1hnkfy4gsk4cks@mail.elegosoft.com> <20080415130531.kjb7fdsbjswk4sck@mail.elegosoft.com> <20080415133129.d6xwc1x1oo40co0c@mail.elegosoft.com> Message-ID: <20080415151117.ns7s255eckoowgow@mail.elegosoft.com> Quoting Ronny Forberger : > -- > Message from: Olaf Wagner > Date: Di 15 Apr 2008 13:05:31 CEST > Subject: Re: new cm3 backend dependencies > > >> Quoting Ronny Forberger : >> >>> Hi there, >>> >>> on birch.elego.de (LINUXLIBC6) there is GMP 4.2.1 on the package >>> management system, which I installed. >>> >>> Also there is MPFR but only at version <2.3.0, this is why I installed >>> MPFR 2.3.0 under the prefix /usr/local. I guess cm3 will automatically >>> find the libs there. >>> >>> On new.elego.de (FreeBSD4) there was libgmp-4.2.1_1 already installed >>> under /usr/local. >>> >>> MPFR was too old there too, so I installed 2.3.0 manually to >>> /usr/contrib. I guess cm3 needs to be told to use libs residing under >>> /usr/contrib ? >> >> Probably. Doesn't the FreeBSD ports system provide an update? > > Only with a later release tag (RELASE_6_3_0), you know I won't upgrade > ports on a productive system apart from upgrading the base system as > this can cause tremendous problems and might break other things running > on the machine. This is OK as a base strategy, but not in the following cases: (1) security updates of ports which need to be installed (2) development servers which need to provide a more recent and active view for the programmer To (1): Even on stable production systems security fixes should lead to port upgrades. To (2): Developers often need the latest version of any software, so if the standard one provided is too old, a second port hierarchy needs to be available. Is this the current use of /usr/contrib? >> If you can build it manually, perhaps it is sufficient to just >> increase the version numbers in the port and send the patch >> to a FreeBSD committer / the port maintainer? > > It has been built, but the next FreeBSD release and higher cope it > anyways. I think it's better to some day upgrade new.elego.de to > FreeBSD 7 in order to have more current package versions. This is a major upgrade and might have other impacts due to incompatibilities. I'd be more careful in upgrading the base system than in upgrading ports. > But we could probably move the FreeBSD-targeted cm3 regression tests > from new.elego.de to willow.elego.de, which can be more easily upgraded > to FreeBSD 7. Stupidly this would cause trouble in the tinderbox view, > when a new hostname would appear. This may be a good idea anyway, but we should progress carefully towards the FreeBSD 7 upgrade. We should also take this discussion from the m3devel-list ;-) I'll see if I can provide a fix for gcc to scan /usr/contrib for dependencies, too. It may take some time. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Tue Apr 15 19:38:56 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 15 Apr 2008 13:38:56 -0400 Subject: [M3devel] new cm3 backend dependencies In-Reply-To: <20080415125155.wi1hnkfy4gsk4cks@mail.elegosoft.com> References: <20080415083516.i3vino6o0w400osw@mail.elegosoft.com> <20080415125155.wi1hnkfy4gsk4cks@mail.elegosoft.com> Message-ID: <5B0A38FF-7170-40A1-AD8F-6E792AC73CD8@cs.purdue.edu> Yes, forgot to mention this. /usr/lib will get foun by configure, so that is the best option if it is not installed as a package to /usr/lib. On Apr 15, 2008, at 6:51 AM, Ronny Forberger wrote: > Hi there, > > on birch.elego.de (LINUXLIBC6) there is GMP 4.2.1 on the package > management system, which I installed. > > Also there is MPFR but only at version <2.3.0, this is why I > installed MPFR 2.3.0 under the prefix /usr/local. I guess cm3 will > automatically find the libs there. > > On new.elego.de (FreeBSD4) there was libgmp-4.2.1_1 already > installed under /usr/local. > > MPFR was too old there too, so I installed 2.3.0 manually to /usr/ > contrib. I guess cm3 needs to be told to use libs residing under / > usr/contrib ? > > Cheers, > > Ronny > > -- > Message from: Olaf Wagner > Date: Di 15 Apr 2008 08:35:16 CEST > Subject: new cm3 backend dependencies > > >> Hi Ronny, >> >> Antony Hosking has updated the gcc in cm3, which leads to new >> build dependencies which are not available at our regression test >> systems: >> >> 1088 NEXT configure: error: Building GCC requires GMP 4.1+ and >> MPFR >> 2.3.0+. >> >> Can you provide these? >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >> Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >> 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >> Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 > > > > -- > > Ronny Forberger > Systemadministration & IT-Support > > elego Software Solutions GmbH > Gustav-Meyer-Allee 25 > Geb?ude 12, Raum 227 > D-13355 Berlin > > Tel. +49 30 23 45 86 96 ronny.forberger at elegosoft.com > Fax +49 30 23 45 86 95 http://www.elegosoft.com > > Gesch?ftsf?hrer: Olaf Wagner, Sitz Berlin > Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 > > From jayk123 at hotmail.com Wed Apr 16 12:18:38 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 16 Apr 2008 10:18:38 +0000 Subject: [M3devel] cm3 regression In-Reply-To: <692B2748-B602-4A6E-B729-3C543772233F@cs.purdue.edu> References: <200804141718.m3EHIExE075667@camembert.async.caltech.edu> <692B2748-B602-4A6E-B729-3C543772233F@cs.purdue.edu> Message-ID: [tangential...] I think the definition of INTEGER is OK, but it'd be nice imho for the language or m3core to also build-in UINTEGER, INT8, INT16, INT32, INT64, UINT8, UINT16, UINT32, UINT64, just so folks wouldn't have to provide them themselves. (CARDINAL I don't think is what I want.) Add them somewhere in m3core? MODULE Integers; ? Unfortunately, actually, I want more than this, and then coming up with names is hard. I want "safe" integers that raise exceptions or something upon overflow. I want "unsafe" integers that silently "wrap around". And maybe "arbitrary precision" integers that grow to accomodate, but also are smart and shrink to throw away trailing zeros. I know you can often push stuff out of the language and into a library. As long as the language allows the library writer to provide a "nice enough" interface. For example the use of the plus sign on user defined types.. You know..like C++... but less complicated and easier to implement and fully understand... In C, "officially", unsigned integers are unsafe and wrap around silently, and overflow on signed integers is undefined, however in reality, they are also silent, and I suspect, but am not sure, that I want both versions..maybe only for compat with existing code. Which reminds me -- am I correct that the Modula-3 language defines overflow as raising an exception but nobody implements it that way? I can check. Are folks interested in fixing that? - Jay > CC: jayk123 at hotmail.com; m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: mika at async.caltech.edu > Subject: Re: [M3devel] cm3 regression > Date: Mon, 14 Apr 2008 14:42:07 -0400 > > I think Modula-3 has it exactly right in that the base types INTEGER > and Word.T use the natural word size of the machine, and that there > are no guarantees about BITSIZE on those. If you want a specific bit > size you use BITS FOR or simply a subrange type, both of which pack > down in memory to just the number of bytes needed. C is generally a > mess since you have both LLP64 (Windows) and LP64 (everyone else, for > good reason -- see http://www.unix.org/version2/whatsnew/ > lp64_wp.html). In any case, yes, I expect there will need to be a > fork of BasicCTypes along the lines of ILP32, LP64, and LLP64. > Currently, we have the strangeness that NT386 = ILP32/LL32 (because > the integrated backend can't grok LL64), but this is an anomaly. > Ideally, this would go to LLP64 (IL32) to match the Win64 world. > Remember, this is only for *C types*. On all 64-bit platforms, we > should aim for 64-bit INTEGER and 64-bit Word.T as the native Modula-3 > types. How C types fall out depends on the native C expectations of > the platform, and really are just about interfacing to C APIs. > > On Apr 14, 2008, at 1:18 PM, Mika Nystrom wrote: > > > Jay writes: > >> --_50e47a65-f79d-472b-8eaf-fbcc30b6410e_ > >> Content-Type: text/plain; charset="iso-8859-1" > >> Content-Transfer-Encoding: quoted-printable > >> > >> new source -> compiling Cstdlib.i3"..\src\C\32BITS\BasicCtypes.i3", > >> line 18= > >> : illegal based LONGINT literal, zero used"..\src\C\32BITS > >> \BasicCtypes.i3",= > >> line 18: illegal based LONGINT literal, zero used > >> long_long =3D [-16_7fffffffffffffffL-1L .. > >> 16_7fffffffffffffffL]= > >> ; > >> =20 > >> Why isn't this LONGINT? So that NT386 can limp along? And it'd be > >> correct f= > >> or the rest, eh? > >> I'll try it and see.. > >> =20 > >> The underlying system (the compiler) has (U)Int[8,16,32,64] > >> They should just be used here imho.. > >> =20 > >> Also, what should "long" be on 64bit? > >> On Windows it is 32 bits always. > >> On 32 bit systems it is 32 bits. > >> I think the 64bits directory is going to be forked for AMD64_NT_*. > >> The Windows decision imho has successfully been applied to more > >> code and mo= > >> re users so therefore is better by practical success, even if the > >> whole iss= > >> ue is problematic almost no matter what. Clearly the C and Modula-3 > >> notions= > >> of integers are pretty poor.. > > > > I have to re-code my program to use Int64 if I want it to use the > > natural INTEGER size on 64 bit machines? No thanks. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Apr 16 12:47:58 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 16 Apr 2008 12:47:58 +0200 Subject: [M3devel] cm3 regression In-Reply-To: References: <200804141718.m3EHIExE075667@camembert.async.caltech.edu> <692B2748-B602-4A6E-B729-3C543772233F@cs.purdue.edu> Message-ID: <20080416124758.lgyai5sjs40wc8k4@mail.elegosoft.com> Quoting Jay : > [tangential...] > > I think the definition of INTEGER is OK, but it'd be nice imho for > the language or m3core to also build-in UINTEGER, INT8, INT16, > INT32, INT64, UINT8, UINT16, UINT32, UINT64, just so folks wouldn't > have to provide them themselves. (CARDINAL I don't think is what I > want.) > Add them somewhere in m3core? > MODULE Integers; ? Such things may be convenient for programmers, but are left out of the language because the specification must not become too long, I think. I'd opt for library extensions in this case. > Unfortunately, actually, I want more than this, and then coming up > with names is hard. > > I know you can often push stuff out of the language and into a > library. As long as the language allows the library writer to > provide a "nice enough" interface. For example the use of the plus > sign on user defined types.. You know..like C++... but less > complicated and easier to implement and fully understand... Ah, operator overloading opens up another of Pandora's boxes, I think. It will dramatically increase the complexity of the language. > In C, "officially", unsigned integers are unsafe and wrap around > silently, and overflow on signed integers is undefined, however in > reality, they are also silent, and I suspect, but am not sure, that > I want both versions..maybe only for compat with existing code. > > Which reminds me -- am I correct that the Modula-3 language defines > overflow as raising an exception but nobody implements it that way? > I can check. Are folks interested in fixing that? Yes, IIRC there are no checks on integer overflow; this is an implementation flaw. How would you provide this? Add generation of checks on every integer operation? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Wed Apr 16 14:30:14 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 16 Apr 2008 08:30:14 -0400 Subject: [M3devel] cm3 regression In-Reply-To: <20080416124758.lgyai5sjs40wc8k4@mail.elegosoft.com> References: <200804141718.m3EHIExE075667@camembert.async.caltech.edu> <692B2748-B602-4A6E-B729-3C543772233F@cs.purdue.edu> <20080416124758.lgyai5sjs40wc8k4@mail.elegosoft.com> Message-ID: <20080416123014.GA13596@topoi.pooq.com> On Wed, Apr 16, 2008 at 12:47:58PM +0200, Olaf Wagner wrote: > Quoting Jay : > > >[tangential...] > > > >I think the definition of INTEGER is OK, but it'd be nice imho for > >the language or m3core to also build-in UINTEGER, INT8, INT16, > >INT32, INT64, UINT8, UINT16, UINT32, UINT64, just so folks wouldn't > >have to provide them themselves. (CARDINAL I don't think is what I > >want.) > >Add them somewhere in m3core? > >MODULE Integers; ? > > Such things may be convenient for programmers, but are left out of the > language because the specification must not become too long, I think. > I'd opt for library extensions in this case. > > >Unfortunately, actually, I want more than this, and then coming up > >with names is hard. > > > >I know you can often push stuff out of the language and into a > >library. As long as the language allows the library writer to > >provide a "nice enough" interface. For example the use of the plus > >sign on user defined types.. You know..like C++... but less > >complicated and easier to implement and fully understand... > > Ah, operator overloading opens up another of Pandora's boxes, > I think. It will dramatically increase the complexity of the > language. > > >In C, "officially", unsigned integers are unsafe and wrap around > >silently, and overflow on signed integers is undefined, however in > >reality, they are also silent, and I suspect, but am not sure, that > >I want both versions..maybe only for compat with existing code. > > > >Which reminds me -- am I correct that the Modula-3 language defines > >overflow as raising an exception but nobody implements it that way? > >I can check. Are folks interested in fixing that? > > Yes, IIRC there are no checks on integer overflow; this is an > implementation flaw. How would you provide this? Add generation of > checks on every integer operation? IIRC, most hardware provides a mechanism for efficient overflow detection. If the language does not provide access to this hardware mechanism, if becomes difficult and inefficient for the programmer to detect overflow. Since checked overflow is necessary for many security issues, the language needs to make it possible to check. How it should do so can be a subject for much dispute. And for Modula 3 it may be difficult if the gcc back end does not support it. -- hendrik From jayk123 at hotmail.com Wed Apr 16 15:31:03 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 16 Apr 2008 13:31:03 +0000 Subject: [M3devel] current cm3cg works? Message-ID: bootstrapping from 5.4.0 on KUbuntu Hardy Heron 8.4 beta AMD64 cm3 just core dumps..around ThreadF__Init probably the setjmp/longjmp scrambling bug 5.4.0 is what the regression framework defaulted to starting with, that's how I picked it. so tried from d5.7.0-2008-04-10-02-00-05 instead my cm3cg yields like: new source -> compiling SystemPosix.m3 ../src/POSIX/SystemPosix.m3: In function 'System__Hostname': ../src/POSIX/SystemPosix.m3:37: internal compiler error: in simplify_subreg, at simplify-rtx.c:4923 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling FSUnix_cm3.m3 ../src/POSIX/FSUnix_cm3.m3: In function 'FSUtils__IsReadable': ../src/POSIX/FSUnix_cm3.m3:10: internal compiler error: in int_mode_for_mode, at stor-layout.c:258 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling TextUtils.m3 ../src/cm3/TextUtils.m3: In function 'TextUtils__SkipLeft': ../src/cm3/TextUtils.m3:36: internal compiler error: in int_mode_for_mode, at stor-layout.c:258 Please submit a full bug report, so now going back to the cm3cg in d5.7.0-2008-04-10-02-00-05 That works, scripts/python/upgrade.py succeeds, having set OMIT_GCC (probably should be CM3_OMIT_GCC). No time right now to dig in.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Apr 16 16:08:11 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 16 Apr 2008 14:08:11 +0000 Subject: [M3devel] cm3 regression In-Reply-To: <20080416124758.lgyai5sjs40wc8k4@mail.elegosoft.com> References: <200804141718.m3EHIExE075667@camembert.async.caltech.edu> <692B2748-B602-4A6E-B729-3C543772233F@cs.purdue.edu> <20080416124758.lgyai5sjs40wc8k4@mail.elegosoft.com> Message-ID: > > it'd be nice imho for the language or m3core to also build-in UINTEGER, INT8, INT16, > > INT32, INT64, UINT8, UINT16, UINT32, UINT64, just so folks wouldn't > > have to provide them themselves. (CARDINAL I don't think is what I > > want.) > > Add them somewhere in m3core? > > MODULE Integers; ? > > Such things may be convenient for programmers, but are left out of the > language because the specification must not become too long, I think. > I'd opt for library extensions in this case. Good enough. Except I'm not sure about UINTEGER..like..why is CARDINAL only half range? I'd have to dig in..NOT now.. > Yes, IIRC there are no checks on integer overflow; this is an > implementation flaw. How would you provide this? Add generation of > checks on every integer operation? Well, it's a no-win situation. The check would bloat the code. Even function calls would bloat and slow. Probably function calls. And then hopefully optimize them some. For example: FOR i := 0 TO n DO ... END; Check up front then n isn't negative, and then no checking is needed for the incrementing of n to overflow. Similarly, FOR i := 0 TO n BY 2 DO ... END; or whatever is the syntax, check if the start/end are divisible by the increment and the start is less than the end, and then no overflow check needed. I guess on most architectures every add/sub/mul/div instruction would tend to have one additional instruction, a conditional branch, after it. It will take some investigation. Perhaps gnat (GNU Ada compiler, part of gcc) or gpc (Pascal, I think likewise, maybe) already provide this though. Maybe just some simple reuse. There'd probably be pragmas or other types to choise behavior, esp. in unsafe modules. Anyway, none of this particular soon, at least by me, I have a bunch of other things I want to do or see done first. But sure we can talk about it or someone else can do it. :) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Wed Apr 16 17:17:23 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 16 Apr 2008 08:17:23 -0700 Subject: [M3devel] cm3 regression In-Reply-To: Your message of "Wed, 16 Apr 2008 10:18:38 -0000." Message-ID: <200804161517.m3GFHNTt056611@camembert.async.caltech.edu> Jay writes: >--_17f831a5-9311-459c-8ba3-fd6675a58221_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >[tangential...] > >I think the definition of INTEGER is OK, but it'd be nice imho for the lang= >uage or m3core to also build-in UINTEGER, INT8, INT16, INT32, INT64, UINT8,= > UINT16, UINT32, UINT64, just so folks wouldn't have to provide them themse= >lves. (CARDINAL I don't think is what I want.) >Add them somewhere in m3core? >MODULE Integers; ? I don't see why you can't provide all these types for yourself in a library that users can import or not as they see fit... as long as my old INTEGER programs are still going to use the "default fast integer type" on the machine! I can see your arguments for using such pre-defined fixed-width types inside system-dependent compiler bits or specific system-dependent source files even in other situations. (Although I would still argue that part of the point of Modula-3 is to get away from this kind of system-dependent-everything programming! Write once, run anywhere! Oops, am I using someone else's slogan?) > >Unfortunately, actually, I want more than this, and then coming up with nam= >es is hard. > >I want "safe" integers that raise exceptions or something upon overflow. INTEGER/CARDINAL? You could just name yours INTEGER32, CARDINAL64, etc. According to the Green Book, overflows for these types are supposed to raise exceptions or cause some other kind of runtime error. (Actually, I am not sure it says so explicitly, but that is definitely the simplest interpretation of what it does say.) If you want exceptions on overflow, you do want CARDINAL, not UINTEGER. Or what would you like 4-5 to return in this "exceptional unsigned" integer type? >I want "unsafe" integers that silently "wrap around". Word.T? Word128.T? By the way there is nothing "unsafe" about this. "Unsafe" has a very specific meaning to Modula-3 people, which I think it would be nice if we could maintain at least on the "m3devel" mailing list! See sections 2.1 (first paragraph of the language definition), 2.5.7, and 2.7 of the Green Book. >And maybe "arbitrary precision" integers that grow to accomodate, but also = >are smart and shrink to throw away trailing zeros. Isn't there already a library for this in CM3? Mika From rodney.bates at wichita.edu Wed Apr 16 22:40:57 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Wed, 16 Apr 2008 15:40:57 -0500 Subject: [M3devel] cm3 regression In-Reply-To: References: <200804141718.m3EHIExE075667@camembert.async.caltech.edu> <692B2748-B602-4A6E-B729-3C543772233F@cs.purdue.edu> <20080416124758.lgyai5sjs40wc8k4@mail.elegosoft.com> Message-ID: <48066459.8000301@wichita.edu> Jay wrote: >>>it'd be nice imho for the language or m3core to also build-in UINTEGER, INT8, INT16, >>>INT32, INT64, UINT8, UINT16, UINT32, UINT64, just so folks wouldn't >>>have to provide them themselves. (CARDINAL I don't think is what I >>>want.) >>>Add them somewhere in m3core? >>>MODULE Integers; ? >> >>Such things may be convenient for programmers, but are left out of the >>language because the specification must not become too long, I think. >>I'd opt for library extensions in this case. > > > Good enough. > Except I'm not sure about UINTEGER..like..why is CARDINAL only half range? > I'd have to dig in..NOT now.. > I've been through this in Modula-2. There, CARDINAL is a whole, unsigned range. Unfortunately, this created a linguistic and portability nightmare. It was worse because I don't think the original Modula-2 definition completely specified things like assignability between the two, operators on mixtures of the two, implied conversions, etc. I know different implementations were different to the point it was difficult even to write code that would compile on them all. Maybe there is a cleaner way to have two distinct types, one signed, one unsigned, and both full range, but it would at least be tricky. The Modula-3 way is found in Word. Word.T is the same type as INTEGER, but the operations in Word (e.g. Word.Times) apply unsigned interpretation to the bits of the same-typed value. This avoids a lot of problems. So for full range, unsigned, values, use Word (and probably, to show your intent to readers, declare variables as Word.T rather than INTEGER, even though it is the same type). As for CARDINAL in Modula-3, it was originally exactly [0..LAST(INTEGER)]. This was changed later to say it is "just like" [0..LAST(INTEGER)]. It was years before I fully understood this. I once posted a question on the M3 newsgroup about it and gave up waiting for an answer. Then I read the compiler code and found what it means, literally, is that CARDINAL is a different type from [0..LAST(INTEGER)], but the two have all the same legal operations. This distinction seldom matters, because it is almost always assignability and not type equality that is relevant. Which didn't help explain why. Then there was an answer to my question saying that the change in the definition of CARDINAL was to support Pickles, but this still left me in the dark. Finally, while working on Pickles, it dawned on me that, without the change, it would not be possible for Pickles to change the size of a CARDINAL between 32 & 64 bits. The type [0..LAST(INTEGER)] (or any other similar subrange) is a different type if LAST(INTEGER) has a different value. CARDINAL, in contrast, can change range between platforms and still be the same type. Moral: Don't pickle anything whose type contains values like LAST(INTEGER) that differ from platform to platform. > >>Yes, IIRC there are no checks on integer overflow; this is an >>implementation flaw. How would you provide this? Add generation of >>checks on every integer operation? > > > Well, it's a no-win situation. > The check would bloat the code. > Even function calls would bloat and slow. > Probably function calls. I happen to be extremely conservative on the value of detecting runtime errors, even at efficiency cost. I heard some horror stories in the early years of my career about programs that had been in use for years and whose output had been used to plan the expenditure of huge amounts of money, then were accidentally found to be producing wrong (though not obviously so) output, that would have been caught by running with runtime checks enabled. In any case, big time cost increases (e.g. double) associated with a few operations very often amortize over the whole program's run time to only 1% or 2%. > > And then hopefully optimize them some. > For example: > FOR i := 0 TO n DO > ... > END; > > Check up front then n isn't negative, and then no checking is needed for the incrementing of n to overflow. Overflow in compiler-generated arithmetic is a little different than in arithmetic explicitly coded by the programmer. In this example, the language specifically exempts the compiler from worrying about this. 2.3.16, last sentence: "If the upper bound of the loop is LAST(INTEGER), it should be rewritten as a WHILE loop to avoid overflow." As for other optimizations, the language specifies the semantics, so a compiler is free to do anything that complies with this. > > Similarly, > FOR i := 0 TO n BY 2 DO > > ... > > END; > > or whatever is the syntax, check if the start/end are divisible by the increment and the start is less than the end, and then no overflow check needed -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From dabenavidesd at yahoo.es Wed Apr 16 23:47:16 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 16 Apr 2008 23:47:16 +0200 (CEST) Subject: [M3devel] cm3 regression In-Reply-To: <48066459.8000301@wichita.edu> Message-ID: <734362.39663.qm@web27109.mail.ukl.yahoo.com> Hi all: The best idea I thing, tough I'm not an expert is to use static methods at the low level of the m3 system, let's say the gcc backend. This is not something really easy, but it's doable. I know for Open64 project http://www.open64.net, see "Implement a static program analysis tool based on Open64 compiler". It's something I found interesting in that area. SRC Modula-3 version 3.3 does not do arithmetic overflow or underflow checking, see the manual reference attached in the mail (see section 1.11.1). But what about pm3 or cm3? The other way it's also more traditional with static tools in the source code of the compiled program (well it's more tedious for most of us, it's using a specification language for a checker). Someone has checked open 64 as a possible backend of cm3? Thanks "Rodney M. Bates" escribi?: Jay wrote: >>>it'd be nice imho for the language or m3core to also build-in UINTEGER, INT8, INT16, >>>INT32, INT64, UINT8, UINT16, UINT32, UINT64, just so folks wouldn't >>>have to provide them themselves. (CARDINAL I don't think is what I >>>want.) >>>Add them somewhere in m3core? >>>MODULE Integers; ? >> >>Such things may be convenient for programmers, but are left out of the >>language because the specification must not become too long, I think. >>I'd opt for library extensions in this case. > > > Good enough. > Except I'm not sure about UINTEGER..like..why is CARDINAL only half range? > I'd have to dig in..NOT now.. > I've been through this in Modula-2. There, CARDINAL is a whole, unsigned range. Unfortunately, this created a linguistic and portability nightmare. It was worse because I don't think the original Modula-2 definition completely specified things like assignability between the two, operators on mixtures of the two, implied conversions, etc. I know different implementations were different to the point it was difficult even to write code that would compile on them all. Maybe there is a cleaner way to have two distinct types, one signed, one unsigned, and both full range, but it would at least be tricky. The Modula-3 way is found in Word. Word.T is the same type as INTEGER, but the operations in Word (e.g. Word.Times) apply unsigned interpretation to the bits of the same-typed value. This avoids a lot of problems. So for full range, unsigned, values, use Word (and probably, to show your intent to readers, declare variables as Word.T rather than INTEGER, even though it is the same type). As for CARDINAL in Modula-3, it was originally exactly [0..LAST(INTEGER)]. This was changed later to say it is "just like" [0..LAST(INTEGER)]. It was years before I fully understood this. I once posted a question on the M3 newsgroup about it and gave up waiting for an answer. Then I read the compiler code and found what it means, literally, is that CARDINAL is a different type from [0..LAST(INTEGER)], but the two have all the same legal operations. This distinction seldom matters, because it is almost always assignability and not type equality that is relevant. Which didn't help explain why. Then there was an answer to my question saying that the change in the definition of CARDINAL was to support Pickles, but this still left me in the dark. Finally, while working on Pickles, it dawned on me that, without the change, it would not be possible for Pickles to change the size of a CARDINAL between 32 & 64 bits. The type [0..LAST(INTEGER)] (or any other similar subrange) is a different type if LAST(INTEGER) has a different value. CARDINAL, in contrast, can change range between platforms and still be the same type. Moral: Don't pickle anything whose type contains values like LAST(INTEGER) that differ from platform to platform. > >>Yes, IIRC there are no checks on integer overflow; this is an >>implementation flaw. How would you provide this? Add generation of >>checks on every integer operation? > > > Well, it's a no-win situation. > The check would bloat the code. > Even function calls would bloat and slow. > Probably function calls. I happen to be extremely conservative on the value of detecting runtime errors, even at efficiency cost. I heard some horror stories in the early years of my career about programs that had been in use for years and whose output had been used to plan the expenditure of huge amounts of money, then were accidentally found to be producing wrong (though not obviously so) output, that would have been caught by running with runtime checks enabled. In any case, big time cost increases (e.g. double) associated with a few operations very often amortize over the whole program's run time to only 1% or 2%. > > And then hopefully optimize them some. > For example: > FOR i := 0 TO n DO > ... > END; > > Check up front then n isn't negative, and then no checking is needed for the incrementing of n to overflow. Overflow in compiler-generated arithmetic is a little different than in arithmetic explicitly coded by the programmer. In this example, the language specifically exempts the compiler from worrying about this. 2.3.16, last sentence: "If the upper bound of the loop is LAST(INTEGER), it should be rewritten as a WHILE loop to avoid overflow." As for other optimizations, the language specifies the semantics, so a compiler is free to do anything that complies with this. > > Similarly, > FOR i := 0 TO n BY 2 DO > > ... > > END; > > or whatever is the syntax, check if the start/end are divisible by the increment and the start is less than the end, and then no overflow check needed -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu --------------------------------- Tu correo tambi?n desde el m?vil. Desc?rgate gratis Yahoo! Go. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SRCm3-3.3.ps.gz Type: application/x-gzip Size: 95592 bytes Desc: 18170785-SRCm3-3.3.ps.gz URL: From neels at elego.de Thu Apr 17 00:59:56 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Thu, 17 Apr 2008 00:59:56 +0200 Subject: [M3devel] snapshot compilation fails on FreeBSD Message-ID: <480684EC.4060401@elego.de> Hi all, on new.elego.de, a FreeBSD 6.2-RELEASE-p3, using the files cm3-min-POSIX-FreeBSD4-d5.7.0-2008-04-14-01-30-39.tgz cm3-src-gnu-d5.7.0-2008-04-16-14-07-05.tgz cm3-src-std-d5.6.0-2008-02-23-22-14-00.tgz cm3-src-sys-d5.7.0-2008-04-16-14-07-05.tgz and running ./cminstall -i issuing installation target as /home/neels/local-new/cm3 then changing the $PATH so that $ which cm3 /home/neels/local-new/cm3/bin/cm3 and running $ cd scripts $ ./do-cm3-core.sh buildship yielded after a few minutes the following error: ... ==> /home/neels/cm3/cm3/m3-libs/m3core done === package /home/neels/cm3/cm3/m3-libs/libm3 === +++ cm3 -build -DROOT='/home/neels/cm3/cm3' -DCM3_VERSION_TEXT='d5.6.0' -DCM3_VERSION_NUMBER='050600' -DCM3_LAST_CHANGED='2008-01-31' && cm3 -ship -DROOT='/home/neels/cm3/cm3' -DCM3_VERSION_TEXT='d5.6.0' -DCM3_VERSION_NUMBER='050600' -DCM3_LAST_CHANGED='2008-01-31' +++ --- building in FreeBSD4 --- ignoring ../src/m3overrides new source -> compiling Atom.i3 new source -> compiling AtomList.i3 new source -> compiling OSError.i3 new source -> compiling File.i3 new source -> compiling RegularFile.i3 new source -> compiling Pipe.i3 new source -> compiling TextSeq.i3 new source -> compiling Pathname.i3 new source -> compiling FS.i3 new source -> compiling Process.i3 new source -> compiling Socket.i3 new source -> compiling Terminal.i3 new source -> compiling FS.m3 new source -> compiling Terminal.m3 new source -> compiling RegularFile.m3 new source -> compiling Pipe.m3 new source -> compiling Socket.m3 new source -> compiling OSConfig.i3 new source -> compiling OSErrorPosix.i3 new source -> compiling Fmt.i3 new source -> compiling OSErrorPosix.m3 new source -> compiling FilePosix.i3 new source -> compiling FilePosix.m3 new source -> compiling FSPosix.m3 new source -> compiling PipePosix.m3 new source -> compiling PathnamePosix.m3 new source -> compiling Env.i3 new source -> compiling ProcessPosix.m3 new source -> compiling SocketPosix.m3 Fatal Error: bad version stamps: SocketPosix.m3 version stamp mismatch: Compiler.Platform => SocketPosix.m3 => Compiler.i3 version stamp mismatch: Compiler.ThisPlatform => SocketPosix.m3 => Compiler.i3 *** execution of cm3 -build -DROOT='/home/neels/cm3/cm3' -DCM3_VERSION_TEXT='d5.6.0' -DCM3_VERSION_NUMBER='050600' -DCM3_LAST_CHANGED='2008-01-31' && cm3 -ship -DROOT='/home/neels/cm3/cm3' -DCM3_VERSION_TEXT='d5.6.0' -DCM3_VERSION_NUMBER='050600' -DCM3_LAST_CHANGED='2008-01-31' failed *** What does this mean? Thanks, Neels From hosking at cs.purdue.edu Thu Apr 17 01:24:37 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 16 Apr 2008 19:24:37 -0400 Subject: [M3devel] snapshot compilation fails on FreeBSD In-Reply-To: <480684EC.4060401@elego.de> References: <480684EC.4060401@elego.de> Message-ID: <0CE452FA-BE6F-40BC-8530-6AD84909223A@cs.purdue.edu> This is a result of the recent addition of an additional target AMD64_DARWIN to the compiler. You need to compile a new bootstrap compiler with the new target in it and use that to compile m3core. 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 Apr 16, 2008, at 6:59 PM, Neels Janosch Hofmeyr wrote: > Hi all, > > on new.elego.de, a FreeBSD 6.2-RELEASE-p3, using the files > > cm3-min-POSIX-FreeBSD4-d5.7.0-2008-04-14-01-30-39.tgz > cm3-src-gnu-d5.7.0-2008-04-16-14-07-05.tgz > cm3-src-std-d5.6.0-2008-02-23-22-14-00.tgz > cm3-src-sys-d5.7.0-2008-04-16-14-07-05.tgz > > > and running > > ./cminstall -i > > issuing installation target as > > /home/neels/local-new/cm3 > > then changing the $PATH so that > > $ which cm3 > /home/neels/local-new/cm3/bin/cm3 > > > and running > > $ cd scripts > $ ./do-cm3-core.sh buildship > > > yielded after a few minutes the following error: > > ... > ==> /home/neels/cm3/cm3/m3-libs/m3core done > > === package /home/neels/cm3/cm3/m3-libs/libm3 === > +++ cm3 -build -DROOT='/home/neels/cm3/cm3' - > DCM3_VERSION_TEXT='d5.6.0' > -DCM3_VERSION_NUMBER='050600' -DCM3_LAST_CHANGED='2008-01-31' && cm3 > -ship -DROOT='/home/neels/cm3/cm3' -DCM3_VERSION_TEXT='d5.6.0' > -DCM3_VERSION_NUMBER='050600' -DCM3_LAST_CHANGED='2008-01-31' +++ > --- building in FreeBSD4 --- > > ignoring ../src/m3overrides > > new source -> compiling Atom.i3 > new source -> compiling AtomList.i3 > new source -> compiling OSError.i3 > new source -> compiling File.i3 > new source -> compiling RegularFile.i3 > new source -> compiling Pipe.i3 > new source -> compiling TextSeq.i3 > new source -> compiling Pathname.i3 > new source -> compiling FS.i3 > new source -> compiling Process.i3 > new source -> compiling Socket.i3 > new source -> compiling Terminal.i3 > new source -> compiling FS.m3 > new source -> compiling Terminal.m3 > new source -> compiling RegularFile.m3 > new source -> compiling Pipe.m3 > new source -> compiling Socket.m3 > new source -> compiling OSConfig.i3 > new source -> compiling OSErrorPosix.i3 > new source -> compiling Fmt.i3 > new source -> compiling OSErrorPosix.m3 > new source -> compiling FilePosix.i3 > new source -> compiling FilePosix.m3 > new source -> compiling FSPosix.m3 > new source -> compiling PipePosix.m3 > new source -> compiling PathnamePosix.m3 > new source -> compiling Env.i3 > new source -> compiling ProcessPosix.m3 > new source -> compiling SocketPosix.m3 > > Fatal Error: bad version stamps: SocketPosix.m3 > > version stamp mismatch: Compiler.Platform > => SocketPosix.m3 > => Compiler.i3 > version stamp mismatch: Compiler.ThisPlatform > => SocketPosix.m3 > => Compiler.i3 > *** execution of cm3 -build -DROOT='/home/neels/cm3/cm3' > -DCM3_VERSION_TEXT='d5.6.0' -DCM3_VERSION_NUMBER='050600' > -DCM3_LAST_CHANGED='2008-01-31' && cm3 -ship > -DROOT='/home/neels/cm3/cm3' -DCM3_VERSION_TEXT='d5.6.0' > -DCM3_VERSION_NUMBER='050600' -DCM3_LAST_CHANGED='2008-01-31' > failed *** > > > > What does this mean? > > Thanks, > Neels -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Apr 17 08:40:10 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 17 Apr 2008 08:40:10 +0200 Subject: [M3devel] new gcc build time Message-ID: <20080417084010.k3clt47rk8go4www@mail.elegosoft.com> The first regression test run on my own system has now been successful after the import of the new gcc. The run time has increased dramatically from about 45 minutes to more than 5 hours :-/ Can anybody explain this? And can we do something about it? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Thu Apr 17 13:53:22 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 17 Apr 2008 11:53:22 +0000 Subject: [M3devel] new gcc build time In-Reply-To: <20080417084010.k3clt47rk8go4www@mail.elegosoft.com> References: <20080417084010.k3clt47rk8go4www@mail.elegosoft.com> Message-ID: I see this too. I've been experimenting.. --disable-bootstrap? I don't know yet. You know, it wants to build gcc to build gcc, but the host gcc usually suffices. Unless maybe bootstrapping from other than gcc, like using the Sun/SGI/AIX/whatever compilers? (Or old gcc on Mac OSX, has trouble building lots of stuff, though a switch worked..) It's also a pain to build on an AMD64 system, even though x86 stuff generally works. I have a whiny email coming up.. There's also this stage1, 2, 3 stuff, related to gcc building itself to build itself, and then again to verify. - Jay > Date: Thu, 17 Apr 2008 08:40:10 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] new gcc build time > > The first regression test run on my own system has now been successful > after the import of the new gcc. > > The run time has increased dramatically from about 45 minutes to > more than 5 hours :-/ > > Can anybody explain this? And can we do something about it? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 jayk123 at hotmail.com Thu Apr 17 14:03:59 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 17 Apr 2008 12:03:59 +0000 Subject: [M3devel] biarch, multilib, etc? Message-ID: Can anyone explain how Linux and gcc are managing that AMD64 systems can run and presumably build x86 code? I know there is /lib32 and /lib64. I know there is gcc -m32 and gcc -m64. I know that gcc itself delegates out to target specific executables, so one gcc plus flags suffices, it's those other executables that multiply out. That ld has the -m flag. That as has --32 and --64. I don't know how much stuff goes through gcc, vs. needs the get the as/ld flags correct. I'm not talking about Modula-3 here, but, like of building gcc and its dependencies. I can deal with the smaller Modula-3 system contained in far more readable Quake code than all the "sh" and layers upon layers of makefiles and autoconf and sh and m4 etc.. ./configure on various things tend to build just AMD64. It appears in general that for any apt-get install foo you can often but not always apt-get install foo-i386 This is on KUbuntu 8.4 Hardy Heron KDE4 beta AMD64 (mouthful!) It looks like in general: CC="gcc -m32" .../configure --prefix=/usr --libdir=/usr/lib32 --build=i686-pc-linux-gnu is what you want, but that many packages are only native. in particular gmp and mpfr: apt-get install mpfr-i386 => no luck Maybe these are not considered "mainstream"? I'll build them myself, something like: cd /usr/src apt-get source mpfr mkdir -p obj/mpfr cd obj/mpfr CC="gcc -m32" /usr/src/mpfr-2.3.1.dfsg.1/configure --prefix=/usr --libdir=/usr/lib32 --build=i686-pc-linux-gnu make sudo make install cd /usr/src apt-get source libgmp3-dev mkdir -p /usr/src/obj/gmp cd /usr/src/obj/obj CC="gcc -m32" /usr/src/gmp-4.2.2+dfsg/configure --prefix=/usr --libdir=/usr/lib32 --build=i686-pc-linux-gnu make sudo make install You know, I just want building the Modula-3 system on AMD64_LINUX to at first merely build an x86 hosted, x86 targeted binary. And then start changing things. And between host, target, and build, I find the names confusing. I understand why there are three -- the current system to build the compiler, a system to run the compiler, a system to run the compiler's output, but these names host, target, build, aren't very mnemonic with me yet. Is it build=now, host=runs the compier, target=runs the compiler's output? I'll dig around. I know, I can figure it all out, there's the www to search, but this biarch/multilib is hard to find the docs for..and I can't read the masses of m4/sh/gmake.. ps: it's easy to get the ld to crash when doing this stuff wrong.. (I can explain how Windows does it, fyi. 1) The system is "doubled up", generally .dlls and .exes, but not kernel and drivers c:\windows\system32 is native c:\windows\syswow64 is 32bit Yeah it's wierd/backwards, but it is source compatible. There is runtime magic to redirect from "system32" in 32 bit processes to syswow64. Though if folks used the very long standing APIs, this wouldn't have been needed. Oh well. There is also c:\program files and c:\program files (x86). I guess people are better about using the APIs here. "Introspection" is "broken" but this -- link -dump against c:\windows\system32 can get "redirected" but devtools aren't the priority and it does all generally work out, despite the hokiness. The registry is similarly doubled up and redirected, in some places at least, since it tends to give paths to .dlls -- a process is either 32bit or 64bit -- can't load one type .dll in other type process. On the devtools side, well, you know, NT always had ppc/mips/alpha/x86, so .libs are generally already in a directory named "i386" or "x86". In any case, folks don't hardcode paths as much, because they are already so variable. So you set up your environment or such using the %LIB% variable and it works easily. For running devtools, there is a separate set of .exes for each target. And sometimes for host. The matrix is filled out as necessary. AMD64 runs x86 fast so not always useful to fill out the matrix. Sometimes a slash is used, sometimes an underscore, sometimes "win64" inserted, but again, it's generally reasonable hidden behind a .bat file to set the environment and set $PATH and set the console's title (console == xterm, not the one special console). If you have more than one cl.exe or link.exe on your path, not good. cl.exe does more work than the gcc driver, it doesn't delegate out as much. There are no "fat" files like Apple does, well, not mechanized/systematic. Something like sysinternals handle.exe that has an embedded driver has a toplevel x86 file that runs on everything and then on demand extracts the AMD64 or IA64 executable and driver, runs the other version of itself, installs the driver on demand and voila.. ) - Jay From wagner at elegosoft.com Thu Apr 17 14:25:25 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 17 Apr 2008 14:25:25 +0200 Subject: [M3devel] new gcc build time In-Reply-To: References: <20080417084010.k3clt47rk8go4www@mail.elegosoft.com> Message-ID: <20080417142525.crce5s5s1wggk04c@mail.elegosoft.com> Quoting Jay : > I see this too. > I've been experimenting.. > --disable-bootstrap? > I don't know yet. I don't think we have ever done a full gcc bootstrap for cm3cg, have we? Is there any reason to do that now? If not, complete bootstrapping of gcc should be disabled again. Or we should make it an option depending on a variable setting like -DCOMPLETE_GCC_BOOTSTRAP or similar. Any other opinions? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Thu Apr 17 15:00:51 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 17 Apr 2008 13:00:51 +0000 Subject: [M3devel] new gcc build time In-Reply-To: <20080417142525.crce5s5s1wggk04c@mail.elegosoft.com> References: <20080417084010.k3clt47rk8go4www@mail.elegosoft.com> <20080417142525.crce5s5s1wggk04c@mail.elegosoft.com> Message-ID: I don't think so. I don't think so. I don't think so. :) I don't think we bootstrapped. I don't think there's much reason. I don't think it should even be an option. But I don't know. It should be faster. I think a reason to bootstrap would be if the system's C compiler can't compile gcc. That is, if it isn't gcc, or is an old gcc. Or maybe even that is false -- not sure what the requirements to build gcc are. Given that usually it is gcc and recent, seems like little reason. Maybe "SOLsun" would do it, for example. ?????? I'm still having trouble just making an x86 hosted x86 targeted build on AMD64, but I'm close. Something like CC="gcc -m32 -Xassembler --32" configure --target=i686-pc-linux-gnu --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu though I'm sure that's overkill to specify three architectures. I have to read the explanation of which is which. When there are only two, host and target make sense, is "build" the current one that is building the compiler, host is where it will run, target is what it will produce? I guess that's reasonable. So build could always be sniffed automatically and it might as well be native -- this compiler already must exist, or it is stage1 if bootstrapping from other than gcc. ? I guess stage1 is build a build-hosted host-targeted compiler, stage2 is host-hosted, target-targeted, what you actually want, stage3 is the same, and compare? Something like that? I should read up.. this doesn't seem like enough passes when building a cross-compiler, or just you have skip the "compare" when building a cross compiler? Later.. - Jay > Date: Thu, 17 Apr 2008 14:25:25 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] new gcc build time > > Quoting Jay : > > > I see this too. > > I've been experimenting.. > > --disable-bootstrap? > > I don't know yet. > > I don't think we have ever done a full gcc bootstrap for cm3cg, > have we? Is there any reason to do that now? > If not, complete bootstrapping of gcc should be disabled again. > Or we should make it an option depending on a variable setting > like -DCOMPLETE_GCC_BOOTSTRAP or similar. > > Any other opinions? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 jayk123 at hotmail.com Thu Apr 17 15:32:19 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 17 Apr 2008 13:32:19 +0000 Subject: [M3devel] biarch, multilib, etc? Message-ID: > And between host, target, and build, I find the names confusing. Ok I was the victim of an older less clear document. The current docs are clear and agreed with my guess. Host is the "future host", the machine that will run the compiler you are building. Target is the target of the compiler you are building. Build is the *Host* you are building the compiler on right now. The terminology I believe derives from the viewpoint that not many people build compilers. Host the machine are you developing on, running the compiler, editor. Target is the machine you are producing code for. "Build" is much less often seen, so its name isn't so clear. It is the host that builds the compiler. But not the host that, like, builds "the real code". Unless that real code, is, uh, the compiler (and linker). While "Build" should be reliably guessable from uname et. al., I think the docs warned against not specifying it if specifying others. You know, if I'm on AMD64, whether "build" is AMD64 or x86 has theoretically no bearing on the result, so I shouldn't care. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Apr 17 19:00:10 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 17 Apr 2008 13:00:10 -0400 Subject: [M3devel] new gcc build time In-Reply-To: References: <20080417084010.k3clt47rk8go4www@mail.elegosoft.com> <20080417142525.crce5s5s1wggk04c@mail.elegosoft.com> Message-ID: <09ABDD15-A087-4CD7-B2E1-C368A35E92A4@cs.purdue.edu> Some suggested flags for gcc configure to avoid full bootstrap: --enable-languages=m3cg --disable-multilib --enable-stage1-languages=m3cg --disable-bootstrap I haven't tried any of these, but some combination in m3cc/src/ m3makefile should have the intended effect. On Apr 17, 2008, at 9:00 AM, Jay wrote: > I don't think so. I don't think so. I don't think so. :) > I don't think we bootstrapped. I don't think there's much reason. I > don't think it should even be an option. > But I don't know. > It should be faster. > > I think a reason to bootstrap would be if the system's C compiler > can't compile gcc. > That is, if it isn't gcc, or is an old gcc. Or maybe even that is > false -- not sure what the requirements to build gcc are. > Given that usually it is gcc and recent, seems like little reason. > Maybe "SOLsun" would do it, for example. > ?????? > > I'm still having trouble just making an x86 hosted x86 targeted > build on AMD64, but I'm close. > Something like > CC="gcc -m32 -Xassembler --32" configure --target=i686-pc-linux-gnu > --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu > though I'm sure that's overkill to specify three architectures. I > have to read the explanation of which is which. > When there are only two, host and target make sense, is "build" the > current one that is building the compiler, host is where it will > run, target is what it will produce? I guess that's reasonable. So > build could always be sniffed automatically and it might as well be > native -- this compiler already must exist, or it is stage1 if > bootstrapping from other than gcc. ? I guess stage1 is build a build- > hosted host-targeted compiler, stage2 is host-hosted, target- > targeted, what you actually want, stage3 is the same, and compare? > Something like that? I should read up.. this doesn't seem like > enough passes when building a cross-compiler, or just you have skip > the "compare" when building a cross compiler? > > Later.. > - Jay > > > Date: Thu, 17 Apr 2008 14:25:25 +0200 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] new gcc build time > > > > Quoting Jay : > > > > > I see this too. > > > I've been experimenting.. > > > --disable-bootstrap? > > > I don't know yet. > > > > I don't think we have ever done a full gcc bootstrap for cm3cg, > > have we? Is there any reason to do that now? > > If not, complete bootstrapping of gcc should be disabled again. > > Or we should make it an option depending on a variable setting > > like -DCOMPLETE_GCC_BOOTSTRAP or similar. > > > > Any other opinions? > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Apr 17 19:03:41 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 17 Apr 2008 13:03:41 -0400 Subject: [M3devel] biarch, multilib, etc? In-Reply-To: References: Message-ID: <527623C3-BC62-4CF0-B338-068D149378C2@cs.purdue.edu> Check the latest version of m3-sys/cminstall/src/config/LINUXLIBC6. Notice that it now always uses -m32, --32 flags to the various compiler components (cm3cg, SYSTEM_CC, SYSTEM_AS). This forces use of the x86 variants. An AMD64_LINUX port will have an almost identical configuration file that forces use of the x86_64 toolchain. 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 Apr 17, 2008, at 8:03 AM, Jay wrote: > > Can anyone explain how Linux and gcc are managing that AMD64 systems > can run > and presumably build x86 code? > > > I know there is /lib32 and /lib64. > I know there is gcc -m32 and gcc -m64. > I know that gcc itself delegates out to target specific executables, > so one gcc plus flags suffices, > it's those other executables that multiply out. That ld has the -m > flag. That as has --32 and --64. > I don't know how much stuff goes through gcc, vs. needs the get the > as/ld flags correct. > I'm not talking about Modula-3 here, but, like of building gcc and > its dependencies. > I can deal with the smaller Modula-3 system contained in far more > readable Quake code than all the "sh" > and layers upon layers of makefiles and autoconf and sh and m4 etc.. > > > ./configure on various things tend to build just AMD64. > > > It appears in general that for any > apt-get install foo > you can often but not always > apt-get install foo-i386 > > > This is on KUbuntu 8.4 Hardy Heron KDE4 beta AMD64 (mouthful!) > > > It looks like in general: > CC="gcc -m32" .../configure --prefix=/usr --libdir=/usr/lib32 -- > build=i686-pc-linux-gnu > > > is what you want, but that many packages are only native. > in particular gmp and mpfr: > apt-get install mpfr-i386 > => no luck > > > Maybe these are not considered "mainstream"? > > > I'll build them myself, something like: > > cd /usr/src > apt-get source mpfr > mkdir -p obj/mpfr > cd obj/mpfr > CC="gcc -m32" /usr/src/mpfr-2.3.1.dfsg.1/configure --prefix=/usr -- > libdir=/usr/lib32 --build=i686-pc-linux-gnu > make > sudo make install > > > cd /usr/src > apt-get source libgmp3-dev > mkdir -p /usr/src/obj/gmp > cd /usr/src/obj/obj > CC="gcc -m32" /usr/src/gmp-4.2.2+dfsg/configure --prefix=/usr -- > libdir=/usr/lib32 --build=i686-pc-linux-gnu > make > sudo make install > > You know, I just want building the Modula-3 system on AMD64_LINUX to > at first merely build > an x86 hosted, x86 targeted binary. And then start changing things. > > > And between host, target, and build, I find the names confusing. > I understand why there are three -- the current system to build the > compiler, a system to run the > compiler, a system to run the compiler's output, but these names > host, target, build, aren't very > mnemonic with me yet. Is it build=now, host=runs the compier, > target=runs the compiler's output? > I'll dig around. > > I know, I can figure it all out, there's the www to search, but this > biarch/multilib is hard > to find the docs for..and I can't read the masses of m4/sh/gmake.. > > ps: it's easy to get the ld to crash when doing this stuff wrong.. > > (I can explain how Windows does it, fyi. > 1) The system is "doubled up", generally .dlls and .exes, but not > kernel and drivers > c:\windows\system32 is native > c:\windows\syswow64 is 32bit > Yeah it's wierd/backwards, but it is source compatible. > There is runtime magic to redirect from "system32" in 32 bit > processes to syswow64. > Though if folks used the very long standing APIs, this wouldn't have > been needed. Oh well. > There is also c:\program files and c:\program files (x86). I guess > people are better about using the APIs here. > "Introspection" is "broken" but this -- link -dump against c:\windows > \system32 can get "redirected" but devtools aren't the priority and > it does all generally work out, despite the hokiness. > The registry is similarly doubled up and redirected, in some places > at least, since it tends to give paths to .dlls -- a process is > either 32bit or 64bit -- can't load one type .dll in other type > process. > > On the devtools side, well, you know, NT always had ppc/mips/alpha/ > x86, so .libs are generally already in a directory named "i386" or > "x86". > In any case, folks don't hardcode paths as much, because they are > already so variable. > So you set up your environment or such using the %LIB% variable and > it works easily. > > For running devtools, there is a separate set of .exes for each > target. > And sometimes for host. > The matrix is filled out as necessary. > AMD64 runs x86 fast so not always useful to fill out the matrix. > Sometimes a slash is used, sometimes an underscore, sometimes > "win64" inserted, but again, it's generally reasonable hidden behind > a .bat file to set the environment and set $PATH and set the > console's title (console == xterm, not the one special console). > > If you have more than one cl.exe or link.exe on your path, not good. > cl.exe does more work than the gcc driver, it doesn't delegate out > as much. > > There are no "fat" files like Apple does, well, not mechanized/ > systematic. > Something like sysinternals handle.exe that has an embedded driver > has a toplevel x86 file that runs on everything and then on demand > extracts the AMD64 or IA64 executable and driver, runs the other > version of itself, installs the driver on demand and voila.. > ) > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Apr 18 03:13:17 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Apr 2008 01:13:17 +0000 Subject: [M3devel] biarch, multilib, etc? In-Reply-To: <527623C3-BC62-4CF0-B338-068D149378C2@cs.purdue.edu> References: <527623C3-BC62-4CF0-B338-068D149378C2@cs.purdue.edu> Message-ID: What I want to start is an x86 hosted x86 targeted cm3cg to (build and) run on my AMD64 system, just to get where we already are. I have this: jay at jayx2:~/dev2/cm3/m3-sys/m3cc$ ldd LINUXLIBC6.1/cm3cg linux-vdso.so.1 => (0x00007fffe21fe000) libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00007f3fd9c8a000) libc.so.6 => /lib/libc.so.6 (0x00007f3fd9928000) /lib64/ld-linux-x86-64.so.2 (0x00007f3fd9ec9000) which I think got via straightforward methods and which I think is not what I want -- it won't run on other people's x86 system. Once I get that working, x86 hosted AMD64 target would be good, or AMD64 hosted, AMD64 targeted if I must. That is, tools can "just" be x86 hosted and work ok, enabling fewer tools that run one more hosts to target more targets. You know, I just want gcc to pretend to ignore all the AMD64 stuff, at least to start. There are a variety of promising methods but stuff keeps failing somewhere or another. stuff like CC="gcc -m32" etc. e.g.: collect2: ld terminated with signal 11 [Segmentation fault], core dumped /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a(hashtab.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a(xmalloc.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a(xstrdup.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a(xexit.o)' is incompatible with i386 output - Jay ________________________________ CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jayk123 at hotmail.com Subject: Re: [M3devel] biarch, multilib, etc? Date: Thu, 17 Apr 2008 13:03:41 -0400 Check the latest version of m3-sys/cminstall/src/config/LINUXLIBC6. Notice that it now always uses -m32, --32 flags to the various compiler components (cm3cg, SYSTEM_CC, SYSTEM_AS). This forces use of the x86 variants. An AMD64_LINUX port will have an almost identical configuration file that forces use of the x86_64 toolchain. 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 Apr 17, 2008, at 8:03 AM, Jay wrote: Can anyone explain how Linux and gcc are managing that AMD64 systems can run and presumably build x86 code? I know there is /lib32 and /lib64. I know there is gcc -m32 and gcc -m64. I know that gcc itself delegates out to target specific executables, so one gcc plus flags suffices, it's those other executables that multiply out. That ld has the -m flag. That as has --32 and --64. I don't know how much stuff goes through gcc, vs. needs the get the as/ld flags correct. I'm not talking about Modula-3 here, but, like of building gcc and its dependencies. I can deal with the smaller Modula-3 system contained in far more readable Quake code than all the "sh" and layers upon layers of makefiles and autoconf and sh and m4 etc.. ./configure on various things tend to build just AMD64. It appears in general that for any apt-get install foo you can often but not always apt-get install foo-i386 This is on KUbuntu 8.4 Hardy Heron KDE4 beta AMD64 (mouthful!) It looks like in general: CC="gcc -m32" .../configure --prefix=/usr --libdir=/usr/lib32 --build=i686-pc-linux-gnu is what you want, but that many packages are only native. in particular gmp and mpfr: apt-get install mpfr-i386 => no luck Maybe these are not considered "mainstream"? I'll build them myself, something like: cd /usr/src apt-get source mpfr mkdir -p obj/mpfr cd obj/mpfr CC="gcc -m32" /usr/src/mpfr-2.3.1.dfsg.1/configure --prefix=/usr --libdir=/usr/lib32 --build=i686-pc-linux-gnu make sudo make install cd /usr/src apt-get source libgmp3-dev mkdir -p /usr/src/obj/gmp cd /usr/src/obj/obj CC="gcc -m32" /usr/src/gmp-4.2.2+dfsg/configure --prefix=/usr --libdir=/usr/lib32 --build=i686-pc-linux-gnu make sudo make install You know, I just want building the Modula-3 system on AMD64_LINUX to at first merely build an x86 hosted, x86 targeted binary. And then start changing things. And between host, target, and build, I find the names confusing. I understand why there are three -- the current system to build the compiler, a system to run the compiler, a system to run the compiler's output, but these names host, target, build, aren't very mnemonic with me yet. Is it build=now, host=runs the compier, target=runs the compiler's output? I'll dig around. I know, I can figure it all out, there's the www to search, but this biarch/multilib is hard to find the docs for..and I can't read the masses of m4/sh/gmake.. ps: it's easy to get the ld to crash when doing this stuff wrong.. (I can explain how Windows does it, fyi. 1) The system is "doubled up", generally .dlls and .exes, but not kernel and drivers c:\windows\system32 is native c:\windows\syswow64 is 32bit Yeah it's wierd/backwards, but it is source compatible. There is runtime magic to redirect from "system32" in 32 bit processes to syswow64. Though if folks used the very long standing APIs, this wouldn't have been needed. Oh well. There is also c:\program files and c:\program files (x86). I guess people are better about using the APIs here. "Introspection" is "broken" but this -- link -dump against c:\windows\system32 can get "redirected" but devtools aren't the priority and it does all generally work out, despite the hokiness. The registry is similarly doubled up and redirected, in some places at least, since it tends to give paths to .dlls -- a process is either 32bit or 64bit -- can't load one type .dll in other type process. On the devtools side, well, you know, NT always had ppc/mips/alpha/x86, so .libs are generally already in a directory named "i386" or "x86". In any case, folks don't hardcode paths as much, because they are already so variable. So you set up your environment or such using the %LIB% variable and it works easily. For running devtools, there is a separate set of .exes for each target. And sometimes for host. The matrix is filled out as necessary. AMD64 runs x86 fast so not always useful to fill out the matrix. Sometimes a slash is used, sometimes an underscore, sometimes "win64" inserted, but again, it's generally reasonable hidden behind a .bat file to set the environment and set $PATH and set the console's title (console == xterm, not the one special console). If you have more than one cl.exe or link.exe on your path, not good. cl.exe does more work than the gcc driver, it doesn't delegate out as much. There are no "fat" files like Apple does, well, not mechanized/systematic. Something like sysinternals handle.exe that has an embedded driver has a toplevel x86 file that runs on everything and then on demand extracts the AMD64 or IA64 executable and driver, runs the other version of itself, installs the driver on demand and voila.. ) - Jay From hosking at cs.purdue.edu Fri Apr 18 04:02:16 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 17 Apr 2008 22:02:16 -0400 Subject: [M3devel] biarch, multilib, etc? In-Reply-To: References: <527623C3-BC62-4CF0-B338-068D149378C2@cs.purdue.edu> Message-ID: Have you tried the following: cd cm3/m3-sys/m3cc mkdir build cd build ../gcc/configure --enable-languages=m3cg make This works for me on Mac OS X and builds a bi-arch version of m3cg that will accept both -m32 and -m64 flags to target x86_32 and x86_64. Admittedly, it does go through the full bootstrap, which is probably overkill. I haven't had a chance to try AMD64_LINUX yet, but I assume it will behave much the same in building a bi-arch compiler. On Apr 17, 2008, at 9:13 PM, Jay wrote: > > What I want to start is an x86 hosted x86 targeted cm3cg to (build > and) run on my AMD64 system, just to get where we already are. > > I have this: > > jay at jayx2:~/dev2/cm3/m3-sys/m3cc$ ldd LINUXLIBC6.1/cm3cg > linux-vdso.so.1 => (0x00007fffe21fe000) > libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00007f3fd9c8a000) > libc.so.6 => /lib/libc.so.6 (0x00007f3fd9928000) > /lib64/ld-linux-x86-64.so.2 (0x00007f3fd9ec9000) > > > which I think got via straightforward methods and which I think is > not what I want -- it won't run on other people's x86 system. > > Once I get that working, x86 hosted AMD64 target would be good, or > AMD64 hosted, AMD64 targeted if I must. > That is, tools can "just" be x86 hosted and work ok, enabling fewer > tools that run one more hosts to target more targets. > > You know, I just want gcc to pretend to ignore all the AMD64 stuff, > at least to start. > There are a variety of promising methods but stuff keeps failing > somewhere or another. > stuff like CC="gcc -m32" etc. > > e.g.: > collect2: ld terminated with signal 11 [Segmentation fault], core > dumped > /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- > unknown-linux-gnu/libiberty/libiberty.a(hashtab.o)' is incompatible > with i386 output > /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- > unknown-linux-gnu/libiberty/libiberty.a(xmalloc.o)' is incompatible > with i386 output > /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- > unknown-linux-gnu/libiberty/libiberty.a(xstrdup.o)' is incompatible > with i386 output > /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- > unknown-linux-gnu/libiberty/libiberty.a(xexit.o)' is incompatible > with i386 output > > - Jay > > ________________________________ > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jayk123 at hotmail.com > Subject: Re: [M3devel] biarch, multilib, etc? > Date: Thu, 17 Apr 2008 13:03:41 -0400 > > Check the latest version of m3-sys/cminstall/src/config/LINUXLIBC6. > Notice that it now always uses -m32, --32 flags to the various > compiler components (cm3cg, SYSTEM_CC, SYSTEM_AS). This forces use > of the x86 variants. An AMD64_LINUX port will have an almost > identical configuration file that forces use of the x86_64 toolchain. > > 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 Apr 17, 2008, at 8:03 AM, Jay wrote: > > Can anyone explain how Linux and gcc are managing that AMD64 systems > can run > and presumably build x86 code? > > > I know there is /lib32 and /lib64. > I know there is gcc -m32 and gcc -m64. > I know that gcc itself delegates out to target specific executables, > so one gcc plus flags suffices, > it's those other executables that multiply out. That ld has the -m > flag. That as has --32 and --64. > I don't know how much stuff goes through gcc, vs. needs the get the > as/ld flags correct. > I'm not talking about Modula-3 here, but, like of building gcc and > its dependencies. > I can deal with the smaller Modula-3 system contained in far more > readable Quake code than all the "sh" > and layers upon layers of makefiles and autoconf and sh and m4 etc.. > > > ./configure on various things tend to build just AMD64. > > > It appears in general that for any > apt-get install foo > you can often but not always > apt-get install foo-i386 > > > This is on KUbuntu 8.4 Hardy Heron KDE4 beta AMD64 (mouthful!) > > > It looks like in general: > CC="gcc -m32" .../configure --prefix=/usr --libdir=/usr/lib32 -- > build=i686-pc-linux-gnu > > > is what you want, but that many packages are only native. > in particular gmp and mpfr: > apt-get install mpfr-i386 > => no luck > > > Maybe these are not considered "mainstream"? > > > I'll build them myself, something like: > > cd /usr/src > apt-get source mpfr > mkdir -p obj/mpfr > cd obj/mpfr > CC="gcc -m32" /usr/src/mpfr-2.3.1.dfsg.1/configure --prefix=/usr -- > libdir=/usr/lib32 --build=i686-pc-linux-gnu > make > sudo make install > > > cd /usr/src > apt-get source libgmp3-dev > mkdir -p /usr/src/obj/gmp > cd /usr/src/obj/obj > CC="gcc -m32" /usr/src/gmp-4.2.2+dfsg/configure --prefix=/usr -- > libdir=/usr/lib32 --build=i686-pc-linux-gnu > make > sudo make install > > You know, I just want building the Modula-3 system on AMD64_LINUX to > at first merely build > an x86 hosted, x86 targeted binary. And then start changing things. > > > And between host, target, and build, I find the names confusing. > I understand why there are three -- the current system to build the > compiler, a system to run the > compiler, a system to run the compiler's output, but these names > host, target, build, aren't very > mnemonic with me yet. Is it build=now, host=runs the compier, > target=runs the compiler's output? > I'll dig around. > > I know, I can figure it all out, there's the www to search, but this > biarch/multilib is hard > to find the docs for..and I can't read the masses of m4/sh/gmake.. > > ps: it's easy to get the ld to crash when doing this stuff wrong.. > > (I can explain how Windows does it, fyi. > 1) The system is "doubled up", generally .dlls and .exes, but not > kernel and drivers > c:\windows\system32 is native > c:\windows\syswow64 is 32bit > Yeah it's wierd/backwards, but it is source compatible. > There is runtime magic to redirect from "system32" in 32 bit > processes to syswow64. > Though if folks used the very long standing APIs, this wouldn't have > been needed. Oh well. > There is also c:\program files and c:\program files (x86). I guess > people are better about using the APIs here. > "Introspection" is "broken" but this -- link -dump against c:\windows > \system32 can get "redirected" but devtools aren't the priority and > it does all generally work out, despite the hokiness. > The registry is similarly doubled up and redirected, in some places > at least, since it tends to give paths to .dlls -- a process is > either 32bit or 64bit -- can't load one type .dll in other type > process. > > On the devtools side, well, you know, NT always had ppc/mips/alpha/ > x86, so .libs are generally already in a directory named "i386" or > "x86". > In any case, folks don't hardcode paths as much, because they are > already so variable. > So you set up your environment or such using the %LIB% variable and > it works easily. > > For running devtools, there is a separate set of .exes for each > target. > And sometimes for host. > The matrix is filled out as necessary. > AMD64 runs x86 fast so not always useful to fill out the matrix. > Sometimes a slash is used, sometimes an underscore, sometimes > "win64" inserted, but again, it's generally reasonable hidden behind > a .bat file to set the environment and set $PATH and set the > console's title (console == xterm, not the one special console). > > If you have more than one cl.exe or link.exe on your path, not good. > cl.exe does more work than the gcc driver, it doesn't delegate out > as much. > > There are no "fat" files like Apple does, well, not mechanized/ > systematic. > Something like sysinternals handle.exe that has an embedded driver > has a toplevel x86 file that runs on everything and then on demand > extracts the AMD64 or IA64 executable and driver, runs the other > version of itself, installs the driver on demand and voila.. > ) > > - Jay > From jayk123 at hotmail.com Fri Apr 18 06:00:27 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Apr 2008 04:00:27 +0000 Subject: [M3devel] biarch, multilib, etc? In-Reply-To: References: <527623C3-BC62-4CF0-B338-068D149378C2@cs.purdue.edu> Message-ID: Kinda sorta but not quite. I am now trying without --disable-bootstrap and --disable-multilib for non-native builds. I'll see how that goes. I understand the niceness of a multarch toolset. I also would like an option for that toolset to be x86 hosted instead of AMD64 hosted, but I'll take either at this point. It still likes to look for i686-pc-linux-gnu-ar and ld and such, rather than just using the existing biarch tools. Epiphany: There are the following platforms: build -- what is building the compiler host -- what the compiler will run on target -- what the compiler's output will run on However each one is potentially biarch or multiarch. (multiarch -- Mac OS X AMD64 machines can run 32 bit PowerPC, 32 bit x86, and AMD64 -- triarch). I understand in the general simple case, gcc -m32 is all it takes, but I don't trust that to suffice for building gcc, since there is at least one more architecture involved and there are a bunch of suspiciously relevant sounding configurable knobs, not just CC and CFLAGS, but AS_FOR_TARGET, GCC_FOR_TARGET, etc., but there aren't FOO_FOR_BUILD, FOO_FOR_HOST, FOO_FOR_TARGET; I guess plain FOO is FOO_FOR_BUILD. I'll keep poking.. - Jay > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jayk123 at hotmail.com > Subject: Re: [M3devel] biarch, multilib, etc? > Date: Thu, 17 Apr 2008 22:02:16 -0400 > > Have you tried the following: > > cd cm3/m3-sys/m3cc > mkdir build > cd build > ../gcc/configure --enable-languages=m3cg > make > > This works for me on Mac OS X and builds a bi-arch version of m3cg > that will accept both -m32 and -m64 flags to target x86_32 and x86_64. > > Admittedly, it does go through the full bootstrap, which is probably > overkill. > > I haven't had a chance to try AMD64_LINUX yet, but I assume it will > behave much the same in building a bi-arch compiler. > > On Apr 17, 2008, at 9:13 PM, Jay wrote: > > > > > What I want to start is an x86 hosted x86 targeted cm3cg to (build > > and) run on my AMD64 system, just to get where we already are. > > > > I have this: > > > > jay at jayx2:~/dev2/cm3/m3-sys/m3cc$ ldd LINUXLIBC6.1/cm3cg > > linux-vdso.so.1 => (0x00007fffe21fe000) > > libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00007f3fd9c8a000) > > libc.so.6 => /lib/libc.so.6 (0x00007f3fd9928000) > > /lib64/ld-linux-x86-64.so.2 (0x00007f3fd9ec9000) > > > > > > which I think got via straightforward methods and which I think is > > not what I want -- it won't run on other people's x86 system. > > > > Once I get that working, x86 hosted AMD64 target would be good, or > > AMD64 hosted, AMD64 targeted if I must. > > That is, tools can "just" be x86 hosted and work ok, enabling fewer > > tools that run one more hosts to target more targets. > > > > You know, I just want gcc to pretend to ignore all the AMD64 stuff, > > at least to start. > > There are a variety of promising methods but stuff keeps failing > > somewhere or another. > > stuff like CC="gcc -m32" etc. > > > > e.g.: > > collect2: ld terminated with signal 11 [Segmentation fault], core > > dumped > > /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- > > unknown-linux-gnu/libiberty/libiberty.a(hashtab.o)' is incompatible > > with i386 output > > /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- > > unknown-linux-gnu/libiberty/libiberty.a(xmalloc.o)' is incompatible > > with i386 output > > /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- > > unknown-linux-gnu/libiberty/libiberty.a(xstrdup.o)' is incompatible > > with i386 output > > /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- > > unknown-linux-gnu/libiberty/libiberty.a(xexit.o)' is incompatible > > with i386 output > > > > - Jay > > > > ________________________________ > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > To: jayk123 at hotmail.com > > Subject: Re: [M3devel] biarch, multilib, etc? > > Date: Thu, 17 Apr 2008 13:03:41 -0400 > > > > Check the latest version of m3-sys/cminstall/src/config/LINUXLIBC6. > > Notice that it now always uses -m32, --32 flags to the various > > compiler components (cm3cg, SYSTEM_CC, SYSTEM_AS). This forces use > > of the x86 variants. An AMD64_LINUX port will have an almost > > identical configuration file that forces use of the x86_64 toolchain. > > > > 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 Apr 17, 2008, at 8:03 AM, Jay wrote: > > > > Can anyone explain how Linux and gcc are managing that AMD64 systems > > can run > > and presumably build x86 code? > > > > > > I know there is /lib32 and /lib64. > > I know there is gcc -m32 and gcc -m64. > > I know that gcc itself delegates out to target specific executables, > > so one gcc plus flags suffices, > > it's those other executables that multiply out. That ld has the -m > > flag. That as has --32 and --64. > > I don't know how much stuff goes through gcc, vs. needs the get the > > as/ld flags correct. > > I'm not talking about Modula-3 here, but, like of building gcc and > > its dependencies. > > I can deal with the smaller Modula-3 system contained in far more > > readable Quake code than all the "sh" > > and layers upon layers of makefiles and autoconf and sh and m4 etc.. > > > > > > ./configure on various things tend to build just AMD64. > > > > > > It appears in general that for any > > apt-get install foo > > you can often but not always > > apt-get install foo-i386 > > > > > > This is on KUbuntu 8.4 Hardy Heron KDE4 beta AMD64 (mouthful!) > > > > > > It looks like in general: > > CC="gcc -m32" .../configure --prefix=/usr --libdir=/usr/lib32 -- > > build=i686-pc-linux-gnu > > > > > > is what you want, but that many packages are only native. > > in particular gmp and mpfr: > > apt-get install mpfr-i386 > > => no luck > > > > > > Maybe these are not considered "mainstream"? > > > > > > I'll build them myself, something like: > > > > cd /usr/src > > apt-get source mpfr > > mkdir -p obj/mpfr > > cd obj/mpfr > > CC="gcc -m32" /usr/src/mpfr-2.3.1.dfsg.1/configure --prefix=/usr -- > > libdir=/usr/lib32 --build=i686-pc-linux-gnu > > make > > sudo make install > > > > > > cd /usr/src > > apt-get source libgmp3-dev > > mkdir -p /usr/src/obj/gmp > > cd /usr/src/obj/obj > > CC="gcc -m32" /usr/src/gmp-4.2.2+dfsg/configure --prefix=/usr -- > > libdir=/usr/lib32 --build=i686-pc-linux-gnu > > make > > sudo make install > > > > You know, I just want building the Modula-3 system on AMD64_LINUX to > > at first merely build > > an x86 hosted, x86 targeted binary. And then start changing things. > > > > > > And between host, target, and build, I find the names confusing. > > I understand why there are three -- the current system to build the > > compiler, a system to run the > > compiler, a system to run the compiler's output, but these names > > host, target, build, aren't very > > mnemonic with me yet. Is it build=now, host=runs the compier, > > target=runs the compiler's output? > > I'll dig around. > > > > I know, I can figure it all out, there's the www to search, but this > > biarch/multilib is hard > > to find the docs for..and I can't read the masses of m4/sh/gmake.. > > > > ps: it's easy to get the ld to crash when doing this stuff wrong.. > > > > (I can explain how Windows does it, fyi. > > 1) The system is "doubled up", generally .dlls and .exes, but not > > kernel and drivers > > c:\windows\system32 is native > > c:\windows\syswow64 is 32bit > > Yeah it's wierd/backwards, but it is source compatible. > > There is runtime magic to redirect from "system32" in 32 bit > > processes to syswow64. > > Though if folks used the very long standing APIs, this wouldn't have > > been needed. Oh well. > > There is also c:\program files and c:\program files (x86). I guess > > people are better about using the APIs here. > > "Introspection" is "broken" but this -- link -dump against c:\windows > > \system32 can get "redirected" but devtools aren't the priority and > > it does all generally work out, despite the hokiness. > > The registry is similarly doubled up and redirected, in some places > > at least, since it tends to give paths to .dlls -- a process is > > either 32bit or 64bit -- can't load one type .dll in other type > > process. > > > > On the devtools side, well, you know, NT always had ppc/mips/alpha/ > > x86, so .libs are generally already in a directory named "i386" or > > "x86". > > In any case, folks don't hardcode paths as much, because they are > > already so variable. > > So you set up your environment or such using the %LIB% variable and > > it works easily. > > > > For running devtools, there is a separate set of .exes for each > > target. > > And sometimes for host. > > The matrix is filled out as necessary. > > AMD64 runs x86 fast so not always useful to fill out the matrix. > > Sometimes a slash is used, sometimes an underscore, sometimes > > "win64" inserted, but again, it's generally reasonable hidden behind > > a .bat file to set the environment and set $PATH and set the > > console's title (console == xterm, not the one special console). > > > > If you have more than one cl.exe or link.exe on your path, not good. > > cl.exe does more work than the gcc driver, it doesn't delegate out > > as much. > > > > There are no "fat" files like Apple does, well, not mechanized/ > > systematic. > > Something like sysinternals handle.exe that has an embedded driver > > has a toplevel x86 file that runs on everything and then on demand > > extracts the AMD64 or IA64 executable and driver, runs the other > > version of itself, installs the driver on demand and voila.. > > ) > > > > - Jay > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Apr 18 06:44:57 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 18 Apr 2008 00:44:57 -0400 Subject: [M3devel] biarch, multilib, etc? In-Reply-To: References: <527623C3-BC62-4CF0-B338-068D149378C2@cs.purdue.edu> Message-ID: 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 Apr 18, 2008, at 12:00 AM, Jay wrote: > Kinda sorta but not quite. > I am now trying without --disable-bootstrap and --disable-multilib > for non-native builds. I'll see how that goes. > I understand the niceness of a multarch toolset. > > I also would like an option for that toolset to be x86 hosted > instead of AMD64 hosted, but I'll take either at this point. > It still likes to look for i686-pc-linux-gnu-ar and ld and such, > rather than just using the existing biarch tools. Who? When building gcc? My build of cm3cg on OS X appears to be x86 hosted. cm3cg does not need to look for any tools... > Epiphany: > There are the following platforms: > build -- what is building the compiler > host -- what the compiler will run on > target -- what the compiler's output will run on > > However each one is potentially biarch or multiarch. > (multiarch -- Mac OS X AMD64 machines can run 32 bit PowerPC, 32 bit > x86, and AMD64 -- triarch). I build gcc without any special setup other than described above. I host on whatever that build turns out to be. I target using -m32/-m64. > I understand in the general simple case, gcc -m32 is all it takes, > but I don't trust that to suffice for building gcc, since there is > at least one more architecture involved and there are a bunch of > suspiciously relevant sounding configurable knobs, not just CC and > CFLAGS, but AS_FOR_TARGET, GCC_FOR_TARGET, etc., but there aren't > FOO_FOR_BUILD, FOO_FOR_HOST, FOO_FOR_TARGET; I guess plain FOO is > FOO_FOR_BUILD. I don't specify -m32 or -m64 to build gcc itself. It automatically builds a biarch compiler. > I'll keep poking.. > > - Jay > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > To: jayk123 at hotmail.com > > Subject: Re: [M3devel] biarch, multilib, etc? > > Date: Thu, 17 Apr 2008 22:02:16 -0400 > > > > Have you tried the following: > > > > cd cm3/m3-sys/m3cc > > mkdir build > > cd build > > ../gcc/configure --enable-languages=m3cg > > make > > > > This works for me on Mac OS X and builds a bi-arch version of m3cg > > that will accept both -m32 and -m64 flags to target x86_32 and > x86_64. > > > > Admittedly, it does go through the full bootstrap, which is probably > > overkill. > > > > I haven't had a chance to try AMD64_LINUX yet, but I assume it will > > behave much the same in building a bi-arch compiler. > > > > On Apr 17, 2008, at 9:13 PM, Jay wrote: > > > > > > > > What I want to start is an x86 hosted x86 targeted cm3cg to (build > > > and) run on my AMD64 system, just to get where we already are. > > > > > > I have this: > > > > > > jay at jayx2:~/dev2/cm3/m3-sys/m3cc$ ldd LINUXLIBC6.1/cm3cg > > > linux-vdso.so.1 => (0x00007fffe21fe000) > > > libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00007f3fd9c8a000) > > > libc.so.6 => /lib/libc.so.6 (0x00007f3fd9928000) > > > /lib64/ld-linux-x86-64.so.2 (0x00007f3fd9ec9000) > > > > > > > > > which I think got via straightforward methods and which I think is > > > not what I want -- it won't run on other people's x86 system. > > > > > > Once I get that working, x86 hosted AMD64 target would be good, or > > > AMD64 hosted, AMD64 targeted if I must. > > > That is, tools can "just" be x86 hosted and work ok, enabling > fewer > > > tools that run one more hosts to target more targets. > > > > > > You know, I just want gcc to pretend to ignore all the AMD64 > stuff, > > > at least to start. > > > There are a variety of promising methods but stuff keeps failing > > > somewhere or another. > > > stuff like CC="gcc -m32" etc. > > > > > > e.g.: > > > collect2: ld terminated with signal 11 [Segmentation fault], core > > > dumped > > > /usr/bin/ld: i386:x86-64 architecture of input file `../build- > x86_64- > > > unknown-linux-gnu/libiberty/libiberty.a(hashtab.o)' is > incompatible > > > with i386 output > > > /usr/bin/ld: i386:x86-64 architecture of input file `../build- > x86_64- > > > unknown-linux-gnu/libiberty/libiberty.a(xmalloc.o)' is > incompatible > > > with i386 output > > > /usr/bin/ld: i386:x86-64 architecture of input file `../build- > x86_64- > > > unknown-linux-gnu/libiberty/libiberty.a(xstrdup.o)' is > incompatible > > > with i386 output > > > /usr/bin/ld: i386:x86-64 architecture of input file `../build- > x86_64- > > > unknown-linux-gnu/libiberty/libiberty.a(xexit.o)' is incompatible > > > with i386 output > > > > > > - Jay > > > > > > ________________________________ > > > CC: m3devel at elegosoft.com > > > From: hosking at cs.purdue.edu > > > To: jayk123 at hotmail.com > > > Subject: Re: [M3devel] biarch, multilib, etc? > > > Date: Thu, 17 Apr 2008 13:03:41 -0400 > > > > > > Check the latest version of m3-sys/cminstall/src/config/ > LINUXLIBC6. > > > Notice that it now always uses -m32, --32 flags to the various > > > compiler components (cm3cg, SYSTEM_CC, SYSTEM_AS). This forces use > > > of the x86 variants. An AMD64_LINUX port will have an almost > > > identical configuration file that forces use of the x86_64 > toolchain. > > > > > > 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 Apr 17, 2008, at 8:03 AM, Jay wrote: > > > > > > Can anyone explain how Linux and gcc are managing that AMD64 > systems > > > can run > > > and presumably build x86 code? > > > > > > > > > I know there is /lib32 and /lib64. > > > I know there is gcc -m32 and gcc -m64. > > > I know that gcc itself delegates out to target specific > executables, > > > so one gcc plus flags suffices, > > > it's those other executables that multiply out. That ld has the -m > > > flag. That as has --32 and --64. > > > I don't know how much stuff goes through gcc, vs. needs the get > the > > > as/ld flags correct. > > > I'm not talking about Modula-3 here, but, like of building gcc and > > > its dependencies. > > > I can deal with the smaller Modula-3 system contained in far more > > > readable Quake code than all the "sh" > > > and layers upon layers of makefiles and autoconf and sh and m4 > etc.. > > > > > > > > > ./configure on various things tend to build just AMD64. > > > > > > > > > It appears in general that for any > > > apt-get install foo > > > you can often but not always > > > apt-get install foo-i386 > > > > > > > > > This is on KUbuntu 8.4 Hardy Heron KDE4 beta AMD64 (mouthful!) > > > > > > > > > It looks like in general: > > > CC="gcc -m32" .../configure --prefix=/usr --libdir=/usr/lib32 -- > > > build=i686-pc-linux-gnu > > > > > > > > > is what you want, but that many packages are only native. > > > in particular gmp and mpfr: > > > apt-get install mpfr-i386 > > > => no luck > > > > > > > > > Maybe these are not considered "mainstream"? > > > > > > > > > I'll build them myself, something like: > > > > > > cd /usr/src > > > apt-get source mpfr > > > mkdir -p obj/mpfr > > > cd obj/mpfr > > > CC="gcc -m32" /usr/src/mpfr-2.3.1.dfsg.1/configure --prefix=/usr > -- > > > libdir=/usr/lib32 --build=i686-pc-linux-gnu > > > make > > > sudo make install > > > > > > > > > cd /usr/src > > > apt-get source libgmp3-dev > > > mkdir -p /usr/src/obj/gmp > > > cd /usr/src/obj/obj > > > CC="gcc -m32" /usr/src/gmp-4.2.2+dfsg/configure --prefix=/usr -- > > > libdir=/usr/lib32 --build=i686-pc-linux-gnu > > > make > > > sudo make install > > > > > > You know, I just want building the Modula-3 system on > AMD64_LINUX to > > > at first merely build > > > an x86 hosted, x86 targeted binary. And then start changing > things. > > > > > > > > > And between host, target, and build, I find the names confusing. > > > I understand why there are three -- the current system to build > the > > > compiler, a system to run the > > > compiler, a system to run the compiler's output, but these names > > > host, target, build, aren't very > > > mnemonic with me yet. Is it build=now, host=runs the compier, > > > target=runs the compiler's output? > > > I'll dig around. > > > > > > I know, I can figure it all out, there's the www to search, but > this > > > biarch/multilib is hard > > > to find the docs for..and I can't read the masses of m4/sh/gmake.. > > > > > > ps: it's easy to get the ld to crash when doing this stuff wrong.. > > > > > > (I can explain how Windows does it, fyi. > > > 1) The system is "doubled up", generally .dlls and .exes, but not > > > kernel and drivers > > > c:\windows\system32 is native > > > c:\windows\syswow64 is 32bit > > > Yeah it's wierd/backwards, but it is source compatible. > > > There is runtime magic to redirect from "system32" in 32 bit > > > processes to syswow64. > > > Though if folks used the very long standing APIs, this wouldn't > have > > > been needed. Oh well. > > > There is also c:\program files and c:\program files (x86). I guess > > > people are better about using the APIs here. > > > "Introspection" is "broken" but this -- link -dump against c: > \windows > > > \system32 can get "redirected" but devtools aren't the priority > and > > > it does all generally work out, despite the hokiness. > > > The registry is similarly doubled up and redirected, in some > places > > > at least, since it tends to give paths to .dlls -- a process is > > > either 32bit or 64bit -- can't load one type .dll in other type > > > process. > > > > > > On the devtools side, well, you know, NT always had ppc/mips/ > alpha/ > > > x86, so .libs are generally already in a directory named "i386" or > > > "x86". > > > In any case, folks don't hardcode paths as much, because they are > > > already so variable. > > > So you set up your environment or such using the %LIB% variable > and > > > it works easily. > > > > > > For running devtools, there is a separate set of .exes for each > > > target. > > > And sometimes for host. > > > The matrix is filled out as necessary. > > > AMD64 runs x86 fast so not always useful to fill out the matrix. > > > Sometimes a slash is used, sometimes an underscore, sometimes > > > "win64" inserted, but again, it's generally reasonable hidden > behind > > > a .bat file to set the environment and set $PATH and set the > > > console's title (console == xterm, not the one special console). > > > > > > If you have more than one cl.exe or link.exe on your path, not > good. > > > cl.exe does more work than the gcc driver, it doesn't delegate out > > > as much. > > > > > > There are no "fat" files like Apple does, well, not mechanized/ > > > systematic. > > > Something like sysinternals handle.exe that has an embedded driver > > > has a toplevel x86 file that runs on everything and then on demand > > > extracts the AMD64 or IA64 executable and driver, runs the other > > > version of itself, installs the driver on demand and voila.. > > > ) > > > > > > - Jay > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Apr 18 07:11:54 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Apr 2008 05:11:54 +0000 Subject: [M3devel] biarch, multilib, etc? In-Reply-To: References: <527623C3-BC62-4CF0-B338-068D149378C2@cs.purdue.edu> Message-ID: I agree this could work on Mac OS X and I will run it again, but I believe that is how I essentially got: jay at jayx2:~/dev2/cm3/m3-sys/m3cc/LINUXLIBC6.1$ ./cm3cg --help | grep -e " -m[0-9]" -m128bit-long-double [disabled] -m32 [disabled] -m3dnow [disabled] -m64 [enabled] -m80387 [enabled] -m96bit-long-double [enabled] jay at jayx2:~/dev2/cm3/m3-sys/m3cc/LINUXLIBC6.1$ ldd ./cm3cg linux-vdso.so.1 => (0x00007fffc7bff000) libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00007fbfbf6fd000) libc.so.6 => /lib/libc.so.6 (0x00007fbfbf39b000) /lib64/ld-linux-x86-64.so.2 (0x00007fbfbf93c000) which I believe will only run on AMD64 and only produce AMD64 code. (Which is probably why I got internal compiler errors trying to use it.) - Jay ________________________________ CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jayk123 at hotmail.com Subject: Re: [M3devel] biarch, multilib, etc? Date: Fri, 18 Apr 2008 00:44:57 -0400 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 Apr 18, 2008, at 12:00 AM, Jay wrote: Kinda sorta but not quite. I am now trying without --disable-bootstrap and --disable-multilib for non-native builds. I'll see how that goes. I understand the niceness of a multarch toolset. I also would like an option for that toolset to be x86 hosted instead of AMD64 hosted, but I'll take either at this point. It still likes to look for i686-pc-linux-gnu-ar and ld and such, rather than just using the existing biarch tools. Who? When building gcc? My build of cm3cg on OS X appears to be x86 hosted. cm3cg does not need to look for any tools... Epiphany: There are the following platforms: build -- what is building the compiler host -- what the compiler will run on target -- what the compiler's output will run on However each one is potentially biarch or multiarch. (multiarch -- Mac OS X AMD64 machines can run 32 bit PowerPC, 32 bit x86, and AMD64 -- triarch). I build gcc without any special setup other than described above. I host on whatever that build turns out to be. I target using -m32/-m64. I understand in the general simple case, gcc -m32 is all it takes, but I don't trust that to suffice for building gcc, since there is at least one more architecture involved and there are a bunch of suspiciously relevant sounding configurable knobs, not just CC and CFLAGS, but AS_FOR_TARGET, GCC_FOR_TARGET, etc., but there aren't FOO_FOR_BUILD, FOO_FOR_HOST, FOO_FOR_TARGET; I guess plain FOO is FOO_FOR_BUILD. I don't specify -m32 or -m64 to build gcc itself. It automatically builds a biarch compiler. I'll keep poking.. - Jay > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jayk123 at hotmail.com > Subject: Re: [M3devel] biarch, multilib, etc? > Date: Thu, 17 Apr 2008 22:02:16 -0400 > > Have you tried the following: > > cd cm3/m3-sys/m3cc > mkdir build > cd build > ../gcc/configure --enable-languages=m3cg > make > > This works for me on Mac OS X and builds a bi-arch version of m3cg > that will accept both -m32 and -m64 flags to target x86_32 and x86_64. > > Admittedly, it does go through the full bootstrap, which is probably > overkill. > > I haven't had a chance to try AMD64_LINUX yet, but I assume it will > behave much the same in building a bi-arch compiler. > > On Apr 17, 2008, at 9:13 PM, Jay wrote: > >> >> What I want to start is an x86 hosted x86 targeted cm3cg to (build >> and) run on my AMD64 system, just to get where we already are. >> >> I have this: >> >> jay at jayx2:~/dev2/cm3/m3-sys/m3cc$ ldd LINUXLIBC6.1/cm3cg >> linux-vdso.so.1 => (0x00007fffe21fe000) >> libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00007f3fd9c8a000) >> libc.so.6 => /lib/libc.so.6 (0x00007f3fd9928000) >> /lib64/ld-linux-x86-64.so.2 (0x00007f3fd9ec9000) >> >> >> which I think got via straightforward methods and which I think is >> not what I want -- it won't run on other people's x86 system. >> >> Once I get that working, x86 hosted AMD64 target would be good, or >> AMD64 hosted, AMD64 targeted if I must. >> That is, tools can "just" be x86 hosted and work ok, enabling fewer >> tools that run one more hosts to target more targets. >> >> You know, I just want gcc to pretend to ignore all the AMD64 stuff, >> at least to start. >> There are a variety of promising methods but stuff keeps failing >> somewhere or another. >> stuff like CC="gcc -m32" etc. >> >> e.g.: >> collect2: ld terminated with signal 11 [Segmentation fault], core >> dumped >> /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- >> unknown-linux-gnu/libiberty/libiberty.a(hashtab.o)' is incompatible >> with i386 output >> /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- >> unknown-linux-gnu/libiberty/libiberty.a(xmalloc.o)' is incompatible >> with i386 output >> /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- >> unknown-linux-gnu/libiberty/libiberty.a(xstrdup.o)' is incompatible >> with i386 output >> /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- >> unknown-linux-gnu/libiberty/libiberty.a(xexit.o)' is incompatible >> with i386 output >> >> - Jay >> >> ________________________________ >> CC: m3devel at elegosoft.com >> From: hosking at cs.purdue.edu >> To: jayk123 at hotmail.com >> Subject: Re: [M3devel] biarch, multilib, etc? >> Date: Thu, 17 Apr 2008 13:03:41 -0400 >> >> Check the latest version of m3-sys/cminstall/src/config/LINUXLIBC6. >> Notice that it now always uses -m32, --32 flags to the various >> compiler components (cm3cg, SYSTEM_CC, SYSTEM_AS). This forces use >> of the x86 variants. An AMD64_LINUX port will have an almost >> identical configuration file that forces use of the x86_64 toolchain. >> >> 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 Apr 17, 2008, at 8:03 AM, Jay wrote: >> >> Can anyone explain how Linux and gcc are managing that AMD64 systems >> can run >> and presumably build x86 code? >> >> >> I know there is /lib32 and /lib64. >> I know there is gcc -m32 and gcc -m64. >> I know that gcc itself delegates out to target specific executables, >> so one gcc plus flags suffices, >> it's those other executables that multiply out. That ld has the -m >> flag. That as has --32 and --64. >> I don't know how much stuff goes through gcc, vs. needs the get the >> as/ld flags correct. >> I'm not talking about Modula-3 here, but, like of building gcc and >> its dependencies. >> I can deal with the smaller Modula-3 system contained in far more >> readable Quake code than all the "sh" >> and layers upon layers of makefiles and autoconf and sh and m4 etc.. >> >> >> ./configure on various things tend to build just AMD64. >> >> >> It appears in general that for any >> apt-get install foo >> you can often but not always >> apt-get install foo-i386 >> >> >> This is on KUbuntu 8.4 Hardy Heron KDE4 beta AMD64 (mouthful!) >> >> >> It looks like in general: >> CC="gcc -m32" .../configure --prefix=/usr --libdir=/usr/lib32 -- >> build=i686-pc-linux-gnu >> >> >> is what you want, but that many packages are only native. >> in particular gmp and mpfr: >> apt-get install mpfr-i386 >> => no luck >> >> >> Maybe these are not considered "mainstream"? >> >> >> I'll build them myself, something like: >> >> cd /usr/src >> apt-get source mpfr >> mkdir -p obj/mpfr >> cd obj/mpfr >> CC="gcc -m32" /usr/src/mpfr-2.3.1.dfsg.1/configure --prefix=/usr -- >> libdir=/usr/lib32 --build=i686-pc-linux-gnu >> make >> sudo make install >> >> >> cd /usr/src >> apt-get source libgmp3-dev >> mkdir -p /usr/src/obj/gmp >> cd /usr/src/obj/obj >> CC="gcc -m32" /usr/src/gmp-4.2.2+dfsg/configure --prefix=/usr -- >> libdir=/usr/lib32 --build=i686-pc-linux-gnu >> make >> sudo make install >> >> You know, I just want building the Modula-3 system on AMD64_LINUX to >> at first merely build >> an x86 hosted, x86 targeted binary. And then start changing things. >> >> >> And between host, target, and build, I find the names confusing. >> I understand why there are three -- the current system to build the >> compiler, a system to run the >> compiler, a system to run the compiler's output, but these names >> host, target, build, aren't very >> mnemonic with me yet. Is it build=now, host=runs the compier, >> target=runs the compiler's output? >> I'll dig around. >> >> I know, I can figure it all out, there's the www to search, but this >> biarch/multilib is hard >> to find the docs for..and I can't read the masses of m4/sh/gmake.. >> >> ps: it's easy to get the ld to crash when doing this stuff wrong.. >> >> (I can explain how Windows does it, fyi. >> 1) The system is "doubled up", generally .dlls and .exes, but not >> kernel and drivers >> c:\windows\system32 is native >> c:\windows\syswow64 is 32bit >> Yeah it's wierd/backwards, but it is source compatible. >> There is runtime magic to redirect from "system32" in 32 bit >> processes to syswow64. >> Though if folks used the very long standing APIs, this wouldn't have >> been needed. Oh well. >> There is also c:\program files and c:\program files (x86). I guess >> people are better about using the APIs here. >> "Introspection" is "broken" but this -- link -dump against c:\windows >> \system32 can get "redirected" but devtools aren't the priority and >> it does all generally work out, despite the hokiness. >> The registry is similarly doubled up and redirected, in some places >> at least, since it tends to give paths to .dlls -- a process is >> either 32bit or 64bit -- can't load one type .dll in other type >> process. >> >> On the devtools side, well, you know, NT always had ppc/mips/alpha/ >> x86, so .libs are generally already in a directory named "i386" or >> "x86". >> In any case, folks don't hardcode paths as much, because they are >> already so variable. >> So you set up your environment or such using the %LIB% variable and >> it works easily. >> >> For running devtools, there is a separate set of .exes for each >> target. >> And sometimes for host. >> The matrix is filled out as necessary. >> AMD64 runs x86 fast so not always useful to fill out the matrix. >> Sometimes a slash is used, sometimes an underscore, sometimes >> "win64" inserted, but again, it's generally reasonable hidden behind >> a .bat file to set the environment and set $PATH and set the >> console's title (console == xterm, not the one special console). >> >> If you have more than one cl.exe or link.exe on your path, not good. >> cl.exe does more work than the gcc driver, it doesn't delegate out >> as much. >> >> There are no "fat" files like Apple does, well, not mechanized/ >> systematic. >> Something like sysinternals handle.exe that has an embedded driver >> has a toplevel x86 file that runs on everything and then on demand >> extracts the AMD64 or IA64 executable and driver, runs the other >> version of itself, installs the driver on demand and voila.. >> ) >> >> - Jay >> > From jayk123 at hotmail.com Fri Apr 18 08:23:08 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Apr 2008 06:23:08 +0000 Subject: [M3devel] biarch, multilib, etc? In-Reply-To: References: <527623C3-BC62-4CF0-B338-068D149378C2@cs.purdue.edu> Message-ID: I definitely need to try again..reading the docs: http://gcc.gnu.org/install/specific.html#x86-64-x-x x86_64-*-*, amd64-*-* GCC supports the x86-64 architecture implemented by the AMD64 processor (amd64-*-* is an alias for x86_64-*-*) on GNU/Linux, FreeBSD and NetBSD. On GNU/Linux the default is a bi-arch compiler which is able to generate both 64-bit x86-64 and 32-bit x86 code (via the -m32 switch). I was able to build an AMD64 hosted x86 targeted compiler and somehow it seemed to go very very quick, like 15 minutes.I need to verify that result, and try the default again for biarch even if it takes 5 hours. There is also --enable-targets=all or a list, which sounded promising, until I saw the above. - Jay > From: jayk123 at hotmail.com > To: hosking at cs.purdue.edu > Date: Fri, 18 Apr 2008 05:11:54 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] biarch, multilib, etc? > > > I agree this could work on Mac OS X and I will run it again, but I believe that is how I essentially got: > > jay at jayx2:~/dev2/cm3/m3-sys/m3cc/LINUXLIBC6.1$ ./cm3cg --help | grep -e " -m[0-9]" > -m128bit-long-double [disabled] > -m32 [disabled] > -m3dnow [disabled] > -m64 [enabled] > -m80387 [enabled] > -m96bit-long-double [enabled] > > jay at jayx2:~/dev2/cm3/m3-sys/m3cc/LINUXLIBC6.1$ ldd ./cm3cg > linux-vdso.so.1 => (0x00007fffc7bff000) > libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00007fbfbf6fd000) > libc.so.6 => /lib/libc.so.6 (0x00007fbfbf39b000) > /lib64/ld-linux-x86-64.so.2 (0x00007fbfbf93c000) > > which I believe will only run on AMD64 and only produce AMD64 code. > (Which is probably why I got internal compiler errors trying to use it.) > > - Jay > > > ________________________________ > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jayk123 at hotmail.com > Subject: Re: [M3devel] biarch, multilib, etc? > Date: Fri, 18 Apr 2008 00:44:57 -0400 > > > 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 Apr 18, 2008, at 12:00 AM, Jay wrote: > Kinda sorta but not quite. > I am now trying without --disable-bootstrap and --disable-multilib for non-native builds. I'll see how that goes. > I understand the niceness of a multarch toolset. > > I also would like an option for that toolset to be x86 hosted instead of AMD64 hosted, but I'll take either at this point. > It still likes to look for i686-pc-linux-gnu-ar and ld and such, rather than just using the existing biarch tools. > > Who? When building gcc? My build of cm3cg on OS X appears to be x86 hosted. cm3cg does not need to look for any tools... > > Epiphany: > There are the following platforms: > build -- what is building the compiler > host -- what the compiler will run on > target -- what the compiler's output will run on > > However each one is potentially biarch or multiarch. > (multiarch -- Mac OS X AMD64 machines can run 32 bit PowerPC, 32 bit x86, and AMD64 -- triarch). > > I build gcc without any special setup other than described above. > I host on whatever that build turns out to be. > I target using -m32/-m64. > > I understand in the general simple case, gcc -m32 is all it takes, but I don't trust that to suffice for building gcc, since there is at least one more architecture involved and there are a bunch of suspiciously relevant sounding configurable knobs, not just CC and CFLAGS, but AS_FOR_TARGET, GCC_FOR_TARGET, etc., but there aren't FOO_FOR_BUILD, FOO_FOR_HOST, FOO_FOR_TARGET; I guess plain FOO is FOO_FOR_BUILD. > > I don't specify -m32 or -m64 to build gcc itself. It automatically builds a biarch compiler. > > I'll keep poking.. > > - Jay > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > To: jayk123 at hotmail.com > > Subject: Re: [M3devel] biarch, multilib, etc? > > Date: Thu, 17 Apr 2008 22:02:16 -0400 > > > > Have you tried the following: > > > > cd cm3/m3-sys/m3cc > > mkdir build > > cd build > > ../gcc/configure --enable-languages=m3cg > > make > > > > This works for me on Mac OS X and builds a bi-arch version of m3cg > > that will accept both -m32 and -m64 flags to target x86_32 and x86_64. > > > > Admittedly, it does go through the full bootstrap, which is probably > > overkill. > > > > I haven't had a chance to try AMD64_LINUX yet, but I assume it will > > behave much the same in building a bi-arch compiler. > > > > On Apr 17, 2008, at 9:13 PM, Jay wrote: > > > >> > >> What I want to start is an x86 hosted x86 targeted cm3cg to (build > >> and) run on my AMD64 system, just to get where we already are. > >> > >> I have this: > >> > >> jay at jayx2:~/dev2/cm3/m3-sys/m3cc$ ldd LINUXLIBC6.1/cm3cg > >> linux-vdso.so.1 => (0x00007fffe21fe000) > >> libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00007f3fd9c8a000) > >> libc.so.6 => /lib/libc.so.6 (0x00007f3fd9928000) > >> /lib64/ld-linux-x86-64.so.2 (0x00007f3fd9ec9000) > >> > >> > >> which I think got via straightforward methods and which I think is > >> not what I want -- it won't run on other people's x86 system. > >> > >> Once I get that working, x86 hosted AMD64 target would be good, or > >> AMD64 hosted, AMD64 targeted if I must. > >> That is, tools can "just" be x86 hosted and work ok, enabling fewer > >> tools that run one more hosts to target more targets. > >> > >> You know, I just want gcc to pretend to ignore all the AMD64 stuff, > >> at least to start. > >> There are a variety of promising methods but stuff keeps failing > >> somewhere or another. > >> stuff like CC="gcc -m32" etc. > >> > >> e.g.: > >> collect2: ld terminated with signal 11 [Segmentation fault], core > >> dumped > >> /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- > >> unknown-linux-gnu/libiberty/libiberty.a(hashtab.o)' is incompatible > >> with i386 output > >> /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- > >> unknown-linux-gnu/libiberty/libiberty.a(xmalloc.o)' is incompatible > >> with i386 output > >> /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- > >> unknown-linux-gnu/libiberty/libiberty.a(xstrdup.o)' is incompatible > >> with i386 output > >> /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- > >> unknown-linux-gnu/libiberty/libiberty.a(xexit.o)' is incompatible > >> with i386 output > >> > >> - Jay > >> > >> ________________________________ > >> CC: m3devel at elegosoft.com > >> From: hosking at cs.purdue.edu > >> To: jayk123 at hotmail.com > >> Subject: Re: [M3devel] biarch, multilib, etc? > >> Date: Thu, 17 Apr 2008 13:03:41 -0400 > >> > >> Check the latest version of m3-sys/cminstall/src/config/LINUXLIBC6. > >> Notice that it now always uses -m32, --32 flags to the various > >> compiler components (cm3cg, SYSTEM_CC, SYSTEM_AS). This forces use > >> of the x86 variants. An AMD64_LINUX port will have an almost > >> identical configuration file that forces use of the x86_64 toolchain. > >> > >> 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 Apr 17, 2008, at 8:03 AM, Jay wrote: > >> > >> Can anyone explain how Linux and gcc are managing that AMD64 systems > >> can run > >> and presumably build x86 code? > >> > >> > >> I know there is /lib32 and /lib64. > >> I know there is gcc -m32 and gcc -m64. > >> I know that gcc itself delegates out to target specific executables, > >> so one gcc plus flags suffices, > >> it's those other executables that multiply out. That ld has the -m > >> flag. That as has --32 and --64. > >> I don't know how much stuff goes through gcc, vs. needs the get the > >> as/ld flags correct. > >> I'm not talking about Modula-3 here, but, like of building gcc and > >> its dependencies. > >> I can deal with the smaller Modula-3 system contained in far more > >> readable Quake code than all the "sh" > >> and layers upon layers of makefiles and autoconf and sh and m4 etc.. > >> > >> > >> ./configure on various things tend to build just AMD64. > >> > >> > >> It appears in general that for any > >> apt-get install foo > >> you can often but not always > >> apt-get install foo-i386 > >> > >> > >> This is on KUbuntu 8.4 Hardy Heron KDE4 beta AMD64 (mouthful!) > >> > >> > >> It looks like in general: > >> CC="gcc -m32" .../configure --prefix=/usr --libdir=/usr/lib32 -- > >> build=i686-pc-linux-gnu > >> > >> > >> is what you want, but that many packages are only native. > >> in particular gmp and mpfr: > >> apt-get install mpfr-i386 > >> => no luck > >> > >> > >> Maybe these are not considered "mainstream"? > >> > >> > >> I'll build them myself, something like: > >> > >> cd /usr/src > >> apt-get source mpfr > >> mkdir -p obj/mpfr > >> cd obj/mpfr > >> CC="gcc -m32" /usr/src/mpfr-2.3.1.dfsg.1/configure --prefix=/usr -- > >> libdir=/usr/lib32 --build=i686-pc-linux-gnu > >> make > >> sudo make install > >> > >> > >> cd /usr/src > >> apt-get source libgmp3-dev > >> mkdir -p /usr/src/obj/gmp > >> cd /usr/src/obj/obj > >> CC="gcc -m32" /usr/src/gmp-4.2.2+dfsg/configure --prefix=/usr -- > >> libdir=/usr/lib32 --build=i686-pc-linux-gnu > >> make > >> sudo make install > >> > >> You know, I just want building the Modula-3 system on AMD64_LINUX to > >> at first merely build > >> an x86 hosted, x86 targeted binary. And then start changing things. > >> > >> > >> And between host, target, and build, I find the names confusing. > >> I understand why there are three -- the current system to build the > >> compiler, a system to run the > >> compiler, a system to run the compiler's output, but these names > >> host, target, build, aren't very > >> mnemonic with me yet. Is it build=now, host=runs the compier, > >> target=runs the compiler's output? > >> I'll dig around. > >> > >> I know, I can figure it all out, there's the www to search, but this > >> biarch/multilib is hard > >> to find the docs for..and I can't read the masses of m4/sh/gmake.. > >> > >> ps: it's easy to get the ld to crash when doing this stuff wrong.. > >> > >> (I can explain how Windows does it, fyi. > >> 1) The system is "doubled up", generally .dlls and .exes, but not > >> kernel and drivers > >> c:\windows\system32 is native > >> c:\windows\syswow64 is 32bit > >> Yeah it's wierd/backwards, but it is source compatible. > >> There is runtime magic to redirect from "system32" in 32 bit > >> processes to syswow64. > >> Though if folks used the very long standing APIs, this wouldn't have > >> been needed. Oh well. > >> There is also c:\program files and c:\program files (x86). I guess > >> people are better about using the APIs here. > >> "Introspection" is "broken" but this -- link -dump against c:\windows > >> \system32 can get "redirected" but devtools aren't the priority and > >> it does all generally work out, despite the hokiness. > >> The registry is similarly doubled up and redirected, in some places > >> at least, since it tends to give paths to .dlls -- a process is > >> either 32bit or 64bit -- can't load one type .dll in other type > >> process. > >> > >> On the devtools side, well, you know, NT always had ppc/mips/alpha/ > >> x86, so .libs are generally already in a directory named "i386" or > >> "x86". > >> In any case, folks don't hardcode paths as much, because they are > >> already so variable. > >> So you set up your environment or such using the %LIB% variable and > >> it works easily. > >> > >> For running devtools, there is a separate set of .exes for each > >> target. > >> And sometimes for host. > >> The matrix is filled out as necessary. > >> AMD64 runs x86 fast so not always useful to fill out the matrix. > >> Sometimes a slash is used, sometimes an underscore, sometimes > >> "win64" inserted, but again, it's generally reasonable hidden behind > >> a .bat file to set the environment and set $PATH and set the > >> console's title (console == xterm, not the one special console). > >> > >> If you have more than one cl.exe or link.exe on your path, not good. > >> cl.exe does more work than the gcc driver, it doesn't delegate out > >> as much. > >> > >> There are no "fat" files like Apple does, well, not mechanized/ > >> systematic. > >> Something like sysinternals handle.exe that has an embedded driver > >> has a toplevel x86 file that runs on everything and then on demand > >> extracts the AMD64 or IA64 executable and driver, runs the other > >> version of itself, installs the driver on demand and voila.. > >> ) > >> > >> - Jay > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Apr 18 08:52:06 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Apr 2008 06:52:06 +0000 Subject: [M3devel] biarch, multilib, etc? In-Reply-To: References: <527623C3-BC62-4CF0-B338-068D149378C2@cs.purdue.edu> Message-ID: ok, indeed, it looks like if you omit target or targets, the default for an AMD64 host is to be able to target x86 and AMD64. If you do specify --target, then you only get one. I think. --disable-bootstrap may also lead to getting one. I think. Using an x86 probably also only gives you one, but maybe you can get multiple? I'll keep digging. I can reproduce the 17 minute build. So maybe two 17 minute builds to get two uniarch cm3cg's is the way, though it should be viable to get a biarch x86 hosted in 34 minutes. Fooling gcc into building an x86 hosted tool on an AMD64 system without a bootstrap may indeed bit a little tricky. Lots of variables.. more later.. Or maybe I should take the AMD64 targeted compiler and look into the rest of the system here.. - Jay From: jayk123 at hotmail.com To: hosking at cs.purdue.edu Date: Fri, 18 Apr 2008 06:23:08 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] biarch, multilib, etc? I definitely need to try again..reading the docs: http://gcc.gnu.org/install/specific.html#x86-64-x-x x86_64-*-*, amd64-*-* GCC supports the x86-64 architecture implemented by the AMD64 processor (amd64-*-* is an alias for x86_64-*-*) on GNU/Linux, FreeBSD and NetBSD. On GNU/Linux the default is a bi-arch compiler which is able to generate both 64-bit x86-64 and 32-bit x86 code (via the -m32 switch). I was able to build an AMD64 hosted x86 targeted compiler and somehow it seemed to go very very quick, like 15 minutes. I need to verify that result, and try the default again for biarch even if it takes 5 hours. There is also --enable-targets=all or a list, which sounded promising, until I saw the above. - Jay > From: jayk123 at hotmail.com > To: hosking at cs.purdue.edu > Date: Fri, 18 Apr 2008 05:11:54 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] biarch, multilib, etc? > > > I agree this could work on Mac OS X and I will run it again, but I believe that is how I essentially got: > > jay at jayx2:~/dev2/cm3/m3-sys/m3cc/LINUXLIBC6.1$ ./cm3cg --help | grep -e " -m[0-9]" > -m128bit-long-double [disabled] > -m32 [disabled] > -m3dnow [disabled] > -m64 [enabled] > -m80387 [enabled] > -m96bit-long-double [enabled] > > jay at jayx2:~/dev2/cm3/m3-sys/m3cc/LINUXLIBC6.1$ ldd ./cm3cg > linux-vdso.so.1 => (0x00007fffc7bff000) > libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00007fbfbf6fd000) > libc.so.6 => /lib/libc.so.6 (0x00007fbfbf39b000) > /lib64/ld-linux-x86-64.so.2 (0x00007fbfbf93c000) > > which I believe will only run on AMD64 and only produce AMD64 code. > (Which is probably why I got internal compiler errors trying to use it.) > > - Jay > > > ________________________________ > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jayk123 at hotmail.com > Subject: Re: [M3devel] biarch, multilib, etc? > Date: Fri, 18 Apr 2008 00:44:57 -0400 > > > 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 Apr 18, 2008, at 12:00 AM, Jay wrote: > Kinda sorta but not quite. > I am now trying without --disable-bootstrap and --disable-multilib for non-native builds. I'll see how that goes. > I understand the niceness of a multarch toolset. > > I also would like an option for that toolset to be x86 hosted instead of AMD64 hosted, but I'll take either at this point. > It still likes to look for i686-pc-linux-gnu-ar and ld and such, rather than just using the existing biarch tools. > > Who? When building gcc? My build of cm3cg on OS X appears to be x86 hosted. cm3cg does not need to look for any tools... > > Epiphany: > There are the following platforms: > build -- what is building the compiler > host -- what the compiler will run on > target -- what the compiler's output will run on > > However each one is potentially biarch or multiarch. > (multiarch -- Mac OS X AMD64 machines can run 32 bit PowerPC, 32 bit x86, and AMD64 -- triarch). > > I build gcc without any special setup other than described above. > I host on whatever that build turns out to be. > I target using -m32/-m64. > > I understand in the general simple case, gcc -m32 is all it takes, but I don't trust that to suffice for building gcc, since there is at least one more architecture involved and there are a bunch of suspiciously relevant sounding configurable knobs, not just CC and CFLAGS, but AS_FOR_TARGET, GCC_FOR_TARGET, etc., but there aren't FOO_FOR_BUILD, FOO_FOR_HOST, FOO_FOR_TARGET; I guess plain FOO is FOO_FOR_BUILD. > > I don't specify -m32 or -m64 to build gcc itself. It automatically builds a biarch compiler. > > I'll keep poking.. > > - Jay > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > To: jayk123 at hotmail.com > > Subject: Re: [M3devel] biarch, multilib, etc? > > Date: Thu, 17 Apr 2008 22:02:16 -0400 > > > > Have you tried the following: > > > > cd cm3/m3-sys/m3cc > > mkdir build > > cd build > > ../gcc/configure --enable-languages=m3cg > > make > > > > This works for me on Mac OS X and builds a bi-arch version of m3cg > > that will accept both -m32 and -m64 flags to target x86_32 and x86_64. > > > > Admittedly, it does go through the full bootstrap, which is probably > > overkill. > > > > I haven't had a chance to try AMD64_LINUX yet, but I assume it will > > behave much the same in building a bi-arch compiler. > > > > On Apr 17, 2008, at 9:13 PM, Jay wrote: > > > >> > >> What I want to start is an x86 hosted x86 targeted cm3cg to (build > >> and) run on my AMD64 system, just to get where we already are. > >> > >> I have this: > >> > >> jay at jayx2:~/dev2/cm3/m3-sys/m3cc$ ldd LINUXLIBC6.1/cm3cg > >> linux-vdso.so.1 => (0x00007fffe21fe000) > >> libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00007f3fd9c8a000) > >> libc.so.6 => /lib/libc.so.6 (0x00007f3fd9928000) > >> /lib64/ld-linux-x86-64.so.2 (0x00007f3fd9ec9000) > >> > >> > >> which I think got via straightforward methods and which I think is > >> not what I want -- it won't run on other people's x86 system. > >> > >> Once I get that working, x86 hosted AMD64 target would be good, or > >> AMD64 hosted, AMD64 targeted if I must. > >> That is, tools can "just" be x86 hosted and work ok, enabling fewer > >> tools that run one more hosts to target more targets. > >> > >> You know, I just want gcc to pretend to ignore all the AMD64 stuff, > >> at least to start. > >> There are a variety of promising methods but stuff keeps failing > >> somewhere or another. > >> stuff like CC="gcc -m32" etc. > >> > >> e.g.: > >> collect2: ld terminated with signal 11 [Segmentation fault], core > >> dumped > >> /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- > >> unknown-linux-gnu/libiberty/libiberty.a(hashtab.o)' is incompatible > >> with i386 output > >> /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- > >> unknown-linux-gnu/libiberty/libiberty.a(xmalloc.o)' is incompatible > >> with i386 output > >> /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- > >> unknown-linux-gnu/libiberty/libiberty.a(xstrdup.o)' is incompatible > >> with i386 output > >> /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- > >> unknown-linux-gnu/libiberty/libiberty.a(xexit.o)' is incompatible > >> with i386 output > >> > >> - Jay > >> > >> ________________________________ > >> CC: m3devel at elegosoft.com > >> From: hosking at cs.purdue.edu > >> To: jayk123 at hotmail.com > >> Subject: Re: [M3devel] biarch, multilib, etc? > >> Date: Thu, 17 Apr 2008 13:03:41 -0400 > >> > >> Check the latest version of m3-sys/cminstall/src/config/LINUXLIBC6. > >> Notice that it now always uses -m32, --32 flags to the various > >> compiler components (cm3cg, SYSTEM_CC, SYSTEM_AS). This forces use > >> of the x86 variants. An AMD64_LINUX port will have an almost > >> identical configuration file that forces use of the x86_64 toolchain. > >> > >> 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 Apr 17, 2008, at 8:03 AM, Jay wrote: > >> > >> Can anyone explain how Linux and gcc are managing that AMD64 systems > >> can run > >> and presumably build x86 code? > >> > >> > >> I know there is /lib32 and /lib64. > >> I know there is gcc -m32 and gcc -m64. > >> I know that gcc itself delegates out to target specific executables, > >> so one gcc plus flags suffices, > >> it's those other executables that multiply out. That ld has the -m > >> flag. That as has --32 and --64. > >> I don't know how much stuff goes through gcc, vs. needs the get the > >> as/ld flags correct. > >> I'm not talking about Modula-3 here, but, like of building gcc and > >> its dependencies. > >> I can deal with the smaller Modula-3 system contained in far more > >> readable Quake code than all the "sh" > >> and layers upon layers of makefiles and autoconf and sh and m4 etc.. > >> > >> > >> ./configure on various things tend to build just AMD64. > >> > >> > >> It appears in general that for any > >> apt-get install foo > >> you can often but not always > >> apt-get install foo-i386 > >> > >> > >> This is on KUbuntu 8.4 Hardy Heron KDE4 beta AMD64 (mouthful!) > >> > >> > >> It looks like in general: > >> CC="gcc -m32" .../configure --prefix=/usr --libdir=/usr/lib32 -- > >> build=i686-pc-linux-gnu > >> > >> > >> is what you want, but that many packages are only native. > >> in particular gmp and mpfr: > >> apt-get install mpfr-i386 > >> => no luck > >> > >> > >> Maybe these are not considered "mainstream"? > >> > >> > >> I'll build them myself, something like: > >> > >> cd /usr/src > >> apt-get source mpfr > >> mkdir -p obj/mpfr > >> cd obj/mpfr > >> CC="gcc -m32" /usr/src/mpfr-2.3.1.dfsg.1/configure --prefix=/usr -- > >> libdir=/usr/lib32 --build=i686-pc-linux-gnu > >> make > >> sudo make install > >> > >> > >> cd /usr/src > >> apt-get source libgmp3-dev > >> mkdir -p /usr/src/obj/gmp > >> cd /usr/src/obj/obj > >> CC="gcc -m32" /usr/src/gmp-4.2.2+dfsg/configure --prefix=/usr -- > >> libdir=/usr/lib32 --build=i686-pc-linux-gnu > >> make > >> sudo make install > >> > >> You know, I just want building the Modula-3 system on AMD64_LINUX to > >> at first merely build > >> an x86 hosted, x86 targeted binary. And then start changing things. > >> > >> > >> And between host, target, and build, I find the names confusing. > >> I understand why there are three -- the current system to build the > >> compiler, a system to run the > >> compiler, a system to run the compiler's output, but these names > >> host, target, build, aren't very > >> mnemonic with me yet. Is it build=now, host=runs the compier, > >> target=runs the compiler's output? > >> I'll dig around. > >> > >> I know, I can figure it all out, there's the www to search, but this > >> biarch/multilib is hard > >> to find the docs for..and I can't read the masses of m4/sh/gmake.. > >> > >> ps: it's easy to get the ld to crash when doing this stuff wrong.. > >> > >> (I can explain how Windows does it, fyi. > >> 1) The system is "doubled up", generally .dlls and .exes, but not > >> kernel and drivers > >> c:\windows\system32 is native > >> c:\windows\syswow64 is 32bit > >> Yeah it's wierd/backwards, but it is source compatible. > >> There is runtime magic to redirect from "system32" in 32 bit > >> processes to syswow64. > >> Though if folks used the very long standing APIs, this wouldn't have > >> been needed. Oh well. > >> There is also c:\program files and c:\program files (x86). I guess > >> people are better about using the APIs here. > >> "Introspection" is "broken" but this -- link -dump against c:\windows > >> \system32 can get "redirected" but devtools aren't the priority and > >> it does all generally work out, despite the hokiness. > >> The registry is similarly doubled up and redirected, in some places > >> at least, since it tends to give paths to .dlls -- a process is > >> either 32bit or 64bit -- can't load one type .dll in other type > >> process. > >> > >> On the devtools side, well, you know, NT always had ppc/mips/alpha/ > >> x86, so .libs are generally already in a directory named "i386" or > >> "x86". > >> In any case, folks don't hardcode paths as much, because they are > >> already so variable. > >> So you set up your environment or such using the %LIB% variable and > >> it works easily. > >> > >> For running devtools, there is a separate set of .exes for each > >> target. > >> And sometimes for host. > >> The matrix is filled out as necessary. > >> AMD64 runs x86 fast so not always useful to fill out the matrix. > >> Sometimes a slash is used, sometimes an underscore, sometimes > >> "win64" inserted, but again, it's generally reasonable hidden behind > >> a .bat file to set the environment and set $PATH and set the > >> console's title (console == xterm, not the one special console). > >> > >> If you have more than one cl.exe or link.exe on your path, not good. > >> cl.exe does more work than the gcc driver, it doesn't delegate out > >> as much. > >> > >> There are no "fat" files like Apple does, well, not mechanized/ > >> systematic. > >> Something like sysinternals handle.exe that has an embedded driver > >> has a toplevel x86 file that runs on everything and then on demand > >> extracts the AMD64 or IA64 executable and driver, runs the other > >> version of itself, installs the driver on demand and voila.. > >> ) > >> > >> - Jay > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Apr 18 09:15:24 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 18 Apr 2008 09:15:24 +0200 Subject: [M3devel] current tinderbox failures / new release? Message-ID: <20080418091524.nlijnhwta8cwk4co@mail.elegosoft.com> Currently builds of cm3 fail because quake's getwd is not in the last release (5.4.0) and so cannot be used for bootstrapping. Could somebody fix that? We really need to provide a new release soon to be able to safely use all the new functionality. But there are still no working tests on NT386*, and X64 porting seems to be underway. I think we should define a goal or milestone (we can even do that with trac), define the needed features or blocking bugs and work towards it. Or is everybody just as busy as I am and this is no good idea? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Fri Apr 18 10:00:56 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Apr 2008 08:00:56 +0000 Subject: [M3devel] current tinderbox failures / new release? In-Reply-To: <20080418091524.nlijnhwta8cwk4co@mail.elegosoft.com> References: <20080418091524.nlijnhwta8cwk4co@mail.elegosoft.com> Message-ID: getwd was my doing. Yeah I guess I'll workaround, with some sh. Sorry, I didn't realize. I guess fs_cp same problem? Tony "argues" for removing the useof getwd, but so far it seems to fix something that is actually a problem. I think any release is ok...sort of. > NT386 tests NT386 tests aren't runnable, but presumably no major regression, right? There is still the bitmap thing. > AMD64 AMD64 Certainly ok to release without. And you meant AMD64_NT/LINUX. AMD64_DARWIN is already there from Tony. :) Am I going to have to stop checking in, or use a branch? > needed features, blocking bugs Just having new targets even in "prerelease" form are nice features already present: AMD64_DARWIN (aka AMD64_MACOSX :) ) NT386GNU NT386MINGNU (still without gui working due to __stdcall; I should workaround..) plus: Quake extensions set relationship bug fix non-interactive install install-less archives possibly available possible perf benefits from sleep() removal in Process Would be nice to get PPC_LINUX up to pthreads but not high priority. Not sure what the marketing department says, if this is "enough" to have a "major" release that everyone will "buy". :) What's the "official" QA/release process anyway, for the daily snapshots, the snapshots I uploaded, vs. anything else? Would be nice to see if .debs/.rpms could be made and available through "official" channels. - Jay > Date: Fri, 18 Apr 2008 09:15:24 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] current tinderbox failures / new release? > > Currently builds of cm3 fail because quake's getwd is not in the > last release (5.4.0) and so cannot be used for bootstrapping. > Could somebody fix that? > > We really need to provide a new release soon to be able to safely use > all the new functionality. But there are still no working tests on > NT386*, and X64 porting seems to be underway. > > I think we should define a goal or milestone (we can even do that with > trac), define the needed features or blocking bugs and work towards > it. > > Or is everybody just as busy as I am and this is no good idea? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 jayk123 at hotmail.com Fri Apr 18 12:19:07 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Apr 2008 10:19:07 +0000 Subject: [M3devel] bootstrap and Compiler.i3 change? Message-ID: What is the deal with building and the Compiler.i3 change? I had difficulty here, despite using upgrade.py and upgrade.sh that have gotten things correct before (and I understand what they are doing). I ended up doing something that didn't make sense to me and I got past it, but then I had another problem. I ran ugprade until it failed -- it built/shipped compiler and m3core; then libm3 fails. Then I think I ran either do-cm3-front.py, or I rolled back tools and then ran do-cm3-front.py. I understand the change to Compiler.i3. It should be ok. It is in m3core, build/ship that and then build libm3 should work, right? The code that is actually using Compiler.i3 is for fairly unused targets, however it actually sets a good example I intend to follow. Rather than probing for what Pathname.Join returns a\b or a/b, you can check Compiler.Platform or whatnot directly. But if there are more uses of this, outside m3core, this build problem needs to be understood. Probably I'm just missing something? The other problem I ran into was, merely running a particular cm3 with no parameters, crash in module initialization: (gdb) r Starting program: /home/jkrell/cm3/bin/cm3 Failed to read a valid object file image from memory. [Thread debugging using libthread_db enabled] [New Thread -1210100032 (LWP 32329)] *** *** runtime error: *** Attempt to reference an illegal memory location. *** file "../src/runtime/common/RTAllocator.m3", line 203 *** Program received signal SIGABRT, Aborted. [Switching to Thread -1210100032 (LWP 32329)] 0xb7f6d410 in ?? () (gdb) bt #0 0xb7f6d410 in ?? () #1 0xbfa24f6c in ?? () #2 0x00000006 in ?? () #3 0x00007e49 in ?? () #4 0xb7e1e811 in raise () from /lib/tls/i686/cmov/libc.so.6 #5 0xb7e1ffb9 in abort () from /lib/tls/i686/cmov/libc.so.6 #6 0x082c4cfe in RTOS__Crash () at ../src/runtime/POSIX/RTOS.m3:20 #7 0x082ba6c5 in RTProcess__Crash (M3_Bd56fi_msg=0x0) at ../src/runtime/common/RTProcess.m3:65 #8 0x082b7e8e in RTError__EndError (M3_AicXUJ_crash=1 '\001') at ../src/runtime/common/RTError.m3:118 #9 0x082b7b52 in RTError__MsgS (M3_AJWxb1_file=0x8359a68, M3_AcxOUs_line=203, M3_Bd56fi_msgA=0x835cd48, M3_Bd56fi_msgB=0x8358f14, M3_Bd56fi_msgC=0x835cd48) at ../src/runtime/common/RTError.m3:40 #10 0x082b8314 in RTException__Crash (M3_Cblw37_a=0xbfa252d8, M3_AicXUJ_raises=0 '\0', M3_AJWxb1_rte=0x8358d00) at ../src/runtime/common/RTException.m3:79 #11 0x082b801d in RTException__DefaultBackstop (M3_Cblw37_a=0xbfa252d8, M3_AicXUJ_raises=0 '\0') at ../src/runtime/common/RTException.m3:39 #12 0x082b7f59 in RTException__InvokeBackstop (M3_Cblw37_a=0xbfa252d8, M3_AicXUJ_raises=0 '\0') at ../src/runtime/common/RTException.m3:25 #13 0x082c5f90 in RTException__Raise (M3_Cblw37_act=0xbfa252d8) at ../src/runtime/ex_frame/RTExFrame.m3:29 #14 0x082b80b6 in RTException__DefaultBackstop (M3_Cblw37_a=0xbfa252d8, M3_AicXUJ_raises=0 '\0') at ../src/runtime/common/RTException.m3:47 #15 0x082b7f59 in RTException__InvokeBackstop (M3_Cblw37_a=0xbfa252d8, M3_AicXUJ_raises=0 '\0') at ../src/runtime/common/RTException.m3:25 #16 0x082c5f90 in RTException__Raise (M3_Cblw37_act=0xbfa252d8) at ../src/runtime/ex_frame/RTExFrame.m3:29 #17 0x082a380f in RTHooks__ReportFault (M3_AJWxb1_module=0x8359aa0, M3_AcxOUs_info=6500) at ../src/runtime/common/RTHooks.m3:110 #18 0x082a5c81 in _m3_fault (M3_AcxOUs_arg=6500) ---Type to continue, or q to quit--- #19 0x082a497e in RTAllocator__GetTracedObj (M3_Eic7CK_def=0x0) at ../src/runtime/common/RTAllocator.m3:203 #20 0x082a4524 in RTHooks__AllocateTracedObj (M3_AJWxb1_defn=0x0) at ../src/runtime/common/RTAllocator.m3:131 #21 0x08272fae in Pathname__Decompose (M3_Bd56fi_pn=0xb7dbb02c) at ../src/os/POSIX/PathnamePosix.m3:31 #22 0x08104d95 in PathRepr__Root (M3_Bd56fi_pn=0xb7dbb02c) at PathReprCommon.m3:37 #23 0x08104e7f in PathReprCommon_M3 (M3_AcxOUs_mode=1) at PathReprCommon.m3:45 #24 0x082b6e9b in RTLinker__RunMainBody (M3_DjPxE3_m=0x830b380) at ../src/runtime/common/RTLinker.m3:399 #25 0x082b6b67 in RTLinker__RunMainBody (M3_DjPxE3_m=0x830a280) at ../src/runtime/common/RTLinker.m3:379 #26 0x082b6b67 in RTLinker__RunMainBody (M3_DjPxE3_m=0x8309c00) at ../src/runtime/common/RTLinker.m3:379 #27 0x082b6b67 in RTLinker__RunMainBody (M3_DjPxE3_m=0x8308360) at ../src/runtime/common/RTLinker.m3:379 #28 0x082b6b67 in RTLinker__RunMainBody (M3_DjPxE3_m=0x8305c00) at ../src/runtime/common/RTLinker.m3:379 #29 0x082b6b67 in RTLinker__RunMainBody (M3_DjPxE3_m=0x82f91e0) at ../src/runtime/common/RTLinker.m3:379 #30 0x082b6b67 in RTLinker__RunMainBody (M3_DjPxE3_m=0x82f89a0) at ../src/runtime/common/RTLinker.m3:379 #31 0x082b6b67 in RTLinker__RunMainBody (M3_DjPxE3_m=0x82fccc0) at ../src/runtime/common/RTLinker.m3:379 #32 0x082b5911 in RTLinker__AddUnitI (M3_DjPxE3_m=0x82fccc0) at ../src/runtime/common/RTLinker.m3:113 #33 0x082b599f in RTLinker__AddUnit (M3_DjPxE5_b=0x808e9a2) at ../src/runtime/common/RTLinker.m3:122 #34 0x08057038 in main (argc=1, argv=0xbfa25eb4, envp=0xbfa25ebc) at _m3main.mc:4 which I'll look into further if I still see it, later.. - Jay From wagner at elegosoft.com Fri Apr 18 12:40:02 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 18 Apr 2008 12:40:02 +0200 Subject: [M3devel] bootstrap and Compiler.i3 change? In-Reply-To: References: Message-ID: <20080418124002.rc7rondrwkc04go8@mail.elegosoft.com> Quoting Jay : > What is the deal with building and the Compiler.i3 change? > I had difficulty here, despite using upgrade.py and upgrade.sh that > have gotten things correct before (and I understand what they are > doing). > > I ended up doing something that didn't make sense to me and I got > past it, but then I had another problem. > > I ran ugprade until it failed -- it built/shipped compiler and > m3core; then libm3 fails. > Then I think I ran either do-cm3-front.py, or I rolled back tools > and then ran do-cm3-front.py. > > I understand the change to Compiler.i3. It should be ok. It is in > m3core, build/ship that and then build libm3 should work, right? > > The code that is actually using Compiler.i3 is for fairly unused > targets, however it actually sets a good example I intend to follow. > Rather than probing for what Pathname.Join returns a\b or a/b, you > can check Compiler.Platform or whatnot directly. > But if there are more uses of this, outside m3core, this build > problem needs to be understood. > Probably I'm just missing something? Are you sure you didn't just forget to clean everything after building the first cm3? upgrade.sh should do it right though... My own regression tests at home seem to have recoverd from the target extension without further help (except for the new required libraries), too, so I'm quite sure that upgrade.sh does the right things. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Fri Apr 18 13:28:43 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Apr 2008 11:28:43 +0000 Subject: [M3devel] bootstrap and Compiler.i3 change? In-Reply-To: <20080418124002.rc7rondrwkc04go8@mail.elegosoft.com> References: <20080418124002.rc7rondrwkc04go8@mail.elegosoft.com> Message-ID: I really thought I did the right thing. Hm. I will have to start over. And I'm seeing this again on birch, alas: at ../src/runtime/ex_frame/RTExFrame.m3:29 #17 0x082a394b in RTHooks__ReportFault (M3_AJWxb1_module=0x8359be0, M3_AcxOUs_info=6500) at ../src/runtime/common/RTHooks.m3:110 #18 0x082a5dbd in _m3_fault (M3_AcxOUs_arg=6500) ---Type to continue, or q to quit--- #19 0x082a4aba in RTAllocator__GetTracedObj (M3_Eic7CK_def=0x0) at ../src/runtime/common/RTAllocator.m3:203 #20 0x082a4660 in RTHooks__AllocateTracedObj (M3_AJWxb1_defn=0x0) at ../src/runtime/common/RTAllocator.m3:131 #21 0x082730ea in Pathname__Decompose (M3_Bd56fi_pn=0xb7e1302c) at ../src/os/POSIX/PathnamePosix.m3:31 #22 0x08104ed1 in PathRepr__Root (M3_Bd56fi_pn=0xb7e1302c) at ../src/PathReprCommon.m3:37 #23 0x08104fbb in PathReprCommon_M3 (M3_AcxOUs_mode=1) at ../src/PathReprCommon.m3:45 #24 0x082b6fd7 in RTLinker__RunMainBody (M3_DjPxE3_m=0x830b4c0) I have AMD64 host building an x86 hosted x86/AMD64 target compiler now..and if you change "make" to "make all-gcc", it does a lot less...though still wastes time building unneeded stuff. - Jay > Date: Fri, 18 Apr 2008 12:40:02 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] bootstrap and Compiler.i3 change? > > Quoting Jay : > >> What is the deal with building and the Compiler.i3 change? >> I had difficulty here, despite using upgrade.py and upgrade.sh that >> have gotten things correct before (and I understand what they are >> doing). >> >> I ended up doing something that didn't make sense to me and I got >> past it, but then I had another problem. >> >> I ran ugprade until it failed -- it built/shipped compiler and >> m3core; then libm3 fails. >> Then I think I ran either do-cm3-front.py, or I rolled back tools >> and then ran do-cm3-front.py. >> >> I understand the change to Compiler.i3. It should be ok. It is in >> m3core, build/ship that and then build libm3 should work, right? >> >> The code that is actually using Compiler.i3 is for fairly unused >> targets, however it actually sets a good example I intend to follow. >> Rather than probing for what Pathname.Join returns a\b or a/b, you >> can check Compiler.Platform or whatnot directly. >> But if there are more uses of this, outside m3core, this build >> problem needs to be understood. >> Probably I'm just missing something? > > Are you sure you didn't just forget to clean everything after > building the first cm3? upgrade.sh should do it right though... > > My own regression tests at home seem to have recoverd from the > target extension without further help (except for the new required > libraries), too, so I'm quite sure that upgrade.sh does the right > things. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 18 16:15:51 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 18 Apr 2008 10:15:51 -0400 Subject: [M3devel] TOT CM3 compile. In-Reply-To: References: <7F1A2BCF-BBFE-4C62-B74C-255D29A31183@cs.purdue.edu> Message-ID: <5A42A212-D002-4ADA-9BF5-E170B7E7C9C3@cs.purdue.edu> I haven't touched that portion of things (bash syntax). Jay may be the culprit. :-) On Apr 18, 2008, at 1:37 AM, Alex Bochannek wrote: > Tony Hosking writes: > >> Because there is now a new target, you need to first build a >> bootstrap >> compiler that understands the new target specs. To build a bootstrap >> compiler, compile and ship the following packages: > > That's what happens when I can't pay attention to the mailing list > for a > while. Suddenly everything changes :-) Building right now... > > Couple of related things. > > I happened to be looking at script/boot-cm3-core.sh and noticed that > there some Bash syntax crept in. You touched that file more recently > and > since it is a bit late for me, I thought maybe you can check if I've > got > the logic right in the replacement for the -ot operator > > Index: boot-cm3-core.sh > =================================================================== > RCS file: /usr/cvs/cm3/scripts/boot-cm3-core.sh,v > retrieving revision 1.9 > diff -u -r1.9 boot-cm3-core.sh > --- boot-cm3-core.sh 13 Apr 2008 18:22:32 -0000 1.9 > +++ boot-cm3-core.sh 18 Apr 2008 05:37:02 -0000 > @@ -25,7 +25,7 @@ > BUILDARGS="${BUILDARGS:--DM3_BOOTSTRAP=TRUE -keep}" > M3CONFIG_SRC=${ROOT}/m3-sys/cm3/src/config/${CROSS_TARGET} > M3CONFIG=${ROOT}/scripts/${TARGET}-${CROSS_TARGET}.cfg > -if [ ! -f "${M3CONFIG}" -o "${M3CONFIG}" -ot "${M3CONFIG_SRC}" ] ; > then > +if [ ! -f "${M3CONFIG}" -o -z `find "${M3CONFIG}" -prune -newer "$ > {M3CONFIG_SRC}"` ] ; then > sed -e "s;m3back.*=.*;m3back = \"@${ROOT}/m3-sys/m3cc/${TARGET}-$ > {CROSS_TARGET}/cm3cg\";" \ > ${M3CONFIG_SRC} > ${M3CONFIG} > fi > > > I noticed that the new GCC needs GMP and MPFR. I can't install > anything > in /usr on my machine (it's a zone on a Solaris server) and instead > use > Blastwave, which puts things into /opt/csw. The only way to tell the > build process where to pick up the libraries is by modifying line > 319 in > m3-sys/m3cc/src/m3makefile. Is there a better way? > > Thanks, > > Alex. From jayk123 at hotmail.com Fri Apr 18 16:58:02 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Apr 2008 14:58:02 +0000 Subject: [M3devel] TOT CM3 compile. In-Reply-To: <5A42A212-D002-4ADA-9BF5-E170B7E7C9C3@cs.purdue.edu> References: <7F1A2BCF-BBFE-4C62-B74C-255D29A31183@cs.purdue.edu> <5A42A212-D002-4ADA-9BF5-E170B7E7C9C3@cs.purdue.edu> Message-ID: > gmp/mpfr Go ahead and either: cm3 -DM3CC_CONFIG="...lots..." which should circument a bunch of the m3makefile content, or edit the m3makefile to probe for your location. /Presumably/ nobody is going to have anything there, that they don't mind getting used in this way. ? The whole m3-sys/m3cc/m3makefile could be considered "optional". It's a "thin" wrapper over just building gcc. It tries to do the right thing in "all" situations, but I'm sure it often fails or is incomplete, such as for cross builds. This is my newfound wisdom from just this week, still subject to sinking in and being wrong. :) > bash syntax Sorry I really don't know what is sh vs. ksh vs. bash. Does anyone know of an implementation that adheres closely to sh that I can use to stop regressing stuff? Preferably that runs on one or more of: MacOS X (PowerPC for now) x86 or AMD64 or PowerPC Linux x86 or AMD64 NT Kubuntu (that I'm using) has "dash" for /bin/sh. Good? Or some flag I should use for bash? I can check the docs, but, next two points: I do usually use the Python stuff, partly to avoid this problem. Oh, but this about boot*.sh. I never looked at, ran, or changed that, sorry. Really...writing scripts/python and quake/m3makefile is usually relatively fun and productive but not this *.sh :) - Jay > From: hosking at cs.purdue.edu > To: alexb at juniper.net > Date: Fri, 18 Apr 2008 10:15:51 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] TOT CM3 compile. > > I haven't touched that portion of things (bash syntax). Jay may be > the culprit. :-) > > On Apr 18, 2008, at 1:37 AM, Alex Bochannek wrote: > > > Tony Hosking writes: > > > >> Because there is now a new target, you need to first build a > >> bootstrap > >> compiler that understands the new target specs. To build a bootstrap > >> compiler, compile and ship the following packages: > > > > That's what happens when I can't pay attention to the mailing list > > for a > > while. Suddenly everything changes :-) Building right now... > > > > Couple of related things. > > > > I happened to be looking at script/boot-cm3-core.sh and noticed that > > there some Bash syntax crept in. You touched that file more recently > > and > > since it is a bit late for me, I thought maybe you can check if I've > > got > > the logic right in the replacement for the -ot operator > > > > Index: boot-cm3-core.sh > > =================================================================== > > RCS file: /usr/cvs/cm3/scripts/boot-cm3-core.sh,v > > retrieving revision 1.9 > > diff -u -r1.9 boot-cm3-core.sh > > --- boot-cm3-core.sh 13 Apr 2008 18:22:32 -0000 1.9 > > +++ boot-cm3-core.sh 18 Apr 2008 05:37:02 -0000 > > @@ -25,7 +25,7 @@ > > BUILDARGS="${BUILDARGS:--DM3_BOOTSTRAP=TRUE -keep}" > > M3CONFIG_SRC=${ROOT}/m3-sys/cm3/src/config/${CROSS_TARGET} > > M3CONFIG=${ROOT}/scripts/${TARGET}-${CROSS_TARGET}.cfg > > -if [ ! -f "${M3CONFIG}" -o "${M3CONFIG}" -ot "${M3CONFIG_SRC}" ] ; > > then > > +if [ ! -f "${M3CONFIG}" -o -z `find "${M3CONFIG}" -prune -newer "$ > > {M3CONFIG_SRC}"` ] ; then > > sed -e "s;m3back.*=.*;m3back = \"@${ROOT}/m3-sys/m3cc/${TARGET}-$ > > {CROSS_TARGET}/cm3cg\";" \ > > ${M3CONFIG_SRC} > ${M3CONFIG} > > fi > > > > > > I noticed that the new GCC needs GMP and MPFR. I can't install > > anything > > in /usr on my machine (it's a zone on a Solaris server) and instead > > use > > Blastwave, which puts things into /opt/csw. The only way to tell the > > build process where to pick up the libraries is by modifying line > > 319 in > > m3-sys/m3cc/src/m3makefile. Is there a better way? > > > > Thanks, > > > > Alex. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Apr 18 17:01:32 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Apr 2008 15:01:32 +0000 Subject: [M3devel] whitespace rationale? Message-ID: Does anyone know of a reason to put a space between a function and the paren to start its call? Other than "When in Rome"? I've long not put that in, but I see a fair amount of code that does, and a fair amount of code that I didn't write that doesn't (e.g. sysutils). Seems to be all over the place, but a lot of Modula-3 code puts it in (not that I have seen much Modula-3 code in the world...but...) Similarly for array indexing array [index] vs. array[index]. (Not to mention if (expr) and not if ( expr ). Modula-3 (and Python!) doesn't require the parens so it comes up less often.) I always like to know why.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Apr 18 17:13:24 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Apr 2008 15:13:24 +0000 Subject: [M3devel] some multi-arch conclusions Message-ID: When cm3cg --help prints -m32 [enabled] -m64 [disabled] enabled/disabled is the present (default) setting. It doesn't indicate if the compiler supports the flag. To see the meaning of the switch spelled out, use cm3cg --quiet --help. Found by searching the code for [enabled]. Seems backwards, and gcc/cc1 don't work this way. No matter. To see if the switch works, try running it: cm3cg -m32 cm3cg -m64 Some variants will give a clear error that the feature isn't there. Otherwise press control-d (or z) twice to exit. AMD64 hosts by default can target 64 bit and 32 bit. PowerPC and SPARC ought to be the same imho but I don't think they are (yet). I saw some mail thread people asking for this for PowerPC. The docs indicate it is there for PowerPC. The code or the ChangeLog at least shows churn here for SPARC. 32 bit hosts do not default to being able to target multiple architectures. But you can configure them so: x86 hosts can be configured to have a working -m64 switch via --enable-targets=all or --enable-targets=i686-pc-linux-gnu,amd64-pc-linux-gnu Same for 32 bit PowerPC I think, and maybe SPARC. Those same switches should work for AMD64 hosts, but it is the default. I guess you might be able to trim out the x86 target via --enable-targets-amd64-pc-linux-gnu or --disable-targets=i686-pc-linux-gnu, but I didn't try that. There is a term "biarch" or "bi-arch" for "two architectures". When searching the code, be sure to also look for bi-arch. Searching the web I see people refer to --enable-biarch, but I don't believe there is any "biarch" flag anywhere in gcc. Just this --enable-targets=all. And --multilibs stuff. I can't speak to glibc and binutils. Perhaps biarch does mean something in the code. Or maybe it used to. That's what I know. Tony -- your multiarch cm3cg may or may not run on x86. As I understand, there are both 32 bit and 64 bit Intel Macintoshes out there. The first generation were "Core" not "Core 2" and no 64 bit. In the hardware. And presumably in the software. I don't know when they enabled 64 bit Intel. Lately I believe all Intel Macintoshes are 64 bit hardware. I don't know if therefore they can all run 64 bit user mode code, or if this isn't always enabled. I'm not sure if the kernel is 32 bit or 64 bit but we don't care, I'm sure. Historically we have built WAY more of gcc than is generally needed. I can see there being bootstrap scenarios from Sun/IBM/SGI tools, and whatnot, and certainly gcc needs this stuff, they need the bootstrap scenario, etc. However for Modula-3, on systems with a reasonably current gcc already, lots of extra. My machine also took hours to build m3cc recently and now just 7 minutes. Yeah. Later, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Apr 18 17:18:43 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Apr 2008 15:18:43 +0000 Subject: [M3devel] current failures? Message-ID: If anyone else sees this consistently, please let me know. There's only about two of us under suspicion. :) If it's just me, on Birch, I try not to worry too much. I have to take a break but will test out more to see if it occurs, like on PPC_DARWIN, NT386GNU, NT386.. Hopefully the Tinderbox is back under way. % gdb cm3 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 "i486-linux-gnu"...Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (gdb) r Starting program: /home/jkrell/cm3/bin/cm3 Failed to read a valid object file image from memory. [Thread debugging using libthread_db enabled] [New Thread -1210534208 (LWP 5467)] *** *** runtime error: *** Attempt to reference an illegal memory location. *** file "../src/runtime/common/RTAllocator.m3", line 203 *** Program received signal SIGABRT, Aborted. [Switching to Thread -1210534208 (LWP 5467)] 0xb7f03410 in ?? () (gdb) bt #0 0xb7f03410 in ?? () #1 0xbfbfa93c in ?? () #2 0x00000006 in ?? () #3 0x0000155b in ?? () #4 0xb7db4811 in raise () from /lib/tls/i686/cmov/libc.so.6 #5 0xb7db5fb9 in abort () from /lib/tls/i686/cmov/libc.so.6 #6 0x082c4e36 in RTOS__Crash () at ../src/runtime/POSIX/RTOS.m3:20 #7 0x082ba7fd in RTProcess__Crash (M3_Bd56fi_msg=0x0) at ../src/runtime/common/RTProcess.m3:65 #8 0x082b7fc6 in RTError__EndError (M3_AicXUJ_crash=1 '\001') at ../src/runtime/common/RTError.m3:118 #9 0x082b7c8a in RTError__MsgS (M3_AJWxb1_file=0x8359ba8, M3_AcxOUs_line=203, M3_Bd56fi_msgA=0x835ce88, M3_Bd56fi_msgB=0x8359054, M3_Bd56fi_msgC=0x835ce88) at ../src/runtime/common/RTError.m3:40 #10 0x082b844c in RTException__Crash (M3_Cblw37_a=0xbfbfaca8, M3_AicXUJ_raises=0 '\0', M3_AJWxb1_rte=0x8358e40) at ../src/runtime/common/RTException.m3:79 #11 0x082b8155 in RTException__DefaultBackstop (M3_Cblw37_a=0xbfbfaca8, M3_AicXUJ_raises=0 '\0') at ../src/runtime/common/RTException.m3:39 #12 0x082b8091 in RTException__InvokeBackstop (M3_Cblw37_a=0xbfbfaca8, M3_AicXUJ_raises=0 '\0') at ../src/runtime/common/RTException.m3:25 #13 0x082c60c8 in RTException__Raise (M3_Cblw37_act=0xbfbfaca8) at ../src/runtime/ex_frame/RTExFrame.m3:29 #14 0x082b81ee in RTException__DefaultBackstop (M3_Cblw37_a=0xbfbfaca8, M3_AicXUJ_raises=0 '\0') at ../src/runtime/common/RTException.m3:47 #15 0x082b8091 in RTException__InvokeBackstop (M3_Cblw37_a=0xbfbfaca8, M3_AicXUJ_raises=0 '\0') at ../src/runtime/common/RTException.m3:25 #16 0x082c60c8 in RTException__Raise (M3_Cblw37_act=0xbfbfaca8) at ../src/runtime/ex_frame/RTExFrame.m3:29 #17 0x082a3947 in RTHooks__ReportFault (M3_AJWxb1_module=0x8359be0, M3_AcxOUs_info=6500) at ../src/runtime/common/RTHooks.m3:110 #18 0x082a5db9 in _m3_fault (M3_AcxOUs_arg=6500) ---Type to continue, or q to quit--- #19 0x082a4ab6 in RTAllocator__GetTracedObj (M3_Eic7CK_def=0x0) at ../src/runtime/common/RTAllocator.m3:203 #20 0x082a465c in RTHooks__AllocateTracedObj (M3_AJWxb1_defn=0x0) at ../src/runtime/common/RTAllocator.m3:131 #21 0x082730e6 in Pathname__Decompose (M3_Bd56fi_pn=0xb7d5102c) at ../src/os/POSIX/PathnamePosix.m3:31 #22 0x08104ecd in PathRepr__Root (M3_Bd56fi_pn=0xb7d5102c) at ../src/PathReprCommon.m3:37 #23 0x08104fb7 in PathReprCommon_M3 (M3_AcxOUs_mode=1) at ../src/PathReprCommon.m3:45 #24 0x082b6fd3 in RTLinker__RunMainBody (M3_DjPxE3_m=0x830b4c0) at ../src/runtime/common/RTLinker.m3:399 #25 0x082b6c9f in RTLinker__RunMainBody (M3_DjPxE3_m=0x830a3c0) at ../src/runtime/common/RTLinker.m3:379 #26 0x082b6c9f in RTLinker__RunMainBody (M3_DjPxE3_m=0x8309d40) at ../src/runtime/common/RTLinker.m3:379 #27 0x082b6c9f in RTLinker__RunMainBody (M3_DjPxE3_m=0x83084a0) at ../src/runtime/common/RTLinker.m3:379 #28 0x082b6c9f in RTLinker__RunMainBody (M3_DjPxE3_m=0x8305d40) at ../src/runtime/common/RTLinker.m3:379 #29 0x082b6c9f in RTLinker__RunMainBody (M3_DjPxE3_m=0x82f9320) at ../src/runtime/common/RTLinker.m3:379 #30 0x082b6c9f in RTLinker__RunMainBody (M3_DjPxE3_m=0x82f8ae0) at ../src/runtime/common/RTLinker.m3:379 #31 0x082b6c9f in RTLinker__RunMainBody (M3_DjPxE3_m=0x82fce00) at ../src/runtime/common/RTLinker.m3:379 #32 0x082b5a49 in RTLinker__AddUnitI (M3_DjPxE3_m=0x82fce00) at ../src/runtime/common/RTLinker.m3:113 #33 0x082b5ad7 in RTLinker__AddUnit (M3_DjPxE5_b=0x808e9a0) at ../src/runtime/common/RTLinker.m3:122 #34 0x08057038 in main (argc=1, argv=0xbfbfb884, envp=0xbfbfb88c) at _m3main.mc:4 Thanks, - Jay From hosking at cs.purdue.edu Fri Apr 18 18:02:04 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 18 Apr 2008 12:02:04 -0400 Subject: [M3devel] whitespace rationale? In-Reply-To: References: Message-ID: <1E08B814-50D5-4A19-930F-76725E6BF426@cs.purdue.edu> Purely a matter of style. I generally don't put the space for calls: EVAL f(); but I do for declarations: PROCEDURE f () = ... just so that when I want to search for a local declaration I can easily do that with a text search for "f ()". Just my 2 cents. However, when editing code in any one style, I tend to preserve the style. On Apr 18, 2008, at 11:01 AM, Jay wrote: > Does anyone know of a reason to put a space between a function and > the paren to start its call? > Other than "When in Rome"? > > I've long not put that in, but I see a fair amount of code that > does, and a fair amount of code that I didn't write that doesn't > (e.g. sysutils). > Seems to be all over the place, but a lot of Modula-3 code puts it > in (not that I have seen much Modula-3 code in the world...but...) > > Similarly for array indexing array [index] vs. array[index]. > > (Not to mention if (expr) and not if ( expr ). Modula-3 (and > Python!) doesn't require the parens so it comes up less often.) > > I always like to know why.. > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Apr 18 18:03:56 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 18 Apr 2008 12:03:56 -0400 Subject: [M3devel] some multi-arch conclusions In-Reply-To: References: Message-ID: On Apr 18, 2008, at 11:13 AM, Jay wrote: > 32 bit hosts do not default to being able to target multiple > architectures. My x86 Mac OS X box seems to. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Apr 18 18:32:02 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Apr 2008 16:32:02 +0000 Subject: [M3devel] whitespace rationale? In-Reply-To: <1E08B814-50D5-4A19-930F-76725E6BF426@cs.purdue.edu> References: <1E08B814-50D5-4A19-930F-76725E6BF426@cs.purdue.edu> Message-ID: I like the function names at the first column to find definitions, but lots of folks don't do that and it is rare/nonexistant in cm3. :( Granted, your way doesn't require a regexp search. Subtle, but also very useful, one of those things that most folks wouldn't think of -- not just style, but style with function. Of course, it's arbitrary which of the two ways, I think. A parameter per line also eases diff/merge, but uses a lot of vertical space.. I still think it's worth coming up with a style and a rationale for new code. Not necessarily in this forum :). It's not all maintenance hopefully. (And yeah I've heard of syntax tree editors that present the text in the user's preferred style. Been an open research question for probably decades now. Plain text in regular file systems wins.) - Jay ________________________________ > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jayk123 at hotmail.com > Subject: Re: [M3devel] whitespace rationale? > Date: Fri, 18 Apr 2008 12:02:04 -0400 > > Purely a matter of style. I generally don't put the space for calls: > > EVAL f(); > > but I do for declarations: > > PROCEDURE f () = ... > > just so that when I want to search for a local declaration I can easily do that with a text search for "f ()". Just my 2 cents. > > However, when editing code in any one style, I tend to preserve the style. > > On Apr 18, 2008, at 11:01 AM, Jay wrote: > Does anyone know of a reason to put a space between a function and the paren to start its call? > Other than "When in Rome"? > > I've long not put that in, but I see a fair amount of code that does, and a fair amount of code that I didn't write that doesn't (e.g. sysutils). > Seems to be all over the place, but a lot of Modula-3 code puts it in (not that I have seen much Modula-3 code in the world...but...) > > Similarly for array indexing array [index] vs. array[index]. > > (Not to mention if (expr) and not if ( expr ). Modula-3 (and Python!) doesn't require the parens so it comes up less often.) > > I always like to know why.. > > - Jay From mika at async.caltech.edu Fri Apr 18 19:30:41 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 18 Apr 2008 10:30:41 -0700 Subject: [M3devel] whitespace rationale? In-Reply-To: Your message of "Fri, 18 Apr 2008 15:01:32 -0000." Message-ID: <200804181730.m3IHUfF0049162@camembert.async.caltech.edu> Dunno, but "m3pp -callspace" does it that way... someone at SRC liked that style?? Mika Jay writes: >--_04796398-baf6-48c8-ba84-074241a4e579_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Does anyone know of a reason to put a space between a function and the pare= >n to start its call? >Other than "When in Rome"? > >I've long not put that in, but I see a fair amount of code that does, and a= > fair amount of code that I didn't write that doesn't (e.g. sysutils). >Seems to be all over the place, but a lot of Modula-3 code puts it in (not = >that I have seen much Modula-3 code in the world...but...) > >Similarly for array indexing array [index] vs. array[index]. > >(Not to mention if (expr) and not if ( expr ). Modula-3 (and Python!) doesn= >'t require the parens so it comes up less often.) > >I always like to know why.. > > - Jay From mika at async.caltech.edu Fri Apr 18 19:34:17 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 18 Apr 2008 10:34:17 -0700 Subject: [M3devel] whitespace rationale? In-Reply-To: Your message of "Fri, 18 Apr 2008 16:32:02 -0000." Message-ID: <200804181734.m3IHYHrw049300@camembert.async.caltech.edu> Jay writes: > >I like the function names at the first column to find definitions, but lots of folks don't do that and it is rare/nonexistant in cm3. :( That's necessary in C, but in Modula-3 you can just search for "EDURE F"! From hosking at cs.purdue.edu Fri Apr 18 19:39:30 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 18 Apr 2008 13:39:30 -0400 Subject: [M3devel] current failures? In-Reply-To: References: Message-ID: <360F3641-769A-4B44-9BF4-3DAD3A805BD6@cs.purdue.edu> Could be an out-of-sync build state. Did you start from clean? On Apr 18, 2008, at 11:18 AM, Jay wrote: > > If anyone else sees this consistently, please let me know. > There's only about two of us under suspicion. :) > If it's just me, on Birch, I try not to worry too much. > I have to take a break but will test out more to see if it occurs, > like on PPC_DARWIN, NT386GNU, NT386.. > > Hopefully the Tinderbox is back under way. > > % gdb cm3 > 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 "i486-linux-gnu"...Using host > libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". > > (gdb) r > Starting program: /home/jkrell/cm3/bin/cm3 > Failed to read a valid object file image from memory. > [Thread debugging using libthread_db enabled] > [New Thread -1210534208 (LWP 5467)] > > > *** > *** runtime error: > *** Attempt to reference an illegal memory location. > *** file "../src/runtime/common/RTAllocator.m3", line 203 > *** > > > Program received signal SIGABRT, Aborted. > [Switching to Thread -1210534208 (LWP 5467)] > 0xb7f03410 in ?? () > (gdb) bt > #0 0xb7f03410 in ?? () > #1 0xbfbfa93c in ?? () > #2 0x00000006 in ?? () > #3 0x0000155b in ?? () > #4 0xb7db4811 in raise () from /lib/tls/i686/cmov/libc.so.6 > #5 0xb7db5fb9 in abort () from /lib/tls/i686/cmov/libc.so.6 > #6 0x082c4e36 in RTOS__Crash () at ../src/runtime/POSIX/RTOS.m3:20 > #7 0x082ba7fd in RTProcess__Crash (M3_Bd56fi_msg=0x0) at ../src/ > runtime/common/RTProcess.m3:65 > #8 0x082b7fc6 in RTError__EndError (M3_AicXUJ_crash=1 '\001') > at ../src/runtime/common/RTError.m3:118 > #9 0x082b7c8a in RTError__MsgS (M3_AJWxb1_file=0x8359ba8, > M3_AcxOUs_line=203, > M3_Bd56fi_msgA=0x835ce88, M3_Bd56fi_msgB=0x8359054, > M3_Bd56fi_msgC=0x835ce88) > at ../src/runtime/common/RTError.m3:40 > #10 0x082b844c in RTException__Crash (M3_Cblw37_a=0xbfbfaca8, > M3_AicXUJ_raises=0 '\0', > M3_AJWxb1_rte=0x8358e40) at ../src/runtime/common/RTException.m3:79 > #11 0x082b8155 in RTException__DefaultBackstop > (M3_Cblw37_a=0xbfbfaca8, M3_AicXUJ_raises=0 '\0') > at ../src/runtime/common/RTException.m3:39 > #12 0x082b8091 in RTException__InvokeBackstop > (M3_Cblw37_a=0xbfbfaca8, M3_AicXUJ_raises=0 '\0') > at ../src/runtime/common/RTException.m3:25 > #13 0x082c60c8 in RTException__Raise (M3_Cblw37_act=0xbfbfaca8) > at ../src/runtime/ex_frame/RTExFrame.m3:29 > #14 0x082b81ee in RTException__DefaultBackstop > (M3_Cblw37_a=0xbfbfaca8, M3_AicXUJ_raises=0 '\0') > at ../src/runtime/common/RTException.m3:47 > #15 0x082b8091 in RTException__InvokeBackstop > (M3_Cblw37_a=0xbfbfaca8, M3_AicXUJ_raises=0 '\0') > at ../src/runtime/common/RTException.m3:25 > #16 0x082c60c8 in RTException__Raise (M3_Cblw37_act=0xbfbfaca8) > at ../src/runtime/ex_frame/RTExFrame.m3:29 > #17 0x082a3947 in RTHooks__ReportFault (M3_AJWxb1_module=0x8359be0, > M3_AcxOUs_info=6500) > at ../src/runtime/common/RTHooks.m3:110 > #18 0x082a5db9 in _m3_fault (M3_AcxOUs_arg=6500) > ---Type to continue, or q to quit--- > #19 0x082a4ab6 in RTAllocator__GetTracedObj (M3_Eic7CK_def=0x0) > at ../src/runtime/common/RTAllocator.m3:203 > #20 0x082a465c in RTHooks__AllocateTracedObj (M3_AJWxb1_defn=0x0) > at ../src/runtime/common/RTAllocator.m3:131 > #21 0x082730e6 in Pathname__Decompose (M3_Bd56fi_pn=0xb7d5102c) > at ../src/os/POSIX/PathnamePosix.m3:31 > #22 0x08104ecd in PathRepr__Root (M3_Bd56fi_pn=0xb7d5102c) at ../src/ > PathReprCommon.m3:37 > #23 0x08104fb7 in PathReprCommon_M3 (M3_AcxOUs_mode=1) at ../src/ > PathReprCommon.m3:45 > #24 0x082b6fd3 in RTLinker__RunMainBody (M3_DjPxE3_m=0x830b4c0) > at ../src/runtime/common/RTLinker.m3:399 > #25 0x082b6c9f in RTLinker__RunMainBody (M3_DjPxE3_m=0x830a3c0) > at ../src/runtime/common/RTLinker.m3:379 > #26 0x082b6c9f in RTLinker__RunMainBody (M3_DjPxE3_m=0x8309d40) > at ../src/runtime/common/RTLinker.m3:379 > #27 0x082b6c9f in RTLinker__RunMainBody (M3_DjPxE3_m=0x83084a0) > at ../src/runtime/common/RTLinker.m3:379 > #28 0x082b6c9f in RTLinker__RunMainBody (M3_DjPxE3_m=0x8305d40) > at ../src/runtime/common/RTLinker.m3:379 > #29 0x082b6c9f in RTLinker__RunMainBody (M3_DjPxE3_m=0x82f9320) > at ../src/runtime/common/RTLinker.m3:379 > #30 0x082b6c9f in RTLinker__RunMainBody (M3_DjPxE3_m=0x82f8ae0) > at ../src/runtime/common/RTLinker.m3:379 > #31 0x082b6c9f in RTLinker__RunMainBody (M3_DjPxE3_m=0x82fce00) > at ../src/runtime/common/RTLinker.m3:379 > #32 0x082b5a49 in RTLinker__AddUnitI (M3_DjPxE3_m=0x82fce00) > at ../src/runtime/common/RTLinker.m3:113 > #33 0x082b5ad7 in RTLinker__AddUnit (M3_DjPxE5_b=0x808e9a0) > at ../src/runtime/common/RTLinker.m3:122 > #34 0x08057038 in main (argc=1, argv=0xbfbfb884, envp=0xbfbfb88c) at > _m3main.mc:4 > > Thanks, > - Jay From rcoleburn at scires.com Fri Apr 18 21:56:28 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 18 Apr 2008 15:56:28 -0400 Subject: [M3devel] whitespace rationale? In-Reply-To: References: <1E08B814-50D5-4A19-930F-76725E6BF426@cs.purdue.edu> Message-ID: <4808C4AE.1E75.00D7.1@scires.com> I have a Modula-3 style guide that I developed for my company a number of years ago. If anyone is interested, I don't mind contributing it to the repository. Regards, Randy >>> Jay 4/18/2008 12:32 PM >>> I like the function names at the first column to find definitions, but lots of folks don't do that and it is rare/nonexistant in cm3. :( Granted, your way doesn't require a regexp search. Subtle, but also very useful, one of those things that most folks wouldn't think of -- not just style, but style with function. Of course, it's arbitrary which of the two ways, I think. A parameter per line also eases diff/merge, but uses a lot of vertical space.. I still think it's worth coming up with a style and a rationale for new code. Not necessarily in this forum :). It's not all maintenance hopefully. (And yeah I've heard of syntax tree editors that present the text in the user's preferred style. Been an open research question for probably decades now. Plain text in regular file systems wins.) - Jay ________________________________ > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jayk123 at hotmail.com > Subject: Re: [M3devel] whitespace rationale? > Date: Fri, 18 Apr 2008 12:02:04 -0400 > > Purely a matter of style. I generally don't put the space for calls: > > EVAL f(); > > but I do for declarations: > > PROCEDURE f () = ... > > just so that when I want to search for a local declaration I can easily do that with a text search for "f ()". Just my 2 cents. > > However, when editing code in any one style, I tend to preserve the style -------------- next part -------------- An HTML attachment was scrubbed... URL: From HOSKING at cs.purdue.edu Fri Apr 18 23:23:24 2008 From: HOSKING at cs.purdue.edu (Tony Hosking) Date: Fri, 18 Apr 2008 17:23:24 -0400 Subject: [M3devel] gmp and mpfr Message-ID: I have added the necessary gmp and mpfr distributions to the m3cc/gcc package. It turns out that gcc will try to build from local source if it is available in the gcc hierarchy. Now, the only question is how to make sure that installs will put things in the right place. One option is to configure gcc to install into INSTALL_ROOT from the m3cc m3makefile. But that would mean a full install of gcc and libraries. Any other thoughts? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Apr 19 01:31:27 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Apr 2008 23:31:27 +0000 Subject: [M3devel] gmp and mpfr In-Reply-To: References: Message-ID: Thanks. > other thoughts? Static link? I should measure the bloat. I accidentally statically linked to libc.a and the bloat was small, I think x86 static was smaller than AMD64 dynamic. > But that would mean a full install of gcc and libraries. Really? Why not just gmp and mpfr and then point configure at them? Besides, if necessary, import them but not under gcc? - Jay From: HOSKING at cs.purdue.edu To: m3devel at elegosoft.com Date: Fri, 18 Apr 2008 17:23:24 -0400 Subject: [M3devel] gmp and mpfr I have added the necessary gmp and mpfr distributions to the m3cc/gcc package. It turns out that gcc will try to build from local source if it is available in the gcc hierarchy. Now, the only question is how to make sure that installs will put things in the right place. One option is to configure gcc to install into INSTALL_ROOT from the m3cc m3makefile. But that would mean a full install of gcc and libraries. Any other thoughts? -------------- next part -------------- An HTML attachment was scrubbed... URL: From neels at elego.de Sat Apr 19 01:43:45 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Sat, 19 Apr 2008 01:43:45 +0200 Subject: [M3devel] Umman.off_t Message-ID: <48093231.8010800@elego.de> Hi, I am having problems deploying the suplib on FreeBSD (FreeBSD new.elego.de 6.2-RELEASE-p3), using the latest cm3 snapshot (cm3-src-all-d5.7.0-2008-04-16-14-07-05.tgz). A type mismatch error is encountered at the last parameter of the call addr := Umman.mmap(NIL, StatBuf.GetStatSize(statbuf), Umman.PROT_READ, Umman.MAP_SHARED, fd, 0); , the zero, that is. The parameter is called "off" and of type off_t. cm3/m3-libs/m3core/src/unix/freebsd-4/Umman.i3 declares the following about off_t: FROM Utypes IMPORT caddr_t, size_t, off_t; <*EXTERNAL*> PROCEDURE mmap (addr: caddr_t; len: size_t; prot,flags,fd: int; off: off_t) : caddr_t; and Utypes.i3 adds: FROM Ctypes IMPORT long, unsigned_long, int, unsigned_int, short, unsigned_short, char, unsigned_char, long_long; TYPE int64_t = long_long; off_t = int64_t; It turns out that using 0L instead of just 0 solves the compilation error on FreeBSD. Yes, but on linux-libc6, Utypes.i3 says something different, and the 0L in turn causes a type mismatch there. So this is a dilemma situation where the porting between linux and FreeBSD involves source code editing - certainly not good. linux-libc6/Utypes.i3: FROM Ctypes IMPORT long, ... off_t = long; Any help? Thanks! -- Neels Hofmeyr -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Sat Apr 19 01:58:41 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Apr 2008 23:58:41 +0000 Subject: [M3devel] Umman.off_t In-Reply-To: <48093231.8010800@elego.de> References: <48093231.8010800@elego.de> Message-ID: Imho constant integer expressions should be promoted silently. But that's just me. Try one of these: ORD (0, off_t) VAL (0, off_t) ORD (off_t, 0) VAL (off_t, 0) - Jay ---------------------------------------- > Date: Sat, 19 Apr 2008 01:43:45 +0200 > From: neels at elego.de > To: m3devel at elego.de > Subject: [M3devel] Umman.off_t > > Hi, > > I am having problems deploying the suplib on FreeBSD (FreeBSD > new.elego.de 6.2-RELEASE-p3), using the latest cm3 snapshot > (cm3-src-all-d5.7.0-2008-04-16-14-07-05.tgz). > > A type mismatch error is encountered at the last parameter of the call > > addr := Umman.mmap(NIL, StatBuf.GetStatSize(statbuf), > Umman.PROT_READ, > Umman.MAP_SHARED, fd, 0); > > , the zero, that is. The parameter is called "off" and of type off_t. > > cm3/m3-libs/m3core/src/unix/freebsd-4/Umman.i3 > > declares the following about off_t: > > > FROM Utypes IMPORT caddr_t, size_t, off_t; > > > PROCEDURE mmap (addr: caddr_t; len: size_t; prot,flags,fd: int; off: off_t) > : caddr_t; > > > and Utypes.i3 adds: > > > FROM Ctypes IMPORT > long, unsigned_long, int, unsigned_int, short, unsigned_short, > char, unsigned_char, long_long; > > TYPE > int64_t = long_long; > > off_t = int64_t; > > > It turns out that using 0L instead of just 0 solves the compilation > error on FreeBSD. > > Yes, but on linux-libc6, Utypes.i3 says something different, and the 0L > in turn causes a type mismatch there. So this is a dilemma situation > where the porting between linux and FreeBSD involves source code editing > - certainly not good. > > linux-libc6/Utypes.i3: > > FROM Ctypes IMPORT > long, ... > off_t = long; > > > Any help? > > Thanks! > > -- > Neels Hofmeyr -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 19 12:43:06 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 19 Apr 2008 12:43:06 +0200 Subject: [M3devel] gmp and mpfr In-Reply-To: References: Message-ID: <20080419124306.oxag3l6ego0owgw0@mail.elegosoft.com> Quoting Jay : > Thanks. > > > other thoughts? > > Static link? > > I should measure the bloat. > I accidentally statically linked to libc.a and the bloat was small, > I think x86 static was smaller than AMD64 dynamic. We must not link _any_ executable completely statically, we've been through that. Modern Unix systems all require dynamic linking, at least for all the standard C libraries. > > But that would mean a full install of gcc and libraries. > > Really? > Why not just gmp and mpfr and then point configure at them? > Besides, if necessary, import them but not under gcc? > > - Jay > > > From: HOSKING at cs.purdue.edu > To: m3devel at elegosoft.com > Date: Fri, 18 Apr 2008 17:23:24 -0400 > Subject: [M3devel] gmp and mpfr > > I have added the necessary gmp and mpfr distributions to the > m3cc/gcc package. It turns out that gcc will try to build from > local source if it is available in the gcc hierarchy. Now, the only > question is how to make sure that installs will put things in the > right place. One option is to configure gcc to install into > INSTALL_ROOT from the m3cc m3makefile. But that would mean a full > install of gcc and libraries. Any other thoughts? If we really need to have these libraries in the distribution, we should either link them in statically or put the shared objects into INSTALL_ROOT/lib. We could either create different packages (that would require adding these to several scripts) or add some special quake code to build them all as part of m3cc: build libgmp ship libgmp to INSTALL_ROOT/lib build mpfr ship mpfr to INSTALL_ROOT/lib configure gcc with --with-mpfr=INSTALL_ROOT/lib/libmpfr.so \ --with-gmp=INSTALL_ROOT/lib/libgmp.so (I don't think the argument are completely correct, but you get the idea.) build gcc ship gcc The problem with this setup is that it wouldn't work for local builds (without shipping), and we'd have problems when the libraries need upgrade and we overwrite them (bootstrap will break). Or ensure proper versioning here (which is nowhere done up=to-now in cm3). Or (in case of build without ship) just specify the locations in the workspace? Then we'd need to re-link cm3cg in case of later build and ship. What do you think? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 19 13:00:13 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 19 Apr 2008 13:00:13 +0200 Subject: [M3devel] gmp and mpfr In-Reply-To: References: Message-ID: <20080419130013.mo2bzawq9kwo0s0g@mail.elegosoft.com> Quoting Tony Hosking : > I have added the necessary gmp and mpfr distributions to the m3cc/gcc > package. It turns out that gcc will try to build from local source if > it is available in the gcc hierarchy. Now, the only question is how > to make sure that installs will put things in the right place. One > option is to configure gcc to install into INSTALL_ROOT from the m3cc > m3makefile. But that would mean a full install of gcc and libraries. > Any other thoughts? After wondering where the libraries might be, I've now found them at /usr/cvs/cm3/m3cc/gcc/{mpfr,gmp}. I think you wanted to import them to usr/cvs/cm3/m3-sys/m3cc/gcc/{mpfr,gmp}, didn't you? Any objections to move them inside the repository (will break existing workspaces and repo copies...) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Sat Apr 19 14:27:38 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Apr 2008 12:27:38 +0000 Subject: [M3devel] gmp and mpfr In-Reply-To: <20080419124306.oxag3l6ego0owgw0@mail.elegosoft.com> References: <20080419124306.oxag3l6ego0owgw0@mail.elegosoft.com> Message-ID: Static linking libc is a different matter. It should work on Linux and NT but I realize it isn't universally supported. I did it by accident. The kernel does have a compatiblity burden, at least where the interfaces have been published. (On NT, the layering is different. You can link statically to libcmt.lib, which to a very large extent is what people think of libc, but it doesn't call the kernel directly, it goes through kernel32.dll, which goes through ntdll.dll, and syscall numbers are not stable.) Anyway, for libgmp and libmpfr, I still think static linking to these two is definitely ok, or better. Whether we import the source is a separate variable -- can still build a static .a file and link to it and drop the runtime dependency. That, or we get to deal with LD_LIBRARY_PATH and/or -rpath. It sure is nice how on Windows you can at least colocate .exes and .dlls in the same directory and the .dlls get found. This is a different matter vs. if current directory is in the search path for .exes. - Jay > Date: Sat, 19 Apr 2008 12:43:06 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] gmp and mpfr > > Quoting Jay : > > > Thanks. > > > > > other thoughts? > > > > Static link? > > > > I should measure the bloat. > > I accidentally statically linked to libc.a and the bloat was small, > > I think x86 static was smaller than AMD64 dynamic. > > We must not link _any_ executable completely statically, we've been > through that. Modern Unix systems all require dynamic linking, at > least for all the standard C libraries. > > > > But that would mean a full install of gcc and libraries. > > > > Really? > > Why not just gmp and mpfr and then point configure at them? > > Besides, if necessary, import them but not under gcc? > > > > - Jay > > > > > > From: HOSKING at cs.purdue.edu > > To: m3devel at elegosoft.com > > Date: Fri, 18 Apr 2008 17:23:24 -0400 > > Subject: [M3devel] gmp and mpfr > > > > I have added the necessary gmp and mpfr distributions to the > > m3cc/gcc package. It turns out that gcc will try to build from > > local source if it is available in the gcc hierarchy. Now, the only > > question is how to make sure that installs will put things in the > > right place. One option is to configure gcc to install into > > INSTALL_ROOT from the m3cc m3makefile. But that would mean a full > > install of gcc and libraries. Any other thoughts? > > If we really need to have these libraries in the distribution, > we should either link them in statically or put the shared objects > into INSTALL_ROOT/lib. We could either create different packages > (that would require adding these to several scripts) or add some > special quake code to build them all as part of m3cc: > > build libgmp > ship libgmp to INSTALL_ROOT/lib > build mpfr > ship mpfr to INSTALL_ROOT/lib > configure gcc with --with-mpfr=INSTALL_ROOT/lib/libmpfr.so \ > --with-gmp=INSTALL_ROOT/lib/libgmp.so > (I don't think the argument are completely correct, but you get the idea.) > build gcc > ship gcc > > The problem with this setup is that it wouldn't work for local builds > (without shipping), and we'd have problems when the libraries need > upgrade and we overwrite them (bootstrap will break). Or ensure > proper versioning here (which is nowhere done up=to-now in cm3). > > Or (in case of build without ship) just specify the locations in the > workspace? Then we'd need to re-link cm3cg in case of later build and > ship. > > What do you think? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 jayk123 at hotmail.com Sat Apr 19 14:41:52 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Apr 2008 12:41:52 +0000 Subject: [M3devel] gmp and mpfr In-Reply-To: <20080419124306.oxag3l6ego0owgw0@mail.elegosoft.com> References: <20080419124306.oxag3l6ego0owgw0@mail.elegosoft.com> Message-ID: Truncated again.. Static linking libc is a different matter. It should work on Linux and NT but I realize it isn't universally supported. I did it by accident. The kernel does have a compatiblity burden, at least where the interfaces have been published. (On NT, the layering is different. You can link statically to libcmt.lib, which to a very large extent is what people think of libc, but it doesn't call the kernel directly, it goes through kernel32.dll, which goes through ntdll.dll, and syscall numbers are not stable.) Anyway, for libgmp and libmpfr, I still think static linking to these two is definitely ok, or better. Whether we import the source is a separate variable -- can still build a static .a file and link to it and drop the runtime dependency. That, or we get to deal with LD_LIBRARY_PATH and/or -rpath. It sure is nice how on Windows you can at least colocate .exes and .dlls in the same directory and the .dlls get found. This is a different matter vs. if current directory is in the search path for .exes. - Jay > Date: Sat, 19 Apr 2008 12:43:06 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] gmp and mpfr > > Quoting Jay : > > > Thanks. > > > > > other thoughts? > > > > Static link? > > > > I should measure the bloat. > > I accidentally statically linked to libc.a and the bloat was small, > > I think x86 static was smaller than AMD64 dynamic. > > We must not link _any_ executable completely statically, we've been > through that. Modern Unix systems all require dynamic linking, at > least for all the standard C libraries. > > > > But that would mean a full install of gcc and libraries. > > > > Really? > > Why not just gmp and mpfr and then point configure at them? > > Besides, if necessary, import them but not under gcc? > > > > - Jay > > > > > > From: HOSKING at cs.purdue.edu > > To: m3devel at elegosoft.com > > Date: Fri, 18 Apr 2008 17:23:24 -0400 > > Subject: [M3devel] gmp and mpfr > > > > I have added the necessary gmp and mpfr distributions to the > > m3cc/gcc package. It turns out that gcc will try to build from > > local source if it is available in the gcc hierarchy. Now, the only > > question is how to make sure that installs will put things in the > > right place. One option is to configure gcc to install into > > INSTALL_ROOT from the m3cc m3makefile. But that would mean a full > > install of gcc and libraries. Any other thoughts? > > If we really need to have these libraries in the distribution, > we should either link them in statically or put the shared objects > into INSTALL_ROOT/lib. We could either create different packages > (that would require adding these to several scripts) or add some > special quake code to build them all as part of m3cc: > > build libgmp > ship libgmp to INSTALL_ROOT/lib > build mpfr > ship mpfr to INSTALL_ROOT/lib > configure gcc with --with-mpfr=INSTALL_ROOT/lib/libmpfr.so \ > --with-gmp=INSTALL_ROOT/lib/libgmp.so > (I don't think the argument are completely correct, but you get the idea.) > build gcc > ship gcc > > The problem with this setup is that it wouldn't work for local builds > (without shipping), and we'd have problems when the libraries need > upgrade and we overwrite them (bootstrap will break). Or ensure > proper versioning here (which is nowhere done up=to-now in cm3). > > Or (in case of build without ship) just specify the locations in the > workspace? Then we'd need to re-link cm3cg in case of later build and > ship. > > What do you think? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 jayk123 at hotmail.com Sat Apr 19 14:55:18 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Apr 2008 12:55:18 +0000 Subject: [M3devel] FW: gmp and mpfr In-Reply-To: <20080419124306.oxag3l6ego0owgw0@mail.elegosoft.com> References: <20080419124306.oxag3l6ego0owgw0@mail.elegosoft.com> Message-ID: truncated yet again, maybe I have to forward instead of reply.. Truncated again.. Static linking libc is a different matter. It should work on Linux and NT but I realize it isn't universally supported. I did it by accident. The kernel does have a compatiblity burden, at least where the interfaces have been published. (On NT, the layering is different. You can link statically to libcmt.lib, which to a very large extent is what people think of libc, but it doesn't call the kernel directly, it goes through kernel32.dll, which goes through ntdll.dll, and syscall numbers are not stable.) Anyway, for libgmp and libmpfr, I still think static linking to these two is definitely ok, or better. Whether we import the source is a separate variable -- can still build a static .a file and link to it and drop the runtime dependency. That, or we get to deal with LD_LIBRARY_PATH and/or -rpath. It sure is nice how on Windows you can at least colocate .exes and .dlls in the same directory and the .dlls get found. This is a different matter vs. if current directory is in the search path for .exes. - Jay > Date: Sat, 19 Apr 2008 12:43:06 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] gmp and mpfr > > Quoting Jay : > > > Thanks. > > > > > other thoughts? > > > > Static link? > > > > I should measure the bloat. > > I accidentally statically linked to libc.a and the bloat was small, > > I think x86 static was smaller than AMD64 dynamic. > > We must not link _any_ executable completely statically, we've been > through that. Modern Unix systems all require dynamic linking, at > least for all the standard C libraries. > > > > But that would mean a full install of gcc and libraries. > > > > Really? > > Why not just gmp and mpfr and then point configure at them? > > Besides, if necessary, import them but not under gcc? > > > > - Jay > > > > > > From: HOSKING at cs.purdue.edu > > To: m3devel at elegosoft.com > > Date: Fri, 18 Apr 2008 17:23:24 -0400 > > Subject: [M3devel] gmp and mpfr > > > > I have added the necessary gmp and mpfr distributions to the > > m3cc/gcc package. It turns out that gcc will try to build from > > local source if it is available in the gcc hierarchy. Now, the only > > question is how to make sure that installs will put things in the > > right place. One option is to configure gcc to install into > > INSTALL_ROOT from the m3cc m3makefile. But that would mean a full > > install of gcc and libraries. Any other thoughts? > > If we really need to have these libraries in the distribution, > we should either link them in statically or put the shared objects > into INSTALL_ROOT/lib. We could either create different packages > (that would require adding these to several scripts) or add some > special quake code to build them all as part of m3cc: > > build libgmp > ship libgmp to INSTALL_ROOT/lib > build mpfr > ship mpfr to INSTALL_ROOT/lib > configure gcc with --with-mpfr=INSTALL_ROOT/lib/libmpfr.so \ > --with-gmp=INSTALL_ROOT/lib/libgmp.so > (I don't think the argument are completely correct, but you get the idea.) > build gcc > ship gcc > > The problem with this setup is that it wouldn't work for local builds > (without shipping), and we'd have problems when the libraries need > upgrade and we overwrite them (bootstrap will break). Or ensure > proper versioning here (which is nowhere done up=to-now in cm3). > > Or (in case of build without ship) just specify the locations in the > workspace? Then we'd need to re-link cm3cg in case of later build and > ship. > > What do you think? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 jayk123 at hotmail.com Sat Apr 19 14:57:48 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Apr 2008 12:57:48 +0000 Subject: [M3devel] FW: gmp and mpfr In-Reply-To: References: <20080419124306.oxag3l6ego0owgw0@mail.elegosoft.com> Message-ID: truncated a second time, I'll try from amother machine, geez short version -- static link libgmp and libmpfr, nothing else static linking libc ought to work imho but that is a different matter; kernels should be compatible with their published interfaces, if they have any -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Apr 19 15:50:00 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Apr 2008 13:50:00 +0000 Subject: [M3devel] gmp and mpfr In-Reply-To: <20080419130013.mo2bzawq9kwo0s0g@mail.elegosoft.com> References: <20080419130013.mo2bzawq9kwo0s0g@mail.elegosoft.com> Message-ID: Isn't it more proper to delete and re-add/re-import in the correct place? I mean, cvs -z3 upd can just work, right? - Jay > Date: Sat, 19 Apr 2008 13:00:13 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] gmp and mpfr > > Quoting Tony Hosking : > > > I have added the necessary gmp and mpfr distributions to the m3cc/gcc > > package. It turns out that gcc will try to build from local source if > > it is available in the gcc hierarchy. Now, the only question is how > > to make sure that installs will put things in the right place. One > > option is to configure gcc to install into INSTALL_ROOT from the m3cc > > m3makefile. But that would mean a full install of gcc and libraries. > > Any other thoughts? > > After wondering where the libraries might be, I've now found them > at /usr/cvs/cm3/m3cc/gcc/{mpfr,gmp}. > I think you wanted to import them to usr/cvs/cm3/m3-sys/m3cc/gcc/{mpfr,gmp}, > didn't you? > Any objections to move them inside the repository (will break existing > workspaces and repo copies...) > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 jayk123 at hotmail.com Sat Apr 19 16:31:32 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Apr 2008 14:31:32 +0000 Subject: [M3devel] a hope for dynamic linking! Message-ID: http://www.eyrie.org/~eagle/notes/rpath.html http://people.debian.org/~che/personal/rpath-considered-harmful but yet: http://www.scons.org/wiki/UsingOrigin So you can either colocate executables and .sos in the same directory or, like /cm3/bin /cm3/lib/m3core.so and vary the install root. We should be using this where available -- Linux, Solaris, Irix. Too bad not supported elsewhere. On Windows you can colocate; the .exe's directory is always searched. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Apr 19 16:40:25 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 19 Apr 2008 10:40:25 -0400 Subject: [M3devel] gmp and mpfr In-Reply-To: <20080419130013.mo2bzawq9kwo0s0g@mail.elegosoft.com> References: <20080419130013.mo2bzawq9kwo0s0g@mail.elegosoft.com> Message-ID: No, the gcc distros are set up to expect them in top-level gcc directory, if at all, along with the other libraries. The configure script will find them there and build locally as necessary rather than finding them in the usual installed places. On Apr 19, 2008, at 7:00 AM, Olaf Wagner wrote: > Quoting Tony Hosking : > >> I have added the necessary gmp and mpfr distributions to the m3cc/gcc >> package. It turns out that gcc will try to build from local source >> if >> it is available in the gcc hierarchy. Now, the only question is how >> to make sure that installs will put things in the right place. One >> option is to configure gcc to install into INSTALL_ROOT from the m3cc >> m3makefile. But that would mean a full install of gcc and libraries. >> Any other thoughts? > > After wondering where the libraries might be, I've now found them > at /usr/cvs/cm3/m3cc/gcc/{mpfr,gmp}. > I think you wanted to import them to usr/cvs/cm3/m3-sys/m3cc/gcc/ > {mpfr,gmp}, > didn't you? > Any objections to move them inside the repository (will break existing > workspaces and repo copies...) > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Sat Apr 19 16:42:54 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 19 Apr 2008 10:42:54 -0400 Subject: [M3devel] gmp and mpfr In-Reply-To: References: <20080419130013.mo2bzawq9kwo0s0g@mail.elegosoft.com> Message-ID: <44D5D5D2-7032-465D-B90E-EBDE9AD7DA75@cs.purdue.edu> Sorry. Looks like they're in the right place now. On Apr 19, 2008, at 9:50 AM, Jay wrote: > Isn't it more proper to delete and re-add/re-import in the correct > place? > I mean, cvs -z3 upd can just work, right? > > - Jay > > > > > Date: Sat, 19 Apr 2008 13:00:13 +0200 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] gmp and mpfr > > > > Quoting Tony Hosking : > > > > > I have added the necessary gmp and mpfr distributions to the > m3cc/gcc > > > package. It turns out that gcc will try to build from local > source if > > > it is available in the gcc hierarchy. Now, the only question is > how > > > to make sure that installs will put things in the right place. One > > > option is to configure gcc to install into INSTALL_ROOT from the > m3cc > > > m3makefile. But that would mean a full install of gcc and > libraries. > > > Any other thoughts? > > > > After wondering where the libraries might be, I've now found them > > at /usr/cvs/cm3/m3cc/gcc/{mpfr,gmp}. > > I think you wanted to import them to usr/cvs/cm3/m3-sys/m3cc/gcc/ > {mpfr,gmp}, > > didn't you? > > Any objections to move them inside the repository (will break > existing > > workspaces and repo copies...) > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Sat Apr 19 16:50:04 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 19 Apr 2008 10:50:04 -0400 Subject: [M3devel] a hope for dynamic linking! In-Reply-To: References: Message-ID: Hold on! I am strongly in favor of static linking for cm3cg/m3cgc1 so that it is a standalone executable. Should be easy enough with gcc configure. On Apr 19, 2008, at 10:31 AM, Jay wrote: > http://www.eyrie.org/~eagle/notes/rpath.html > http://people.debian.org/~che/personal/rpath-considered-harmful > > > but yet: > > http://www.scons.org/wiki/UsingOrigin > > So you can either colocate executables and .sos in the same > directory or, like > /cm3/bin > /cm3/lib/m3core.so > > and vary the install root. > > We should be using this where available -- Linux, Solaris, Irix. > Too bad not supported elsewhere. > On Windows you can colocate; the .exe's directory is always searched. > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Apr 19 17:02:44 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Apr 2008 15:02:44 +0000 Subject: [M3devel] a hope for dynamic linking! In-Reply-To: References: Message-ID: I mean for the "regular" Modula-3 "app" stuff, not cm3cg. It looks like it is already static, good. 1) http://gcc.gnu.org/ml/gcc/2006-10/msg00141.html 2) The current code: m3-sys/m3cc/gcc/Makefile.in: configure-gmp: ... echo Configuring in $(HOST_SUBDIR)/gmp; \ ... $(HOST_CONFIGARGS) --build=${build_alias} --host=none-${host_vendor}-${host_os} \ --target=none-${host_vendor}-${host_os} $${srcdiroption} --disable-shared \ || exit 1 @endif gmp configure-mpfr: ... echo Configuring in $(HOST_SUBDIR)/mpfr; \ ... $(HOST_CONFIGARGS) --build=${build_alias} --host=none-${host_vendor}-${host_os} \ --target=none-${host_vendor}-${host_os} $${srcdiroption} --disable-shared --with-gmp-build=$$r/$(HOST_SUBDIR)/gmp \ || exit 1 @endif mpfr Let me test it and then I'll remove the Quake code related to this. - Jay CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jayk123 at hotmail.com Subject: Re: [M3devel] a hope for dynamic linking! Date: Sat, 19 Apr 2008 10:50:04 -0400 Hold on! I am strongly in favor of static linking for cm3cg/m3cgc1 so that it is a standalone executable. Should be easy enough with gcc configure. On Apr 19, 2008, at 10:31 AM, Jay wrote:http://www.eyrie.org/~eagle/notes/rpath.html http://people.debian.org/~che/personal/rpath-considered-harmful but yet: http://www.scons.org/wiki/UsingOrigin So you can either colocate executables and .sos in the same directory or, like /cm3/bin /cm3/lib/m3core.so and vary the install root. We should be using this where available -- Linux, Solaris, Irix. Too bad not supported elsewhere. On Windows you can colocate; the .exe's directory is always searched. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Apr 19 17:10:16 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Apr 2008 15:10:16 +0000 Subject: [M3devel] a hope for dynamic linking! In-Reply-To: References: Message-ID: (ok, actually I meant maybe for cm3cg but ok either way, there'd only be one use of "/usr/local/cm3/bin/libgmp.so" so might as well be static) From: jayk123 at hotmail.com To: hosking at cs.purdue.edu Date: Sat, 19 Apr 2008 15:02:44 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] a hope for dynamic linking! I mean for the "regular" Modula-3 "app" stuff, not cm3cg. It looks like it is already static, good. 1) http://gcc.gnu.org/ml/gcc/2006-10/msg00141.html 2) The current code: m3-sys/m3cc/gcc/Makefile.in: configure-gmp: ... echo Configuring in $(HOST_SUBDIR)/gmp; \ ... $(HOST_CONFIGARGS) --build=${build_alias} --host=none-${host_vendor}-${host_os} \ --target=none-${host_vendor}-${host_os} $${srcdiroption} --disable-shared \ || exit 1 @endif gmp configure-mpfr: ... echo Configuring in $(HOST_SUBDIR)/mpfr; \ ... $(HOST_CONFIGARGS) --build=${build_alias} --host=none-${host_vendor}-${host_os} \ --target=none-${host_vendor}-${host_os} $${srcdiroption} --disable-shared --with-gmp-build=$$r/$(HOST_SUBDIR)/gmp \ || exit 1 @endif mpfr Let me test it and then I'll remove the Quake code related to this. - Jay CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jayk123 at hotmail.com Subject: Re: [M3devel] a hope for dynamic linking! Date: Sat, 19 Apr 2008 10:50:04 -0400 Hold on! I am strongly in favor of static linking for cm3cg/m3cgc1 so that it is a standalone executable. Should be easy enough with gcc configure. On Apr 19, 2008, at 10:31 AM, Jay wrote:http://www.eyrie.org/~eagle/notes/rpath.html http://people.debian.org/~che/personal/rpath-considered-harmful but yet: http://www.scons.org/wiki/UsingOrigin So you can either colocate executables and .sos in the same directory or, like /cm3/bin /cm3/lib/m3core.so and vary the install root. We should be using this where available -- Linux, Solaris, Irix. Too bad not supported elsewhere. On Windows you can colocate; the .exe's directory is always searched. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Apr 19 17:34:38 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 19 Apr 2008 11:34:38 -0400 Subject: [M3devel] a hope for dynamic linking! In-Reply-To: References: Message-ID: Regular Modula-3 app stuff should build statically already, where it makes sense. build_standalone() achieves this. On some systems static libraries for certain system libraries are not available and cannot be assumed. We always build static Modula-3 libraries, so the current setup will link those statically even if other libraries are not available. For example, cm3 on I386_DARWIN gives: hosking$ otool -L /usr/local/cm3/bin/cm3 /usr/local/cm3/bin/cm3: /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) Notice that all the M3 libraries are static, but libgcc and friends are dynamic. So, I don't know what you are attempting to do. Did you try --disable- shared for m3cc configuration? On Apr 19, 2008, at 11:10 AM, Jay wrote: > (ok, actually I meant maybe for cm3cg but ok either way, there'd > only be one use of "/usr/local/cm3/bin/libgmp.so" so might as well > be static) > > > > > From: jayk123 at hotmail.com > To: hosking at cs.purdue.edu > Date: Sat, 19 Apr 2008 15:02:44 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] a hope for dynamic linking! > > I mean for the "regular" Modula-3 "app" stuff, not cm3cg. > > It looks like it is already static, good. > > 1) http://gcc.gnu.org/ml/gcc/2006-10/msg00141.html > > 2) The current code: > > m3-sys/m3cc/gcc/Makefile.in: > > configure-gmp: > ... > echo Configuring in $(HOST_SUBDIR)/gmp; \ > ... > $(HOST_CONFIGARGS) --build=${build_alias} --host=none-$ > {host_vendor}-${host_os} \ > --target=none-${host_vendor}-${host_os} $${srcdiroption} -- > disable-shared \ > || exit 1 > @endif gmp > > > configure-mpfr: > ... > echo Configuring in $(HOST_SUBDIR)/mpfr; \ > ... > $(HOST_CONFIGARGS) --build=${build_alias} --host=none-$ > {host_vendor}-${host_os} \ > --target=none-${host_vendor}-${host_os} $${srcdiroption} -- > disable-shared --with-gmp-build=$$r/$(HOST_SUBDIR)/gmp \ > || exit 1 > @endif mpfr > > > Let me test it and then I'll remove the Quake code related to this. > > > - Jay > > > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jayk123 at hotmail.com > Subject: Re: [M3devel] a hope for dynamic linking! > Date: Sat, 19 Apr 2008 10:50:04 -0400 > > Hold on! I am strongly in favor of static linking for cm3cg/m3cgc1 > so that it is a standalone executable. Should be easy enough with > gcc configure. > > On Apr 19, 2008, at 10:31 AM, Jay wrote: > http://www.eyrie.org/~eagle/notes/rpath.html > http://people.debian.org/~che/personal/rpath-considered-harmful > > > but yet: > > http://www.scons.org/wiki/UsingOrigin > > So you can either colocate executables and .sos in the same > directory or, like > /cm3/bin > /cm3/lib/m3core.so > > and vary the install root. > > We should be using this where available -- Linux, Solaris, Irix. > Too bad not supported elsewhere. > On Windows you can colocate; the .exe's directory is always searched. > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Apr 19 17:46:31 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Apr 2008 15:46:31 +0000 Subject: [M3devel] a hope for dynamic linking! In-Reply-To: References: Message-ID: I understand. But when dynamic linking is actually used, -rpath/$ORIGIN might be a little better than having to modify LD_LIBRARY_PATH. I realize it's not night and day. It doesn't make dynamic linking suddenly problem free, just maybe every so slightly better. When that still isn't adequate and diskspace/memory not a concern, or there are issues of circular dependencies (cm3), build_standalone. (I think cm3 is statically linked for subtle reasons I can't quite grasp at the moment. Not just so it can copy m3core.dll around while it is running, that could probably be dealt with less severely.) It looks like when gmp/mpfr source are in the gcc tree, it always does --disable-shared on them. I'm testing some now. libgcc seems to be a bit of a middle ground, like Modula3 stuff -- available both static and dynamic, and the need for dynamic varies. libgcc I believe contains roughly: 1) math helpers -- multiply/divide, 64 bit stuff 2) exception handling #1 is a case of kinda like, hey, I didn't make any function calls, why do I do need a .lib or .dll and no thank you on the dynamic linking headaches #2 is similar, but rather than "no function calls", it's using language constructs that actually have heavy dependencies, and if people want to throw/catch exceptions across linkage boundaries, the exception handling implementation might need to be shared building with the in-gcc-tree gmp/mpfr: gcc -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_STDARG=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SETLOCALE=1 -DHAVE_GETTIMEOFDAY=1 -DMPFR_HAVE_FESETROUND=1 -DHAVE_ROUND=1 -DHAVE_TRUNC=1 -DHAVE_FLOOR=1 -DHAVE_CEIL=1 -DHAVE_NEARBYINT=1 -DHAVE_ATTRIBUTE_MODE=1 -DHAVE_ALLOCA_H=1 -I. -I../../gcc/mpfr -I/dev2/cm3/m3-sys/m3cc/PPC_DARWIN/./gmp -I/dev2/cm3/m3-sys/m3cc/PPC_DARWIN/./gmp/tune -g -MT remquo.lo -MD -MP -MF .deps/remquo.Tpo -c ../../gcc/mpfr/remquo.c -o remquo.o ./get_patches.sh > get_patches.c || rm -f get_patches.c /bin/sh: line 1: ./get_patches.sh: No such file or directory if /bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_STDARG=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SETLOCALE=1 -DHAVE_GETTIMEOFDAY=1 -DMPFR_HAVE_FESETROUND=1 -DHAVE_ROUND=1 -DHAVE_TRUNC=1 -DHAVE_FLOOR=1 -DHAVE_CEIL=1 -DHAVE_NEARBYINT=1 -DHAVE_ATTRIBUTE_MODE=1 -DHAVE_ALLOCA_H=1 -I. -I../../gcc/mpfr -I/dev2/cm3/m3-sys/m3cc/PPC_DARWIN/./gmp -I/dev2/cm3/m3-sys/m3cc/PPC_DARWIN/./gmp/tune -g -MT get_patches.lo -MD -MP -MF ".deps/get_patches.Tpo" -c -o get_patches.lo get_patches.c; \ then mv -f ".deps/get_patches.Tpo" ".deps/get_patches.Plo"; else rm -f ".deps/get_patches.Tpo"; exit 1; fi gcc -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_STDARG=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SETLOCALE=1 -DHAVE_GETTIMEOFDAY=1 -DMPFR_HAVE_FESETROUND=1 -DHAVE_ROUND=1 -DHAVE_TRUNC=1 -DHAVE_FLOOR=1 -DHAVE_CEIL=1 -DHAVE_NEARBYINT=1 -DHAVE_ATTRIBUTE_MODE=1 -DHAVE_ALLOCA_H=1 -I. -I../../gcc/mpfr -I/dev2/cm3/m3-sys/m3cc/PPC_DARWIN/./gmp -I/dev2/cm3/m3-sys/m3cc/PPC_DARWIN/./gmp/tune -g -MT get_patches.lo -MD -MP -MF .deps/get_patches.Tpo -c get_patches.c -o get_patches.o powerpc-apple-darwin8-gcc-4.0.1: get_patches.c: No such file or directory I'll investigate. I was able to build them on another machine via apt-get source. Maybe you missed a file? I'll look.. - Jay CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jayk123 at hotmail.com Subject: Re: [M3devel] a hope for dynamic linking! Date: Sat, 19 Apr 2008 11:34:38 -0400 Regular Modula-3 app stuff should build statically already, where it makes sense. build_standalone() achieves this. On some systems static libraries for certain system libraries are not available and cannot be assumed. We always build static Modula-3 libraries, so the current setup will link those statically even if other libraries are not available. For example, cm3 on I386_DARWIN gives: hosking$ otool -L /usr/local/cm3/bin/cm3/usr/local/cm3/bin/cm3: /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) Notice that all the M3 libraries are static, but libgcc and friends are dynamic. So, I don't know what you are attempting to do. Did you try --disable-shared for m3cc configuration? On Apr 19, 2008, at 11:10 AM, Jay wrote:(ok, actually I meant maybe for cm3cg but ok either way, there'd only be one use of "/usr/local/cm3/bin/libgmp.so" so might as well be static) From: jayk123 at hotmail.com To: hosking at cs.purdue.edu Date: Sat, 19 Apr 2008 15:02:44 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] a hope for dynamic linking! I mean for the "regular" Modula-3 "app" stuff, not cm3cg. It looks like it is already static, good. 1) http://gcc.gnu.org/ml/gcc/2006-10/msg00141.html 2) The current code: m3-sys/m3cc/gcc/Makefile.in: configure-gmp: ... echo Configuring in $(HOST_SUBDIR)/gmp; \ ... $(HOST_CONFIGARGS) --build=${build_alias} --host=none-${host_vendor}-${host_os} \ --target=none-${host_vendor}-${host_os} $${srcdiroption} --disable-shared \ || exit 1 @endif gmp configure-mpfr: ... echo Configuring in $(HOST_SUBDIR)/mpfr; \ ... $(HOST_CONFIGARGS) --build=${build_alias} --host=none-${host_vendor}-${host_os} \ --target=none-${host_vendor}-${host_os} $${srcdiroption} --disable-shared --with-gmp-build=$$r/$(HOST_SUBDIR)/gmp \ || exit 1 @endif mpfr Let me test it and then I'll remove the Quake code related to this. - Jay CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jayk123 at hotmail.com Subject: Re: [M3devel] a hope for dynamic linking! Date: Sat, 19 Apr 2008 10:50:04 -0400 Hold on! I am strongly in favor of static linking for cm3cg/m3cgc1 so that it is a standalone executable. Should be easy enough with gcc configure. On Apr 19, 2008, at 10:31 AM, Jay wrote:http://www.eyrie.org/~eagle/notes/rpath.html http://people.debian.org/~che/personal/rpath-considered-harmful but yet: http://www.scons.org/wiki/UsingOrigin So you can either colocate executables and .sos in the same directory or, like /cm3/bin /cm3/lib/m3core.so and vary the install root. We should be using this where available -- Linux, Solaris, Irix. Too bad not supported elsewhere. On Windows you can colocate; the .exe's directory is always searched. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Apr 19 17:56:34 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Apr 2008 15:56:34 +0000 Subject: [M3devel] a hope for dynamic linking! In-Reply-To: References: Message-ID: sorry, that was with them symlinked in, from before the fix; maybe that's the problem I'll see. - Jay From: jayk123 at hotmail.com To: hosking at cs.purdue.edu Date: Sat, 19 Apr 2008 15:46:31 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] a hope for dynamic linking! I understand. But when dynamic linking is actually used, -rpath/$ORIGIN might be a little better than having to modify LD_LIBRARY_PATH. I realize it's not night and day. It doesn't make dynamic linking suddenly problem free, just maybe every so slightly better. When that still isn't adequate and diskspace/memory not a concern, or there are issues of circular dependencies (cm3), build_standalone. (I think cm3 is statically linked for subtle reasons I can't quite grasp at the moment. Not just so it can copy m3core.dll around while it is running, that could probably be dealt with less severely.) It looks like when gmp/mpfr source are in the gcc tree, it always does --disable-shared on them. I'm testing some now. libgcc seems to be a bit of a middle ground, like Modula3 stuff -- available both static and dynamic, and the need for dynamic varies. libgcc I believe contains roughly: 1) math helpers -- multiply/divide, 64 bit stuff 2) exception handling #1 is a case of kinda like, hey, I didn't make any function calls, why do I do need a .lib or .dll and no thank you on the dynamic linking headaches #2 is similar, but rather than "no function calls", it's using language constructs that actually have heavy dependencies, and if people want to throw/catch exceptions across linkage boundaries, the exception handling implementation might need to be shared building with the in-gcc-tree gmp/mpfr: gcc -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_STDARG=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SETLOCALE=1 -DHAVE_GETTIMEOFDAY=1 -DMPFR_HAVE_FESETROUND=1 -DHAVE_ROUND=1 -DHAVE_TRUNC=1 -DHAVE_FLOOR=1 -DHAVE_CEIL=1 -DHAVE_NEARBYINT=1 -DHAVE_ATTRIBUTE_MODE=1 -DHAVE_ALLOCA_H=1 -I. -I../../gcc/mpfr -I/dev2/cm3/m3-sys/m3cc/PPC_DARWIN/./gmp -I/dev2/cm3/m3-sys/m3cc/PPC_DARWIN/./gmp/tune -g -MT remquo.lo -MD -MP -MF .deps/remquo.Tpo -c ../../gcc/mpfr/remquo.c -o remquo.o ./get_patches.sh > get_patches.c || rm -f get_patches.c /bin/sh: line 1: ./get_patches.sh: No such file or directory if /bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_STDARG=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SETLOCALE=1 -DHAVE_GETTIMEOFDAY=1 -DMPFR_HAVE_FESETROUND=1 -DHAVE_ROUND=1 -DHAVE_TRUNC=1 -DHAVE_FLOOR=1 -DHAVE_CEIL=1 -DHAVE_NEARBYINT=1 -DHAVE_ATTRIBUTE_MODE=1 -DHAVE_ALLOCA_H=1 -I. -I../../gcc/mpfr -I/dev2/cm3/m3-sys/m3cc/PPC_DARWIN/./gmp -I/dev2/cm3/m3-sys/m3cc/PPC_DARWIN/./gmp/tune -g -MT get_patches.lo -MD -MP -MF ".deps/get_patches.Tpo" -c -o get_patches.lo get_patches.c; \ then mv -f ".deps/get_patches.Tpo" ".deps/get_patches.Plo"; else rm -f ".deps/get_patches.Tpo"; exit 1; fi gcc -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_STDARG=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SETLOCALE=1 -DHAVE_GETTIMEOFDAY=1 -DMPFR_HAVE_FESETROUND=1 -DHAVE_ROUND=1 -DHAVE_TRUNC=1 -DHAVE_FLOOR=1 -DHAVE_CEIL=1 -DHAVE_NEARBYINT=1 -DHAVE_ATTRIBUTE_MODE=1 -DHAVE_ALLOCA_H=1 -I. -I../../gcc/mpfr -I/dev2/cm3/m3-sys/m3cc/PPC_DARWIN/./gmp -I/dev2/cm3/m3-sys/m3cc/PPC_DARWIN/./gmp/tune -g -MT get_patches.lo -MD -MP -MF .deps/get_patches.Tpo -c get_patches.c -o get_patches.o powerpc-apple-darwin8-gcc-4.0.1: get_patches.c: No such file or directory I'll investigate. I was able to build them on another machine via apt-get source. Maybe you missed a file? I'll look.. - Jay CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jayk123 at hotmail.com Subject: Re: [M3devel] a hope for dynamic linking! Date: Sat, 19 Apr 2008 11:34:38 -0400 Regular Modula-3 app stuff should build statically already, where it makes sense. build_standalone() achieves this. On some systems static libraries for certain system libraries are not available and cannot be assumed. We always build static Modula-3 libraries, so the current setup will link those statically even if other libraries are not available. For example, cm3 on I386_DARWIN gives: hosking$ otool -L /usr/local/cm3/bin/cm3/usr/local/cm3/bin/cm3: /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) Notice that all the M3 libraries are static, but libgcc and friends are dynamic. So, I don't know what you are attempting to do. Did you try --disable-shared for m3cc configuration? On Apr 19, 2008, at 11:10 AM, Jay wrote:(ok, actually I meant maybe for cm3cg but ok either way, there'd only be one use of "/usr/local/cm3/bin/libgmp.so" so might as well be static) From: jayk123 at hotmail.com To: hosking at cs.purdue.edu Date: Sat, 19 Apr 2008 15:02:44 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] a hope for dynamic linking! I mean for the "regular" Modula-3 "app" stuff, not cm3cg. It looks like it is already static, good. 1) http://gcc.gnu.org/ml/gcc/2006-10/msg00141.html 2) The current code: m3-sys/m3cc/gcc/Makefile.in: configure-gmp: ... echo Configuring in $(HOST_SUBDIR)/gmp; \ ... $(HOST_CONFIGARGS) --build=${build_alias} --host=none-${host_vendor}-${host_os} \ --target=none-${host_vendor}-${host_os} $${srcdiroption} --disable-shared \ || exit 1 @endif gmp configure-mpfr: ... echo Configuring in $(HOST_SUBDIR)/mpfr; \ ... $(HOST_CONFIGARGS) --build=${build_alias} --host=none-${host_vendor}-${host_os} \ --target=none-${host_vendor}-${host_os} $${srcdiroption} --disable-shared --with-gmp-build=$$r/$(HOST_SUBDIR)/gmp \ || exit 1 @endif mpfr Let me test it and then I'll remove the Quake code related to this. - Jay CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jayk123 at hotmail.com Subject: Re: [M3devel] a hope for dynamic linking! Date: Sat, 19 Apr 2008 10:50:04 -0400 Hold on! I am strongly in favor of static linking for cm3cg/m3cgc1 so that it is a standalone executable. Should be easy enough with gcc configure. On Apr 19, 2008, at 10:31 AM, Jay wrote:http://www.eyrie.org/~eagle/notes/rpath.html http://people.debian.org/~che/personal/rpath-considered-harmful but yet: http://www.scons.org/wiki/UsingOrigin So you can either colocate executables and .sos in the same directory or, like /cm3/bin /cm3/lib/m3core.so and vary the install root. We should be using this where available -- Linux, Solaris, Irix. Too bad not supported elsewhere. On Windows you can colocate; the .exe's directory is always searched. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Apr 19 18:09:37 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 19 Apr 2008 12:09:37 -0400 Subject: [M3devel] a hope for dynamic linking! In-Reply-To: References: Message-ID: <1C5B9FD1-2B46-4C4E-9F21-A7CD1119C5F5@cs.purdue.edu> I just ran into this one myself. Looks like this version of mpfr doesn't play totally nicely with building within gcc. I've commented out the following lines in mpfr/Makefile.in which appear to do the trick. If so, then I will commit it... get_patches.c: PATCHES get_patches.sh ./get_patches.sh > $@ || rm -f $@ On Apr 19, 2008, at 11:46 AM, Jay wrote: > building with the in-gcc-tree gmp/mpfr: > > gcc -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DTIME_WITH_SYS_TIME=1 - > DHAVE_STDARG=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SETLOCALE=1 - > DHAVE_GETTIMEOFDAY=1 -DMPFR_HAVE_FESETROUND=1 -DHAVE_ROUND=1 - > DHAVE_TRUNC=1 -DHAVE_FLOOR=1 -DHAVE_CEIL=1 -DHAVE_NEARBYINT=1 - > DHAVE_ATTRIBUTE_MODE=1 -DHAVE_ALLOCA_H=1 -I. -I../../gcc/mpfr -I/ > dev2/cm3/m3-sys/m3cc/PPC_DARWIN/./gmp -I/dev2/cm3/m3-sys/m3cc/ > PPC_DARWIN/./gmp/tune -g -MT remquo.lo -MD -MP -MF .deps/remquo.Tpo - > c ../../gcc/mpfr/remquo.c -o remquo.o > ./get_patches.sh > get_patches.c || rm -f get_patches.c > /bin/sh: line 1: ./get_patches.sh: No such file or directory > if /bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_INTTYPES_H=1 > -DHAVE_STDINT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_STDARG=1 - > DHAVE_SYS_TIME_H=1 -DHAVE_SETLOCALE=1 -DHAVE_GETTIMEOFDAY=1 - > DMPFR_HAVE_FESETROUND=1 -DHAVE_ROUND=1 -DHAVE_TRUNC=1 -DHAVE_FLOOR=1 > -DHAVE_CEIL=1 -DHAVE_NEARBYINT=1 -DHAVE_ATTRIBUTE_MODE=1 - > DHAVE_ALLOCA_H=1 -I. -I../../gcc/mpfr -I/dev2/cm3/m3-sys/m3cc/ > PPC_DARWIN/./gmp -I/dev2/cm3/m3-sys/m3cc/PPC_DARWIN/./gmp/tune -g - > MT get_patches.lo -MD -MP -MF ".deps/get_patches.Tpo" -c -o > get_patches.lo get_patches.c; \ > then mv -f ".deps/get_patches.Tpo" ".deps/get_patches.Plo"; else rm - > f ".deps/get_patches.Tpo"; exit 1; fi > gcc -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DTIME_WITH_SYS_TIME=1 - > DHAVE_STDARG=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SETLOCALE=1 - > DHAVE_GETTIMEOFDAY=1 -DMPFR_HAVE_FESETROUND=1 -DHAVE_ROUND=1 - > DHAVE_TRUNC=1 -DHAVE_FLOOR=1 -DHAVE_CEIL=1 -DHAVE_NEARBYINT=1 - > DHAVE_ATTRIBUTE_MODE=1 -DHAVE_ALLOCA_H=1 -I. -I../../gcc/mpfr -I/ > dev2/cm3/m3-sys/m3cc/PPC_DARWIN/./gmp -I/dev2/cm3/m3-sys/m3cc/ > PPC_DARWIN/./gmp/tune -g -MT get_patches.lo -MD -MP -MF .deps/ > get_patches.Tpo -c get_patches.c -o get_patches.o > powerpc-apple-darwin8-gcc-4.0.1: get_patches.c: No such file or > directory -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Apr 19 22:06:43 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 19 Apr 2008 22:06:43 +0200 Subject: [M3devel] new gcc configure and setup In-Reply-To: References: <20080419113533.zi4vqsvxs0ocgs4c@mail.elegosoft.com> <3E4BBF85-989B-4649-AC7D-20E82610940B@cs.purdue.edu> <2A490CE3-D906-4795-B7A8-5928276CA2FD@cs.purdue.edu> Message-ID: <20080419220643.d9sfh9gx8kggkw8g@mail.elegosoft.com> I manually started a build on new.elego.de some hours ago, which succeeded; everything seems to build again now, thanks to you both! And we have the base for X64 support in CM3, which is a great step forward! Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Sun Apr 20 05:56:15 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 20 Apr 2008 03:56:15 +0000 Subject: [M3devel] moving versions into simple text file (sh?) Message-ID: I'd like to (finally) move the default versions out into a simple file. Given: jbook15:/dev2/cm3/scripts jay$ cat version CM3VERSION d5.7.0 CM3VERSIONNUM 050700 CM3LASTCHANGED 2008-03-16 Is there any chance this is Posix/Solaris compliant? get_version() { if [ -n "$(eval echo \$$1)" ] ; then return fi eval "$1=\"$(echo $(grep "$1 " $root/scripts/version | awk '{print $2}'))\"" } get_version CM3VERSION get_version CM3VERSIONNUM get_version CM3LASTCHANGED echo "CM3VERSION is $CM3VERSION" echo "CM3VERSIONNUM is $CM3VERSIONNUM" echo "CM3LASTCHANGED is $CM3LASTCHANGED" It works on my Mac. This is not what I would have expected, in particular the need for eval and echo seems strange. The quoting is all unfortunate as usual too. If this isn't standard, then how about just the last line: get_version() { eval "$1=\"$(echo $(grep "$1 " $root/scripts/version | awk '{print $2}'))\"" } ? Otherwise, I guess dumb it down and be repetitive, like: CM3VERSION=${CM3VERSION-`grep "CM3VERSION " $root/scripts/version | awk '{print $2}'))`} ? I didn't want to repeat the variable names three times each. What I really want is to append version to PKGS and regenerate PKGS whenever its lines aren't all there, so as to trigger an automatic rebuild of PKGS when the version changes. One more application of the version numbers, and I was pushed to fix them. Full diff: Index: sysinfo.sh =================================================================== RCS file: /usr/cvs/cm3/scripts/sysinfo.sh,v retrieving revision 1.61 diff -c -r1.61 sysinfo.sh *** sysinfo.sh 15 Apr 2008 06:51:31 -0000 1.61 --- sysinfo.sh 20 Apr 2008 03:48:13 -0000 *************** *** 10,38 **** PRJ_ROOT=${PRJ_ROOT:-${HOME}/work} - #----------------------------------------------------------------------------- - # set some defaults # ! # These three lines must be carefully formed as they are parsed by other code. # ! # For cmd: ! # They must start with a name and an equals sign. ! # They must contain one and only one colon. ! # They must contain one and only one equals sign. ! # The content to the right of the colon, minus the first two ! # and last two characters, is the value. # ! # For Python, we have much more flexibility. Currently the code ! # looks for fairly precisely A=${A:-"value"}, but this can be easily ! # relaxed or changed. # ! # Refer to scripts/win/sysinfo.cmd and scripts/python/lib.py. ! # Specifically look for "DefaultsFromSh". # CM3VERSION=${CM3VERSION:-"d5.7.0"} CM3VERSIONNUM=${CM3VERSIONNUM:-"050700"} CM3LASTCHANGED=${CM3LASTCHANGED:-"2008-03-16"} CM3_GCC_BACKEND=yes CM3_GDB=no # --- 10,49 ---- PRJ_ROOT=${PRJ_ROOT:-${HOME}/work} # ! # Allow direct invocation of sysinfo.sh for testing purposes. # ! if [ -z "$root" -o ! -d "$root" ] ; then ! root=`pwd` ! while [ -n "$root" -a ! -f "$root/scripts/sysinfo.sh" ] ; do ! root=`dirname $root` ! done ! fi ! ! #----------------------------------------------------------------------------- ! # set some defaults # ! ! get_version() { ! if [ -n "$(eval echo \$$1)" ] ; then ! return ! fi ! eval "$1=\"$(echo $(grep "$1 " $root/scripts/version | awk '{print $2}'))\"" ! } ! ! get_version CM3VERSION ! get_version CM3VERSIONNUM ! get_version CM3LASTCHANGED ! # ! # Leave these lines in TEMPORARILY for compat with cmd, Python, Quake. # CM3VERSION=${CM3VERSION:-"d5.7.0"} CM3VERSIONNUM=${CM3VERSIONNUM:-"050700"} CM3LASTCHANGED=${CM3LASTCHANGED:-"2008-03-16"} + CM3_INSTALL=${CM3_INSTALL:-`dirname \`find_exe cm3 /usr/local/cm3/\ \``} + CM3_GCC_BACKEND=yes CM3_GDB=no # - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.illig at gmx.de Sun Apr 20 09:58:28 2008 From: roland.illig at gmx.de (Roland Illig) Date: Sun, 20 Apr 2008 08:58:28 +0100 Subject: [M3devel] moving versions into simple text file (sh?) In-Reply-To: References: Message-ID: <480AF7A4.4060905@gmx.de> Jay schrieb: > I'd like to (finally) move the default versions out into a simple file. > > Given: > > jbook15:/dev2/cm3/scripts jay$ cat version > CM3VERSION d5.7.0 > CM3VERSIONNUM 050700 > CM3LASTCHANGED 2008-03-16 > > Is there any chance this is Posix/Solaris compliant? > > get_version() { > if [ -n "$(eval echo \$$1)" ] ; then > return > fi > eval "$1=\"$(echo $(grep "$1 " $root/scripts/version | awk '{print > $2}'))\"" > } Solaris' /bin/sh doesn't know the $(...) operator. Why do you need "eval echo" at all? Better use this: # usage: get_version VARNAME get_version() { eval "gv__set=\${$1+set}" if [ "$gv__set" != "set" ]; then gv__value=`awk '$1 == "'"$1"'" { print $2 }' $root/scripts/version` eval "$1=\$gv__value" fi } $ /bin/sh $ . ./get_version.sh $ set -x $ get_version CM3VERSION + get_version CM3VERSION + eval __set=${CM3VERSION+set} __set= + [ != set ] + awk $1 == "CM3VERSION" { print $2 } version value=d5.7.0 + eval CM3VERSION=$value CM3VERSION=d5.7.0 $ get_version CM3VERSION + get_version CM3VERSION + eval __set=${CM3VERSION+set} __set=set + [ set != set ] Roland From roland.illig at gmx.de Sun Apr 20 10:05:25 2008 From: roland.illig at gmx.de (Roland Illig) Date: Sun, 20 Apr 2008 09:05:25 +0100 Subject: [M3devel] moving versions into simple text file (sh?) In-Reply-To: <480AF7A4.4060905@gmx.de> References: <480AF7A4.4060905@gmx.de> Message-ID: <480AF945.40602@gmx.de> Roland Illig schrieb: > Jay schrieb: >> I'd like to (finally) move the default versions out into a simple file. >> >> Given: >> >> jbook15:/dev2/cm3/scripts jay$ cat version >> CM3VERSION d5.7.0 >> CM3VERSIONNUM 050700 >> CM3LASTCHANGED 2008-03-16 or maybe this, which is even easier: $ eval "`sed 's, ,=,' $root/scripts/version`" Roland From jayk123 at hotmail.com Sun Apr 20 16:26:34 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 20 Apr 2008 14:26:34 +0000 Subject: [M3devel] moving versions into simple text file (sh?) In-Reply-To: <480AF945.40602@gmx.de> References: <480AF7A4.4060905@gmx.de> <480AF945.40602@gmx.de> Message-ID: Right -- turning it into executable code is tempting, however what you show isn't quite the whole story. Perhaps if the sed sticks default_ on the front or something. How about: > $ eval "`awk < $root/scripts/version '{print default_$1=$2}'`" FOO=${FOO:$default_FOO} BAR=${FOO:$default_BAR} So then I am back to repeating every variable name three times, but hey at least I only run awk/sed once instead of three times. :) I will try something like that. The other code you shows was not understandable to me, alas. I wasn't going to use $( ), but it does seem to be posix and nested ` bit me before. So I've been reading about bash vs. sh vs. dash, and autoconfigure..and I learn that Solaris sh is pre-Posix and not conformant. That /bin/sh isn't even where you get Posix sh from, according to Posix. I am more and more convinced that the way to go "here" (not actually "here", not Modula-3 related, but GNU/Unix related) is a really small "portable" "thingy" that is used only to bootstrap the next level up which would be much richer. For example, a decent non-extensible single-threaded scripting language written in one large C file, that only used like stdio and/or open/read/write.. Then the "configure" script is really small: configure-unix #!/bin/sh cc foo.c -o foo if ! -f foo then echo "C compilation failed, please see $0" exit 1 end ./foo $0 And then write the rest in C, but the "script" can contain some "scripting language" for the C to interpret from there. Write the above in .cmd/.bat and the VMS language and done. Add some probes for the compiler name, cl, bcc, icc, dmc, etc. I mean, all the gnarly workarounds in autoconf output, heck, can't bash be distilled down to a small portable useful base, that doesn't need configuring, and just use it without workarounds? I just don't see much value in all the layers.. or I'm too lazy to keep learning more and more and more similar stuff full of history and cruft.... - Jay ---------------------------------------- > Date: Sun, 20 Apr 2008 09:05:25 +0100 > From: roland.illig at gmx.de > To: m3devel at elegosoft.com > Subject: Re: [M3devel] moving versions into simple text file (sh?) > > Roland Illig schrieb: >> Jay schrieb: >>> I'd like to (finally) move the default versions out into a simple file. >>> >>> Given: >>> >>> jbook15:/dev2/cm3/scripts jay$ cat version >>> CM3VERSION d5.7.0 >>> CM3VERSIONNUM 050700 >>> CM3LASTCHANGED 2008-03-16 > > or maybe this, which is even easier: > > $ eval "`sed 's, ,=,' $root/scripts/version`" > > Roland From hosking at cs.purdue.edu Mon Apr 21 00:52:51 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 20 Apr 2008 18:52:51 -0400 Subject: [M3devel] Update on cm3cg for x86_64 Linux Message-ID: <7281A261-2AC4-46CA-938C-785C1C4D1EE1@cs.purdue.edu> It seems there is an incompatibility between cm3cg built using default gcc (not -m32) on x86_64 Linux and the CM3 front-end targeting 32-bit LINUXLIBC6. I get errors in the gcc-based backend code if I build it without -m32 using it to compile M3IR. Looks like some problem with LONGREAL alignment. If I build using -m32 then cm3cg works just fine on x86_64. Anyway, something to watch out for. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Apr 22 01:15:05 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Apr 2008 23:15:05 +0000 Subject: [M3devel] more path stuff, sorry Message-ID: Maybe this is dubious. The question is, like, should native NT386 cm3 accept /cygdrive/c/foo and translate to c:\foo?Or trickier, /usr/bin/foo and translate to c:\cygwin\usr\bin\foo?And vice versa, should NT386GNU accept c:\foo? The translation is not simple in general./ maps to the Cygwin install root.There can be symlinks.But many common cases can be handled with little, simple code.It's already in. Ultimately the way to do this correctly is to link to cygwin1.dll, which is only done sometimes, and which probably license-undesirable when not done. As well, a path like /foo is actually ambiguous.It is a valid native Win32 path, equivalent to \foo.Or it could be Cygwin path requivalent to c:\cygwin\foo. While it is nice to keep cm3 simple, it is also nice to have a more uniform interfaceacross hosts, I think. Maybe. To some extent a user can do this himself.That is, NTFS junctions and/or Cygwin symblinks can cause their to be identical pathswith identical meanings: e.g. for me, symlink /msdev => c:\msdev, /cm3 => c:\cm3 /dev => c:\dev2 In some places Cygwin open et. al. accept Win32 paths, but lately taking advantage ofthat issues a warning. In some places, I think, it isn't sufficient to have Cygwin handle it. The harder question then is, if I feed Cygwin paths of a particular form, should ittry to report back paths in the same form? I put some code in M3Path.m3 "like this", but it may not be advisable. I also had an NTFS junction on my system so Win32 /cygdrive/c => c:\, but this causesa circularity in the file system, which I'd rather not have. As well, there are at least three or four Posix runtimes for Windows, and they each mapdifferently. UWin I think uses /c <=> c:\.Cygwin /cygdrive <=> c:\Interix/ServicesForUnix/SUA I think something via /dev.MinGWin also has a runtime that I think uses the UWin mapping, but this runtime is onlymeant for sh/gcc to use, not user apps. Having special code that only knows the Cygwin convention is questionable. I was often setting up some environment variables one way or the other, and thenrunning one cm3 or the other, without thinking about which form the variables were in.Indeed, it might be nice to set CM3_ROOT and CM3_INSTALL "once and for all", while still switching between different forms of cm3.exe?Though granted, CM3_INSTALL cm3.exe can usually figure out from its own path, andCM3_ROOT could usually be figured out by looking at the CVS directories in the currentworking directory, not always, but often. Basically, instead of setting these variblesone way or the other, I'd like to set them always one way, or even not at all. Hm, in fact, I think cm3 could figure out all overrides itself? You know, if there is a shipped package store, it can use that to determine the source <=> pkg mapping. And it can figure out CM3_ROOT by looking at the current directory and on up until the CVS/Root changes? As well, you know, the source <=> pkg mapping could be a simple generated checked in file. You know, like the PKGS file, but stripped down to only what is needed? Maybe just remove the code I put in and forget the whole thing.Maybe most people only ever stay in one of the worlds and "translation" isn't important? Just me stuck with providing support for both and therefore living with both more? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Apr 22 03:44:17 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 21 Apr 2008 21:44:17 -0400 Subject: [M3devel] more path stuff, sorry In-Reply-To: References: Message-ID: Why would native NT386 know anything at all about Cygwin. I say just avoid split personalities like the plague. Similarly, I'd be happy for NT386GNU (i.e., Cygwin?) to simply behave like a POSIX build (modulo native threads perhaps). On Apr 21, 2008, at 7:15 PM, Jay wrote: > Maybe this is dubious. > > The question is, like, should native NT386 cm3 accept /cygdrive/c/ > foo and translate to c:\foo? > Or trickier, /usr/bin/foo and translate to c:\cygwin\usr\bin\foo? > And vice versa, should NT386GNU accept c:\foo? > > The translation is not simple in general. > / maps to the Cygwin install root. > There can be symlinks. > But many common cases can be handled with little, simple code. > It's already in. > > Ultimately the way to do this correctly is to link to cygwin1.dll, > which is only done sometimes, > and which probably license-undesirable when not done. > > As well, a path like /foo is actually ambiguous. > It is a valid native Win32 path, equivalent to \foo. > Or it could be Cygwin path requivalent to c:\cygwin\foo. > > While it is nice to keep cm3 simple, it is also nice to have a more > uniform interface > across hosts, I think. Maybe. > > To some extent a user can do this himself. > That is, NTFS junctions and/or Cygwin symblinks can cause their to > be identical paths > with identical meanings: > e.g. for me, symlink /msdev => c:\msdev, /cm3 => c:\cm3 /dev => c: > \dev2 > > In some places Cygwin open et. al. accept Win32 paths, but lately > taking advantage of > that issues a warning. In some places, I think, it isn't sufficient > to have Cygwin handle it. > > The harder question then is, if I feed Cygwin paths of a particular > form, should it > try to report back paths in the same form? > > I put some code in M3Path.m3 "like this", but it may not be advisable. > > I also had an NTFS junction on my system so Win32 /cygdrive/c => c: > \, but this causes > a circularity in the file system, which I'd rather not have. > > As well, there are at least three or four Posix runtimes for > Windows, and they each map > differently. > > UWin I think uses /c <=> c:\. > Cygwin /cygdrive <=> c:\ > Interix/ServicesForUnix/SUA I think something via /dev. > MinGWin also has a runtime that I think uses the UWin mapping, but > this runtime is only > meant for sh/gcc to use, not user apps. > > Having special code that only knows the Cygwin convention is > questionable. > > I was often setting up some environment variables one way or the > other, and then > running one cm3 or the other, without thinking about which form the > variables were in. > Indeed, it might be nice to set CM3_ROOT and CM3_INSTALL "once and > for all", > while still switching between different forms of cm3.exe? > Though granted, CM3_INSTALL cm3.exe can usually figure out from its > own path, and > CM3_ROOT could usually be figured out by looking at the CVS > directories in the current > working directory, not always, but often. Basically, instead of > setting these varibles > one way or the other, I'd like to set them always one way, or even > not at all. > > > Hm, in fact, I think cm3 could figure out all overrides itself? > You know, if there is a shipped package store, it can use that to > determine the source <=> pkg mapping. > And it can figure out CM3_ROOT by looking at the current directory > and on up until the CVS/Root > changes? > > As well, you know, the source <=> pkg mapping could be a simple > generated checked in file. > You know, like the PKGS file, but stripped down to only what is > needed? > > Maybe just remove the code I put in and forget the whole thing. > Maybe most people only ever stay in one of the worlds and > "translation" isn't important? > Just me stuck with providing support for both and therefore living > with both more? > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Apr 22 04:21:38 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 22 Apr 2008 02:21:38 +0000 Subject: [M3devel] more path stuff, sorry In-Reply-To: References: Message-ID: The split personality has to be somewhere -- either in the user of both or in the code. But maybe there are no users of both. :) Ok, they are it. I'll remove the code, and see how my experience fairs, and try to keep the results to myself. :) > Why would native NT386 know anything at all about Cygwin It depends on why someone choses the one cm3 or the other. If a user "likes Unix" but finds gcc too slow, he might be passing Cygwin paths to the native compiler. If a user "likes Windows" but really wants 64 bit integers right now, he might be inclined to pass Win32 paths to the Cygwin compiler. Granted, the second user could also use NT386MINGNU (__stdcall still broken, I should be able to fix or workaround.) As well, um, the first user could make up a configurationi that suites actually. That is, the choice of backend and the choice "what runtime cm3 uses" are two independent variables.I am answering my question though -- all four combinations should work, and three of them even have names. Mostly user doesn't care "what runtime in use", but user could easily care about the command lines accepted. And, you know, accepting different path forms..doesn't really require cygwin. If the inputs are human generated, he/she can probably live with c:/foo, or /c/foo and make a junction -- c:\c\foo => c:\foo. Oh that second one is a new idea to me actually. I should type that up -- "Windows paths for people that like forward slashes". Again, I know I'm a broken record, but it comes down to what someone wants in "NT386GNU". And the host and target are independently configurable, mostly, maybe -- NT386 can output NT386GNU and vice versa. User might like backward slashes but need to produce code that works in a more Posixish environment. This is like a cross build, except both targets run on the same OS. It probably just comes down what we have -- the two or three canned config files, and someone that wants to mix and match differently can do so. The toplevel NT386/NT386GNU/NT386MINGNU are small thin easily rewritten wrappers over NT386.common anyway. User can provide his own. At some hypothetical point, that will probably never arrive, config files should be tried out for Borland, Watcom, Digital Mars, and ideally, they follow this same pattern -- managing to get by with no compiler change and no new target, just a config file, possibly growing the jmpbuf to the largest of them, if that isn't too large. Actually the compiler doesn't do this correctly. I think it assumes the external backend targets one jumpbuf size and integrated one another. This should either be a dangerous integer directly set in the config file, or keyed off the "CRuntime" parameter there, values like MS, GNU, WATCOM, MWERKS, DMARS. It could be more configuration knobs make sense, since Windows compilers tend to have so many switches, the M3 compiler might have to know more stuff, to interoperate. Anyway..I'm skeptical these targets/configs would have any customers..on to other stuff for now. :) This reminds me of maybe a more important problem -- discerning host and target, I'll start a separate thread. - Jay CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] more path stuff, sorryDate: Mon, 21 Apr 2008 21:44:17 -0400 Why would native NT386 know anything at all about Cygwin. I say just avoid split personalities like the plague. Similarly, I'd be happy for NT386GNU (i.e., Cygwin?) to simply behave like a POSIX build (modulo native threads perhaps). On Apr 21, 2008, at 7:15 PM, Jay wrote: Maybe this is dubious.The question is, like, should native NT386 cm3 accept /cygdrive/c/foo and translate to c:\foo?Or trickier, /usr/bin/foo and translate to c:\cygwin\usr\bin\foo?And vice versa, should NT386GNU accept c:\foo?The translation is not simple in general./ maps to the Cygwin install root.There can be symlinks.But many common cases can be handled with little, simple code.It's already in.Ultimately the way to do this correctly is to link to cygwin1.dll, which is only done sometimes, and which probably license-undesirable when not done.As well, a path like /foo is actually ambiguous.It is a valid native Win32 path, equivalent to \foo.Or it could be Cygwin path requivalent to c:\cygwin\foo.While it is nice to keep cm3 simple, it is also nice to have a more uniform interfaceacross hosts, I think. Maybe.To some extent a user can do this himself.That is, NTFS junctions and/or Cygwin symblinks can cause their to be identical pathswith identical meanings:e.g. for me, symlink /msdev => c:\msdev, /cm3 => c:\cm3 /dev => c:\dev2In some places Cygwin open et. al. accept Win32 paths, but lately taking advantage ofthat issues a warning. In some places, I think, it isn't sufficient to have Cygwin handle it.The harder question then is, if I feed Cygwin paths of a particular form, should ittry to report back paths in the same form?I put some code in M3Path.m3 "like this", but it may not be advisable.I also had an NTFS junction on my system so Win32 /cygdrive/c => c:\, but this causesa circularity in the file system, which I'd rather not have.As well, there are at least three or four Posix runtimes for Windows, and they each mapdifferently.UWin I think uses /c <=> c:\.Cygwin /cygdrive <=> c:\Interix/ServicesForUnix/SUA I think something via /dev.MinGWin also has a runtime that I think uses the UWin mapping, but this runtime is onlymeant for sh/gcc to use, not user apps.Having special code that only knows the Cygwin convention is questionable. I was often setting up some environment variables one way or the other, and thenrunning one cm3 or the other, without thinking about which form the variables were in.Indeed, it might be nice to set CM3_ROOT and CM3_INSTALL "once and for all",while still switching between different forms of cm3.exe?Though granted, CM3_INSTALL cm3.exe can usually figure out from its own path, andCM3_ROOT could usually be figured out by looking at the CVS directories in the currentworking directory, not always, but often. Basically, instead of setting these variblesone way or the other, I'd like to set them always one way, or even not at all.Hm, in fact, I think cm3 could figure out all overrides itself?You know, if there is a shipped package store, it can use that to determine the source <=> pkg mapping.And it can figure out CM3_ROOT by looking at the current directory and on up until the CVS/Rootchanges? As well, you know, the source <=> pkg mapping could be a simple generated checked in file.You know, like the PKGS file, but stripped down to only what is needed? Maybe just remove the code I put in and forget the whole thing.Maybe most people only ever stay in one of the worlds and "translation" isn't important?Just me stuck with providing support for both and therefore living with both more? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Apr 22 04:36:42 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 22 Apr 2008 02:36:42 +0000 Subject: [M3devel] host vs. target and host_ostype exposed to quake? In-Reply-To: References: Message-ID: I found Compiler.i3 recently.I had been writing Quake code like: if equal ($OS, "Windows_NT") and: if equal (SL, "/") I propose that the data in Compiler.i3 be exposed to Quake with variable names something like: HOST -- ALPHA_OSF, NT386, LINUXLIBC6, AMD64_DARWIN, etc. HOST_OSTYPE -- POSIX, WIN32 /maybe/ booleans thereof: HOST_IS_POSIX HOST_IS_WIN32 and /possibly/ others: HOST_GNU_PLATFORM -- maybe needed, maybe not -- currently m3makefile maps from HOST, and the config files have unused declarations for the target. HOST_WORDSIZE -- shouldn't be relevant I /speculate/ as well that the following should be introduced: TARGET_ARCHITECTURE -- AMD64, I386, PPC (Compiler.i3 already separates this out) HOST_ARCHITECTURE TARGET_OS -- SOLARIS (SOL?), NT, DARWIN (MACOSX? Too late.), LINUX, OSF, VMS, HPUX, FREEBSD, OPENBSD, NETBSD (FBSD, OBSD, NBSD?) HOST_OS And then, /maybe/ ultimately, the full calculus I have described: TARGET_C_LIBRARY -- native, cygwin, ms (multiple versions?) TARGET_C_COMPILER -- gnu, sun, ms, dmars, mwerks, borland, watcom, darwin TARGET_C_LINKER -- similar to previous TARGET_WINDOW_LIBRARY -- xwin, mswin TARGET_THREAD_LIBRARY -- pthreads, alarmthreads, nt or at least just the very first two: HOST -- ALPHA_OSF, NT386, LINUXLIBC6, AMD64_DARWIN, etc. HOST_OSTYPE -- POSIX, WIN32 This is super easy, like two lines of code in m3quake to expose the data in Compiler.i3. Also, related, all the places that check Pathname.Join(a, b) == a/b or Epoch = 0, should use Compiler.OSType instead, or whatever it is. I'd have to check if Compiler.i3 puts anything in the .i3 vs. the .m3, if in the .m3, that could be slower, but easily fixed too. Oh, and maybe cm3 --print-var HOST. gcc has all those useful --print flags. Thus, all the uname stuff in sysinfo could go away, you just default to what the compiler runs on. You'd override it for cross builds with -D on the command line or a config file as usual (ie: the Quake variable would lose its read-onlyness, possibly taking on a new special form of "write-once"). One downside is that, as written, the config files are more readable and self-documenting by starting with the important settings up front. Whatever is buried in cm3 is more hidden from users, good and bad. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Tue Apr 22 05:09:39 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 21 Apr 2008 23:09:39 -0400 Subject: [M3devel] more path stuff, sorry In-Reply-To: References: Message-ID: <480D1EAD.1E75.00D7.1@scires.com> I think I've made my opinion on the path issue known, but just so there is no doubt, I do not want the underlying code trying to translate paths from one format to another. I think this is a recipe for problems since different OS represent paths and switches etc differently. Programmers should use the standard interfaces to construct paths appropriate for the current host operating system. Part of the beauty of Modula-3 is write once run everywhere. I have code that uses pathnames that runs on multiple platforms without the need to make any source code modifications. Regards, Randy >>> Jay 4/21/2008 7:15 PM >>> Maybe this is dubious. The question is, like, should native NT386 cm3 accept /cygdrive/c/foo and translate to c:\foo? Or trickier, /usr/bin/foo and translate to c:\cygwin\usr\bin\foo? And vice versa, should NT386GNU accept c:\foo? The translation is not simple in general. / maps to the Cygwin install root. There can be symlinks. But many common cases can be handled with little, simple code. It's already in. Ultimately the way to do this correctly is to link to cygwin1.dll, which is only done sometimes, and which probably license-undesirable when not done. As well, a path like /foo is actually ambiguous. It is a valid native Win32 path, equivalent to \foo. Or it could be Cygwin path requivalent to c:\cygwin\foo. While it is nice to keep cm3 simple, it is also nice to have a more uniform interface across hosts, I think. Maybe. To some extent a user can do this himself. That is, NTFS junctions and/or Cygwin symblinks can cause their to be identical paths with identical meanings: e.g. for me, symlink /msdev => c:\msdev, /cm3 => c:\cm3 /dev => c:\dev2 In some places Cygwin open et. al. accept Win32 paths, but lately taking advantage of that issues a warning. In some places, I think, it isn't sufficient to have Cygwin handle it. The harder question then is, if I feed Cygwin paths of a particular form, should it try to report back paths in the same form? I put some code in M3Path.m3 "like this", but it may not be advisable. I also had an NTFS junction on my system so Win32 /cygdrive/c => c:\, but this causes a circularity in the file system, which I'd rather not have. As well, there are at least three or four Posix runtimes for Windows, and they each map differently. UWin I think uses /c <=> c:\. Cygwin /cygdrive <=> c:\ Interix/ServicesForUnix/SUA I think something via /dev. MinGWin also has a runtime that I think uses the UWin mapping, but this runtime is only meant for sh/gcc to use, not user apps. Having special code that only knows the Cygwin convention is questionable. I was often setting up some environment variables one way or the other, and then running one cm3 or the other, without thinking about which form the variables were in. Indeed, it might be nice to set CM3_ROOT and CM3_INSTALL "once and for all", while still switching between different forms of cm3.exe? Though granted, CM3_INSTALL cm3.exe can usually figure out from its own path, and CM3_ROOT could usually be figured out by looking at the CVS directories in the current working directory, not always, but often. Basically, instead of setting these varibles one way or the other, I'd like to set them always one way, or even not at all. Hm, in fact, I think cm3 could figure out all overrides itself? You know, if there is a shipped package store, it can use that to determine the source <=> pkg mapping. And it can figure out CM3_ROOT by looking at the current directory and on up until the CVS/Root changes? As well, you know, the source <=> pkg mapping could be a simple generated checked in file. You know, like the PKGS file, but stripped down to only what is needed? Maybe just remove the code I put in and forget the whole thing. Maybe most people only ever stay in one of the worlds and "translation" isn't important? Just me stuck with providing support for both and therefore living with both more? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Tue Apr 22 05:14:00 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 21 Apr 2008 23:14:00 -0400 Subject: [M3devel] more path stuff, sorry In-Reply-To: References: Message-ID: <480D1FB2.1E75.00D7.1@scires.com> I concur wholeheartedly. I absolutely DO NOT want native NT386 to have any knowledge of or dependency on Cygwin. Regards, Randy >>> Tony Hosking 4/21/2008 9:44 PM >>> Why would native NT386 know anything at all about Cygwin. I say just avoid split personalities like the plague. Similarly, I'd be happy for NT386GNU (i.e., Cygwin?) to simply behave like a POSIX build (modulo native threads perhaps). On Apr 21, 2008, at 7:15 PM, Jay wrote: Maybe this is dubious. The question is, like, should native NT386 cm3 accept /cygdrive/c/foo and translate to c:\foo? Or trickier, /usr/bin/foo and translate to c:\cygwin\usr\bin\foo? And vice versa, should NT386GNU accept c:\foo? The translation is not simple in general. / maps to the Cygwin install root. There can be symlinks. But many common cases can be handled with little, simple code. It's already in. Ultimately the way to do this correctly is to link to cygwin1.dll, which is only done sometimes, and which probably license-undesirable when not done. As well, a path like /foo is actually ambiguous. It is a valid native Win32 path, equivalent to \foo. Or it could be Cygwin path requivalent to c:\cygwin\foo. While it is nice to keep cm3 simple, it is also nice to have a more uniform interface across hosts, I think. Maybe. To some extent a user can do this himself. That is, NTFS junctions and/or Cygwin symblinks can cause their to be identical paths with identical meanings: e.g. for me, symlink /msdev => c:\msdev, /cm3 => c:\cm3 /dev => c:\dev2 In some places Cygwin open et. al. accept Win32 paths, but lately taking advantage of that issues a warning. In some places, I think, it isn't sufficient to have Cygwin handle it. The harder question then is, if I feed Cygwin paths of a particular form, should it try to report back paths in the same form? I put some code in M3Path.m3 "like this", but it may not be advisable. I also had an NTFS junction on my system so Win32 /cygdrive/c => c:\, but this causes a circularity in the file system, which I'd rather not have. As well, there are at least three or four Posix runtimes for Windows, and they each map differently. UWin I think uses /c <=> c:\. Cygwin /cygdrive <=> c:\ Interix/ServicesForUnix/SUA I think something via /dev. MinGWin also has a runtime that I think uses the UWin mapping, but this runtime is only meant for sh/gcc to use, not user apps. Having special code that only knows the Cygwin convention is questionable. I was often setting up some environment variables one way or the other, and then running one cm3 or the other, without thinking about which form the variables were in. Indeed, it might be nice to set CM3_ROOT and CM3_INSTALL "once and for all", while still switching between different forms of cm3.exe? Though granted, CM3_INSTALL cm3.exe can usually figure out from its own path, and CM3_ROOT could usually be figured out by looking at the CVS directories in the current working directory, not always, but often. Basically, instead of setting these varibles one way or the other, I'd like to set them always one way, or even not at all. Hm, in fact, I think cm3 could figure out all overrides itself? You know, if there is a shipped package store, it can use that to determine the source <=> pkg mapping. And it can figure out CM3_ROOT by looking at the current directory and on up until the CVS/Root changes? As well, you know, the source <=> pkg mapping could be a simple generated checked in file. You know, like the PKGS file, but stripped down to only what is needed? Maybe just remove the code I put in and forget the whole thing. Maybe most people only ever stay in one of the worlds and "translation" isn't important? Just me stuck with providing support for both and therefore living with both more? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Apr 22 06:16:44 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 22 Apr 2008 04:16:44 +0000 Subject: [M3devel] more path stuff, sorry In-Reply-To: <480D1EAD.1E75.00D7.1@scires.com> References: <480D1EAD.1E75.00D7.1@scires.com> Message-ID: Randy we are kind of saying the same thing. Imagine if you will code out that that assumes all "full paths" start with a forward slash. There is surely a lot of this code. Imagine if you will code out there that assumes that all "full paths" start with either two slashes or a letter, colon, slash. There is a lot of this code too. (I think btw that Windows CE paths all start with one leading slash, and I suspect it must be a backward one, but I don't have a CE Phone yet, maybe soon, ARM_CE? :) ARM_WINCE?) Now imagine that this code is being used in some build automation and feeding the paths it forms to cm3. There is actually probably not much of this, but it is "reasonable". The idea then would be for such code to be "portable" to Posix and/or Win32, without having to adopt "some abstraction". You know...there's some tension in programming, between inventing abstractions and layers to bridge different underlying implementations, ahead of time or in all paths, vs. inserting new layers in some paths to make them "look like" preexisting paths. "Emulation layers" if you will. The advantage of "emulation" is that at least some variants run "native" and skip the "emulation". That is, like, survey the landscape of existing implementations, pick one that is reasonable and popular and easily emulated, write all your code to it, and add an emulation layer for the other cases. The trick of course is that it isn't always possible. Sometimes the job of the "abstraction layer" includes narrowing the underlying interfaces/feature set to the intersection, often refered to as "least common denominator". And then, some "abstraction layers" to "fix" this problem, let you "break through" to the underlying system. Such allowing of "break through" is obviously good and bad in multiple ways. The ability to break through takes away the ability of the layer to be stateful. Stateful layers are also to be avoided in the first place if performance is a concern. Now, in reality, paths are not a great example of this, because paths don't have all that many "features", so an abstraction boundary isn't likely to be lossy. Besides features, there issues of "capacity". For example, imagine I have a system that allows files larger than 4gig and a system that does not. Imagine the portability layer lets through file sizes larger than 4gig. While this enables the better system to have a larger capacity, it also enables a situation where users on one system can write files that users on another cannot read. Sometimes people suggest warnings for these kinds of things, like when you save a Word document in an older format and some formating may or may not be lost. Another problem with abstraction boundaries is you that you inevitably create yet another way of doing things, in the service of papering over that there is already more than one way. The cure is similar to the disease, sort of. You know, there is some set of programmers who can read XWindows code, some set that can read MSWindows, and the set that can read Trestle is bound to be less. Of course, this varies. Like, probably more people are familiar now with MFC, Qt, GTk than XOpenDisplay or CreateWindow. Sometimes the underlying systems are too hard to use, too unfeatureful and the layers built on them are not just for portability but also ease of use and sometimes add a bunch of value. In the end, I think I'll remove the code. But I'm not crazy. Portability can be served by catering to existing practises rather than inventing new ones. But granted it doesn't always work well. The Posix systems for Windows all seem to stink, and Wine seems to really stink. Btw, interesting point I think is how cm3cg manages to not care -- its input and output are always in the current working directory. It doesn't create any threads, no gui. While the "build system", sh, nmake, sed, awk, might have heavier requirements on their runtime (I don't know, haven't looked, not sure if Cygwin was for them or the larger goal), m3cg is light. Gcc is somewhere in between since it does look up paths "around the system" and run sub processes. But it still shouldn't be much OS dependent code, vs. all the work of parsing C, codegen, optimization. I must point out that the landscape is strewn with abstraction boundaries that work a lot and fail a lot. File systems are a huge example here. Some file systems allow files over 2 or 4 gig, some do not. Some perform at the much greater speed of nearby mechanically spinning disks, some at the usually slow rate of a network, some write at the very very slow speed of flash, some (flash) cannot stand too many writes. Some have readonly/hidden/system/etc. bits, some do not. Sometimes people stash the extra data in one form or another, sometimes it tends to get lost (Mac resource fork), sometimes now. I vaguely recall that Mac OSX implements hardlinks on HFS+ in a pretty convoluted way. File systems, thinking about paths, are also a big problem in terms of preservation of file names across file systems. At one extreme is MS-DOS 8.3 and some 14 character Unix systems. At another extreme is 255 character Unicode names. Files created one system cannot necessarily be moved to another. Yet the abstraction boundary to the file system, fopen, or whatever Modula-3 has, doesn't somehow deal with this. You know, you could do something whacky like put everything in a .zip file. But then you lose interoperability when the data would have been ok. Case sensitivity...how many folks think "Win32" is case sensitive and "Unix" is not? And yet, that is not how it works. It depends on the file system. How much code in the world is not prepared for symlinks or hard links? A lot. We muddle along. - Jay Date: Mon, 21 Apr 2008 23:09:39 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] more path stuff, sorry I think I've made my opinion on the path issue known, but just so there is no doubt, I do not want the underlying code trying to translate paths from one format to another. I think this is a recipe for problems since different OS represent paths and switches etc differently. Programmers should use the standard interfaces to construct paths appropriate for the current host operating system. Part of the beauty of Modula-3 is write once run everywhere. I have code that uses pathnames that runs on multiple platforms without the need to make any source code modifications. Regards, Randy>>> Jay 4/21/2008 7:15 PM >>>Maybe this is dubious.The question is, like, should native NT386 cm3 accept /cygdrive/c/foo and translate to c:\foo?Or trickier, /usr/bin/foo and translate to c:\cygwin\usr\bin\foo?And vice versa, should NT386GNU accept c:\foo?The translation is not simple in general./ maps to the Cygwin install root.There can be symlinks.But many common cases can be handled with little, simple code.It's already in.Ultimately the way to do this correctly is to link to cygwin1.dll, which is only done sometimes, and which probably license-undesirable when not done.As well, a path like /foo is actually ambiguous.It is a valid native Win32 path, equivalent to \foo.Or it could be Cygwin path requivalent to c:\cygwin\foo.While it is nice to keep cm3 simple, it is also nice to have a more uniform interfaceacross hosts, I think. Maybe.To some extent a user can do this himself.That is, NTFS junctions and/or Cygwin symblinks can cause their to be identical pathswith identical meanings:e.g. for me, symlink /msdev => c:\msdev, /cm3 => c:\cm3 /dev => c:\dev2In some places Cygwin open et. al. accept Win32 paths, but lately taking advantage ofthat issues a warning. In some places, I think, it isn't sufficient to have Cygwin handle it.The harder question then is, if I feed Cygwin paths of a particular form, should ittry to report back paths in the same form?I put some code in M3Path.m3 "like this", but it may not be advisable.I also had an NTFS junction on my system so Win32 /cygdrive/c => c:\, but this causesa circularity in the file system, which I'd rather not have.As well, there are at least three or four Posix runtimes for Windows, and they each mapdifferently.UWin I think uses /c <=> c:\.Cygwin /cygdrive <=> c:\Interix/ServicesForUnix/SUA I think something via /dev.MinGWin also has a runtime that I think uses the UWin mapping, but this runtime is onlymeant for sh/gcc to use, not user apps.Having special code that only knows the Cygwin convention is questionable. I was often setting up some environment variables one way or the other, and thenrunning one cm3 or the other, without thinking about which form the variables were in.Indeed, it might be nice to set CM3_ROOT and CM3_INSTALL "once and for all",while still switching between different forms of cm3.exe?Though granted, CM3_INSTALL cm3.exe can usually figure out from its own path, andCM3_ROOT could usually be figured out by looking at the CVS directories in the currentworking directory, not always, but often. Basically, instead of setting these variblesone way or the other, I'd like to set them always one way, or even not at all.Hm, in fact, I think cm3 could figure out all overrides itself?You know, if there is a shipped package store, it can use that to determine the source <=> pkg mapping.And it can figure out CM3_ROOT by looking at the current directory and on up until the CVS/Rootchanges? As well, you know, the source <=> pkg mapping could be a simple generated checked in file.You know, like the PKGS file, but stripped down to only what is needed? Maybe just remove the code I put in and forget the whole thing.Maybe most people only ever stay in one of the worlds and "translation" isn't important?Just me stuck with providing support for both and therefore living with both more? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Apr 22 06:19:52 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 22 Apr 2008 04:19:52 +0000 Subject: [M3devel] more path stuff, sorry In-Reply-To: <480D1FB2.1E75.00D7.1@scires.com> References: <480D1FB2.1E75.00D7.1@scires.com> Message-ID: There's no dependency, no linkage. Just a few simple string operations. I'll probably remove it tonight. Modula-3 has a split personality no matter what, in that it calls into very varying underlying layers, often trafficing in their specific data formats. It's just that it can strive to aid portability between them or not, by accepting either input and massaging it to work, vs. passing it along "unchanged" (well, that's not what happens actually). If there were no ambiguous cases and the Posix systems on Windows were consistent in their conventions, I'd be more for it. But the ambiguity and varying Posix conventions weaken the case tremendously. - Jay Date: Mon, 21 Apr 2008 23:14:00 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] more path stuff, sorry I concur wholeheartedly. I absolutely DO NOT want native NT386 to have any knowledge of or dependency on Cygwin. Regards, Randy>>> Tony Hosking 4/21/2008 9:44 PM >>> Why would native NT386 know anything at all about Cygwin. I say just avoid split personalities like the plague. Similarly, I'd be happy for NT386GNU (i.e., Cygwin?) to simply behave like a POSIX build (modulo native threads perhaps). On Apr 21, 2008, at 7:15 PM, Jay wrote: Maybe this is dubious.The question is, like, should native NT386 cm3 accept /cygdrive/c/foo and translate to c:\foo?Or trickier, /usr/bin/foo and translate to c:\cygwin\usr\bin\foo?And vice versa, should NT386GNU accept c:\foo?The translation is not simple in general./ maps to the Cygwin install root.There can be symlinks.But many common cases can be handled with little, simple code.It's already in.Ultimately the way to do this correctly is to link to cygwin1.dll, which is only done sometimes, and which probably license-undesirable when not done.As well, a path like /foo is actually ambiguous.It is a valid native Win32 path, equivalent to \foo.Or it could be Cygwin path requivalent to c:\cygwin\foo.While it is nice to keep cm3 simple, it is also nice to have a more uniform interfaceacross hosts, I think. Maybe.To some extent a user can do this himself.That is, NTFS junctions and/or Cygwin symblinks can cause their to be identical pathswith identical meanings:e.g. for me, symlink /msdev => c:\msdev, /cm3 => c:\cm3 /dev => c:\dev2In some places Cygwin open et. al. accept Win32 paths, but lately taking advantage ofthat issues a warning. In some places, I think, it isn't sufficient to have Cygwin handle it.The harder question then is, if I feed Cygwin paths of a particular form, should ittry to report back paths in the same form?I put some code in M3Path.m3 "like this", but it may not be advisable.I also had an NTFS junction on my system so Win32 /cygdrive/c => c:\, but this causesa circularity in the file system, which I'd rather not have.As well, there are at least three or four Posix runtimes for Windows, and they each mapdifferently.UWin I think uses /c <=> c:\.Cygwin /cygdrive <=> c:\Interix/ServicesForUnix/SUA I think something via /dev.MinGWin also has a runtime that I think uses the UWin mapping, but this runtime is onlymeant for sh/gcc to use, not user apps.Having special code that only knows the Cygwin convention is questionable. I was often setting up some environment variables one way or the other, and thenrunning one cm3 or the other, without thinking about which form the variables were in.Indeed, it might be nice to set CM3_ROOT and CM3_INSTALL "once and for all",while still switching between different forms of cm3.exe?Though granted, CM3_INSTALL cm3.exe can usually figure out from its own path, andCM3_ROOT could usually be figured out by looking at the CVS directories in the currentworking directory, not always, but often. Basically, instead of setting these variblesone way or the other, I'd like to set them always one way, or even not at all.Hm, in fact, I think cm3 could figure out all overrides itself?You know, if there is a shipped package store, it can use that to determine the source <=> pkg mapping.And it can figure out CM3_ROOT by looking at the current directory and on up until the CVS/Rootchanges? As well, you know, the source <=> pkg mapping could be a simple generated checked in file.You know, like the PKGS file, but stripped down to only what is needed? Maybe just remove the code I put in and forget the whole thing.Maybe most people only ever stay in one of the worlds and "translation" isn't important?Just me stuck with providing support for both and therefore living with both more? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Apr 22 06:28:23 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 22 Apr 2008 04:28:23 +0000 Subject: [M3devel] FW: more path stuff, sorry In-Reply-To: <480D1FB2.1E75.00D7.1@scires.com> References: <480D1FB2.1E75.00D7.1@scires.com> Message-ID: [truncated]... From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] more path stuff, sorryDate: Tue, 22 Apr 2008 04:19:52 +0000 There's no dependency, no linkage. Just a few simple string operations.I'll probably remove it tonight. Modula-3 has a split personality no matter what, in that it calls into very varying underlying layers, often trafficing in their specific data formats.It's just that it can strive to aid portability between them or not, by accepting either input and massaging it to work, vs. passing it along "unchanged" (well, that's not what happens actually). If there were no ambiguous cases and the Posix systems on Windows were consistent in their conventions, I'd be more for it. But the ambiguity and varying Posix conventions weaken the case tremendously. - Jay Date: Mon, 21 Apr 2008 23:14:00 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] more path stuff, sorry I concur wholeheartedly. I absolutely DO NOT want native NT386 to have any knowledge of or dependency on Cygwin. Regards, Randy>>> Tony Hosking 4/21/2008 9:44 PM >>> Why would native NT386 know anything at all about Cygwin. I say just avoid split personalities like the plague. Similarly, I'd be happy for NT386GNU (i.e., Cygwin?) to simply behave like a POSIX build (modulo native threads perhaps). On Apr 21, 2008, at 7:15 PM, Jay wrote: Maybe this is dubious.The question is, like, should native NT386 cm3 accept /cygdrive/c/foo and translate to c:\foo?Or trickier, /usr/bin/foo and translate to c:\cygwin\usr\bin\foo?And vice versa, should NT386GNU accept c:\foo?... -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Apr 22 14:29:09 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 22 Apr 2008 08:29:09 -0400 Subject: [M3devel] FW: more path stuff, sorry In-Reply-To: References: <480D1FB2.1E75.00D7.1@scires.com> Message-ID: <08DD9502-27D3-4C5C-9E30-A9E9D2CADAB4@cs.purdue.edu> Jay, there is an underlying principle here that you seem to be missing so I will make it explicit. Cross-product systems tend to acquire unmanageable complexity, especially when it comes to testing. By making each target one personality we are able to test machine- dependent code in isolation from machine-independent code. Often, when something breaks on one target I will test on another just to isolate the problem. This is a very powerful approach and I am very leery of destroying any ability to do this -- it allows us to maintain the high-level portability of most Modula-3 code while isolating the small fraction of machine-/target-dependent stuff. On Apr 22, 2008, at 12:28 AM, Jay wrote: > [truncated]... > > > > > From: jayk123 at hotmail.com > To: rcoleburn at scires.com; m3devel at elegosoft.com > Subject: RE: [M3devel] more path stuff, sorry > Date: Tue, 22 Apr 2008 04:19:52 +0000 > > There's no dependency, no linkage. Just a few simple string > operations. > I'll probably remove it tonight. > > Modula-3 has a split personality no matter what, in that it calls > into very varying underlying layers, often trafficing in their > specific data formats. > It's just that it can strive to aid portability between them or not, > by accepting either input and massaging it to work, vs. passing it > along "unchanged" (well, that's not what happens actually). If there > were no ambiguous cases and the Posix systems on Windows were > consistent in their conventions, I'd be more for it. But the > ambiguity and varying Posix conventions weaken the case tremendously. > > - Jay > > Date: Mon, 21 Apr 2008 23:14:00 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] more path stuff, sorry > > I concur wholeheartedly. I absolutely DO NOT want native NT386 to > have any knowledge of or dependency on Cygwin. > Regards, > Randy > > >>> Tony Hosking 4/21/2008 9:44 PM >>> > Why would native NT386 know anything at all about Cygwin. I say > just avoid split personalities like the plague. Similarly, I'd be > happy for NT386GNU (i.e., Cygwin?) to simply behave like a POSIX > build (modulo native threads perhaps). > > On Apr 21, 2008, at 7:15 PM, Jay wrote: > > Maybe this is dubious. > > The question is, like, should native NT386 cm3 accept /cygdrive/c/ > foo and translate to c:\foo? > Or trickier, /usr/bin/foo and translate to c:\cygwin\usr\bin\foo? > And vice versa, should NT386GNU accept c:\foo? > > ... -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Apr 22 14:52:05 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 22 Apr 2008 12:52:05 +0000 Subject: [M3devel] type mismatches? Message-ID: 4797 NEXT Fatal Error: bad version stamps: SocketPosix.m3 4798 4799 version stamp mismatch: Compiler.Platform 4800 => SocketPosix.m3 4801 => Compiler.i3 4802 version stamp mismatch: Compiler.ThisPlatform 4803 => SocketPosix.m3 4804 => Compiler.i3 This is now in the Tinderbox, on some machines, e.g. FreeBSD4. I have two source trees on same machine sharing same install root, one sees it, one does not. Even though I start the install root out by extracting the same initial snapshot, I think. I think they are the same except for path but that needs scrutiny. I am making SOME attempt to isolate it, but I'm not looking forward to it.. One expensive potshot is wait for a full hours-long gcc build with no switches. In case it is a cm3cg problem, emanating from the compiler used to build cm3cg. (I just did another build of cm3cg, took 11 minutes..) That is: There is a problem here. It's not just me. I MIGHT find it. If anyone can save me the trouble, please do. :) Other potshots include more conservative codegen like -fno-reorder-blocks -mno-double-align -O0, some/all of which are already in use. I was going to commit blindly such conservatism for FreeBSD4, however my local repro is persisting despite this. It could still be some simple bootstrapping issue. I don't know. SocketPosix is only using Compiler for some dormant platforms. The code is probably dead. But hey, extra dead code finds extra live bugs. :) Question: Am I correct that, in the absence of cm3/cm3cg/underlying bugs, the following should never occur: cd .../m3core rm -rf cm3 cm3 -ship cd ../libm3 rm -rf cm3 => version stamp mismatch ? That is -- if this happens, it can't be any bootstrapping problem? These checks are libm3 vs. m3core, right? What the compiler itself is? - Jay From hosking at cs.purdue.edu Tue Apr 22 19:02:47 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 22 Apr 2008 13:02:47 -0400 Subject: [M3devel] type mismatches? In-Reply-To: References: Message-ID: This happens whenever you add a new target to the compiler. You need to bootstrap a new compiler with the old libraries (m3core, libm3) before trying to build the new libraries containing the new Compiler.tmpl. On Apr 22, 2008, at 8:52 AM, Jay wrote: > > 4797 NEXT Fatal Error: bad version stamps: SocketPosix.m3 > 4798 > 4799 version stamp mismatch: Compiler.Platform > 4800 => SocketPosix.m3 > 4801 => Compiler.i3 > 4802 version stamp mismatch: Compiler.ThisPlatform > 4803 => SocketPosix.m3 > 4804 => Compiler.i3 > > This is now in the Tinderbox, on some machines, e.g. FreeBSD4. > I have two source trees on same machine sharing same install root, > one sees it, one does not. > Even though I start the install root out by extracting the same > initial snapshot, I think. > I think they are the same except for path but that needs scrutiny. > > I am making SOME attempt to isolate it, but I'm not looking forward > to it.. > One expensive potshot is wait for a full hours-long gcc build with > no switches. > In case it is a cm3cg problem, emanating from the compiler used to > build cm3cg. > (I just did another build of cm3cg, took 11 minutes..) > > That is: > There is a problem here. It's not just me. I MIGHT find it. > If anyone can save me the trouble, please do. :) > > Other potshots include more conservative codegen like -fno-reorder- > blocks -mno-double-align -O0, some/all of which are already in use. > I was going to commit blindly such conservatism for FreeBSD4, > however my local repro is persisting despite this. > > It could still be some simple bootstrapping issue. I don't know. > > SocketPosix is only using Compiler for some dormant platforms. The > code is probably dead. > But hey, extra dead code finds extra live bugs. :) > > Question: > Am I correct that, in the absence of cm3/cm3cg/underlying bugs, the > following should never occur: > cd .../m3core > rm -rf > cm3 > cm3 -ship > cd ../libm3 > rm -rf > cm3 > => version stamp mismatch > > ? That is -- if this happens, it can't be any bootstrapping problem? > These checks are libm3 vs. m3core, right? What the compiler itself is? > > - Jay From jayk123 at hotmail.com Tue Apr 22 20:31:53 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 22 Apr 2008 18:31:53 +0000 Subject: [M3devel] type mismatches? In-Reply-To: References: Message-ID: Tony, I thought I understood, I thought the automation handled this, both that I run and that the Tinderbox runs, such that one would never see this. I'll poke around a bit more. Oh, I think I see now. m3front/src/builtInfo/InfoModule.m3 This will happen also if you only change one side. Could be I had that edit on my machine. Still not sure about the Tinderbox but I'll wait and see. Thanks, - Jay > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jayk123 at hotmail.com > Subject: Re: [M3devel] type mismatches? > Date: Tue, 22 Apr 2008 13:02:47 -0400 > > This happens whenever you add a new target to the compiler. You need > to bootstrap a new compiler with the old libraries (m3core, libm3) > before trying to build the new libraries containing the new > Compiler.tmpl. > > On Apr 22, 2008, at 8:52 AM, Jay wrote: > > > > > 4797 NEXT Fatal Error: bad version stamps: SocketPosix.m3 > > 4798 > > 4799 version stamp mismatch: Compiler.Platform > > 4800 => SocketPosix.m3 > > 4801 => Compiler.i3 > > 4802 version stamp mismatch: Compiler.ThisPlatform > > 4803 => SocketPosix.m3 > > 4804 => Compiler.i3 > > > > This is now in the Tinderbox, on some machines, e.g. FreeBSD4. > > I have two source trees on same machine sharing same install root, > > one sees it, one does not. > > Even though I start the install root out by extracting the same > > initial snapshot, I think. > > I think they are the same except for path but that needs scrutiny. > > > > I am making SOME attempt to isolate it, but I'm not looking forward > > to it.. > > One expensive potshot is wait for a full hours-long gcc build with > > no switches. > > In case it is a cm3cg problem, emanating from the compiler used to > > build cm3cg. > > (I just did another build of cm3cg, took 11 minutes..) > > > > That is: > > There is a problem here. It's not just me. I MIGHT find it. > > If anyone can save me the trouble, please do. :) > > > > Other potshots include more conservative codegen like -fno-reorder- > > blocks -mno-double-align -O0, some/all of which are already in use. > > I was going to commit blindly such conservatism for FreeBSD4, > > however my local repro is persisting despite this. > > > > It could still be some simple bootstrapping issue. I don't know. > > > > SocketPosix is only using Compiler for some dormant platforms. The > > code is probably dead. > > But hey, extra dead code finds extra live bugs. :) > > > > Question: > > Am I correct that, in the absence of cm3/cm3cg/underlying bugs, the > > following should never occur: > > cd .../m3core > > rm -rf > > cm3 > > cm3 -ship > > cd ../libm3 > > rm -rf > > cm3 > > => version stamp mismatch > > > > ? That is -- if this happens, it can't be any bootstrapping problem? > > These checks are libm3 vs. m3core, right? What the compiler itself is? > > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Wed Apr 23 06:00:43 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 23 Apr 2008 06:00:43 +0200 (CEST) Subject: [M3devel] FW: more path stuff, sorry In-Reply-To: <08DD9502-27D3-4C5C-9E30-A9E9D2CADAB4@cs.purdue.edu> Message-ID: <135722.70767.qm@web27113.mail.ukl.yahoo.com> Hi all: Does pm3 treat NT386GNU paths as POSIX class? I think if one take the definition the Interface Pathname, NT386GNU target should not have access directly to use POSIX paths but Win32 ones because of: "A Pathname.T (or just a pathname) is a text conforming to the syntax of the underlying operating system" in http://www.opencm3.net/doc/help/gen_html/libm3/src/os/Common/Pathname.i3.html But if we think in "the underlying operating system" as the cygwin api, it should be the natural POSIX paths. I agree Pathname is a common interface, but what happens with that sense of portability we want? Maybe the answer is in the cygwin api; the non-standard functions of converting one style to the other: http://cygwin.com/cygwin-api/cygwin-functions.html . See http://www.cygwin.com/cygwin-ug-net/using.html#using-pathnames for the main notes of compatibility. It seems clear that cygwin can use both kind of path styles, so it's not a problem to use just one of POSIX or Win32 paths. So defining a Pathname of type POSIX style for NT386GNU, it is not resign to the more capable functions of cygwin? I mean if Pathname accept both kind of forward and back slashes in different Pathnames it should be defined a new kind of Pathname syntax. Oh I remember saw the mix of both kind of slashes in pm3 quake/config files of NT386GNU :) Is this really confusing or unthinkable? I think this is clear for some of yous (NT386GNU should just accept POSIX paths, not even a Win32 one, and obviously not a mix of the two syntax in a same path), but it is not for me. In my opinion both styles should be acceptable without defining a new kind of path syntax, and convert only using the cygwin api functions. For instance when using netbios resources but also trying to mount disks partitions on the cygwin mount table file we need both kind of syntax. Is that even logical? Thanks in advance. Tony Hosking escribi?: Jay, there is an underlying principle here that you seem to be missing so I will make it explicit. Cross-product systems tend to acquire unmanageable complexity, especially when it comes to testing. By making each target one personality we are able to test machine-dependent code in isolation from machine-independent code. Often, when something breaks on one target I will test on another just to isolate the problem. This is a very powerful approach and I am very leery of destroying any ability to do this -- it allows us to maintain the high-level portability of most Modula-3 code while isolating the small fraction of machine-/target-dependent stuff. On Apr 22, 2008, at 12:28 AM, Jay wrote: [truncated]... --------------------------------- From: jayk123 at hotmail.com To: rcoleburn at scires.com; m3devel at elegosoft.com Subject: RE: [M3devel] more path stuff, sorry Date: Tue, 22 Apr 2008 04:19:52 +0000 There's no dependency, no linkage. Just a few simple string operations. I'll probably remove it tonight. Modula-3 has a split personality no matter what, in that it calls into very varying underlying layers, often trafficing in their specific data formats. It's just that it can strive to aid portability between them or not, by accepting either input and massaging it to work, vs. passing it along "unchanged" (well, that's not what happens actually). If there were no ambiguous cases and the Posix systems on Windows were consistent in their conventions, I'd be more for it. But the ambiguity and varying Posix conventions weaken the case tremendously. - Jay --------------------------------- Date: Mon, 21 Apr 2008 23:14:00 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] more path stuff, sorry I concur wholeheartedly. I absolutely DO NOT want native NT386 to have any knowledge of or dependency on Cygwin. Regards, Randy >>> Tony Hosking 4/21/2008 9:44 PM >>> Why would native NT386 know anything at all about Cygwin. I say just avoid split personalities like the plague. Similarly, I'd be happy for NT386GNU (i.e., Cygwin?) to simply behave like a POSIX build (modulo native threads perhaps). On Apr 21, 2008, at 7:15 PM, Jay wrote: Maybe this is dubious. The question is, like, should native NT386 cm3 accept /cygdrive/c/foo and translate to c:\foo? Or trickier, /usr/bin/foo and translate to c:\cygwin\usr\bin\foo? And vice versa, should NT386GNU accept c:\foo? ... --------------------------------- Enviado desde Correo Yahoo! La bandeja de entrada m?s inteligente. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Apr 23 06:44:23 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Apr 2008 04:44:23 +0000 Subject: [M3devel] FW: more path stuff, sorry In-Reply-To: <135722.70767.qm@web27113.mail.ukl.yahoo.com> References: <08DD9502-27D3-4C5C-9E30-A9E9D2CADAB4@cs.purdue.edu> <135722.70767.qm@web27113.mail.ukl.yahoo.com> Message-ID: Daniel, this should address SOME but not necessarily all of your concern and questions: The underlying libraries are mostly Cygwin. Underlying THEM is another library, but the way it works, there is approximately zero "break through". Except for threads. Also, I intend, somehow, to expose FilePosix.T and FileWin32.T, besides the regular File.T. This would be part of enabling the serial package to build, using strictly "break through" and the Win32 code. However FilePosix.m3 and FileWin32.m3 both reveal File.T. I need to split the revelation out into a separate interface/module I think, shouldn't be hard. >From SOME point of view, forward slashes are perfectly acceptable in Win32 paths and have the same meaning as backward slashs. It is not 100%, but largely. This isn't Modula-3 code doing any "translation" but the Modula-3 does treat \ and / equivalent upon read. The lowest level Win32 File functions in kernel32.dll -- CreateFile, DeleteFile, MoveFile, CreateDirectory, RemoveDirectory, CopyFile, GetCurrentDirectory, SetCurrentDirectory, GetFileAttributes[Ex], FindFirst[Next]File[Ex], what else am I forgetting? Maybe CreateProcess? GetFullPathName, GetShortPathName, usually consider \ and / the same. Unless the paths starts \\?. The / are all converted to \ before getting to the underlying system, the NtCreateFile, where strictly \ is the separator and there is no working directory. If a path starts \\?, it is passed on directly. You don't have to pass full paths. You can pass a handle to a parent directory. Now, I recently read, regarding NTFS-3G for Linux, about allowing : and \ in file names. The claim is that if you install SFU (Services For Unix, previously Interix, now SUA), you can access such names on NT. I tried it out. In fact this claim seems wrong. I create those paths, and then enumerated and printed from Win32. Their lower 8 bits were : and \. But their upper 8 bits were 0xF0 or 0xFF or somesuch. SFU has some ability to access unicode file names, but not that I could find that would reveal this trickery. In particular, there is like wcs_opendir that opens a directory with a unicode path, but there is only the asii/ansi/utf8/7bit/8bit/whatever readdir/readdir_r. So the 0xF000 cannot show through. And proper unicode Win32 code still doesn't see ':' or '\' per se in file names (in paths, but not individual names). I think I happened to accidentally copy this stuff to a Linux machine, and they didn't come across as ':' or '\'. Maybe I used wine cmd copy though. I should try with NTFS-3G. I do suspect I'll get ':' and '\'. Speaking of portability -- should Modula-3 on Posix systems allow file names with ':' and '\'? There are pluses and minuses. It's a rhetorical question -- in that, I don't really want to discuss it that much. I don't think there's a good answer, so I'd just as soon leave the code alone vs. trying in vain to come up with what is "correct". Yes there are Cygwin specific functions for converting paths. It would be reasonable for some NT386GNU-specific paths to use them. You can write up the *.i3 files and call them where you deem appropriate. Where deemed appropriate is not clear. It would not be great for the NT386 tools to use them -- to link to cygwin1.dll, for any reason. Maybe via LoadLibrary/GetProcAddress -- an optional dependency. Maybe. I believe "linkage" should mean "static linkage in the same file" and not "dynamic linkage in the same process" but it isn't up to me and it very well might be this way. I think the Linux kernel grants an exception, but I'm skeptical that non-GPL code doesn't dynamically link to in-proc GPL code that hasn't granted an exception. Anyway, Modula-3 except for NT386GNU is not in any uniquely worrying boat, for sure. You see, like my little speech about emulation layers and "break though", Cygwin is an emulation layer. But its users may or may not consider it to have much "break through". It's users might be very accustomed to Posix paths and a full set of Posix-path-using tools, and have no need to give any of them a Win32 path, and if they do, might be prepared to stop and think about it and do their own conversion. I think it's gray, because gcc as a compiler is arguably way more valuable than a Posix porting layer for other code. Or really, they are both useful. Some people will want one, or the other, or both, or neither. And again I am confusing Cygwin, NT386GNU, and the backend vs. the runtime. You can very well combine the integrated backend with a Posixish runtime -- remember all the systems now have the integrated backend, you should be able to output NT386 .obj files on any platform just by saying TARGET= "NT386" in cm3.cfg. And you can combine the gcc backend with a Win32 runtime -- that is what NT386MINGNU is. Also, while kernel32.dll treats / like \, other Win32 functions/libraries do not, such as comdlg32.dll (File.Open, File.Save), and shlwapi.dll, I think. You'd have to read the docs and/or experiment. Win32 has a lot of nice internal consistencies, but it isn't 100% consistent. Probably nothing is. A mix of slashes works fine on NT386. Does some of this make sense? Again again again, "NT386GNU" is different things to different people, and some of them are in fact independent and you can pick and chose which parts you compose. There is the runtime the compiler uses. There is the backend. There is the library the output uses, both the "C library" (fopen), the threading library (pthreads vs. Win32), the windowing library (X Windows vs. Win32), the naming conventions (libfoo.a vs. foo.lib). Nearly every one of these factors is independent of the others, The config files are written as such and you should be able to experiment and make your own other combinations. Three such combinations are provided, and there's sort of a tendency for the host and the target to be the same, but they don't have to be. There are other factors, like which C compiler do you use, which linker. The compiler, backend, and linker conspire to determine which debugger you can use. If you se the integrated backend and MS linker, you can use MS debuggers. If you use the gcc backend and GNU linker, you can use gdb. Oh, well you can always use either debugger, but the point here is if you have symbols or not. Currently there is some problem mixing the gcc backend with the MS linker and/or the integrated backend with the GNU linker. I think gcc backend with MS linker, and only sometimes the other. There is a symbol alway injected into the .o files that the GNU linker knows about but that the MS linker gives as unresolved. The MS linker has a different name for it, but I don't believe it is always injected by the integrated backend. This is the symbol that lets you point to the start of your image, it is __ImageBase in MS. It isn't used much. But for some reason gcc always generates references to it, and gives it a different name. Therefore some of the supposedly independent factors are not independent as they should be. For network paths, Cygwin allows //machine/server. Current Cygwin issues warnings when you use Win32 paths, and the warning says you can quash it by setting CYGWIN=nodospathwarning or somesuch. Does this make some sense? At some point maybe I'll put together distributions for other combinations. Oh, one more thing, the gcc backend can use __int64. I was feeling guilty about taking so long adding that to the integrated backend, thus I fast-forwarded and got NT386GNU to work. I should still go back and add it though. Also, currently the compiler assumes some linkage of these factors. It assumes OS_TYPE=POSIX means targeting Cygwin. Eh that's pretty much correct. At some point maybe UWin and SFU will be options, but not right now. The compiler's main concern is the jumpbuf size, which is much larger for Cygwin. You can to some extent maybe link NT386 and NT386GNU together, but this jumpbuf thing could really hurt in a hard to diagnose way. (Maybe it's safe due to setjmp vs. _setjmp?)? Sorry this is too long. As Olaf said, what I say might be very true and an accurate model, but it confuses everyone. People want very very few variables. Sorry I have to run, no proofreading this "masterpiece". - Jay Date: Wed, 23 Apr 2008 06:00:43 +0200From: dabenavidesd at yahoo.esTo: m3devel at elegosoft.comSubject: Re: [M3devel] FW: more path stuff, sorryHi all:Does pm3 treat NT386GNU paths as POSIX class? I think if one take the definition the Interface Pathname, NT386GNU target should not have access directly to use POSIX paths but Win32 ones because of:"A Pathname.T (or just a pathname) is a text conforming to the syntax of the underlying operating system" inhttp://www.opencm3.net/doc/help/gen_html/libm3/src/os/Common/Pathname.i3.htmlBut if we think in "the underlying operating system" as the cygwin api, it should be the natural POSIX paths.I agree Pathname is a common interface, but what happens with that sense of portability we want? Maybe the answer is in the cygwin api; the non-standard functions of converting one style to the other: http://cygwin.com/cygwin-api/cygwin-functions.html .See http://www.cygwin.com/cygwin-ug-net/using.html#using-pathnamesfor the main notes of compatibility. It seems clear that cygwin can use both kind of path styles, so it's not a problem to use just one of POSIX or Win32 paths. So defining a Pathname of type POSIX style for NT386GNU, it is not resign to the more capable functions of cygwin?I mean if Pathname accept both kind of forward and back slashes in different Pathnames it should be defined a new kind of Pathname syntax. Oh I remember saw the mix of both kind of slashes in pm3 quake/config files of NT386GNU :) Is this really confusing or unthinkable?I think this is clear for some of yous (NT386GNU should just accept POSIX paths, not even a Win32 one, and obviously not a mix of the two syntax in a same path), but it is not for me.In my opinion both styles should be acceptable without defining a new kind of path syntax, and convert only using the cygwin api functions. For instance when using netbios resources but also trying to mount disks partitions on the cygwin mount table file we need both kind of syntax. Is that even logical?Thanks in advance.Tony Hosking escribi?: Jay, there is an underlying principle here that you seem to be missing so I will make it explicit. Cross-product systems tend to acquire unmanageable complexity, especially when it comes to testing. By making each target one personality we are able to test machine-dependent code in isolation from machine-independent code. Often, when something breaks on one target I will test on another just to isolate the problem. This is a very powerful approach and I am very leery of destroying any ability to do this -- it allows us to maintain the high-level portability of most Modula-3 code while isolating the small fraction of machine-/target-dependent stuff. On Apr 22, 2008, at 12:28 AM, Jay wrote: [truncated]... From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] more path stuff, sorryDate: Tue, 22 Apr 2008 04:19:52 +0000There's no dependency, no linkage. Just a few simple string operations.I'll probably remove it tonight. Modula-3 has a split personality no matter what, in that it calls into very varying underlying layers, often trafficing in their specific data formats.It's just that it can strive to aid portability between them or not, by accepting either input and massaging it to work, vs. passing it along "unchanged" (well, that's not what happens actually). If there were no ambiguous cases and the Posix systems on Windows were consistent in their conventions, I'd be more for it. But the ambiguity and varying Posix conventions weaken the case tremendously. - Jay Date: Mon, 21 Apr 2008 23:14:00 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] more path stuff, sorry I concur wholeheartedly. I absolutely DO NOT want native NT386 to have any knowledge of or dependency on Cygwin. Regards, Randy>>> Tony Hosking 4/21/2008 9:44 PM >>> Why would native NT386 know anything at all about Cygwin. I say just avoid split personalities like the plague. Similarly, I'd be happy for NT386GNU (i.e., Cygwin?) to simply behave like a POSIX build (modulo native threads perhaps). On Apr 21, 2008, at 7:15 PM, Jay wrote: Maybe this is dubious.The question is, like, should native NT386 cm3 accept /cygdrive/c/foo and translate to c:\foo?Or trickier, /usr/bin/foo and translate to c:\cygwin\usr\bin\foo?And vice versa, should NT386GNU accept c:\foo?... Enviado desde Correo Yahoo!La bandeja de entrada m?s inteligente. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Apr 23 06:59:51 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Apr 2008 04:59:51 +0000 Subject: [M3devel] FW: more path stuff, sorry In-Reply-To: <135722.70767.qm@web27113.mail.ukl.yahoo.com> References: <08DD9502-27D3-4C5C-9E30-A9E9D2CADAB4@cs.purdue.edu> <135722.70767.qm@web27113.mail.ukl.yahoo.com> Message-ID: I forgot some points.Daniel, in order to convert paths between the two, you need context to know what type the provider of the path intended. There are paths that are valid in both systems but that have different means. The path /usr/bin in Win32 is the same as \usr\bin and on the drive of the current working directory (the working, if you will)The path /usr/bin in Cygwin is \usr\bin under the Cygwin root, so often like c:\cygwin\usr\bin. The path /cygdrive/c/foo is also valid in Win32, and has a different meaning there than in Cygwin. Get it? The path c:/foo is unambiguous. The "string" c:/foo is ambiguous, depending on point of view. Let's say I want a string that contains colon delimited paths. Then this is the path c and the path /foo. But if paths themselves can have colons then it is also the single element list with the element c:/foo. You could get fancy shmancy and escape the colon c\:/foo but that's insane. Quoting is already a big problem in existing systems and usage, and I just made that garbage up. One of the points maybe the Modula-3 folks are alluding is that Pathname.T is a TYPE with an INTERFACE. It is not a "string". In many other systems a "path" is "just" a "string", it just gets pass around, and both sides party on it and hope they give it the same meaning. If your notion of type is not clear, between Win32 and Posix, then neither is the meaning. Strings are a terribly loose overused type.... This does save people from coming up with those fancy complicated difficult to learn INTERFACES, and it aids interoperability, since everyone can use a string...it's good and it's bad, the glass is half full and half empty... c:\ "looks" like a win32 path, but hey, be careful there, I'm just smiling big and wearing a crooked hat, you have interpreted it completely incorretly, eh? Types are important. I think much more so than modules. And /foo/ looks like a Posix path, but actually it's italicized text. :) Or then again, this whole email is a valid Posix path, newlines and all, since it has no embedded nuls. :) - Jay From: jayk123 at hotmail.comTo: dabenavidesd at yahoo.es; m3devel at elegosoft.comSubject: RE: [M3devel] FW: more path stuff, sorryDate: Wed, 23 Apr 2008 04:44:23 +0000 Daniel, this should address SOME but not necessarily all of your concern and questions: The underlying libraries are mostly Cygwin.Underlying THEM is another library, but the way it works, there is approximately zero "break through".Except for threads.Also, I intend, somehow, to expose FilePosix.T and FileWin32.T, besides the regular File.T.This would be part of enabling the serial package to build, using strictly "break through" and the Win32 code.However FilePosix.m3 and FileWin32.m3 both reveal File.T. I need to split the revelation out into a separate interface/module I think, shouldn't be hard. From SOME point of view, forward slashes are perfectly acceptable in Win32 paths and have the same meaning as backward slashs. It is not 100%, but largely. This isn't Modula-3 code doing any "translation" but the Modula-3 does treat \ and / equivalent upon read. The lowest level Win32 File functions in kernel32.dll -- CreateFile, DeleteFile, MoveFile, CreateDirectory, RemoveDirectory, CopyFile, GetCurrentDirectory, SetCurrentDirectory, GetFileAttributes[Ex], FindFirst[Next]File[Ex], what else am I forgetting? Maybe CreateProcess? GetFullPathName, GetShortPathName, usually consider \ and / the same. Unless the paths starts \\?. The / are all converted to \ before getting to the underlying system, the NtCreateFile, where strictly \ is the separator and there is no working directory. If a path starts \\?, it is passed on directly. You don't have to pass full paths. You can pass a handle to a parent directory. Now, I recently read, regarding NTFS-3G for Linux, about allowing : and \ in file names.The claim is that if you install SFU (Services For Unix, previously Interix, now SUA), you can access such names on NT.I tried it out. In fact this claim seems wrong. I create those paths, and then enumerated and printed from Win32. Their lower 8 bits were : and \. But their upper 8 bits were 0xF0 or 0xFF or somesuch. SFU has some ability to access unicode file names, but not that I could find that would reveal this trickery. In particular, there is like wcs_opendir that opens a directory with a unicode path, but there is only the asii/ansi/utf8/7bit/8bit/whatever readdir/readdir_r. So the 0xF000 cannot show through.And proper unicode Win32 code still doesn't see ':' or '\' per se in file names (in paths, but not individual names). I think I happened to accidentally copy this stuff to a Linux machine, and they didn't come across as ':' or '\'.Maybe I used wine cmd copy though. I should try with NTFS-3G. I do suspect I'll get ':' and '\'. Speaking of portability -- should Modula-3 on Posix systems allow file names with ':' and '\'? There are pluses and minuses. It's a rhetorical question -- in that, I don't really want to discuss it that much. I don't think there's a good answer, so I'd just as soon leave the code alone vs. trying in vain to come up with what is "correct". Yes there are Cygwin specific functions for converting paths.It would be reasonable for some NT386GNU-specific paths to use them.You can write up the *.i3 files and call them where you deem appropriate. Where deemed appropriate is not clear.It would not be great for the NT386 tools to use them -- to link to cygwin1.dll, for any reason.Maybe via LoadLibrary/GetProcAddress -- an optional dependency. Maybe.I believe "linkage" should mean "static linkage in the same file" and not "dynamic linkage in the same process" but it isn't up to me and it very well might be this way. I think the Linux kernel grants an exception, but I'm skeptical that non-GPL code doesn't dynamically link to in-proc GPL code that hasn't granted an exception. Anyway, Modula-3 except for NT386GNU is not in any uniquely worrying boat, for sure. You see, like my little speech about emulation layers and "break though", Cygwin is an emulation layer.But its users may or may not consider it to have much "break through".It's users might be very accustomed to Posix paths and a full set of Posix-path-using tools, and have no need to give any of them a Win32 path, and if they do, might be prepared to stop and think about it and do their own conversion. I think it's gray, because gcc as a compiler is arguably way more valuable than a Posix porting layer for other code.Or really, they are both useful. Some people will want one, or the other, or both, or neither. And again I am confusing Cygwin, NT386GNU, and the backend vs. the runtime. You can very well combine the integrated backend with a Posixish runtime -- remember all the systems now have the integrated backend, you should be able to output NT386 .obj files on any platform just by saying TARGET= "NT386" in cm3.cfg. And you can combine the gcc backend with a Win32 runtime -- that is what NT386MINGNU is. Also, while kernel32.dll treats / like \, other Win32 functions/libraries do not, such as comdlg32.dll (File.Open, File.Save), and shlwapi.dll, I think. You'd have to read the docs and/or experiment.Win32 has a lot of nice internal consistencies, but it isn't 100% consistent. Probably nothing is. A mix of slashes works fine on NT386. Does some of this make sense? Again again again, "NT386GNU" is different things to different people, and some of them are in fact independent and you can pick and chose which parts you compose. There is the runtime the compiler uses. There is the backend. There is the library the output uses, both the "C library" (fopen), the threading library (pthreads vs. Win32), the windowing library (X Windows vs. Win32), the naming conventions (libfoo.a vs. foo.lib). Nearly every one of these factors is independent of the others, The config files are written as such and you should be able to experiment and make your own other combinations. Three such combinations are provided, and there's sort of a tendency for the host and the target to be the same, but they don't have to be. There are other factors, like which C compiler do you use, which linker. The compiler, backend, and linker conspire to determine which debugger you can use. If you se the integrated backend and MS linker, you can use MS debuggers. If you use the gcc backend and GNU linker, you can use gdb. Oh, well you can always use either debugger, but the point here is if you have symbols or not. Currently there is some problem mixing the gcc backend with the MS linker and/or the integrated backend with the GNU linker. I think gcc backend with MS linker, and only sometimes the other. There is a symbol alway injected into the .o files that the GNU linker knows about but that the MS linker gives as unresolved. The MS linker has a different name for it, but I don't believe it is always injected by the integrated backend. This is the symbol that lets you point to the start of your image, it is __ImageBase in MS. It isn't used much. But for some reason gcc always generates references to it, and gives it a different name. Therefore some of the supposedly independent factors are not independent as they should be. For network paths, Cygwin allows //machine/server. Current Cygwin issues warnings when you use Win32 paths, and the warning says you can quash it by setting CYGWIN=nodospathwarning or somesuch. Does this make some sense? At some point maybe I'll put together distributions for other combinations. Oh, one more thing, the gcc backend can use __int64.I was feeling guilty about taking so long adding that to the integrated backend, thus I fast-forwarded and got NT386GNU to work. I should still go back and add it though. Also, currently the compiler assumes some linkage of these factors. It assumes OS_TYPE=POSIX means targeting Cygwin. Eh that's pretty much correct. At some point maybe UWin and SFU will be options, but not right now. The compiler's main concern is the jumpbuf size, which is much larger for Cygwin. You can to some extent maybe link NT386 and NT386GNU together, but this jumpbuf thing could really hurt in a hard to diagnose way. (Maybe it's safe due to setjmp vs. _setjmp?)? Sorry this is too long. As Olaf said, what I say might be very true and an accurate model, but it confuses everyone.People want very very few variables. Sorry I have to run, no proofreading this "masterpiece". - Jay Date: Wed, 23 Apr 2008 06:00:43 +0200From: dabenavidesd at yahoo.esTo: m3devel at elegosoft.comSubject: Re: [M3devel] FW: more path stuff, sorryHi all:Does pm3 treat NT386GNU paths as POSIX class? I think if one take the definition the Interface Pathname, NT386GNU target should not have access directly to use POSIX paths but Win32 ones because of:"A Pathname.T (or just a pathname) is a text conforming to the syntax of the underlying operating system" inhttp://www.opencm3.net/doc/help/gen_html/libm3/src/os/Common/Pathname.i3.htmlBut if we think in "the underlying operating system" as the cygwin api, it should be the natural POSIX paths.I agree Pathname is a common interface, but what happens with that sense of portability we want? Maybe the answer is in the cygwin api; the non-standard functions of converting one style to the other: http://cygwin.com/cygwin-api/cygwin-functions.html .See http://www.cygwin.com/cygwin-ug-net/using.html#using-pathnamesfor the main notes of compatibility. It seems clear that cygwin can use both kind of path styles, so it's not a problem to use just one of POSIX or Win32 paths. So defining a Pathname of type POSIX style for NT386GNU, it is not resign to the more capable functions of cygwin?I mean if Pathname accept both kind of forward and back slashes in different Pathnames it should be defined a new kind of Pathname syntax. Oh I remember saw the mix of both kind of slashes in pm3 quake/config files of NT386GNU :) Is this really confusing or unthinkable?I think this is clear for some of yous (NT386GNU should just accept POSIX paths, not even a Win32 one, and obviously not a mix of the two syntax in a same path), but it is not for me.In my opinion both styles should be acceptable without defining a new kind of path syntax, and convert only using the cygwin api functions. For instance when using netbios resources but also trying to mount disks partitions on the cygwin mount table file we need both kind of syntax. Is that even logical?Thanks in advance.Tony Hosking escribi?: Jay, there is an underlying principle here that you seem to be missing so I will make it explicit. Cross-product systems tend to acquire unmanageable complexity, especially when it comes to testing. By making each target one personality we are able to test machine-dependent code in isolation from machine-independent code. Often, when something breaks on one target I will test on another just to isolate the problem. This is a very powerful approach and I am very leery of destroying any ability to do this -- it allows us to maintain the high-level portability of most Modula-3 code while isolating the small fraction of machine-/target-dependent stuff. On Apr 22, 2008, at 12:28 AM, Jay wrote: [truncated]... From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] more path stuff, sorryDate: Tue, 22 Apr 2008 04:19:52 +0000There's no dependency, no linkage. Just a few simple string operations.I'll probably remove it tonight. Modula-3 has a split personality no matter what, in that it calls into very varying underlying layers, often trafficing in their specific data formats.It's just that it can strive to aid portability between them or not, by accepting either input and massaging it to work, vs. passing it along "unchanged" (well, that's not what happens actually). If there were no ambiguous cases and the Posix systems on Windows were consistent in their conventions, I'd be more for it. But the ambiguity and varying Posix conventions weaken the case tremendously. - Jay Date: Mon, 21 Apr 2008 23:14:00 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] more path stuff, sorry I concur wholeheartedly. I absolutely DO NOT want native NT386 to have any knowledge of or dependency on Cygwin. Regards, Randy>>> Tony Hosking 4/21/2008 9:44 PM >>> Why would native NT386 know anything at all about Cygwin. I say just avoid split personalities like the plague. Similarly, I'd be happy for NT386GNU (i.e., Cygwin?) to simply behave like a POSIX build (modulo native threads perhaps). On Apr 21, 2008, at 7:15 PM, Jay wrote: Maybe this is dubious.The question is, like, should native NT386 cm3 accept /cygdrive/c/foo and translate to c:\foo?Or trickier, /usr/bin/foo and translate to c:\cygwin\usr\bin\foo?And vice versa, should NT386GNU accept c:\foo?... Enviado desde Correo Yahoo!La bandeja de entrada m?s inteligente. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Apr 23 07:17:43 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Apr 2008 05:17:43 +0000 Subject: [M3devel] FW: more path stuff, sorry In-Reply-To: References: <08DD9502-27D3-4C5C-9E30-A9E9D2CADAB4@cs.purdue.edu> <135722.70767.qm@web27113.mail.ukl.yahoo.com> Message-ID: > Types are important. I think much more so than modules. But user input, esp. in the form of a command line, are ambiguous and not strongly typed, and therefore sometimes open to "sniffing", to loose interpretation, guessing what was intended. There IS a place for guessing, but not everywhere. For example maybe?: cp foo bar What does that do? Copy one file or a directory full of files? A really bad example, what does this command line do: c:\program files\microsoft visual studio\cl.exe Does it run "cl.exe" in the directory "c:\program files\microsoft visual studio". Or does it run the "program" in c:\ with parameters "files\microsoft", "visual", "studio\cl.exe"? I BELIEVE the answer is that it DEPENDS. Both can exist at the same time -- "c:\program" and "C:\program files" I BELIEVE if "c:\program" exists, it is run. I'm not sure. CreateProcess has two parameters here and so there is a way to disambiguate and execve is probably unambiguous, but system() is ambiguous and CreateProcess has an ambiguous mode since you don't have to use both parameters -- like path to .exe and command line, you can leave the first NULL, something like that it's considered poor practise. Command lines are awfully weakly typed. You know -- you need to hit those keys harder. :) Or watch this, sometimes you don't need spaces between command line parameters: D:\>dir cd foo => nothing D:\>mkdir foo D:\>cd\foo => changes into the foo directory. let's go back up: cd \ and now... enable running extensionless files: set PATHEXT=.;%PATHEXT% create one.. mkdir \cd copy %windir%\notepad.exe \cd\foo and..: cd\foo now cd\foo runs the copy of notepad. ambiguity abounds... - Jay From: jayk123 at hotmail.comTo: dabenavidesd at yahoo.es; m3devel at elegosoft.comDate: Wed, 23 Apr 2008 04:59:51 +0000Subject: Re: [M3devel] FW: more path stuff, sorry I forgot some points.Daniel, in order to convert paths between the two, you need context to know what type the provider of the path intended. There are paths that are valid in both systems but that have different means. The path /usr/bin in Win32 is the same as \usr\bin and on the drive of the current working directory (the working, if you will)The path /usr/bin in Cygwin is \usr\bin under the Cygwin root, so often like c:\cygwin\usr\bin. The path /cygdrive/c/foo is also valid in Win32, and has a different meaning there than in Cygwin. Get it? The path c:/foo is unambiguous. The "string" c:/foo is ambiguous, depending on point of view.Let's say I want a string that contains colon delimited paths.Then this is the path c and the path /foo.But if paths themselves can have colons then it is also the single element list with the element c:/foo. You could get fancy shmancy and escape the colon c\:/foo but that's insane.Quoting is already a big problem in existing systems and usage, and I just made that garbage up. One of the points maybe the Modula-3 folks are alluding is that Pathname.T is a TYPE with an INTERFACE. It is not a "string".In many other systems a "path" is "just" a "string", it just gets pass around, and both sides party on it and hope they give it the same meaning.If your notion of type is not clear, between Win32 and Posix, then neither is the meaning.Strings are a terribly loose overused type....This does save people from coming up with those fancy complicated difficult to learn INTERFACES, and it aids interoperability, since everyone can use a string...it's good and it's bad, the glass is half full and half empty... c:\ "looks" like a win32 path, but hey, be careful there, I'm just smiling big and wearing a crooked hat, you have interpreted it completely incorretly, eh? Types are important. I think much more so than modules. And /foo/ looks like a Posix path, but actually it's italicized text. :)Or then again, this whole email is a valid Posix path, newlines and all, since it has no embedded nuls. :) - Jay From: jayk123 at hotmail.comTo: dabenavidesd at yahoo.es; m3devel at elegosoft.comSubject: RE: [M3devel] FW: more path stuff, sorryDate: Wed, 23 Apr 2008 04:44:23 +0000 Daniel, this should address SOME but not necessarily all of your concern and questions: The underlying libraries are mostly Cygwin.Underlying THEM is another library, but the way it works, there is approximately zero "break through".Except for threads.Also, I intend, somehow, to expose FilePosix.T and FileWin32.T, besides the regular File.T.This would be part of enabling the serial package to build, using strictly "break through" and the Win32 code.However FilePosix.m3 and FileWin32.m3 both reveal File.T. I need to split the revelation out into a separate interface/module I think, shouldn't be hard. From SOME point of view, forward slashes are perfectly acceptable in Win32 paths and have the same meaning as backward slashs. It is not 100%, but largely. This isn't Modula-3 code doing any "translation" but the Modula-3 does treat \ and / equivalent upon read. The lowest level Win32 File functions in kernel32.dll -- CreateFile, DeleteFile, MoveFile, CreateDirectory, RemoveDirectory, CopyFile, GetCurrentDirectory, SetCurrentDirectory, GetFileAttributes[Ex], FindFirst[Next]File[Ex], what else am I forgetting? Maybe CreateProcess? GetFullPathName, GetShortPathName, usually consider \ and / the same. Unless the paths starts \\?. The / are all converted to \ before getting to the underlying system, the NtCreateFile, where strictly \ is the separator and there is no working directory. If a path starts \\?, it is passed on directly. You don't have to pass full paths. You can pass a handle to a parent directory. Now, I recently read, regarding NTFS-3G for Linux, about allowing : and \ in file names.The claim is that if you install SFU (Services For Unix, previously Interix, now SUA), you can access such names on NT.I tried it out. In fact this claim seems wrong. I create those paths, and then enumerated and printed from Win32. Their lower 8 bits were : and \. But their upper 8 bits were 0xF0 or 0xFF or somesuch. SFU has some ability to access unicode file names, but not that I could find that would reveal this trickery. In particular, there is like wcs_opendir that opens a directory with a unicode path, but there is only the asii/ansi/utf8/7bit/8bit/whatever readdir/readdir_r. So the 0xF000 cannot show through.And proper unicode Win32 code still doesn't see ':' or '\' per se in file names (in paths, but not individual names). I think I happened to accidentally copy this stuff to a Linux machine, and they didn't come across as ':' or '\'.Maybe I used wine cmd copy though. I should try with NTFS-3G. I do suspect I'll get ':' and '\'. Speaking of portability -- should Modula-3 on Posix systems allow file names with ':' and '\'? There are pluses and minuses. It's a rhetorical question -- in that, I don't really want to discuss it that much. I don't think there's a good answer, so I'd just as soon leave the code alone vs. trying in vain to come up with what is "correct". Yes there are Cygwin specific functions for converting paths.It would be reasonable for some NT386GNU-specific paths to use them.You can write up the *.i3 files and call them where you deem appropriate. Where deemed appropriate is not clear.It would not be great for the NT386 tools to use them -- to link to cygwin1.dll, for any reason.Maybe via LoadLibrary/GetProcAddress -- an optional dependency. Maybe.I believe "linkage" should mean "static linkage in the same file" and not "dynamic linkage in the same process" but it isn't up to me and it very well might be this way. I think the Linux kernel grants an exception, but I'm skeptical that non-GPL code doesn't dynamically link to in-proc GPL code that hasn't granted an exception. Anyway, Modula-3 except for NT386GNU is not in any uniquely worrying boat, for sure. You see, like my little speech about emulation layers and "break though", Cygwin is an emulation layer.But its users may or may not consider it to have much "break through".It's users might be very accustomed to Posix paths and a full set of Posix-path-using tools, and have no need to give any of them a Win32 path, and if they do, might be prepared to stop and think about it and do their own conversion. I think it's gray, because gcc as a compiler is arguably way more valuable than a Posix porting layer for other code.Or really, they are both useful. Some people will want one, or the other, or both, or neither. And again I am confusing Cygwin, NT386GNU, and the backend vs. the runtime. You can very well combine the integrated backend with a Posixish runtime -- remember all the systems now have the integrated backend, you should be able to output NT386 .obj files on any platform just by saying TARGET= "NT386" in cm3.cfg. And you can combine the gcc backend with a Win32 runtime -- that is what NT386MINGNU is. Also, while kernel32.dll treats / like \, other Win32 functions/libraries do not, such as comdlg32.dll (File.Open, File.Save), and shlwapi.dll, I think. You'd have to read the docs and/or experiment.Win32 has a lot of nice internal consistencies, but it isn't 100% consistent. Probably nothing is. A mix of slashes works fine on NT386. Does some of this make sense? Again again again, "NT386GNU" is different things to different people, and some of them are in fact independent and you can pick and chose which parts you compose. There is the runtime the compiler uses. There is the backend. There is the library the output uses, both the "C library" (fopen), the threading library (pthreads vs. Win32), the windowing library (X Windows vs. Win32), the naming conventions (libfoo.a vs. foo.lib). Nearly every one of these factors is independent of the others, The config files are written as such and you should be able to experiment and make your own other combinations. Three such combinations are provided, and there's sort of a tendency for the host and the target to be the same, but they don't have to be. There are other factors, like which C compiler do you use, which linker. The compiler, backend, and linker conspire to determine which debugger you can use. If you se the integrated backend and MS linker, you can use MS debuggers. If you use the gcc backend and GNU linker, you can use gdb. Oh, well you can always use either debugger, but the point here is if you have symbols or not. Currently there is some problem mixing the gcc backend with the MS linker and/or the integrated backend with the GNU linker. I think gcc backend with MS linker, and only sometimes the other. There is a symbol alway injected into the .o files that the GNU linker knows about but that the MS linker gives as unresolved. The MS linker has a different name for it, but I don't believe it is always injected by the integrated backend. This is the symbol that lets you point to the start of your image, it is __ImageBase in MS. It isn't used much. But for some reason gcc always generates references to it, and gives it a different name. Therefore some of the supposedly independent factors are not independent as they should be. For network paths, Cygwin allows //machine/server. Current Cygwin issues warnings when you use Win32 paths, and the warning says you can quash it by setting CYGWIN=nodospathwarning or somesuch. Does this make some sense? At some point maybe I'll put together distributions for other combinations. Oh, one more thing, the gcc backend can use __int64.I was feeling guilty about taking so long adding that to the integrated backend, thus I fast-forwarded and got NT386GNU to work. I should still go back and add it though. Also, currently the compiler assumes some linkage of these factors. It assumes OS_TYPE=POSIX means targeting Cygwin. Eh that's pretty much correct. At some point maybe UWin and SFU will be options, but not right now. The compiler's main concern is the jumpbuf size, which is much larger for Cygwin. You can to some extent maybe link NT386 and NT386GNU together, but this jumpbuf thing could really hurt in a hard to diagnose way. (Maybe it's safe due to setjmp vs. _setjmp?)? Sorry this is too long. As Olaf said, what I say might be very true and an accurate model, but it confuses everyone.People want very very few variables. Sorry I have to run, no proofreading this "masterpiece". - Jay Date: Wed, 23 Apr 2008 06:00:43 +0200From: dabenavidesd at yahoo.esTo: m3devel at elegosoft.comSubject: Re: [M3devel] FW: more path stuff, sorryHi all:Does pm3 treat NT386GNU paths as POSIX class? I think if one take the definition the Interface Pathname, NT386GNU target should not have access directly to use POSIX paths but Win32 ones because of:"A Pathname.T (or just a pathname) is a text conforming to the syntax of the underlying operating system" inhttp://www.opencm3.net/doc/help/gen_html/libm3/src/os/Common/Pathname.i3.htmlBut if we think in "the underlying operating system" as the cygwin api, it should be the natural POSIX paths.I agree Pathname is a common interface, but what happens with that sense of portability we want? Maybe the answer is in the cygwin api; the non-standard functions of converting one style to the other: http://cygwin.com/cygwin-api/cygwin-functions.html .See http://www.cygwin.com/cygwin-ug-net/using.html#using-pathnamesfor the main notes of compatibility. It seems clear that cygwin can use both kind of path styles, so it's not a problem to use just one of POSIX or Win32 paths. So defining a Pathname of type POSIX style for NT386GNU, it is not resign to the more capable functions of cygwin?I mean if Pathname accept both kind of forward and back slashes in different Pathnames it should be defined a new kind of Pathname syntax. Oh I remember saw the mix of both kind of slashes in pm3 quake/config files of NT386GNU :) Is this really confusing or unthinkable?I think this is clear for some of yous (NT386GNU should just accept POSIX paths, not even a Win32 one, and obviously not a mix of the two syntax in a same path), but it is not for me.In my opinion both styles should be acceptable without defining a new kind of path syntax, and convert only using the cygwin api functions. For instance when using netbios resources but also trying to mount disks partitions on the cygwin mount table file we need both kind of syntax. Is that even logical?Thanks in advance.Tony Hosking escribi?: Jay, there is an underlying principle here that you seem to be missing so I will make it explicit. Cross-product systems tend to acquire unmanageable complexity, especially when it comes to testing. By making each target one personality we are able to test machine-dependent code in isolation from machine-independent code. Often, when something breaks on one target I will test on another just to isolate the problem. This is a very powerful approach and I am very leery of destroying any ability to do this -- it allows us to maintain the high-level portability of most Modula-3 code while isolating the small fraction of machine-/target-dependent stuff. On Apr 22, 2008, at 12:28 AM, Jay wrote: [truncated]... From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] more path stuff, sorryDate: Tue, 22 Apr 2008 04:19:52 +0000There's no dependency, no linkage. Just a few simple string operations.I'll probably remove it tonight. Modula-3 has a split personality no matter what, in that it calls into very varying underlying layers, often trafficing in their specific data formats.It's just that it can strive to aid portability between them or not, by accepting either input and massaging it to work, vs. passing it along "unchanged" (well, that's not what happens actually). If there were no ambiguous cases and the Posix systems on Windows were consistent in their conventions, I'd be more for it. But the ambiguity and varying Posix conventions weaken the case tremendously. - Jay Date: Mon, 21 Apr 2008 23:14:00 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] more path stuff, sorry I concur wholeheartedly. I absolutely DO NOT want native NT386 to have any knowledge of or dependency on Cygwin. Regards, Randy>>> Tony Hosking 4/21/2008 9:44 PM >>> Why would native NT386 know anything at all about Cygwin. I say just avoid split personalities like the plague. Similarly, I'd be happy for NT386GNU (i.e., Cygwin?) to simply behave like a POSIX build (modulo native threads perhaps). On Apr 21, 2008, at 7:15 PM, Jay wrote: Maybe this is dubious.The question is, like, should native NT386 cm3 accept /cygdrive/c/foo and translate to c:\foo?Or trickier, /usr/bin/foo and translate to c:\cygwin\usr\bin\foo?And vice versa, should NT386GNU accept c:\foo?... Enviado desde Correo Yahoo!La bandeja de entrada m?s inteligente. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Apr 23 07:20:12 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Apr 2008 05:20:12 +0000 Subject: [M3devel] FW: more path stuff, sorry In-Reply-To: References: <08DD9502-27D3-4C5C-9E30-A9E9D2CADAB4@cs.purdue.edu> <135722.70767.qm@web27113.mail.ukl.yahoo.com> Message-ID: > enable running extensionless files: > set PATHEXT=.;%PATHEXT% Oh, hey, better yet: mkdir \cd\foo.exe, then you don't need to alter PATHEXT. Directories with extensions often occuring on files..that might cause some interesting problems.. - Jay From: jayk123 at hotmail.comTo: dabenavidesd at yahoo.es; m3devel at elegosoft.comSubject: RE: [M3devel] FW: more path stuff, sorryDate: Wed, 23 Apr 2008 05:17:43 +0000 > Types are important. I think much more so than modules.But user input, esp. in the form of a command line, are ambiguous and not strongly typed, and therefore sometimes open to "sniffing", to loose interpretation, guessing what was intended. There IS a place for guessing, but not everywhere. For example maybe?: cp foo bar What does that do? Copy one file or a directory full of files? A really bad example, what does this command line do: c:\program files\microsoft visual studio\cl.exe Does it run "cl.exe" in the directory "c:\program files\microsoft visual studio".Or does it run the "program" in c:\ with parameters "files\microsoft", "visual", "studio\cl.exe"? I BELIEVE the answer is that it DEPENDS. Both can exist at the same time -- "c:\program" and "C:\program files" I BELIEVE if "c:\program" exists, it is run.I'm not sure. CreateProcess has two parameters here and so there is a way to disambiguate and execve is probably unambiguous, but system() is ambiguous and CreateProcess has an ambiguous mode since you don't have to use both parameters -- like path to .exe and command line, you can leave the first NULL, something like that it's considered poor practise. Command lines are awfully weakly typed.You know -- you need to hit those keys harder. :) Or watch this, sometimes you don't need spaces between command line parameters: D:\>dir cd foo => nothing D:\>mkdir fooD:\>cd\foo => changes into the foo directory. let's go back up:cd \ and now...enable running extensionless files: set PATHEXT=.;%PATHEXT% create one.. mkdir \cd copy %windir%\notepad.exe \cd\foo and..: cd\foo now cd\foo runs the copy of notepad. ambiguity abounds... - Jay From: jayk123 at hotmail.comTo: dabenavidesd at yahoo.es; m3devel at elegosoft.comDate: Wed, 23 Apr 2008 04:59:51 +0000Subject: Re: [M3devel] FW: more path stuff, sorry I forgot some points.Daniel, in order to convert paths between the two, you need context to know what type the provider of the path intended. There are paths that are valid in both systems but that have different means. The path /usr/bin in Win32 is the same as \usr\bin and on the drive of the current working directory (the working, if you will)The path /usr/bin in Cygwin is \usr\bin under the Cygwin root, so often like c:\cygwin\usr\bin. The path /cygdrive/c/foo is also valid in Win32, and has a different meaning there than in Cygwin. Get it? The path c:/foo is unambiguous. The "string" c:/foo is ambiguous, depending on point of view.Let's say I want a string that contains colon delimited paths.Then this is the path c and the path /foo.But if paths themselves can have colons then it is also the single element list with the element c:/foo. You could get fancy shmancy and escape the colon c\:/foo but that's insane.Quoting is already a big problem in existing systems and usage, and I just made that garbage up. One of the points maybe the Modula-3 folks are alluding is that Pathname.T is a TYPE with an INTERFACE. It is not a "string".In many other systems a "path" is "just" a "string", it just gets pass around, and both sides party on it and hope they give it the same meaning.If your notion of type is not clear, between Win32 and Posix, then neither is the meaning.Strings are a terribly loose overused type....This does save people from coming up with those fancy complicated difficult to learn INTERFACES, and it aids interoperability, since everyone can use a string...it's good and it's bad, the glass is half full and half empty... c:\ "looks" like a win32 path, but hey, be careful there, I'm just smiling big and wearing a crooked hat, you have interpreted it completely incorretly, eh? Types are important. I think much more so than modules. And /foo/ looks like a Posix path, but actually it's italicized text. :)Or then again, this whole email is a valid Posix path, newlines and all, since it has no embedded nuls. :) - Jay From: jayk123 at hotmail.comTo: dabenavidesd at yahoo.es; m3devel at elegosoft.comSubject: RE: [M3devel] FW: more path stuff, sorryDate: Wed, 23 Apr 2008 04:44:23 +0000 Daniel, this should address SOME but not necessarily all of your concern and questions: The underlying libraries are mostly Cygwin.Underlying THEM is another library, but the way it works, there is approximately zero "break through".Except for threads.Also, I intend, somehow, to expose FilePosix.T and FileWin32.T, besides the regular File.T.This would be part of enabling the serial package to build, using strictly "break through" and the Win32 code.However FilePosix.m3 and FileWin32.m3 both reveal File.T. I need to split the revelation out into a separate interface/module I think, shouldn't be hard. From SOME point of view, forward slashes are perfectly acceptable in Win32 paths and have the same meaning as backward slashs. It is not 100%, but largely. This isn't Modula-3 code doing any "translation" but the Modula-3 does treat \ and / equivalent upon read. The lowest level Win32 File functions in kernel32.dll -- CreateFile, DeleteFile, MoveFile, CreateDirectory, RemoveDirectory, CopyFile, GetCurrentDirectory, SetCurrentDirectory, GetFileAttributes[Ex], FindFirst[Next]File[Ex], what else am I forgetting? Maybe CreateProcess? GetFullPathName, GetShortPathName, usually consider \ and / the same. Unless the paths starts \\?. The / are all converted to \ before getting to the underlying system, the NtCreateFile, where strictly \ is the separator and there is no working directory. If a path starts \\?, it is passed on directly. You don't have to pass full paths. You can pass a handle to a parent directory. Now, I recently read, regarding NTFS-3G for Linux, about allowing : and \ in file names.The claim is that if you install SFU (Services For Unix, previously Interix, now SUA), you can access such names on NT.I tried it out. In fact this claim seems wrong. I create those paths, and then enumerated and printed from Win32. Their lower 8 bits were : and \. But their upper 8 bits were 0xF0 or 0xFF or somesuch. SFU has some ability to access unicode file names, but not that I could find that would reveal this trickery. In particular, there is like wcs_opendir that opens a directory with a unicode path, but there is only the asii/ansi/utf8/7bit/8bit/whatever readdir/readdir_r. So the 0xF000 cannot show through.And proper unicode Win32 code still doesn't see ':' or '\' per se in file names (in paths, but not individual names). I think I happened to accidentally copy this stuff to a Linux machine, and they didn't come across as ':' or '\'.Maybe I used wine cmd copy though. I should try with NTFS-3G. I do suspect I'll get ':' and '\'. Speaking of portability -- should Modula-3 on Posix systems allow file names with ':' and '\'? There are pluses and minuses. It's a rhetorical question -- in that, I don't really want to discuss it that much. I don't think there's a good answer, so I'd just as soon leave the code alone vs. trying in vain to come up with what is "correct". Yes there are Cygwin specific functions for converting paths.It would be reasonable for some NT386GNU-specific paths to use them.You can write up the *.i3 files and call them where you deem appropriate. Where deemed appropriate is not clear.It would not be great for the NT386 tools to use them -- to link to cygwin1.dll, for any reason.Maybe via LoadLibrary/GetProcAddress -- an optional dependency. Maybe.I believe "linkage" should mean "static linkage in the same file" and not "dynamic linkage in the same process" but it isn't up to me and it very well might be this way. I think the Linux kernel grants an exception, but I'm skeptical that non-GPL code doesn't dynamically link to in-proc GPL code that hasn't granted an exception. Anyway, Modula-3 except for NT386GNU is not in any uniquely worrying boat, for sure. You see, like my little speech about emulation layers and "break though", Cygwin is an emulation layer.But its users may or may not consider it to have much "break through".It's users might be very accustomed to Posix paths and a full set of Posix-path-using tools, and have no need to give any of them a Win32 path, and if they do, might be prepared to stop and think about it and do their own conversion. I think it's gray, because gcc as a compiler is arguably way more valuable than a Posix porting layer for other code.Or really, they are both useful. Some people will want one, or the other, or both, or neither. And again I am confusing Cygwin, NT386GNU, and the backend vs. the runtime. You can very well combine the integrated backend with a Posixish runtime -- remember all the systems now have the integrated backend, you should be able to output NT386 .obj files on any platform just by saying TARGET= "NT386" in cm3.cfg. And you can combine the gcc backend with a Win32 runtime -- that is what NT386MINGNU is. Also, while kernel32.dll treats / like \, other Win32 functions/libraries do not, such as comdlg32.dll (File.Open, File.Save), and shlwapi.dll, I think. You'd have to read the docs and/or experiment.Win32 has a lot of nice internal consistencies, but it isn't 100% consistent. Probably nothing is. A mix of slashes works fine on NT386. Does some of this make sense? Again again again, "NT386GNU" is different things to different people, and some of them are in fact independent and you can pick and chose which parts you compose. There is the runtime the compiler uses. There is the backend. There is the library the output uses, both the "C library" (fopen), the threading library (pthreads vs. Win32), the windowing library (X Windows vs. Win32), the naming conventions (libfoo.a vs. foo.lib). Nearly every one of these factors is independent of the others, The config files are written as such and you should be able to experiment and make your own other combinations. Three such combinations are provided, and there's sort of a tendency for the host and the target to be the same, but they don't have to be. There are other factors, like which C compiler do you use, which linker. The compiler, backend, and linker conspire to determine which debugger you can use. If you se the integrated backend and MS linker, you can use MS debuggers. If you use the gcc backend and GNU linker, you can use gdb. Oh, well you can always use either debugger, but the point here is if you have symbols or not. Currently there is some problem mixing the gcc backend with the MS linker and/or the integrated backend with the GNU linker. I think gcc backend with MS linker, and only sometimes the other. There is a symbol alway injected into the .o files that the GNU linker knows about but that the MS linker gives as unresolved. The MS linker has a different name for it, but I don't believe it is always injected by the integrated backend. This is the symbol that lets you point to the start of your image, it is __ImageBase in MS. It isn't used much. But for some reason gcc always generates references to it, and gives it a different name. Therefore some of the supposedly independent factors are not independent as they should be. For network paths, Cygwin allows //machine/server. Current Cygwin issues warnings when you use Win32 paths, and the warning says you can quash it by setting CYGWIN=nodospathwarning or somesuch. Does this make some sense? At some point maybe I'll put together distributions for other combinations. Oh, one more thing, the gcc backend can use __int64.I was feeling guilty about taking so long adding that to the integrated backend, thus I fast-forwarded and got NT386GNU to work. I should still go back and add it though. Also, currently the compiler assumes some linkage of these factors. It assumes OS_TYPE=POSIX means targeting Cygwin. Eh that's pretty much correct. At some point maybe UWin and SFU will be options, but not right now. The compiler's main concern is the jumpbuf size, which is much larger for Cygwin. You can to some extent maybe link NT386 and NT386GNU together, but this jumpbuf thing could really hurt in a hard to diagnose way. (Maybe it's safe due to setjmp vs. _setjmp?)? Sorry this is too long. As Olaf said, what I say might be very true and an accurate model, but it confuses everyone.People want very very few variables. Sorry I have to run, no proofreading this "masterpiece". - Jay Date: Wed, 23 Apr 2008 06:00:43 +0200From: dabenavidesd at yahoo.esTo: m3devel at elegosoft.comSubject: Re: [M3devel] FW: more path stuff, sorryHi all:Does pm3 treat NT386GNU paths as POSIX class? I think if one take the definition the Interface Pathname, NT386GNU target should not have access directly to use POSIX paths but Win32 ones because of:"A Pathname.T (or just a pathname) is a text conforming to the syntax of the underlying operating system" inhttp://www.opencm3.net/doc/help/gen_html/libm3/src/os/Common/Pathname.i3.htmlBut if we think in "the underlying operating system" as the cygwin api, it should be the natural POSIX paths.I agree Pathname is a common interface, but what happens with that sense of portability we want? Maybe the answer is in the cygwin api; the non-standard functions of converting one style to the other: http://cygwin.com/cygwin-api/cygwin-functions.html .See http://www.cygwin.com/cygwin-ug-net/using.html#using-pathnamesfor the main notes of compatibility. It seems clear that cygwin can use both kind of path styles, so it's not a problem to use just one of POSIX or Win32 paths. So defining a Pathname of type POSIX style for NT386GNU, it is not resign to the more capable functions of cygwin?I mean if Pathname accept both kind of forward and back slashes in different Pathnames it should be defined a new kind of Pathname syntax. Oh I remember saw the mix of both kind of slashes in pm3 quake/config files of NT386GNU :) Is this really confusing or unthinkable?I think this is clear for some of yous (NT386GNU should just accept POSIX paths, not even a Win32 one, and obviously not a mix of the two syntax in a same path), but it is not for me.In my opinion both styles should be acceptable without defining a new kind of path syntax, and convert only using the cygwin api functions. For instance when using netbios resources but also trying to mount disks partitions on the cygwin mount table file we need both kind of syntax. Is that even logical?Thanks in advance.Tony Hosking escribi?: Jay, there is an underlying principle here that you seem to be missing so I will make it explicit. Cross-product systems tend to acquire unmanageable complexity, especially when it comes to testing. By making each target one personality we are able to test machine-dependent code in isolation from machine-independent code. Often, when something breaks on one target I will test on another just to isolate the problem. This is a very powerful approach and I am very leery of destroying any ability to do this -- it allows us to maintain the high-level portability of most Modula-3 code while isolating the small fraction of machine-/target-dependent stuff. On Apr 22, 2008, at 12:28 AM, Jay wrote: [truncated]... From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] more path stuff, sorryDate: Tue, 22 Apr 2008 04:19:52 +0000There's no dependency, no linkage. Just a few simple string operations.I'll probably remove it tonight. Modula-3 has a split personality no matter what, in that it calls into very varying underlying layers, often trafficing in their specific data formats.It's just that it can strive to aid portability between them or not, by accepting either input and massaging it to work, vs. passing it along "unchanged" (well, that's not what happens actually). If there were no ambiguous cases and the Posix systems on Windows were consistent in their conventions, I'd be more for it. But the ambiguity and varying Posix conventions weaken the case tremendously. - Jay Date: Mon, 21 Apr 2008 23:14:00 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] more path stuff, sorry I concur wholeheartedly. I absolutely DO NOT want native NT386 to have any knowledge of or dependency on Cygwin. Regards, Randy>>> Tony Hosking 4/21/2008 9:44 PM >>> Why would native NT386 know anything at all about Cygwin. I say just avoid split personalities like the plague. Similarly, I'd be happy for NT386GNU (i.e., Cygwin?) to simply behave like a POSIX build (modulo native threads perhaps). On Apr 21, 2008, at 7:15 PM, Jay wrote: Maybe this is dubious.The question is, like, should native NT386 cm3 accept /cygdrive/c/foo and translate to c:\foo?Or trickier, /usr/bin/foo and translate to c:\cygwin\usr\bin\foo?And vice versa, should NT386GNU accept c:\foo?... Enviado desde Correo Yahoo!La bandeja de entrada m?s inteligente. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Apr 23 15:06:12 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 23 Apr 2008 09:06:12 -0400 Subject: [M3devel] FW: more path stuff, sorry In-Reply-To: References: <08DD9502-27D3-4C5C-9E30-A9E9D2CADAB4@cs.purdue.edu> <135722.70767.qm@web27113.mail.ukl.yahoo.com> Message-ID: <2CB6197F-E4CA-4D05-8363-BA18A60B0DF3@cs.purdue.edu> Jay, Daniel was referring to PM3, not CM3. 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 Apr 23, 2008, at 12:44 AM, Jay wrote: > Daniel, this should address SOME but not necessarily all of your > concern and questions: > > The underlying libraries are mostly Cygwin. > Underlying THEM is another library, but the way it works, there is > approximately zero "break through". > Except for threads. > Also, I intend, somehow, to expose FilePosix.T and FileWin32.T, > besides the regular File.T. > This would be part of enabling the serial package to build, using > strictly "break through" and the Win32 code. > However FilePosix.m3 and FileWin32.m3 both reveal File.T. I need to > split the revelation out into a separate interface/module I think, > shouldn't be hard. > > >From SOME point of view, forward slashes are perfectly acceptable > in Win32 paths and have the same meaning as backward slashs. It is > not 100%, but largely. This isn't Modula-3 code doing any > "translation" but the Modula-3 does treat \ and / equivalent upon > read. > > The lowest level Win32 File functions in kernel32.dll -- CreateFile, > DeleteFile, MoveFile, CreateDirectory, RemoveDirectory, CopyFile, > GetCurrentDirectory, SetCurrentDirectory, GetFileAttributes[Ex], > FindFirst[Next]File[Ex], what else am I forgetting? Maybe > CreateProcess? GetFullPathName, GetShortPathName, usually consider \ > and / the same. Unless the paths starts \\?. The / are all converted > to \ before getting to the underlying system, the NtCreateFile, > where strictly \ is the separator and there is no working directory. > If a path starts \\?, it is passed on directly. You don't have to > pass full paths. You can pass a handle to a parent directory. > > Now, I recently read, regarding NTFS-3G for Linux, about allowing : > and \ in file names. > The claim is that if you install SFU (Services For Unix, previously > Interix, now SUA), you can access such names on NT. > I tried it out. In fact this claim seems wrong. I create those > paths, and then enumerated and printed from Win32. Their lower 8 > bits were : and \. But their upper 8 bits were 0xF0 or 0xFF or > somesuch. SFU has some ability to access unicode file names, but not > that I could find that would reveal this trickery. In particular, > there is like wcs_opendir that opens a directory with a unicode > path, but there is only the asii/ansi/utf8/7bit/8bit/whatever > readdir/readdir_r. So the 0xF000 cannot show through. > And proper unicode Win32 code still doesn't see ':' or '\' per se in > file names (in paths, but not individual names). > > I think I happened to accidentally copy this stuff to a Linux > machine, and they didn't come across as ':' or '\'. > Maybe I used wine cmd copy though. I should try with NTFS-3G. I do > suspect I'll get ':' and '\'. > > Speaking of portability -- should Modula-3 on Posix systems allow > file names with ':' and '\'? There are pluses and minuses. It's a > rhetorical question -- in that, I don't really want to discuss it > that much. I don't think there's a good answer, so I'd just as soon > leave the code alone vs. trying in vain to come up with what is > "correct". > > Yes there are Cygwin specific functions for converting paths. > It would be reasonable for some NT386GNU-specific paths to use them. > You can write up the *.i3 files and call them where you deem > appropriate. > Where deemed appropriate is not clear. > It would not be great for the NT386 tools to use them -- to link to > cygwin1.dll, for any reason. > Maybe via LoadLibrary/GetProcAddress -- an optional dependency. Maybe. > > I believe "linkage" should mean "static linkage in the same file" > and not "dynamic linkage in the same process" but it isn't up to me > and it very well might be this way. I think the Linux kernel grants > an exception, but I'm skeptical that non-GPL code doesn't > dynamically link to in-proc GPL code that hasn't granted an > exception. Anyway, Modula-3 except for NT386GNU is not in any > uniquely worrying boat, for sure. > > You see, like my little speech about emulation layers and "break > though", Cygwin is an emulation layer. > But its users may or may not consider it to have much "break through". > It's users might be very accustomed to Posix paths and a full set of > Posix-path-using tools, and have no need to give any of them a Win32 > path, and if they do, might be prepared to stop and think about it > and do their own conversion. > > I think it's gray, because gcc as a compiler is arguably way more > valuable than a Posix porting layer for other code. > Or really, they are both useful. Some people will want one, or the > other, or both, or neither. > > And again I am confusing Cygwin, NT386GNU, and the backend vs. the > runtime. > > You can very well combine the integrated backend with a Posixish > runtime -- remember all the systems now have the integrated backend, > you should be able to output NT386 .obj files on any platform just > by saying TARGET= "NT386" in cm3.cfg. > > And you can combine the gcc backend with a Win32 runtime -- that is > what NT386MINGNU is. > > Also, while kernel32.dll treats / like \, other Win32 functions/ > libraries do not, such as comdlg32.dll (File.Open, File.Save), and > shlwapi.dll, I think. You'd have to read the docs and/or experiment. > Win32 has a lot of nice internal consistencies, but it isn't 100% > consistent. Probably nothing is. > > A mix of slashes works fine on NT386. > > Does some of this make sense? > > Again again again, "NT386GNU" is different things to different > people, and some of them are in fact independent and you can pick > and chose which parts you compose. There is the runtime the compiler > uses. There is the backend. There is the library the output uses, > both the "C library" (fopen), the threading library (pthreads vs. > Win32), the windowing library (X Windows vs. Win32), the naming > conventions (libfoo.a vs. foo.lib). Nearly every one of these > factors is independent of the others, The config files are written > as such and you should be able to experiment and make your own other > combinations. Three such combinations are provided, and there's sort > of a tendency for the host and the target to be the same, but they > don't have to be. There are other factors, like which C compiler do > you use, which linker. The compiler, backend, and linker conspire to > determine which debugger you can use. If you se the integrated > backend and MS linker, you can use MS debuggers. If you use the gcc > backend and GNU linker, you can use gdb. Oh, well you can always use > either debugger, but the point here is if you have symbols or not. > Currently there is some problem mixing the gcc backend with the MS > linker and/or the integrated backend with the GNU linker. I think > gcc backend with MS linker, and only sometimes the other. There is a > symbol alway injected into the .o files that the GNU linker knows > about but that the MS linker gives as unresolved. The MS linker has > a different name for it, but I don't believe it is always injected > by the integrated backend. This is the symbol that lets you point to > the start of your image, it is __ImageBase in MS. It isn't used > much. But for some reason gcc always generates references to it, and > gives it a different name. Therefore some of the supposedly > independent factors are not independent as they should be. > > For network paths, Cygwin allows //machine/server. > > Current Cygwin issues warnings when you use Win32 paths, and the > warning says you can quash it by setting CYGWIN=nodospathwarning or > somesuch. > > Does this make some sense? > > At some point maybe I'll put together distributions for other > combinations. > > Oh, one more thing, the gcc backend can use __int64. > I was feeling guilty about taking so long adding that to the > integrated backend, thus I fast-forwarded and got NT386GNU to work. > I should still go back and add it though. > > Also, currently the compiler assumes some linkage of these factors. > It assumes OS_TYPE=POSIX means targeting Cygwin. Eh that's pretty > much correct. At some point maybe UWin and SFU will be options, but > not right now. The compiler's main concern is the jumpbuf size, > which is much larger for Cygwin. You can to some extent maybe link > NT386 and NT386GNU together, but this jumpbuf thing could really > hurt in a hard to diagnose way. (Maybe it's safe due to setjmp vs. > _setjmp?)? > > Sorry this is too long. As Olaf said, what I say might be very true > and an accurate model, but it confuses everyone. > People want very very few variables. > > Sorry I have to run, no proofreading this "masterpiece". deprecating humor inserted here.> > > > - Jay > > Date: Wed, 23 Apr 2008 06:00:43 +0200 > From: dabenavidesd at yahoo.es > To: m3devel at elegosoft.com > Subject: Re: [M3devel] FW: more path stuff, sorry > > Hi all: > Does pm3 treat NT386GNU paths as POSIX class? I think if one take > the definition the Interface Pathname, NT386GNU target should not > have access directly to use POSIX paths but Win32 ones because of: > "A Pathname.T (or just a pathname) is a text conforming to the > syntax of the underlying operating system" in > http://www.opencm3.net/doc/help/gen_html/libm3/src/os/Common/Pathname.i3.html > But if we think in "the underlying operating system" as the cygwin > api, it should be the natural POSIX paths. > I agree Pathname is a common interface, but what happens with that > sense of portability we want? Maybe the answer is in the cygwin api; > the non-standard functions of converting one style to the other: http://cygwin.com/cygwin-api/cygwin-functions.html > . > See http://www.cygwin.com/cygwin-ug-net/using.html#using-pathnames > for the main notes of compatibility. It seems clear that cygwin can > use both kind of path styles, so it's not a problem to use just one > of POSIX or Win32 paths. So defining a Pathname of type POSIX style > for NT386GNU, it is not resign to the more capable functions of > cygwin? > I mean if Pathname accept both kind of forward and back slashes in > different Pathnames it should be defined a new kind of Pathname > syntax. Oh I remember saw the mix of both kind of slashes in pm3 > quake/config files of NT386GNU :) Is this really confusing or > unthinkable? > I think this is clear for some of yous (NT386GNU should just accept > POSIX paths, not even a Win32 one, and obviously not a mix of the > two syntax in a same path), but it is not for me. > In my opinion both styles should be acceptable without defining a > new kind of path syntax, and convert only using the cygwin api > functions. For instance when using netbios resources but also trying > to mount disks partitions on the cygwin mount table file we need > both kind of syntax. Is that even logical? > Thanks in advance. > > Tony Hosking escribi?: > Jay, there is an underlying principle here that you seem to be > missing so I will make it explicit. Cross-product systems tend to > acquire unmanageable complexity, especially when it comes to > testing. By making each target one personality we are able to test > machine-dependent code in isolation from machine-independent code. > Often, when something breaks on one target I will test on another > just to isolate the problem. This is a very powerful approach and I > am very leery of destroying any ability to do this -- it allows us > to maintain the high-level portability of most Modula-3 code while > isolating the small fraction of machine-/target-dependent stuff. > > > > On Apr 22, 2008, at 12:28 AM, Jay wrote: > > [truncated]... > > > > > From: jayk123 at hotmail.com > To: rcoleburn at scires.com; m3devel at elegosoft.com > Subject: RE: [M3devel] more path stuff, sorry > Date: Tue, 22 Apr 2008 04:19:52 +0000 > > There's no dependency, no linkage. Just a few simple string > operations. > I'll probably remove it tonight. > > Modula-3 has a split personality no matter what, in that it calls > into very varying underlying layers, often trafficing in their > specific data formats. > It's just that it can strive to aid portability between them or not, > by accepting either input and massaging it to work, vs. passing it > along "unchanged" (well, that's not what happens actually). If there > were no ambiguous cases and the Posix systems on Windows were > consistent in their conventions, I'd be more for it. But the > ambiguity and varying Posix conventions weaken the case tremendously. > > - Jay > > Date: Mon, 21 Apr 2008 23:14:00 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] more path stuff, sorry > > I concur wholeheartedly. I absolutely DO NOT want native NT386 to > have any knowledge of or dependency on Cygwin. > Regards, > Randy > > >>> Tony Hosking 4/21/2008 9:44 PM >>> > Why would native NT386 know anything at all about Cygwin. I say > just avoid split personalities like the plague. Similarly, I'd be > happy for NT386GNU (i.e., Cygwin?) to simply behave like a POSIX > build (modulo native threads perhaps). > > On Apr 21, 2008, at 7:15 PM, Jay wrote: > > Maybe this is dubious. > > The question is, like, should native NT386 cm3 accept /cygdrive/c/ > foo and translate to c:\foo? > Or trickier, /usr/bin/foo and translate to c:\cygwin\usr\bin\foo? > And vice versa, should NT386GNU accept c:\foo? > > ... > > > > Enviado desde Correo Yahoo! > La bandeja de entrada m?s inteligente. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Apr 23 17:20:41 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Apr 2008 15:20:41 +0000 Subject: [M3devel] naming conventions for split/composed interfaces? Message-ID: So I'm fixing AMD64_LINUX Utypes.i3, Ustat.i3, etc. Look at what I did for example with Upthread.i3 vs. UpthreadMachine.i3. Ustat.i3 shall be mostly the same between PPC_LINUX, LINUXLIBC6 (I386_LINUX), AMD64_LINUX, etc. However struct_stat will not likely be. It appears, though I have to double check, the difference cannot be abstracted out to pointer-sized integer types, that the fields are of varying orders. So I want to say: linux-i386/UstatPlatformSpecific.i3 TYPE struct_stat = ... linux-amd64/UstatPlatformSpecific.i3 TYPE struct_stat = ... linux-ppc/UstatPlatformSpecific.i3 TYPE struct_stat = ... linuxlibc/Ustat.i3 TYPE struct_stat = UstatsPlatformSpecific.struct_stat; My question is simply: What is the, or a good, naming convention for UstatPlatformSpecific? Note that it /could/ be that all but x86 have the same definition, so "PlatformSpecific", might be too, um, specific. UstatMachine? (Similarly wrong, but maybe no matter, and shorter.) UstatNotCommon? Sounds dumb. UstatX? Not as bad as it sounds. There is a precedent. It self-documents the idea that there isn't an obvious good name. UstatInternal? UstatPrivate? It's not really about hiding, so much as implementation factoring. But implementation structure is an internal detail. UstatF? (Friend?) Ustructstat? no -- ideally, anything in existing Ustat.i3 that varies goess here, not necessarily just this type. I do not want fork entire files. The system is composed of common and uncommon pieces. I believe the decision where to split should be in general pushed down. However not without judgement calls. You know, there are things that must be shared, things that are nice to share, things that are more efficient to share, things that cannot be shared. Type declarations are usually "must" but in this case largely "nice" (not Ustat, but e.g. Upthreads), and some parts of them "cannot". This split/compose pattern, you know, is a way to get something like #ifdef, without any language change or such. It does make existing code harder to read, because it is broken up into more pieces, but code will always be broken up into pieces and never all in one place and always require some assumption or tracking down of what the next level down does (until you get to atoms, quantum physics, and all that), the thing is merely to decide on just what amount is the right amount (says Goldilocks.) - Jay From hosking at cs.purdue.edu Wed Apr 23 17:33:00 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 23 Apr 2008 11:33:00 -0400 Subject: [M3devel] naming conventions for split/composed interfaces? In-Reply-To: References: Message-ID: <06FA077F-C6FB-4E42-B4AE-1A040EE2698E@cs.purdue.edu> Generally, what I try to do is to make Uxxxxx.i3 files for every corresponding C xxxx.h file. This way, as the C headers change it is easy to figure out where things should go. Why do you need a platform- specific name at all? Simply put it into a platform-specific subdirectory which will then be selectively included by the parent m3makefile. That way, we retain a consistent name for the files containing relevant declarations *across* platforms. Remember, only one of these subdirectories gets included in any given build (these are part of the run-time). So, for simplicity's sake I would argue that you are once more making unneeded complexity where simplicity is needed. So, simply having a "linux-generic" directory, and "linux-amd64" + "linux-ppc" + "linux-x86" subdirectories, each with "Upthread", "Ustat", etc. should work just fine. What's the point in making it more complicated? On Apr 23, 2008, at 11:20 AM, Jay wrote: > > So I'm fixing AMD64_LINUX Utypes.i3, Ustat.i3, etc. > > Look at what I did for example with Upthread.i3 vs. > UpthreadMachine.i3. > > Ustat.i3 shall be mostly the same between PPC_LINUX, LINUXLIBC6 > (I386_LINUX), AMD64_LINUX, etc. > > However struct_stat will not likely be. It appears, though I have to > double check, the difference cannot be abstracted out to pointer- > sized integer types, that the fields are of varying orders. > > So I want to say: > > linux-i386/UstatPlatformSpecific.i3 > TYPE struct_stat = ... > > linux-amd64/UstatPlatformSpecific.i3 > TYPE struct_stat = ... > > linux-ppc/UstatPlatformSpecific.i3 > TYPE struct_stat = ... > > linuxlibc/Ustat.i3 > TYPE struct_stat = UstatsPlatformSpecific.struct_stat; > > My question is simply: > > What is the, or a good, naming convention for UstatPlatformSpecific? > > Note that it /could/ be that all but x86 have the same definition, > so "PlatformSpecific", might be too, um, specific. > UstatMachine? (Similarly wrong, but maybe no matter, and shorter.) > UstatNotCommon? Sounds dumb. > UstatX? Not as bad as it sounds. There is a precedent. It self- > documents the idea that there isn't an obvious good name. > UstatInternal? UstatPrivate? > It's not really about hiding, so much as implementation factoring. > But implementation structure is an internal detail. > UstatF? (Friend?) > Ustructstat? no -- ideally, anything in existing Ustat.i3 that > varies goess here, not necessarily just this type. > > I do not want fork entire files. > The system is composed of common and uncommon pieces. > I believe the decision where to split should be in general pushed > down. > However not without judgement calls. > You know, there are things that must be shared, things that are nice > to share, things that are more efficient to share, things that > cannot be shared. > Type declarations are usually "must" but in this case largely > "nice" (not Ustat, but e.g. Upthreads), and some parts of them > "cannot". > > This split/compose pattern, you know, is a way to get something like > #ifdef, without any language change or such. > It does make existing code harder to read, because it is broken up > into more pieces, but code will always be broken up into pieces and > never all in one place and always require some assumption or > tracking down of what the next level down does (until you get to > atoms, quantum physics, and all that), the thing is merely to decide > on just what amount is the right amount (says Goldilocks.) > > - Jay From jayk123 at hotmail.com Wed Apr 23 17:35:57 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Apr 2008 15:35:57 +0000 Subject: [M3devel] naming conventions for split/composed interfaces? Message-ID: another idea: merge UpthreadMachine.i3 and UstatMachine.i3 into just Umachine.i3. Seems like it produces fewer medium sized files instead of more tiny ones but I think I see a drawback too, and until I hear back will go with UstatMachine. Eventually more sharing is probably possible, like of all of Ustat across all platforms, except for struct_stat. And all of Upthread except the sizes of the types and possibly the initializers (Cygwin has non-zero initializers, ideally they are all zero though.) And most of Cstd*. It bugs me to have so many so similar files.... - Jay have moved struct > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Subject: naming conventions for split/composed interfaces? > Date: Wed, 23 Apr 2008 15:20:41 +0000 > > > So I'm fixing AMD64_LINUX Utypes.i3, Ustat.i3, etc. > > Look at what I did for example with Upthread.i3 vs. UpthreadMachine.i3. > > Ustat.i3 shall be mostly the same between PPC_LINUX, LINUXLIBC6 (I386_LINUX), AMD64_LINUX, etc. > > However struct_stat will not likely be. It appears, though I have to double check, the difference cannot be abstracted out to pointer-sized integer types, that the fields are of varying orders. > > So I want to say: > > linux-i386/UstatPlatformSpecific.i3 > TYPE struct_stat = ... > > linux-amd64/UstatPlatformSpecific.i3 > TYPE struct_stat = ... > > linux-ppc/UstatPlatformSpecific.i3 > TYPE struct_stat = ... > > linuxlibc/Ustat.i3 > TYPE struct_stat = UstatsPlatformSpecific.struct_stat; > > My question is simply: > > What is the, or a good, naming convention for UstatPlatformSpecific? > > Note that it /could/ be that all but x86 have the same definition, so "PlatformSpecific", might be too, um, specific. > UstatMachine? (Similarly wrong, but maybe no matter, and shorter.) > UstatNotCommon? Sounds dumb. > UstatX? Not as bad as it sounds. There is a precedent. It self-documents the idea that there isn't an obvious good name. > UstatInternal? UstatPrivate? > It's not really about hiding, so much as implementation factoring. But implementation structure is an internal detail. > UstatF? (Friend?) > Ustructstat? no -- ideally, anything in existing Ustat.i3 that varies goess here, not necessarily just this type. > > I do not want fork entire files. > The system is composed of common and uncommon pieces. > I believe the decision where to split should be in general pushed down. > However not without judgement calls. > You know, there are things that must be shared, things that are nice to share, things that are more efficient to share, things that cannot be shared. > Type declarations are usually "must" but in this case largely "nice" (not Ustat, but e.g. Upthreads), and some parts of them "cannot". > > This split/compose pattern, you know, is a way to get something like #ifdef, without any language change or such. > It does make existing code harder to read, because it is broken up into more pieces, but code will always be broken up into pieces and never all in one place and always require some assumption or tracking down of what the next level down does (until you get to atoms, quantum physics, and all that), the thing is merely to decide on just what amount is the right amount (says Goldilocks.) > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Apr 23 22:01:24 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 23 Apr 2008 16:01:24 -0400 Subject: [M3devel] naming conventions for split/composed interfaces? In-Reply-To: References: <06FA077F-C6FB-4E42-B4AE-1A040EE2698E@cs.purdue.edu> <7F9C2510-13AB-4CB0-8C79-4315C75C90E6@cs.purdue.edu> Message-ID: Basically, I hate the idea of tangling together multiple machine- dependent systems in the same files. Yes, it is verbose with duplicated functionality, but it *is* separable. I can delete one set of files without breaking builds on other targets. I hate the idea of C wrappers even more! So, my position remains that while it is verbose having separate target-specific directories, at least they are independent and isolated. I actually think your suggestion is much messier than the current situation! On Apr 23, 2008, at 1:12 PM, Jay wrote: > ok. stat is an evolutionary mess actually. > > > Tony, Are you against having one Modula-3 definition of the type, > arbitrarily defined (any order, no padding, omit the nanoseconds > probably) and then wrappers in C to copy the data out? That is very > simple and obviously correct and just a tad inefficient. I'm very > much leaning toward this. Just for all live Linux variants for now, > not anything else (until I see if they have messy slightly hard to > read headers -- really, I can read them, or preprocess them, but I > am a little off put, others would be more off put and checking my > work becomes harder). I think there's gains to be in Cygwin too -- > you can ask it for not all the fields and have it be faster, you > know, if you don't need some complicated made up ino. > > Either that, or I rather think I should work out the two or three > struct declarations precisely and write non-copying wrappers in > Modula-3 that call __lxstat64, __fxstat64, etc., copying the inlines > out of the header. > > I approach from both sides -- read the header, and have C code print > sizes and offsets. > > It's a little messy. Read the comments. > There is a version number parameter to an underlying wrapper function. > The wrapper is either inlined or statically linked. > > I have to check if /usr/include represents all architectures, or > just x86 and AMD64. > It could be that the fork is on 32 and 64. > It could also be that using stat64 makes it all a little simpler, > but still a little messy. I have to see when then was introduced, I > assume well before LINUXLIBC6 but I have to check. Even stat64 isn't > the same between architectures though, it is split 32bit and 64bit.. > > - Jay > > From: hosking at cs.purdue.edu > To: jayk123 at hotmail.com > Subject: Re: [M3devel] naming conventions for split/composed > interfaces? > Date: Wed, 23 Apr 2008 12:40:23 -0400 > > Yeah, but in this case they really are for the platform -- header > files in /usr/include. I just want to make sure that we don't > slice and dice in ways that multiply the confusion. Right now, if I > know what platform I am on I know where to look in cm3/m3-libs/ > m3core/src/unix. I do try to use generic stuff where possible > (witness my darwin-generic, darwin-ppc, darwin-i386, darwin-amd64). > > On Apr 23, 2008, at 11:39 AM, Jay wrote: > > The point is to reduce massive duplication. > > Sometimes we split on ostype, sometimes on wordsize, sometimes on > the entire platform, sometimes otherwise. > Imagine if we always split on entire platform, what a mess that > would be. > > Upthread.i3 should be nearly identical across all platforms. > I know some platforms might have more functions, but the next > level up is not split and is therefore consistent in what it uses, > so no point in splitting the entire interface. > Let's not multiply everything out just to change a few lines. > > There is too much duplication in the system imho and I'd like to see > it reduced. > > - Jay > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > To: jayk123 at hotmail.com > > Subject: Re: [M3devel] naming conventions for split/composed > interfaces? > > Date: Wed, 23 Apr 2008 11:33:00 -0400 > > > > Generally, what I try to do is to make Uxxxxx.i3 files for every > > corresponding C xxxx.h file. This way, as the C headers change it is > > easy to figure out where things should go. Why do you need a > platform- > > specific name at all? Simply put it into a platform-specific > > subdirectory which will then be selectively included by the parent > > m3makefile. That way, we retain a consistent name for the files > > containing relevant declarations *across* platforms. Remember, only > > one of these subdirectories gets included in any given build (these > > are part of the run-time). So, for simplicity's sake I would argue > > that you are once more making unneeded complexity where simplicity > is > > needed. > > > > So, simply having a "linux-generic" directory, and "linux-amd64" + > > "linux-ppc" + "linux-x86" subdirectories, each with "Upthread", > > "Ustat", etc. should work just fine. What's the point in making it > > more complicated? > > > > On Apr 23, 2008, at 11:20 AM, Jay wrote: > > > > > > > > So I'm fixing AMD64_LINUX Utypes.i3, Ustat.i3, etc. > > > > > > Look at what I did for example with Upthread.i3 vs. > > > UpthreadMachine.i3. > > > > > > Ustat.i3 shall be mostly the same between PPC_LINUX, LINUXLIBC6 > > > (I386_LINUX), AMD64_LINUX, etc. > > > > > > However struct_stat will not likely be. It appears, though I > have to > > > double check, the difference cannot be abstracted out to pointer- > > > sized integer types, that the fields are of varying orders. > > > > > > So I want to say: > > > > > > linux-i386/UstatPlatformSpecific.i3 > > > TYPE struct_stat = ... > > > > > > linux-amd64/UstatPlatformSpecific.i3 > > > TYPE struct_stat = ... > > > > > > linux-ppc/UstatPlatformSpecific.i3 > > > TYPE struct_stat = ... > > > > > > linuxlibc/Ustat.i3 > > > TYPE struct_stat = UstatsPlatformSpecific.struct_stat; > > > > > > My question is simply: > > > > > > What is the, or a good, naming convention for > UstatPlatformSpecific? > > > > > > Note that it /could/ be that all but x86 have the same definition, > > > so "PlatformSpecific", might be too, um, specific. > > > UstatMachine? (Similarly wrong, but maybe no matter, and shorter.) > > > UstatNotCommon? Sounds dumb. > > > UstatX? Not as bad as it sounds. There is a precedent. It self- > > > documents the idea that there isn't an obvious good name. > > > UstatInternal? UstatPrivate? > > > It's not really about hiding, so much as implementation factoring. > > > But implementation structure is an internal detail. > > > UstatF? (Friend?) > > > Ustructstat? no -- ideally, anything in existing Ustat.i3 that > > > varies goess here, not necessarily just this type. > > > > > > I do not want fork entire files. > > > The system is composed of common and uncommon pieces. > > > I believe the decision where to split should be in general pushed > > > down. > > > However not without judgement calls. > > > You know, there are things that must be shared, things that are > nice > > > to share, things that are more efficient to share, things that > > > cannot be shared. > > > Type declarations are usually "must" but in this case largely > > > "nice" (not Ustat, but e.g. Upthreads), and some parts of them > > > "cannot". > > > > > > This split/compose pattern, you know, is a way to get something > like > > > #ifdef, without any language change or such. > > > It does make existing code harder to read, because it is broken up > > > into more pieces, but code will always be broken up into pieces > and > > > never all in one place and always require some assumption or > > > tracking down of what the next level down does (until you get to > > > atoms, quantum physics, and all that), the thing is merely to > decide > > > on just what amount is the right amount (says Goldilocks.) > > > > > > - Jay > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Apr 23 23:32:43 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 23 Apr 2008 23:32:43 +0200 Subject: [M3devel] naming conventions for split/composed interfaces? In-Reply-To: References: <06FA077F-C6FB-4E42-B4AE-1A040EE2698E@cs.purdue.edu> <7F9C2510-13AB-4CB0-8C79-4315C75C90E6@cs.purdue.edu> Message-ID: <20080423233243.ijpvrxlgwsw8s4og@mail.elegosoft.com> Quoting Tony Hosking : > Basically, I hate the idea of tangling together multiple machine- > dependent systems in the same files. Yes, it is verbose with > duplicated functionality, but it *is* separable. I can delete one set > of files without breaking builds on other targets. I hate the idea of > C wrappers even more! > > So, my position remains that while it is verbose having separate > target-specific directories, at least they are independent and isolated. > > I actually think your suggestion is much messier than the current situation! I agree with Tony here: we should keep the structure as simple and easily manageable as possible. While I understand your idea to join together files based on content (or, ultimately, on Unix history) we should keep in mind that a minimal amount of code does not always mean the minimal amount of maintenance costs, as the underlying systems evolve, too, and may (and will) do so in different directions. This may then require a different internal structure. So I like the idea of keeping different directories for different systems, even if there is some redundancy. Another argument to keep the structure is that is has proven to be easily portable; and we should be very careful to change it. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Thu Apr 24 01:01:27 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 23 Apr 2008 19:01:27 -0400 Subject: [M3devel] naming conventions for split/composed interfaces? In-Reply-To: <20080423233243.ijpvrxlgwsw8s4og@mail.elegosoft.com> References: <06FA077F-C6FB-4E42-B4AE-1A040EE2698E@cs.purdue.edu> <7F9C2510-13AB-4CB0-8C79-4315C75C90E6@cs.purdue.edu> <20080423233243.ijpvrxlgwsw8s4og@mail.elegosoft.com> Message-ID: <480F8783.1E75.00D7.1@scires.com> I too agree with Tony and Olaf on this point. The type of change Jay is suggesting goes against the way the language development has been set up and established since the beginning. Regards, Randy >>> Olaf Wagner 4/23/2008 5:32 PM >>> Quoting Tony Hosking : > Basically, I hate the idea of tangling together multiple machine- > dependent systems in the same files. Yes, it is verbose with > duplicated functionality, but it *is* separable. I can delete one set > of files without breaking builds on other targets. I hate the idea of > C wrappers even more! > > So, my position remains that while it is verbose having separate > target-specific directories, at least they are independent and isolated. > > I actually think your suggestion is much messier than the current situation! I agree with Tony here: we should keep the structure as simple and easily manageable as possible. While I understand your idea to join together files based on content (or, ultimately, on Unix history) we should keep in mind that a minimal amount of code does not always mean the minimal amount of maintenance costs, as the underlying systems evolve, too, and may (and will) do so in different directions. This may then require a different internal structure. So I like the idea of keeping different directories for different systems, even if there is some redundancy. Another argument to keep the structure is that is has proven to be easily portable; and we should be very careful to change it. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com ( 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 jayk123 at hotmail.com Thu Apr 24 12:58:12 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 24 Apr 2008 10:58:12 +0000 Subject: [M3devel] naming conventions for split/composed interfaces? In-Reply-To: <20080423233243.ijpvrxlgwsw8s4og@mail.elegosoft.com> References: <06FA077F-C6FB-4E42-B4AE-1A040EE2698E@cs.purdue.edu> <7F9C2510-13AB-4CB0-8C79-4315C75C90E6@cs.purdue.edu> <20080423233243.ijpvrxlgwsw8s4og@mail.elegosoft.com> Message-ID: Um..I have spent quite some time reading stat.h. At least 5 minutes. :) I must say, I really really really like the copyout method. Obviously, it goes something like this: struct_stat = RECORD st_dev : uint64_t; st_ino : uint64_t; st_mode : uint64_t; st_nlink : uint64_t; st_uid : uint64_t; st_gid : uint64_t; st_rdev : uint64_t; st_size : uint64_t; st_blksize: uint64_t; st_blocks : uint64_t; st_atime : uint64_t; st_mtime : uint64_t; st_ctime : uint64_t; END; struct_stat_star = UNTRACED REF struct_stat; void copyout(const stat_t* s, m3_stat_t* m) { m->st_ctime = s.st_stime; ... } int m3_stat(const char* path, m3_stat_t* m) { int result; struct stat s; result = m3_stat(path, &s); copyout(&s, m); return result; } and this one type definition and wrapper function is, like, arbitrarily portable to all systems. Quite simple. A little inefficient -- but it's not like the stat call itself won't dwarf the copying. I think I agree merging the files into Umachine.i3. However consider the part of Ustat.i3 other than the struct. The bit masks are probably identical across ALL platforms. The function declarations are. Actually even the struct can often be factored just by giving types like gid_t, ino_t, but I don't think that's worth it. I'd rather uint16_t, uint32_t, uint64_t. So I think moving just the struct into its own file, or using copyout, not a bad idea. Ustat.i3 is not quite the best example. I think a much better one is Upthread.i3. The file is very large and basically I think varies by 3-5 lines per variation. Lastly, you know, I do work to generate the headers kind of, and/or to derive them somewhat automatically. This work should probably be fully automated, at least for test cases, so assert the correctness. You know, write Modula-3 and C code to print field offsets and sizes and verify they are identical. This should aid maintenability. I assert the current system, no matter how the files are laid out, is overly fragile. I assert that transcribing .h files into .i3 files is a very dubious practise. It has an upside of easier cross building -- don't need the platform-specific headers. And it has the upside of not needing to worry about parsing .h files. But it is obviously bad maintainability. Better would be do wrappers like the above, except where perf is critical. Or at least actively (daily) assert the sizes/offsets. > Another argument to keep the structure is that is has proven to be > easily portable; and we should be very careful to change it. I think the current structure has proven easily copied around and then not fixed and bugs lurking.. This is not really my original point, but I have to harp a bit, it's been simmering in my brain a long time. Any time I see header cloning I cringe significantly. Visual Basic and C# have this same problem. - Jay > Date: Wed, 23 Apr 2008 23:32:43 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] naming conventions for split/composed interfaces? > > Quoting Tony Hosking : > > > Basically, I hate the idea of tangling together multiple machine- > > dependent systems in the same files. Yes, it is verbose with > > duplicated functionality, but it *is* separable. I can delete one set > > of files without breaking builds on other targets. I hate the idea of > > C wrappers even more! > > > > So, my position remains that while it is verbose having separate > > target-specific directories, at least they are independent and isolated. > > > > I actually think your suggestion is much messier than the current situation! > > I agree with Tony here: we should keep the structure as simple and > easily manageable as possible. > > While I understand your idea to join together files based on content > (or, ultimately, on Unix history) we should keep in mind that a > minimal amount of code does not always mean the minimal amount > of maintenance costs, as the underlying systems evolve, too, and may > (and will) do so in different directions. This may then require a > different internal structure. > > So I like the idea of keeping different directories for different > systems, even if there is some redundancy. > > Another argument to keep the structure is that is has proven to be > easily portable; and we should be very careful to change it. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Apr 24 14:44:57 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 24 Apr 2008 08:44:57 -0400 Subject: [M3devel] naming conventions for split/composed interfaces? In-Reply-To: References: <06FA077F-C6FB-4E42-B4AE-1A040EE2698E@cs.purdue.edu> <7F9C2510-13AB-4CB0-8C79-4315C75C90E6@cs.purdue.edu> <20080423233243.ijpvrxlgwsw8s4og@mail.elegosoft.com> Message-ID: Please, avoid C wrappers wherever possible. 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 Apr 24, 2008, at 6:58 AM, Jay wrote: > > Um..I have spent quite some time reading stat.h. At least 5 > minutes. :) > > I must say, I really really really like the copyout method. > > Obviously, it goes something like this: > > struct_stat = RECORD > st_dev : uint64_t; > st_ino : uint64_t; > st_mode : uint64_t; > st_nlink : uint64_t; > st_uid : uint64_t; > st_gid : uint64_t; > st_rdev : uint64_t; > st_size : uint64_t; > st_blksize: uint64_t; > st_blocks : uint64_t; > st_atime : uint64_t; > st_mtime : uint64_t; > st_ctime : uint64_t; > END; > struct_stat_star = UNTRACED REF struct_stat; > > > void copyout(const stat_t* s, m3_stat_t* m) > { > m->st_ctime = s.st_stime; > ... > } > int m3_stat(const char* path, m3_stat_t* m) > { > int result; > struct stat s; > > result = m3_stat(path, &s); > copyout(&s, m); > return result; > } > > and this one type definition and wrapper function is, like, > arbitrarily portable to all systems. > Quite simple. A little inefficient -- but it's not like the stat > call itself won't dwarf the copying. > > I think I agree merging the files into Umachine.i3. > > However consider the part of Ustat.i3 other than the struct. > The bit masks are probably identical across ALL platforms. > The function declarations are. > Actually even the struct can often be factored just by giving types > like gid_t, ino_t, but I don't think that's worth it. > I'd rather uint16_t, uint32_t, uint64_t. > > So I think moving just the struct into its own file, or using > copyout, not a bad idea. > > Ustat.i3 is not quite the best example. > I think a much better one is Upthread.i3. > The file is very large and basically I think varies by 3-5 lines per > variation. > > Lastly, you know, I do work to generate the headers kind of, and/or > to derive them somewhat automatically. > This work should probably be fully automated, at least for test > cases, so assert the correctness. > You know, write Modula-3 and C code to print field offsets and sizes > and verify they are identical. > This should aid maintenability. I assert the current system, no > matter how the files are laid out, is overly fragile. > I assert that transcribing .h files into .i3 files is a very dubious > practise. > It has an upside of easier cross building -- don't need the platform- > specific headers. > And it has the upside of not needing to worry about parsing .h files. > But it is obviously bad maintainability. > > Better would be do wrappers like the above, except where perf is > critical. > Or at least actively (daily) assert the sizes/offsets. > >> Another argument to keep the structure is that is has proven to be >> easily portable; and we should be very careful to change it. > > I think the current structure has proven easily copied around and > then not fixed and bugs lurking.. > This is not really my original point, but I have to harp a bit, it's > been simmering in my brain a long time. > Any time I see header cloning I cringe significantly. Visual Basic > and C# have this same problem. > > - Jay > > > > >> Date: Wed, 23 Apr 2008 23:32:43 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] naming conventions for split/composed >> interfaces? >> >> Quoting Tony Hosking : >> >>> Basically, I hate the idea of tangling together multiple machine- >>> dependent systems in the same files. Yes, it is verbose with >>> duplicated functionality, but it *is* separable. I can delete one >>> set >>> of files without breaking builds on other targets. I hate the >>> idea of >>> C wrappers even more! >>> >>> So, my position remains that while it is verbose having separate >>> target-specific directories, at least they are independent and >>> isolated -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Apr 25 02:28:00 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 25 Apr 2008 00:28:00 +0000 Subject: [M3devel] naming conventions for split/composed interfaces? In-Reply-To: References: <06FA077F-C6FB-4E42-B4AE-1A040EE2698E@cs.purdue.edu> <7F9C2510-13AB-4CB0-8C79-4315C75C90E6@cs.purdue.edu> <20080423233243.ijpvrxlgwsw8s4og@mail.elegosoft.com> Message-ID: What cost are you willing to pay? It is EASY to write one simple Ustat.i3 and UstatC.c that is correct for all platforms, totally portable, simple, efficient enough etc. The cost of avoiding the wrapper is pain, uncertainty, much higher risk of the implementation being wrong or becoming silently wrong, though... Well, how about this suggestion? How about we start writing some C code that asserts the correctness of the .i3 files?Or even having the compiler output such C code? Just make sure it compiles? Ustat.i3 would get some directive LIKE: <* PRAGMA C-derived "#include sys/stat.h", "struct stat" *> struct_stat = RECORD ... END The second parameter is the type that the record should "match". This would generate and a compile a file something like: #include #define size(a,b,c) (sizeof((a)(a*)0)->b == c) #define field(a,b) ((a*)0)->b) #define offset(a,b) ((size_t)a) type_size_size(struct stat, 0x123) size(struct stat, st_dev, 8) size(field(struct stat, st_dev), 8) size(field(struct stat, st_ino), 8) offset(field(struct stat, st_dev), 0) offset(field(struct stat, st_ino), 8) etc. where all the numbers on the right are what the compiler computes. This way, the transcription of C into Modula-3 is checked for correctness. It can be optional -- like for cross builds that might have a C compiler or headers/libs. I have to admit, there is an aspect of avoiding C that I really like -- the idea of building one tool for all targets, all in one, no need to get a cross compiler or headers/libs. To me that is a potential big upside to avoiding wrappers. I would even suggest -- can the dtoa.c and hand.c be rewritten in Modula-3. dtoa.c was very very gnarly last I looked. Could be they dropped support for IBM/Cray/VAX and it's simpler now, I don't know. While I like the idea, I would be reluctant because I don't understand the code much. hand.c though, I strongly suspect can be written in perfectly portable efficient Modula-3. It may or MIGHT not compiler down as efficiently, just if the compiler doesn't do a good job, but I don't think, like, "there any layers in the model" that prevent it, like you wouldn't have to do extra heap allocs or copies. You might get some extra array bounds checks, that would be good to avoid introducing. Well, I'm too busy right now, but: 1) I'll maybe the errno wrapper in NT386. As long as you avoid the thread-unsafe library, this area has been stable forever. And building in a dependency on thread safety is a good thing. 2) I'll see about rewriting hand.c in Modula-3 and see if I can convince myself there's no perf loss. 3) I look at gtoa.c to confirm it is still way to gnarly to consider changing. 4) Eventually see about building in this checking. It removes the upside of not having a compiler/headers, that's why optional. 5) Wonder about automating generation of the Modula-3 in the first place? Something like SWIG? I don't know. Problem with #4 and #5 is special cases. Coming up with some mechanized translation that actually exists and works. Gotta run, - Jay CC: wagner at elegosoft.com; m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] naming conventions for split/composed interfaces?Date: Thu, 24 Apr 2008 08:44:57 -0400 Please, avoid C wrappers wherever possible. 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 Apr 24, 2008, at 6:58 AM, Jay wrote: Um..I have spent quite some time reading stat.h. At least 5 minutes. :)I must say, I really really really like the copyout method.Obviously, it goes something like this: struct_stat = RECORD st_dev : uint64_t; st_ino : uint64_t; st_mode : uint64_t; st_nlink : uint64_t; st_uid : uint64_t; st_gid : uint64_t; st_rdev : uint64_t; st_size : uint64_t; st_blksize: uint64_t; st_blocks : uint64_t; st_atime : uint64_t; st_mtime : uint64_t; st_ctime : uint64_t; END; struct_stat_star = UNTRACED REF struct_stat;void copyout(const stat_t* s, m3_stat_t* m){ m->st_ctime = s.st_stime; ...}int m3_stat(const char* path, m3_stat_t* m){ int result; struct stat s; result = m3_stat(path, &s); copyout(&s, m); return result;}and this one type definition and wrapper function is, like, arbitrarily portable to all systems.Quite simple. A little inefficient -- but it's not like the stat call itself won't dwarf the copying.I think I agree merging the files into Umachine.i3.However consider the part of Ustat.i3 other than the struct.The bit masks are probably identical across ALL platforms.The function declarations are.Actually even the struct can often be factored just by giving types like gid_t, ino_t, but I don't think that's worth it.I'd rather uint16_t, uint32_t, uint64_t.So I think moving just the struct into its own file, or using copyout, not a bad idea.Ustat.i3 is not quite the best example.I think a much better one is Upthread.i3.The file is very large and basically I think varies by 3-5 lines per variation.Lastly, you know, I do work to generate the headers kind of, and/or to derive them somewhat automatically.This work should probably be fully automated, at least for test cases, so assert the correctness.You know, write Modula-3 and C code to print field offsets and sizes and verify they are identical.This should aid maintenability. I assert the current system, no matter how the files are laid out, is overly fragile.I assert that transcribing .h files into .i3 files is a very dubious practise.It has an upside of easier cross building -- don't need the platform-specific headers.And it has the upside of not needing to worry about parsing .h files.But it is obviously bad maintainability.Better would be do wrappers like the above, except where perf is critical.Or at least actively (daily) assert the sizes/offsets. Another argument to keep the structure is that is has proven to be easily portable; and we should be very careful to change it.I think the current structure has proven easily copied around and then not fixed and bugs lurking..This is not really my original point, but I have to harp a bit, it's been simmering in my brain a long time.Any time I see header cloning I cringe significantly. Visual Basic and C# have this same problem.- Jay Date: Wed, 23 Apr 2008 23:32:43 +0200 From: wagner at elegosoft.com To: m3devel at elegosoft.com Subject: Re: [M3devel] naming conventions for split/composed interfaces? Quoting Tony Hosking : Basically, I hate the idea of tangling together multiple machine- dependent systems in the same files. Yes, it is verbose with duplicated functionality, but it *is* separable. I can delete one set of files without breaking builds on other targets. I hate the idea of C wrappers even more! So, my position remains that while it is verbose having separate target-specific directories, at least they are independent and isolated -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Apr 25 08:19:05 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 25 Apr 2008 08:19:05 +0200 Subject: [M3devel] naming conventions for split/composed interfaces? In-Reply-To: References: <06FA077F-C6FB-4E42-B4AE-1A040EE2698E@cs.purdue.edu> <7F9C2510-13AB-4CB0-8C79-4315C75C90E6@cs.purdue.edu> <20080423233243.ijpvrxlgwsw8s4og@mail.elegosoft.com> Message-ID: <20080425081905.bibtuvhnhcg8k4wk@mail.elegosoft.com> Quoting Jay : > What cost are you willing to pay? > It is EASY to write one simple Ustat.i3 and UstatC.c that is correct > for all platforms, totally portable, simple, efficient enough etc. > The cost of avoiding the wrapper is pain, uncertainty, much higher > risk of the implementation being wrong or becoming silently wrong, > though... In case of stat, copying the structure may lead to performance bottle- necks in I/O intensive programs (like build systmes etc.). Build systems for example may start by stat-ing ten thousands of files in their first phase. I'd not object to adding something like a generic posix subdir, which could be used for fast porting, but I wouldn't want this to be used for current plaforms if it has performance impacts. > Well, how about this suggestion? > How about we start writing some C code that asserts the correctness > of the .i3 files?Or even having the compiler output such C code? > Just make sure it compiles? This sounds more than what I'd like to do. I think we need to analyze what exactly M3 really needs from the underlying target platform, and automate a way of generating the correct interfaces for that. Something configure-like that will only be used for porting (or checking the correctness of existing interfaces). > Ustat.i3 would get some directive LIKE: > > <* PRAGMA C-derived "#include sys/stat.h", "struct stat" *> > struct_stat = RECORD ... END > > The second parameter is the type that the record should "match". > > This would generate and a compile a file something like: > #include > #define size(a,b,c) (sizeof((a)(a*)0)->b == c) > #define field(a,b) ((a*)0)->b) > #define offset(a,b) ((size_t)a) > > type_size_size(struct stat, 0x123) > size(struct stat, st_dev, 8) > size(field(struct stat, st_dev), 8) > size(field(struct stat, st_ino), 8) > offset(field(struct stat, st_dev), 0) > offset(field(struct stat, st_ino), 8) > etc. > > where all the numbers on the right are what the compiler computes. > > This way, the transcription of C into Modula-3 is checked for correctness. > > It can be optional -- like for cross builds that might have a C > compiler or headers/libs. > I have to admit, there is an aspect of avoiding C that I really like > -- the idea of building one tool for all targets, all in one, no > need to get a cross compiler or headers/libs. To me that is a > potential big upside to avoiding wrappers. > I would even suggest -- can the dtoa.c and hand.c be rewritten in Modula-3. > dtoa.c was very very gnarly last I looked. Could be they dropped > support for IBM/Cray/VAX and it's simpler now, I don't know. While I > like the idea, I would be reluctant because I don't understand the > code much. > hand.c though, I strongly suspect can be written in perfectly > portable efficient Modula-3. There have been some discussions in the past about updating or replacing dtoa.h in M3. Have a look at the mailing list archives before spending too much time on it. > It may or MIGHT not compiler down as efficiently, just if the > compiler doesn't do a good job, but I don't think, like, "there any > layers in the model" that prevent it, like you wouldn't have to do > extra heap allocs or copies. You might get some extra array bounds > checks, that would be good to avoid introducing. > > Well, I'm too busy right now, but: > > 1) I'll maybe the errno wrapper in NT386. As long as you avoid the > thread-unsafe library, this area has been stable forever. > And building in a dependency on thread safety is a good thing. > > 2) I'll see about rewriting hand.c in Modula-3 and see if I can > convince myself there's no perf loss. > > 3) I look at gtoa.c to confirm it is still way to gnarly to consider > changing. > > 4) Eventually see about building in this checking. It removes the > upside of not having a compiler/headers, that's why optional. > > 5) Wonder about automating generation of the Modula-3 in the first > place? Something like SWIG? I don't know. > Problem with #4 and #5 is special cases. Coming up with some > mechanized translation that actually exists and works. SWIG has already been tried at least twice for M3, and found to be somewhat unhandy and insufficient. It does not really speed up the process of getting correct M3 interfaces for C headers IIRC. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Fri Apr 25 08:37:13 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 25 Apr 2008 06:37:13 +0000 Subject: [M3devel] naming conventions for split/composed interfaces? In-Reply-To: <20080425081905.bibtuvhnhcg8k4wk@mail.elegosoft.com> References: <06FA077F-C6FB-4E42-B4AE-1A040EE2698E@cs.purdue.edu> <7F9C2510-13AB-4CB0-8C79-4315C75C90E6@cs.purdue.edu> <20080423233243.ijpvrxlgwsw8s4og@mail.elegosoft.com> <20080425081905.bibtuvhnhcg8k4wk@mail.elegosoft.com> Message-ID: Copying around 64 bytes per stat call is never going to be the bottleneck.I am not 100% sure, but I believe every stat call is akernel call. Data already has to be copied betweenkernel and user mode, and some i/o, possibly cached,has to occur.Maybe if someone stats a bunch of files, and thenstats them many times afterward. I'm all for thin (zero thickness) wrappers, keeping things fast, but header cloning really bugs me. If you really want to stat a lot of files, at somepoint you'll win by using something like opendir/readdirto just get all the data -- given some readdir thatreturns the needed stat information.On Windows this is simply FindFirstFile/FindNextFile. (and yes I realize I'm partly rearranging deck chairs -- the readdir has to return some struct with the same issues as stat, however maybe there'd be knowledge of it operating on larger data and less tendency to slow it down) > generic posix directory to speed ports Sounds like a good compromise.And existing ports could even try it and measure the difference maybe. > swig vs. my compiler-based idea vs. generating some other> way only what is needed Good point. I did some stuff for Cygwin along these linesthat may be close to just right. Fairly simple C code that prints out the Modula-3.Again, what you could do, is in the build, optionallyrecompile/rerun the C and assert the output is unchanged. This is super easy for constants and chosing the rightinteger type for record fields.It is easy enough for getting the record fields in the rightorder, and asserting that you didn't miss any (no holes), thoughI didn't do that (yet). Perhaps I should try that?Come up with reasonably simple very very portable C (probablyc++, with specific reasons) code that prints out..well..some set of .i3 files that bother me.I guess it is fairly scientific, which .i3 files describeC and which Modula-3.It is presence of <* external *>, the types they take and return.Constants, harder to identify mechanically. I also made a large stab to determine exactly what is neededand no or very little more. The Cygwin stuff should be a goodbasis for determing this, except it doesn't use pthreads. Another problem here not yet addressed is picking out functionsignatures. I think some simple uses of C++ templates mightwork here, but I have to experiment. There would still be much duplicity, but I guess generated(and still checked in, and often regenerated), is better thanhand written once and then not checked through time.Granted, if you get Ustat.i3 wrong, you do tend to find andfix the bugs fairly fast, but I'd like "static" checkingto get this stuff right. I'm not going to do much of anything here for now,but maybe I'll get around to it. It depends what bugs me most. :) - Jay > Date: Fri, 25 Apr 2008 08:19:05 +0200> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com> Subject: RE: [M3devel] naming conventions for split/composed interfaces?> > Quoting Jay :> > > What cost are you willing to pay?> > It is EASY to write one simple Ustat.i3 and UstatC.c that is correct > > for all platforms, totally portable, simple, efficient enough etc. > > The cost of avoiding the wrapper is pain, uncertainty, much higher > > risk of the implementation being wrong or becoming silently wrong, > > though...> > In case of stat, copying the structure may lead to performance bottle-> necks in I/O intensive programs (like build systmes etc.). Build> systems for example may start by stat-ing ten thousands of files in> their first phase.> > I'd not object to adding something like a generic posix subdir,> which could be used for fast porting, but I wouldn't want this> to be used for current plaforms if it has performance impacts.> > > Well, how about this suggestion?> > How about we start writing some C code that asserts the correctness > > of the .i3 files?Or even having the compiler output such C code? > > Just make sure it compiles?> > This sounds more than what I'd like to do. I think we need to> analyze what exactly M3 really needs from the underlying target> platform, and automate a way of generating the correct interfaces for> that. Something configure-like that will only be used for porting> (or checking the correctness of existing interfaces).> > > Ustat.i3 would get some directive LIKE:> >> > <* PRAGMA C-derived "#include sys/stat.h", "struct stat" *>> > struct_stat = RECORD ... END> >> > The second parameter is the type that the record should "match".> >> > This would generate and a compile a file something like:> > #include > > #define size(a,b,c) (sizeof((a)(a*)0)->b == c)> > #define field(a,b) ((a*)0)->b)> > #define offset(a,b) ((size_t)a)> >> > type_size_size(struct stat, 0x123)> > size(struct stat, st_dev, 8)> > size(field(struct stat, st_dev), 8)> > size(field(struct stat, st_ino), 8)> > offset(field(struct stat, st_dev), 0)> > offset(field(struct stat, st_ino), 8)> > etc.> >> > where all the numbers on the right are what the compiler computes.> >> > This way, the transcription of C into Modula-3 is checked for correctness.> >> > It can be optional -- like for cross builds that might have a C > > compiler or headers/libs.> > I have to admit, there is an aspect of avoiding C that I really like > > -- the idea of building one tool for all targets, all in one, no > > need to get a cross compiler or headers/libs. To me that is a > > potential big upside to avoiding wrappers.> > I would even suggest -- can the dtoa.c and hand.c be rewritten in Modula-3.> > dtoa.c was very very gnarly last I looked. Could be they dropped > > support for IBM/Cray/VAX and it's simpler now, I don't know. While I > > like the idea, I would be reluctant because I don't understand the > > code much.> > hand.c though, I strongly suspect can be written in perfectly > > portable efficient Modula-3.> > There have been some discussions in the past about updating or> replacing dtoa.h in M3. Have a look at the mailing list archives> before spending too much time on it.> > > It may or MIGHT not compiler down as efficiently, just if the > > compiler doesn't do a good job, but I don't think, like, "there any > > layers in the model" that prevent it, like you wouldn't have to do > > extra heap allocs or copies. You might get some extra array bounds > > checks, that would be good to avoid introducing.> >> > Well, I'm too busy right now, but:> >> > 1) I'll maybe the errno wrapper in NT386. As long as you avoid the > > thread-unsafe library, this area has been stable forever.> > And building in a dependency on thread safety is a good thing.> >> > 2) I'll see about rewriting hand.c in Modula-3 and see if I can > > convince myself there's no perf loss.> >> > 3) I look at gtoa.c to confirm it is still way to gnarly to consider > > changing.> >> > 4) Eventually see about building in this checking. It removes the > > upside of not having a compiler/headers, that's why optional.> >> > 5) Wonder about automating generation of the Modula-3 in the first > > place? Something like SWIG? I don't know.> > Problem with #4 and #5 is special cases. Coming up with some > > mechanized translation that actually exists and works.> > SWIG has already been tried at least twice for M3, and found to be> somewhat unhandy and insufficient. It does not really speed up the> process of getting correct M3 interfaces for C headers IIRC.> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 roland.illig at gmx.de Fri Apr 25 09:20:28 2008 From: roland.illig at gmx.de (Roland Illig) Date: Fri, 25 Apr 2008 08:20:28 +0100 Subject: [M3devel] moving versions into simple text file (sh?) In-Reply-To: <480AF7A4.4060905@gmx.de> References: <480AF7A4.4060905@gmx.de> Message-ID: <4811863C.40506@gmx.de> I'm explaining my code for getting the version numbers into a shell script, since it is not completely obvious. Roland Illig schrieb: > # usage: get_version VARNAME > get_version() { > eval "gv__set=\${$1+set}" This code tests whether VARNAME is already defined. When it is, gv__set will become "set", otherwise the empty string. > if [ "$gv__set" != "set" ]; then > gv__value=`awk '$1 == "'"$1"'" { print $2 }' $root/scripts/version` The awk script compares the first field ($1) of each line with VARNAME, and if they are equal, prints the second field ($2). The funny quotes ("'") are used to insert a shell variable ($1, the first argument to the function) literally into the awk script. > eval "$1=\$gv__value" Finally, the VARNAME variable gets the value that has been read from the file. If there was no value, the empty string is used. > fi > } Roland From hosking at cs.purdue.edu Fri Apr 25 15:53:54 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 25 Apr 2008 09:53:54 -0400 Subject: [M3devel] naming conventions for split/composed interfaces? In-Reply-To: References: <06FA077F-C6FB-4E42-B4AE-1A040EE2698E@cs.purdue.edu> <7F9C2510-13AB-4CB0-8C79-4315C75C90E6@cs.purdue.edu> <20080423233243.ijpvrxlgwsw8s4og@mail.elegosoft.com> <20080425081905.bibtuvhnhcg8k4wk@mail.elegosoft.com> Message-ID: <448E8A93-88BC-495B-A11D-587310A43F39@cs.purdue.edu> Header cloning is the price we pay for straightforward, uncomplicated, untangled, porting. Yes, there is a small amount of effort (usually an hour or so in my experience) putting together the *very few* interfaces to match C headers in order to bring up a new target. The resulting code is easily maintained as a faithful mirror of the original C headers. I really think you are overstating the difficulty here, and as others have observed, this approach has not impeded the development and portability of the system. On Apr 25, 2008, at 2:37 AM, Jay wrote: > Copying around 64 bytes per stat call is never going to be the > bottleneck. > I am not 100% sure, but I believe every stat call is a > kernel call. Data already has to be copied between > kernel and user mode, and some i/o, possibly cached, > has to occur. > Maybe if someone stats a bunch of files, and then > stats them many times afterward. > > I'm all for thin (zero thickness) wrappers, keeping things fast, but > header cloning really bugs me. > > If you really want to stat a lot of files, at some > point you'll win by using something like opendir/readdir > to just get all the data -- given some readdir that > returns the needed stat information. > On Windows this is simply FindFirstFile/FindNextFile. > (and yes I realize I'm partly rearranging deck chairs -- the readdir > has to return > some struct with the same issues as stat, however maybe there'd be > knowledge > of it operating on larger data and less tendency to slow it down) > > > generic posix directory to speed ports > > Sounds like a good compromise. > And existing ports could even try it and measure the difference maybe. > > > swig vs. my compiler-based idea vs. generating some other > > way only what is needed > > Good point. I did some stuff for Cygwin along these lines > that may be close to just right. > > Fairly simple C code that prints out the Modula-3. > Again, what you could do, is in the build, optionally > recompile/rerun the C and assert the output is unchanged. > > This is super easy for constants and chosing the right > integer type for record fields. > It is easy enough for getting the record fields in the right > order, and asserting that you didn't miss any (no holes), though > I didn't do that (yet). > > Perhaps I should try that? > Come up with reasonably simple very very portable C (probably > c++, with specific reasons) code that prints out..well.. > some set of .i3 files that bother me. > I guess it is fairly scientific, which .i3 files describe > C and which Modula-3. > It is presence of <* external *>, the types they take and return. > Constants, harder to identify mechanically. > > I also made a large stab to determine exactly what is needed > and no or very little more. The Cygwin stuff should be a good > basis for determing this, except it doesn't use pthreads. > > Another problem here not yet addressed is picking out function > signatures. I think some simple uses of C++ templates might > work here, but I have to experiment. > > There would still be much duplicity, but I guess generated > (and still checked in, and often regenerated), is better than > hand written once and then not checked through time. > Granted, if you get Ustat.i3 wrong, you do tend to find and > fix the bugs fairly fast, but I'd like "static" checking > to get this stuff right. > > I'm not going to do much of anything here for now, > but maybe I'll get around to it. It depends what bugs me most. :) > > - Jay > > > > > > > > Date: Fri, 25 Apr 2008 08:19:05 +0200 > > From: wagner at elegosoft.com > > To: jayk123 at hotmail.com > > CC: hosking at cs.purdue.edu; m3devel at elegosoft.com > > Subject: RE: [M3devel] naming conventions for split/composed > interfaces? > > > > Quoting Jay : > > > > > What cost are you willing to pay? > > > It is EASY to write one simple Ustat.i3 and UstatC.c that is > correct > > > for all platforms, totally portable, simple, efficient enough etc. > > > The cost of avoiding the wrapper is pain, uncertainty, much higher > > > risk of the implementation being wrong or becoming silently wrong, > > > though... > > > > In case of stat, copying the structure may lead to performance > bottle- > > necks in I/O intensive programs (like build systmes etc.). Build > > systems for example may start by stat-ing ten thousands of files in > > their first phase. > > > > I'd not object to adding something like a generic posix subdir, > > which could be used for fast porting, but I wouldn't want this > > to be used for current plaforms if it has performance impacts. > > > > > Well, how about this suggestion? > > > How about we start writing some C code that asserts the > correctness > > > of the .i3 files?Or even having the compiler output such C code? > > > Just make sure it compiles? > > > > This sounds more than what I'd like to do. I think we need to > > analyze what exactly M3 really needs from the underlying target > > platform, and automate a way of generating the correct interfaces > for > > that. Something configure-like that will only be used for porting > > (or checking the correctness of existing interfaces). > > > > > Ustat.i3 would get some directive LIKE: > > > > > > <* PRAGMA C-derived "#include sys/stat.h", "struct stat" *> > > > struct_stat = RECORD ... END > > > > > > The second parameter is the type that the record should "match". > > > > > > This would generate and a compile a file something like: > > > #include > > > #define size(a,b,c) (sizeof((a)(a*)0)->b == c) > > > #define field(a,b) ((a*)0)->b) > > > #define offset(a,b) ((size_t)a) > > > > > > type_size_size(struct stat, 0x123) > > > size(struct stat, st_dev, 8) > > > size(field(struct stat, st_dev), 8) > > > size(field(struct stat, st_ino), 8) > > > offset(field(struct stat, st_dev), 0) > > > offset(field(struct stat, st_ino), 8) > > > etc. > > > > > > where all the numbers on the right are what the compiler computes. > > > > > > This way, the transcription of C into Modula-3 is checked for > correctness. > > > > > > It can be optional -- like for cross builds that might have a C > > > compiler or headers/libs. > > > I have to admit, there is an aspect of avoiding C that I really > like > > > -- the idea of building one tool for all targets, all in one, no > > > need to get a cross compiler or headers/libs. To me that is a > > > potential big upside to avoiding wrappers. > > > I would even suggest -- can the dtoa.c and hand.c be rewritten > in Modula-3. > > > dtoa.c was very very gnarly last I looked. Could be they dropped > > > support for IBM/Cray/VAX and it's simpler now, I don't know. > While I > > > like the idea, I would be reluctant because I don't understand the > > > code much. > > > hand.c though, I strongly suspect can be written in perfectly > > > portable efficient Modula-3. > > > > There have been some discussions in the past about updating or > > replacing dtoa.h in M3. Have a look at the mailing list archives > > before spending too much time on it. > > > > > It may or MIGHT not compiler down as efficiently, just if the > > > compiler doesn't do a good job, but I don't think, like, "there > any > > > layers in the model" that prevent it, like you wouldn't have to do > > > extra heap allocs or copies. You might get some extra array bounds > > > checks, that would be good to avoid introducing. > > > > > > Well, I'm too busy right now, but: > > > > > > 1) I'll maybe the errno wrapper in NT386. As long as you avoid the > > > thread-unsafe library, this area has been stable forever. > > > And building in a dependency on thread safety is a good thing. > > > > > > 2) I'll see about rewriting hand.c in Modula-3 and see if I can > > > convince myself there's no perf loss. > > > > > > 3) I look at gtoa.c to confirm it is still way to gnarly to > consider > > > changing. > > > > > > 4) Eventually see about building in this checking. It removes the > > > upside of not having a compiler/headers, that's why optional. > > > > > > 5) Wonder about automating generation of the Modula-3 in the first > > > place? Something like SWIG? I don't know. > > > Problem with #4 and #5 is special cases. Coming up with some > > > mechanized translation that actually exists and works. > > > > SWIG has already been tried at least twice for M3, and found to be > > somewhat unhandy and insufficient. It does not really speed up the > > process of getting correct M3 interfaces for C headers IIRC. > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Apr 26 09:17:04 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 26 Apr 2008 09:17:04 +0200 Subject: [M3devel] tinderbox failures / release builds broken Message-ID: <20080426091704.472e30pem8ww8wgs@mail.elegosoft.com> Jay, this seems to have broken all release builds: (+34/18) Lines changed. When Who File Rev +/- Description 2008-04-25 22:33 jkrell cm3/m3-sys/m3cc/src/m3makefile 1.58 34/18 workaround strange problems building gmp/mpfr for NT386GNU as well as non-strange problem building m3cg1.exe (the makefile wants m3cg1. '.exe' is dealt with some other way Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Sat Apr 26 10:03:06 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 26 Apr 2008 08:03:06 +0000 Subject: [M3devel] tinderbox failures / release builds broken In-Reply-To: <20080426091704.472e30pem8ww8wgs@mail.elegosoft.com> References: <20080426091704.472e30pem8ww8wgs@mail.elegosoft.com> Message-ID: oops, sorry, should be ok now > Date: Sat, 26 Apr 2008 09:17:04 +0200 > From: wagner at elegosoft.com > To: jayk123 at hotmail.com > CC: m3devel at elegosoft.com > Subject: tinderbox failures / release builds broken > > Jay, > > this seems to have broken all release builds: > > (+34/18) Lines changed. > When Who File Rev +/- Description > 2008-04-25 22:33 jkrell cm3/m3-sys/m3cc/src/m3makefile 1.58 34/18 > workaround strange problems building gmp/mpfr for NT386GNU as well as > non-strange problem building m3cg1.exe (the makefile wants m3cg1. > '.exe' is dealt with some other way > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Apr 28 18:42:17 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 28 Apr 2008 18:42:17 +0200 Subject: [M3devel] Popup Windows stalling regression tests on WinXP Message-ID: <20080428184217.dizt8loly8go80gg@mail.elegosoft.com> Hi Jay, everytime I have a look why the regression tests haven't terminated yet, I find another popup window with a message like this: cm3.exe has encountered a problem and needs to close. We are sorry for the inconvenience. Any idea how to suppress this kind of error notification? We'll never get reliable regression testing with popup windows :-/ Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Mon Apr 28 23:47:35 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Apr 2008 21:47:35 +0000 Subject: [M3devel] Popup Windows stalling regression tests on WinXP In-Reply-To: <20080428184217.dizt8loly8go80gg@mail.elegosoft.com> References: <20080428184217.dizt8loly8go80gg@mail.elegosoft.com> Message-ID: Olaf, this is a bug and should be fixed.Like someone calling abort or assert(false) or NtRaiseHardError or dereferencing NULL or such.Or skip those tests on NT386 for now.And please provide an easy way to run specific tests.I'm working on adding some tests (ok, just one) and it seems to be a pain.I think it's just cm3 -FA ../../TESTARGS but it wasn't working. Install the debuggers: http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx I install to c:\bin\x86 and c:\bin\amd64, though the default is c:\program files\blah. mkdir c:\symbols this is just for a local cache, not needed but nice cd c:\bin\x86\windbg -o -G -g -y srv*c:\symbols*http://msdl.microsoft.com/download/symbols cm3 When there is a popup, type: ~*k to get all the thread stacks, and see which one is in MessageBox or abort or whatnot. And send the stack? Or all of them if uncertain. You can also make a full or minidump with .dump for someone else to look at. Good to have the cm3.exe and cm3.pdb as well. Or I guess I can/should just fix them.I think I've seen a few of these myself. The stack might not be well displayed by the debugger. It could be this in the toplevel exception handler/watson thingy. Another thing to try is: c:\bin\x86\windbg -I to install windbg as the JIT debugger. That way, some crashes will bring up a debugger, possibly prompting first. I need to make a web page with a Win32 debugging primer at some point. Anyway, I'll try to bump this up in priority. Could be that SetErrorMode(something) quashes them, but that doesn't mean it isn't a bug. Another very good theory is that the "app type", console vs. gui, is relevant. Console apps upon abort() or assert(false) print something to stdout/stderr and then exit, whereas gui apps use MessageBox. The type is determined from the .exe, and you can change it at runtime via a call. Not clear to me which of the various catastrophic errors this is though. I think abort(). - Jay > Date: Mon, 28 Apr 2008 18:42:17 +0200> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Popup Windows stalling regression tests on WinXP> > Hi Jay,> > everytime I have a look why the regression tests haven't terminated> yet, I find another popup window with a message like this:> > cm3.exe has encountered a problem and needs to close.> We are sorry for the inconvenience.> > Any idea how to suppress this kind of error notification?> We'll never get reliable regression testing with popup windows :-/> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 jayk123 at hotmail.com Mon Apr 28 23:56:17 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Apr 2008 21:56:17 +0000 Subject: [M3devel] Popup Windows stalling regression tests on WinXP In-Reply-To: <20080428184217.dizt8loly8go80gg@mail.elegosoft.com> References: <20080428184217.dizt8loly8go80gg@mail.elegosoft.com> Message-ID: truncated and newlines got removed, I wonder if email will ever work.. From: jayk123 at hotmail.comTo: wagner at elegosoft.comCC: m3devel at elegosoft.comSubject: RE: Popup Windows stalling regression tests on WinXPDate: Mon, 28 Apr 2008 21:47:35 +0000 Olaf, this is a bug and should be fixed.Like someone calling abort or assert(false) or NtRaiseHardError or dereferencing NULL or such.Or skip those tests on NT386 for now.And please provide an easy way to run specific tests.I'm working on adding some tests (ok, just one) and it seems to be a pain.I think it's just cm3 -FA ../../TESTARGS but it wasn't working.Install the debuggers: http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx I install to c:\bin\x86 and c:\bin\amd64, though the default is c:\program files\blah. mkdir c:\symbols this is just for a local cache, not needed but nice cd c:\bin\x86\windbg -o -G -g -y srv*c:\symbols*http://msdl.microsoft.com/download/symbols cm3 When there is a popup, type: ~*k to get all the thread stacks, and see which one is in MessageBox or abort or whatnot.And send the stack? Or all of them if uncertain.You can also make a full or minidump with .dump for someone else to look at.Good to have the cm3.exe and cm3.pdb as well.Or I guess I can/should just fix them.I think I've seen a few of these myself. The stack might not be well displayed by the debugger.It could be this in the toplevel exception handler/watson thingy. Another thing to try is:c:\bin\x86\windbg -I to install windbg as the JIT debugger. That way, some crashes will bring up a debugger, possibly prompting first. I need to make a web page with a Win32 debugging primer at some point.Anyway, I'll try to bump this up in priority. Could be that SetErrorMode(something) quashes them, but that doesn't mean it isn't a bug.Another very good theory is that the "app type", console vs. gui, is relevant.Console apps upon abort() or assert(false) print something to stdout/stderr and then exit, whereas gui appsuse MessageBox. The type is determined from the .exe, and you can change it at runtime via a call. Not clear to me which of the various catastrophic errors this is though. I think abort(). - Jay > Date: Mon, 28 Apr 2008 18:42:17 +0200> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Popup Windows stalling regression tests on WinXP> > Hi Jay,> > everytime I have a look why the regression tests haven't terminated> yet, I find another popup window with a message like this:> > cm3.exe has encountered a problem and needs to close.> We are sorry for the inconvenience.> > Any idea how to suppress this kind of error notification?> We'll never get reliable regression testing with popup windows :-/> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 dabenavidesd at yahoo.es Tue Apr 29 04:26:43 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 29 Apr 2008 04:26:43 +0200 (CEST) Subject: [M3devel] Popup Windows stalling regression tests on WinXP In-Reply-To: Message-ID: <700233.58102.qm@web27105.mail.ukl.yahoo.com> Hi all: What test(s) it fails? What happens if you append the options the compiler has for building on Win boxes: -console produce a Windows CONSOLE subsystem program -gui produce a Windows GUI subsystem program -windows produce a Windows GUI subsystem program About the options above , does the last two: - gui and -windows have the same meaning? Should the NT386 cm3 compiler build with any of these options? What does the compiler know about this options? That errors should be just understood by the runtime (I think that's the beauty of the SAFE subset of the language), the system (Nt386) M3 runtime doesn't have the capacity to avoid the segment violation, etc of the program before it gets killed by the OS? Thanks Jay escribi?: .hmmessage P { margin:0px; padding:0px } body.hmmessage { FONT-SIZE: 10pt; FONT-FAMILY:Tahoma } truncated and newlines got removed, I wonder if email will ever work.. --------------------------------- From: jayk123 at hotmail.com To: wagner at elegosoft.com CC: m3devel at elegosoft.com Subject: RE: Popup Windows stalling regression tests on WinXP Date: Mon, 28 Apr 2008 21:47:35 +0000 .ExternalClass .EC_hmmessage P {padding:0px;} .ExternalClass body.EC_hmmessage {font-size:10pt;font-family:Tahoma;} Olaf, this is a bug and should be fixed. Like someone calling abort or assert(false) or NtRaiseHardError or dereferencing NULL or such. Or skip those tests on NT386 for now. And please provide an easy way to run specific tests. I'm working on adding some tests (ok, just one) and it seems to be a pain. I think it's just cm3 -FA ../../TESTARGS but it wasn't working. Install the debuggers: http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx I install to c:\bin\x86 and c:\bin\amd64, though the default is c:\program files\blah. mkdir c:\symbols this is just for a local cache, not needed but nice cd c:\bin\x86\windbg -o -G -g -y srv*c:\symbols*http://msdl.microsoft.com/download/symbols cm3 When there is a popup, type: ~*k to get all the thread stacks, and see which one is in MessageBox or abort or whatnot. And send the stack? Or all of them if uncertain. You can also make a full or minidump with .dump for someone else to look at. Good to have the cm3.exe and cm3.pdb as well. Or I guess I can/should just fix them. I think I've seen a few of these myself. The stack might not be well displayed by the debugger. It could be this in the toplevel exception handler/watson thingy. Another thing to try is: c:\bin\x86\windbg -I to install windbg as the JIT debugger. That way, some crashes will bring up a debugger, possibly prompting first. I need to make a web page with a Win32 debugging primer at some point. Anyway, I'll try to bump this up in priority. Could be that SetErrorMode(something) quashes them, but that doesn't mean it isn't a bug. Another very good theory is that the "app type", console vs. gui, is relevant. Console apps upon abort() or assert(false) print something to stdout/stderr and then exit, whereas gui apps use MessageBox. The type is determined from the .exe, and you can change it at runtime via a call. Not clear to me which of the various catastrophic errors this is though. I think abort(). - Jay --------------------------------- > Date: Mon, 28 Apr 2008 18:42:17 +0200 > From: wagner at elegosoft.com > To: jayk123 at hotmail.com > CC: m3devel at elegosoft.com > Subject: Popup Windows stalling regression tests on WinXP > > Hi Jay, > > everytime I have a look why the regression tests haven't terminated > yet, I find another popup window with a message like this: > > cm3.exe has encountered a problem and needs to close. > We are sorry for the inconvenience. > > Any idea how to suppress this kind of error notification? > We'll never get reliable regression testing with popup windows :-/ > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > --------------------------------- Yahoo! Solidario. Intercambia los objetos que ya no necesitas y ayuda a mantener un entorno m?s ecol?gico. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Apr 29 04:36:25 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 29 Apr 2008 02:36:25 +0000 Subject: [M3devel] Popup Windows stalling regression tests on WinXP In-Reply-To: <700233.58102.qm@web27105.mail.ukl.yahoo.com> References: <700233.58102.qm@web27105.mail.ukl.yahoo.com> Message-ID: I'd bet the correct options are already in use. Otherwise functionality would be badly messed up. At least for cm3.exe. MAYBE not the tests. -gui and -windows show the same meaning below. You'd have to read the code. This is an area that needs repair for NT386GNU and NT386MINGNU, but it should be ok for NT386. What the compiler should know about these is how it marks the "system" in the resulting .exe. (It is meaningless for .dlls.) It's just one field in the .exe, via a switch to the linker. Oh, and I guess there is mainCRTStartup vs. WinMainCRTStartup, which drags in different associated data, to inform the C runtime as to your type. However...I'm sure you can mix and match these. A GUI app can start with main, they just don't tend to. main and WinMain have different signatures, but mainCRTStartup and WinMainCRTStartup do not. They both take no parameters and get their data from GetCommandLine, GetStartupInfo, GetEnvironmentVariables, etc. > That errors should be just understood by the runtime Maybe. > the system (Nt386) M3 runtime doesn't have the capacity to > avoid the segment violation, etc of the program before it gets killed by the OS? It probably does. It depends, but maybe. Best just to avoid them if possible. I realize there could be tests that want to deliberately dereference NULL to test the runtime handling.It might be viable to have runtime hooks for testing. Maybe that are only supported in standalone() or something. I'll have to look into it. I have seen errors like this running the tests but I have ignored them before. - Jay Date: Tue, 29 Apr 2008 04:26:43 +0200From: dabenavidesd at yahoo.esSubject: Re: [M3devel] Popup Windows stalling regression tests on WinXPTo: jayk123 at hotmail.com; wagner at elegosoft.comCC: m3devel at elegosoft.comHi all:What test(s) it fails? What happens if you append the options the compiler has for building on Win boxes:-console produce a Windows CONSOLE subsystem program-gui produce a Windows GUI subsystem program-windows produce a Windows GUI subsystem programAbout the options above , does the last two: - gui and -windows have the same meaning? Should the NT386 cm3 compiler build with any of these options? What does the compiler know about this options?That errors should be just understood by the runtime (I think that's the beauty of the SAFE subset of the language), the system (Nt386) M3 runtime doesn't have the capacity to avoid the segment violation, etc of the program before it gets killed by the OS?ThanksJay escribi?: truncated and newlines got removed, I wonder if email will ever work.. From: jayk123 at hotmail.comTo: wagner at elegosoft.comCC: m3devel at elegosoft.comSubject: RE: Popup Windows stalling regression tests on WinXPDate: Mon, 28 Apr 2008 21:47:35 +0000 Olaf, this is a bug and should be fixed.Like someone calling abort or assert(false) or NtRaiseHardError or dereferencing NULL or such.Or skip those tests on NT386 for now.And please provide an easy way to run specific tests.I'm working on adding some tests (ok, just one) and it seems to be a pain.I think it's just cm3 -FA ../../TESTARGS but it wasn't working.Install the debuggers: http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx I install to c:\bin\x86 and c:\bin\amd64, though the default is c:\program files\blah. mkdir c:\symbols this is just for a local cache, not needed but nice cd c:\bin\x86\windbg -o -G -g -y srv*c:\symbols*http://msdl.microsoft.com/download/symbols cm3 When there is a popup, type: ~*k to get all the thread stacks, and see which one is in MessageBox or abort or whatnot.And send the stack? Or all of them if uncertain.You can also make a full or minidump with .dump for someone else to look at.Good to have the cm3.exe and cm3.pdb as well.Or I guess I can/should just fix them.I think I've seen a few of these myself. The stack might not be well displayed by the debugger.It could be this in the toplevel exception handler/watson thingy. Another thing to try is:c:\bin\x86\windbg -I to install windbg as the JIT debugger. That way, some crashes will bring up a debugger, possibly prompting first. I need to make a web page with a Win32 debugging primer at some point.Anyway, I'll try to bump this up in priority. Could be that SetErrorMode(something) quashes them, but that doesn't mean it isn't a bug.Another very good theory is that the "app type", console vs. gui, is relevant.Console apps upon abort() or assert(false) print something to stdout/stderr and then exit, whereas gui appsuse MessageBox. The type is determined from the .exe, and you can change it at runtime via a call. Not clear to me which of the various catastrophic errors this is though. I think abort(). - Jay > Date: Mon, 28 Apr 2008 18:42:17 +0200> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Popup Windows stalling regression tests on WinXP> > Hi Jay,> > everytime I have a look why the regression tests haven't terminated> yet, I find another popup window with a message like this:> > cm3.exe has encountered a problem and needs to close.> We are sorry for the inconvenience.> > Any idea how to suppress this kind of error notification?> We'll never get reliable regression testing with popup windows :-/> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> Yahoo! Solidario.Intercambia los objetos que ya no necesitas y ayuda a mantener un entorno m?s ecol?gico. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Apr 29 13:51:20 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 29 Apr 2008 13:51:20 +0200 Subject: [M3devel] Popup Windows stalling regression tests on WinXP In-Reply-To: References: <20080428184217.dizt8loly8go80gg@mail.elegosoft.com> Message-ID: <20080429135120.m5413443cwo884so@mail.elegosoft.com> Sorry, I currently have neither the time to install debuggers on my slow VM machine nor to chase after such bugs. What I hoped is that there is some system switch that turns off all such popups. If there is not, there may not be much further progress from me for some time. If I start a program like the compiler without any GUI from the command line, I do not expect to get any popup boxes on some unmonitored server machine. It will just not work this way. Even if I found and fixed this special problem now, we'll run into the next one some time later when the tests are hanging again... Olaf PS: As for running only one test with the m3tests makefile, I simply switch off most of the definitions with `if "" ... end' and copy the interesting line just before. Quoting Jay : > Olaf, this is a bug and should be fixed.Like someone calling abort > or assert(false) or NtRaiseHardError or dereferencing NULL or > such.Or skip those tests on NT386 for now.And please provide an easy > way to run specific tests.I'm working on adding some tests (ok, > just one) and it seems to be a pain.I think it's just cm3 -FA > ../../TESTARGS but it wasn't working. > Install the debuggers: > http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx > > I install to c:\bin\x86 and c:\bin\amd64, though the default is > c:\program files\blah. mkdir c:\symbols this is just for a local > cache, not needed but nice > > cd > c:\bin\x86\windbg -o -G -g -y > srv*c:\symbols*http://msdl.microsoft.com/download/symbols cm3 > > When there is a popup, type: > > ~*k > to get all the thread stacks, and see which one is in MessageBox or > abort or whatnot. > And send the stack? Or all of them if uncertain. > You can also make a full or minidump with .dump for someone else to look at. > Good to have the cm3.exe and cm3.pdb as well. > Or I guess I can/should just fix them.I think I've seen a few of > these myself. > > The stack might not be well displayed by the debugger. > It could be this in the toplevel exception handler/watson thingy. > > Another thing to try is: > c:\bin\x86\windbg -I > > to install windbg as the JIT debugger. That way, some crashes will > bring up a debugger, possibly prompting first. > > I need to make a web page with a Win32 debugging primer at some point. > Anyway, I'll try to bump this up in priority. > > Could be that SetErrorMode(something) quashes them, but that doesn't > mean it isn't a bug. > Another very good theory is that the "app type", console vs. gui, is > relevant. > Console apps upon abort() or assert(false) print something to > stdout/stderr and then exit, whereas gui apps > use MessageBox. The type is determined from the .exe, and you can > change it at runtime via a call. > > Not clear to me which of the various catastrophic errors this is > though. I think abort(). > - Jay > > > >> Date: Mon, 28 Apr 2008 18:42:17 +0200> From: wagner at elegosoft.com> >> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Popup >> Windows stalling regression tests on WinXP> > Hi Jay,> > everytime >> I have a look why the regression tests haven't terminated> yet, I >> find another popup window with a message like this:> > cm3.exe has >> encountered a problem and needs to close.> We are sorry for the >> inconvenience.> > Any idea how to suppress this kind of error >> notification?> We'll never get reliable regression testing with >> popup windows :-/> > Olaf> -- > Olaf Wagner -- elego Software >> Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >> Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: >> +49 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 dabenavidesd at yahoo.es Tue Apr 29 14:46:31 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 29 Apr 2008 14:46:31 +0200 (CEST) Subject: [M3devel] Popup Windows stalling regression tests on WinXP In-Reply-To: <20080429135120.m5413443cwo884so@mail.elegosoft.com> Message-ID: <444151.41574.qm@web27109.mail.ukl.yahoo.com> Hi all: Olaf, but in the case is not even the cm3 process, but a sub process of it, maybe the linker or/and the assembler (what VS version do you have?) which in turn throws the fault, how do you know from sure is cm3 only causing that?, Can you check the label of "Click here for more information". Then you can click on see the files involved in the fault. There you should see the list of files like dll or lib and executable involved, can you send that info? Thanks Olaf Wagner wrote: Sorry, I currently have neither the time to install debuggers on my slow VM machine nor to chase after such bugs. What I hoped is that there is some system switch that turns off all such popups. If there is not, there may not be much further progress from me for some time. If I start a program like the compiler without any GUI from the command line, I do not expect to get any popup boxes on some unmonitored server machine. It will just not work this way. Even if I found and fixed this special problem now, we'll run into the next one some time later when the tests are hanging again... Olaf PS: As for running only one test with the m3tests makefile, I simply switch off most of the definitions with `if "" ... end' and copy the interesting line just before. Quoting Jay : > Olaf, this is a bug and should be fixed.Like someone calling abort > or assert(false) or NtRaiseHardError or dereferencing NULL or > such.Or skip those tests on NT386 for now.And please provide an easy > way to run specific tests.I'm working on adding some tests (ok, > just one) and it seems to be a pain.I think it's just cm3 -FA > ../../TESTARGS but it wasn't working. > Install the debuggers: > http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx > > I install to c:\bin\x86 and c:\bin\amd64, though the default is > c:\program files\blah. mkdir c:\symbols this is just for a local > cache, not needed but nice > > cd > c:\bin\x86\windbg -o -G -g -y > srv*c:\symbols*http://msdl.microsoft.com/download/symbols cm3 > > When there is a popup, type: > > ~*k > to get all the thread stacks, and see which one is in MessageBox or > abort or whatnot. > And send the stack? Or all of them if uncertain. > You can also make a full or minidump with .dump for someone else to look at. > Good to have the cm3.exe and cm3.pdb as well. > Or I guess I can/should just fix them.I think I've seen a few of > these myself. > > The stack might not be well displayed by the debugger. > It could be this in the toplevel exception handler/watson thingy. > > Another thing to try is: > c:\bin\x86\windbg -I > > to install windbg as the JIT debugger. That way, some crashes will > bring up a debugger, possibly prompting first. > > I need to make a web page with a Win32 debugging primer at some point. > Anyway, I'll try to bump this up in priority. > > Could be that SetErrorMode(something) quashes them, but that doesn't > mean it isn't a bug. > Another very good theory is that the "app type", console vs. gui, is > relevant. > Console apps upon abort() or assert(false) print something to > stdout/stderr and then exit, whereas gui apps > use MessageBox. The type is determined from the .exe, and you can > change it at runtime via a call. > > Not clear to me which of the various catastrophic errors this is > though. I think abort(). > - Jay > > > >> Date: Mon, 28 Apr 2008 18:42:17 +0200> From: wagner at elegosoft.com> >> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Popup >> Windows stalling regression tests on WinXP> > Hi Jay,> > everytime >> I have a look why the regression tests haven't terminated> yet, I >> find another popup window with a message like this:> > cm3.exe has >> encountered a problem and needs to close.> We are sorry for the >> inconvenience.> > Any idea how to suppress this kind of error >> notification?> We'll never get reliable regression testing with >> popup windows :-/> > Olaf> -- > Olaf Wagner -- elego Software >> Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >> Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: >> +49 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 --------------------------------- Enviado desde Correo Yahoo! La bandeja de entrada m?s inteligente. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Apr 29 16:00:27 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 29 Apr 2008 16:00:27 +0200 Subject: [M3devel] Popup Windows stalling regression tests on WinXP In-Reply-To: <444151.41574.qm@web27109.mail.ukl.yahoo.com> References: <444151.41574.qm@web27109.mail.ukl.yahoo.com> Message-ID: <20080429160027.hp9wb3dhc0g0kkko@mail.elegosoft.com> Quoting "Daniel Alejandro Benavides D." : > Hi all: > Olaf, but in the case is not even the cm3 process, but a sub process > of it, maybe the linker or/and the assembler (what VS version do > you have?) which in turn throws the fault, how do you know from > sure is cm3 only causing that?, Can you check the label of "Click > here for more information". Then you can click on see the files > involved in the fault. There you should see the list of files like > dll or lib and executable involved, can you send that info? I'll restart the tests after some more obvious fixes later this evening and may be able to send more information tomorrow. IIRC there was no label `click here for more information', but just `send report to Microsoft' and `do not send'. Currently we're working hard on a completely different release... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dabenavidesd at yahoo.es Tue Apr 29 16:47:23 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 29 Apr 2008 16:47:23 +0200 (CEST) Subject: [M3devel] Popup Windows stalling regression tests on WinXP In-Reply-To: <20080429160027.hp9wb3dhc0g0kkko@mail.elegosoft.com> Message-ID: <495318.48565.qm@web27105.mail.ukl.yahoo.com> Hi all: Olaf, I don't have the Win box here (just a Kubuntu one). But even if you don't want to send the file, one can see the report file in a window. Should be with two steps: The first click on the blue label "Click here " in the first pop up window. That throws another window with a label that you can click-on and actually see it Well I found with google the instruction to disable that error pop up: http://pcsupport.about.com/od/windowsxp/ht/disableerror.htm I hope this helps to you. Thanks Olaf Wagner escribi?: Quoting "Daniel Alejandro Benavides D." : > Hi all: > Olaf, but in the case is not even the cm3 process, but a sub process > of it, maybe the linker or/and the assembler (what VS version do > you have?) which in turn throws the fault, how do you know from > sure is cm3 only causing that?, Can you check the label of "Click > here for more information". Then you can click on see the files > involved in the fault. There you should see the list of files like > dll or lib and executable involved, can you send that info? I'll restart the tests after some more obvious fixes later this evening and may be able to send more information tomorrow. IIRC there was no label `click here for more information', but just `send report to Microsoft' and `do not send'. Currently we're working hard on a completely different release... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 --------------------------------- Enviado desde Correo Yahoo! La bandeja de entrada m?s inteligente. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Apr 29 17:11:17 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 29 Apr 2008 17:11:17 +0200 Subject: [M3devel] Popup Windows stalling regression tests on WinXP In-Reply-To: <495318.48565.qm@web27105.mail.ukl.yahoo.com> References: <495318.48565.qm@web27105.mail.ukl.yahoo.com> Message-ID: <20080429171117.oopp3fpcpc84ccwk@mail.elegosoft.com> Quoting "Daniel Alejandro Benavides D." : > Hi all: > Olaf, I don't have the Win box here (just a Kubuntu one). But even > if you don't want to send the file, one can see the report file in > a window. Should be with two steps: The first click on the blue > label "Click here " in the first pop up window. That throws another > window with a label that you can click-on and actually see it > Well I found with google the instruction to disable that error pop up: > http://pcsupport.about.com/od/windowsxp/ht/disableerror.htm > I hope this helps to you. Thanks, that sounds good, I'll try it tonight. Olaf > > Thanks > > Olaf Wagner escribi?: Quoting "Daniel > Alejandro Benavides D." : > >> Hi all: >> Olaf, but in the case is not even the cm3 process, but a sub process >> of it, maybe the linker or/and the assembler (what VS version do >> you have?) which in turn throws the fault, how do you know from >> sure is cm3 only causing that?, Can you check the label of "Click >> here for more information". Then you can click on see the files >> involved in the fault. There you should see the list of files like >> dll or lib and executable involved, can you send that info? > > I'll restart the tests after some more obvious fixes later this > evening and may be able to send more information tomorrow. > IIRC there was no label `click here for more information', but > just `send report to Microsoft' and `do not send'. > > Currently we're working hard on a completely different release... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > > > > --------------------------------- > > Enviado desde Correo Yahoo! > La bandeja de entrada m?s inteligente. > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Tue Apr 29 17:52:24 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 29 Apr 2008 11:52:24 -0400 Subject: [M3devel] Your recent change to parse.c Message-ID: I don't understand your change to parse.c re TREE_PUBLIC being set on procedure declarations. TREE_PUBLIC just means that it is possible to call the procedure from outside the current compilation unit. It has nothing to do with intra-library visibility. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Apr 29 23:38:14 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 29 Apr 2008 21:38:14 +0000 Subject: [M3devel] Popup Windows stalling regression tests on WinXP In-Reply-To: <20080429171117.oopp3fpcpc84ccwk@mail.elegosoft.com> References: <495318.48565.qm@web27105.mail.ukl.yahoo.com> <20080429171117.oopp3fpcpc84ccwk@mail.elegosoft.com> Message-ID: Yes, this might be it. My x86 Windows machine is out on loan this week, my AMD64 Windows machine needed a reinstall, and I was deep into debugging the AMD64_LINUX problem (on same machine, multi-boot), so I punted. Now I've reinstalled AMD64 Windows and can debug to see what the problem is, to decide if it is quashable..There should be a way without global changes to the machine, but if that's ok, ok. (If this even it.) - Jay> Date: Tue, 29 Apr 2008 17:11:17 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] Popup Windows stalling regression tests on WinXP> > Quoting "Daniel Alejandro Benavides D." :> > > Hi all:> > Olaf, I don't have the Win box here (just a Kubuntu one). But even > > if you don't want to send the file, one can see the report file in > > a window. Should be with two steps: The first click on the blue > > label "Click here " in the first pop up window. That throws another > > window with a label that you can click-on and actually see it> > Well I found with google the instruction to disable that error pop up:> > http://pcsupport.about.com/od/windowsxp/ht/disableerror.htm> > I hope this helps to you.> > Thanks, that sounds good, I'll try it tonight.> > Olaf> > >> > Thanks> >> > Olaf Wagner escribi?: Quoting "Daniel > > Alejandro Benavides D." :> >> >> Hi all:> >> Olaf, but in the case is not even the cm3 process, but a sub process> >> of it, maybe the linker or/and the assembler (what VS version do> >> you have?) which in turn throws the fault, how do you know from> >> sure is cm3 only causing that?, Can you check the label of "Click> >> here for more information". Then you can click on see the files> >> involved in the fault. There you should see the list of files like> >> dll or lib and executable involved, can you send that info?> >> > I'll restart the tests after some more obvious fixes later this> > evening and may be able to send more information tomorrow.> > IIRC there was no label `click here for more information', but> > just `send report to Microsoft' and `do not send'.> >> > Currently we're working hard on a completely different release...> >> > Olaf> > --> > Olaf Wagner -- elego Software Solutions GmbH> > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> >> >> >> >> > ---------------------------------> >> > Enviado desde Correo Yahoo!> > La bandeja de entrada m?s inteligente.> >> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 jayk123 at hotmail.com Tue Apr 29 23:57:45 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 29 Apr 2008 21:57:45 +0000 Subject: [M3devel] Your recent change to parse.c In-Reply-To: References: Message-ID: Tony, this is a serious problem on AMD64_LINUX.It is not a problem at all on Win32, as Win32 has amuch better codegen model. It's amazing how Linux works.. Look at the .ms file for ThreadPThread.I looked on AMD64_LINUX and LINUXLIBC6. ThreadPThread__InitMutex's call to its own finallyblock goes through the PLT and on AMD64_LINUX the static linkin r10 is trashed. It's possible that if you turn on optimizations, the finallyblock is inlined and that hides the problem, but you can'tcount on that. I was experimenting with another fix at the same time,that of using -fvisibility=hidden on m3cg, butto me that seems more like a C/C++ front end switch,even though cm3cg supports it. I can try again and carefully tweak the two variables,see if -fvisibility=hidden suffices. At the levelcm3cg operates though, it marks the visibility of everythingexplicitly, so again, I think my fix is the way. As well calls within a file to functions within that filethat aren't in an interface are going through the PLT.This is just wasteful. They shouldn't even go through the PLT for calls within thesame "library" (ie: m3core to m3core, libm3 to libm3). What such indirect calls "buy" is that, e.g. the .exe or libm3can replace functions in m3core, or such, and function pointerequality might be achieved. I think the "interposition" featureis widely accepted on Linux, though it is dodgy.I think on Linux going through the PLT for exported functions mightbe the norm. I'll have to read up more. But going through the PLTfor unexported functions is not the norm. Documentation stronglyencourages marking visibility and saving the PLT indirection. In C/C++ there's further problems of name uniquess of unexportedfunctions across the dynamic link. I believe Modula-3 deals with that,since pretty much every function in the system gets a unique name,exported or not. One or the other or both these changes (public = exported,or -fvisibilit=hidden) optimizes those calls. In general going through the PLT is very wasteful whenit isn't necessary. There's a bunch of "literature" aboutthis on the web. On Windows, to call a function Foo, you just call Foo.If Foo ends up imported, the linker generates a single instructionfunction for you, Foo, that jumps through __imp__Foo.If you are absolutely sure Foo will be imported and want tooptimize a little, you can mark Foo as __declspec(dllimport),however for functions this is totally optional. To export functions, you either mark them __declspec(dllexport)or list them in a .def file. For C++, .def files are a pain, butfor C they work just fine, or better. For importing data, you pretty much have to mark it as __declspec(dllimport).Importing data is rare.gcc/ld on Windows have some hack to make this easier that I'm not familiar with. So in the absence of importing data, there is just one codegenmodel that is acceptable -- call Foo.Most function calls, theoretically, are not imported, and thisends up as a normal direct call. There may be issues of position-independence, but on AMD64 thisis not relevant. On AMD64_NT, I believe the vast majority ofcode is naturally position-indendent via RIP-relative addressing.It is true that things like vtables might have relocs.I think that is unfortunate. It would be nice to have 100%position independence for .dlls and .exes. On Linux, if you are compiling for a .dll, you must be position-independent,I think fully, and all function calls by default go through the PLT.Maybe to statics don't. But just sharing across two source files does.Every call is therefore indirect, subject to loader machinations ateither load or first-call time, and "interposable" -- someone elsecan export a function of the same name and take over the function.As well, someone else can call these internal functions more easilythan otherwise. Granted, anyone can call any of your code at any time, justby jumping to it. But symbolic exports are considered more attackablesurface area than random code sitting in memory. If you don't use -fPIC, I think all calls are direct.And you can't link into a .dll. And then, really, the truth is in between.Individual calls can be marked one way or the other. But Modula-3 is marking everything as public, exported, subjectto dynamic linking, called through the PLT. As to why only AMD64_LINUX is seeing this, I don't know.I'd have to check how the static link is passed on others andif the loader preserves it. Could be it is an extra parameteron the stack, since x86 has so few registers. Could be AMD64_LINUX could/should pass it another way, butreally, avoiding the PLT for unexported functions seems likepure goodness. I was quite surprised and dismayed to learn about all this lastnight when I was debugging. Why must inline function bodies for unexported functions be preservedanyway? They are just dead code, right? Is there another way to preserve them? If it is <*inline*> on the implementation but listed in the *.i3 file, that should be public/exported. Is it not? I was able to build LINUXLIBC6 this way as far as building on AMD64 gets, which is pretty far -- eventually failing for lack of some X .libs. Oh, I guess I should be sure optimization is on? I didn't twiddle that. I can try again. - Jay From: hosking at cs.purdue.eduTo: jkrell at elegosoft.comDate: Tue, 29 Apr 2008 11:52:24 -0400CC: m3devel at elegosoft.comSubject: [M3devel] Your recent change to parse.c I don't understand your change to parse.c re TREE_PUBLIC being set on procedure declarations. TREE_PUBLIC just means that it is possible to call the procedure from outside the current compilation unit. It has nothing to do with intra-library visibility. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Apr 30 00:01:51 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 29 Apr 2008 22:01:51 +0000 Subject: [M3devel] Popup Windows stalling regression tests on WinXP In-Reply-To: References: <495318.48565.qm@web27105.mail.ukl.yahoo.com> <20080429171117.oopp3fpcpc84ccwk@mail.elegosoft.com> Message-ID: ps: Olaf, the debugger install is incredibly fast and small. This isn't Visual Studio. I get, but hadn't previously considered, that future regressions would hang the machine, so a fix is only "temporary", but hey...maybe a process needs to monitor the tests and kill them if they take too long? SetErrorMode will probably fix this, now that I think more. We can add a switch to cm3 and it can call that on itself, and it always gets inherited by child processes. Or we can have a trivial wrapper .exe to run the tests, if the switch to cm3 is not liked. But I have to test it out. Suggest an .exe or switch name? :) If indeed it is SetErrorMode, I'd do seterrormode.exe Though this is a low level name. It could be testwrapper.exe or quashpopups.exe. -Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Tue, 29 Apr 2008 21:38:14 +0000Subject: Re: [M3devel] Popup Windows stalling regression tests on WinXP Yes, this might be it.My x86 Windows machine is out on loan this week, my AMD64 Windows machine needed a reinstall, and I was deep into debugging the AMD64_LINUX problem (on same machine, multi-boot), so I punted. Now I've reinstalled AMD64 Windows and can debug to see what the problem is, to decide if it is quashable..There should be a way without global changes to the machine, but if that's ok, ok. (If this even it.) - Jay> Date: Tue, 29 Apr 2008 17:11:17 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] Popup Windows stalling regression tests on WinXP> > Quoting "Daniel Alejandro Benavides D." :> > > Hi all:> > Olaf, I don't have the Win box here (just a Kubuntu one). But even > > if you don't want to send the file, one can see the report file in > > a window. Should be with two steps: The first click on the blue > > label "Click here " in the first pop up window. That throws another > > window with a label that you can click-on and actually see it> > Well I found with google the instruction to disable that error pop up:> > http://pcsupport.about.com/od/windowsxp/ht/disableerror.htm> > I hope this helps to you.> > Thanks, that sounds good, I'll try it tonight.> > Olaf> > >> > Thanks> >> > Olaf Wagner escribi?: Quoting "Daniel > > Alejandro Benavides D." :> >> >> Hi all:> >> Olaf, but in the case is not even the cm3 process, but a sub process> >> of it, maybe the linker or/and the assembler (what VS version do> >> you have?) which in turn throws the fault, how do you know from> >> sure is cm3 only causing that?, Can you check the label of "Click> >> here for more information". Then you can click on see the files> >> involved in the fault. There you should see the list of files like> >> dll or lib and executable involved, can you send that info?> >> > I'll restart the tests after some more obvious fixes later this> > evening and may be able to send more information tomorrow.> > IIRC there was no label `click here for more information', but> > just `send report to Microsoft' and `do not send'.> >> > Currently we're working hard on a completely different release...> >> > Olaf> > --> > Olaf Wagner -- elego Software Solutions GmbH> > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> >> >> >> >> > ---------------------------------> >> > Enviado desde Correo Yahoo!> > La bandeja de entrada m?s inteligente.> >> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 jayk123 at hotmail.com Wed Apr 30 00:28:57 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 29 Apr 2008 22:28:57 +0000 Subject: [M3devel] Your recent change to parse.c In-Reply-To: References: Message-ID: simply: probably: calls to finally blocks must not go through PLT definitely: calls to finally blocks must successfully pass the static link (assuming any locals/parameters are used, and don't bother otherwise); perhaps they just be inlined and not even calls; of course it's a bit more than that, I'd have to try except and actually raising exceptions, but as a start, successful runs of finally blocks need to work, they don't currently on AMD64 due to the call through PLT trashing r10 optionally: calls through PLT should be in general decreased as they are just very wasteful; it's disheartening to realize how it currently is inlines that are declared in an .i3 should be callable from other .m3 files in the same "library" and even exportable and callable outside the .dll/.so - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; jkrell at elegosoft.comDate: Tue, 29 Apr 2008 21:57:45 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] Your recent change to parse.c Tony, this is a serious problem on AMD64_LINUX.It is not a problem at all on Win32, as Win32 has amuch better codegen model. It's amazing how Linux works..Look at the .ms file for ThreadPThread.I looked on AMD64_LINUX and LINUXLIBC6.ThreadPThread__InitMutex's call to its own finallyblock goes through the PLT and on AMD64_LINUX the static linkin r10 is trashed.It's possible that if you turn on optimizations, the finallyblock is inlined and that hides the problem, but you can'tcount on that.I was experimenting with another fix at the same time,that of using -fvisibility=hidden on m3cg, butto me that seems more like a C/C++ front end switch,even though cm3cg supports it.I can try again and carefully tweak the two variables,see if -fvisibility=hidden suffices. At the levelcm3cg operates though, it marks the visibility of everythingexplicitly, so again, I think my fix is the way.As well calls within a file to functions within that filethat aren't in an interface are going through the PLT.This is just wasteful.They shouldn't even go through the PLT for calls within thesame "library" (ie: m3core to m3core, libm3 to libm3).What such indirect calls "buy" is that, e.g. the .exe or libm3can replace functions in m3core, or such, and function pointerequality might be achieved. I think the "interposition" featureis widely accepted on Linux, though it is dodgy.I think on Linux going through the PLT for exported functions mightbe the norm. I'll have to read up more. But going through the PLTfor unexported functions is not the norm. Documentation stronglyencourages marking visibility and saving the PLT indirection.In C/C++ there's further problems of name uniquess of unexportedfunctions across the dynamic link. I believe Modula-3 deals with that,since pretty much every function in the system gets a unique name,exported or not. One or the other or both these changes (public = exported,or -fvisibilit=hidden) optimizes those calls.In general going through the PLT is very wasteful whenit isn't necessary. There's a bunch of "literature" aboutthis on the web.On Windows, to call a function Foo, you just call Foo.If Foo ends up imported, the linker generates a single instructionfunction for you, Foo, that jumps through __imp__Foo.If you are absolutely sure Foo will be imported and want tooptimize a little, you can mark Foo as __declspec(dllimport),however for functions this is totally optional.To export functions, you either mark them __declspec(dllexport)or list them in a .def file. For C++, .def files are a pain, butfor C they work just fine, or better.For importing data, you pretty much have to mark it as __declspec(dllimport).Importing data is rare.gcc/ld on Windows have some hack to make this easier that I'm not familiar with.So in the absence of importing data, there is just one codegenmodel that is acceptable -- call Foo.Most function calls, theoretically, are not imported, and thisends up as a normal direct call.There may be issues of position-independence, but on AMD64 thisis not relevant. On AMD64_NT, I believe the vast majority ofcode is naturally position-indendent via RIP-relative addressing.It is true that things like vtables might have relocs.I think that is unfortunate. It would be nice to have 100%position independence for .dlls and .exes. On Linux, if you are compiling for a .dll, you must be position-independent,I think fully, and all function calls by default go through the PLT.Maybe to statics don't. But just sharing across two source files does.Every call is therefore indirect, subject to loader machinations ateither load or first-call time, and "interposable" -- someone elsecan export a function of the same name and take over the function.As well, someone else can call these internal functions more easilythan otherwise. Granted, anyone can call any of your code at any time, justby jumping to it. But symbolic exports are considered more attackablesurface area than random code sitting in memory.If you don't use -fPIC, I think all calls are direct.And you can't link into a .dll.And then, really, the truth is in between.Individual calls can be marked one way or the other.But Modula-3 is marking everything as public, exported, subjectto dynamic linking, called through the PLT.As to why only AMD64_LINUX is seeing this, I don't know.I'd have to check how the static link is passed on others andif the loader preserves it. Could be it is an extra parameteron the stack, since x86 has so few registers.Could be AMD64_LINUX could/should pass it another way, butreally, avoiding the PLT for unexported functions seems likepure goodness.I was quite surprised and dismayed to learn about all this lastnight when I was debugging.Why must inline function bodies for unexported functions be preservedanyway? They are just dead code, right? Is there another way to preserve them?If it is <*inline*> on the implementation but listed in the *.i3 file, that should be public/exported. Is it not? I was able to build LINUXLIBC6 this way as far as building on AMD64 gets, which is pretty far -- eventually failing for lack of some X .libs.Oh, I guess I should be sure optimization is on? I didn't twiddle that. I can try again. - Jay From: hosking at cs.purdue.eduTo: jkrell at elegosoft.comDate: Tue, 29 Apr 2008 11:52:24 -0400CC: m3devel at elegosoft.comSubject: [M3devel] Your recent change to parse.c I don't understand your change to parse.c re TREE_PUBLIC being set on procedure declarations. TREE_PUBLIC just means that it is possible to call the procedure from outside the current compilation unit. It has nothing to do with intra-library visibility. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Apr 30 00:32:28 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 29 Apr 2008 18:32:28 -0400 Subject: [M3devel] Your recent change to parse.c In-Reply-To: References: Message-ID: <78640E3D-7188-456B-98A1-8450D0F9F419@cs.purdue.edu> Jay, thanks for your explanation! If your log message could have had some of this information I might have understood what the need was. OK, I've gone back through the logs and see that I did not put this in for specific optimization reasons, though it may have had a historic basis in making something work. So, let's restore your fix and see what happens. I wonder if it breaks procedure values (code address + static chain records)? On Apr 29, 2008, at 5:57 PM, Jay wrote: > Tony, this is a serious problem on AMD64_LINUX. > It is not a problem at all on Win32, as Win32 has a > much better codegen model. It's amazing how Linux works.. > > Look at the .ms file for ThreadPThread. > I looked on AMD64_LINUX and LINUXLIBC6. > > ThreadPThread__InitMutex's call to its own finally > block goes through the PLT and on AMD64_LINUX the static link > in r10 is trashed. > > It's possible that if you turn on optimizations, the finally > block is inlined and that hides the problem, but you can't > count on that. > > I was experimenting with another fix at the same time, > that of using -fvisibility=hidden on m3cg, but > to me that seems more like a C/C++ front end switch, > even though cm3cg supports it. > > I can try again and carefully tweak the two variables, > see if -fvisibility=hidden suffices. At the level > cm3cg operates though, it marks the visibility of everything > explicitly, so again, I think my fix is the way. > > As well calls within a file to functions within that file > that aren't in an interface are going through the PLT. > This is just wasteful. > > They shouldn't even go through the PLT for calls within the > same "library" (ie: m3core to m3core, libm3 to libm3). > > What such indirect calls "buy" is that, e.g. the .exe or libm3 > can replace functions in m3core, or such, and function pointer > equality might be achieved. I think the "interposition" feature > is widely accepted on Linux, though it is dodgy. > I think on Linux going through the PLT for exported functions might > be the norm. I'll have to read up more. But going through the PLT > for unexported functions is not the norm. Documentation strongly > encourages marking visibility and saving the PLT indirection. > > In C/C++ there's further problems of name uniquess of unexported > functions across the dynamic link. I believe Modula-3 deals with that, > since pretty much every function in the system gets a unique name, > exported or not. > > One or the other or both these changes (public = exported, > or -fvisibilit=hidden) optimizes those calls. > > In general going through the PLT is very wasteful when > it isn't necessary. There's a bunch of "literature" about > this on the web. > > On Windows, to call a function Foo, you just call Foo. > If Foo ends up imported, the linker generates a single instruction > function for you, Foo, that jumps through __imp__Foo. > If you are absolutely sure Foo will be imported and want to > optimize a little, you can mark Foo as __declspec(dllimport), > however for functions this is totally optional. > To export functions, you either mark them __declspec(dllexport) > or list them in a .def file. For C++, .def files are a pain, but > for C they work just fine, or better. > For importing data, you pretty much have to mark it as > __declspec(dllimport). > Importing data is rare. > gcc/ld on Windows have some hack to make this easier that I'm not > familiar with. > > So in the absence of importing data, there is just one codegen > model that is acceptable -- call Foo. > Most function calls, theoretically, are not imported, and this > ends up as a normal direct call. > There may be issues of position-independence, but on AMD64 this > is not relevant. On AMD64_NT, I believe the vast majority of > code is naturally position-indendent via RIP-relative addressing. > It is true that things like vtables might have relocs. > I think that is unfortunate. It would be nice to have 100% > position independence for .dlls and .exes. > > On Linux, if you are compiling for a .dll, you must be position- > independent, > I think fully, and all function calls by default go through the PLT. > Maybe to statics don't. But just sharing across two source files does. > Every call is therefore indirect, subject to loader machinations at > either load or first-call time, and "interposable" -- someone else > can export a function of the same name and take over the function. > As well, someone else can call these internal functions more easily > than otherwise. Granted, anyone can call any of your code at any > time, just > by jumping to it. But symbolic exports are considered more attackable > surface area than random code sitting in memory. > > If you don't use -fPIC, I think all calls are direct. > And you can't link into a .dll. > > And then, really, the truth is in between. > Individual calls can be marked one way or the other. > > But Modula-3 is marking everything as public, exported, subject > to dynamic linking, called through the PLT. > > As to why only AMD64_LINUX is seeing this, I don't know. > I'd have to check how the static link is passed on others and > if the loader preserves it. Could be it is an extra parameter > on the stack, since x86 has so few registers. > > Could be AMD64_LINUX could/should pass it another way, but > really, avoiding the PLT for unexported functions seems like > pure goodness. > > I was quite surprised and dismayed to learn about all this last > night when I was debugging. > > Why must inline function bodies for unexported functions be preserved > anyway? They are just dead code, right? > Is there another way to preserve them? > If it is <*inline*> on the implementation but listed in the *.i3 > file, that should be public/exported. Is it not? I was able to build > LINUXLIBC6 this way as far as building on AMD64 gets, which is > pretty far -- eventually failing for lack of some X .libs. > Oh, I guess I should be sure optimization is on? I didn't twiddle > that. I can try again. > > - Jay > > From: hosking at cs.purdue.edu > To: jkrell at elegosoft.com > Date: Tue, 29 Apr 2008 11:52:24 -0400 > CC: m3devel at elegosoft.com > Subject: [M3devel] Your recent change to parse.c > > I don't understand your change to parse.c re TREE_PUBLIC being set > on procedure declarations. TREE_PUBLIC just means that it is > possible to call the procedure from outside the current compilation > unit. It has nothing to do with intra-library visibility. > > > 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 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Apr 30 02:19:51 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 30 Apr 2008 00:19:51 +0000 Subject: [M3devel] silenly allowing "WINAPI" on all targets? (wrt Popup Windows stalling regression tests on WinXP) In-Reply-To: References: <495318.48565.qm@web27105.mail.ukl.yahoo.com> <20080429171117.oopp3fpcpc84ccwk@mail.elegosoft.com> Message-ID: I think cm3 can just make this call unconditionally. As long as the crash is bubbled up as a failure that is printed or something. There should also be a public interface for collecting and sending the reports without a prompt. Various command line tools (cl, link) now have switches to control this behavior. I know the crash is not in cm3 but what it runs -- the setting is inherited by child processes. So, I have a function that exists and I want to call on Win32, and doesn't exist anywhere else, in which case I want to do nothing. In my opinion, a good way to do this is: something.i3 <* extern WINAPI *> PROCEDURE SetErrorMode(UINT32); I wouldn't mind a way to write this in Modula-3, but the naming is in the way. common/something.c void SetErrorMode(UINT32 a) { /* do nothing */ } and only compile something.c on non-Win32. This raises some issues, that I have raised before. I think WINAPI should be silently ignored for all but NT386. It's a small change. It lets this kind of thing work. I know there are other ideas, like <* extern NT386:WINAPI LINUXLIBC:FOOAPI *> or <* extern SYSAPI *> but really I think what I propose is sufficient (and simplest). I doubt that a generalization or renaming has any point. In fact I'd argue for removing all the synonyms and supporting just __stdcall, __cdecl, __fastcall, and __thiscall, possibly as STDCALL, CDECL, FASTCALL, THISCALL, since Modula-3 doesn't like identifiers to start with underscore, and the last two are optional. As I said/implied before, having multiple calling conventions on one target is a terrible idea and I don't expect it to occur again, not at this level at least. I know, for example, you could describe the Linux kernel as exposing two calling conventions, depending on if there is a "small" or "large" number of parameters, but really, even neither of these two are the "normal" convention and such things always get wrapped up in a little wrapper with the "standard" calling convention of the platform (except on NT386, sort of, where the wrapper is one of a few conventions). Precedent is that calling conventions are allowed in source for other Windows platforms, but are ignored. They might be #defined away sometimes, but I bet the compiler ignores them. This provides better source compatibility. As x86 gradually goes away, people will stop putting these things in. I guess the alternative to my proposal is an extra level of wrapping behind some made up "portable" interface: something.i3: PROCEDURE SetErrorMode(UINT32); win32/something.m3 PROCEDURE SetErrorMode(UINT32 a) = BEGIN WinBase.SetErrorMode(a); END SetErrorMode; posix/something.m3 PROCEDURE SetErrorMode(UINT32 <* unused *> a) = BEGIN (* do nothing *); END SetErrorMode; The alternative does have more flexibility, obviously, if the Posix implementation is anything other than "do nothing", such as even having to return a value, which might be the case here, then it'd go this way. Also this saves there from being a .c file. Is that sleazy to use the same function name in two modules? I know Modula-3 prepends module names always. It seems like a feature more than a bug. Anyway, as before, a gain here would be to reduce the doubled up odbc and maybe opengl .i3 files, which vary only in calling convention. - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comSubject: RE: [M3devel] Popup Windows stalling regression tests on WinXPDate: Tue, 29 Apr 2008 22:01:51 +0000 ps: Olaf, the debugger install is incredibly fast and small.This isn't Visual Studio.I get, but hadn't previously considered, that future regressions would hang the machine, so a fix is only "temporary", but hey...maybe a process needs to monitor the tests and kill them if they take too long? SetErrorMode will probably fix this, now that I think more.We can add a switch to cm3 and it can call that on itself, and it always gets inherited by child processes. Or we can have a trivial wrapper .exe to run the tests, if the switch to cm3 is not liked. But I have to test it out.Suggest an .exe or switch name? :)If indeed it is SetErrorMode, I'd doseterrormode.exe Though this is a low level name.It could be testwrapper.exe or quashpopups.exe. -Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Tue, 29 Apr 2008 21:38:14 +0000Subject: Re: [M3devel] Popup Windows stalling regression tests on WinXP Yes, this might be it.My x86 Windows machine is out on loan this week, my AMD64 Windows machine needed a reinstall, and I was deep into debugging the AMD64_LINUX problem (on same machine, multi-boot), so I punted. Now I've reinstalled AMD64 Windows and can debug to see what the problem is, to decide if it is quashable..There should be a way without global changes to the machine, but if that's ok, ok. (If this even it.) - Jay> Date: Tue, 29 Apr 2008 17:11:17 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] Popup Windows stalling regression tests on WinXP> > Quoting "Daniel Alejandro Benavides D." :> > > Hi all:> > Olaf, I don't have the Win box here (just a Kubuntu one). But even > > if you don't want to send the file, one can see the report file in > > a window. Should be with two steps: The first click on the blue > > label "Click here " in the first pop up window. That throws another > > window with a label that you can click-on and actually see it> > Well I found with google the instruction to disable that error pop up:> > http://pcsupport.about.com/od/windowsxp/ht/disableerror.htm> > I hope this helps to you.> > Thanks, that sounds good, I'll try it tonight.> > Olaf> > >> > Thanks> >> > Olaf Wagner escribi?: Quoting "Daniel > > Alejandro Benavides D." :> >> >> Hi all:> >> Olaf, but in the case is not even the cm3 process, but a sub process> >> of it, maybe the linker or/and the assembler (what VS version do> >> you have?) which in turn throws the fault, how do you know from> >> sure is cm3 only causing that?, Can you check the label of "Click> >> here for more information". Then you can click on see the files> >> involved in the fault. There you should see the list of files like> >> dll or lib and executable involved, can you send that info?> >> > I'll restart the tests after some more obvious fixes later this> > evening and may be able to send more information tomorrow.> > IIRC there was no label `click here for more information', but> > just `send report to Microsoft' and `do not send'.> >> > Currently we're working hard on a completely different release...> >> > Olaf> > --> > Olaf Wagner -- elego Software Solutions GmbH> > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> >> >> >> >> > ---------------------------------> >> > Enviado desde Correo Yahoo!> > La bandeja de entrada m?s inteligente.> >> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 jayk123 at hotmail.com Wed Apr 30 05:25:01 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 30 Apr 2008 03:25:01 +0000 Subject: [M3devel] Your recent change to parse.c In-Reply-To: <78640E3D-7188-456B-98A1-8450D0F9F419@cs.purdue.edu> References: <78640E3D-7188-456B-98A1-8450D0F9F419@cs.purdue.edu> Message-ID: Tony, another thing to try here is: TREE_PUBLIC (p) = (lev == 0); I should have noticed that, and can't confirm right now if itis what I think -- nested procedures and finally/except blocksI assume are (lev > 0). I still think calls through the PLT should be drastically reducedand hope to look into this further. In particular, calls that are known to resolve in the same .soneed not be through the PLT, at least on AMD64. I have to check others. There is a paper dsohowto.pdf that talks about this stuff. So it's not just me. I need to read it more closely but I think it resolves to simply that the front end does know what is in the same .so and can pass the information on to cm3cg. - Jay CC: jkrell at elegosoft.com; m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] Your recent change to parse.cDate: Tue, 29 Apr 2008 18:32:28 -0400 Jay, thanks for your explanation! If your log message could have had some of this information I might have understood what the need was. OK, I've gone back through the logs and see that I did not put this in for specific optimization reasons, though it may have had a historic basis in making something work. So, let's restore your fix and see what happens. I wonder if it breaks procedure values (code address + static chain records)? On Apr 29, 2008, at 5:57 PM, Jay wrote: Tony, this is a serious problem on AMD64_LINUX.It is not a problem at all on Win32, as Win32 has amuch better codegen model. It's amazing how Linux works..Look at the .ms file for ThreadPThread.I looked on AMD64_LINUX and LINUXLIBC6.ThreadPThread__InitMutex's call to its own finallyblock goes through the PLT and on AMD64_LINUX the static linkin r10 is trashed.It's possible that if you turn on optimizations, the finallyblock is inlined and that hides the problem, but you can'tcount on that.I was experimenting with another fix at the same time,that of using -fvisibility=hidden on m3cg, butto me that seems more like a C/C++ front end switch,even though cm3cg supports it.I can try again and carefully tweak the two variables,see if -fvisibility=hidden suffices. At the levelcm3cg operates though, it marks the visibility of everythingexplicitly, so again, I think my fix is the way.As well calls within a file to functions within that filethat aren't in an interface are going through the PLT.This is just wasteful.They shouldn't even go through the PLT for calls within thesame "library" (ie: m3core to m3core, libm3 to libm3).What such indirect calls "buy" is that, e.g. the .exe or libm3can replace functions in m3core, or such, and function pointerequality might be achieved. I think the "interposition" featureis widely accepted on Linux, though it is dodgy.I think on Linux going through the PLT for exported functions mightbe the norm. I'll have to read up more. But going through the PLTfor unexported functions is not the norm. Documentation stronglyencourages marking visibility and saving the PLT indirection.In C/C++ there's further problems of name uniquess of unexportedfunctions across the dynamic link. I believe Modula-3 deals with that,since pretty much every function in the system gets a unique name,exported or not. One or the other or both these changes (public = exported,or -fvisibilit=hidden) optimizes those calls.In general going through the PLT is very wasteful whenit isn't necessary. There's a bunch of "literature" aboutthis on the web.On Windows, to call a function Foo, you just call Foo.If Foo ends up imported, the linker generates a single instructionfunction for you, Foo, that jumps through __imp__Foo.If you are absolutely sure Foo will be imported and want tooptimize a little, you can mark Foo as __declspec(dllimport),however for functions this is totally optional.To export functions, you either mark them __declspec(dllexport)or list them in a .def file. For C++, .def files are a pain, butfor C they work just fine, or better.For importing data, you pretty much have to mark it as __declspec(dllimport).Importing data is rare.gcc/ld on Windows have some hack to make this easier that I'm not familiar with.So in the absence of importing data, there is just one codegenmodel that is acceptable -- call Foo.Most function calls, theoretically, are not imported, and thisends up as a normal direct call.There may be issues of position-independence, but on AMD64 thisis not relevant. On AMD64_NT, I believe the vast majority ofcode is naturally position-indendent via RIP-relative addressing.It is true that things like vtables might have relocs.I think that is unfortunate. It would be nice to have 100%position independence for .dlls and .exes. On Linux, if you are compiling for a .dll, you must be position-independent,I think fully, and all function calls by default go through the PLT.Maybe to statics don't. But just sharing across two source files does.Every call is therefore indirect, subject to loader machinations ateither load or first-call time, and "interposable" -- someone elsecan export a function of the same name and take over the function.As well, someone else can call these internal functions more easilythan otherwise. Granted, anyone can call any of your code at any time, justby jumping to it. But symbolic exports are considered more attackablesurface area than random code sitting in memory.If you don't use -fPIC, I think all calls are direct.And you can't link into a .dll.And then, really, the truth is in between.Individual calls can be marked one way or the other.But Modula-3 is marking everything as public, exported, subjectto dynamic linking, called through the PLT.As to why only AMD64_LINUX is seeing this, I don't know.I'd have to check how the static link is passed on others andif the loader preserves it. Could be it is an extra parameteron the stack, since x86 has so few registers.Could be AMD64_LINUX could/should pass it another way, butreally, avoiding the PLT for unexported functions seems likepure goodness.I was quite surprised and dismayed to learn about all this lastnight when I was debugging.Why must inline function bodies for unexported functions be preservedanyway? They are just dead code, right? Is there another way to preserve them?If it is <*inline*> on the implementation but listed in the *.i3 file, that should be public/exported. Is it not? I was able to build LINUXLIBC6 this way as far as building on AMD64 gets, which is pretty far -- eventually failing for lack of some X .libs.Oh, I guess I should be sure optimization is on? I didn't twiddle that. I can try again. - Jay From: hosking at cs.purdue.eduTo: jkrell at elegosoft.comDate: Tue, 29 Apr 2008 11:52:24 -0400CC: m3devel at elegosoft.comSubject: [M3devel] Your recent change to parse.c I don't understand your change to parse.c re TREE_PUBLIC being set on procedure declarations. TREE_PUBLIC just means that it is possible to call the procedure from outside the current compilation unit. It has nothing to do with intra-library visibility. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Apr 30 08:00:23 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 30 Apr 2008 08:00:23 +0200 Subject: [M3devel] Popup Windows stalling regression tests on WinXP In-Reply-To: <495318.48565.qm@web27105.mail.ukl.yahoo.com> References: <495318.48565.qm@web27105.mail.ukl.yahoo.com> Message-ID: <20080430080023.egxncs5vk4sk0skg@mail.elegosoft.com> This is the only information I can copy&paste into this mail: AppName: cm3.exe AppVer: 0.0.0.0 ModName: ntdll.dll ModVer: 5.1.2600.2180 Offset: 00001230 There is a lot more, but I cannot copy it now (many pages), and copy&paste does not work :-( I'll attach the binary file that the system wants to send to Microsoft in case somebody can decode that. The error occurs reproduciably in test p204. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb??ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 -------------- ??<?xml version="1.0" encoding="UTF-16"?> <DATABASE> <EXE NAME="cm3.exe" FILTER="GRABMI_FILTER_PRIVACY"> <MATCHING_FILE NAME="anim3D.dll" SIZE="480768" CHECKSUM="0x823BB10C" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:48:19" UPTO_LINK_DATE="04/08/2008 00:48:19" /> <MATCHING_FILE NAME="arithmetic.dll" SIZE="1219072" CHECKSUM="0x91EC1B94" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:42:26" UPTO_LINK_DATE="04/07/2008 07:42:26" /> <MATCHING_FILE NAME="binIO.dll" SIZE="10240" CHECKSUM="0xAEC61462" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:51:00" UPTO_LINK_DATE="04/07/2008 07:51:00" /> <MATCHING_FILE NAME="BitVector.dll" SIZE="29184" CHECKSUM="0xF72FA5FB" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:13:22" UPTO_LINK_DATE="04/07/2008 07:13:22" /> <MATCHING_FILE NAME="Calculator.exe" SIZE="13312" CHECKSUM="0x33E2EBD2" MODULE_TYPE="WIN32" PE_CHECKSUM="0xCC73" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:07:16" UPTO_LINK_DATE="04/08/2008 01:07:16" /> <MATCHING_FILE NAME="cit_common.dll" SIZE="8704" CHECKSUM="0xBD445A42" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:11:43" UPTO_LINK_DATE="04/08/2008 01:11:43" /> <MATCHING_FILE NAME="cit_util.dll" SIZE="71680" CHECKSUM="0x7EC274E4" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:12:48" UPTO_LINK_DATE="04/08/2008 01:12:48" /> <MATCHING_FILE NAME="cm3-d5.5.0.exe" SIZE="2465792" CHECKSUM="0x262627D" MODULE_TYPE="WIN32" PE_CHECKSUM="0x25BD65" LINKER_VERSION="0x0" LINK_DATE="12/18/2007 13:38:27" UPTO_LINK_DATE="12/18/2007 13:38:27" /> <MATCHING_FILE NAME="cm3-d5.7.0.exe" SIZE="2610176" CHECKSUM="0x4626C839" MODULE_TYPE="WIN32" PE_CHECKSUM="0x2852D5" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:11:03" UPTO_LINK_DATE="04/07/2008 07:11:03" /> <MATCHING_FILE NAME="cm3.exe" SIZE="2610176" CHECKSUM="0x4626C839" MODULE_TYPE="WIN32" PE_CHECKSUM="0x2852D5" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:11:03" UPTO_LINK_DATE="04/07/2008 07:11:03" /> <MATCHING_FILE NAME="cmpdir.exe" SIZE="419840" CHECKSUM="0x2EF852E6" MODULE_TYPE="WIN32" PE_CHECKSUM="0x6F5C9" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:57:15" UPTO_LINK_DATE="04/07/2008 07:57:15" /> <MATCHING_FILE NAME="cmvbt.dll" SIZE="75264" CHECKSUM="0x635777BC" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:43:24" UPTO_LINK_DATE="04/08/2008 00:43:24" /> <MATCHING_FILE NAME="commandrw.dll" SIZE="7680" CHECKSUM="0x9DC9781E" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:51:33" UPTO_LINK_DATE="04/07/2008 07:51:33" /> <MATCHING_FILE NAME="Cube.exe" SIZE="46080" CHECKSUM="0xD7ABA671" MODULE_TYPE="WIN32" PE_CHECKSUM="0x130C9" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:06:49" UPTO_LINK_DATE="04/08/2008 01:06:49" /> <MATCHING_FILE NAME="db.dll" SIZE="35840" CHECKSUM="0x1EFF81F3" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:38:55" UPTO_LINK_DATE="04/08/2008 00:38:55" /> <MATCHING_FILE NAME="debug.dll" SIZE="6656" CHECKSUM="0xF04EFA2E" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:48:50" UPTO_LINK_DATE="04/07/2008 07:48:50" /> <MATCHING_FILE NAME="deepcopy.dll" SIZE="7680" CHECKSUM="0xAADDF510" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:13:35" UPTO_LINK_DATE="04/08/2008 01:13:35" /> <MATCHING_FILE NAME="DiGraph.dll" SIZE="5632" CHECKSUM="0x5C4C3FA0" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:13:35" UPTO_LINK_DATE="04/07/2008 07:13:35" /> <MATCHING_FILE NAME="dirfp.exe" SIZE="413184" CHECKSUM="0x64276DAC" MODULE_TYPE="WIN32" PE_CHECKSUM="0x6E347" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:58:14" UPTO_LINK_DATE="04/07/2008 07:58:14" /> <MATCHING_FILE NAME="drawcontext.dll" SIZE="80896" CHECKSUM="0x1A411D15" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:14:33" UPTO_LINK_DATE="04/08/2008 01:14:33" /> <MATCHING_FILE NAME="embutils.dll" SIZE="3584" CHECKSUM="0xF9483DB8" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:49:39" UPTO_LINK_DATE="04/07/2008 07:49:39" /> <MATCHING_FILE NAME="events.dll" SIZE="150528" CHECKSUM="0xB2FF58BF" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:35:28" UPTO_LINK_DATE="04/08/2008 00:35:28" /> <MATCHING_FILE NAME="ext.exe" SIZE="660992" CHECKSUM="0xE037ACC0" MODULE_TYPE="WIN32" PE_CHECKSUM="0xA1D01" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:18:47" UPTO_LINK_DATE="04/08/2008 01:18:47" /> <MATCHING_FILE NAME="fisheye.exe" SIZE="309248" CHECKSUM="0x14677CD5" MODULE_TYPE="WIN32" PE_CHECKSUM="0x539B1" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:07:46" UPTO_LINK_DATE="04/08/2008 01:07:46" /> <MATCHING_FILE NAME="fix_nl.exe" SIZE="416256" CHECKSUM="0x1CA96408" MODULE_TYPE="WIN32" PE_CHECKSUM="0x73894" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:12:51" UPTO_LINK_DATE="04/07/2008 07:12:51" /> <MATCHING_FILE NAME="formsedit.exe" SIZE="95232" CHECKSUM="0x9557EA01" MODULE_TYPE="WIN32" PE_CHECKSUM="0x27173" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:46:02" UPTO_LINK_DATE="04/08/2008 00:46:02" /> <MATCHING_FILE NAME="Geometry.dll" SIZE="49664" CHECKSUM="0x6898BD6D" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:14:00" UPTO_LINK_DATE="04/07/2008 07:14:00" /> <MATCHING_FILE NAME="http.dll" SIZE="175104" CHECKSUM="0x8E6BC41A" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:50:33" UPTO_LINK_DATE="04/07/2008 07:50:33" /> <MATCHING_FILE NAME="juno-compiler.dll" SIZE="365056" CHECKSUM="0xAAAC820F" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:05:24" UPTO_LINK_DATE="04/08/2008 01:05:24" /> <MATCHING_FILE NAME="juno-machine.dll" SIZE="175104" CHECKSUM="0xF1339677" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:04:48" UPTO_LINK_DATE="04/08/2008 01:04:48" /> <MATCHING_FILE NAME="Juno.exe" SIZE="769024" CHECKSUM="0xEADA1C8A" MODULE_TYPE="WIN32" PE_CHECKSUM="0xBEA28" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:06:10" UPTO_LINK_DATE="04/08/2008 01:06:10" /> <MATCHING_FILE NAME="jvideo.dll" SIZE="3072" CHECKSUM="0x25A85F31" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:43:46" UPTO_LINK_DATE="04/08/2008 00:43:46" /> <MATCHING_FILE NAME="klexlib.dll" SIZE="79360" CHECKSUM="0xEDD959F" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:16:56" UPTO_LINK_DATE="04/08/2008 01:16:56" /> <MATCHING_FILE NAME="ktoklib.dll" SIZE="57856" CHECKSUM="0x60EB40FE" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:16:20" UPTO_LINK_DATE="04/08/2008 01:16:20" /> <MATCHING_FILE NAME="kyacclib.dll" SIZE="52224" CHECKSUM="0x4DF59544" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:17:23" UPTO_LINK_DATE="04/08/2008 01:17:23" /> <MATCHING_FILE NAME="libbuf.dll" SIZE="10752" CHECKSUM="0xE225AC88" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:48:27" UPTO_LINK_DATE="04/07/2008 07:48:27" /> <MATCHING_FILE NAME="libsio.dll" SIZE="10240" CHECKSUM="0x402B9346" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:48:04" UPTO_LINK_DATE="04/07/2008 07:48:04" /> <MATCHING_FILE NAME="listfuncs.dll" SIZE="15872" CHECKSUM="0x82D3DC0C" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:49:15" UPTO_LINK_DATE="04/07/2008 07:49:15" /> <MATCHING_FILE NAME="m3.dll" SIZE="900608" CHECKSUM="0xCC3412E7" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:06:55" UPTO_LINK_DATE="04/07/2008 07:06:55" /> <MATCHING_FILE NAME="m3browser.exe" SIZE="108032" CHECKSUM="0x2175DA6F" MODULE_TYPE="WIN32" PE_CHECKSUM="0x22355" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:56:47" UPTO_LINK_DATE="04/07/2008 07:56:47" /> <MATCHING_FILE NAME="m3browserhack.exe" SIZE="10240" CHECKSUM="0x981D39D9" MODULE_TYPE="WIN32" PE_CHECKSUM="0x84D8" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:15:53" UPTO_LINK_DATE="04/08/2008 01:15:53" /> <MATCHING_FILE NAME="m3bundle.exe" SIZE="419328" CHECKSUM="0xE00DA5B9" MODULE_TYPE="WIN32" PE_CHECKSUM="0x6FA98" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:12:21" UPTO_LINK_DATE="04/07/2008 07:12:21" /> <MATCHING_FILE NAME="m3codeview.dll" SIZE="48128" CHECKSUM="0xEC827D5C" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:46:28" UPTO_LINK_DATE="04/08/2008 00:46:28" /> <MATCHING_FILE NAME="m3core.dll" SIZE="453120" CHECKSUM="0xFE42B480" MODULE_TYPE="WIN32" PE_CHECKSUM="0x7DC99" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:05:45" UPTO_LINK_DATE="04/07/2008 07:05:45" /> <MATCHING_FILE NAME="m3formsvbt.dll" SIZE="321536" CHECKSUM="0x74283C1A" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:45:16" UPTO_LINK_DATE="04/08/2008 00:45:16" /> <MATCHING_FILE NAME="m3formsvbtpixmaps.dll" SIZE="41984" CHECKSUM="0xD32CC0F2" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:44:50" UPTO_LINK_DATE="04/08/2008 00:44:50" /> <MATCHING_FILE NAME="m3markup.dll" SIZE="61952" CHECKSUM="0x275E2179" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:56:25" UPTO_LINK_DATE="04/07/2008 07:56:25" /> <MATCHING_FILE NAME="m3mg.dll" SIZE="150016" CHECKSUM="0x933B256B" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:46:53" UPTO_LINK_DATE="04/08/2008 00:46:53" /> <MATCHING_FILE NAME="m3mgkit.dll" SIZE="258048" CHECKSUM="0x8E793FF" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:47:21" UPTO_LINK_DATE="04/08/2008 00:47:21" /> <MATCHING_FILE NAME="m3netobj.dll" SIZE="163328" CHECKSUM="0xF3EEB081" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:33:33" UPTO_LINK_DATE="04/08/2008 00:33:33" /> <MATCHING_FILE NAME="m3parseparams.dll" SIZE="12800" CHECKSUM="0x5679B98A" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:13:47" UPTO_LINK_DATE="04/07/2008 07:13:47" /> <MATCHING_FILE NAME="m3scan.dll" SIZE="26624" CHECKSUM="0x4B4C853" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:55:59" UPTO_LINK_DATE="04/07/2008 07:55:59" /> <MATCHING_FILE NAME="m3slisp.dll" SIZE="75776" CHECKSUM="0xA6274123" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:14:30" UPTO_LINK_DATE="04/07/2008 07:14:30" /> <MATCHING_FILE NAME="m3smalldb.dll" SIZE="18944" CHECKSUM="0xFBFCFF44" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:39:33" UPTO_LINK_DATE="04/08/2008 00:39:33" /> <MATCHING_FILE NAME="m3tcp.dll" SIZE="40448" CHECKSUM="0x2CDEA533" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:47:24" UPTO_LINK_DATE="04/07/2008 07:47:24" /> <MATCHING_FILE NAME="m3tk-misc.dll" SIZE="60928" CHECKSUM="0x5AFD1714" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:50:06" UPTO_LINK_DATE="04/07/2008 07:50:06" /> <MATCHING_FILE NAME="m3tk.dll" SIZE="1691648" CHECKSUM="0x499FCE79" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:53:43" UPTO_LINK_DATE="04/07/2008 07:53:43" /> <MATCHING_FILE NAME="m3tmplhack.exe" SIZE="463872" CHECKSUM="0x59869FAE" MODULE_TYPE="WIN32" PE_CHECKSUM="0x7DC69" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:12:11" UPTO_LINK_DATE="04/08/2008 01:12:11" /> <MATCHING_FILE NAME="m3tohtml.exe" SIZE="680448" CHECKSUM="0xE7446678" MODULE_TYPE="WIN32" PE_CHECKSUM="0xA6717" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:55:26" UPTO_LINK_DATE="04/07/2008 07:55:26" /> <MATCHING_FILE NAME="m3totex.exe" SIZE="22528" CHECKSUM="0x913128DB" MODULE_TYPE="WIN32" PE_CHECKSUM="0x789E" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:55:00" UPTO_LINK_DATE="04/07/2008 07:55:00" /> <MATCHING_FILE NAME="m3ui.dll" SIZE="690688" CHECKSUM="0xC8B3CE03" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:41:35" UPTO_LINK_DATE="04/08/2008 00:41:35" /> <MATCHING_FILE NAME="m3unit-numeric.dll" SIZE="6656" CHECKSUM="0x8ED35521" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:43:48" UPTO_LINK_DATE="04/07/2008 07:43:48" /> <MATCHING_FILE NAME="m3unit.dll" SIZE="11776" CHECKSUM="0x5A90BF01" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:08:06" UPTO_LINK_DATE="04/07/2008 07:08:06" /> <MATCHING_FILE NAME="m3vbtkit.dll" SIZE="803328" CHECKSUM="0xF78DE500" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:42:45" UPTO_LINK_DATE="04/08/2008 00:42:45" /> <MATCHING_FILE NAME="m3zeus.dll" SIZE="193536" CHECKSUM="0x66C70909" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:48:59" UPTO_LINK_DATE="04/08/2008 00:48:59" /> <MATCHING_FILE NAME="m3zume.exe" SIZE="98816" CHECKSUM="0x818FF503" MODULE_TYPE="WIN32" PE_CHECKSUM="0x220C1" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:49:25" UPTO_LINK_DATE="04/08/2008 00:49:25" /> <MATCHING_FILE NAME="mentor.exe" SIZE="2422784" CHECKSUM="0x894619CE" MODULE_TYPE="WIN32" PE_CHECKSUM="0x251B4E" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:10:20" UPTO_LINK_DATE="04/08/2008 01:10:20" /> <MATCHING_FILE NAME="metasyn.dll" SIZE="60416" CHECKSUM="0x5468CC37" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:50:33" UPTO_LINK_DATE="04/08/2008 00:50:33" /> <MATCHING_FILE NAME="mklib.exe" SIZE="469504" CHECKSUM="0xB73A8C0D" MODULE_TYPE="WIN32" PE_CHECKSUM="0x7A22B" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:12:35" UPTO_LINK_DATE="04/07/2008 07:12:35" /> <MATCHING_FILE NAME="netobjd.exe" SIZE="740352" CHECKSUM="0xB9498D42" MODULE_TYPE="WIN32" PE_CHECKSUM="0xB84DF" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:33:57" UPTO_LINK_DATE="04/08/2008 00:33:57" /> <MATCHING_FILE NAME="obliq-anim.exe" SIZE="8192" CHECKSUM="0xA7016EDE" MODULE_TYPE="WIN32" PE_CHECKSUM="0x49B1" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:57:23" UPTO_LINK_DATE="04/08/2008 00:57:23" /> <MATCHING_FILE NAME="obliq-min.exe" SIZE="7168" CHECKSUM="0xE52FCFC9" MODULE_TYPE="WIN32" PE_CHECKSUM="0xB6EF" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:55:54" UPTO_LINK_DATE="04/08/2008 00:55:54" /> <MATCHING_FILE NAME="obliq-std.exe" SIZE="1801728" CHECKSUM="0x58C1C1A5" MODULE_TYPE="WIN32" PE_CHECKSUM="0x1BD08F" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:56:18" UPTO_LINK_DATE="04/08/2008 00:56:18" /> <MATCHING_FILE NAME="obliq-ui.exe" SIZE="8192" CHECKSUM="0xD3965549" MODULE_TYPE="WIN32" PE_CHECKSUM="0x636F" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:56:49" UPTO_LINK_DATE="04/08/2008 00:56:49" /> <MATCHING_FILE NAME="obliq.dll" SIZE="97280" CHECKSUM="0xB788243" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:52:59" UPTO_LINK_DATE="04/08/2008 00:52:59" /> <MATCHING_FILE NAME="obliqlib3D.dll" SIZE="558592" CHECKSUM="0x467E1BA3" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:58:23" UPTO_LINK_DATE="04/08/2008 00:58:23" /> <MATCHING_FILE NAME="obliqlibanim.dll" SIZE="115712" CHECKSUM="0x8F8DA488" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:54:49" UPTO_LINK_DATE="04/08/2008 00:54:49" /> <MATCHING_FILE NAME="obliqlibemb.dll" SIZE="43008" CHECKSUM="0xE3A39039" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:53:39" UPTO_LINK_DATE="04/08/2008 00:53:39" /> <MATCHING_FILE NAME="obliqlibm3.dll" SIZE="68608" CHECKSUM="0x9F00F489" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:54:03" UPTO_LINK_DATE="04/08/2008 00:54:03" /> <MATCHING_FILE NAME="obliqlibui.dll" SIZE="86528" CHECKSUM="0xE452A083" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:54:27" UPTO_LINK_DATE="04/08/2008 00:54:27" /> <MATCHING_FILE NAME="obliqparse.dll" SIZE="109568" CHECKSUM="0x119B3185" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:51:58" UPTO_LINK_DATE="04/08/2008 00:51:58" /> <MATCHING_FILE NAME="obliqprint.dll" SIZE="55296" CHECKSUM="0xCACF7E42" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:52:22" UPTO_LINK_DATE="04/08/2008 00:52:22" /> <MATCHING_FILE NAME="obliqrt.dll" SIZE="399872" CHECKSUM="0x1E58E57D" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:51:20" UPTO_LINK_DATE="04/08/2008 00:51:20" /> <MATCHING_FILE NAME="obliqsrv-std.exe" SIZE="8704" CHECKSUM="0x46689203" MODULE_TYPE="WIN32" PE_CHECKSUM="0xFDDC" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:55:08" UPTO_LINK_DATE="04/08/2008 00:55:08" /> <MATCHING_FILE NAME="obliqsrv-ui.exe" SIZE="8704" CHECKSUM="0xB1EE543D" MODULE_TYPE="WIN32" PE_CHECKSUM="0xF242" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:55:31" UPTO_LINK_DATE="04/08/2008 00:55:31" /> <MATCHING_FILE NAME="odbc.dll" SIZE="4096" CHECKSUM="0xF8BE9A14" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:37:54" UPTO_LINK_DATE="04/08/2008 00:37:54" /> <MATCHING_FILE NAME="opengl.dll" SIZE="3584" CHECKSUM="0xB2C33385" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:47:44" UPTO_LINK_DATE="04/08/2008 00:47:44" /> <MATCHING_FILE NAME="parserlib.dll" SIZE="12800" CHECKSUM="0x5502B841" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:19:18" UPTO_LINK_DATE="04/08/2008 01:19:18" /> <MATCHING_FILE NAME="patternmatching.dll" SIZE="24064" CHECKSUM="0x8373AD2D" MODULE_TYPE="WIN32" PE_CHECKSUM="0xFDD7" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:07:27" UPTO_LINK_DATE="04/07/2008 07:07:27" /> <MATCHING_FILE NAME="rdwr.dll" SIZE="32256" CHECKSUM="0x7B9046A7" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:36:01" UPTO_LINK_DATE="04/08/2008 00:36:01" /> <MATCHING_FILE NAME="RehearseCode.exe" SIZE="25088" CHECKSUM="0xD3390093" MODULE_TYPE="WIN32" PE_CHECKSUM="0xDAA9" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:01:59" UPTO_LINK_DATE="04/08/2008 01:01:59" /> <MATCHING_FILE NAME="replayheap.exe" SIZE="15360" CHECKSUM="0x52932983" MODULE_TYPE="WIN32" PE_CHECKSUM="0x545F" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:02:26" UPTO_LINK_DATE="04/08/2008 01:02:26" /> <MATCHING_FILE NAME="serialio.dll" SIZE="8704" CHECKSUM="0x4E2838D6" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:52:26" UPTO_LINK_DATE="04/07/2008 07:52:26" /> <MATCHING_FILE NAME="set.dll" SIZE="53248" CHECKSUM="0x3EA73D8F" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:14:18" UPTO_LINK_DATE="04/07/2008 07:14:18" /> <MATCHING_FILE NAME="sgml.dll" SIZE="149504" CHECKSUM="0x7F0C814D" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:20:38" UPTO_LINK_DATE="04/08/2008 01:20:38" /> <MATCHING_FILE NAME="sharedobj.dll" SIZE="193024" CHECKSUM="0x2F138704" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:36:34" UPTO_LINK_DATE="04/08/2008 00:36:34" /> <MATCHING_FILE NAME="shobjcodegen.exe" SIZE="1941504" CHECKSUM="0xE2CE99C2" MODULE_TYPE="WIN32" PE_CHECKSUM="0x1E04EE" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:37:08" UPTO_LINK_DATE="04/08/2008 00:37:08" /> <MATCHING_FILE NAME="showheap.exe" SIZE="22528" CHECKSUM="0xFA5909F9" MODULE_TYPE="WIN32" PE_CHECKSUM="0x6897" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:02:52" UPTO_LINK_DATE="04/08/2008 01:02:52" /> <MATCHING_FILE NAME="shownew.exe" SIZE="32256" CHECKSUM="0xEA1457E3" MODULE_TYPE="WIN32" PE_CHECKSUM="0xB820" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:03:18" UPTO_LINK_DATE="04/08/2008 01:03:18" /> <MATCHING_FILE NAME="showthread.exe" SIZE="16384" CHECKSUM="0x31F5DB4C" MODULE_TYPE="WIN32" PE_CHECKSUM="0x8316" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:03:44" UPTO_LINK_DATE="04/08/2008 01:03:44" /> <MATCHING_FILE NAME="SortedTableExtras.dll" SIZE="33280" CHECKSUM="0x7991D3EC" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:14:42" UPTO_LINK_DATE="04/07/2008 07:14:42" /> <MATCHING_FILE NAME="stable.dll" SIZE="27648" CHECKSUM="0xF3B16723" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:40:34" UPTO_LINK_DATE="04/08/2008 00:40:34" /> <MATCHING_FILE NAME="stablegen.exe" SIZE="1832960" CHECKSUM="0xBF99DCCB" MODULE_TYPE="WIN32" PE_CHECKSUM="0x1CBB89" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:39:56" UPTO_LINK_DATE="04/08/2008 00:39:56" /> <MATCHING_FILE NAME="stubgen.exe" SIZE="1844224" CHECKSUM="0x61009FC5" MODULE_TYPE="WIN32" PE_CHECKSUM="0x1C7A67" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:34:34" UPTO_LINK_DATE="04/08/2008 00:34:34" /> <MATCHING_FILE NAME="synex.dll" SIZE="60928" CHECKSUM="0x1642437E" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:50:10" UPTO_LINK_DATE="04/08/2008 00:50:10" /> <MATCHING_FILE NAME="synwr.dll" SIZE="13824" CHECKSUM="0xB1A73466" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:49:49" UPTO_LINK_DATE="04/08/2008 00:49:49" /> <MATCHING_FILE NAME="sysutils.dll" SIZE="113152" CHECKSUM="0x17DC14FE" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:07:52" UPTO_LINK_DATE="04/07/2008 07:07:52" /> <MATCHING_FILE NAME="table-list.dll" SIZE="49152" CHECKSUM="0x6D75D670" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:14:55" UPTO_LINK_DATE="04/07/2008 07:14:55" /> <MATCHING_FILE NAME="TempFiles.dll" SIZE="6656" CHECKSUM="0x9C140244" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:15:07" UPTO_LINK_DATE="04/07/2008 07:15:07" /> <MATCHING_FILE NAME="tok.exe" SIZE="532992" CHECKSUM="0x9944F2E6" MODULE_TYPE="WIN32" PE_CHECKSUM="0x891E6" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:17:46" UPTO_LINK_DATE="04/08/2008 01:17:46" /> <MATCHING_FILE NAME="videovbt.dll" SIZE="9216" CHECKSUM="0x2237D9BE" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:44:07" UPTO_LINK_DATE="04/08/2008 00:44:07" /> <MATCHING_FILE NAME="visobliq.exe" SIZE="414208" CHECKSUM="0x97B860F1" MODULE_TYPE="WIN32" PE_CHECKSUM="0x6C676" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:59:02" UPTO_LINK_DATE="04/08/2008 00:59:02" /> <MATCHING_FILE NAME="vocgi.exe" SIZE="51712" CHECKSUM="0xDE0557FD" MODULE_TYPE="WIN32" PE_CHECKSUM="0x10853" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:59:33" UPTO_LINK_DATE="04/08/2008 00:59:33" /> <MATCHING_FILE NAME="voquery.exe" SIZE="9216" CHECKSUM="0xC2E99515" MODULE_TYPE="WIN32" PE_CHECKSUM="0xD556" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:00:01" UPTO_LINK_DATE="04/08/2008 01:00:01" /> <MATCHING_FILE NAME="vorun.exe" SIZE="80896" CHECKSUM="0xF5FF2444" MODULE_TYPE="WIN32" PE_CHECKSUM="0x23646" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:00:34" UPTO_LINK_DATE="04/08/2008 01:00:34" /> <MATCHING_FILE NAME="web.dll" SIZE="20480" CHECKSUM="0x4AD2B1F7" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:44:29" UPTO_LINK_DATE="04/08/2008 00:44:29" /> <MATCHING_FILE NAME="webvbt.dll" SIZE="180736" CHECKSUM="0x8823E2FB" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:01:13" UPTO_LINK_DATE="04/08/2008 01:01:13" /> </EXE> <EXE NAME="ntdll.dll" FILTER="GRABMI_FILTER_THISFILEONLY"> <MATCHING_FILE NAME="ntdll.dll" SIZE="708096" CHECKSUM="0x9D20568" BIN_FILE_VERSION="5.1.2600.2180" BIN_PRODUCT_VERSION="5.1.2600.2180" PRODUCT_VERSION="5.1.2600.2180" FILE_DESCRIPTION="NT Layer DLL" COMPANY_NAME="Microsoft Corporation" PRODUCT_NAME="Microsoft? Windows? Operating System" FILE_VERSION="5.1.2600.2180 (xpsp_sp2_rtm.040803-2158)" ORIGINAL_FILENAME="ntdll.dll" INTERNAL_NAME="ntdll.dll" LEGAL_COPYRIGHT="? Microsoft Corporation. All rights reserved." VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x40004" VERFILETYPE="0x2" MODULE_TYPE="WIN32" PE_CHECKSUM="0xAF2F7" LINKER_VERSION="0x50001" UPTO_BIN_FILE_VERSION="5.1.2600.2180" UPTO_BIN_PRODUCT_VERSION="5.1.2600.2180" LINK_DATE="08/04/2004 07:56:36" UPTO_LINK_DATE="08/04/2004 07:56:36" VER_LANGUAGE="English (United States) [0x409]" /> </EXE> <EXE NAME="kernel32.dll" FILTER="GRABMI_FILTER_THISFILEONLY"> <MATCHING_FILE NAME="kernel32.dll" SIZE="984576" CHECKSUM="0xF0B331F6" BIN_FILE_VERSION="5.1.2600.3119" BIN_PRODUCT_VERSION="5.1.2600.3119" PRODUCT_VERSION="5.1.2600.3119" FILE_DESCRIPTION="Windows NT BASE API Client DLL" COMPANY_NAME="Microsoft Corporation" PRODUCT_NAME="Microsoft? Windows? Operating System" FILE_VERSION="5.1.2600.3119 (xpsp_sp2_gdr.070416-1301)" ORIGINAL_FILENAME="kernel32" INTERNAL_NAME="kernel32" LEGAL_COPYRIGHT="? Microsoft Corporation. All rights reserved." VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x40004" VERFILETYPE="0x2" MODULE_TYPE="WIN32" PE_CHECKSUM="0xF9293" LINKER_VERSION="0x50001" UPTO_BIN_FILE_VERSION="5.1.2600.3119" UPTO_BIN_PRODUCT_VERSION="5.1.2600.3119" LINK_DATE="04/16/2007 15:52:53" UPTO_LINK_DATE="04/16/2007 15:52:53" VER_LANGUAGE="English (United States) [0x409]" /> </EXE> </DATABASE> From jayk123 at hotmail.com Wed Apr 30 14:40:17 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 30 Apr 2008 12:40:17 +0000 Subject: [M3devel] silenly allowing "WINAPI" on all targets? (wrt Popup Windows stalling regression tests In-Reply-To: References: <495318.48565.qm@web27105.mail.ukl.yahoo.com> <20080429171117.oopp3fpcpc84ccwk@mail.elegosoft.com> Message-ID: I still really like this idea, but this turned out to be something else.. - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Wed, 30 Apr 2008 00:19:51 +0000Subject: [M3devel] silenly allowing "WINAPI" on all targets? (wrt Popup Windows stalling regression tests on WinXP) I think cm3 can just make this call unconditionally. As long as the crash is bubbled up as a failure that is printed or something. There should also be a public interface for collecting and sending the reports without a prompt. Various command line tools (cl, link) now have switches to control this behavior.I know the crash is not in cm3 but what it runs -- the setting is inherited by child processes. So, I have a function that exists and I want to call on Win32, and doesn't exist anywhere else, in which case I want to do nothing. In my opinion, a good way to do this is: something.i3 <* extern WINAPI *> PROCEDURE SetErrorMode(UINT32); I wouldn't mind a way to write this in Modula-3, but the naming is in the way.common/something.c void SetErrorMode(UINT32 a) { /* do nothing */ } and only compile something.c on non-Win32. This raises some issues, that I have raised before. I think WINAPI should be silently ignored for all but NT386.It's a small change. It lets this kind of thing work. I know there are other ideas, like <* extern NT386:WINAPI LINUXLIBC:FOOAPI *>or <* extern SYSAPI *> but really I think what I propose is sufficient (and simplest).I doubt that a generalization or renaming has any point.In fact I'd argue for removing all the synonyms and supporting just __stdcall, __cdecl, __fastcall, and __thiscall, possibly as STDCALL, CDECL, FASTCALL, THISCALL, since Modula-3 doesn't like identifiers to start with underscore, and the last two are optional. As I said/implied before, having multiple calling conventions on one target is a terrible idea and I don't expect it to occur again, not at this level at least. I know, for example, you could describe the Linux kernel as exposing two calling conventions, depending on if there is a "small" or "large" number of parameters, but really, even neither of these two are the "normal" convention and such things always get wrapped up in a little wrapper with the "standard" calling convention of the platform (except on NT386, sort of, where the wrapper is one of a few conventions). Precedent is that calling conventions are allowed in source for other Windows platforms, but are ignored.They might be #defined away sometimes, but I bet the compiler ignores them.This provides better source compatibility.As x86 gradually goes away, people will stop putting these things in. I guess the alternative to my proposal is an extra level of wrapping behind some made up "portable" interface: something.i3: PROCEDURE SetErrorMode(UINT32); win32/something.m3 PROCEDURE SetErrorMode(UINT32 a) = BEGIN WinBase.SetErrorMode(a); END SetErrorMode; posix/something.m3 PROCEDURE SetErrorMode(UINT32 <* unused *> a) = BEGIN (* do nothing *); END SetErrorMode; The alternative does have more flexibility, obviously, if the Posix implementation is anything other than "do nothing", such as even having to return a value, which might be the case here, then it'd go this way. Also this saves there from being a .c file. Is that sleazy to use the same function name in two modules? I know Modula-3 prepends module names always. It seems like a feature more than a bug. Anyway, as before, a gain here would be to reduce the doubled up odbc and maybe opengl .i3 files, which vary only in calling convention. - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comSubject: RE: [M3devel] Popup Windows stalling regression tests on WinXPDate: Tue, 29 Apr 2008 22:01:51 +0000 ps: Olaf, the debugger install is incredibly fast and small.This isn't Visual Studio.I get, but hadn't previously considered, that future regressions would hang the machine, so a fix is only "temporary", but hey...maybe a process needs to monitor the tests and kill them if they take too long? SetErrorMode will probably fix this, now that I think more.We can add a switch to cm3 and it can call that on itself, and it always gets inherited by child processes. Or we can have a trivial wrapper .exe to run the tests, if the switch to cm3 is not liked. But I have to test it out.Suggest an .exe or switch name? :)If indeed it is SetErrorMode, I'd doseterrormode.exe Though this is a low level name.It could be testwrapper.exe or quashpopups.exe. -Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Tue, 29 Apr 2008 21:38:14 +0000Subject: Re: [M3devel] Popup Windows stalling regression tests on WinXP Yes, this might be it.My x86 Windows machine is out on loan this week, my AMD64 Windows machine needed a reinstall, and I was deep into debugging the AMD64_LINUX problem (on same machine, multi-boot), so I punted. Now I've reinstalled AMD64 Windows and can debug to see what the problem is, to decide if it is quashable..There should be a way without global changes to the machine, but if that's ok, ok. (If this even it.) - Jay> Date: Tue, 29 Apr 2008 17:11:17 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] Popup Windows stalling regression tests on WinXP> > Quoting "Daniel Alejandro Benavides D." :> > > Hi all:> > Olaf, I don't have the Win box here (just a Kubuntu one). But even > > if you don't want to send the file, one can see the report file in > > a window. Should be with two steps: The first click on the blue > > label "Click here " in the first pop up window. That throws another > > window with a label that you can click-on and actually see it> > Well I found with google the instruction to disable that error pop up:> > http://pcsupport.about.com/od/windowsxp/ht/disableerror.htm> > I hope this helps to you.> > Thanks, that sounds good, I'll try it tonight.> > Olaf> > >> > Thanks> >> > Olaf Wagner escribi?: Quoting "Daniel > > Alejandro Benavides D." :> >> >> Hi all:> >> Olaf, but in the case is not even the cm3 process, but a sub process> >> of it, maybe the linker or/and the assembler (what VS version do> >> you have?) which in turn throws the fault, how do you know from> >> sure is cm3 only causing that?, Can you check the label of "Click> >> here for more information". Then you can click on see the files> >> involved in the fault. There you should see the list of files like> >> dll or lib and executable involved, can you send that info?> >> > I'll restart the tests after some more obvious fixes later this> > evening and may be able to send more information tomorrow.> > IIRC there was no label `click here for more information', but> > just `send report to Microsoft' and `do not send'.> >> > Currently we're working hard on a completely different release...> >> > Olaf> > --> > Olaf Wagner -- elego Software Solutions GmbH> > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> >> >> >> >> > ---------------------------------> >> > Enviado desde Correo Yahoo!> > La bandeja de entrada m?s inteligente.> >> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Tue Apr 1 00:56:38 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 31 Mar 2008 18:56:38 -0400 Subject: [M3devel] target naming again..DJGPP? In-Reply-To: References: <1206874390.7023.16.camel@faramir.m3w.org> Message-ID: <20080331225638.GA12935@topoi.pooq.com> On Sun, Mar 30, 2008 at 03:38:28PM +0000, Jay wrote: > The environment variable is still "AMD64" on Windows machines with Intel CPUs. It can't change, for compatibility. > The headers mention AMD64 repeatedly. And it's the name of the platform on Debian Linux. -- hendrik From hosking at cs.purdue.edu Tue Apr 1 01:01:01 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 31 Mar 2008 19:01:01 -0400 Subject: [M3devel] target naming again..DJGPP? In-Reply-To: <20080331225638.GA12935@topoi.pooq.com> References: <1206874390.7023.16.camel@faramir.m3w.org> <20080331225638.GA12935@topoi.pooq.com> Message-ID: On Linux you get x86_64-pc-linux-gnu. This is on an AMD box: zed 52 $ gcc --version gcc (GCC) 4.1.2 (Gentoo 4.1.2 p1.0.2) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. zed 53 $ gcc --verbose Using built-in specs. Target: x86_64-pc-linux-gnu Configured with: /scratch/portage/tmp/portage/sys-devel/gcc-4.1.2/work/ gcc-4.1.2/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/ gcc-bin/4.1.2 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/ include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.2 -- mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.2/man --infodir=/ usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.2/info --with-gxx-include- dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include/g++-v4 -- host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-nls --with-system-zlib --disable-checking --disable-werror -- enable-secureplt --disable-libunwind-exceptions --enable-multilib -- enable-libmudflap --disable-libssp --enable-java-awt=gtk --enable- languages=c,c++,java,treelang,fortran --enable-shared --enable- threads=posix --enable-__cxa_atexit --enable-clocale=gnu Thread model: posix gcc version 4.1.2 (Gentoo 4.1.2 p1.0.2) 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 Mar 31, 2008, at 6:56 PM, hendrik at topoi.pooq.com wrote: > On Sun, Mar 30, 2008 at 03:38:28PM +0000, Jay wrote: >> The environment variable is still "AMD64" on Windows machines with >> Intel CPUs. It can't change, for compatibility. >> The headers mention AMD64 repeatedly. > > And it's the name of the platform on Debian Linux. > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Tue Apr 1 01:08:08 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 31 Mar 2008 19:08:08 -0400 Subject: [M3devel] target naming again..DJGPP? In-Reply-To: References: <1206874390.7023.16.camel@faramir.m3w.org> <20080331225638.GA12935@topoi.pooq.com> Message-ID: <20080331230808.GC12532@topoi.pooq.com> On Mon, Mar 31, 2008 at 07:01:01PM -0400, Tony Hosking wrote: > On Linux you get x86_64-pc-linux-gnu. This is on an AMD box: > Interesting. Linux's naming seems to be inconsistent with gcc. hendrik at april:~$ uname -a Linux april 2.6.18-3-amd64 #1 SMP Mon Dec 4 17:04:37 CET 2006 x86_64 GNU/Linux hendrik at april:~$ but hendrik at april:~$ gcc --verbose Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release x86_64-linux-gnu Thread model: posix gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) hendrik at april:~$ -- hendrik From hosking at cs.purdue.edu Tue Apr 1 01:26:03 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 31 Mar 2008 19:26:03 -0400 Subject: [M3devel] target naming again..DJGPP? In-Reply-To: <20080331230808.GC12532@topoi.pooq.com> References: <1206874390.7023.16.camel@faramir.m3w.org> <20080331225638.GA12935@topoi.pooq.com> <20080331230808.GC12532@topoi.pooq.com> Message-ID: Umm... zed 51 $ uname -a Linux zed.cs.purdue.edu 2.6.23.16 #2 SMP Mon Feb 11 13:01:13 EST 2008 x86_64 Intel(R) Xeon(R) CPU E5310 @ 1.60GHz GenuineIntel GNU/Linux On Mar 31, 2008, at 7:08 PM, hendrik at topoi.pooq.com wrote: > On Mon, Mar 31, 2008 at 07:01:01PM -0400, Tony Hosking wrote: >> On Linux you get x86_64-pc-linux-gnu. This is on an AMD box: >> > > Interesting. Linux's naming seems to be inconsistent with gcc. > > hendrik at april:~$ uname -a > Linux april 2.6.18-3-amd64 #1 SMP Mon Dec 4 17:04:37 CET 2006 x86_64 > GNU/Linux > hendrik at april:~$ > > but > > hendrik at april:~$ gcc --verbose > Using built-in specs. > Target: x86_64-linux-gnu > Configured with: ../src/configure -v > --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr > --enable-shared --with-system-zlib --libexecdir=/usr/lib > --without-included-gettext --enable-threads=posix --enable-nls > --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu > --enable-libstdcxx-debug --enable-mpfr --enable-checking=release > x86_64-linux-gnu > Thread model: posix > gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) > hendrik at april:~$ > > > -- hendrik From wagner at elegosoft.com Tue Apr 1 14:39:00 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 01 Apr 2008 14:39:00 +0200 Subject: [M3devel] cm3 for 64 bit linux In-Reply-To: <47F1BF9D.2010803@sirfrt.com.au> References: <47F1BF9D.2010803@sirfrt.com.au> Message-ID: <20080401143900.hmb8fm7ls0s0ks4c@mail.elegosoft.com> Quoting peter mckinna : > Hey, > > I tried to install the linuxlibc6 on my new debian phenom box running > 64 bit linux and had errors > in the assembler for rthooks mostly something about push and pop > invalid length > So I was wondering if you plan to support a 64 bit modula3 distribution? Support for 64 bit targets is definitely on the todo list, but there is no finished port yet. I wonder if it might be possible to get a 32 bit version to run as a workaround though. Perhaps others on the m3devel list have some experience there? It would also be helpful if you could send the exact action and errors to the list. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Tue Apr 1 15:12:04 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 1 Apr 2008 09:12:04 -0400 Subject: [M3devel] cm3 for 64 bit linux In-Reply-To: <20080401143900.hmb8fm7ls0s0ks4c@mail.elegosoft.com> References: <47F1BF9D.2010803@sirfrt.com.au> <20080401143900.hmb8fm7ls0s0ks4c@mail.elegosoft.com> Message-ID: I have Modula-3 running in 32-bit mode on our x86_64 SMP boxes at Purdue. I just checked in the changes needed for the LINUXLIBC6 config file to do this. You can easily bootstrap from the existing LINUXLIBC6 binary distribution. 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 Apr 1, 2008, at 8:39 AM, Olaf Wagner wrote: > Quoting peter mckinna : > >> Hey, >> >> I tried to install the linuxlibc6 on my new debian phenom box >> running >> 64 bit linux and had errors >> in the assembler for rthooks mostly something about push and pop >> invalid length >> So I was wondering if you plan to support a 64 bit modula3 >> distribution? > > Support for 64 bit targets is definitely on the todo list, but there > is > no finished port yet. I wonder if it might be possible to get a 32 bit > version to run as a workaround though. Perhaps others on the m3devel > list have some experience there? > > It would also be helpful if you could send the exact action and errors > to the list. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Tue Apr 1 21:01:55 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 1 Apr 2008 15:01:55 -0400 Subject: [M3devel] target naming again..DJGPP? In-Reply-To: References: <1206874390.7023.16.camel@faramir.m3w.org> <20080331225638.GA12935@topoi.pooq.com> <20080331230808.GC12532@topoi.pooq.com> Message-ID: <20080401190155.GB14168@topoi.pooq.com> On Mon, Mar 31, 2008 at 07:26:03PM -0400, Tony Hosking wrote: > Umm... > > zed 51 $ uname -a > Linux zed.cs.purdue.edu 2.6.23.16 #2 SMP Mon Feb 11 13:01:13 EST 2008 > x86_64 Intel(R) Xeon(R) CPU E5310 @ 1.60GHz GenuineIntel GNU/Linux Interesting. I'm running Debian etch on a real AMD processor. Could it be you have a 64-bit Intel processor? Could there be a subtle difference between the processors? Or might you be using a different Linux distribution, that might use different terminology? Puzzling. -- hendrik From ndantam at purdue.edu Tue Apr 1 21:52:46 2008 From: ndantam at purdue.edu (Neil Thomas Dantam) Date: Tue, 01 Apr 2008 15:52:46 -0400 Subject: [M3devel] target naming again..DJGPP? In-Reply-To: <20080401190155.GB14168@topoi.pooq.com> References: <1206874390.7023.16.camel@faramir.m3w.org> <20080331225638.GA12935@topoi.pooq.com> <20080331230808.GC12532@topoi.pooq.com> <20080401190155.GB14168@topoi.pooq.com> Message-ID: <47F2928E.5010001@purdue.edu> hendrik at topoi.pooq.com wrote: > On Mon, Mar 31, 2008 at 07:26:03PM -0400, Tony Hosking wrote: >> Umm... >> >> zed 51 $ uname -a >> Linux zed.cs.purdue.edu 2.6.23.16 #2 SMP Mon Feb 11 13:01:13 EST 2008 >> x86_64 Intel(R) Xeon(R) CPU E5310 @ 1.60GHz GenuineIntel GNU/Linux > > Interesting. I'm running Debian etch on a real AMD processor. Could it > be you have a 64-bit Intel processor? Could there be a subtle > difference between the processors? Or might you be using a different > Linux distribution, that might use different terminology? My understanding of these names are as follows: - AMD started calling it's new architecture x86_64 - The Linux Kernel chose to call it's support for the the architecture x86_64 - AMD then changed the architecture name to AMD64 so that they could trademark it - Some Linux Distributions choose to call the architecture AMD64, perhaps to give credit to AMD - Sun and Microsoft marketing call the architecture x64, perhaps just to be contrary The instruction set should be the same for Intel and AMD, modulo extensions like SSE3/4 and virtualization. The differing names are the result of AMD changing the name of the architecture and different developers choosing to use the original or modified name. Also, for linux kernel version "2.6.18-3-amd64", the "-3-amd64" part is a patch version tag added by the distribution maintainer. -- Neil From hosking at cs.purdue.edu Wed Apr 2 01:12:00 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 1 Apr 2008 19:12:00 -0400 Subject: [M3devel] target naming again..DJGPP? In-Reply-To: <20080401190155.GB14168@topoi.pooq.com> References: <1206874390.7023.16.camel@faramir.m3w.org> <20080331225638.GA12935@topoi.pooq.com> <20080331230808.GC12532@topoi.pooq.com> <20080401190155.GB14168@topoi.pooq.com> Message-ID: Even more amusing: http://www.x86-64.org/ On Apr 1, 2008, at 3:01 PM, hendrik at topoi.pooq.com wrote: > On Mon, Mar 31, 2008 at 07:26:03PM -0400, Tony Hosking wrote: >> Umm... >> >> zed 51 $ uname -a >> Linux zed.cs.purdue.edu 2.6.23.16 #2 SMP Mon Feb 11 13:01:13 EST 2008 >> x86_64 Intel(R) Xeon(R) CPU E5310 @ 1.60GHz GenuineIntel GNU/Linux > > Interesting. I'm running Debian etch on a real AMD processor. > Could it > be you have a 64-bit Intel processor? Could there be a subtle > difference between the processors? Or might you be using a different > Linux distribution, that might use different terminology? > > Puzzling. > > -- hendrik From hendrik at topoi.pooq.com Wed Apr 2 12:01:04 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 2 Apr 2008 06:01:04 -0400 Subject: [M3devel] target naming again..DJGPP? In-Reply-To: References: <1206874390.7023.16.camel@faramir.m3w.org> <20080331225638.GA12935@topoi.pooq.com> <20080331230808.GC12532@topoi.pooq.com> <20080401190155.GB14168@topoi.pooq.com> Message-ID: <20080402100104.GA16148@topoi.pooq.com> On Tue, Apr 01, 2008 at 07:12:00PM -0400, Tony Hosking wrote: > Even more amusing: http://www.x86-64.org/ I gather that the amusing thing about x86-64.org is that they seem to talk only about AMD64? -- hendrik From hosking at cs.purdue.edu Wed Apr 2 16:03:46 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 2 Apr 2008 10:03:46 -0400 Subject: [M3devel] target naming again..DJGPP? In-Reply-To: <20080402100104.GA16148@topoi.pooq.com> References: <1206874390.7023.16.camel@faramir.m3w.org> <20080331225638.GA12935@topoi.pooq.com> <20080331230808.GC12532@topoi.pooq.com> <20080401190155.GB14168@topoi.pooq.com> <20080402100104.GA16148@topoi.pooq.com> Message-ID: Precisely! :-) Anyway, given that the target would be to both AMD and Intel versions of x86_64/AMD64 perhaps it is best to go with a neutral name. To that end, x86_64 is probably preferable to AMD64. On Apr 2, 2008, at 6:01 AM, hendrik at topoi.pooq.com wrote: > On Tue, Apr 01, 2008 at 07:12:00PM -0400, Tony Hosking wrote: >> Even more amusing: http://www.x86-64.org/ > > I gather that the amusing thing about x86-64.org is that they seem to > talk only about AMD64? > > -- hendrik From jayk123 at hotmail.com Wed Apr 2 23:35:09 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 2 Apr 2008 21:35:09 +0000 Subject: [M3devel] target naming again..DJGPP? In-Reply-To: References: <1206874390.7023.16.camel@faramir.m3w.org> <20080331225638.GA12935@topoi.pooq.com> <20080331230808.GC12532@topoi.pooq.com> <20080401190155.GB14168@topoi.pooq.com> <20080402100104.GA16148@topoi.pooq.com> Message-ID: AMD was the original implementor. Intel is a clone. Admittedly AMD64 is derived from Intel 8086. AMD64 ascribes credit, and is shorter, is consistent with a widespread name that is not going away (not unique in this aspect), and avoids pesky characters like '-' or '_'. I cast my one vote for AMD64 (for the second time at least :) ) - Jay > From: hosking at cs.purdue.edu> To: hendrik at topoi.pooq.com> Date: Wed, 2 Apr 2008 10:03:46 -0400> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] target naming again..DJGPP?> > Precisely! :-)> > Anyway, given that the target would be to both AMD and Intel versions > of x86_64/AMD64 perhaps it is best to go with a neutral name. To that > end, x86_64 is probably preferable to AMD64.> > On Apr 2, 2008, at 6:01 AM, hendrik at topoi.pooq.com wrote:> > > On Tue, Apr 01, 2008 at 07:12:00PM -0400, Tony Hosking wrote:> >> Even more amusing: http://www.x86-64.org/> >> > I gather that the amusing thing about x86-64.org is that they seem to> > talk only about AMD64?> >> > -- hendrik> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Apr 3 23:59:14 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 3 Apr 2008 21:59:14 +0000 Subject: [M3devel] target naming again..DJGPP? In-Reply-To: References: <1206874390.7023.16.camel@faramir.m3w.org> <20080331225638.GA12935@topoi.pooq.com> <20080331230808.GC12532@topoi.pooq.com> <20080401190155.GB14168@topoi.pooq.com> <20080402100104.GA16148@topoi.pooq.com> Message-ID: While I favor AMD64, another popular name is X64. - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; hendrik at topoi.pooq.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] target naming again..DJGPP?Date: Wed, 2 Apr 2008 21:35:09 +0000 AMD was the original implementor. Intel is a clone. Admittedly AMD64 is derived from Intel 8086. AMD64 ascribes credit, and is shorter, is consistent with a widespread name that is not going away (not unique in this aspect), and avoids pesky characters like '-' or '_'.I cast my one vote for AMD64 (for the second time at least :) ) - Jay > From: hosking at cs.purdue.edu> To: hendrik at topoi.pooq.com> Date: Wed, 2 Apr 2008 10:03:46 -0400> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] target naming again..DJGPP?> > Precisely! :-)> > Anyway, given that the target would be to both AMD and Intel versions > of x86_64/AMD64 perhaps it is best to go with a neutral name. To that > end, x86_64 is probably preferable to AMD64.> > On Apr 2, 2008, at 6:01 AM, hendrik at topoi.pooq.com wrote:> > > On Tue, Apr 01, 2008 at 07:12:00PM -0400, Tony Hosking wrote:> >> Even more amusing: http://www.x86-64.org/> >> > I gather that the amusing thing about x86-64.org is that they seem to> > talk only about AMD64?> >> > -- hendrik> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Apr 4 07:38:06 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 4 Apr 2008 05:38:06 +0000 Subject: [M3devel] environment variables..? Message-ID: for example, currently: export CM3_GCC_BACKEND=yesexport CM3_OSTYPE=POSIXexport CM3_TARGET=NT386export OMIT_GCC=yesexport CM3_ROOT=/dev2/cm3.2export CM3_INSTALL=/cm3export M3CONFIG=/dev2/cm3.2/m3-sys/cminstall/src/config/NT386GNU I propose that CM3_OMIT_GCC and CM3_CONFIG be supported. ? Support for M3CONFIG and OMIT_GCC shall remain for compatibility, reluctantly. OMIT_GCC is strictly a "scripts" thing. M3CONFIG is a cm3 thing. I would grant that M3CONFIG isn't terrible, on the theory that really cm3==m3. Anyway, I'm off to do more important stuff probably. :) (such as investigating test failures) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sat Apr 5 02:39:28 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 4 Apr 2008 20:39:28 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. Message-ID: <20080405003928.GA25238@topoi.pooq.com> I downloaded cm3-min-POSIX-LINUXLIBC6-d5.5.0.tgz, unpacked it, ran ./cminstall and got as far as checking for directory /usr/lib... found 1: /usr/lib Where are the X11 libraries? [/usr/lib](1 of 1) The libraries libX11.so libICE.so libSM.so libXt.so libXext.so libXmu.so libXaw.so are not present in the chosen directory. Would you like to change the library names? [yes] However, lovesong:/usr/lib# ls -l libX11.so* libICE.so* libSM.so* libXt.so* libXext.so* libXmu.so* libXaw.so* lrwxrwxrwx 1 root root 15 2007-12-27 21:38 libICE.so -> libICE.so.6.3.0 lrwxrwxrwx 1 root root 15 2007-12-27 21:38 libICE.so.6 -> libICE.so.6.3.0 -rw-r--r-- 1 root root 84880 2007-08-21 03:19 libICE.so.6.3.0 lrwxrwxrwx 1 root root 14 2007-12-27 21:38 libSM.so -> libSM.so.6.0.0 lrwxrwxrwx 1 root root 14 2007-12-27 21:38 libSM.so.6 -> libSM.so.6.0.0 -rw-r--r-- 1 root root 27944 2007-07-11 04:40 libSM.so.6.0.0 lrwxrwxrwx 1 root root 15 2007-12-27 15:59 libX11.so -> libX11.so.6.2.0 lrwxrwxrwx 1 root root 15 2007-12-27 15:59 libX11.so.6 -> libX11.so.6.2.0 -rw-r--r-- 1 root root 965952 2007-04-03 13:24 libX11.so.6.2.0 lrwxrwxrwx 1 root root 12 2007-12-27 21:39 libXaw.so.7 -> libXaw7.so.7 lrwxrwxrwx 1 root root 16 2008-03-25 21:35 libXext.so -> libXext.so.6.4.0 lrwxrwxrwx 1 root root 16 2008-03-25 21:35 libXext.so.6 -> libXext.so.6.4.0 -rw-r--r-- 1 root root 53788 2008-03-02 10:30 libXext.so.6.4.0 lrwxrwxrwx 1 root root 15 2008-01-30 10:01 libXmu.so.6 -> libXmu.so.6.2.0 -rw-r--r-- 1 root root 85528 2008-01-17 08:58 libXmu.so.6.2.0 lrwxrwxrwx 1 root root 14 2007-12-27 21:38 libXt.so -> libXt.so.6.0.0 lrwxrwxrwx 1 root root 14 2007-12-27 21:38 libXt.so.6 -> libXt.so.6.0.0 -rw-r--r-- 1 root root 324484 2007-05-18 18:15 libXt.so.6.0.0 lovesong:/usr/lib# -- hendrik From hosking at cs.purdue.edu Sat Apr 5 03:08:06 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 4 Apr 2008 21:08:06 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080405003928.GA25238@topoi.pooq.com> References: <20080405003928.GA25238@topoi.pooq.com> Message-ID: <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> Looks like you have a strangely configured X11 subsystem. Look at how libXaw (the one cminstall is actually looking for) is not visible in / usr/lib. On Apr 4, 2008, at 8:39 PM, hendrik at topoi.pooq.com wrote: > I downloaded cm3-min-POSIX-LINUXLIBC6-d5.5.0.tgz, unpacked it, > ran ./cminstall and got as far as > > checking for directory /usr/lib... found > > 1: /usr/lib > Where are the X11 libraries? [/usr/lib](1 of 1) > The libraries libX11.so libICE.so libSM.so libXt.so libXext.so > libXmu.so > libXaw.so are not present in the chosen directory. > Would you like to change the library names? [yes] > > > However, > > > lovesong:/usr/lib# ls -l libX11.so* libICE.so* libSM.so* libXt.so* > libXext.so* libXmu.so* libXaw.so* > lrwxrwxrwx 1 root root 15 2007-12-27 21:38 libICE.so -> > libICE.so.6.3.0 > lrwxrwxrwx 1 root root 15 2007-12-27 21:38 libICE.so.6 -> > libICE.so.6.3.0 > -rw-r--r-- 1 root root 84880 2007-08-21 03:19 libICE.so.6.3.0 > lrwxrwxrwx 1 root root 14 2007-12-27 21:38 libSM.so -> libSM.so. > 6.0.0 > lrwxrwxrwx 1 root root 14 2007-12-27 21:38 libSM.so.6 -> > libSM.so.6.0.0 > -rw-r--r-- 1 root root 27944 2007-07-11 04:40 libSM.so.6.0.0 > lrwxrwxrwx 1 root root 15 2007-12-27 15:59 libX11.so -> > libX11.so.6.2.0 > lrwxrwxrwx 1 root root 15 2007-12-27 15:59 libX11.so.6 -> > libX11.so.6.2.0 > -rw-r--r-- 1 root root 965952 2007-04-03 13:24 libX11.so.6.2.0 > lrwxrwxrwx 1 root root 12 2007-12-27 21:39 libXaw.so.7 -> > libXaw7.so.7 > lrwxrwxrwx 1 root root 16 2008-03-25 21:35 libXext.so -> > libXext.so.6.4.0 > lrwxrwxrwx 1 root root 16 2008-03-25 21:35 libXext.so.6 -> > libXext.so.6.4.0 > -rw-r--r-- 1 root root 53788 2008-03-02 10:30 libXext.so.6.4.0 > lrwxrwxrwx 1 root root 15 2008-01-30 10:01 libXmu.so.6 -> > libXmu.so.6.2.0 > -rw-r--r-- 1 root root 85528 2008-01-17 08:58 libXmu.so.6.2.0 > lrwxrwxrwx 1 root root 14 2007-12-27 21:38 libXt.so -> libXt.so. > 6.0.0 > lrwxrwxrwx 1 root root 14 2007-12-27 21:38 libXt.so.6 -> > libXt.so.6.0.0 > -rw-r--r-- 1 root root 324484 2007-05-18 18:15 libXt.so.6.0.0 > lovesong:/usr/lib# > > > -- hendrik From jayk123 at hotmail.com Sat Apr 5 21:02:01 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 5 Apr 2008 19:02:01 +0000 Subject: [M3devel] returning an array from a function?? Message-ID: How does one return a constant array of unspecified size from a function? You know, what might otherwise be a constant array in the interface, but I'd rather hide it behind a function? something like this, though I haven't found anything that compiles and runs: PROCEDURE GetPathVariableNames(): REF ARRAY OF TEXT = BEGIN RETURN ARRAY OF TEXT { (* not all of these presently have meaning but they are suggested synonyms *) (* 0123456789012345 *) (* 8*) "CM3_ROOT", (* root of source tree *) (* 8*) "M3CONFIG", (*10*) "CM3_CONFIG", (* new unimplemented synonym for M3CONFIG *) (*11*) "CM3_INSTALL", (*11*) "INSTALLROOT", (*12*) "INSTALL_ROOT", (*14*) "CM3_SOURCEROOT", (* new unimplemented synonym for CM3_ROOT *) (*15*) "CM3_INSTALLROOT", (*15*) "CM3_SOURCE_ROOT", (* new unimplemented synonym for CM3_ROOT *) (*16*) "CM3_INSTALL_ROOT" (* 0123456789012345 *) }; END GetPathVariableNames; in C I would write: char** GetWhatever() { const static char* strings[] = { "abc", "def", 0 }; return strings; } or char** GetWhatever(size_t* Count) { const static char* strings[] = { "abc", "def" }; *Count = sizeof(strings)/sizeof(strings[0]); return strings; } The client doesn't have to know if it is constant or not. It could be initialized at runtime, with a dynamic size, or not I should not have to make a copy per call. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Sat Apr 5 21:36:53 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat, 05 Apr 2008 21:36:53 +0200 (CEST) Subject: [M3devel] returning an array from a function?? In-Reply-To: References: Message-ID: On Sat, 5 Apr 2008, Jay wrote: > How does one return a constant array of unspecified size from a function? > You know, what might otherwise be a constant array in the interface, but I'd > rather hide it behind a function? Since you cannot obtain a traced pointer to an existing object, you can only create a reference as global variable, initialize it with NEW and := in the modules startup code and return that pointer by GetPathVariableNames. From jayk123 at hotmail.com Sat Apr 5 21:47:20 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 5 Apr 2008 19:47:20 +0000 Subject: [M3devel] returning an array from a function?? In-Reply-To: References: Message-ID: I made it a constant in the interface. I shouldn't have to pay for heap allocation for constants.. :( Thanks, - Jay > Date: Sat, 5 Apr 2008 21:36:53 +0200 > From: lemming at henning-thielemann.de > Subject: Re: [M3devel] returning an array from a function?? > To: jayk123 at hotmail.com > CC: m3devel at elegosoft.com > > > On Sat, 5 Apr 2008, Jay wrote: > > > How does one return a constant array of unspecified size from a function? > > You know, what might otherwise be a constant array in the interface, but I'd > > rather hide it behind a function? > > Since you cannot obtain a traced pointer to an existing object, you can > only create a reference as global variable, initialize it with NEW and := > in the modules startup code and return that pointer by > GetPathVariableNames. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sun Apr 6 15:49:33 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 6 Apr 2008 09:49:33 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> References: <20080405003928.GA25238@topoi.pooq.com> <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> Message-ID: <20080406134933.GA28414@topoi.pooq.com> On Fri, Apr 04, 2008 at 09:08:06PM -0400, Tony Hosking wrote: > Looks like you have a strangely configured X11 subsystem. Look at how > libXaw (the one cminstall is actually looking for) is not visible in / > usr/lib. So you seem to be telling me that the problem is that a symbolic link libXaw->libXaw7.so.7 is missing, even though libXaw.so.7->libXaw7.so.7 is clearly present, there's a complete suite of links for libXaw7, and, as far as I know, no other programs are having problems with this. hendrik at april:/usr/lib$ ls -l libXaw* lrwxrwxrwx 1 root root 15 2006-06-15 11:33 libXaw3d.so.6 -> libXaw3d.so.6.1 -rw-r--r-- 1 root root 367784 2006-05-03 07:20 libXaw3d.so.6.1 lrwxrwxrwx 1 root root 16 2006-09-20 11:39 libXaw7.so.7 -> libXaw7.so.7.0.0 -rw-r--r-- 1 root root 440496 2006-08-27 19:51 libXaw7.so.7.0.0 lrwxrwxrwx 1 root root 12 2006-09-20 11:39 libXaw.so.7 -> libXaw7.so.7 hendrik at april:/usr/lib$ So, since I run a pretty-well autoconfigured X installed from Debian-stable packages, and regularly updated, something must have gone wrong with one of the upgrades since the dawn of time. Or maybe Debian is just weird. I'll go on the Debian sites and try to identify the misbehaving package. Thanks. From hosking at cs.purdue.edu Sun Apr 6 17:29:48 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 6 Apr 2008 11:29:48 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080406134933.GA28414@topoi.pooq.com> References: <20080405003928.GA25238@topoi.pooq.com> <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> Message-ID: <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> You should have a link from libXaw.so, etc. 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 Apr 6, 2008, at 9:49 AM, hendrik at topoi.pooq.com wrote: > On Fri, Apr 04, 2008 at 09:08:06PM -0400, Tony Hosking wrote: >> Looks like you have a strangely configured X11 subsystem. Look at >> how >> libXaw (the one cminstall is actually looking for) is not visible >> in / >> usr/lib. > > So you seem to be telling me that the problem is that a symbolic > link libXaw->libXaw7.so.7 is missing, even though > libXaw.so.7->libXaw7.so.7 is clearly present, there's a complete suite > of links for libXaw7, and, as far as I know, no other programs are > having problems with this. > > hendrik at april:/usr/lib$ ls -l libXaw* > lrwxrwxrwx 1 root root 15 2006-06-15 11:33 libXaw3d.so.6 -> > libXaw3d.so.6.1 > -rw-r--r-- 1 root root 367784 2006-05-03 07:20 libXaw3d.so.6.1 > lrwxrwxrwx 1 root root 16 2006-09-20 11:39 libXaw7.so.7 -> > libXaw7.so.7.0.0 > -rw-r--r-- 1 root root 440496 2006-08-27 19:51 libXaw7.so.7.0.0 > lrwxrwxrwx 1 root root 12 2006-09-20 11:39 libXaw.so.7 -> > libXaw7.so.7 > hendrik at april:/usr/lib$ > > So, since I run a pretty-well autoconfigured X installed from > Debian-stable packages, and regularly updated, something must have > gone > wrong with one of the upgrades since the dawn of time. Or maybe > Debian > is just weird. I'll go on the Debian sites and try to identify the > misbehaving package. > > Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Apr 6 23:43:12 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 6 Apr 2008 21:43:12 +0000 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> References: <20080405003928.GA25238@topoi.pooq.com> <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> Message-ID: Here is birch: % ls -l /usr/lib/libXaw*lrwxrwxrwx 1 root root 15 2007-05-15 10:55 /usr/lib/libXaw3d.so.6 -> libXaw3d.so.6.1-rw-r--r-- 1 root root 290444 2006-05-03 12:21 /usr/lib/libXaw3d.so.6.1-rw-r--r-- 1 root root 342464 2006-08-27 21:27 /usr/lib/libXaw6.a lrwxrwxrwx 1 root root 16 2007-05-30 11:00 /usr/lib/libXaw6.so -> libXaw6.so.6.0.1lrwxrwxrwx 1 root root 16 2007-05-30 11:00 /usr/lib/libXaw6.so.6 -> libXaw6.so.6.0.1-rw-r--r-- 1 root root 253332 2006-08-27 21:27 /usr/lib/libXaw6.so.6.0.1lrwxrwxrwx 1 root root 16 2007-05-30 10:50 /usr/lib/libXaw7.so.7 -> libXaw7.so.7.0.0-rw-r--r-- 1 root root 363260 2006-08-27 21:27 /usr/lib/libXaw7.so.7.0.0lrwxrwxrwx 1 root root 10 2007-05-30 11:00 /usr/lib/libXaw.so -> libXaw6.solrwxrwxrwx 1 root root 12 2007-05-30 11:00 /usr/lib/libXaw.so.6 -> libXaw6.so.6lrwxrwxrwx 1 root root 12 2007-05-30 10:50 /usr/lib/libXaw.so.7 -> libXaw7.so.7 - Jay From: hosking at cs.purdue.eduTo: hendrik at topoi.pooq.comDate: Sun, 6 Apr 2008 11:29:48 -0400CC: m3devel at elegosoft.comSubject: Re: [M3devel] trouble installing on a Debian lenny system.You should have a link from libXaw.so, etc. 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 Apr 6, 2008, at 9:49 AM, hendrik at topoi.pooq.com wrote: On Fri, Apr 04, 2008 at 09:08:06PM -0400, Tony Hosking wrote: Looks like you have a strangely configured X11 subsystem. Look at how libXaw (the one cminstall is actually looking for) is not visible in / usr/lib.So you seem to be telling me that the problem is that a symbolic link libXaw->libXaw7.so.7 is missing, even though libXaw.so.7->libXaw7.so.7 is clearly present, there's a complete suite of links for libXaw7, and, as far as I know, no other programs are having problems with this.hendrik at april:/usr/lib$ ls -l libXaw*lrwxrwxrwx 1 root root 15 2006-06-15 11:33 libXaw3d.so.6 -> libXaw3d.so.6.1-rw-r--r-- 1 root root 367784 2006-05-03 07:20 libXaw3d.so.6.1lrwxrwxrwx 1 root root 16 2006-09-20 11:39 libXaw7.so.7 -> libXaw7.so.7.0.0-rw-r--r-- 1 root root 440496 2006-08-27 19:51 libXaw7.so.7.0.0lrwxrwxrwx 1 root root 12 2006-09-20 11:39 libXaw.so.7 -> libXaw7.so.7hendrik at april:/usr/lib$ So, since I run a pretty-well autoconfigured X installed from Debian-stable packages, and regularly updated, something must have gone wrong with one of the upgrades since the dawn of time. Or maybe Debian is just weird. I'll go on the Debian sites and try to identify the misbehaving package.Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Apr 7 01:39:58 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 6 Apr 2008 23:39:58 +0000 Subject: [M3devel] RTAllocator.OutOfMemory Message-ID: Is the fix really to annotate these with RAISES declarations? In the klex case, I suspect it'll percolate all the way up. And there is some "difference" between explicit calls to the allocator, vs. regular NEW? 27611 NEXT "../src/DeepCopy.m3", line 56: warning: potentially unhandled exception: RTAllocator.OutOfMemory27972 NEXT "../LINUXLIBC6/RegExpTok.m3", line 41: warning: potentially unhandled exception: RTAllocator.OutOfMemory - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Apr 7 02:38:01 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 7 Apr 2008 00:38:01 +0000 Subject: [M3devel] set relationships? Message-ID: I'm looking at test p1\p155. I haven't started debugging it, just trying to understand it. C:\dev2\cm3\doc\reference\relations.html: " infix <=, >= ... (x,y: Set) : BOOLEAN ... <= returns TRUE if every element of x is an element of y. ... The expression x >= y is equivalent to y <= x. ... In all cases, x < y means (x <= y) AND (x # y), and x > y means y < x " Let's just use the sets {1} and {2}. {1} <= {2} {2} <= {1} {1} < {2} {2} < {1} {1} >= {2} {2} >= {1} {1} > {2} {2} > {1} All these expressions are true from the definitions above. Is that reasonable? It seems a little strange to me. I guess I am very used to strongly ordered things, such that a <= b && a => b implies a == b, not true here, and you can't have both a < b and b < a, which you have here, and that (a < b) == !(a >= b) and similar, which is not true here. In this case, every relation but equality is true. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Apr 7 02:52:10 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 7 Apr 2008 00:52:10 +0000 Subject: [M3devel] set relationships? In-Reply-To: References: Message-ID: oops -- I mean they are all false. From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Mon, 7 Apr 2008 00:38:01 +0000Subject: [M3devel] set relationships? I'm looking at test p1\p155.I haven't started debugging it, just trying to understand it. C:\dev2\cm3\doc\reference\relations.html:" infix <=, >= ... (x,y: Set) : BOOLEAN ... <= returns TRUE if every element of x is an element of y....The expression x >= y is equivalent to y <= x. ...In all cases, x < y means (x <= y) AND (x # y), and x > y means y < x" Let's just use the sets {1} and {2}. {1} <= {2} {2} <= {1} {1} < {2} {2} < {1} {1} >= {2} {2} >= {1} {1} > {2} {2} > {1} All these expressions are true from the definitions above.Is that reasonable?It seems a little strange to me. I guess I am very used to strongly ordered things, such that a <= b && a => b implies a == b, not true here, and you can't have both a < b and b < a, which you have here, and that (a < b) == !(a >= b) and similar, which is not true here. In this case, every relation but equality is true. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Mon Apr 7 03:39:18 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 6 Apr 2008 21:39:18 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> References: <20080405003928.GA25238@topoi.pooq.com> <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> Message-ID: <20080407013918.GA29466@topoi.pooq.com> On Sun, Apr 06, 2008 at 11:29:48AM -0400, Tony Hosking wrote: > You should have a link from libXaw.so, etc. It turns out that link was in the package libXaw7-dev, which was missing on both my 64- and 32-bit systems. -- hendrik hendrik at lovesong:/usr/lib$ ls -l libXaw.so lrwxrwxrwx 1 root root 10 2008-04-06 20:38 libXaw.so -> libXaw7.so hendrik at lovesong:/usr/lib$ From wagner at elegosoft.com Mon Apr 7 12:03:50 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 07 Apr 2008 12:03:50 +0200 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080407013918.GA29466@topoi.pooq.com> References: <20080405003928.GA25238@topoi.pooq.com> <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> Message-ID: <20080407120350.2dkp81ly0gs0ko8s@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > On Sun, Apr 06, 2008 at 11:29:48AM -0400, Tony Hosking wrote: >> You should have a link from libXaw.so, etc. > > It turns out that link was in the package libXaw7-dev, which was missing > on both my 64- and 32-bit systems. This sounds broken to me. M3 has been changed some time ago to look for shared objects instead of archives, as the latter are often not installed on modern systems, but come only as part of development packages. But there must be a simple unique name for the resource; we cannot per default refer to libXaw.so.7.0 or similar, since this would need more updates and maintenance and would break if another version is actually installed. So I don't see a reason for this kind of link to be in the development packages. Should we report this as a bug? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 7 15:56:19 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 7 Apr 2008 09:56:19 -0400 Subject: [M3devel] RTAllocator.OutOfMemory In-Reply-To: References: Message-ID: Just put FATAL declarations to have the system die when it receives those errors. On Apr 6, 2008, at 7:39 PM, Jay wrote: > Is the fix really to annotate these with RAISES declarations? > In the klex case, I suspect it'll percolate all the way up. > And there is some "difference" between explicit calls to the > allocator, vs. regular NEW? > > 27611 NEXT "../src/DeepCopy.m3", line 56: warning: potentially > unhandled exception: RTAllocator.OutOfMemory > 27972 NEXT "../LINUXLIBC6/RegExpTok.m3", line 41: warning: > potentially unhandled exception: RTAllocator.OutOfMemory > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Apr 7 18:29:26 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 7 Apr 2008 12:29:26 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080407120350.2dkp81ly0gs0ko8s@mail.elegosoft.com> References: <20080405003928.GA25238@topoi.pooq.com> <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> <20080407120350.2dkp81ly0gs0ko8s@mail.elegosoft.com> Message-ID: Generally, you'll need all dev packages with CM3. 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 Apr 7, 2008, at 6:03 AM, Olaf Wagner wrote: > Quoting hendrik at topoi.pooq.com: > >> On Sun, Apr 06, 2008 at 11:29:48AM -0400, Tony Hosking wrote: >>> You should have a link from libXaw.so, etc. >> >> It turns out that link was in the package libXaw7-dev, which was >> missing >> on both my 64- and 32-bit systems. > > This sounds broken to me. > > M3 has been changed some time ago to look for shared objects instead > of > archives, as the latter are often not installed on modern systems, but > come only as part of development packages. > > But there must be a simple unique name for the resource; we cannot > per default refer to libXaw.so.7.0 or similar, since this would > need more updates and maintenance and would break if another version > is actually installed. > > So I don't see a reason for this kind of link to be in the development > packages. Should we report this as a bug? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Apr 7 21:28:49 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 07 Apr 2008 21:28:49 +0200 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: References: <20080405003928.GA25238@topoi.pooq.com> <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> <20080407120350.2dkp81ly0gs0ko8s@mail.elegosoft.com> Message-ID: <20080407212849.1ovvw8niaocs8g0g@mail.elegosoft.com> Quoting Tony Hosking : > Generally, you'll need all dev packages with CM3. Hm 8-/ Seems I'm not really up-to-date here... Olaf > 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 Apr 7, 2008, at 6:03 AM, Olaf Wagner wrote: > >> Quoting hendrik at topoi.pooq.com: >> >>> On Sun, Apr 06, 2008 at 11:29:48AM -0400, Tony Hosking wrote: >>>> You should have a link from libXaw.so, etc. >>> >>> It turns out that link was in the package libXaw7-dev, which was missing >>> on both my 64- and 32-bit systems. >> >> This sounds broken to me. >> >> M3 has been changed some time ago to look for shared objects instead of >> archives, as the latter are often not installed on modern systems, but >> come only as part of development packages. >> >> But there must be a simple unique name for the resource; we cannot >> per default refer to libXaw.so.7.0 or similar, since this would >> need more updates and maintenance and would break if another version >> is actually installed. >> >> So I don't see a reason for this kind of link to be in the development >> packages. Should we report this as a bug? >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Mon Apr 7 21:41:08 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 7 Apr 2008 15:41:08 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080407212849.1ovvw8niaocs8g0g@mail.elegosoft.com> References: <20080405003928.GA25238@topoi.pooq.com> <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> <20080407120350.2dkp81ly0gs0ko8s@mail.elegosoft.com> <20080407212849.1ovvw8niaocs8g0g@mail.elegosoft.com> Message-ID: <78F773EF-E82D-43B7-B402-60C854A6BDE1@cs.purdue.edu> Perhaps you're right. 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 Apr 7, 2008, at 3:28 PM, Olaf Wagner wrote: > Quoting Tony Hosking : > >> Generally, you'll need all dev packages with CM3. > > Hm 8-/ Seems I'm not really up-to-date here... > > Olaf > >> 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 Apr 7, 2008, at 6:03 AM, Olaf Wagner wrote: >> >>> Quoting hendrik at topoi.pooq.com: >>> >>>> On Sun, Apr 06, 2008 at 11:29:48AM -0400, Tony Hosking wrote: >>>>> You should have a link from libXaw.so, etc. >>>> >>>> It turns out that link was in the package libXaw7-dev, which was >>>> missing >>>> on both my 64- and 32-bit systems. >>> >>> This sounds broken to me. >>> >>> M3 has been changed some time ago to look for shared objects >>> instead of >>> archives, as the latter are often not installed on modern systems, >>> but >>> come only as part of development packages. >>> >>> But there must be a simple unique name for the resource; we cannot >>> per default refer to libXaw.so.7.0 or similar, since this would >>> need more updates and maintenance and would break if another version >>> is actually installed. >>> >>> So I don't see a reason for this kind of link to be in the >>> development >>> packages. Should we report this as a bug? >>> >>> Olaf >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>> Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Tue Apr 8 02:36:30 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 7 Apr 2008 20:36:30 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080407120350.2dkp81ly0gs0ko8s@mail.elegosoft.com> References: <20080405003928.GA25238@topoi.pooq.com> <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> <20080407120350.2dkp81ly0gs0ko8s@mail.elegosoft.com> Message-ID: <20080408003630.GA30598@topoi.pooq.com> On Mon, Apr 07, 2008 at 12:03:50PM +0200, Olaf Wagner wrote: > Quoting hendrik at topoi.pooq.com: > > >On Sun, Apr 06, 2008 at 11:29:48AM -0400, Tony Hosking wrote: > >>You should have a link from libXaw.so, etc. > > > >It turns out that link was in the package libXaw7-dev, which was missing > >on both my 64- and 32-bit systems. > > This sounds broken to me. > > M3 has been changed some time ago to look for shared objects instead of > archives, as the latter are often not installed on modern systems, but > come only as part of development packages. > > But there must be a simple unique name for the resource; we cannot > per default refer to libXaw.so.7.0 or similar, since this would > need more updates and maintenance and would break if another version > is actually installed. > > So I don't see a reason for this kind of link to be in the development > packages. Should we report this as a bug? I suppose that depends on whether the linker and loader understand the version numbers in the name and does the right thing in the absence of links. I know there's a convention as to which parts of the versin number indicate compatible vs incompatible changes. I thought that compatible alternatives could be found automatically at load time, and (I thought) the wrong alternatives would not be. I don't know whether the mechanism for this is symbolic links. I suppose it could be. So I don't know whether this is a bug. The major version number changes for incompatible changes. If the linker links a program to a particular shared library, changes in the minor version wouldn't matter, but change in the major version likely would. So I'd guess that the linker would include a reference to the particular major version in the linked binary, not a reference to the versin-free file name. Thus the version-free library name would not be needed just for running the binary. It might end up referring to an incompatible version. I could be wrong, of course. I'm just trying to guess what Debian's reasoning might have been. -- hendrik From hendrik at topoi.pooq.com Tue Apr 8 19:17:34 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 8 Apr 2008 13:17:34 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080407013918.GA29466@topoi.pooq.com> References: <20080405003928.GA25238@topoi.pooq.com> <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> Message-ID: <20080408171734.GA31674@topoi.pooq.com> On Sun, Apr 06, 2008 at 09:39:18PM -0400, hendrik at topoi.pooq.com wrote: > On Sun, Apr 06, 2008 at 11:29:48AM -0400, Tony Hosking wrote: > > You should have a link from libXaw.so, etc. > > It turns out that link was in the package libXaw7-dev, which was missing > on both my 64- and 32-bit systems. > > -- hendrik > > hendrik at lovesong:/usr/lib$ ls -l libXaw.so > lrwxrwxrwx 1 root root 10 2008-04-06 20:38 libXaw.so -> libXaw7.so > hendrik at lovesong:/usr/lib$ I resumed installation. Ths installer failed to find my odbc or my postresql, which I thought would be OK since I don't expect to need them and I didn't have them installed. I then followed the instructions on http://modula3.elegosoft.com/cm3/installation.html using the commands mkdir cm3 cd cm3 tar -zxf /path/to/cm3-src-sys-CM3VERSION.tgz tar -zxf /path/to/cm3-src-gnu-CM3VERSION.tgz tar -zxf /path/to/cm3-src-std-CM3VERSION.tgz (1) I patched to avoid the asm/ipc.h problem. (2) the last step failed as follows: hendrik at lovesong:~/cm3/scripts$ ./do-cm3-std.sh buildship CM3C = /farhome/hendrik/cm3/scripts/pkgmap.sh -c "cm3 -build -DROOT='/farhome/hendrik/cm3' && cm3 -ship -DROOT='/farhome/hendrik/cm3' " m3gc-simple m3core libm3 patternmatching m3middle m3quake m3scanner m3tools m3cgcat m3cggen m3gdb m3bundle arithmetic bitvector digraph parseparams realgeometry set slisp sortedtableextras table-list tempfiles tcp udp libsio libbuf debug listfuncs embutils m3tk-misc http binIO commandrw m3tk mtex m3totex m3tohtml m3scan m3markup m3browser cmpdir cmpfp dirfp uniq netobj netobjd stubgen events rdwr sharedobj sharedobjgen odbc postgres95 db smalldb stable stablegen X11R4 ui PEX vbtkit cmvbt jvideo videovbt web formsvbtpixmaps formsvbt formsview formsedit codeview mg mgkit opengl anim3D zeus m3zume synloc synex metasyn obliqrt obliqparse obliqprint obliq obliqlibemb obliqlibm3 obliqlibui obliqlibanim obliqsrvstd obliqsrvui obliqbinmin obliqbinstd obliqbinui obliqbinanim visualobliq vocgi voquery vorun webvbt recordheap rehearsecode replayheap showheap shownew showthread pkl-fonts juno-machine juno-compiler juno-app cube calculator fisheye mentor === package /farhome/hendrik/cm3/m3-libs/m3gc-simple === +++ cm3 -build -DROOT='/farhome/hendrik/cm3' && cm3 -ship -DROOT='/farhome/hendrik/cm3' +++ /bin/sh: line 1: 10644 Segmentation fault cm3 -build -DROOT='/farhome/hendrik/cm3' *** execution of failed *** hendrik at lovesong:~/cm3/scripts$ (my text editor wrapped the lines when I pasted them into this message)) Presumably there's something else weird about my system. Any ideas what to look for? -- hendrik From jayk123 at hotmail.com Tue Apr 8 22:16:05 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 8 Apr 2008 20:16:05 +0000 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080408171734.GA31674@topoi.pooq.com> References: <20080405003928.GA25238@topoi.pooq.com> <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> <20080408171734.GA31674@topoi.pooq.com> Message-ID: Try current source from CVS instead of the .tgz files.Be sure to delete scripts/PKGS. m3gc-simple no longer exists. - Jay > Date: Tue, 8 Apr 2008 13:17:34 -0400> From: hendrik at topoi.pooq.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] trouble installing on a Debian lenny system.> > On Sun, Apr 06, 2008 at 09:39:18PM -0400, hendrik at topoi.pooq.com wrote:> > On Sun, Apr 06, 2008 at 11:29:48AM -0400, Tony Hosking wrote:> > > You should have a link from libXaw.so, etc.> > > > It turns out that link was in the package libXaw7-dev, which was missing > > on both my 64- and 32-bit systems.> > > > -- hendrik> > > > hendrik at lovesong:/usr/lib$ ls -l libXaw.so> > lrwxrwxrwx 1 root root 10 2008-04-06 20:38 libXaw.so -> libXaw7.so> > hendrik at lovesong:/usr/lib$ > > I resumed installation. Ths installer failed to find my odbc or my > postresql, which I thought would be OK since I don't expect to need > them and I didn't have them installed.> > I then followed the instructions on > http://modula3.elegosoft.com/cm3/installation.html using the commands> > mkdir cm3> cd cm3> tar -zxf /path/to/cm3-src-sys-CM3VERSION.tgz> tar -zxf /path/to/cm3-src-gnu-CM3VERSION.tgz> tar -zxf /path/to/cm3-src-std-CM3VERSION.tgz> > > (1) I patched to avoid the asm/ipc.h problem.> (2) the last step failed as follows:> > hendrik at lovesong:~/cm3/scripts$ ./do-cm3-std.sh buildship> CM3C => /farhome/hendrik/cm3/scripts/pkgmap.sh -c "cm3 -build > -DROOT='/farhome/hendrik/cm3' && cm3 -ship > -DROOT='/farhome/hendrik/cm3' " m3gc-simple m3core libm3 patternmatching > m3middle m3quake m3scanner m3tools m3cgcat m3cggen m3gdb m3bundle > arithmetic bitvector digraph parseparams realgeometry set slisp > sortedtableextras table-list tempfiles tcp udp libsio libbuf debug > listfuncs embutils m3tk-misc http binIO commandrw m3tk mtex m3totex > m3tohtml m3scan m3markup m3browser cmpdir cmpfp dirfp uniq netobj > netobjd stubgen events rdwr sharedobj sharedobjgen odbc postgres95 db > smalldb stable stablegen X11R4 ui PEX vbtkit cmvbt jvideo videovbt web > formsvbtpixmaps formsvbt formsview formsedit codeview mg mgkit opengl > anim3D zeus m3zume synloc synex metasyn obliqrt obliqparse obliqprint > obliq obliqlibemb obliqlibm3 obliqlibui obliqlibanim obliqsrvstd > obliqsrvui obliqbinmin obliqbinstd obliqbinui obliqbinanim visualobliq > vocgi voquery vorun webvbt recordheap rehearsecode replayheap showheap > shownew showthread pkl-fonts juno-machine juno-compiler juno-app cube > calculator fisheye mentor> === package /farhome/hendrik/cm3/m3-libs/m3gc-simple ===> +++ cm3 -build -DROOT='/farhome/hendrik/cm3' && cm3 -ship > -DROOT='/farhome/hendrik/cm3' +++> /bin/sh: line 1: 10644 Segmentation fault cm3 -build > -DROOT='/farhome/hendrik/cm3'> *** execution of failed ***> hendrik at lovesong:~/cm3/scripts$ > > > (my text editor wrapped the lines when I pasted them into this message))> > Presumably there's something else weird about my system.> > Any ideas what to look for?> > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Wed Apr 9 01:15:41 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 8 Apr 2008 19:15:41 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: References: <20080405003928.GA25238@topoi.pooq.com> <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> <20080408171734.GA31674@topoi.pooq.com> Message-ID: <20080408231541.GA31929@topoi.pooq.com> On Tue, Apr 08, 2008 at 08:16:05PM +0000, Jay wrote: > Try current source from CVS instead of the .tgz files.Be sure to delete scripts/PKGS. > m3gc-simple no longer exists. > > - Jay Did that. Used cvs -z 3 -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 as described in http://modula3.elegosoft.com/cm3/install-cm3-on-ubuntu-7-10.html (although I have Debian) and got hendrik at lovesong:~/cm3/scripts$ ./do-cm3-core.sh buildship making /farhome/hendrik/cm3/scripts/PKGS (slow but rare) /farhome/hendrik/cm3/scripts/pkgmap.sh -c "cm3 -build -DROOT='/farhome/hendrik/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' && cm3 -ship -DROOT='/farhome/hendrik/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' " import-libs m3cc m3core libm3 patternmatching sysutils unittest m3middle m3objfile m3linker m3back m3staloneback m3front m3quake cm3 m3scanner m3tools m3cgcat m3cggen m3bundle mklib fix_nl libdump bitvector digraph parseparams realgeometry set slisp sortedtableextras table-list tempfiles tcl === package /farhome/hendrik/cm3/m3-win/import-libs === === package omitted on this platform === ==> /farhome/hendrik/cm3/m3-win/import-libs done === package /farhome/hendrik/cm3/m3-sys/m3cc === +++ cm3 -build -DROOT='/farhome/hendrik/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' && cm3 -ship -DROOT='/farhome/hendrik/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' +++ /bin/sh: line 1: 30590 Segmentation fault cm3 -build -DROOT='/farhome/hendrik/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' *** execution of cm3 -build -DROOT='/farhome/hendrik/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' && cm3 -ship -DROOT='/farhome/hendrik/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' failed *** hendrik at lovesong:~/cm3/scripts$ -- hendrik Perhaps I have to wipe /usr/local/cm3 and start again with the cm3-install script? - hendrik From hendrik at topoi.pooq.com Wed Apr 9 01:33:38 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 8 Apr 2008 19:33:38 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080408231541.GA31929@topoi.pooq.com> References: <20080405003928.GA25238@topoi.pooq.com> <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> <20080408171734.GA31674@topoi.pooq.com> <20080408231541.GA31929@topoi.pooq.com> Message-ID: <20080408233338.GA32037@topoi.pooq.com> On Tue, Apr 08, 2008 at 07:15:41PM -0400, hendrik at topoi.pooq.com wrote: > > Perhaps I have to wipe /usr/local/cm3 and start again with the > cm3-install script? > > - hendrik Now doing that. It seems to be working better now. -- hendrik From hendrik at topoi.pooq.com Wed Apr 9 02:02:07 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 8 Apr 2008 20:02:07 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080408233338.GA32037@topoi.pooq.com> References: <20080405003928.GA25238@topoi.pooq.com> <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> <20080408171734.GA31674@topoi.pooq.com> <20080408231541.GA31929@topoi.pooq.com> <20080408233338.GA32037@topoi.pooq.com> Message-ID: <20080409000207.GA32073@topoi.pooq.com> On Tue, Apr 08, 2008 at 07:33:38PM -0400, hendrik at topoi.pooq.com wrote: > On Tue, Apr 08, 2008 at 07:15:41PM -0400, hendrik at topoi.pooq.com wrote: > > > > Perhaps I have to wipe /usr/local/cm3 and start again with the > > cm3-install script? > > > > - hendrik > > Now doing that. It seems to be working better now. > > -- hendrik > Everything went fine until new source -> compiling Cstdlib.i3 "../src/word/LongRep.i3", line 2: undefined (LONGINT) "../src/C/32BITS/BasicCtypes.i3", line 18: undefined (LONGINT) "../src/C/Common/Cstdlib.i3", line 13: imported interface contains errors (Ctypes) 3 errors encountered It looks as if LONGINT isn't defined. This is within package === package /farhome/hendrik/cm3/m3-libs/m3core === At this point I presume it is still using the cminstalled compiler. Does that need to be nudged?. -- hendrik From hendrik at topoi.pooq.com Wed Apr 9 02:33:29 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 8 Apr 2008 20:33:29 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080409000207.GA32073@topoi.pooq.com> References: <20080405003928.GA25238@topoi.pooq.com> <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> <20080408171734.GA31674@topoi.pooq.com> <20080408231541.GA31929@topoi.pooq.com> <20080408233338.GA32037@topoi.pooq.com> <20080409000207.GA32073@topoi.pooq.com> Message-ID: <20080409003329.GB32073@topoi.pooq.com> On Tue, Apr 08, 2008 at 08:02:07PM -0400, hendrik at topoi.pooq.com wrote: > > At this point I presume it is still using the cminstalled compiler. > Does that need to be nudged?. > > -- hendrik > I obtained another cminstall, from ../cm3-min-POSIX-LINUXLIBC6-d5.7.0-2008-04-08-14-00-05.tgz Tried it. It rushed through the dialogues without giving me a chance to answer anything. (Is this a bug?) It even found odbc and postgres95, which I thought hadn't been installed. Where are the Postgres95 libraries? looking for library file(s): libpq.so checking for library files in directory /usr/lib... not found checking for library files in directory /usr/local/postgres95/lib... not found checking for library files in directory /usr/local/lib... not found checking for directory /usr/lib... found --> "-L/usr/lib" But, hendrik at lovesong:~$ ls /usr/lib/libpq* ls: cannot access /usr/lib/libpq*: No such file or directory hendrik at lovesong:~$ and Where are the ODBC libraries? looking for library file(s): libiodbc.so checking for library files in directory /usr/lib... not found checking for library files in directory /usr/local/lib... not found checking for library files in directory /usr/local/pgsql/lib... not found checking for library files in directory /usr/local/postgres95/lib... not found checking for directory /usr/lib... found --> "-L/usr/lib" but hendrik at lovesong:~$ ls /usr/lib/libio* ls: cannot access /usr/lib/libio*: No such file or directory hendrik at lovesong:~$ Finding these two nonexistent files does seem to be a bug. -- hendrik From jay.krell at cornell.edu Wed Apr 9 02:57:39 2008 From: jay.krell at cornell.edu (Jay) Date: Wed, 9 Apr 2008 00:57:39 +0000 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080409003329.GB32073@topoi.pooq.com> References: <20080405003928.GA25238@topoi.pooq.com> <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> <20080408171734.GA31674@topoi.pooq.com> <20080408231541.GA31929@topoi.pooq.com> <20080408233338.GA32037@topoi.pooq.com> <20080409000207.GA32073@topoi.pooq.com> <20080409003329.GB32073@topoi.pooq.com> Message-ID: "Rushing through the dialogues" is a new feature. I kept complaining about how dumb it was. On NT386* at least, I stopped using cminstall altogether. There is an -interactive option or somesuch. - Jay > Date: Tue, 8 Apr 2008 20:33:29 -0400> From: hendrik at topoi.pooq.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] trouble installing on a Debian lenny system.> > On Tue, Apr 08, 2008 at 08:02:07PM -0400, hendrik at topoi.pooq.com wrote:> > > > At this point I presume it is still using the cminstalled compiler. > > Does that need to be nudged?.> > > > -- hendrik> > > > I obtained another cminstall, from > ../cm3-min-POSIX-LINUXLIBC6-d5.7.0-2008-04-08-14-00-05.tgz> > Tried it. It rushed through the dialogues without giving me a chance to > answer anything. (Is this a bug?) It even found odbc and postgres95, > which I thought hadn't been installed.> > Where are the Postgres95 libraries?> looking for library file(s): libpq.so> checking for library files in directory /usr/lib... not found> checking for library files in directory /usr/local/postgres95/lib... not > found> checking for library files in directory /usr/local/lib... not found> checking for directory /usr/lib... found > --> "-L/usr/lib"> > > But, > > hendrik at lovesong:~$ ls /usr/lib/libpq*> ls: cannot access /usr/lib/libpq*: No such file or directory> hendrik at lovesong:~$ > > > and > > Where are the ODBC libraries?> looking for library file(s): libiodbc.so> checking for library files in directory /usr/lib... not found> checking for library files in directory /usr/local/lib... not found> checking for library files in directory /usr/local/pgsql/lib... not > found> checking for library files in directory /usr/local/postgres95/lib... not > found> checking for directory /usr/lib... found > --> "-L/usr/lib"> > but> > hendrik at lovesong:~$ ls /usr/lib/libio*> ls: cannot access /usr/lib/libio*: No such file or directory> hendrik at lovesong:~$ > > Finding these two nonexistent files does seem to be a bug.> > -- hendrik> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Apr 9 03:00:20 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 9 Apr 2008 01:00:20 +0000 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080409000207.GA32073@topoi.pooq.com> References: <20080405003928.GA25238@topoi.pooq.com> <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> <20080408171734.GA31674@topoi.pooq.com> <20080408231541.GA31929@topoi.pooq.com> <20080408233338.GA32037@topoi.pooq.com> <20080409000207.GA32073@topoi.pooq.com> Message-ID: Right. This is a normal symptom of using an "old" compiler to compile current source. You must first build a new compiler against an old runtime (which you must get from "somewhere", such as an existing older install), then use that to build a new runtime. scripts/upgrade.sh scripts/python/upgrade.py scripts/win/upgrade.cmd should all handle the "dance" for you. - Jay > Date: Tue, 8 Apr 2008 20:02:07 -0400> From: hendrik at topoi.pooq.com > "../src/word/LongRep.i3", line 2: undefined (LONGINT)> "../src/C/32BITS/BasicCtypes.i3", line 18: undefined (LONGINT)> "../src/C/Common/Cstdlib.i3", line 13: imported interface contains errors (Ctypes)> 3 errors encountered> > At this point I presume it is still using the cminstalled compiler. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Wed Apr 9 03:14:18 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 8 Apr 2008 21:14:18 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: References: <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> <20080408171734.GA31674@topoi.pooq.com> <20080408231541.GA31929@topoi.pooq.com> <20080408233338.GA32037@topoi.pooq.com> <20080409000207.GA32073@topoi.pooq.com> Message-ID: <20080409011418.GC32073@topoi.pooq.com> On Wed, Apr 09, 2008 at 01:00:20AM +0000, Jay wrote: > Right. > This is a normal symptom of using an "old" compiler to compile current source. > You must first build a new compiler against an old runtime (which you must get from "somewhere", such as an existing older install), then use that to build a new runtime. > > scripts/upgrade.sh > scripts/python/upgrade.py > scripts/win/upgrade.cmd > > should all handle the "dance" for you. > > - Jay Except I don't *have* a working old runtime. I've mentioned my experiences with ../cm3-min-POSIX-LINUXLIBC6-d5.7.0-2008-04-08-14-00-05.tgz in another post. I acquired it in the hope that it wouldn't be an old runtime. -- hendrik > > > > > Date: Tue, 8 Apr 2008 20:02:07 -0400> From: hendrik at topoi.pooq.com > > "../src/word/LongRep.i3", line 2: undefined (LONGINT)> "../src/C/32BITS/BasicCtypes.i3", line 18: undefined (LONGINT)> "../src/C/Common/Cstdlib.i3", line 13: imported interface contains errors (Ctypes)> 3 errors encountered> > At this point I presume it is still using the cminstalled compiler. From hendrik at topoi.pooq.com Wed Apr 9 03:17:42 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 8 Apr 2008 21:17:42 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: References: <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> <20080408171734.GA31674@topoi.pooq.com> <20080408231541.GA31929@topoi.pooq.com> <20080408233338.GA32037@topoi.pooq.com> <20080409000207.GA32073@topoi.pooq.com> <20080409003329.GB32073@topoi.pooq.com> Message-ID: <20080409011742.GD32073@topoi.pooq.com> On Wed, Apr 09, 2008 at 12:57:39AM +0000, Jay wrote: > "Rushing through the dialogues" is a new feature. I kept complaining about how dumb it was. On NT386* at least, I stopped using cminstall altogether. There is an -interactive option or somesuch. > > - Jay > But I suspect finding nonexistent files isn't a feature, new or old. Is it going to cause trouble later on? Is it going to try to install things that depend on postgres and odbc and fall apart? -- hendrik From hendrik at topoi.pooq.com Wed Apr 9 03:24:11 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 8 Apr 2008 21:24:11 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080409011742.GD32073@topoi.pooq.com> References: <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> <20080408171734.GA31674@topoi.pooq.com> <20080408231541.GA31929@topoi.pooq.com> <20080408233338.GA32037@topoi.pooq.com> <20080409000207.GA32073@topoi.pooq.com> <20080409003329.GB32073@topoi.pooq.com> <20080409011742.GD32073@topoi.pooq.com> Message-ID: <20080409012411.GE32073@topoi.pooq.com> On Tue, Apr 08, 2008 at 09:17:42PM -0400, hendrik at topoi.pooq.com wrote: > On Wed, Apr 09, 2008 at 12:57:39AM +0000, Jay wrote: > > "Rushing through the dialogues" is a new feature. I kept complaining > about how dumb it was. On NT386* at least, I stopped using cminstall > altogether. There is an -interactive option or somesuch. > > > > > - Jay > > > > But I suspect finding nonexistent files isn't a feature, new or old. Is > it going to cause trouble later on? Is it going to try to install > things that depend on postgres and odbc and fall apart? The -interactive option gives me interaction. But it still finds the nonexistent libpq.so in /usr/lib. Where are the Postgres95 libraries? looking for library file(s): libpq.so checking for library files in directory /usr/lib... not found checking for library files in directory /usr/local/postgres95/lib... not found checking for library files in directory /usr/local/lib... not found checking for directory /usr/lib... found 1: /usr/lib Where are the Postgres95 libraries? [/usr/lib](1 of 1) Only after I accept the default location does it notice threre's no such file there. I find this confusing, because it correctly fails to find in in all the other locations. But I guess I can live with this, because it gives me the chance to say: The libraries libpq.so are not present in the chosen directory. Would you like to change the library names? [yes] no Would you like to continue nonetheless? [yes] yes Thanks. -- hendrik From hendrik at topoi.pooq.com Wed Apr 9 04:25:29 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 8 Apr 2008 22:25:29 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080409012411.GE32073@topoi.pooq.com> References: <20080407013918.GA29466@topoi.pooq.com> <20080408171734.GA31674@topoi.pooq.com> <20080408231541.GA31929@topoi.pooq.com> <20080408233338.GA32037@topoi.pooq.com> <20080409000207.GA32073@topoi.pooq.com> <20080409003329.GB32073@topoi.pooq.com> <20080409011742.GD32073@topoi.pooq.com> <20080409012411.GE32073@topoi.pooq.com> Message-ID: <20080409022529.GF32073@topoi.pooq.com> On Tue, Apr 08, 2008 at 09:24:11PM -0400, hendrik at topoi.pooq.com wrote: > On Tue, Apr 08, 2008 at 09:17:42PM -0400, hendrik at topoi.pooq.com wrote: > > On Wed, Apr 09, 2008 at 12:57:39AM +0000, Jay wrote: > > > "Rushing through the dialogues" is a new feature. I kept complaining > > about how dumb it was. On NT386* at least, I stopped using cminstall > > altogether. There is an -interactive option or somesuch. > > > > > > > > - Jay > > > > > > > But I suspect finding nonexistent files isn't a feature, new or old. Is > > it going to cause trouble later on? Is it going to try to install > > things that depend on postgres and odbc and fall apart? > > The -interactive option gives me interaction. But it still finds the > nonexistent libpq.so in /usr/lib. > > Where are the Postgres95 libraries? > looking for library file(s): libpq.so > checking for library files in directory /usr/lib... not found > checking for library files in directory /usr/local/postgres95/lib... > not found > checking for library files in directory /usr/local/lib... not found > checking for directory /usr/lib... found > > 1: /usr/lib > Where are the Postgres95 libraries? [/usr/lib](1 of 1) > > > Only after I accept the default location does it notice threre's no such > file there. I find this confusing, because it correctly fails to find > in in all the other locations. > > But I guess I can live with this, because it gives me the chance to say: > > The libraries libpq.so are not present in the chosen directory. > Would you like to change the library names? [yes] no > Would you like to continue nonetheless? [yes] yes > > Thanks. > > -- hendrik Well, it's working now. My trouble do suggest to me that the downloads and instructions obtained from http://modula3.elegosoft.com/cm3/installation.html may no longer work properly. The ones that worked for me were http://modula3.elegosoft.com/cm3/install-cm3-on-ubuntu-7-10.html Further, the noninteractive default for cminstall is quite confusing. The instructions should recommend the -interactive option. Finally, I kept typing cm3 --version instead of cm3 -version The double hyphen is such a standard on other software that it should perhaps be accepted here, too. -- hendrik From wagner at elegosoft.com Wed Apr 9 09:05:49 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 09 Apr 2008 09:05:49 +0200 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080409011418.GC32073@topoi.pooq.com> References: <8534D782-331B-40AA-9AE6-6654306C0E3B@cs.purdue.edu> <20080406134933.GA28414@topoi.pooq.com> <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> <20080408171734.GA31674@topoi.pooq.com> <20080408231541.GA31929@topoi.pooq.com> <20080408233338.GA32037@topoi.pooq.com> <20080409000207.GA32073@topoi.pooq.com> <20080409011418.GC32073@topoi.pooq.com> Message-ID: <20080409090549.cdpk2tjocgg0wcg8@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > On Wed, Apr 09, 2008 at 01:00:20AM +0000, Jay wrote: >> Right. >> This is a normal symptom of using an "old" compiler to compile >> current source. >> You must first build a new compiler against an old runtime (which >> you must get from "somewhere", such as an existing older install), >> then use that to build a new runtime. >> >> scripts/upgrade.sh >> scripts/python/upgrade.py >> scripts/win/upgrade.cmd >> >> should all handle the "dance" for you. >> >> - Jay > > Except I don't *have* a working old runtime. I've mentioned my > experiences with > ../cm3-min-POSIX-LINUXLIBC6-d5.7.0-2008-04-08-14-00-05.tgz > in another post. I acquired it in the hope that it wouldn't be an old > runtime. Three short notes: o cminstall didn't find the non-existent libraries, it just checked the existence of a directory: checking for library files in directory /usr/local/lib... not found ^^^^^^^^^^^^^^^^^^^^^^^^^^ checking for directory /usr/lib... found ^^^^^^^^^^^^^ o Your compiler didn't have LONGINT support, so you need to use upgrade.sh. This should be documented (I think it is), as the introduction of LONGINT was an incompatible change wrt. bootstrapping. o cm3-min-POSIX-LINUXLIBC6-d5.7.0-2008-04-08-14-00-05.tgz should contain a new compiler and a new runtime, so there's no need for bootstrapping cm3, only normal package compilation. Realclean is required though to remove old derived 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 hendrik at topoi.pooq.com Wed Apr 9 14:29:12 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 9 Apr 2008 08:29:12 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080409090549.cdpk2tjocgg0wcg8@mail.elegosoft.com> References: <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> <20080408171734.GA31674@topoi.pooq.com> <20080408231541.GA31929@topoi.pooq.com> <20080408233338.GA32037@topoi.pooq.com> <20080409000207.GA32073@topoi.pooq.com> <20080409011418.GC32073@topoi.pooq.com> <20080409090549.cdpk2tjocgg0wcg8@mail.elegosoft.com> Message-ID: <20080409122912.GA1060@topoi.pooq.com> On Wed, Apr 09, 2008 at 09:05:49AM +0200, Olaf Wagner wrote: > Quoting hendrik at topoi.pooq.com: > > >On Wed, Apr 09, 2008 at 01:00:20AM +0000, Jay wrote: > >>Right. > >>This is a normal symptom of using an "old" compiler to compile > >>current source. > >>You must first build a new compiler against an old runtime (which > >>you must get from "somewhere", such as an existing older install), > >>then use that to build a new runtime. > >> > >> scripts/upgrade.sh > >> scripts/python/upgrade.py > >> scripts/win/upgrade.cmd > >> > >>should all handle the "dance" for you. > >> > >> - Jay > > > >Except I don't *have* a working old runtime. I've mentioned my > >experiences with > >../cm3-min-POSIX-LINUXLIBC6-d5.7.0-2008-04-08-14-00-05.tgz > >in another post. I acquired it in the hope that it wouldn't be an old > >runtime. > > Three short notes: > > o cminstall didn't find the non-existent libraries, it just checked > the existence of a directory: > > checking for library files in directory /usr/local/lib... not found > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > checking for directory /usr/lib... found > ^^^^^^^^^^^^^ That explains the messages. Thanks. > > o Your compiler didn't have LONGINT support, so you need to use > upgrade.sh. This should be documented (I think it is), as the > introduction of LONGINT was an incompatible change wrt. > bootstrapping. I was doing a new install. The first installation (the stable release obtained from the .tgz archives) crashed. I was advised to use the latest version from cvs, which failed because of the LONGINT problem and the fact I was still using the old cminstall file for bootstrapping. Finally I found a new place to get a new cminstall, and that one finally worked. > > o cm3-min-POSIX-LINUXLIBC6-d5.7.0-2008-04-08-14-00-05.tgz > should contain a new compiler and a new runtime, so there's > no need for bootstrapping cm3, only normal package compilation. And this should be documented somewhere on the installation and download pages, which is what a beginner sees. A beginner, who wasn't already sold on the virtues of Modula 3, would have given up long before I did. > Realclean is required though to remove old derived files. That's something I hadn't heard of. It looks useful. Where is it documented? -- hendrik From wagner at elegosoft.com Wed Apr 9 14:54:08 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 09 Apr 2008 14:54:08 +0200 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080409122912.GA1060@topoi.pooq.com> References: <080C6DF7-0249-4E17-B011-B8B96A93DAC1@cs.purdue.edu> <20080407013918.GA29466@topoi.pooq.com> <20080408171734.GA31674@topoi.pooq.com> <20080408231541.GA31929@topoi.pooq.com> <20080408233338.GA32037@topoi.pooq.com> <20080409000207.GA32073@topoi.pooq.com> <20080409011418.GC32073@topoi.pooq.com> <20080409090549.cdpk2tjocgg0wcg8@mail.elegosoft.com> <20080409122912.GA1060@topoi.pooq.com> Message-ID: <20080409145408.ekn7fszvrk8084ko@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > On Wed, Apr 09, 2008 at 09:05:49AM +0200, Olaf Wagner wrote: >> Three short notes: >> o cminstall didn't find the non-existent libraries, it just checked >> the existence of a directory: >> >> checking for library files in directory /usr/local/lib... not found >> ^^^^^^^^^^^^^^^^^^^^^^^^^^ >> checking for directory /usr/lib... found >> ^^^^^^^^^^^^^ > That explains the messages. Thanks. >> >> o Your compiler didn't have LONGINT support, so you need to use >> upgrade.sh. This should be documented (I think it is), as the >> introduction of LONGINT was an incompatible change wrt. >> bootstrapping. > > I was doing a new install. The first installation (the stable > release obtained from the .tgz archives) crashed. I was advised to use > the latest version from cvs, which failed because of the LONGINT > problem and the fact I was still using the old cminstall file for > bootstrapping. Finally I found a new place to get a new cminstall, and > that one finally worked. > >> o cm3-min-POSIX-LINUXLIBC6-d5.7.0-2008-04-08-14-00-05.tgz >> should contain a new compiler and a new runtime, so there's >> no need for bootstrapping cm3, only normal package compilation. > > And this should be documented somewhere on the installation and download > pages, which is what a beginner sees. A beginner, who wasn't already > sold on the virtues of Modula 3, would have given up long before I did. > >> Realclean is required though to remove old derived files. > > That's something I hadn't heard of. It looks useful. Where is it > documented? Hi, I agree that the documentation is probably neither consistent nor complete not completely up-to-date :-/ I'm working on it when I've got some spare time, but currently I'm really busy and can spare none. Would you mind providing some patches to cm3/www that address at least the problems you encountered? That would be very helpful. I'll ship them to our WWW server on the request of any m3devel member. Thanks in advance for any doc contributions (from you or others), Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From mika at async.caltech.edu Thu Apr 10 12:41:12 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 10 Apr 2008 03:41:12 -0700 Subject: [M3devel] set relationships? In-Reply-To: Your message of "Mon, 07 Apr 2008 00:52:10 -0000." Message-ID: <200804101041.m3AAfCKQ099273@camembert.async.caltech.edu> I think the point is, <= for sets, in the form you describe, defines a partial order. There are libraries full of math books describing what you can and can't do with partial orders. And yes all your examples should be all false. Mika Jay writes: >--_dbaf03aa-e4eb-4ef2-8579-90576f2305db_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >oops -- I mean they are all false. > > >From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Mon, 7 Apr 2008 00:= >38:01 +0000Subject: [M3devel] set relationships? > > >I'm looking at test p1\p155.I haven't started debugging it, just trying to = >understand it. C:\dev2\cm3\doc\reference\relations.html:" infix <=3D= >, >=3D ... (x,y: Set) : BOOLEAN ... <=3D returns TRUE if every element= > of x is an element of y....The expression x >=3D y is equivalent to y <=3D= > x. ...In all cases, x < y means (x <=3D y) AND (x # y), and x > y means y = >< x" Let's just use the sets {1} and {2}. {1} <=3D {2} {2} <=3D {1} {= >1} < {2} {2} < {1} {1} >=3D {2} {2} >=3D {1} {1} > {2} {2} > {1} = > All these expressions are true from the definitions above.Is that reasonab= >le?It seems a little strange to me. I guess I am very used to strongly orde= >red things, such that a <=3D b && a =3D> b implies a =3D=3D b, not true her= >e, and you can't have both a < b and b < a, which you have here, and that (= >a < b) =3D=3D !(a >=3D b) and similar, which is not true here. In this case= >, every relation but equality is true. - Jay= > >--_dbaf03aa-e4eb-4ef2-8579-90576f2305db_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > >oops -- I mean they are all false.


>
>
>From: jayk123 at hotmail.com
To: m3devel at elegosoft.com
Date: Mon, 7 Apr = >2008 00:38:01 +0000
Subject: [M3devel] set relationships?

> > >I'm looking at test p1\p155.
I haven't started debugging it, just trying= > to understand it.
 
C:\dev2\cm3\doc\reference\relations.html:R>"
     infix&nbs= >p;   <=3D, >=3D  ... 
(x,y: Set) &nbs= >p;   : BOOLEAN

 
... <=3D returns= > TRUE if every element of x is an element of y.<= >BR>...
The expression x >=3D y is equivalent to y <= >=3D x.
...
In all cases, x < y means (x <=3D= > y) AND (x # y), and x > y means y < x
= >"
 
Let's just use the sets {1} and {2}.
 
 = >; {1} <=3D {2}
  {2} <=3D {1}
  {1} < {2}
&n= >bsp; {2} < {1}
  {1} >=3D {2}
  {2} >= >=3D {1}
  {1} > {2}
  {2} > {1}
 = >;
All these expressions are true from the definitions above.
Is that = >reasonable?
It seems a little strange to me.
 
I guess I am v= >ery used to strongly ordered things, such that a <=3D b && a =3D= >> b implies a =3D=3D b, not true here, and you can't have both= > a < b and b < a, which you have here, and that (a < b) =3D=3D !(a= > >=3D b) and similar, which is not true here. In this case, every relati= >on but equality is true.
 
 - Jay

y> >= > >--_dbaf03aa-e4eb-4ef2-8579-90576f2305db_-- From hosking at cs.purdue.edu Thu Apr 10 14:29:38 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 10 Apr 2008 08:29:38 -0400 Subject: [M3devel] Fwd: Output from "cron" command References: <200804101030.m3AAU76w002296@niagara.cs.purdue.edu> Message-ID: <81A65E59-E09B-49C4-A7DE-DD139A219A2D@cs.purdue.edu> Regressions are broken... Begin forwarded message: > From: Tony Hosking > Date: April 10, 2008 6:30:07 AM GMT-04:00 > To: hosking at cs.purdue.edu > Subject: Output from "cron" command > > Your "cron" job on niagara.cs.purdue.edu > $HOME/cm3/scripts/regression/cron.sh > > produced the following output: > > ./tinderbox-build.sh: syntax error at line 270: `R=$' unexpected > ./tinderbox-build.sh: syntax error at line 270: `R=$' unexpected -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Apr 10 14:41:10 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 10 Apr 2008 12:41:10 +0000 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: <81A65E59-E09B-49C4-A7DE-DD139A219A2D@cs.purdue.edu> References: <200804101030.m3AAU76w002296@niagara.cs.purdue.edu> <81A65E59-E09B-49C4-A7DE-DD139A219A2D@cs.purdue.edu> Message-ID: This was surely my attempt at "fixing" them to honor my $CVSROOT. It worked for me on Cygwin..my checkin comment was "good" -- it said I don't know if it was bash or Cygwin specific. C:\dev2\cm3.2\scripts\regression\cm3.build# checkout the current cm3 regression script and source it(echo $CVSROOT | grep @m3.elegosoft.com:/usr/cvs > /dev/null) || CVSROOT=":ext:modula3.elegosoft.com:/usr/cvs" cvs -d $CVSROOT checkout -A \ -d ${REGRESSION_SCRIPTS_DIR} cm3/scripts/regression/defs.sh Can you quickly/easily massage that into something more portable? Otherwise I'll just put back. I have hardly gotten anywhere trying to run the Tinderbox stuff, but can run various tests manually.. Looks like I'm getting a cheap Sun machine from eBay..might be a bit interesting... - Jay From: hosking at cs.purdue.eduTo: m3devel at elegosoft.comDate: Thu, 10 Apr 2008 08:29:38 -0400Subject: [M3devel] Fwd: Output from "cron" command Regressions are broken... Begin forwarded message: From: Tony Hosking Date: April 10, 2008 6:30:07 AM GMT-04:00 To: hosking at cs.purdue.edu Subject: Output from "cron" command Your "cron" job on niagara.cs.purdue.edu$HOME/cm3/scripts/regression/cron.shproduced the following output:./tinderbox-build.sh: syntax error at line 270: `R=$' unexpected./tinderbox-build.sh: syntax error at line 270: `R=$' unexpected -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Apr 10 14:46:10 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 10 Apr 2008 12:46:10 +0000 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: References: <200804101030.m3AAU76w002296@niagara.cs.purdue.edu> <81A65E59-E09B-49C4-A7DE-DD139A219A2D@cs.purdue.edu> Message-ID: > I have hardly gotten anywhere trying to run the Tinderbox stuff, but can run various tests manually.. The first problem is finding distributions to download. Maybe it can fallback to that less tested directory where I have put stuff (which reminds me, I should delete what is there and put up newer...) - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; m3devel at elegosoft.comDate: Thu, 10 Apr 2008 12:41:10 +0000Subject: Re: [M3devel] Fwd: Output from "cron" command This was surely my attempt at "fixing" them to honor my $CVSROOT.It worked for me on Cygwin..my checkin comment was "good" -- it said I don't know if it was bash or Cygwin specific. C:\dev2\cm3.2\scripts\regression\cm3.build# checkout the current cm3 regression script and source it(echo $CVSROOT | grep @m3.elegosoft.com:/usr/cvs > /dev/null) || CVSROOT=":ext:modula3.elegosoft.com:/usr/cvs"cvs -d $CVSROOT checkout -A \ -d ${REGRESSION_SCRIPTS_DIR} cm3/scripts/regression/defs.shCan you quickly/easily massage that into something more portable?Otherwise I'll just put back. I have hardly gotten anywhere trying to run the Tinderbox stuff, but can run various tests manually.. Looks like I'm getting a cheap Sun machine from eBay..might be a bit interesting... - Jay From: hosking at cs.purdue.eduTo: m3devel at elegosoft.comDate: Thu, 10 Apr 2008 08:29:38 -0400Subject: [M3devel] Fwd: Output from "cron" command Regressions are broken... Begin forwarded message: From: Tony Hosking Date: April 10, 2008 6:30:07 AM GMT-04:00 To: hosking at cs.purdue.edu Subject: Output from "cron" command Your "cron" job on niagara.cs.purdue.edu$HOME/cm3/scripts/regression/cron.shproduced the following output:./tinderbox-build.sh: syntax error at line 270: `R=$' unexpected./tinderbox-build.sh: syntax error at line 270: `R=$' unexpected -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu Apr 10 15:19:07 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 10 Apr 2008 09:19:07 -0400 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080409145408.ekn7fszvrk8084ko@mail.elegosoft.com> References: <20080408171734.GA31674@topoi.pooq.com> <20080408231541.GA31929@topoi.pooq.com> <20080408233338.GA32037@topoi.pooq.com> <20080409000207.GA32073@topoi.pooq.com> <20080409011418.GC32073@topoi.pooq.com> <20080409090549.cdpk2tjocgg0wcg8@mail.elegosoft.com> <20080409122912.GA1060@topoi.pooq.com> <20080409145408.ekn7fszvrk8084ko@mail.elegosoft.com> Message-ID: <20080410131907.GA2401@topoi.pooq.com> Looking at your message, and trying to imagine the documentation changes, it suddenly doesn't seem so easy. For one thing, I'm not familiar enough with the various systems to know what to say. On Wed, Apr 09, 2008 at 02:54:08PM +0200, Olaf Wagner wrote: > Quoting hendrik at topoi.pooq.com: > > >On Wed, Apr 09, 2008 at 09:05:49AM +0200, Olaf Wagner wrote: > >>Three short notes: > >> o cminstall didn't find the non-existent libraries, it just checked > >> the existence of a directory: > >> > >> checking for library files in directory /usr/local/lib... not found > >> ^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> checking for directory /usr/lib... found > >> ^^^^^^^^^^^^^ > > >That explains the messages. Thanks. > >> > >> o Your compiler didn't have LONGINT support, so you need to use > >> upgrade.sh. This should be documented (I think it is), as the > >> introduction of LONGINT was an incompatible change wrt. > >> bootstrapping. ********** > > > >I was doing a new install. The first installation (the stable > >release obtained from the .tgz archives) crashed. This crash isn't a matter of a documentation change. If the stable release crashes during installation, it probably need to be replaced with one that doesn't crash. Or is that just a problem on Ubuntu, Debian and related distributions? The http://modula3.elegosoft.com/cm3/ page says only: : If you would like to : : * install on Ubuntu, Debian or a related distribution, or : * install a recent snapshot of CM3, : you will want to read these more specific installation instructions. : Alternatively, continue reading the general instructions below. Which, I suppose wasn't worded strongly enough to warn me off the "more general" method. Perhaps it should say, : you will need to use these different installation instructions,. : Otherwise, continue reading the general instructions below. ********** On the page of "CM3 5.5.1 Installation on Ubuntu 7.10 and Similar GNU/Linux Distributions" there's a list of software you should already have installed. It should include cvs. ********** > I was advised to use > >the latest version from cvs, which failed because of the LONGINT > >problem and the fact I was still using the old cminstall file for > >bootstrapping. I gather that normally there isn't a bootstrapping problem from one compiler to the next. The CVS instructions should mention that you have to start with a new cm3-min- file, and not proceed from the old compiler, or and old cm3-min-. And, in fact, they do. So this was my fault for not noticing it. A friend of mine once said that his mother was a superhero, and that her superpower was the ability to follow instructions correctly. I'm starting to realize how true that is. *********** When it says, : the newest available stable tarballs (version 5.4.0) are too old. it should perhaps say that they do not work, as : the newest available stable tarballs (version 5.4.0) are too old and : do not work. By the way, what was too old about them -- are they no longer compatible with current versions of Ubuntu, Debian, or other related distributions? *********** > > > >> o cm3-min-POSIX-LINUXLIBC6-d5.7.0-2008-04-08-14-00-05.tgz > >> should contain a new compiler and a new runtime, so there's > >> no need for bootstrapping cm3, only normal package compilation. Do you mean that there was no reason to run the commands ./do-cm3-core.sh buildship ./install-cm3-compiler.sh upgrade ? ********** > >> Realclean is required though to remove old derived files. > > > >That's something I hadn't heard of. It looks useful. Where is it > >documented? And I have no idea how to document Realclean, or even how to use it. I've found the cm3 option cm3 -clean . Is realclean something like this, as cm3 -realclean ? And if so, what is the difference? > > Hi, > > I agree that the documentation is probably neither consistent nor > complete not completely up-to-date :-/ > > I'm working on it when I've got some spare time, but currently > I'm really busy and can spare none. Would you mind providing some > patches to cm3/www that address at least the problems you encountered? > That would be very helpful. I'd be happy to try. -- hendrik > > I'll ship them to our WWW server on the request of any m3devel > member. > > Thanks in advance for any doc contributions (from you or others), > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 10 17:14:44 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 10 Apr 2008 17:14:44 +0200 Subject: [M3devel] trouble installing on a Debian lenny system. In-Reply-To: <20080410131907.GA2401@topoi.pooq.com> References: <20080408171734.GA31674@topoi.pooq.com> <20080408231541.GA31929@topoi.pooq.com> <20080408233338.GA32037@topoi.pooq.com> <20080409000207.GA32073@topoi.pooq.com> <20080409011418.GC32073@topoi.pooq.com> <20080409090549.cdpk2tjocgg0wcg8@mail.elegosoft.com> <20080409122912.GA1060@topoi.pooq.com> <20080409145408.ekn7fszvrk8084ko@mail.elegosoft.com> <20080410131907.GA2401@topoi.pooq.com> Message-ID: <20080410171444.n9kt2aim68oss00w@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > Looking at your message, and trying to imagine the documentation > changes, it suddenly doesn't seem so easy. For one thing, I'm not > familiar enough with the various systems to know what to say. In Germany we've got a saying `the devil lurks in the details'; don't know if that is known to English speaking people, too :-) > On Wed, Apr 09, 2008 at 02:54:08PM +0200, Olaf Wagner wrote: >> Quoting hendrik at topoi.pooq.com: >> >> >On Wed, Apr 09, 2008 at 09:05:49AM +0200, Olaf Wagner wrote: >> >I was doing a new install. The first installation (the stable >> >release obtained from the .tgz archives) crashed. > > This crash isn't a matter of a documentation change. If the stable > release crashes during installation, it probably need to be replaced > with one that doesn't crash. Or is that just a problem on Ubuntu, > Debian and related distributions? > > The http://modula3.elegosoft.com/cm3/ page says only: > > : If you would like to > : > : * install on Ubuntu, Debian or a related distribution, or > : * install a recent snapshot of CM3, > > : you will want to read these more specific installation instructions. > > : Alternatively, continue reading the general instructions below. > > Which, I suppose wasn't worded strongly enough to warn me off the "more > general" method. > > Perhaps it should say, > > : you will need to use these different installation instructions,. > > : Otherwise, continue reading the general instructions below. Sounds good. > ********** > > On the page of "CM3 5.5.1 Installation on Ubuntu 7.10 and Similar > GNU/Linux Distributions" > > there's a list of software you should already have installed. It should > include cvs. OK. But you can get the daily source snapshots without CVS, too. > ********** > >> I was advised to use >> >the latest version from cvs, which failed because of the LONGINT >> >problem and the fact I was still using the old cminstall file for >> >bootstrapping. > > I gather that normally there isn't a bootstrapping problem from one > compiler to the next. The CVS instructions should mention that > you have to start with a new cm3-min- file, and not proceed from the old > compiler, or and old cm3-min-. And, in fact, they do. So this was my > fault for not noticing it. > > A friend of mine once said that his mother was a superhero, and that her > superpower was the ability to follow instructions correctly. I'm > starting to realize how true that is. :-) > *********** > > When it says, > > : the newest available stable tarballs (version 5.4.0) are too old. > > it should perhaps say that they do not work, as > > : the newest available stable tarballs (version 5.4.0) are too old and > : do not work. OK. > By the way, what was too old about them -- are they no longer compatible > with current versions of Ubuntu, Debian, or other related > distributions? IIRC, the problem is that these systems encrypt their jmp_bufs which are used for user threads in M3. I don't know if this can be turned off globally. I'm also not sure if there wasn't something else. Perhaps somebody else remembers? > *********** > >> >> o cm3-min-POSIX-LINUXLIBC6-d5.7.0-2008-04-08-14-00-05.tgz >> >> should contain a new compiler and a new runtime, so there's >> >> no need for bootstrapping cm3, only normal package compilation. > > Do you mean that there was no reason to run the commands > > ./do-cm3-core.sh buildship > > ./install-cm3-compiler.sh upgrade > > ? Yes. If the compiler works, it's up-to-date, as is m3core and libm3. Everything that is not contained can then be compiled. > ********** > >> >> Realclean is required though to remove old derived files. >> > >> >That's something I hadn't heard of. It looks useful. Where is it >> >documented? > > And I have no idea how to document Realclean, or even how to use it. > I've found the cm3 option > > cm3 -clean > > . Is realclean something like this, as > > cm3 -realclean > > ? And if so, what is the difference? No, there's no cm3 -realclean. It's only a command for the scripts, as in scripts/do-cm3-all.sh realclean which performs rm -rf $TARGET in every package. >> Hi, >> >> I agree that the documentation is probably neither consistent nor >> complete not completely up-to-date :-/ >> >> I'm working on it when I've got some spare time, but currently >> I'm really busy and can spare none. Would you mind providing some >> patches to cm3/www that address at least the problems you encountered? >> That would be very helpful. > > I'd be happy to try. Great. I hope the remarks above will help. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 10 18:56:13 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 10 Apr 2008 12:56:13 -0400 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: References: <200804101030.m3AAU76w002296@niagara.cs.purdue.edu> <81A65E59-E09B-49C4-A7DE-DD139A219A2D@cs.purdue.edu> Message-ID: <2B8FF29D-E004-4F74-A60C-F215814BAFDC@cs.purdue.edu> I don't even use $CVSROOT generally, so it probably should not be assumed. I don't have the time to fix this right now. On Apr 10, 2008, at 8:41 AM, Jay wrote: > This was surely my attempt at "fixing" them to honor my $CVSROOT. > It worked for me on Cygwin..my checkin comment was "good" -- it said > I don't know if it was bash or Cygwin specific. > > C:\dev2\cm3.2\scripts\regression\cm3.build > > # checkout the current cm3 regression script and source it > (echo $CVSROOT | grep @m3.elegosoft.com:/usr/cvs > /dev/null) || > CVSROOT=":ext:modula3.elegosoft.com:/usr/cvs" > > > cvs -d $CVSROOT checkout -A \ > -d ${REGRESSION_SCRIPTS_DIR} cm3/scripts/regression/defs.sh > > > Can you quickly/easily massage that into something more portable? > Otherwise I'll just put back. I have hardly gotten anywhere trying > to run the Tinderbox stuff, but can run various tests manually.. > > Looks like I'm getting a cheap Sun machine from eBay..might be a bit > interesting... > > - Jay > > From: hosking at cs.purdue.edu > To: m3devel at elegosoft.com > Date: Thu, 10 Apr 2008 08:29:38 -0400 > Subject: [M3devel] Fwd: Output from "cron" command > > Regressions are broken... > > Begin forwarded message: > From: Tony Hosking > Date: April 10, 2008 6:30:07 AM GMT-04:00 > To: hosking at cs.purdue.edu > Subject: Output from "cron" command > > Your "cron" job on niagara.cs.purdue.edu > $HOME/cm3/scripts/regression/cron.sh > > produced the following output: > > ./tinderbox-build.sh: syntax error at line 270: `R=$' unexpected > ./tinderbox-build.sh: syntax error at line 270: `R=$' unexpected > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Thu Apr 10 21:46:29 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 10 Apr 2008 14:46:29 -0500 Subject: [M3devel] Need CVS help fixing log message Message-ID: <47FE6E95.4070405@wichita.edu> I committed a bunch of files and mistakenly used -m when I should have used -F. The result is, the log message is a local path to a file. My CVS book shows a -m option to cvs admin to repair log messages, but nothing that does what the -F option to commit does. My log message has several lines. How can I fix the logs? Is there an equivalent to admin -F? Will the -m accept newlines between the quotes? -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From wagner at elegosoft.com Thu Apr 10 22:45:24 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 10 Apr 2008 22:45:24 +0200 Subject: [M3devel] Need CVS help fixing log message In-Reply-To: <47FE6E95.4070405@wichita.edu> References: <47FE6E95.4070405@wichita.edu> Message-ID: <20080410224524.tnubedsin4cck4ks@mail.elegosoft.com> Quoting "Rodney M. Bates" : > I committed a bunch of files and mistakenly used -m when I should > have used -F. The result is, the log message is a local path to > a file. My CVS book shows a -m option to cvs admin to repair log > messages, but nothing that does what the -F option to commit does. > My log message has several lines. How can I fix the logs? Is there > an equivalent to admin -F? Will the -m accept newlines between the > quotes? Use something like cvs admin -m1.24:'line 1 line 2 line 3' fn Note that it is based on the RCS revision; so you've got to do it for each file with the correct revision number. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Sat Apr 12 22:54:16 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 12 Apr 2008 16:54:16 -0400 Subject: [M3devel] AMD64_DARWIN Message-ID: <9CC27F14-E89D-49D8-AA69-2CC173B61CFA@cs.purdue.edu> I have successfully bootstrapped a AMD64_DARWIN (64-bit x86_64 Mac OS X) target. In order to do this I needed to upgrade the gcc-based compiler backend to a newer version. Does anyone have any objection to my checking in a newer version of m3cc, as I check in my support for AMD64_DARWIN? From rodney.bates at wichita.edu Sun Apr 13 01:02:50 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Sat, 12 Apr 2008 18:02:50 -0500 Subject: [M3devel] AMD64_DARWIN In-Reply-To: <9CC27F14-E89D-49D8-AA69-2CC173B61CFA@cs.purdue.edu> References: <9CC27F14-E89D-49D8-AA69-2CC173B61CFA@cs.purdue.edu> Message-ID: <48013F9A.6090500@wichita.edu> Short answer: No. But maybe put the old one on a branch, for thoroughness? In the past, I have made a few changes to it to support m3gdb. They might revert as a result. But I made a copy of the current m3cc, and I can't think of anything else that might be needed for that purpose, before a new version checkin. Tony Hosking wrote: > I have successfully bootstrapped a AMD64_DARWIN (64-bit x86_64 Mac OS > X) target. In order to do this I needed to upgrade the gcc-based > compiler backend to a newer version. Does anyone have any objection > to my checking in a newer version of m3cc, as I check in my support for > AMD64_DARWIN? > > -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From jayk123 at hotmail.com Sun Apr 13 00:58:14 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 12 Apr 2008 22:58:14 +0000 Subject: [M3devel] AMD64_DARWIN In-Reply-To: <48013F9A.6090500@wichita.edu> References: <9CC27F14-E89D-49D8-AA69-2CC173B61CFA@cs.purdue.edu> <48013F9A.6090500@wichita.edu> Message-ID: Rodney, I bet he is doing that already as a matter of course. And I bet he will merge your changes, and any others. I have no objection but I'm sure that was obvious. :) - Jay > Date: Sat, 12 Apr 2008 18:02:50 -0500> From: rodney.bates at wichita.edu> To: hosking at cs.purdue.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] AMD64_DARWIN> > Short answer: No. But maybe put the old one on a branch, for> thoroughness?> > In the past, I have made a few changes to it to support m3gdb. They> might revert as a result. But I made a copy of the current m3cc,> and I can't think of anything else that might be needed for that> purpose, before a new version checkin.> > Tony Hosking wrote:> > I have successfully bootstrapped a AMD64_DARWIN (64-bit x86_64 Mac OS > > X) target. In order to do this I needed to upgrade the gcc-based > > compiler backend to a newer version. Does anyone have any objection > > to my checking in a newer version of m3cc, as I check in my support for > > AMD64_DARWIN?> > > > > > -- > -------------------------------------------------------------> Rodney M. Bates, retired assistant professor> Dept. of Computer Science, Wichita State University> Wichita, KS 67260-0083> 316-978-3922> rodney.bates at wichita.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Apr 13 01:40:28 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 12 Apr 2008 19:40:28 -0400 Subject: [M3devel] AMD64_DARWIN In-Reply-To: References: <9CC27F14-E89D-49D8-AA69-2CC173B61CFA@cs.purdue.edu> <48013F9A.6090500@wichita.edu> Message-ID: <0DE77BAB-EE98-44FA-8E56-385085E8B1EA@cs.purdue.edu> I've propagated all the prior diffs. In fact, I'll do this as a cvs import and merge so we shouldn't lose anything. There are some bugfixes for 64-bit as well, but nothing major. On Apr 12, 2008, at 6:58 PM, Jay wrote: > Rodney, I bet he is doing that already as a matter of course. And I > bet he will merge your changes, and any others. > I have no objection but I'm sure that was obvious. :) > > - Jay > > > > > Date: Sat, 12 Apr 2008 18:02:50 -0500 > > From: rodney.bates at wichita.edu > > To: hosking at cs.purdue.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] AMD64_DARWIN > > > > Short answer: No. But maybe put the old one on a branch, for > > thoroughness? > > > > In the past, I have made a few changes to it to support m3gdb. They > > might revert as a result. But I made a copy of the current m3cc, > > and I can't think of anything else that might be needed for that > > purpose, before a new version checkin. > > > > Tony Hosking wrote: > > > I have successfully bootstrapped a AMD64_DARWIN (64-bit x86_64 > Mac OS > > > X) target. In order to do this I needed to upgrade the gcc-based > > > compiler backend to a newer version. Does anyone have any > objection > > > to my checking in a newer version of m3cc, as I check in my > support for > > > AMD64_DARWIN? > > > > > > > > > > -- > > ------------------------------------------------------------- > > Rodney M. Bates, retired assistant professor > > Dept. of Computer Science, Wichita State University > > Wichita, KS 67260-0083 > > 316-978-3922 > > rodney.bates at wichita.edu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sun Apr 13 06:03:40 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 13 Apr 2008 00:03:40 -0400 Subject: [M3devel] AMD64_DARWIN In-Reply-To: <9CC27F14-E89D-49D8-AA69-2CC173B61CFA@cs.purdue.edu> References: <9CC27F14-E89D-49D8-AA69-2CC173B61CFA@cs.purdue.edu> Message-ID: <20080413040340.GC9473@topoi.pooq.com> On Sat, Apr 12, 2008 at 04:54:16PM -0400, Tony Hosking wrote: > I have successfully bootstrapped a AMD64_DARWIN (64-bit x86_64 Mac OS > X) target. In order to do this I needed to upgrade the gcc-based > compiler backend to a newer version. Does anyone have any objection > to my checking in a newer version of m3cc, as I check in my support > for AMD64_DARWIN? > While we're on a related subjext -- is m3 available on an AMD64 Linux box yet (in 64-bit mode)? From hosking at cs.purdue.edu Sun Apr 13 06:15:56 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 13 Apr 2008 00:15:56 -0400 Subject: [M3devel] AMD64_DARWIN In-Reply-To: <20080413040340.GC9473@topoi.pooq.com> References: <9CC27F14-E89D-49D8-AA69-2CC173B61CFA@cs.purdue.edu> <20080413040340.GC9473@topoi.pooq.com> Message-ID: <5C33687C-D899-429C-86A0-F55C2676051B@cs.purdue.edu> Not that I know, but porting to AMD64_DARWIN should give us most of what is needed for AMD64_LINUX. Stay tuned. On Apr 13, 2008, at 12:03 AM, hendrik at topoi.pooq.com wrote: > On Sat, Apr 12, 2008 at 04:54:16PM -0400, Tony Hosking wrote: >> I have successfully bootstrapped a AMD64_DARWIN (64-bit x86_64 Mac OS >> X) target. In order to do this I needed to upgrade the gcc-based >> compiler backend to a newer version. Does anyone have any objection >> to my checking in a newer version of m3cc, as I check in my support >> for AMD64_DARWIN? >> > > While we're on a related subjext -- is m3 available on an AMD64 Linux > box yet (in 64-bit mode)? From wagner at elegosoft.com Mon Apr 14 08:48:55 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 14 Apr 2008 08:48:55 +0200 Subject: [M3devel] cm3 regression Message-ID: <20080414084855.tebzp7f2cksss004@mail.elegosoft.com> Building of libm3 now fails even in release-builds with 4539 new source -> compiling SocketPosix.m3 4540 4541 NEXT Fatal Error: bad version stamps: SocketPosix.m3 4542 4543 version stamp mismatch: Compiler.Platform 4544 => SocketPosix.m3 4545 => Compiler.i3 4546 version stamp mismatch: Compiler.ThisPlatform 4547 <92d2f58d2092154f> => SocketPosix.m3 4548 => Compiler.i3 4549 NEXT *** execution of cm3 -build -DROOT=?/home/m3/work/cm3-ws/birch.elegosoft.com-2008-04-14-00-00-03/cm3? -DCM3_VERSION_TEXT=?d5.7.0? -DCM3_VERSION_NUMBER=?050700? -DCM3_LAST_CHANGED=?2008-03-16? && cm3 -ship -DROOT=?/home/m3/work/cm3-ws/birch.elegosoft.com-2008-04-14-00-00-03/cm3? -DCM3_VERSION_TEXT=?d5.7.0? -DCM3_VERSION_NUMBER=?050700? -DCM3_LAST_CHANGED=?2008-03-16? failed *** 4550 compile return value: 0 4551 [end compile 2008.04.14 02:54:34] 4552 *** COMPILE FAILED Does anybody understand what's going on? During upgrade(), libm3 should only be built _after_ the new compiler has been installed, at least that is the intention. I'm in a hurry, so if anybody else cares to fix this, it would be great. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 14 08:52:52 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 14 Apr 2008 08:52:52 +0200 Subject: [M3devel] cm3 regression In-Reply-To: <20080414084855.tebzp7f2cksss004@mail.elegosoft.com> References: <20080414084855.tebzp7f2cksss004@mail.elegosoft.com> Message-ID: <20080414085252.mzhkll84kk408gso@mail.elegosoft.com> Quoting Olaf Wagner : > Building of libm3 now fails even in release-builds with > > 4539 new source -> compiling SocketPosix.m3 > 4540 > 4541 NEXT Fatal Error: bad version stamps: SocketPosix.m3 > 4542 > 4543 version stamp mismatch: Compiler.Platform > 4544 => SocketPosix.m3 > 4545 => Compiler.i3 > 4546 version stamp mismatch: Compiler.ThisPlatform > 4547 <92d2f58d2092154f> => SocketPosix.m3 > 4548 => Compiler.i3 > 4549 NEXT *** execution of cm3 -build > -DROOT=?/home/m3/work/cm3-ws/birch.elegosoft.com-2008-04-14-00-00-03/cm3? > -DCM3_VERSION_TEXT=?d5.7.0? -DCM3_VERSION_NUMBER=?050700? > -DCM3_LAST_CHANGED=?2008-03-16? && cm3 -ship > -DROOT=?/home/m3/work/cm3-ws/birch.elegosoft.com-2008-04-14-00-00-03/cm3? > -DCM3_VERSION_TEXT=?d5.7.0? -DCM3_VERSION_NUMBER=?050700? > -DCM3_LAST_CHANGED=?2008-03-16? failed *** > 4550 compile return value: 0 > 4551 [end compile 2008.04.14 02:54:34] > 4552 *** COMPILE FAILED > > Does anybody understand what's going on? > During upgrade(), libm3 should only be built _after_ the new compiler > has been installed, at least that is the intention. > > I'm in a hurry, so if anybody else cares to fix this, it would be great. I sent that mail too fast. It seems that only I386_DARWIN fails in the release-build, but for other reasons. The last-ok builds can be expexted to fail after incompatible changes in the runtime. So this should cure itself during the next days. We should however note that we need a full compiler bootstrap again even from older d5.7.0 archives now to compile current sources. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Mon Apr 14 09:17:53 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 14 Apr 2008 07:17:53 +0000 Subject: [M3devel] cm3 regression In-Reply-To: <20080414085252.mzhkll84kk408gso@mail.elegosoft.com> References: <20080414084855.tebzp7f2cksss004@mail.elegosoft.com> <20080414085252.mzhkll84kk408gso@mail.elegosoft.com> Message-ID: new source -> compiling Cstdlib.i3"..\src\C\32BITS\BasicCtypes.i3", line 18: illegal based LONGINT literal, zero used"..\src\C\32BITS\BasicCtypes.i3", line 18: illegal based LONGINT literal, zero used long_long = [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL]; Why isn't this LONGINT? So that NT386 can limp along? And it'd be correct for the rest, eh? I'll try it and see.. The underlying system (the compiler) has (U)Int[8,16,32,64] They should just be used here imho.. Also, what should "long" be on 64bit? On Windows it is 32 bits always. On 32 bit systems it is 32 bits. I think the 64bits directory is going to be forked for AMD64_NT_*. The Windows decision imho has successfully been applied to more code and more users so therefore is better by practical success, even if the whole issue is problematic almost no matter what. Clearly the C and Modula-3 notions of integers are pretty poor.. - Jay > Date: Mon, 14 Apr 2008 08:52:52 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] cm3 regression> > Quoting Olaf Wagner :> > > Building of libm3 now fails even in release-builds with> >> > 4539 new source -> compiling SocketPosix.m3> > 4540> > 4541 NEXT Fatal Error: bad version stamps: SocketPosix.m3> > 4542> > 4543 version stamp mismatch: Compiler.Platform> > 4544 => SocketPosix.m3> > 4545 => Compiler.i3> > 4546 version stamp mismatch: Compiler.ThisPlatform> > 4547 <92d2f58d2092154f> => SocketPosix.m3> > 4548 => Compiler.i3> > 4549 NEXT *** execution of cm3 -build> > -DROOT=?/home/m3/work/cm3-ws/birch.elegosoft.com-2008-04-14-00-00-03/cm3?> > -DCM3_VERSION_TEXT=?d5.7.0? -DCM3_VERSION_NUMBER=?050700?> > -DCM3_LAST_CHANGED=?2008-03-16? && cm3 -ship> > -DROOT=?/home/m3/work/cm3-ws/birch.elegosoft.com-2008-04-14-00-00-03/cm3?> > -DCM3_VERSION_TEXT=?d5.7.0? -DCM3_VERSION_NUMBER=?050700?> > -DCM3_LAST_CHANGED=?2008-03-16? failed ***> > 4550 compile return value: 0> > 4551 [end compile 2008.04.14 02:54:34]> > 4552 *** COMPILE FAILED> >> > Does anybody understand what's going on?> > During upgrade(), libm3 should only be built _after_ the new compiler> > has been installed, at least that is the intention.> >> > I'm in a hurry, so if anybody else cares to fix this, it would be great.> > I sent that mail too fast. It seems that only I386_DARWIN fails in> the release-build, but for other reasons. The last-ok builds can> be expexted to fail after incompatible changes in the runtime.> So this should cure itself during the next days.> > We should however note that we need a full compiler bootstrap again> even from older d5.7.0 archives now to compile current sources.> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Apr 14 09:18:35 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 14 Apr 2008 09:18:35 +0200 Subject: [M3devel] latest failure on NT386 Message-ID: <20080414091835.gm0aycpxcwg4s0k4@mail.elegosoft.com> Just when I thought that I finally might be able to run a complete regression on NT386, the compilation breaks with this: new source -> compiling Cstdlib.i3 "..\src\C\32BITS\BasicCtypes.i3", line 18: illegal based LONGINT literal, zero used "..\src\C\32BITS\BasicCtypes.i3", line 18: illegal based LONGINT literal, zero used "..\src\C\Common\Cstdlib.i3", line 13: imported interface contains errors (Ctypes) 3 errors encountered new source -> compiling Csetjmp.i3 "..\src\C\NT386\Csetjmp.i3", line 13: imported interface contains errors (Ctypes) 1 error encountered Can anybody look into 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: DE16321419 From jayk123 at hotmail.com Mon Apr 14 09:32:51 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 14 Apr 2008 07:32:51 +0000 Subject: [M3devel] latest failure on NT386 In-Reply-To: <20080414091835.gm0aycpxcwg4s0k4@mail.elegosoft.com> References: <20080414091835.gm0aycpxcwg4s0k4@mail.elegosoft.com> Message-ID: Olaf, this will fix your problem. Tony should speak to it probably before it is commited -- like if it works on AMD64_DARWIN. Here is my reluctant proposal: cvs diff: Diffing 32BITSIndex: 32BITS/BasicCtypes.i3===================================================================RCS file: /usr/cvs/cm3/m3-libs/m3core/src/C/32BITS/BasicCtypes.i3,vretrieving revision 1.10diff -c -r1.10 BasicCtypes.i3*** 32BITS/BasicCtypes.i3 13 Apr 2008 19:41:49 -0000 1.10--- 32BITS/BasicCtypes.i3 14 Apr 2008 07:20:59 -0000****************** 13,21 **** (* the four signed integer types *) signed_char = [-16_7f-1 .. 16_7f]; short_int = [-16_7fff-1 .. 16_7fff];! int = [-16_7fffffff-1 .. 16_7fffffff];! long_int = [-16_7fffffff-1 .. 16_7fffffff];! long_long = [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL]; (* the four unsigned integer types *) unsigned_char = [16_0 .. 16_ff];--- 13,21 ---- (* the four signed integer types *) signed_char = [-16_7f-1 .. 16_7f]; short_int = [-16_7fff-1 .. 16_7fff];! int = INTEGER;! long_int = INTEGER;! long_long = LONGINT; (* the four unsigned integer types *) unsigned_char = [16_0 .. 16_ff];cvs diff: Diffing 64BITSIndex: 64BITS/BasicCtypes.i3===================================================================RCS file: /usr/cvs/cm3/m3-libs/m3core/src/C/64BITS/BasicCtypes.i3,vretrieving revision 1.8diff -c -r1.8 BasicCtypes.i3*** 64BITS/BasicCtypes.i3 13 Apr 2008 19:44:02 -0000 1.8--- 64BITS/BasicCtypes.i3 14 Apr 2008 07:20:59 -0000****************** 14,21 **** signed_char = [-16_7f-1 .. 16_7f]; short_int = [-16_7fff-1 .. 16_7fff]; int = [-16_7fffffff-1 .. 16_7fffffff];! long_int = [-16_7fffffffffffffff -1 .. 16_7fffffffffffffff ];! long_long = [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL]; (* the four unsigned integer types *) unsigned_char = [16_0 .. 16_ff];--- 14,21 ---- signed_char = [-16_7f-1 .. 16_7f]; short_int = [-16_7fff-1 .. 16_7fff]; int = [-16_7fffffff-1 .. 16_7fffffff];! long_int = INTEGER;! long_long = LONGINT; (* the four unsigned integer types *) unsigned_char = [16_0 .. 16_ff]; Win64 might not be able to use this but I guess the other 64 bit systems can. The bigger point is the 32bit fix to get NT386 compiling again. Type "long" is just dumb imho.By corrolary LONGINT. There should be the explicitly sized types [u]int[8,16,32,64,more in the future] and then unsigned and signed pointer sized types aka size_t, ptrdiff_t or size_t, ssize_t or Word.T, INTEGER I think it's unfortunate that Modula-3 followed C's lead here.This is one thing C definitely did wrong.You just know, 128 bit types are going to be called "long long long".. When they should have been called like int128 and uint128 and possibly size_t, ssize_t. Arguably "size_t" should be "word". "size_t" isn't the best name probably, but I'm not fighting that one. :) (I'm not really fighting any of this; I lost already.) - Jay > Date: Mon, 14 Apr 2008 09:18:35 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: [M3devel] latest failure on NT386> > Just when I thought that I finally might be able to run a complete> regression on NT386, the compilation breaks with this:> > new source -> compiling Cstdlib.i3> "..\src\C\32BITS\BasicCtypes.i3", line 18: illegal based LONGINT > literal, zero used> "..\src\C\32BITS\BasicCtypes.i3", line 18: illegal based LONGINT > literal, zero used> "..\src\C\Common\Cstdlib.i3", line 13: imported interface contains > errors (Ctypes)> 3 errors encountered> new source -> compiling Csetjmp.i3> "..\src\C\NT386\Csetjmp.i3", line 13: imported interface contains > errors (Ctypes)> 1 error encountered> > Can anybody look into 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: DE16321419> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Apr 14 10:00:34 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 14 Apr 2008 08:00:34 +0000 Subject: [M3devel] target naming? AMD64_NT, UWIN? In-Reply-To: <20080414091835.gm0aycpxcwg4s0k4@mail.elegosoft.com> References: <20080414091835.gm0aycpxcwg4s0k4@mail.elegosoft.com> Message-ID: the old target name game Lately I'm playing around at home with AMD64 Linux and Windows.Been using AMD64 Windows a while otherwise.I've also been playing around with UWin, which is something like Cygwin.Really nothing substantial yet.Anyone else with similar inclination, go ahead. UWin has an optional runtime, and not really a toolset.It has cc, ld, ar, but cc and ld are just wrappers forVisual C++ cl/link or other alternatives like Digital Mars,Borland, etc.ar is either a link -lib wrapper or doesn't do all that much in any case. They also have ncc -- native compiler, to produce Win32 executables.pcc for Posix executables, not sure of the point. Their runtime supports fork/vfork/exec/spawn, Posix file names, pthreads.They have sh that is ksh, vi.So far gcc does not build in this environment. I tried a bit.They are a much smaller system than Cygwin.Far fewer packages. They DO have X Windows. They say they will have 64 bit soon -- presumably AMD64. (IA64?) Cygwin is fairly x86 specific at this point.I haven't seen any movement on an AMD64 port, though it probably isn't that difficult. MinGWin is out there too already of course, and has a 64 bit port (shouldn't behard to just rebuild gcc, esp. with Tony's update). Therefore there are bunch more viable targets or configurations.It is hard to even describe them, other than via the earlier proposedand essentially implemented calculus: processor + runtime + C compiler + linker + modula-3 backend processor = x86, AMD64 runtime = msvc, uwin C compiler = msvc, gcc (borland, watcom, metrowerks, etc.) (now I see a reason to eliminate C -- so it doesn't figure into the target calculus! :) ) modula-3 backend = integrated, gcc NT386.Common implements something like this, though not always correctly, just enough for the three existing instantiations to work. UWin does not provide setjmp/longjmp, good.They have sigsetjmp/siglongjmp that only adds a /small/ amount, like 2 integers or 2 pointers.I have no qualm inflating always an AMD64 jmpbuf to accomodate, if needed.Inflating the NT386 one is still tempting to reduce variety. On one hand there is a quandary of too many target combinations to consider.But on the other hand is the solution that I implemented under the covers, the above calculus.Therefore, the compiler need only know about AMD64_NT, and the rest can be just "configurations". Besides, this same answer can be applied to any 32 bit UWin target. ??? Given the "configuration" idea, I would be ok with NTAMD64, or AMD64_NT, or AMD64_MSWIN, etc.I assume most folks will chose AMD64_NT. Some other names should probably be chosen, for the Quake files. AMD64_NT_WIN_UWIN -- "native runtime" AMD64_NT_POSIX_UWIN -- posix, X Windows AMD64_NT_MINGWIN -- native runtime AMD64_NT - reserved for future port of integrated backend? But in the compiler these could all be the same. or, shorter: AMD64_UWINN - UWin native AMD64_UWINP - UWin posix AMD64_UWINX - UWin posix ? "UWIN" implies "Windows" implies "NT", so good enough? or, processor, ostype, variant, and again UWin implies NT, ostype=win implies NT?: AMD64_POSIX_UWIN AMD64_WIN_UWIN (not very interesting, really) AMD64_WIN_GCC (MinGWin) AMD64_POSIX_CYG (future) same as AMD64_CYGWIN or NTAMD64GNU?? AMD64_WIN_NATIVE -- integrated backend, msvc cl/link (future) Usually "ostype" is not interesting in targets, since nearly everything is Posix.And "variant" is just a random escape hatch to try to come up with something. ??? I know I talk more about making new targets than actually doing it, sorry. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Apr 14 11:28:07 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 14 Apr 2008 09:28:07 +0000 Subject: [M3devel] target naming? AMD64_NT, UWIN? In-Reply-To: References: <20080414091835.gm0aycpxcwg4s0k4@mail.elegosoft.com> Message-ID: > processor + runtime + C compiler + linker + modula-3 backend correction: processor + kernel/"operating system" + C runtime + C compiler + linker + modula-3 backend + gui runtime Often only the first two vary, but not always. Most systems have "native" and GNU as I understand for C compiler and linker -- Solaris, AIX, HP-UX. And then Windows has multiple compilers, linkers, runtimes. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Apr 14 14:45:15 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Apr 2008 08:45:15 -0400 Subject: [M3devel] cm3 regression In-Reply-To: References: <20080414084855.tebzp7f2cksss004@mail.elegosoft.com> <20080414085252.mzhkll84kk408gso@mail.elegosoft.com> Message-ID: <4434FAA9-237F-4977-AAB8-DDE36FB2B503@cs.purdue.edu> Yes, sorry, probably best to make it LONGINT. I'll fix. 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 Apr 14, 2008, at 3:17 AM, Jay wrote: > new source -> compiling Cstdlib.i3 > "..\src\C\32BITS\BasicCtypes.i3", line 18: illegal based LONGINT > literal, zero used > "..\src\C\32BITS\BasicCtypes.i3", line 18: illegal based LONGINT > literal, zero used > > long_long = [-16_7fffffffffffffffL-1L .. > 16_7fffffffffffffffL]; > > > Why isn't this LONGINT? So that NT386 can limp along? And it'd be > correct for the rest, eh? > I'll try it and see.. > > The underlying system (the compiler) has (U)Int[8,16,32,64] > They should just be used here imho.. > > Also, what should "long" be on 64bit? > On Windows it is 32 bits always. > On 32 bit systems it is 32 bits. > I think the 64bits directory is going to be forked for AMD64_NT_*. > The Windows decision imho has successfully been applied to more code > and more users so therefore is better by practical success, even if > the whole issue is problematic almost no matter what. Clearly the C > and Modula-3 notions of integers are pretty poor.. > > - Jay > > > > > Date: Mon, 14 Apr 2008 08:52:52 +0200 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] cm3 regression > > > > Quoting Olaf Wagner : > > > > > Building of libm3 now fails even in release-builds with > > > > > > 4539 new source -> compiling SocketPosix.m3 > > > 4540 > > > 4541 NEXT Fatal Error: bad version stamps: SocketPosix.m3 > > > 4542 > > > 4543 version stamp mismatch: Compiler.Platform > > > 4544 => SocketPosix.m3 > > > 4545 => Compiler.i3 > > > 4546 version stamp mismatch: Compiler.ThisPlatform > > > 4547 <92d2f58d2092154f> => SocketPosix.m3 > > > 4548 => Compiler.i3 > > > 4549 NEXT *** execution of cm3 -build > > > -DROOT=?/home/m3/work/cm3-ws/ > birch.elegosoft.com-2008-04-14-00-00-03/cm3? > > > -DCM3_VERSION_TEXT=?d5.7.0? -DCM3_VERSION_NUMBER=?050700? > > > -DCM3_LAST_CHANGED=?2008-03-16? && cm3 -ship > > > -DROOT=?/home/m3/work/cm3-ws/ > birch.elegosoft.com-2008-04-14-00-00-03/cm3? > > > -DCM3_VERSION_TEXT=?d5.7.0? -DCM3_VERSION_NUMBER=?050700? > > > -DCM3_LAST_CHANGED=?2008-03-16? failed *** > > > 4550 compile return value: 0 > > > 4551 [end compile 2008.04.14 02:54:34] > > > 4552 *** COMPILE FAILED > > > > > > Does anybody understand what's going on? > > > During upgrade(), libm3 should only be built _after_ the new > compiler > > > has been installed, at least that is the intention. > > > > > > I'm in a hurry, so if anybody else cares to fix this, it would > be great. > > > > I sent that mail too fast. It seems that only I386_DARWIN fails in > > the release-build, but for other reasons. The last-ok builds can > > be expexted to fail after incompatible changes in the runtime. > > So this should cure itself during the next days. > > > > We should however note that we need a full compiler bootstrap again > > even from older d5.7.0 archives now to compile current sources. > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Apr 14 14:45:37 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Apr 2008 08:45:37 -0400 Subject: [M3devel] cm3 regression In-Reply-To: <20080414085252.mzhkll84kk408gso@mail.elegosoft.com> References: <20080414084855.tebzp7f2cksss004@mail.elegosoft.com> <20080414085252.mzhkll84kk408gso@mail.elegosoft.com> Message-ID: <8F8EDEDC-5AD4-4E0E-8C88-CF597D613049@cs.purdue.edu> Some regression to be expected while dust settles from AMD64_DARWIN changes. 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 Apr 14, 2008, at 2:52 AM, Olaf Wagner wrote: > Quoting Olaf Wagner : > >> Building of libm3 now fails even in release-builds with >> >> 4539 new source -> compiling SocketPosix.m3 >> 4540 >> 4541 NEXT Fatal Error: bad version stamps: SocketPosix.m3 >> 4542 >> 4543 version stamp mismatch: Compiler.Platform >> 4544 => SocketPosix.m3 >> 4545 => Compiler.i3 >> 4546 version stamp mismatch: Compiler.ThisPlatform >> 4547 <92d2f58d2092154f> => SocketPosix.m3 >> 4548 => Compiler.i3 >> 4549 NEXT *** execution of cm3 -build >> -DROOT=?/home/m3/work/cm3-ws/ >> birch.elegosoft.com-2008-04-14-00-00-03/cm3? >> -DCM3_VERSION_TEXT=?d5.7.0? -DCM3_VERSION_NUMBER=?050700? >> -DCM3_LAST_CHANGED=?2008-03-16? && cm3 -ship >> -DROOT=?/home/m3/work/cm3-ws/ >> birch.elegosoft.com-2008-04-14-00-00-03/cm3? >> -DCM3_VERSION_TEXT=?d5.7.0? -DCM3_VERSION_NUMBER=?050700? >> -DCM3_LAST_CHANGED=?2008-03-16? failed *** >> 4550 compile return value: 0 >> 4551 [end compile 2008.04.14 02:54:34] >> 4552 *** COMPILE FAILED >> >> Does anybody understand what's going on? >> During upgrade(), libm3 should only be built _after_ the new compiler >> has been installed, at least that is the intention. >> >> I'm in a hurry, so if anybody else cares to fix this, it would be >> great. > > I sent that mail too fast. It seems that only I386_DARWIN fails in > the release-build, but for other reasons. The last-ok builds can > be expexted to fail after incompatible changes in the runtime. > So this should cure itself during the next days. > > We should however note that we need a full compiler bootstrap again > even from older d5.7.0 archives now to compile current sources. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 jayk123 at hotmail.com Mon Apr 14 16:51:37 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 14 Apr 2008 14:51:37 +0000 Subject: [M3devel] small set comparisons understood, now just to understand the front end code.. Message-ID: currently set <,>,<=,>= are implemented merely as integer <,>,<=,>= This is wrong. I believe it should be: a < b => (a & b) == a a <= b => (a & b) == a (same as <=) a > b => (a & b) == b a >= b => (a & b) == b (same as >) The bug is in the frontend. m3-sys\m3front\src\misc\CG.m3. The code should be /something/ like: PROCEDURE Set_compare (s: Size; op: Cmp) = VAR tmp: Val; swap := FALSE; BEGIN (* a op b => BOOLEAN *) IF Force_pair (commute := TRUE) THEN op := M3CG.SwappedCompare [op]; END; IF (s <= Target.Integer.size) THEN IF (op = Cmp.EQ) OR (op = Cmp.NE) THEN cg.compare (Target.Word.cg_type, Target.Integer.cg_type, op); ELSE (* set a is less than or equal to set b, if all of set a's members are in set b. *) IF (op = Cmp.LT) OR (op = Cmp.LE) THEN swap := TRUE; Swap (); END; tmp := Pop (); Push (tmp); IF swap THEN Swap (); END; cg.and (Target.Integer.cg_type); Push (tmp); SimpleIndirectLoad (tmp^, Target.Word.cg_type); EVAL Force_pair (commute := TRUE); cg.compare (Target.Word.cg_type, Target.Integer.cg_type, Cmp.EQ); SPop (1, "Set_compare"); Free (tmp); END; ELSE cg.set_compare (AsBytes (s), op, Target.Integer.cg_type); END; SPop (2, "Set_compare"); SPush (Type.Int32); END Set_compare; though this doesn't quite drive all the machinery correctly, since it yields assertion failures in the compiler due to an unbalanced software stack. upgrade works, but the test case (p155) fails assertions in the integrated backend. I'd love to figure this out but have to do other stuff for now. Anyone (if there is anyone) familiar with what all is being pushed and popped around here should be able to figure it out easily from this mail. Otherwise I'll stare at more later. ps: "small" sets should probably be anything up to the number of bits in longint, rather than int or pointer, since that is probably efficient enough at the next level down. This is tangential. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Apr 14 17:22:35 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Apr 2008 11:22:35 -0400 Subject: [M3devel] small set comparisons understood, now just to understand the front end code.. In-Reply-To: References: Message-ID: <32E9EDBE-18FC-4F1B-8653-E60FC39DD534@cs.purdue.edu> I would hesitate to implement small sets as LONGINT instead of INTEGER, since there is no guarantee that LONGINT is necessarily efficient, whereas INTEGER is intended to be the same as the natural word size of the target. I could take a look at this but not anytime soon, since I have several other things I need to work on. On Apr 14, 2008, at 10:51 AM, Jay wrote: > currently set <,>,<=,>= are implemented merely as > integer <,>,<=,>= Yes, that seems quite wrong. I can't imagine things ever worked properly if that is how they are implemented. > > > This is wrong. > > I believe it should be: > > a < b => (a & b) == a > a <= b => (a & b) == a (same as <=) > a > b => (a & b) == b > a >= b => (a & b) == b (same as >) Probably should be: a <= b => (a & b) == a a < b => (a # b) && ((a & b) == a) a >= b => (a & b) == b a > b => (a # b) && ((a & b) == b) > > > The bug is in the frontend. > > m3-sys\m3front\src\misc\CG.m3. > > The code should be /something/ like: > > PROCEDURE Set_compare (s: Size; op: Cmp) = > VAR tmp: Val; > swap := FALSE; > BEGIN > (* a op b => BOOLEAN *) > IF Force_pair (commute := TRUE) THEN > op := M3CG.SwappedCompare [op]; > END; > IF (s <= Target.Integer.size) THEN > IF (op = Cmp.EQ) OR (op = Cmp.NE) THEN > cg.compare (Target.Word.cg_type, Target.Integer.cg_type, op); > ELSE > (* set a is less than or equal to set b, if all of set a's > members are in set b. *) > IF (op = Cmp.LT) OR (op = Cmp.LE) THEN > swap := TRUE; > Swap (); > END; > tmp := Pop (); > Push (tmp); > IF swap THEN > Swap (); > END; > cg.and (Target.Integer.cg_type); > Push (tmp); > SimpleIndirectLoad (tmp^, Target.Word.cg_type); > EVAL Force_pair (commute := TRUE); > cg.compare (Target.Word.cg_type, Target.Integer.cg_type, > Cmp.EQ); > SPop (1, "Set_compare"); > Free (tmp); > END; > ELSE > cg.set_compare (AsBytes (s), op, Target.Integer.cg_type); > END; > SPop (2, "Set_compare"); > SPush (Type.Int32); > END Set_compare; > > though this doesn't quite drive all the machinery correctly, since > it yields assertion failures in the compiler due to an unbalanced > software stack. > upgrade works, but the test case (p155) fails assertions in the > integrated backend. > > I'd love to figure this out but have to do other stuff for now. > Anyone (if there is anyone) familiar with what all is being pushed > and popped around here should be able to figure it out easily from > this mail. > Otherwise I'll stare at more later. > > ps: "small" sets should probably be anything up to the number of > bits in longint, rather than int or pointer, since that is probably > efficient enough at the next level down. This is tangential. > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Apr 14 19:18:14 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 14 Apr 2008 10:18:14 -0700 Subject: [M3devel] cm3 regression In-Reply-To: Your message of "Mon, 14 Apr 2008 07:17:53 -0000." Message-ID: <200804141718.m3EHIExE075667@camembert.async.caltech.edu> Jay writes: >--_50e47a65-f79d-472b-8eaf-fbcc30b6410e_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >new source -> compiling Cstdlib.i3"..\src\C\32BITS\BasicCtypes.i3", line 18= >: illegal based LONGINT literal, zero used"..\src\C\32BITS\BasicCtypes.i3",= > line 18: illegal based LONGINT literal, zero used > long_long =3D [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL]= >; >=20 >Why isn't this LONGINT? So that NT386 can limp along? And it'd be correct f= >or the rest, eh? >I'll try it and see.. >=20 >The underlying system (the compiler) has (U)Int[8,16,32,64] >They should just be used here imho.. >=20 >Also, what should "long" be on 64bit? >On Windows it is 32 bits always. >On 32 bit systems it is 32 bits. >I think the 64bits directory is going to be forked for AMD64_NT_*. >The Windows decision imho has successfully been applied to more code and mo= >re users so therefore is better by practical success, even if the whole iss= >ue is problematic almost no matter what. Clearly the C and Modula-3 notions= > of integers are pretty poor.. I have to re-code my program to use Int64 if I want it to use the natural INTEGER size on 64 bit machines? No thanks. From jayk123 at hotmail.com Mon Apr 14 19:52:24 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 14 Apr 2008 17:52:24 +0000 Subject: [M3devel] cm3 regression In-Reply-To: <200804141718.m3EHIExE075667@camembert.async.caltech.edu> References: Your message of "Mon, 14 Apr 2008 07:17:53 -0000." <200804141718.m3EHIExE075667@camembert.async.caltech.edu> Message-ID: Well, something has to give somewhere. INTEGER could be a "natural" signed integer if you want, however you have to balance the desire for a "natural" integer with any persistant format. It's not like 32 bit integers are going to be inefficient anywhere, so not changing the more concrete meaning of various code isn't going to really hurt it. What does hurt is 1) breaking code that really needs to represent the entire address space or 2) breaking code that really needs to maintain binary compatibility with persistant file formats. You lose either way. It just seems like the best tradeoff is to provide explicitly sized signed and unsigned types, and pointer sized signed and unsigned. And then decide what your ranges are and know that 32 bit integers are always efficient and 64 bit integers are always ok or better. Really, 32 bit integers are usually adequate or no less efficient. Really, it's hard to go wrong for efficiency, 32bit or 64bit integers, and easy to go wrong in terms of compatibility by changing the sizes of types.. - Jay > To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] cm3 regression > Date: Mon, 14 Apr 2008 10:18:14 -0700> From: mika at async.caltech.edu> > Jay writes:> >--_50e47a65-f79d-472b-8eaf-fbcc30b6410e_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >new source -> compiling Cstdlib.i3"..\src\C\32BITS\BasicCtypes.i3", line 18=> >: illegal based LONGINT literal, zero used"..\src\C\32BITS\BasicCtypes.i3",=> > line 18: illegal based LONGINT literal, zero used> > long_long =3D [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL]=> >;> >=20> >Why isn't this LONGINT? So that NT386 can limp along? And it'd be correct f=> >or the rest, eh?> >I'll try it and see..> >=20> >The underlying system (the compiler) has (U)Int[8,16,32,64]> >They should just be used here imho..> >=20> >Also, what should "long" be on 64bit?> >On Windows it is 32 bits always.> >On 32 bit systems it is 32 bits.> >I think the 64bits directory is going to be forked for AMD64_NT_*.> >The Windows decision imho has successfully been applied to more code and mo=> >re users so therefore is better by practical success, even if the whole iss=> >ue is problematic almost no matter what. Clearly the C and Modula-3 notions=> > of integers are pretty poor..> > I have to re-code my program to use Int64 if I want it to use the> natural INTEGER size on 64 bit machines? No thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Apr 14 19:55:47 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 14 Apr 2008 17:55:47 +0000 Subject: [M3devel] small set comparisons understood, now just to understand the front end code.. In-Reply-To: <32E9EDBE-18FC-4F1B-8653-E60FC39DD534@cs.purdue.edu> References: <32E9EDBE-18FC-4F1B-8653-E60FC39DD534@cs.purdue.edu> Message-ID: If they fit in an INT32, use an INT32. But if they fit in an INT64, that's still probably more efficient than an otherwise "big set". Well, of course, there's always the inline vs. non-inline size vs. speed. And here I teeter toward hypocricy in taking advantage of two "natural" integer types. Heck, generalize it to a list of efficient sizes: 8, 16, 32, 64, pick the smallest that fits, and in the future when otherwise there would have been LONGLONGINT, add 128 to the list. - Jay CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] small set comparisons understood, now just to understand the front end code..Date: Mon, 14 Apr 2008 11:22:35 -0400 I would hesitate to implement small sets as LONGINT instead of INTEGER, since there is no guarantee that LONGINT is necessarily efficient, whereas INTEGER is intended to be the same as the natural word size of the target. I could take a look at this but not anytime soon, since I have several other things I need to work on. On Apr 14, 2008, at 10:51 AM, Jay wrote: currently set <,>,<=,>= are implemented merely asinteger <,>,<=,>= Yes, that seems quite wrong. I can't imagine things ever worked properly if that is how they are implemented. This is wrong. I believe it should be: a < b => (a & b) == aa <= b => (a & b) == a (same as <=) a > b => (a & b) == ba >= b => (a & b) == b (same as >) Probably should be: a <= b => (a & b) == a a < b => (a # b) && ((a & b) == a) a >= b => (a & b) == b a > b => (a # b) && ((a & b) == b) The bug is in the frontend. m3-sys\m3front\src\misc\CG.m3. The code should be /something/ like: PROCEDURE Set_compare (s: Size; op: Cmp) =VAR tmp: Val; swap := FALSE;BEGIN (* a op b => BOOLEAN *) IF Force_pair (commute := TRUE) THEN op := M3CG.SwappedCompare [op]; END; IF (s <= Target.Integer.size) THEN IF (op = Cmp.EQ) OR (op = Cmp.NE) THEN cg.compare (Target.Word.cg_type, Target.Integer.cg_type, op); ELSE (* set a is less than or equal to set b, if all of set a's members are in set b. *) IF (op = Cmp.LT) OR (op = Cmp.LE) THEN swap := TRUE; Swap (); END; tmp := Pop (); Push (tmp); IF swap THEN Swap (); END; cg.and (Target.Integer.cg_type); Push (tmp); SimpleIndirectLoad (tmp^, Target.Word.cg_type); EVAL Force_pair (commute := TRUE); cg.compare (Target.Word.cg_type, Target.Integer.cg_type, Cmp.EQ); SPop (1, "Set_compare"); Free (tmp); END; ELSE cg.set_compare (AsBytes (s), op, Target.Integer.cg_type); END; SPop (2, "Set_compare"); SPush (Type.Int32);END Set_compare; though this doesn't quite drive all the machinery correctly, since it yields assertion failures in the compiler due to an unbalanced software stack.upgrade works, but the test case (p155) fails assertions in the integrated backend. I'd love to figure this out but have to do other stuff for now.Anyone (if there is anyone) familiar with what all is being pushed and popped around here should be able to figure it out easily from this mail.Otherwise I'll stare at more later. ps: "small" sets should probably be anything up to the number of bits in longint, rather than int or pointer, since that is probably efficient enough at the next level down. This is tangential. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Apr 14 20:14:05 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 14 Apr 2008 18:14:05 +0000 Subject: [M3devel] FW: small set comparisons understood, now just to understand the front end code.. In-Reply-To: <32E9EDBE-18FC-4F1B-8653-E60FC39DD534@cs.purdue.edu> References: <32E9EDBE-18FC-4F1B-8653-E60FC39DD534@cs.purdue.edu> Message-ID: [truncated again..] From: jayk123 at hotmail.comTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] small set comparisons understood, now just to understand the front end code..Date: Mon, 14 Apr 2008 17:55:47 +0000 If they fit in an INT32, use an INT32.But if they fit in an INT64, that's still probably more efficient than an otherwise "big set". Well, of course, there's always the inline vs. non-inline size vs. speed.And here I teeter toward hypocricy in taking advantage of two "natural" integer types.Heck, generalize it to a list of efficient sizes: 8, 16, 32, 64, pick the smallest that fits, and in the future when otherwise there would have been LONGLONGINT, add 128 to the list. - Jay[snip] -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Apr 14 20:42:07 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Apr 2008 14:42:07 -0400 Subject: [M3devel] cm3 regression In-Reply-To: <200804141718.m3EHIExE075667@camembert.async.caltech.edu> References: <200804141718.m3EHIExE075667@camembert.async.caltech.edu> Message-ID: <692B2748-B602-4A6E-B729-3C543772233F@cs.purdue.edu> I think Modula-3 has it exactly right in that the base types INTEGER and Word.T use the natural word size of the machine, and that there are no guarantees about BITSIZE on those. If you want a specific bit size you use BITS FOR or simply a subrange type, both of which pack down in memory to just the number of bytes needed. C is generally a mess since you have both LLP64 (Windows) and LP64 (everyone else, for good reason -- see http://www.unix.org/version2/whatsnew/ lp64_wp.html). In any case, yes, I expect there will need to be a fork of BasicCTypes along the lines of ILP32, LP64, and LLP64. Currently, we have the strangeness that NT386 = ILP32/LL32 (because the integrated backend can't grok LL64), but this is an anomaly. Ideally, this would go to LLP64 (IL32) to match the Win64 world. Remember, this is only for *C types*. On all 64-bit platforms, we should aim for 64-bit INTEGER and 64-bit Word.T as the native Modula-3 types. How C types fall out depends on the native C expectations of the platform, and really are just about interfacing to C APIs. On Apr 14, 2008, at 1:18 PM, Mika Nystrom wrote: > Jay writes: >> --_50e47a65-f79d-472b-8eaf-fbcc30b6410e_ >> Content-Type: text/plain; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> new source -> compiling Cstdlib.i3"..\src\C\32BITS\BasicCtypes.i3", >> line 18= >> : illegal based LONGINT literal, zero used"..\src\C\32BITS >> \BasicCtypes.i3",= >> line 18: illegal based LONGINT literal, zero used >> long_long =3D [-16_7fffffffffffffffL-1L .. >> 16_7fffffffffffffffL]= >> ; >> =20 >> Why isn't this LONGINT? So that NT386 can limp along? And it'd be >> correct f= >> or the rest, eh? >> I'll try it and see.. >> =20 >> The underlying system (the compiler) has (U)Int[8,16,32,64] >> They should just be used here imho.. >> =20 >> Also, what should "long" be on 64bit? >> On Windows it is 32 bits always. >> On 32 bit systems it is 32 bits. >> I think the 64bits directory is going to be forked for AMD64_NT_*. >> The Windows decision imho has successfully been applied to more >> code and mo= >> re users so therefore is better by practical success, even if the >> whole iss= >> ue is problematic almost no matter what. Clearly the C and Modula-3 >> notions= >> of integers are pretty poor.. > > I have to re-code my program to use Int64 if I want it to use the > natural INTEGER size on 64 bit machines? No thanks. From hosking at cs.purdue.edu Mon Apr 14 20:44:50 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Apr 2008 14:44:50 -0400 Subject: [M3devel] small set comparisons understood, now just to understand the front end code.. In-Reply-To: References: <32E9EDBE-18FC-4F1B-8653-E60FC39DD534@cs.purdue.edu> Message-ID: Premature optimization is usually time wasted and results in unnecessary complexity. On Apr 14, 2008, at 1:55 PM, Jay wrote: > If they fit in an INT32, use an INT32. > But if they fit in an INT64, that's still probably more efficient > than an otherwise "big set". > Well, of course, there's always the inline vs. non-inline size > vs. speed. > And here I teeter toward hypocricy in taking advantage of two > "natural" integer types. > Heck, generalize it to a list of efficient sizes: 8, 16, 32, 64, > pick the smallest that fits, and in the future when otherwise there > would have been LONGLONGINT, add 128 to the list. > > - Jay > > > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jayk123 at hotmail.com > Subject: Re: [M3devel] small set comparisons understood, now just to > understand the front end code.. > Date: Mon, 14 Apr 2008 11:22:35 -0400 > > I would hesitate to implement small sets as LONGINT instead of > INTEGER, since there is no guarantee that LONGINT is necessarily > efficient, whereas INTEGER is intended to be the same as the natural > word size of the target. > > I could take a look at this but not anytime soon, since I have > several other things I need to work on. > > On Apr 14, 2008, at 10:51 AM, Jay wrote: > > currently set <,>,<=,>= are implemented merely as > integer <,>,<=,>= > > Yes, that seems quite wrong. I can't imagine things ever worked > properly if that is how they are implemented. > > > > This is wrong. > > I believe it should be: > > a < b => (a & b) == a > a <= b => (a & b) == a (same as <=) > a > b => (a & b) == b > a >= b => (a & b) == b (same as >) > > Probably should be: > > a <= b => (a & b) == a > a < b => (a # b) && ((a & b) == a) > a >= b => (a & b) == b > a > b => (a # b) && ((a & b) == b) > > > > The bug is in the frontend. > > m3-sys\m3front\src\misc\CG.m3. > > The code should be /something/ like: > > PROCEDURE Set_compare (s: Size; op: Cmp) = > VAR tmp: Val; > swap := FALSE; > BEGIN > (* a op b => BOOLEAN *) > IF Force_pair (commute := TRUE) THEN > op := M3CG.SwappedCompare [op]; > END; > IF (s <= Target.Integer.size) THEN > IF (op = Cmp.EQ) OR (op = Cmp.NE) THEN > cg.compare (Target.Word.cg_type, Target.Integer.cg_type, op); > ELSE > (* set a is less than or equal to set b, if all of set a's > members are in set b. *) > IF (op = Cmp.LT) OR (op = Cmp.LE) THEN > swap := TRUE; > Swap (); > END; > tmp := Pop (); > Push (tmp); > IF swap THEN > Swap (); > END; > cg.and (Target.Integer.cg_type); > Push (tmp); > SimpleIndirectLoad (tmp^, Target.Word.cg_type); > EVAL Force_pair (commute := TRUE); > cg.compare (Target.Word.cg_type, Target.Integer.cg_type, > Cmp.EQ); > SPop (1, "Set_compare"); > Free (tmp); > END; > ELSE > cg.set_compare (AsBytes (s), op, Target.Integer.cg_type); > END; > SPop (2, "Set_compare"); > SPush (Type.Int32); > END Set_compare; > > though this doesn't quite drive all the machinery correctly, since > it yields assertion failures in the compiler due to an unbalanced > software stack. > upgrade works, but the test case (p155) fails assertions in the > integrated backend. > > I'd love to figure this out but have to do other stuff for now. > Anyone (if there is anyone) familiar with what all is being pushed > and popped around here should be able to figure it out easily from > this mail. > Otherwise I'll stare at more later. > > ps: "small" sets should probably be anything up to the number of > bits in longint, rather than int or pointer, since that is probably > efficient enough at the next level down. This is tangential. > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Apr 14 20:59:22 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 14 Apr 2008 18:59:22 +0000 Subject: [M3devel] cm3 regression In-Reply-To: <692B2748-B602-4A6E-B729-3C543772233F@cs.purdue.edu> References: <200804141718.m3EHIExE075667@camembert.async.caltech.edu> <692B2748-B602-4A6E-B729-3C543772233F@cs.purdue.edu> Message-ID: Right. Win64 will be: INTEGER = 64 bits LONGINT = 64 bits Word.T = INTEGER (should be common to all platforms) LongWord.T = LONGINT (should be common to all platforms) BasicCtypes.int = 32 bits (should be common to all platforms?) BasicCtypes.long = 32 bits (the difference) BasicCtypes.longlong = 64 bits if this even exists > mess since you have both LLP64 (Windows) and LP64 (everyone else, for > good reason -- see http://www.unix.org/version2/whatsnew/ > lp64_wp.html). In any case, yes, I expect there will need to be a I think everyone else had the advantage of: 1) doing it earlier 2) and with much less code 3) no 16 bit legacy that pushed stuff to "long" earlier, thereby taking it away as an option, whereas I GUESS on Unix int was more common, or more "care" had already been taken more often given an earlier "variety" of systems, but again #1 and #2. Hey, good redirect, want to name the directories: ILP32 (aka 32 bits) LP64 (aka 64 bits except Windows) LLP64 (aka 64 bit Windows) ? Too cryptic? While I don't want a bunch of "Win64" directories, maybe put in some selectively, and have: 32bit (same as today) 64bit (same as today) Win64 Anyway, this is still getting a bit ahead of things. - Jay > CC: jayk123 at hotmail.com; m3devel at elegosoft.com> From: hosking at cs.purdue.edu> To: mika at async.caltech.edu> Subject: Re: [M3devel] cm3 regression> Date: Mon, 14 Apr 2008 14:42:07 -0400> > I think Modula-3 has it exactly right in that the base types INTEGER > and Word.T use the natural word size of the machine, and that there > are no guarantees about BITSIZE on those. If you want a specific bit > size you use BITS FOR or simply a subrange type, both of which pack > down in memory to just the number of bytes needed. C is generally a > mess since you have both LLP64 (Windows) and LP64 (everyone else, for > good reason -- see http://www.unix.org/version2/whatsnew/ > lp64_wp.html). In any case, yes, I expect there will need to be a > fork of BasicCTypes along the lines of ILP32, LP64, and LLP64. > Currently, we have the strangeness that NT386 = ILP32/LL32 (because > the integrated backend can't grok LL64), but this is an anomaly. > Ideally, this would go to LLP64 (IL32) to match the Win64 world. > Remember, this is only for *C types*. On all 64-bit platforms, we > should aim for 64-bit INTEGER and 64-bit Word.T as the native Modula-3 > types. How C types fall out depends on the native C expectations of > the platform, and really are just about interfacing to C APIs.> > On Apr 14, 2008, at 1:18 PM, Mika Nystrom wrote:> > > Jay writes:> >> --_50e47a65-f79d-472b-8eaf-fbcc30b6410e_> >> Content-Type: text/plain; charset="iso-8859-1"> >> Content-Transfer-Encoding: quoted-printable> >>> >> new source -> compiling Cstdlib.i3"..\src\C\32BITS\BasicCtypes.i3", > >> line 18=> >> : illegal based LONGINT literal, zero used"..\src\C\32BITS > >> \BasicCtypes.i3",=> >> line 18: illegal based LONGINT literal, zero used> >> long_long =3D [-16_7fffffffffffffffL-1L .. > >> 16_7fffffffffffffffL]=> >> ;> >> =20> >> Why isn't this LONGINT? So that NT386 can limp along? And it'd be > >> correct f=> >> or the rest, eh?> >> I'll try it and see..> >> =20> >> The underlying system (the compiler) has (U)Int[8,16,32,64]> >> They should just be used here imho..> >> =20> >> Also, what should "long" be on 64bit?> >> On Windows it is 32 bits always.> >> On 32 bit systems it is 32 bits.> >> I think the 64bits directory is going to be forked for AMD64_NT_*.> >> The Windows decision imho has successfully been applied to more > >> code and mo=> >> re users so therefore is better by practical success, even if the > >> whole iss=> >> ue is problematic almost no matter what. Clearly the C and Modula-3 > >> notions=> >> of integers are pretty poor..> >> > I have to re-code my program to use Int64 if I want it to use the> > natural INTEGER size on 64 bit machines? No thanks.> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Apr 14 21:03:00 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 14 Apr 2008 19:03:00 +0000 Subject: [M3devel] small set comparisons understood, now just to understand the front end code.. In-Reply-To: References: <32E9EDBE-18FC-4F1B-8653-E60FC39DD534@cs.purdue.edu> Message-ID: Mika corrected my proposed implementation of set_compare. I had it right for <= and >= but wrong for < and >. < and > need to check if the sets are equal, in which case return false. My confidence here wasn't particularly high, I intend(ed) to test a bunch, once it works at all, and it doesn't yet. Should also 1) check the history; I suspect it never worked 2) as a stopgap if really desparate can probably omit the optimization and just use the functions but that's lame.. well, for < and >, the inline code might be kind of large actually.. could write helpers just for int-sized sets... - Jay[snip -- the below is wrong] I believe it should be: a < b => (a & b) == aa <= b => (a & b) == a (same as <=) a > b => (a & b) == ba >= b => (a & b) == b (same as >) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Apr 14 22:10:05 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 14 Apr 2008 13:10:05 -0700 Subject: [M3devel] small set comparisons understood, now just to understand the front end code.. In-Reply-To: Your message of "Mon, 14 Apr 2008 17:48:06 -0000." Message-ID: <200804142010.m3EKA5ep081393@camembert.async.caltech.edu> Sorry, I think the Green Book is completely unambiguous about this. a < b is the same as a <= b AND a # b for all a and b, no matter the type (set, integer, or floating). That's what 2.6.11 says, and it seems correct, because it implies that for sets, <= is the subset relation, and < is the proper subset relation. Mika Jay writes: >--_a67e670a-e4c4-4f68-a1a3-4f4661e52338_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > a < b "should be implemented as" (a & b) =3D=3D a=20 >=20 > I believe, and so on.=20 >I could be wrong. I only thought about it a few minutes.=20 >=20 > The current incorrect code is:=20 >PROCEDURE Set_compare (s: Size; op: Cmp) =3D BEGIN IF Force_pair (comm= >ute :=3D TRUE) THEN op :=3D M3CG.SwappedCompare [op]; END; IF (s= > <=3D Target.Integer.size) THEN cg.compare (Target.Word.cg_type, Targe= >t.Integer.cg_type, op); ELSE cg.set_compare (AsBytes (s), op, Target.I= >nteger.cg_type); END; SPop (2, "Set_eq"); SPush (Type.Int32); END= > Set_compare; >=20 >which generates simply, I think this was <=3D (jbe -- jump if below or equa= >l): >=20 >=20 > 0040119C: 56 push esi 0040119D: E8 AE FE FF FF = > call _Main__m 004011A2: 83 C4 04 add esp,4 >=20 > ... end of previous line that just called m("foo")=20 >=20 > ; push a string to print=20 > 004011A5: 8D 35 2C 12 40 00 lea esi,ds:[40122Ch] 004011AB: 56 = > push esi >=20 > ; compare two sets=20 > ; one is constant 0x15; one is a global=20 > 004011AC: 83 3D 44 90 45 00 cmp dword ptr ds:[459044h],15h = > 15 >=20 > ; spend a while converting the compare result to a boolean 004011B3: 0F = >96 45 FC setbe byte ptr [ebp-4] 004011B7: 33 DB = >xor ebx,ebx 004011B9: 8A 5D FC mov bl,byte ptr [= ebp-4] 004011BC: 83 FB 00 cmp ebx,0 004011BF: 0F 94 45 = >F8 sete byte ptr [ebp-8] 004011C3: 33 D2 xor = > edx,edx 004011C5: 8A 55 F8 mov dl,byte ptr [ebp-8] > ; and then push that boolean=20 > 004011C8: 52 push edx > 004011C9: E8 6C FF FF FF call _Main__checkM >oh, you are right, < needs to also be !=3D. >I thought it was suspicious to have only two implementations of four operat= >ions, but I did like the resulting efficiency. :) >Hey, I was at least sure the current code was wrong. >=20 > - Jay > > > >> To: jayk123 at hotmail.com> Subject: Re: [M3devel] small set comparisons und= >erstood, now just to understand the front end code.. > Date: Mon, 14 Apr 20= >08 10:16:01 -0700> From: mika at async.caltech.edu> > Jay writes:> >--_6435b74= >a-d943-44c2-9091-ab0408dc7ed0_> >Content-Type: text/plain; charset=3D"iso-8= >859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >currently set = ><,>,<=3D3D,>=3D3D are implemented merely as> >integer <,>,<=3D3D,>=3D3D> >= >=3D20> >This is wrong.> >=3D20> >I believe it should be:> >=3D20> >a < b = >=3D3D> (a & b) =3D3D=3D3D a> >a <=3D3D b =3D3D> (a & b) =3D3D=3D3D a (same = >as <=3D3D)> >a > b =3D3D> (a & b) =3D3D=3D3D b> >a >=3D3D b =3D3D> (a & b) = >=3D3D=3D3D b (same as >)> > You don't actually mean logical implication by = >your arrows do you,> but equivalence, where the objects to the left of the = >arrow refer> to the abstract sets a and b and the objects to the right of t= >he> arrow refer to bit-vector implementations (in C) of the same?> > Green = >Book, page 57, section 2.6.1:> > "In all cases, x < y means (x <=3D y) AND = >(x # y), and x > y means y < x."> > So in your syntax a > b would be ((a & = >b) =3D=3D a) && (a !=3D b).> > Also, just above it, > > "The expression x >= >=3D y is equivalent to y <=3D x."> > Why not define the operation "x >=3D y= >" and then use the two statements> from the Green Book to generate the rest= >?> > Mika= > >--_a67e670a-e4c4-4f68-a1a3-4f4661e52338_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > a < b "should be implemented as" (a &= >; b) =3D=3D a
> 
> I believe, and so on.
>I could be wrong. I only thought about it a few minutes.
> 
> The current incorrect code is:
>
PROCEDURE Set_compare (s: Size;  op: Cmp) =3D
  BEGIN
&= >nbsp;   IF Force_pair (commute :=3D TRUE) THEN
  &nb= >sp;   op :=3D M3CG.SwappedCompare [op];
    END= >;
    IF (s <=3D Target.Integer.size)
  &= >nbsp;   THEN cg.compare (Target.Word.cg_type, Target.Integer.cg_t= >ype, op);
      ELSE cg.set_compare (AsBytes (s= >), op, Target.Integer.cg_type);
    END;
  &= >nbsp; SPop (2, "Set_eq");
    SPush (Type.Int32);
&nbs= >p; END Set_compare;

> 
>which generates simply, I think this was <=3D (jbe -- jump if below or e= >qual):
> 
> 
>  0040119C: 56         &n= >bsp;       push     = >   esi
  0040119D: E8 AE FE FF FF    = > call        _Main__m
  004011A2= >: 83 C4 04           add&= >nbsp;        esp,4
> 
> ... end of previous line that just called m("foo")
> 
> ; push a string to print
>  004011A5: 8D 35 2C 12 40 00  lea     &= >nbsp;   esi,ds:[40122Ch]
  004011AB: 56   = >            &nb= >sp; push        esi
> 
> ; compare two sets
> ; one is constant 0x15; one is a global
>  004011AC: 83 3D 44 90 45 00  cmp     &= >nbsp;   dword ptr ds:[459044h],15h
    &nb= >sp;       15
> 
> ; spend a while converting the compare result to a boolean
 = > 004011B3: 0F 96 45 FC        setbe = >;      byte ptr [ebp-4]
  004011B7: 33 DB&= >nbsp;           &nbs= >p; xor         ebx,ebx
  00= >4011B9: 8A 5D FC          = >; mov         bl,byte ptr [ebp-4]R>  004011BC: 83 FB 00        = >   cmp         ebx,0
&= >nbsp; 004011BF: 0F 94 45 F8        sete&= >nbsp;       byte ptr [ebp-8]
  004011= >C3: 33 D2           = >   xor         edx,edx>  004011C5: 8A 55 F8        &= >nbsp;  mov         dl,byte ptr= > [ebp-8]

> ; and then push that boolean
>  004011C8: 52         &n= >bsp;       push     = >   edx
>  004011C9: E8 6C FF FF FF     call  &nb= >sp;     _Main__checkM


>oh, you are right, < needs to also be !=3D.
>I thought it was suspicious to have only two implementations of four operat= >ions, but I did like the resulting efficiency. :)
Hey, I was at least sure the current code was wrong.
> 
> - Jay



> >
>
>> To: jayk123 at hotmail.com
> Subject: Re: [M3devel] small set compa= >risons understood, now just to understand the front end code..
> Dat= >e: Mon, 14 Apr 2008 10:16:01 -0700
> From: mika at async.caltech.edu
= >>
> Jay writes:
> >--_6435b74a-d943-44c2-9091-ab0408dc7e= >d0_
> >Content-Type: text/plain; charset=3D"iso-8859-1"
> &g= >t;Content-Transfer-Encoding: quoted-printable
> >
> >
= >> >currently set <,>,<=3D3D,>=3D3D are implemented merely= > as
> >integer <,>,<=3D3D,>=3D3D
> >=3D20
= >> >This is wrong.
> >=3D20
> >I believe it should b= >e:
> >=3D20
> >a < b =3D3D> (a & b) =3D3D=3D3D = >a
> >a <=3D3D b =3D3D> (a & b) =3D3D=3D3D a (same as <= >;=3D3D)
> >a > b =3D3D> (a & b) =3D3D=3D3D b
> >= >;a >=3D3D b =3D3D> (a & b) =3D3D=3D3D b (same as >)
> R>> You don't actually mean logical implication by your arrows do you,R>> but equivalence, where the objects to the left of the arrow refer>> to the abstract sets a and b and the objects to the right of the
&= >gt; arrow refer to bit-vector implementations (in C) of the same?
> <= >BR>> Green Book, page 57, section 2.6.1:
>
> "In all cases,= > x < y means (x <=3D y) AND (x # y), and x > y means y < x.">>
> So in your syntax a > b would be ((a & b) =3D=3D a) &= >amp;& (a !=3D b).
>
> Also, just above it,
>
&g= >t; "The expression x >=3D y is equivalent to y <=3D x."
>
&= >gt; Why not define the operation "x >=3D y" and then use the two stateme= >nts
> from the Green Book to generate the rest?
>
> Mika= >

>= > >--_a67e670a-e4c4-4f68-a1a3-4f4661e52338_-- From jayk123 at hotmail.com Mon Apr 14 23:55:48 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 14 Apr 2008 21:55:48 +0000 Subject: [M3devel] small set comparisons understood, now just to understand the front end code.. In-Reply-To: <200804142010.m3EKA5ep081393@camembert.async.caltech.edu> References: Your message of "Mon, 14 Apr 2008 17:48:06 -0000." <200804142010.m3EKA5ep081393@camembert.async.caltech.edu> Message-ID: I think we are in agreement now on this. My original assertions were indeed wrong for <= and >=. I'm not even sure they were correct for < and >. - Jay > To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] small set comparisons understood, now just to understand the front end code.. > Date: Mon, 14 Apr 2008 13:10:05 -0700> From: mika at async.caltech.edu> > Sorry, I think the Green Book is completely unambiguous about this.> > a < b is the same as a <= b AND a # b for all a and b, no matter> the type (set, integer, or floating). That's what 2.6.11 says, and> it seems correct, because it implies that for sets, <= is the subset> relation, and < is the proper subset relation.> > Mika> > Jay writes:> >--_a67e670a-e4c4-4f68-a1a3-4f4661e52338_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> > a < b "should be implemented as" (a & b) =3D=3D a=20> >=20> > I believe, and so on.=20> >I could be wrong. I only thought about it a few minutes.=20> >=20> > The current incorrect code is:=20> >PROCEDURE Set_compare (s: Size; op: Cmp) =3D BEGIN IF Force_pair (comm=> >ute :=3D TRUE) THEN op :=3D M3CG.SwappedCompare [op]; END; IF (s=> > <=3D Target.Integer.size) THEN cg.compare (Target.Word.cg_type, Targe=> >t.Integer.cg_type, op); ELSE cg.set_compare (AsBytes (s), op, Target.I=> >nteger.cg_type); END; SPop (2, "Set_eq"); SPush (Type.Int32); END=> > Set_compare;> >=20> >which generates simply, I think this was <=3D (jbe -- jump if below or equa=> >l):> >=20> >=20> > 0040119C: 56 push esi 0040119D: E8 AE FE FF FF => > call _Main__m 004011A2: 83 C4 04 add esp,4> >=20> > ... end of previous line that just called m("foo")=20> >=20> > ; push a string to print=20> > 004011A5: 8D 35 2C 12 40 00 lea esi,ds:[40122Ch] 004011AB: 56 => > push esi> >=20> > ; compare two sets=20> > ; one is constant 0x15; one is a global=20> > 004011AC: 83 3D 44 90 45 00 cmp dword ptr ds:[459044h],15h => > 15> >=20> > ; spend a while converting the compare result to a boolean 004011B3: 0F => >96 45 FC setbe byte ptr [ebp-4] 004011B7: 33 DB => >xor ebx,ebx 004011B9: 8A 5D FC mov bl,byte ptr [=> ebp-4] 004011BC: 83 FB 00 cmp ebx,0 004011BF: 0F 94 45 => >F8 sete byte ptr [ebp-8] 004011C3: 33 D2 xor => > edx,edx 004011C5: 8A 55 F8 mov dl,byte ptr [ebp-8]> > ; and then push that boolean=20> > 004011C8: 52 push edx> > 004011C9: E8 6C FF FF FF call _Main__checkM> >oh, you are right, < needs to also be !=3D.> >I thought it was suspicious to have only two implementations of four operat=> >ions, but I did like the resulting efficiency. :)> >Hey, I was at least sure the current code was wrong.> >=20> > - Jay> >> >> >> >> To: jayk123 at hotmail.com> Subject: Re: [M3devel] small set comparisons und=> >erstood, now just to understand the front end code.. > Date: Mon, 14 Apr 20=> >08 10:16:01 -0700> From: mika at async.caltech.edu> > Jay writes:> >--_6435b74=> >a-d943-44c2-9091-ab0408dc7ed0_> >Content-Type: text/plain; charset=3D"iso-8=> >859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >currently set => ><,>,<=3D3D,>=3D3D are implemented merely as> >integer <,>,<=3D3D,>=3D3D> >=> >=3D20> >This is wrong.> >=3D20> >I believe it should be:> >=3D20> >a < b => >=3D3D> (a & b) =3D3D=3D3D a> >a <=3D3D b =3D3D> (a & b) =3D3D=3D3D a (same => >as <=3D3D)> >a > b =3D3D> (a & b) =3D3D=3D3D b> >a >=3D3D b =3D3D> (a & b) => >=3D3D=3D3D b (same as >)> > You don't actually mean logical implication by => >your arrows do you,> but equivalence, where the objects to the left of the => >arrow refer> to the abstract sets a and b and the objects to the right of t=> >he> arrow refer to bit-vector implementations (in C) of the same?> > Green => >Book, page 57, section 2.6.1:> > "In all cases, x < y means (x <=3D y) AND => >(x # y), and x > y means y < x."> > So in your syntax a > b would be ((a & => >b) =3D=3D a) && (a !=3D b).> > Also, just above it, > > "The expression x >=> >=3D y is equivalent to y <=3D x."> > Why not define the operation "x >=3D y=> >" and then use the two statements> from the Green Book to generate the rest=> >?> > Mika=> >> >--_a67e670a-e4c4-4f68-a1a3-4f4661e52338_> >Content-Type: text/html; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >> >> >> > a < b "should be implemented as" (a &=> >; b) =3D=3D a
> > 
> > I believe, and so on.
> >I could be wrong. I only thought about it a few minutes.
> > 
> > The current incorrect code is:
> >
PROCEDURE Set_compare (s: Size;  op: Cmp) =3D
  BEGIN
&=> >nbsp;   IF Force_pair (commute :=3D TRUE) THEN
  &nb=> >sp;   op :=3D M3CG.SwappedCompare [op];
    END=> >;
    IF (s <=3D Target.Integer.size)
  &=> >nbsp;   THEN cg.compare (Target.Word.cg_type, Target.Integer.cg_t=> >ype, op);
      ELSE cg.set_compare (AsBytes (s=> >), op, Target.Integer.cg_type);
    END;
  &=> >nbsp; SPop (2, "Set_eq");
    SPush (Type.Int32);
&nbs=> >p; END Set_compare;

> > 
> >which generates simply, I think this was <=3D (jbe -- jump if below or e=> >qual):
> > 
> > 
> >  0040119C: 56         &n=> >bsp;       push     => >   esi
  0040119D: E8 AE FE FF FF    => > call        _Main__m
  004011A2=> >: 83 C4 04           add&=> >nbsp;        esp,4
> > 
> > ... end of previous line that just called m("foo")
> > 
> > ; push a string to print
> >  004011A5: 8D 35 2C 12 40 00  lea     &=> >nbsp;   esi,ds:[40122Ch]
  004011AB: 56   => >            &nb=> >sp; push        esi
> > 
> > ; compare two sets
> > ; one is constant 0x15; one is a global
> >  004011AC: 83 3D 44 90 45 00  cmp     &=> >nbsp;   dword ptr ds:[459044h],15h
    &nb=> >sp;       15
> > 
> > ; spend a while converting the compare result to a boolean
 => > 004011B3: 0F 96 45 FC        setbe => >;      byte ptr [ebp-4]
  004011B7: 33 DB&=> >nbsp;           &nbs=> >p; xor         ebx,ebx
  00=> >4011B9: 8A 5D FC          => >; mov         bl,byte ptr [ebp-4] >R>  004011BC: 83 FB 00        => >   cmp         ebx,0
&=> >nbsp; 004011BF: 0F 94 45 F8        sete&=> >nbsp;       byte ptr [ebp-8]
  004011=> >C3: 33 D2           => >   xor         edx,edx >>  004011C5: 8A 55 F8        &=> >nbsp;  mov         dl,byte ptr=> > [ebp-8]

> > ; and then push that boolean
> >  004011C8: 52         &n=> >bsp;       push     => >   edx
> >  004011C9: E8 6C FF FF FF     call  &nb=> >sp;     _Main__checkM


> >oh, you are right, < needs to also be !=3D.
> >I thought it was suspicious to have only two implementations of four operat=> >ions, but I did like the resulting efficiency. :)
> Hey, I was at least sure the current code was wrong.
> > 
> > - Jay



> >> >
> >
> >> To: jayk123 at hotmail.com
> Subject: Re: [M3devel] small set compa=> >risons understood, now just to understand the front end code..
> Dat=> >e: Mon, 14 Apr 2008 10:16:01 -0700
> From: mika at async.caltech.edu
=> >>
> Jay writes:
> >--_6435b74a-d943-44c2-9091-ab0408dc7e=> >d0_
> >Content-Type: text/plain; charset=3D"iso-8859-1"
> &g=> >t;Content-Transfer-Encoding: quoted-printable
> >
> >
=> >> >currently set <,>,<=3D3D,>=3D3D are implemented merely=> > as
> >integer <,>,<=3D3D,>=3D3D
> >=3D20
=> >> >This is wrong.
> >=3D20
> >I believe it should b=> >e:
> >=3D20
> >a < b =3D3D> (a & b) =3D3D=3D3D => >a
> >a <=3D3D b =3D3D> (a & b) =3D3D=3D3D a (same as <=> >;=3D3D)
> >a > b =3D3D> (a & b) =3D3D=3D3D b
> >=> >;a >=3D3D b =3D3D> (a & b) =3D3D=3D3D b (same as >)
> >R>> You don't actually mean logical implication by your arrows do you, >R>> but equivalence, where the objects to the left of the arrow refer >>> to the abstract sets a and b and the objects to the right of the
&=> >gt; arrow refer to bit-vector implementations (in C) of the same?
> <=> >BR>> Green Book, page 57, section 2.6.1:
>
> "In all cases,=> > x < y means (x <=3D y) AND (x # y), and x > y means y < x." >>>
> So in your syntax a > b would be ((a & b) =3D=3D a) &=> >amp;& (a !=3D b).
>
> Also, just above it,
>
&g=> >t; "The expression x >=3D y is equivalent to y <=3D x."
>
&=> >gt; Why not define the operation "x >=3D y" and then use the two stateme=> >nts
> from the Green Book to generate the rest?
>
> Mika=> >

> >=> >> >--_a67e670a-e4c4-4f68-a1a3-4f4661e52338_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Apr 14 23:58:31 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 14 Apr 2008 21:58:31 +0000 Subject: [M3devel] small set comparisons understood, now just to understand the front end code.. In-Reply-To: References: <32E9EDBE-18FC-4F1B-8653-E60FC39DD534@cs.purdue.edu> Message-ID: And doing no optimization up front, or not designing to allow it later, leads to it being difficult to doing all of it later. Early optimization and profiling followed by late optimization are both needed. A balance must be found. "Premature" has a negative connotation, "early" does not. Complexity is imho often overstated also.. ..Jay CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] small set comparisons understood, now just to understand the front end code..Date: Mon, 14 Apr 2008 14:44:50 -0400 Premature optimization is usually time wasted and results in unnecessary complexity. On Apr 14, 2008, at 1:55 PM, Jay wrote: If they fit in an INT32, use an INT32.But if they fit in an INT64, that's still probably more efficient than an otherwise "big set". Well, of course, there's always the inline vs. non-inline size vs. speed.And here I teeter toward hypocricy in taking advantage of two "natural" integer types.Heck, generalize it to a list of efficient sizes: 8, 16, 32, 64, pick the smallest that fits, and in the future when otherwise there would have been LONGLONGINT, add 128 to the list. - Jay CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] small set comparisons understood, now just to understand the front end code..Date: Mon, 14 Apr 2008 11:22:35 -0400 I would hesitate to implement small sets as LONGINT instead of INTEGER, since there is no guarantee that LONGINT is necessarily efficient, whereas INTEGER is intended to be the same as the natural word size of the target. I could take a look at this but not anytime soon, since I have several other things I need to work on. On Apr 14, 2008, at 10:51 AM, Jay wrote: currently set <,>,<=,>= are implemented merely asinteger <,>,<=,>= Yes, that seems quite wrong. I can't imagine things ever worked properly if that is how they are implemented. This is wrong. I believe it should be: a < b => (a & b) == aa <= b => (a & b) == a (same as <=) a > b => (a & b) == ba >= b => (a & b) == b (same as >) Probably should be: a <= b => (a & b) == a a < b => (a # b) && ((a & b) == a) a >= b => (a & b) == b a > b => (a # b) && ((a & b) == b) The bug is in the frontend. m3-sys\m3front\src\misc\CG.m3. The code should be /something/ like: PROCEDURE Set_compare (s: Size; op: Cmp) =VAR tmp: Val; swap := FALSE;BEGIN (* a op b => BOOLEAN *) IF Force_pair (commute := TRUE) THEN op := M3CG.SwappedCompare [op]; END; IF (s <= Target.Integer.size) THEN IF (op = Cmp.EQ) OR (op = Cmp.NE) THEN cg.compare (Target.Word.cg_type, Target.Integer.cg_type, op); ELSE (* set a is less than or equal to set b, if all of set a's members are in set b. *) IF (op = Cmp.LT) OR (op = Cmp.LE) THEN swap := TRUE; Swap (); END; tmp := Pop (); Push (tmp); IF swap THEN Swap (); END; cg.and (Target.Integer.cg_type); Push (tmp); SimpleIndirectLoad (tmp^, Target.Word.cg_type); EVAL Force_pair (commute := TRUE); cg.compare (Target.Word.cg_type, Target.Integer.cg_type, Cmp.EQ); SPop (1, "Set_compare"); Free (tmp); END; ELSE cg.set_compare (AsBytes (s), op, Target.Integer.cg_type); END; SPop (2, "Set_compare"); SPush (Type.Int32);END Set_compare; though this doesn't quite drive all the machinery correctly, since it yields assertion failures in the compiler due to an unbalanced software stack.upgrade works, but the test case (p155) fails assertions in the integrated backend. I'd love to figure this out but have to do other stuff for now.Anyone (if there is anyone) familiar with what all is being pushed and popped around here should be able to figure it out easily from this mail.Otherwise I'll stare at more later. ps: "small" sets should probably be anything up to the number of bits in longint, rather than int or pointer, since that is probably efficient enough at the next level down. This is tangential. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Apr 15 08:35:16 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 15 Apr 2008 08:35:16 +0200 Subject: [M3devel] new cm3 backend dependencies Message-ID: <20080415083516.i3vino6o0w400osw@mail.elegosoft.com> Hi Ronny, Antony Hosking has updated the gcc in cm3, which leads to new build dependencies which are not available at our regression test systems: 1088 NEXT configure: error: Building GCC requires GMP 4.1+ and MPFR 2.3.0+. Can you provide these? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From ronny.forberger at elegosoft.com Tue Apr 15 12:51:55 2008 From: ronny.forberger at elegosoft.com (Ronny Forberger) Date: Tue, 15 Apr 2008 12:51:55 +0200 Subject: [M3devel] new cm3 backend dependencies In-Reply-To: <20080415083516.i3vino6o0w400osw@mail.elegosoft.com> References: <20080415083516.i3vino6o0w400osw@mail.elegosoft.com> Message-ID: <20080415125155.wi1hnkfy4gsk4cks@mail.elegosoft.com> Hi there, on birch.elego.de (LINUXLIBC6) there is GMP 4.2.1 on the package management system, which I installed. Also there is MPFR but only at version <2.3.0, this is why I installed MPFR 2.3.0 under the prefix /usr/local. I guess cm3 will automatically find the libs there. On new.elego.de (FreeBSD4) there was libgmp-4.2.1_1 already installed under /usr/local. MPFR was too old there too, so I installed 2.3.0 manually to /usr/contrib. I guess cm3 needs to be told to use libs residing under /usr/contrib ? Cheers, Ronny -- Message from: Olaf Wagner Date: Di 15 Apr 2008 08:35:16 CEST Subject: new cm3 backend dependencies > Hi Ronny, > > Antony Hosking has updated the gcc in cm3, which leads to new > build dependencies which are not available at our regression test > systems: > > 1088 NEXT configure: error: Building GCC requires GMP 4.1+ and MPFR > 2.3.0+. > > Can you provide these? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -- Ronny Forberger Systemadministration & IT-Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Geb?ude 12, Raum 227 D-13355 Berlin Tel. +49 30 23 45 86 96 ronny.forberger at elegosoft.com Fax +49 30 23 45 86 95 http://www.elegosoft.com Gesch?ftsf?hrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Apr 15 13:05:31 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 15 Apr 2008 13:05:31 +0200 Subject: [M3devel] new cm3 backend dependencies In-Reply-To: <20080415125155.wi1hnkfy4gsk4cks@mail.elegosoft.com> References: <20080415083516.i3vino6o0w400osw@mail.elegosoft.com> <20080415125155.wi1hnkfy4gsk4cks@mail.elegosoft.com> Message-ID: <20080415130531.kjb7fdsbjswk4sck@mail.elegosoft.com> Quoting Ronny Forberger : > Hi there, > > on birch.elego.de (LINUXLIBC6) there is GMP 4.2.1 on the package > management system, which I installed. > > Also there is MPFR but only at version <2.3.0, this is why I installed > MPFR 2.3.0 under the prefix /usr/local. I guess cm3 will automatically > find the libs there. > > On new.elego.de (FreeBSD4) there was libgmp-4.2.1_1 already installed > under /usr/local. > > MPFR was too old there too, so I installed 2.3.0 manually to > /usr/contrib. I guess cm3 needs to be told to use libs residing under > /usr/contrib ? Probably. Doesn't the FreeBSD ports system provide an update? If you can build it manually, perhaps it is sufficient to just increase the version numbers in the port and send the patch to a FreeBSD committer / the port maintainer? Olaf > Cheers, > > Ronny > > -- > Message from: Olaf Wagner > Date: Di 15 Apr 2008 08:35:16 CEST > Subject: new cm3 backend dependencies > > >> Hi Ronny, >> >> Antony Hosking has updated the gcc in cm3, which leads to new >> build dependencies which are not available at our regression test >> systems: >> >> 1088 NEXT configure: error: Building GCC requires GMP 4.1+ and MPFR >> 2.3.0+. >> >> Can you provide these? >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > > > -- > > Ronny Forberger > Systemadministration & IT-Support > > elego Software Solutions GmbH > Gustav-Meyer-Allee 25 > Geb?ude 12, Raum 227 > D-13355 Berlin > > Tel. +49 30 23 45 86 96 ronny.forberger at elegosoft.com > Fax +49 30 23 45 86 95 http://www.elegosoft.com > > Gesch?ftsf?hrer: Olaf Wagner, Sitz Berlin > Amtsgericht Berlin-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 hendrik at topoi.pooq.com Tue Apr 15 13:07:40 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 15 Apr 2008 07:07:40 -0400 Subject: [M3devel] small set comparisons understood, now just to understand the front end code.. In-Reply-To: <32E9EDBE-18FC-4F1B-8653-E60FC39DD534@cs.purdue.edu> References: <32E9EDBE-18FC-4F1B-8653-E60FC39DD534@cs.purdue.edu> Message-ID: <20080415110740.GA12952@topoi.pooq.com> On Mon, Apr 14, 2008 at 11:22:35AM -0400, Tony Hosking wrote: > > Yes, that seems quite wrong. I can't imagine things ever worked > properly if that is how they are implemented. Maybe stick a test in the compiler to see if < > <= >= are ever used on small sets anywhere in the m3 system? You might want to do this anyway in case anyone is relying on them doing integer comparisons. I seem to remember using them for subset comparisons in a Pascal program I converted to modula 3 many years ago. I was using the PM3 compiler then, and I haven't tried it on cm3 yet. I'd have to check the code to see what I was really doing, though. -- hendrik From hendrik at topoi.pooq.com Tue Apr 15 13:09:19 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 15 Apr 2008 07:09:19 -0400 Subject: [M3devel] small set comparisons understood, now just to understand the front end code.. In-Reply-To: References: <32E9EDBE-18FC-4F1B-8653-E60FC39DD534@cs.purdue.edu> Message-ID: <20080415110919.GB12952@topoi.pooq.com> On Mon, Apr 14, 2008 at 07:03:00PM +0000, Jay wrote: > Should also 1) check the history; I suspect it never worked 2) as a stopgap if really desparate can probably omit the optimization and just use the functions but that's lame.. well, for < and >, the inline code might be kind of large actually.. could write helpers just for int-sized sets... You might compare the cm3 code with the pm3 code. I think I may have used it on pm3 long ago without mishap. -- hendrik From jayk123 at hotmail.com Tue Apr 15 13:23:38 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 15 Apr 2008 11:23:38 +0000 Subject: [M3devel] small set comparisons understood, now just to understand the front end code.. In-Reply-To: <20080415110919.GB12952@topoi.pooq.com> References: <32E9EDBE-18FC-4F1B-8653-E60FC39DD534@cs.purdue.edu> <20080415110919.GB12952@topoi.pooq.com> Message-ID: PM3 has it wrong too. http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/pm3/m3/pm3/language/modula3/m3compiler/m3front/src/misc/CG.m3?rev=1.4;content-type=text%2FplainPROCEDURE Set_compare (s: Size; op: Cmp) = BEGIN IF Force_pair (commute := TRUE) THEN op := M3CG.SwappedCompare [op]; END; IF (s <= Target.Integer.size) THEN cg.compare (Target.Word.cg_type, Target.Integer.cg_type, op); ELSE cg.set_compare (AsBytes (s), op, Target.Integer.cg_type); END; SPop (2, "Set_eq"); SPush (Type.Int32); END Set_compare; I didn't run it and look at the generate code, but this is the same as cm3 had and it just generated <,<=,>,>= for integers. Anyway, I checked in a fix for it. - Jay > Date: Tue, 15 Apr 2008 07:09:19 -0400> From: hendrik at topoi.pooq.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] small set comparisons understood, now just to understand the front end code..> > On Mon, Apr 14, 2008 at 07:03:00PM +0000, Jay wrote:> > > Should also 1) check the history; I suspect it never worked 2) as a stopgap if really desparate can probably omit the optimization and just use the functions but that's lame.. well, for < and >, the inline code might be kind of large actually.. could write helpers just for int-sized sets...> > You might compare the cm3 code with the pm3 code. I think I may have > used it on pm3 long ago without mishap.> > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Apr 15 13:24:13 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 15 Apr 2008 11:24:13 +0000 Subject: [M3devel] small set comparisons understood, now just to understand the front end code.. In-Reply-To: <20080415110919.GB12952@topoi.pooq.com> References: <32E9EDBE-18FC-4F1B-8653-E60FC39DD534@cs.purdue.edu> <20080415110919.GB12952@topoi.pooq.com> Message-ID: PM3 has it wrong too. http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/pm3/m3/pm3/language/modula3/m3compiler/m3front/src/misc/CG.m3?rev=1.4;content-type=text%2FplainPROCEDURE Set_compare (s: Size; op: Cmp) = BEGIN IF Force_pair (commute := TRUE) THEN op := M3CG.SwappedCompare [op]; END; IF (s <= Target.Integer.size) THEN cg.compare (Target.Word.cg_type, Target.Integer.cg_type, op); ELSE cg.set_compare (AsBytes (s), op, Target.Integer.cg_type); END; SPop (2, "Set_eq"); SPush (Type.Int32); END Set_compare; I didn't run it and look at the generate code, but this is the same as cm3 had and it just generated <,<=,>,>= for integers. Anyway, I checked in a fix for it. - Jay > Date: Tue, 15 Apr 2008 07:09:19 -0400> From: hendrik at topoi.pooq.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] small set comparisons understood, now just to understand the front end code..> > On Mon, Apr 14, 2008 at 07:03:00PM +0000, Jay wrote:> > > Should also 1) check the history; I suspect it never worked 2) as a stopgap if really desparate can probably omit the optimization and just use the functions but that's lame.. well, for < and >, the inline code might be kind of large actually.. could write helpers just for int-sized sets...> > You might compare the cm3 code with the pm3 code. I think I may have > used it on pm3 long ago without mishap.> > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronny.forberger at elegosoft.com Tue Apr 15 13:31:29 2008 From: ronny.forberger at elegosoft.com (Ronny Forberger) Date: Tue, 15 Apr 2008 13:31:29 +0200 Subject: [M3devel] new cm3 backend dependencies In-Reply-To: <20080415130531.kjb7fdsbjswk4sck@mail.elegosoft.com> References: <20080415083516.i3vino6o0w400osw@mail.elegosoft.com> <20080415125155.wi1hnkfy4gsk4cks@mail.elegosoft.com> <20080415130531.kjb7fdsbjswk4sck@mail.elegosoft.com> Message-ID: <20080415133129.d6xwc1x1oo40co0c@mail.elegosoft.com> -- Message from: Olaf Wagner Date: Di 15 Apr 2008 13:05:31 CEST Subject: Re: new cm3 backend dependencies > Quoting Ronny Forberger : > >> Hi there, >> >> on birch.elego.de (LINUXLIBC6) there is GMP 4.2.1 on the package >> management system, which I installed. >> >> Also there is MPFR but only at version <2.3.0, this is why I installed >> MPFR 2.3.0 under the prefix /usr/local. I guess cm3 will automatically >> find the libs there. >> >> On new.elego.de (FreeBSD4) there was libgmp-4.2.1_1 already installed >> under /usr/local. >> >> MPFR was too old there too, so I installed 2.3.0 manually to >> /usr/contrib. I guess cm3 needs to be told to use libs residing under >> /usr/contrib ? > > Probably. Doesn't the FreeBSD ports system provide an update? Only with a later release tag (RELASE_6_3_0), you know I won't upgrade ports on a productive system apart from upgrading the base system as this can cause tremendous problems and might break other things running on the machine. > If you can build it manually, perhaps it is sufficient to just > increase the version numbers in the port and send the patch > to a FreeBSD committer / the port maintainer? It has been built, but the next FreeBSD release and higher cope it anyways. I think it's better to some day upgrade new.elego.de to FreeBSD 7 in order to have more current package versions. But we could probably move the FreeBSD-targeted cm3 regression tests from new.elego.de to willow.elego.de, which can be more easily upgraded to FreeBSD 7. Stupidly this would cause trouble in the tinderbox view, when a new hostname would appear. Cheers, Ronny > > Olaf > >> Cheers, >> >> Ronny >> >> -- >> Message from: Olaf Wagner >> Date: Di 15 Apr 2008 08:35:16 CEST >> Subject: new cm3 backend dependencies >> >> >>> Hi Ronny, >>> >>> Antony Hosking has updated the gcc in cm3, which leads to new >>> build dependencies which are not available at our regression test >>> systems: >>> >>> 1088 NEXT configure: error: Building GCC requires GMP 4.1+ and MPFR >>> 2.3.0+. >>> >>> Can you provide these? >>> >>> Olaf >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>> 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >> >> >> >> -- >> >> Ronny Forberger >> Systemadministration & IT-Support >> >> elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 >> Geb?ude 12, Raum 227 >> D-13355 Berlin >> >> Tel. +49 30 23 45 86 96 ronny.forberger at elegosoft.com >> Fax +49 30 23 45 86 95 http://www.elegosoft.com >> >> Gesch?ftsf?hrer: Olaf Wagner, Sitz Berlin >> Amtsgericht Berlin-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 -- Ronny Forberger Systemadministration & IT-Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Geb?ude 12, Raum 227 D-13355 Berlin Tel. +49 30 23 45 86 96 ronny.forberger at elegosoft.com Fax +49 30 23 45 86 95 http://www.elegosoft.com Gesch?ftsf?hrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Tue Apr 15 14:09:13 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 15 Apr 2008 08:09:13 -0400 Subject: [M3devel] small set comparisons understood, now just to understand the front end code.. In-Reply-To: <20080415110740.GA12952@topoi.pooq.com> References: <32E9EDBE-18FC-4F1B-8653-E60FC39DD534@cs.purdue.edu> <20080415110740.GA12952@topoi.pooq.com> Message-ID: <20080415120913.GC12952@topoi.pooq.com> On Tue, Apr 15, 2008 at 07:07:40AM -0400, hendrik at topoi.pooq.com wrote: > On Mon, Apr 14, 2008 at 11:22:35AM -0400, Tony Hosking wrote: > > > > Yes, that seems quite wrong. I can't imagine things ever worked > > properly if that is how they are implemented. > > Maybe stick a test in the compiler to see if < > <= >= are ever used on > small sets anywhere in the m3 system? You might want to do this anyway > in case anyone is relying on them doing integer comparisons. > > I seem to remember using them for subset comparisons in a Pascal program > I converted to modula 3 many years ago. I was using the PM3 compiler > then, and I haven't tried it on cm3 yet. I'd have to check the code to > see what I was really doing, though. Found it. I didn't actually use < or <=. I used *. - hendrik From wagner at elegosoft.com Tue Apr 15 15:11:17 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 15 Apr 2008 15:11:17 +0200 Subject: [M3devel] new cm3 backend dependencies In-Reply-To: <20080415133129.d6xwc1x1oo40co0c@mail.elegosoft.com> References: <20080415083516.i3vino6o0w400osw@mail.elegosoft.com> <20080415125155.wi1hnkfy4gsk4cks@mail.elegosoft.com> <20080415130531.kjb7fdsbjswk4sck@mail.elegosoft.com> <20080415133129.d6xwc1x1oo40co0c@mail.elegosoft.com> Message-ID: <20080415151117.ns7s255eckoowgow@mail.elegosoft.com> Quoting Ronny Forberger : > -- > Message from: Olaf Wagner > Date: Di 15 Apr 2008 13:05:31 CEST > Subject: Re: new cm3 backend dependencies > > >> Quoting Ronny Forberger : >> >>> Hi there, >>> >>> on birch.elego.de (LINUXLIBC6) there is GMP 4.2.1 on the package >>> management system, which I installed. >>> >>> Also there is MPFR but only at version <2.3.0, this is why I installed >>> MPFR 2.3.0 under the prefix /usr/local. I guess cm3 will automatically >>> find the libs there. >>> >>> On new.elego.de (FreeBSD4) there was libgmp-4.2.1_1 already installed >>> under /usr/local. >>> >>> MPFR was too old there too, so I installed 2.3.0 manually to >>> /usr/contrib. I guess cm3 needs to be told to use libs residing under >>> /usr/contrib ? >> >> Probably. Doesn't the FreeBSD ports system provide an update? > > Only with a later release tag (RELASE_6_3_0), you know I won't upgrade > ports on a productive system apart from upgrading the base system as > this can cause tremendous problems and might break other things running > on the machine. This is OK as a base strategy, but not in the following cases: (1) security updates of ports which need to be installed (2) development servers which need to provide a more recent and active view for the programmer To (1): Even on stable production systems security fixes should lead to port upgrades. To (2): Developers often need the latest version of any software, so if the standard one provided is too old, a second port hierarchy needs to be available. Is this the current use of /usr/contrib? >> If you can build it manually, perhaps it is sufficient to just >> increase the version numbers in the port and send the patch >> to a FreeBSD committer / the port maintainer? > > It has been built, but the next FreeBSD release and higher cope it > anyways. I think it's better to some day upgrade new.elego.de to > FreeBSD 7 in order to have more current package versions. This is a major upgrade and might have other impacts due to incompatibilities. I'd be more careful in upgrading the base system than in upgrading ports. > But we could probably move the FreeBSD-targeted cm3 regression tests > from new.elego.de to willow.elego.de, which can be more easily upgraded > to FreeBSD 7. Stupidly this would cause trouble in the tinderbox view, > when a new hostname would appear. This may be a good idea anyway, but we should progress carefully towards the FreeBSD 7 upgrade. We should also take this discussion from the m3devel-list ;-) I'll see if I can provide a fix for gcc to scan /usr/contrib for dependencies, too. It may take some time. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Tue Apr 15 19:38:56 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 15 Apr 2008 13:38:56 -0400 Subject: [M3devel] new cm3 backend dependencies In-Reply-To: <20080415125155.wi1hnkfy4gsk4cks@mail.elegosoft.com> References: <20080415083516.i3vino6o0w400osw@mail.elegosoft.com> <20080415125155.wi1hnkfy4gsk4cks@mail.elegosoft.com> Message-ID: <5B0A38FF-7170-40A1-AD8F-6E792AC73CD8@cs.purdue.edu> Yes, forgot to mention this. /usr/lib will get foun by configure, so that is the best option if it is not installed as a package to /usr/lib. On Apr 15, 2008, at 6:51 AM, Ronny Forberger wrote: > Hi there, > > on birch.elego.de (LINUXLIBC6) there is GMP 4.2.1 on the package > management system, which I installed. > > Also there is MPFR but only at version <2.3.0, this is why I > installed MPFR 2.3.0 under the prefix /usr/local. I guess cm3 will > automatically find the libs there. > > On new.elego.de (FreeBSD4) there was libgmp-4.2.1_1 already > installed under /usr/local. > > MPFR was too old there too, so I installed 2.3.0 manually to /usr/ > contrib. I guess cm3 needs to be told to use libs residing under / > usr/contrib ? > > Cheers, > > Ronny > > -- > Message from: Olaf Wagner > Date: Di 15 Apr 2008 08:35:16 CEST > Subject: new cm3 backend dependencies > > >> Hi Ronny, >> >> Antony Hosking has updated the gcc in cm3, which leads to new >> build dependencies which are not available at our regression test >> systems: >> >> 1088 NEXT configure: error: Building GCC requires GMP 4.1+ and >> MPFR >> 2.3.0+. >> >> Can you provide these? >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >> Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >> 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >> Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 > > > > -- > > Ronny Forberger > Systemadministration & IT-Support > > elego Software Solutions GmbH > Gustav-Meyer-Allee 25 > Geb?ude 12, Raum 227 > D-13355 Berlin > > Tel. +49 30 23 45 86 96 ronny.forberger at elegosoft.com > Fax +49 30 23 45 86 95 http://www.elegosoft.com > > Gesch?ftsf?hrer: Olaf Wagner, Sitz Berlin > Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 > > From jayk123 at hotmail.com Wed Apr 16 12:18:38 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 16 Apr 2008 10:18:38 +0000 Subject: [M3devel] cm3 regression In-Reply-To: <692B2748-B602-4A6E-B729-3C543772233F@cs.purdue.edu> References: <200804141718.m3EHIExE075667@camembert.async.caltech.edu> <692B2748-B602-4A6E-B729-3C543772233F@cs.purdue.edu> Message-ID: [tangential...] I think the definition of INTEGER is OK, but it'd be nice imho for the language or m3core to also build-in UINTEGER, INT8, INT16, INT32, INT64, UINT8, UINT16, UINT32, UINT64, just so folks wouldn't have to provide them themselves. (CARDINAL I don't think is what I want.) Add them somewhere in m3core? MODULE Integers; ? Unfortunately, actually, I want more than this, and then coming up with names is hard. I want "safe" integers that raise exceptions or something upon overflow. I want "unsafe" integers that silently "wrap around". And maybe "arbitrary precision" integers that grow to accomodate, but also are smart and shrink to throw away trailing zeros. I know you can often push stuff out of the language and into a library. As long as the language allows the library writer to provide a "nice enough" interface. For example the use of the plus sign on user defined types.. You know..like C++... but less complicated and easier to implement and fully understand... In C, "officially", unsigned integers are unsafe and wrap around silently, and overflow on signed integers is undefined, however in reality, they are also silent, and I suspect, but am not sure, that I want both versions..maybe only for compat with existing code. Which reminds me -- am I correct that the Modula-3 language defines overflow as raising an exception but nobody implements it that way? I can check. Are folks interested in fixing that? - Jay > CC: jayk123 at hotmail.com; m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: mika at async.caltech.edu > Subject: Re: [M3devel] cm3 regression > Date: Mon, 14 Apr 2008 14:42:07 -0400 > > I think Modula-3 has it exactly right in that the base types INTEGER > and Word.T use the natural word size of the machine, and that there > are no guarantees about BITSIZE on those. If you want a specific bit > size you use BITS FOR or simply a subrange type, both of which pack > down in memory to just the number of bytes needed. C is generally a > mess since you have both LLP64 (Windows) and LP64 (everyone else, for > good reason -- see http://www.unix.org/version2/whatsnew/ > lp64_wp.html). In any case, yes, I expect there will need to be a > fork of BasicCTypes along the lines of ILP32, LP64, and LLP64. > Currently, we have the strangeness that NT386 = ILP32/LL32 (because > the integrated backend can't grok LL64), but this is an anomaly. > Ideally, this would go to LLP64 (IL32) to match the Win64 world. > Remember, this is only for *C types*. On all 64-bit platforms, we > should aim for 64-bit INTEGER and 64-bit Word.T as the native Modula-3 > types. How C types fall out depends on the native C expectations of > the platform, and really are just about interfacing to C APIs. > > On Apr 14, 2008, at 1:18 PM, Mika Nystrom wrote: > > > Jay writes: > >> --_50e47a65-f79d-472b-8eaf-fbcc30b6410e_ > >> Content-Type: text/plain; charset="iso-8859-1" > >> Content-Transfer-Encoding: quoted-printable > >> > >> new source -> compiling Cstdlib.i3"..\src\C\32BITS\BasicCtypes.i3", > >> line 18= > >> : illegal based LONGINT literal, zero used"..\src\C\32BITS > >> \BasicCtypes.i3",= > >> line 18: illegal based LONGINT literal, zero used > >> long_long =3D [-16_7fffffffffffffffL-1L .. > >> 16_7fffffffffffffffL]= > >> ; > >> =20 > >> Why isn't this LONGINT? So that NT386 can limp along? And it'd be > >> correct f= > >> or the rest, eh? > >> I'll try it and see.. > >> =20 > >> The underlying system (the compiler) has (U)Int[8,16,32,64] > >> They should just be used here imho.. > >> =20 > >> Also, what should "long" be on 64bit? > >> On Windows it is 32 bits always. > >> On 32 bit systems it is 32 bits. > >> I think the 64bits directory is going to be forked for AMD64_NT_*. > >> The Windows decision imho has successfully been applied to more > >> code and mo= > >> re users so therefore is better by practical success, even if the > >> whole iss= > >> ue is problematic almost no matter what. Clearly the C and Modula-3 > >> notions= > >> of integers are pretty poor.. > > > > I have to re-code my program to use Int64 if I want it to use the > > natural INTEGER size on 64 bit machines? No thanks. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Apr 16 12:47:58 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 16 Apr 2008 12:47:58 +0200 Subject: [M3devel] cm3 regression In-Reply-To: References: <200804141718.m3EHIExE075667@camembert.async.caltech.edu> <692B2748-B602-4A6E-B729-3C543772233F@cs.purdue.edu> Message-ID: <20080416124758.lgyai5sjs40wc8k4@mail.elegosoft.com> Quoting Jay : > [tangential...] > > I think the definition of INTEGER is OK, but it'd be nice imho for > the language or m3core to also build-in UINTEGER, INT8, INT16, > INT32, INT64, UINT8, UINT16, UINT32, UINT64, just so folks wouldn't > have to provide them themselves. (CARDINAL I don't think is what I > want.) > Add them somewhere in m3core? > MODULE Integers; ? Such things may be convenient for programmers, but are left out of the language because the specification must not become too long, I think. I'd opt for library extensions in this case. > Unfortunately, actually, I want more than this, and then coming up > with names is hard. > > I know you can often push stuff out of the language and into a > library. As long as the language allows the library writer to > provide a "nice enough" interface. For example the use of the plus > sign on user defined types.. You know..like C++... but less > complicated and easier to implement and fully understand... Ah, operator overloading opens up another of Pandora's boxes, I think. It will dramatically increase the complexity of the language. > In C, "officially", unsigned integers are unsafe and wrap around > silently, and overflow on signed integers is undefined, however in > reality, they are also silent, and I suspect, but am not sure, that > I want both versions..maybe only for compat with existing code. > > Which reminds me -- am I correct that the Modula-3 language defines > overflow as raising an exception but nobody implements it that way? > I can check. Are folks interested in fixing that? Yes, IIRC there are no checks on integer overflow; this is an implementation flaw. How would you provide this? Add generation of checks on every integer operation? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Wed Apr 16 14:30:14 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 16 Apr 2008 08:30:14 -0400 Subject: [M3devel] cm3 regression In-Reply-To: <20080416124758.lgyai5sjs40wc8k4@mail.elegosoft.com> References: <200804141718.m3EHIExE075667@camembert.async.caltech.edu> <692B2748-B602-4A6E-B729-3C543772233F@cs.purdue.edu> <20080416124758.lgyai5sjs40wc8k4@mail.elegosoft.com> Message-ID: <20080416123014.GA13596@topoi.pooq.com> On Wed, Apr 16, 2008 at 12:47:58PM +0200, Olaf Wagner wrote: > Quoting Jay : > > >[tangential...] > > > >I think the definition of INTEGER is OK, but it'd be nice imho for > >the language or m3core to also build-in UINTEGER, INT8, INT16, > >INT32, INT64, UINT8, UINT16, UINT32, UINT64, just so folks wouldn't > >have to provide them themselves. (CARDINAL I don't think is what I > >want.) > >Add them somewhere in m3core? > >MODULE Integers; ? > > Such things may be convenient for programmers, but are left out of the > language because the specification must not become too long, I think. > I'd opt for library extensions in this case. > > >Unfortunately, actually, I want more than this, and then coming up > >with names is hard. > > > >I know you can often push stuff out of the language and into a > >library. As long as the language allows the library writer to > >provide a "nice enough" interface. For example the use of the plus > >sign on user defined types.. You know..like C++... but less > >complicated and easier to implement and fully understand... > > Ah, operator overloading opens up another of Pandora's boxes, > I think. It will dramatically increase the complexity of the > language. > > >In C, "officially", unsigned integers are unsafe and wrap around > >silently, and overflow on signed integers is undefined, however in > >reality, they are also silent, and I suspect, but am not sure, that > >I want both versions..maybe only for compat with existing code. > > > >Which reminds me -- am I correct that the Modula-3 language defines > >overflow as raising an exception but nobody implements it that way? > >I can check. Are folks interested in fixing that? > > Yes, IIRC there are no checks on integer overflow; this is an > implementation flaw. How would you provide this? Add generation of > checks on every integer operation? IIRC, most hardware provides a mechanism for efficient overflow detection. If the language does not provide access to this hardware mechanism, if becomes difficult and inefficient for the programmer to detect overflow. Since checked overflow is necessary for many security issues, the language needs to make it possible to check. How it should do so can be a subject for much dispute. And for Modula 3 it may be difficult if the gcc back end does not support it. -- hendrik From jayk123 at hotmail.com Wed Apr 16 15:31:03 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 16 Apr 2008 13:31:03 +0000 Subject: [M3devel] current cm3cg works? Message-ID: bootstrapping from 5.4.0 on KUbuntu Hardy Heron 8.4 beta AMD64 cm3 just core dumps..around ThreadF__Init probably the setjmp/longjmp scrambling bug 5.4.0 is what the regression framework defaulted to starting with, that's how I picked it. so tried from d5.7.0-2008-04-10-02-00-05 instead my cm3cg yields like: new source -> compiling SystemPosix.m3 ../src/POSIX/SystemPosix.m3: In function 'System__Hostname': ../src/POSIX/SystemPosix.m3:37: internal compiler error: in simplify_subreg, at simplify-rtx.c:4923 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling FSUnix_cm3.m3 ../src/POSIX/FSUnix_cm3.m3: In function 'FSUtils__IsReadable': ../src/POSIX/FSUnix_cm3.m3:10: internal compiler error: in int_mode_for_mode, at stor-layout.c:258 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling TextUtils.m3 ../src/cm3/TextUtils.m3: In function 'TextUtils__SkipLeft': ../src/cm3/TextUtils.m3:36: internal compiler error: in int_mode_for_mode, at stor-layout.c:258 Please submit a full bug report, so now going back to the cm3cg in d5.7.0-2008-04-10-02-00-05 That works, scripts/python/upgrade.py succeeds, having set OMIT_GCC (probably should be CM3_OMIT_GCC). No time right now to dig in.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Apr 16 16:08:11 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 16 Apr 2008 14:08:11 +0000 Subject: [M3devel] cm3 regression In-Reply-To: <20080416124758.lgyai5sjs40wc8k4@mail.elegosoft.com> References: <200804141718.m3EHIExE075667@camembert.async.caltech.edu> <692B2748-B602-4A6E-B729-3C543772233F@cs.purdue.edu> <20080416124758.lgyai5sjs40wc8k4@mail.elegosoft.com> Message-ID: > > it'd be nice imho for the language or m3core to also build-in UINTEGER, INT8, INT16, > > INT32, INT64, UINT8, UINT16, UINT32, UINT64, just so folks wouldn't > > have to provide them themselves. (CARDINAL I don't think is what I > > want.) > > Add them somewhere in m3core? > > MODULE Integers; ? > > Such things may be convenient for programmers, but are left out of the > language because the specification must not become too long, I think. > I'd opt for library extensions in this case. Good enough. Except I'm not sure about UINTEGER..like..why is CARDINAL only half range? I'd have to dig in..NOT now.. > Yes, IIRC there are no checks on integer overflow; this is an > implementation flaw. How would you provide this? Add generation of > checks on every integer operation? Well, it's a no-win situation. The check would bloat the code. Even function calls would bloat and slow. Probably function calls. And then hopefully optimize them some. For example: FOR i := 0 TO n DO ... END; Check up front then n isn't negative, and then no checking is needed for the incrementing of n to overflow. Similarly, FOR i := 0 TO n BY 2 DO ... END; or whatever is the syntax, check if the start/end are divisible by the increment and the start is less than the end, and then no overflow check needed. I guess on most architectures every add/sub/mul/div instruction would tend to have one additional instruction, a conditional branch, after it. It will take some investigation. Perhaps gnat (GNU Ada compiler, part of gcc) or gpc (Pascal, I think likewise, maybe) already provide this though. Maybe just some simple reuse. There'd probably be pragmas or other types to choise behavior, esp. in unsafe modules. Anyway, none of this particular soon, at least by me, I have a bunch of other things I want to do or see done first. But sure we can talk about it or someone else can do it. :) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Wed Apr 16 17:17:23 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 16 Apr 2008 08:17:23 -0700 Subject: [M3devel] cm3 regression In-Reply-To: Your message of "Wed, 16 Apr 2008 10:18:38 -0000." Message-ID: <200804161517.m3GFHNTt056611@camembert.async.caltech.edu> Jay writes: >--_17f831a5-9311-459c-8ba3-fd6675a58221_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >[tangential...] > >I think the definition of INTEGER is OK, but it'd be nice imho for the lang= >uage or m3core to also build-in UINTEGER, INT8, INT16, INT32, INT64, UINT8,= > UINT16, UINT32, UINT64, just so folks wouldn't have to provide them themse= >lves. (CARDINAL I don't think is what I want.) >Add them somewhere in m3core? >MODULE Integers; ? I don't see why you can't provide all these types for yourself in a library that users can import or not as they see fit... as long as my old INTEGER programs are still going to use the "default fast integer type" on the machine! I can see your arguments for using such pre-defined fixed-width types inside system-dependent compiler bits or specific system-dependent source files even in other situations. (Although I would still argue that part of the point of Modula-3 is to get away from this kind of system-dependent-everything programming! Write once, run anywhere! Oops, am I using someone else's slogan?) > >Unfortunately, actually, I want more than this, and then coming up with nam= >es is hard. > >I want "safe" integers that raise exceptions or something upon overflow. INTEGER/CARDINAL? You could just name yours INTEGER32, CARDINAL64, etc. According to the Green Book, overflows for these types are supposed to raise exceptions or cause some other kind of runtime error. (Actually, I am not sure it says so explicitly, but that is definitely the simplest interpretation of what it does say.) If you want exceptions on overflow, you do want CARDINAL, not UINTEGER. Or what would you like 4-5 to return in this "exceptional unsigned" integer type? >I want "unsafe" integers that silently "wrap around". Word.T? Word128.T? By the way there is nothing "unsafe" about this. "Unsafe" has a very specific meaning to Modula-3 people, which I think it would be nice if we could maintain at least on the "m3devel" mailing list! See sections 2.1 (first paragraph of the language definition), 2.5.7, and 2.7 of the Green Book. >And maybe "arbitrary precision" integers that grow to accomodate, but also = >are smart and shrink to throw away trailing zeros. Isn't there already a library for this in CM3? Mika From rodney.bates at wichita.edu Wed Apr 16 22:40:57 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Wed, 16 Apr 2008 15:40:57 -0500 Subject: [M3devel] cm3 regression In-Reply-To: References: <200804141718.m3EHIExE075667@camembert.async.caltech.edu> <692B2748-B602-4A6E-B729-3C543772233F@cs.purdue.edu> <20080416124758.lgyai5sjs40wc8k4@mail.elegosoft.com> Message-ID: <48066459.8000301@wichita.edu> Jay wrote: >>>it'd be nice imho for the language or m3core to also build-in UINTEGER, INT8, INT16, >>>INT32, INT64, UINT8, UINT16, UINT32, UINT64, just so folks wouldn't >>>have to provide them themselves. (CARDINAL I don't think is what I >>>want.) >>>Add them somewhere in m3core? >>>MODULE Integers; ? >> >>Such things may be convenient for programmers, but are left out of the >>language because the specification must not become too long, I think. >>I'd opt for library extensions in this case. > > > Good enough. > Except I'm not sure about UINTEGER..like..why is CARDINAL only half range? > I'd have to dig in..NOT now.. > I've been through this in Modula-2. There, CARDINAL is a whole, unsigned range. Unfortunately, this created a linguistic and portability nightmare. It was worse because I don't think the original Modula-2 definition completely specified things like assignability between the two, operators on mixtures of the two, implied conversions, etc. I know different implementations were different to the point it was difficult even to write code that would compile on them all. Maybe there is a cleaner way to have two distinct types, one signed, one unsigned, and both full range, but it would at least be tricky. The Modula-3 way is found in Word. Word.T is the same type as INTEGER, but the operations in Word (e.g. Word.Times) apply unsigned interpretation to the bits of the same-typed value. This avoids a lot of problems. So for full range, unsigned, values, use Word (and probably, to show your intent to readers, declare variables as Word.T rather than INTEGER, even though it is the same type). As for CARDINAL in Modula-3, it was originally exactly [0..LAST(INTEGER)]. This was changed later to say it is "just like" [0..LAST(INTEGER)]. It was years before I fully understood this. I once posted a question on the M3 newsgroup about it and gave up waiting for an answer. Then I read the compiler code and found what it means, literally, is that CARDINAL is a different type from [0..LAST(INTEGER)], but the two have all the same legal operations. This distinction seldom matters, because it is almost always assignability and not type equality that is relevant. Which didn't help explain why. Then there was an answer to my question saying that the change in the definition of CARDINAL was to support Pickles, but this still left me in the dark. Finally, while working on Pickles, it dawned on me that, without the change, it would not be possible for Pickles to change the size of a CARDINAL between 32 & 64 bits. The type [0..LAST(INTEGER)] (or any other similar subrange) is a different type if LAST(INTEGER) has a different value. CARDINAL, in contrast, can change range between platforms and still be the same type. Moral: Don't pickle anything whose type contains values like LAST(INTEGER) that differ from platform to platform. > >>Yes, IIRC there are no checks on integer overflow; this is an >>implementation flaw. How would you provide this? Add generation of >>checks on every integer operation? > > > Well, it's a no-win situation. > The check would bloat the code. > Even function calls would bloat and slow. > Probably function calls. I happen to be extremely conservative on the value of detecting runtime errors, even at efficiency cost. I heard some horror stories in the early years of my career about programs that had been in use for years and whose output had been used to plan the expenditure of huge amounts of money, then were accidentally found to be producing wrong (though not obviously so) output, that would have been caught by running with runtime checks enabled. In any case, big time cost increases (e.g. double) associated with a few operations very often amortize over the whole program's run time to only 1% or 2%. > > And then hopefully optimize them some. > For example: > FOR i := 0 TO n DO > ... > END; > > Check up front then n isn't negative, and then no checking is needed for the incrementing of n to overflow. Overflow in compiler-generated arithmetic is a little different than in arithmetic explicitly coded by the programmer. In this example, the language specifically exempts the compiler from worrying about this. 2.3.16, last sentence: "If the upper bound of the loop is LAST(INTEGER), it should be rewritten as a WHILE loop to avoid overflow." As for other optimizations, the language specifies the semantics, so a compiler is free to do anything that complies with this. > > Similarly, > FOR i := 0 TO n BY 2 DO > > ... > > END; > > or whatever is the syntax, check if the start/end are divisible by the increment and the start is less than the end, and then no overflow check needed -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From dabenavidesd at yahoo.es Wed Apr 16 23:47:16 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 16 Apr 2008 23:47:16 +0200 (CEST) Subject: [M3devel] cm3 regression In-Reply-To: <48066459.8000301@wichita.edu> Message-ID: <734362.39663.qm@web27109.mail.ukl.yahoo.com> Hi all: The best idea I thing, tough I'm not an expert is to use static methods at the low level of the m3 system, let's say the gcc backend. This is not something really easy, but it's doable. I know for Open64 project http://www.open64.net, see "Implement a static program analysis tool based on Open64 compiler". It's something I found interesting in that area. SRC Modula-3 version 3.3 does not do arithmetic overflow or underflow checking, see the manual reference attached in the mail (see section 1.11.1). But what about pm3 or cm3? The other way it's also more traditional with static tools in the source code of the compiled program (well it's more tedious for most of us, it's using a specification language for a checker). Someone has checked open 64 as a possible backend of cm3? Thanks "Rodney M. Bates" escribi?: Jay wrote: >>>it'd be nice imho for the language or m3core to also build-in UINTEGER, INT8, INT16, >>>INT32, INT64, UINT8, UINT16, UINT32, UINT64, just so folks wouldn't >>>have to provide them themselves. (CARDINAL I don't think is what I >>>want.) >>>Add them somewhere in m3core? >>>MODULE Integers; ? >> >>Such things may be convenient for programmers, but are left out of the >>language because the specification must not become too long, I think. >>I'd opt for library extensions in this case. > > > Good enough. > Except I'm not sure about UINTEGER..like..why is CARDINAL only half range? > I'd have to dig in..NOT now.. > I've been through this in Modula-2. There, CARDINAL is a whole, unsigned range. Unfortunately, this created a linguistic and portability nightmare. It was worse because I don't think the original Modula-2 definition completely specified things like assignability between the two, operators on mixtures of the two, implied conversions, etc. I know different implementations were different to the point it was difficult even to write code that would compile on them all. Maybe there is a cleaner way to have two distinct types, one signed, one unsigned, and both full range, but it would at least be tricky. The Modula-3 way is found in Word. Word.T is the same type as INTEGER, but the operations in Word (e.g. Word.Times) apply unsigned interpretation to the bits of the same-typed value. This avoids a lot of problems. So for full range, unsigned, values, use Word (and probably, to show your intent to readers, declare variables as Word.T rather than INTEGER, even though it is the same type). As for CARDINAL in Modula-3, it was originally exactly [0..LAST(INTEGER)]. This was changed later to say it is "just like" [0..LAST(INTEGER)]. It was years before I fully understood this. I once posted a question on the M3 newsgroup about it and gave up waiting for an answer. Then I read the compiler code and found what it means, literally, is that CARDINAL is a different type from [0..LAST(INTEGER)], but the two have all the same legal operations. This distinction seldom matters, because it is almost always assignability and not type equality that is relevant. Which didn't help explain why. Then there was an answer to my question saying that the change in the definition of CARDINAL was to support Pickles, but this still left me in the dark. Finally, while working on Pickles, it dawned on me that, without the change, it would not be possible for Pickles to change the size of a CARDINAL between 32 & 64 bits. The type [0..LAST(INTEGER)] (or any other similar subrange) is a different type if LAST(INTEGER) has a different value. CARDINAL, in contrast, can change range between platforms and still be the same type. Moral: Don't pickle anything whose type contains values like LAST(INTEGER) that differ from platform to platform. > >>Yes, IIRC there are no checks on integer overflow; this is an >>implementation flaw. How would you provide this? Add generation of >>checks on every integer operation? > > > Well, it's a no-win situation. > The check would bloat the code. > Even function calls would bloat and slow. > Probably function calls. I happen to be extremely conservative on the value of detecting runtime errors, even at efficiency cost. I heard some horror stories in the early years of my career about programs that had been in use for years and whose output had been used to plan the expenditure of huge amounts of money, then were accidentally found to be producing wrong (though not obviously so) output, that would have been caught by running with runtime checks enabled. In any case, big time cost increases (e.g. double) associated with a few operations very often amortize over the whole program's run time to only 1% or 2%. > > And then hopefully optimize them some. > For example: > FOR i := 0 TO n DO > ... > END; > > Check up front then n isn't negative, and then no checking is needed for the incrementing of n to overflow. Overflow in compiler-generated arithmetic is a little different than in arithmetic explicitly coded by the programmer. In this example, the language specifically exempts the compiler from worrying about this. 2.3.16, last sentence: "If the upper bound of the loop is LAST(INTEGER), it should be rewritten as a WHILE loop to avoid overflow." As for other optimizations, the language specifies the semantics, so a compiler is free to do anything that complies with this. > > Similarly, > FOR i := 0 TO n BY 2 DO > > ... > > END; > > or whatever is the syntax, check if the start/end are divisible by the increment and the start is less than the end, and then no overflow check needed -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu --------------------------------- Tu correo tambi?n desde el m?vil. Desc?rgate gratis Yahoo! Go. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SRCm3-3.3.ps.gz Type: application/x-gzip Size: 95592 bytes Desc: 18170785-SRCm3-3.3.ps.gz URL: From neels at elego.de Thu Apr 17 00:59:56 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Thu, 17 Apr 2008 00:59:56 +0200 Subject: [M3devel] snapshot compilation fails on FreeBSD Message-ID: <480684EC.4060401@elego.de> Hi all, on new.elego.de, a FreeBSD 6.2-RELEASE-p3, using the files cm3-min-POSIX-FreeBSD4-d5.7.0-2008-04-14-01-30-39.tgz cm3-src-gnu-d5.7.0-2008-04-16-14-07-05.tgz cm3-src-std-d5.6.0-2008-02-23-22-14-00.tgz cm3-src-sys-d5.7.0-2008-04-16-14-07-05.tgz and running ./cminstall -i issuing installation target as /home/neels/local-new/cm3 then changing the $PATH so that $ which cm3 /home/neels/local-new/cm3/bin/cm3 and running $ cd scripts $ ./do-cm3-core.sh buildship yielded after a few minutes the following error: ... ==> /home/neels/cm3/cm3/m3-libs/m3core done === package /home/neels/cm3/cm3/m3-libs/libm3 === +++ cm3 -build -DROOT='/home/neels/cm3/cm3' -DCM3_VERSION_TEXT='d5.6.0' -DCM3_VERSION_NUMBER='050600' -DCM3_LAST_CHANGED='2008-01-31' && cm3 -ship -DROOT='/home/neels/cm3/cm3' -DCM3_VERSION_TEXT='d5.6.0' -DCM3_VERSION_NUMBER='050600' -DCM3_LAST_CHANGED='2008-01-31' +++ --- building in FreeBSD4 --- ignoring ../src/m3overrides new source -> compiling Atom.i3 new source -> compiling AtomList.i3 new source -> compiling OSError.i3 new source -> compiling File.i3 new source -> compiling RegularFile.i3 new source -> compiling Pipe.i3 new source -> compiling TextSeq.i3 new source -> compiling Pathname.i3 new source -> compiling FS.i3 new source -> compiling Process.i3 new source -> compiling Socket.i3 new source -> compiling Terminal.i3 new source -> compiling FS.m3 new source -> compiling Terminal.m3 new source -> compiling RegularFile.m3 new source -> compiling Pipe.m3 new source -> compiling Socket.m3 new source -> compiling OSConfig.i3 new source -> compiling OSErrorPosix.i3 new source -> compiling Fmt.i3 new source -> compiling OSErrorPosix.m3 new source -> compiling FilePosix.i3 new source -> compiling FilePosix.m3 new source -> compiling FSPosix.m3 new source -> compiling PipePosix.m3 new source -> compiling PathnamePosix.m3 new source -> compiling Env.i3 new source -> compiling ProcessPosix.m3 new source -> compiling SocketPosix.m3 Fatal Error: bad version stamps: SocketPosix.m3 version stamp mismatch: Compiler.Platform => SocketPosix.m3 => Compiler.i3 version stamp mismatch: Compiler.ThisPlatform => SocketPosix.m3 => Compiler.i3 *** execution of cm3 -build -DROOT='/home/neels/cm3/cm3' -DCM3_VERSION_TEXT='d5.6.0' -DCM3_VERSION_NUMBER='050600' -DCM3_LAST_CHANGED='2008-01-31' && cm3 -ship -DROOT='/home/neels/cm3/cm3' -DCM3_VERSION_TEXT='d5.6.0' -DCM3_VERSION_NUMBER='050600' -DCM3_LAST_CHANGED='2008-01-31' failed *** What does this mean? Thanks, Neels From hosking at cs.purdue.edu Thu Apr 17 01:24:37 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 16 Apr 2008 19:24:37 -0400 Subject: [M3devel] snapshot compilation fails on FreeBSD In-Reply-To: <480684EC.4060401@elego.de> References: <480684EC.4060401@elego.de> Message-ID: <0CE452FA-BE6F-40BC-8530-6AD84909223A@cs.purdue.edu> This is a result of the recent addition of an additional target AMD64_DARWIN to the compiler. You need to compile a new bootstrap compiler with the new target in it and use that to compile m3core. 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 Apr 16, 2008, at 6:59 PM, Neels Janosch Hofmeyr wrote: > Hi all, > > on new.elego.de, a FreeBSD 6.2-RELEASE-p3, using the files > > cm3-min-POSIX-FreeBSD4-d5.7.0-2008-04-14-01-30-39.tgz > cm3-src-gnu-d5.7.0-2008-04-16-14-07-05.tgz > cm3-src-std-d5.6.0-2008-02-23-22-14-00.tgz > cm3-src-sys-d5.7.0-2008-04-16-14-07-05.tgz > > > and running > > ./cminstall -i > > issuing installation target as > > /home/neels/local-new/cm3 > > then changing the $PATH so that > > $ which cm3 > /home/neels/local-new/cm3/bin/cm3 > > > and running > > $ cd scripts > $ ./do-cm3-core.sh buildship > > > yielded after a few minutes the following error: > > ... > ==> /home/neels/cm3/cm3/m3-libs/m3core done > > === package /home/neels/cm3/cm3/m3-libs/libm3 === > +++ cm3 -build -DROOT='/home/neels/cm3/cm3' - > DCM3_VERSION_TEXT='d5.6.0' > -DCM3_VERSION_NUMBER='050600' -DCM3_LAST_CHANGED='2008-01-31' && cm3 > -ship -DROOT='/home/neels/cm3/cm3' -DCM3_VERSION_TEXT='d5.6.0' > -DCM3_VERSION_NUMBER='050600' -DCM3_LAST_CHANGED='2008-01-31' +++ > --- building in FreeBSD4 --- > > ignoring ../src/m3overrides > > new source -> compiling Atom.i3 > new source -> compiling AtomList.i3 > new source -> compiling OSError.i3 > new source -> compiling File.i3 > new source -> compiling RegularFile.i3 > new source -> compiling Pipe.i3 > new source -> compiling TextSeq.i3 > new source -> compiling Pathname.i3 > new source -> compiling FS.i3 > new source -> compiling Process.i3 > new source -> compiling Socket.i3 > new source -> compiling Terminal.i3 > new source -> compiling FS.m3 > new source -> compiling Terminal.m3 > new source -> compiling RegularFile.m3 > new source -> compiling Pipe.m3 > new source -> compiling Socket.m3 > new source -> compiling OSConfig.i3 > new source -> compiling OSErrorPosix.i3 > new source -> compiling Fmt.i3 > new source -> compiling OSErrorPosix.m3 > new source -> compiling FilePosix.i3 > new source -> compiling FilePosix.m3 > new source -> compiling FSPosix.m3 > new source -> compiling PipePosix.m3 > new source -> compiling PathnamePosix.m3 > new source -> compiling Env.i3 > new source -> compiling ProcessPosix.m3 > new source -> compiling SocketPosix.m3 > > Fatal Error: bad version stamps: SocketPosix.m3 > > version stamp mismatch: Compiler.Platform > => SocketPosix.m3 > => Compiler.i3 > version stamp mismatch: Compiler.ThisPlatform > => SocketPosix.m3 > => Compiler.i3 > *** execution of cm3 -build -DROOT='/home/neels/cm3/cm3' > -DCM3_VERSION_TEXT='d5.6.0' -DCM3_VERSION_NUMBER='050600' > -DCM3_LAST_CHANGED='2008-01-31' && cm3 -ship > -DROOT='/home/neels/cm3/cm3' -DCM3_VERSION_TEXT='d5.6.0' > -DCM3_VERSION_NUMBER='050600' -DCM3_LAST_CHANGED='2008-01-31' > failed *** > > > > What does this mean? > > Thanks, > Neels -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Apr 17 08:40:10 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 17 Apr 2008 08:40:10 +0200 Subject: [M3devel] new gcc build time Message-ID: <20080417084010.k3clt47rk8go4www@mail.elegosoft.com> The first regression test run on my own system has now been successful after the import of the new gcc. The run time has increased dramatically from about 45 minutes to more than 5 hours :-/ Can anybody explain this? And can we do something about it? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Thu Apr 17 13:53:22 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 17 Apr 2008 11:53:22 +0000 Subject: [M3devel] new gcc build time In-Reply-To: <20080417084010.k3clt47rk8go4www@mail.elegosoft.com> References: <20080417084010.k3clt47rk8go4www@mail.elegosoft.com> Message-ID: I see this too. I've been experimenting.. --disable-bootstrap? I don't know yet. You know, it wants to build gcc to build gcc, but the host gcc usually suffices. Unless maybe bootstrapping from other than gcc, like using the Sun/SGI/AIX/whatever compilers? (Or old gcc on Mac OSX, has trouble building lots of stuff, though a switch worked..) It's also a pain to build on an AMD64 system, even though x86 stuff generally works. I have a whiny email coming up.. There's also this stage1, 2, 3 stuff, related to gcc building itself to build itself, and then again to verify. - Jay > Date: Thu, 17 Apr 2008 08:40:10 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] new gcc build time > > The first regression test run on my own system has now been successful > after the import of the new gcc. > > The run time has increased dramatically from about 45 minutes to > more than 5 hours :-/ > > Can anybody explain this? And can we do something about it? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 jayk123 at hotmail.com Thu Apr 17 14:03:59 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 17 Apr 2008 12:03:59 +0000 Subject: [M3devel] biarch, multilib, etc? Message-ID: Can anyone explain how Linux and gcc are managing that AMD64 systems can run and presumably build x86 code? I know there is /lib32 and /lib64. I know there is gcc -m32 and gcc -m64. I know that gcc itself delegates out to target specific executables, so one gcc plus flags suffices, it's those other executables that multiply out. That ld has the -m flag. That as has --32 and --64. I don't know how much stuff goes through gcc, vs. needs the get the as/ld flags correct. I'm not talking about Modula-3 here, but, like of building gcc and its dependencies. I can deal with the smaller Modula-3 system contained in far more readable Quake code than all the "sh" and layers upon layers of makefiles and autoconf and sh and m4 etc.. ./configure on various things tend to build just AMD64. It appears in general that for any apt-get install foo you can often but not always apt-get install foo-i386 This is on KUbuntu 8.4 Hardy Heron KDE4 beta AMD64 (mouthful!) It looks like in general: CC="gcc -m32" .../configure --prefix=/usr --libdir=/usr/lib32 --build=i686-pc-linux-gnu is what you want, but that many packages are only native. in particular gmp and mpfr: apt-get install mpfr-i386 => no luck Maybe these are not considered "mainstream"? I'll build them myself, something like: cd /usr/src apt-get source mpfr mkdir -p obj/mpfr cd obj/mpfr CC="gcc -m32" /usr/src/mpfr-2.3.1.dfsg.1/configure --prefix=/usr --libdir=/usr/lib32 --build=i686-pc-linux-gnu make sudo make install cd /usr/src apt-get source libgmp3-dev mkdir -p /usr/src/obj/gmp cd /usr/src/obj/obj CC="gcc -m32" /usr/src/gmp-4.2.2+dfsg/configure --prefix=/usr --libdir=/usr/lib32 --build=i686-pc-linux-gnu make sudo make install You know, I just want building the Modula-3 system on AMD64_LINUX to at first merely build an x86 hosted, x86 targeted binary. And then start changing things. And between host, target, and build, I find the names confusing. I understand why there are three -- the current system to build the compiler, a system to run the compiler, a system to run the compiler's output, but these names host, target, build, aren't very mnemonic with me yet. Is it build=now, host=runs the compier, target=runs the compiler's output? I'll dig around. I know, I can figure it all out, there's the www to search, but this biarch/multilib is hard to find the docs for..and I can't read the masses of m4/sh/gmake.. ps: it's easy to get the ld to crash when doing this stuff wrong.. (I can explain how Windows does it, fyi. 1) The system is "doubled up", generally .dlls and .exes, but not kernel and drivers c:\windows\system32 is native c:\windows\syswow64 is 32bit Yeah it's wierd/backwards, but it is source compatible. There is runtime magic to redirect from "system32" in 32 bit processes to syswow64. Though if folks used the very long standing APIs, this wouldn't have been needed. Oh well. There is also c:\program files and c:\program files (x86). I guess people are better about using the APIs here. "Introspection" is "broken" but this -- link -dump against c:\windows\system32 can get "redirected" but devtools aren't the priority and it does all generally work out, despite the hokiness. The registry is similarly doubled up and redirected, in some places at least, since it tends to give paths to .dlls -- a process is either 32bit or 64bit -- can't load one type .dll in other type process. On the devtools side, well, you know, NT always had ppc/mips/alpha/x86, so .libs are generally already in a directory named "i386" or "x86". In any case, folks don't hardcode paths as much, because they are already so variable. So you set up your environment or such using the %LIB% variable and it works easily. For running devtools, there is a separate set of .exes for each target. And sometimes for host. The matrix is filled out as necessary. AMD64 runs x86 fast so not always useful to fill out the matrix. Sometimes a slash is used, sometimes an underscore, sometimes "win64" inserted, but again, it's generally reasonable hidden behind a .bat file to set the environment and set $PATH and set the console's title (console == xterm, not the one special console). If you have more than one cl.exe or link.exe on your path, not good. cl.exe does more work than the gcc driver, it doesn't delegate out as much. There are no "fat" files like Apple does, well, not mechanized/systematic. Something like sysinternals handle.exe that has an embedded driver has a toplevel x86 file that runs on everything and then on demand extracts the AMD64 or IA64 executable and driver, runs the other version of itself, installs the driver on demand and voila.. ) - Jay From wagner at elegosoft.com Thu Apr 17 14:25:25 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 17 Apr 2008 14:25:25 +0200 Subject: [M3devel] new gcc build time In-Reply-To: References: <20080417084010.k3clt47rk8go4www@mail.elegosoft.com> Message-ID: <20080417142525.crce5s5s1wggk04c@mail.elegosoft.com> Quoting Jay : > I see this too. > I've been experimenting.. > --disable-bootstrap? > I don't know yet. I don't think we have ever done a full gcc bootstrap for cm3cg, have we? Is there any reason to do that now? If not, complete bootstrapping of gcc should be disabled again. Or we should make it an option depending on a variable setting like -DCOMPLETE_GCC_BOOTSTRAP or similar. Any other opinions? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Thu Apr 17 15:00:51 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 17 Apr 2008 13:00:51 +0000 Subject: [M3devel] new gcc build time In-Reply-To: <20080417142525.crce5s5s1wggk04c@mail.elegosoft.com> References: <20080417084010.k3clt47rk8go4www@mail.elegosoft.com> <20080417142525.crce5s5s1wggk04c@mail.elegosoft.com> Message-ID: I don't think so. I don't think so. I don't think so. :) I don't think we bootstrapped. I don't think there's much reason. I don't think it should even be an option. But I don't know. It should be faster. I think a reason to bootstrap would be if the system's C compiler can't compile gcc. That is, if it isn't gcc, or is an old gcc. Or maybe even that is false -- not sure what the requirements to build gcc are. Given that usually it is gcc and recent, seems like little reason. Maybe "SOLsun" would do it, for example. ?????? I'm still having trouble just making an x86 hosted x86 targeted build on AMD64, but I'm close. Something like CC="gcc -m32 -Xassembler --32" configure --target=i686-pc-linux-gnu --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu though I'm sure that's overkill to specify three architectures. I have to read the explanation of which is which. When there are only two, host and target make sense, is "build" the current one that is building the compiler, host is where it will run, target is what it will produce? I guess that's reasonable. So build could always be sniffed automatically and it might as well be native -- this compiler already must exist, or it is stage1 if bootstrapping from other than gcc. ? I guess stage1 is build a build-hosted host-targeted compiler, stage2 is host-hosted, target-targeted, what you actually want, stage3 is the same, and compare? Something like that? I should read up.. this doesn't seem like enough passes when building a cross-compiler, or just you have skip the "compare" when building a cross compiler? Later.. - Jay > Date: Thu, 17 Apr 2008 14:25:25 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] new gcc build time > > Quoting Jay : > > > I see this too. > > I've been experimenting.. > > --disable-bootstrap? > > I don't know yet. > > I don't think we have ever done a full gcc bootstrap for cm3cg, > have we? Is there any reason to do that now? > If not, complete bootstrapping of gcc should be disabled again. > Or we should make it an option depending on a variable setting > like -DCOMPLETE_GCC_BOOTSTRAP or similar. > > Any other opinions? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 jayk123 at hotmail.com Thu Apr 17 15:32:19 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 17 Apr 2008 13:32:19 +0000 Subject: [M3devel] biarch, multilib, etc? Message-ID: > And between host, target, and build, I find the names confusing. Ok I was the victim of an older less clear document. The current docs are clear and agreed with my guess. Host is the "future host", the machine that will run the compiler you are building. Target is the target of the compiler you are building. Build is the *Host* you are building the compiler on right now. The terminology I believe derives from the viewpoint that not many people build compilers. Host the machine are you developing on, running the compiler, editor. Target is the machine you are producing code for. "Build" is much less often seen, so its name isn't so clear. It is the host that builds the compiler. But not the host that, like, builds "the real code". Unless that real code, is, uh, the compiler (and linker). While "Build" should be reliably guessable from uname et. al., I think the docs warned against not specifying it if specifying others. You know, if I'm on AMD64, whether "build" is AMD64 or x86 has theoretically no bearing on the result, so I shouldn't care. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Apr 17 19:00:10 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 17 Apr 2008 13:00:10 -0400 Subject: [M3devel] new gcc build time In-Reply-To: References: <20080417084010.k3clt47rk8go4www@mail.elegosoft.com> <20080417142525.crce5s5s1wggk04c@mail.elegosoft.com> Message-ID: <09ABDD15-A087-4CD7-B2E1-C368A35E92A4@cs.purdue.edu> Some suggested flags for gcc configure to avoid full bootstrap: --enable-languages=m3cg --disable-multilib --enable-stage1-languages=m3cg --disable-bootstrap I haven't tried any of these, but some combination in m3cc/src/ m3makefile should have the intended effect. On Apr 17, 2008, at 9:00 AM, Jay wrote: > I don't think so. I don't think so. I don't think so. :) > I don't think we bootstrapped. I don't think there's much reason. I > don't think it should even be an option. > But I don't know. > It should be faster. > > I think a reason to bootstrap would be if the system's C compiler > can't compile gcc. > That is, if it isn't gcc, or is an old gcc. Or maybe even that is > false -- not sure what the requirements to build gcc are. > Given that usually it is gcc and recent, seems like little reason. > Maybe "SOLsun" would do it, for example. > ?????? > > I'm still having trouble just making an x86 hosted x86 targeted > build on AMD64, but I'm close. > Something like > CC="gcc -m32 -Xassembler --32" configure --target=i686-pc-linux-gnu > --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu > though I'm sure that's overkill to specify three architectures. I > have to read the explanation of which is which. > When there are only two, host and target make sense, is "build" the > current one that is building the compiler, host is where it will > run, target is what it will produce? I guess that's reasonable. So > build could always be sniffed automatically and it might as well be > native -- this compiler already must exist, or it is stage1 if > bootstrapping from other than gcc. ? I guess stage1 is build a build- > hosted host-targeted compiler, stage2 is host-hosted, target- > targeted, what you actually want, stage3 is the same, and compare? > Something like that? I should read up.. this doesn't seem like > enough passes when building a cross-compiler, or just you have skip > the "compare" when building a cross compiler? > > Later.. > - Jay > > > Date: Thu, 17 Apr 2008 14:25:25 +0200 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] new gcc build time > > > > Quoting Jay : > > > > > I see this too. > > > I've been experimenting.. > > > --disable-bootstrap? > > > I don't know yet. > > > > I don't think we have ever done a full gcc bootstrap for cm3cg, > > have we? Is there any reason to do that now? > > If not, complete bootstrapping of gcc should be disabled again. > > Or we should make it an option depending on a variable setting > > like -DCOMPLETE_GCC_BOOTSTRAP or similar. > > > > Any other opinions? > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Apr 17 19:03:41 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 17 Apr 2008 13:03:41 -0400 Subject: [M3devel] biarch, multilib, etc? In-Reply-To: References: Message-ID: <527623C3-BC62-4CF0-B338-068D149378C2@cs.purdue.edu> Check the latest version of m3-sys/cminstall/src/config/LINUXLIBC6. Notice that it now always uses -m32, --32 flags to the various compiler components (cm3cg, SYSTEM_CC, SYSTEM_AS). This forces use of the x86 variants. An AMD64_LINUX port will have an almost identical configuration file that forces use of the x86_64 toolchain. 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 Apr 17, 2008, at 8:03 AM, Jay wrote: > > Can anyone explain how Linux and gcc are managing that AMD64 systems > can run > and presumably build x86 code? > > > I know there is /lib32 and /lib64. > I know there is gcc -m32 and gcc -m64. > I know that gcc itself delegates out to target specific executables, > so one gcc plus flags suffices, > it's those other executables that multiply out. That ld has the -m > flag. That as has --32 and --64. > I don't know how much stuff goes through gcc, vs. needs the get the > as/ld flags correct. > I'm not talking about Modula-3 here, but, like of building gcc and > its dependencies. > I can deal with the smaller Modula-3 system contained in far more > readable Quake code than all the "sh" > and layers upon layers of makefiles and autoconf and sh and m4 etc.. > > > ./configure on various things tend to build just AMD64. > > > It appears in general that for any > apt-get install foo > you can often but not always > apt-get install foo-i386 > > > This is on KUbuntu 8.4 Hardy Heron KDE4 beta AMD64 (mouthful!) > > > It looks like in general: > CC="gcc -m32" .../configure --prefix=/usr --libdir=/usr/lib32 -- > build=i686-pc-linux-gnu > > > is what you want, but that many packages are only native. > in particular gmp and mpfr: > apt-get install mpfr-i386 > => no luck > > > Maybe these are not considered "mainstream"? > > > I'll build them myself, something like: > > cd /usr/src > apt-get source mpfr > mkdir -p obj/mpfr > cd obj/mpfr > CC="gcc -m32" /usr/src/mpfr-2.3.1.dfsg.1/configure --prefix=/usr -- > libdir=/usr/lib32 --build=i686-pc-linux-gnu > make > sudo make install > > > cd /usr/src > apt-get source libgmp3-dev > mkdir -p /usr/src/obj/gmp > cd /usr/src/obj/obj > CC="gcc -m32" /usr/src/gmp-4.2.2+dfsg/configure --prefix=/usr -- > libdir=/usr/lib32 --build=i686-pc-linux-gnu > make > sudo make install > > You know, I just want building the Modula-3 system on AMD64_LINUX to > at first merely build > an x86 hosted, x86 targeted binary. And then start changing things. > > > And between host, target, and build, I find the names confusing. > I understand why there are three -- the current system to build the > compiler, a system to run the > compiler, a system to run the compiler's output, but these names > host, target, build, aren't very > mnemonic with me yet. Is it build=now, host=runs the compier, > target=runs the compiler's output? > I'll dig around. > > I know, I can figure it all out, there's the www to search, but this > biarch/multilib is hard > to find the docs for..and I can't read the masses of m4/sh/gmake.. > > ps: it's easy to get the ld to crash when doing this stuff wrong.. > > (I can explain how Windows does it, fyi. > 1) The system is "doubled up", generally .dlls and .exes, but not > kernel and drivers > c:\windows\system32 is native > c:\windows\syswow64 is 32bit > Yeah it's wierd/backwards, but it is source compatible. > There is runtime magic to redirect from "system32" in 32 bit > processes to syswow64. > Though if folks used the very long standing APIs, this wouldn't have > been needed. Oh well. > There is also c:\program files and c:\program files (x86). I guess > people are better about using the APIs here. > "Introspection" is "broken" but this -- link -dump against c:\windows > \system32 can get "redirected" but devtools aren't the priority and > it does all generally work out, despite the hokiness. > The registry is similarly doubled up and redirected, in some places > at least, since it tends to give paths to .dlls -- a process is > either 32bit or 64bit -- can't load one type .dll in other type > process. > > On the devtools side, well, you know, NT always had ppc/mips/alpha/ > x86, so .libs are generally already in a directory named "i386" or > "x86". > In any case, folks don't hardcode paths as much, because they are > already so variable. > So you set up your environment or such using the %LIB% variable and > it works easily. > > For running devtools, there is a separate set of .exes for each > target. > And sometimes for host. > The matrix is filled out as necessary. > AMD64 runs x86 fast so not always useful to fill out the matrix. > Sometimes a slash is used, sometimes an underscore, sometimes > "win64" inserted, but again, it's generally reasonable hidden behind > a .bat file to set the environment and set $PATH and set the > console's title (console == xterm, not the one special console). > > If you have more than one cl.exe or link.exe on your path, not good. > cl.exe does more work than the gcc driver, it doesn't delegate out > as much. > > There are no "fat" files like Apple does, well, not mechanized/ > systematic. > Something like sysinternals handle.exe that has an embedded driver > has a toplevel x86 file that runs on everything and then on demand > extracts the AMD64 or IA64 executable and driver, runs the other > version of itself, installs the driver on demand and voila.. > ) > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Apr 18 03:13:17 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Apr 2008 01:13:17 +0000 Subject: [M3devel] biarch, multilib, etc? In-Reply-To: <527623C3-BC62-4CF0-B338-068D149378C2@cs.purdue.edu> References: <527623C3-BC62-4CF0-B338-068D149378C2@cs.purdue.edu> Message-ID: What I want to start is an x86 hosted x86 targeted cm3cg to (build and) run on my AMD64 system, just to get where we already are. I have this: jay at jayx2:~/dev2/cm3/m3-sys/m3cc$ ldd LINUXLIBC6.1/cm3cg linux-vdso.so.1 => (0x00007fffe21fe000) libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00007f3fd9c8a000) libc.so.6 => /lib/libc.so.6 (0x00007f3fd9928000) /lib64/ld-linux-x86-64.so.2 (0x00007f3fd9ec9000) which I think got via straightforward methods and which I think is not what I want -- it won't run on other people's x86 system. Once I get that working, x86 hosted AMD64 target would be good, or AMD64 hosted, AMD64 targeted if I must. That is, tools can "just" be x86 hosted and work ok, enabling fewer tools that run one more hosts to target more targets. You know, I just want gcc to pretend to ignore all the AMD64 stuff, at least to start. There are a variety of promising methods but stuff keeps failing somewhere or another. stuff like CC="gcc -m32" etc. e.g.: collect2: ld terminated with signal 11 [Segmentation fault], core dumped /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a(hashtab.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a(xmalloc.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a(xstrdup.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a(xexit.o)' is incompatible with i386 output - Jay ________________________________ CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jayk123 at hotmail.com Subject: Re: [M3devel] biarch, multilib, etc? Date: Thu, 17 Apr 2008 13:03:41 -0400 Check the latest version of m3-sys/cminstall/src/config/LINUXLIBC6. Notice that it now always uses -m32, --32 flags to the various compiler components (cm3cg, SYSTEM_CC, SYSTEM_AS). This forces use of the x86 variants. An AMD64_LINUX port will have an almost identical configuration file that forces use of the x86_64 toolchain. 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 Apr 17, 2008, at 8:03 AM, Jay wrote: Can anyone explain how Linux and gcc are managing that AMD64 systems can run and presumably build x86 code? I know there is /lib32 and /lib64. I know there is gcc -m32 and gcc -m64. I know that gcc itself delegates out to target specific executables, so one gcc plus flags suffices, it's those other executables that multiply out. That ld has the -m flag. That as has --32 and --64. I don't know how much stuff goes through gcc, vs. needs the get the as/ld flags correct. I'm not talking about Modula-3 here, but, like of building gcc and its dependencies. I can deal with the smaller Modula-3 system contained in far more readable Quake code than all the "sh" and layers upon layers of makefiles and autoconf and sh and m4 etc.. ./configure on various things tend to build just AMD64. It appears in general that for any apt-get install foo you can often but not always apt-get install foo-i386 This is on KUbuntu 8.4 Hardy Heron KDE4 beta AMD64 (mouthful!) It looks like in general: CC="gcc -m32" .../configure --prefix=/usr --libdir=/usr/lib32 --build=i686-pc-linux-gnu is what you want, but that many packages are only native. in particular gmp and mpfr: apt-get install mpfr-i386 => no luck Maybe these are not considered "mainstream"? I'll build them myself, something like: cd /usr/src apt-get source mpfr mkdir -p obj/mpfr cd obj/mpfr CC="gcc -m32" /usr/src/mpfr-2.3.1.dfsg.1/configure --prefix=/usr --libdir=/usr/lib32 --build=i686-pc-linux-gnu make sudo make install cd /usr/src apt-get source libgmp3-dev mkdir -p /usr/src/obj/gmp cd /usr/src/obj/obj CC="gcc -m32" /usr/src/gmp-4.2.2+dfsg/configure --prefix=/usr --libdir=/usr/lib32 --build=i686-pc-linux-gnu make sudo make install You know, I just want building the Modula-3 system on AMD64_LINUX to at first merely build an x86 hosted, x86 targeted binary. And then start changing things. And between host, target, and build, I find the names confusing. I understand why there are three -- the current system to build the compiler, a system to run the compiler, a system to run the compiler's output, but these names host, target, build, aren't very mnemonic with me yet. Is it build=now, host=runs the compier, target=runs the compiler's output? I'll dig around. I know, I can figure it all out, there's the www to search, but this biarch/multilib is hard to find the docs for..and I can't read the masses of m4/sh/gmake.. ps: it's easy to get the ld to crash when doing this stuff wrong.. (I can explain how Windows does it, fyi. 1) The system is "doubled up", generally .dlls and .exes, but not kernel and drivers c:\windows\system32 is native c:\windows\syswow64 is 32bit Yeah it's wierd/backwards, but it is source compatible. There is runtime magic to redirect from "system32" in 32 bit processes to syswow64. Though if folks used the very long standing APIs, this wouldn't have been needed. Oh well. There is also c:\program files and c:\program files (x86). I guess people are better about using the APIs here. "Introspection" is "broken" but this -- link -dump against c:\windows\system32 can get "redirected" but devtools aren't the priority and it does all generally work out, despite the hokiness. The registry is similarly doubled up and redirected, in some places at least, since it tends to give paths to .dlls -- a process is either 32bit or 64bit -- can't load one type .dll in other type process. On the devtools side, well, you know, NT always had ppc/mips/alpha/x86, so .libs are generally already in a directory named "i386" or "x86". In any case, folks don't hardcode paths as much, because they are already so variable. So you set up your environment or such using the %LIB% variable and it works easily. For running devtools, there is a separate set of .exes for each target. And sometimes for host. The matrix is filled out as necessary. AMD64 runs x86 fast so not always useful to fill out the matrix. Sometimes a slash is used, sometimes an underscore, sometimes "win64" inserted, but again, it's generally reasonable hidden behind a .bat file to set the environment and set $PATH and set the console's title (console == xterm, not the one special console). If you have more than one cl.exe or link.exe on your path, not good. cl.exe does more work than the gcc driver, it doesn't delegate out as much. There are no "fat" files like Apple does, well, not mechanized/systematic. Something like sysinternals handle.exe that has an embedded driver has a toplevel x86 file that runs on everything and then on demand extracts the AMD64 or IA64 executable and driver, runs the other version of itself, installs the driver on demand and voila.. ) - Jay From hosking at cs.purdue.edu Fri Apr 18 04:02:16 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 17 Apr 2008 22:02:16 -0400 Subject: [M3devel] biarch, multilib, etc? In-Reply-To: References: <527623C3-BC62-4CF0-B338-068D149378C2@cs.purdue.edu> Message-ID: Have you tried the following: cd cm3/m3-sys/m3cc mkdir build cd build ../gcc/configure --enable-languages=m3cg make This works for me on Mac OS X and builds a bi-arch version of m3cg that will accept both -m32 and -m64 flags to target x86_32 and x86_64. Admittedly, it does go through the full bootstrap, which is probably overkill. I haven't had a chance to try AMD64_LINUX yet, but I assume it will behave much the same in building a bi-arch compiler. On Apr 17, 2008, at 9:13 PM, Jay wrote: > > What I want to start is an x86 hosted x86 targeted cm3cg to (build > and) run on my AMD64 system, just to get where we already are. > > I have this: > > jay at jayx2:~/dev2/cm3/m3-sys/m3cc$ ldd LINUXLIBC6.1/cm3cg > linux-vdso.so.1 => (0x00007fffe21fe000) > libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00007f3fd9c8a000) > libc.so.6 => /lib/libc.so.6 (0x00007f3fd9928000) > /lib64/ld-linux-x86-64.so.2 (0x00007f3fd9ec9000) > > > which I think got via straightforward methods and which I think is > not what I want -- it won't run on other people's x86 system. > > Once I get that working, x86 hosted AMD64 target would be good, or > AMD64 hosted, AMD64 targeted if I must. > That is, tools can "just" be x86 hosted and work ok, enabling fewer > tools that run one more hosts to target more targets. > > You know, I just want gcc to pretend to ignore all the AMD64 stuff, > at least to start. > There are a variety of promising methods but stuff keeps failing > somewhere or another. > stuff like CC="gcc -m32" etc. > > e.g.: > collect2: ld terminated with signal 11 [Segmentation fault], core > dumped > /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- > unknown-linux-gnu/libiberty/libiberty.a(hashtab.o)' is incompatible > with i386 output > /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- > unknown-linux-gnu/libiberty/libiberty.a(xmalloc.o)' is incompatible > with i386 output > /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- > unknown-linux-gnu/libiberty/libiberty.a(xstrdup.o)' is incompatible > with i386 output > /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- > unknown-linux-gnu/libiberty/libiberty.a(xexit.o)' is incompatible > with i386 output > > - Jay > > ________________________________ > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jayk123 at hotmail.com > Subject: Re: [M3devel] biarch, multilib, etc? > Date: Thu, 17 Apr 2008 13:03:41 -0400 > > Check the latest version of m3-sys/cminstall/src/config/LINUXLIBC6. > Notice that it now always uses -m32, --32 flags to the various > compiler components (cm3cg, SYSTEM_CC, SYSTEM_AS). This forces use > of the x86 variants. An AMD64_LINUX port will have an almost > identical configuration file that forces use of the x86_64 toolchain. > > 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 Apr 17, 2008, at 8:03 AM, Jay wrote: > > Can anyone explain how Linux and gcc are managing that AMD64 systems > can run > and presumably build x86 code? > > > I know there is /lib32 and /lib64. > I know there is gcc -m32 and gcc -m64. > I know that gcc itself delegates out to target specific executables, > so one gcc plus flags suffices, > it's those other executables that multiply out. That ld has the -m > flag. That as has --32 and --64. > I don't know how much stuff goes through gcc, vs. needs the get the > as/ld flags correct. > I'm not talking about Modula-3 here, but, like of building gcc and > its dependencies. > I can deal with the smaller Modula-3 system contained in far more > readable Quake code than all the "sh" > and layers upon layers of makefiles and autoconf and sh and m4 etc.. > > > ./configure on various things tend to build just AMD64. > > > It appears in general that for any > apt-get install foo > you can often but not always > apt-get install foo-i386 > > > This is on KUbuntu 8.4 Hardy Heron KDE4 beta AMD64 (mouthful!) > > > It looks like in general: > CC="gcc -m32" .../configure --prefix=/usr --libdir=/usr/lib32 -- > build=i686-pc-linux-gnu > > > is what you want, but that many packages are only native. > in particular gmp and mpfr: > apt-get install mpfr-i386 > => no luck > > > Maybe these are not considered "mainstream"? > > > I'll build them myself, something like: > > cd /usr/src > apt-get source mpfr > mkdir -p obj/mpfr > cd obj/mpfr > CC="gcc -m32" /usr/src/mpfr-2.3.1.dfsg.1/configure --prefix=/usr -- > libdir=/usr/lib32 --build=i686-pc-linux-gnu > make > sudo make install > > > cd /usr/src > apt-get source libgmp3-dev > mkdir -p /usr/src/obj/gmp > cd /usr/src/obj/obj > CC="gcc -m32" /usr/src/gmp-4.2.2+dfsg/configure --prefix=/usr -- > libdir=/usr/lib32 --build=i686-pc-linux-gnu > make > sudo make install > > You know, I just want building the Modula-3 system on AMD64_LINUX to > at first merely build > an x86 hosted, x86 targeted binary. And then start changing things. > > > And between host, target, and build, I find the names confusing. > I understand why there are three -- the current system to build the > compiler, a system to run the > compiler, a system to run the compiler's output, but these names > host, target, build, aren't very > mnemonic with me yet. Is it build=now, host=runs the compier, > target=runs the compiler's output? > I'll dig around. > > I know, I can figure it all out, there's the www to search, but this > biarch/multilib is hard > to find the docs for..and I can't read the masses of m4/sh/gmake.. > > ps: it's easy to get the ld to crash when doing this stuff wrong.. > > (I can explain how Windows does it, fyi. > 1) The system is "doubled up", generally .dlls and .exes, but not > kernel and drivers > c:\windows\system32 is native > c:\windows\syswow64 is 32bit > Yeah it's wierd/backwards, but it is source compatible. > There is runtime magic to redirect from "system32" in 32 bit > processes to syswow64. > Though if folks used the very long standing APIs, this wouldn't have > been needed. Oh well. > There is also c:\program files and c:\program files (x86). I guess > people are better about using the APIs here. > "Introspection" is "broken" but this -- link -dump against c:\windows > \system32 can get "redirected" but devtools aren't the priority and > it does all generally work out, despite the hokiness. > The registry is similarly doubled up and redirected, in some places > at least, since it tends to give paths to .dlls -- a process is > either 32bit or 64bit -- can't load one type .dll in other type > process. > > On the devtools side, well, you know, NT always had ppc/mips/alpha/ > x86, so .libs are generally already in a directory named "i386" or > "x86". > In any case, folks don't hardcode paths as much, because they are > already so variable. > So you set up your environment or such using the %LIB% variable and > it works easily. > > For running devtools, there is a separate set of .exes for each > target. > And sometimes for host. > The matrix is filled out as necessary. > AMD64 runs x86 fast so not always useful to fill out the matrix. > Sometimes a slash is used, sometimes an underscore, sometimes > "win64" inserted, but again, it's generally reasonable hidden behind > a .bat file to set the environment and set $PATH and set the > console's title (console == xterm, not the one special console). > > If you have more than one cl.exe or link.exe on your path, not good. > cl.exe does more work than the gcc driver, it doesn't delegate out > as much. > > There are no "fat" files like Apple does, well, not mechanized/ > systematic. > Something like sysinternals handle.exe that has an embedded driver > has a toplevel x86 file that runs on everything and then on demand > extracts the AMD64 or IA64 executable and driver, runs the other > version of itself, installs the driver on demand and voila.. > ) > > - Jay > From jayk123 at hotmail.com Fri Apr 18 06:00:27 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Apr 2008 04:00:27 +0000 Subject: [M3devel] biarch, multilib, etc? In-Reply-To: References: <527623C3-BC62-4CF0-B338-068D149378C2@cs.purdue.edu> Message-ID: Kinda sorta but not quite. I am now trying without --disable-bootstrap and --disable-multilib for non-native builds. I'll see how that goes. I understand the niceness of a multarch toolset. I also would like an option for that toolset to be x86 hosted instead of AMD64 hosted, but I'll take either at this point. It still likes to look for i686-pc-linux-gnu-ar and ld and such, rather than just using the existing biarch tools. Epiphany: There are the following platforms: build -- what is building the compiler host -- what the compiler will run on target -- what the compiler's output will run on However each one is potentially biarch or multiarch. (multiarch -- Mac OS X AMD64 machines can run 32 bit PowerPC, 32 bit x86, and AMD64 -- triarch). I understand in the general simple case, gcc -m32 is all it takes, but I don't trust that to suffice for building gcc, since there is at least one more architecture involved and there are a bunch of suspiciously relevant sounding configurable knobs, not just CC and CFLAGS, but AS_FOR_TARGET, GCC_FOR_TARGET, etc., but there aren't FOO_FOR_BUILD, FOO_FOR_HOST, FOO_FOR_TARGET; I guess plain FOO is FOO_FOR_BUILD. I'll keep poking.. - Jay > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jayk123 at hotmail.com > Subject: Re: [M3devel] biarch, multilib, etc? > Date: Thu, 17 Apr 2008 22:02:16 -0400 > > Have you tried the following: > > cd cm3/m3-sys/m3cc > mkdir build > cd build > ../gcc/configure --enable-languages=m3cg > make > > This works for me on Mac OS X and builds a bi-arch version of m3cg > that will accept both -m32 and -m64 flags to target x86_32 and x86_64. > > Admittedly, it does go through the full bootstrap, which is probably > overkill. > > I haven't had a chance to try AMD64_LINUX yet, but I assume it will > behave much the same in building a bi-arch compiler. > > On Apr 17, 2008, at 9:13 PM, Jay wrote: > > > > > What I want to start is an x86 hosted x86 targeted cm3cg to (build > > and) run on my AMD64 system, just to get where we already are. > > > > I have this: > > > > jay at jayx2:~/dev2/cm3/m3-sys/m3cc$ ldd LINUXLIBC6.1/cm3cg > > linux-vdso.so.1 => (0x00007fffe21fe000) > > libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00007f3fd9c8a000) > > libc.so.6 => /lib/libc.so.6 (0x00007f3fd9928000) > > /lib64/ld-linux-x86-64.so.2 (0x00007f3fd9ec9000) > > > > > > which I think got via straightforward methods and which I think is > > not what I want -- it won't run on other people's x86 system. > > > > Once I get that working, x86 hosted AMD64 target would be good, or > > AMD64 hosted, AMD64 targeted if I must. > > That is, tools can "just" be x86 hosted and work ok, enabling fewer > > tools that run one more hosts to target more targets. > > > > You know, I just want gcc to pretend to ignore all the AMD64 stuff, > > at least to start. > > There are a variety of promising methods but stuff keeps failing > > somewhere or another. > > stuff like CC="gcc -m32" etc. > > > > e.g.: > > collect2: ld terminated with signal 11 [Segmentation fault], core > > dumped > > /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- > > unknown-linux-gnu/libiberty/libiberty.a(hashtab.o)' is incompatible > > with i386 output > > /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- > > unknown-linux-gnu/libiberty/libiberty.a(xmalloc.o)' is incompatible > > with i386 output > > /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- > > unknown-linux-gnu/libiberty/libiberty.a(xstrdup.o)' is incompatible > > with i386 output > > /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- > > unknown-linux-gnu/libiberty/libiberty.a(xexit.o)' is incompatible > > with i386 output > > > > - Jay > > > > ________________________________ > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > To: jayk123 at hotmail.com > > Subject: Re: [M3devel] biarch, multilib, etc? > > Date: Thu, 17 Apr 2008 13:03:41 -0400 > > > > Check the latest version of m3-sys/cminstall/src/config/LINUXLIBC6. > > Notice that it now always uses -m32, --32 flags to the various > > compiler components (cm3cg, SYSTEM_CC, SYSTEM_AS). This forces use > > of the x86 variants. An AMD64_LINUX port will have an almost > > identical configuration file that forces use of the x86_64 toolchain. > > > > 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 Apr 17, 2008, at 8:03 AM, Jay wrote: > > > > Can anyone explain how Linux and gcc are managing that AMD64 systems > > can run > > and presumably build x86 code? > > > > > > I know there is /lib32 and /lib64. > > I know there is gcc -m32 and gcc -m64. > > I know that gcc itself delegates out to target specific executables, > > so one gcc plus flags suffices, > > it's those other executables that multiply out. That ld has the -m > > flag. That as has --32 and --64. > > I don't know how much stuff goes through gcc, vs. needs the get the > > as/ld flags correct. > > I'm not talking about Modula-3 here, but, like of building gcc and > > its dependencies. > > I can deal with the smaller Modula-3 system contained in far more > > readable Quake code than all the "sh" > > and layers upon layers of makefiles and autoconf and sh and m4 etc.. > > > > > > ./configure on various things tend to build just AMD64. > > > > > > It appears in general that for any > > apt-get install foo > > you can often but not always > > apt-get install foo-i386 > > > > > > This is on KUbuntu 8.4 Hardy Heron KDE4 beta AMD64 (mouthful!) > > > > > > It looks like in general: > > CC="gcc -m32" .../configure --prefix=/usr --libdir=/usr/lib32 -- > > build=i686-pc-linux-gnu > > > > > > is what you want, but that many packages are only native. > > in particular gmp and mpfr: > > apt-get install mpfr-i386 > > => no luck > > > > > > Maybe these are not considered "mainstream"? > > > > > > I'll build them myself, something like: > > > > cd /usr/src > > apt-get source mpfr > > mkdir -p obj/mpfr > > cd obj/mpfr > > CC="gcc -m32" /usr/src/mpfr-2.3.1.dfsg.1/configure --prefix=/usr -- > > libdir=/usr/lib32 --build=i686-pc-linux-gnu > > make > > sudo make install > > > > > > cd /usr/src > > apt-get source libgmp3-dev > > mkdir -p /usr/src/obj/gmp > > cd /usr/src/obj/obj > > CC="gcc -m32" /usr/src/gmp-4.2.2+dfsg/configure --prefix=/usr -- > > libdir=/usr/lib32 --build=i686-pc-linux-gnu > > make > > sudo make install > > > > You know, I just want building the Modula-3 system on AMD64_LINUX to > > at first merely build > > an x86 hosted, x86 targeted binary. And then start changing things. > > > > > > And between host, target, and build, I find the names confusing. > > I understand why there are three -- the current system to build the > > compiler, a system to run the > > compiler, a system to run the compiler's output, but these names > > host, target, build, aren't very > > mnemonic with me yet. Is it build=now, host=runs the compier, > > target=runs the compiler's output? > > I'll dig around. > > > > I know, I can figure it all out, there's the www to search, but this > > biarch/multilib is hard > > to find the docs for..and I can't read the masses of m4/sh/gmake.. > > > > ps: it's easy to get the ld to crash when doing this stuff wrong.. > > > > (I can explain how Windows does it, fyi. > > 1) The system is "doubled up", generally .dlls and .exes, but not > > kernel and drivers > > c:\windows\system32 is native > > c:\windows\syswow64 is 32bit > > Yeah it's wierd/backwards, but it is source compatible. > > There is runtime magic to redirect from "system32" in 32 bit > > processes to syswow64. > > Though if folks used the very long standing APIs, this wouldn't have > > been needed. Oh well. > > There is also c:\program files and c:\program files (x86). I guess > > people are better about using the APIs here. > > "Introspection" is "broken" but this -- link -dump against c:\windows > > \system32 can get "redirected" but devtools aren't the priority and > > it does all generally work out, despite the hokiness. > > The registry is similarly doubled up and redirected, in some places > > at least, since it tends to give paths to .dlls -- a process is > > either 32bit or 64bit -- can't load one type .dll in other type > > process. > > > > On the devtools side, well, you know, NT always had ppc/mips/alpha/ > > x86, so .libs are generally already in a directory named "i386" or > > "x86". > > In any case, folks don't hardcode paths as much, because they are > > already so variable. > > So you set up your environment or such using the %LIB% variable and > > it works easily. > > > > For running devtools, there is a separate set of .exes for each > > target. > > And sometimes for host. > > The matrix is filled out as necessary. > > AMD64 runs x86 fast so not always useful to fill out the matrix. > > Sometimes a slash is used, sometimes an underscore, sometimes > > "win64" inserted, but again, it's generally reasonable hidden behind > > a .bat file to set the environment and set $PATH and set the > > console's title (console == xterm, not the one special console). > > > > If you have more than one cl.exe or link.exe on your path, not good. > > cl.exe does more work than the gcc driver, it doesn't delegate out > > as much. > > > > There are no "fat" files like Apple does, well, not mechanized/ > > systematic. > > Something like sysinternals handle.exe that has an embedded driver > > has a toplevel x86 file that runs on everything and then on demand > > extracts the AMD64 or IA64 executable and driver, runs the other > > version of itself, installs the driver on demand and voila.. > > ) > > > > - Jay > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Apr 18 06:44:57 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 18 Apr 2008 00:44:57 -0400 Subject: [M3devel] biarch, multilib, etc? In-Reply-To: References: <527623C3-BC62-4CF0-B338-068D149378C2@cs.purdue.edu> Message-ID: 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 Apr 18, 2008, at 12:00 AM, Jay wrote: > Kinda sorta but not quite. > I am now trying without --disable-bootstrap and --disable-multilib > for non-native builds. I'll see how that goes. > I understand the niceness of a multarch toolset. > > I also would like an option for that toolset to be x86 hosted > instead of AMD64 hosted, but I'll take either at this point. > It still likes to look for i686-pc-linux-gnu-ar and ld and such, > rather than just using the existing biarch tools. Who? When building gcc? My build of cm3cg on OS X appears to be x86 hosted. cm3cg does not need to look for any tools... > Epiphany: > There are the following platforms: > build -- what is building the compiler > host -- what the compiler will run on > target -- what the compiler's output will run on > > However each one is potentially biarch or multiarch. > (multiarch -- Mac OS X AMD64 machines can run 32 bit PowerPC, 32 bit > x86, and AMD64 -- triarch). I build gcc without any special setup other than described above. I host on whatever that build turns out to be. I target using -m32/-m64. > I understand in the general simple case, gcc -m32 is all it takes, > but I don't trust that to suffice for building gcc, since there is > at least one more architecture involved and there are a bunch of > suspiciously relevant sounding configurable knobs, not just CC and > CFLAGS, but AS_FOR_TARGET, GCC_FOR_TARGET, etc., but there aren't > FOO_FOR_BUILD, FOO_FOR_HOST, FOO_FOR_TARGET; I guess plain FOO is > FOO_FOR_BUILD. I don't specify -m32 or -m64 to build gcc itself. It automatically builds a biarch compiler. > I'll keep poking.. > > - Jay > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > To: jayk123 at hotmail.com > > Subject: Re: [M3devel] biarch, multilib, etc? > > Date: Thu, 17 Apr 2008 22:02:16 -0400 > > > > Have you tried the following: > > > > cd cm3/m3-sys/m3cc > > mkdir build > > cd build > > ../gcc/configure --enable-languages=m3cg > > make > > > > This works for me on Mac OS X and builds a bi-arch version of m3cg > > that will accept both -m32 and -m64 flags to target x86_32 and > x86_64. > > > > Admittedly, it does go through the full bootstrap, which is probably > > overkill. > > > > I haven't had a chance to try AMD64_LINUX yet, but I assume it will > > behave much the same in building a bi-arch compiler. > > > > On Apr 17, 2008, at 9:13 PM, Jay wrote: > > > > > > > > What I want to start is an x86 hosted x86 targeted cm3cg to (build > > > and) run on my AMD64 system, just to get where we already are. > > > > > > I have this: > > > > > > jay at jayx2:~/dev2/cm3/m3-sys/m3cc$ ldd LINUXLIBC6.1/cm3cg > > > linux-vdso.so.1 => (0x00007fffe21fe000) > > > libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00007f3fd9c8a000) > > > libc.so.6 => /lib/libc.so.6 (0x00007f3fd9928000) > > > /lib64/ld-linux-x86-64.so.2 (0x00007f3fd9ec9000) > > > > > > > > > which I think got via straightforward methods and which I think is > > > not what I want -- it won't run on other people's x86 system. > > > > > > Once I get that working, x86 hosted AMD64 target would be good, or > > > AMD64 hosted, AMD64 targeted if I must. > > > That is, tools can "just" be x86 hosted and work ok, enabling > fewer > > > tools that run one more hosts to target more targets. > > > > > > You know, I just want gcc to pretend to ignore all the AMD64 > stuff, > > > at least to start. > > > There are a variety of promising methods but stuff keeps failing > > > somewhere or another. > > > stuff like CC="gcc -m32" etc. > > > > > > e.g.: > > > collect2: ld terminated with signal 11 [Segmentation fault], core > > > dumped > > > /usr/bin/ld: i386:x86-64 architecture of input file `../build- > x86_64- > > > unknown-linux-gnu/libiberty/libiberty.a(hashtab.o)' is > incompatible > > > with i386 output > > > /usr/bin/ld: i386:x86-64 architecture of input file `../build- > x86_64- > > > unknown-linux-gnu/libiberty/libiberty.a(xmalloc.o)' is > incompatible > > > with i386 output > > > /usr/bin/ld: i386:x86-64 architecture of input file `../build- > x86_64- > > > unknown-linux-gnu/libiberty/libiberty.a(xstrdup.o)' is > incompatible > > > with i386 output > > > /usr/bin/ld: i386:x86-64 architecture of input file `../build- > x86_64- > > > unknown-linux-gnu/libiberty/libiberty.a(xexit.o)' is incompatible > > > with i386 output > > > > > > - Jay > > > > > > ________________________________ > > > CC: m3devel at elegosoft.com > > > From: hosking at cs.purdue.edu > > > To: jayk123 at hotmail.com > > > Subject: Re: [M3devel] biarch, multilib, etc? > > > Date: Thu, 17 Apr 2008 13:03:41 -0400 > > > > > > Check the latest version of m3-sys/cminstall/src/config/ > LINUXLIBC6. > > > Notice that it now always uses -m32, --32 flags to the various > > > compiler components (cm3cg, SYSTEM_CC, SYSTEM_AS). This forces use > > > of the x86 variants. An AMD64_LINUX port will have an almost > > > identical configuration file that forces use of the x86_64 > toolchain. > > > > > > 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 Apr 17, 2008, at 8:03 AM, Jay wrote: > > > > > > Can anyone explain how Linux and gcc are managing that AMD64 > systems > > > can run > > > and presumably build x86 code? > > > > > > > > > I know there is /lib32 and /lib64. > > > I know there is gcc -m32 and gcc -m64. > > > I know that gcc itself delegates out to target specific > executables, > > > so one gcc plus flags suffices, > > > it's those other executables that multiply out. That ld has the -m > > > flag. That as has --32 and --64. > > > I don't know how much stuff goes through gcc, vs. needs the get > the > > > as/ld flags correct. > > > I'm not talking about Modula-3 here, but, like of building gcc and > > > its dependencies. > > > I can deal with the smaller Modula-3 system contained in far more > > > readable Quake code than all the "sh" > > > and layers upon layers of makefiles and autoconf and sh and m4 > etc.. > > > > > > > > > ./configure on various things tend to build just AMD64. > > > > > > > > > It appears in general that for any > > > apt-get install foo > > > you can often but not always > > > apt-get install foo-i386 > > > > > > > > > This is on KUbuntu 8.4 Hardy Heron KDE4 beta AMD64 (mouthful!) > > > > > > > > > It looks like in general: > > > CC="gcc -m32" .../configure --prefix=/usr --libdir=/usr/lib32 -- > > > build=i686-pc-linux-gnu > > > > > > > > > is what you want, but that many packages are only native. > > > in particular gmp and mpfr: > > > apt-get install mpfr-i386 > > > => no luck > > > > > > > > > Maybe these are not considered "mainstream"? > > > > > > > > > I'll build them myself, something like: > > > > > > cd /usr/src > > > apt-get source mpfr > > > mkdir -p obj/mpfr > > > cd obj/mpfr > > > CC="gcc -m32" /usr/src/mpfr-2.3.1.dfsg.1/configure --prefix=/usr > -- > > > libdir=/usr/lib32 --build=i686-pc-linux-gnu > > > make > > > sudo make install > > > > > > > > > cd /usr/src > > > apt-get source libgmp3-dev > > > mkdir -p /usr/src/obj/gmp > > > cd /usr/src/obj/obj > > > CC="gcc -m32" /usr/src/gmp-4.2.2+dfsg/configure --prefix=/usr -- > > > libdir=/usr/lib32 --build=i686-pc-linux-gnu > > > make > > > sudo make install > > > > > > You know, I just want building the Modula-3 system on > AMD64_LINUX to > > > at first merely build > > > an x86 hosted, x86 targeted binary. And then start changing > things. > > > > > > > > > And between host, target, and build, I find the names confusing. > > > I understand why there are three -- the current system to build > the > > > compiler, a system to run the > > > compiler, a system to run the compiler's output, but these names > > > host, target, build, aren't very > > > mnemonic with me yet. Is it build=now, host=runs the compier, > > > target=runs the compiler's output? > > > I'll dig around. > > > > > > I know, I can figure it all out, there's the www to search, but > this > > > biarch/multilib is hard > > > to find the docs for..and I can't read the masses of m4/sh/gmake.. > > > > > > ps: it's easy to get the ld to crash when doing this stuff wrong.. > > > > > > (I can explain how Windows does it, fyi. > > > 1) The system is "doubled up", generally .dlls and .exes, but not > > > kernel and drivers > > > c:\windows\system32 is native > > > c:\windows\syswow64 is 32bit > > > Yeah it's wierd/backwards, but it is source compatible. > > > There is runtime magic to redirect from "system32" in 32 bit > > > processes to syswow64. > > > Though if folks used the very long standing APIs, this wouldn't > have > > > been needed. Oh well. > > > There is also c:\program files and c:\program files (x86). I guess > > > people are better about using the APIs here. > > > "Introspection" is "broken" but this -- link -dump against c: > \windows > > > \system32 can get "redirected" but devtools aren't the priority > and > > > it does all generally work out, despite the hokiness. > > > The registry is similarly doubled up and redirected, in some > places > > > at least, since it tends to give paths to .dlls -- a process is > > > either 32bit or 64bit -- can't load one type .dll in other type > > > process. > > > > > > On the devtools side, well, you know, NT always had ppc/mips/ > alpha/ > > > x86, so .libs are generally already in a directory named "i386" or > > > "x86". > > > In any case, folks don't hardcode paths as much, because they are > > > already so variable. > > > So you set up your environment or such using the %LIB% variable > and > > > it works easily. > > > > > > For running devtools, there is a separate set of .exes for each > > > target. > > > And sometimes for host. > > > The matrix is filled out as necessary. > > > AMD64 runs x86 fast so not always useful to fill out the matrix. > > > Sometimes a slash is used, sometimes an underscore, sometimes > > > "win64" inserted, but again, it's generally reasonable hidden > behind > > > a .bat file to set the environment and set $PATH and set the > > > console's title (console == xterm, not the one special console). > > > > > > If you have more than one cl.exe or link.exe on your path, not > good. > > > cl.exe does more work than the gcc driver, it doesn't delegate out > > > as much. > > > > > > There are no "fat" files like Apple does, well, not mechanized/ > > > systematic. > > > Something like sysinternals handle.exe that has an embedded driver > > > has a toplevel x86 file that runs on everything and then on demand > > > extracts the AMD64 or IA64 executable and driver, runs the other > > > version of itself, installs the driver on demand and voila.. > > > ) > > > > > > - Jay > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Apr 18 07:11:54 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Apr 2008 05:11:54 +0000 Subject: [M3devel] biarch, multilib, etc? In-Reply-To: References: <527623C3-BC62-4CF0-B338-068D149378C2@cs.purdue.edu> Message-ID: I agree this could work on Mac OS X and I will run it again, but I believe that is how I essentially got: jay at jayx2:~/dev2/cm3/m3-sys/m3cc/LINUXLIBC6.1$ ./cm3cg --help | grep -e " -m[0-9]" -m128bit-long-double [disabled] -m32 [disabled] -m3dnow [disabled] -m64 [enabled] -m80387 [enabled] -m96bit-long-double [enabled] jay at jayx2:~/dev2/cm3/m3-sys/m3cc/LINUXLIBC6.1$ ldd ./cm3cg linux-vdso.so.1 => (0x00007fffc7bff000) libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00007fbfbf6fd000) libc.so.6 => /lib/libc.so.6 (0x00007fbfbf39b000) /lib64/ld-linux-x86-64.so.2 (0x00007fbfbf93c000) which I believe will only run on AMD64 and only produce AMD64 code. (Which is probably why I got internal compiler errors trying to use it.) - Jay ________________________________ CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jayk123 at hotmail.com Subject: Re: [M3devel] biarch, multilib, etc? Date: Fri, 18 Apr 2008 00:44:57 -0400 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 Apr 18, 2008, at 12:00 AM, Jay wrote: Kinda sorta but not quite. I am now trying without --disable-bootstrap and --disable-multilib for non-native builds. I'll see how that goes. I understand the niceness of a multarch toolset. I also would like an option for that toolset to be x86 hosted instead of AMD64 hosted, but I'll take either at this point. It still likes to look for i686-pc-linux-gnu-ar and ld and such, rather than just using the existing biarch tools. Who? When building gcc? My build of cm3cg on OS X appears to be x86 hosted. cm3cg does not need to look for any tools... Epiphany: There are the following platforms: build -- what is building the compiler host -- what the compiler will run on target -- what the compiler's output will run on However each one is potentially biarch or multiarch. (multiarch -- Mac OS X AMD64 machines can run 32 bit PowerPC, 32 bit x86, and AMD64 -- triarch). I build gcc without any special setup other than described above. I host on whatever that build turns out to be. I target using -m32/-m64. I understand in the general simple case, gcc -m32 is all it takes, but I don't trust that to suffice for building gcc, since there is at least one more architecture involved and there are a bunch of suspiciously relevant sounding configurable knobs, not just CC and CFLAGS, but AS_FOR_TARGET, GCC_FOR_TARGET, etc., but there aren't FOO_FOR_BUILD, FOO_FOR_HOST, FOO_FOR_TARGET; I guess plain FOO is FOO_FOR_BUILD. I don't specify -m32 or -m64 to build gcc itself. It automatically builds a biarch compiler. I'll keep poking.. - Jay > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jayk123 at hotmail.com > Subject: Re: [M3devel] biarch, multilib, etc? > Date: Thu, 17 Apr 2008 22:02:16 -0400 > > Have you tried the following: > > cd cm3/m3-sys/m3cc > mkdir build > cd build > ../gcc/configure --enable-languages=m3cg > make > > This works for me on Mac OS X and builds a bi-arch version of m3cg > that will accept both -m32 and -m64 flags to target x86_32 and x86_64. > > Admittedly, it does go through the full bootstrap, which is probably > overkill. > > I haven't had a chance to try AMD64_LINUX yet, but I assume it will > behave much the same in building a bi-arch compiler. > > On Apr 17, 2008, at 9:13 PM, Jay wrote: > >> >> What I want to start is an x86 hosted x86 targeted cm3cg to (build >> and) run on my AMD64 system, just to get where we already are. >> >> I have this: >> >> jay at jayx2:~/dev2/cm3/m3-sys/m3cc$ ldd LINUXLIBC6.1/cm3cg >> linux-vdso.so.1 => (0x00007fffe21fe000) >> libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00007f3fd9c8a000) >> libc.so.6 => /lib/libc.so.6 (0x00007f3fd9928000) >> /lib64/ld-linux-x86-64.so.2 (0x00007f3fd9ec9000) >> >> >> which I think got via straightforward methods and which I think is >> not what I want -- it won't run on other people's x86 system. >> >> Once I get that working, x86 hosted AMD64 target would be good, or >> AMD64 hosted, AMD64 targeted if I must. >> That is, tools can "just" be x86 hosted and work ok, enabling fewer >> tools that run one more hosts to target more targets. >> >> You know, I just want gcc to pretend to ignore all the AMD64 stuff, >> at least to start. >> There are a variety of promising methods but stuff keeps failing >> somewhere or another. >> stuff like CC="gcc -m32" etc. >> >> e.g.: >> collect2: ld terminated with signal 11 [Segmentation fault], core >> dumped >> /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- >> unknown-linux-gnu/libiberty/libiberty.a(hashtab.o)' is incompatible >> with i386 output >> /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- >> unknown-linux-gnu/libiberty/libiberty.a(xmalloc.o)' is incompatible >> with i386 output >> /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- >> unknown-linux-gnu/libiberty/libiberty.a(xstrdup.o)' is incompatible >> with i386 output >> /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- >> unknown-linux-gnu/libiberty/libiberty.a(xexit.o)' is incompatible >> with i386 output >> >> - Jay >> >> ________________________________ >> CC: m3devel at elegosoft.com >> From: hosking at cs.purdue.edu >> To: jayk123 at hotmail.com >> Subject: Re: [M3devel] biarch, multilib, etc? >> Date: Thu, 17 Apr 2008 13:03:41 -0400 >> >> Check the latest version of m3-sys/cminstall/src/config/LINUXLIBC6. >> Notice that it now always uses -m32, --32 flags to the various >> compiler components (cm3cg, SYSTEM_CC, SYSTEM_AS). This forces use >> of the x86 variants. An AMD64_LINUX port will have an almost >> identical configuration file that forces use of the x86_64 toolchain. >> >> 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 Apr 17, 2008, at 8:03 AM, Jay wrote: >> >> Can anyone explain how Linux and gcc are managing that AMD64 systems >> can run >> and presumably build x86 code? >> >> >> I know there is /lib32 and /lib64. >> I know there is gcc -m32 and gcc -m64. >> I know that gcc itself delegates out to target specific executables, >> so one gcc plus flags suffices, >> it's those other executables that multiply out. That ld has the -m >> flag. That as has --32 and --64. >> I don't know how much stuff goes through gcc, vs. needs the get the >> as/ld flags correct. >> I'm not talking about Modula-3 here, but, like of building gcc and >> its dependencies. >> I can deal with the smaller Modula-3 system contained in far more >> readable Quake code than all the "sh" >> and layers upon layers of makefiles and autoconf and sh and m4 etc.. >> >> >> ./configure on various things tend to build just AMD64. >> >> >> It appears in general that for any >> apt-get install foo >> you can often but not always >> apt-get install foo-i386 >> >> >> This is on KUbuntu 8.4 Hardy Heron KDE4 beta AMD64 (mouthful!) >> >> >> It looks like in general: >> CC="gcc -m32" .../configure --prefix=/usr --libdir=/usr/lib32 -- >> build=i686-pc-linux-gnu >> >> >> is what you want, but that many packages are only native. >> in particular gmp and mpfr: >> apt-get install mpfr-i386 >> => no luck >> >> >> Maybe these are not considered "mainstream"? >> >> >> I'll build them myself, something like: >> >> cd /usr/src >> apt-get source mpfr >> mkdir -p obj/mpfr >> cd obj/mpfr >> CC="gcc -m32" /usr/src/mpfr-2.3.1.dfsg.1/configure --prefix=/usr -- >> libdir=/usr/lib32 --build=i686-pc-linux-gnu >> make >> sudo make install >> >> >> cd /usr/src >> apt-get source libgmp3-dev >> mkdir -p /usr/src/obj/gmp >> cd /usr/src/obj/obj >> CC="gcc -m32" /usr/src/gmp-4.2.2+dfsg/configure --prefix=/usr -- >> libdir=/usr/lib32 --build=i686-pc-linux-gnu >> make >> sudo make install >> >> You know, I just want building the Modula-3 system on AMD64_LINUX to >> at first merely build >> an x86 hosted, x86 targeted binary. And then start changing things. >> >> >> And between host, target, and build, I find the names confusing. >> I understand why there are three -- the current system to build the >> compiler, a system to run the >> compiler, a system to run the compiler's output, but these names >> host, target, build, aren't very >> mnemonic with me yet. Is it build=now, host=runs the compier, >> target=runs the compiler's output? >> I'll dig around. >> >> I know, I can figure it all out, there's the www to search, but this >> biarch/multilib is hard >> to find the docs for..and I can't read the masses of m4/sh/gmake.. >> >> ps: it's easy to get the ld to crash when doing this stuff wrong.. >> >> (I can explain how Windows does it, fyi. >> 1) The system is "doubled up", generally .dlls and .exes, but not >> kernel and drivers >> c:\windows\system32 is native >> c:\windows\syswow64 is 32bit >> Yeah it's wierd/backwards, but it is source compatible. >> There is runtime magic to redirect from "system32" in 32 bit >> processes to syswow64. >> Though if folks used the very long standing APIs, this wouldn't have >> been needed. Oh well. >> There is also c:\program files and c:\program files (x86). I guess >> people are better about using the APIs here. >> "Introspection" is "broken" but this -- link -dump against c:\windows >> \system32 can get "redirected" but devtools aren't the priority and >> it does all generally work out, despite the hokiness. >> The registry is similarly doubled up and redirected, in some places >> at least, since it tends to give paths to .dlls -- a process is >> either 32bit or 64bit -- can't load one type .dll in other type >> process. >> >> On the devtools side, well, you know, NT always had ppc/mips/alpha/ >> x86, so .libs are generally already in a directory named "i386" or >> "x86". >> In any case, folks don't hardcode paths as much, because they are >> already so variable. >> So you set up your environment or such using the %LIB% variable and >> it works easily. >> >> For running devtools, there is a separate set of .exes for each >> target. >> And sometimes for host. >> The matrix is filled out as necessary. >> AMD64 runs x86 fast so not always useful to fill out the matrix. >> Sometimes a slash is used, sometimes an underscore, sometimes >> "win64" inserted, but again, it's generally reasonable hidden behind >> a .bat file to set the environment and set $PATH and set the >> console's title (console == xterm, not the one special console). >> >> If you have more than one cl.exe or link.exe on your path, not good. >> cl.exe does more work than the gcc driver, it doesn't delegate out >> as much. >> >> There are no "fat" files like Apple does, well, not mechanized/ >> systematic. >> Something like sysinternals handle.exe that has an embedded driver >> has a toplevel x86 file that runs on everything and then on demand >> extracts the AMD64 or IA64 executable and driver, runs the other >> version of itself, installs the driver on demand and voila.. >> ) >> >> - Jay >> > From jayk123 at hotmail.com Fri Apr 18 08:23:08 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Apr 2008 06:23:08 +0000 Subject: [M3devel] biarch, multilib, etc? In-Reply-To: References: <527623C3-BC62-4CF0-B338-068D149378C2@cs.purdue.edu> Message-ID: I definitely need to try again..reading the docs: http://gcc.gnu.org/install/specific.html#x86-64-x-x x86_64-*-*, amd64-*-* GCC supports the x86-64 architecture implemented by the AMD64 processor (amd64-*-* is an alias for x86_64-*-*) on GNU/Linux, FreeBSD and NetBSD. On GNU/Linux the default is a bi-arch compiler which is able to generate both 64-bit x86-64 and 32-bit x86 code (via the -m32 switch). I was able to build an AMD64 hosted x86 targeted compiler and somehow it seemed to go very very quick, like 15 minutes.I need to verify that result, and try the default again for biarch even if it takes 5 hours. There is also --enable-targets=all or a list, which sounded promising, until I saw the above. - Jay > From: jayk123 at hotmail.com > To: hosking at cs.purdue.edu > Date: Fri, 18 Apr 2008 05:11:54 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] biarch, multilib, etc? > > > I agree this could work on Mac OS X and I will run it again, but I believe that is how I essentially got: > > jay at jayx2:~/dev2/cm3/m3-sys/m3cc/LINUXLIBC6.1$ ./cm3cg --help | grep -e " -m[0-9]" > -m128bit-long-double [disabled] > -m32 [disabled] > -m3dnow [disabled] > -m64 [enabled] > -m80387 [enabled] > -m96bit-long-double [enabled] > > jay at jayx2:~/dev2/cm3/m3-sys/m3cc/LINUXLIBC6.1$ ldd ./cm3cg > linux-vdso.so.1 => (0x00007fffc7bff000) > libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00007fbfbf6fd000) > libc.so.6 => /lib/libc.so.6 (0x00007fbfbf39b000) > /lib64/ld-linux-x86-64.so.2 (0x00007fbfbf93c000) > > which I believe will only run on AMD64 and only produce AMD64 code. > (Which is probably why I got internal compiler errors trying to use it.) > > - Jay > > > ________________________________ > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jayk123 at hotmail.com > Subject: Re: [M3devel] biarch, multilib, etc? > Date: Fri, 18 Apr 2008 00:44:57 -0400 > > > 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 Apr 18, 2008, at 12:00 AM, Jay wrote: > Kinda sorta but not quite. > I am now trying without --disable-bootstrap and --disable-multilib for non-native builds. I'll see how that goes. > I understand the niceness of a multarch toolset. > > I also would like an option for that toolset to be x86 hosted instead of AMD64 hosted, but I'll take either at this point. > It still likes to look for i686-pc-linux-gnu-ar and ld and such, rather than just using the existing biarch tools. > > Who? When building gcc? My build of cm3cg on OS X appears to be x86 hosted. cm3cg does not need to look for any tools... > > Epiphany: > There are the following platforms: > build -- what is building the compiler > host -- what the compiler will run on > target -- what the compiler's output will run on > > However each one is potentially biarch or multiarch. > (multiarch -- Mac OS X AMD64 machines can run 32 bit PowerPC, 32 bit x86, and AMD64 -- triarch). > > I build gcc without any special setup other than described above. > I host on whatever that build turns out to be. > I target using -m32/-m64. > > I understand in the general simple case, gcc -m32 is all it takes, but I don't trust that to suffice for building gcc, since there is at least one more architecture involved and there are a bunch of suspiciously relevant sounding configurable knobs, not just CC and CFLAGS, but AS_FOR_TARGET, GCC_FOR_TARGET, etc., but there aren't FOO_FOR_BUILD, FOO_FOR_HOST, FOO_FOR_TARGET; I guess plain FOO is FOO_FOR_BUILD. > > I don't specify -m32 or -m64 to build gcc itself. It automatically builds a biarch compiler. > > I'll keep poking.. > > - Jay > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > To: jayk123 at hotmail.com > > Subject: Re: [M3devel] biarch, multilib, etc? > > Date: Thu, 17 Apr 2008 22:02:16 -0400 > > > > Have you tried the following: > > > > cd cm3/m3-sys/m3cc > > mkdir build > > cd build > > ../gcc/configure --enable-languages=m3cg > > make > > > > This works for me on Mac OS X and builds a bi-arch version of m3cg > > that will accept both -m32 and -m64 flags to target x86_32 and x86_64. > > > > Admittedly, it does go through the full bootstrap, which is probably > > overkill. > > > > I haven't had a chance to try AMD64_LINUX yet, but I assume it will > > behave much the same in building a bi-arch compiler. > > > > On Apr 17, 2008, at 9:13 PM, Jay wrote: > > > >> > >> What I want to start is an x86 hosted x86 targeted cm3cg to (build > >> and) run on my AMD64 system, just to get where we already are. > >> > >> I have this: > >> > >> jay at jayx2:~/dev2/cm3/m3-sys/m3cc$ ldd LINUXLIBC6.1/cm3cg > >> linux-vdso.so.1 => (0x00007fffe21fe000) > >> libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00007f3fd9c8a000) > >> libc.so.6 => /lib/libc.so.6 (0x00007f3fd9928000) > >> /lib64/ld-linux-x86-64.so.2 (0x00007f3fd9ec9000) > >> > >> > >> which I think got via straightforward methods and which I think is > >> not what I want -- it won't run on other people's x86 system. > >> > >> Once I get that working, x86 hosted AMD64 target would be good, or > >> AMD64 hosted, AMD64 targeted if I must. > >> That is, tools can "just" be x86 hosted and work ok, enabling fewer > >> tools that run one more hosts to target more targets. > >> > >> You know, I just want gcc to pretend to ignore all the AMD64 stuff, > >> at least to start. > >> There are a variety of promising methods but stuff keeps failing > >> somewhere or another. > >> stuff like CC="gcc -m32" etc. > >> > >> e.g.: > >> collect2: ld terminated with signal 11 [Segmentation fault], core > >> dumped > >> /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- > >> unknown-linux-gnu/libiberty/libiberty.a(hashtab.o)' is incompatible > >> with i386 output > >> /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- > >> unknown-linux-gnu/libiberty/libiberty.a(xmalloc.o)' is incompatible > >> with i386 output > >> /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- > >> unknown-linux-gnu/libiberty/libiberty.a(xstrdup.o)' is incompatible > >> with i386 output > >> /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- > >> unknown-linux-gnu/libiberty/libiberty.a(xexit.o)' is incompatible > >> with i386 output > >> > >> - Jay > >> > >> ________________________________ > >> CC: m3devel at elegosoft.com > >> From: hosking at cs.purdue.edu > >> To: jayk123 at hotmail.com > >> Subject: Re: [M3devel] biarch, multilib, etc? > >> Date: Thu, 17 Apr 2008 13:03:41 -0400 > >> > >> Check the latest version of m3-sys/cminstall/src/config/LINUXLIBC6. > >> Notice that it now always uses -m32, --32 flags to the various > >> compiler components (cm3cg, SYSTEM_CC, SYSTEM_AS). This forces use > >> of the x86 variants. An AMD64_LINUX port will have an almost > >> identical configuration file that forces use of the x86_64 toolchain. > >> > >> 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 Apr 17, 2008, at 8:03 AM, Jay wrote: > >> > >> Can anyone explain how Linux and gcc are managing that AMD64 systems > >> can run > >> and presumably build x86 code? > >> > >> > >> I know there is /lib32 and /lib64. > >> I know there is gcc -m32 and gcc -m64. > >> I know that gcc itself delegates out to target specific executables, > >> so one gcc plus flags suffices, > >> it's those other executables that multiply out. That ld has the -m > >> flag. That as has --32 and --64. > >> I don't know how much stuff goes through gcc, vs. needs the get the > >> as/ld flags correct. > >> I'm not talking about Modula-3 here, but, like of building gcc and > >> its dependencies. > >> I can deal with the smaller Modula-3 system contained in far more > >> readable Quake code than all the "sh" > >> and layers upon layers of makefiles and autoconf and sh and m4 etc.. > >> > >> > >> ./configure on various things tend to build just AMD64. > >> > >> > >> It appears in general that for any > >> apt-get install foo > >> you can often but not always > >> apt-get install foo-i386 > >> > >> > >> This is on KUbuntu 8.4 Hardy Heron KDE4 beta AMD64 (mouthful!) > >> > >> > >> It looks like in general: > >> CC="gcc -m32" .../configure --prefix=/usr --libdir=/usr/lib32 -- > >> build=i686-pc-linux-gnu > >> > >> > >> is what you want, but that many packages are only native. > >> in particular gmp and mpfr: > >> apt-get install mpfr-i386 > >> => no luck > >> > >> > >> Maybe these are not considered "mainstream"? > >> > >> > >> I'll build them myself, something like: > >> > >> cd /usr/src > >> apt-get source mpfr > >> mkdir -p obj/mpfr > >> cd obj/mpfr > >> CC="gcc -m32" /usr/src/mpfr-2.3.1.dfsg.1/configure --prefix=/usr -- > >> libdir=/usr/lib32 --build=i686-pc-linux-gnu > >> make > >> sudo make install > >> > >> > >> cd /usr/src > >> apt-get source libgmp3-dev > >> mkdir -p /usr/src/obj/gmp > >> cd /usr/src/obj/obj > >> CC="gcc -m32" /usr/src/gmp-4.2.2+dfsg/configure --prefix=/usr -- > >> libdir=/usr/lib32 --build=i686-pc-linux-gnu > >> make > >> sudo make install > >> > >> You know, I just want building the Modula-3 system on AMD64_LINUX to > >> at first merely build > >> an x86 hosted, x86 targeted binary. And then start changing things. > >> > >> > >> And between host, target, and build, I find the names confusing. > >> I understand why there are three -- the current system to build the > >> compiler, a system to run the > >> compiler, a system to run the compiler's output, but these names > >> host, target, build, aren't very > >> mnemonic with me yet. Is it build=now, host=runs the compier, > >> target=runs the compiler's output? > >> I'll dig around. > >> > >> I know, I can figure it all out, there's the www to search, but this > >> biarch/multilib is hard > >> to find the docs for..and I can't read the masses of m4/sh/gmake.. > >> > >> ps: it's easy to get the ld to crash when doing this stuff wrong.. > >> > >> (I can explain how Windows does it, fyi. > >> 1) The system is "doubled up", generally .dlls and .exes, but not > >> kernel and drivers > >> c:\windows\system32 is native > >> c:\windows\syswow64 is 32bit > >> Yeah it's wierd/backwards, but it is source compatible. > >> There is runtime magic to redirect from "system32" in 32 bit > >> processes to syswow64. > >> Though if folks used the very long standing APIs, this wouldn't have > >> been needed. Oh well. > >> There is also c:\program files and c:\program files (x86). I guess > >> people are better about using the APIs here. > >> "Introspection" is "broken" but this -- link -dump against c:\windows > >> \system32 can get "redirected" but devtools aren't the priority and > >> it does all generally work out, despite the hokiness. > >> The registry is similarly doubled up and redirected, in some places > >> at least, since it tends to give paths to .dlls -- a process is > >> either 32bit or 64bit -- can't load one type .dll in other type > >> process. > >> > >> On the devtools side, well, you know, NT always had ppc/mips/alpha/ > >> x86, so .libs are generally already in a directory named "i386" or > >> "x86". > >> In any case, folks don't hardcode paths as much, because they are > >> already so variable. > >> So you set up your environment or such using the %LIB% variable and > >> it works easily. > >> > >> For running devtools, there is a separate set of .exes for each > >> target. > >> And sometimes for host. > >> The matrix is filled out as necessary. > >> AMD64 runs x86 fast so not always useful to fill out the matrix. > >> Sometimes a slash is used, sometimes an underscore, sometimes > >> "win64" inserted, but again, it's generally reasonable hidden behind > >> a .bat file to set the environment and set $PATH and set the > >> console's title (console == xterm, not the one special console). > >> > >> If you have more than one cl.exe or link.exe on your path, not good. > >> cl.exe does more work than the gcc driver, it doesn't delegate out > >> as much. > >> > >> There are no "fat" files like Apple does, well, not mechanized/ > >> systematic. > >> Something like sysinternals handle.exe that has an embedded driver > >> has a toplevel x86 file that runs on everything and then on demand > >> extracts the AMD64 or IA64 executable and driver, runs the other > >> version of itself, installs the driver on demand and voila.. > >> ) > >> > >> - Jay > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Apr 18 08:52:06 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Apr 2008 06:52:06 +0000 Subject: [M3devel] biarch, multilib, etc? In-Reply-To: References: <527623C3-BC62-4CF0-B338-068D149378C2@cs.purdue.edu> Message-ID: ok, indeed, it looks like if you omit target or targets, the default for an AMD64 host is to be able to target x86 and AMD64. If you do specify --target, then you only get one. I think. --disable-bootstrap may also lead to getting one. I think. Using an x86 probably also only gives you one, but maybe you can get multiple? I'll keep digging. I can reproduce the 17 minute build. So maybe two 17 minute builds to get two uniarch cm3cg's is the way, though it should be viable to get a biarch x86 hosted in 34 minutes. Fooling gcc into building an x86 hosted tool on an AMD64 system without a bootstrap may indeed bit a little tricky. Lots of variables.. more later.. Or maybe I should take the AMD64 targeted compiler and look into the rest of the system here.. - Jay From: jayk123 at hotmail.com To: hosking at cs.purdue.edu Date: Fri, 18 Apr 2008 06:23:08 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] biarch, multilib, etc? I definitely need to try again..reading the docs: http://gcc.gnu.org/install/specific.html#x86-64-x-x x86_64-*-*, amd64-*-* GCC supports the x86-64 architecture implemented by the AMD64 processor (amd64-*-* is an alias for x86_64-*-*) on GNU/Linux, FreeBSD and NetBSD. On GNU/Linux the default is a bi-arch compiler which is able to generate both 64-bit x86-64 and 32-bit x86 code (via the -m32 switch). I was able to build an AMD64 hosted x86 targeted compiler and somehow it seemed to go very very quick, like 15 minutes. I need to verify that result, and try the default again for biarch even if it takes 5 hours. There is also --enable-targets=all or a list, which sounded promising, until I saw the above. - Jay > From: jayk123 at hotmail.com > To: hosking at cs.purdue.edu > Date: Fri, 18 Apr 2008 05:11:54 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] biarch, multilib, etc? > > > I agree this could work on Mac OS X and I will run it again, but I believe that is how I essentially got: > > jay at jayx2:~/dev2/cm3/m3-sys/m3cc/LINUXLIBC6.1$ ./cm3cg --help | grep -e " -m[0-9]" > -m128bit-long-double [disabled] > -m32 [disabled] > -m3dnow [disabled] > -m64 [enabled] > -m80387 [enabled] > -m96bit-long-double [enabled] > > jay at jayx2:~/dev2/cm3/m3-sys/m3cc/LINUXLIBC6.1$ ldd ./cm3cg > linux-vdso.so.1 => (0x00007fffc7bff000) > libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00007fbfbf6fd000) > libc.so.6 => /lib/libc.so.6 (0x00007fbfbf39b000) > /lib64/ld-linux-x86-64.so.2 (0x00007fbfbf93c000) > > which I believe will only run on AMD64 and only produce AMD64 code. > (Which is probably why I got internal compiler errors trying to use it.) > > - Jay > > > ________________________________ > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jayk123 at hotmail.com > Subject: Re: [M3devel] biarch, multilib, etc? > Date: Fri, 18 Apr 2008 00:44:57 -0400 > > > 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 Apr 18, 2008, at 12:00 AM, Jay wrote: > Kinda sorta but not quite. > I am now trying without --disable-bootstrap and --disable-multilib for non-native builds. I'll see how that goes. > I understand the niceness of a multarch toolset. > > I also would like an option for that toolset to be x86 hosted instead of AMD64 hosted, but I'll take either at this point. > It still likes to look for i686-pc-linux-gnu-ar and ld and such, rather than just using the existing biarch tools. > > Who? When building gcc? My build of cm3cg on OS X appears to be x86 hosted. cm3cg does not need to look for any tools... > > Epiphany: > There are the following platforms: > build -- what is building the compiler > host -- what the compiler will run on > target -- what the compiler's output will run on > > However each one is potentially biarch or multiarch. > (multiarch -- Mac OS X AMD64 machines can run 32 bit PowerPC, 32 bit x86, and AMD64 -- triarch). > > I build gcc without any special setup other than described above. > I host on whatever that build turns out to be. > I target using -m32/-m64. > > I understand in the general simple case, gcc -m32 is all it takes, but I don't trust that to suffice for building gcc, since there is at least one more architecture involved and there are a bunch of suspiciously relevant sounding configurable knobs, not just CC and CFLAGS, but AS_FOR_TARGET, GCC_FOR_TARGET, etc., but there aren't FOO_FOR_BUILD, FOO_FOR_HOST, FOO_FOR_TARGET; I guess plain FOO is FOO_FOR_BUILD. > > I don't specify -m32 or -m64 to build gcc itself. It automatically builds a biarch compiler. > > I'll keep poking.. > > - Jay > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > To: jayk123 at hotmail.com > > Subject: Re: [M3devel] biarch, multilib, etc? > > Date: Thu, 17 Apr 2008 22:02:16 -0400 > > > > Have you tried the following: > > > > cd cm3/m3-sys/m3cc > > mkdir build > > cd build > > ../gcc/configure --enable-languages=m3cg > > make > > > > This works for me on Mac OS X and builds a bi-arch version of m3cg > > that will accept both -m32 and -m64 flags to target x86_32 and x86_64. > > > > Admittedly, it does go through the full bootstrap, which is probably > > overkill. > > > > I haven't had a chance to try AMD64_LINUX yet, but I assume it will > > behave much the same in building a bi-arch compiler. > > > > On Apr 17, 2008, at 9:13 PM, Jay wrote: > > > >> > >> What I want to start is an x86 hosted x86 targeted cm3cg to (build > >> and) run on my AMD64 system, just to get where we already are. > >> > >> I have this: > >> > >> jay at jayx2:~/dev2/cm3/m3-sys/m3cc$ ldd LINUXLIBC6.1/cm3cg > >> linux-vdso.so.1 => (0x00007fffe21fe000) > >> libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00007f3fd9c8a000) > >> libc.so.6 => /lib/libc.so.6 (0x00007f3fd9928000) > >> /lib64/ld-linux-x86-64.so.2 (0x00007f3fd9ec9000) > >> > >> > >> which I think got via straightforward methods and which I think is > >> not what I want -- it won't run on other people's x86 system. > >> > >> Once I get that working, x86 hosted AMD64 target would be good, or > >> AMD64 hosted, AMD64 targeted if I must. > >> That is, tools can "just" be x86 hosted and work ok, enabling fewer > >> tools that run one more hosts to target more targets. > >> > >> You know, I just want gcc to pretend to ignore all the AMD64 stuff, > >> at least to start. > >> There are a variety of promising methods but stuff keeps failing > >> somewhere or another. > >> stuff like CC="gcc -m32" etc. > >> > >> e.g.: > >> collect2: ld terminated with signal 11 [Segmentation fault], core > >> dumped > >> /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- > >> unknown-linux-gnu/libiberty/libiberty.a(hashtab.o)' is incompatible > >> with i386 output > >> /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- > >> unknown-linux-gnu/libiberty/libiberty.a(xmalloc.o)' is incompatible > >> with i386 output > >> /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- > >> unknown-linux-gnu/libiberty/libiberty.a(xstrdup.o)' is incompatible > >> with i386 output > >> /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- > >> unknown-linux-gnu/libiberty/libiberty.a(xexit.o)' is incompatible > >> with i386 output > >> > >> - Jay > >> > >> ________________________________ > >> CC: m3devel at elegosoft.com > >> From: hosking at cs.purdue.edu > >> To: jayk123 at hotmail.com > >> Subject: Re: [M3devel] biarch, multilib, etc? > >> Date: Thu, 17 Apr 2008 13:03:41 -0400 > >> > >> Check the latest version of m3-sys/cminstall/src/config/LINUXLIBC6. > >> Notice that it now always uses -m32, --32 flags to the various > >> compiler components (cm3cg, SYSTEM_CC, SYSTEM_AS). This forces use > >> of the x86 variants. An AMD64_LINUX port will have an almost > >> identical configuration file that forces use of the x86_64 toolchain. > >> > >> 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 Apr 17, 2008, at 8:03 AM, Jay wrote: > >> > >> Can anyone explain how Linux and gcc are managing that AMD64 systems > >> can run > >> and presumably build x86 code? > >> > >> > >> I know there is /lib32 and /lib64. > >> I know there is gcc -m32 and gcc -m64. > >> I know that gcc itself delegates out to target specific executables, > >> so one gcc plus flags suffices, > >> it's those other executables that multiply out. That ld has the -m > >> flag. That as has --32 and --64. > >> I don't know how much stuff goes through gcc, vs. needs the get the > >> as/ld flags correct. > >> I'm not talking about Modula-3 here, but, like of building gcc and > >> its dependencies. > >> I can deal with the smaller Modula-3 system contained in far more > >> readable Quake code than all the "sh" > >> and layers upon layers of makefiles and autoconf and sh and m4 etc.. > >> > >> > >> ./configure on various things tend to build just AMD64. > >> > >> > >> It appears in general that for any > >> apt-get install foo > >> you can often but not always > >> apt-get install foo-i386 > >> > >> > >> This is on KUbuntu 8.4 Hardy Heron KDE4 beta AMD64 (mouthful!) > >> > >> > >> It looks like in general: > >> CC="gcc -m32" .../configure --prefix=/usr --libdir=/usr/lib32 -- > >> build=i686-pc-linux-gnu > >> > >> > >> is what you want, but that many packages are only native. > >> in particular gmp and mpfr: > >> apt-get install mpfr-i386 > >> => no luck > >> > >> > >> Maybe these are not considered "mainstream"? > >> > >> > >> I'll build them myself, something like: > >> > >> cd /usr/src > >> apt-get source mpfr > >> mkdir -p obj/mpfr > >> cd obj/mpfr > >> CC="gcc -m32" /usr/src/mpfr-2.3.1.dfsg.1/configure --prefix=/usr -- > >> libdir=/usr/lib32 --build=i686-pc-linux-gnu > >> make > >> sudo make install > >> > >> > >> cd /usr/src > >> apt-get source libgmp3-dev > >> mkdir -p /usr/src/obj/gmp > >> cd /usr/src/obj/obj > >> CC="gcc -m32" /usr/src/gmp-4.2.2+dfsg/configure --prefix=/usr -- > >> libdir=/usr/lib32 --build=i686-pc-linux-gnu > >> make > >> sudo make install > >> > >> You know, I just want building the Modula-3 system on AMD64_LINUX to > >> at first merely build > >> an x86 hosted, x86 targeted binary. And then start changing things. > >> > >> > >> And between host, target, and build, I find the names confusing. > >> I understand why there are three -- the current system to build the > >> compiler, a system to run the > >> compiler, a system to run the compiler's output, but these names > >> host, target, build, aren't very > >> mnemonic with me yet. Is it build=now, host=runs the compier, > >> target=runs the compiler's output? > >> I'll dig around. > >> > >> I know, I can figure it all out, there's the www to search, but this > >> biarch/multilib is hard > >> to find the docs for..and I can't read the masses of m4/sh/gmake.. > >> > >> ps: it's easy to get the ld to crash when doing this stuff wrong.. > >> > >> (I can explain how Windows does it, fyi. > >> 1) The system is "doubled up", generally .dlls and .exes, but not > >> kernel and drivers > >> c:\windows\system32 is native > >> c:\windows\syswow64 is 32bit > >> Yeah it's wierd/backwards, but it is source compatible. > >> There is runtime magic to redirect from "system32" in 32 bit > >> processes to syswow64. > >> Though if folks used the very long standing APIs, this wouldn't have > >> been needed. Oh well. > >> There is also c:\program files and c:\program files (x86). I guess > >> people are better about using the APIs here. > >> "Introspection" is "broken" but this -- link -dump against c:\windows > >> \system32 can get "redirected" but devtools aren't the priority and > >> it does all generally work out, despite the hokiness. > >> The registry is similarly doubled up and redirected, in some places > >> at least, since it tends to give paths to .dlls -- a process is > >> either 32bit or 64bit -- can't load one type .dll in other type > >> process. > >> > >> On the devtools side, well, you know, NT always had ppc/mips/alpha/ > >> x86, so .libs are generally already in a directory named "i386" or > >> "x86". > >> In any case, folks don't hardcode paths as much, because they are > >> already so variable. > >> So you set up your environment or such using the %LIB% variable and > >> it works easily. > >> > >> For running devtools, there is a separate set of .exes for each > >> target. > >> And sometimes for host. > >> The matrix is filled out as necessary. > >> AMD64 runs x86 fast so not always useful to fill out the matrix. > >> Sometimes a slash is used, sometimes an underscore, sometimes > >> "win64" inserted, but again, it's generally reasonable hidden behind > >> a .bat file to set the environment and set $PATH and set the > >> console's title (console == xterm, not the one special console). > >> > >> If you have more than one cl.exe or link.exe on your path, not good. > >> cl.exe does more work than the gcc driver, it doesn't delegate out > >> as much. > >> > >> There are no "fat" files like Apple does, well, not mechanized/ > >> systematic. > >> Something like sysinternals handle.exe that has an embedded driver > >> has a toplevel x86 file that runs on everything and then on demand > >> extracts the AMD64 or IA64 executable and driver, runs the other > >> version of itself, installs the driver on demand and voila.. > >> ) > >> > >> - Jay > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Apr 18 09:15:24 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 18 Apr 2008 09:15:24 +0200 Subject: [M3devel] current tinderbox failures / new release? Message-ID: <20080418091524.nlijnhwta8cwk4co@mail.elegosoft.com> Currently builds of cm3 fail because quake's getwd is not in the last release (5.4.0) and so cannot be used for bootstrapping. Could somebody fix that? We really need to provide a new release soon to be able to safely use all the new functionality. But there are still no working tests on NT386*, and X64 porting seems to be underway. I think we should define a goal or milestone (we can even do that with trac), define the needed features or blocking bugs and work towards it. Or is everybody just as busy as I am and this is no good idea? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Fri Apr 18 10:00:56 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Apr 2008 08:00:56 +0000 Subject: [M3devel] current tinderbox failures / new release? In-Reply-To: <20080418091524.nlijnhwta8cwk4co@mail.elegosoft.com> References: <20080418091524.nlijnhwta8cwk4co@mail.elegosoft.com> Message-ID: getwd was my doing. Yeah I guess I'll workaround, with some sh. Sorry, I didn't realize. I guess fs_cp same problem? Tony "argues" for removing the useof getwd, but so far it seems to fix something that is actually a problem. I think any release is ok...sort of. > NT386 tests NT386 tests aren't runnable, but presumably no major regression, right? There is still the bitmap thing. > AMD64 AMD64 Certainly ok to release without. And you meant AMD64_NT/LINUX. AMD64_DARWIN is already there from Tony. :) Am I going to have to stop checking in, or use a branch? > needed features, blocking bugs Just having new targets even in "prerelease" form are nice features already present: AMD64_DARWIN (aka AMD64_MACOSX :) ) NT386GNU NT386MINGNU (still without gui working due to __stdcall; I should workaround..) plus: Quake extensions set relationship bug fix non-interactive install install-less archives possibly available possible perf benefits from sleep() removal in Process Would be nice to get PPC_LINUX up to pthreads but not high priority. Not sure what the marketing department says, if this is "enough" to have a "major" release that everyone will "buy". :) What's the "official" QA/release process anyway, for the daily snapshots, the snapshots I uploaded, vs. anything else? Would be nice to see if .debs/.rpms could be made and available through "official" channels. - Jay > Date: Fri, 18 Apr 2008 09:15:24 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] current tinderbox failures / new release? > > Currently builds of cm3 fail because quake's getwd is not in the > last release (5.4.0) and so cannot be used for bootstrapping. > Could somebody fix that? > > We really need to provide a new release soon to be able to safely use > all the new functionality. But there are still no working tests on > NT386*, and X64 porting seems to be underway. > > I think we should define a goal or milestone (we can even do that with > trac), define the needed features or blocking bugs and work towards > it. > > Or is everybody just as busy as I am and this is no good idea? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 jayk123 at hotmail.com Fri Apr 18 12:19:07 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Apr 2008 10:19:07 +0000 Subject: [M3devel] bootstrap and Compiler.i3 change? Message-ID: What is the deal with building and the Compiler.i3 change? I had difficulty here, despite using upgrade.py and upgrade.sh that have gotten things correct before (and I understand what they are doing). I ended up doing something that didn't make sense to me and I got past it, but then I had another problem. I ran ugprade until it failed -- it built/shipped compiler and m3core; then libm3 fails. Then I think I ran either do-cm3-front.py, or I rolled back tools and then ran do-cm3-front.py. I understand the change to Compiler.i3. It should be ok. It is in m3core, build/ship that and then build libm3 should work, right? The code that is actually using Compiler.i3 is for fairly unused targets, however it actually sets a good example I intend to follow. Rather than probing for what Pathname.Join returns a\b or a/b, you can check Compiler.Platform or whatnot directly. But if there are more uses of this, outside m3core, this build problem needs to be understood. Probably I'm just missing something? The other problem I ran into was, merely running a particular cm3 with no parameters, crash in module initialization: (gdb) r Starting program: /home/jkrell/cm3/bin/cm3 Failed to read a valid object file image from memory. [Thread debugging using libthread_db enabled] [New Thread -1210100032 (LWP 32329)] *** *** runtime error: *** Attempt to reference an illegal memory location. *** file "../src/runtime/common/RTAllocator.m3", line 203 *** Program received signal SIGABRT, Aborted. [Switching to Thread -1210100032 (LWP 32329)] 0xb7f6d410 in ?? () (gdb) bt #0 0xb7f6d410 in ?? () #1 0xbfa24f6c in ?? () #2 0x00000006 in ?? () #3 0x00007e49 in ?? () #4 0xb7e1e811 in raise () from /lib/tls/i686/cmov/libc.so.6 #5 0xb7e1ffb9 in abort () from /lib/tls/i686/cmov/libc.so.6 #6 0x082c4cfe in RTOS__Crash () at ../src/runtime/POSIX/RTOS.m3:20 #7 0x082ba6c5 in RTProcess__Crash (M3_Bd56fi_msg=0x0) at ../src/runtime/common/RTProcess.m3:65 #8 0x082b7e8e in RTError__EndError (M3_AicXUJ_crash=1 '\001') at ../src/runtime/common/RTError.m3:118 #9 0x082b7b52 in RTError__MsgS (M3_AJWxb1_file=0x8359a68, M3_AcxOUs_line=203, M3_Bd56fi_msgA=0x835cd48, M3_Bd56fi_msgB=0x8358f14, M3_Bd56fi_msgC=0x835cd48) at ../src/runtime/common/RTError.m3:40 #10 0x082b8314 in RTException__Crash (M3_Cblw37_a=0xbfa252d8, M3_AicXUJ_raises=0 '\0', M3_AJWxb1_rte=0x8358d00) at ../src/runtime/common/RTException.m3:79 #11 0x082b801d in RTException__DefaultBackstop (M3_Cblw37_a=0xbfa252d8, M3_AicXUJ_raises=0 '\0') at ../src/runtime/common/RTException.m3:39 #12 0x082b7f59 in RTException__InvokeBackstop (M3_Cblw37_a=0xbfa252d8, M3_AicXUJ_raises=0 '\0') at ../src/runtime/common/RTException.m3:25 #13 0x082c5f90 in RTException__Raise (M3_Cblw37_act=0xbfa252d8) at ../src/runtime/ex_frame/RTExFrame.m3:29 #14 0x082b80b6 in RTException__DefaultBackstop (M3_Cblw37_a=0xbfa252d8, M3_AicXUJ_raises=0 '\0') at ../src/runtime/common/RTException.m3:47 #15 0x082b7f59 in RTException__InvokeBackstop (M3_Cblw37_a=0xbfa252d8, M3_AicXUJ_raises=0 '\0') at ../src/runtime/common/RTException.m3:25 #16 0x082c5f90 in RTException__Raise (M3_Cblw37_act=0xbfa252d8) at ../src/runtime/ex_frame/RTExFrame.m3:29 #17 0x082a380f in RTHooks__ReportFault (M3_AJWxb1_module=0x8359aa0, M3_AcxOUs_info=6500) at ../src/runtime/common/RTHooks.m3:110 #18 0x082a5c81 in _m3_fault (M3_AcxOUs_arg=6500) ---Type to continue, or q to quit--- #19 0x082a497e in RTAllocator__GetTracedObj (M3_Eic7CK_def=0x0) at ../src/runtime/common/RTAllocator.m3:203 #20 0x082a4524 in RTHooks__AllocateTracedObj (M3_AJWxb1_defn=0x0) at ../src/runtime/common/RTAllocator.m3:131 #21 0x08272fae in Pathname__Decompose (M3_Bd56fi_pn=0xb7dbb02c) at ../src/os/POSIX/PathnamePosix.m3:31 #22 0x08104d95 in PathRepr__Root (M3_Bd56fi_pn=0xb7dbb02c) at PathReprCommon.m3:37 #23 0x08104e7f in PathReprCommon_M3 (M3_AcxOUs_mode=1) at PathReprCommon.m3:45 #24 0x082b6e9b in RTLinker__RunMainBody (M3_DjPxE3_m=0x830b380) at ../src/runtime/common/RTLinker.m3:399 #25 0x082b6b67 in RTLinker__RunMainBody (M3_DjPxE3_m=0x830a280) at ../src/runtime/common/RTLinker.m3:379 #26 0x082b6b67 in RTLinker__RunMainBody (M3_DjPxE3_m=0x8309c00) at ../src/runtime/common/RTLinker.m3:379 #27 0x082b6b67 in RTLinker__RunMainBody (M3_DjPxE3_m=0x8308360) at ../src/runtime/common/RTLinker.m3:379 #28 0x082b6b67 in RTLinker__RunMainBody (M3_DjPxE3_m=0x8305c00) at ../src/runtime/common/RTLinker.m3:379 #29 0x082b6b67 in RTLinker__RunMainBody (M3_DjPxE3_m=0x82f91e0) at ../src/runtime/common/RTLinker.m3:379 #30 0x082b6b67 in RTLinker__RunMainBody (M3_DjPxE3_m=0x82f89a0) at ../src/runtime/common/RTLinker.m3:379 #31 0x082b6b67 in RTLinker__RunMainBody (M3_DjPxE3_m=0x82fccc0) at ../src/runtime/common/RTLinker.m3:379 #32 0x082b5911 in RTLinker__AddUnitI (M3_DjPxE3_m=0x82fccc0) at ../src/runtime/common/RTLinker.m3:113 #33 0x082b599f in RTLinker__AddUnit (M3_DjPxE5_b=0x808e9a2) at ../src/runtime/common/RTLinker.m3:122 #34 0x08057038 in main (argc=1, argv=0xbfa25eb4, envp=0xbfa25ebc) at _m3main.mc:4 which I'll look into further if I still see it, later.. - Jay From wagner at elegosoft.com Fri Apr 18 12:40:02 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 18 Apr 2008 12:40:02 +0200 Subject: [M3devel] bootstrap and Compiler.i3 change? In-Reply-To: References: Message-ID: <20080418124002.rc7rondrwkc04go8@mail.elegosoft.com> Quoting Jay : > What is the deal with building and the Compiler.i3 change? > I had difficulty here, despite using upgrade.py and upgrade.sh that > have gotten things correct before (and I understand what they are > doing). > > I ended up doing something that didn't make sense to me and I got > past it, but then I had another problem. > > I ran ugprade until it failed -- it built/shipped compiler and > m3core; then libm3 fails. > Then I think I ran either do-cm3-front.py, or I rolled back tools > and then ran do-cm3-front.py. > > I understand the change to Compiler.i3. It should be ok. It is in > m3core, build/ship that and then build libm3 should work, right? > > The code that is actually using Compiler.i3 is for fairly unused > targets, however it actually sets a good example I intend to follow. > Rather than probing for what Pathname.Join returns a\b or a/b, you > can check Compiler.Platform or whatnot directly. > But if there are more uses of this, outside m3core, this build > problem needs to be understood. > Probably I'm just missing something? Are you sure you didn't just forget to clean everything after building the first cm3? upgrade.sh should do it right though... My own regression tests at home seem to have recoverd from the target extension without further help (except for the new required libraries), too, so I'm quite sure that upgrade.sh does the right things. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Fri Apr 18 13:28:43 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Apr 2008 11:28:43 +0000 Subject: [M3devel] bootstrap and Compiler.i3 change? In-Reply-To: <20080418124002.rc7rondrwkc04go8@mail.elegosoft.com> References: <20080418124002.rc7rondrwkc04go8@mail.elegosoft.com> Message-ID: I really thought I did the right thing. Hm. I will have to start over. And I'm seeing this again on birch, alas: at ../src/runtime/ex_frame/RTExFrame.m3:29 #17 0x082a394b in RTHooks__ReportFault (M3_AJWxb1_module=0x8359be0, M3_AcxOUs_info=6500) at ../src/runtime/common/RTHooks.m3:110 #18 0x082a5dbd in _m3_fault (M3_AcxOUs_arg=6500) ---Type to continue, or q to quit--- #19 0x082a4aba in RTAllocator__GetTracedObj (M3_Eic7CK_def=0x0) at ../src/runtime/common/RTAllocator.m3:203 #20 0x082a4660 in RTHooks__AllocateTracedObj (M3_AJWxb1_defn=0x0) at ../src/runtime/common/RTAllocator.m3:131 #21 0x082730ea in Pathname__Decompose (M3_Bd56fi_pn=0xb7e1302c) at ../src/os/POSIX/PathnamePosix.m3:31 #22 0x08104ed1 in PathRepr__Root (M3_Bd56fi_pn=0xb7e1302c) at ../src/PathReprCommon.m3:37 #23 0x08104fbb in PathReprCommon_M3 (M3_AcxOUs_mode=1) at ../src/PathReprCommon.m3:45 #24 0x082b6fd7 in RTLinker__RunMainBody (M3_DjPxE3_m=0x830b4c0) I have AMD64 host building an x86 hosted x86/AMD64 target compiler now..and if you change "make" to "make all-gcc", it does a lot less...though still wastes time building unneeded stuff. - Jay > Date: Fri, 18 Apr 2008 12:40:02 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] bootstrap and Compiler.i3 change? > > Quoting Jay : > >> What is the deal with building and the Compiler.i3 change? >> I had difficulty here, despite using upgrade.py and upgrade.sh that >> have gotten things correct before (and I understand what they are >> doing). >> >> I ended up doing something that didn't make sense to me and I got >> past it, but then I had another problem. >> >> I ran ugprade until it failed -- it built/shipped compiler and >> m3core; then libm3 fails. >> Then I think I ran either do-cm3-front.py, or I rolled back tools >> and then ran do-cm3-front.py. >> >> I understand the change to Compiler.i3. It should be ok. It is in >> m3core, build/ship that and then build libm3 should work, right? >> >> The code that is actually using Compiler.i3 is for fairly unused >> targets, however it actually sets a good example I intend to follow. >> Rather than probing for what Pathname.Join returns a\b or a/b, you >> can check Compiler.Platform or whatnot directly. >> But if there are more uses of this, outside m3core, this build >> problem needs to be understood. >> Probably I'm just missing something? > > Are you sure you didn't just forget to clean everything after > building the first cm3? upgrade.sh should do it right though... > > My own regression tests at home seem to have recoverd from the > target extension without further help (except for the new required > libraries), too, so I'm quite sure that upgrade.sh does the right > things. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 18 16:15:51 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 18 Apr 2008 10:15:51 -0400 Subject: [M3devel] TOT CM3 compile. In-Reply-To: References: <7F1A2BCF-BBFE-4C62-B74C-255D29A31183@cs.purdue.edu> Message-ID: <5A42A212-D002-4ADA-9BF5-E170B7E7C9C3@cs.purdue.edu> I haven't touched that portion of things (bash syntax). Jay may be the culprit. :-) On Apr 18, 2008, at 1:37 AM, Alex Bochannek wrote: > Tony Hosking writes: > >> Because there is now a new target, you need to first build a >> bootstrap >> compiler that understands the new target specs. To build a bootstrap >> compiler, compile and ship the following packages: > > That's what happens when I can't pay attention to the mailing list > for a > while. Suddenly everything changes :-) Building right now... > > Couple of related things. > > I happened to be looking at script/boot-cm3-core.sh and noticed that > there some Bash syntax crept in. You touched that file more recently > and > since it is a bit late for me, I thought maybe you can check if I've > got > the logic right in the replacement for the -ot operator > > Index: boot-cm3-core.sh > =================================================================== > RCS file: /usr/cvs/cm3/scripts/boot-cm3-core.sh,v > retrieving revision 1.9 > diff -u -r1.9 boot-cm3-core.sh > --- boot-cm3-core.sh 13 Apr 2008 18:22:32 -0000 1.9 > +++ boot-cm3-core.sh 18 Apr 2008 05:37:02 -0000 > @@ -25,7 +25,7 @@ > BUILDARGS="${BUILDARGS:--DM3_BOOTSTRAP=TRUE -keep}" > M3CONFIG_SRC=${ROOT}/m3-sys/cm3/src/config/${CROSS_TARGET} > M3CONFIG=${ROOT}/scripts/${TARGET}-${CROSS_TARGET}.cfg > -if [ ! -f "${M3CONFIG}" -o "${M3CONFIG}" -ot "${M3CONFIG_SRC}" ] ; > then > +if [ ! -f "${M3CONFIG}" -o -z `find "${M3CONFIG}" -prune -newer "$ > {M3CONFIG_SRC}"` ] ; then > sed -e "s;m3back.*=.*;m3back = \"@${ROOT}/m3-sys/m3cc/${TARGET}-$ > {CROSS_TARGET}/cm3cg\";" \ > ${M3CONFIG_SRC} > ${M3CONFIG} > fi > > > I noticed that the new GCC needs GMP and MPFR. I can't install > anything > in /usr on my machine (it's a zone on a Solaris server) and instead > use > Blastwave, which puts things into /opt/csw. The only way to tell the > build process where to pick up the libraries is by modifying line > 319 in > m3-sys/m3cc/src/m3makefile. Is there a better way? > > Thanks, > > Alex. From jayk123 at hotmail.com Fri Apr 18 16:58:02 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Apr 2008 14:58:02 +0000 Subject: [M3devel] TOT CM3 compile. In-Reply-To: <5A42A212-D002-4ADA-9BF5-E170B7E7C9C3@cs.purdue.edu> References: <7F1A2BCF-BBFE-4C62-B74C-255D29A31183@cs.purdue.edu> <5A42A212-D002-4ADA-9BF5-E170B7E7C9C3@cs.purdue.edu> Message-ID: > gmp/mpfr Go ahead and either: cm3 -DM3CC_CONFIG="...lots..." which should circument a bunch of the m3makefile content, or edit the m3makefile to probe for your location. /Presumably/ nobody is going to have anything there, that they don't mind getting used in this way. ? The whole m3-sys/m3cc/m3makefile could be considered "optional". It's a "thin" wrapper over just building gcc. It tries to do the right thing in "all" situations, but I'm sure it often fails or is incomplete, such as for cross builds. This is my newfound wisdom from just this week, still subject to sinking in and being wrong. :) > bash syntax Sorry I really don't know what is sh vs. ksh vs. bash. Does anyone know of an implementation that adheres closely to sh that I can use to stop regressing stuff? Preferably that runs on one or more of: MacOS X (PowerPC for now) x86 or AMD64 or PowerPC Linux x86 or AMD64 NT Kubuntu (that I'm using) has "dash" for /bin/sh. Good? Or some flag I should use for bash? I can check the docs, but, next two points: I do usually use the Python stuff, partly to avoid this problem. Oh, but this about boot*.sh. I never looked at, ran, or changed that, sorry. Really...writing scripts/python and quake/m3makefile is usually relatively fun and productive but not this *.sh :) - Jay > From: hosking at cs.purdue.edu > To: alexb at juniper.net > Date: Fri, 18 Apr 2008 10:15:51 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] TOT CM3 compile. > > I haven't touched that portion of things (bash syntax). Jay may be > the culprit. :-) > > On Apr 18, 2008, at 1:37 AM, Alex Bochannek wrote: > > > Tony Hosking writes: > > > >> Because there is now a new target, you need to first build a > >> bootstrap > >> compiler that understands the new target specs. To build a bootstrap > >> compiler, compile and ship the following packages: > > > > That's what happens when I can't pay attention to the mailing list > > for a > > while. Suddenly everything changes :-) Building right now... > > > > Couple of related things. > > > > I happened to be looking at script/boot-cm3-core.sh and noticed that > > there some Bash syntax crept in. You touched that file more recently > > and > > since it is a bit late for me, I thought maybe you can check if I've > > got > > the logic right in the replacement for the -ot operator > > > > Index: boot-cm3-core.sh > > =================================================================== > > RCS file: /usr/cvs/cm3/scripts/boot-cm3-core.sh,v > > retrieving revision 1.9 > > diff -u -r1.9 boot-cm3-core.sh > > --- boot-cm3-core.sh 13 Apr 2008 18:22:32 -0000 1.9 > > +++ boot-cm3-core.sh 18 Apr 2008 05:37:02 -0000 > > @@ -25,7 +25,7 @@ > > BUILDARGS="${BUILDARGS:--DM3_BOOTSTRAP=TRUE -keep}" > > M3CONFIG_SRC=${ROOT}/m3-sys/cm3/src/config/${CROSS_TARGET} > > M3CONFIG=${ROOT}/scripts/${TARGET}-${CROSS_TARGET}.cfg > > -if [ ! -f "${M3CONFIG}" -o "${M3CONFIG}" -ot "${M3CONFIG_SRC}" ] ; > > then > > +if [ ! -f "${M3CONFIG}" -o -z `find "${M3CONFIG}" -prune -newer "$ > > {M3CONFIG_SRC}"` ] ; then > > sed -e "s;m3back.*=.*;m3back = \"@${ROOT}/m3-sys/m3cc/${TARGET}-$ > > {CROSS_TARGET}/cm3cg\";" \ > > ${M3CONFIG_SRC} > ${M3CONFIG} > > fi > > > > > > I noticed that the new GCC needs GMP and MPFR. I can't install > > anything > > in /usr on my machine (it's a zone on a Solaris server) and instead > > use > > Blastwave, which puts things into /opt/csw. The only way to tell the > > build process where to pick up the libraries is by modifying line > > 319 in > > m3-sys/m3cc/src/m3makefile. Is there a better way? > > > > Thanks, > > > > Alex. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Apr 18 17:01:32 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Apr 2008 15:01:32 +0000 Subject: [M3devel] whitespace rationale? Message-ID: Does anyone know of a reason to put a space between a function and the paren to start its call? Other than "When in Rome"? I've long not put that in, but I see a fair amount of code that does, and a fair amount of code that I didn't write that doesn't (e.g. sysutils). Seems to be all over the place, but a lot of Modula-3 code puts it in (not that I have seen much Modula-3 code in the world...but...) Similarly for array indexing array [index] vs. array[index]. (Not to mention if (expr) and not if ( expr ). Modula-3 (and Python!) doesn't require the parens so it comes up less often.) I always like to know why.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Apr 18 17:13:24 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Apr 2008 15:13:24 +0000 Subject: [M3devel] some multi-arch conclusions Message-ID: When cm3cg --help prints -m32 [enabled] -m64 [disabled] enabled/disabled is the present (default) setting. It doesn't indicate if the compiler supports the flag. To see the meaning of the switch spelled out, use cm3cg --quiet --help. Found by searching the code for [enabled]. Seems backwards, and gcc/cc1 don't work this way. No matter. To see if the switch works, try running it: cm3cg -m32 cm3cg -m64 Some variants will give a clear error that the feature isn't there. Otherwise press control-d (or z) twice to exit. AMD64 hosts by default can target 64 bit and 32 bit. PowerPC and SPARC ought to be the same imho but I don't think they are (yet). I saw some mail thread people asking for this for PowerPC. The docs indicate it is there for PowerPC. The code or the ChangeLog at least shows churn here for SPARC. 32 bit hosts do not default to being able to target multiple architectures. But you can configure them so: x86 hosts can be configured to have a working -m64 switch via --enable-targets=all or --enable-targets=i686-pc-linux-gnu,amd64-pc-linux-gnu Same for 32 bit PowerPC I think, and maybe SPARC. Those same switches should work for AMD64 hosts, but it is the default. I guess you might be able to trim out the x86 target via --enable-targets-amd64-pc-linux-gnu or --disable-targets=i686-pc-linux-gnu, but I didn't try that. There is a term "biarch" or "bi-arch" for "two architectures". When searching the code, be sure to also look for bi-arch. Searching the web I see people refer to --enable-biarch, but I don't believe there is any "biarch" flag anywhere in gcc. Just this --enable-targets=all. And --multilibs stuff. I can't speak to glibc and binutils. Perhaps biarch does mean something in the code. Or maybe it used to. That's what I know. Tony -- your multiarch cm3cg may or may not run on x86. As I understand, there are both 32 bit and 64 bit Intel Macintoshes out there. The first generation were "Core" not "Core 2" and no 64 bit. In the hardware. And presumably in the software. I don't know when they enabled 64 bit Intel. Lately I believe all Intel Macintoshes are 64 bit hardware. I don't know if therefore they can all run 64 bit user mode code, or if this isn't always enabled. I'm not sure if the kernel is 32 bit or 64 bit but we don't care, I'm sure. Historically we have built WAY more of gcc than is generally needed. I can see there being bootstrap scenarios from Sun/IBM/SGI tools, and whatnot, and certainly gcc needs this stuff, they need the bootstrap scenario, etc. However for Modula-3, on systems with a reasonably current gcc already, lots of extra. My machine also took hours to build m3cc recently and now just 7 minutes. Yeah. Later, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Apr 18 17:18:43 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Apr 2008 15:18:43 +0000 Subject: [M3devel] current failures? Message-ID: If anyone else sees this consistently, please let me know. There's only about two of us under suspicion. :) If it's just me, on Birch, I try not to worry too much. I have to take a break but will test out more to see if it occurs, like on PPC_DARWIN, NT386GNU, NT386.. Hopefully the Tinderbox is back under way. % gdb cm3 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 "i486-linux-gnu"...Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (gdb) r Starting program: /home/jkrell/cm3/bin/cm3 Failed to read a valid object file image from memory. [Thread debugging using libthread_db enabled] [New Thread -1210534208 (LWP 5467)] *** *** runtime error: *** Attempt to reference an illegal memory location. *** file "../src/runtime/common/RTAllocator.m3", line 203 *** Program received signal SIGABRT, Aborted. [Switching to Thread -1210534208 (LWP 5467)] 0xb7f03410 in ?? () (gdb) bt #0 0xb7f03410 in ?? () #1 0xbfbfa93c in ?? () #2 0x00000006 in ?? () #3 0x0000155b in ?? () #4 0xb7db4811 in raise () from /lib/tls/i686/cmov/libc.so.6 #5 0xb7db5fb9 in abort () from /lib/tls/i686/cmov/libc.so.6 #6 0x082c4e36 in RTOS__Crash () at ../src/runtime/POSIX/RTOS.m3:20 #7 0x082ba7fd in RTProcess__Crash (M3_Bd56fi_msg=0x0) at ../src/runtime/common/RTProcess.m3:65 #8 0x082b7fc6 in RTError__EndError (M3_AicXUJ_crash=1 '\001') at ../src/runtime/common/RTError.m3:118 #9 0x082b7c8a in RTError__MsgS (M3_AJWxb1_file=0x8359ba8, M3_AcxOUs_line=203, M3_Bd56fi_msgA=0x835ce88, M3_Bd56fi_msgB=0x8359054, M3_Bd56fi_msgC=0x835ce88) at ../src/runtime/common/RTError.m3:40 #10 0x082b844c in RTException__Crash (M3_Cblw37_a=0xbfbfaca8, M3_AicXUJ_raises=0 '\0', M3_AJWxb1_rte=0x8358e40) at ../src/runtime/common/RTException.m3:79 #11 0x082b8155 in RTException__DefaultBackstop (M3_Cblw37_a=0xbfbfaca8, M3_AicXUJ_raises=0 '\0') at ../src/runtime/common/RTException.m3:39 #12 0x082b8091 in RTException__InvokeBackstop (M3_Cblw37_a=0xbfbfaca8, M3_AicXUJ_raises=0 '\0') at ../src/runtime/common/RTException.m3:25 #13 0x082c60c8 in RTException__Raise (M3_Cblw37_act=0xbfbfaca8) at ../src/runtime/ex_frame/RTExFrame.m3:29 #14 0x082b81ee in RTException__DefaultBackstop (M3_Cblw37_a=0xbfbfaca8, M3_AicXUJ_raises=0 '\0') at ../src/runtime/common/RTException.m3:47 #15 0x082b8091 in RTException__InvokeBackstop (M3_Cblw37_a=0xbfbfaca8, M3_AicXUJ_raises=0 '\0') at ../src/runtime/common/RTException.m3:25 #16 0x082c60c8 in RTException__Raise (M3_Cblw37_act=0xbfbfaca8) at ../src/runtime/ex_frame/RTExFrame.m3:29 #17 0x082a3947 in RTHooks__ReportFault (M3_AJWxb1_module=0x8359be0, M3_AcxOUs_info=6500) at ../src/runtime/common/RTHooks.m3:110 #18 0x082a5db9 in _m3_fault (M3_AcxOUs_arg=6500) ---Type to continue, or q to quit--- #19 0x082a4ab6 in RTAllocator__GetTracedObj (M3_Eic7CK_def=0x0) at ../src/runtime/common/RTAllocator.m3:203 #20 0x082a465c in RTHooks__AllocateTracedObj (M3_AJWxb1_defn=0x0) at ../src/runtime/common/RTAllocator.m3:131 #21 0x082730e6 in Pathname__Decompose (M3_Bd56fi_pn=0xb7d5102c) at ../src/os/POSIX/PathnamePosix.m3:31 #22 0x08104ecd in PathRepr__Root (M3_Bd56fi_pn=0xb7d5102c) at ../src/PathReprCommon.m3:37 #23 0x08104fb7 in PathReprCommon_M3 (M3_AcxOUs_mode=1) at ../src/PathReprCommon.m3:45 #24 0x082b6fd3 in RTLinker__RunMainBody (M3_DjPxE3_m=0x830b4c0) at ../src/runtime/common/RTLinker.m3:399 #25 0x082b6c9f in RTLinker__RunMainBody (M3_DjPxE3_m=0x830a3c0) at ../src/runtime/common/RTLinker.m3:379 #26 0x082b6c9f in RTLinker__RunMainBody (M3_DjPxE3_m=0x8309d40) at ../src/runtime/common/RTLinker.m3:379 #27 0x082b6c9f in RTLinker__RunMainBody (M3_DjPxE3_m=0x83084a0) at ../src/runtime/common/RTLinker.m3:379 #28 0x082b6c9f in RTLinker__RunMainBody (M3_DjPxE3_m=0x8305d40) at ../src/runtime/common/RTLinker.m3:379 #29 0x082b6c9f in RTLinker__RunMainBody (M3_DjPxE3_m=0x82f9320) at ../src/runtime/common/RTLinker.m3:379 #30 0x082b6c9f in RTLinker__RunMainBody (M3_DjPxE3_m=0x82f8ae0) at ../src/runtime/common/RTLinker.m3:379 #31 0x082b6c9f in RTLinker__RunMainBody (M3_DjPxE3_m=0x82fce00) at ../src/runtime/common/RTLinker.m3:379 #32 0x082b5a49 in RTLinker__AddUnitI (M3_DjPxE3_m=0x82fce00) at ../src/runtime/common/RTLinker.m3:113 #33 0x082b5ad7 in RTLinker__AddUnit (M3_DjPxE5_b=0x808e9a0) at ../src/runtime/common/RTLinker.m3:122 #34 0x08057038 in main (argc=1, argv=0xbfbfb884, envp=0xbfbfb88c) at _m3main.mc:4 Thanks, - Jay From hosking at cs.purdue.edu Fri Apr 18 18:02:04 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 18 Apr 2008 12:02:04 -0400 Subject: [M3devel] whitespace rationale? In-Reply-To: References: Message-ID: <1E08B814-50D5-4A19-930F-76725E6BF426@cs.purdue.edu> Purely a matter of style. I generally don't put the space for calls: EVAL f(); but I do for declarations: PROCEDURE f () = ... just so that when I want to search for a local declaration I can easily do that with a text search for "f ()". Just my 2 cents. However, when editing code in any one style, I tend to preserve the style. On Apr 18, 2008, at 11:01 AM, Jay wrote: > Does anyone know of a reason to put a space between a function and > the paren to start its call? > Other than "When in Rome"? > > I've long not put that in, but I see a fair amount of code that > does, and a fair amount of code that I didn't write that doesn't > (e.g. sysutils). > Seems to be all over the place, but a lot of Modula-3 code puts it > in (not that I have seen much Modula-3 code in the world...but...) > > Similarly for array indexing array [index] vs. array[index]. > > (Not to mention if (expr) and not if ( expr ). Modula-3 (and > Python!) doesn't require the parens so it comes up less often.) > > I always like to know why.. > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Apr 18 18:03:56 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 18 Apr 2008 12:03:56 -0400 Subject: [M3devel] some multi-arch conclusions In-Reply-To: References: Message-ID: On Apr 18, 2008, at 11:13 AM, Jay wrote: > 32 bit hosts do not default to being able to target multiple > architectures. My x86 Mac OS X box seems to. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Apr 18 18:32:02 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Apr 2008 16:32:02 +0000 Subject: [M3devel] whitespace rationale? In-Reply-To: <1E08B814-50D5-4A19-930F-76725E6BF426@cs.purdue.edu> References: <1E08B814-50D5-4A19-930F-76725E6BF426@cs.purdue.edu> Message-ID: I like the function names at the first column to find definitions, but lots of folks don't do that and it is rare/nonexistant in cm3. :( Granted, your way doesn't require a regexp search. Subtle, but also very useful, one of those things that most folks wouldn't think of -- not just style, but style with function. Of course, it's arbitrary which of the two ways, I think. A parameter per line also eases diff/merge, but uses a lot of vertical space.. I still think it's worth coming up with a style and a rationale for new code. Not necessarily in this forum :). It's not all maintenance hopefully. (And yeah I've heard of syntax tree editors that present the text in the user's preferred style. Been an open research question for probably decades now. Plain text in regular file systems wins.) - Jay ________________________________ > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jayk123 at hotmail.com > Subject: Re: [M3devel] whitespace rationale? > Date: Fri, 18 Apr 2008 12:02:04 -0400 > > Purely a matter of style. I generally don't put the space for calls: > > EVAL f(); > > but I do for declarations: > > PROCEDURE f () = ... > > just so that when I want to search for a local declaration I can easily do that with a text search for "f ()". Just my 2 cents. > > However, when editing code in any one style, I tend to preserve the style. > > On Apr 18, 2008, at 11:01 AM, Jay wrote: > Does anyone know of a reason to put a space between a function and the paren to start its call? > Other than "When in Rome"? > > I've long not put that in, but I see a fair amount of code that does, and a fair amount of code that I didn't write that doesn't (e.g. sysutils). > Seems to be all over the place, but a lot of Modula-3 code puts it in (not that I have seen much Modula-3 code in the world...but...) > > Similarly for array indexing array [index] vs. array[index]. > > (Not to mention if (expr) and not if ( expr ). Modula-3 (and Python!) doesn't require the parens so it comes up less often.) > > I always like to know why.. > > - Jay From mika at async.caltech.edu Fri Apr 18 19:30:41 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 18 Apr 2008 10:30:41 -0700 Subject: [M3devel] whitespace rationale? In-Reply-To: Your message of "Fri, 18 Apr 2008 15:01:32 -0000." Message-ID: <200804181730.m3IHUfF0049162@camembert.async.caltech.edu> Dunno, but "m3pp -callspace" does it that way... someone at SRC liked that style?? Mika Jay writes: >--_04796398-baf6-48c8-ba84-074241a4e579_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Does anyone know of a reason to put a space between a function and the pare= >n to start its call? >Other than "When in Rome"? > >I've long not put that in, but I see a fair amount of code that does, and a= > fair amount of code that I didn't write that doesn't (e.g. sysutils). >Seems to be all over the place, but a lot of Modula-3 code puts it in (not = >that I have seen much Modula-3 code in the world...but...) > >Similarly for array indexing array [index] vs. array[index]. > >(Not to mention if (expr) and not if ( expr ). Modula-3 (and Python!) doesn= >'t require the parens so it comes up less often.) > >I always like to know why.. > > - Jay From mika at async.caltech.edu Fri Apr 18 19:34:17 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 18 Apr 2008 10:34:17 -0700 Subject: [M3devel] whitespace rationale? In-Reply-To: Your message of "Fri, 18 Apr 2008 16:32:02 -0000." Message-ID: <200804181734.m3IHYHrw049300@camembert.async.caltech.edu> Jay writes: > >I like the function names at the first column to find definitions, but lots of folks don't do that and it is rare/nonexistant in cm3. :( That's necessary in C, but in Modula-3 you can just search for "EDURE F"! From hosking at cs.purdue.edu Fri Apr 18 19:39:30 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 18 Apr 2008 13:39:30 -0400 Subject: [M3devel] current failures? In-Reply-To: References: Message-ID: <360F3641-769A-4B44-9BF4-3DAD3A805BD6@cs.purdue.edu> Could be an out-of-sync build state. Did you start from clean? On Apr 18, 2008, at 11:18 AM, Jay wrote: > > If anyone else sees this consistently, please let me know. > There's only about two of us under suspicion. :) > If it's just me, on Birch, I try not to worry too much. > I have to take a break but will test out more to see if it occurs, > like on PPC_DARWIN, NT386GNU, NT386.. > > Hopefully the Tinderbox is back under way. > > % gdb cm3 > 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 "i486-linux-gnu"...Using host > libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". > > (gdb) r > Starting program: /home/jkrell/cm3/bin/cm3 > Failed to read a valid object file image from memory. > [Thread debugging using libthread_db enabled] > [New Thread -1210534208 (LWP 5467)] > > > *** > *** runtime error: > *** Attempt to reference an illegal memory location. > *** file "../src/runtime/common/RTAllocator.m3", line 203 > *** > > > Program received signal SIGABRT, Aborted. > [Switching to Thread -1210534208 (LWP 5467)] > 0xb7f03410 in ?? () > (gdb) bt > #0 0xb7f03410 in ?? () > #1 0xbfbfa93c in ?? () > #2 0x00000006 in ?? () > #3 0x0000155b in ?? () > #4 0xb7db4811 in raise () from /lib/tls/i686/cmov/libc.so.6 > #5 0xb7db5fb9 in abort () from /lib/tls/i686/cmov/libc.so.6 > #6 0x082c4e36 in RTOS__Crash () at ../src/runtime/POSIX/RTOS.m3:20 > #7 0x082ba7fd in RTProcess__Crash (M3_Bd56fi_msg=0x0) at ../src/ > runtime/common/RTProcess.m3:65 > #8 0x082b7fc6 in RTError__EndError (M3_AicXUJ_crash=1 '\001') > at ../src/runtime/common/RTError.m3:118 > #9 0x082b7c8a in RTError__MsgS (M3_AJWxb1_file=0x8359ba8, > M3_AcxOUs_line=203, > M3_Bd56fi_msgA=0x835ce88, M3_Bd56fi_msgB=0x8359054, > M3_Bd56fi_msgC=0x835ce88) > at ../src/runtime/common/RTError.m3:40 > #10 0x082b844c in RTException__Crash (M3_Cblw37_a=0xbfbfaca8, > M3_AicXUJ_raises=0 '\0', > M3_AJWxb1_rte=0x8358e40) at ../src/runtime/common/RTException.m3:79 > #11 0x082b8155 in RTException__DefaultBackstop > (M3_Cblw37_a=0xbfbfaca8, M3_AicXUJ_raises=0 '\0') > at ../src/runtime/common/RTException.m3:39 > #12 0x082b8091 in RTException__InvokeBackstop > (M3_Cblw37_a=0xbfbfaca8, M3_AicXUJ_raises=0 '\0') > at ../src/runtime/common/RTException.m3:25 > #13 0x082c60c8 in RTException__Raise (M3_Cblw37_act=0xbfbfaca8) > at ../src/runtime/ex_frame/RTExFrame.m3:29 > #14 0x082b81ee in RTException__DefaultBackstop > (M3_Cblw37_a=0xbfbfaca8, M3_AicXUJ_raises=0 '\0') > at ../src/runtime/common/RTException.m3:47 > #15 0x082b8091 in RTException__InvokeBackstop > (M3_Cblw37_a=0xbfbfaca8, M3_AicXUJ_raises=0 '\0') > at ../src/runtime/common/RTException.m3:25 > #16 0x082c60c8 in RTException__Raise (M3_Cblw37_act=0xbfbfaca8) > at ../src/runtime/ex_frame/RTExFrame.m3:29 > #17 0x082a3947 in RTHooks__ReportFault (M3_AJWxb1_module=0x8359be0, > M3_AcxOUs_info=6500) > at ../src/runtime/common/RTHooks.m3:110 > #18 0x082a5db9 in _m3_fault (M3_AcxOUs_arg=6500) > ---Type to continue, or q to quit--- > #19 0x082a4ab6 in RTAllocator__GetTracedObj (M3_Eic7CK_def=0x0) > at ../src/runtime/common/RTAllocator.m3:203 > #20 0x082a465c in RTHooks__AllocateTracedObj (M3_AJWxb1_defn=0x0) > at ../src/runtime/common/RTAllocator.m3:131 > #21 0x082730e6 in Pathname__Decompose (M3_Bd56fi_pn=0xb7d5102c) > at ../src/os/POSIX/PathnamePosix.m3:31 > #22 0x08104ecd in PathRepr__Root (M3_Bd56fi_pn=0xb7d5102c) at ../src/ > PathReprCommon.m3:37 > #23 0x08104fb7 in PathReprCommon_M3 (M3_AcxOUs_mode=1) at ../src/ > PathReprCommon.m3:45 > #24 0x082b6fd3 in RTLinker__RunMainBody (M3_DjPxE3_m=0x830b4c0) > at ../src/runtime/common/RTLinker.m3:399 > #25 0x082b6c9f in RTLinker__RunMainBody (M3_DjPxE3_m=0x830a3c0) > at ../src/runtime/common/RTLinker.m3:379 > #26 0x082b6c9f in RTLinker__RunMainBody (M3_DjPxE3_m=0x8309d40) > at ../src/runtime/common/RTLinker.m3:379 > #27 0x082b6c9f in RTLinker__RunMainBody (M3_DjPxE3_m=0x83084a0) > at ../src/runtime/common/RTLinker.m3:379 > #28 0x082b6c9f in RTLinker__RunMainBody (M3_DjPxE3_m=0x8305d40) > at ../src/runtime/common/RTLinker.m3:379 > #29 0x082b6c9f in RTLinker__RunMainBody (M3_DjPxE3_m=0x82f9320) > at ../src/runtime/common/RTLinker.m3:379 > #30 0x082b6c9f in RTLinker__RunMainBody (M3_DjPxE3_m=0x82f8ae0) > at ../src/runtime/common/RTLinker.m3:379 > #31 0x082b6c9f in RTLinker__RunMainBody (M3_DjPxE3_m=0x82fce00) > at ../src/runtime/common/RTLinker.m3:379 > #32 0x082b5a49 in RTLinker__AddUnitI (M3_DjPxE3_m=0x82fce00) > at ../src/runtime/common/RTLinker.m3:113 > #33 0x082b5ad7 in RTLinker__AddUnit (M3_DjPxE5_b=0x808e9a0) > at ../src/runtime/common/RTLinker.m3:122 > #34 0x08057038 in main (argc=1, argv=0xbfbfb884, envp=0xbfbfb88c) at > _m3main.mc:4 > > Thanks, > - Jay From rcoleburn at scires.com Fri Apr 18 21:56:28 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 18 Apr 2008 15:56:28 -0400 Subject: [M3devel] whitespace rationale? In-Reply-To: References: <1E08B814-50D5-4A19-930F-76725E6BF426@cs.purdue.edu> Message-ID: <4808C4AE.1E75.00D7.1@scires.com> I have a Modula-3 style guide that I developed for my company a number of years ago. If anyone is interested, I don't mind contributing it to the repository. Regards, Randy >>> Jay 4/18/2008 12:32 PM >>> I like the function names at the first column to find definitions, but lots of folks don't do that and it is rare/nonexistant in cm3. :( Granted, your way doesn't require a regexp search. Subtle, but also very useful, one of those things that most folks wouldn't think of -- not just style, but style with function. Of course, it's arbitrary which of the two ways, I think. A parameter per line also eases diff/merge, but uses a lot of vertical space.. I still think it's worth coming up with a style and a rationale for new code. Not necessarily in this forum :). It's not all maintenance hopefully. (And yeah I've heard of syntax tree editors that present the text in the user's preferred style. Been an open research question for probably decades now. Plain text in regular file systems wins.) - Jay ________________________________ > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jayk123 at hotmail.com > Subject: Re: [M3devel] whitespace rationale? > Date: Fri, 18 Apr 2008 12:02:04 -0400 > > Purely a matter of style. I generally don't put the space for calls: > > EVAL f(); > > but I do for declarations: > > PROCEDURE f () = ... > > just so that when I want to search for a local declaration I can easily do that with a text search for "f ()". Just my 2 cents. > > However, when editing code in any one style, I tend to preserve the style -------------- next part -------------- An HTML attachment was scrubbed... URL: From HOSKING at cs.purdue.edu Fri Apr 18 23:23:24 2008 From: HOSKING at cs.purdue.edu (Tony Hosking) Date: Fri, 18 Apr 2008 17:23:24 -0400 Subject: [M3devel] gmp and mpfr Message-ID: I have added the necessary gmp and mpfr distributions to the m3cc/gcc package. It turns out that gcc will try to build from local source if it is available in the gcc hierarchy. Now, the only question is how to make sure that installs will put things in the right place. One option is to configure gcc to install into INSTALL_ROOT from the m3cc m3makefile. But that would mean a full install of gcc and libraries. Any other thoughts? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Apr 19 01:31:27 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Apr 2008 23:31:27 +0000 Subject: [M3devel] gmp and mpfr In-Reply-To: References: Message-ID: Thanks. > other thoughts? Static link? I should measure the bloat. I accidentally statically linked to libc.a and the bloat was small, I think x86 static was smaller than AMD64 dynamic. > But that would mean a full install of gcc and libraries. Really? Why not just gmp and mpfr and then point configure at them? Besides, if necessary, import them but not under gcc? - Jay From: HOSKING at cs.purdue.edu To: m3devel at elegosoft.com Date: Fri, 18 Apr 2008 17:23:24 -0400 Subject: [M3devel] gmp and mpfr I have added the necessary gmp and mpfr distributions to the m3cc/gcc package. It turns out that gcc will try to build from local source if it is available in the gcc hierarchy. Now, the only question is how to make sure that installs will put things in the right place. One option is to configure gcc to install into INSTALL_ROOT from the m3cc m3makefile. But that would mean a full install of gcc and libraries. Any other thoughts? -------------- next part -------------- An HTML attachment was scrubbed... URL: From neels at elego.de Sat Apr 19 01:43:45 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Sat, 19 Apr 2008 01:43:45 +0200 Subject: [M3devel] Umman.off_t Message-ID: <48093231.8010800@elego.de> Hi, I am having problems deploying the suplib on FreeBSD (FreeBSD new.elego.de 6.2-RELEASE-p3), using the latest cm3 snapshot (cm3-src-all-d5.7.0-2008-04-16-14-07-05.tgz). A type mismatch error is encountered at the last parameter of the call addr := Umman.mmap(NIL, StatBuf.GetStatSize(statbuf), Umman.PROT_READ, Umman.MAP_SHARED, fd, 0); , the zero, that is. The parameter is called "off" and of type off_t. cm3/m3-libs/m3core/src/unix/freebsd-4/Umman.i3 declares the following about off_t: FROM Utypes IMPORT caddr_t, size_t, off_t; <*EXTERNAL*> PROCEDURE mmap (addr: caddr_t; len: size_t; prot,flags,fd: int; off: off_t) : caddr_t; and Utypes.i3 adds: FROM Ctypes IMPORT long, unsigned_long, int, unsigned_int, short, unsigned_short, char, unsigned_char, long_long; TYPE int64_t = long_long; off_t = int64_t; It turns out that using 0L instead of just 0 solves the compilation error on FreeBSD. Yes, but on linux-libc6, Utypes.i3 says something different, and the 0L in turn causes a type mismatch there. So this is a dilemma situation where the porting between linux and FreeBSD involves source code editing - certainly not good. linux-libc6/Utypes.i3: FROM Ctypes IMPORT long, ... off_t = long; Any help? Thanks! -- Neels Hofmeyr -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Sat Apr 19 01:58:41 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Apr 2008 23:58:41 +0000 Subject: [M3devel] Umman.off_t In-Reply-To: <48093231.8010800@elego.de> References: <48093231.8010800@elego.de> Message-ID: Imho constant integer expressions should be promoted silently. But that's just me. Try one of these: ORD (0, off_t) VAL (0, off_t) ORD (off_t, 0) VAL (off_t, 0) - Jay ---------------------------------------- > Date: Sat, 19 Apr 2008 01:43:45 +0200 > From: neels at elego.de > To: m3devel at elego.de > Subject: [M3devel] Umman.off_t > > Hi, > > I am having problems deploying the suplib on FreeBSD (FreeBSD > new.elego.de 6.2-RELEASE-p3), using the latest cm3 snapshot > (cm3-src-all-d5.7.0-2008-04-16-14-07-05.tgz). > > A type mismatch error is encountered at the last parameter of the call > > addr := Umman.mmap(NIL, StatBuf.GetStatSize(statbuf), > Umman.PROT_READ, > Umman.MAP_SHARED, fd, 0); > > , the zero, that is. The parameter is called "off" and of type off_t. > > cm3/m3-libs/m3core/src/unix/freebsd-4/Umman.i3 > > declares the following about off_t: > > > FROM Utypes IMPORT caddr_t, size_t, off_t; > > > PROCEDURE mmap (addr: caddr_t; len: size_t; prot,flags,fd: int; off: off_t) > : caddr_t; > > > and Utypes.i3 adds: > > > FROM Ctypes IMPORT > long, unsigned_long, int, unsigned_int, short, unsigned_short, > char, unsigned_char, long_long; > > TYPE > int64_t = long_long; > > off_t = int64_t; > > > It turns out that using 0L instead of just 0 solves the compilation > error on FreeBSD. > > Yes, but on linux-libc6, Utypes.i3 says something different, and the 0L > in turn causes a type mismatch there. So this is a dilemma situation > where the porting between linux and FreeBSD involves source code editing > - certainly not good. > > linux-libc6/Utypes.i3: > > FROM Ctypes IMPORT > long, ... > off_t = long; > > > Any help? > > Thanks! > > -- > Neels Hofmeyr -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 19 12:43:06 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 19 Apr 2008 12:43:06 +0200 Subject: [M3devel] gmp and mpfr In-Reply-To: References: Message-ID: <20080419124306.oxag3l6ego0owgw0@mail.elegosoft.com> Quoting Jay : > Thanks. > > > other thoughts? > > Static link? > > I should measure the bloat. > I accidentally statically linked to libc.a and the bloat was small, > I think x86 static was smaller than AMD64 dynamic. We must not link _any_ executable completely statically, we've been through that. Modern Unix systems all require dynamic linking, at least for all the standard C libraries. > > But that would mean a full install of gcc and libraries. > > Really? > Why not just gmp and mpfr and then point configure at them? > Besides, if necessary, import them but not under gcc? > > - Jay > > > From: HOSKING at cs.purdue.edu > To: m3devel at elegosoft.com > Date: Fri, 18 Apr 2008 17:23:24 -0400 > Subject: [M3devel] gmp and mpfr > > I have added the necessary gmp and mpfr distributions to the > m3cc/gcc package. It turns out that gcc will try to build from > local source if it is available in the gcc hierarchy. Now, the only > question is how to make sure that installs will put things in the > right place. One option is to configure gcc to install into > INSTALL_ROOT from the m3cc m3makefile. But that would mean a full > install of gcc and libraries. Any other thoughts? If we really need to have these libraries in the distribution, we should either link them in statically or put the shared objects into INSTALL_ROOT/lib. We could either create different packages (that would require adding these to several scripts) or add some special quake code to build them all as part of m3cc: build libgmp ship libgmp to INSTALL_ROOT/lib build mpfr ship mpfr to INSTALL_ROOT/lib configure gcc with --with-mpfr=INSTALL_ROOT/lib/libmpfr.so \ --with-gmp=INSTALL_ROOT/lib/libgmp.so (I don't think the argument are completely correct, but you get the idea.) build gcc ship gcc The problem with this setup is that it wouldn't work for local builds (without shipping), and we'd have problems when the libraries need upgrade and we overwrite them (bootstrap will break). Or ensure proper versioning here (which is nowhere done up=to-now in cm3). Or (in case of build without ship) just specify the locations in the workspace? Then we'd need to re-link cm3cg in case of later build and ship. What do you think? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 19 13:00:13 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 19 Apr 2008 13:00:13 +0200 Subject: [M3devel] gmp and mpfr In-Reply-To: References: Message-ID: <20080419130013.mo2bzawq9kwo0s0g@mail.elegosoft.com> Quoting Tony Hosking : > I have added the necessary gmp and mpfr distributions to the m3cc/gcc > package. It turns out that gcc will try to build from local source if > it is available in the gcc hierarchy. Now, the only question is how > to make sure that installs will put things in the right place. One > option is to configure gcc to install into INSTALL_ROOT from the m3cc > m3makefile. But that would mean a full install of gcc and libraries. > Any other thoughts? After wondering where the libraries might be, I've now found them at /usr/cvs/cm3/m3cc/gcc/{mpfr,gmp}. I think you wanted to import them to usr/cvs/cm3/m3-sys/m3cc/gcc/{mpfr,gmp}, didn't you? Any objections to move them inside the repository (will break existing workspaces and repo copies...) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Sat Apr 19 14:27:38 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Apr 2008 12:27:38 +0000 Subject: [M3devel] gmp and mpfr In-Reply-To: <20080419124306.oxag3l6ego0owgw0@mail.elegosoft.com> References: <20080419124306.oxag3l6ego0owgw0@mail.elegosoft.com> Message-ID: Static linking libc is a different matter. It should work on Linux and NT but I realize it isn't universally supported. I did it by accident. The kernel does have a compatiblity burden, at least where the interfaces have been published. (On NT, the layering is different. You can link statically to libcmt.lib, which to a very large extent is what people think of libc, but it doesn't call the kernel directly, it goes through kernel32.dll, which goes through ntdll.dll, and syscall numbers are not stable.) Anyway, for libgmp and libmpfr, I still think static linking to these two is definitely ok, or better. Whether we import the source is a separate variable -- can still build a static .a file and link to it and drop the runtime dependency. That, or we get to deal with LD_LIBRARY_PATH and/or -rpath. It sure is nice how on Windows you can at least colocate .exes and .dlls in the same directory and the .dlls get found. This is a different matter vs. if current directory is in the search path for .exes. - Jay > Date: Sat, 19 Apr 2008 12:43:06 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] gmp and mpfr > > Quoting Jay : > > > Thanks. > > > > > other thoughts? > > > > Static link? > > > > I should measure the bloat. > > I accidentally statically linked to libc.a and the bloat was small, > > I think x86 static was smaller than AMD64 dynamic. > > We must not link _any_ executable completely statically, we've been > through that. Modern Unix systems all require dynamic linking, at > least for all the standard C libraries. > > > > But that would mean a full install of gcc and libraries. > > > > Really? > > Why not just gmp and mpfr and then point configure at them? > > Besides, if necessary, import them but not under gcc? > > > > - Jay > > > > > > From: HOSKING at cs.purdue.edu > > To: m3devel at elegosoft.com > > Date: Fri, 18 Apr 2008 17:23:24 -0400 > > Subject: [M3devel] gmp and mpfr > > > > I have added the necessary gmp and mpfr distributions to the > > m3cc/gcc package. It turns out that gcc will try to build from > > local source if it is available in the gcc hierarchy. Now, the only > > question is how to make sure that installs will put things in the > > right place. One option is to configure gcc to install into > > INSTALL_ROOT from the m3cc m3makefile. But that would mean a full > > install of gcc and libraries. Any other thoughts? > > If we really need to have these libraries in the distribution, > we should either link them in statically or put the shared objects > into INSTALL_ROOT/lib. We could either create different packages > (that would require adding these to several scripts) or add some > special quake code to build them all as part of m3cc: > > build libgmp > ship libgmp to INSTALL_ROOT/lib > build mpfr > ship mpfr to INSTALL_ROOT/lib > configure gcc with --with-mpfr=INSTALL_ROOT/lib/libmpfr.so \ > --with-gmp=INSTALL_ROOT/lib/libgmp.so > (I don't think the argument are completely correct, but you get the idea.) > build gcc > ship gcc > > The problem with this setup is that it wouldn't work for local builds > (without shipping), and we'd have problems when the libraries need > upgrade and we overwrite them (bootstrap will break). Or ensure > proper versioning here (which is nowhere done up=to-now in cm3). > > Or (in case of build without ship) just specify the locations in the > workspace? Then we'd need to re-link cm3cg in case of later build and > ship. > > What do you think? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 jayk123 at hotmail.com Sat Apr 19 14:41:52 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Apr 2008 12:41:52 +0000 Subject: [M3devel] gmp and mpfr In-Reply-To: <20080419124306.oxag3l6ego0owgw0@mail.elegosoft.com> References: <20080419124306.oxag3l6ego0owgw0@mail.elegosoft.com> Message-ID: Truncated again.. Static linking libc is a different matter. It should work on Linux and NT but I realize it isn't universally supported. I did it by accident. The kernel does have a compatiblity burden, at least where the interfaces have been published. (On NT, the layering is different. You can link statically to libcmt.lib, which to a very large extent is what people think of libc, but it doesn't call the kernel directly, it goes through kernel32.dll, which goes through ntdll.dll, and syscall numbers are not stable.) Anyway, for libgmp and libmpfr, I still think static linking to these two is definitely ok, or better. Whether we import the source is a separate variable -- can still build a static .a file and link to it and drop the runtime dependency. That, or we get to deal with LD_LIBRARY_PATH and/or -rpath. It sure is nice how on Windows you can at least colocate .exes and .dlls in the same directory and the .dlls get found. This is a different matter vs. if current directory is in the search path for .exes. - Jay > Date: Sat, 19 Apr 2008 12:43:06 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] gmp and mpfr > > Quoting Jay : > > > Thanks. > > > > > other thoughts? > > > > Static link? > > > > I should measure the bloat. > > I accidentally statically linked to libc.a and the bloat was small, > > I think x86 static was smaller than AMD64 dynamic. > > We must not link _any_ executable completely statically, we've been > through that. Modern Unix systems all require dynamic linking, at > least for all the standard C libraries. > > > > But that would mean a full install of gcc and libraries. > > > > Really? > > Why not just gmp and mpfr and then point configure at them? > > Besides, if necessary, import them but not under gcc? > > > > - Jay > > > > > > From: HOSKING at cs.purdue.edu > > To: m3devel at elegosoft.com > > Date: Fri, 18 Apr 2008 17:23:24 -0400 > > Subject: [M3devel] gmp and mpfr > > > > I have added the necessary gmp and mpfr distributions to the > > m3cc/gcc package. It turns out that gcc will try to build from > > local source if it is available in the gcc hierarchy. Now, the only > > question is how to make sure that installs will put things in the > > right place. One option is to configure gcc to install into > > INSTALL_ROOT from the m3cc m3makefile. But that would mean a full > > install of gcc and libraries. Any other thoughts? > > If we really need to have these libraries in the distribution, > we should either link them in statically or put the shared objects > into INSTALL_ROOT/lib. We could either create different packages > (that would require adding these to several scripts) or add some > special quake code to build them all as part of m3cc: > > build libgmp > ship libgmp to INSTALL_ROOT/lib > build mpfr > ship mpfr to INSTALL_ROOT/lib > configure gcc with --with-mpfr=INSTALL_ROOT/lib/libmpfr.so \ > --with-gmp=INSTALL_ROOT/lib/libgmp.so > (I don't think the argument are completely correct, but you get the idea.) > build gcc > ship gcc > > The problem with this setup is that it wouldn't work for local builds > (without shipping), and we'd have problems when the libraries need > upgrade and we overwrite them (bootstrap will break). Or ensure > proper versioning here (which is nowhere done up=to-now in cm3). > > Or (in case of build without ship) just specify the locations in the > workspace? Then we'd need to re-link cm3cg in case of later build and > ship. > > What do you think? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 jayk123 at hotmail.com Sat Apr 19 14:55:18 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Apr 2008 12:55:18 +0000 Subject: [M3devel] FW: gmp and mpfr In-Reply-To: <20080419124306.oxag3l6ego0owgw0@mail.elegosoft.com> References: <20080419124306.oxag3l6ego0owgw0@mail.elegosoft.com> Message-ID: truncated yet again, maybe I have to forward instead of reply.. Truncated again.. Static linking libc is a different matter. It should work on Linux and NT but I realize it isn't universally supported. I did it by accident. The kernel does have a compatiblity burden, at least where the interfaces have been published. (On NT, the layering is different. You can link statically to libcmt.lib, which to a very large extent is what people think of libc, but it doesn't call the kernel directly, it goes through kernel32.dll, which goes through ntdll.dll, and syscall numbers are not stable.) Anyway, for libgmp and libmpfr, I still think static linking to these two is definitely ok, or better. Whether we import the source is a separate variable -- can still build a static .a file and link to it and drop the runtime dependency. That, or we get to deal with LD_LIBRARY_PATH and/or -rpath. It sure is nice how on Windows you can at least colocate .exes and .dlls in the same directory and the .dlls get found. This is a different matter vs. if current directory is in the search path for .exes. - Jay > Date: Sat, 19 Apr 2008 12:43:06 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] gmp and mpfr > > Quoting Jay : > > > Thanks. > > > > > other thoughts? > > > > Static link? > > > > I should measure the bloat. > > I accidentally statically linked to libc.a and the bloat was small, > > I think x86 static was smaller than AMD64 dynamic. > > We must not link _any_ executable completely statically, we've been > through that. Modern Unix systems all require dynamic linking, at > least for all the standard C libraries. > > > > But that would mean a full install of gcc and libraries. > > > > Really? > > Why not just gmp and mpfr and then point configure at them? > > Besides, if necessary, import them but not under gcc? > > > > - Jay > > > > > > From: HOSKING at cs.purdue.edu > > To: m3devel at elegosoft.com > > Date: Fri, 18 Apr 2008 17:23:24 -0400 > > Subject: [M3devel] gmp and mpfr > > > > I have added the necessary gmp and mpfr distributions to the > > m3cc/gcc package. It turns out that gcc will try to build from > > local source if it is available in the gcc hierarchy. Now, the only > > question is how to make sure that installs will put things in the > > right place. One option is to configure gcc to install into > > INSTALL_ROOT from the m3cc m3makefile. But that would mean a full > > install of gcc and libraries. Any other thoughts? > > If we really need to have these libraries in the distribution, > we should either link them in statically or put the shared objects > into INSTALL_ROOT/lib. We could either create different packages > (that would require adding these to several scripts) or add some > special quake code to build them all as part of m3cc: > > build libgmp > ship libgmp to INSTALL_ROOT/lib > build mpfr > ship mpfr to INSTALL_ROOT/lib > configure gcc with --with-mpfr=INSTALL_ROOT/lib/libmpfr.so \ > --with-gmp=INSTALL_ROOT/lib/libgmp.so > (I don't think the argument are completely correct, but you get the idea.) > build gcc > ship gcc > > The problem with this setup is that it wouldn't work for local builds > (without shipping), and we'd have problems when the libraries need > upgrade and we overwrite them (bootstrap will break). Or ensure > proper versioning here (which is nowhere done up=to-now in cm3). > > Or (in case of build without ship) just specify the locations in the > workspace? Then we'd need to re-link cm3cg in case of later build and > ship. > > What do you think? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 jayk123 at hotmail.com Sat Apr 19 14:57:48 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Apr 2008 12:57:48 +0000 Subject: [M3devel] FW: gmp and mpfr In-Reply-To: References: <20080419124306.oxag3l6ego0owgw0@mail.elegosoft.com> Message-ID: truncated a second time, I'll try from amother machine, geez short version -- static link libgmp and libmpfr, nothing else static linking libc ought to work imho but that is a different matter; kernels should be compatible with their published interfaces, if they have any -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Apr 19 15:50:00 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Apr 2008 13:50:00 +0000 Subject: [M3devel] gmp and mpfr In-Reply-To: <20080419130013.mo2bzawq9kwo0s0g@mail.elegosoft.com> References: <20080419130013.mo2bzawq9kwo0s0g@mail.elegosoft.com> Message-ID: Isn't it more proper to delete and re-add/re-import in the correct place? I mean, cvs -z3 upd can just work, right? - Jay > Date: Sat, 19 Apr 2008 13:00:13 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] gmp and mpfr > > Quoting Tony Hosking : > > > I have added the necessary gmp and mpfr distributions to the m3cc/gcc > > package. It turns out that gcc will try to build from local source if > > it is available in the gcc hierarchy. Now, the only question is how > > to make sure that installs will put things in the right place. One > > option is to configure gcc to install into INSTALL_ROOT from the m3cc > > m3makefile. But that would mean a full install of gcc and libraries. > > Any other thoughts? > > After wondering where the libraries might be, I've now found them > at /usr/cvs/cm3/m3cc/gcc/{mpfr,gmp}. > I think you wanted to import them to usr/cvs/cm3/m3-sys/m3cc/gcc/{mpfr,gmp}, > didn't you? > Any objections to move them inside the repository (will break existing > workspaces and repo copies...) > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 jayk123 at hotmail.com Sat Apr 19 16:31:32 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Apr 2008 14:31:32 +0000 Subject: [M3devel] a hope for dynamic linking! Message-ID: http://www.eyrie.org/~eagle/notes/rpath.html http://people.debian.org/~che/personal/rpath-considered-harmful but yet: http://www.scons.org/wiki/UsingOrigin So you can either colocate executables and .sos in the same directory or, like /cm3/bin /cm3/lib/m3core.so and vary the install root. We should be using this where available -- Linux, Solaris, Irix. Too bad not supported elsewhere. On Windows you can colocate; the .exe's directory is always searched. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Apr 19 16:40:25 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 19 Apr 2008 10:40:25 -0400 Subject: [M3devel] gmp and mpfr In-Reply-To: <20080419130013.mo2bzawq9kwo0s0g@mail.elegosoft.com> References: <20080419130013.mo2bzawq9kwo0s0g@mail.elegosoft.com> Message-ID: No, the gcc distros are set up to expect them in top-level gcc directory, if at all, along with the other libraries. The configure script will find them there and build locally as necessary rather than finding them in the usual installed places. On Apr 19, 2008, at 7:00 AM, Olaf Wagner wrote: > Quoting Tony Hosking : > >> I have added the necessary gmp and mpfr distributions to the m3cc/gcc >> package. It turns out that gcc will try to build from local source >> if >> it is available in the gcc hierarchy. Now, the only question is how >> to make sure that installs will put things in the right place. One >> option is to configure gcc to install into INSTALL_ROOT from the m3cc >> m3makefile. But that would mean a full install of gcc and libraries. >> Any other thoughts? > > After wondering where the libraries might be, I've now found them > at /usr/cvs/cm3/m3cc/gcc/{mpfr,gmp}. > I think you wanted to import them to usr/cvs/cm3/m3-sys/m3cc/gcc/ > {mpfr,gmp}, > didn't you? > Any objections to move them inside the repository (will break existing > workspaces and repo copies...) > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Sat Apr 19 16:42:54 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 19 Apr 2008 10:42:54 -0400 Subject: [M3devel] gmp and mpfr In-Reply-To: References: <20080419130013.mo2bzawq9kwo0s0g@mail.elegosoft.com> Message-ID: <44D5D5D2-7032-465D-B90E-EBDE9AD7DA75@cs.purdue.edu> Sorry. Looks like they're in the right place now. On Apr 19, 2008, at 9:50 AM, Jay wrote: > Isn't it more proper to delete and re-add/re-import in the correct > place? > I mean, cvs -z3 upd can just work, right? > > - Jay > > > > > Date: Sat, 19 Apr 2008 13:00:13 +0200 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] gmp and mpfr > > > > Quoting Tony Hosking : > > > > > I have added the necessary gmp and mpfr distributions to the > m3cc/gcc > > > package. It turns out that gcc will try to build from local > source if > > > it is available in the gcc hierarchy. Now, the only question is > how > > > to make sure that installs will put things in the right place. One > > > option is to configure gcc to install into INSTALL_ROOT from the > m3cc > > > m3makefile. But that would mean a full install of gcc and > libraries. > > > Any other thoughts? > > > > After wondering where the libraries might be, I've now found them > > at /usr/cvs/cm3/m3cc/gcc/{mpfr,gmp}. > > I think you wanted to import them to usr/cvs/cm3/m3-sys/m3cc/gcc/ > {mpfr,gmp}, > > didn't you? > > Any objections to move them inside the repository (will break > existing > > workspaces and repo copies...) > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Sat Apr 19 16:50:04 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 19 Apr 2008 10:50:04 -0400 Subject: [M3devel] a hope for dynamic linking! In-Reply-To: References: Message-ID: Hold on! I am strongly in favor of static linking for cm3cg/m3cgc1 so that it is a standalone executable. Should be easy enough with gcc configure. On Apr 19, 2008, at 10:31 AM, Jay wrote: > http://www.eyrie.org/~eagle/notes/rpath.html > http://people.debian.org/~che/personal/rpath-considered-harmful > > > but yet: > > http://www.scons.org/wiki/UsingOrigin > > So you can either colocate executables and .sos in the same > directory or, like > /cm3/bin > /cm3/lib/m3core.so > > and vary the install root. > > We should be using this where available -- Linux, Solaris, Irix. > Too bad not supported elsewhere. > On Windows you can colocate; the .exe's directory is always searched. > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Apr 19 17:02:44 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Apr 2008 15:02:44 +0000 Subject: [M3devel] a hope for dynamic linking! In-Reply-To: References: Message-ID: I mean for the "regular" Modula-3 "app" stuff, not cm3cg. It looks like it is already static, good. 1) http://gcc.gnu.org/ml/gcc/2006-10/msg00141.html 2) The current code: m3-sys/m3cc/gcc/Makefile.in: configure-gmp: ... echo Configuring in $(HOST_SUBDIR)/gmp; \ ... $(HOST_CONFIGARGS) --build=${build_alias} --host=none-${host_vendor}-${host_os} \ --target=none-${host_vendor}-${host_os} $${srcdiroption} --disable-shared \ || exit 1 @endif gmp configure-mpfr: ... echo Configuring in $(HOST_SUBDIR)/mpfr; \ ... $(HOST_CONFIGARGS) --build=${build_alias} --host=none-${host_vendor}-${host_os} \ --target=none-${host_vendor}-${host_os} $${srcdiroption} --disable-shared --with-gmp-build=$$r/$(HOST_SUBDIR)/gmp \ || exit 1 @endif mpfr Let me test it and then I'll remove the Quake code related to this. - Jay CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jayk123 at hotmail.com Subject: Re: [M3devel] a hope for dynamic linking! Date: Sat, 19 Apr 2008 10:50:04 -0400 Hold on! I am strongly in favor of static linking for cm3cg/m3cgc1 so that it is a standalone executable. Should be easy enough with gcc configure. On Apr 19, 2008, at 10:31 AM, Jay wrote:http://www.eyrie.org/~eagle/notes/rpath.html http://people.debian.org/~che/personal/rpath-considered-harmful but yet: http://www.scons.org/wiki/UsingOrigin So you can either colocate executables and .sos in the same directory or, like /cm3/bin /cm3/lib/m3core.so and vary the install root. We should be using this where available -- Linux, Solaris, Irix. Too bad not supported elsewhere. On Windows you can colocate; the .exe's directory is always searched. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Apr 19 17:10:16 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Apr 2008 15:10:16 +0000 Subject: [M3devel] a hope for dynamic linking! In-Reply-To: References: Message-ID: (ok, actually I meant maybe for cm3cg but ok either way, there'd only be one use of "/usr/local/cm3/bin/libgmp.so" so might as well be static) From: jayk123 at hotmail.com To: hosking at cs.purdue.edu Date: Sat, 19 Apr 2008 15:02:44 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] a hope for dynamic linking! I mean for the "regular" Modula-3 "app" stuff, not cm3cg. It looks like it is already static, good. 1) http://gcc.gnu.org/ml/gcc/2006-10/msg00141.html 2) The current code: m3-sys/m3cc/gcc/Makefile.in: configure-gmp: ... echo Configuring in $(HOST_SUBDIR)/gmp; \ ... $(HOST_CONFIGARGS) --build=${build_alias} --host=none-${host_vendor}-${host_os} \ --target=none-${host_vendor}-${host_os} $${srcdiroption} --disable-shared \ || exit 1 @endif gmp configure-mpfr: ... echo Configuring in $(HOST_SUBDIR)/mpfr; \ ... $(HOST_CONFIGARGS) --build=${build_alias} --host=none-${host_vendor}-${host_os} \ --target=none-${host_vendor}-${host_os} $${srcdiroption} --disable-shared --with-gmp-build=$$r/$(HOST_SUBDIR)/gmp \ || exit 1 @endif mpfr Let me test it and then I'll remove the Quake code related to this. - Jay CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jayk123 at hotmail.com Subject: Re: [M3devel] a hope for dynamic linking! Date: Sat, 19 Apr 2008 10:50:04 -0400 Hold on! I am strongly in favor of static linking for cm3cg/m3cgc1 so that it is a standalone executable. Should be easy enough with gcc configure. On Apr 19, 2008, at 10:31 AM, Jay wrote:http://www.eyrie.org/~eagle/notes/rpath.html http://people.debian.org/~che/personal/rpath-considered-harmful but yet: http://www.scons.org/wiki/UsingOrigin So you can either colocate executables and .sos in the same directory or, like /cm3/bin /cm3/lib/m3core.so and vary the install root. We should be using this where available -- Linux, Solaris, Irix. Too bad not supported elsewhere. On Windows you can colocate; the .exe's directory is always searched. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Apr 19 17:34:38 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 19 Apr 2008 11:34:38 -0400 Subject: [M3devel] a hope for dynamic linking! In-Reply-To: References: Message-ID: Regular Modula-3 app stuff should build statically already, where it makes sense. build_standalone() achieves this. On some systems static libraries for certain system libraries are not available and cannot be assumed. We always build static Modula-3 libraries, so the current setup will link those statically even if other libraries are not available. For example, cm3 on I386_DARWIN gives: hosking$ otool -L /usr/local/cm3/bin/cm3 /usr/local/cm3/bin/cm3: /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) Notice that all the M3 libraries are static, but libgcc and friends are dynamic. So, I don't know what you are attempting to do. Did you try --disable- shared for m3cc configuration? On Apr 19, 2008, at 11:10 AM, Jay wrote: > (ok, actually I meant maybe for cm3cg but ok either way, there'd > only be one use of "/usr/local/cm3/bin/libgmp.so" so might as well > be static) > > > > > From: jayk123 at hotmail.com > To: hosking at cs.purdue.edu > Date: Sat, 19 Apr 2008 15:02:44 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] a hope for dynamic linking! > > I mean for the "regular" Modula-3 "app" stuff, not cm3cg. > > It looks like it is already static, good. > > 1) http://gcc.gnu.org/ml/gcc/2006-10/msg00141.html > > 2) The current code: > > m3-sys/m3cc/gcc/Makefile.in: > > configure-gmp: > ... > echo Configuring in $(HOST_SUBDIR)/gmp; \ > ... > $(HOST_CONFIGARGS) --build=${build_alias} --host=none-$ > {host_vendor}-${host_os} \ > --target=none-${host_vendor}-${host_os} $${srcdiroption} -- > disable-shared \ > || exit 1 > @endif gmp > > > configure-mpfr: > ... > echo Configuring in $(HOST_SUBDIR)/mpfr; \ > ... > $(HOST_CONFIGARGS) --build=${build_alias} --host=none-$ > {host_vendor}-${host_os} \ > --target=none-${host_vendor}-${host_os} $${srcdiroption} -- > disable-shared --with-gmp-build=$$r/$(HOST_SUBDIR)/gmp \ > || exit 1 > @endif mpfr > > > Let me test it and then I'll remove the Quake code related to this. > > > - Jay > > > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jayk123 at hotmail.com > Subject: Re: [M3devel] a hope for dynamic linking! > Date: Sat, 19 Apr 2008 10:50:04 -0400 > > Hold on! I am strongly in favor of static linking for cm3cg/m3cgc1 > so that it is a standalone executable. Should be easy enough with > gcc configure. > > On Apr 19, 2008, at 10:31 AM, Jay wrote: > http://www.eyrie.org/~eagle/notes/rpath.html > http://people.debian.org/~che/personal/rpath-considered-harmful > > > but yet: > > http://www.scons.org/wiki/UsingOrigin > > So you can either colocate executables and .sos in the same > directory or, like > /cm3/bin > /cm3/lib/m3core.so > > and vary the install root. > > We should be using this where available -- Linux, Solaris, Irix. > Too bad not supported elsewhere. > On Windows you can colocate; the .exe's directory is always searched. > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Apr 19 17:46:31 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Apr 2008 15:46:31 +0000 Subject: [M3devel] a hope for dynamic linking! In-Reply-To: References: Message-ID: I understand. But when dynamic linking is actually used, -rpath/$ORIGIN might be a little better than having to modify LD_LIBRARY_PATH. I realize it's not night and day. It doesn't make dynamic linking suddenly problem free, just maybe every so slightly better. When that still isn't adequate and diskspace/memory not a concern, or there are issues of circular dependencies (cm3), build_standalone. (I think cm3 is statically linked for subtle reasons I can't quite grasp at the moment. Not just so it can copy m3core.dll around while it is running, that could probably be dealt with less severely.) It looks like when gmp/mpfr source are in the gcc tree, it always does --disable-shared on them. I'm testing some now. libgcc seems to be a bit of a middle ground, like Modula3 stuff -- available both static and dynamic, and the need for dynamic varies. libgcc I believe contains roughly: 1) math helpers -- multiply/divide, 64 bit stuff 2) exception handling #1 is a case of kinda like, hey, I didn't make any function calls, why do I do need a .lib or .dll and no thank you on the dynamic linking headaches #2 is similar, but rather than "no function calls", it's using language constructs that actually have heavy dependencies, and if people want to throw/catch exceptions across linkage boundaries, the exception handling implementation might need to be shared building with the in-gcc-tree gmp/mpfr: gcc -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_STDARG=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SETLOCALE=1 -DHAVE_GETTIMEOFDAY=1 -DMPFR_HAVE_FESETROUND=1 -DHAVE_ROUND=1 -DHAVE_TRUNC=1 -DHAVE_FLOOR=1 -DHAVE_CEIL=1 -DHAVE_NEARBYINT=1 -DHAVE_ATTRIBUTE_MODE=1 -DHAVE_ALLOCA_H=1 -I. -I../../gcc/mpfr -I/dev2/cm3/m3-sys/m3cc/PPC_DARWIN/./gmp -I/dev2/cm3/m3-sys/m3cc/PPC_DARWIN/./gmp/tune -g -MT remquo.lo -MD -MP -MF .deps/remquo.Tpo -c ../../gcc/mpfr/remquo.c -o remquo.o ./get_patches.sh > get_patches.c || rm -f get_patches.c /bin/sh: line 1: ./get_patches.sh: No such file or directory if /bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_STDARG=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SETLOCALE=1 -DHAVE_GETTIMEOFDAY=1 -DMPFR_HAVE_FESETROUND=1 -DHAVE_ROUND=1 -DHAVE_TRUNC=1 -DHAVE_FLOOR=1 -DHAVE_CEIL=1 -DHAVE_NEARBYINT=1 -DHAVE_ATTRIBUTE_MODE=1 -DHAVE_ALLOCA_H=1 -I. -I../../gcc/mpfr -I/dev2/cm3/m3-sys/m3cc/PPC_DARWIN/./gmp -I/dev2/cm3/m3-sys/m3cc/PPC_DARWIN/./gmp/tune -g -MT get_patches.lo -MD -MP -MF ".deps/get_patches.Tpo" -c -o get_patches.lo get_patches.c; \ then mv -f ".deps/get_patches.Tpo" ".deps/get_patches.Plo"; else rm -f ".deps/get_patches.Tpo"; exit 1; fi gcc -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_STDARG=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SETLOCALE=1 -DHAVE_GETTIMEOFDAY=1 -DMPFR_HAVE_FESETROUND=1 -DHAVE_ROUND=1 -DHAVE_TRUNC=1 -DHAVE_FLOOR=1 -DHAVE_CEIL=1 -DHAVE_NEARBYINT=1 -DHAVE_ATTRIBUTE_MODE=1 -DHAVE_ALLOCA_H=1 -I. -I../../gcc/mpfr -I/dev2/cm3/m3-sys/m3cc/PPC_DARWIN/./gmp -I/dev2/cm3/m3-sys/m3cc/PPC_DARWIN/./gmp/tune -g -MT get_patches.lo -MD -MP -MF .deps/get_patches.Tpo -c get_patches.c -o get_patches.o powerpc-apple-darwin8-gcc-4.0.1: get_patches.c: No such file or directory I'll investigate. I was able to build them on another machine via apt-get source. Maybe you missed a file? I'll look.. - Jay CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jayk123 at hotmail.com Subject: Re: [M3devel] a hope for dynamic linking! Date: Sat, 19 Apr 2008 11:34:38 -0400 Regular Modula-3 app stuff should build statically already, where it makes sense. build_standalone() achieves this. On some systems static libraries for certain system libraries are not available and cannot be assumed. We always build static Modula-3 libraries, so the current setup will link those statically even if other libraries are not available. For example, cm3 on I386_DARWIN gives: hosking$ otool -L /usr/local/cm3/bin/cm3/usr/local/cm3/bin/cm3: /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) Notice that all the M3 libraries are static, but libgcc and friends are dynamic. So, I don't know what you are attempting to do. Did you try --disable-shared for m3cc configuration? On Apr 19, 2008, at 11:10 AM, Jay wrote:(ok, actually I meant maybe for cm3cg but ok either way, there'd only be one use of "/usr/local/cm3/bin/libgmp.so" so might as well be static) From: jayk123 at hotmail.com To: hosking at cs.purdue.edu Date: Sat, 19 Apr 2008 15:02:44 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] a hope for dynamic linking! I mean for the "regular" Modula-3 "app" stuff, not cm3cg. It looks like it is already static, good. 1) http://gcc.gnu.org/ml/gcc/2006-10/msg00141.html 2) The current code: m3-sys/m3cc/gcc/Makefile.in: configure-gmp: ... echo Configuring in $(HOST_SUBDIR)/gmp; \ ... $(HOST_CONFIGARGS) --build=${build_alias} --host=none-${host_vendor}-${host_os} \ --target=none-${host_vendor}-${host_os} $${srcdiroption} --disable-shared \ || exit 1 @endif gmp configure-mpfr: ... echo Configuring in $(HOST_SUBDIR)/mpfr; \ ... $(HOST_CONFIGARGS) --build=${build_alias} --host=none-${host_vendor}-${host_os} \ --target=none-${host_vendor}-${host_os} $${srcdiroption} --disable-shared --with-gmp-build=$$r/$(HOST_SUBDIR)/gmp \ || exit 1 @endif mpfr Let me test it and then I'll remove the Quake code related to this. - Jay CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jayk123 at hotmail.com Subject: Re: [M3devel] a hope for dynamic linking! Date: Sat, 19 Apr 2008 10:50:04 -0400 Hold on! I am strongly in favor of static linking for cm3cg/m3cgc1 so that it is a standalone executable. Should be easy enough with gcc configure. On Apr 19, 2008, at 10:31 AM, Jay wrote:http://www.eyrie.org/~eagle/notes/rpath.html http://people.debian.org/~che/personal/rpath-considered-harmful but yet: http://www.scons.org/wiki/UsingOrigin So you can either colocate executables and .sos in the same directory or, like /cm3/bin /cm3/lib/m3core.so and vary the install root. We should be using this where available -- Linux, Solaris, Irix. Too bad not supported elsewhere. On Windows you can colocate; the .exe's directory is always searched. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Apr 19 17:56:34 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Apr 2008 15:56:34 +0000 Subject: [M3devel] a hope for dynamic linking! In-Reply-To: References: Message-ID: sorry, that was with them symlinked in, from before the fix; maybe that's the problem I'll see. - Jay From: jayk123 at hotmail.com To: hosking at cs.purdue.edu Date: Sat, 19 Apr 2008 15:46:31 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] a hope for dynamic linking! I understand. But when dynamic linking is actually used, -rpath/$ORIGIN might be a little better than having to modify LD_LIBRARY_PATH. I realize it's not night and day. It doesn't make dynamic linking suddenly problem free, just maybe every so slightly better. When that still isn't adequate and diskspace/memory not a concern, or there are issues of circular dependencies (cm3), build_standalone. (I think cm3 is statically linked for subtle reasons I can't quite grasp at the moment. Not just so it can copy m3core.dll around while it is running, that could probably be dealt with less severely.) It looks like when gmp/mpfr source are in the gcc tree, it always does --disable-shared on them. I'm testing some now. libgcc seems to be a bit of a middle ground, like Modula3 stuff -- available both static and dynamic, and the need for dynamic varies. libgcc I believe contains roughly: 1) math helpers -- multiply/divide, 64 bit stuff 2) exception handling #1 is a case of kinda like, hey, I didn't make any function calls, why do I do need a .lib or .dll and no thank you on the dynamic linking headaches #2 is similar, but rather than "no function calls", it's using language constructs that actually have heavy dependencies, and if people want to throw/catch exceptions across linkage boundaries, the exception handling implementation might need to be shared building with the in-gcc-tree gmp/mpfr: gcc -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_STDARG=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SETLOCALE=1 -DHAVE_GETTIMEOFDAY=1 -DMPFR_HAVE_FESETROUND=1 -DHAVE_ROUND=1 -DHAVE_TRUNC=1 -DHAVE_FLOOR=1 -DHAVE_CEIL=1 -DHAVE_NEARBYINT=1 -DHAVE_ATTRIBUTE_MODE=1 -DHAVE_ALLOCA_H=1 -I. -I../../gcc/mpfr -I/dev2/cm3/m3-sys/m3cc/PPC_DARWIN/./gmp -I/dev2/cm3/m3-sys/m3cc/PPC_DARWIN/./gmp/tune -g -MT remquo.lo -MD -MP -MF .deps/remquo.Tpo -c ../../gcc/mpfr/remquo.c -o remquo.o ./get_patches.sh > get_patches.c || rm -f get_patches.c /bin/sh: line 1: ./get_patches.sh: No such file or directory if /bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_STDARG=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SETLOCALE=1 -DHAVE_GETTIMEOFDAY=1 -DMPFR_HAVE_FESETROUND=1 -DHAVE_ROUND=1 -DHAVE_TRUNC=1 -DHAVE_FLOOR=1 -DHAVE_CEIL=1 -DHAVE_NEARBYINT=1 -DHAVE_ATTRIBUTE_MODE=1 -DHAVE_ALLOCA_H=1 -I. -I../../gcc/mpfr -I/dev2/cm3/m3-sys/m3cc/PPC_DARWIN/./gmp -I/dev2/cm3/m3-sys/m3cc/PPC_DARWIN/./gmp/tune -g -MT get_patches.lo -MD -MP -MF ".deps/get_patches.Tpo" -c -o get_patches.lo get_patches.c; \ then mv -f ".deps/get_patches.Tpo" ".deps/get_patches.Plo"; else rm -f ".deps/get_patches.Tpo"; exit 1; fi gcc -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_STDARG=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SETLOCALE=1 -DHAVE_GETTIMEOFDAY=1 -DMPFR_HAVE_FESETROUND=1 -DHAVE_ROUND=1 -DHAVE_TRUNC=1 -DHAVE_FLOOR=1 -DHAVE_CEIL=1 -DHAVE_NEARBYINT=1 -DHAVE_ATTRIBUTE_MODE=1 -DHAVE_ALLOCA_H=1 -I. -I../../gcc/mpfr -I/dev2/cm3/m3-sys/m3cc/PPC_DARWIN/./gmp -I/dev2/cm3/m3-sys/m3cc/PPC_DARWIN/./gmp/tune -g -MT get_patches.lo -MD -MP -MF .deps/get_patches.Tpo -c get_patches.c -o get_patches.o powerpc-apple-darwin8-gcc-4.0.1: get_patches.c: No such file or directory I'll investigate. I was able to build them on another machine via apt-get source. Maybe you missed a file? I'll look.. - Jay CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jayk123 at hotmail.com Subject: Re: [M3devel] a hope for dynamic linking! Date: Sat, 19 Apr 2008 11:34:38 -0400 Regular Modula-3 app stuff should build statically already, where it makes sense. build_standalone() achieves this. On some systems static libraries for certain system libraries are not available and cannot be assumed. We always build static Modula-3 libraries, so the current setup will link those statically even if other libraries are not available. For example, cm3 on I386_DARWIN gives: hosking$ otool -L /usr/local/cm3/bin/cm3/usr/local/cm3/bin/cm3: /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) Notice that all the M3 libraries are static, but libgcc and friends are dynamic. So, I don't know what you are attempting to do. Did you try --disable-shared for m3cc configuration? On Apr 19, 2008, at 11:10 AM, Jay wrote:(ok, actually I meant maybe for cm3cg but ok either way, there'd only be one use of "/usr/local/cm3/bin/libgmp.so" so might as well be static) From: jayk123 at hotmail.com To: hosking at cs.purdue.edu Date: Sat, 19 Apr 2008 15:02:44 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] a hope for dynamic linking! I mean for the "regular" Modula-3 "app" stuff, not cm3cg. It looks like it is already static, good. 1) http://gcc.gnu.org/ml/gcc/2006-10/msg00141.html 2) The current code: m3-sys/m3cc/gcc/Makefile.in: configure-gmp: ... echo Configuring in $(HOST_SUBDIR)/gmp; \ ... $(HOST_CONFIGARGS) --build=${build_alias} --host=none-${host_vendor}-${host_os} \ --target=none-${host_vendor}-${host_os} $${srcdiroption} --disable-shared \ || exit 1 @endif gmp configure-mpfr: ... echo Configuring in $(HOST_SUBDIR)/mpfr; \ ... $(HOST_CONFIGARGS) --build=${build_alias} --host=none-${host_vendor}-${host_os} \ --target=none-${host_vendor}-${host_os} $${srcdiroption} --disable-shared --with-gmp-build=$$r/$(HOST_SUBDIR)/gmp \ || exit 1 @endif mpfr Let me test it and then I'll remove the Quake code related to this. - Jay CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jayk123 at hotmail.com Subject: Re: [M3devel] a hope for dynamic linking! Date: Sat, 19 Apr 2008 10:50:04 -0400 Hold on! I am strongly in favor of static linking for cm3cg/m3cgc1 so that it is a standalone executable. Should be easy enough with gcc configure. On Apr 19, 2008, at 10:31 AM, Jay wrote:http://www.eyrie.org/~eagle/notes/rpath.html http://people.debian.org/~che/personal/rpath-considered-harmful but yet: http://www.scons.org/wiki/UsingOrigin So you can either colocate executables and .sos in the same directory or, like /cm3/bin /cm3/lib/m3core.so and vary the install root. We should be using this where available -- Linux, Solaris, Irix. Too bad not supported elsewhere. On Windows you can colocate; the .exe's directory is always searched. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Apr 19 18:09:37 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 19 Apr 2008 12:09:37 -0400 Subject: [M3devel] a hope for dynamic linking! In-Reply-To: References: Message-ID: <1C5B9FD1-2B46-4C4E-9F21-A7CD1119C5F5@cs.purdue.edu> I just ran into this one myself. Looks like this version of mpfr doesn't play totally nicely with building within gcc. I've commented out the following lines in mpfr/Makefile.in which appear to do the trick. If so, then I will commit it... get_patches.c: PATCHES get_patches.sh ./get_patches.sh > $@ || rm -f $@ On Apr 19, 2008, at 11:46 AM, Jay wrote: > building with the in-gcc-tree gmp/mpfr: > > gcc -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DTIME_WITH_SYS_TIME=1 - > DHAVE_STDARG=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SETLOCALE=1 - > DHAVE_GETTIMEOFDAY=1 -DMPFR_HAVE_FESETROUND=1 -DHAVE_ROUND=1 - > DHAVE_TRUNC=1 -DHAVE_FLOOR=1 -DHAVE_CEIL=1 -DHAVE_NEARBYINT=1 - > DHAVE_ATTRIBUTE_MODE=1 -DHAVE_ALLOCA_H=1 -I. -I../../gcc/mpfr -I/ > dev2/cm3/m3-sys/m3cc/PPC_DARWIN/./gmp -I/dev2/cm3/m3-sys/m3cc/ > PPC_DARWIN/./gmp/tune -g -MT remquo.lo -MD -MP -MF .deps/remquo.Tpo - > c ../../gcc/mpfr/remquo.c -o remquo.o > ./get_patches.sh > get_patches.c || rm -f get_patches.c > /bin/sh: line 1: ./get_patches.sh: No such file or directory > if /bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_INTTYPES_H=1 > -DHAVE_STDINT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_STDARG=1 - > DHAVE_SYS_TIME_H=1 -DHAVE_SETLOCALE=1 -DHAVE_GETTIMEOFDAY=1 - > DMPFR_HAVE_FESETROUND=1 -DHAVE_ROUND=1 -DHAVE_TRUNC=1 -DHAVE_FLOOR=1 > -DHAVE_CEIL=1 -DHAVE_NEARBYINT=1 -DHAVE_ATTRIBUTE_MODE=1 - > DHAVE_ALLOCA_H=1 -I. -I../../gcc/mpfr -I/dev2/cm3/m3-sys/m3cc/ > PPC_DARWIN/./gmp -I/dev2/cm3/m3-sys/m3cc/PPC_DARWIN/./gmp/tune -g - > MT get_patches.lo -MD -MP -MF ".deps/get_patches.Tpo" -c -o > get_patches.lo get_patches.c; \ > then mv -f ".deps/get_patches.Tpo" ".deps/get_patches.Plo"; else rm - > f ".deps/get_patches.Tpo"; exit 1; fi > gcc -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DTIME_WITH_SYS_TIME=1 - > DHAVE_STDARG=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SETLOCALE=1 - > DHAVE_GETTIMEOFDAY=1 -DMPFR_HAVE_FESETROUND=1 -DHAVE_ROUND=1 - > DHAVE_TRUNC=1 -DHAVE_FLOOR=1 -DHAVE_CEIL=1 -DHAVE_NEARBYINT=1 - > DHAVE_ATTRIBUTE_MODE=1 -DHAVE_ALLOCA_H=1 -I. -I../../gcc/mpfr -I/ > dev2/cm3/m3-sys/m3cc/PPC_DARWIN/./gmp -I/dev2/cm3/m3-sys/m3cc/ > PPC_DARWIN/./gmp/tune -g -MT get_patches.lo -MD -MP -MF .deps/ > get_patches.Tpo -c get_patches.c -o get_patches.o > powerpc-apple-darwin8-gcc-4.0.1: get_patches.c: No such file or > directory -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Apr 19 22:06:43 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 19 Apr 2008 22:06:43 +0200 Subject: [M3devel] new gcc configure and setup In-Reply-To: References: <20080419113533.zi4vqsvxs0ocgs4c@mail.elegosoft.com> <3E4BBF85-989B-4649-AC7D-20E82610940B@cs.purdue.edu> <2A490CE3-D906-4795-B7A8-5928276CA2FD@cs.purdue.edu> Message-ID: <20080419220643.d9sfh9gx8kggkw8g@mail.elegosoft.com> I manually started a build on new.elego.de some hours ago, which succeeded; everything seems to build again now, thanks to you both! And we have the base for X64 support in CM3, which is a great step forward! Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Sun Apr 20 05:56:15 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 20 Apr 2008 03:56:15 +0000 Subject: [M3devel] moving versions into simple text file (sh?) Message-ID: I'd like to (finally) move the default versions out into a simple file. Given: jbook15:/dev2/cm3/scripts jay$ cat version CM3VERSION d5.7.0 CM3VERSIONNUM 050700 CM3LASTCHANGED 2008-03-16 Is there any chance this is Posix/Solaris compliant? get_version() { if [ -n "$(eval echo \$$1)" ] ; then return fi eval "$1=\"$(echo $(grep "$1 " $root/scripts/version | awk '{print $2}'))\"" } get_version CM3VERSION get_version CM3VERSIONNUM get_version CM3LASTCHANGED echo "CM3VERSION is $CM3VERSION" echo "CM3VERSIONNUM is $CM3VERSIONNUM" echo "CM3LASTCHANGED is $CM3LASTCHANGED" It works on my Mac. This is not what I would have expected, in particular the need for eval and echo seems strange. The quoting is all unfortunate as usual too. If this isn't standard, then how about just the last line: get_version() { eval "$1=\"$(echo $(grep "$1 " $root/scripts/version | awk '{print $2}'))\"" } ? Otherwise, I guess dumb it down and be repetitive, like: CM3VERSION=${CM3VERSION-`grep "CM3VERSION " $root/scripts/version | awk '{print $2}'))`} ? I didn't want to repeat the variable names three times each. What I really want is to append version to PKGS and regenerate PKGS whenever its lines aren't all there, so as to trigger an automatic rebuild of PKGS when the version changes. One more application of the version numbers, and I was pushed to fix them. Full diff: Index: sysinfo.sh =================================================================== RCS file: /usr/cvs/cm3/scripts/sysinfo.sh,v retrieving revision 1.61 diff -c -r1.61 sysinfo.sh *** sysinfo.sh 15 Apr 2008 06:51:31 -0000 1.61 --- sysinfo.sh 20 Apr 2008 03:48:13 -0000 *************** *** 10,38 **** PRJ_ROOT=${PRJ_ROOT:-${HOME}/work} - #----------------------------------------------------------------------------- - # set some defaults # ! # These three lines must be carefully formed as they are parsed by other code. # ! # For cmd: ! # They must start with a name and an equals sign. ! # They must contain one and only one colon. ! # They must contain one and only one equals sign. ! # The content to the right of the colon, minus the first two ! # and last two characters, is the value. # ! # For Python, we have much more flexibility. Currently the code ! # looks for fairly precisely A=${A:-"value"}, but this can be easily ! # relaxed or changed. # ! # Refer to scripts/win/sysinfo.cmd and scripts/python/lib.py. ! # Specifically look for "DefaultsFromSh". # CM3VERSION=${CM3VERSION:-"d5.7.0"} CM3VERSIONNUM=${CM3VERSIONNUM:-"050700"} CM3LASTCHANGED=${CM3LASTCHANGED:-"2008-03-16"} CM3_GCC_BACKEND=yes CM3_GDB=no # --- 10,49 ---- PRJ_ROOT=${PRJ_ROOT:-${HOME}/work} # ! # Allow direct invocation of sysinfo.sh for testing purposes. # ! if [ -z "$root" -o ! -d "$root" ] ; then ! root=`pwd` ! while [ -n "$root" -a ! -f "$root/scripts/sysinfo.sh" ] ; do ! root=`dirname $root` ! done ! fi ! ! #----------------------------------------------------------------------------- ! # set some defaults # ! ! get_version() { ! if [ -n "$(eval echo \$$1)" ] ; then ! return ! fi ! eval "$1=\"$(echo $(grep "$1 " $root/scripts/version | awk '{print $2}'))\"" ! } ! ! get_version CM3VERSION ! get_version CM3VERSIONNUM ! get_version CM3LASTCHANGED ! # ! # Leave these lines in TEMPORARILY for compat with cmd, Python, Quake. # CM3VERSION=${CM3VERSION:-"d5.7.0"} CM3VERSIONNUM=${CM3VERSIONNUM:-"050700"} CM3LASTCHANGED=${CM3LASTCHANGED:-"2008-03-16"} + CM3_INSTALL=${CM3_INSTALL:-`dirname \`find_exe cm3 /usr/local/cm3/\ \``} + CM3_GCC_BACKEND=yes CM3_GDB=no # - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.illig at gmx.de Sun Apr 20 09:58:28 2008 From: roland.illig at gmx.de (Roland Illig) Date: Sun, 20 Apr 2008 08:58:28 +0100 Subject: [M3devel] moving versions into simple text file (sh?) In-Reply-To: References: Message-ID: <480AF7A4.4060905@gmx.de> Jay schrieb: > I'd like to (finally) move the default versions out into a simple file. > > Given: > > jbook15:/dev2/cm3/scripts jay$ cat version > CM3VERSION d5.7.0 > CM3VERSIONNUM 050700 > CM3LASTCHANGED 2008-03-16 > > Is there any chance this is Posix/Solaris compliant? > > get_version() { > if [ -n "$(eval echo \$$1)" ] ; then > return > fi > eval "$1=\"$(echo $(grep "$1 " $root/scripts/version | awk '{print > $2}'))\"" > } Solaris' /bin/sh doesn't know the $(...) operator. Why do you need "eval echo" at all? Better use this: # usage: get_version VARNAME get_version() { eval "gv__set=\${$1+set}" if [ "$gv__set" != "set" ]; then gv__value=`awk '$1 == "'"$1"'" { print $2 }' $root/scripts/version` eval "$1=\$gv__value" fi } $ /bin/sh $ . ./get_version.sh $ set -x $ get_version CM3VERSION + get_version CM3VERSION + eval __set=${CM3VERSION+set} __set= + [ != set ] + awk $1 == "CM3VERSION" { print $2 } version value=d5.7.0 + eval CM3VERSION=$value CM3VERSION=d5.7.0 $ get_version CM3VERSION + get_version CM3VERSION + eval __set=${CM3VERSION+set} __set=set + [ set != set ] Roland From roland.illig at gmx.de Sun Apr 20 10:05:25 2008 From: roland.illig at gmx.de (Roland Illig) Date: Sun, 20 Apr 2008 09:05:25 +0100 Subject: [M3devel] moving versions into simple text file (sh?) In-Reply-To: <480AF7A4.4060905@gmx.de> References: <480AF7A4.4060905@gmx.de> Message-ID: <480AF945.40602@gmx.de> Roland Illig schrieb: > Jay schrieb: >> I'd like to (finally) move the default versions out into a simple file. >> >> Given: >> >> jbook15:/dev2/cm3/scripts jay$ cat version >> CM3VERSION d5.7.0 >> CM3VERSIONNUM 050700 >> CM3LASTCHANGED 2008-03-16 or maybe this, which is even easier: $ eval "`sed 's, ,=,' $root/scripts/version`" Roland From jayk123 at hotmail.com Sun Apr 20 16:26:34 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 20 Apr 2008 14:26:34 +0000 Subject: [M3devel] moving versions into simple text file (sh?) In-Reply-To: <480AF945.40602@gmx.de> References: <480AF7A4.4060905@gmx.de> <480AF945.40602@gmx.de> Message-ID: Right -- turning it into executable code is tempting, however what you show isn't quite the whole story. Perhaps if the sed sticks default_ on the front or something. How about: > $ eval "`awk < $root/scripts/version '{print default_$1=$2}'`" FOO=${FOO:$default_FOO} BAR=${FOO:$default_BAR} So then I am back to repeating every variable name three times, but hey at least I only run awk/sed once instead of three times. :) I will try something like that. The other code you shows was not understandable to me, alas. I wasn't going to use $( ), but it does seem to be posix and nested ` bit me before. So I've been reading about bash vs. sh vs. dash, and autoconfigure..and I learn that Solaris sh is pre-Posix and not conformant. That /bin/sh isn't even where you get Posix sh from, according to Posix. I am more and more convinced that the way to go "here" (not actually "here", not Modula-3 related, but GNU/Unix related) is a really small "portable" "thingy" that is used only to bootstrap the next level up which would be much richer. For example, a decent non-extensible single-threaded scripting language written in one large C file, that only used like stdio and/or open/read/write.. Then the "configure" script is really small: configure-unix #!/bin/sh cc foo.c -o foo if ! -f foo then echo "C compilation failed, please see $0" exit 1 end ./foo $0 And then write the rest in C, but the "script" can contain some "scripting language" for the C to interpret from there. Write the above in .cmd/.bat and the VMS language and done. Add some probes for the compiler name, cl, bcc, icc, dmc, etc. I mean, all the gnarly workarounds in autoconf output, heck, can't bash be distilled down to a small portable useful base, that doesn't need configuring, and just use it without workarounds? I just don't see much value in all the layers.. or I'm too lazy to keep learning more and more and more similar stuff full of history and cruft.... - Jay ---------------------------------------- > Date: Sun, 20 Apr 2008 09:05:25 +0100 > From: roland.illig at gmx.de > To: m3devel at elegosoft.com > Subject: Re: [M3devel] moving versions into simple text file (sh?) > > Roland Illig schrieb: >> Jay schrieb: >>> I'd like to (finally) move the default versions out into a simple file. >>> >>> Given: >>> >>> jbook15:/dev2/cm3/scripts jay$ cat version >>> CM3VERSION d5.7.0 >>> CM3VERSIONNUM 050700 >>> CM3LASTCHANGED 2008-03-16 > > or maybe this, which is even easier: > > $ eval "`sed 's, ,=,' $root/scripts/version`" > > Roland From hosking at cs.purdue.edu Mon Apr 21 00:52:51 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 20 Apr 2008 18:52:51 -0400 Subject: [M3devel] Update on cm3cg for x86_64 Linux Message-ID: <7281A261-2AC4-46CA-938C-785C1C4D1EE1@cs.purdue.edu> It seems there is an incompatibility between cm3cg built using default gcc (not -m32) on x86_64 Linux and the CM3 front-end targeting 32-bit LINUXLIBC6. I get errors in the gcc-based backend code if I build it without -m32 using it to compile M3IR. Looks like some problem with LONGREAL alignment. If I build using -m32 then cm3cg works just fine on x86_64. Anyway, something to watch out for. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Apr 22 01:15:05 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Apr 2008 23:15:05 +0000 Subject: [M3devel] more path stuff, sorry Message-ID: Maybe this is dubious. The question is, like, should native NT386 cm3 accept /cygdrive/c/foo and translate to c:\foo?Or trickier, /usr/bin/foo and translate to c:\cygwin\usr\bin\foo?And vice versa, should NT386GNU accept c:\foo? The translation is not simple in general./ maps to the Cygwin install root.There can be symlinks.But many common cases can be handled with little, simple code.It's already in. Ultimately the way to do this correctly is to link to cygwin1.dll, which is only done sometimes, and which probably license-undesirable when not done. As well, a path like /foo is actually ambiguous.It is a valid native Win32 path, equivalent to \foo.Or it could be Cygwin path requivalent to c:\cygwin\foo. While it is nice to keep cm3 simple, it is also nice to have a more uniform interfaceacross hosts, I think. Maybe. To some extent a user can do this himself.That is, NTFS junctions and/or Cygwin symblinks can cause their to be identical pathswith identical meanings: e.g. for me, symlink /msdev => c:\msdev, /cm3 => c:\cm3 /dev => c:\dev2 In some places Cygwin open et. al. accept Win32 paths, but lately taking advantage ofthat issues a warning. In some places, I think, it isn't sufficient to have Cygwin handle it. The harder question then is, if I feed Cygwin paths of a particular form, should ittry to report back paths in the same form? I put some code in M3Path.m3 "like this", but it may not be advisable. I also had an NTFS junction on my system so Win32 /cygdrive/c => c:\, but this causesa circularity in the file system, which I'd rather not have. As well, there are at least three or four Posix runtimes for Windows, and they each mapdifferently. UWin I think uses /c <=> c:\.Cygwin /cygdrive <=> c:\Interix/ServicesForUnix/SUA I think something via /dev.MinGWin also has a runtime that I think uses the UWin mapping, but this runtime is onlymeant for sh/gcc to use, not user apps. Having special code that only knows the Cygwin convention is questionable. I was often setting up some environment variables one way or the other, and thenrunning one cm3 or the other, without thinking about which form the variables were in.Indeed, it might be nice to set CM3_ROOT and CM3_INSTALL "once and for all", while still switching between different forms of cm3.exe?Though granted, CM3_INSTALL cm3.exe can usually figure out from its own path, andCM3_ROOT could usually be figured out by looking at the CVS directories in the currentworking directory, not always, but often. Basically, instead of setting these variblesone way or the other, I'd like to set them always one way, or even not at all. Hm, in fact, I think cm3 could figure out all overrides itself? You know, if there is a shipped package store, it can use that to determine the source <=> pkg mapping. And it can figure out CM3_ROOT by looking at the current directory and on up until the CVS/Root changes? As well, you know, the source <=> pkg mapping could be a simple generated checked in file. You know, like the PKGS file, but stripped down to only what is needed? Maybe just remove the code I put in and forget the whole thing.Maybe most people only ever stay in one of the worlds and "translation" isn't important? Just me stuck with providing support for both and therefore living with both more? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Apr 22 03:44:17 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 21 Apr 2008 21:44:17 -0400 Subject: [M3devel] more path stuff, sorry In-Reply-To: References: Message-ID: Why would native NT386 know anything at all about Cygwin. I say just avoid split personalities like the plague. Similarly, I'd be happy for NT386GNU (i.e., Cygwin?) to simply behave like a POSIX build (modulo native threads perhaps). On Apr 21, 2008, at 7:15 PM, Jay wrote: > Maybe this is dubious. > > The question is, like, should native NT386 cm3 accept /cygdrive/c/ > foo and translate to c:\foo? > Or trickier, /usr/bin/foo and translate to c:\cygwin\usr\bin\foo? > And vice versa, should NT386GNU accept c:\foo? > > The translation is not simple in general. > / maps to the Cygwin install root. > There can be symlinks. > But many common cases can be handled with little, simple code. > It's already in. > > Ultimately the way to do this correctly is to link to cygwin1.dll, > which is only done sometimes, > and which probably license-undesirable when not done. > > As well, a path like /foo is actually ambiguous. > It is a valid native Win32 path, equivalent to \foo. > Or it could be Cygwin path requivalent to c:\cygwin\foo. > > While it is nice to keep cm3 simple, it is also nice to have a more > uniform interface > across hosts, I think. Maybe. > > To some extent a user can do this himself. > That is, NTFS junctions and/or Cygwin symblinks can cause their to > be identical paths > with identical meanings: > e.g. for me, symlink /msdev => c:\msdev, /cm3 => c:\cm3 /dev => c: > \dev2 > > In some places Cygwin open et. al. accept Win32 paths, but lately > taking advantage of > that issues a warning. In some places, I think, it isn't sufficient > to have Cygwin handle it. > > The harder question then is, if I feed Cygwin paths of a particular > form, should it > try to report back paths in the same form? > > I put some code in M3Path.m3 "like this", but it may not be advisable. > > I also had an NTFS junction on my system so Win32 /cygdrive/c => c: > \, but this causes > a circularity in the file system, which I'd rather not have. > > As well, there are at least three or four Posix runtimes for > Windows, and they each map > differently. > > UWin I think uses /c <=> c:\. > Cygwin /cygdrive <=> c:\ > Interix/ServicesForUnix/SUA I think something via /dev. > MinGWin also has a runtime that I think uses the UWin mapping, but > this runtime is only > meant for sh/gcc to use, not user apps. > > Having special code that only knows the Cygwin convention is > questionable. > > I was often setting up some environment variables one way or the > other, and then > running one cm3 or the other, without thinking about which form the > variables were in. > Indeed, it might be nice to set CM3_ROOT and CM3_INSTALL "once and > for all", > while still switching between different forms of cm3.exe? > Though granted, CM3_INSTALL cm3.exe can usually figure out from its > own path, and > CM3_ROOT could usually be figured out by looking at the CVS > directories in the current > working directory, not always, but often. Basically, instead of > setting these varibles > one way or the other, I'd like to set them always one way, or even > not at all. > > > Hm, in fact, I think cm3 could figure out all overrides itself? > You know, if there is a shipped package store, it can use that to > determine the source <=> pkg mapping. > And it can figure out CM3_ROOT by looking at the current directory > and on up until the CVS/Root > changes? > > As well, you know, the source <=> pkg mapping could be a simple > generated checked in file. > You know, like the PKGS file, but stripped down to only what is > needed? > > Maybe just remove the code I put in and forget the whole thing. > Maybe most people only ever stay in one of the worlds and > "translation" isn't important? > Just me stuck with providing support for both and therefore living > with both more? > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Apr 22 04:21:38 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 22 Apr 2008 02:21:38 +0000 Subject: [M3devel] more path stuff, sorry In-Reply-To: References: Message-ID: The split personality has to be somewhere -- either in the user of both or in the code. But maybe there are no users of both. :) Ok, they are it. I'll remove the code, and see how my experience fairs, and try to keep the results to myself. :) > Why would native NT386 know anything at all about Cygwin It depends on why someone choses the one cm3 or the other. If a user "likes Unix" but finds gcc too slow, he might be passing Cygwin paths to the native compiler. If a user "likes Windows" but really wants 64 bit integers right now, he might be inclined to pass Win32 paths to the Cygwin compiler. Granted, the second user could also use NT386MINGNU (__stdcall still broken, I should be able to fix or workaround.) As well, um, the first user could make up a configurationi that suites actually. That is, the choice of backend and the choice "what runtime cm3 uses" are two independent variables.I am answering my question though -- all four combinations should work, and three of them even have names. Mostly user doesn't care "what runtime in use", but user could easily care about the command lines accepted. And, you know, accepting different path forms..doesn't really require cygwin. If the inputs are human generated, he/she can probably live with c:/foo, or /c/foo and make a junction -- c:\c\foo => c:\foo. Oh that second one is a new idea to me actually. I should type that up -- "Windows paths for people that like forward slashes". Again, I know I'm a broken record, but it comes down to what someone wants in "NT386GNU". And the host and target are independently configurable, mostly, maybe -- NT386 can output NT386GNU and vice versa. User might like backward slashes but need to produce code that works in a more Posixish environment. This is like a cross build, except both targets run on the same OS. It probably just comes down what we have -- the two or three canned config files, and someone that wants to mix and match differently can do so. The toplevel NT386/NT386GNU/NT386MINGNU are small thin easily rewritten wrappers over NT386.common anyway. User can provide his own. At some hypothetical point, that will probably never arrive, config files should be tried out for Borland, Watcom, Digital Mars, and ideally, they follow this same pattern -- managing to get by with no compiler change and no new target, just a config file, possibly growing the jmpbuf to the largest of them, if that isn't too large. Actually the compiler doesn't do this correctly. I think it assumes the external backend targets one jumpbuf size and integrated one another. This should either be a dangerous integer directly set in the config file, or keyed off the "CRuntime" parameter there, values like MS, GNU, WATCOM, MWERKS, DMARS. It could be more configuration knobs make sense, since Windows compilers tend to have so many switches, the M3 compiler might have to know more stuff, to interoperate. Anyway..I'm skeptical these targets/configs would have any customers..on to other stuff for now. :) This reminds me of maybe a more important problem -- discerning host and target, I'll start a separate thread. - Jay CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] more path stuff, sorryDate: Mon, 21 Apr 2008 21:44:17 -0400 Why would native NT386 know anything at all about Cygwin. I say just avoid split personalities like the plague. Similarly, I'd be happy for NT386GNU (i.e., Cygwin?) to simply behave like a POSIX build (modulo native threads perhaps). On Apr 21, 2008, at 7:15 PM, Jay wrote: Maybe this is dubious.The question is, like, should native NT386 cm3 accept /cygdrive/c/foo and translate to c:\foo?Or trickier, /usr/bin/foo and translate to c:\cygwin\usr\bin\foo?And vice versa, should NT386GNU accept c:\foo?The translation is not simple in general./ maps to the Cygwin install root.There can be symlinks.But many common cases can be handled with little, simple code.It's already in.Ultimately the way to do this correctly is to link to cygwin1.dll, which is only done sometimes, and which probably license-undesirable when not done.As well, a path like /foo is actually ambiguous.It is a valid native Win32 path, equivalent to \foo.Or it could be Cygwin path requivalent to c:\cygwin\foo.While it is nice to keep cm3 simple, it is also nice to have a more uniform interfaceacross hosts, I think. Maybe.To some extent a user can do this himself.That is, NTFS junctions and/or Cygwin symblinks can cause their to be identical pathswith identical meanings:e.g. for me, symlink /msdev => c:\msdev, /cm3 => c:\cm3 /dev => c:\dev2In some places Cygwin open et. al. accept Win32 paths, but lately taking advantage ofthat issues a warning. In some places, I think, it isn't sufficient to have Cygwin handle it.The harder question then is, if I feed Cygwin paths of a particular form, should ittry to report back paths in the same form?I put some code in M3Path.m3 "like this", but it may not be advisable.I also had an NTFS junction on my system so Win32 /cygdrive/c => c:\, but this causesa circularity in the file system, which I'd rather not have.As well, there are at least three or four Posix runtimes for Windows, and they each mapdifferently.UWin I think uses /c <=> c:\.Cygwin /cygdrive <=> c:\Interix/ServicesForUnix/SUA I think something via /dev.MinGWin also has a runtime that I think uses the UWin mapping, but this runtime is onlymeant for sh/gcc to use, not user apps.Having special code that only knows the Cygwin convention is questionable. I was often setting up some environment variables one way or the other, and thenrunning one cm3 or the other, without thinking about which form the variables were in.Indeed, it might be nice to set CM3_ROOT and CM3_INSTALL "once and for all",while still switching between different forms of cm3.exe?Though granted, CM3_INSTALL cm3.exe can usually figure out from its own path, andCM3_ROOT could usually be figured out by looking at the CVS directories in the currentworking directory, not always, but often. Basically, instead of setting these variblesone way or the other, I'd like to set them always one way, or even not at all.Hm, in fact, I think cm3 could figure out all overrides itself?You know, if there is a shipped package store, it can use that to determine the source <=> pkg mapping.And it can figure out CM3_ROOT by looking at the current directory and on up until the CVS/Rootchanges? As well, you know, the source <=> pkg mapping could be a simple generated checked in file.You know, like the PKGS file, but stripped down to only what is needed? Maybe just remove the code I put in and forget the whole thing.Maybe most people only ever stay in one of the worlds and "translation" isn't important?Just me stuck with providing support for both and therefore living with both more? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Apr 22 04:36:42 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 22 Apr 2008 02:36:42 +0000 Subject: [M3devel] host vs. target and host_ostype exposed to quake? In-Reply-To: References: Message-ID: I found Compiler.i3 recently.I had been writing Quake code like: if equal ($OS, "Windows_NT") and: if equal (SL, "/") I propose that the data in Compiler.i3 be exposed to Quake with variable names something like: HOST -- ALPHA_OSF, NT386, LINUXLIBC6, AMD64_DARWIN, etc. HOST_OSTYPE -- POSIX, WIN32 /maybe/ booleans thereof: HOST_IS_POSIX HOST_IS_WIN32 and /possibly/ others: HOST_GNU_PLATFORM -- maybe needed, maybe not -- currently m3makefile maps from HOST, and the config files have unused declarations for the target. HOST_WORDSIZE -- shouldn't be relevant I /speculate/ as well that the following should be introduced: TARGET_ARCHITECTURE -- AMD64, I386, PPC (Compiler.i3 already separates this out) HOST_ARCHITECTURE TARGET_OS -- SOLARIS (SOL?), NT, DARWIN (MACOSX? Too late.), LINUX, OSF, VMS, HPUX, FREEBSD, OPENBSD, NETBSD (FBSD, OBSD, NBSD?) HOST_OS And then, /maybe/ ultimately, the full calculus I have described: TARGET_C_LIBRARY -- native, cygwin, ms (multiple versions?) TARGET_C_COMPILER -- gnu, sun, ms, dmars, mwerks, borland, watcom, darwin TARGET_C_LINKER -- similar to previous TARGET_WINDOW_LIBRARY -- xwin, mswin TARGET_THREAD_LIBRARY -- pthreads, alarmthreads, nt or at least just the very first two: HOST -- ALPHA_OSF, NT386, LINUXLIBC6, AMD64_DARWIN, etc. HOST_OSTYPE -- POSIX, WIN32 This is super easy, like two lines of code in m3quake to expose the data in Compiler.i3. Also, related, all the places that check Pathname.Join(a, b) == a/b or Epoch = 0, should use Compiler.OSType instead, or whatever it is. I'd have to check if Compiler.i3 puts anything in the .i3 vs. the .m3, if in the .m3, that could be slower, but easily fixed too. Oh, and maybe cm3 --print-var HOST. gcc has all those useful --print flags. Thus, all the uname stuff in sysinfo could go away, you just default to what the compiler runs on. You'd override it for cross builds with -D on the command line or a config file as usual (ie: the Quake variable would lose its read-onlyness, possibly taking on a new special form of "write-once"). One downside is that, as written, the config files are more readable and self-documenting by starting with the important settings up front. Whatever is buried in cm3 is more hidden from users, good and bad. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Tue Apr 22 05:09:39 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 21 Apr 2008 23:09:39 -0400 Subject: [M3devel] more path stuff, sorry In-Reply-To: References: Message-ID: <480D1EAD.1E75.00D7.1@scires.com> I think I've made my opinion on the path issue known, but just so there is no doubt, I do not want the underlying code trying to translate paths from one format to another. I think this is a recipe for problems since different OS represent paths and switches etc differently. Programmers should use the standard interfaces to construct paths appropriate for the current host operating system. Part of the beauty of Modula-3 is write once run everywhere. I have code that uses pathnames that runs on multiple platforms without the need to make any source code modifications. Regards, Randy >>> Jay 4/21/2008 7:15 PM >>> Maybe this is dubious. The question is, like, should native NT386 cm3 accept /cygdrive/c/foo and translate to c:\foo? Or trickier, /usr/bin/foo and translate to c:\cygwin\usr\bin\foo? And vice versa, should NT386GNU accept c:\foo? The translation is not simple in general. / maps to the Cygwin install root. There can be symlinks. But many common cases can be handled with little, simple code. It's already in. Ultimately the way to do this correctly is to link to cygwin1.dll, which is only done sometimes, and which probably license-undesirable when not done. As well, a path like /foo is actually ambiguous. It is a valid native Win32 path, equivalent to \foo. Or it could be Cygwin path requivalent to c:\cygwin\foo. While it is nice to keep cm3 simple, it is also nice to have a more uniform interface across hosts, I think. Maybe. To some extent a user can do this himself. That is, NTFS junctions and/or Cygwin symblinks can cause their to be identical paths with identical meanings: e.g. for me, symlink /msdev => c:\msdev, /cm3 => c:\cm3 /dev => c:\dev2 In some places Cygwin open et. al. accept Win32 paths, but lately taking advantage of that issues a warning. In some places, I think, it isn't sufficient to have Cygwin handle it. The harder question then is, if I feed Cygwin paths of a particular form, should it try to report back paths in the same form? I put some code in M3Path.m3 "like this", but it may not be advisable. I also had an NTFS junction on my system so Win32 /cygdrive/c => c:\, but this causes a circularity in the file system, which I'd rather not have. As well, there are at least three or four Posix runtimes for Windows, and they each map differently. UWin I think uses /c <=> c:\. Cygwin /cygdrive <=> c:\ Interix/ServicesForUnix/SUA I think something via /dev. MinGWin also has a runtime that I think uses the UWin mapping, but this runtime is only meant for sh/gcc to use, not user apps. Having special code that only knows the Cygwin convention is questionable. I was often setting up some environment variables one way or the other, and then running one cm3 or the other, without thinking about which form the variables were in. Indeed, it might be nice to set CM3_ROOT and CM3_INSTALL "once and for all", while still switching between different forms of cm3.exe? Though granted, CM3_INSTALL cm3.exe can usually figure out from its own path, and CM3_ROOT could usually be figured out by looking at the CVS directories in the current working directory, not always, but often. Basically, instead of setting these varibles one way or the other, I'd like to set them always one way, or even not at all. Hm, in fact, I think cm3 could figure out all overrides itself? You know, if there is a shipped package store, it can use that to determine the source <=> pkg mapping. And it can figure out CM3_ROOT by looking at the current directory and on up until the CVS/Root changes? As well, you know, the source <=> pkg mapping could be a simple generated checked in file. You know, like the PKGS file, but stripped down to only what is needed? Maybe just remove the code I put in and forget the whole thing. Maybe most people only ever stay in one of the worlds and "translation" isn't important? Just me stuck with providing support for both and therefore living with both more? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Tue Apr 22 05:14:00 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 21 Apr 2008 23:14:00 -0400 Subject: [M3devel] more path stuff, sorry In-Reply-To: References: Message-ID: <480D1FB2.1E75.00D7.1@scires.com> I concur wholeheartedly. I absolutely DO NOT want native NT386 to have any knowledge of or dependency on Cygwin. Regards, Randy >>> Tony Hosking 4/21/2008 9:44 PM >>> Why would native NT386 know anything at all about Cygwin. I say just avoid split personalities like the plague. Similarly, I'd be happy for NT386GNU (i.e., Cygwin?) to simply behave like a POSIX build (modulo native threads perhaps). On Apr 21, 2008, at 7:15 PM, Jay wrote: Maybe this is dubious. The question is, like, should native NT386 cm3 accept /cygdrive/c/foo and translate to c:\foo? Or trickier, /usr/bin/foo and translate to c:\cygwin\usr\bin\foo? And vice versa, should NT386GNU accept c:\foo? The translation is not simple in general. / maps to the Cygwin install root. There can be symlinks. But many common cases can be handled with little, simple code. It's already in. Ultimately the way to do this correctly is to link to cygwin1.dll, which is only done sometimes, and which probably license-undesirable when not done. As well, a path like /foo is actually ambiguous. It is a valid native Win32 path, equivalent to \foo. Or it could be Cygwin path requivalent to c:\cygwin\foo. While it is nice to keep cm3 simple, it is also nice to have a more uniform interface across hosts, I think. Maybe. To some extent a user can do this himself. That is, NTFS junctions and/or Cygwin symblinks can cause their to be identical paths with identical meanings: e.g. for me, symlink /msdev => c:\msdev, /cm3 => c:\cm3 /dev => c:\dev2 In some places Cygwin open et. al. accept Win32 paths, but lately taking advantage of that issues a warning. In some places, I think, it isn't sufficient to have Cygwin handle it. The harder question then is, if I feed Cygwin paths of a particular form, should it try to report back paths in the same form? I put some code in M3Path.m3 "like this", but it may not be advisable. I also had an NTFS junction on my system so Win32 /cygdrive/c => c:\, but this causes a circularity in the file system, which I'd rather not have. As well, there are at least three or four Posix runtimes for Windows, and they each map differently. UWin I think uses /c <=> c:\. Cygwin /cygdrive <=> c:\ Interix/ServicesForUnix/SUA I think something via /dev. MinGWin also has a runtime that I think uses the UWin mapping, but this runtime is only meant for sh/gcc to use, not user apps. Having special code that only knows the Cygwin convention is questionable. I was often setting up some environment variables one way or the other, and then running one cm3 or the other, without thinking about which form the variables were in. Indeed, it might be nice to set CM3_ROOT and CM3_INSTALL "once and for all", while still switching between different forms of cm3.exe? Though granted, CM3_INSTALL cm3.exe can usually figure out from its own path, and CM3_ROOT could usually be figured out by looking at the CVS directories in the current working directory, not always, but often. Basically, instead of setting these varibles one way or the other, I'd like to set them always one way, or even not at all. Hm, in fact, I think cm3 could figure out all overrides itself? You know, if there is a shipped package store, it can use that to determine the source <=> pkg mapping. And it can figure out CM3_ROOT by looking at the current directory and on up until the CVS/Root changes? As well, you know, the source <=> pkg mapping could be a simple generated checked in file. You know, like the PKGS file, but stripped down to only what is needed? Maybe just remove the code I put in and forget the whole thing. Maybe most people only ever stay in one of the worlds and "translation" isn't important? Just me stuck with providing support for both and therefore living with both more? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Apr 22 06:16:44 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 22 Apr 2008 04:16:44 +0000 Subject: [M3devel] more path stuff, sorry In-Reply-To: <480D1EAD.1E75.00D7.1@scires.com> References: <480D1EAD.1E75.00D7.1@scires.com> Message-ID: Randy we are kind of saying the same thing. Imagine if you will code out that that assumes all "full paths" start with a forward slash. There is surely a lot of this code. Imagine if you will code out there that assumes that all "full paths" start with either two slashes or a letter, colon, slash. There is a lot of this code too. (I think btw that Windows CE paths all start with one leading slash, and I suspect it must be a backward one, but I don't have a CE Phone yet, maybe soon, ARM_CE? :) ARM_WINCE?) Now imagine that this code is being used in some build automation and feeding the paths it forms to cm3. There is actually probably not much of this, but it is "reasonable". The idea then would be for such code to be "portable" to Posix and/or Win32, without having to adopt "some abstraction". You know...there's some tension in programming, between inventing abstractions and layers to bridge different underlying implementations, ahead of time or in all paths, vs. inserting new layers in some paths to make them "look like" preexisting paths. "Emulation layers" if you will. The advantage of "emulation" is that at least some variants run "native" and skip the "emulation". That is, like, survey the landscape of existing implementations, pick one that is reasonable and popular and easily emulated, write all your code to it, and add an emulation layer for the other cases. The trick of course is that it isn't always possible. Sometimes the job of the "abstraction layer" includes narrowing the underlying interfaces/feature set to the intersection, often refered to as "least common denominator". And then, some "abstraction layers" to "fix" this problem, let you "break through" to the underlying system. Such allowing of "break through" is obviously good and bad in multiple ways. The ability to break through takes away the ability of the layer to be stateful. Stateful layers are also to be avoided in the first place if performance is a concern. Now, in reality, paths are not a great example of this, because paths don't have all that many "features", so an abstraction boundary isn't likely to be lossy. Besides features, there issues of "capacity". For example, imagine I have a system that allows files larger than 4gig and a system that does not. Imagine the portability layer lets through file sizes larger than 4gig. While this enables the better system to have a larger capacity, it also enables a situation where users on one system can write files that users on another cannot read. Sometimes people suggest warnings for these kinds of things, like when you save a Word document in an older format and some formating may or may not be lost. Another problem with abstraction boundaries is you that you inevitably create yet another way of doing things, in the service of papering over that there is already more than one way. The cure is similar to the disease, sort of. You know, there is some set of programmers who can read XWindows code, some set that can read MSWindows, and the set that can read Trestle is bound to be less. Of course, this varies. Like, probably more people are familiar now with MFC, Qt, GTk than XOpenDisplay or CreateWindow. Sometimes the underlying systems are too hard to use, too unfeatureful and the layers built on them are not just for portability but also ease of use and sometimes add a bunch of value. In the end, I think I'll remove the code. But I'm not crazy. Portability can be served by catering to existing practises rather than inventing new ones. But granted it doesn't always work well. The Posix systems for Windows all seem to stink, and Wine seems to really stink. Btw, interesting point I think is how cm3cg manages to not care -- its input and output are always in the current working directory. It doesn't create any threads, no gui. While the "build system", sh, nmake, sed, awk, might have heavier requirements on their runtime (I don't know, haven't looked, not sure if Cygwin was for them or the larger goal), m3cg is light. Gcc is somewhere in between since it does look up paths "around the system" and run sub processes. But it still shouldn't be much OS dependent code, vs. all the work of parsing C, codegen, optimization. I must point out that the landscape is strewn with abstraction boundaries that work a lot and fail a lot. File systems are a huge example here. Some file systems allow files over 2 or 4 gig, some do not. Some perform at the much greater speed of nearby mechanically spinning disks, some at the usually slow rate of a network, some write at the very very slow speed of flash, some (flash) cannot stand too many writes. Some have readonly/hidden/system/etc. bits, some do not. Sometimes people stash the extra data in one form or another, sometimes it tends to get lost (Mac resource fork), sometimes now. I vaguely recall that Mac OSX implements hardlinks on HFS+ in a pretty convoluted way. File systems, thinking about paths, are also a big problem in terms of preservation of file names across file systems. At one extreme is MS-DOS 8.3 and some 14 character Unix systems. At another extreme is 255 character Unicode names. Files created one system cannot necessarily be moved to another. Yet the abstraction boundary to the file system, fopen, or whatever Modula-3 has, doesn't somehow deal with this. You know, you could do something whacky like put everything in a .zip file. But then you lose interoperability when the data would have been ok. Case sensitivity...how many folks think "Win32" is case sensitive and "Unix" is not? And yet, that is not how it works. It depends on the file system. How much code in the world is not prepared for symlinks or hard links? A lot. We muddle along. - Jay Date: Mon, 21 Apr 2008 23:09:39 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] more path stuff, sorry I think I've made my opinion on the path issue known, but just so there is no doubt, I do not want the underlying code trying to translate paths from one format to another. I think this is a recipe for problems since different OS represent paths and switches etc differently. Programmers should use the standard interfaces to construct paths appropriate for the current host operating system. Part of the beauty of Modula-3 is write once run everywhere. I have code that uses pathnames that runs on multiple platforms without the need to make any source code modifications. Regards, Randy>>> Jay 4/21/2008 7:15 PM >>>Maybe this is dubious.The question is, like, should native NT386 cm3 accept /cygdrive/c/foo and translate to c:\foo?Or trickier, /usr/bin/foo and translate to c:\cygwin\usr\bin\foo?And vice versa, should NT386GNU accept c:\foo?The translation is not simple in general./ maps to the Cygwin install root.There can be symlinks.But many common cases can be handled with little, simple code.It's already in.Ultimately the way to do this correctly is to link to cygwin1.dll, which is only done sometimes, and which probably license-undesirable when not done.As well, a path like /foo is actually ambiguous.It is a valid native Win32 path, equivalent to \foo.Or it could be Cygwin path requivalent to c:\cygwin\foo.While it is nice to keep cm3 simple, it is also nice to have a more uniform interfaceacross hosts, I think. Maybe.To some extent a user can do this himself.That is, NTFS junctions and/or Cygwin symblinks can cause their to be identical pathswith identical meanings:e.g. for me, symlink /msdev => c:\msdev, /cm3 => c:\cm3 /dev => c:\dev2In some places Cygwin open et. al. accept Win32 paths, but lately taking advantage ofthat issues a warning. In some places, I think, it isn't sufficient to have Cygwin handle it.The harder question then is, if I feed Cygwin paths of a particular form, should ittry to report back paths in the same form?I put some code in M3Path.m3 "like this", but it may not be advisable.I also had an NTFS junction on my system so Win32 /cygdrive/c => c:\, but this causesa circularity in the file system, which I'd rather not have.As well, there are at least three or four Posix runtimes for Windows, and they each mapdifferently.UWin I think uses /c <=> c:\.Cygwin /cygdrive <=> c:\Interix/ServicesForUnix/SUA I think something via /dev.MinGWin also has a runtime that I think uses the UWin mapping, but this runtime is onlymeant for sh/gcc to use, not user apps.Having special code that only knows the Cygwin convention is questionable. I was often setting up some environment variables one way or the other, and thenrunning one cm3 or the other, without thinking about which form the variables were in.Indeed, it might be nice to set CM3_ROOT and CM3_INSTALL "once and for all",while still switching between different forms of cm3.exe?Though granted, CM3_INSTALL cm3.exe can usually figure out from its own path, andCM3_ROOT could usually be figured out by looking at the CVS directories in the currentworking directory, not always, but often. Basically, instead of setting these variblesone way or the other, I'd like to set them always one way, or even not at all.Hm, in fact, I think cm3 could figure out all overrides itself?You know, if there is a shipped package store, it can use that to determine the source <=> pkg mapping.And it can figure out CM3_ROOT by looking at the current directory and on up until the CVS/Rootchanges? As well, you know, the source <=> pkg mapping could be a simple generated checked in file.You know, like the PKGS file, but stripped down to only what is needed? Maybe just remove the code I put in and forget the whole thing.Maybe most people only ever stay in one of the worlds and "translation" isn't important?Just me stuck with providing support for both and therefore living with both more? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Apr 22 06:19:52 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 22 Apr 2008 04:19:52 +0000 Subject: [M3devel] more path stuff, sorry In-Reply-To: <480D1FB2.1E75.00D7.1@scires.com> References: <480D1FB2.1E75.00D7.1@scires.com> Message-ID: There's no dependency, no linkage. Just a few simple string operations. I'll probably remove it tonight. Modula-3 has a split personality no matter what, in that it calls into very varying underlying layers, often trafficing in their specific data formats. It's just that it can strive to aid portability between them or not, by accepting either input and massaging it to work, vs. passing it along "unchanged" (well, that's not what happens actually). If there were no ambiguous cases and the Posix systems on Windows were consistent in their conventions, I'd be more for it. But the ambiguity and varying Posix conventions weaken the case tremendously. - Jay Date: Mon, 21 Apr 2008 23:14:00 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] more path stuff, sorry I concur wholeheartedly. I absolutely DO NOT want native NT386 to have any knowledge of or dependency on Cygwin. Regards, Randy>>> Tony Hosking 4/21/2008 9:44 PM >>> Why would native NT386 know anything at all about Cygwin. I say just avoid split personalities like the plague. Similarly, I'd be happy for NT386GNU (i.e., Cygwin?) to simply behave like a POSIX build (modulo native threads perhaps). On Apr 21, 2008, at 7:15 PM, Jay wrote: Maybe this is dubious.The question is, like, should native NT386 cm3 accept /cygdrive/c/foo and translate to c:\foo?Or trickier, /usr/bin/foo and translate to c:\cygwin\usr\bin\foo?And vice versa, should NT386GNU accept c:\foo?The translation is not simple in general./ maps to the Cygwin install root.There can be symlinks.But many common cases can be handled with little, simple code.It's already in.Ultimately the way to do this correctly is to link to cygwin1.dll, which is only done sometimes, and which probably license-undesirable when not done.As well, a path like /foo is actually ambiguous.It is a valid native Win32 path, equivalent to \foo.Or it could be Cygwin path requivalent to c:\cygwin\foo.While it is nice to keep cm3 simple, it is also nice to have a more uniform interfaceacross hosts, I think. Maybe.To some extent a user can do this himself.That is, NTFS junctions and/or Cygwin symblinks can cause their to be identical pathswith identical meanings:e.g. for me, symlink /msdev => c:\msdev, /cm3 => c:\cm3 /dev => c:\dev2In some places Cygwin open et. al. accept Win32 paths, but lately taking advantage ofthat issues a warning. In some places, I think, it isn't sufficient to have Cygwin handle it.The harder question then is, if I feed Cygwin paths of a particular form, should ittry to report back paths in the same form?I put some code in M3Path.m3 "like this", but it may not be advisable.I also had an NTFS junction on my system so Win32 /cygdrive/c => c:\, but this causesa circularity in the file system, which I'd rather not have.As well, there are at least three or four Posix runtimes for Windows, and they each mapdifferently.UWin I think uses /c <=> c:\.Cygwin /cygdrive <=> c:\Interix/ServicesForUnix/SUA I think something via /dev.MinGWin also has a runtime that I think uses the UWin mapping, but this runtime is onlymeant for sh/gcc to use, not user apps.Having special code that only knows the Cygwin convention is questionable. I was often setting up some environment variables one way or the other, and thenrunning one cm3 or the other, without thinking about which form the variables were in.Indeed, it might be nice to set CM3_ROOT and CM3_INSTALL "once and for all",while still switching between different forms of cm3.exe?Though granted, CM3_INSTALL cm3.exe can usually figure out from its own path, andCM3_ROOT could usually be figured out by looking at the CVS directories in the currentworking directory, not always, but often. Basically, instead of setting these variblesone way or the other, I'd like to set them always one way, or even not at all.Hm, in fact, I think cm3 could figure out all overrides itself?You know, if there is a shipped package store, it can use that to determine the source <=> pkg mapping.And it can figure out CM3_ROOT by looking at the current directory and on up until the CVS/Rootchanges? As well, you know, the source <=> pkg mapping could be a simple generated checked in file.You know, like the PKGS file, but stripped down to only what is needed? Maybe just remove the code I put in and forget the whole thing.Maybe most people only ever stay in one of the worlds and "translation" isn't important?Just me stuck with providing support for both and therefore living with both more? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Apr 22 06:28:23 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 22 Apr 2008 04:28:23 +0000 Subject: [M3devel] FW: more path stuff, sorry In-Reply-To: <480D1FB2.1E75.00D7.1@scires.com> References: <480D1FB2.1E75.00D7.1@scires.com> Message-ID: [truncated]... From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] more path stuff, sorryDate: Tue, 22 Apr 2008 04:19:52 +0000 There's no dependency, no linkage. Just a few simple string operations.I'll probably remove it tonight. Modula-3 has a split personality no matter what, in that it calls into very varying underlying layers, often trafficing in their specific data formats.It's just that it can strive to aid portability between them or not, by accepting either input and massaging it to work, vs. passing it along "unchanged" (well, that's not what happens actually). If there were no ambiguous cases and the Posix systems on Windows were consistent in their conventions, I'd be more for it. But the ambiguity and varying Posix conventions weaken the case tremendously. - Jay Date: Mon, 21 Apr 2008 23:14:00 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] more path stuff, sorry I concur wholeheartedly. I absolutely DO NOT want native NT386 to have any knowledge of or dependency on Cygwin. Regards, Randy>>> Tony Hosking 4/21/2008 9:44 PM >>> Why would native NT386 know anything at all about Cygwin. I say just avoid split personalities like the plague. Similarly, I'd be happy for NT386GNU (i.e., Cygwin?) to simply behave like a POSIX build (modulo native threads perhaps). On Apr 21, 2008, at 7:15 PM, Jay wrote: Maybe this is dubious.The question is, like, should native NT386 cm3 accept /cygdrive/c/foo and translate to c:\foo?Or trickier, /usr/bin/foo and translate to c:\cygwin\usr\bin\foo?And vice versa, should NT386GNU accept c:\foo?... -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Apr 22 14:29:09 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 22 Apr 2008 08:29:09 -0400 Subject: [M3devel] FW: more path stuff, sorry In-Reply-To: References: <480D1FB2.1E75.00D7.1@scires.com> Message-ID: <08DD9502-27D3-4C5C-9E30-A9E9D2CADAB4@cs.purdue.edu> Jay, there is an underlying principle here that you seem to be missing so I will make it explicit. Cross-product systems tend to acquire unmanageable complexity, especially when it comes to testing. By making each target one personality we are able to test machine- dependent code in isolation from machine-independent code. Often, when something breaks on one target I will test on another just to isolate the problem. This is a very powerful approach and I am very leery of destroying any ability to do this -- it allows us to maintain the high-level portability of most Modula-3 code while isolating the small fraction of machine-/target-dependent stuff. On Apr 22, 2008, at 12:28 AM, Jay wrote: > [truncated]... > > > > > From: jayk123 at hotmail.com > To: rcoleburn at scires.com; m3devel at elegosoft.com > Subject: RE: [M3devel] more path stuff, sorry > Date: Tue, 22 Apr 2008 04:19:52 +0000 > > There's no dependency, no linkage. Just a few simple string > operations. > I'll probably remove it tonight. > > Modula-3 has a split personality no matter what, in that it calls > into very varying underlying layers, often trafficing in their > specific data formats. > It's just that it can strive to aid portability between them or not, > by accepting either input and massaging it to work, vs. passing it > along "unchanged" (well, that's not what happens actually). If there > were no ambiguous cases and the Posix systems on Windows were > consistent in their conventions, I'd be more for it. But the > ambiguity and varying Posix conventions weaken the case tremendously. > > - Jay > > Date: Mon, 21 Apr 2008 23:14:00 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] more path stuff, sorry > > I concur wholeheartedly. I absolutely DO NOT want native NT386 to > have any knowledge of or dependency on Cygwin. > Regards, > Randy > > >>> Tony Hosking 4/21/2008 9:44 PM >>> > Why would native NT386 know anything at all about Cygwin. I say > just avoid split personalities like the plague. Similarly, I'd be > happy for NT386GNU (i.e., Cygwin?) to simply behave like a POSIX > build (modulo native threads perhaps). > > On Apr 21, 2008, at 7:15 PM, Jay wrote: > > Maybe this is dubious. > > The question is, like, should native NT386 cm3 accept /cygdrive/c/ > foo and translate to c:\foo? > Or trickier, /usr/bin/foo and translate to c:\cygwin\usr\bin\foo? > And vice versa, should NT386GNU accept c:\foo? > > ... -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Apr 22 14:52:05 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 22 Apr 2008 12:52:05 +0000 Subject: [M3devel] type mismatches? Message-ID: 4797 NEXT Fatal Error: bad version stamps: SocketPosix.m3 4798 4799 version stamp mismatch: Compiler.Platform 4800 => SocketPosix.m3 4801 => Compiler.i3 4802 version stamp mismatch: Compiler.ThisPlatform 4803 => SocketPosix.m3 4804 => Compiler.i3 This is now in the Tinderbox, on some machines, e.g. FreeBSD4. I have two source trees on same machine sharing same install root, one sees it, one does not. Even though I start the install root out by extracting the same initial snapshot, I think. I think they are the same except for path but that needs scrutiny. I am making SOME attempt to isolate it, but I'm not looking forward to it.. One expensive potshot is wait for a full hours-long gcc build with no switches. In case it is a cm3cg problem, emanating from the compiler used to build cm3cg. (I just did another build of cm3cg, took 11 minutes..) That is: There is a problem here. It's not just me. I MIGHT find it. If anyone can save me the trouble, please do. :) Other potshots include more conservative codegen like -fno-reorder-blocks -mno-double-align -O0, some/all of which are already in use. I was going to commit blindly such conservatism for FreeBSD4, however my local repro is persisting despite this. It could still be some simple bootstrapping issue. I don't know. SocketPosix is only using Compiler for some dormant platforms. The code is probably dead. But hey, extra dead code finds extra live bugs. :) Question: Am I correct that, in the absence of cm3/cm3cg/underlying bugs, the following should never occur: cd .../m3core rm -rf cm3 cm3 -ship cd ../libm3 rm -rf cm3 => version stamp mismatch ? That is -- if this happens, it can't be any bootstrapping problem? These checks are libm3 vs. m3core, right? What the compiler itself is? - Jay From hosking at cs.purdue.edu Tue Apr 22 19:02:47 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 22 Apr 2008 13:02:47 -0400 Subject: [M3devel] type mismatches? In-Reply-To: References: Message-ID: This happens whenever you add a new target to the compiler. You need to bootstrap a new compiler with the old libraries (m3core, libm3) before trying to build the new libraries containing the new Compiler.tmpl. On Apr 22, 2008, at 8:52 AM, Jay wrote: > > 4797 NEXT Fatal Error: bad version stamps: SocketPosix.m3 > 4798 > 4799 version stamp mismatch: Compiler.Platform > 4800 => SocketPosix.m3 > 4801 => Compiler.i3 > 4802 version stamp mismatch: Compiler.ThisPlatform > 4803 => SocketPosix.m3 > 4804 => Compiler.i3 > > This is now in the Tinderbox, on some machines, e.g. FreeBSD4. > I have two source trees on same machine sharing same install root, > one sees it, one does not. > Even though I start the install root out by extracting the same > initial snapshot, I think. > I think they are the same except for path but that needs scrutiny. > > I am making SOME attempt to isolate it, but I'm not looking forward > to it.. > One expensive potshot is wait for a full hours-long gcc build with > no switches. > In case it is a cm3cg problem, emanating from the compiler used to > build cm3cg. > (I just did another build of cm3cg, took 11 minutes..) > > That is: > There is a problem here. It's not just me. I MIGHT find it. > If anyone can save me the trouble, please do. :) > > Other potshots include more conservative codegen like -fno-reorder- > blocks -mno-double-align -O0, some/all of which are already in use. > I was going to commit blindly such conservatism for FreeBSD4, > however my local repro is persisting despite this. > > It could still be some simple bootstrapping issue. I don't know. > > SocketPosix is only using Compiler for some dormant platforms. The > code is probably dead. > But hey, extra dead code finds extra live bugs. :) > > Question: > Am I correct that, in the absence of cm3/cm3cg/underlying bugs, the > following should never occur: > cd .../m3core > rm -rf > cm3 > cm3 -ship > cd ../libm3 > rm -rf > cm3 > => version stamp mismatch > > ? That is -- if this happens, it can't be any bootstrapping problem? > These checks are libm3 vs. m3core, right? What the compiler itself is? > > - Jay From jayk123 at hotmail.com Tue Apr 22 20:31:53 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 22 Apr 2008 18:31:53 +0000 Subject: [M3devel] type mismatches? In-Reply-To: References: Message-ID: Tony, I thought I understood, I thought the automation handled this, both that I run and that the Tinderbox runs, such that one would never see this. I'll poke around a bit more. Oh, I think I see now. m3front/src/builtInfo/InfoModule.m3 This will happen also if you only change one side. Could be I had that edit on my machine. Still not sure about the Tinderbox but I'll wait and see. Thanks, - Jay > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jayk123 at hotmail.com > Subject: Re: [M3devel] type mismatches? > Date: Tue, 22 Apr 2008 13:02:47 -0400 > > This happens whenever you add a new target to the compiler. You need > to bootstrap a new compiler with the old libraries (m3core, libm3) > before trying to build the new libraries containing the new > Compiler.tmpl. > > On Apr 22, 2008, at 8:52 AM, Jay wrote: > > > > > 4797 NEXT Fatal Error: bad version stamps: SocketPosix.m3 > > 4798 > > 4799 version stamp mismatch: Compiler.Platform > > 4800 => SocketPosix.m3 > > 4801 => Compiler.i3 > > 4802 version stamp mismatch: Compiler.ThisPlatform > > 4803 => SocketPosix.m3 > > 4804 => Compiler.i3 > > > > This is now in the Tinderbox, on some machines, e.g. FreeBSD4. > > I have two source trees on same machine sharing same install root, > > one sees it, one does not. > > Even though I start the install root out by extracting the same > > initial snapshot, I think. > > I think they are the same except for path but that needs scrutiny. > > > > I am making SOME attempt to isolate it, but I'm not looking forward > > to it.. > > One expensive potshot is wait for a full hours-long gcc build with > > no switches. > > In case it is a cm3cg problem, emanating from the compiler used to > > build cm3cg. > > (I just did another build of cm3cg, took 11 minutes..) > > > > That is: > > There is a problem here. It's not just me. I MIGHT find it. > > If anyone can save me the trouble, please do. :) > > > > Other potshots include more conservative codegen like -fno-reorder- > > blocks -mno-double-align -O0, some/all of which are already in use. > > I was going to commit blindly such conservatism for FreeBSD4, > > however my local repro is persisting despite this. > > > > It could still be some simple bootstrapping issue. I don't know. > > > > SocketPosix is only using Compiler for some dormant platforms. The > > code is probably dead. > > But hey, extra dead code finds extra live bugs. :) > > > > Question: > > Am I correct that, in the absence of cm3/cm3cg/underlying bugs, the > > following should never occur: > > cd .../m3core > > rm -rf > > cm3 > > cm3 -ship > > cd ../libm3 > > rm -rf > > cm3 > > => version stamp mismatch > > > > ? That is -- if this happens, it can't be any bootstrapping problem? > > These checks are libm3 vs. m3core, right? What the compiler itself is? > > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Wed Apr 23 06:00:43 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 23 Apr 2008 06:00:43 +0200 (CEST) Subject: [M3devel] FW: more path stuff, sorry In-Reply-To: <08DD9502-27D3-4C5C-9E30-A9E9D2CADAB4@cs.purdue.edu> Message-ID: <135722.70767.qm@web27113.mail.ukl.yahoo.com> Hi all: Does pm3 treat NT386GNU paths as POSIX class? I think if one take the definition the Interface Pathname, NT386GNU target should not have access directly to use POSIX paths but Win32 ones because of: "A Pathname.T (or just a pathname) is a text conforming to the syntax of the underlying operating system" in http://www.opencm3.net/doc/help/gen_html/libm3/src/os/Common/Pathname.i3.html But if we think in "the underlying operating system" as the cygwin api, it should be the natural POSIX paths. I agree Pathname is a common interface, but what happens with that sense of portability we want? Maybe the answer is in the cygwin api; the non-standard functions of converting one style to the other: http://cygwin.com/cygwin-api/cygwin-functions.html . See http://www.cygwin.com/cygwin-ug-net/using.html#using-pathnames for the main notes of compatibility. It seems clear that cygwin can use both kind of path styles, so it's not a problem to use just one of POSIX or Win32 paths. So defining a Pathname of type POSIX style for NT386GNU, it is not resign to the more capable functions of cygwin? I mean if Pathname accept both kind of forward and back slashes in different Pathnames it should be defined a new kind of Pathname syntax. Oh I remember saw the mix of both kind of slashes in pm3 quake/config files of NT386GNU :) Is this really confusing or unthinkable? I think this is clear for some of yous (NT386GNU should just accept POSIX paths, not even a Win32 one, and obviously not a mix of the two syntax in a same path), but it is not for me. In my opinion both styles should be acceptable without defining a new kind of path syntax, and convert only using the cygwin api functions. For instance when using netbios resources but also trying to mount disks partitions on the cygwin mount table file we need both kind of syntax. Is that even logical? Thanks in advance. Tony Hosking escribi?: Jay, there is an underlying principle here that you seem to be missing so I will make it explicit. Cross-product systems tend to acquire unmanageable complexity, especially when it comes to testing. By making each target one personality we are able to test machine-dependent code in isolation from machine-independent code. Often, when something breaks on one target I will test on another just to isolate the problem. This is a very powerful approach and I am very leery of destroying any ability to do this -- it allows us to maintain the high-level portability of most Modula-3 code while isolating the small fraction of machine-/target-dependent stuff. On Apr 22, 2008, at 12:28 AM, Jay wrote: [truncated]... --------------------------------- From: jayk123 at hotmail.com To: rcoleburn at scires.com; m3devel at elegosoft.com Subject: RE: [M3devel] more path stuff, sorry Date: Tue, 22 Apr 2008 04:19:52 +0000 There's no dependency, no linkage. Just a few simple string operations. I'll probably remove it tonight. Modula-3 has a split personality no matter what, in that it calls into very varying underlying layers, often trafficing in their specific data formats. It's just that it can strive to aid portability between them or not, by accepting either input and massaging it to work, vs. passing it along "unchanged" (well, that's not what happens actually). If there were no ambiguous cases and the Posix systems on Windows were consistent in their conventions, I'd be more for it. But the ambiguity and varying Posix conventions weaken the case tremendously. - Jay --------------------------------- Date: Mon, 21 Apr 2008 23:14:00 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] more path stuff, sorry I concur wholeheartedly. I absolutely DO NOT want native NT386 to have any knowledge of or dependency on Cygwin. Regards, Randy >>> Tony Hosking 4/21/2008 9:44 PM >>> Why would native NT386 know anything at all about Cygwin. I say just avoid split personalities like the plague. Similarly, I'd be happy for NT386GNU (i.e., Cygwin?) to simply behave like a POSIX build (modulo native threads perhaps). On Apr 21, 2008, at 7:15 PM, Jay wrote: Maybe this is dubious. The question is, like, should native NT386 cm3 accept /cygdrive/c/foo and translate to c:\foo? Or trickier, /usr/bin/foo and translate to c:\cygwin\usr\bin\foo? And vice versa, should NT386GNU accept c:\foo? ... --------------------------------- Enviado desde Correo Yahoo! La bandeja de entrada m?s inteligente. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Apr 23 06:44:23 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Apr 2008 04:44:23 +0000 Subject: [M3devel] FW: more path stuff, sorry In-Reply-To: <135722.70767.qm@web27113.mail.ukl.yahoo.com> References: <08DD9502-27D3-4C5C-9E30-A9E9D2CADAB4@cs.purdue.edu> <135722.70767.qm@web27113.mail.ukl.yahoo.com> Message-ID: Daniel, this should address SOME but not necessarily all of your concern and questions: The underlying libraries are mostly Cygwin. Underlying THEM is another library, but the way it works, there is approximately zero "break through". Except for threads. Also, I intend, somehow, to expose FilePosix.T and FileWin32.T, besides the regular File.T. This would be part of enabling the serial package to build, using strictly "break through" and the Win32 code. However FilePosix.m3 and FileWin32.m3 both reveal File.T. I need to split the revelation out into a separate interface/module I think, shouldn't be hard. >From SOME point of view, forward slashes are perfectly acceptable in Win32 paths and have the same meaning as backward slashs. It is not 100%, but largely. This isn't Modula-3 code doing any "translation" but the Modula-3 does treat \ and / equivalent upon read. The lowest level Win32 File functions in kernel32.dll -- CreateFile, DeleteFile, MoveFile, CreateDirectory, RemoveDirectory, CopyFile, GetCurrentDirectory, SetCurrentDirectory, GetFileAttributes[Ex], FindFirst[Next]File[Ex], what else am I forgetting? Maybe CreateProcess? GetFullPathName, GetShortPathName, usually consider \ and / the same. Unless the paths starts \\?. The / are all converted to \ before getting to the underlying system, the NtCreateFile, where strictly \ is the separator and there is no working directory. If a path starts \\?, it is passed on directly. You don't have to pass full paths. You can pass a handle to a parent directory. Now, I recently read, regarding NTFS-3G for Linux, about allowing : and \ in file names. The claim is that if you install SFU (Services For Unix, previously Interix, now SUA), you can access such names on NT. I tried it out. In fact this claim seems wrong. I create those paths, and then enumerated and printed from Win32. Their lower 8 bits were : and \. But their upper 8 bits were 0xF0 or 0xFF or somesuch. SFU has some ability to access unicode file names, but not that I could find that would reveal this trickery. In particular, there is like wcs_opendir that opens a directory with a unicode path, but there is only the asii/ansi/utf8/7bit/8bit/whatever readdir/readdir_r. So the 0xF000 cannot show through. And proper unicode Win32 code still doesn't see ':' or '\' per se in file names (in paths, but not individual names). I think I happened to accidentally copy this stuff to a Linux machine, and they didn't come across as ':' or '\'. Maybe I used wine cmd copy though. I should try with NTFS-3G. I do suspect I'll get ':' and '\'. Speaking of portability -- should Modula-3 on Posix systems allow file names with ':' and '\'? There are pluses and minuses. It's a rhetorical question -- in that, I don't really want to discuss it that much. I don't think there's a good answer, so I'd just as soon leave the code alone vs. trying in vain to come up with what is "correct". Yes there are Cygwin specific functions for converting paths. It would be reasonable for some NT386GNU-specific paths to use them. You can write up the *.i3 files and call them where you deem appropriate. Where deemed appropriate is not clear. It would not be great for the NT386 tools to use them -- to link to cygwin1.dll, for any reason. Maybe via LoadLibrary/GetProcAddress -- an optional dependency. Maybe. I believe "linkage" should mean "static linkage in the same file" and not "dynamic linkage in the same process" but it isn't up to me and it very well might be this way. I think the Linux kernel grants an exception, but I'm skeptical that non-GPL code doesn't dynamically link to in-proc GPL code that hasn't granted an exception. Anyway, Modula-3 except for NT386GNU is not in any uniquely worrying boat, for sure. You see, like my little speech about emulation layers and "break though", Cygwin is an emulation layer. But its users may or may not consider it to have much "break through". It's users might be very accustomed to Posix paths and a full set of Posix-path-using tools, and have no need to give any of them a Win32 path, and if they do, might be prepared to stop and think about it and do their own conversion. I think it's gray, because gcc as a compiler is arguably way more valuable than a Posix porting layer for other code. Or really, they are both useful. Some people will want one, or the other, or both, or neither. And again I am confusing Cygwin, NT386GNU, and the backend vs. the runtime. You can very well combine the integrated backend with a Posixish runtime -- remember all the systems now have the integrated backend, you should be able to output NT386 .obj files on any platform just by saying TARGET= "NT386" in cm3.cfg. And you can combine the gcc backend with a Win32 runtime -- that is what NT386MINGNU is. Also, while kernel32.dll treats / like \, other Win32 functions/libraries do not, such as comdlg32.dll (File.Open, File.Save), and shlwapi.dll, I think. You'd have to read the docs and/or experiment. Win32 has a lot of nice internal consistencies, but it isn't 100% consistent. Probably nothing is. A mix of slashes works fine on NT386. Does some of this make sense? Again again again, "NT386GNU" is different things to different people, and some of them are in fact independent and you can pick and chose which parts you compose. There is the runtime the compiler uses. There is the backend. There is the library the output uses, both the "C library" (fopen), the threading library (pthreads vs. Win32), the windowing library (X Windows vs. Win32), the naming conventions (libfoo.a vs. foo.lib). Nearly every one of these factors is independent of the others, The config files are written as such and you should be able to experiment and make your own other combinations. Three such combinations are provided, and there's sort of a tendency for the host and the target to be the same, but they don't have to be. There are other factors, like which C compiler do you use, which linker. The compiler, backend, and linker conspire to determine which debugger you can use. If you se the integrated backend and MS linker, you can use MS debuggers. If you use the gcc backend and GNU linker, you can use gdb. Oh, well you can always use either debugger, but the point here is if you have symbols or not. Currently there is some problem mixing the gcc backend with the MS linker and/or the integrated backend with the GNU linker. I think gcc backend with MS linker, and only sometimes the other. There is a symbol alway injected into the .o files that the GNU linker knows about but that the MS linker gives as unresolved. The MS linker has a different name for it, but I don't believe it is always injected by the integrated backend. This is the symbol that lets you point to the start of your image, it is __ImageBase in MS. It isn't used much. But for some reason gcc always generates references to it, and gives it a different name. Therefore some of the supposedly independent factors are not independent as they should be. For network paths, Cygwin allows //machine/server. Current Cygwin issues warnings when you use Win32 paths, and the warning says you can quash it by setting CYGWIN=nodospathwarning or somesuch. Does this make some sense? At some point maybe I'll put together distributions for other combinations. Oh, one more thing, the gcc backend can use __int64. I was feeling guilty about taking so long adding that to the integrated backend, thus I fast-forwarded and got NT386GNU to work. I should still go back and add it though. Also, currently the compiler assumes some linkage of these factors. It assumes OS_TYPE=POSIX means targeting Cygwin. Eh that's pretty much correct. At some point maybe UWin and SFU will be options, but not right now. The compiler's main concern is the jumpbuf size, which is much larger for Cygwin. You can to some extent maybe link NT386 and NT386GNU together, but this jumpbuf thing could really hurt in a hard to diagnose way. (Maybe it's safe due to setjmp vs. _setjmp?)? Sorry this is too long. As Olaf said, what I say might be very true and an accurate model, but it confuses everyone. People want very very few variables. Sorry I have to run, no proofreading this "masterpiece". - Jay Date: Wed, 23 Apr 2008 06:00:43 +0200From: dabenavidesd at yahoo.esTo: m3devel at elegosoft.comSubject: Re: [M3devel] FW: more path stuff, sorryHi all:Does pm3 treat NT386GNU paths as POSIX class? I think if one take the definition the Interface Pathname, NT386GNU target should not have access directly to use POSIX paths but Win32 ones because of:"A Pathname.T (or just a pathname) is a text conforming to the syntax of the underlying operating system" inhttp://www.opencm3.net/doc/help/gen_html/libm3/src/os/Common/Pathname.i3.htmlBut if we think in "the underlying operating system" as the cygwin api, it should be the natural POSIX paths.I agree Pathname is a common interface, but what happens with that sense of portability we want? Maybe the answer is in the cygwin api; the non-standard functions of converting one style to the other: http://cygwin.com/cygwin-api/cygwin-functions.html .See http://www.cygwin.com/cygwin-ug-net/using.html#using-pathnamesfor the main notes of compatibility. It seems clear that cygwin can use both kind of path styles, so it's not a problem to use just one of POSIX or Win32 paths. So defining a Pathname of type POSIX style for NT386GNU, it is not resign to the more capable functions of cygwin?I mean if Pathname accept both kind of forward and back slashes in different Pathnames it should be defined a new kind of Pathname syntax. Oh I remember saw the mix of both kind of slashes in pm3 quake/config files of NT386GNU :) Is this really confusing or unthinkable?I think this is clear for some of yous (NT386GNU should just accept POSIX paths, not even a Win32 one, and obviously not a mix of the two syntax in a same path), but it is not for me.In my opinion both styles should be acceptable without defining a new kind of path syntax, and convert only using the cygwin api functions. For instance when using netbios resources but also trying to mount disks partitions on the cygwin mount table file we need both kind of syntax. Is that even logical?Thanks in advance.Tony Hosking escribi?: Jay, there is an underlying principle here that you seem to be missing so I will make it explicit. Cross-product systems tend to acquire unmanageable complexity, especially when it comes to testing. By making each target one personality we are able to test machine-dependent code in isolation from machine-independent code. Often, when something breaks on one target I will test on another just to isolate the problem. This is a very powerful approach and I am very leery of destroying any ability to do this -- it allows us to maintain the high-level portability of most Modula-3 code while isolating the small fraction of machine-/target-dependent stuff. On Apr 22, 2008, at 12:28 AM, Jay wrote: [truncated]... From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] more path stuff, sorryDate: Tue, 22 Apr 2008 04:19:52 +0000There's no dependency, no linkage. Just a few simple string operations.I'll probably remove it tonight. Modula-3 has a split personality no matter what, in that it calls into very varying underlying layers, often trafficing in their specific data formats.It's just that it can strive to aid portability between them or not, by accepting either input and massaging it to work, vs. passing it along "unchanged" (well, that's not what happens actually). If there were no ambiguous cases and the Posix systems on Windows were consistent in their conventions, I'd be more for it. But the ambiguity and varying Posix conventions weaken the case tremendously. - Jay Date: Mon, 21 Apr 2008 23:14:00 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] more path stuff, sorry I concur wholeheartedly. I absolutely DO NOT want native NT386 to have any knowledge of or dependency on Cygwin. Regards, Randy>>> Tony Hosking 4/21/2008 9:44 PM >>> Why would native NT386 know anything at all about Cygwin. I say just avoid split personalities like the plague. Similarly, I'd be happy for NT386GNU (i.e., Cygwin?) to simply behave like a POSIX build (modulo native threads perhaps). On Apr 21, 2008, at 7:15 PM, Jay wrote: Maybe this is dubious.The question is, like, should native NT386 cm3 accept /cygdrive/c/foo and translate to c:\foo?Or trickier, /usr/bin/foo and translate to c:\cygwin\usr\bin\foo?And vice versa, should NT386GNU accept c:\foo?... Enviado desde Correo Yahoo!La bandeja de entrada m?s inteligente. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Apr 23 06:59:51 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Apr 2008 04:59:51 +0000 Subject: [M3devel] FW: more path stuff, sorry In-Reply-To: <135722.70767.qm@web27113.mail.ukl.yahoo.com> References: <08DD9502-27D3-4C5C-9E30-A9E9D2CADAB4@cs.purdue.edu> <135722.70767.qm@web27113.mail.ukl.yahoo.com> Message-ID: I forgot some points.Daniel, in order to convert paths between the two, you need context to know what type the provider of the path intended. There are paths that are valid in both systems but that have different means. The path /usr/bin in Win32 is the same as \usr\bin and on the drive of the current working directory (the working, if you will)The path /usr/bin in Cygwin is \usr\bin under the Cygwin root, so often like c:\cygwin\usr\bin. The path /cygdrive/c/foo is also valid in Win32, and has a different meaning there than in Cygwin. Get it? The path c:/foo is unambiguous. The "string" c:/foo is ambiguous, depending on point of view. Let's say I want a string that contains colon delimited paths. Then this is the path c and the path /foo. But if paths themselves can have colons then it is also the single element list with the element c:/foo. You could get fancy shmancy and escape the colon c\:/foo but that's insane. Quoting is already a big problem in existing systems and usage, and I just made that garbage up. One of the points maybe the Modula-3 folks are alluding is that Pathname.T is a TYPE with an INTERFACE. It is not a "string". In many other systems a "path" is "just" a "string", it just gets pass around, and both sides party on it and hope they give it the same meaning. If your notion of type is not clear, between Win32 and Posix, then neither is the meaning. Strings are a terribly loose overused type.... This does save people from coming up with those fancy complicated difficult to learn INTERFACES, and it aids interoperability, since everyone can use a string...it's good and it's bad, the glass is half full and half empty... c:\ "looks" like a win32 path, but hey, be careful there, I'm just smiling big and wearing a crooked hat, you have interpreted it completely incorretly, eh? Types are important. I think much more so than modules. And /foo/ looks like a Posix path, but actually it's italicized text. :) Or then again, this whole email is a valid Posix path, newlines and all, since it has no embedded nuls. :) - Jay From: jayk123 at hotmail.comTo: dabenavidesd at yahoo.es; m3devel at elegosoft.comSubject: RE: [M3devel] FW: more path stuff, sorryDate: Wed, 23 Apr 2008 04:44:23 +0000 Daniel, this should address SOME but not necessarily all of your concern and questions: The underlying libraries are mostly Cygwin.Underlying THEM is another library, but the way it works, there is approximately zero "break through".Except for threads.Also, I intend, somehow, to expose FilePosix.T and FileWin32.T, besides the regular File.T.This would be part of enabling the serial package to build, using strictly "break through" and the Win32 code.However FilePosix.m3 and FileWin32.m3 both reveal File.T. I need to split the revelation out into a separate interface/module I think, shouldn't be hard. From SOME point of view, forward slashes are perfectly acceptable in Win32 paths and have the same meaning as backward slashs. It is not 100%, but largely. This isn't Modula-3 code doing any "translation" but the Modula-3 does treat \ and / equivalent upon read. The lowest level Win32 File functions in kernel32.dll -- CreateFile, DeleteFile, MoveFile, CreateDirectory, RemoveDirectory, CopyFile, GetCurrentDirectory, SetCurrentDirectory, GetFileAttributes[Ex], FindFirst[Next]File[Ex], what else am I forgetting? Maybe CreateProcess? GetFullPathName, GetShortPathName, usually consider \ and / the same. Unless the paths starts \\?. The / are all converted to \ before getting to the underlying system, the NtCreateFile, where strictly \ is the separator and there is no working directory. If a path starts \\?, it is passed on directly. You don't have to pass full paths. You can pass a handle to a parent directory. Now, I recently read, regarding NTFS-3G for Linux, about allowing : and \ in file names.The claim is that if you install SFU (Services For Unix, previously Interix, now SUA), you can access such names on NT.I tried it out. In fact this claim seems wrong. I create those paths, and then enumerated and printed from Win32. Their lower 8 bits were : and \. But their upper 8 bits were 0xF0 or 0xFF or somesuch. SFU has some ability to access unicode file names, but not that I could find that would reveal this trickery. In particular, there is like wcs_opendir that opens a directory with a unicode path, but there is only the asii/ansi/utf8/7bit/8bit/whatever readdir/readdir_r. So the 0xF000 cannot show through.And proper unicode Win32 code still doesn't see ':' or '\' per se in file names (in paths, but not individual names). I think I happened to accidentally copy this stuff to a Linux machine, and they didn't come across as ':' or '\'.Maybe I used wine cmd copy though. I should try with NTFS-3G. I do suspect I'll get ':' and '\'. Speaking of portability -- should Modula-3 on Posix systems allow file names with ':' and '\'? There are pluses and minuses. It's a rhetorical question -- in that, I don't really want to discuss it that much. I don't think there's a good answer, so I'd just as soon leave the code alone vs. trying in vain to come up with what is "correct". Yes there are Cygwin specific functions for converting paths.It would be reasonable for some NT386GNU-specific paths to use them.You can write up the *.i3 files and call them where you deem appropriate. Where deemed appropriate is not clear.It would not be great for the NT386 tools to use them -- to link to cygwin1.dll, for any reason.Maybe via LoadLibrary/GetProcAddress -- an optional dependency. Maybe.I believe "linkage" should mean "static linkage in the same file" and not "dynamic linkage in the same process" but it isn't up to me and it very well might be this way. I think the Linux kernel grants an exception, but I'm skeptical that non-GPL code doesn't dynamically link to in-proc GPL code that hasn't granted an exception. Anyway, Modula-3 except for NT386GNU is not in any uniquely worrying boat, for sure. You see, like my little speech about emulation layers and "break though", Cygwin is an emulation layer.But its users may or may not consider it to have much "break through".It's users might be very accustomed to Posix paths and a full set of Posix-path-using tools, and have no need to give any of them a Win32 path, and if they do, might be prepared to stop and think about it and do their own conversion. I think it's gray, because gcc as a compiler is arguably way more valuable than a Posix porting layer for other code.Or really, they are both useful. Some people will want one, or the other, or both, or neither. And again I am confusing Cygwin, NT386GNU, and the backend vs. the runtime. You can very well combine the integrated backend with a Posixish runtime -- remember all the systems now have the integrated backend, you should be able to output NT386 .obj files on any platform just by saying TARGET= "NT386" in cm3.cfg. And you can combine the gcc backend with a Win32 runtime -- that is what NT386MINGNU is. Also, while kernel32.dll treats / like \, other Win32 functions/libraries do not, such as comdlg32.dll (File.Open, File.Save), and shlwapi.dll, I think. You'd have to read the docs and/or experiment.Win32 has a lot of nice internal consistencies, but it isn't 100% consistent. Probably nothing is. A mix of slashes works fine on NT386. Does some of this make sense? Again again again, "NT386GNU" is different things to different people, and some of them are in fact independent and you can pick and chose which parts you compose. There is the runtime the compiler uses. There is the backend. There is the library the output uses, both the "C library" (fopen), the threading library (pthreads vs. Win32), the windowing library (X Windows vs. Win32), the naming conventions (libfoo.a vs. foo.lib). Nearly every one of these factors is independent of the others, The config files are written as such and you should be able to experiment and make your own other combinations. Three such combinations are provided, and there's sort of a tendency for the host and the target to be the same, but they don't have to be. There are other factors, like which C compiler do you use, which linker. The compiler, backend, and linker conspire to determine which debugger you can use. If you se the integrated backend and MS linker, you can use MS debuggers. If you use the gcc backend and GNU linker, you can use gdb. Oh, well you can always use either debugger, but the point here is if you have symbols or not. Currently there is some problem mixing the gcc backend with the MS linker and/or the integrated backend with the GNU linker. I think gcc backend with MS linker, and only sometimes the other. There is a symbol alway injected into the .o files that the GNU linker knows about but that the MS linker gives as unresolved. The MS linker has a different name for it, but I don't believe it is always injected by the integrated backend. This is the symbol that lets you point to the start of your image, it is __ImageBase in MS. It isn't used much. But for some reason gcc always generates references to it, and gives it a different name. Therefore some of the supposedly independent factors are not independent as they should be. For network paths, Cygwin allows //machine/server. Current Cygwin issues warnings when you use Win32 paths, and the warning says you can quash it by setting CYGWIN=nodospathwarning or somesuch. Does this make some sense? At some point maybe I'll put together distributions for other combinations. Oh, one more thing, the gcc backend can use __int64.I was feeling guilty about taking so long adding that to the integrated backend, thus I fast-forwarded and got NT386GNU to work. I should still go back and add it though. Also, currently the compiler assumes some linkage of these factors. It assumes OS_TYPE=POSIX means targeting Cygwin. Eh that's pretty much correct. At some point maybe UWin and SFU will be options, but not right now. The compiler's main concern is the jumpbuf size, which is much larger for Cygwin. You can to some extent maybe link NT386 and NT386GNU together, but this jumpbuf thing could really hurt in a hard to diagnose way. (Maybe it's safe due to setjmp vs. _setjmp?)? Sorry this is too long. As Olaf said, what I say might be very true and an accurate model, but it confuses everyone.People want very very few variables. Sorry I have to run, no proofreading this "masterpiece". - Jay Date: Wed, 23 Apr 2008 06:00:43 +0200From: dabenavidesd at yahoo.esTo: m3devel at elegosoft.comSubject: Re: [M3devel] FW: more path stuff, sorryHi all:Does pm3 treat NT386GNU paths as POSIX class? I think if one take the definition the Interface Pathname, NT386GNU target should not have access directly to use POSIX paths but Win32 ones because of:"A Pathname.T (or just a pathname) is a text conforming to the syntax of the underlying operating system" inhttp://www.opencm3.net/doc/help/gen_html/libm3/src/os/Common/Pathname.i3.htmlBut if we think in "the underlying operating system" as the cygwin api, it should be the natural POSIX paths.I agree Pathname is a common interface, but what happens with that sense of portability we want? Maybe the answer is in the cygwin api; the non-standard functions of converting one style to the other: http://cygwin.com/cygwin-api/cygwin-functions.html .See http://www.cygwin.com/cygwin-ug-net/using.html#using-pathnamesfor the main notes of compatibility. It seems clear that cygwin can use both kind of path styles, so it's not a problem to use just one of POSIX or Win32 paths. So defining a Pathname of type POSIX style for NT386GNU, it is not resign to the more capable functions of cygwin?I mean if Pathname accept both kind of forward and back slashes in different Pathnames it should be defined a new kind of Pathname syntax. Oh I remember saw the mix of both kind of slashes in pm3 quake/config files of NT386GNU :) Is this really confusing or unthinkable?I think this is clear for some of yous (NT386GNU should just accept POSIX paths, not even a Win32 one, and obviously not a mix of the two syntax in a same path), but it is not for me.In my opinion both styles should be acceptable without defining a new kind of path syntax, and convert only using the cygwin api functions. For instance when using netbios resources but also trying to mount disks partitions on the cygwin mount table file we need both kind of syntax. Is that even logical?Thanks in advance.Tony Hosking escribi?: Jay, there is an underlying principle here that you seem to be missing so I will make it explicit. Cross-product systems tend to acquire unmanageable complexity, especially when it comes to testing. By making each target one personality we are able to test machine-dependent code in isolation from machine-independent code. Often, when something breaks on one target I will test on another just to isolate the problem. This is a very powerful approach and I am very leery of destroying any ability to do this -- it allows us to maintain the high-level portability of most Modula-3 code while isolating the small fraction of machine-/target-dependent stuff. On Apr 22, 2008, at 12:28 AM, Jay wrote: [truncated]... From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] more path stuff, sorryDate: Tue, 22 Apr 2008 04:19:52 +0000There's no dependency, no linkage. Just a few simple string operations.I'll probably remove it tonight. Modula-3 has a split personality no matter what, in that it calls into very varying underlying layers, often trafficing in their specific data formats.It's just that it can strive to aid portability between them or not, by accepting either input and massaging it to work, vs. passing it along "unchanged" (well, that's not what happens actually). If there were no ambiguous cases and the Posix systems on Windows were consistent in their conventions, I'd be more for it. But the ambiguity and varying Posix conventions weaken the case tremendously. - Jay Date: Mon, 21 Apr 2008 23:14:00 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] more path stuff, sorry I concur wholeheartedly. I absolutely DO NOT want native NT386 to have any knowledge of or dependency on Cygwin. Regards, Randy>>> Tony Hosking 4/21/2008 9:44 PM >>> Why would native NT386 know anything at all about Cygwin. I say just avoid split personalities like the plague. Similarly, I'd be happy for NT386GNU (i.e., Cygwin?) to simply behave like a POSIX build (modulo native threads perhaps). On Apr 21, 2008, at 7:15 PM, Jay wrote: Maybe this is dubious.The question is, like, should native NT386 cm3 accept /cygdrive/c/foo and translate to c:\foo?Or trickier, /usr/bin/foo and translate to c:\cygwin\usr\bin\foo?And vice versa, should NT386GNU accept c:\foo?... Enviado desde Correo Yahoo!La bandeja de entrada m?s inteligente. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Apr 23 07:17:43 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Apr 2008 05:17:43 +0000 Subject: [M3devel] FW: more path stuff, sorry In-Reply-To: References: <08DD9502-27D3-4C5C-9E30-A9E9D2CADAB4@cs.purdue.edu> <135722.70767.qm@web27113.mail.ukl.yahoo.com> Message-ID: > Types are important. I think much more so than modules. But user input, esp. in the form of a command line, are ambiguous and not strongly typed, and therefore sometimes open to "sniffing", to loose interpretation, guessing what was intended. There IS a place for guessing, but not everywhere. For example maybe?: cp foo bar What does that do? Copy one file or a directory full of files? A really bad example, what does this command line do: c:\program files\microsoft visual studio\cl.exe Does it run "cl.exe" in the directory "c:\program files\microsoft visual studio". Or does it run the "program" in c:\ with parameters "files\microsoft", "visual", "studio\cl.exe"? I BELIEVE the answer is that it DEPENDS. Both can exist at the same time -- "c:\program" and "C:\program files" I BELIEVE if "c:\program" exists, it is run. I'm not sure. CreateProcess has two parameters here and so there is a way to disambiguate and execve is probably unambiguous, but system() is ambiguous and CreateProcess has an ambiguous mode since you don't have to use both parameters -- like path to .exe and command line, you can leave the first NULL, something like that it's considered poor practise. Command lines are awfully weakly typed. You know -- you need to hit those keys harder. :) Or watch this, sometimes you don't need spaces between command line parameters: D:\>dir cd foo => nothing D:\>mkdir foo D:\>cd\foo => changes into the foo directory. let's go back up: cd \ and now... enable running extensionless files: set PATHEXT=.;%PATHEXT% create one.. mkdir \cd copy %windir%\notepad.exe \cd\foo and..: cd\foo now cd\foo runs the copy of notepad. ambiguity abounds... - Jay From: jayk123 at hotmail.comTo: dabenavidesd at yahoo.es; m3devel at elegosoft.comDate: Wed, 23 Apr 2008 04:59:51 +0000Subject: Re: [M3devel] FW: more path stuff, sorry I forgot some points.Daniel, in order to convert paths between the two, you need context to know what type the provider of the path intended. There are paths that are valid in both systems but that have different means. The path /usr/bin in Win32 is the same as \usr\bin and on the drive of the current working directory (the working, if you will)The path /usr/bin in Cygwin is \usr\bin under the Cygwin root, so often like c:\cygwin\usr\bin. The path /cygdrive/c/foo is also valid in Win32, and has a different meaning there than in Cygwin. Get it? The path c:/foo is unambiguous. The "string" c:/foo is ambiguous, depending on point of view.Let's say I want a string that contains colon delimited paths.Then this is the path c and the path /foo.But if paths themselves can have colons then it is also the single element list with the element c:/foo. You could get fancy shmancy and escape the colon c\:/foo but that's insane.Quoting is already a big problem in existing systems and usage, and I just made that garbage up. One of the points maybe the Modula-3 folks are alluding is that Pathname.T is a TYPE with an INTERFACE. It is not a "string".In many other systems a "path" is "just" a "string", it just gets pass around, and both sides party on it and hope they give it the same meaning.If your notion of type is not clear, between Win32 and Posix, then neither is the meaning.Strings are a terribly loose overused type....This does save people from coming up with those fancy complicated difficult to learn INTERFACES, and it aids interoperability, since everyone can use a string...it's good and it's bad, the glass is half full and half empty... c:\ "looks" like a win32 path, but hey, be careful there, I'm just smiling big and wearing a crooked hat, you have interpreted it completely incorretly, eh? Types are important. I think much more so than modules. And /foo/ looks like a Posix path, but actually it's italicized text. :)Or then again, this whole email is a valid Posix path, newlines and all, since it has no embedded nuls. :) - Jay From: jayk123 at hotmail.comTo: dabenavidesd at yahoo.es; m3devel at elegosoft.comSubject: RE: [M3devel] FW: more path stuff, sorryDate: Wed, 23 Apr 2008 04:44:23 +0000 Daniel, this should address SOME but not necessarily all of your concern and questions: The underlying libraries are mostly Cygwin.Underlying THEM is another library, but the way it works, there is approximately zero "break through".Except for threads.Also, I intend, somehow, to expose FilePosix.T and FileWin32.T, besides the regular File.T.This would be part of enabling the serial package to build, using strictly "break through" and the Win32 code.However FilePosix.m3 and FileWin32.m3 both reveal File.T. I need to split the revelation out into a separate interface/module I think, shouldn't be hard. From SOME point of view, forward slashes are perfectly acceptable in Win32 paths and have the same meaning as backward slashs. It is not 100%, but largely. This isn't Modula-3 code doing any "translation" but the Modula-3 does treat \ and / equivalent upon read. The lowest level Win32 File functions in kernel32.dll -- CreateFile, DeleteFile, MoveFile, CreateDirectory, RemoveDirectory, CopyFile, GetCurrentDirectory, SetCurrentDirectory, GetFileAttributes[Ex], FindFirst[Next]File[Ex], what else am I forgetting? Maybe CreateProcess? GetFullPathName, GetShortPathName, usually consider \ and / the same. Unless the paths starts \\?. The / are all converted to \ before getting to the underlying system, the NtCreateFile, where strictly \ is the separator and there is no working directory. If a path starts \\?, it is passed on directly. You don't have to pass full paths. You can pass a handle to a parent directory. Now, I recently read, regarding NTFS-3G for Linux, about allowing : and \ in file names.The claim is that if you install SFU (Services For Unix, previously Interix, now SUA), you can access such names on NT.I tried it out. In fact this claim seems wrong. I create those paths, and then enumerated and printed from Win32. Their lower 8 bits were : and \. But their upper 8 bits were 0xF0 or 0xFF or somesuch. SFU has some ability to access unicode file names, but not that I could find that would reveal this trickery. In particular, there is like wcs_opendir that opens a directory with a unicode path, but there is only the asii/ansi/utf8/7bit/8bit/whatever readdir/readdir_r. So the 0xF000 cannot show through.And proper unicode Win32 code still doesn't see ':' or '\' per se in file names (in paths, but not individual names). I think I happened to accidentally copy this stuff to a Linux machine, and they didn't come across as ':' or '\'.Maybe I used wine cmd copy though. I should try with NTFS-3G. I do suspect I'll get ':' and '\'. Speaking of portability -- should Modula-3 on Posix systems allow file names with ':' and '\'? There are pluses and minuses. It's a rhetorical question -- in that, I don't really want to discuss it that much. I don't think there's a good answer, so I'd just as soon leave the code alone vs. trying in vain to come up with what is "correct". Yes there are Cygwin specific functions for converting paths.It would be reasonable for some NT386GNU-specific paths to use them.You can write up the *.i3 files and call them where you deem appropriate. Where deemed appropriate is not clear.It would not be great for the NT386 tools to use them -- to link to cygwin1.dll, for any reason.Maybe via LoadLibrary/GetProcAddress -- an optional dependency. Maybe.I believe "linkage" should mean "static linkage in the same file" and not "dynamic linkage in the same process" but it isn't up to me and it very well might be this way. I think the Linux kernel grants an exception, but I'm skeptical that non-GPL code doesn't dynamically link to in-proc GPL code that hasn't granted an exception. Anyway, Modula-3 except for NT386GNU is not in any uniquely worrying boat, for sure. You see, like my little speech about emulation layers and "break though", Cygwin is an emulation layer.But its users may or may not consider it to have much "break through".It's users might be very accustomed to Posix paths and a full set of Posix-path-using tools, and have no need to give any of them a Win32 path, and if they do, might be prepared to stop and think about it and do their own conversion. I think it's gray, because gcc as a compiler is arguably way more valuable than a Posix porting layer for other code.Or really, they are both useful. Some people will want one, or the other, or both, or neither. And again I am confusing Cygwin, NT386GNU, and the backend vs. the runtime. You can very well combine the integrated backend with a Posixish runtime -- remember all the systems now have the integrated backend, you should be able to output NT386 .obj files on any platform just by saying TARGET= "NT386" in cm3.cfg. And you can combine the gcc backend with a Win32 runtime -- that is what NT386MINGNU is. Also, while kernel32.dll treats / like \, other Win32 functions/libraries do not, such as comdlg32.dll (File.Open, File.Save), and shlwapi.dll, I think. You'd have to read the docs and/or experiment.Win32 has a lot of nice internal consistencies, but it isn't 100% consistent. Probably nothing is. A mix of slashes works fine on NT386. Does some of this make sense? Again again again, "NT386GNU" is different things to different people, and some of them are in fact independent and you can pick and chose which parts you compose. There is the runtime the compiler uses. There is the backend. There is the library the output uses, both the "C library" (fopen), the threading library (pthreads vs. Win32), the windowing library (X Windows vs. Win32), the naming conventions (libfoo.a vs. foo.lib). Nearly every one of these factors is independent of the others, The config files are written as such and you should be able to experiment and make your own other combinations. Three such combinations are provided, and there's sort of a tendency for the host and the target to be the same, but they don't have to be. There are other factors, like which C compiler do you use, which linker. The compiler, backend, and linker conspire to determine which debugger you can use. If you se the integrated backend and MS linker, you can use MS debuggers. If you use the gcc backend and GNU linker, you can use gdb. Oh, well you can always use either debugger, but the point here is if you have symbols or not. Currently there is some problem mixing the gcc backend with the MS linker and/or the integrated backend with the GNU linker. I think gcc backend with MS linker, and only sometimes the other. There is a symbol alway injected into the .o files that the GNU linker knows about but that the MS linker gives as unresolved. The MS linker has a different name for it, but I don't believe it is always injected by the integrated backend. This is the symbol that lets you point to the start of your image, it is __ImageBase in MS. It isn't used much. But for some reason gcc always generates references to it, and gives it a different name. Therefore some of the supposedly independent factors are not independent as they should be. For network paths, Cygwin allows //machine/server. Current Cygwin issues warnings when you use Win32 paths, and the warning says you can quash it by setting CYGWIN=nodospathwarning or somesuch. Does this make some sense? At some point maybe I'll put together distributions for other combinations. Oh, one more thing, the gcc backend can use __int64.I was feeling guilty about taking so long adding that to the integrated backend, thus I fast-forwarded and got NT386GNU to work. I should still go back and add it though. Also, currently the compiler assumes some linkage of these factors. It assumes OS_TYPE=POSIX means targeting Cygwin. Eh that's pretty much correct. At some point maybe UWin and SFU will be options, but not right now. The compiler's main concern is the jumpbuf size, which is much larger for Cygwin. You can to some extent maybe link NT386 and NT386GNU together, but this jumpbuf thing could really hurt in a hard to diagnose way. (Maybe it's safe due to setjmp vs. _setjmp?)? Sorry this is too long. As Olaf said, what I say might be very true and an accurate model, but it confuses everyone.People want very very few variables. Sorry I have to run, no proofreading this "masterpiece". - Jay Date: Wed, 23 Apr 2008 06:00:43 +0200From: dabenavidesd at yahoo.esTo: m3devel at elegosoft.comSubject: Re: [M3devel] FW: more path stuff, sorryHi all:Does pm3 treat NT386GNU paths as POSIX class? I think if one take the definition the Interface Pathname, NT386GNU target should not have access directly to use POSIX paths but Win32 ones because of:"A Pathname.T (or just a pathname) is a text conforming to the syntax of the underlying operating system" inhttp://www.opencm3.net/doc/help/gen_html/libm3/src/os/Common/Pathname.i3.htmlBut if we think in "the underlying operating system" as the cygwin api, it should be the natural POSIX paths.I agree Pathname is a common interface, but what happens with that sense of portability we want? Maybe the answer is in the cygwin api; the non-standard functions of converting one style to the other: http://cygwin.com/cygwin-api/cygwin-functions.html .See http://www.cygwin.com/cygwin-ug-net/using.html#using-pathnamesfor the main notes of compatibility. It seems clear that cygwin can use both kind of path styles, so it's not a problem to use just one of POSIX or Win32 paths. So defining a Pathname of type POSIX style for NT386GNU, it is not resign to the more capable functions of cygwin?I mean if Pathname accept both kind of forward and back slashes in different Pathnames it should be defined a new kind of Pathname syntax. Oh I remember saw the mix of both kind of slashes in pm3 quake/config files of NT386GNU :) Is this really confusing or unthinkable?I think this is clear for some of yous (NT386GNU should just accept POSIX paths, not even a Win32 one, and obviously not a mix of the two syntax in a same path), but it is not for me.In my opinion both styles should be acceptable without defining a new kind of path syntax, and convert only using the cygwin api functions. For instance when using netbios resources but also trying to mount disks partitions on the cygwin mount table file we need both kind of syntax. Is that even logical?Thanks in advance.Tony Hosking escribi?: Jay, there is an underlying principle here that you seem to be missing so I will make it explicit. Cross-product systems tend to acquire unmanageable complexity, especially when it comes to testing. By making each target one personality we are able to test machine-dependent code in isolation from machine-independent code. Often, when something breaks on one target I will test on another just to isolate the problem. This is a very powerful approach and I am very leery of destroying any ability to do this -- it allows us to maintain the high-level portability of most Modula-3 code while isolating the small fraction of machine-/target-dependent stuff. On Apr 22, 2008, at 12:28 AM, Jay wrote: [truncated]... From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] more path stuff, sorryDate: Tue, 22 Apr 2008 04:19:52 +0000There's no dependency, no linkage. Just a few simple string operations.I'll probably remove it tonight. Modula-3 has a split personality no matter what, in that it calls into very varying underlying layers, often trafficing in their specific data formats.It's just that it can strive to aid portability between them or not, by accepting either input and massaging it to work, vs. passing it along "unchanged" (well, that's not what happens actually). If there were no ambiguous cases and the Posix systems on Windows were consistent in their conventions, I'd be more for it. But the ambiguity and varying Posix conventions weaken the case tremendously. - Jay Date: Mon, 21 Apr 2008 23:14:00 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] more path stuff, sorry I concur wholeheartedly. I absolutely DO NOT want native NT386 to have any knowledge of or dependency on Cygwin. Regards, Randy>>> Tony Hosking 4/21/2008 9:44 PM >>> Why would native NT386 know anything at all about Cygwin. I say just avoid split personalities like the plague. Similarly, I'd be happy for NT386GNU (i.e., Cygwin?) to simply behave like a POSIX build (modulo native threads perhaps). On Apr 21, 2008, at 7:15 PM, Jay wrote: Maybe this is dubious.The question is, like, should native NT386 cm3 accept /cygdrive/c/foo and translate to c:\foo?Or trickier, /usr/bin/foo and translate to c:\cygwin\usr\bin\foo?And vice versa, should NT386GNU accept c:\foo?... Enviado desde Correo Yahoo!La bandeja de entrada m?s inteligente. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Apr 23 07:20:12 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Apr 2008 05:20:12 +0000 Subject: [M3devel] FW: more path stuff, sorry In-Reply-To: References: <08DD9502-27D3-4C5C-9E30-A9E9D2CADAB4@cs.purdue.edu> <135722.70767.qm@web27113.mail.ukl.yahoo.com> Message-ID: > enable running extensionless files: > set PATHEXT=.;%PATHEXT% Oh, hey, better yet: mkdir \cd\foo.exe, then you don't need to alter PATHEXT. Directories with extensions often occuring on files..that might cause some interesting problems.. - Jay From: jayk123 at hotmail.comTo: dabenavidesd at yahoo.es; m3devel at elegosoft.comSubject: RE: [M3devel] FW: more path stuff, sorryDate: Wed, 23 Apr 2008 05:17:43 +0000 > Types are important. I think much more so than modules.But user input, esp. in the form of a command line, are ambiguous and not strongly typed, and therefore sometimes open to "sniffing", to loose interpretation, guessing what was intended. There IS a place for guessing, but not everywhere. For example maybe?: cp foo bar What does that do? Copy one file or a directory full of files? A really bad example, what does this command line do: c:\program files\microsoft visual studio\cl.exe Does it run "cl.exe" in the directory "c:\program files\microsoft visual studio".Or does it run the "program" in c:\ with parameters "files\microsoft", "visual", "studio\cl.exe"? I BELIEVE the answer is that it DEPENDS. Both can exist at the same time -- "c:\program" and "C:\program files" I BELIEVE if "c:\program" exists, it is run.I'm not sure. CreateProcess has two parameters here and so there is a way to disambiguate and execve is probably unambiguous, but system() is ambiguous and CreateProcess has an ambiguous mode since you don't have to use both parameters -- like path to .exe and command line, you can leave the first NULL, something like that it's considered poor practise. Command lines are awfully weakly typed.You know -- you need to hit those keys harder. :) Or watch this, sometimes you don't need spaces between command line parameters: D:\>dir cd foo => nothing D:\>mkdir fooD:\>cd\foo => changes into the foo directory. let's go back up:cd \ and now...enable running extensionless files: set PATHEXT=.;%PATHEXT% create one.. mkdir \cd copy %windir%\notepad.exe \cd\foo and..: cd\foo now cd\foo runs the copy of notepad. ambiguity abounds... - Jay From: jayk123 at hotmail.comTo: dabenavidesd at yahoo.es; m3devel at elegosoft.comDate: Wed, 23 Apr 2008 04:59:51 +0000Subject: Re: [M3devel] FW: more path stuff, sorry I forgot some points.Daniel, in order to convert paths between the two, you need context to know what type the provider of the path intended. There are paths that are valid in both systems but that have different means. The path /usr/bin in Win32 is the same as \usr\bin and on the drive of the current working directory (the working, if you will)The path /usr/bin in Cygwin is \usr\bin under the Cygwin root, so often like c:\cygwin\usr\bin. The path /cygdrive/c/foo is also valid in Win32, and has a different meaning there than in Cygwin. Get it? The path c:/foo is unambiguous. The "string" c:/foo is ambiguous, depending on point of view.Let's say I want a string that contains colon delimited paths.Then this is the path c and the path /foo.But if paths themselves can have colons then it is also the single element list with the element c:/foo. You could get fancy shmancy and escape the colon c\:/foo but that's insane.Quoting is already a big problem in existing systems and usage, and I just made that garbage up. One of the points maybe the Modula-3 folks are alluding is that Pathname.T is a TYPE with an INTERFACE. It is not a "string".In many other systems a "path" is "just" a "string", it just gets pass around, and both sides party on it and hope they give it the same meaning.If your notion of type is not clear, between Win32 and Posix, then neither is the meaning.Strings are a terribly loose overused type....This does save people from coming up with those fancy complicated difficult to learn INTERFACES, and it aids interoperability, since everyone can use a string...it's good and it's bad, the glass is half full and half empty... c:\ "looks" like a win32 path, but hey, be careful there, I'm just smiling big and wearing a crooked hat, you have interpreted it completely incorretly, eh? Types are important. I think much more so than modules. And /foo/ looks like a Posix path, but actually it's italicized text. :)Or then again, this whole email is a valid Posix path, newlines and all, since it has no embedded nuls. :) - Jay From: jayk123 at hotmail.comTo: dabenavidesd at yahoo.es; m3devel at elegosoft.comSubject: RE: [M3devel] FW: more path stuff, sorryDate: Wed, 23 Apr 2008 04:44:23 +0000 Daniel, this should address SOME but not necessarily all of your concern and questions: The underlying libraries are mostly Cygwin.Underlying THEM is another library, but the way it works, there is approximately zero "break through".Except for threads.Also, I intend, somehow, to expose FilePosix.T and FileWin32.T, besides the regular File.T.This would be part of enabling the serial package to build, using strictly "break through" and the Win32 code.However FilePosix.m3 and FileWin32.m3 both reveal File.T. I need to split the revelation out into a separate interface/module I think, shouldn't be hard. From SOME point of view, forward slashes are perfectly acceptable in Win32 paths and have the same meaning as backward slashs. It is not 100%, but largely. This isn't Modula-3 code doing any "translation" but the Modula-3 does treat \ and / equivalent upon read. The lowest level Win32 File functions in kernel32.dll -- CreateFile, DeleteFile, MoveFile, CreateDirectory, RemoveDirectory, CopyFile, GetCurrentDirectory, SetCurrentDirectory, GetFileAttributes[Ex], FindFirst[Next]File[Ex], what else am I forgetting? Maybe CreateProcess? GetFullPathName, GetShortPathName, usually consider \ and / the same. Unless the paths starts \\?. The / are all converted to \ before getting to the underlying system, the NtCreateFile, where strictly \ is the separator and there is no working directory. If a path starts \\?, it is passed on directly. You don't have to pass full paths. You can pass a handle to a parent directory. Now, I recently read, regarding NTFS-3G for Linux, about allowing : and \ in file names.The claim is that if you install SFU (Services For Unix, previously Interix, now SUA), you can access such names on NT.I tried it out. In fact this claim seems wrong. I create those paths, and then enumerated and printed from Win32. Their lower 8 bits were : and \. But their upper 8 bits were 0xF0 or 0xFF or somesuch. SFU has some ability to access unicode file names, but not that I could find that would reveal this trickery. In particular, there is like wcs_opendir that opens a directory with a unicode path, but there is only the asii/ansi/utf8/7bit/8bit/whatever readdir/readdir_r. So the 0xF000 cannot show through.And proper unicode Win32 code still doesn't see ':' or '\' per se in file names (in paths, but not individual names). I think I happened to accidentally copy this stuff to a Linux machine, and they didn't come across as ':' or '\'.Maybe I used wine cmd copy though. I should try with NTFS-3G. I do suspect I'll get ':' and '\'. Speaking of portability -- should Modula-3 on Posix systems allow file names with ':' and '\'? There are pluses and minuses. It's a rhetorical question -- in that, I don't really want to discuss it that much. I don't think there's a good answer, so I'd just as soon leave the code alone vs. trying in vain to come up with what is "correct". Yes there are Cygwin specific functions for converting paths.It would be reasonable for some NT386GNU-specific paths to use them.You can write up the *.i3 files and call them where you deem appropriate. Where deemed appropriate is not clear.It would not be great for the NT386 tools to use them -- to link to cygwin1.dll, for any reason.Maybe via LoadLibrary/GetProcAddress -- an optional dependency. Maybe.I believe "linkage" should mean "static linkage in the same file" and not "dynamic linkage in the same process" but it isn't up to me and it very well might be this way. I think the Linux kernel grants an exception, but I'm skeptical that non-GPL code doesn't dynamically link to in-proc GPL code that hasn't granted an exception. Anyway, Modula-3 except for NT386GNU is not in any uniquely worrying boat, for sure. You see, like my little speech about emulation layers and "break though", Cygwin is an emulation layer.But its users may or may not consider it to have much "break through".It's users might be very accustomed to Posix paths and a full set of Posix-path-using tools, and have no need to give any of them a Win32 path, and if they do, might be prepared to stop and think about it and do their own conversion. I think it's gray, because gcc as a compiler is arguably way more valuable than a Posix porting layer for other code.Or really, they are both useful. Some people will want one, or the other, or both, or neither. And again I am confusing Cygwin, NT386GNU, and the backend vs. the runtime. You can very well combine the integrated backend with a Posixish runtime -- remember all the systems now have the integrated backend, you should be able to output NT386 .obj files on any platform just by saying TARGET= "NT386" in cm3.cfg. And you can combine the gcc backend with a Win32 runtime -- that is what NT386MINGNU is. Also, while kernel32.dll treats / like \, other Win32 functions/libraries do not, such as comdlg32.dll (File.Open, File.Save), and shlwapi.dll, I think. You'd have to read the docs and/or experiment.Win32 has a lot of nice internal consistencies, but it isn't 100% consistent. Probably nothing is. A mix of slashes works fine on NT386. Does some of this make sense? Again again again, "NT386GNU" is different things to different people, and some of them are in fact independent and you can pick and chose which parts you compose. There is the runtime the compiler uses. There is the backend. There is the library the output uses, both the "C library" (fopen), the threading library (pthreads vs. Win32), the windowing library (X Windows vs. Win32), the naming conventions (libfoo.a vs. foo.lib). Nearly every one of these factors is independent of the others, The config files are written as such and you should be able to experiment and make your own other combinations. Three such combinations are provided, and there's sort of a tendency for the host and the target to be the same, but they don't have to be. There are other factors, like which C compiler do you use, which linker. The compiler, backend, and linker conspire to determine which debugger you can use. If you se the integrated backend and MS linker, you can use MS debuggers. If you use the gcc backend and GNU linker, you can use gdb. Oh, well you can always use either debugger, but the point here is if you have symbols or not. Currently there is some problem mixing the gcc backend with the MS linker and/or the integrated backend with the GNU linker. I think gcc backend with MS linker, and only sometimes the other. There is a symbol alway injected into the .o files that the GNU linker knows about but that the MS linker gives as unresolved. The MS linker has a different name for it, but I don't believe it is always injected by the integrated backend. This is the symbol that lets you point to the start of your image, it is __ImageBase in MS. It isn't used much. But for some reason gcc always generates references to it, and gives it a different name. Therefore some of the supposedly independent factors are not independent as they should be. For network paths, Cygwin allows //machine/server. Current Cygwin issues warnings when you use Win32 paths, and the warning says you can quash it by setting CYGWIN=nodospathwarning or somesuch. Does this make some sense? At some point maybe I'll put together distributions for other combinations. Oh, one more thing, the gcc backend can use __int64.I was feeling guilty about taking so long adding that to the integrated backend, thus I fast-forwarded and got NT386GNU to work. I should still go back and add it though. Also, currently the compiler assumes some linkage of these factors. It assumes OS_TYPE=POSIX means targeting Cygwin. Eh that's pretty much correct. At some point maybe UWin and SFU will be options, but not right now. The compiler's main concern is the jumpbuf size, which is much larger for Cygwin. You can to some extent maybe link NT386 and NT386GNU together, but this jumpbuf thing could really hurt in a hard to diagnose way. (Maybe it's safe due to setjmp vs. _setjmp?)? Sorry this is too long. As Olaf said, what I say might be very true and an accurate model, but it confuses everyone.People want very very few variables. Sorry I have to run, no proofreading this "masterpiece". - Jay Date: Wed, 23 Apr 2008 06:00:43 +0200From: dabenavidesd at yahoo.esTo: m3devel at elegosoft.comSubject: Re: [M3devel] FW: more path stuff, sorryHi all:Does pm3 treat NT386GNU paths as POSIX class? I think if one take the definition the Interface Pathname, NT386GNU target should not have access directly to use POSIX paths but Win32 ones because of:"A Pathname.T (or just a pathname) is a text conforming to the syntax of the underlying operating system" inhttp://www.opencm3.net/doc/help/gen_html/libm3/src/os/Common/Pathname.i3.htmlBut if we think in "the underlying operating system" as the cygwin api, it should be the natural POSIX paths.I agree Pathname is a common interface, but what happens with that sense of portability we want? Maybe the answer is in the cygwin api; the non-standard functions of converting one style to the other: http://cygwin.com/cygwin-api/cygwin-functions.html .See http://www.cygwin.com/cygwin-ug-net/using.html#using-pathnamesfor the main notes of compatibility. It seems clear that cygwin can use both kind of path styles, so it's not a problem to use just one of POSIX or Win32 paths. So defining a Pathname of type POSIX style for NT386GNU, it is not resign to the more capable functions of cygwin?I mean if Pathname accept both kind of forward and back slashes in different Pathnames it should be defined a new kind of Pathname syntax. Oh I remember saw the mix of both kind of slashes in pm3 quake/config files of NT386GNU :) Is this really confusing or unthinkable?I think this is clear for some of yous (NT386GNU should just accept POSIX paths, not even a Win32 one, and obviously not a mix of the two syntax in a same path), but it is not for me.In my opinion both styles should be acceptable without defining a new kind of path syntax, and convert only using the cygwin api functions. For instance when using netbios resources but also trying to mount disks partitions on the cygwin mount table file we need both kind of syntax. Is that even logical?Thanks in advance.Tony Hosking escribi?: Jay, there is an underlying principle here that you seem to be missing so I will make it explicit. Cross-product systems tend to acquire unmanageable complexity, especially when it comes to testing. By making each target one personality we are able to test machine-dependent code in isolation from machine-independent code. Often, when something breaks on one target I will test on another just to isolate the problem. This is a very powerful approach and I am very leery of destroying any ability to do this -- it allows us to maintain the high-level portability of most Modula-3 code while isolating the small fraction of machine-/target-dependent stuff. On Apr 22, 2008, at 12:28 AM, Jay wrote: [truncated]... From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] more path stuff, sorryDate: Tue, 22 Apr 2008 04:19:52 +0000There's no dependency, no linkage. Just a few simple string operations.I'll probably remove it tonight. Modula-3 has a split personality no matter what, in that it calls into very varying underlying layers, often trafficing in their specific data formats.It's just that it can strive to aid portability between them or not, by accepting either input and massaging it to work, vs. passing it along "unchanged" (well, that's not what happens actually). If there were no ambiguous cases and the Posix systems on Windows were consistent in their conventions, I'd be more for it. But the ambiguity and varying Posix conventions weaken the case tremendously. - Jay Date: Mon, 21 Apr 2008 23:14:00 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] more path stuff, sorry I concur wholeheartedly. I absolutely DO NOT want native NT386 to have any knowledge of or dependency on Cygwin. Regards, Randy>>> Tony Hosking 4/21/2008 9:44 PM >>> Why would native NT386 know anything at all about Cygwin. I say just avoid split personalities like the plague. Similarly, I'd be happy for NT386GNU (i.e., Cygwin?) to simply behave like a POSIX build (modulo native threads perhaps). On Apr 21, 2008, at 7:15 PM, Jay wrote: Maybe this is dubious.The question is, like, should native NT386 cm3 accept /cygdrive/c/foo and translate to c:\foo?Or trickier, /usr/bin/foo and translate to c:\cygwin\usr\bin\foo?And vice versa, should NT386GNU accept c:\foo?... Enviado desde Correo Yahoo!La bandeja de entrada m?s inteligente. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Apr 23 15:06:12 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 23 Apr 2008 09:06:12 -0400 Subject: [M3devel] FW: more path stuff, sorry In-Reply-To: References: <08DD9502-27D3-4C5C-9E30-A9E9D2CADAB4@cs.purdue.edu> <135722.70767.qm@web27113.mail.ukl.yahoo.com> Message-ID: <2CB6197F-E4CA-4D05-8363-BA18A60B0DF3@cs.purdue.edu> Jay, Daniel was referring to PM3, not CM3. 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 Apr 23, 2008, at 12:44 AM, Jay wrote: > Daniel, this should address SOME but not necessarily all of your > concern and questions: > > The underlying libraries are mostly Cygwin. > Underlying THEM is another library, but the way it works, there is > approximately zero "break through". > Except for threads. > Also, I intend, somehow, to expose FilePosix.T and FileWin32.T, > besides the regular File.T. > This would be part of enabling the serial package to build, using > strictly "break through" and the Win32 code. > However FilePosix.m3 and FileWin32.m3 both reveal File.T. I need to > split the revelation out into a separate interface/module I think, > shouldn't be hard. > > >From SOME point of view, forward slashes are perfectly acceptable > in Win32 paths and have the same meaning as backward slashs. It is > not 100%, but largely. This isn't Modula-3 code doing any > "translation" but the Modula-3 does treat \ and / equivalent upon > read. > > The lowest level Win32 File functions in kernel32.dll -- CreateFile, > DeleteFile, MoveFile, CreateDirectory, RemoveDirectory, CopyFile, > GetCurrentDirectory, SetCurrentDirectory, GetFileAttributes[Ex], > FindFirst[Next]File[Ex], what else am I forgetting? Maybe > CreateProcess? GetFullPathName, GetShortPathName, usually consider \ > and / the same. Unless the paths starts \\?. The / are all converted > to \ before getting to the underlying system, the NtCreateFile, > where strictly \ is the separator and there is no working directory. > If a path starts \\?, it is passed on directly. You don't have to > pass full paths. You can pass a handle to a parent directory. > > Now, I recently read, regarding NTFS-3G for Linux, about allowing : > and \ in file names. > The claim is that if you install SFU (Services For Unix, previously > Interix, now SUA), you can access such names on NT. > I tried it out. In fact this claim seems wrong. I create those > paths, and then enumerated and printed from Win32. Their lower 8 > bits were : and \. But their upper 8 bits were 0xF0 or 0xFF or > somesuch. SFU has some ability to access unicode file names, but not > that I could find that would reveal this trickery. In particular, > there is like wcs_opendir that opens a directory with a unicode > path, but there is only the asii/ansi/utf8/7bit/8bit/whatever > readdir/readdir_r. So the 0xF000 cannot show through. > And proper unicode Win32 code still doesn't see ':' or '\' per se in > file names (in paths, but not individual names). > > I think I happened to accidentally copy this stuff to a Linux > machine, and they didn't come across as ':' or '\'. > Maybe I used wine cmd copy though. I should try with NTFS-3G. I do > suspect I'll get ':' and '\'. > > Speaking of portability -- should Modula-3 on Posix systems allow > file names with ':' and '\'? There are pluses and minuses. It's a > rhetorical question -- in that, I don't really want to discuss it > that much. I don't think there's a good answer, so I'd just as soon > leave the code alone vs. trying in vain to come up with what is > "correct". > > Yes there are Cygwin specific functions for converting paths. > It would be reasonable for some NT386GNU-specific paths to use them. > You can write up the *.i3 files and call them where you deem > appropriate. > Where deemed appropriate is not clear. > It would not be great for the NT386 tools to use them -- to link to > cygwin1.dll, for any reason. > Maybe via LoadLibrary/GetProcAddress -- an optional dependency. Maybe. > > I believe "linkage" should mean "static linkage in the same file" > and not "dynamic linkage in the same process" but it isn't up to me > and it very well might be this way. I think the Linux kernel grants > an exception, but I'm skeptical that non-GPL code doesn't > dynamically link to in-proc GPL code that hasn't granted an > exception. Anyway, Modula-3 except for NT386GNU is not in any > uniquely worrying boat, for sure. > > You see, like my little speech about emulation layers and "break > though", Cygwin is an emulation layer. > But its users may or may not consider it to have much "break through". > It's users might be very accustomed to Posix paths and a full set of > Posix-path-using tools, and have no need to give any of them a Win32 > path, and if they do, might be prepared to stop and think about it > and do their own conversion. > > I think it's gray, because gcc as a compiler is arguably way more > valuable than a Posix porting layer for other code. > Or really, they are both useful. Some people will want one, or the > other, or both, or neither. > > And again I am confusing Cygwin, NT386GNU, and the backend vs. the > runtime. > > You can very well combine the integrated backend with a Posixish > runtime -- remember all the systems now have the integrated backend, > you should be able to output NT386 .obj files on any platform just > by saying TARGET= "NT386" in cm3.cfg. > > And you can combine the gcc backend with a Win32 runtime -- that is > what NT386MINGNU is. > > Also, while kernel32.dll treats / like \, other Win32 functions/ > libraries do not, such as comdlg32.dll (File.Open, File.Save), and > shlwapi.dll, I think. You'd have to read the docs and/or experiment. > Win32 has a lot of nice internal consistencies, but it isn't 100% > consistent. Probably nothing is. > > A mix of slashes works fine on NT386. > > Does some of this make sense? > > Again again again, "NT386GNU" is different things to different > people, and some of them are in fact independent and you can pick > and chose which parts you compose. There is the runtime the compiler > uses. There is the backend. There is the library the output uses, > both the "C library" (fopen), the threading library (pthreads vs. > Win32), the windowing library (X Windows vs. Win32), the naming > conventions (libfoo.a vs. foo.lib). Nearly every one of these > factors is independent of the others, The config files are written > as such and you should be able to experiment and make your own other > combinations. Three such combinations are provided, and there's sort > of a tendency for the host and the target to be the same, but they > don't have to be. There are other factors, like which C compiler do > you use, which linker. The compiler, backend, and linker conspire to > determine which debugger you can use. If you se the integrated > backend and MS linker, you can use MS debuggers. If you use the gcc > backend and GNU linker, you can use gdb. Oh, well you can always use > either debugger, but the point here is if you have symbols or not. > Currently there is some problem mixing the gcc backend with the MS > linker and/or the integrated backend with the GNU linker. I think > gcc backend with MS linker, and only sometimes the other. There is a > symbol alway injected into the .o files that the GNU linker knows > about but that the MS linker gives as unresolved. The MS linker has > a different name for it, but I don't believe it is always injected > by the integrated backend. This is the symbol that lets you point to > the start of your image, it is __ImageBase in MS. It isn't used > much. But for some reason gcc always generates references to it, and > gives it a different name. Therefore some of the supposedly > independent factors are not independent as they should be. > > For network paths, Cygwin allows //machine/server. > > Current Cygwin issues warnings when you use Win32 paths, and the > warning says you can quash it by setting CYGWIN=nodospathwarning or > somesuch. > > Does this make some sense? > > At some point maybe I'll put together distributions for other > combinations. > > Oh, one more thing, the gcc backend can use __int64. > I was feeling guilty about taking so long adding that to the > integrated backend, thus I fast-forwarded and got NT386GNU to work. > I should still go back and add it though. > > Also, currently the compiler assumes some linkage of these factors. > It assumes OS_TYPE=POSIX means targeting Cygwin. Eh that's pretty > much correct. At some point maybe UWin and SFU will be options, but > not right now. The compiler's main concern is the jumpbuf size, > which is much larger for Cygwin. You can to some extent maybe link > NT386 and NT386GNU together, but this jumpbuf thing could really > hurt in a hard to diagnose way. (Maybe it's safe due to setjmp vs. > _setjmp?)? > > Sorry this is too long. As Olaf said, what I say might be very true > and an accurate model, but it confuses everyone. > People want very very few variables. > > Sorry I have to run, no proofreading this "masterpiece". deprecating humor inserted here.> > > > - Jay > > Date: Wed, 23 Apr 2008 06:00:43 +0200 > From: dabenavidesd at yahoo.es > To: m3devel at elegosoft.com > Subject: Re: [M3devel] FW: more path stuff, sorry > > Hi all: > Does pm3 treat NT386GNU paths as POSIX class? I think if one take > the definition the Interface Pathname, NT386GNU target should not > have access directly to use POSIX paths but Win32 ones because of: > "A Pathname.T (or just a pathname) is a text conforming to the > syntax of the underlying operating system" in > http://www.opencm3.net/doc/help/gen_html/libm3/src/os/Common/Pathname.i3.html > But if we think in "the underlying operating system" as the cygwin > api, it should be the natural POSIX paths. > I agree Pathname is a common interface, but what happens with that > sense of portability we want? Maybe the answer is in the cygwin api; > the non-standard functions of converting one style to the other: http://cygwin.com/cygwin-api/cygwin-functions.html > . > See http://www.cygwin.com/cygwin-ug-net/using.html#using-pathnames > for the main notes of compatibility. It seems clear that cygwin can > use both kind of path styles, so it's not a problem to use just one > of POSIX or Win32 paths. So defining a Pathname of type POSIX style > for NT386GNU, it is not resign to the more capable functions of > cygwin? > I mean if Pathname accept both kind of forward and back slashes in > different Pathnames it should be defined a new kind of Pathname > syntax. Oh I remember saw the mix of both kind of slashes in pm3 > quake/config files of NT386GNU :) Is this really confusing or > unthinkable? > I think this is clear for some of yous (NT386GNU should just accept > POSIX paths, not even a Win32 one, and obviously not a mix of the > two syntax in a same path), but it is not for me. > In my opinion both styles should be acceptable without defining a > new kind of path syntax, and convert only using the cygwin api > functions. For instance when using netbios resources but also trying > to mount disks partitions on the cygwin mount table file we need > both kind of syntax. Is that even logical? > Thanks in advance. > > Tony Hosking escribi?: > Jay, there is an underlying principle here that you seem to be > missing so I will make it explicit. Cross-product systems tend to > acquire unmanageable complexity, especially when it comes to > testing. By making each target one personality we are able to test > machine-dependent code in isolation from machine-independent code. > Often, when something breaks on one target I will test on another > just to isolate the problem. This is a very powerful approach and I > am very leery of destroying any ability to do this -- it allows us > to maintain the high-level portability of most Modula-3 code while > isolating the small fraction of machine-/target-dependent stuff. > > > > On Apr 22, 2008, at 12:28 AM, Jay wrote: > > [truncated]... > > > > > From: jayk123 at hotmail.com > To: rcoleburn at scires.com; m3devel at elegosoft.com > Subject: RE: [M3devel] more path stuff, sorry > Date: Tue, 22 Apr 2008 04:19:52 +0000 > > There's no dependency, no linkage. Just a few simple string > operations. > I'll probably remove it tonight. > > Modula-3 has a split personality no matter what, in that it calls > into very varying underlying layers, often trafficing in their > specific data formats. > It's just that it can strive to aid portability between them or not, > by accepting either input and massaging it to work, vs. passing it > along "unchanged" (well, that's not what happens actually). If there > were no ambiguous cases and the Posix systems on Windows were > consistent in their conventions, I'd be more for it. But the > ambiguity and varying Posix conventions weaken the case tremendously. > > - Jay > > Date: Mon, 21 Apr 2008 23:14:00 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] more path stuff, sorry > > I concur wholeheartedly. I absolutely DO NOT want native NT386 to > have any knowledge of or dependency on Cygwin. > Regards, > Randy > > >>> Tony Hosking 4/21/2008 9:44 PM >>> > Why would native NT386 know anything at all about Cygwin. I say > just avoid split personalities like the plague. Similarly, I'd be > happy for NT386GNU (i.e., Cygwin?) to simply behave like a POSIX > build (modulo native threads perhaps). > > On Apr 21, 2008, at 7:15 PM, Jay wrote: > > Maybe this is dubious. > > The question is, like, should native NT386 cm3 accept /cygdrive/c/ > foo and translate to c:\foo? > Or trickier, /usr/bin/foo and translate to c:\cygwin\usr\bin\foo? > And vice versa, should NT386GNU accept c:\foo? > > ... > > > > Enviado desde Correo Yahoo! > La bandeja de entrada m?s inteligente. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Apr 23 17:20:41 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Apr 2008 15:20:41 +0000 Subject: [M3devel] naming conventions for split/composed interfaces? Message-ID: So I'm fixing AMD64_LINUX Utypes.i3, Ustat.i3, etc. Look at what I did for example with Upthread.i3 vs. UpthreadMachine.i3. Ustat.i3 shall be mostly the same between PPC_LINUX, LINUXLIBC6 (I386_LINUX), AMD64_LINUX, etc. However struct_stat will not likely be. It appears, though I have to double check, the difference cannot be abstracted out to pointer-sized integer types, that the fields are of varying orders. So I want to say: linux-i386/UstatPlatformSpecific.i3 TYPE struct_stat = ... linux-amd64/UstatPlatformSpecific.i3 TYPE struct_stat = ... linux-ppc/UstatPlatformSpecific.i3 TYPE struct_stat = ... linuxlibc/Ustat.i3 TYPE struct_stat = UstatsPlatformSpecific.struct_stat; My question is simply: What is the, or a good, naming convention for UstatPlatformSpecific? Note that it /could/ be that all but x86 have the same definition, so "PlatformSpecific", might be too, um, specific. UstatMachine? (Similarly wrong, but maybe no matter, and shorter.) UstatNotCommon? Sounds dumb. UstatX? Not as bad as it sounds. There is a precedent. It self-documents the idea that there isn't an obvious good name. UstatInternal? UstatPrivate? It's not really about hiding, so much as implementation factoring. But implementation structure is an internal detail. UstatF? (Friend?) Ustructstat? no -- ideally, anything in existing Ustat.i3 that varies goess here, not necessarily just this type. I do not want fork entire files. The system is composed of common and uncommon pieces. I believe the decision where to split should be in general pushed down. However not without judgement calls. You know, there are things that must be shared, things that are nice to share, things that are more efficient to share, things that cannot be shared. Type declarations are usually "must" but in this case largely "nice" (not Ustat, but e.g. Upthreads), and some parts of them "cannot". This split/compose pattern, you know, is a way to get something like #ifdef, without any language change or such. It does make existing code harder to read, because it is broken up into more pieces, but code will always be broken up into pieces and never all in one place and always require some assumption or tracking down of what the next level down does (until you get to atoms, quantum physics, and all that), the thing is merely to decide on just what amount is the right amount (says Goldilocks.) - Jay From hosking at cs.purdue.edu Wed Apr 23 17:33:00 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 23 Apr 2008 11:33:00 -0400 Subject: [M3devel] naming conventions for split/composed interfaces? In-Reply-To: References: Message-ID: <06FA077F-C6FB-4E42-B4AE-1A040EE2698E@cs.purdue.edu> Generally, what I try to do is to make Uxxxxx.i3 files for every corresponding C xxxx.h file. This way, as the C headers change it is easy to figure out where things should go. Why do you need a platform- specific name at all? Simply put it into a platform-specific subdirectory which will then be selectively included by the parent m3makefile. That way, we retain a consistent name for the files containing relevant declarations *across* platforms. Remember, only one of these subdirectories gets included in any given build (these are part of the run-time). So, for simplicity's sake I would argue that you are once more making unneeded complexity where simplicity is needed. So, simply having a "linux-generic" directory, and "linux-amd64" + "linux-ppc" + "linux-x86" subdirectories, each with "Upthread", "Ustat", etc. should work just fine. What's the point in making it more complicated? On Apr 23, 2008, at 11:20 AM, Jay wrote: > > So I'm fixing AMD64_LINUX Utypes.i3, Ustat.i3, etc. > > Look at what I did for example with Upthread.i3 vs. > UpthreadMachine.i3. > > Ustat.i3 shall be mostly the same between PPC_LINUX, LINUXLIBC6 > (I386_LINUX), AMD64_LINUX, etc. > > However struct_stat will not likely be. It appears, though I have to > double check, the difference cannot be abstracted out to pointer- > sized integer types, that the fields are of varying orders. > > So I want to say: > > linux-i386/UstatPlatformSpecific.i3 > TYPE struct_stat = ... > > linux-amd64/UstatPlatformSpecific.i3 > TYPE struct_stat = ... > > linux-ppc/UstatPlatformSpecific.i3 > TYPE struct_stat = ... > > linuxlibc/Ustat.i3 > TYPE struct_stat = UstatsPlatformSpecific.struct_stat; > > My question is simply: > > What is the, or a good, naming convention for UstatPlatformSpecific? > > Note that it /could/ be that all but x86 have the same definition, > so "PlatformSpecific", might be too, um, specific. > UstatMachine? (Similarly wrong, but maybe no matter, and shorter.) > UstatNotCommon? Sounds dumb. > UstatX? Not as bad as it sounds. There is a precedent. It self- > documents the idea that there isn't an obvious good name. > UstatInternal? UstatPrivate? > It's not really about hiding, so much as implementation factoring. > But implementation structure is an internal detail. > UstatF? (Friend?) > Ustructstat? no -- ideally, anything in existing Ustat.i3 that > varies goess here, not necessarily just this type. > > I do not want fork entire files. > The system is composed of common and uncommon pieces. > I believe the decision where to split should be in general pushed > down. > However not without judgement calls. > You know, there are things that must be shared, things that are nice > to share, things that are more efficient to share, things that > cannot be shared. > Type declarations are usually "must" but in this case largely > "nice" (not Ustat, but e.g. Upthreads), and some parts of them > "cannot". > > This split/compose pattern, you know, is a way to get something like > #ifdef, without any language change or such. > It does make existing code harder to read, because it is broken up > into more pieces, but code will always be broken up into pieces and > never all in one place and always require some assumption or > tracking down of what the next level down does (until you get to > atoms, quantum physics, and all that), the thing is merely to decide > on just what amount is the right amount (says Goldilocks.) > > - Jay From jayk123 at hotmail.com Wed Apr 23 17:35:57 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Apr 2008 15:35:57 +0000 Subject: [M3devel] naming conventions for split/composed interfaces? Message-ID: another idea: merge UpthreadMachine.i3 and UstatMachine.i3 into just Umachine.i3. Seems like it produces fewer medium sized files instead of more tiny ones but I think I see a drawback too, and until I hear back will go with UstatMachine. Eventually more sharing is probably possible, like of all of Ustat across all platforms, except for struct_stat. And all of Upthread except the sizes of the types and possibly the initializers (Cygwin has non-zero initializers, ideally they are all zero though.) And most of Cstd*. It bugs me to have so many so similar files.... - Jay have moved struct > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Subject: naming conventions for split/composed interfaces? > Date: Wed, 23 Apr 2008 15:20:41 +0000 > > > So I'm fixing AMD64_LINUX Utypes.i3, Ustat.i3, etc. > > Look at what I did for example with Upthread.i3 vs. UpthreadMachine.i3. > > Ustat.i3 shall be mostly the same between PPC_LINUX, LINUXLIBC6 (I386_LINUX), AMD64_LINUX, etc. > > However struct_stat will not likely be. It appears, though I have to double check, the difference cannot be abstracted out to pointer-sized integer types, that the fields are of varying orders. > > So I want to say: > > linux-i386/UstatPlatformSpecific.i3 > TYPE struct_stat = ... > > linux-amd64/UstatPlatformSpecific.i3 > TYPE struct_stat = ... > > linux-ppc/UstatPlatformSpecific.i3 > TYPE struct_stat = ... > > linuxlibc/Ustat.i3 > TYPE struct_stat = UstatsPlatformSpecific.struct_stat; > > My question is simply: > > What is the, or a good, naming convention for UstatPlatformSpecific? > > Note that it /could/ be that all but x86 have the same definition, so "PlatformSpecific", might be too, um, specific. > UstatMachine? (Similarly wrong, but maybe no matter, and shorter.) > UstatNotCommon? Sounds dumb. > UstatX? Not as bad as it sounds. There is a precedent. It self-documents the idea that there isn't an obvious good name. > UstatInternal? UstatPrivate? > It's not really about hiding, so much as implementation factoring. But implementation structure is an internal detail. > UstatF? (Friend?) > Ustructstat? no -- ideally, anything in existing Ustat.i3 that varies goess here, not necessarily just this type. > > I do not want fork entire files. > The system is composed of common and uncommon pieces. > I believe the decision where to split should be in general pushed down. > However not without judgement calls. > You know, there are things that must be shared, things that are nice to share, things that are more efficient to share, things that cannot be shared. > Type declarations are usually "must" but in this case largely "nice" (not Ustat, but e.g. Upthreads), and some parts of them "cannot". > > This split/compose pattern, you know, is a way to get something like #ifdef, without any language change or such. > It does make existing code harder to read, because it is broken up into more pieces, but code will always be broken up into pieces and never all in one place and always require some assumption or tracking down of what the next level down does (until you get to atoms, quantum physics, and all that), the thing is merely to decide on just what amount is the right amount (says Goldilocks.) > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Apr 23 22:01:24 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 23 Apr 2008 16:01:24 -0400 Subject: [M3devel] naming conventions for split/composed interfaces? In-Reply-To: References: <06FA077F-C6FB-4E42-B4AE-1A040EE2698E@cs.purdue.edu> <7F9C2510-13AB-4CB0-8C79-4315C75C90E6@cs.purdue.edu> Message-ID: Basically, I hate the idea of tangling together multiple machine- dependent systems in the same files. Yes, it is verbose with duplicated functionality, but it *is* separable. I can delete one set of files without breaking builds on other targets. I hate the idea of C wrappers even more! So, my position remains that while it is verbose having separate target-specific directories, at least they are independent and isolated. I actually think your suggestion is much messier than the current situation! On Apr 23, 2008, at 1:12 PM, Jay wrote: > ok. stat is an evolutionary mess actually. > > > Tony, Are you against having one Modula-3 definition of the type, > arbitrarily defined (any order, no padding, omit the nanoseconds > probably) and then wrappers in C to copy the data out? That is very > simple and obviously correct and just a tad inefficient. I'm very > much leaning toward this. Just for all live Linux variants for now, > not anything else (until I see if they have messy slightly hard to > read headers -- really, I can read them, or preprocess them, but I > am a little off put, others would be more off put and checking my > work becomes harder). I think there's gains to be in Cygwin too -- > you can ask it for not all the fields and have it be faster, you > know, if you don't need some complicated made up ino. > > Either that, or I rather think I should work out the two or three > struct declarations precisely and write non-copying wrappers in > Modula-3 that call __lxstat64, __fxstat64, etc., copying the inlines > out of the header. > > I approach from both sides -- read the header, and have C code print > sizes and offsets. > > It's a little messy. Read the comments. > There is a version number parameter to an underlying wrapper function. > The wrapper is either inlined or statically linked. > > I have to check if /usr/include represents all architectures, or > just x86 and AMD64. > It could be that the fork is on 32 and 64. > It could also be that using stat64 makes it all a little simpler, > but still a little messy. I have to see when then was introduced, I > assume well before LINUXLIBC6 but I have to check. Even stat64 isn't > the same between architectures though, it is split 32bit and 64bit.. > > - Jay > > From: hosking at cs.purdue.edu > To: jayk123 at hotmail.com > Subject: Re: [M3devel] naming conventions for split/composed > interfaces? > Date: Wed, 23 Apr 2008 12:40:23 -0400 > > Yeah, but in this case they really are for the platform -- header > files in /usr/include. I just want to make sure that we don't > slice and dice in ways that multiply the confusion. Right now, if I > know what platform I am on I know where to look in cm3/m3-libs/ > m3core/src/unix. I do try to use generic stuff where possible > (witness my darwin-generic, darwin-ppc, darwin-i386, darwin-amd64). > > On Apr 23, 2008, at 11:39 AM, Jay wrote: > > The point is to reduce massive duplication. > > Sometimes we split on ostype, sometimes on wordsize, sometimes on > the entire platform, sometimes otherwise. > Imagine if we always split on entire platform, what a mess that > would be. > > Upthread.i3 should be nearly identical across all platforms. > I know some platforms might have more functions, but the next > level up is not split and is therefore consistent in what it uses, > so no point in splitting the entire interface. > Let's not multiply everything out just to change a few lines. > > There is too much duplication in the system imho and I'd like to see > it reduced. > > - Jay > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > To: jayk123 at hotmail.com > > Subject: Re: [M3devel] naming conventions for split/composed > interfaces? > > Date: Wed, 23 Apr 2008 11:33:00 -0400 > > > > Generally, what I try to do is to make Uxxxxx.i3 files for every > > corresponding C xxxx.h file. This way, as the C headers change it is > > easy to figure out where things should go. Why do you need a > platform- > > specific name at all? Simply put it into a platform-specific > > subdirectory which will then be selectively included by the parent > > m3makefile. That way, we retain a consistent name for the files > > containing relevant declarations *across* platforms. Remember, only > > one of these subdirectories gets included in any given build (these > > are part of the run-time). So, for simplicity's sake I would argue > > that you are once more making unneeded complexity where simplicity > is > > needed. > > > > So, simply having a "linux-generic" directory, and "linux-amd64" + > > "linux-ppc" + "linux-x86" subdirectories, each with "Upthread", > > "Ustat", etc. should work just fine. What's the point in making it > > more complicated? > > > > On Apr 23, 2008, at 11:20 AM, Jay wrote: > > > > > > > > So I'm fixing AMD64_LINUX Utypes.i3, Ustat.i3, etc. > > > > > > Look at what I did for example with Upthread.i3 vs. > > > UpthreadMachine.i3. > > > > > > Ustat.i3 shall be mostly the same between PPC_LINUX, LINUXLIBC6 > > > (I386_LINUX), AMD64_LINUX, etc. > > > > > > However struct_stat will not likely be. It appears, though I > have to > > > double check, the difference cannot be abstracted out to pointer- > > > sized integer types, that the fields are of varying orders. > > > > > > So I want to say: > > > > > > linux-i386/UstatPlatformSpecific.i3 > > > TYPE struct_stat = ... > > > > > > linux-amd64/UstatPlatformSpecific.i3 > > > TYPE struct_stat = ... > > > > > > linux-ppc/UstatPlatformSpecific.i3 > > > TYPE struct_stat = ... > > > > > > linuxlibc/Ustat.i3 > > > TYPE struct_stat = UstatsPlatformSpecific.struct_stat; > > > > > > My question is simply: > > > > > > What is the, or a good, naming convention for > UstatPlatformSpecific? > > > > > > Note that it /could/ be that all but x86 have the same definition, > > > so "PlatformSpecific", might be too, um, specific. > > > UstatMachine? (Similarly wrong, but maybe no matter, and shorter.) > > > UstatNotCommon? Sounds dumb. > > > UstatX? Not as bad as it sounds. There is a precedent. It self- > > > documents the idea that there isn't an obvious good name. > > > UstatInternal? UstatPrivate? > > > It's not really about hiding, so much as implementation factoring. > > > But implementation structure is an internal detail. > > > UstatF? (Friend?) > > > Ustructstat? no -- ideally, anything in existing Ustat.i3 that > > > varies goess here, not necessarily just this type. > > > > > > I do not want fork entire files. > > > The system is composed of common and uncommon pieces. > > > I believe the decision where to split should be in general pushed > > > down. > > > However not without judgement calls. > > > You know, there are things that must be shared, things that are > nice > > > to share, things that are more efficient to share, things that > > > cannot be shared. > > > Type declarations are usually "must" but in this case largely > > > "nice" (not Ustat, but e.g. Upthreads), and some parts of them > > > "cannot". > > > > > > This split/compose pattern, you know, is a way to get something > like > > > #ifdef, without any language change or such. > > > It does make existing code harder to read, because it is broken up > > > into more pieces, but code will always be broken up into pieces > and > > > never all in one place and always require some assumption or > > > tracking down of what the next level down does (until you get to > > > atoms, quantum physics, and all that), the thing is merely to > decide > > > on just what amount is the right amount (says Goldilocks.) > > > > > > - Jay > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Apr 23 23:32:43 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 23 Apr 2008 23:32:43 +0200 Subject: [M3devel] naming conventions for split/composed interfaces? In-Reply-To: References: <06FA077F-C6FB-4E42-B4AE-1A040EE2698E@cs.purdue.edu> <7F9C2510-13AB-4CB0-8C79-4315C75C90E6@cs.purdue.edu> Message-ID: <20080423233243.ijpvrxlgwsw8s4og@mail.elegosoft.com> Quoting Tony Hosking : > Basically, I hate the idea of tangling together multiple machine- > dependent systems in the same files. Yes, it is verbose with > duplicated functionality, but it *is* separable. I can delete one set > of files without breaking builds on other targets. I hate the idea of > C wrappers even more! > > So, my position remains that while it is verbose having separate > target-specific directories, at least they are independent and isolated. > > I actually think your suggestion is much messier than the current situation! I agree with Tony here: we should keep the structure as simple and easily manageable as possible. While I understand your idea to join together files based on content (or, ultimately, on Unix history) we should keep in mind that a minimal amount of code does not always mean the minimal amount of maintenance costs, as the underlying systems evolve, too, and may (and will) do so in different directions. This may then require a different internal structure. So I like the idea of keeping different directories for different systems, even if there is some redundancy. Another argument to keep the structure is that is has proven to be easily portable; and we should be very careful to change it. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Thu Apr 24 01:01:27 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 23 Apr 2008 19:01:27 -0400 Subject: [M3devel] naming conventions for split/composed interfaces? In-Reply-To: <20080423233243.ijpvrxlgwsw8s4og@mail.elegosoft.com> References: <06FA077F-C6FB-4E42-B4AE-1A040EE2698E@cs.purdue.edu> <7F9C2510-13AB-4CB0-8C79-4315C75C90E6@cs.purdue.edu> <20080423233243.ijpvrxlgwsw8s4og@mail.elegosoft.com> Message-ID: <480F8783.1E75.00D7.1@scires.com> I too agree with Tony and Olaf on this point. The type of change Jay is suggesting goes against the way the language development has been set up and established since the beginning. Regards, Randy >>> Olaf Wagner 4/23/2008 5:32 PM >>> Quoting Tony Hosking : > Basically, I hate the idea of tangling together multiple machine- > dependent systems in the same files. Yes, it is verbose with > duplicated functionality, but it *is* separable. I can delete one set > of files without breaking builds on other targets. I hate the idea of > C wrappers even more! > > So, my position remains that while it is verbose having separate > target-specific directories, at least they are independent and isolated. > > I actually think your suggestion is much messier than the current situation! I agree with Tony here: we should keep the structure as simple and easily manageable as possible. While I understand your idea to join together files based on content (or, ultimately, on Unix history) we should keep in mind that a minimal amount of code does not always mean the minimal amount of maintenance costs, as the underlying systems evolve, too, and may (and will) do so in different directions. This may then require a different internal structure. So I like the idea of keeping different directories for different systems, even if there is some redundancy. Another argument to keep the structure is that is has proven to be easily portable; and we should be very careful to change it. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com ( 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 jayk123 at hotmail.com Thu Apr 24 12:58:12 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 24 Apr 2008 10:58:12 +0000 Subject: [M3devel] naming conventions for split/composed interfaces? In-Reply-To: <20080423233243.ijpvrxlgwsw8s4og@mail.elegosoft.com> References: <06FA077F-C6FB-4E42-B4AE-1A040EE2698E@cs.purdue.edu> <7F9C2510-13AB-4CB0-8C79-4315C75C90E6@cs.purdue.edu> <20080423233243.ijpvrxlgwsw8s4og@mail.elegosoft.com> Message-ID: Um..I have spent quite some time reading stat.h. At least 5 minutes. :) I must say, I really really really like the copyout method. Obviously, it goes something like this: struct_stat = RECORD st_dev : uint64_t; st_ino : uint64_t; st_mode : uint64_t; st_nlink : uint64_t; st_uid : uint64_t; st_gid : uint64_t; st_rdev : uint64_t; st_size : uint64_t; st_blksize: uint64_t; st_blocks : uint64_t; st_atime : uint64_t; st_mtime : uint64_t; st_ctime : uint64_t; END; struct_stat_star = UNTRACED REF struct_stat; void copyout(const stat_t* s, m3_stat_t* m) { m->st_ctime = s.st_stime; ... } int m3_stat(const char* path, m3_stat_t* m) { int result; struct stat s; result = m3_stat(path, &s); copyout(&s, m); return result; } and this one type definition and wrapper function is, like, arbitrarily portable to all systems. Quite simple. A little inefficient -- but it's not like the stat call itself won't dwarf the copying. I think I agree merging the files into Umachine.i3. However consider the part of Ustat.i3 other than the struct. The bit masks are probably identical across ALL platforms. The function declarations are. Actually even the struct can often be factored just by giving types like gid_t, ino_t, but I don't think that's worth it. I'd rather uint16_t, uint32_t, uint64_t. So I think moving just the struct into its own file, or using copyout, not a bad idea. Ustat.i3 is not quite the best example. I think a much better one is Upthread.i3. The file is very large and basically I think varies by 3-5 lines per variation. Lastly, you know, I do work to generate the headers kind of, and/or to derive them somewhat automatically. This work should probably be fully automated, at least for test cases, so assert the correctness. You know, write Modula-3 and C code to print field offsets and sizes and verify they are identical. This should aid maintenability. I assert the current system, no matter how the files are laid out, is overly fragile. I assert that transcribing .h files into .i3 files is a very dubious practise. It has an upside of easier cross building -- don't need the platform-specific headers. And it has the upside of not needing to worry about parsing .h files. But it is obviously bad maintainability. Better would be do wrappers like the above, except where perf is critical. Or at least actively (daily) assert the sizes/offsets. > Another argument to keep the structure is that is has proven to be > easily portable; and we should be very careful to change it. I think the current structure has proven easily copied around and then not fixed and bugs lurking.. This is not really my original point, but I have to harp a bit, it's been simmering in my brain a long time. Any time I see header cloning I cringe significantly. Visual Basic and C# have this same problem. - Jay > Date: Wed, 23 Apr 2008 23:32:43 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] naming conventions for split/composed interfaces? > > Quoting Tony Hosking : > > > Basically, I hate the idea of tangling together multiple machine- > > dependent systems in the same files. Yes, it is verbose with > > duplicated functionality, but it *is* separable. I can delete one set > > of files without breaking builds on other targets. I hate the idea of > > C wrappers even more! > > > > So, my position remains that while it is verbose having separate > > target-specific directories, at least they are independent and isolated. > > > > I actually think your suggestion is much messier than the current situation! > > I agree with Tony here: we should keep the structure as simple and > easily manageable as possible. > > While I understand your idea to join together files based on content > (or, ultimately, on Unix history) we should keep in mind that a > minimal amount of code does not always mean the minimal amount > of maintenance costs, as the underlying systems evolve, too, and may > (and will) do so in different directions. This may then require a > different internal structure. > > So I like the idea of keeping different directories for different > systems, even if there is some redundancy. > > Another argument to keep the structure is that is has proven to be > easily portable; and we should be very careful to change it. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Apr 24 14:44:57 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 24 Apr 2008 08:44:57 -0400 Subject: [M3devel] naming conventions for split/composed interfaces? In-Reply-To: References: <06FA077F-C6FB-4E42-B4AE-1A040EE2698E@cs.purdue.edu> <7F9C2510-13AB-4CB0-8C79-4315C75C90E6@cs.purdue.edu> <20080423233243.ijpvrxlgwsw8s4og@mail.elegosoft.com> Message-ID: Please, avoid C wrappers wherever possible. 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 Apr 24, 2008, at 6:58 AM, Jay wrote: > > Um..I have spent quite some time reading stat.h. At least 5 > minutes. :) > > I must say, I really really really like the copyout method. > > Obviously, it goes something like this: > > struct_stat = RECORD > st_dev : uint64_t; > st_ino : uint64_t; > st_mode : uint64_t; > st_nlink : uint64_t; > st_uid : uint64_t; > st_gid : uint64_t; > st_rdev : uint64_t; > st_size : uint64_t; > st_blksize: uint64_t; > st_blocks : uint64_t; > st_atime : uint64_t; > st_mtime : uint64_t; > st_ctime : uint64_t; > END; > struct_stat_star = UNTRACED REF struct_stat; > > > void copyout(const stat_t* s, m3_stat_t* m) > { > m->st_ctime = s.st_stime; > ... > } > int m3_stat(const char* path, m3_stat_t* m) > { > int result; > struct stat s; > > result = m3_stat(path, &s); > copyout(&s, m); > return result; > } > > and this one type definition and wrapper function is, like, > arbitrarily portable to all systems. > Quite simple. A little inefficient -- but it's not like the stat > call itself won't dwarf the copying. > > I think I agree merging the files into Umachine.i3. > > However consider the part of Ustat.i3 other than the struct. > The bit masks are probably identical across ALL platforms. > The function declarations are. > Actually even the struct can often be factored just by giving types > like gid_t, ino_t, but I don't think that's worth it. > I'd rather uint16_t, uint32_t, uint64_t. > > So I think moving just the struct into its own file, or using > copyout, not a bad idea. > > Ustat.i3 is not quite the best example. > I think a much better one is Upthread.i3. > The file is very large and basically I think varies by 3-5 lines per > variation. > > Lastly, you know, I do work to generate the headers kind of, and/or > to derive them somewhat automatically. > This work should probably be fully automated, at least for test > cases, so assert the correctness. > You know, write Modula-3 and C code to print field offsets and sizes > and verify they are identical. > This should aid maintenability. I assert the current system, no > matter how the files are laid out, is overly fragile. > I assert that transcribing .h files into .i3 files is a very dubious > practise. > It has an upside of easier cross building -- don't need the platform- > specific headers. > And it has the upside of not needing to worry about parsing .h files. > But it is obviously bad maintainability. > > Better would be do wrappers like the above, except where perf is > critical. > Or at least actively (daily) assert the sizes/offsets. > >> Another argument to keep the structure is that is has proven to be >> easily portable; and we should be very careful to change it. > > I think the current structure has proven easily copied around and > then not fixed and bugs lurking.. > This is not really my original point, but I have to harp a bit, it's > been simmering in my brain a long time. > Any time I see header cloning I cringe significantly. Visual Basic > and C# have this same problem. > > - Jay > > > > >> Date: Wed, 23 Apr 2008 23:32:43 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] naming conventions for split/composed >> interfaces? >> >> Quoting Tony Hosking : >> >>> Basically, I hate the idea of tangling together multiple machine- >>> dependent systems in the same files. Yes, it is verbose with >>> duplicated functionality, but it *is* separable. I can delete one >>> set >>> of files without breaking builds on other targets. I hate the >>> idea of >>> C wrappers even more! >>> >>> So, my position remains that while it is verbose having separate >>> target-specific directories, at least they are independent and >>> isolated -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Apr 25 02:28:00 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 25 Apr 2008 00:28:00 +0000 Subject: [M3devel] naming conventions for split/composed interfaces? In-Reply-To: References: <06FA077F-C6FB-4E42-B4AE-1A040EE2698E@cs.purdue.edu> <7F9C2510-13AB-4CB0-8C79-4315C75C90E6@cs.purdue.edu> <20080423233243.ijpvrxlgwsw8s4og@mail.elegosoft.com> Message-ID: What cost are you willing to pay? It is EASY to write one simple Ustat.i3 and UstatC.c that is correct for all platforms, totally portable, simple, efficient enough etc. The cost of avoiding the wrapper is pain, uncertainty, much higher risk of the implementation being wrong or becoming silently wrong, though... Well, how about this suggestion? How about we start writing some C code that asserts the correctness of the .i3 files?Or even having the compiler output such C code? Just make sure it compiles? Ustat.i3 would get some directive LIKE: <* PRAGMA C-derived "#include sys/stat.h", "struct stat" *> struct_stat = RECORD ... END The second parameter is the type that the record should "match". This would generate and a compile a file something like: #include #define size(a,b,c) (sizeof((a)(a*)0)->b == c) #define field(a,b) ((a*)0)->b) #define offset(a,b) ((size_t)a) type_size_size(struct stat, 0x123) size(struct stat, st_dev, 8) size(field(struct stat, st_dev), 8) size(field(struct stat, st_ino), 8) offset(field(struct stat, st_dev), 0) offset(field(struct stat, st_ino), 8) etc. where all the numbers on the right are what the compiler computes. This way, the transcription of C into Modula-3 is checked for correctness. It can be optional -- like for cross builds that might have a C compiler or headers/libs. I have to admit, there is an aspect of avoiding C that I really like -- the idea of building one tool for all targets, all in one, no need to get a cross compiler or headers/libs. To me that is a potential big upside to avoiding wrappers. I would even suggest -- can the dtoa.c and hand.c be rewritten in Modula-3. dtoa.c was very very gnarly last I looked. Could be they dropped support for IBM/Cray/VAX and it's simpler now, I don't know. While I like the idea, I would be reluctant because I don't understand the code much. hand.c though, I strongly suspect can be written in perfectly portable efficient Modula-3. It may or MIGHT not compiler down as efficiently, just if the compiler doesn't do a good job, but I don't think, like, "there any layers in the model" that prevent it, like you wouldn't have to do extra heap allocs or copies. You might get some extra array bounds checks, that would be good to avoid introducing. Well, I'm too busy right now, but: 1) I'll maybe the errno wrapper in NT386. As long as you avoid the thread-unsafe library, this area has been stable forever. And building in a dependency on thread safety is a good thing. 2) I'll see about rewriting hand.c in Modula-3 and see if I can convince myself there's no perf loss. 3) I look at gtoa.c to confirm it is still way to gnarly to consider changing. 4) Eventually see about building in this checking. It removes the upside of not having a compiler/headers, that's why optional. 5) Wonder about automating generation of the Modula-3 in the first place? Something like SWIG? I don't know. Problem with #4 and #5 is special cases. Coming up with some mechanized translation that actually exists and works. Gotta run, - Jay CC: wagner at elegosoft.com; m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] naming conventions for split/composed interfaces?Date: Thu, 24 Apr 2008 08:44:57 -0400 Please, avoid C wrappers wherever possible. 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 Apr 24, 2008, at 6:58 AM, Jay wrote: Um..I have spent quite some time reading stat.h. At least 5 minutes. :)I must say, I really really really like the copyout method.Obviously, it goes something like this: struct_stat = RECORD st_dev : uint64_t; st_ino : uint64_t; st_mode : uint64_t; st_nlink : uint64_t; st_uid : uint64_t; st_gid : uint64_t; st_rdev : uint64_t; st_size : uint64_t; st_blksize: uint64_t; st_blocks : uint64_t; st_atime : uint64_t; st_mtime : uint64_t; st_ctime : uint64_t; END; struct_stat_star = UNTRACED REF struct_stat;void copyout(const stat_t* s, m3_stat_t* m){ m->st_ctime = s.st_stime; ...}int m3_stat(const char* path, m3_stat_t* m){ int result; struct stat s; result = m3_stat(path, &s); copyout(&s, m); return result;}and this one type definition and wrapper function is, like, arbitrarily portable to all systems.Quite simple. A little inefficient -- but it's not like the stat call itself won't dwarf the copying.I think I agree merging the files into Umachine.i3.However consider the part of Ustat.i3 other than the struct.The bit masks are probably identical across ALL platforms.The function declarations are.Actually even the struct can often be factored just by giving types like gid_t, ino_t, but I don't think that's worth it.I'd rather uint16_t, uint32_t, uint64_t.So I think moving just the struct into its own file, or using copyout, not a bad idea.Ustat.i3 is not quite the best example.I think a much better one is Upthread.i3.The file is very large and basically I think varies by 3-5 lines per variation.Lastly, you know, I do work to generate the headers kind of, and/or to derive them somewhat automatically.This work should probably be fully automated, at least for test cases, so assert the correctness.You know, write Modula-3 and C code to print field offsets and sizes and verify they are identical.This should aid maintenability. I assert the current system, no matter how the files are laid out, is overly fragile.I assert that transcribing .h files into .i3 files is a very dubious practise.It has an upside of easier cross building -- don't need the platform-specific headers.And it has the upside of not needing to worry about parsing .h files.But it is obviously bad maintainability.Better would be do wrappers like the above, except where perf is critical.Or at least actively (daily) assert the sizes/offsets. Another argument to keep the structure is that is has proven to be easily portable; and we should be very careful to change it.I think the current structure has proven easily copied around and then not fixed and bugs lurking..This is not really my original point, but I have to harp a bit, it's been simmering in my brain a long time.Any time I see header cloning I cringe significantly. Visual Basic and C# have this same problem.- Jay Date: Wed, 23 Apr 2008 23:32:43 +0200 From: wagner at elegosoft.com To: m3devel at elegosoft.com Subject: Re: [M3devel] naming conventions for split/composed interfaces? Quoting Tony Hosking : Basically, I hate the idea of tangling together multiple machine- dependent systems in the same files. Yes, it is verbose with duplicated functionality, but it *is* separable. I can delete one set of files without breaking builds on other targets. I hate the idea of C wrappers even more! So, my position remains that while it is verbose having separate target-specific directories, at least they are independent and isolated -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Apr 25 08:19:05 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 25 Apr 2008 08:19:05 +0200 Subject: [M3devel] naming conventions for split/composed interfaces? In-Reply-To: References: <06FA077F-C6FB-4E42-B4AE-1A040EE2698E@cs.purdue.edu> <7F9C2510-13AB-4CB0-8C79-4315C75C90E6@cs.purdue.edu> <20080423233243.ijpvrxlgwsw8s4og@mail.elegosoft.com> Message-ID: <20080425081905.bibtuvhnhcg8k4wk@mail.elegosoft.com> Quoting Jay : > What cost are you willing to pay? > It is EASY to write one simple Ustat.i3 and UstatC.c that is correct > for all platforms, totally portable, simple, efficient enough etc. > The cost of avoiding the wrapper is pain, uncertainty, much higher > risk of the implementation being wrong or becoming silently wrong, > though... In case of stat, copying the structure may lead to performance bottle- necks in I/O intensive programs (like build systmes etc.). Build systems for example may start by stat-ing ten thousands of files in their first phase. I'd not object to adding something like a generic posix subdir, which could be used for fast porting, but I wouldn't want this to be used for current plaforms if it has performance impacts. > Well, how about this suggestion? > How about we start writing some C code that asserts the correctness > of the .i3 files?Or even having the compiler output such C code? > Just make sure it compiles? This sounds more than what I'd like to do. I think we need to analyze what exactly M3 really needs from the underlying target platform, and automate a way of generating the correct interfaces for that. Something configure-like that will only be used for porting (or checking the correctness of existing interfaces). > Ustat.i3 would get some directive LIKE: > > <* PRAGMA C-derived "#include sys/stat.h", "struct stat" *> > struct_stat = RECORD ... END > > The second parameter is the type that the record should "match". > > This would generate and a compile a file something like: > #include > #define size(a,b,c) (sizeof((a)(a*)0)->b == c) > #define field(a,b) ((a*)0)->b) > #define offset(a,b) ((size_t)a) > > type_size_size(struct stat, 0x123) > size(struct stat, st_dev, 8) > size(field(struct stat, st_dev), 8) > size(field(struct stat, st_ino), 8) > offset(field(struct stat, st_dev), 0) > offset(field(struct stat, st_ino), 8) > etc. > > where all the numbers on the right are what the compiler computes. > > This way, the transcription of C into Modula-3 is checked for correctness. > > It can be optional -- like for cross builds that might have a C > compiler or headers/libs. > I have to admit, there is an aspect of avoiding C that I really like > -- the idea of building one tool for all targets, all in one, no > need to get a cross compiler or headers/libs. To me that is a > potential big upside to avoiding wrappers. > I would even suggest -- can the dtoa.c and hand.c be rewritten in Modula-3. > dtoa.c was very very gnarly last I looked. Could be they dropped > support for IBM/Cray/VAX and it's simpler now, I don't know. While I > like the idea, I would be reluctant because I don't understand the > code much. > hand.c though, I strongly suspect can be written in perfectly > portable efficient Modula-3. There have been some discussions in the past about updating or replacing dtoa.h in M3. Have a look at the mailing list archives before spending too much time on it. > It may or MIGHT not compiler down as efficiently, just if the > compiler doesn't do a good job, but I don't think, like, "there any > layers in the model" that prevent it, like you wouldn't have to do > extra heap allocs or copies. You might get some extra array bounds > checks, that would be good to avoid introducing. > > Well, I'm too busy right now, but: > > 1) I'll maybe the errno wrapper in NT386. As long as you avoid the > thread-unsafe library, this area has been stable forever. > And building in a dependency on thread safety is a good thing. > > 2) I'll see about rewriting hand.c in Modula-3 and see if I can > convince myself there's no perf loss. > > 3) I look at gtoa.c to confirm it is still way to gnarly to consider > changing. > > 4) Eventually see about building in this checking. It removes the > upside of not having a compiler/headers, that's why optional. > > 5) Wonder about automating generation of the Modula-3 in the first > place? Something like SWIG? I don't know. > Problem with #4 and #5 is special cases. Coming up with some > mechanized translation that actually exists and works. SWIG has already been tried at least twice for M3, and found to be somewhat unhandy and insufficient. It does not really speed up the process of getting correct M3 interfaces for C headers IIRC. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Fri Apr 25 08:37:13 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 25 Apr 2008 06:37:13 +0000 Subject: [M3devel] naming conventions for split/composed interfaces? In-Reply-To: <20080425081905.bibtuvhnhcg8k4wk@mail.elegosoft.com> References: <06FA077F-C6FB-4E42-B4AE-1A040EE2698E@cs.purdue.edu> <7F9C2510-13AB-4CB0-8C79-4315C75C90E6@cs.purdue.edu> <20080423233243.ijpvrxlgwsw8s4og@mail.elegosoft.com> <20080425081905.bibtuvhnhcg8k4wk@mail.elegosoft.com> Message-ID: Copying around 64 bytes per stat call is never going to be the bottleneck.I am not 100% sure, but I believe every stat call is akernel call. Data already has to be copied betweenkernel and user mode, and some i/o, possibly cached,has to occur.Maybe if someone stats a bunch of files, and thenstats them many times afterward. I'm all for thin (zero thickness) wrappers, keeping things fast, but header cloning really bugs me. If you really want to stat a lot of files, at somepoint you'll win by using something like opendir/readdirto just get all the data -- given some readdir thatreturns the needed stat information.On Windows this is simply FindFirstFile/FindNextFile. (and yes I realize I'm partly rearranging deck chairs -- the readdir has to return some struct with the same issues as stat, however maybe there'd be knowledge of it operating on larger data and less tendency to slow it down) > generic posix directory to speed ports Sounds like a good compromise.And existing ports could even try it and measure the difference maybe. > swig vs. my compiler-based idea vs. generating some other> way only what is needed Good point. I did some stuff for Cygwin along these linesthat may be close to just right. Fairly simple C code that prints out the Modula-3.Again, what you could do, is in the build, optionallyrecompile/rerun the C and assert the output is unchanged. This is super easy for constants and chosing the rightinteger type for record fields.It is easy enough for getting the record fields in the rightorder, and asserting that you didn't miss any (no holes), thoughI didn't do that (yet). Perhaps I should try that?Come up with reasonably simple very very portable C (probablyc++, with specific reasons) code that prints out..well..some set of .i3 files that bother me.I guess it is fairly scientific, which .i3 files describeC and which Modula-3.It is presence of <* external *>, the types they take and return.Constants, harder to identify mechanically. I also made a large stab to determine exactly what is neededand no or very little more. The Cygwin stuff should be a goodbasis for determing this, except it doesn't use pthreads. Another problem here not yet addressed is picking out functionsignatures. I think some simple uses of C++ templates mightwork here, but I have to experiment. There would still be much duplicity, but I guess generated(and still checked in, and often regenerated), is better thanhand written once and then not checked through time.Granted, if you get Ustat.i3 wrong, you do tend to find andfix the bugs fairly fast, but I'd like "static" checkingto get this stuff right. I'm not going to do much of anything here for now,but maybe I'll get around to it. It depends what bugs me most. :) - Jay > Date: Fri, 25 Apr 2008 08:19:05 +0200> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com> Subject: RE: [M3devel] naming conventions for split/composed interfaces?> > Quoting Jay :> > > What cost are you willing to pay?> > It is EASY to write one simple Ustat.i3 and UstatC.c that is correct > > for all platforms, totally portable, simple, efficient enough etc. > > The cost of avoiding the wrapper is pain, uncertainty, much higher > > risk of the implementation being wrong or becoming silently wrong, > > though...> > In case of stat, copying the structure may lead to performance bottle-> necks in I/O intensive programs (like build systmes etc.). Build> systems for example may start by stat-ing ten thousands of files in> their first phase.> > I'd not object to adding something like a generic posix subdir,> which could be used for fast porting, but I wouldn't want this> to be used for current plaforms if it has performance impacts.> > > Well, how about this suggestion?> > How about we start writing some C code that asserts the correctness > > of the .i3 files?Or even having the compiler output such C code? > > Just make sure it compiles?> > This sounds more than what I'd like to do. I think we need to> analyze what exactly M3 really needs from the underlying target> platform, and automate a way of generating the correct interfaces for> that. Something configure-like that will only be used for porting> (or checking the correctness of existing interfaces).> > > Ustat.i3 would get some directive LIKE:> >> > <* PRAGMA C-derived "#include sys/stat.h", "struct stat" *>> > struct_stat = RECORD ... END> >> > The second parameter is the type that the record should "match".> >> > This would generate and a compile a file something like:> > #include > > #define size(a,b,c) (sizeof((a)(a*)0)->b == c)> > #define field(a,b) ((a*)0)->b)> > #define offset(a,b) ((size_t)a)> >> > type_size_size(struct stat, 0x123)> > size(struct stat, st_dev, 8)> > size(field(struct stat, st_dev), 8)> > size(field(struct stat, st_ino), 8)> > offset(field(struct stat, st_dev), 0)> > offset(field(struct stat, st_ino), 8)> > etc.> >> > where all the numbers on the right are what the compiler computes.> >> > This way, the transcription of C into Modula-3 is checked for correctness.> >> > It can be optional -- like for cross builds that might have a C > > compiler or headers/libs.> > I have to admit, there is an aspect of avoiding C that I really like > > -- the idea of building one tool for all targets, all in one, no > > need to get a cross compiler or headers/libs. To me that is a > > potential big upside to avoiding wrappers.> > I would even suggest -- can the dtoa.c and hand.c be rewritten in Modula-3.> > dtoa.c was very very gnarly last I looked. Could be they dropped > > support for IBM/Cray/VAX and it's simpler now, I don't know. While I > > like the idea, I would be reluctant because I don't understand the > > code much.> > hand.c though, I strongly suspect can be written in perfectly > > portable efficient Modula-3.> > There have been some discussions in the past about updating or> replacing dtoa.h in M3. Have a look at the mailing list archives> before spending too much time on it.> > > It may or MIGHT not compiler down as efficiently, just if the > > compiler doesn't do a good job, but I don't think, like, "there any > > layers in the model" that prevent it, like you wouldn't have to do > > extra heap allocs or copies. You might get some extra array bounds > > checks, that would be good to avoid introducing.> >> > Well, I'm too busy right now, but:> >> > 1) I'll maybe the errno wrapper in NT386. As long as you avoid the > > thread-unsafe library, this area has been stable forever.> > And building in a dependency on thread safety is a good thing.> >> > 2) I'll see about rewriting hand.c in Modula-3 and see if I can > > convince myself there's no perf loss.> >> > 3) I look at gtoa.c to confirm it is still way to gnarly to consider > > changing.> >> > 4) Eventually see about building in this checking. It removes the > > upside of not having a compiler/headers, that's why optional.> >> > 5) Wonder about automating generation of the Modula-3 in the first > > place? Something like SWIG? I don't know.> > Problem with #4 and #5 is special cases. Coming up with some > > mechanized translation that actually exists and works.> > SWIG has already been tried at least twice for M3, and found to be> somewhat unhandy and insufficient. It does not really speed up the> process of getting correct M3 interfaces for C headers IIRC.> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 roland.illig at gmx.de Fri Apr 25 09:20:28 2008 From: roland.illig at gmx.de (Roland Illig) Date: Fri, 25 Apr 2008 08:20:28 +0100 Subject: [M3devel] moving versions into simple text file (sh?) In-Reply-To: <480AF7A4.4060905@gmx.de> References: <480AF7A4.4060905@gmx.de> Message-ID: <4811863C.40506@gmx.de> I'm explaining my code for getting the version numbers into a shell script, since it is not completely obvious. Roland Illig schrieb: > # usage: get_version VARNAME > get_version() { > eval "gv__set=\${$1+set}" This code tests whether VARNAME is already defined. When it is, gv__set will become "set", otherwise the empty string. > if [ "$gv__set" != "set" ]; then > gv__value=`awk '$1 == "'"$1"'" { print $2 }' $root/scripts/version` The awk script compares the first field ($1) of each line with VARNAME, and if they are equal, prints the second field ($2). The funny quotes ("'") are used to insert a shell variable ($1, the first argument to the function) literally into the awk script. > eval "$1=\$gv__value" Finally, the VARNAME variable gets the value that has been read from the file. If there was no value, the empty string is used. > fi > } Roland From hosking at cs.purdue.edu Fri Apr 25 15:53:54 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 25 Apr 2008 09:53:54 -0400 Subject: [M3devel] naming conventions for split/composed interfaces? In-Reply-To: References: <06FA077F-C6FB-4E42-B4AE-1A040EE2698E@cs.purdue.edu> <7F9C2510-13AB-4CB0-8C79-4315C75C90E6@cs.purdue.edu> <20080423233243.ijpvrxlgwsw8s4og@mail.elegosoft.com> <20080425081905.bibtuvhnhcg8k4wk@mail.elegosoft.com> Message-ID: <448E8A93-88BC-495B-A11D-587310A43F39@cs.purdue.edu> Header cloning is the price we pay for straightforward, uncomplicated, untangled, porting. Yes, there is a small amount of effort (usually an hour or so in my experience) putting together the *very few* interfaces to match C headers in order to bring up a new target. The resulting code is easily maintained as a faithful mirror of the original C headers. I really think you are overstating the difficulty here, and as others have observed, this approach has not impeded the development and portability of the system. On Apr 25, 2008, at 2:37 AM, Jay wrote: > Copying around 64 bytes per stat call is never going to be the > bottleneck. > I am not 100% sure, but I believe every stat call is a > kernel call. Data already has to be copied between > kernel and user mode, and some i/o, possibly cached, > has to occur. > Maybe if someone stats a bunch of files, and then > stats them many times afterward. > > I'm all for thin (zero thickness) wrappers, keeping things fast, but > header cloning really bugs me. > > If you really want to stat a lot of files, at some > point you'll win by using something like opendir/readdir > to just get all the data -- given some readdir that > returns the needed stat information. > On Windows this is simply FindFirstFile/FindNextFile. > (and yes I realize I'm partly rearranging deck chairs -- the readdir > has to return > some struct with the same issues as stat, however maybe there'd be > knowledge > of it operating on larger data and less tendency to slow it down) > > > generic posix directory to speed ports > > Sounds like a good compromise. > And existing ports could even try it and measure the difference maybe. > > > swig vs. my compiler-based idea vs. generating some other > > way only what is needed > > Good point. I did some stuff for Cygwin along these lines > that may be close to just right. > > Fairly simple C code that prints out the Modula-3. > Again, what you could do, is in the build, optionally > recompile/rerun the C and assert the output is unchanged. > > This is super easy for constants and chosing the right > integer type for record fields. > It is easy enough for getting the record fields in the right > order, and asserting that you didn't miss any (no holes), though > I didn't do that (yet). > > Perhaps I should try that? > Come up with reasonably simple very very portable C (probably > c++, with specific reasons) code that prints out..well.. > some set of .i3 files that bother me. > I guess it is fairly scientific, which .i3 files describe > C and which Modula-3. > It is presence of <* external *>, the types they take and return. > Constants, harder to identify mechanically. > > I also made a large stab to determine exactly what is needed > and no or very little more. The Cygwin stuff should be a good > basis for determing this, except it doesn't use pthreads. > > Another problem here not yet addressed is picking out function > signatures. I think some simple uses of C++ templates might > work here, but I have to experiment. > > There would still be much duplicity, but I guess generated > (and still checked in, and often regenerated), is better than > hand written once and then not checked through time. > Granted, if you get Ustat.i3 wrong, you do tend to find and > fix the bugs fairly fast, but I'd like "static" checking > to get this stuff right. > > I'm not going to do much of anything here for now, > but maybe I'll get around to it. It depends what bugs me most. :) > > - Jay > > > > > > > > Date: Fri, 25 Apr 2008 08:19:05 +0200 > > From: wagner at elegosoft.com > > To: jayk123 at hotmail.com > > CC: hosking at cs.purdue.edu; m3devel at elegosoft.com > > Subject: RE: [M3devel] naming conventions for split/composed > interfaces? > > > > Quoting Jay : > > > > > What cost are you willing to pay? > > > It is EASY to write one simple Ustat.i3 and UstatC.c that is > correct > > > for all platforms, totally portable, simple, efficient enough etc. > > > The cost of avoiding the wrapper is pain, uncertainty, much higher > > > risk of the implementation being wrong or becoming silently wrong, > > > though... > > > > In case of stat, copying the structure may lead to performance > bottle- > > necks in I/O intensive programs (like build systmes etc.). Build > > systems for example may start by stat-ing ten thousands of files in > > their first phase. > > > > I'd not object to adding something like a generic posix subdir, > > which could be used for fast porting, but I wouldn't want this > > to be used for current plaforms if it has performance impacts. > > > > > Well, how about this suggestion? > > > How about we start writing some C code that asserts the > correctness > > > of the .i3 files?Or even having the compiler output such C code? > > > Just make sure it compiles? > > > > This sounds more than what I'd like to do. I think we need to > > analyze what exactly M3 really needs from the underlying target > > platform, and automate a way of generating the correct interfaces > for > > that. Something configure-like that will only be used for porting > > (or checking the correctness of existing interfaces). > > > > > Ustat.i3 would get some directive LIKE: > > > > > > <* PRAGMA C-derived "#include sys/stat.h", "struct stat" *> > > > struct_stat = RECORD ... END > > > > > > The second parameter is the type that the record should "match". > > > > > > This would generate and a compile a file something like: > > > #include > > > #define size(a,b,c) (sizeof((a)(a*)0)->b == c) > > > #define field(a,b) ((a*)0)->b) > > > #define offset(a,b) ((size_t)a) > > > > > > type_size_size(struct stat, 0x123) > > > size(struct stat, st_dev, 8) > > > size(field(struct stat, st_dev), 8) > > > size(field(struct stat, st_ino), 8) > > > offset(field(struct stat, st_dev), 0) > > > offset(field(struct stat, st_ino), 8) > > > etc. > > > > > > where all the numbers on the right are what the compiler computes. > > > > > > This way, the transcription of C into Modula-3 is checked for > correctness. > > > > > > It can be optional -- like for cross builds that might have a C > > > compiler or headers/libs. > > > I have to admit, there is an aspect of avoiding C that I really > like > > > -- the idea of building one tool for all targets, all in one, no > > > need to get a cross compiler or headers/libs. To me that is a > > > potential big upside to avoiding wrappers. > > > I would even suggest -- can the dtoa.c and hand.c be rewritten > in Modula-3. > > > dtoa.c was very very gnarly last I looked. Could be they dropped > > > support for IBM/Cray/VAX and it's simpler now, I don't know. > While I > > > like the idea, I would be reluctant because I don't understand the > > > code much. > > > hand.c though, I strongly suspect can be written in perfectly > > > portable efficient Modula-3. > > > > There have been some discussions in the past about updating or > > replacing dtoa.h in M3. Have a look at the mailing list archives > > before spending too much time on it. > > > > > It may or MIGHT not compiler down as efficiently, just if the > > > compiler doesn't do a good job, but I don't think, like, "there > any > > > layers in the model" that prevent it, like you wouldn't have to do > > > extra heap allocs or copies. You might get some extra array bounds > > > checks, that would be good to avoid introducing. > > > > > > Well, I'm too busy right now, but: > > > > > > 1) I'll maybe the errno wrapper in NT386. As long as you avoid the > > > thread-unsafe library, this area has been stable forever. > > > And building in a dependency on thread safety is a good thing. > > > > > > 2) I'll see about rewriting hand.c in Modula-3 and see if I can > > > convince myself there's no perf loss. > > > > > > 3) I look at gtoa.c to confirm it is still way to gnarly to > consider > > > changing. > > > > > > 4) Eventually see about building in this checking. It removes the > > > upside of not having a compiler/headers, that's why optional. > > > > > > 5) Wonder about automating generation of the Modula-3 in the first > > > place? Something like SWIG? I don't know. > > > Problem with #4 and #5 is special cases. Coming up with some > > > mechanized translation that actually exists and works. > > > > SWIG has already been tried at least twice for M3, and found to be > > somewhat unhandy and insufficient. It does not really speed up the > > process of getting correct M3 interfaces for C headers IIRC. > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Apr 26 09:17:04 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 26 Apr 2008 09:17:04 +0200 Subject: [M3devel] tinderbox failures / release builds broken Message-ID: <20080426091704.472e30pem8ww8wgs@mail.elegosoft.com> Jay, this seems to have broken all release builds: (+34/18) Lines changed. When Who File Rev +/- Description 2008-04-25 22:33 jkrell cm3/m3-sys/m3cc/src/m3makefile 1.58 34/18 workaround strange problems building gmp/mpfr for NT386GNU as well as non-strange problem building m3cg1.exe (the makefile wants m3cg1. '.exe' is dealt with some other way Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Sat Apr 26 10:03:06 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 26 Apr 2008 08:03:06 +0000 Subject: [M3devel] tinderbox failures / release builds broken In-Reply-To: <20080426091704.472e30pem8ww8wgs@mail.elegosoft.com> References: <20080426091704.472e30pem8ww8wgs@mail.elegosoft.com> Message-ID: oops, sorry, should be ok now > Date: Sat, 26 Apr 2008 09:17:04 +0200 > From: wagner at elegosoft.com > To: jayk123 at hotmail.com > CC: m3devel at elegosoft.com > Subject: tinderbox failures / release builds broken > > Jay, > > this seems to have broken all release builds: > > (+34/18) Lines changed. > When Who File Rev +/- Description > 2008-04-25 22:33 jkrell cm3/m3-sys/m3cc/src/m3makefile 1.58 34/18 > workaround strange problems building gmp/mpfr for NT386GNU as well as > non-strange problem building m3cg1.exe (the makefile wants m3cg1. > '.exe' is dealt with some other way > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Apr 28 18:42:17 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 28 Apr 2008 18:42:17 +0200 Subject: [M3devel] Popup Windows stalling regression tests on WinXP Message-ID: <20080428184217.dizt8loly8go80gg@mail.elegosoft.com> Hi Jay, everytime I have a look why the regression tests haven't terminated yet, I find another popup window with a message like this: cm3.exe has encountered a problem and needs to close. We are sorry for the inconvenience. Any idea how to suppress this kind of error notification? We'll never get reliable regression testing with popup windows :-/ Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Mon Apr 28 23:47:35 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Apr 2008 21:47:35 +0000 Subject: [M3devel] Popup Windows stalling regression tests on WinXP In-Reply-To: <20080428184217.dizt8loly8go80gg@mail.elegosoft.com> References: <20080428184217.dizt8loly8go80gg@mail.elegosoft.com> Message-ID: Olaf, this is a bug and should be fixed.Like someone calling abort or assert(false) or NtRaiseHardError or dereferencing NULL or such.Or skip those tests on NT386 for now.And please provide an easy way to run specific tests.I'm working on adding some tests (ok, just one) and it seems to be a pain.I think it's just cm3 -FA ../../TESTARGS but it wasn't working. Install the debuggers: http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx I install to c:\bin\x86 and c:\bin\amd64, though the default is c:\program files\blah. mkdir c:\symbols this is just for a local cache, not needed but nice cd c:\bin\x86\windbg -o -G -g -y srv*c:\symbols*http://msdl.microsoft.com/download/symbols cm3 When there is a popup, type: ~*k to get all the thread stacks, and see which one is in MessageBox or abort or whatnot. And send the stack? Or all of them if uncertain. You can also make a full or minidump with .dump for someone else to look at. Good to have the cm3.exe and cm3.pdb as well. Or I guess I can/should just fix them.I think I've seen a few of these myself. The stack might not be well displayed by the debugger. It could be this in the toplevel exception handler/watson thingy. Another thing to try is: c:\bin\x86\windbg -I to install windbg as the JIT debugger. That way, some crashes will bring up a debugger, possibly prompting first. I need to make a web page with a Win32 debugging primer at some point. Anyway, I'll try to bump this up in priority. Could be that SetErrorMode(something) quashes them, but that doesn't mean it isn't a bug. Another very good theory is that the "app type", console vs. gui, is relevant. Console apps upon abort() or assert(false) print something to stdout/stderr and then exit, whereas gui apps use MessageBox. The type is determined from the .exe, and you can change it at runtime via a call. Not clear to me which of the various catastrophic errors this is though. I think abort(). - Jay > Date: Mon, 28 Apr 2008 18:42:17 +0200> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Popup Windows stalling regression tests on WinXP> > Hi Jay,> > everytime I have a look why the regression tests haven't terminated> yet, I find another popup window with a message like this:> > cm3.exe has encountered a problem and needs to close.> We are sorry for the inconvenience.> > Any idea how to suppress this kind of error notification?> We'll never get reliable regression testing with popup windows :-/> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 jayk123 at hotmail.com Mon Apr 28 23:56:17 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Apr 2008 21:56:17 +0000 Subject: [M3devel] Popup Windows stalling regression tests on WinXP In-Reply-To: <20080428184217.dizt8loly8go80gg@mail.elegosoft.com> References: <20080428184217.dizt8loly8go80gg@mail.elegosoft.com> Message-ID: truncated and newlines got removed, I wonder if email will ever work.. From: jayk123 at hotmail.comTo: wagner at elegosoft.comCC: m3devel at elegosoft.comSubject: RE: Popup Windows stalling regression tests on WinXPDate: Mon, 28 Apr 2008 21:47:35 +0000 Olaf, this is a bug and should be fixed.Like someone calling abort or assert(false) or NtRaiseHardError or dereferencing NULL or such.Or skip those tests on NT386 for now.And please provide an easy way to run specific tests.I'm working on adding some tests (ok, just one) and it seems to be a pain.I think it's just cm3 -FA ../../TESTARGS but it wasn't working.Install the debuggers: http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx I install to c:\bin\x86 and c:\bin\amd64, though the default is c:\program files\blah. mkdir c:\symbols this is just for a local cache, not needed but nice cd c:\bin\x86\windbg -o -G -g -y srv*c:\symbols*http://msdl.microsoft.com/download/symbols cm3 When there is a popup, type: ~*k to get all the thread stacks, and see which one is in MessageBox or abort or whatnot.And send the stack? Or all of them if uncertain.You can also make a full or minidump with .dump for someone else to look at.Good to have the cm3.exe and cm3.pdb as well.Or I guess I can/should just fix them.I think I've seen a few of these myself. The stack might not be well displayed by the debugger.It could be this in the toplevel exception handler/watson thingy. Another thing to try is:c:\bin\x86\windbg -I to install windbg as the JIT debugger. That way, some crashes will bring up a debugger, possibly prompting first. I need to make a web page with a Win32 debugging primer at some point.Anyway, I'll try to bump this up in priority. Could be that SetErrorMode(something) quashes them, but that doesn't mean it isn't a bug.Another very good theory is that the "app type", console vs. gui, is relevant.Console apps upon abort() or assert(false) print something to stdout/stderr and then exit, whereas gui appsuse MessageBox. The type is determined from the .exe, and you can change it at runtime via a call. Not clear to me which of the various catastrophic errors this is though. I think abort(). - Jay > Date: Mon, 28 Apr 2008 18:42:17 +0200> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Popup Windows stalling regression tests on WinXP> > Hi Jay,> > everytime I have a look why the regression tests haven't terminated> yet, I find another popup window with a message like this:> > cm3.exe has encountered a problem and needs to close.> We are sorry for the inconvenience.> > Any idea how to suppress this kind of error notification?> We'll never get reliable regression testing with popup windows :-/> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 dabenavidesd at yahoo.es Tue Apr 29 04:26:43 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 29 Apr 2008 04:26:43 +0200 (CEST) Subject: [M3devel] Popup Windows stalling regression tests on WinXP In-Reply-To: Message-ID: <700233.58102.qm@web27105.mail.ukl.yahoo.com> Hi all: What test(s) it fails? What happens if you append the options the compiler has for building on Win boxes: -console produce a Windows CONSOLE subsystem program -gui produce a Windows GUI subsystem program -windows produce a Windows GUI subsystem program About the options above , does the last two: - gui and -windows have the same meaning? Should the NT386 cm3 compiler build with any of these options? What does the compiler know about this options? That errors should be just understood by the runtime (I think that's the beauty of the SAFE subset of the language), the system (Nt386) M3 runtime doesn't have the capacity to avoid the segment violation, etc of the program before it gets killed by the OS? Thanks Jay escribi?: .hmmessage P { margin:0px; padding:0px } body.hmmessage { FONT-SIZE: 10pt; FONT-FAMILY:Tahoma } truncated and newlines got removed, I wonder if email will ever work.. --------------------------------- From: jayk123 at hotmail.com To: wagner at elegosoft.com CC: m3devel at elegosoft.com Subject: RE: Popup Windows stalling regression tests on WinXP Date: Mon, 28 Apr 2008 21:47:35 +0000 .ExternalClass .EC_hmmessage P {padding:0px;} .ExternalClass body.EC_hmmessage {font-size:10pt;font-family:Tahoma;} Olaf, this is a bug and should be fixed. Like someone calling abort or assert(false) or NtRaiseHardError or dereferencing NULL or such. Or skip those tests on NT386 for now. And please provide an easy way to run specific tests. I'm working on adding some tests (ok, just one) and it seems to be a pain. I think it's just cm3 -FA ../../TESTARGS but it wasn't working. Install the debuggers: http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx I install to c:\bin\x86 and c:\bin\amd64, though the default is c:\program files\blah. mkdir c:\symbols this is just for a local cache, not needed but nice cd c:\bin\x86\windbg -o -G -g -y srv*c:\symbols*http://msdl.microsoft.com/download/symbols cm3 When there is a popup, type: ~*k to get all the thread stacks, and see which one is in MessageBox or abort or whatnot. And send the stack? Or all of them if uncertain. You can also make a full or minidump with .dump for someone else to look at. Good to have the cm3.exe and cm3.pdb as well. Or I guess I can/should just fix them. I think I've seen a few of these myself. The stack might not be well displayed by the debugger. It could be this in the toplevel exception handler/watson thingy. Another thing to try is: c:\bin\x86\windbg -I to install windbg as the JIT debugger. That way, some crashes will bring up a debugger, possibly prompting first. I need to make a web page with a Win32 debugging primer at some point. Anyway, I'll try to bump this up in priority. Could be that SetErrorMode(something) quashes them, but that doesn't mean it isn't a bug. Another very good theory is that the "app type", console vs. gui, is relevant. Console apps upon abort() or assert(false) print something to stdout/stderr and then exit, whereas gui apps use MessageBox. The type is determined from the .exe, and you can change it at runtime via a call. Not clear to me which of the various catastrophic errors this is though. I think abort(). - Jay --------------------------------- > Date: Mon, 28 Apr 2008 18:42:17 +0200 > From: wagner at elegosoft.com > To: jayk123 at hotmail.com > CC: m3devel at elegosoft.com > Subject: Popup Windows stalling regression tests on WinXP > > Hi Jay, > > everytime I have a look why the regression tests haven't terminated > yet, I find another popup window with a message like this: > > cm3.exe has encountered a problem and needs to close. > We are sorry for the inconvenience. > > Any idea how to suppress this kind of error notification? > We'll never get reliable regression testing with popup windows :-/ > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > --------------------------------- Yahoo! Solidario. Intercambia los objetos que ya no necesitas y ayuda a mantener un entorno m?s ecol?gico. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Apr 29 04:36:25 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 29 Apr 2008 02:36:25 +0000 Subject: [M3devel] Popup Windows stalling regression tests on WinXP In-Reply-To: <700233.58102.qm@web27105.mail.ukl.yahoo.com> References: <700233.58102.qm@web27105.mail.ukl.yahoo.com> Message-ID: I'd bet the correct options are already in use. Otherwise functionality would be badly messed up. At least for cm3.exe. MAYBE not the tests. -gui and -windows show the same meaning below. You'd have to read the code. This is an area that needs repair for NT386GNU and NT386MINGNU, but it should be ok for NT386. What the compiler should know about these is how it marks the "system" in the resulting .exe. (It is meaningless for .dlls.) It's just one field in the .exe, via a switch to the linker. Oh, and I guess there is mainCRTStartup vs. WinMainCRTStartup, which drags in different associated data, to inform the C runtime as to your type. However...I'm sure you can mix and match these. A GUI app can start with main, they just don't tend to. main and WinMain have different signatures, but mainCRTStartup and WinMainCRTStartup do not. They both take no parameters and get their data from GetCommandLine, GetStartupInfo, GetEnvironmentVariables, etc. > That errors should be just understood by the runtime Maybe. > the system (Nt386) M3 runtime doesn't have the capacity to > avoid the segment violation, etc of the program before it gets killed by the OS? It probably does. It depends, but maybe. Best just to avoid them if possible. I realize there could be tests that want to deliberately dereference NULL to test the runtime handling.It might be viable to have runtime hooks for testing. Maybe that are only supported in standalone() or something. I'll have to look into it. I have seen errors like this running the tests but I have ignored them before. - Jay Date: Tue, 29 Apr 2008 04:26:43 +0200From: dabenavidesd at yahoo.esSubject: Re: [M3devel] Popup Windows stalling regression tests on WinXPTo: jayk123 at hotmail.com; wagner at elegosoft.comCC: m3devel at elegosoft.comHi all:What test(s) it fails? What happens if you append the options the compiler has for building on Win boxes:-console produce a Windows CONSOLE subsystem program-gui produce a Windows GUI subsystem program-windows produce a Windows GUI subsystem programAbout the options above , does the last two: - gui and -windows have the same meaning? Should the NT386 cm3 compiler build with any of these options? What does the compiler know about this options?That errors should be just understood by the runtime (I think that's the beauty of the SAFE subset of the language), the system (Nt386) M3 runtime doesn't have the capacity to avoid the segment violation, etc of the program before it gets killed by the OS?ThanksJay escribi?: truncated and newlines got removed, I wonder if email will ever work.. From: jayk123 at hotmail.comTo: wagner at elegosoft.comCC: m3devel at elegosoft.comSubject: RE: Popup Windows stalling regression tests on WinXPDate: Mon, 28 Apr 2008 21:47:35 +0000 Olaf, this is a bug and should be fixed.Like someone calling abort or assert(false) or NtRaiseHardError or dereferencing NULL or such.Or skip those tests on NT386 for now.And please provide an easy way to run specific tests.I'm working on adding some tests (ok, just one) and it seems to be a pain.I think it's just cm3 -FA ../../TESTARGS but it wasn't working.Install the debuggers: http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx I install to c:\bin\x86 and c:\bin\amd64, though the default is c:\program files\blah. mkdir c:\symbols this is just for a local cache, not needed but nice cd c:\bin\x86\windbg -o -G -g -y srv*c:\symbols*http://msdl.microsoft.com/download/symbols cm3 When there is a popup, type: ~*k to get all the thread stacks, and see which one is in MessageBox or abort or whatnot.And send the stack? Or all of them if uncertain.You can also make a full or minidump with .dump for someone else to look at.Good to have the cm3.exe and cm3.pdb as well.Or I guess I can/should just fix them.I think I've seen a few of these myself. The stack might not be well displayed by the debugger.It could be this in the toplevel exception handler/watson thingy. Another thing to try is:c:\bin\x86\windbg -I to install windbg as the JIT debugger. That way, some crashes will bring up a debugger, possibly prompting first. I need to make a web page with a Win32 debugging primer at some point.Anyway, I'll try to bump this up in priority. Could be that SetErrorMode(something) quashes them, but that doesn't mean it isn't a bug.Another very good theory is that the "app type", console vs. gui, is relevant.Console apps upon abort() or assert(false) print something to stdout/stderr and then exit, whereas gui appsuse MessageBox. The type is determined from the .exe, and you can change it at runtime via a call. Not clear to me which of the various catastrophic errors this is though. I think abort(). - Jay > Date: Mon, 28 Apr 2008 18:42:17 +0200> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Popup Windows stalling regression tests on WinXP> > Hi Jay,> > everytime I have a look why the regression tests haven't terminated> yet, I find another popup window with a message like this:> > cm3.exe has encountered a problem and needs to close.> We are sorry for the inconvenience.> > Any idea how to suppress this kind of error notification?> We'll never get reliable regression testing with popup windows :-/> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> Yahoo! Solidario.Intercambia los objetos que ya no necesitas y ayuda a mantener un entorno m?s ecol?gico. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Apr 29 13:51:20 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 29 Apr 2008 13:51:20 +0200 Subject: [M3devel] Popup Windows stalling regression tests on WinXP In-Reply-To: References: <20080428184217.dizt8loly8go80gg@mail.elegosoft.com> Message-ID: <20080429135120.m5413443cwo884so@mail.elegosoft.com> Sorry, I currently have neither the time to install debuggers on my slow VM machine nor to chase after such bugs. What I hoped is that there is some system switch that turns off all such popups. If there is not, there may not be much further progress from me for some time. If I start a program like the compiler without any GUI from the command line, I do not expect to get any popup boxes on some unmonitored server machine. It will just not work this way. Even if I found and fixed this special problem now, we'll run into the next one some time later when the tests are hanging again... Olaf PS: As for running only one test with the m3tests makefile, I simply switch off most of the definitions with `if "" ... end' and copy the interesting line just before. Quoting Jay : > Olaf, this is a bug and should be fixed.Like someone calling abort > or assert(false) or NtRaiseHardError or dereferencing NULL or > such.Or skip those tests on NT386 for now.And please provide an easy > way to run specific tests.I'm working on adding some tests (ok, > just one) and it seems to be a pain.I think it's just cm3 -FA > ../../TESTARGS but it wasn't working. > Install the debuggers: > http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx > > I install to c:\bin\x86 and c:\bin\amd64, though the default is > c:\program files\blah. mkdir c:\symbols this is just for a local > cache, not needed but nice > > cd > c:\bin\x86\windbg -o -G -g -y > srv*c:\symbols*http://msdl.microsoft.com/download/symbols cm3 > > When there is a popup, type: > > ~*k > to get all the thread stacks, and see which one is in MessageBox or > abort or whatnot. > And send the stack? Or all of them if uncertain. > You can also make a full or minidump with .dump for someone else to look at. > Good to have the cm3.exe and cm3.pdb as well. > Or I guess I can/should just fix them.I think I've seen a few of > these myself. > > The stack might not be well displayed by the debugger. > It could be this in the toplevel exception handler/watson thingy. > > Another thing to try is: > c:\bin\x86\windbg -I > > to install windbg as the JIT debugger. That way, some crashes will > bring up a debugger, possibly prompting first. > > I need to make a web page with a Win32 debugging primer at some point. > Anyway, I'll try to bump this up in priority. > > Could be that SetErrorMode(something) quashes them, but that doesn't > mean it isn't a bug. > Another very good theory is that the "app type", console vs. gui, is > relevant. > Console apps upon abort() or assert(false) print something to > stdout/stderr and then exit, whereas gui apps > use MessageBox. The type is determined from the .exe, and you can > change it at runtime via a call. > > Not clear to me which of the various catastrophic errors this is > though. I think abort(). > - Jay > > > >> Date: Mon, 28 Apr 2008 18:42:17 +0200> From: wagner at elegosoft.com> >> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Popup >> Windows stalling regression tests on WinXP> > Hi Jay,> > everytime >> I have a look why the regression tests haven't terminated> yet, I >> find another popup window with a message like this:> > cm3.exe has >> encountered a problem and needs to close.> We are sorry for the >> inconvenience.> > Any idea how to suppress this kind of error >> notification?> We'll never get reliable regression testing with >> popup windows :-/> > Olaf> -- > Olaf Wagner -- elego Software >> Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >> Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: >> +49 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 dabenavidesd at yahoo.es Tue Apr 29 14:46:31 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 29 Apr 2008 14:46:31 +0200 (CEST) Subject: [M3devel] Popup Windows stalling regression tests on WinXP In-Reply-To: <20080429135120.m5413443cwo884so@mail.elegosoft.com> Message-ID: <444151.41574.qm@web27109.mail.ukl.yahoo.com> Hi all: Olaf, but in the case is not even the cm3 process, but a sub process of it, maybe the linker or/and the assembler (what VS version do you have?) which in turn throws the fault, how do you know from sure is cm3 only causing that?, Can you check the label of "Click here for more information". Then you can click on see the files involved in the fault. There you should see the list of files like dll or lib and executable involved, can you send that info? Thanks Olaf Wagner wrote: Sorry, I currently have neither the time to install debuggers on my slow VM machine nor to chase after such bugs. What I hoped is that there is some system switch that turns off all such popups. If there is not, there may not be much further progress from me for some time. If I start a program like the compiler without any GUI from the command line, I do not expect to get any popup boxes on some unmonitored server machine. It will just not work this way. Even if I found and fixed this special problem now, we'll run into the next one some time later when the tests are hanging again... Olaf PS: As for running only one test with the m3tests makefile, I simply switch off most of the definitions with `if "" ... end' and copy the interesting line just before. Quoting Jay : > Olaf, this is a bug and should be fixed.Like someone calling abort > or assert(false) or NtRaiseHardError or dereferencing NULL or > such.Or skip those tests on NT386 for now.And please provide an easy > way to run specific tests.I'm working on adding some tests (ok, > just one) and it seems to be a pain.I think it's just cm3 -FA > ../../TESTARGS but it wasn't working. > Install the debuggers: > http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx > > I install to c:\bin\x86 and c:\bin\amd64, though the default is > c:\program files\blah. mkdir c:\symbols this is just for a local > cache, not needed but nice > > cd > c:\bin\x86\windbg -o -G -g -y > srv*c:\symbols*http://msdl.microsoft.com/download/symbols cm3 > > When there is a popup, type: > > ~*k > to get all the thread stacks, and see which one is in MessageBox or > abort or whatnot. > And send the stack? Or all of them if uncertain. > You can also make a full or minidump with .dump for someone else to look at. > Good to have the cm3.exe and cm3.pdb as well. > Or I guess I can/should just fix them.I think I've seen a few of > these myself. > > The stack might not be well displayed by the debugger. > It could be this in the toplevel exception handler/watson thingy. > > Another thing to try is: > c:\bin\x86\windbg -I > > to install windbg as the JIT debugger. That way, some crashes will > bring up a debugger, possibly prompting first. > > I need to make a web page with a Win32 debugging primer at some point. > Anyway, I'll try to bump this up in priority. > > Could be that SetErrorMode(something) quashes them, but that doesn't > mean it isn't a bug. > Another very good theory is that the "app type", console vs. gui, is > relevant. > Console apps upon abort() or assert(false) print something to > stdout/stderr and then exit, whereas gui apps > use MessageBox. The type is determined from the .exe, and you can > change it at runtime via a call. > > Not clear to me which of the various catastrophic errors this is > though. I think abort(). > - Jay > > > >> Date: Mon, 28 Apr 2008 18:42:17 +0200> From: wagner at elegosoft.com> >> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Popup >> Windows stalling regression tests on WinXP> > Hi Jay,> > everytime >> I have a look why the regression tests haven't terminated> yet, I >> find another popup window with a message like this:> > cm3.exe has >> encountered a problem and needs to close.> We are sorry for the >> inconvenience.> > Any idea how to suppress this kind of error >> notification?> We'll never get reliable regression testing with >> popup windows :-/> > Olaf> -- > Olaf Wagner -- elego Software >> Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >> Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: >> +49 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 --------------------------------- Enviado desde Correo Yahoo! La bandeja de entrada m?s inteligente. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Apr 29 16:00:27 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 29 Apr 2008 16:00:27 +0200 Subject: [M3devel] Popup Windows stalling regression tests on WinXP In-Reply-To: <444151.41574.qm@web27109.mail.ukl.yahoo.com> References: <444151.41574.qm@web27109.mail.ukl.yahoo.com> Message-ID: <20080429160027.hp9wb3dhc0g0kkko@mail.elegosoft.com> Quoting "Daniel Alejandro Benavides D." : > Hi all: > Olaf, but in the case is not even the cm3 process, but a sub process > of it, maybe the linker or/and the assembler (what VS version do > you have?) which in turn throws the fault, how do you know from > sure is cm3 only causing that?, Can you check the label of "Click > here for more information". Then you can click on see the files > involved in the fault. There you should see the list of files like > dll or lib and executable involved, can you send that info? I'll restart the tests after some more obvious fixes later this evening and may be able to send more information tomorrow. IIRC there was no label `click here for more information', but just `send report to Microsoft' and `do not send'. Currently we're working hard on a completely different release... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dabenavidesd at yahoo.es Tue Apr 29 16:47:23 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 29 Apr 2008 16:47:23 +0200 (CEST) Subject: [M3devel] Popup Windows stalling regression tests on WinXP In-Reply-To: <20080429160027.hp9wb3dhc0g0kkko@mail.elegosoft.com> Message-ID: <495318.48565.qm@web27105.mail.ukl.yahoo.com> Hi all: Olaf, I don't have the Win box here (just a Kubuntu one). But even if you don't want to send the file, one can see the report file in a window. Should be with two steps: The first click on the blue label "Click here " in the first pop up window. That throws another window with a label that you can click-on and actually see it Well I found with google the instruction to disable that error pop up: http://pcsupport.about.com/od/windowsxp/ht/disableerror.htm I hope this helps to you. Thanks Olaf Wagner escribi?: Quoting "Daniel Alejandro Benavides D." : > Hi all: > Olaf, but in the case is not even the cm3 process, but a sub process > of it, maybe the linker or/and the assembler (what VS version do > you have?) which in turn throws the fault, how do you know from > sure is cm3 only causing that?, Can you check the label of "Click > here for more information". Then you can click on see the files > involved in the fault. There you should see the list of files like > dll or lib and executable involved, can you send that info? I'll restart the tests after some more obvious fixes later this evening and may be able to send more information tomorrow. IIRC there was no label `click here for more information', but just `send report to Microsoft' and `do not send'. Currently we're working hard on a completely different release... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 --------------------------------- Enviado desde Correo Yahoo! La bandeja de entrada m?s inteligente. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Apr 29 17:11:17 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 29 Apr 2008 17:11:17 +0200 Subject: [M3devel] Popup Windows stalling regression tests on WinXP In-Reply-To: <495318.48565.qm@web27105.mail.ukl.yahoo.com> References: <495318.48565.qm@web27105.mail.ukl.yahoo.com> Message-ID: <20080429171117.oopp3fpcpc84ccwk@mail.elegosoft.com> Quoting "Daniel Alejandro Benavides D." : > Hi all: > Olaf, I don't have the Win box here (just a Kubuntu one). But even > if you don't want to send the file, one can see the report file in > a window. Should be with two steps: The first click on the blue > label "Click here " in the first pop up window. That throws another > window with a label that you can click-on and actually see it > Well I found with google the instruction to disable that error pop up: > http://pcsupport.about.com/od/windowsxp/ht/disableerror.htm > I hope this helps to you. Thanks, that sounds good, I'll try it tonight. Olaf > > Thanks > > Olaf Wagner escribi?: Quoting "Daniel > Alejandro Benavides D." : > >> Hi all: >> Olaf, but in the case is not even the cm3 process, but a sub process >> of it, maybe the linker or/and the assembler (what VS version do >> you have?) which in turn throws the fault, how do you know from >> sure is cm3 only causing that?, Can you check the label of "Click >> here for more information". Then you can click on see the files >> involved in the fault. There you should see the list of files like >> dll or lib and executable involved, can you send that info? > > I'll restart the tests after some more obvious fixes later this > evening and may be able to send more information tomorrow. > IIRC there was no label `click here for more information', but > just `send report to Microsoft' and `do not send'. > > Currently we're working hard on a completely different release... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > > > > --------------------------------- > > Enviado desde Correo Yahoo! > La bandeja de entrada m?s inteligente. > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Tue Apr 29 17:52:24 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 29 Apr 2008 11:52:24 -0400 Subject: [M3devel] Your recent change to parse.c Message-ID: I don't understand your change to parse.c re TREE_PUBLIC being set on procedure declarations. TREE_PUBLIC just means that it is possible to call the procedure from outside the current compilation unit. It has nothing to do with intra-library visibility. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Apr 29 23:38:14 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 29 Apr 2008 21:38:14 +0000 Subject: [M3devel] Popup Windows stalling regression tests on WinXP In-Reply-To: <20080429171117.oopp3fpcpc84ccwk@mail.elegosoft.com> References: <495318.48565.qm@web27105.mail.ukl.yahoo.com> <20080429171117.oopp3fpcpc84ccwk@mail.elegosoft.com> Message-ID: Yes, this might be it. My x86 Windows machine is out on loan this week, my AMD64 Windows machine needed a reinstall, and I was deep into debugging the AMD64_LINUX problem (on same machine, multi-boot), so I punted. Now I've reinstalled AMD64 Windows and can debug to see what the problem is, to decide if it is quashable..There should be a way without global changes to the machine, but if that's ok, ok. (If this even it.) - Jay> Date: Tue, 29 Apr 2008 17:11:17 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] Popup Windows stalling regression tests on WinXP> > Quoting "Daniel Alejandro Benavides D." :> > > Hi all:> > Olaf, I don't have the Win box here (just a Kubuntu one). But even > > if you don't want to send the file, one can see the report file in > > a window. Should be with two steps: The first click on the blue > > label "Click here " in the first pop up window. That throws another > > window with a label that you can click-on and actually see it> > Well I found with google the instruction to disable that error pop up:> > http://pcsupport.about.com/od/windowsxp/ht/disableerror.htm> > I hope this helps to you.> > Thanks, that sounds good, I'll try it tonight.> > Olaf> > >> > Thanks> >> > Olaf Wagner escribi?: Quoting "Daniel > > Alejandro Benavides D." :> >> >> Hi all:> >> Olaf, but in the case is not even the cm3 process, but a sub process> >> of it, maybe the linker or/and the assembler (what VS version do> >> you have?) which in turn throws the fault, how do you know from> >> sure is cm3 only causing that?, Can you check the label of "Click> >> here for more information". Then you can click on see the files> >> involved in the fault. There you should see the list of files like> >> dll or lib and executable involved, can you send that info?> >> > I'll restart the tests after some more obvious fixes later this> > evening and may be able to send more information tomorrow.> > IIRC there was no label `click here for more information', but> > just `send report to Microsoft' and `do not send'.> >> > Currently we're working hard on a completely different release...> >> > Olaf> > --> > Olaf Wagner -- elego Software Solutions GmbH> > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> >> >> >> >> > ---------------------------------> >> > Enviado desde Correo Yahoo!> > La bandeja de entrada m?s inteligente.> >> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 jayk123 at hotmail.com Tue Apr 29 23:57:45 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 29 Apr 2008 21:57:45 +0000 Subject: [M3devel] Your recent change to parse.c In-Reply-To: References: Message-ID: Tony, this is a serious problem on AMD64_LINUX.It is not a problem at all on Win32, as Win32 has amuch better codegen model. It's amazing how Linux works.. Look at the .ms file for ThreadPThread.I looked on AMD64_LINUX and LINUXLIBC6. ThreadPThread__InitMutex's call to its own finallyblock goes through the PLT and on AMD64_LINUX the static linkin r10 is trashed. It's possible that if you turn on optimizations, the finallyblock is inlined and that hides the problem, but you can'tcount on that. I was experimenting with another fix at the same time,that of using -fvisibility=hidden on m3cg, butto me that seems more like a C/C++ front end switch,even though cm3cg supports it. I can try again and carefully tweak the two variables,see if -fvisibility=hidden suffices. At the levelcm3cg operates though, it marks the visibility of everythingexplicitly, so again, I think my fix is the way. As well calls within a file to functions within that filethat aren't in an interface are going through the PLT.This is just wasteful. They shouldn't even go through the PLT for calls within thesame "library" (ie: m3core to m3core, libm3 to libm3). What such indirect calls "buy" is that, e.g. the .exe or libm3can replace functions in m3core, or such, and function pointerequality might be achieved. I think the "interposition" featureis widely accepted on Linux, though it is dodgy.I think on Linux going through the PLT for exported functions mightbe the norm. I'll have to read up more. But going through the PLTfor unexported functions is not the norm. Documentation stronglyencourages marking visibility and saving the PLT indirection. In C/C++ there's further problems of name uniquess of unexportedfunctions across the dynamic link. I believe Modula-3 deals with that,since pretty much every function in the system gets a unique name,exported or not. One or the other or both these changes (public = exported,or -fvisibilit=hidden) optimizes those calls. In general going through the PLT is very wasteful whenit isn't necessary. There's a bunch of "literature" aboutthis on the web. On Windows, to call a function Foo, you just call Foo.If Foo ends up imported, the linker generates a single instructionfunction for you, Foo, that jumps through __imp__Foo.If you are absolutely sure Foo will be imported and want tooptimize a little, you can mark Foo as __declspec(dllimport),however for functions this is totally optional. To export functions, you either mark them __declspec(dllexport)or list them in a .def file. For C++, .def files are a pain, butfor C they work just fine, or better. For importing data, you pretty much have to mark it as __declspec(dllimport).Importing data is rare.gcc/ld on Windows have some hack to make this easier that I'm not familiar with. So in the absence of importing data, there is just one codegenmodel that is acceptable -- call Foo.Most function calls, theoretically, are not imported, and thisends up as a normal direct call. There may be issues of position-independence, but on AMD64 thisis not relevant. On AMD64_NT, I believe the vast majority ofcode is naturally position-indendent via RIP-relative addressing.It is true that things like vtables might have relocs.I think that is unfortunate. It would be nice to have 100%position independence for .dlls and .exes. On Linux, if you are compiling for a .dll, you must be position-independent,I think fully, and all function calls by default go through the PLT.Maybe to statics don't. But just sharing across two source files does.Every call is therefore indirect, subject to loader machinations ateither load or first-call time, and "interposable" -- someone elsecan export a function of the same name and take over the function.As well, someone else can call these internal functions more easilythan otherwise. Granted, anyone can call any of your code at any time, justby jumping to it. But symbolic exports are considered more attackablesurface area than random code sitting in memory. If you don't use -fPIC, I think all calls are direct.And you can't link into a .dll. And then, really, the truth is in between.Individual calls can be marked one way or the other. But Modula-3 is marking everything as public, exported, subjectto dynamic linking, called through the PLT. As to why only AMD64_LINUX is seeing this, I don't know.I'd have to check how the static link is passed on others andif the loader preserves it. Could be it is an extra parameteron the stack, since x86 has so few registers. Could be AMD64_LINUX could/should pass it another way, butreally, avoiding the PLT for unexported functions seems likepure goodness. I was quite surprised and dismayed to learn about all this lastnight when I was debugging. Why must inline function bodies for unexported functions be preservedanyway? They are just dead code, right? Is there another way to preserve them? If it is <*inline*> on the implementation but listed in the *.i3 file, that should be public/exported. Is it not? I was able to build LINUXLIBC6 this way as far as building on AMD64 gets, which is pretty far -- eventually failing for lack of some X .libs. Oh, I guess I should be sure optimization is on? I didn't twiddle that. I can try again. - Jay From: hosking at cs.purdue.eduTo: jkrell at elegosoft.comDate: Tue, 29 Apr 2008 11:52:24 -0400CC: m3devel at elegosoft.comSubject: [M3devel] Your recent change to parse.c I don't understand your change to parse.c re TREE_PUBLIC being set on procedure declarations. TREE_PUBLIC just means that it is possible to call the procedure from outside the current compilation unit. It has nothing to do with intra-library visibility. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Apr 30 00:01:51 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 29 Apr 2008 22:01:51 +0000 Subject: [M3devel] Popup Windows stalling regression tests on WinXP In-Reply-To: References: <495318.48565.qm@web27105.mail.ukl.yahoo.com> <20080429171117.oopp3fpcpc84ccwk@mail.elegosoft.com> Message-ID: ps: Olaf, the debugger install is incredibly fast and small. This isn't Visual Studio. I get, but hadn't previously considered, that future regressions would hang the machine, so a fix is only "temporary", but hey...maybe a process needs to monitor the tests and kill them if they take too long? SetErrorMode will probably fix this, now that I think more. We can add a switch to cm3 and it can call that on itself, and it always gets inherited by child processes. Or we can have a trivial wrapper .exe to run the tests, if the switch to cm3 is not liked. But I have to test it out. Suggest an .exe or switch name? :) If indeed it is SetErrorMode, I'd do seterrormode.exe Though this is a low level name. It could be testwrapper.exe or quashpopups.exe. -Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Tue, 29 Apr 2008 21:38:14 +0000Subject: Re: [M3devel] Popup Windows stalling regression tests on WinXP Yes, this might be it.My x86 Windows machine is out on loan this week, my AMD64 Windows machine needed a reinstall, and I was deep into debugging the AMD64_LINUX problem (on same machine, multi-boot), so I punted. Now I've reinstalled AMD64 Windows and can debug to see what the problem is, to decide if it is quashable..There should be a way without global changes to the machine, but if that's ok, ok. (If this even it.) - Jay> Date: Tue, 29 Apr 2008 17:11:17 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] Popup Windows stalling regression tests on WinXP> > Quoting "Daniel Alejandro Benavides D." :> > > Hi all:> > Olaf, I don't have the Win box here (just a Kubuntu one). But even > > if you don't want to send the file, one can see the report file in > > a window. Should be with two steps: The first click on the blue > > label "Click here " in the first pop up window. That throws another > > window with a label that you can click-on and actually see it> > Well I found with google the instruction to disable that error pop up:> > http://pcsupport.about.com/od/windowsxp/ht/disableerror.htm> > I hope this helps to you.> > Thanks, that sounds good, I'll try it tonight.> > Olaf> > >> > Thanks> >> > Olaf Wagner escribi?: Quoting "Daniel > > Alejandro Benavides D." :> >> >> Hi all:> >> Olaf, but in the case is not even the cm3 process, but a sub process> >> of it, maybe the linker or/and the assembler (what VS version do> >> you have?) which in turn throws the fault, how do you know from> >> sure is cm3 only causing that?, Can you check the label of "Click> >> here for more information". Then you can click on see the files> >> involved in the fault. There you should see the list of files like> >> dll or lib and executable involved, can you send that info?> >> > I'll restart the tests after some more obvious fixes later this> > evening and may be able to send more information tomorrow.> > IIRC there was no label `click here for more information', but> > just `send report to Microsoft' and `do not send'.> >> > Currently we're working hard on a completely different release...> >> > Olaf> > --> > Olaf Wagner -- elego Software Solutions GmbH> > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> >> >> >> >> > ---------------------------------> >> > Enviado desde Correo Yahoo!> > La bandeja de entrada m?s inteligente.> >> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 jayk123 at hotmail.com Wed Apr 30 00:28:57 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 29 Apr 2008 22:28:57 +0000 Subject: [M3devel] Your recent change to parse.c In-Reply-To: References: Message-ID: simply: probably: calls to finally blocks must not go through PLT definitely: calls to finally blocks must successfully pass the static link (assuming any locals/parameters are used, and don't bother otherwise); perhaps they just be inlined and not even calls; of course it's a bit more than that, I'd have to try except and actually raising exceptions, but as a start, successful runs of finally blocks need to work, they don't currently on AMD64 due to the call through PLT trashing r10 optionally: calls through PLT should be in general decreased as they are just very wasteful; it's disheartening to realize how it currently is inlines that are declared in an .i3 should be callable from other .m3 files in the same "library" and even exportable and callable outside the .dll/.so - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; jkrell at elegosoft.comDate: Tue, 29 Apr 2008 21:57:45 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] Your recent change to parse.c Tony, this is a serious problem on AMD64_LINUX.It is not a problem at all on Win32, as Win32 has amuch better codegen model. It's amazing how Linux works..Look at the .ms file for ThreadPThread.I looked on AMD64_LINUX and LINUXLIBC6.ThreadPThread__InitMutex's call to its own finallyblock goes through the PLT and on AMD64_LINUX the static linkin r10 is trashed.It's possible that if you turn on optimizations, the finallyblock is inlined and that hides the problem, but you can'tcount on that.I was experimenting with another fix at the same time,that of using -fvisibility=hidden on m3cg, butto me that seems more like a C/C++ front end switch,even though cm3cg supports it.I can try again and carefully tweak the two variables,see if -fvisibility=hidden suffices. At the levelcm3cg operates though, it marks the visibility of everythingexplicitly, so again, I think my fix is the way.As well calls within a file to functions within that filethat aren't in an interface are going through the PLT.This is just wasteful.They shouldn't even go through the PLT for calls within thesame "library" (ie: m3core to m3core, libm3 to libm3).What such indirect calls "buy" is that, e.g. the .exe or libm3can replace functions in m3core, or such, and function pointerequality might be achieved. I think the "interposition" featureis widely accepted on Linux, though it is dodgy.I think on Linux going through the PLT for exported functions mightbe the norm. I'll have to read up more. But going through the PLTfor unexported functions is not the norm. Documentation stronglyencourages marking visibility and saving the PLT indirection.In C/C++ there's further problems of name uniquess of unexportedfunctions across the dynamic link. I believe Modula-3 deals with that,since pretty much every function in the system gets a unique name,exported or not. One or the other or both these changes (public = exported,or -fvisibilit=hidden) optimizes those calls.In general going through the PLT is very wasteful whenit isn't necessary. There's a bunch of "literature" aboutthis on the web.On Windows, to call a function Foo, you just call Foo.If Foo ends up imported, the linker generates a single instructionfunction for you, Foo, that jumps through __imp__Foo.If you are absolutely sure Foo will be imported and want tooptimize a little, you can mark Foo as __declspec(dllimport),however for functions this is totally optional.To export functions, you either mark them __declspec(dllexport)or list them in a .def file. For C++, .def files are a pain, butfor C they work just fine, or better.For importing data, you pretty much have to mark it as __declspec(dllimport).Importing data is rare.gcc/ld on Windows have some hack to make this easier that I'm not familiar with.So in the absence of importing data, there is just one codegenmodel that is acceptable -- call Foo.Most function calls, theoretically, are not imported, and thisends up as a normal direct call.There may be issues of position-independence, but on AMD64 thisis not relevant. On AMD64_NT, I believe the vast majority ofcode is naturally position-indendent via RIP-relative addressing.It is true that things like vtables might have relocs.I think that is unfortunate. It would be nice to have 100%position independence for .dlls and .exes. On Linux, if you are compiling for a .dll, you must be position-independent,I think fully, and all function calls by default go through the PLT.Maybe to statics don't. But just sharing across two source files does.Every call is therefore indirect, subject to loader machinations ateither load or first-call time, and "interposable" -- someone elsecan export a function of the same name and take over the function.As well, someone else can call these internal functions more easilythan otherwise. Granted, anyone can call any of your code at any time, justby jumping to it. But symbolic exports are considered more attackablesurface area than random code sitting in memory.If you don't use -fPIC, I think all calls are direct.And you can't link into a .dll.And then, really, the truth is in between.Individual calls can be marked one way or the other.But Modula-3 is marking everything as public, exported, subjectto dynamic linking, called through the PLT.As to why only AMD64_LINUX is seeing this, I don't know.I'd have to check how the static link is passed on others andif the loader preserves it. Could be it is an extra parameteron the stack, since x86 has so few registers.Could be AMD64_LINUX could/should pass it another way, butreally, avoiding the PLT for unexported functions seems likepure goodness.I was quite surprised and dismayed to learn about all this lastnight when I was debugging.Why must inline function bodies for unexported functions be preservedanyway? They are just dead code, right? Is there another way to preserve them?If it is <*inline*> on the implementation but listed in the *.i3 file, that should be public/exported. Is it not? I was able to build LINUXLIBC6 this way as far as building on AMD64 gets, which is pretty far -- eventually failing for lack of some X .libs.Oh, I guess I should be sure optimization is on? I didn't twiddle that. I can try again. - Jay From: hosking at cs.purdue.eduTo: jkrell at elegosoft.comDate: Tue, 29 Apr 2008 11:52:24 -0400CC: m3devel at elegosoft.comSubject: [M3devel] Your recent change to parse.c I don't understand your change to parse.c re TREE_PUBLIC being set on procedure declarations. TREE_PUBLIC just means that it is possible to call the procedure from outside the current compilation unit. It has nothing to do with intra-library visibility. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Apr 30 00:32:28 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 29 Apr 2008 18:32:28 -0400 Subject: [M3devel] Your recent change to parse.c In-Reply-To: References: Message-ID: <78640E3D-7188-456B-98A1-8450D0F9F419@cs.purdue.edu> Jay, thanks for your explanation! If your log message could have had some of this information I might have understood what the need was. OK, I've gone back through the logs and see that I did not put this in for specific optimization reasons, though it may have had a historic basis in making something work. So, let's restore your fix and see what happens. I wonder if it breaks procedure values (code address + static chain records)? On Apr 29, 2008, at 5:57 PM, Jay wrote: > Tony, this is a serious problem on AMD64_LINUX. > It is not a problem at all on Win32, as Win32 has a > much better codegen model. It's amazing how Linux works.. > > Look at the .ms file for ThreadPThread. > I looked on AMD64_LINUX and LINUXLIBC6. > > ThreadPThread__InitMutex's call to its own finally > block goes through the PLT and on AMD64_LINUX the static link > in r10 is trashed. > > It's possible that if you turn on optimizations, the finally > block is inlined and that hides the problem, but you can't > count on that. > > I was experimenting with another fix at the same time, > that of using -fvisibility=hidden on m3cg, but > to me that seems more like a C/C++ front end switch, > even though cm3cg supports it. > > I can try again and carefully tweak the two variables, > see if -fvisibility=hidden suffices. At the level > cm3cg operates though, it marks the visibility of everything > explicitly, so again, I think my fix is the way. > > As well calls within a file to functions within that file > that aren't in an interface are going through the PLT. > This is just wasteful. > > They shouldn't even go through the PLT for calls within the > same "library" (ie: m3core to m3core, libm3 to libm3). > > What such indirect calls "buy" is that, e.g. the .exe or libm3 > can replace functions in m3core, or such, and function pointer > equality might be achieved. I think the "interposition" feature > is widely accepted on Linux, though it is dodgy. > I think on Linux going through the PLT for exported functions might > be the norm. I'll have to read up more. But going through the PLT > for unexported functions is not the norm. Documentation strongly > encourages marking visibility and saving the PLT indirection. > > In C/C++ there's further problems of name uniquess of unexported > functions across the dynamic link. I believe Modula-3 deals with that, > since pretty much every function in the system gets a unique name, > exported or not. > > One or the other or both these changes (public = exported, > or -fvisibilit=hidden) optimizes those calls. > > In general going through the PLT is very wasteful when > it isn't necessary. There's a bunch of "literature" about > this on the web. > > On Windows, to call a function Foo, you just call Foo. > If Foo ends up imported, the linker generates a single instruction > function for you, Foo, that jumps through __imp__Foo. > If you are absolutely sure Foo will be imported and want to > optimize a little, you can mark Foo as __declspec(dllimport), > however for functions this is totally optional. > To export functions, you either mark them __declspec(dllexport) > or list them in a .def file. For C++, .def files are a pain, but > for C they work just fine, or better. > For importing data, you pretty much have to mark it as > __declspec(dllimport). > Importing data is rare. > gcc/ld on Windows have some hack to make this easier that I'm not > familiar with. > > So in the absence of importing data, there is just one codegen > model that is acceptable -- call Foo. > Most function calls, theoretically, are not imported, and this > ends up as a normal direct call. > There may be issues of position-independence, but on AMD64 this > is not relevant. On AMD64_NT, I believe the vast majority of > code is naturally position-indendent via RIP-relative addressing. > It is true that things like vtables might have relocs. > I think that is unfortunate. It would be nice to have 100% > position independence for .dlls and .exes. > > On Linux, if you are compiling for a .dll, you must be position- > independent, > I think fully, and all function calls by default go through the PLT. > Maybe to statics don't. But just sharing across two source files does. > Every call is therefore indirect, subject to loader machinations at > either load or first-call time, and "interposable" -- someone else > can export a function of the same name and take over the function. > As well, someone else can call these internal functions more easily > than otherwise. Granted, anyone can call any of your code at any > time, just > by jumping to it. But symbolic exports are considered more attackable > surface area than random code sitting in memory. > > If you don't use -fPIC, I think all calls are direct. > And you can't link into a .dll. > > And then, really, the truth is in between. > Individual calls can be marked one way or the other. > > But Modula-3 is marking everything as public, exported, subject > to dynamic linking, called through the PLT. > > As to why only AMD64_LINUX is seeing this, I don't know. > I'd have to check how the static link is passed on others and > if the loader preserves it. Could be it is an extra parameter > on the stack, since x86 has so few registers. > > Could be AMD64_LINUX could/should pass it another way, but > really, avoiding the PLT for unexported functions seems like > pure goodness. > > I was quite surprised and dismayed to learn about all this last > night when I was debugging. > > Why must inline function bodies for unexported functions be preserved > anyway? They are just dead code, right? > Is there another way to preserve them? > If it is <*inline*> on the implementation but listed in the *.i3 > file, that should be public/exported. Is it not? I was able to build > LINUXLIBC6 this way as far as building on AMD64 gets, which is > pretty far -- eventually failing for lack of some X .libs. > Oh, I guess I should be sure optimization is on? I didn't twiddle > that. I can try again. > > - Jay > > From: hosking at cs.purdue.edu > To: jkrell at elegosoft.com > Date: Tue, 29 Apr 2008 11:52:24 -0400 > CC: m3devel at elegosoft.com > Subject: [M3devel] Your recent change to parse.c > > I don't understand your change to parse.c re TREE_PUBLIC being set > on procedure declarations. TREE_PUBLIC just means that it is > possible to call the procedure from outside the current compilation > unit. It has nothing to do with intra-library visibility. > > > 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 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Apr 30 02:19:51 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 30 Apr 2008 00:19:51 +0000 Subject: [M3devel] silenly allowing "WINAPI" on all targets? (wrt Popup Windows stalling regression tests on WinXP) In-Reply-To: References: <495318.48565.qm@web27105.mail.ukl.yahoo.com> <20080429171117.oopp3fpcpc84ccwk@mail.elegosoft.com> Message-ID: I think cm3 can just make this call unconditionally. As long as the crash is bubbled up as a failure that is printed or something. There should also be a public interface for collecting and sending the reports without a prompt. Various command line tools (cl, link) now have switches to control this behavior. I know the crash is not in cm3 but what it runs -- the setting is inherited by child processes. So, I have a function that exists and I want to call on Win32, and doesn't exist anywhere else, in which case I want to do nothing. In my opinion, a good way to do this is: something.i3 <* extern WINAPI *> PROCEDURE SetErrorMode(UINT32); I wouldn't mind a way to write this in Modula-3, but the naming is in the way. common/something.c void SetErrorMode(UINT32 a) { /* do nothing */ } and only compile something.c on non-Win32. This raises some issues, that I have raised before. I think WINAPI should be silently ignored for all but NT386. It's a small change. It lets this kind of thing work. I know there are other ideas, like <* extern NT386:WINAPI LINUXLIBC:FOOAPI *> or <* extern SYSAPI *> but really I think what I propose is sufficient (and simplest). I doubt that a generalization or renaming has any point. In fact I'd argue for removing all the synonyms and supporting just __stdcall, __cdecl, __fastcall, and __thiscall, possibly as STDCALL, CDECL, FASTCALL, THISCALL, since Modula-3 doesn't like identifiers to start with underscore, and the last two are optional. As I said/implied before, having multiple calling conventions on one target is a terrible idea and I don't expect it to occur again, not at this level at least. I know, for example, you could describe the Linux kernel as exposing two calling conventions, depending on if there is a "small" or "large" number of parameters, but really, even neither of these two are the "normal" convention and such things always get wrapped up in a little wrapper with the "standard" calling convention of the platform (except on NT386, sort of, where the wrapper is one of a few conventions). Precedent is that calling conventions are allowed in source for other Windows platforms, but are ignored. They might be #defined away sometimes, but I bet the compiler ignores them. This provides better source compatibility. As x86 gradually goes away, people will stop putting these things in. I guess the alternative to my proposal is an extra level of wrapping behind some made up "portable" interface: something.i3: PROCEDURE SetErrorMode(UINT32); win32/something.m3 PROCEDURE SetErrorMode(UINT32 a) = BEGIN WinBase.SetErrorMode(a); END SetErrorMode; posix/something.m3 PROCEDURE SetErrorMode(UINT32 <* unused *> a) = BEGIN (* do nothing *); END SetErrorMode; The alternative does have more flexibility, obviously, if the Posix implementation is anything other than "do nothing", such as even having to return a value, which might be the case here, then it'd go this way. Also this saves there from being a .c file. Is that sleazy to use the same function name in two modules? I know Modula-3 prepends module names always. It seems like a feature more than a bug. Anyway, as before, a gain here would be to reduce the doubled up odbc and maybe opengl .i3 files, which vary only in calling convention. - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comSubject: RE: [M3devel] Popup Windows stalling regression tests on WinXPDate: Tue, 29 Apr 2008 22:01:51 +0000 ps: Olaf, the debugger install is incredibly fast and small.This isn't Visual Studio.I get, but hadn't previously considered, that future regressions would hang the machine, so a fix is only "temporary", but hey...maybe a process needs to monitor the tests and kill them if they take too long? SetErrorMode will probably fix this, now that I think more.We can add a switch to cm3 and it can call that on itself, and it always gets inherited by child processes. Or we can have a trivial wrapper .exe to run the tests, if the switch to cm3 is not liked. But I have to test it out.Suggest an .exe or switch name? :)If indeed it is SetErrorMode, I'd doseterrormode.exe Though this is a low level name.It could be testwrapper.exe or quashpopups.exe. -Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Tue, 29 Apr 2008 21:38:14 +0000Subject: Re: [M3devel] Popup Windows stalling regression tests on WinXP Yes, this might be it.My x86 Windows machine is out on loan this week, my AMD64 Windows machine needed a reinstall, and I was deep into debugging the AMD64_LINUX problem (on same machine, multi-boot), so I punted. Now I've reinstalled AMD64 Windows and can debug to see what the problem is, to decide if it is quashable..There should be a way without global changes to the machine, but if that's ok, ok. (If this even it.) - Jay> Date: Tue, 29 Apr 2008 17:11:17 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] Popup Windows stalling regression tests on WinXP> > Quoting "Daniel Alejandro Benavides D." :> > > Hi all:> > Olaf, I don't have the Win box here (just a Kubuntu one). But even > > if you don't want to send the file, one can see the report file in > > a window. Should be with two steps: The first click on the blue > > label "Click here " in the first pop up window. That throws another > > window with a label that you can click-on and actually see it> > Well I found with google the instruction to disable that error pop up:> > http://pcsupport.about.com/od/windowsxp/ht/disableerror.htm> > I hope this helps to you.> > Thanks, that sounds good, I'll try it tonight.> > Olaf> > >> > Thanks> >> > Olaf Wagner escribi?: Quoting "Daniel > > Alejandro Benavides D." :> >> >> Hi all:> >> Olaf, but in the case is not even the cm3 process, but a sub process> >> of it, maybe the linker or/and the assembler (what VS version do> >> you have?) which in turn throws the fault, how do you know from> >> sure is cm3 only causing that?, Can you check the label of "Click> >> here for more information". Then you can click on see the files> >> involved in the fault. There you should see the list of files like> >> dll or lib and executable involved, can you send that info?> >> > I'll restart the tests after some more obvious fixes later this> > evening and may be able to send more information tomorrow.> > IIRC there was no label `click here for more information', but> > just `send report to Microsoft' and `do not send'.> >> > Currently we're working hard on a completely different release...> >> > Olaf> > --> > Olaf Wagner -- elego Software Solutions GmbH> > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> >> >> >> >> > ---------------------------------> >> > Enviado desde Correo Yahoo!> > La bandeja de entrada m?s inteligente.> >> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 jayk123 at hotmail.com Wed Apr 30 05:25:01 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 30 Apr 2008 03:25:01 +0000 Subject: [M3devel] Your recent change to parse.c In-Reply-To: <78640E3D-7188-456B-98A1-8450D0F9F419@cs.purdue.edu> References: <78640E3D-7188-456B-98A1-8450D0F9F419@cs.purdue.edu> Message-ID: Tony, another thing to try here is: TREE_PUBLIC (p) = (lev == 0); I should have noticed that, and can't confirm right now if itis what I think -- nested procedures and finally/except blocksI assume are (lev > 0). I still think calls through the PLT should be drastically reducedand hope to look into this further. In particular, calls that are known to resolve in the same .soneed not be through the PLT, at least on AMD64. I have to check others. There is a paper dsohowto.pdf that talks about this stuff. So it's not just me. I need to read it more closely but I think it resolves to simply that the front end does know what is in the same .so and can pass the information on to cm3cg. - Jay CC: jkrell at elegosoft.com; m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] Your recent change to parse.cDate: Tue, 29 Apr 2008 18:32:28 -0400 Jay, thanks for your explanation! If your log message could have had some of this information I might have understood what the need was. OK, I've gone back through the logs and see that I did not put this in for specific optimization reasons, though it may have had a historic basis in making something work. So, let's restore your fix and see what happens. I wonder if it breaks procedure values (code address + static chain records)? On Apr 29, 2008, at 5:57 PM, Jay wrote: Tony, this is a serious problem on AMD64_LINUX.It is not a problem at all on Win32, as Win32 has amuch better codegen model. It's amazing how Linux works..Look at the .ms file for ThreadPThread.I looked on AMD64_LINUX and LINUXLIBC6.ThreadPThread__InitMutex's call to its own finallyblock goes through the PLT and on AMD64_LINUX the static linkin r10 is trashed.It's possible that if you turn on optimizations, the finallyblock is inlined and that hides the problem, but you can'tcount on that.I was experimenting with another fix at the same time,that of using -fvisibility=hidden on m3cg, butto me that seems more like a C/C++ front end switch,even though cm3cg supports it.I can try again and carefully tweak the two variables,see if -fvisibility=hidden suffices. At the levelcm3cg operates though, it marks the visibility of everythingexplicitly, so again, I think my fix is the way.As well calls within a file to functions within that filethat aren't in an interface are going through the PLT.This is just wasteful.They shouldn't even go through the PLT for calls within thesame "library" (ie: m3core to m3core, libm3 to libm3).What such indirect calls "buy" is that, e.g. the .exe or libm3can replace functions in m3core, or such, and function pointerequality might be achieved. I think the "interposition" featureis widely accepted on Linux, though it is dodgy.I think on Linux going through the PLT for exported functions mightbe the norm. I'll have to read up more. But going through the PLTfor unexported functions is not the norm. Documentation stronglyencourages marking visibility and saving the PLT indirection.In C/C++ there's further problems of name uniquess of unexportedfunctions across the dynamic link. I believe Modula-3 deals with that,since pretty much every function in the system gets a unique name,exported or not. One or the other or both these changes (public = exported,or -fvisibilit=hidden) optimizes those calls.In general going through the PLT is very wasteful whenit isn't necessary. There's a bunch of "literature" aboutthis on the web.On Windows, to call a function Foo, you just call Foo.If Foo ends up imported, the linker generates a single instructionfunction for you, Foo, that jumps through __imp__Foo.If you are absolutely sure Foo will be imported and want tooptimize a little, you can mark Foo as __declspec(dllimport),however for functions this is totally optional.To export functions, you either mark them __declspec(dllexport)or list them in a .def file. For C++, .def files are a pain, butfor C they work just fine, or better.For importing data, you pretty much have to mark it as __declspec(dllimport).Importing data is rare.gcc/ld on Windows have some hack to make this easier that I'm not familiar with.So in the absence of importing data, there is just one codegenmodel that is acceptable -- call Foo.Most function calls, theoretically, are not imported, and thisends up as a normal direct call.There may be issues of position-independence, but on AMD64 thisis not relevant. On AMD64_NT, I believe the vast majority ofcode is naturally position-indendent via RIP-relative addressing.It is true that things like vtables might have relocs.I think that is unfortunate. It would be nice to have 100%position independence for .dlls and .exes. On Linux, if you are compiling for a .dll, you must be position-independent,I think fully, and all function calls by default go through the PLT.Maybe to statics don't. But just sharing across two source files does.Every call is therefore indirect, subject to loader machinations ateither load or first-call time, and "interposable" -- someone elsecan export a function of the same name and take over the function.As well, someone else can call these internal functions more easilythan otherwise. Granted, anyone can call any of your code at any time, justby jumping to it. But symbolic exports are considered more attackablesurface area than random code sitting in memory.If you don't use -fPIC, I think all calls are direct.And you can't link into a .dll.And then, really, the truth is in between.Individual calls can be marked one way or the other.But Modula-3 is marking everything as public, exported, subjectto dynamic linking, called through the PLT.As to why only AMD64_LINUX is seeing this, I don't know.I'd have to check how the static link is passed on others andif the loader preserves it. Could be it is an extra parameteron the stack, since x86 has so few registers.Could be AMD64_LINUX could/should pass it another way, butreally, avoiding the PLT for unexported functions seems likepure goodness.I was quite surprised and dismayed to learn about all this lastnight when I was debugging.Why must inline function bodies for unexported functions be preservedanyway? They are just dead code, right? Is there another way to preserve them?If it is <*inline*> on the implementation but listed in the *.i3 file, that should be public/exported. Is it not? I was able to build LINUXLIBC6 this way as far as building on AMD64 gets, which is pretty far -- eventually failing for lack of some X .libs.Oh, I guess I should be sure optimization is on? I didn't twiddle that. I can try again. - Jay From: hosking at cs.purdue.eduTo: jkrell at elegosoft.comDate: Tue, 29 Apr 2008 11:52:24 -0400CC: m3devel at elegosoft.comSubject: [M3devel] Your recent change to parse.c I don't understand your change to parse.c re TREE_PUBLIC being set on procedure declarations. TREE_PUBLIC just means that it is possible to call the procedure from outside the current compilation unit. It has nothing to do with intra-library visibility. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Apr 30 08:00:23 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 30 Apr 2008 08:00:23 +0200 Subject: [M3devel] Popup Windows stalling regression tests on WinXP In-Reply-To: <495318.48565.qm@web27105.mail.ukl.yahoo.com> References: <495318.48565.qm@web27105.mail.ukl.yahoo.com> Message-ID: <20080430080023.egxncs5vk4sk0skg@mail.elegosoft.com> This is the only information I can copy&paste into this mail: AppName: cm3.exe AppVer: 0.0.0.0 ModName: ntdll.dll ModVer: 5.1.2600.2180 Offset: 00001230 There is a lot more, but I cannot copy it now (many pages), and copy&paste does not work :-( I'll attach the binary file that the system wants to send to Microsoft in case somebody can decode that. The error occurs reproduciably in test p204. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb??ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 -------------- ??<?xml version="1.0" encoding="UTF-16"?> <DATABASE> <EXE NAME="cm3.exe" FILTER="GRABMI_FILTER_PRIVACY"> <MATCHING_FILE NAME="anim3D.dll" SIZE="480768" CHECKSUM="0x823BB10C" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:48:19" UPTO_LINK_DATE="04/08/2008 00:48:19" /> <MATCHING_FILE NAME="arithmetic.dll" SIZE="1219072" CHECKSUM="0x91EC1B94" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:42:26" UPTO_LINK_DATE="04/07/2008 07:42:26" /> <MATCHING_FILE NAME="binIO.dll" SIZE="10240" CHECKSUM="0xAEC61462" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:51:00" UPTO_LINK_DATE="04/07/2008 07:51:00" /> <MATCHING_FILE NAME="BitVector.dll" SIZE="29184" CHECKSUM="0xF72FA5FB" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:13:22" UPTO_LINK_DATE="04/07/2008 07:13:22" /> <MATCHING_FILE NAME="Calculator.exe" SIZE="13312" CHECKSUM="0x33E2EBD2" MODULE_TYPE="WIN32" PE_CHECKSUM="0xCC73" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:07:16" UPTO_LINK_DATE="04/08/2008 01:07:16" /> <MATCHING_FILE NAME="cit_common.dll" SIZE="8704" CHECKSUM="0xBD445A42" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:11:43" UPTO_LINK_DATE="04/08/2008 01:11:43" /> <MATCHING_FILE NAME="cit_util.dll" SIZE="71680" CHECKSUM="0x7EC274E4" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:12:48" UPTO_LINK_DATE="04/08/2008 01:12:48" /> <MATCHING_FILE NAME="cm3-d5.5.0.exe" SIZE="2465792" CHECKSUM="0x262627D" MODULE_TYPE="WIN32" PE_CHECKSUM="0x25BD65" LINKER_VERSION="0x0" LINK_DATE="12/18/2007 13:38:27" UPTO_LINK_DATE="12/18/2007 13:38:27" /> <MATCHING_FILE NAME="cm3-d5.7.0.exe" SIZE="2610176" CHECKSUM="0x4626C839" MODULE_TYPE="WIN32" PE_CHECKSUM="0x2852D5" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:11:03" UPTO_LINK_DATE="04/07/2008 07:11:03" /> <MATCHING_FILE NAME="cm3.exe" SIZE="2610176" CHECKSUM="0x4626C839" MODULE_TYPE="WIN32" PE_CHECKSUM="0x2852D5" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:11:03" UPTO_LINK_DATE="04/07/2008 07:11:03" /> <MATCHING_FILE NAME="cmpdir.exe" SIZE="419840" CHECKSUM="0x2EF852E6" MODULE_TYPE="WIN32" PE_CHECKSUM="0x6F5C9" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:57:15" UPTO_LINK_DATE="04/07/2008 07:57:15" /> <MATCHING_FILE NAME="cmvbt.dll" SIZE="75264" CHECKSUM="0x635777BC" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:43:24" UPTO_LINK_DATE="04/08/2008 00:43:24" /> <MATCHING_FILE NAME="commandrw.dll" SIZE="7680" CHECKSUM="0x9DC9781E" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:51:33" UPTO_LINK_DATE="04/07/2008 07:51:33" /> <MATCHING_FILE NAME="Cube.exe" SIZE="46080" CHECKSUM="0xD7ABA671" MODULE_TYPE="WIN32" PE_CHECKSUM="0x130C9" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:06:49" UPTO_LINK_DATE="04/08/2008 01:06:49" /> <MATCHING_FILE NAME="db.dll" SIZE="35840" CHECKSUM="0x1EFF81F3" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:38:55" UPTO_LINK_DATE="04/08/2008 00:38:55" /> <MATCHING_FILE NAME="debug.dll" SIZE="6656" CHECKSUM="0xF04EFA2E" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:48:50" UPTO_LINK_DATE="04/07/2008 07:48:50" /> <MATCHING_FILE NAME="deepcopy.dll" SIZE="7680" CHECKSUM="0xAADDF510" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:13:35" UPTO_LINK_DATE="04/08/2008 01:13:35" /> <MATCHING_FILE NAME="DiGraph.dll" SIZE="5632" CHECKSUM="0x5C4C3FA0" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:13:35" UPTO_LINK_DATE="04/07/2008 07:13:35" /> <MATCHING_FILE NAME="dirfp.exe" SIZE="413184" CHECKSUM="0x64276DAC" MODULE_TYPE="WIN32" PE_CHECKSUM="0x6E347" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:58:14" UPTO_LINK_DATE="04/07/2008 07:58:14" /> <MATCHING_FILE NAME="drawcontext.dll" SIZE="80896" CHECKSUM="0x1A411D15" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:14:33" UPTO_LINK_DATE="04/08/2008 01:14:33" /> <MATCHING_FILE NAME="embutils.dll" SIZE="3584" CHECKSUM="0xF9483DB8" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:49:39" UPTO_LINK_DATE="04/07/2008 07:49:39" /> <MATCHING_FILE NAME="events.dll" SIZE="150528" CHECKSUM="0xB2FF58BF" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:35:28" UPTO_LINK_DATE="04/08/2008 00:35:28" /> <MATCHING_FILE NAME="ext.exe" SIZE="660992" CHECKSUM="0xE037ACC0" MODULE_TYPE="WIN32" PE_CHECKSUM="0xA1D01" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:18:47" UPTO_LINK_DATE="04/08/2008 01:18:47" /> <MATCHING_FILE NAME="fisheye.exe" SIZE="309248" CHECKSUM="0x14677CD5" MODULE_TYPE="WIN32" PE_CHECKSUM="0x539B1" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:07:46" UPTO_LINK_DATE="04/08/2008 01:07:46" /> <MATCHING_FILE NAME="fix_nl.exe" SIZE="416256" CHECKSUM="0x1CA96408" MODULE_TYPE="WIN32" PE_CHECKSUM="0x73894" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:12:51" UPTO_LINK_DATE="04/07/2008 07:12:51" /> <MATCHING_FILE NAME="formsedit.exe" SIZE="95232" CHECKSUM="0x9557EA01" MODULE_TYPE="WIN32" PE_CHECKSUM="0x27173" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:46:02" UPTO_LINK_DATE="04/08/2008 00:46:02" /> <MATCHING_FILE NAME="Geometry.dll" SIZE="49664" CHECKSUM="0x6898BD6D" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:14:00" UPTO_LINK_DATE="04/07/2008 07:14:00" /> <MATCHING_FILE NAME="http.dll" SIZE="175104" CHECKSUM="0x8E6BC41A" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:50:33" UPTO_LINK_DATE="04/07/2008 07:50:33" /> <MATCHING_FILE NAME="juno-compiler.dll" SIZE="365056" CHECKSUM="0xAAAC820F" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:05:24" UPTO_LINK_DATE="04/08/2008 01:05:24" /> <MATCHING_FILE NAME="juno-machine.dll" SIZE="175104" CHECKSUM="0xF1339677" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:04:48" UPTO_LINK_DATE="04/08/2008 01:04:48" /> <MATCHING_FILE NAME="Juno.exe" SIZE="769024" CHECKSUM="0xEADA1C8A" MODULE_TYPE="WIN32" PE_CHECKSUM="0xBEA28" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:06:10" UPTO_LINK_DATE="04/08/2008 01:06:10" /> <MATCHING_FILE NAME="jvideo.dll" SIZE="3072" CHECKSUM="0x25A85F31" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:43:46" UPTO_LINK_DATE="04/08/2008 00:43:46" /> <MATCHING_FILE NAME="klexlib.dll" SIZE="79360" CHECKSUM="0xEDD959F" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:16:56" UPTO_LINK_DATE="04/08/2008 01:16:56" /> <MATCHING_FILE NAME="ktoklib.dll" SIZE="57856" CHECKSUM="0x60EB40FE" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:16:20" UPTO_LINK_DATE="04/08/2008 01:16:20" /> <MATCHING_FILE NAME="kyacclib.dll" SIZE="52224" CHECKSUM="0x4DF59544" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:17:23" UPTO_LINK_DATE="04/08/2008 01:17:23" /> <MATCHING_FILE NAME="libbuf.dll" SIZE="10752" CHECKSUM="0xE225AC88" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:48:27" UPTO_LINK_DATE="04/07/2008 07:48:27" /> <MATCHING_FILE NAME="libsio.dll" SIZE="10240" CHECKSUM="0x402B9346" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:48:04" UPTO_LINK_DATE="04/07/2008 07:48:04" /> <MATCHING_FILE NAME="listfuncs.dll" SIZE="15872" CHECKSUM="0x82D3DC0C" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:49:15" UPTO_LINK_DATE="04/07/2008 07:49:15" /> <MATCHING_FILE NAME="m3.dll" SIZE="900608" CHECKSUM="0xCC3412E7" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:06:55" UPTO_LINK_DATE="04/07/2008 07:06:55" /> <MATCHING_FILE NAME="m3browser.exe" SIZE="108032" CHECKSUM="0x2175DA6F" MODULE_TYPE="WIN32" PE_CHECKSUM="0x22355" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:56:47" UPTO_LINK_DATE="04/07/2008 07:56:47" /> <MATCHING_FILE NAME="m3browserhack.exe" SIZE="10240" CHECKSUM="0x981D39D9" MODULE_TYPE="WIN32" PE_CHECKSUM="0x84D8" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:15:53" UPTO_LINK_DATE="04/08/2008 01:15:53" /> <MATCHING_FILE NAME="m3bundle.exe" SIZE="419328" CHECKSUM="0xE00DA5B9" MODULE_TYPE="WIN32" PE_CHECKSUM="0x6FA98" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:12:21" UPTO_LINK_DATE="04/07/2008 07:12:21" /> <MATCHING_FILE NAME="m3codeview.dll" SIZE="48128" CHECKSUM="0xEC827D5C" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:46:28" UPTO_LINK_DATE="04/08/2008 00:46:28" /> <MATCHING_FILE NAME="m3core.dll" SIZE="453120" CHECKSUM="0xFE42B480" MODULE_TYPE="WIN32" PE_CHECKSUM="0x7DC99" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:05:45" UPTO_LINK_DATE="04/07/2008 07:05:45" /> <MATCHING_FILE NAME="m3formsvbt.dll" SIZE="321536" CHECKSUM="0x74283C1A" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:45:16" UPTO_LINK_DATE="04/08/2008 00:45:16" /> <MATCHING_FILE NAME="m3formsvbtpixmaps.dll" SIZE="41984" CHECKSUM="0xD32CC0F2" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:44:50" UPTO_LINK_DATE="04/08/2008 00:44:50" /> <MATCHING_FILE NAME="m3markup.dll" SIZE="61952" CHECKSUM="0x275E2179" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:56:25" UPTO_LINK_DATE="04/07/2008 07:56:25" /> <MATCHING_FILE NAME="m3mg.dll" SIZE="150016" CHECKSUM="0x933B256B" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:46:53" UPTO_LINK_DATE="04/08/2008 00:46:53" /> <MATCHING_FILE NAME="m3mgkit.dll" SIZE="258048" CHECKSUM="0x8E793FF" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:47:21" UPTO_LINK_DATE="04/08/2008 00:47:21" /> <MATCHING_FILE NAME="m3netobj.dll" SIZE="163328" CHECKSUM="0xF3EEB081" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:33:33" UPTO_LINK_DATE="04/08/2008 00:33:33" /> <MATCHING_FILE NAME="m3parseparams.dll" SIZE="12800" CHECKSUM="0x5679B98A" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:13:47" UPTO_LINK_DATE="04/07/2008 07:13:47" /> <MATCHING_FILE NAME="m3scan.dll" SIZE="26624" CHECKSUM="0x4B4C853" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:55:59" UPTO_LINK_DATE="04/07/2008 07:55:59" /> <MATCHING_FILE NAME="m3slisp.dll" SIZE="75776" CHECKSUM="0xA6274123" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:14:30" UPTO_LINK_DATE="04/07/2008 07:14:30" /> <MATCHING_FILE NAME="m3smalldb.dll" SIZE="18944" CHECKSUM="0xFBFCFF44" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:39:33" UPTO_LINK_DATE="04/08/2008 00:39:33" /> <MATCHING_FILE NAME="m3tcp.dll" SIZE="40448" CHECKSUM="0x2CDEA533" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:47:24" UPTO_LINK_DATE="04/07/2008 07:47:24" /> <MATCHING_FILE NAME="m3tk-misc.dll" SIZE="60928" CHECKSUM="0x5AFD1714" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:50:06" UPTO_LINK_DATE="04/07/2008 07:50:06" /> <MATCHING_FILE NAME="m3tk.dll" SIZE="1691648" CHECKSUM="0x499FCE79" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:53:43" UPTO_LINK_DATE="04/07/2008 07:53:43" /> <MATCHING_FILE NAME="m3tmplhack.exe" SIZE="463872" CHECKSUM="0x59869FAE" MODULE_TYPE="WIN32" PE_CHECKSUM="0x7DC69" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:12:11" UPTO_LINK_DATE="04/08/2008 01:12:11" /> <MATCHING_FILE NAME="m3tohtml.exe" SIZE="680448" CHECKSUM="0xE7446678" MODULE_TYPE="WIN32" PE_CHECKSUM="0xA6717" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:55:26" UPTO_LINK_DATE="04/07/2008 07:55:26" /> <MATCHING_FILE NAME="m3totex.exe" SIZE="22528" CHECKSUM="0x913128DB" MODULE_TYPE="WIN32" PE_CHECKSUM="0x789E" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:55:00" UPTO_LINK_DATE="04/07/2008 07:55:00" /> <MATCHING_FILE NAME="m3ui.dll" SIZE="690688" CHECKSUM="0xC8B3CE03" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:41:35" UPTO_LINK_DATE="04/08/2008 00:41:35" /> <MATCHING_FILE NAME="m3unit-numeric.dll" SIZE="6656" CHECKSUM="0x8ED35521" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:43:48" UPTO_LINK_DATE="04/07/2008 07:43:48" /> <MATCHING_FILE NAME="m3unit.dll" SIZE="11776" CHECKSUM="0x5A90BF01" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:08:06" UPTO_LINK_DATE="04/07/2008 07:08:06" /> <MATCHING_FILE NAME="m3vbtkit.dll" SIZE="803328" CHECKSUM="0xF78DE500" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:42:45" UPTO_LINK_DATE="04/08/2008 00:42:45" /> <MATCHING_FILE NAME="m3zeus.dll" SIZE="193536" CHECKSUM="0x66C70909" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:48:59" UPTO_LINK_DATE="04/08/2008 00:48:59" /> <MATCHING_FILE NAME="m3zume.exe" SIZE="98816" CHECKSUM="0x818FF503" MODULE_TYPE="WIN32" PE_CHECKSUM="0x220C1" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:49:25" UPTO_LINK_DATE="04/08/2008 00:49:25" /> <MATCHING_FILE NAME="mentor.exe" SIZE="2422784" CHECKSUM="0x894619CE" MODULE_TYPE="WIN32" PE_CHECKSUM="0x251B4E" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:10:20" UPTO_LINK_DATE="04/08/2008 01:10:20" /> <MATCHING_FILE NAME="metasyn.dll" SIZE="60416" CHECKSUM="0x5468CC37" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:50:33" UPTO_LINK_DATE="04/08/2008 00:50:33" /> <MATCHING_FILE NAME="mklib.exe" SIZE="469504" CHECKSUM="0xB73A8C0D" MODULE_TYPE="WIN32" PE_CHECKSUM="0x7A22B" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:12:35" UPTO_LINK_DATE="04/07/2008 07:12:35" /> <MATCHING_FILE NAME="netobjd.exe" SIZE="740352" CHECKSUM="0xB9498D42" MODULE_TYPE="WIN32" PE_CHECKSUM="0xB84DF" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:33:57" UPTO_LINK_DATE="04/08/2008 00:33:57" /> <MATCHING_FILE NAME="obliq-anim.exe" SIZE="8192" CHECKSUM="0xA7016EDE" MODULE_TYPE="WIN32" PE_CHECKSUM="0x49B1" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:57:23" UPTO_LINK_DATE="04/08/2008 00:57:23" /> <MATCHING_FILE NAME="obliq-min.exe" SIZE="7168" CHECKSUM="0xE52FCFC9" MODULE_TYPE="WIN32" PE_CHECKSUM="0xB6EF" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:55:54" UPTO_LINK_DATE="04/08/2008 00:55:54" /> <MATCHING_FILE NAME="obliq-std.exe" SIZE="1801728" CHECKSUM="0x58C1C1A5" MODULE_TYPE="WIN32" PE_CHECKSUM="0x1BD08F" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:56:18" UPTO_LINK_DATE="04/08/2008 00:56:18" /> <MATCHING_FILE NAME="obliq-ui.exe" SIZE="8192" CHECKSUM="0xD3965549" MODULE_TYPE="WIN32" PE_CHECKSUM="0x636F" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:56:49" UPTO_LINK_DATE="04/08/2008 00:56:49" /> <MATCHING_FILE NAME="obliq.dll" SIZE="97280" CHECKSUM="0xB788243" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:52:59" UPTO_LINK_DATE="04/08/2008 00:52:59" /> <MATCHING_FILE NAME="obliqlib3D.dll" SIZE="558592" CHECKSUM="0x467E1BA3" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:58:23" UPTO_LINK_DATE="04/08/2008 00:58:23" /> <MATCHING_FILE NAME="obliqlibanim.dll" SIZE="115712" CHECKSUM="0x8F8DA488" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:54:49" UPTO_LINK_DATE="04/08/2008 00:54:49" /> <MATCHING_FILE NAME="obliqlibemb.dll" SIZE="43008" CHECKSUM="0xE3A39039" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:53:39" UPTO_LINK_DATE="04/08/2008 00:53:39" /> <MATCHING_FILE NAME="obliqlibm3.dll" SIZE="68608" CHECKSUM="0x9F00F489" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:54:03" UPTO_LINK_DATE="04/08/2008 00:54:03" /> <MATCHING_FILE NAME="obliqlibui.dll" SIZE="86528" CHECKSUM="0xE452A083" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:54:27" UPTO_LINK_DATE="04/08/2008 00:54:27" /> <MATCHING_FILE NAME="obliqparse.dll" SIZE="109568" CHECKSUM="0x119B3185" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:51:58" UPTO_LINK_DATE="04/08/2008 00:51:58" /> <MATCHING_FILE NAME="obliqprint.dll" SIZE="55296" CHECKSUM="0xCACF7E42" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:52:22" UPTO_LINK_DATE="04/08/2008 00:52:22" /> <MATCHING_FILE NAME="obliqrt.dll" SIZE="399872" CHECKSUM="0x1E58E57D" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:51:20" UPTO_LINK_DATE="04/08/2008 00:51:20" /> <MATCHING_FILE NAME="obliqsrv-std.exe" SIZE="8704" CHECKSUM="0x46689203" MODULE_TYPE="WIN32" PE_CHECKSUM="0xFDDC" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:55:08" UPTO_LINK_DATE="04/08/2008 00:55:08" /> <MATCHING_FILE NAME="obliqsrv-ui.exe" SIZE="8704" CHECKSUM="0xB1EE543D" MODULE_TYPE="WIN32" PE_CHECKSUM="0xF242" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:55:31" UPTO_LINK_DATE="04/08/2008 00:55:31" /> <MATCHING_FILE NAME="odbc.dll" SIZE="4096" CHECKSUM="0xF8BE9A14" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:37:54" UPTO_LINK_DATE="04/08/2008 00:37:54" /> <MATCHING_FILE NAME="opengl.dll" SIZE="3584" CHECKSUM="0xB2C33385" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:47:44" UPTO_LINK_DATE="04/08/2008 00:47:44" /> <MATCHING_FILE NAME="parserlib.dll" SIZE="12800" CHECKSUM="0x5502B841" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:19:18" UPTO_LINK_DATE="04/08/2008 01:19:18" /> <MATCHING_FILE NAME="patternmatching.dll" SIZE="24064" CHECKSUM="0x8373AD2D" MODULE_TYPE="WIN32" PE_CHECKSUM="0xFDD7" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:07:27" UPTO_LINK_DATE="04/07/2008 07:07:27" /> <MATCHING_FILE NAME="rdwr.dll" SIZE="32256" CHECKSUM="0x7B9046A7" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:36:01" UPTO_LINK_DATE="04/08/2008 00:36:01" /> <MATCHING_FILE NAME="RehearseCode.exe" SIZE="25088" CHECKSUM="0xD3390093" MODULE_TYPE="WIN32" PE_CHECKSUM="0xDAA9" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:01:59" UPTO_LINK_DATE="04/08/2008 01:01:59" /> <MATCHING_FILE NAME="replayheap.exe" SIZE="15360" CHECKSUM="0x52932983" MODULE_TYPE="WIN32" PE_CHECKSUM="0x545F" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:02:26" UPTO_LINK_DATE="04/08/2008 01:02:26" /> <MATCHING_FILE NAME="serialio.dll" SIZE="8704" CHECKSUM="0x4E2838D6" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:52:26" UPTO_LINK_DATE="04/07/2008 07:52:26" /> <MATCHING_FILE NAME="set.dll" SIZE="53248" CHECKSUM="0x3EA73D8F" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:14:18" UPTO_LINK_DATE="04/07/2008 07:14:18" /> <MATCHING_FILE NAME="sgml.dll" SIZE="149504" CHECKSUM="0x7F0C814D" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:20:38" UPTO_LINK_DATE="04/08/2008 01:20:38" /> <MATCHING_FILE NAME="sharedobj.dll" SIZE="193024" CHECKSUM="0x2F138704" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:36:34" UPTO_LINK_DATE="04/08/2008 00:36:34" /> <MATCHING_FILE NAME="shobjcodegen.exe" SIZE="1941504" CHECKSUM="0xE2CE99C2" MODULE_TYPE="WIN32" PE_CHECKSUM="0x1E04EE" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:37:08" UPTO_LINK_DATE="04/08/2008 00:37:08" /> <MATCHING_FILE NAME="showheap.exe" SIZE="22528" CHECKSUM="0xFA5909F9" MODULE_TYPE="WIN32" PE_CHECKSUM="0x6897" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:02:52" UPTO_LINK_DATE="04/08/2008 01:02:52" /> <MATCHING_FILE NAME="shownew.exe" SIZE="32256" CHECKSUM="0xEA1457E3" MODULE_TYPE="WIN32" PE_CHECKSUM="0xB820" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:03:18" UPTO_LINK_DATE="04/08/2008 01:03:18" /> <MATCHING_FILE NAME="showthread.exe" SIZE="16384" CHECKSUM="0x31F5DB4C" MODULE_TYPE="WIN32" PE_CHECKSUM="0x8316" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:03:44" UPTO_LINK_DATE="04/08/2008 01:03:44" /> <MATCHING_FILE NAME="SortedTableExtras.dll" SIZE="33280" CHECKSUM="0x7991D3EC" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:14:42" UPTO_LINK_DATE="04/07/2008 07:14:42" /> <MATCHING_FILE NAME="stable.dll" SIZE="27648" CHECKSUM="0xF3B16723" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:40:34" UPTO_LINK_DATE="04/08/2008 00:40:34" /> <MATCHING_FILE NAME="stablegen.exe" SIZE="1832960" CHECKSUM="0xBF99DCCB" MODULE_TYPE="WIN32" PE_CHECKSUM="0x1CBB89" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:39:56" UPTO_LINK_DATE="04/08/2008 00:39:56" /> <MATCHING_FILE NAME="stubgen.exe" SIZE="1844224" CHECKSUM="0x61009FC5" MODULE_TYPE="WIN32" PE_CHECKSUM="0x1C7A67" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:34:34" UPTO_LINK_DATE="04/08/2008 00:34:34" /> <MATCHING_FILE NAME="synex.dll" SIZE="60928" CHECKSUM="0x1642437E" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:50:10" UPTO_LINK_DATE="04/08/2008 00:50:10" /> <MATCHING_FILE NAME="synwr.dll" SIZE="13824" CHECKSUM="0xB1A73466" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:49:49" UPTO_LINK_DATE="04/08/2008 00:49:49" /> <MATCHING_FILE NAME="sysutils.dll" SIZE="113152" CHECKSUM="0x17DC14FE" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:07:52" UPTO_LINK_DATE="04/07/2008 07:07:52" /> <MATCHING_FILE NAME="table-list.dll" SIZE="49152" CHECKSUM="0x6D75D670" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:14:55" UPTO_LINK_DATE="04/07/2008 07:14:55" /> <MATCHING_FILE NAME="TempFiles.dll" SIZE="6656" CHECKSUM="0x9C140244" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/07/2008 07:15:07" UPTO_LINK_DATE="04/07/2008 07:15:07" /> <MATCHING_FILE NAME="tok.exe" SIZE="532992" CHECKSUM="0x9944F2E6" MODULE_TYPE="WIN32" PE_CHECKSUM="0x891E6" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:17:46" UPTO_LINK_DATE="04/08/2008 01:17:46" /> <MATCHING_FILE NAME="videovbt.dll" SIZE="9216" CHECKSUM="0x2237D9BE" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:44:07" UPTO_LINK_DATE="04/08/2008 00:44:07" /> <MATCHING_FILE NAME="visobliq.exe" SIZE="414208" CHECKSUM="0x97B860F1" MODULE_TYPE="WIN32" PE_CHECKSUM="0x6C676" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:59:02" UPTO_LINK_DATE="04/08/2008 00:59:02" /> <MATCHING_FILE NAME="vocgi.exe" SIZE="51712" CHECKSUM="0xDE0557FD" MODULE_TYPE="WIN32" PE_CHECKSUM="0x10853" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:59:33" UPTO_LINK_DATE="04/08/2008 00:59:33" /> <MATCHING_FILE NAME="voquery.exe" SIZE="9216" CHECKSUM="0xC2E99515" MODULE_TYPE="WIN32" PE_CHECKSUM="0xD556" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:00:01" UPTO_LINK_DATE="04/08/2008 01:00:01" /> <MATCHING_FILE NAME="vorun.exe" SIZE="80896" CHECKSUM="0xF5FF2444" MODULE_TYPE="WIN32" PE_CHECKSUM="0x23646" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:00:34" UPTO_LINK_DATE="04/08/2008 01:00:34" /> <MATCHING_FILE NAME="web.dll" SIZE="20480" CHECKSUM="0x4AD2B1F7" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 00:44:29" UPTO_LINK_DATE="04/08/2008 00:44:29" /> <MATCHING_FILE NAME="webvbt.dll" SIZE="180736" CHECKSUM="0x8823E2FB" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="04/08/2008 01:01:13" UPTO_LINK_DATE="04/08/2008 01:01:13" /> </EXE> <EXE NAME="ntdll.dll" FILTER="GRABMI_FILTER_THISFILEONLY"> <MATCHING_FILE NAME="ntdll.dll" SIZE="708096" CHECKSUM="0x9D20568" BIN_FILE_VERSION="5.1.2600.2180" BIN_PRODUCT_VERSION="5.1.2600.2180" PRODUCT_VERSION="5.1.2600.2180" FILE_DESCRIPTION="NT Layer DLL" COMPANY_NAME="Microsoft Corporation" PRODUCT_NAME="Microsoft? Windows? Operating System" FILE_VERSION="5.1.2600.2180 (xpsp_sp2_rtm.040803-2158)" ORIGINAL_FILENAME="ntdll.dll" INTERNAL_NAME="ntdll.dll" LEGAL_COPYRIGHT="? Microsoft Corporation. All rights reserved." VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x40004" VERFILETYPE="0x2" MODULE_TYPE="WIN32" PE_CHECKSUM="0xAF2F7" LINKER_VERSION="0x50001" UPTO_BIN_FILE_VERSION="5.1.2600.2180" UPTO_BIN_PRODUCT_VERSION="5.1.2600.2180" LINK_DATE="08/04/2004 07:56:36" UPTO_LINK_DATE="08/04/2004 07:56:36" VER_LANGUAGE="English (United States) [0x409]" /> </EXE> <EXE NAME="kernel32.dll" FILTER="GRABMI_FILTER_THISFILEONLY"> <MATCHING_FILE NAME="kernel32.dll" SIZE="984576" CHECKSUM="0xF0B331F6" BIN_FILE_VERSION="5.1.2600.3119" BIN_PRODUCT_VERSION="5.1.2600.3119" PRODUCT_VERSION="5.1.2600.3119" FILE_DESCRIPTION="Windows NT BASE API Client DLL" COMPANY_NAME="Microsoft Corporation" PRODUCT_NAME="Microsoft? Windows? Operating System" FILE_VERSION="5.1.2600.3119 (xpsp_sp2_gdr.070416-1301)" ORIGINAL_FILENAME="kernel32" INTERNAL_NAME="kernel32" LEGAL_COPYRIGHT="? Microsoft Corporation. All rights reserved." VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x40004" VERFILETYPE="0x2" MODULE_TYPE="WIN32" PE_CHECKSUM="0xF9293" LINKER_VERSION="0x50001" UPTO_BIN_FILE_VERSION="5.1.2600.3119" UPTO_BIN_PRODUCT_VERSION="5.1.2600.3119" LINK_DATE="04/16/2007 15:52:53" UPTO_LINK_DATE="04/16/2007 15:52:53" VER_LANGUAGE="English (United States) [0x409]" /> </EXE> </DATABASE> From jayk123 at hotmail.com Wed Apr 30 14:40:17 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 30 Apr 2008 12:40:17 +0000 Subject: [M3devel] silenly allowing "WINAPI" on all targets? (wrt Popup Windows stalling regression tests In-Reply-To: References: <495318.48565.qm@web27105.mail.ukl.yahoo.com> <20080429171117.oopp3fpcpc84ccwk@mail.elegosoft.com> Message-ID: I still really like this idea, but this turned out to be something else.. - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Wed, 30 Apr 2008 00:19:51 +0000Subject: [M3devel] silenly allowing "WINAPI" on all targets? (wrt Popup Windows stalling regression tests on WinXP) I think cm3 can just make this call unconditionally. As long as the crash is bubbled up as a failure that is printed or something. There should also be a public interface for collecting and sending the reports without a prompt. Various command line tools (cl, link) now have switches to control this behavior.I know the crash is not in cm3 but what it runs -- the setting is inherited by child processes. So, I have a function that exists and I want to call on Win32, and doesn't exist anywhere else, in which case I want to do nothing. In my opinion, a good way to do this is: something.i3 <* extern WINAPI *> PROCEDURE SetErrorMode(UINT32); I wouldn't mind a way to write this in Modula-3, but the naming is in the way.common/something.c void SetErrorMode(UINT32 a) { /* do nothing */ } and only compile something.c on non-Win32. This raises some issues, that I have raised before. I think WINAPI should be silently ignored for all but NT386.It's a small change. It lets this kind of thing work. I know there are other ideas, like <* extern NT386:WINAPI LINUXLIBC:FOOAPI *>or <* extern SYSAPI *> but really I think what I propose is sufficient (and simplest).I doubt that a generalization or renaming has any point.In fact I'd argue for removing all the synonyms and supporting just __stdcall, __cdecl, __fastcall, and __thiscall, possibly as STDCALL, CDECL, FASTCALL, THISCALL, since Modula-3 doesn't like identifiers to start with underscore, and the last two are optional. As I said/implied before, having multiple calling conventions on one target is a terrible idea and I don't expect it to occur again, not at this level at least. I know, for example, you could describe the Linux kernel as exposing two calling conventions, depending on if there is a "small" or "large" number of parameters, but really, even neither of these two are the "normal" convention and such things always get wrapped up in a little wrapper with the "standard" calling convention of the platform (except on NT386, sort of, where the wrapper is one of a few conventions). Precedent is that calling conventions are allowed in source for other Windows platforms, but are ignored.They might be #defined away sometimes, but I bet the compiler ignores them.This provides better source compatibility.As x86 gradually goes away, people will stop putting these things in. I guess the alternative to my proposal is an extra level of wrapping behind some made up "portable" interface: something.i3: PROCEDURE SetErrorMode(UINT32); win32/something.m3 PROCEDURE SetErrorMode(UINT32 a) = BEGIN WinBase.SetErrorMode(a); END SetErrorMode; posix/something.m3 PROCEDURE SetErrorMode(UINT32 <* unused *> a) = BEGIN (* do nothing *); END SetErrorMode; The alternative does have more flexibility, obviously, if the Posix implementation is anything other than "do nothing", such as even having to return a value, which might be the case here, then it'd go this way. Also this saves there from being a .c file. Is that sleazy to use the same function name in two modules? I know Modula-3 prepends module names always. It seems like a feature more than a bug. Anyway, as before, a gain here would be to reduce the doubled up odbc and maybe opengl .i3 files, which vary only in calling convention. - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comSubject: RE: [M3devel] Popup Windows stalling regression tests on WinXPDate: Tue, 29 Apr 2008 22:01:51 +0000 ps: Olaf, the debugger install is incredibly fast and small.This isn't Visual Studio.I get, but hadn't previously considered, that future regressions would hang the machine, so a fix is only "temporary", but hey...maybe a process needs to monitor the tests and kill them if they take too long? SetErrorMode will probably fix this, now that I think more.We can add a switch to cm3 and it can call that on itself, and it always gets inherited by child processes. Or we can have a trivial wrapper .exe to run the tests, if the switch to cm3 is not liked. But I have to test it out.Suggest an .exe or switch name? :)If indeed it is SetErrorMode, I'd doseterrormode.exe Though this is a low level name.It could be testwrapper.exe or quashpopups.exe. -Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Tue, 29 Apr 2008 21:38:14 +0000Subject: Re: [M3devel] Popup Windows stalling regression tests on WinXP Yes, this might be it.My x86 Windows machine is out on loan this week, my AMD64 Windows machine needed a reinstall, and I was deep into debugging the AMD64_LINUX problem (on same machine, multi-boot), so I punted. Now I've reinstalled AMD64 Windows and can debug to see what the problem is, to decide if it is quashable..There should be a way without global changes to the machine, but if that's ok, ok. (If this even it.) - Jay> Date: Tue, 29 Apr 2008 17:11:17 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] Popup Windows stalling regression tests on WinXP> > Quoting "Daniel Alejandro Benavides D." :> > > Hi all:> > Olaf, I don't have the Win box here (just a Kubuntu one). But even > > if you don't want to send the file, one can see the report file in > > a window. Should be with two steps: The first click on the blue > > label "Click here " in the first pop up window. That throws another > > window with a label that you can click-on and actually see it> > Well I found with google the instruction to disable that error pop up:> > http://pcsupport.about.com/od/windowsxp/ht/disableerror.htm> > I hope this helps to you.> > Thanks, that sounds good, I'll try it tonight.> > Olaf> > >> > Thanks> >> > Olaf Wagner escribi?: Quoting "Daniel > > Alejandro Benavides D." :> >> >> Hi all:> >> Olaf, but in the case is not even the cm3 process, but a sub process> >> of it, maybe the linker or/and the assembler (what VS version do> >> you have?) which in turn throws the fault, how do you know from> >> sure is cm3 only causing that?, Can you check the label of "Click> >> here for more information". Then you can click on see the files> >> involved in the fault. There you should see the list of files like> >> dll or lib and executable involved, can you send that info?> >> > I'll restart the tests after some more obvious fixes later this> > evening and may be able to send more information tomorrow.> > IIRC there was no label `click here for more information', but> > just `send report to Microsoft' and `do not send'.> >> > Currently we're working hard on a completely different release...> >> > Olaf> > --> > Olaf Wagner -- elego Software Solutions GmbH> > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> >> >> >> >> > ---------------------------------> >> > Enviado desde Correo Yahoo!> > La bandeja de entrada m?s inteligente.> >> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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: